librelist archives

« back to archive

"Standard Library" of gems?

"Standard Library" of gems?

From:
Steve Klabnik
Date:
2010-11-02 @ 13:27
Hey guys-

Just wanted to get some discussion going on the Shoes 'standard library,' of
sorts.

Right now, we're bundling the chipmunk, bloopsaphone, ftsearch, hpricot,
json, and sqlite3 gems. This is mostly because they all require native
extensions, and Shoes breaks terribly when installing those, right? So we
compile and build them with Shoes itself.


There's two sort of paths we can take in the future: Adding more onto this,
possibly with some custom Ruby code of our own, or work hard to fix the
native extensions problem, and stop bundling any gems.

I thought about this because of this feature request:
http://github.com/shoes/shoes/issues#issue/8 (I've been spending lots of
time on Issues lately.)

We could continue to add stuff like this, or we could not. Hackety Hack is
already shipping a sort of "Shoes extended stdlib" in a way. Shoes is kind
of supposed to be tiny, so I'm not sure how I feel about adding more stuff
to it. At the same time, if lots of people are using or would want to use a
gem, it'd make sense to add it.

What's everyone think?

Re: [shoes] "Standard Library" of gems?

From:
Cecil Coupe
Date:
2010-11-03 @ 04:13
I'd like to suggest as way forward that might work if there are enough
volunteers.

Shoes is several things: A GUI DSL that uses Ruby, a manual, a Shoes
installer/packager/downloader, and its self contained with it owns gem
installation that doesn't require installing Ruby or gems (or even
require the end user to have a C compiler)

For those that need that kind of Shoes, you really have to supply it all
in one download. 

A lot of the github issues and many mailing list bug reports are from
Rubyists who like the GUI/DSL and don't like the gem restrictions or
care to learn about the packager, and the manual is goofy or incomplete
from their point of view. 

1. When Green or Blue Shoes is complete enough to run most of the test
scripts, that developer group is satisfied. That group already has their
C compilers and Ruby set up, and would prefer to use their system's
gems, and mostly don't care about the manual or distribution.  I'd call
it *Sandals* instead of Shoes since it's not all there. It would satisfy
many existing ruby coders who learn of Shoes(Sandals). I look forward to
that release myself.

2 The "Caaual User" would be satisfied with a Red Shoes Policeman that
had fewer bugs.  If they exceed what Red Shoes can do, then they have to
get dirty with the Sandals.  So Fix the bugs in Policeman Red Shoes and
put a freeze on new features. Call it a job well done and a final
tribute to _why vision and quirkiness. 

3.Turning Sandals into Shoes? I don't think we can, IMHO. Here's why:
Sure we could write a manual.rb script that 'require sandals'. Probably
should.  We might be able to write a package.rb script that 'requires
sandals' which would creates a exe/dmg/run that ultimately downloads and
installs the Sandals.app, Sandals-Manual.app, Sandals-Packager.app and
the Sandals-Gem.app (if you want to manage Shoes specific Gems) 4 Apps,
3+ platforms each. No problem, right? 12 rakes, 12 downloads. Easy.

To even get that far into that fantasy land, we'll have to fix the
package/install bugs in Red Shoes first because we need the code. What
has been gained by exploding the number of apps and rake files and
downloads? 

In summary. 
1. Fix egregious Red Shoes bugs or call it dead, broken and never to be
fixed again.
2. The next Shoes won't be everything the old Shoes was and it can't be
unless the C code is debugged and maintained, so scale back our dreams
and evangelical promises. Green/Blue Shoes needs C to be Shoes. Or it
Sandals - Shoes will stuff missing. It's OK to admit our limits. 



On Tue, 2010-11-02 at 09:27 -0400, Steve Klabnik wrote:
> Hey guys-
> 
> 
> Just wanted to get some discussion going on the Shoes 'standard
> library,' of sorts.
> 
> 
> Right now, we're bundling the chipmunk, bloopsaphone, ftsearch,
> hpricot, json, and sqlite3 gems. This is mostly because they all
> require native extensions, and Shoes breaks terribly when installing
> those, right? So we compile and build them with Shoes itself.
> 
> 
> 
> 
> There's two sort of paths we can take in the future: Adding more onto
> this, possibly with some custom Ruby code of our own, or work hard to
> fix the native extensions problem, and stop bundling any gems.
> 
> 
> I thought about this because of this feature
> request: http://github.com/shoes/shoes/issues#issue/8 (I've been
> spending lots of time on Issues lately.)
> 
> 
> We could continue to add stuff like this, or we could not. Hackety
> Hack is already shipping a sort of "Shoes extended stdlib" in a way.
> Shoes is kind of supposed to be tiny, so I'm not sure how I feel about
> adding more stuff to it. At the same time, if lots of people are using
> or would want to use a gem, it'd make sense to add it.
> 
> 
> What's everyone think?

Re: [shoes] "Standard Library" of gems?

From:
ashbb
Date:
2010-11-03 @ 08:39
Hi Cecil,

Thank you for sharing your thoughts. :)

> Green/Blue Shoes needs C to be Shoes. Or it Sandals.
You are exactly right.

I don't have a specific idea for now. But want to try to include or get out
some code from Red shoes and use the code in Green Shoes.

I'm not sure it's possible. But I've been slowly learning something
everyday. ;-)

Have fun,
ashbb

Re: [shoes] "Standard Library" of gems?

From:
Cecil Coupe
Date:
2010-11-04 @ 02:57
On Wed, 2010-11-03 at 17:39 +0900, ashbb wrote:
> Hi Cecil,
> 
> Thank you for sharing your thoughts. :)
> 
> > Green/Blue Shoes needs C to be Shoes. Or it Sandals.
> You are exactly right.
> 
> I don't have a specific idea for now. But want to try to include or
> get out some code from Red shoes and use the code in Green Shoes.

> I'm not sure it's possible. But I've been slowly learning something
> everyday. ;-)
> 
I think it is possible. Easier for GTK than QT - just find all the
dll/so/dyld being used and copy them into a installation like Red Shoes
does.