Re: [Pyobjc-dev] Python rather than ObjC for main?
Brought to you by:
ronaldoussoren
From: Peter M. <zig...@po...> - 2002-11-07 05:48:57
|
On Thursday, November 7, 2002, at 07:13 AM, bb...@ma... wrote: > On Wednesday, November 6, 2002, at 09:23 AM, Peter Montagner wrote: >> Is there any reason why the executable pointed to by >> CFBundleExecutable has to be a Mach-O file? > > Not in and of itself... but it fixes a separate problem with the > lightest possible solution I could come up with (faster than launching > Python interpreter). OK, it was just an experiment to see if we could avoid C code in the app completely. Of course if you are shipping a couple of MBs of pyobjc in the Resources folder, it's a moot point. Is there anything that can be done to reduce that code size? I'm thinking of register.m ... > (This really isn't a bug in NSBundle -- more of a lacking feature. > There needs to be a way to tell NSBundle that yes, in fact, you really > want to point the main bundle HERE and not THERE before it > initializes. An enhancement request has been filed at > bugreport.apple.com.) I'd say it *is* a bug. Anything after NSApplicationMain() should use the launch arguments passed to it rather than trying to get the arguments itself. Otherwise, what is the point of that function having those arguments? Is there a way of physically changing argv[0] from the C side of the bridge to the correct value? That couldn't break anything any more than passing the wrong argv[0] when it execve()'s. As you say though, it probably isn't worth it. It would be cleaner if we could avoid that execve() but I guess env just does a similar exec() anyway. > A symlink to the python interpreter could be included in the app > wrapper, but that would be extremely fragile for all but the Apple > provided interpreter. The call to execve() doesn't add *that* much > overhead to the startup process and the current main() and Main.py can > do things like automatically loading frameworks based on what is > linked into the executable (as well as a handful of other features). Unless everyone symlinks /usr/bin/python to their real interpreter but I guess that really isn't worth it. The current approach is much more flexible. > I'm going to clean up everything, including the project template, in > preparation for a 0.8.0 release. Take what we have now and release > it so people don't stumble on 0.6.x any longer... Want to have it > out by end of this weekend. Good idea. I've been playing with PyObjC since last year and have been looking for a new version frequently. I thought the project was dead. It was only when I decided to look at the mailing list that I realised how far it's come. There *really* needs to be a new version released. Peter |