Hey everyone! I think it's time to evaluate which gems belong in Red Shoes. Here's a summary: binject bloopsaphone chipmunk ftsearch hpricot json redcarpet2 sqlite3 What do you think about all of these? Here's my thoughts: binject - needed by the packager. Probably should be kept. :p bloopsaphone - Was used by hackety, hasn't been in a while. Isn't really maintained. I vote pull it out. chipmunk - Added by ash. Super fun. Last release was August, so pretty up-to-date. ftsearch - Only used by Shoes::Search. Does anyone use this at all? hpricot - Getting pulled in favor of Nokogiri. I'm starting this work soon. If you really think you can come up with a compelling reason, I'm all ears. json - Obviously needed, super useful. A bit old, from 2008! This should be brought current. redcarpet2 - Just added. This will be super useful for Hackety, and since Shoes internally uses crazy stuff to compile markdown for the manual, a good idea, methinks. sqlite3 - Same as json. Super useful, but old. Not too bad, but I'll bring it current. Thoughts, anyone? Are there other useful c extension gems we're missing? Can we remove bloops and ftsearch? -Steve
On Jan 3, 2012, at 4:20 PM, Steve Klabnik wrote:
> binject - needed by the packager. Probably should be kept. :p
Is binject only used for the "distribute app without a bundled Shoes"
option? If so, let's consider whether we are committed to that packaging
option. I don't think it works at this point, does it (can a packaged app
find the correct Shoes version at the URL it contains, download it, and
execute)?
Eric
To me packaging is one of the greatest things about shoes. Imo it's a big selling point and I know that documenting the packaging process has been on Steve's todo for some time. We should definitely try if it works and if not fix it. It'd be very sad to see it go :-( Tobi On 01/04/2012 03:07 PM, Eric Watson wrote: > On Jan 3, 2012, at 4:20 PM, Steve Klabnik wrote: > > > binject - needed by the packager. Probably should be kept. :p > > Is binject only used for the "distribute app without a bundled Shoes" option? If > so, let's consider whether we are committed to that packaging option. I don't > think it works at this point, does it (can a packaged app find the correct Shoes > version at the URL it contains, download it, and execute)? > > Eric >
Packaging is absolutely important. Eric is referring to the option to distribute a small file, and then have it download Shoes on someone else's computer.
Toby, I agree that we have to have packaging. But there are 2 kinds of packaging, and I think binject is only used for one of them. I could be wrong about that, though On Jan 4, 2012, at 8:34 AM, Tobias Pfeiffer <tobias.pfeiffer@student.hpi.uni-potsdam.de> wrote: > To me packaging is one of the greatest things about shoes. Imo it's a > big selling point and I know that documenting the packaging process has > been on Steve's todo for some time. We should definitely try if it works > and if not fix it. It'd be very sad to see it go :-( > > Tobi > > On 01/04/2012 03:07 PM, Eric Watson wrote: >> On Jan 3, 2012, at 4:20 PM, Steve Klabnik wrote: >> >>> binject - needed by the packager. Probably should be kept. :p >> >> Is binject only used for the "distribute app without a bundled Shoes" option? If >> so, let's consider whether we are committed to that packaging option. I don't >> think it works at this point, does it (can a packaged app find the correct Shoes >> version at the URL it contains, download it, and execute)? >> >> Eric >> >
Hi Eric and folks, > there are 2 kinds of packaging, and I think binject is only used > for one of them. Does "2 kinds of packaging" mean the .shy file and the .exe/run/dmg file? If so, you are right, binject is only used for making the .exe/run/dmg file. Shoes uses minitar for making the .shy file. binject is written in C. minitar is written in Ruby. If you don't have to include Shoes with your app, there is no need to use the .exe/run/dmg file. And IMHO, we don't have to include Shoes with our app. What do you think about it? ;-) ashbb
ashbb, > > there are 2 kinds of packaging, and I think binject is only used > > for one of them. > Does "2 kinds of packaging" mean the .shy file and the .exe/run/dmg file? > If so, you are right, binject is only used for making the .exe/run/dmg file. > > Shoes uses minitar for making the .shy file. binject is written in C. minitar is written in Ruby. > > If you don't have to include Shoes with your app, there is no need to use the .exe/run/dmg file. Oops! Looks like I had it backwards. I was thinking that binject was used only to inject Shoes into an app packaged as a .shy. After re-reading https://github.com/shoes/shoes/wiki/A-Developer's-Tour-Through-The-Magic-Packager, it seems like binject _is_ used for that purpose, but also for creating the .exe/run/dmg file. > And IMHO, we don't have to include Shoes with our app. That makes sense for Green Shoes, I think. How do you package Green Shoes apps? As .shy files that install ruby and Green Shoes? Can you also bundle ruby and Green Shoes with a Green Shoes app? What about Red Shoes apps? Does a .shy package even work currently? Can I package an app without Red Shoes and send it to you, so that when you open the app, it installs Red Shoes? I'd be interested to try that. Looking through the code a while back, I remember thinking, "This can't possibly work anymore" (but I didn't try it). I think we should preserve the option to package Shoes within an app, entirely self-contained. However, what I'd really like to see is the extracted packager serialhex and steveklabnik were discussing, that would work for any ruby app. I have also been toying with the idea of a packaging webservice for Shoes apps. Eric
As always, the devil is in the details. I've looked at moving the packager stuff into a gem but gave up when I realized how deeply embedded it is in Shoes. Even it you did that, you still have to fix the bugs so all you've done is add complexity. Remember, you can't install binary gems in Red Shoes, so how would a person access it from Shoes? I'm aware of several bugs: Creating a network install .exe has to be done on Windows box that has Mingw. The plists for .dmgs need to be updated to whatever OSX is doing now and the network download code (obj-c) needs testing and mods for Ruby 1.9.1 threading. On Thu, 2012-01-05 at 10:12 -0600, Eric Watson wrote: > ashbb, > > > > > there are 2 kinds of packaging, and I think binject is only used > > > for one of them. > > Does "2 kinds of packaging" mean the .shy file and the .exe/run/dmg > > file? > > If so, you are right, binject is only used for making > > the .exe/run/dmg file. > > > > Shoes uses minita r for making the .shy file. binject is written in > > C. minitar is written in Ruby. > > > > If you don't have to include Shoes with your app, there is no need > > to use the .exe/run/dmg file. > > > Oops! Looks like I had it backwards. I was thinking that binject was > used only to inject Shoes into an app packaged as a .shy. After > re-reading https://github.com/shoes/shoes/wiki/A-Developer's-Tour-Through-The-Magic-Packager, it seems like binject _is_ used for that purpose, but also for creating the .exe/run/dmg file. > > > > And IMHO, we don't have to include Shoes with our app. > > That makes sense for Green Shoes, I think. How do you package Green > Shoes apps? As .shy files that install ruby and Green Shoes? Can you > also bundle ruby and Green Shoes with a Green Shoes app? > > > What about Red Shoes apps? Does a .shy package even work currently? > Can I package an app without Red Shoes and send it to you, so that > when you open the app, it installs Red Shoes? I'd be interested to try > that. Looking through the code a while back, I remember thinking, > "This can't possibly work anymore" (but I didn't try it). > > > I think we should preserve the option to package Shoes within an app, > entirely self-contained. However, what I'd really like to see is the > extracted packager serialhex and steveklabnik were discussing, that > would work for any ruby app. I have also been toying with the idea of > a packaging webservice for Shoes apps. > > > Eric
> As always, the devil is in the details. I've looked at moving the > packager stuff into a gem but gave up when I realized how deeply > embedded it is in Shoes. Even it you did that, you still have to fix the > bugs so all you've done is add complexity. This is true. However, it seems to me that having all of that code so deeply embedded in Shoes is actually hurting Shoes, because nobody (myself included) is quite brave enough to touch it. As time passes, this gets worse. > Remember, you can't install > binary gems in Red Shoes, so how would a person access it from Shoes? Bring me up to speed on this point: why can't you install binary gems in Red Shoes? (I know that you can't, but I'm not sure what the problem is.) I'm working from the vision that shoes will act like a normal gem someday, and that this packager will be one of its dependencies, much like hpricot and friends are today. > I'm aware of several bugs: Creating a network install .exe has to be > done on Windows box that has Mingw. The plists for .dmgs need to be > updated to whatever OSX is doing now and the network download code > (obj-c) needs testing and mods for Ruby 1.9.1 threading. Thanks for listing these bugs. However we move forward, these have to be addressed. Eric
On Thu, 2012-01-05 at 15:32 -0600, Eric Watson wrote: > > > > > Remember, you can't install > > binary gems in Red Shoes, so how would a person access it from > > Shoes? > > Bring me up to speed on this point: why can't you ins tall binary gems > in Red Shoes? (I know that you can't, but I'm not sure what the > problem is.) > The issue is that 'normal' people don't have the compile tools installed. Certainly true for windows, osx? and some linux. > > I'm working from the vision that shoes will act like a normal gem > someday, and that this packager will be one of its dependencies, much > like hpricot and friends are today. We talked this over a few years ago. There is a circular dependency. The packager needs Shoes - a lot of the work is controlled by the lib/shoes/pack.rb which is also a Shoes GUI script. It all becomes clear when you look at the pack.rb code and the shock wears off. > > > I'm aware of several bugs: Creating a network install .exe has to be > > done on Windows box that has Mingw. The plists for .dmgs need to be > > updated to whatever OSX is doing now and the network download code > > (obj-c) needs testing and mods for Ruby 1.9.1 threading. > > > Thanks for listing these bugs. However we move forward, these have to > be addressed. > > > Eric
> It all becomes clear > when you look at the pack.rb code and the shock wears off. I'll have to take another look (and maybe the shock just hasn't worn off yet ;) )
>Bring me up to speed on this point: why can't you ins tall binary gems in
Red Shoes? (I know that you can't, but I'm not sure what the problem is.)
Think of the use case: some random person installs Hackety Hack. They
have no programming stuff whatsoever on their system.
How are they supposed to compile binary gems?
>> Bring me up to speed on this point: why can't you ins tall binary gems in Red Shoes? (I know that you can't, but I'm not sure what the problem is.) > > Think of the use case: some random person installs Hackety Hack. They > have no programming stuff whatsoever on their system. > > How are they supposed to compile binary gems? Reasonable concern--we definitely don't want to have a full build environment as a prerequisite for using Shoes. But here you are talking about being able to distribute a Shoes app without a packaged Shoes. Let's think about it another way: if I am a random person who installs Hackety Hack, and I write a Hackety Hack program that depends on a binary gem, how am I supposed to even write the app if I can't install binary gems on my system? Given that I have created an app that uses binary gems, then I must be able to compile them on my system. If I can compile them, why couldn't I package them? I think Jake did that recently with gStreamer. My understanding is that you _can_ install binary gems in Red Shoes, you just can't expect that users of your Shoes app will be able to. But this is all coming in the context of the "extract packager into a separate project" idea. To me, that project (and any binary components) would be packaged along with Shoes itself, and so shouldn't affect users without a build system. Am I missing the boat?
> Reasonable concern--we definitely don't want to have a full build environment as a prerequisite for using Shoes. But here you are talking about being able to distribute a Shoes app without a packaged Shoes. Ah. Yeah, I mean, a simple .shy should be fine for that. > My understanding is that you _can_ install binary gems in Red Shoes, you just can't expect that users of your Shoes app will be able to. Right. > But this is all coming in the context of the "extract packager into a separate project" idea. To me, that project (and any binary components) would be packaged along with Shoes itself, and so shouldn't affect users without a build system. Sure. That'd work, in theory. Like Cecil says, it's pretty damn complicated.
I'm starting a new thread from a older post. On Thu, 2012-01-05 at 17:25 -0500, Steve Klabnik wrote: > > Reasonable concern--we definitely don't want to have a full build > environment as a prerequisite for using Shoes. But here you are talking > about being able to distribute a Shoes app without a packaged Shoes. > > Ah. Yeah, I mean, a simple .shy should be fine for that. > > > My understanding is that you _can_ install binary gems in Red Shoes, > you just can't expect that users of your Shoes app will be able to. > > Right. I think the backdoor install of binary gems broke in policeman or a gem version change. You can install them from the shoes command line but they aren't found on a require. > > > But this is all coming in the context of the "extract packager into a > separate project" idea. To me, that project (and any binary components) > would be packaged along with Shoes itself, and so shouldn't affect > users without a build system. > > Sure. That'd work, in theory. Like Cecil says, it's pretty damn > complicated. First, binject would need to made into a gem which wouldn't be that hard at first glance since its mostly layed out like a gem and just missing the gem config files and somebody to maintain it. Somebody with Windows, OSX and C skills. Know anyone? Assume that binject is a gem. Now we need another gem 'packer' that is a Module that requires the binject gem. 'packer' would have skillz to manipulate binject according to some API so that Shoes pack.rb could just say Packer::Make_a_net_exe(outfile, script) and Packer::Make_big_exe and Packer::Make_bigass_vlc_exe along with the OSX versions and of course Packer::Make_Linux_net_download(outfile, script, [opts]) where opts is a hash :os_name, :version, :arch so it all works with Ubuntu 10.4, 10.10, 11.4, 11.10, Fedora, Arch..] * [ia32, x64, armel, mips]. Actually you could use the [opts] for OSX - 10.5, 10.6, 10.7 and so on. It's certainly possible. Anyone up for that challenge and willing to maintain that gem for a decade of new OS versions? Anyone? Bueller? Back in the real world. We can't get the Windows bugs with binject/pack.rb fixed. When that's done along with the OSX bugs/testing, then we might be able to contemplate how to build a linux .run or a bunch of them [os|version|arch]. I have an idea how that could work but it's not the right time until we actually have policeman doing what raisins used to do: Create exe & dmg net-install downloads from *any* platform for *any* platform. That worked long ago. Really, it did. ashbb and others don't believe that packaging an executable is an important feature of Red Shoes and his Green shoes won't have .exe, .dmg or .run versions any time soon. I respect his opinion and his contributions and I admire his work getting green shoes working and Peters attempts on Brown Shoes. I think the packaging system was as technically brilliant as the GUI. Others may disagree and do. I think they fail to see the brilliance inside. Or maybe they see x^y problem in the packager. It is there, in your face complexity. FWIW, Shoes Linux uses /usr/bin/makeself to build a .run and it's documented at http://megastep.org/makeself/ /usr/bin/makeself is a bash shell script so you can look at it and think about improving it. --Cecil
> I'm starting a new thread from a older post. Good idea :) Reading the title of the new thread, I wonder if I have been unclear. I was not proposing that we package Shoes apps as gems. I would like to maintain the way Red Shoes packages apps as executables (although I did float the idea of dropping the net install method). I would also like to preserve the way Red Shoes can package apps throught the GUI (although I don't think the packaging should be entangled with the GUI). > On Thu, 2012-01-05 at 17:25 -0500, Steve Klabnik wrote: >>> Reasonable concern--we definitely don't want to have a full build >> environment as a prerequisite for using Shoes. But here you are talking >> about being able to distribute a Shoes app without a packaged Shoes. >> >> Ah. Yeah, I mean, a simple .shy should be fine for that. >> >>> My understanding is that you _can_ install binary gems in Red Shoes, >> you just can't expect that users of your Shoes app will be able to. >> >> Right. > > I think the backdoor install of binary gems broke in policeman or a gem > version change. You can install them from the shoes command line but > they aren't found on a require. This seems to have blocked a few users from using Shoes for their projects recently. >> >>> But this is all coming in the context of the "extract packager into a >> separate project" idea. To me, that project (and any binary components) >> would be packaged along with Shoes itself, and so shouldn't affect >> users without a build system. >> >> Sure. That'd work, in theory. Like Cecil says, it's pretty damn >> complicated. > > First, binject would need to made into a gem which wouldn't be that hard > at first glance since its mostly layed out like a gem and just missing > the gem config files and somebody to maintain it. Somebody with Windows, > OSX and C skills. Know anyone? > > Assume that binject is a gem. Now we need another gem 'packer' that is a > Module that requires the binject gem. 'packer' would have skillz to > manipulate binject according to some API so that Shoes pack.rb could > just say Packer::Make_a_net_exe(outfile, script) and > Packer::Make_big_exe and Packer::Make_bigass_vlc_exe along with the OSX > versions and of course Packer::Make_Linux_net_download(outfile, script, > [opts]) where opts is a hash :os_name, :version, :arch so it all works > with Ubuntu 10.4, 10.10, 11.4, 11.10, Fedora, Arch..] * [ia32, x64, > armel, mips]. Actually you could use the [opts] for OSX - 10.5, 10.6, > 10.7 and so on. It's certainly possible. Anyone up for that challenge > and willing to maintain that gem for a decade of new OS versions? > Anyone? Bueller? I agree, a daunting task that requires special skills. But we have to do all of this anyway, don't we? Already, just to keep Shoes working, we have to support packaging in lots of formats. We need coders who can work on all the platforms. To me, this becomes simpler when the packaging is a separate task. The complexity is huge, but to me it is more complex when it is bound up inside Shoes. The packaging would be easier to understand and test if it were separate. I see lots of people getting excited about Shoes until they see the code, and then not having the time/perseverence/interest/courage to invest in getting to know the code. I think we could hook a lot more developers with a better architected code base. > Back in the real world. We can't get the Windows bugs with > binject/pack.rb fixed. When that's done I don't follow. Do you mean we can't move forward until Windows bugs are fixed? > along with the OSX bugs/testing, > then we might be able to contemplate how to build a linux .run or a > bunch of them [os|version|arch]. I have an idea how that could work but > it's not the right time until we actually have policeman doing what > raisins used to do: Create exe & dmg net-install downloads from *any* > platform for *any* platform. That worked long ago. Really, it did. I would love to see it working again. You are saying that you think it would be better to have everything working as it once did before thinking about extracting anything? That sounds wise to me. > ashbb and others don't believe that packaging an executable is an > important feature of Red Shoes and his Green shoes won't have .exe, .dmg > or .run versions any time soon. I respect his opinion and his > contributions and I admire his work getting green shoes working and > Peters attempts on Brown Shoes. I think the packaging system was as > technically brilliant as the GUI. Others may disagree and do. I think > they fail to see the brilliance inside. Or maybe they see x^y problem in > the packager. It is there, in your face complexity. I agree that the packaging is brilliant. I also think it's central to the idea of Shoes, that I can create a cool app and share it with my non-technical friends. The net install is also a great idea, because it allows me to email a tiny file to my friend whose inbox quota is 10mb, and downloads Shoes for her. As we produce more versions of Shoes, the complexity is going to explode here, too, though. Thanks for your insights. I feel like we're lumbering into motion... Eric
On Fri, 2012-01-06 at 08:57 -0600, Eric Watson wrote: > > > > I think the backdoor install of binary gems broke in policeman or a gem > > version change. You can install them from the shoes command line but > > they aren't found on a require. > > This seems to have blocked a few users from using Shoes for their projects recently. > When I say "I think" I usually mean I *think*. It might work for you. If it doesn't, its a low priority bug because the user would be better off not doing that (or using green Shoes). > >> > >>> But this is all coming in the context of the "extract packager into a > >> separate project" idea. To me, that project (and any binary components) > >> would be packaged along with Shoes itself, and so shouldn't affect > >> users without a build system. > >> > >> Sure. That'd work, in theory. Like Cecil says, it's pretty damn > >> complicated. > > > > [snip]... Anyone up for that challenge > > and willing to maintain that gem for a decade of new OS versions? > > Anyone? Bueller? > > I agree, a daunting task that requires special skills. But we have to do all of this anyway, don't we? Already, just to keep Shoes working, we have to support packaging in lots of formats. We need coders who can work on all the platforms. To me, this becomes simpler when the packaging is a separate task. The complexity is huge, but to me it is more complex when it is bound up inside Shoes. The packaging would be easier to understand and test if it were separate. I see lots of people getting excited about Shoes until they see the code, and then not having the time/perseverence/interest/courage to invest in getting to know the code. I think we could hook a lot more developers with a better architected code base. > Not really. Fixing bugs is a lot different than restructuring code that few understand to meet a undefined goal of unknown utility. > > Back in the real world. We can't get the Windows bugs with > > binject/pack.rb fixed. When that's done > > I don't follow. Do you mean we can't move forward until Windows bugs are fixed? Not really. Clearly we are moving on, windows bugs be damned. If I had an OSX box, I could test and attempt to fix the. I lack the knowledge of windows resources, their C level GUI API and my life is too short to spend some of it learning Windows. I'm of the opinion that if we can't test & fix the packaging bugs & options then we should remove all the options but .shy in the pack.rb screen. That *is not* the removal of Steve's packaging of hacketyhack (that's a rakefile task, pack.rb and binject are not involved with that).
Hi Cecil and folks, Thank you for starting the new thread. Let me post a question. ;-) When your friend wants to run your app, in Green Shoes for Windows, he/she will do the following three steps. 1) Install Ruby Download rubyinstaller-1.9.3-p0.exe from RubyInstaller.org and install (double-click the .exe file). 2) Install Green Shoes Open console window and run a command: gem install green_shoes 3) Run your app Download your_app.gsy from your website and double-click the .gsy file. That's it. Your friend can play your app. QUESTION: Can your friend try to do the above three steps? This is an example of Green Shoes. But I think it's possible to do the same for Red Shoes. I'd like to see your opinions. ;-) ashbb
Hi ashbb, What are the steps for an 'normal' OSX user to run the .gsy they downloaded? I'm guessing it would take about 8 man-hours if they don't make a mistake. Linux is slightly easier but it's still several steps more that your three. Or the user could download myscript.exe or myscript.dmg produced from Red Shoes and click a couple of buttons to install and run and never see the Windows or OSX console or even know a command line exists. Which would be easier for your Mother or Grandmother? On Fri, 2012-01-06 at 21:40 +0900, ashbb wrote: > Hi Cecil and folks, > > Thank you for starting the new thread. > > Let me post a question. ;-) > > When your friend wants to run your app, in Green Shoes for Windows, > he/she will do the following three steps. > > 1) Install Ruby > Download rubyinstaller-1.9.3-p0.exe from RubyInstaller.org and > install (double-click the .exe file). > > 2) Install Green Shoes > Open console window and run a command: gem install green_shoes > > 3) Run your app > Download your_app.gsy from your website and double-click the .gsy > file. > > That's it. Your friend can play your app. > > QUESTION: Can your friend try to do the above three steps? > > This is an example of Green Shoes. But I think it's possible to do the > same for Red Shoes. > > I'd like to see your opinions. ;-) > > ashbb
Hi Cecil, > What are the steps for an 'normal' OSX user to run the .gsy they > downloaded? I'm guessing it would take about 8 man-hours if they don't > make a mistake. Oh, my! I've never used OSX. So, I'm not sure about that. But that is really too bad... > Linux is slightly easier but it's still several steps more that your > three. Umm,... I've not confirmed on my ubuntu on virtualbox for Windows. But doesn't the following work well? $ gshoes my_app.gsy > Or the user could download myscript.exe or myscript.dmg produced from > Red Shoes and click a couple of buttons to install and run and never see > the Windows or OSX console or even know a command line exists. > > Which would be easier for your Mother or Grandmother? Oh,... hahaha. You are right! My mother and grandmother wouldn't download even a .exe file. All they know is just clicking a link on web-browser. So, I have a high expectation of HTML5 Back-End For GTK3. http://www.phoronix.com/scan.php?page=news_item&px=ODgzMA Someday in the future, ashbb
> > > Linux is slightly easier but it's still several steps more that > your > > three. > Umm,... > I've not confirmed on my ubuntu on virtualbox for Windows. > But doesn't the following work well? > > $ gshoes my_app.gsy > ccoupe@twb:~$ gem update greenshoes Updating installed gems Nothing to update ccoupe@twb:~$ ruby -v ruby 1.9.1p378 (2010-01-10 revision 26273) [x86_64-linux] ccoupe@twb:~$ rvm use 1.9.2 info: Using ruby 1.9.2 p0 ccoupe@twb:~$ gem update greenshoes Updating installed gems Nothing to update ccoupe@twb:~$ gem update green-shoes Updating installed gems Nothing to update ccoupe@twb:~$ gem update green_shoes Updating installed gems Updating green_shoes Building native extensions. This could take a while... ERROR: Error installing green_shoes: ERROR: Failed to build gem native extension. /home/ccoupe/.rvm/rubies/ruby-1.9.2-p0/bin/ruby extconf.rb checking for -Wall option to compiler... yes checking for -Waggregate-return option to compiler... yes checking for -Wcast-align option to compiler... yes checking for -Wextra option to compiler... yes checking for -Wformat=2 option to compiler... yes checking for -Winit-self option to compiler... yes checking for -Wlarger-than-65500 option to compiler... yes checking for -Wmissing-declarations option to compiler... yes checking for -Wmissing-format-attribute option to compiler... yes checking for -Wmissing-include-dirs option to compiler... yes checking for -Wmissing-noreturn option to compiler... yes checking for -Wmissing-prototypes option to compiler... yes checking for -Wnested-externs option to compiler... yes checking for -Wold-style-definition option to compiler... yes checking for -Wpacked option to compiler... yes checking for -Wp,-D_FORTIFY_SOURCE=2 option to compiler... yes checking for -Wpointer-arith option to compiler... yes checking for -Wswitch-default option to compiler... yes checking for -Wswitch-enum option to compiler... yes checking for -Wundef option to compiler... yes checking for -Wunsafe-loop-optimizations option to compiler... yes checking for -Wwrite-strings option to compiler... yes checking for rb_define_alloc_func() in ruby.h... yes checking for rb_block_proc() in ruby.h... yes checking for new allocation framework... yes checking for attribute assignment... no checking for Win32 OS... no checking for gobject-2.0... no *** extconf.rb failed *** Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options. Provided configuration options: --with-opt-dir --without-opt-dir --with-opt-include --without-opt-include=${opt-dir}/include --with-opt-lib --without-opt-lib=${opt-dir}/lib --with-make-prog --without-make-prog --srcdir=. --curdir --ruby=/home/ccoupe/.rvm/rubies/ruby-1.9.2-p0/bin/ruby --with-pkg-config --without-pkg-config --with-override-variables --without-override-variables Gem files will remain installed in /home/ccoupe/.rvm/gems/ruby-1.9.2-p0/gems/glib2-1.1.0 for inspection. Results logged to /home/ccoupe/.rvm/gems/ruby-1.9.2-p0/gems/glib2-1.1.0/ext/glib2/gem_make.out Gems updated: green_shoes Installing ri documentation for green_shoes-1.1.348... Installing RDoc documentation for green_shoes-1.1.348... ccoupe@twb:~$ Oh wait, I have to be sudo right? ccoupe@twb:~$ sudo gem update green_shoes [sudo] password for ccoupe: Updating installed gems Nothing to update ccoupe@twb:~$ I suspect I know have a problem with a half installed gem, Right?
On Sat, 2012-01-07 at 15:44 +0900, ashbb wrote: > Hi Cecil, > > > What are the steps for an 'normal' OSX user to run the .gsy they > > downloaded? I'm guessing it would take about 8 man-hours if they > don't > > make a mistake. > Oh, my! > I've never used OSX. So, I'm not sure about that. But that is really > too bad... > > > Linux is slightly easier but it's still several steps more that > your > > three. > Umm,... > I've not confirmed on my ubuntu on virtualbox for Windows. > But doesn't the following work well? > > $ gshoes my_app.gsy I don't have a gshoes at my command line and I do have the green shoes gem (maybe not latest). I've used to write a script or two with binary gems that Red Shoes couldn't handle. I also had to apt-get all the dependent libraries by hand > > > > Or the user could download myscript.exe or myscript.dmg produced > from > > Red Shoes and click a couple of buttons to install and run and never > see > > the Windows or OSX console or even know a command line exists. > > > > Which would be easier for your Mother or Grandmother? > Oh,... hahaha. You are right! > My mother and grandmother wouldn't download even a .exe file. > All they know is just clicking a link on web-browser. > So, I have a high expectation of HTML5 Back-End For GTK3. > > http://www.phoronix.com/scan.php?page=news_item&px=ODgzMA > > Someday in the future, > ashbb And that my friend is the difference we face. Red Shoes used to work with packaging exe and dmg. It didn't need preconditions and it didn't need fanciful future developments and future cloud goodness. Raisins worked (for packaging a script into an exe/dmg) and Policeman mostly doesn't work. Green/Brown Shoes probably won't bother to try or we could wait for Cloud Shoes to abstract all our bugs away and we do nothing will waiting for the future. I'm sorry for sounding so confrontational. I know it's not polite. The future of Red Shoes depends on those willing to fix it NOW, not later and not with with magic dreams of the future. We are the what the future will become. Except I won't learn Windows so it's up to you other future people to fix the Windows packager bugs so that Red Shoes becomes the future you all are waiting for. [insert smile or grouch icon here] I am aware of my split personality on this. Everyone wants to pick off a chunk of of Shoes they like and the future will take care of the parts they didn't want to deal with. It's not bad or good, it just is. Grouchy people would port Shoes to WxWindows where all the cool cross platform apps live and they can package complex c++, python, or ruby apps into binaries for all the platforms. Cross Trainer Shoes?!? That still wouldn't do what Red Shoes packager use to do in Raisins.
> The > future of Red Shoes depends on those willing to fix it NOW, not later All right, Cecil, you make a decent (if a little grouchy) argument ;). Let's work together to fix red shoes now. I was looking into the packager last night on OSX. Here's what I discovered 1. Making a .shy (for people who already have Shoes) works. Opening the .shy with Shoes.app works. Double clicking the .shy doesn't work. 2. The URLs for downloading Shoes for a net install are bad. The URLs, release naming, and release compatibility expectations need to be coordinated and documented. 3. I did not try placing a Shoes in the filesystem where the net install code looks for a cached copy. Not sure if that works or not. Sorry for no code links. On phone today I'll continue to explore. Eric
On Sat, 2012-01-07 at 11:11 -0600, Eric Watson wrote: > > The > > future of Red Shoes depends on those willing to fix it NOW, not later > > All right, Cecil, you make a decent (if a little grouchy) argument ;). What? My over the top rhetoric did not impress you? I must do better. ;-) > Let's work together to fix red shoes now. > > I was looking into the packager last night on OSX. Here's what I discovered > > 1. Making a .shy (for people who already have Shoes) works. Opening > the .shy with Shoes.app works. Double clicking the .shy doesn't work. In my vague memory, there used to be a way in OSX to associate extensions with apps or a right click on it to see the alternative apps that register for handling those files. It might be entry in the plist for the Shoes.app - thats where I'd look first (the plist documentation) > > 2. The URLs for downloading Shoes for a net install are bad. The URLs, > release naming, and release compatibility expectations need to be > coordinated and documented. Yeah they are confusing and testing is a head scratcher - how can you test a download version that doesn't exist because you're testing it? I once had a version of pack.rb that let you pick whether you want to pack a script for Raisins or Policeman. No one saw why I would want to do that so the feature vanished but it made sure made testing much easier.
>> 1. Making a .shy (for people who already have Shoes) works. Opening >> the .shy with Shoes.app works. Double clicking the .shy doesn't work. > > In my vague memory, there used to be a way in OSX to associate > extensions with apps or a right click on it to see the alternative apps > that register for handling those files. It might be entry in the plist > for the Shoes.app - thats where I'd look first (the plist documentation) I should be more specific. The .shy has a Shoes icon, and begins the "I'm launching an app" animation when you double-click it, but the launch doesn't succeed. No error logged.
Hi Cecil, > I don't have a gshoes at my command line and I do have the green shoes gem > (maybe not latest). > The gem is not the latest version of green_shoes, and does not include the gshoes command. Clone the latest version from the repo: https://github.com/ashbb/green_shoes (from ash...) - git clone git://github.com/ashbb/green_shoes.git - cd green_shoes - rake build - cd pkg - ls green_shoes-1.x.xxx.gem - gem uninstall green_shoes - gem install green_shoes-1.x.xxx.gem ...worked for me - ubuntu 10.04, ruby 1.9.3. - j
On Sun, 2012-01-08 at 06:45 +0100, J. Kaiden wrote: > Hi Cecil, > > I don't have a gshoes at my command line and I do have the > green shoes gem (maybe not latest). > > > The gem is not the latest version of green_shoes, and does not > include the gshoes command. It's an interesting bug in the green shoes gem update. For my rvm situation I don't need su to update my gems. It don't know what that error message means since the mkmf.log is the same as the console message I reported. Thats no help in fixing the problem, Sigh. I suspect it is a glibc version number change after I installed green shoes gem long agi and then months later upgraded to Ubuntu 11.04. My point being that Linux is a moving target and ashbb's 3 steps to running a shy or gsy on Windows are not my linux experience or a substitute for a Red Shoes packaged exe/dmg. Even more fun, after the gem update (and the reported error) I do have a gshoes command and $ gshoes -p does bring up the shy screen to to build a gsy. I have an isp.rb script in a directory dropouts/ that I wrote in Red Shoes to track how often my cable modem drops out. It's tied to Linux version of ping and its a very simple script GUI wise at www.mvmanila.com/public isp.rb and dropouts.gsy (2kB and 400kB if you want to try them out. Both .rb and .gsy work on my Green shoes gem even after what looks like a failed upgrade so thats good news. The gsy seems to believe 'pwd' is somewhere in /tmp/xxxx land instead of where I launched the gsy. Which is a bit of pain but Windows like (for better or worse). And because I'm such a negative nancy, I spent a few hours debugging this which is something casual users wont do from a Windows command line. On the other hand, Green Shoes does work So That's Good. I can always clone or update my version of the Green Shoes source if I wanted to but the point is, I shouldn't have to. It would be easier to build Red Shoes from source and even easier to double click an exe or dmg for a casual user. > > Clone the latest version from the repo: > https://github.com/ashbb/green_shoes > > > (from ash...) > - git clone git://github.com/ashbb/green_shoes.git > - cd green_shoes > - rake build > - cd pkg > - ls > green_shoes-1.x.xxx.gem > - gem uninstall green_shoes > - gem install green_shoes-1.x.xxx.gem > > > ...worked for me - ubuntu 10.04, ruby 1.9.3. > > > - j
hey all, Given that I have created an app that uses binary gems, then I must be able > to compile them on my system. If I can compile them, why couldn't I package > them? I think Jake did that recently with gStreamer. > > My understanding is that you _can_ install binary gems in Red Shoes, you > just can't expect that users of your Shoes app will be able to. > I think your understanding is dead on. I did manage to build a pair of Shoes with gstreamer (after a lengthy session on IRC with Steve,) and it's really not that big a deal - https://github.com/lljk/shoes-stuff/wiki/Shoes-and-Gems-with-Native-Dependencies - except yeah, it's kind of a big deal - you probably can't expect 'typical' users to go through this kind of hassle just to run your app - and packaging it hasn't quite worked out yet... For me the ideal situation would be to have the ability to package an app (in a gem?) with whatever Shoes you've rolled - though I know this is more than a little complicated... Although it's complicated, I think it's important enough to put some effort into - (wish I had the knowhow to help more) - writing an app that you can run on your system is neat, but if you can't distribute it, well.... you can't distribute it. very happy to see so much activity lately - - j
On Jan 5, 2012 6:54 AM, "ashbb" <ashbbb@gmail. [snip] > If you don't have to include Shoes with your app, there is no need to use the .exe/run/dmg file. > > And IMHO, we don't have to include Shoes with our app. > > What do you think about it? ;-) > > ashbb > I don't think it should be *required* as most ppl probably don't use it, tho - and I'm just speculating here - popping out the functionality to make an exe/run/dmg into its own gem or something, so one can (mostly) easily make an executabled if one wants it. I don't know how easy/hard something like that would be, but its an idea if we want to keep the functionality instead of trashing it altogether... ...how difficult wouldn something like that be? Steve? Ashbb? The two of you would know best. hex sent frm mah awsum andrid, txt mite berong sumtimze
> And IMHO, we don't have to include Shoes with our app. This is _incredibly_ important for Hackety Hack. > popping out the functionality to make an > exe/run/dmg into its own gem or something, so one can (mostly) easily make > an executabled if one wants it. I don't know how easy/hard something like > that would be, but its an idea if we want to keep the functionality instead > of trashing it altogether... I would love that idea. I even made a repo for it. But I haven't had the time to actually try to pull it out. I have no idea how hard it would be; I haven't examined the guts of the packager.
Hi Steve and folks, > chipmunk - Added by ash. Super fun. Last release was August, > so pretty up-to-date. Look at this site: https://github.com/beoran/chipmunk The latest chipmunk version is 5.3.4. It's necessary to compile with gcc 4.5.0 and over. When I tried to compile Red Shoes and chipmunk with gcc 4.5.0 on Windows 7, I couldn't. :( But that was over one year ago... As it is now, there is a binary gem for Windows on RubyGems.org. So, I think that there is no need to include the old chimunk. ashbb
In my office Json has been replaced by Yajl https://rubygems.org/gems/yajl-ruby Peter Fitzgibbons (847) 859-9550 Email: peter.fitzgibbons@gmail.com IM GTalk: peter.fitzgibbons IM AOL: peter.fitzgibbons@gmail.com
hey Steve, > Are there other useful c extension gems we're > missing? Shoes rocks - except for all the loud music... I'd love to see some kind of cross-platform audio library included with Shoes. From what I understand audio and video works for Windows, and with your help I managed to build my own pair of Shoes with GStreamer support on Linux - but it'd be awesome (and so only fitting) if Shoes could have cross-platform audio and video support out of the box. Shoes On, - j
J, The vlc embedding code is already in Shoes it just needs a C and Ruby API savy person to update it to Ruby 1.9.x, test it and maintain it. Which turns out to be big can of worms or more if VLC changes the API again. If someone could make a gem out of the VLC / Ruby bindings then it would be helpful for GreenShoes and RedShoes. So far, I haven't seen anyone step up to that task. But my google is weak. > From what I understand audio and video works for Windows, and with > your help I managed to build my own pair of Shoes with GStreamer > support on Linux - but it'd be awesome (and so only fitting) if Shoes > could have cross-platform audio and video support out of the box. > > > Shoes On, > > > - j >
Hi Cecil,
The vlc embedding code is already in Shoes ...
...If someone could make a gem out of the VLC / Ruby bindings then it would
> be helpful for GreenShoes and RedShoes
VLC seems like a good route. I've played around with vlcrc some (
http://rubygems.org/gems/vlcrc) - but it seems that I can only open and
operate VLC with it - not use it in the background. I could well be
mistaken though - I haven't fooled with it too much.
The only other gem for VLC that jumps out is libvlc, which appears to
have been yanked (http://rubygems.org/gems/libvlc) . I haven't tried this
one at all - I guess I will...
I'll keep looking and see if I can find something else.
rock on,
- j
I've been looking at the VLC wiki http://wiki.videolan.org/Win32Compile and they cross compile and build their Windows binaries on Linux! And package them on Linux. Whoa!!! There are serious lessons in there for Shoes maintainers on Linux (OSX?). Would the .exe run in Wine? If it did perhaps I could fix some Red Shoes packaging bugs or we could also borrow their packaging code since it is far more current than Red Shoes. Lessons indeed. Still doesn't fix the problem of someone needs to create a Ruby gem bindings for VLC and modifying Shoes to use that. The VLC is an elephant and I'm examining one leg. On Wed, 2012-01-04 at 05:36 +0100, J. Kaiden wrote: > Hi Cecil, > > The vlc embedding code is already in Shoes ... > ...If someone could make a gem out of the VLC / Ruby bindings > then it would > be helpful for GreenShoes and RedShoes > > > VLC seems like a good route. I've played around with vlcrc some > (http://rubygems.org/gems/vlcrc) - but it seems that I can only open > and operate VLC with it - not use it in the background. I could well > be mistaken though - I haven't fooled with it too much. > > > The only other gem for VLC that jumps out is libvlc, which appears > to have been yanked (http://rubygems.org/gems/libvlc) . I haven't > tried this one at all - I guess I will... > > > I'll keep looking and see if I can find something else. > > > rock on, > > > - j
I pretty much agree with your suggestions but I thought the Manual search function used ftsearch and I do search the manual. we could alway add the serialport gem that people stumble on ;^) On Tue, 2012-01-03 at 17:20 -0500, Steve Klabnik wrote: > Hey everyone! > > I think it's time to evaluate which gems belong in Red Shoes. Here's a summary: > > binject > bloopsaphone > chipmunk > ftsearch > hpricot > json > redcarpet2 > sqlite3 > > What do you think about all of these? Here's my thoughts: > > binject - needed by the packager. Probably should be kept. :p > bloopsaphone - Was used by hackety, hasn't been in a while. Isn't > really maintained. I vote pull it out. > chipmunk - Added by ash. Super fun. Last release was August, so pretty > up-to-date. > ftsearch - Only used by Shoes::Search. Does anyone use this at all? > hpricot - Getting pulled in favor of Nokogiri. I'm starting this work > soon. If you really think you can come up with a compelling reason, > I'm all ears. > json - Obviously needed, super useful. A bit old, from 2008! This > should be brought current. > redcarpet2 - Just added. This will be super useful for Hackety, and > since Shoes internally uses crazy stuff to compile markdown for the > manual, a good idea, methinks. > sqlite3 - Same as json. Super useful, but old. Not too bad, but I'll > bring it current. > > Thoughts, anyone? Are there other useful c extension gems we're > missing? Can we remove bloops and ftsearch? > > -Steve
> I pretty much agree with your suggestions but I thought the Manual > search function used ftsearch and I do search the manual. Ah, maybe. The search is good, even if sometimes the results suck. More investigation needed. > we could alway add the serialport gem that people stumble on ;^) Haha, that does seem popular.