[Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs

[Jack Jansen]

> > > This isn't worth it. We discussed it about a year ago (both here and
> > > on the GUSI list) and by getting the BSD sockets you would also get
> > > (unless you do major surgery) all the rest of glibc, so you would get
> > > Unix filenames, Sioux would go down the drain, etc.
> > 
> > I think there's a bit of confusion as to why one would still want to 
> > load code from a CFM library EVEN on MachoPython. Of course, if a Mach-O 
> > library is available it should be used. However, there will be occasions 
> > where a Mach-O library will not be available.
> > 
> > Probably the most obvious example would be closed-source VST plugins. If 
> > the plugin author even bothers to relink the plugin with Carbon, it will 
> > most definitely be as a CFM library, not a Mach-O library. Thus the 
> > necessity of loading and running code in a CFM library from a Mach-O 
> > binary.

Ok, this is indeed a completely different situation. Depending on the
API the plugin is provided with it could be either easy or impossible
to put Python in between. If the plugin is in complete control it's
easy, the only problem to solve is the CFM-MachO bridge. Although
someone will have to take care to convert pathnames, if any go across
the API. If the plugin API provided by the host application is
sufficiently rich (as an Adobe plugin API I've glanced at happens to be,
IIRC) there's a bit of a problem, but not too much, as you really have
to only build a Python interpreter that refrains from doing its own
I/O calls incorrectly. Linking against a cfm-bridged glibc should go a
long way. If the API is just a couple of start/stop calls plus a long
list of do's and don'ts (like the Netscape plugin API) there is a problem.

> Donovan wrote:
> > ...until CFM MacPython on OS X dies a horrible death.
> 
> This especially concerns me because it sounds like the problem will
> never be solved, even if we could wait a while for the GUSI
> multi-tasking problem be worked out.

I think that's too negative. First, it'll be a while until CFM
MacPython dies (and why something that has served us so well for so
long deserves a "horrible death".... well.... :-). Second, this
problem isn't really Python-related. Every product that has a plugin
architecture with a sufficient marketshare will have to face this
problem when they decide to move the product to Mach-O. And I'm pretty
sure everyone will move to Mach-O at some point...

--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm