[ANN] Ruby Changes in Leopard

Discussion in 'Ruby' started by Laurent Sansonetti, Oct 25, 2007.

  1. Hi,

    Leopard, Mac OS X 10.5, will very soon be available to everyone!

    Many of you have been wondering about the changes that will impact the
    Ruby environment. We preventively compiled a list of all changes, and
    you can now access it from here:

    http://ruby.macosforge.org
    http://trac.macosforge.org/projects/ruby/wiki/WhatsNewInLeopard

    As you can see we also just created a new Ruby project on MacOSForge,
    with the aim of providing more information regarding the usage of Ruby
    on the Mac in the future.

    Enjoy!

    Laurent
    Laurent Sansonetti, Oct 25, 2007
    #1
    1. Advertising

  2. Laurent Sansonetti

    Lyle Johnson Guest

    On Oct 25, 2007, at 1:42 PM, Laurent Sansonetti wrote:

    > Leopard, Mac OS X 10.5, will very soon be available to everyone!
    >
    > Many of you have been wondering about the changes that will impact the
    > Ruby environment. We preventively compiled a list of all changes, and
    > you can now access it from here:
    >
    > http://ruby.macosforge.org
    > http://trac.macosforge.org/projects/ruby/wiki/WhatsNewInLeopard
    >
    > As you can see we also just created a new Ruby project on MacOSForge,
    > with the aim of providing more information regarding the usage of Ruby
    > on the Mac in the future.


    Thanks for all the work that you've put into this, Laurent. Looks
    like a great resource, and I for one appreciate Apple's support for
    Ruby.
    Lyle Johnson, Oct 25, 2007
    #2
    1. Advertising

  3. Laurent Sansonetti

    Lee Packham Guest

    I didn't notice Apple had integrated the DTrace stuff as is. The only
    shame is that adding stuff like the gems I use I'll have to do outside
    of Macports.

    Still - really good job tbh.

    On 25 Oct 2007, at 19:52, Lyle Johnson wrote:

    >
    > On Oct 25, 2007, at 1:42 PM, Laurent Sansonetti wrote:
    >
    >> Leopard, Mac OS X 10.5, will very soon be available to everyone!
    >>
    >> Many of you have been wondering about the changes that will impact
    >> the
    >> Ruby environment. We preventively compiled a list of all changes, and
    >> you can now access it from here:
    >>
    >> http://ruby.macosforge.org
    >> http://trac.macosforge.org/projects/ruby/wiki/WhatsNewInLeopard
    >>
    >> As you can see we also just created a new Ruby project on MacOSForge,
    >> with the aim of providing more information regarding the usage of
    >> Ruby
    >> on the Mac in the future.

    >
    > Thanks for all the work that you've put into this, Laurent. Looks
    > like a great resource, and I for one appreciate Apple's support for
    > Ruby.
    >
    Lee Packham, Oct 25, 2007
    #3
  4. Laurent Sansonetti

    Tim Pease Guest

    On Oct 25, 2007, at 12:42 PM, Laurent Sansonetti wrote:

    > Hi,
    >
    > Leopard, Mac OS X 10.5, will very soon be available to everyone!
    >
    > Many of you have been wondering about the changes that will impact the
    > Ruby environment. We preventively compiled a list of all changes, and
    > you can now access it from here:
    >
    > http://ruby.macosforge.org
    > http://trac.macosforge.org/projects/ruby/wiki/WhatsNewInLeopard
    >



    The wiki page says that "The gem_server utility is not part of the
    client distribution of Leopard. It is only provided in the server."
    This seems a very horrible omission -- gem_server is used regularly
    to view the RDoc documentation for installed gems. Is there another
    mechanism in Leopard to view RDoc for installed gems? A nice Cocoa
    app perhaps ;)

    Blessings,
    TwP
    Tim Pease, Oct 25, 2007
    #4
  5. On Fri, Oct 26, 2007 at 06:49:03AM +0900, Tim Pease wrote:
    > On Oct 25, 2007, at 12:42 PM, Laurent Sansonetti wrote:
    > >Leopard, Mac OS X 10.5, will very soon be available to everyone!
    > >
    > >Many of you have been wondering about the changes that will impact the
    > >Ruby environment. We preventively compiled a list of all changes, and
    > >you can now access it from here:
    > >
    > >http://ruby.macosforge.org
    > >http://trac.macosforge.org/projects/ruby/wiki/WhatsNewInLeopard

    >
    > The wiki page says that "The gem_server utility is not part of the
    > client distribution of Leopard. It is only provided in the server."
    > This seems a very horrible omission -- gem_server is used regularly
    > to view the RDoc documentation for installed gems. Is there another
    > mechanism in Leopard to view RDoc for installed gems? A nice Cocoa
    > app perhaps ;)


    As a side note, the latest RubyGems code moves the gem_server functionality
    into the gem command, accessed via gem server. So in the future providing
    this only on the server version of OS X wouldn't make sense as it will just
    be part of the gem command and likely, by that point, RubyGems will be
    bundled with Ruby itself..

    marcel
    --
    Marcel Molina Jr. <>
    Marcel Molina Jr., Oct 26, 2007
    #5
  6. Laurent Sansonetti

    Rob Sanheim Guest

    On 10/25/07, Laurent Sansonetti <> wrote:
    > Hi,
    >
    > Leopard, Mac OS X 10.5, will very soon be available to everyone!
    >
    > Many of you have been wondering about the changes that will impact the
    > Ruby environment. We preventively compiled a list of all changes, and
    > you can now access it from here:
    >
    > http://ruby.macosforge.org
    > http://trac.macosforge.org/projects/ruby/wiki/WhatsNewInLeopard
    >
    > As you can see we also just created a new Ruby project on MacOSForge,
    > with the aim of providing more information regarding the usage of Ruby
    > on the Mac in the future.
    >
    > Enjoy!
    >
    > Laurent


    Looks good, except I didn't see anything about how to upgrade ruby or
    ruby gems..will it be as easy as the doing 'sudo port upgrade ruby' ?

    - Rob

    http://robsanheim.com
    http://thinkrelevance.com
    Rob Sanheim, Oct 26, 2007
    #6
  7. Laurent Sansonetti

    John Joyce Guest

    On Oct 25, 2007, at 9:42 PM, Rob Sanheim wrote:

    > On 10/25/07, Laurent Sansonetti <> wrote:
    >> Hi,
    >>
    >> Leopard, Mac OS X 10.5, will very soon be available to everyone!
    >>
    >> Many of you have been wondering about the changes that will impact
    >> the
    >> Ruby environment. We preventively compiled a list of all changes, and
    >> you can now access it from here:
    >>
    >> http://ruby.macosforge.org
    >> http://trac.macosforge.org/projects/ruby/wiki/WhatsNewInLeopard
    >>
    >> As you can see we also just created a new Ruby project on MacOSForge,
    >> with the aim of providing more information regarding the usage of
    >> Ruby
    >> on the Mac in the future.
    >>
    >> Enjoy!
    >>
    >> Laurent

    >
    > Looks good, except I didn't see anything about how to upgrade ruby or
    > ruby gems..will it be as easy as the doing 'sudo port upgrade ruby' ?
    >
    > - Rob
    >
    > http://robsanheim.com
    > http://thinkrelevance.com
    >

    Uh, no.
    Not if it isn't installed via Mac Ports (formerly known as Darwin Ports)
    But it is likely that the current (or a future) one-click installer
    will be maintained for custom installs...
    but with a better bundled Ruby, we might see even Apple making use of
    its install. They already occasionally make use of Perl and Python
    bundled with OS X.
    John Joyce, Oct 26, 2007
    #7
  8. On 10/25/07, Marcel Molina Jr. <> wrote:
    > On Fri, Oct 26, 2007 at 06:49:03AM +0900, Tim Pease wrote:
    > > On Oct 25, 2007, at 12:42 PM, Laurent Sansonetti wrote:
    > > >Leopard, Mac OS X 10.5, will very soon be available to everyone!
    > > >
    > > >Many of you have been wondering about the changes that will impact the


    >
    > As a side note, the latest RubyGems code moves the gem_server functionality
    > into the gem command, accessed via gem server. So in the future providing
    > this only on the server version of OS X wouldn't make sense as it will just
    > be part of the gem command and likely, by that point, RubyGems will be
    > bundled with Ruby itself..


    Apple's decision to restrict gem_server to the server version of
    Leopard seems out of tune, considering things like the fact that OSX
    already includes Apache as part of the desktop version of the OS.

    I find myself conflicted about whether to use the Apple packaging of
    Ruby when I eventually upgrade to Leopard or continue to use either
    the macport version or compile from sources. On Ubuntu, I've always
    compiled from source so as to have better control over my development
    environment.

    By the way Marcel, are you working on something like this for RubyConf?
    http://www.boingboing.net/2007/10/24/howto-make-a-killer.html
    --
    Rick DeNatale

    My blog on Ruby
    http://talklikeaduck.denhaven2.com/
    Rick DeNatale, Oct 26, 2007
    #8
  9. On 10/26/07, Marcel Molina Jr. <> wrote:
    > On Fri, Oct 26, 2007 at 06:49:03AM +0900, Tim Pease wrote:
    > > On Oct 25, 2007, at 12:42 PM, Laurent Sansonetti wrote:
    > > >Leopard, Mac OS X 10.5, will very soon be available to everyone!
    > > >
    > > >Many of you have been wondering about the changes that will impact the
    > > >Ruby environment. We preventively compiled a list of all changes, and
    > > >you can now access it from here:
    > > >
    > > >http://ruby.macosforge.org
    > > >http://trac.macosforge.org/projects/ruby/wiki/WhatsNewInLeopard

    > >
    > > The wiki page says that "The gem_server utility is not part of the
    > > client distribution of Leopard. It is only provided in the server."
    > > This seems a very horrible omission -- gem_server is used regularly
    > > to view the RDoc documentation for installed gems. Is there another
    > > mechanism in Leopard to view RDoc for installed gems? A nice Cocoa
    > > app perhaps ;)

    >
    > As a side note, the latest RubyGems code moves the gem_server functionality
    > into the gem command, accessed via gem server. So in the future providing
    > this only on the server version of OS X wouldn't make sense as it will just
    > be part of the gem command and likely, by that point, RubyGems will be
    > bundled with Ruby itself..
    >


    gem_server wasn't packaged in the client because it was decided at the
    beginning that serving gems over the network wasn't intended to be
    done by desktop users, but more server users. If you feel disappointed
    I recommend you to file a bug at http://bugreporter.apple.com, the
    more bugs we receive the more it will look important to the
    management.

    We understand that many people are using gem_server to read RDocs, and
    will be worried by this decision, that's why we put it in the article.
    We however think that starting a web-server just to read RDocs is a
    bit overkill, since you can point Safari to one of the sub-directories
    of /usr/lib/ruby/gems/1.8/doc.

    The fact that gem_server's functionality is moving into the gem
    command in the next gems release is a pretty good idea (like most of
    the other changes also), and we are excited about that.

    Laurent
    Laurent Sansonetti, Oct 26, 2007
    #9
  10. On 10/26/07, Rob Sanheim <> wrote:
    > Looks good, except I didn't see anything about how to upgrade ruby or
    > ruby gems..will it be as easy as the doing 'sudo port upgrade ruby' ?


    Unfortunately no, sorry, but you should still be able to manually
    build Ruby in /usr/local, exactly as in Tiger. Or use MacPorts.

    Laurent
    Laurent Sansonetti, Oct 26, 2007
    #10
  11. Laurent Sansonetti

    ara.t.howard Guest

    On Oct 26, 2007, at 11:12 AM, Laurent Sansonetti wrote:

    > Unfortunately no, sorry, but you should still be able to manually
    > build Ruby in /usr/local, exactly as in Tiger. Or use MacPorts.


    i would humbling suggest that mac not follow the path tread but
    redhat and a billion other oses of scattering installs all over the
    place and not using standard practices for upgrade - it's a sad
    statement that at noaa we do all of our serious package management
    outside of rpms (building everything by hand) and i've been doing the
    same on mac for the same reason: a system that leverages open source
    *without* the ability to follow the rapidly moving pace of the
    packages' development has complete missed one of the main features of
    open source and is, for me and my clients, utterly useless -
    inability to keep up with head or, at least, do that via a package
    manager renders *open* source to be effectively *closed*

    respectfully,

    a @ http://codeforpeople.com/
    --
    share your knowledge. it's a way to achieve immortality.
    h.h. the 14th dalai lama
    ara.t.howard, Oct 26, 2007
    #11
  12. > a system that leverages open source
    > *without* the ability to follow the rapidly moving pace of the
    > packages' development has complete missed one of the main features of
    > open source and is, for me and my clients, utterly useless -
    > inability to keep up with head or, at least, do that via a package
    > manager renders *open* source to be effectively *closed*


    I wouldn't go as far as that, but it definitely does result in
    crippled versions of Ruby. Laurent et al. @ Apple set up a custom
    install so they could get the latest Ruby into the latest OS X. the
    problem is, the whole **idea** of that is off. it's fundamentally
    flawed because you're not really shipping software that goes on a
    platform - you're just shipping the platform. the Ruby schedule is
    totally independent of the OS X schedule and co-ordinating the two in
    **any way at all** is illogical wasted effort.

    what you really need to do is say, some of our users are open source
    power users who want the latest language. what you've set up in
    attempt to give us that is guaranteed to **not** satisfy our needs
    because it assumes that OS X is a product rather than a platform, and
    Ruby is a feature rather than a language. packaging it up for us just
    wastes our time, and causes dismay and confusion among newbies.

    we're going to have to manually update our Ruby installs just like we
    had to last time **anyway**, because Ruby will probably change again
    before OS X does. the "gem server" (not gem_server any more) example
    illustrates exactly that problem, because it's already happened - the
    new gems is in pre-release already.

    you need to make a fundamental distinction between features you
    provide and communities you support.

    </rant>

    --
    Giles Bowkett

    Blog: http://gilesbowkett.blogspot.com
    Portfolio: http://www.gilesgoatboy.org
    Tumblelog: http://giles.tumblr.com/
    Giles Bowkett, Oct 26, 2007
    #12
  13. Laurent Sansonetti

    Tim Pease Guest

    On 10/26/07, Giles Bowkett <> wrote:
    > > a system that leverages open source
    > > *without* the ability to follow the rapidly moving pace of the
    > > packages' development has complete missed one of the main features of
    > > open source and is, for me and my clients, utterly useless -
    > > inability to keep up with head or, at least, do that via a package
    > > manager renders *open* source to be effectively *closed*

    >
    > we're going to have to manually update our Ruby installs just like we
    > had to last time **anyway**, because Ruby will probably change again
    > before OS X does. the "gem server" (not gem_server any more) example
    > illustrates exactly that problem, because it's already happened - the
    > new gems is in pre-release already.
    >


    Hmmm, why not provide the XCode project files so that we can create
    our own Ruby framework. I assume the framework in a user's Library
    folder would supersede the System folder. Just a thought.

    TwP
    Tim Pease, Oct 26, 2007
    #13
  14. Laurent Sansonetti

    John Joyce Guest

    On Oct 26, 2007, at 2:49 PM, Tim Pease wrote:

    > On 10/26/07, Giles Bowkett <> wrote:
    >>> a system that leverages open source
    >>> *without* the ability to follow the rapidly moving pace of the
    >>> packages' development has complete missed one of the main
    >>> features of
    >>> open source and is, for me and my clients, utterly useless -
    >>> inability to keep up with head or, at least, do that via a package
    >>> manager renders *open* source to be effectively *closed*

    >>
    >> we're going to have to manually update our Ruby installs just like we
    >> had to last time **anyway**, because Ruby will probably change again
    >> before OS X does. the "gem server" (not gem_server any more) example
    >> illustrates exactly that problem, because it's already happened - the
    >> new gems is in pre-release already.
    >>

    >
    > Hmmm, why not provide the XCode project files so that we can create
    > our own Ruby framework. I assume the framework in a user's Library
    > folder would supersede the System folder. Just a thought.
    >
    > TwP
    >

    Arguably it should all be part of software management system.
    Though MacPorts should not be the only option.
    It is a bit short sighted in some regards, but we do have to
    acknowledge that as an operating system/platform it needs to have a
    stable & reliable official release to develop around, as well.
    There are indeed both the bleeding edge people and the stable/
    reliable/predictable people. Both camps have valid merits.
    Personally, I was (unrealisticallly) hoping for Ruby 2.0 & Rails 2.0
    all rolled up together in the new OS X...
    John Joyce, Oct 26, 2007
    #14
  15. Laurent Sansonetti

    John Wilger Guest

    Re: Ruby Changes in Leopard

    On Oct 26, 11:33 am, "Giles Bowkett" <> wrote:
    > the Ruby schedule is
    > totally independent of the OS X schedule and co-ordinating the two in
    > **any way at all** is illogical wasted effort.

    <snip>
    > we're going to have to manually update our Ruby installs just like we
    > had to last time **anyway**, because Ruby will probably change again
    > before OS X does. the "gem server" (not gem_server any more) example
    > illustrates exactly that problem, because it's already happened - the
    > new gems is in pre-release already


    In terms of a ruby developer's workstation, I can agree with you. I've
    been running the preview releases for a while now, and installing my
    own build of Ruby in a different directory was one of the first things
    I did.

    However, there is a clear benefit to having some version of Ruby
    installed by default as a system framework given that we can now
    pretty easily use it to provide the guts of native Cocoa applications.
    It's nice to be able to write such an app for general distribution
    without having to worry about whether your end-user has Ruby installed
    correctly (or at all) with the objective C bridge enabled.

    --
    Regards,

    John Wilger
    John Wilger, Oct 27, 2007
    #15
  16. Laurent Sansonetti

    Lee Packham Guest

    Re: Ruby Changes in Leopard

    The thing you're all missing by installing your own build is the
    DTrace functionality included in the build in OSX.

    Also Ruby doesn't change "that" much in 2 years. I don't see what the
    problem is if I am honest.

    On 10/27/07, John Wilger <> wrote:
    > On Oct 26, 11:33 am, "Giles Bowkett" <> wrote:
    > > the Ruby schedule is
    > > totally independent of the OS X schedule and co-ordinating the two in
    > > **any way at all** is illogical wasted effort.

    > <snip>
    > > we're going to have to manually update our Ruby installs just like we
    > > had to last time **anyway**, because Ruby will probably change again
    > > before OS X does. the "gem server" (not gem_server any more) example
    > > illustrates exactly that problem, because it's already happened - the
    > > new gems is in pre-release already

    >
    > In terms of a ruby developer's workstation, I can agree with you. I've
    > been running the preview releases for a while now, and installing my
    > own build of Ruby in a different directory was one of the first things
    > I did.
    >
    > However, there is a clear benefit to having some version of Ruby
    > installed by default as a system framework given that we can now
    > pretty easily use it to provide the guts of native Cocoa applications.
    > It's nice to be able to write such an app for general distribution
    > without having to worry about whether your end-user has Ruby installed
    > correctly (or at all) with the objective C bridge enabled.
    >
    > --
    > Regards,
    >
    > John Wilger
    >
    >
    >
    Lee Packham, Oct 27, 2007
    #16
  17. Laurent Sansonetti

    Rob Sanheim Guest

    Re: Ruby Changes in Leopard

    On 10/27/07, Lee Packham <> wrote:
    > The thing you're all missing by installing your own build is the
    > DTrace functionality included in the build in OSX.
    >
    > Also Ruby doesn't change "that" much in 2 years. I don't see what the
    > problem is if I am honest.
    >


    The problem is for people working with Ruby for paying clients
    everyday. When a security update comes out in two months, and my
    production sites all start using it immediately, Leopard's version of
    Ruby becomes useless to me. I want to run the version that my
    clients are running in production, so I'll end up using macports again
    anyways (assuming the port is kept up to date), or just installing
    from source.

    It seems like Apple could've just preinstalled Ruby via macports,
    giving us integrated goodness _and_ the ability to upgrade for power
    users. I realize macports as its flaws, but I've used it to bootstrap
    3 or 4 machines over the past month with a full Ruby/Rails/mysql/etc
    stack and it just works.

    - Rob
    Rob Sanheim, Oct 27, 2007
    #17
  18. Laurent Sansonetti

    John Joyce Guest

    On Oct 27, 2007, at 11:03 AM, Richard Kilmer wrote:

    > On Oct 26, 2007, at 2:33 PM, Giles Bowkett wrote:
    >
    >> we're going to have to manually update our Ruby installs just like we
    >> had to last time **anyway**, because Ruby will probably change again
    >> before OS X does. the "gem server" (not gem_server any more) example
    >> illustrates exactly that problem, because it's already happened - the
    >> new gems is in pre-release already.

    >
    > I really don't follow this line of reasoning. Rubygems itself is
    > just a Ruby library and that Ruby library can be replaced/overridden.
    >
    > If you look at the load paths that Apple set in leopard:
    >
    > irb
    > >> puts $:

    > /Library/Ruby/Site/1.8
    > /Library/Ruby/Site/1.8/powerpc-darwin9.0
    > /Library/Ruby/Site/1.8/universal-darwin9.0
    > /Library/Ruby/Site
    > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/
    > 1.8
    > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/
    > 1.8/powerpc-darwin9.0
    > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/
    > 1.8/universal-darwin9.0
    > .
    >
    > The site dir normally is parallel to the standard ruby lib dir
    > something like:
    >
    > /usr/local/lib/ruby/1.8
    > /usr/local/lib/ruby/site_ruby/1.8
    >
    > But Laurent moved that on OS X into /Library/Ruby/Site. So, if you
    > install a later rubygems in /Library/Ruby/Site/1.8 then it will
    > override the rubygems that is installed in the OS (and the 'gem'
    > command will use the one you upgraded first)
    >
    > Gems are the same way. If you gem install/update a gem it will go
    > in /Library/Ruby/Gems/1.8 and higher version gems will always be
    > the ones loaded.
    >
    > What Apple did was provide a foundation that THEY can build upon
    > (in the OS) and we can update ourselves. I think that is an
    > awesome balance. They also built a bunch of native gems in that
    > are a PITA to build yourself by hand.
    >
    > Of course if you need within your Mac to always run the latest SVN
    > build of Ruby just download that source and build it and install it
    > wherever you want.
    >
    > Realize they could have totally screwed this up by reordering the
    > above load paths, but Laurent is a smart guy :)
    >
    > Best,
    >
    > Rich
    >
    >


    boy you nailed that one on the head. They did it for them.
    Truth is, anybody seriously doing development in Ruby outside of
    something OS X 10.5-centric will probably need to create their own
    install at some point.

    If you're doing RubyCocoa, it might be good to go with the stock
    install, since it is easily and predictably deployable.

    If you're doing Rails or something to be deployed on a different
    platform, you'll be better with a custom setup.

    It's no big deal. We still have Hivelogic for reminders!
    John Joyce, Oct 27, 2007
    #18
  19. Re: Ruby Changes in Leopard

    On Oct 27, 2007, at 3:21 AM, Lee Packham wrote:

    > Also Ruby doesn't change "that" much in 2 years. I don't see what the
    > problem is if I am honest.


    With a Ruby 1.9.1 release planned for Christmas using an all new
    virtual machine and having an m17n implementation, this might not be
    the best time to make such statements. ;)

    James Edward Gray II
    James Edward Gray II, Oct 27, 2007
    #19
  20. Laurent Sansonetti

    Bil Kleb Guest

    John Joyce wrote:
    >
    > On Oct 27, 2007, at 11:03 AM, Richard Kilmer wrote:
    >>
    >> Realize they could have totally screwed this up by reordering the
    >> above load paths, but Laurent is a smart guy :)


    +1

    (Haven't seen Rich's original show up in comp.lang.ruby yet.)

    Later,
    --
    Bil Kleb
    http://nato-rto-latex.googlecode.com
    Bil Kleb, Oct 27, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Greg Ewing
    Replies:
    0
    Views:
    231
    Greg Ewing
    Apr 23, 2011
  2. C. Lung

    Mac OS X Leopard and Ruby

    C. Lung, Dec 8, 2006, in forum: Ruby
    Replies:
    1
    Views:
    82
    James Edward Gray II
    Dec 8, 2006
  3. Gary Wright

    Mac OS X Leopard Ruby Features

    Gary Wright, Oct 18, 2007, in forum: Ruby
    Replies:
    4
    Views:
    118
    Laurent Sansonetti
    Oct 25, 2007
  4. Tim Becker

    Ruby DTrace (on OSX Leopard)

    Tim Becker, Oct 30, 2007, in forum: Ruby
    Replies:
    1
    Views:
    92
    Tim Becker
    Oct 30, 2007
  5. Mauricio Fernandez
    Replies:
    20
    Views:
    268
    Trans
    Feb 21, 2008
Loading...

Share This Page