Re: [Pyobjc-dev] Python rather than ObjC for main?

[<bb...@ma...>]

On Thursday, November 7, 2002, at 12:48 AM, Peter Montagner wrote:
> 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 
> ...

I was wondering the same.   In particular, the size of the pyobjc-- 
specifically, mostly in _objc.so-- module jumped from 550k to 3.5MB 
recently.   I believe it is because Ronald regenerated the register.m 
file to contain a more complete set of potential selectors?  Not sure.

In any case, Yes-- register.m needs to be addressed.  There should be a 
way using a third party library or some other mechanism to effectively 
eliminate the need for each individual function.   Ronald knows a heck 
of a lot more about this than I do.

>> (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?

A lot of Foundation/CFBundle applications (and a number of AppKit 
applications) never use NSApplicationMain().  As well, one could easily 
implement something like:

int main(...) {
     ... release pool ...
     [[NSBundle mainBundle] ...];
}

Which would cause the mainBundle to come into existence almost 
immediately upon program execution.  It can also boil down to a 
chicken-and-egg problem;  we need NSBundle like API to be able to find 
things in the app wrapper to initialize the interpreter, but we can't 
touch the API without causing mainBundle to be created.

In effect, we need a call that can be made to NSBundle or, likely, 
CFBundle (as that API doesn't have the auto initialization behavior of 
ObjC classes) that sets the main bundle path as basically the very 
first thing to happen upon entry into the application.   This would 
have to be built into the PyObjC project as a separate module from the 
ones we have now;  a module whose sole purpose is to control this 
particular parameter.

> 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.

All of this is just a bunch of hacks to work around the fact that Apple 
doesn't ship the libraries necessary to embed their build of python 
into applications.   A bug has been filed regarding that via 
bugreport.apple.com, but it always helps if others file the same bug-- 
gives Apple an idea of how many developers are interested in the 
problem-- so, if you haven't done so, please go file an enhancement 
request at bugreport.apple.com asking that Apple please ship a complete 
python distribution that (a) includes a linkable library for embedding 
and (b) includes the full set of unit tests that normally ship with 
python.

>> 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.

The alternative would be for the app to symlink to the real interpreter 
directly within the app wrapper upon installation, but that pretty much 
kills the drag-n-drop style of installation -- unacceptable as far as 
I'm concerned.

In general, I shy away from symlinks for problems like this because 
they tend to break in the most unlikely of contexts...

>> 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.

Yes.   There will be very soon.  I'll do a cut on Sunday evening, 
regardless of what state everything is in [as long as it continues to 
work as well as it does right now-- which is really, really well].

Jim Tittsler was kind enough to send a brand spanking new web site to 
me.  Includes a make environment, FAQ, documentation, examples, and 
everything else... and a really cool dog/snake icon.   I have asked him 
to forward along a discussion of it to the list so that we can review 
it before it gets shoved into CVS.

It has a couple of advantages over what was recently discussed-- 
namely, it exists, it works right now, it is really simple, and it can 
be configured to automatically regenerate the site on sourceforge's 
server as we push out new releases.

Very, very cool -- a HUGE thank you to Jim for doing this as it is 
definitely going to take the project to the next level!

b.bum


b.bum
....lying there snoring,
	breath smelling like a 1948 buick.


b.bum
No Chunks...
	... No Foul!