Hi all,
I found this great post by _why from way back in 2008, when he had just
gotten the packager working. Gives you a little more insight into what he
was thinking about packager. Note the excitement in the comments!
http://viewsourcecode.org/why/hackety.org/2008/06/19/stampingExesAndDmgs.html
Since I'm working on OS X, and packaging is broken there, that's where I'm
starting. Here are some progress notes from my recent investigations:
We have some duplication in the templates Shoes uses to produce a .app.
When you build a .app, the Rakefile uses templates stored in platform/mac,
and Shoes::Pack uses templates that are inlined in the lib/shoes/pack.rb
code. There are some slight differences between the templates, but the
duplication is problematic. I have fixed some issues in the build,
relating to pango, that weren't carried over into the packager.
The launch script for a packaged .app contains this code:
if [ ! -d /Applications/Shoes.app ]
then ./cocoa-install
fi
If /Applications/Shoes.app doesn't exist, then execute cocoa-install.
Presumably, this opens ~/.shoes/.../shoes.dmg and installs Shoes.app into
/Applications. But it's a binary file, so I can't see what exactly it
does. Does anyone know? Also, is there a compelling reason to install
Shoes.app versus running Shoes.app from ~/.shoes ?
Eric
I've done enough research to learn that I should be able to cross compile mingw code from Linux and I should be able to install and run the Nullsoft nsis Windows installer code in Linux. So, in theory, everything Shoes/MingW can be done in linux (probably also from OSX intel if you're a masochist) This will take some rakefile changes and the "great refactoring" previously done will help . My thoughts are I need to create several more variations of env.rb and tasks.rb in a new directory in make/. Perhaps it could be called linux-mingw32 (just a suggestion, please, please advise). That would contain the recipes for compiling windows code with the mingw32 cross compiler from linux. I would also need to tweak the main Rakefile to acknowledge that there are cross compiled bastard children in linux-mingw32 and this time I want to build them instead of building linux shoes. Rake file tasks like 'rake build-mingw32' and 'rake package-mingw32' and 'rake stubs-mingw32'. I don't really understand the refactored rake files so before I go crazy on them, I'd like some advice.
> I've done enough research to learn that I should be able to cross > compile mingw code from Linux and I should be able to install and run > the Nullsoft nsis Windows installer code in Linux. So, in theory, > everything Shoes/MingW can be done in linux (probably also from OSX > intel if you're a masochist) I know Steve has been working with a few people on a new Windows build (Chuck, Paul, and others). I don't know enough about it to be helpful. > This will take some rakefile changes and the "great refactoring" > previously done will help . My thoughts are I need to create several > more variations of env.rb and tasks.rb in a new directory in make/. > Perhaps it could be called linux-mingw32 (just a suggestion, please, > please advise). That would contain the recipes for compiling windows > code with the mingw32 cross compiler from linux. I would also need to > tweak the main Rakefile to acknowledge that there are cross compiled > bastard children in linux-mingw32 and this time I want to build them > instead of building linux shoes. Rake file tasks like 'rake > build-mingw32' and 'rake package-mingw32' and 'rake stubs-mingw32'. I > don't really understand the refactored rake files so before I go crazy > on them, I'd like some advice. The "great refactoring" is very much not finished. The plan was to convert the various env.rb files from scripts into Rake tasks. It's incredibly confusing to have a hybrid script-based and task-based build, because certain code is evaluated on load, and other code is not evaluated until a task is called. Also, the fact that env.rb relies on constants means that it is difficult to provide defaults and then override them in specific environments without generating warnings. There is a *huge* amount of copy/paste and "just make it work" code among the env.rb files, so that it is difficult to even see what matters. There has been the shell of a namespace created, and many tasks for OS X have been extracted, but the env.rb files remain. Given that the refactor is not complete, you could either complete it, or just create a parallel env using the same structure as those that exist. I think I know which you will choose ;) Eric
On Wed, 2012-01-11 at 06:49 -0600, Eric Watson wrote: > > I know Steve has been working with a few people on a new Windows build > (Chuck, Paul, and others). I don't know enough about it to be helpful. I would be nice if one of them wanted to work on the windows stub code. I only know enough windows to be dangerous. > > The "great refactoring" is very much not finished. The plan was to > convert the various env.rb files from scripts into Rake tasks. It's > incredibly confusing to have a hybrid script-based and task-based > build, because certain code is evaluated on load, and other code is not > evaluated until a task is called. Also, the fact that env.rb relies on > constants means that it is difficult to provide defaults and then > override them in specific environments without generating warnings. > > There is a *huge* amount of copy/paste and "just make it work" code > among the env.rb files, so that it is difficult to even see what > matters. > > There has been the shell of a namespace created, and many tasks for OS > X have been extracted, but the env.rb files remain. Given that the > refactor is not complete, you could either complete it, or just create > a parallel env using the same structure as those that exist. I think I > know which you will choose ;) Normally I like to debug at the Church of What's Working Now. I'll spend some time thinking about the cross compiling changes needed.
A few more packaging 'observations'. I'm comparing code from Raisins
(when packaging worked) and Policeman (3.1)
For osx, I strongly suspect cocoa-install is the compiled (FAT)
platform/mac/stub.m. It is certainly involved in performing a net
install and it still has hacketyhack.net URLs so that's gonna fail and
needs fixing.
It would have to be FAT at the time - both ppc and intel in one file.
Probably needs to be x32 and x64 now.
Similarly for Windows I suspect blank.exe is really platform/msw/stub.c
Why do I think these things? In Raisins Rakefile there was a task ('rake
stub') which which not linked to by any dependency in the Raisin
rakefile so it was meant to be call from the command line as a separate
step from building or packaging a Shoes install. platform/msw/stub.c
certainly does what the _why email said blank.exe does. Perhaps _why
didn't finish the rakefile :stub task with a task descriptor line (for
sure) and he might not have finished the :stub task activities that
create blank.exe.
If we assume that the Raisins rakefile was not really complete when _why
went walkabout it's easy to see how the :stub task was placed inside the
wrong place in Policeman Rakefile and various hacks were made to pack.rb
to get a halfway exe pack (download full version unless you are on
windows).
At the time of the Policeman release, there weren't a whole of
developers, and Steve had never even tried the script packager (not the
same as packaging hacketyhack) so he didn't bother to fix that code he
doesn't use. Ashbb isn't/wasn't all that interested in .exe and .dmg
and .run script packaging either, but he did hack pack.rb to do what he
thought should be done. I'm not trash talking either of them. In the
case of OSX it needs to fix the what was never done in the cocoa code
when the download urls changed. Windows needs to revert back to what
used to work and fix the bugs that the mingw switch created (if any). I
can't see any difference between stub.c and shoes-stub.c except for the
URL change and the rakefile change and the pack.rb change that rippled
up from not understand the script packager.
If Eric is going to fix OSX, I might try to fix Windows unless someone
else smarter than me wants to help.
On Jan 10, 2012, at 10:37 PM, Cecil Coupe wrote: > For osx, I strongly suspect cocoa-install is the compiled (FAT) > platform/mac/stub.m. It is certainly involved in performing a net > install and it still has hacketyhack.net URLs so that's gonna fail and > needs fixing. > > It would have to be FAT at the time - both ppc and intel in one file. > Probably needs to be x32 and x64 now. I've confirmed this to be true, first by running static/stubs/cocoa-install (it pops up a Downloading Shoes window that doesn't do anything), and then by recompiling platform/mac/stub.m and running it (same thing, as expected--haven't touched the actual code yet). Some discoveries and notes: I ran `git whatchanged static/stubs/cocoa-install` and discovered that it's been with us in its compiled form since July 2008! commit 37ea5ffad6076dfd17152ce988648688db2a5faf Author: _why <why@whytheluckystiff.net> Date: Fri Jul 11 14:04:16 2008 -0600 * static/stubs/cocoa-install: replacing the OS X stub with a Universal buil :100755 100755 7d01ad6... 267821b... M static/stubs/cocoa-install commit b77188ea51dcbcfdc1cd3cf5e374af0bd8d5a648 Author: _why <why@whytheluckystiff.net> Date: Wed Jun 18 23:10:21 2008 -0600 * lib/shoes/pack.rb: use `open` to launch Shoes.app inside the portable app * platform/mac/stub.m: quit after everything's installed. … I updated the rake task to compile the stub so it creates a fat binary for x86_64 and i386 architectures (and so it uses the same 10.6 SDK we are using elsewhere). When you run the task rake stub you will have an executable called 'stub' in the main project directory. Apparently, this was copied manually and placed under version control as static/stubs/cocoa-install. That's it for now! Eric
You are a beast! I've spent the last few days putting my life on hold to be present in a courtroom. Wooo! Tomorrow is about fixing my backlog, and Friday I hope to dig into this kind of stuff. :)
> For osx, I strongly suspect cocoa-install is the compiled (FAT) > platform/mac/stub.m. It is certainly involved in performing a net > install and it still has hacketyhack.net URLs so that's gonna fail and > needs fixing. Nice work! Yes, I think you've found it. This is great for our understanding of the code. So we've got three download URLs in the codebase (that we've discovered) so far: - hacketyhack.net (platform/mac/stub.m) - shoes.heroku.com (lib/shoes/pack.rb) - www.rin-shun.com (platform/msw/stub.c) (I think this is ashbb's personal site) Currently, the project website is at shoesrb.com, code is at github.com/shoes/shoes. Hackety is at hackety.com (and hackety.net), code is at github.com/hacketyhack/hacketyhack Steve, let's dedicate a download url space here and commit to maintaining it, documenting it, and protecting it for the community. > It would have to be FAT at the time - both ppc and intel in one file. > Probably needs to be x32 and x64 now. Right. I'll chase that down. > Similarly for Windows I suspect blank.exe is really platform/msw/stub.c > Why do I think these things? In Raisins Rakefile there was a task ('rake > stub') which which not linked to by any dependency in the Raisin > rakefile so it was meant to be call from the command line as a separate > step from building or packaging a Shoes install. platform/msw/stub.c > certainly does what the _why email said blank.exe does. Perhaps _why > didn't finish the rakefile :stub task with a task descriptor line (for > sure) and he might not have finished the :stub task activities that > create blank.exe. I have looked at that stub task *many* times without understanding what it is for. This is great! > If we assume that the Raisins rakefile was not really complete when _why > went walkabout it's easy to see how the :stub task was placed inside the > wrong place in Policeman Rakefile and various hacks were made to pack.rb > to get a halfway exe pack (download full version unless you are on > windows). > > If Eric is going to fix OSX, I might try to fix Windows unless someone > else smarter than me wants to help. Perfect. Thanks, Cecil! Eric
On Wed, 2012-01-11 at 06:37 -0600, Eric Watson wrote: > > So we've got three download URLs in the codebase (that we've discovered) so far: > > - hacketyhack.net (platform/mac/stub.m) > - shoes.heroku.com (lib/shoes/pack.rb) > - www.rin-shun.com (platform/msw/stub.c) (I think this is ashbb's personal site) There's is another URL for linux too, i thinks at rin-shun too. > > Currently, the project website is at shoesrb.com, code is at github.com/shoes/shoes. > > Hackety is at hackety.com (and hackety.net), code is at github.com/hacketyhack/hacketyhack > > Steve, let's dedicate a download url space here and commit to maintaining it, documenting it, and protecting it for the community. > For those who are reading along with this thread it's time to mention how the website/pack.rb/download-ing stubs work together. When packaging a script, the pack.rb code contacts shoes.heroku.com/pkg/policeman/osx/shoes the website returns one line of text which is a the url where the shoes installer (shoes.dmg in this example). If the script packager is packing for a net install it ignores that (its up to the stubs to know where to download from, silly but true and probably fixable by wizards). There are good things about the website returning the correct url for downloading. For example if I build a newer Windows Shoes and put it on my personal webserver the shoes.heroku webmaster only has to replace the url returned to pack.rb for windows and all packers from then on will use the newer shoes.exe. Or if its a clunker or not maintained, then it can be switched back to point to ashbb shoes.exe or someone elses. That's really a good thing. The problem is the stub also has to have the 'real' url, because the stub will use it to install shoes on demand. There are some benefits to this duplication as it makes testing the packing/stub/installing easier. Sadly, it's a very manual effort to make sure they are both correct when testing if over and its time to release a new version. Trust me, it can be forgotten. Eric, it appears that there is no entry at www.heroku.com and for the osx packager with file (unless I made a typo) wget www.heroku.com/pkg/policeman/osx/shoes-novideo returns a 404 and it fails when I try to pkg osx from shoes. That needs fixing What ever it is set to is what is put into stub.m and recompile into cocoa-install and when full size packaging and net install packaging are working then we should talk about how to make it better.
An update on OS X packaging.
But first, have you checked out The Magic Packager wiki page lately?
https://github.com/shoes/shoes/wiki/A-Developer's-Tour-Through-The-Magic-Packager
I just dropped by to review, and Cecil has added a new cast of characters
(Judy, Joe, and mom) and plenty more sauce. It's worth reading five or six
times if you're interested in how Shoes packaging works.
Okay, packaging. I have used the Shoes packager to package a script for OS
X. The .dmg code still doesn't work. I did have a little luck with the
.app, though. Keep in mind, what's supposed to happen is that Shoes
generates the .app, then packages it into a .dmg, then deletes the .app.
For some reason, I'm getting no .dmg, but I still have the .app, which
doesn't run. At first.
After tinkering with the generated files, I did get my packaged app to
run, using a pre-installed /Applications/Shoes.app. That's awesome, and
won't be hard to fix in code.
I moved /Applications/Shoes.app, and got my packaged script to run the
installer stub. Now, this didn't actually complete the installation,
because the download URLs aren't there yet. And there's no feedback about
that--it just hangs. But still, on the OS X side, I think we're about at
the point where we need those Shoes .dmg/.exe/.run available for download.
Note: I am using the term 'installer stub' to refer to the file generated
from platform/mac/stub.m, which is called 'cocoa-installer' in your
packaged .app. Its job is to download and install Shoes if it's needed.
Here are some questions:
1. Oh, binject, you are so C, so byte-level, you pwn project, you. I am
starting to experiment with Binject to see what's failing. I'm just
manually requiring the binject bundle that Shoes creates:
$ pry -I/Users/eric/code/shoes/dist/ruby/lib/universal-darwin11.2.0
[1] pry(main)> require 'binject'
=> true
and typing in code like you find in lib/shoes/pack.rb. Anyone with hints
or time to play with it and see what fails, jump in!
2. The packager will check your ~/.shoes directory to see if you already
have a copy of Shoes there. If so, it'll use that to package your app. If
not, it'll download a copy. However, the OS X installer stub doesn't check
for a cached copy at ~/.shoes. Instead, it checks for
/Applications/Shoes.app. If there, it launches your app with that copy of
Shoes. If not, it downloads Shoes and installs it to /Applications. On
some level, this makes sense to me, but on some level, it seems like
things would be simpler if there were only one process. Thoughts?
3. Neither the packager nor the installer stub make any effort to find the
'proper' version of Shoes. They just download the latest. That seems
fragile. If I packaged my app using Policeman, and it worked fine, but at
some point the latest version is Lollipop (on which my app doesn't run),
nobody will be able to run my app, because it will always download Shoes
Lollipop. At some point, we might consider developing a better versioning
system (SemVer?), and bundling the Shoes version with packaged apps, so
they can download the appropriate version. Or maybe that would cause more
problems…
Thanks, team.
Over and out.
Eric
On Wed, 2012-01-18 at 14:53 -0600, Eric Watson wrote: > > 1. Oh, binject, you are so C, so byte-level, you pwn project, you. I am > starting to experiment with Binject to see what's failing. I'm just > manually requiring the binject bundle that Shoes creates: > > $ pry -I/Users/eric/code/shoes/dist/ruby/lib/universal-darwin11.2.0 > [1] pry(main)> require 'binject' => true Yes, binject is a secret place with hardcoded knowledge of Windows and OSX file and resource formats. I would not surprise me to learn that the code is not upto date with modern Windows and OSX. > > > 2. The packager will check your ~/.shoes directory to see if you > already have a copy of Shoes there. If so, it'll use that to package > your app. If not, it'll download a copy. However, the OS X installer > stub doesn't check for a cached copy at ~/.shoes. Instead, it checks > for /Applications/Shoes.app. If there, it launches your app with that > copy of Shoes. If not, it downloads Shoes and installs it to > /Applications. On some level, this makes sense to me, but on some > level, it seems like things would be simpler if there were only one > process. Thoughts? Did OSX kill off ~/Applications ? > > 3. Neither the packager nor the installer stub make any effort to find > the 'proper' version of Shoes. They just download the latest. That > seems fragile. If I packaged my app using Policeman, and it worked > fine, but at some point the latest version is Lollipop (on which my app > doesn't run), nobody will be able to run my app, because it will always > download Shoes Lollipop. At some point, we might consider developing a > better versioning system (SemVer?), and bundling the Shoes version with > packaged apps, so they can download the appropriate version. Or maybe > that would cause more problems… Who is managing that list? There is a exe and a run and they work within well known limits. We just need a one line addition to point to a Shoes3.dmg I think a numbering system would be very useful and also include OS versions and 32/64 bit distinctions. Thanks for working on the OSX stuff, Eric. My progress with crosscompiling Ruby and Shoes for Windows is progressing. I've got a ruby1.9.2 dll that might be OK. Maybe in a couple of days I'll have a Shoes.exe. Maybe.
On Jan 18, 2012, at 3:47 PM, Cecil Coupe wrote: > On Wed, 2012-01-18 at 14:53 -0600, Eric Watson wrote: > >> >> 1. Oh, binject, you are so C, so byte-level, you pwn project, you. I am >> starting to experiment with Binject to see what's failing. I'm just >> manually requiring the binject bundle that Shoes creates: >> >> $ pry -I/Users/eric/code/shoes/dist/ruby/lib/universal-darwin11.2.0 >> [1] pry(main)> require 'binject' => true > > Yes, binject is a secret place with hardcoded knowledge of Windows and > OSX file and resource formats. I would not surprise me to learn that the > code is not upto date with modern Windows and OSX. Binject is pretty much a ruby wrapper for this project, whose last commit was July 2010: https://github.com/planetbeing/xpwn >> >> 2. The packager will check your ~/.shoes directory to see if you >> already have a copy of Shoes there. If so, it'll use that to package >> your app. If not, it'll download a copy. However, the OS X installer >> stub doesn't check for a cached copy at ~/.shoes. Instead, it checks >> for /Applications/Shoes.app. If there, it launches your app with that >> copy of Shoes. If not, it downloads Shoes and installs it to >> /Applications. On some level, this makes sense to me, but on some >> level, it seems like things would be simpler if there were only one >> process. Thoughts? > > Did OSX kill off ~/Applications ? No, but it's not much used, and most users probably don't understand the difference. > >> >> 3. Neither the packager nor the installer stub make any effort to find >> the 'proper' version of Shoes. They just download the latest. That >> seems fragile. If I packaged my app using Policeman, and it worked >> fine, but at some point the latest version is Lollipop (on which my app >> doesn't run), nobody will be able to run my app, because it will always >> download Shoes Lollipop. At some point, we might consider developing a >> better versioning system (SemVer?), and bundling the Shoes version with >> packaged apps, so they can download the appropriate version. Or maybe >> that would cause more problems… > > Who is managing that list? There is a exe and a run and they work within > well known limits. We just need a one line addition to point to a > Shoes3.dmg My guess is nobody. Steve, can we get someone access to shoesrb.com? > > I think a numbering system would be very useful and also include OS > versions and 32/64 bit distinctions. > > Thanks for working on the OSX stuff, Eric. My progress with > crosscompiling Ruby and Shoes for Windows is progressing. I've got a > ruby1.9.2 dll that might be OK. Maybe in a couple of days I'll have a > Shoes.exe. Maybe. :) Eric
>> >> Yes, binject is a secret place with hardcoded knowledge of Windows and >> OSX file and resource formats. I would not surprise me to learn that the >> code is not upto date with modern Windows and OSX. > > Binject is pretty much a ruby wrapper for this project, whose last commit was July 2010: > > https://github.com/planetbeing/xpwn For comparison, looks like the last commits to our version of the library was in 2008.
Eric and Cecil, you're awesome. SemVer +1 here, too.
SemVer +1. Peter Fitzgibbons (847) 859-9550 Email: peter.fitzgibbons@gmail.com IM GTalk: peter.fitzgibbons IM AOL: peter.fitzgibbons@gmail.com On Wed, Jan 18, 2012 at 2:53 PM, Eric Watson <wasnotrice@gmail.com> wrote: > An update on OS X packaging. > > But first, have you checked out The Magic Packager wiki page lately? > > > https://github.com/shoes/shoes/wiki/A-Developer's-Tour-Through-The-Magic-Packager > > I just dropped by to review, and Cecil has added a new cast of characters > (Judy, Joe, and mom) and plenty more sauce. It's worth reading five or six > times if you're interested in how Shoes packaging works. > > Okay, packaging. I have used the Shoes packager to package a script for OS > X. The .dmg code still doesn't work. I did have a little luck with the > .app, though. Keep in mind, what's supposed to happen is that Shoes > generates the .app, then packages it into a .dmg, then deletes the .app. > For some reason, I'm getting no .dmg, but I still have the .app, which > doesn't run. At first. > > After tinkering with the generated files, I did get my packaged app to > run, using a pre-installed /Applications/Shoes.app. That's awesome, and > won't be hard to fix in code. > > I moved /Applications/Shoes.app, and got my packaged script to run the > installer stub. Now, this didn't actually complete the installation, > because the download URLs aren't there yet. And there's no feedback about > that--it just hangs. But still, on the OS X side, I think we're about at > the point where we need those Shoes .dmg/.exe/.run available for download. > > Note: I am using the term 'installer stub' to refer to the file generated > from platform/mac/stub.m, which is called 'cocoa-installer' in your > packaged .app. Its job is to download and install Shoes if it's needed. > > > Here are some questions: > > 1. Oh, binject, you are so C, so byte-level, you pwn project, you. I am > starting to experiment with Binject to see what's failing. I'm just > manually requiring the binject bundle that Shoes creates: > > $ pry -I/Users/eric/code/shoes/dist/ruby/lib/universal-darwin11.2.0 > > [1] pry(main)> require 'binject' > => true > > and typing in code like you find in lib/shoes/pack.rb. Anyone with hints > or time to play with it and see what fails, jump in! > > 2. The packager will check your ~/.shoes directory to see if you already > have a copy of Shoes there. If so, it'll use that to package your app. If > not, it'll download a copy. However, the OS X installer stub doesn't check > for a cached copy at ~/.shoes. Instead, it checks for > /Applications/Shoes.app. If there, it launches your app with that copy of > Shoes. If not, it downloads Shoes and installs it to /Applications. On some > level, this makes sense to me, but on some level, it seems like things > would be simpler if there were only one process. Thoughts? > > 3. Neither the packager nor the installer stub make any effort to find the > 'proper' version of Shoes. They just download the latest. That seems > fragile. If I packaged my app using Policeman, and it worked fine, but at > some point the latest version is Lollipop (on which my app doesn't run), > nobody will be able to run my app, because it will always download Shoes > Lollipop. At some point, we might consider developing a better versioning > system (SemVer?), and bundling the Shoes version with packaged apps, so > they can download the appropriate version. Or maybe that would cause more > problems… > > Thanks, team. > Over and out. > > Eric
> I'm not trash talking either of them. Zero bad vibes taken. I didn't even realize there were 3 kinds of packaging for a long time... > Steve, let's dedicate a download url space here and commit to maintaining it, documenting it, and protecting it for the community. Let's do it. http://shoesrb.com/stubs seems like an appropriate holding place. Thoughts? > I know Steve has been working with a few people on a new Windows build (Chuck, Paul, and others). I don't know enough about it to be helpful. Basically, we got a new version of everything building, but it won't actually run. The idea was to pull RubyInstaller up to current. Chuck put in a lot of awesome work, but I wasn't quite able to get it over the finish line.
On Jan 11, 2012, at 7:03 AM, Steve Klabnik <steve@steveklabnik.com> wrote: >> Steve, let's dedicate a download url space here and commit to maintaining it, documenting it, and protecting it for the community. > > Let's do it. http://shoesrb.com/stubs seems like an appropriate > holding place. Thoughts? Well, this URL will not be for the stubs themselves, but for the shoes setup downloads. In platform/mac/stub.m, the URL is /pkg/osx/shoes. I *think* this download was just a .dmg of Shoes.app, but not certain. What about http://shoesrb.com/pkg/osx/shoes and similar? This assumes a dynamic web app, not a static site. It also assumes that we distribute Shoes as a .dmg Eric
> What about http://shoesrb.com/pkg/osx/shoes and similar? Sure. > This assumes a dynamic web app, not a static site. It's currently a Redmine install. > It also assumes that we distribute Shoes as a .dmg Which we should.
>> It also assumes that we distribute Shoes as a .dmg > > Which we should. Right, so for those interested, to create a .dmg of Shoes on OS X, after you build, just do rake installer or, to build Shoes and create the installer all at once, rake package Either way, you will find the .dmg in the pkg directory. I added a task description for this task to the Rakefile, and updated the wiki: https://github.com/shoes/shoes/wiki/Building-Shoes-on-Mac-OS-X-10.6-and-10.7 Eric
Hi everyone, i usually don't ask from help since I think that by looking
for the answer you learn the most.
But this one, I'm not sure I can handle.
This is a program of me to search an artist on spotify musicservice,
distillate all songs from that artist albums and show that list in a
stack.
I use green shoes because in the Red Shoes version I can't use the
meta-spotify gem, I have to shell out and run a regular ruby program twice
before I have my results, not what I like.
In Green Shoes I don't have that problem but when the result is large (an
artist with a lot of songs) Shoes takes many minutes to show something or
crashes.
I'm on windows 7 and use the most recent Green Shoes gem.
The code is somewhat compact and not with much comment but you should be
able to run it if you do a "gem install meta-spotify" first.
To have the same results as me, search for Anouk (a Dutch artist I
recommend listening to). You should get 5 results, if you click the last
you should alse get the songnames since this is a shot list. If you click
the first you get the songnames in the consolewindow after half a minute
but in the Shoes window you have to wait veeeryyy long and possibly Shoes
crashes. Do I do something wrong by adding the para's this way or what ?
If I just show the array as in the commented out line I eventually get all
the results but I would like to show them as a link and perform an action
if they are clicked.
Please help me out here.
Since I use the new version of Green Shoes I also get the following error
in the console
"C:/Ruby193/lib/ruby/gems/1.9.1/gems/glib2-1.1.0-x86-mingw32/lib/1.9/glib2.so:
warning: no super class for `GLib::IOChannelWin32Socket', Object assumed"
but this was not in the old version where I had the same problem, the
program runs though.
Here the code
<code>
['green_shoes','meta-spotify'].each(&method(:require))
app = Shoes.app :width => 500, :height => 600 do
stack do
@menu = flow do
@e = edit_line
button("Search") do
@slot.clear
@artists = MetaSpotify::Artist.search(@e.text)
if @artists[:artists].length > 0
@artists[:artists].each do |artist|
@slot.append{para link("#{artist.name}"){
@slot.clear
@e.text = "#{artist.name}"
uri = artist.uri
songs = Array.new
chosen_artist = MetaSpotify::Artist.lookup(uri, :extras =>
'albumdetail')
print "\n"
print chosen_artist.inspect #to see the result in the console window
chosen_artist.albums.each do |album|
album = MetaSpotify::Album.lookup(album.uri, :extras => "track")
tracks = album.tracks.to_a
tracks.each do |track|
track.artists.each do |artist|
if chosen_artist.uri==uri
songs << track.name.gsub(/&/,' and ').to_s #have to
do this otherwise error on the &
end
end
end
end
songs.uniq!.sort! #remove duplicates and sort the songtitles
print songs.inspect #to see the result in the console window
songs.each do |song|
@slot.append{para link(song)} #******here is my problem:
it hangs with large lists (+100)********
end
#@slot.append{para songs} #a bit faster but also waaay too
slow and not what I want
}}
end
else
@slot.clear{para "No Artists found for the search term." }
end
end
button('Exit'){exit}
end
@slot = stack{""}
end
end
</code>
Hi Peter, Thank you for sharing an interesting Shoes app. :) > in the Shoes window you have to wait veeeryyy long and possibly > Shoes crashes. Yeah, because GTK would assume no response. > If I just show the array as in the commented out line I eventually > get all the results Yes, *eventually*. But you have to respond to Shoes once in a while. Try out this one I modified: https://gist.github.com/1610747 I divided into groups of ten. If you don't want to divide, you have to run the code that takes time in other thread. > Since I use the new version of Green Shoes I also get the following > error in the console "C:/Ruby193/lib/ruby/gems/1.9.1/gems/glib2- > 1.1.0-x86-mingw32/lib/1.9/glib2.so: warning: no super class for > `GLib::IOChannelWin32Socket', Object assumed" This is a bug of Ruby/GTK2 1.1.0. It will be fixed in the next release. ashbb
On Tue, 2012-01-10 at 16:12 -0600, Eric Watson wrote: > If /Applications/Shoes.app doesn't exist, then execute cocoa-install. > Presumably, this opens ~/.shoes/.../shoes.dmg and installs Shoes.app > into /Applications. But it's a binary file, so I can't see what > exactly it does. Does anyone know? Also, is there a compelling reason > to install Shoes.app versus running Shoes.app from ~/.shoes ? The way it should work (IMO) is that if it's a shoes install built from the rake file, then it belongs in /Applications. If its shoes packaged with a script or shy then the shoes should be put in ~/.shoes and executed from there unless there is the same shoes in /Application
On Tue, 2012-01-10 at 16:12 -0600, Eric Watson wrote: > Hi all, > > I found this great post by _why from way back in 2008, when he had just > gotten the packager working. Gives you a little more insight into what > he was thinking about packager. Note the excitement in the comments! > > http://viewsourcecode.org/why/hackety.org/2008/06/19/stampingExesAndDmgs.html Yes! Finally an explanation of what's in blank.exe. > > If /Applications/Shoes.app doesn't exist, then execute cocoa-install. > Presumably, this opens ~/.shoes/.../shoes.dmg and installs Shoes.app > into /Applications. But it's a binary file, so I can't see what exactly > it does. Does anyone know? Also, is there a compelling reason to > install Shoes.app versus running Shoes.app from ~/.shoes ? > We need to find the source code for cocoa-install and blank.exe. They might have been created by the rake file from files with different names. The fact that the cocoa-install is a Fat file (ppc/intel) suggests it might have a problem on 64 bit systems.