librelist archives

« back to archive

Fixing the packager

Fixing the packager

From:
Eric Watson
Date:
2012-01-10 @ 22:12
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





Re: [shoes] Fixing the packager

From:
Cecil Coupe
Date:
2012-01-10 @ 23:44
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 

Re: [shoes] Fixing the packager

From:
Cecil Coupe
Date:
2012-01-11 @ 04:37
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.

Re: [shoes] Fixing the packager

From:
Eric Watson
Date:
2012-01-11 @ 22:08
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

Re: [shoes] Fixing the packager

From:
Steve Klabnik
Date:
2012-01-11 @ 23:43
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. :)

Re: [shoes] Fixing the packager

From:
Eric Watson
Date:
2012-01-11 @ 12:37
> 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

Re: [shoes] Fixing the packager

From:
Cecil Coupe
Date:
2012-01-12 @ 01:13
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. 


Re: [shoes] Fixing the packager

From:
Eric Watson
Date:
2012-01-18 @ 20:53
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

Re: [shoes] Fixing the packager

From:
Cecil Coupe
Date:
2012-01-18 @ 21:47
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.

Re: [shoes] Fixing the packager

From:
Eric Watson
Date:
2012-01-18 @ 22:15
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

Re: [shoes] Fixing the packager

From:
Eric Watson
Date:
2012-01-18 @ 22:29
>> 
>> 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.

Re: [shoes] Fixing the packager

From:
Steve Klabnik
Date:
2012-01-18 @ 21:50
Eric and Cecil, you're awesome. SemVer +1 here, too.

Re: [shoes] Fixing the packager

From:
Peter Fitzgibbons
Date:
2012-01-18 @ 20:58
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

Re: [shoes] Fixing the packager

From:
Steve Klabnik
Date:
2012-01-11 @ 13:02
> 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.

Re: [shoes] Fixing the packager

From:
Eric Watson
Date:
2012-01-11 @ 14:12
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

Re: [shoes] Fixing the packager

From:
Steve Klabnik
Date:
2012-01-11 @ 18:18
> 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.

Re: [shoes] Fixing the packager

From:
Eric Watson
Date:
2012-01-11 @ 21:52
>> 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

[shoes] slow rendering with lage list

From:
Date:
2012-01-11 @ 15:19
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>

Re: [shoes] slow rendering with lage list

From:
ashbb
Date:
2012-01-14 @ 15:23
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

Re: [shoes] Fixing the packager

From:
Cecil Coupe
Date:
2012-01-10 @ 23:23
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.

Re: [shoes] Fixing the packager

From:
Cecil Coupe
Date:
2012-01-11 @ 09:36
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.

Re: [shoes] Fixing the packager

From:
Eric Watson
Date:
2012-01-11 @ 12:49
> 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

Re: [shoes] Fixing the packager

From:
Cecil Coupe
Date:
2012-01-12 @ 01:24
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.