librelist archives

« back to archive

Let's talk included gems.

Let's talk included gems.

From:
Steve Klabnik
Date:
2012-01-03 @ 22:20
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

Re: [shoes] Let's talk included gems.

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

Re: [shoes] Let's talk included gems.

From:
Tobias Pfeiffer
Date:
2012-01-04 @ 14:33
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
>

Re: [shoes] Let's talk included gems.

From:
Steve Klabnik
Date:
2012-01-04 @ 16:09
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.

Re: [shoes] Let's talk included gems.

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

Re: [shoes] Let's talk included gems.

From:
ashbb
Date:
2012-01-05 @ 11:53
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

Re: [shoes] Let's talk included gems.

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

Re: [shoes] Let's talk included gems.

From:
Cecil Coupe
Date:
2012-01-05 @ 19:33
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

Re: [shoes] Let's talk included gems.

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

Re: [shoes] Let's talk included gems.

From:
Cecil Coupe
Date:
2012-01-05 @ 22:07
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

Re: [shoes] Let's talk included gems.

From:
Eric Watson
Date:
2012-01-05 @ 22:13
> 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 ;) )

Re: [shoes] Let's talk included gems.

From:
Steve Klabnik
Date:
2012-01-05 @ 21:40
>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?

Re: [shoes] Let's talk included gems.

From:
Eric Watson
Date:
2012-01-05 @ 22:04
>> 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?

Re: [shoes] Let's talk included gems.

From:
Steve Klabnik
Date:
2012-01-05 @ 22:25
> 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.

Packager: gem or app?

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



Re: [shoes] Packager: gem or app?

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

Re: [shoes] Packager: gem or app?

From:
Cecil Coupe
Date:
2012-01-07 @ 02:11
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).

Re: [shoes] Packager: gem or app?

From:
ashbb
Date:
2012-01-06 @ 12:40
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

Re: [shoes] Packager: gem or app?

From:
Cecil Coupe
Date:
2012-01-07 @ 02:27
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

Re: [shoes] Packager: gem or app?

From:
ashbb
Date:
2012-01-07 @ 06:44
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

Re: [shoes] Packager: gem or app?

From:
Cecil Coupe
Date:
2012-01-08 @ 04:39
> 
> >  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?

Re: [shoes] Packager: gem or app?

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

Re: [shoes] Packager: gem or app?

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

Re: [shoes] Packager: gem or app?

From:
Cecil Coupe
Date:
2012-01-08 @ 03:58
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. 


Re: [shoes] Packager: gem or app?

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

Re: [shoes] Packager: gem or app?

From:
J. Kaiden
Date:
2012-01-08 @ 05:45
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

Re: [shoes] Packager: gem or app?

From:
Cecil Coupe
Date:
2012-01-08 @ 06:58
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

Re: [shoes] Let's talk included gems.

From:
J. Kaiden
Date:
2012-01-06 @ 00:23
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

Re: [shoes] Let's talk included gems.

From:
serialhex
Date:
2012-01-05 @ 15:20
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

Re: [shoes] Let's talk included gems.

From:
Steve Klabnik
Date:
2012-01-05 @ 15:25
> 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.

Re: [shoes] Let's talk included gems.

From:
ashbb
Date:
2012-01-04 @ 12:37
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

Re: [shoes] Let's talk included gems.

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

Re: [shoes] Let's talk included gems.

From:
J. Kaiden
Date:
2012-01-04 @ 03:11
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

Re: [shoes] Let's talk included gems.

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

Re: [shoes] Let's talk included gems.

From:
J. Kaiden
Date:
2012-01-04 @ 04:36
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

Re: [shoes] Let's talk included gems.

From:
Cecil Coupe
Date:
2012-01-04 @ 05:20
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

Re: [shoes] Let's talk included gems.

From:
Cecil Coupe
Date:
2012-01-03 @ 22:41
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

Re: [shoes] Let's talk included gems.

From:
Steve Klabnik
Date:
2012-01-03 @ 22:48
> 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.