Re: PyObjC, CamelBones, etc. (WAS Re: Rosetta : Prevernece Panels vs. ScreenSavers?)
Re: PyObjC, CamelBones, etc. (WAS Re: Rosetta : Prevernece Panels vs. ScreenSavers?)
- Subject: Re: PyObjC, CamelBones, etc. (WAS Re: Rosetta : Prevernece Panels vs. ScreenSavers?)
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 7 Jun 2005 14:04:30 -0700
On Jun 7, 2005, at 1:31 PM, Daniel DeCovnick wrote:
Geez... and people wonder why I think this is really a bad thing. I
imagine RubyCocoa will suffer the same fate, actually probably
anything that bridges to ObjC at anything but the highest levels
will. :( To say nothing of the retooling that the non-Apple (non-
Omni, maybe) networking frameworks are going to need. Oh, and,
interestingly, class-dump can't read the new fat... er...
Universal... binaries. No fun there either.
This whole thing really isn't that big of a deal and it certainly
isn't the end of the world. class-dump has done MAB/Unversal/FAT
binaries before, it is just a matter of restoring that functionality
as the underlying file format has been present in Darwin for quite a
long time.
As for PyObjC, RubyCocoa, CamelBones, and the other bridges, the
bridge code only needs to be done once and it is just a matter of
figuring out the ABI. I'm sure that information is either available
now or will be soon. More likely than note, one of the already
supported ABIs for Intel will "just work" (at least, in the case of
FFI -- I don't know what the other bridges are using).
Given that there will be a significant, though unspecified, window of
time between now and when Apple ships systems with Intel chips inside
to customers, there is plenty of time to address these kinds of
problems. Considering that none of the development community has
an Intel based system in their hands right now anyway, this situation
is currently a complete non-issue.
In the early days, PyObjC supported 4 architectures; i386, m68k,
sparc, and hppa. So did the Tcl/Obj-C bridge.
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden