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

[Ronald O. <ous...@ci...>]

On Thursday, Nov 7, 2002, at 16:40 Europe/Amsterdam, bb...@ma... wrote:

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

register.m is an alternative to dynamicly building function invocations 
at runtime. For normal method calls we use NSInvocation for that, but 
that class cannot be used for calls to the superclass implementation of 
a method. That is calls using 'objc_msgSendSuper' instead of 
'objc_msgSend'.

The file also contains a lot of stub functions that can be used as 
method implementations in the dispatch table of an Objective-C class. 
These are required if you want to override the implementation of a 
method in a Python-based subclass.

If we'd use libffi (homepage is on sources.redhat.com, the latest 
version is in the GCC CVS tree, license is BSD-like) this file could be 
replaced by a much shorter file. I've more or less writting a function 
to dynamicly generate the method IMPs, but ran into a problem: I cannot 
get libffi to build into object files that can be made part of a shared 
library.

The file register.m could also be made smaller by creating slightly 
smarter functions in their that can detect how many arguments they 
should have and then ignore any arguments they think to have beyond the 
actual amount of arguments. This would allow us to use 1 function for
	(int)aMeth:(int)arg withArg:someId andArg:(char*)foo
and
	(int)aMeth:(int)arg
and
	(int)doIt

I'd prefer to wait with either change until after the upcoming release.

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

As Bill noted Cocoa seems to fetch the value of argv[0] from somewhere 
else. It is not even fetched from the argv vector (e.g. argv[0] = "foo" 
wouldn't be usable). I guess it is fetched directly from the 
datastructure passed in by execv(), which is only the source from which 
the argv vector is build.

IIRC a couple of months ago someone on the MacPython list suggested how 
to deal with this using some undocumented function calls.
>
> 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.

Please stuff it into CVS as-is, we can discus it afterwards.

Even without seeing the site I'd like to say: Thanks a lot Jim.

Ronald