OS X Tiger still including ruby 1.6

[Carl Youngblood]

I'm not sure who to talk to about this, but in my correspondence with
some of the Apple developers on the carbon-dev mailing list, I have
discovered that the current beta release of OS X Tiger is still using
Ruby 1.6. We should really remedy this situation.

Carl

---------- Forwarded message ----------
From: David McLeod <[email protected]>
Date: Mon, 1 Nov 2004 11:08:51 -0800
Subject: Re: Follow-up: Creating a window through DL
To: (e-mail address removed)

Make sure you have Ruby 1.8.1 installed on your system. The version
that comes with OS X is really old.

Thanks. I guess that Tiger's Ruby is old too...

 

[dross]

I'm not sure who to talk to about this, but in my correspondence with
some of the Apple developers on the carbon-dev mailing list, I have
discovered that the current beta release of OS X Tiger is still using
Ruby 1.6. We should really remedy this situation.

Carl

---------- Forwarded message ----------
From: David McLeod <[email protected]>
Date: Mon, 1 Nov 2004 11:08:51 -0800
Subject: Re: Follow-up: Creating a window through DL
To: (e-mail address removed)




Thanks. I guess that Tiger's Ruby is old too...

Ouch, I hope they fix the problem with having a old version. Really its
the first disappointment I've seen from MacOSX.

David Ross

 

[Phil Tomson]

I'm not sure who to talk to about this, but in my correspondence with
some of the Apple developers on the carbon-dev mailing list, I have
discovered that the current beta release of OS X Tiger is still using
Ruby 1.6. We should really remedy this situation.

Tiger still having 1.6 would be really bad. When are they looking to
release the Tiger? Seems I heard something about February 2005. There
_should_ be enough time to get it changed before then.

Phil

 

[Carl Youngblood]

The question is, who do we talk to to change it?

Tiger still having 1.6 would be really bad. When are they looking to
release the Tiger? Seems I heard something about February 2005. There
_should_ be enough time to get it changed before then.

Phil

 

[Phil Tomson]

The question is, who do we talk to to change it?

Has anyone out there ruby-talk-land signed up for the Tiger developer
package? I would think that Apple would have some method for feedback
from developers who are using Tiger now.


Phil

 

[Michael DeHaan]

I wonder what we could do to get Apple to throw in some extra bells
and whistles by default, say working SDL, Cocoa, Tk (the shiny one
from the Aqua Port?), and OpenGL bindings? I'm building out of
darwinports now, and I really should just be using straight source.
Anyhow, the Ruby "market" would take off like crazy if they put in
some good bindings by default and made them work -- it's kind of
clunky to get a GUI off the ground as it is (save for darwinports,
which is not good for distribution).

Look at what RedHat has done for Python acceptance...

If you know the right people at Apple to talk to about this, maybe we
can get Ruby a leg up.

--MPD

 

[Mike Clark]

I expect Apple will track the latest Ruby version available during
their Tiger code freeze.

As for bells and whistles, the best way I know to get work prioritized
for the teams at Apple is to file a "new feature" request:

https://bugreport.apple.com/

I've heard Apple developers plead for new ideas to be reported this way
as it's one of the only ways to ensure that they get time scheduled to
work on those features.

Mike

I wonder what we could do to get Apple to throw in some extra bells
and whistles by default, say working SDL, Cocoa, Tk (the shiny one
from the Aqua Port?), and OpenGL bindings? I'm building out of
darwinports now, and I really should just be using straight source.
Anyhow, the Ruby "market" would take off like crazy if they put in
some good bindings by default and made them work -- it's kind of
clunky to get a GUI off the ground as it is (save for darwinports,
which is not good for distribution).

Look at what RedHat has done for Python acceptance...

If you know the right people at Apple to talk to about this, maybe we
can get Ruby a leg up.

--MPD

Mike

 

[Ollivier Robert]

I'm not sure who to talk to about this, but in my correspondence with some
of the Apple developers on the carbon-dev mailing list, I have discovered
that the current beta release of OS X Tiger is still using Ruby 1.6. We
should really remedy this situation.

My contact at Apple and the people I know who have tried the
developers' version given out at WWDC said to be that it is 1.8.1 in the
current builds.

1.8.2 would be better (even preview2) but they have been in a feature
freeze for a few months now.

 

[Eivind Eklund]

I wonder what we could do to get Apple to throw in some extra bells
and whistles by default, say working SDL, Cocoa, Tk (the shiny one
from the Aqua Port?), and OpenGL bindings? I'm building out of
darwinports now, and I really should just be using straight source.
Anyhow, the Ruby "market" would take off like crazy if they put in
some good bindings by default and made them work -- it's kind of
clunky to get a GUI off the ground as it is (save for darwinports,
which is not good for distribution).

