Re: [Pyobjc-dev] Newbie: Can't get TableModel to work

[Peter M. <zig...@po...>]

On Wednesday, November 13, 2002, at 02:27 AM, bb...@ma... wrote:

> It struck me that if you were to turn off the 'copy only when 
> installing' flag on the build phase that copies the pyobjc module 
> [you'll likely need to adjust the filesystem reference as it is 
> hardwired to a pyobjc module installed against Apple's build of 
> python], the resulting builds will 'just work' regardless of which 
> interpreter is used (as long as the interpreter remains compatible 
> with the build of python on the dynamic loading front).

Yeah, I was wondering about that too. Probably because I don't usually 
use the concept of install builds.


>
> Not the best of solutions, really, given the fragility of playing 'mix 
> and match' with interpreters and modules.
>
> I'm thinking that the bootstrap executable should first check to see 
> if there is a pyobjc directory in Resources and, if not, derive the 
> library path from the python binary that will be used and subsequently 
> figure out if the pyobjc module is installed in that interpreter's 
> environment.
>
> The first test is very inexpensive;  I'm going to throw it in 
> regardless-- if the pyobjc directory isn't available, the bootstrap 
> executable can assume that it is in a developer mode and can dump a 
> quick summary of the interpreter that will be used.
>
> The second test is more expensive and generally only applicable in a 
> developer type environment.  I'm not sure if it is worth going there 
> or not -- maybe only if a particular flag is available?   It's too bad 
> that the bootstrap binary can't fork() instead of using execve(), but 
> doing so causes problems with mach ports and the applications 
> integration into the rest of OS X [at least, it used to, I haven't 
> checked].

Unless it is *really* expensive I wouldn't worry about it. I've done 
some quick benchmarking (read: putting in lots of print statements) and 
the amount of time spent in the bootstrap executable is really 
negligible compared to the dynamic loading of the frameworks a bit 
latter on.


> As always -- just a bunch of hacks to workaround the lack of an 
> embeddable Python shipping with OS X.   Even if Apple doesn't move to 
> 2.3 in the near future, I hope they at least fix the current build!
>
> b.bum
>
> On Monday, November 11, 2002, at 04:01 AM, Just van Rossum wrote:
>> Ronald Oussoren wrote:
>>
>>> You might want to try TableModel2, this contains the same code but 
>>> now
>>> part of a ProjectBuilder project. This project does work with python
>>> 2.2.
>>
>> I actually did, the app builds fine, but when I launch it it 
>> immediately quits,
>> no trace of any error in the Console, no crash, nothing. Hm, I just 
>> tried again
>> with Python 2.2 instead of CVS, and it works! Hey, that's great!
>>
>> I guess I'll rebuild my FrameWork install and see how far I get with 
>> running the
>> examples with that.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing 
> your web site with SSL, click here to get a FREE TRIAL of a Thawte 
> Server Certificate: http://www.gothawte.com/rd522.html
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>