a) Where is White Shoes being written? b) Is it going to be a written document, or an executable test / spec suite, or both? -- ~devyn
http://blog.shoesrb.com/post/1306003281/a-rainbow-of-shoes-white-shoes
Ah, okay. Perfect. I'm curious as to how you're going to write user interaction specs (checking if things display properly, simulating clicks, keys, etc.) On Sun, Oct 17, 2010 at 3:13 PM, Steve Klabnik <steve@steveklabnik.com>wrote: > http://blog.shoesrb.com/post/1306003281/a-rainbow-of-shoes-white-shoes > -- ~devyn
On Sun, 2010-10-17 at 20:16 -0700, Devyn Cairns wrote: > I'm curious as to how you're going to write user interaction specs > (checking if things display properly, simulating clicks, keys, etc.) Devyn, you are such a pessimist ;^) It must be time for a cranky Cecil rant. Using deep introspection meta programming into the C/C++ code, set up baseline set of screenshots and train a series of neural networks to recognize the widgets on each platform and the text and state of them and their spacial relationship along with background color and font style attributes. Then compare all the would be new Shoes contenders (similarly instrumented with snapshots of course) Dudes, It's Simples! Joking aside, Something like the old AppleScript could be re-invented 'send keydown to widget1 of window 2' Preceded and followed by commands to sample the gui state, 'Ask position of Widget 1 of Window 2. That only worked if the app was written to allow that level of introspection by an outside process. It's probably easier in Cocoa than back in the early days of AppleScript. There's probably a Microsoft 'Innovation' somewhere. I think there is a Gnome/python facility for scripting GUI's like Applescript does. There's probably a Ruby gem to do the same on Linux. Just unify them. Simples. Writing, verifying and maintaining those tests would be harder than writing the code it's testing. Still, it could happen. Shoes could be rewritten in Adobe Air or Python or JavaScript or Visual Basic quicker than a GUI test suite. IMO. God bless the dreamers, there can be no progress without them. Dreamers on a small project like Shoes also have to walk the talk. Ie: write the code they want, like the gtk/qt/java/ folks are working on. Fluffy visions, good intentions and politically correct talking points won't make a code base appear out of the misty abyss. If White shoes provides a useful spec or test suite or can generate the source code for red/green/blue/black/brown Shoes on demand, then developers will adopt it. Meanwhile, my 30 day old pull request into Red Shoes has not been accepted, rejected or modified, nor is there any talk of a 3.1 bug release or fixing the OSX/MSW packaging mess. I know when to stop resuscitating a dead horse. To mis-quote Scotty of Star Trek, "It's dead Jim. Your red Shoes are dead". I'm not blaming anyone or pointing fingers at anyone. We did our best and we weren't up to the task. We were lacking in ability to keep Red Shoes alive. There's no shame in admitting to our failures and weaknesses. Shameful is pretending Red Shoes is ever going to be fixed. [Rant off] > > On Sun, Oct 17, 2010 at 3:13 PM, Steve Klabnik > <steve@steveklabnik.com> wrote: > http://blog.shoesrb.com/post/1306003281/a-rainbow-of-shoes-white-shoes > > > > -- > ~devyn >
I kind of came up with a quick and hacky solution in brown_shoes of trying to give each element (or widget) an id. Then in my specs, being able to access individual elements based off the object returned by the app call. According to Peter Fitzgibbons, I've got a lot to learn about mocking, but until that happens, I've got a working spec solution now :) On Mon, Oct 18, 2010 at 3:02 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Sun, 2010-10-17 at 20:16 -0700, Devyn Cairns wrote: > > > I'm curious as to how you're going to write user interaction specs > > (checking if things display properly, simulating clicks, keys, etc.) > > Devyn, you are such a pessimist ;^) > > It must be time for a cranky Cecil rant. > > Using deep introspection meta programming into the C/C++ code, set up > baseline set of screenshots and train a series of neural networks to > recognize the widgets on each platform and the text and state of them > and their spacial relationship along with background color and font > style attributes. Then compare all the would be new Shoes contenders > (similarly instrumented with snapshots of course) Dudes, It's Simples! > > Joking aside, Something like the old AppleScript could be re-invented > 'send keydown to widget1 of window 2' Preceded and followed by commands > to sample the gui state, 'Ask position of Widget 1 of Window 2. That > only worked if the app was written to allow that level of introspection > by an outside process. It's probably easier in Cocoa than back in the > early days of AppleScript. There's probably a Microsoft 'Innovation' > somewhere. I think there is a Gnome/python facility for scripting GUI's > like Applescript does. There's probably a Ruby gem to do the same on > Linux. Just unify them. Simples. > > Writing, verifying and maintaining those tests would be harder than > writing the code it's testing. Still, it could happen. Shoes could be > rewritten in Adobe Air or Python or JavaScript or Visual Basic quicker > than a GUI test suite. IMO. > > God bless the dreamers, there can be no progress without them. Dreamers > on a small project like Shoes also have to walk the talk. Ie: write the > code they want, like the gtk/qt/java/ folks are working on. > > Fluffy visions, good intentions and politically correct talking points > won't make a code base appear out of the misty abyss. If White shoes > provides a useful spec or test suite or can generate the source code for > red/green/blue/black/brown Shoes on demand, then developers will adopt > it. > > Meanwhile, my 30 day old pull request into Red Shoes has not been > accepted, rejected or modified, nor is there any talk of a 3.1 bug > release or fixing the OSX/MSW packaging mess. I know when to stop > resuscitating a dead horse. To mis-quote Scotty of Star Trek, "It's dead > Jim. Your red Shoes are dead". > > I'm not blaming anyone or pointing fingers at anyone. We did our best > and we weren't up to the task. We were lacking in ability to keep Red > Shoes alive. There's no shame in admitting to our failures and > weaknesses. Shameful is pretending Red Shoes is ever going to be fixed. > > [Rant off] > > > > > On Sun, Oct 17, 2010 at 3:13 PM, Steve Klabnik > > <steve@steveklabnik.com> wrote: > > > http://blog.shoesrb.com/post/1306003281/a-rainbow-of-shoes-white-shoes > > > > > > > > -- > > ~devyn > > > > >
Re: Testing The upper hand we have here above Python (sorta), AIR, .NET, is that our very dynamic language Ruby and its robust reflection and reopening allows our code to side-step "UI" testing entirely. There is a principle I follow in all my testing, sometimes very difficult to follow without determination : Don't Test The Framework. So that means, don't attempt to test that : A button appears on the form, in the location indicated. The application appears on the screeen. A click event makes widget xyz do a dance. Do test : That your code instantiating Button is executed in the proper order, and contains the expected attributes. The application "view" is executed when expected (thought not actually, at test time, through mocking). The expected event code is attached to the correct widget at instantiation. The expected "other" widget is referenced and controlled during the click event. From a 37s blog entry : The Epicenter based Developer : Don't worry about the frosting... just bake the cake! Peter Fitzgibbons (847) 859-9550 Email: peter.fitzgibbons@gmail.com IM GTalk: peter.fitzgibbons IM AOL: peter.fitzgibbons@gmail.com On Mon, Oct 18, 2010 at 7:42 AM, Scott Werner <stwerner@vt.edu> wrote: > I kind of came up with a quick and hacky solution in brown_shoes of trying > to give each element (or widget) an id. Then in my specs, being able to > access individual elements based off the object returned by the app call. > > According to Peter Fitzgibbons, I've got a lot to learn about mocking, but > until that happens, I've got a working spec solution now :) > > > On Mon, Oct 18, 2010 at 3:02 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > >> On Sun, 2010-10-17 at 20:16 -0700, Devyn Cairns wrote: >> >> > I'm curious as to how you're going to write user interaction specs >> > (checking if things display properly, simulating clicks, keys, etc.) >> >> Devyn, you are such a pessimist ;^) >> >> It must be time for a cranky Cecil rant. >> >> Using deep introspection meta programming into the C/C++ code, set up >> baseline set of screenshots and train a series of neural networks to >> recognize the widgets on each platform and the text and state of them >> and their spacial relationship along with background color and font >> style attributes. Then compare all the would be new Shoes contenders >> (similarly instrumented with snapshots of course) Dudes, It's Simples! >> >> Joking aside, Something like the old AppleScript could be re-invented >> 'send keydown to widget1 of window 2' Preceded and followed by commands >> to sample the gui state, 'Ask position of Widget 1 of Window 2. That >> only worked if the app was written to allow that level of introspection >> by an outside process. It's probably easier in Cocoa than back in the >> early days of AppleScript. There's probably a Microsoft 'Innovation' >> somewhere. I think there is a Gnome/python facility for scripting GUI's >> like Applescript does. There's probably a Ruby gem to do the same on >> Linux. Just unify them. Simples. >> >> Writing, verifying and maintaining those tests would be harder than >> writing the code it's testing. Still, it could happen. Shoes could be >> rewritten in Adobe Air or Python or JavaScript or Visual Basic quicker >> than a GUI test suite. IMO. >> >> God bless the dreamers, there can be no progress without them. Dreamers >> on a small project like Shoes also have to walk the talk. Ie: write the >> code they want, like the gtk/qt/java/ folks are working on. >> >> Fluffy visions, good intentions and politically correct talking points >> won't make a code base appear out of the misty abyss. If White shoes >> provides a useful spec or test suite or can generate the source code for >> red/green/blue/black/brown Shoes on demand, then developers will adopt >> it. >> >> Meanwhile, my 30 day old pull request into Red Shoes has not been >> accepted, rejected or modified, nor is there any talk of a 3.1 bug >> release or fixing the OSX/MSW packaging mess. I know when to stop >> resuscitating a dead horse. To mis-quote Scotty of Star Trek, "It's dead >> Jim. Your red Shoes are dead". >> >> I'm not blaming anyone or pointing fingers at anyone. We did our best >> and we weren't up to the task. We were lacking in ability to keep Red >> Shoes alive. There's no shame in admitting to our failures and >> weaknesses. Shameful is pretending Red Shoes is ever going to be fixed. >> >> [Rant off] >> >> > >> > On Sun, Oct 17, 2010 at 3:13 PM, Steve Klabnik >> > <steve@steveklabnik.com> wrote: >> > >> http://blog.shoesrb.com/post/1306003281/a-rainbow-of-shoes-white-shoes >> > >> > >> > >> > -- >> > ~devyn >> > >> >> >> >
> Shoes could be > rewritten in Adobe Air or Python or JavaScript or Visual Basic quicker > than a GUI test suite. IMO. Randomly, (since this is tangential to your true rant) this is one of the things I like about qtruby: http://techbase.kde.org/Development/Languages/Ruby#Testing_UI_Classes > Meanwhile, my 30 day old pull request into Red Shoes has not been > accepted, rejected or modified, nor is there any talk of a 3.1 bug > release or fixing the OSX/MSW packaging mess. FWIW, I just looked at your pull request yesterday. Blame for this falls squarely on my shoulders, so I'm not going to say "yeah real soon now." Same thing with the wiki. What I _will_ say is that last night I made a to-do list last night of all of the ducks I need to get in a row for the Hackety 1.0 release (which by the way, will be on Red Shoes), and both those things are on there. I've actually been emailing back and forth with the guy who makes libgosu about his packaging for OSX: http://code.google.com/p/gosu/wiki/RubyPackagingOnOsx There's still some issues with it, like his '10.6 only' bit, but he's basically doing exactly what we're doing with Shoes. We're going to see if between the good old Red Shoes codebase and what he's been working on, if we can't get some good documentation going on how to make stuff packaged up for OSX. So the horse isn't totally dead. I had a really unproductive weekend, I've been coughing so much it's hard to sleep. :/ Last night has been the best in a while, thank you NyQuil...
On Mon, 2010-10-18 at 07:46 -0400, Steve Klabnik wrote: > Randomly, (since this is tangential to your true rant) this is one of > the things I like about qtruby: > http://techbase.kde.org/Development/Languages/Ruby#Testing_UI_Classes I'm convinced that qtruby has serious promise. > > ... I've actually been > emailing back and forth with the guy who makes libgosu about his > packaging for OSX: > http://code.google.com/p/gosu/wiki/RubyPackagingOnOsx Very interesting. They do Windows too. Differently, but there are lessons to be learned in that project. > > There's still some issues with it, like his '10.6 only' bit, but he's > basically doing exactly what we're doing with Shoes. We're going to > see if between the good old Red Shoes codebase and what he's been > working on, if we can't get some good documentation going on how to > make stuff packaged up for OSX. So the horse isn't totally dead. I had > a really unproductive weekend, I've been coughing so much it's hard to > sleep. :/ Last night has been the best in a while, thank you NyQuil... So Red Shoes is off life support but not out of the ER yet. Good to know.
On Mon, Oct 18, 2010 at 10:04 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Mon, 2010-10-18 at 07:46 -0400, Steve Klabnik wrote: > > Randomly, (since this is tangential to your true rant) this is one of > > the things I like about qtruby: > > http://techbase.kde.org/Development/Languages/Ruby#Testing_UI_Classes > > I'm convinced that qtruby has serious promise. > > > > ... I've actually been > > emailing back and forth with the guy who makes libgosu about his > > packaging for OSX: > > http://code.google.com/p/gosu/wiki/RubyPackagingOnOsx > > Very interesting. They do Windows too. Differently, but there are > lessons to be learned in that project. > This is pretty much what Red Shoes did, except automated. The way it was done though… it just fell apart. I think an automated process would be good. It could be in the form of a White Shoes compliant app separate from Shoes itself. > > > > There's still some issues with it, like his '10.6 only' bit, but he's > > basically doing exactly what we're doing with Shoes. We're going to > > see if between the good old Red Shoes codebase and what he's been > > working on, if we can't get some good documentation going on how to > > make stuff packaged up for OSX. So the horse isn't totally dead. I had > > a really unproductive weekend, I've been coughing so much it's hard to > > sleep. :/ Last night has been the best in a while, thank you NyQuil... > > So Red Shoes is off life support but not out of the ER yet. Good to > know. > > > -- ~devyn
On Tue, 2010-10-19 at 15:22 -0700, Devyn Cairns wrote: > > This is pretty much what Red Shoes did, except automated. The way it > was done though… it just fell apart. > > > I think an automated process would be good. It could be in the form of > a White Shoes compliant app separate from Shoes itself. > It's easy to get into a circular loop trying to separate the packaging code from Red Shoes and make a separate app out of it. Remember that a Shoes user who wants to package a script may not have Ruby installed or any development tools at all. They have to use the Ruby+gems in the Shoes package they are running. So the separate packager.app has to contain Shoes for the Gui+Ruby+gems which is what we have already - a Shoes.app that runs scripts and can package scripts into Shoes.app, the packager.app has more functionality than Shoes.app so why separate? If the user that wishes to package a script has to install a Ruby development environment first then packaging and Shoes can be separated into two apps. In that case you might as well them to tar or zip up the script in a terminal command and not write the packager. The self contained nature of RedShoes.app is both a brilliant sandbox and a developer constraint that developers don't always understand -- for example all the binary Gem confusion is because of the sandbox that is Shoes.
On Tue, Oct 19, 2010 at 6:15 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Tue, 2010-10-19 at 15:22 -0700, Devyn Cairns wrote: > > > > > This is pretty much what Red Shoes did, except automated. The way it > > was done though… it just fell apart. > > > > > > I think an automated process would be good. It could be in the form of > > a White Shoes compliant app separate from Shoes itself. > > > It's easy to get into a circular loop trying to separate the packaging > code from Red Shoes and make a separate app out of it. Remember that a > Shoes user who wants to package a script may not have Ruby installed or > any development tools at all. They have to use the Ruby+gems in the > Shoes package they are running. So the separate packager.app has to > contain Shoes for the Gui+Ruby+gems which is what we have already - a > Shoes.app that runs scripts and can package scripts into Shoes.app, the > packager.app has more functionality than Shoes.app so why separate? > Packaging has nothing to do with Shoes itself—it's something you can do *with* a Shoes app, as I see it. > > If the user that wishes to package a script has to install a Ruby > development environment first then packaging and Shoes can be separated > into two apps. In that case you might as well them to tar or zip up the > script in a terminal command and not write the packager. > With the direction we're headed in, Shoes would almost certainly be a gem this time. _why's reasons for not making Red Shoes a gem were good—but I think we can do a gem this time, and perhaps have an ‘easy install’ packaged version which comes with Ruby and all of the dependencies that just installs like a normal application and has file associations and whatnot. > > The self contained nature of RedShoes.app is both a brilliant sandbox > and a developer constraint that developers don't always understand -- > for example all the binary Gem confusion is because of the sandbox that > is Shoes. > I completely understand Red Shoes' self-containedness. However, I think the modular approach is the way to go (what we're doing now). -- ~devyn
On Tue, 2010-10-19 at 21:45 -0700, Devyn Cairns wrote: > > With the direction we're headed in, Shoes would almost certainly be a > gem this time. _why's reasons for not making Red Shoes a gem were good > —but I think we can do a gem this time, and perhaps have an ‘easy > install’ packaged version which comes with Ruby and all of the > dependencies that just installs like a normal application and has file > associations and whatnot. Shoes.app and installer.app vs Shoes with installer functionality.app If you are going write both, why not write just the one?
The installer is implemented in Shoes—it is a Shoes script. It really wouldn't help at all to make it part of Shoes; it would just make Shoes more monolithic without good reason. It wouldn't be easier for the user, nor would it be easier for the developer. I have nothing against distributing the packager script *with* Shoes, though. I just think that, in terms of modularity, the packager is a separate module. On Tue, Oct 19, 2010 at 10:24 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Tue, 2010-10-19 at 21:45 -0700, Devyn Cairns wrote: > > > > > With the direction we're headed in, Shoes would almost certainly be a > > gem this time. _why's reasons for not making Red Shoes a gem were good > > —but I think we can do a gem this time, and perhaps have an ‘easy > > install’ packaged version which comes with Ruby and all of the > > dependencies that just installs like a normal application and has file > > associations and whatnot. > > Shoes.app and installer.app vs Shoes with installer functionality.app > > If you are going write both, why not write just the one? > > > -- ~devyn
On Tue, 2010-10-19 at 22:54 -0700, Devyn Cairns wrote: > The installer is implemented in Shoes—it is a Shoes script. Sorry, It requires C/C++ binaries to work, just like SQLite3. Maybe that is easier to understand. If a future Multi-Colored gem based Shoes script 'requires sqlite3' where is that going to be located? Compiled? Installed? > It really wouldn't help at all to make it part of Shoes; it would just > make Shoes more monolithic without good reason. Ahh, it's already monolithic in Red Shoes. That bridge is behind us. There is no technical difference between the Sqlite binary gem and the packager binaries. Will the new Shoes require compiling Sqlite3 by hand in a terminal? I'm not opposed to the gem/blue/green/brown efforts to cut Shoes down into its popular core (a Gui DSL) and rebuild it from that since everybody seems to be afraid of the platform C monsters. But, Shoes as we know it, includes that other stuff (packaging, sqlite, bloopsaphone, chipmonk and god help us, VLC. Not to mention Shoes specific gem handling) Ditch those from the Shoes definition and Shoes isn't an app for easy peasy. It just would be a DSL for for ruby mandarins. > It wouldn't be easier for the user, nor would it be easier for the > developer. I have nothing against distributing the packager script > *with* Shoes, though. I just think that, in terms of modularity, the > packager is a separate module. > > On Tue, Oct 19, 2010 at 10:24 PM, Cecil Coupe <ccoupe@cableone.net> > wrote: > On Tue, 2010-10-19 at 21:45 -0700, Devyn Cairns wrote: > > > > > With the direction we're headed in, Shoes would almost > certainly be a > > gem this time. _why's reasons for not making Red Shoes a gem > were good > > —but I think we can do a gem this time, and perhaps have an > ‘easy > > install’ packaged version which comes with Ruby and all of > the > > dependencies that just installs like a normal application > and has file > > associations and whatnot. > > > Shoes.app and installer.app vs Shoes with installer > functionality.app > > If you are going write both, why not write just the one? > > > > > > -- > ~devyn
On Tue, Oct 19, 2010 at 11:47 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Tue, 2010-10-19 at 22:54 -0700, Devyn Cairns wrote: > > The installer is implemented in Shoes—it is a Shoes script. > > Sorry, It requires C/C++ binaries to work, just like SQLite3. Maybe > that is easier to understand. If a future Multi-Colored gem based Shoes > script 'requires sqlite3' where is that going to be located? Compiled? > Installed? > I meant the packager, sorry—and why does the packager have to require C/C++ binaries? We're not necessarily using Binject. Dependencies will be installed through system RubyGems. > > > It really wouldn't help at all to make it part of Shoes; it would just > > make Shoes more monolithic without good reason. > > Ahh, it's already monolithic in Red Shoes. That bridge is behind us. > There is no technical difference between the Sqlite binary gem and the > packager binaries. Will the new Shoes require compiling Sqlite3 by hand > in a terminal? > No, it will just be another gem, and dependencies will be installed as gems as well. The self-contained version would work a little differently—it would be a Ruby environment with RubyGems and the Shoes gem + dependencies pre-installed. > > I'm not opposed to the gem/blue/green/brown efforts to cut Shoes down > into its popular core (a Gui DSL) and rebuild it from that since > everybody seems to be afraid of the platform C monsters. But, Shoes as > we know it, includes that other stuff (packaging, sqlite, bloopsaphone, > chipmonk and god help us, VLC. We want to split that all up into multiple gems (separate from Shoes) that other people could use without Shoes. Again, they'd be installed as gems like any other. > Not to mention Shoes specific gem > handling) Ditch those from the Shoes definition and Shoes isn't an app > for easy peasy. It just would be a DSL for for ruby mandarins. > Shoes is no longer the container. It is a gem like any other. As I understand it, the way we're going to make it easy is to provide a pre-prepared easily-installable self-contained Ruby environment package. Decisions like automatic installation of gems will be made later. We will probably still use Shoes.setup in some form—it just won't be quite the same thing. > > > It wouldn't be easier for the user, nor would it be easier for the > > developer. I have nothing against distributing the packager script > > *with* Shoes, though. I just think that, in terms of modularity, the > > packager is a separate module. > > > > On Tue, Oct 19, 2010 at 10:24 PM, Cecil Coupe <ccoupe@cableone.net> > > wrote: > > On Tue, 2010-10-19 at 21:45 -0700, Devyn Cairns wrote: > > > > > > > > With the direction we're headed in, Shoes would almost > > certainly be a > > > gem this time. _why's reasons for not making Red Shoes a gem > > were good > > > —but I think we can do a gem this time, and perhaps have an > > ‘easy > > > install’ packaged version which comes with Ruby and all of > > the > > > dependencies that just installs like a normal application > > and has file > > > associations and whatnot. > > > > > > Shoes.app and installer.app vs Shoes with installer > > functionality.app > > > > If you are going write both, why not write just the one? > > > > > > > > > > > > -- > > ~devyn > > > -- ~devyn
On Wed, 2010-10-20 at 09:53 -0700, Devyn Cairns wrote: > > > On Tue, Oct 19, 2010 at 11:47 PM, Cecil Coupe <ccoupe@cableone.net> > wrote: > On Tue, 2010-10-19 at 22:54 -0700, Devyn Cairns wrote: > > > > I meant the packager, sorry—and why does the packager have to require > C/C++ binaries? We're not necessarily using Binject. Binject is used because their is no pure Ruby way to build a dmg from Windows and Linux or to build the Windows container from OSX and Linux. > > > Dependencies will be installed through system RubyGems. So the Shoes user would have to install Ruby/gems/rake... first. > > > > It really wouldn't help at all to make it part of Shoes; it > would just > > make Shoes more monolithic without good reason. > > > Ahh, it's already monolithic in Red Shoes. That bridge is > behind us. > There is no technical difference between the Sqlite binary gem > and the > packager binaries. Will the new Shoes require compiling > Sqlite3 by hand > in a terminal? > > > No, it will just be another gem, and dependencies will be installed as > gems as well. The self-contained version would work a little > differently—it would be a Ruby environment with RubyGems and the Shoes > gem + dependencies pre-installed. Using something like binject.
On Wed, Oct 20, 2010 at 11:25 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Wed, 2010-10-20 at 09:53 -0700, Devyn Cairns wrote: > > > > > > On Tue, Oct 19, 2010 at 11:47 PM, Cecil Coupe <ccoupe@cableone.net> > > wrote: > > On Tue, 2010-10-19 at 22:54 -0700, Devyn Cairns wrote: > > > > > > > > > I meant the packager, sorry—and why does the packager have to require > > C/C++ binaries? We're not necessarily using Binject. > > Binject is used because their is no pure Ruby way to build a dmg from > Windows and Linux or to build the Windows container from OSX and Linux. > Of course there is… if it can be done in C[++], it can be done in Ruby. > > > > > > Dependencies will be installed through system RubyGems. > > So the Shoes user would have to install Ruby/gems/rake... first. > No—you misunderstood. The Shoes bundle (what most people install) would have a self-contained already set up Ruby environment. Or you can install Shoes as a gem. Either way is fine. > > > > > > > It really wouldn't help at all to make it part of Shoes; it > > would just > > > make Shoes more monolithic without good reason. > > > > > > Ahh, it's already monolithic in Red Shoes. That bridge is > > behind us. > > There is no technical difference between the Sqlite binary gem > > and the > > packager binaries. Will the new Shoes require compiling > > Sqlite3 by hand > > in a terminal? > > > > > > No, it will just be another gem, and dependencies will be installed as > > gems as well. The self-contained version would work a little > > differently—it would be a Ruby environment with RubyGems and the Shoes > > gem + dependencies pre-installed. > > Using something like binject. > I was thinking more along the lines of NSIS / makeself / DMG for an installer… for packaging, yes, we would use something similar to binject. -- ~devyn
On Wed, 2010-10-20 at 15:25 -0700, Devyn Cairns wrote: > > Binject is used because their is no pure Ruby way to build a > dmg from > Windows and Linux or to build the Windows container from OSX > and Linux. > > > Of course there is… if it can be done in C[++], it can be done in > Ruby. Not by a sane person ;^) There's some gnarly code in there for simulating HFS things. Take a look at it and work out how you'd do it in Ruby. While your at it, you could add some documentation on whats going on in there. Either way, C or Ruby, it's part of Shoes. Plan for it now in multicolor Shoes or retrofit them later.
On Wed, Oct 20, 2010 at 4:01 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Wed, 2010-10-20 at 15:25 -0700, Devyn Cairns wrote: > > > > > > Binject is used because their is no pure Ruby way to build a > > dmg from > > Windows and Linux or to build the Windows container from OSX > > and Linux. > > > > > > Of course there is… if it can be done in C[++], it can be done in > > Ruby. > Not by a sane person ;^) There's some gnarly code in there for > simulating HFS things. Take a look at it and work out how you'd do it in > Ruby. While your at it, you could add some documentation on whats going > on in there. > > Either way, C or Ruby, it's part of Shoes. Plan for it now in multicolor > Shoes or retrofit them later. > It doesn't have to be part of Shoes, though. I'd like to use a separate gem, myself. -- ~devyn
I forgot to mention, the binject C (and minitar.rb) has Shoes specific code, so it can't be packaged up as general purpose gem. It's Shoes only. It needs to be part of the Shoes installation.
Yeah, if we go with binject it would. I don't think we can go with binject, anyway, if it has Shoes specific code—Shoes no longer has any kind of C API. On the topic of gems, Shoes can maintain a repository of popular gems as binaries (perhaps with user-contributed builds?) — this is commonly done for Windows, on which a development environment is really difficult to set up. Linux is more likely to have a working compiler… well, except base Ubuntu, which for some reason *doesn't… *seriously, what's up with that? Mac OS X always contains a working compiler suite. All versions. Anyway, I don't think that's such a big issue. It was with the old Shoes, but we're going to do things *really* differently this time. It's our project now. We're doing what we want with it. :D On Thu, Oct 21, 2010 at 8:14 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > I forgot to mention, the binject C (and minitar.rb) has Shoes specific > code, so it can't be packaged up as general purpose gem. It's Shoes > only. It needs to be part of the Shoes installation. > > > > -- ~devyn
On Thu, 2010-10-21 at 22:01 -0700, Devyn Cairns wrote: > > Anyway, I don't think that's such a big issue. It was with the old > Shoes, but we're going to do things really differently this time. It's > our project now. We're doing what we want with it. :D Without a requirements doc or specs or tests or even a to-do list, lets run to future! Devyn, I'm confused, you've praised the _why and his vision and yet you throw him under the bus because C is just too hard for some of developers to handle. If you just move the goal posts one more time and wait, magic will happen. Meanwhile, in the other world, Apple finally gave up on their Java (it was always second class). No word yet if Oracle will step up. Not comforting news for cross platform Java developers like jruby and those who build upon jRuby. In a year, Apple OSX Lion will be here with the tablet UI of iOS. Swipe and pinch and so on. Only a conspiracy nut would think that Apple introduced new event that Java can't handle and won't or can't legally be duplicated in Oracle Java. Or a year or two later in QT and a year later in Shoes of any color but Red. > On Thu, Oct 21, 2010 at 8:14 PM, Cecil Coupe <ccoupe@cableone.net> > wrote: > I forgot to mention, the binject C (and minitar.rb) has Shoes > specific > code, so it can't be packaged up as general purpose gem. It's > Shoes > only. It needs to be part of the Shoes installation. > > > > > > > -- > ~devyn >
On Sat, Oct 23, 2010 at 1:14 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Thu, 2010-10-21 at 22:01 -0700, Devyn Cairns wrote: > > > > Anyway, I don't think that's such a big issue. It was with the old > > Shoes, but we're going to do things really differently this time. It's > > our project now. We're doing what we want with it. :D > > Without a requirements doc or specs or tests or even a to-do list, lets > run to future! Devyn, I'm confused, you've praised the _why and his > vision and yet you throw him under the bus because C is just too hard > for some of developers to handle. This is precisely it. White Shoes is all about platform independence. A C/Ruby implementation is still perfectly possible with White Shoes. It's just that Red Shoes was so broken that we now want to modularize it. White Shoes will be a collection of specs à la RubySpec that Shoes implementations will aim to pass. > If you just move the goal posts one > more time and wait, magic will happen. > > Meanwhile, in the other world, Apple finally gave up on their Java (it > was always second class). No word yet if Oracle will step up. Not > comforting news for cross platform Java developers like jruby and those > who build upon jRuby. > In a year, Apple OSX Lion will be here with the tablet UI of iOS. Swipe > and pinch and so on. Only a conspiracy nut would think that Apple > introduced new event that Java can't handle and won't or can't legally > be duplicated in Oracle Java. Or a year or two later in QT and a year > later in Shoes of any color but Red. > I doubt very much that OS X Lion is going to be like iOS. They'd wait until OS 11 to do that. ;-) But again, with White Shoes, we are not forcing Java/GTK+/Qt and certainly not deciding on just one of them. We are modularizing Shoes. We are forking it. Our end result will be several implementations, not one, but which all pass White Shoes. A Cocoa Shoes implementation, for example, would be fine. Anyone is free to make whatever color of Shoes they want. As Satoshi put it, “Let's enjoy colorful Shoes!” > > > On Thu, Oct 21, 2010 at 8:14 PM, Cecil Coupe <ccoupe@cableone.net> > > wrote: > > I forgot to mention, the binject C (and minitar.rb) has Shoes > > specific > > code, so it can't be packaged up as general purpose gem. It's > > Shoes > > only. It needs to be part of the Shoes installation. > > > > > > > > > > > > > > -- > > ~devyn > > > > > -- ~devyn
I understand. Meta-Shoes. One Uber Shoes project to gather the unruly Shoes under a White cloak of specifications and tests. Dream higher! You could generate the code base of red/blue/green as required. The Stage2 macro processor might be just what you are looking for. Kind of Prolog and functional and macro texty. The ancient texts suggest a Fortran bootstrap of it's VM but you do it in Ruby in a half days effort. On Sat, 2010-10-23 at 12:14 -0700, Devyn Cairns wrote: > > > On Sat, Oct 23, 2010 at 1:14 AM, Cecil Coupe <ccoupe@cableone.net> > wrote: > On Thu, 2010-10-21 at 22:01 -0700, Devyn Cairns wrote: > > > > Anyway, I don't think that's such a big issue. It was with > the old > > Shoes, but we're going to do things really differently this > time. It's > > our project now. We're doing what we want with it. :D > > > Without a requirements doc or specs or tests or even a to-do > list, lets > run to future! Devyn, I'm confused, you've praised the _why > and his > vision and yet you throw him under the bus because C is just > too hard > for some of developers to handle. > > > This is precisely it. White Shoes is all about platform independence. > A C/Ruby implementation is still perfectly possible with White Shoes. > It's just that Red Shoes was so broken that we now want to modularize > it. White Shoes will be a collection of specs à la RubySpec that Shoes > implementations will aim to pass. > > If you just move the goal posts one > more time and wait, magic will happen. > > Meanwhile, in the other world, Apple finally gave up on their > Java (it > was always second class). No word yet if Oracle will step up. > Not > comforting news for cross platform Java developers like jruby > and those > who build upon jRuby. > > In a year, Apple OSX Lion will be here with the tablet UI of > iOS. Swipe > and pinch and so on. Only a conspiracy nut would think that > Apple > introduced new event that Java can't handle and won't or can't > legally > be duplicated in Oracle Java. Or a year or two later in QT and > a year > later in Shoes of any color but Red. > > > I doubt very much that OS X Lion is going to be like iOS. They'd wait > until OS 11 to do that. ;-) > But again, with White Shoes, we are not forcing Java/GTK+/Qt and > certainly not deciding on just one of them. > We are modularizing Shoes. We are forking it. Our end result will be > several implementations, not one, but which all pass White Shoes. > A Cocoa Shoes implementation, for example, would be fine. Anyone is > free to make whatever color of Shoes they want. > > > As Satoshi put it, “Let's enjoy colorful Shoes!” > > > > > On Thu, Oct 21, 2010 at 8:14 PM, Cecil Coupe > <ccoupe@cableone.net> > > wrote: > > I forgot to mention, the binject C (and minitar.rb) > has Shoes > > specific > > code, so it can't be packaged up as general purpose > gem. It's > > Shoes > > only. It needs to be part of the Shoes installation. > > > > > > > > > > > > > > -- > > ~devyn > > > > > > > > > -- > ~devyn
On Sun, Oct 24, 2010 at 12:08 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > I understand. Meta-Shoes. One Uber Shoes project to gather the unruly > Shoes under a White cloak of specifications and tests. Dream higher! You > could generate the code base of red/blue/green as required. I very much doubt this is easily possible. Even if it is, you would be writing separate generators for each, which would require even more code. There are large differences in implementation between each of the colors of Shoes. Think of White Shoes as the interface (with automatic checking), and each color as an implementation. That's pretty much it. How each color does things is up to it, so long as it passes White Shoes. > The Stage2 > macro processor might be just what you are looking for. Kind of Prolog > and functional and macro texty. The ancient texts suggest a Fortran > bootstrap of it's VM but you do it in Ruby in a half days effort. > You're joking, right? > > On Sat, 2010-10-23 at 12:14 -0700, Devyn Cairns wrote: > > > > > > On Sat, Oct 23, 2010 at 1:14 AM, Cecil Coupe <ccoupe@cableone.net> > > wrote: > > On Thu, 2010-10-21 at 22:01 -0700, Devyn Cairns wrote: > > > > > > Anyway, I don't think that's such a big issue. It was with > > the old > > > Shoes, but we're going to do things really differently this > > time. It's > > > our project now. We're doing what we want with it. :D > > > > > > Without a requirements doc or specs or tests or even a to-do > > list, lets > > run to future! Devyn, I'm confused, you've praised the _why > > and his > > vision and yet you throw him under the bus because C is just > > too hard > > for some of developers to handle. > > > > > > This is precisely it. White Shoes is all about platform independence. > > A C/Ruby implementation is still perfectly possible with White Shoes. > > It's just that Red Shoes was so broken that we now want to modularize > > it. White Shoes will be a collection of specs à la RubySpec that Shoes > > implementations will aim to pass. > > > > If you just move the goal posts one > > more time and wait, magic will happen. > > > > Meanwhile, in the other world, Apple finally gave up on their > > Java (it > > was always second class). No word yet if Oracle will step up. > > Not > > comforting news for cross platform Java developers like jruby > > and those > > who build upon jRuby. > > > > In a year, Apple OSX Lion will be here with the tablet UI of > > iOS. Swipe > > and pinch and so on. Only a conspiracy nut would think that > > Apple > > introduced new event that Java can't handle and won't or can't > > legally > > be duplicated in Oracle Java. Or a year or two later in QT and > > a year > > later in Shoes of any color but Red. > > > > > > I doubt very much that OS X Lion is going to be like iOS. They'd wait > > until OS 11 to do that. ;-) > > But again, with White Shoes, we are not forcing Java/GTK+/Qt and > > certainly not deciding on just one of them. > > We are modularizing Shoes. We are forking it. Our end result will be > > several implementations, not one, but which all pass White Shoes. > > A Cocoa Shoes implementation, for example, would be fine. Anyone is > > free to make whatever color of Shoes they want. > > > > > > As Satoshi put it, “Let's enjoy colorful Shoes!” > > > > > > > > > On Thu, Oct 21, 2010 at 8:14 PM, Cecil Coupe > > <ccoupe@cableone.net> > > > wrote: > > > I forgot to mention, the binject C (and minitar.rb) > > has Shoes > > > specific > > > code, so it can't be packaged up as general purpose > > gem. It's > > > Shoes > > > only. It needs to be part of the Shoes installation. > > > > > > > > > > > > > > > > > > > > > -- > > > ~devyn > > > > > > > > > > > > > > > > > -- > > ~devyn > > > -- ~devyn
On Sun, 2010-10-24 at 01:39 -0700, Devyn Cairns wrote: > > > On Sun, Oct 24, 2010 at 12:08 AM, Cecil Coupe <ccoupe@cableone.net> > wrote: > I understand. Meta-Shoes. One Uber Shoes project to gather the > unruly > Shoes under a White cloak of specifications and tests. Dream > higher! You > could generate the code base of red/blue/green as required. > > > I very much doubt this is easily possible. Even if it is, you would be > writing separate generators for each, which would require even more > code. > > > There are large differences in implementation between each of the > colors of Shoes. Think of White Shoes as the interface (with automatic > checking), and each color as an implementation. That's pretty much it. > How each color does things is up to it, so long as it passes White > Shoes. > > The Stage2 > macro processor might be just what you are looking for. Kind > of Prolog > and functional and macro texty. The ancient texts suggest a > Fortran > bootstrap of it's VM but you do it in Ruby in a half days > effort. > > > You're joking, right? Not as much joking as you suspect. If you write the specs properly, it's just boiler plate, creating widgets and connecting signals/events to handlers (layout is a just a form of internally generated event processing and parameter transformation). Sadly, most people think regexp is the ultimate in string processing and they forget or never learned what macro processors like Stage2 can do. Prolog really might be a way forward in writing specs that generate code. Or Tcl. or Stage2 and of course Lisp can do everything. Prolog querying a db of template patterns? Where the template is a logic expression? Then feed the result to a textual macro processor to get the syntax correct. > > > On Sat, 2010-10-23 at 12:14 -0700, Devyn Cairns wrote: > > > > > > On Sat, Oct 23, 2010 at 1:14 AM, Cecil Coupe > <ccoupe@cableone.net> > > wrote: > > On Thu, 2010-10-21 at 22:01 -0700, Devyn Cairns > wrote: > > > > > > Anyway, I don't think that's such a big issue. It > was with > > the old > > > Shoes, but we're going to do things really > differently this > > time. It's > > > our project now. We're doing what we want with > it. :D > > > > > > Without a requirements doc or specs or tests or even > a to-do > > list, lets > > run to future! Devyn, I'm confused, you've praised > the _why > > and his > > vision and yet you throw him under the bus because C > is just > > too hard > > for some of developers to handle. > > > > > > This is precisely it. White Shoes is all about platform > independence. > > A C/Ruby implementation is still perfectly possible with > White Shoes. > > It's just that Red Shoes was so broken that we now want to > modularize > > it. White Shoes will be a collection of specs à la RubySpec > that Shoes > > implementations will aim to pass. > > > > If you just move the goal posts one > > more time and wait, magic will happen. > > > > Meanwhile, in the other world, Apple finally gave up > on their > > Java (it > > was always second class). No word yet if Oracle will > step up. > > Not > > comforting news for cross platform Java developers > like jruby > > and those > > who build upon jRuby. > > > > In a year, Apple OSX Lion will be here with the > tablet UI of > > iOS. Swipe > > and pinch and so on. Only a conspiracy nut would > think that > > Apple > > introduced new event that Java can't handle and > won't or can't > > legally > > be duplicated in Oracle Java. Or a year or two later > in QT and > > a year > > later in Shoes of any color but Red. > > > > > > I doubt very much that OS X Lion is going to be like iOS. > They'd wait > > until OS 11 to do that. ;-) > > But again, with White Shoes, we are not forcing Java/GTK+/Qt > and > > certainly not deciding on just one of them. > > We are modularizing Shoes. We are forking it. Our end result > will be > > several implementations, not one, but which all pass White > Shoes. > > A Cocoa Shoes implementation, for example, would be fine. > Anyone is > > free to make whatever color of Shoes they want. > > > > > > As Satoshi put it, “Let's enjoy colorful Shoes!” > > > > > > > > > On Thu, Oct 21, 2010 at 8:14 PM, Cecil Coupe > > <ccoupe@cableone.net> > > > wrote: > > > I forgot to mention, the binject C (and > minitar.rb) > > has Shoes > > > specific > > > code, so it can't be packaged up as > general purpose > > gem. It's > > > Shoes > > > only. It needs to be part of the Shoes > installation. > > > > > > > > > > > > > > > > > > > > > -- > > > ~devyn > > > > > > > > > > > > > > > > > -- > > ~devyn > > > > > > > -- > ~devyn
On Sun, Oct 24, 2010 at 5:14 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Sun, 2010-10-24 at 01:39 -0700, Devyn Cairns wrote: > > > > > > On Sun, Oct 24, 2010 at 12:08 AM, Cecil Coupe <ccoupe@cableone.net> > > wrote: > > > > You're joking, right? > Not as much joking as you suspect. If you write the specs properly, it's > just boiler plate, creating widgets and connecting signals/events to > handlers (layout is a just a form of internally generated event > processing and parameter transformation). Sadly, most people think > regexp is the ultimate in string processing and they forget or never > learned what macro processors like Stage2 can do. > > Prolog really might be a way forward in writing specs that generate > code. Or Tcl. or Stage2 and of course Lisp can do everything. Prolog > querying a db of template patterns? Where the template is a logic > expression? Then feed the result to a textual macro processor to get the > syntax correct. > > Go for it Cecil! The rest of us will carry on keeping up with just one language, maybe 2, ok 3 then. (ruby, html, css, javascript). Hey that's 4! I personally don't have space for Meta-Language implementations. God help me just to grok meta-programming in ruby. :) Have a good day none the less! Peter Fitzgibbons (847) 859-9550 Email: peter.fitzgibbons@gmail.com IM GTalk: peter.fitzgibbons IM AOL: peter.fitzgibbons@gmail.com
On Sun, 2010-10-24 at 06:13 -0500, Peter Fitzgibbons wrote: > > Go for it Cecil! The rest of us will carry on keeping up with just > one language, maybe 2, ok 3 then. (ruby, html, css, javascript). Hey > that's 4! > I personally don't have space for Meta-Language implementations. God > help me just to grok meta-programming in ruby. I'm not going for it ;^) My point is to set the scope of a project's goals to something that is realistic for participants to accomplish or likely to make useful progress forwards before entropy overcomes best intentions. I'm still bleeding from the AI craze of the 90's so I know a little about software fads and paradigms. And the ultra strong typing movement and the ultra loose movement. What was the chip Intel was going to build that was intended to run Ada? > > > :) Have a good day none the less! > > > Peter Fitzgibbons > (847) 859-9550 > Email: peter.fitzgibbons@gmail.com > IM GTalk: peter.fitzgibbons > IM AOL: peter.fitzgibbons@gmail.com > > > >
> > > I'm still bleeding from the AI craze of the 90's so I know a little > about software fads and paradigms. And the ultra strong typing movement > and the ultra loose movement. What was the chip Intel was going to build > that was intended to run Ada? > > > Woah, Peter watch out for that dinosaur that's about to eat youuuuuuuu!! -- Zachary Scott
Nah, I tamed the Ada beast in my "Survey of Languages" class. Now, the COBOLosaurus... yes, that one would eat me. :) Peter Fitzgibbons (847) 859-9550 Email: peter.fitzgibbons@gmail.com IM GTalk: peter.fitzgibbons IM AOL: peter.fitzgibbons@gmail.com On Tue, Oct 26, 2010 at 9:16 AM, Zachary Scott <zachary.s.scott@gmail.com>wrote: > >> I'm still bleeding from the AI craze of the 90's so I know a little >> about software fads and paradigms. And the ultra strong typing movement >> and the ultra loose movement. What was the chip Intel was going to build >> that was intended to run Ada? >> > >> > > Woah, Peter watch out for that dinosaur that's about to eat youuuuuuuu!! > > -- > Zachary Scott > >
On Tue, Oct 26, 2010 at 7:18 AM, Peter Fitzgibbons < peter.fitzgibbons@gmail.com> wrote: > Nah, I tamed the Ada beast in my "Survey of Languages" class. > > Now, the COBOLosaurus... yes, that one would eat me. > :) > INTERCAL. > > > Peter Fitzgibbons > (847) 859-9550 > Email: peter.fitzgibbons@gmail.com > IM GTalk: peter.fitzgibbons > IM AOL: peter.fitzgibbons@gmail.com > > > On Tue, Oct 26, 2010 at 9:16 AM, Zachary Scott <zachary.s.scott@gmail.com>wrote: > >> >>> I'm still bleeding from the AI craze of the 90's so I know a little >>> about software fads and paradigms. And the ultra strong typing movement >>> and the ultra loose movement. What was the chip Intel was going to build >>> that was intended to run Ada? >>> > >>> >> >> Woah, Peter watch out for that dinosaur that's about to eat youuuuuuuu!! >> >> -- >> Zachary Scott >> >> > -- ~devyn
On Tue, 2010-10-26 at 18:56 -0700, Devyn Cairns wrote: > > > On Tue, Oct 26, 2010 at 7:18 AM, Peter Fitzgibbons > <peter.fitzgibbons@gmail.com> wrote: > Nah, I tamed the Ada beast in my "Survey of Languages" class. > > > Now, the COBOLosaurus... yes, that one would eat me. > :) > > > INTERCAL. I assume you mean http://en.wikipedia.org/wiki/INTERCAL A language and myth I had never heard of. Kind of reminds me of some python choices when they went OO. __self__ ? The COBOLosaurus is not a meat eater, Peter. It's a huge vegetarian that will stomp on you if you approach its home territory. Do not wave flags of Duck Typing at the beast or it will respond with massive OC4 core dumps. Only Visual Basic has been known able to coexist with the COBOLosaurus in its home territory. > > > > Peter Fitzgibbons > (847) 859-9550 > Email: peter.fitzgibbons@gmail.com > IM GTalk: peter.fitzgibbons > IM AOL: peter.fitzgibbons@gmail.com > > > > > On Tue, Oct 26, 2010 at 9:16 AM, Zachary Scott > <zachary.s.scott@gmail.com> wrote: > > I'm still bleeding from the AI craze of the > 90's so I know a little > about software fads and paradigms. And the > ultra strong typing movement > and the ultra loose movement. What was the > chip Intel was going to build > that was intended to run Ada? > > > > > > > Woah, Peter watch out for that dinosaur that's about > to eat youuuuuuuu!! > > > -- > Zachary Scott > > > > > > > -- > ~devyn
On Wed, Oct 27, 2010 at 12:00 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Tue, 2010-10-26 at 18:56 -0700, Devyn Cairns wrote: > > Only __Visual Basic__ has been known able to coexist with the > COBOLosaurus in its home territory. > Ahh, THATS why it seemed so familiar!! Yes, I rode the VisualBasicops for several years. Loving this thread! Peter Fitzgibbons (847) 859-9550 Email: peter.fitzgibbons@gmail.com IM GTalk: peter.fitzgibbons IM AOL: peter.fitzgibbons@gmail.com
could not decode message
On Wed, Oct 27, 2010 at 10:30 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > > I assume you mean http://en.wikipedia.org/wiki/INTERCAL A language and > myth I had never heard of. Kind of reminds me of some python choices > when they went OO. __self__ ? If nothing else, INTERCAL has entered the programming language hall of fame for its COME FROM statement :) martin
On Wed, 2010-10-27 at 10:54 +0530, Martin DeMello wrote: > > If nothing else, INTERCAL has entered the programming language hall of > fame for its COME FROM statement :) Sigh, we still haven't developed the 'WHEN NEEDED' statement. Oh wait, maybe we have that. I seem to remember writing some code in some language (Prolog?) that was essentially 'COME FROM'. That was about the time I stepped back from the edge.
On Wed, 2010-10-20 at 23:33 -0700, Devyn Cairns wrote: > Either way, C or Ruby, it's part of Shoes. Plan for it now in > multicolor > Shoes or retrofit them later. > > > It doesn't have to be part of Shoes, though. I'd like to use a > separate gem, myself. Even if it's a gem, it's a binary gem so it won't compile for casual Shoes scripters that don't have a development environment so you might as well distribute the binary code along with the rest of the shoes install. FYI, if you want to see a Ruby replacement for a simple C program, look at minitar.rb which has only one C struct to deal with. Then think about all the lovely HFS and Windows C struct's > > > > -- > ~devyn
I'd be interested if the bowline project could provide some more ideas for the project, maybe even develop a webkit shoes implementation at some point. http://github.com/maccman/bowline <http://github.com/maccman/bowline> On Wed, Oct 20, 2010 at 6:25 PM, Devyn Cairns <devyn.cairns@gmail.com>wrote: > > > On Wed, Oct 20, 2010 at 11:25 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > >> On Wed, 2010-10-20 at 09:53 -0700, Devyn Cairns wrote: >> > >> > >> > On Tue, Oct 19, 2010 at 11:47 PM, Cecil Coupe <ccoupe@cableone.net> >> > wrote: >> > On Tue, 2010-10-19 at 22:54 -0700, Devyn Cairns wrote: >> >> > >> > >> > >> > I meant the packager, sorry—and why does the packager have to require >> > C/C++ binaries? We're not necessarily using Binject. >> >> Binject is used because their is no pure Ruby way to build a dmg from >> Windows and Linux or to build the Windows container from OSX and Linux. >> > > Of course there is… if it can be done in C[++], it can be done in Ruby. > > >> > >> > >> > Dependencies will be installed through system RubyGems. >> >> So the Shoes user would have to install Ruby/gems/rake... first. >> > > No—you misunderstood. The Shoes bundle (what most people install) would > have a self-contained already set up Ruby environment. Or you can install > Shoes as a gem. Either way is fine. > > >> > >> > >> > > It really wouldn't help at all to make it part of Shoes; it >> > would just >> > > make Shoes more monolithic without good reason. >> > >> > >> > Ahh, it's already monolithic in Red Shoes. That bridge is >> > behind us. >> > There is no technical difference between the Sqlite binary gem >> > and the >> > packager binaries. Will the new Shoes require compiling >> > Sqlite3 by hand >> > in a terminal? >> > >> > >> > No, it will just be another gem, and dependencies will be installed as >> > gems as well. The self-contained version would work a little >> > differently—it would be a Ruby environment with RubyGems and the Shoes >> > gem + dependencies pre-installed. >> >> Using something like binject. >> > > I was thinking more along the lines of NSIS / makeself / DMG for an > installer… for packaging, yes, we would use something similar to binject. > > > > -- > ~devyn > -- Zachary Scott http://zacharyscott.net/ http://twitter.com/hasmanytweets
On Tue, Oct 19, 2010 at 10:54 PM, Devyn Cairns <devyn.cairns@gmail.com>wrote: > The installer Correction: packager. I shouldn't write emails when I'm sleepy. > is implemented in Shoes—it is a Shoes script. It really wouldn't help at > all to make it part of Shoes; it would just make Shoes more monolithic > without good reason. It wouldn't be easier for the user, nor would it be > easier for the developer. I have nothing against distributing the packager > script *with* Shoes, though. I just think that, in terms of modularity, the > packager is a separate module. > > > On Tue, Oct 19, 2010 at 10:24 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > >> On Tue, 2010-10-19 at 21:45 -0700, Devyn Cairns wrote: >> >> > >> > With the direction we're headed in, Shoes would almost certainly be a >> > gem this time. _why's reasons for not making Red Shoes a gem were good >> > —but I think we can do a gem this time, and perhaps have an ‘easy >> > install’ packaged version which comes with Ruby and all of the >> > dependencies that just installs like a normal application and has file >> > associations and whatnot. >> >> Shoes.app and installer.app vs Shoes with installer functionality.app >> >> If you are going write both, why not write just the one? >> >> >> > > > -- > ~devyn > -- ~devyn
Yep. I actually have started doing this, I just hadn't told anyone about it yet: http://github.com/steveklabnik/furoshiki I was going to post to the list in a few days, but I guess you beat me to it. ;)
On Tue, Oct 19, 2010 at 15:38, Steve Klabnik <steve@steveklabnik.com> wrote:
> http://github.com/steveklabnik/furoshiki
Can i suggest another, similar but kinder license,
http://danslalune.posterous.com/the-romantic-wtf-public-license
/shameless plug :-D
-- Pierre-Yves
haha! I've actually seen your license, and I like it, but the fact that it's kinder is actually a downside, as far as I'm concerned. I generally subscribe to this line of reasoning: http://www.loudthinking.com/posts/39-im-an-r-rated-individual Obviously, there are times where it's inappropriate, such as "Steve as leader of Hackety Hack." But for my own personal stuff...
Me too. There's gotta be a way to do it, something along the lines of selenium. This isn't exactly solved yet. On Oct 17, 2010 11:17 PM, "Devyn Cairns" <devyn.cairns@gmail.com> wrote: > Ah, okay. Perfect. > > I'm curious as to how you're going to write user interaction specs (checking > if things display properly, simulating clicks, keys, etc.) > > On Sun, Oct 17, 2010 at 3:13 PM, Steve Klabnik <steve@steveklabnik.com >wrote: > >> http://blog.shoesrb.com/post/1306003281/a-rainbow-of-shoes-white-shoes >> > > > > -- > ~devyn