[Rubyinstaller-devel] Mac OS installer

Curt Hibbs curt.hibbs at gmail.com
Tue Oct 18 12:36:09 EDT 2005

I've cc'd this back to the mailing list to keep everyone up to date. I also
cc'd Rich Kilmer because he'd like to see Apple pick this up to be part of
their official distribution, and he has some internal Apple contacts that
could possibly make this a reality.

See the rest of my response below...

On 10/18/05, Mark Hubbart <discordantus at gmail.com> wrote:
> On 10/17/05, Curt Hibbs <curt.hibbs at gmail.com> wrote:
> > Don't update for 1.8.3 -- its got bugs in it. Better to stick with 1.8.2
> .
> Thanks for the tip. I never updated to 1.8.3 myself, and am glad to
> know that I'm not missing anything :) Still, 1.8.3 comes with an
> entirely different build mechanism for the extensions. If core
> continues to use it for future versions, I'll need to be looking into
> it.

Whenever you're ready to release something based on 1.8.2, let's call it a
preview (or something similar), because Matz will be releasing 1.8.4 at the
end of the year and we'll want to make the official release use 1.8.4.

I worked on the project this evening, to see what still needs to be
> done. I discovered that most of the work ahead is just on features. I
> fixed all but one of the bugs that were slowing me down, so as soon as
> I swat this last one, I think I'll be able to do some sort of a
> release.
> This last bug is causing a segmentation fault when rdoc generates
> documentation for installed gems. I'm a bit stymied, but I'll keep
> working on it. C just isn't my thing.
> I need to figure out where I can use help on this project... The
> framework code and copious patches might be a bit daunting to someone
> unfamiliar with ruby internals (it's daunting to me), and once I get
> the framework working bug-free, packaging it should be the easy part.

I didn't realize that you had to patch Ruby. What are the nature of these
patches? Are these things that we should submit back for incorporation into

> Also, as I've said, I haven't worked on many collaborative projects
> before, so I'm unsure of how to work this :/

I don't know James or Patrick's skills, but an example could be to help
track down the seg-fault if they were already up to speed.

They could also serve as alpha tester by downloaded and installing what
you've got now. They might run into problems that are easily addressed now
when you'd only have 2 users instead of after the release when there would
be hundreds.

They could also work on incorporating the extensions that we want to bundle.
I advocate keeping it to a minimum, but some just make sense (like RubyGems
and RubyCocoa).


Anyway, this made me find some time to get some work done on the
> project, so I'll count my blessings :)
> cheers,
> Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rubyinstaller-devel/attachments/20051018/b32d901c/attachment.htm

More information about the Rubyinstaller-devel mailing list