Look at what RedHat has done for Python acceptance...

If you know the right people at Apple to talk to about this, maybe we
can get Ruby a leg up.

I think I know who to talk to (their release engineer). However, I
think we should have exact information about the current status and
some idea of what we want to propose before I talk to him; I don't
think me sending him a mail with "Some Ruby people thing you should
include some more Ruby stuff in your releases. And by the way, what
do you have now?" would do much good.

Eivind.

 

[David Ross]

* rpa and/or rubygems installed by default.

This would be a bad for anyone to do. When you include a library into
the base, it is diifucult giving out version changes unless you wish to
override and break other programs. If the api changes, etc. One good
exampe of this is SOAP4r, I've been using it for the past 6 months, and
I have to override the base installation becuase it is in the base
already. NaHi just can't simply throw it in stable-snapshot and people
download the version. It has to most likely be with releases for the
sake of compatibility and stability.

Neither packaging systems should be included at this time. rpa-base
actually upgrades itself, but has no function to upgrade the system to
tell the new software is installed. Like on most BSDs the software is
taken off at uninstall by a series of checks and deletes. If there is a
new version downloaded, the md5 sum of the file will be wrong and much
will go wrong.


David Ross

 

[Michael DeHaan]

"When you include a library into
the base, it is diifucult giving out version changes unless you wish to
override and break other programs."

I disagree here. CPAN.pm has been working seamlessly for many years.
It's even self upgradeable. You can even update modules in the base
distribution. This stuff just has to be designed in.

 

[David Ross]

"When you include a library into
the base, it is diifucult giving out version changes unless you wish to
override and break other programs."

I disagree here. CPAN.pm has been working seamlessly for many years.
It's even self upgradeable. You can even update modules in the base
distribution. This stuff just has to be designed in.

Rpa-base is also self-upgradable, and has a decent package count. Sure,
CPAN on BSD systems has a modified version called BSDPAN which has nice
features. BSDPAN can register modules with the native package system.
Infact, what RPA is attempting to write is a package manager which does
register packages and any upgrades to any of the unix package systems.
Right now I wouldn't include rpa-base in the ruby base because of this
reason. If it were even thought of to be included, it would have to be
after all wanted features and API changes are finished. It can do well
in any unix system so far, and there is a Ruby Windows QA Team which
I've created consisting of 4 people. The QA team is not apart of RPA,
and it most likely won't ever be apart of RPA. Its a seperate project
which will support the Microsoft Windows operating system for Ruby
packages. Talk later, can't stop having fun at work.


David Ross

 

[Mauricio Fernández]

"When you include a library into
the base, it is diifucult giving out version changes unless you wish to
override and break other programs."

I disagree here. CPAN.pm has been working seamlessly for many years.
It's even self upgradeable. You can even update modules in the base
distribution. This stuff just has to be designed in.

Both RubyGems (admittedly not 100% automatically) and rpa-base (from the
very first public release: 0.1.0, i.e. long before I thought of that as
a feature and listed it at http://rpa-base.rubyforge.org) can upgrade
themselves. rpa-base can update modules in the base distribution too, if
you let it take ownership of those files (and overwrite them as needed).
RubyGems can emulate that if you set RUBYOPT or add a
require 'rubygems'
to your software.

That said, it is best not to give up on any of our freedom to change
rpa-base to make it better: consider for instance changes in the internal
installed package lists or metadata storage. In the current development
phase, we absolutely want to be able to modify everything as needed.

RubyGems is nearly 1.0, so it might make sense to include it in OSX.
It would be premature to include rpa-base since, despite being more
featureful, it is subject to harder requirements. Remember it's 0.2.2,
that's more of a statement about where we want to go for 1.0 than
about its current maturity. We don't want to get stuck with possible
mistakes in our fundamentals. Once we're *absolutely* sure they're 100%
sound, rpa-base will become 1.0 quickly.

 

[illocutionist]

I think I know who to talk to (their release engineer). However, I
think we should have exact information about the current status and
some idea of what we want to propose before I talk to him; I don't
think me sending him a mail with "Some Ruby people thing you should
include some more Ruby stuff in your releases. And by the way, what
do you have now?" would do much good.

Eivind.

The shiny Tk working out of the box would be huge. Tk has never worked on
OSX with out considerable (for a newcomer) head-banging.

*Me thinks Apple should replace applescript with Ruby. One can
can imagine the growth explosion from that. Or, would it be a bad thing?*

 

[Michael DeHaan]

"*Me thinks Apple should replace applescript with Ruby. One can
can imagine the growth explosion from that. Or, would it be a bad thing?*"

That was in the back of my mind ... Consider the (revised) bug report
submitted. Do the same yourself and maybe they'll listen to two of
us

Or in Applescript syntax:
"tell language applescript go boom".