Re: [Pyobjc-dev] Embedding in Apps & Loading preferences Bundles
Brought to you by:
ronaldoussoren
From: <bb...@ma...> - 2002-11-26 03:16:22
|
On Monday, November 25, 2002, at 08:56 PM, Peter Montagner wrote: > On Tuesday, November 26, 2002, at 01:24 AM, Ronald Oussoren wrote: >> On Monday, Nov 25, 2002, at 14:37 Europe/Amsterdam, bb...@ma... >> wrote: >>> Key challenge: The classes that are subsequently subclassed by the >>> loaded module must have instance variables that look/feel/act >>> exactly like the iVars in the original parent class.... >> That should be no problem, PyObjC can already to that. For me the key >> challenge is finding a way to initialize an embedded python >> interpreter and run a python script when the plugin bundle is loaded >> (and for bonus points: Initialize exactly 1 interpreter, even when >> loading more than 1 python-based plugin) > Will this work with Apple's python? Or are you planning on shipping a > full python distro with the plugin? Otherwise it'd be a nice hack but > it wouldn't be distributable. It would only work with a distribution of python that has an embeddable library.... i.e. not the Apple build. >>>> Finding a way to automaticly execute a function when 'our' shared >>>> library is loaded will probably the most problematic part of this. >>>> That is: Whenever the 'pyobjcextension' shared libary is loaded >>>> 'initPyObjCExtension' in that library should run. I haven't looked >>>> into this yet and this may well be either trivial or impossible. >>> Assuming that the target application is ObjC, simply creating a >>> +(void)load in a class/category within the dylib should be enough to >>> cause a hunk of code to be executing that can call >>> -initPyObjCExtension. There is also a similar mechanism in the >>> pure C++ world. >> I hadn't though of using a (dummy) class to do this. Thanks for the >> tip. > There are problems with +(void)load. Namely, you can't guarantee the > order of +(void)load methods, so you can't rely on any other classes. > Well, certainly not those in the same bundle. This doesn't sound like > a problem in this case but it is something to be wary of. Not really a problem; in any given hunk o' dynamically loadable code, provide a single +load or ensure that your initialization code is only executed once. Alternatively, the code invoked as a part of the static initializer (which +load really is) should *only* initialize the class in question, never touching anything else. If the initialization code *must* be executed at a point in time when the rest of the framework has been loaded/initialized, then one can typically use something like NSNotificationCenter to cause a notif to be sent (exact mechanism varies according to environment). [In all my experience as a developer, I find it surprising the number of times folks have been tripped up by the undefined order of execution inflicted upon really early initialization code... The NS 3.3 and OS 4.2 AppKit's both suffered from really nasty bugs if you touched classes in the wrong order, thereby causing +initialize to b executed in an "unexpected" order, very bad things would happen. I'm surprised at the number of times I have tripped over this and I should *really* know better by now! In any case, unless explicitly defined... don't assume anything prior to main() or at dyna-load time.] b.bum |