[MacRuby-devel] PBI - macirb as a console, debugger, etc.
rich at infoether.com
Tue Oct 28 06:30:49 PDT 2008
Just my $0.02.
In 1.9, and thus MacRuby, RubyGems is enabled differently than in 1.8
and so you don't even have to do:
All gems' lib paths are pushed on the LOAD_PATH at init time and
versioning is still enabled through some magic constant_missing/
method_missing stuff in gems itself. If you ARE going to ship a gem
with MacRuby though, don't do it from github because the name of the
gem is prefaced with the user's account. So if I had a gem named foo,
the gem would be:
Or whatever. On RubyForge the gems can be named naturally...like
Anyway, the benefit I see with gems is they can be incrementally
updated between OS updates. This could be a GOOD THING. If we had
several of our macruby libraries as gems then we could provide updates
to them often...then when the OS updates the latest gem could be
included there. That could be interesting from an incremental update
If control of the libraries and tying them to OS updates is valued,
however, then gems may not a good idea.
On Oct 28, 2008, at 8:41 AM, Antonin Hildebrand wrote:
> Hi guys,
> It seems I'm alone in opinion on packaging console as a gem right
> now :-/
> In my opinion MacRuby should be Ruby1.9 with original stdlib shape.
> Nothing more.
> The only difference should be ObjC runtime + changes forced by this
> Other useful library additions should be preinstalled macgems,
> including HotCocoa as a gem.
> Rich, I'm also promoting including them. I'm just talking about
> including them in different place of MacRuby release, not in stdlib.
> Jordan said:
>> It's very MacRuby-specific, what we're talking about here, and not
>> really a generic gem.
> Sounds to me, that you are promoting that MacRuby specific things
> shouldn't be gems.
> Gems is a generic system for ruby libraries. No mater how specific
> they are to specific technologies.
> Copying bunch of things into stdlib is a dirty old-fashioned way Matz
> was doing with ruby when no rubygems ever existed :-)
> Rich said:
>> The fewer hoops a newbie has to jump through, the better chance
>> that s/he won't get Tired
> For a newbie the difference is just in two lines on top of the
> (generated) file:
> instead of:
> require 'console'
> there will be:
> require 'rubygems'
> require 'console'
> If she knows nothing about gems, then she probably knows nothing about
> stdlib location. So she takes it as a magic.
> Laurent, I have a proposal for you:
> I will create console project as a gem published on github (maybe
> this weekend).
> And you may freely take what you find useful and include it in
> MacRuby releases.
> I want to show that 'gemization' of a ruby library is a piece of cake
> with github.
> Anybody then can take it, innovate and republish. And switching is
> just a mater of running macgem command.
> On Tue, Oct 28, 2008 at 5:43 AM, Rich Morin <rdm at cfcl.com> wrote:
>> FWIW, I'd like to see the console (and any other generally-useful
>> tools) included in the MacRuby release. The fewer hoops a newbie
>> has to jump through, the better chance that s/he won't get Tired
>> of the Whole Thing and bail out.
>> In the meanwhile, I've taken an initial swipe at creating a HowTo
>> for getting and using Antonin's Console project:
>> After typing "2 + 2" into the irb session, I kinda ran out of
>> steam, but I will try to get back to it RSN. In the meanwhile,
>> feel free to contribute and/or correct...
>> http://www.cfcl.com/rdm Rich Morin
>> http://www.cfcl.com/rdm/resume rdm at cfcl.com
>> http://www.cfcl.com/rdm/weblog +1 650-873-7841
>> Technical editing and writing, programming, and web development
>> MacRuby-devel mailing list
>> MacRuby-devel at lists.macosforge.org
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
More information about the MacRuby-devel