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 <dmcleod@apple.com>
Date: Mon, 1 Nov 2004 11:08:51 -0800
Subject: Re: Follow-up: Creating a window through DL
To: carl@youngbloods.org
On Oct 28, 2004, at 6:18 PM, Carl Youngblood wrote:
Make sure you have Ruby 1.8.1 installed on your system. The version
that comes with OS X is really old.
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
From: David McLeod <dmcleod@apple.com>
Date: Mon, 1 Nov 2004 11:08:51 -0800
Subject: Re: Follow-up: Creating a window through DL
To: carl@youngbloods.org
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...
Ouch, I hope they fix the problem with having a old version. Really its the first disappointment I've seen from MacOSX.
David Ross
···
---------- Forwarded message ----------
On Oct 28, 2004, at 6:18 PM, Carl Youngblood wrote:
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.
Are you sure it is 1.6? The source code for darwin 8 (tiger) has been partially released, and it seems to include 1.8.0.
I hope that there is still time to include 1.8.2 when it comes out. Other pieces of tiger seem to get extra features in the newer developer builds, so I don't think code is frozen yet.
In article <e5ed7b69041101112361adf896@mail.gmail.com>,
···
Carl Youngblood <carl.youngblood@gmail.com> wrote:
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.
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.
···
On Tue, 02 Nov 2004 04:23:27 +0900, Carl Youngblood wrote:
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.
On Tue, 2 Nov 2004 05:08:50 +0900, Phil Tomson <ptkwt@aracnet.com> wrote:
In article <e5ed7b69041101112361adf896@mail.gmail.com>,
Carl Youngblood <carl.youngblood@gmail.com> wrote:
>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.
In article <e5ed7b6904110112267a693474@mail.gmail.com>,
···
Carl Youngblood <carl.youngblood@gmail.com> wrote:
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.
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
···
On Tue, 2 Nov 2004 06:38:49 +0900, Phil Tomson <ptkwt@aracnet.com> wrote:
In article <e5ed7b6904110112267a693474@mail.gmail.com>,
Carl Youngblood <carl.youngblood@gmail.com> wrote:
>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.
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
···
On Nov 1, 2004, at 3:17 PM, Michael DeHaan wrote:
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
On Tue, 2 Nov 2004 06:38:49 +0900, Phil Tomson <ptkwt@aracnet.com> > wrote:
In article <e5ed7b6904110112267a693474@mail.gmail.com>,
Carl Youngblood <carl.youngblood@gmail.com> wrote:
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.
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.
···
On Tue, 2 Nov 2004 07:17:04 +0900, Michael DeHaan <michael.dehaan@gmail.com> wrote:
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.
Well what I would like in Tiger:
* a working ftp module on osx (it has been fixed in 1.8.2-preview, maybe backport the fix to 1.8.1)
* ri working by default for the standard library
* rpa and/or rubygems installed by default.
For the release after Tiger, I would like to see the same level of support for ruby+cocoa as there is today for objective-c+cocoa. So a ruby-cocoa project in xcode, integration with interface builder, ruby-documentation in the documenation center, "fix and continue",...
Eivind Eklund <eeklund@gmail.com> wrote in message news:<dc9b20bb041102060459a30f56@mail.gmail.com>...
···
On Tue, 2 Nov 2004 07:17:04 +0900, Michael DeHaan > <michael.dehaan@gmail.com> wrote:
> 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.
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?*
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.
"*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".
···
On Mon, 8 Nov 2004 23:43:55 +0900, illocutionist <gltewalt@yahoo.com> wrote:
Eivind Eklund <eeklund@gmail.com> wrote in message news:<dc9b20bb041102060459a30f56@mail.gmail.com>...
> On Tue, 2 Nov 2004 07:17:04 +0900, Michael DeHaan > > <michael.dehaan@gmail.com> wrote:
> > 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.
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?*
"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.
···
On Tue, 2 Nov 2004 23:59:51 +0900, David Ross <dross@code-exec.net> wrote:
>
> * 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.
"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 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.
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
···
On Tue, 2 Nov 2004 23:59:51 +0900, David Ross <dross@code-exec.net> wrote:
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.
···
On Thu, Nov 04, 2004 at 06:03:06AM +0900, Michael DeHaan wrote:
"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.
