Thread: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5
Brought to you by:
ronaldoussoren
From: Just v. R. <ju...@le...> - 2002-11-22 20:45:58
|
Look, the patch below shows _exactly_ why I don't like the execve wrapper to written in anything but Python. I can't even tell (but then again, I'm lazy) whether this prepends or sets or appends PYTHONPATH. (Ronald, please don't take this as an insult, the code is just fine, I'm just trying to make a further argument for the Python version...) I will apply a similar patch to the execve wrapper, but I need to do different things in different situations: When building an applet: - append PYTHONPATH (not prepend as that kindof defeats its purpose) When building a fully standalone app: - set PYTHONHOME to something inside the bundle, just to make sure no modules can be loaded from anywhere but the bundle - set or replace PYTHONPATH. A bogus PYTHONPATH could otherwise break the app. With the Python version this is trivial to do. For main.c this would add yet another 20 or so lines of terse C code. Just Ronald Oussoren wrote (on the checkins list): > Update of /cvsroot/pyobjc/pyobjc/Examples/TableModel2 > In directory sc8-pr-cvs1:/tmp/cvs-serv9080 > > Modified Files: > main.m > Log Message: > Set PYTHONPATH in main.m > > Index: main.m > =================================================================== > RCS file: /cvsroot/pyobjc/pyobjc/Examples/TableModel2/main.m,v > retrieving revision 1.4 > retrieving revision 1.5 > diff -C2 -d -r1.4 -r1.5 > *** main.m 18 Oct 2002 19:08:57 -0000 1.4 > --- main.m 22 Nov 2002 20:26:12 -0000 1.5 > *************** > *** 22,25 **** > --- 22,56 ---- > NSMutableArray *bundlePaths = [[NSMutableArray array] retain]; > int i; > + int envc; > + char** childEnvp; > + char* PYTHONPATH = NULL; > + > + for (envc = 0; envp[envc] != NULL; envc++) { > + if (strncmp(envp[envc], "PYTHONPATH=", sizeof("PYTHONPATH=")-1) == 0) { > + PYTHONPATH=envp[envc] + sizeof("PYTHONPATH=") - 1; > + /* No break, we also want to know how large envp is */ > + } > + } > + > + childEnvp = alloca(sizeof(char*) * (envc + 2)); > + for (envc = 0; envp[envc] != NULL; envc ++) { > + if (strncmp(envp[envc], "PYTHONPATH=", sizeof("PYTHONPATH=")-1) == 0) { > + const char* s = [[[NSBundle mainBundle] resourcePath] UTF8String]; > + childEnvp[envc] = alloca(strlen(envp[envc]) + strlen(s) + 2); > + sprintf(childEnvp[envc], "%s:%s", envp[envc], s); > + > + } else { > + childEnvp[envc] = envp[i]; > + } > + } > + if (PYTHONPATH) { > + envp[envc] = NULL; > + } else { > + const char* s = [[[NSBundle mainBundle] resourcePath] UTF8String]; > + childEnvp[envc] = alloca(sizeof("PYTHONPATH=") + strlen(s)); > + sprintf(childEnvp[envc], "PYTHONPATH=%s", s); > + childEnvp[envc+1] = NULL; > + } > + > > while ( aBundle = [bundleEnumerator nextObject] ) { > *************** > *** 56,60 **** > childArgv[i+3] = NULL; > > ! return execve(pythonBinPathPtr, (char **)childArgv, envp); > } > > --- 87,93 ---- > childArgv[i+3] = NULL; > > ! i = execve(pythonBinPathPtr, (char **)childArgv, (char**) childEnvp); > ! if (i == -1) perror("execv"); > ! return 1; > } |
From: Ronald O. <ous...@ci...> - 2002-11-22 21:07:04
|
On Friday, Nov 22, 2002, at 21:45 Europe/Amsterdam, Just van Rossum wrote: > Look, the patch below shows _exactly_ why I don't like the execve > wrapper to > written in anything but Python. I can't even tell (but then again, I'm > lazy) > whether this prepends or sets or appends PYTHONPATH. (Ronald, please > don't take > this as an insult, the code is just fine, I'm just trying to make a > further > argument for the Python version...) No insult was taken. This appends to PYTHONPATH, doing it the other way around is probably better. I'll check-in a patch latter tonight. BTW. There is no need to convince me about using Python instead of C :-) > > I will apply a similar patch to the execve wrapper, but I need to do > different > things in different situations: > > When building an applet: > - append PYTHONPATH (not prepend as that kindof defeats its purpose) > > When building a fully standalone app: > - set PYTHONHOME to something inside the bundle, just to make sure > no modules can be loaded from anywhere but the bundle > - set or replace PYTHONPATH. A bogus PYTHONPATH could otherwise > break the app. Sounds good, but how are you going to deal with moving the .app bundle when not using /usr/bin/python? '#!../Resources/python-interpreter' probably won't work. Standalone apps are probably the most important for not using a python-based main. Ronald |
From: Just v. R. <ju...@le...> - 2002-11-22 21:52:37
|
Ronald Oussoren wrote: > BTW. There is no need to convince me about using Python instead of C :-) Oh, in my mind I was actually talking to Bill ;-) > > When building an applet: > > - append PYTHONPATH (not prepend as that kindof defeats its purpose) > > > > When building a fully standalone app: > > - set PYTHONHOME to something inside the bundle, just to make sure > > no modules can be loaded from anywhere but the bundle > > - set or replace PYTHONPATH. A bogus PYTHONPATH could otherwise > > break the app. > Sounds good, but how are you going to deal with moving the .app bundle > when not using /usr/bin/python? '#!../Resources/python-interpreter' > probably won't work. Standalone apps are probably the most important > for not using a python-based main. It works by the assumption that there is _a_ python available as /usr/bin/env python. This is safe as of Jaguar, unless someone has actually deleted python. Tough luck for those. The _real_ (python) executable is copied to Contents/Resources/ and the bootstrapping code calculates its path just like it calculates the path to the real main script. It passes this path to os.execve. The bundle can be moved anywhere. Just |
From: <bb...@ma...> - 2002-11-22 22:06:48
|
On Friday, November 22, 2002, at 04:52 PM, Just van Rossum wrote: > Ronald Oussoren wrote: >> BTW. There is no need to convince me about using Python instead of C >> :-) > Oh, in my mind I was actually talking to Bill ;-) Oh -- no need to do that -- I'm a firm believer in doing everything in Python whenever possible. Just that no one has shown me that want I want to do in the main.m IS possible in Python.... b.bum |
From: Just v. R. <ju...@le...> - 2002-11-22 22:28:23
|
bb...@ma... wrote: > Just that no one has shown me that want I want to do in the main.m IS > possible in Python.... But neither have you shown why it's all that _important_ to be able do these things in main.m (apart from nicer PB integration)... But let's not go there again ;-) Just |
From: <bb...@ma...> - 2002-11-22 22:37:32
|
I guess my long winded message was too long winded. In short, PyObjC in the context of first-class development tool in conjunction with Apple's supplied IDE & APIs requires full support for frameworks; encapsulated within the app, modified by the DYLD environment variables, and working correctly within the Project Builder environment. (Support for indexed docs within PBX is a nice bonus, but I can live without it) b.bum On Friday, November 22, 2002, at 05:27 PM, Just van Rossum wrote: >> Just that no one has shown me that want I want to do in the main.m IS >> possible in Python.... > > But neither have you shown why it's all that _important_ to be able do > these > things in main.m (apart from nicer PB integration)... But let's not go > there > again ;-) |
From: Just v. R. <ju...@le...> - 2002-11-22 23:17:53
|
bb...@ma... wrote: > I guess my long winded message was too long winded. In short, PyObjC > in the context of first-class development tool in conjunction with > Apple's supplied IDE & APIs requires full support for frameworks; > encapsulated within the app, modified by the DYLD environment > variables, and working correctly within the Project Builder environment. But you haven't answered our (Jack and me) question how that is even relevant if you wipe the process away with execve()? Or did you, and I missed it? Sorry if that's the case, but I still don't understand a word of what you're saying... Just |
From: <bb...@ma...> - 2002-11-22 23:24:05
|
On Friday, November 22, 2002, at 06:08 PM, Just van Rossum wrote: > But you haven't answered our (Jack and me) question how that is even > relevant if > you wipe the process away with execve()? Or did you, and I missed it? > Sorry if > that's the case, but I still don't understand a word of what you're > saying... I did and you missed it. :-) It is in that long winded message that I posted a few days ago... b.bum |
From: Jack J. <Jac...@or...> - 2002-11-22 22:49:17
|
On vrijdag, nov 22, 2002, at 22:05 Europe/Amsterdam, Ronald Oussoren wrote: > Sounds good, but how are you going to deal with moving the .app bundle > when not using /usr/bin/python? '#!../Resources/python-interpreter' > probably won't work. Don't even bother trying it: I did, and it doesn't:-) What we would need is a standard unix tool that we can give 1 argument and that would execute a mangled version of argv[0]. I don't think such a tool exists:-) -- - Jack Jansen <Jac...@or...> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - |
From: Just v. R. <ju...@le...> - 2002-11-22 23:10:57
|
Jack Jansen wrote: > On vrijdag, nov 22, 2002, at 22:05 Europe/Amsterdam, Ronald Oussoren > wrote: > > Sounds good, but how are you going to deal with moving the .app bundle > > when not using /usr/bin/python? '#!../Resources/python-interpreter' > > probably won't work. > > Don't even bother trying it: I did, and it doesn't:-) > > What we would need is a standard unix tool that we can give 1 argument > and that would execute a mangled version of argv[0]. I don't think such > a tool exists:-) What are you guys on about? The execve wrapper is run as #!/usr/bin/env python (which will usually be /usr/bin/python) and the rest is taken from there. Am I missing something? Just |
From: Ronald O. <ous...@ci...> - 2002-11-23 06:10:11
|
On Saturday, Nov 23, 2002, at 00:10 Europe/Amsterdam, Just van Rossum wrote: > Jack Jansen wrote: > >> On vrijdag, nov 22, 2002, at 22:05 Europe/Amsterdam, Ronald Oussoren >> wrote: >>> Sounds good, but how are you going to deal with moving the .app >>> bundle >>> when not using /usr/bin/python? '#!../Resources/python-interpreter' >>> probably won't work. >> >> Don't even bother trying it: I did, and it doesn't:-) >> >> What we would need is a standard unix tool that we can give 1 argument >> and that would execute a mangled version of argv[0]. I don't think >> such >> a tool exists:-) > > What are you guys on about? The execve wrapper is run as > #!/usr/bin/env python > (which will usually be /usr/bin/python) and the rest is taken from > there. Am I > missing something? MacOSX 10.1 isn't shipped with a python interpreter. Not that this should keep us from using a python-based main by default. Ronald |
From: Ronald O. <ous...@ci...> - 2002-11-23 06:08:34
|
On Friday, Nov 22, 2002, at 23:49 Europe/Amsterdam, Jack Jansen wrote: > > On vrijdag, nov 22, 2002, at 22:05 Europe/Amsterdam, Ronald Oussoren > wrote: >> Sounds good, but how are you going to deal with moving the .app >> bundle when not using /usr/bin/python? >> '#!../Resources/python-interpreter' probably won't work. > > Don't even bother trying it: I did, and it doesn't:-) > > What we would need is a standard unix tool that we can give 1 argument > and that would execute a mangled version of argv[0]. I don't think > such a tool exists:-) sh? #!/bin/bash res=$(dirname $(dirname ${0}))/Resources main=${res}/main.py export PYTHONPATH PYTHONPATH=$res exec /usr/local/bin/python ${main} # end of file The above code is completely untested and doesn't like whitespace in argv[0]. Ronald > -- > - Jack Jansen <Jac...@or...> > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > > |
From: Jack J. <Jac...@or...> - 2002-11-23 12:56:27
|
On zaterdag, nov 23, 2002, at 07:07 Europe/Amsterdam, Ronald Oussoren wrote: >> What we would need is a standard unix tool that we can give 1 >> argument and that would execute a mangled version of argv[0]. I don't >> think such a tool exists:-) > > sh? Hmm, there is something to be said for that too, as it'll work pre-jaguar too. So now we have three stubs: one in Python, one in ObjC, one in sh (although I would use /bin/sh, bash wasn't available on 10.1), and each one has a specific advantage. How about using the Python stub as the default, but make it easy to use the other stubs, and in the documentation explain about that? [Incidentally, what I was originally really after was a #! line that would immediately execute the *correct* python, so we wouldn't need the execve(). This, I think, is impossible in the general case. But the execve() doesn't seem to be such a big deal anyway on current hardware]. -- - Jack Jansen <Jac...@or...> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - |
From: Just v. R. <ju...@le...> - 2002-11-23 13:48:34
|
Jack Jansen wrote: > Hmm, there is something to be said for that too, as it'll work > pre-jaguar too. So now we have three stubs: one in Python, one in ObjC, > one in sh (although I would use /bin/sh, bash wasn't available on > 10.1), and each one has a specific advantage. Go right ahead, but I don't care one single bit for 10.1, so I think it's a waste of time (although it would probably be faster to do it with /usr/bin/sh. We're targeting developers mostly, and by the time Python 2.3 and a new PyObjC get decent exposure, supporting 10.1 will be even less of an issue. But: I'm about to embarge on a major refactoring of bundlebuilder.py: I'll try to make it possible to use different templates. Speaking of bundlebuilder and plistlib: I saw that Ronald checked them in into the pyobjc project, which made me wonder whether repository symlinks are possible across sf projects. Shall I just open a support request and ask? Just |
From: Jack J. <Jac...@or...> - 2002-11-23 17:34:43
|
On zaterdag, nov 23, 2002, at 14:47 Europe/Amsterdam, Just van Rossum wrote: > Speaking of bundlebuilder and plistlib: I saw that Ronald checked them > in into > the pyobjc project, which made me wonder whether repository symlinks > are > possible across sf projects. Shall I just open a support request and > ask? I think it would be a major can of worms. I think I would designate one as the main copy, and use "cvs import" in the other tree. -- - Jack Jansen <Jac...@or...> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - |
From: Ronald O. <ous...@ci...> - 2002-11-25 08:07:50
|
On Saturday, Nov 23, 2002, at 18:34 Europe/Amsterdam, Jack Jansen wrote: > > On zaterdag, nov 23, 2002, at 14:47 Europe/Amsterdam, Just van Rossum > wrote: >> Speaking of bundlebuilder and plistlib: I saw that Ronald checked >> them in into >> the pyobjc project, which made me wonder whether repository symlinks >> are >> possible across sf projects. Shall I just open a support request and >> ask? > > I think it would be a major can of worms. I think I would designate > one as the main copy, and use "cvs import" in the other tree. I completely forgot about 'cvs import'. The version in the Python tree should be leading and it was my intention to copy that once in a while. Ronald |
From: Jack J. <Jac...@or...> - 2002-11-23 17:36:14
|
On zaterdag, nov 23, 2002, at 14:47 Europe/Amsterdam, Just van Rossum wrote: > Go right ahead, but I don't care one single bit for 10.1, so I think > it's a > waste of time (although it would probably be faster to do it with > /usr/bin/sh. Forgot to reply to this bit. What makes 10.1.5 interesting is that it's the last release that runs on 603 and 604 hardware, 10.2 is G3/G4-only. And I haven't seen any numbers yet on how many people are sticking with 10.1 because of the price of the upgrade... -- - Jack Jansen <Jac...@or...> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - |
From: Just v. R. <ju...@le...> - 2002-11-23 18:52:22
|
Jack Jansen wrote: > On zaterdag, nov 23, 2002, at 14:47 Europe/Amsterdam, Just van Rossum > wrote: > > Go right ahead, but I don't care one single bit for 10.1, so I > > think it's a waste of time (although it would probably be faster to > > do it with /usr/bin/sh. > > Forgot to reply to this bit. What makes 10.1.5 interesting is that it's > the last release that runs on 603 and 604 hardware, 10.2 is G3/G4-only. The only person I know that runs 10.1.5 for that reason (on an old 8500) uses it as a headless server. The only app on that machine that matters is Apache... I don't think this an interesting platform for (standalone) Python/PyObjC GUI apps at *all*. > And I haven't seen any numbers yet on how many people are sticking with > 10.1 because of the price of the upgrade... On the other hand: Python is free ;-) I'm not suggesting we should always demand the latest version (not at all) but I'm all for taking full advantage of the fact that 10.2 ships with Python. I'm convinced it will save us a lot of time. > > Speaking of bundlebuilder and plistlib: I saw that Ronald checked > > them in into the pyobjc project, which made me wonder whether > > repository symlinks are possible across sf projects. Shall I just > > open a support request and ask? > > I think it would be a major can of worms. I think I would designate > one as the main copy, and use "cvs import" in the other tree. And manually update everytime the main copy has been upgraded? I'm not looking forward to do _two_ checkins for each change to each of these files. Why would it be a can of worms? I maintain those modules, and it's my excplicit goal to stay compatible with Python 2.2. Just |
From: Just v. R. <ju...@le...> - 2002-11-26 13:29:49
|
Ok, ok, I take it all back about requiring Jaguar just so we can use /usr/bin/python for bootstrapping... This was Ronald's suggestion from a while back: > sh? > > #!/bin/bash > > res=$(dirname $(dirname ${0}))/Resources > main=${res}/main.py > export PYTHONPATH > PYTHONPATH=$res > > exec /usr/local/bin/python ${main} > # end of file I've actually managed to make it sortof work (hey, I've never written a shell script before! ;-). But I'm running into a problem: the runtime can't find the path for the main nib: Traceback (most recent call last): File "/Users/just/code/pyobjc/Examples/TableModel/build/TableModel.app/Contents/ Resources/TableModel.py", line 19, in ? NibClassBuilder.extractClasses("MainMenu") File "/usr/lib/python2.2/site-packages/AppKit/NibClassBuilder.py", line 128, in extractClasses self._extractClassesFromNibFromBundle(nibName, bundle) File "/usr/lib/python2.2/site-packages/AppKit/NibClassBuilder.py", line 144, in _extractClassesFromNibFromBundle raise NibLoaderError, ("Could not find nib named '%s' " AppKit.NibClassBuilder.NibLoaderError: Could not find nib named 'MainMenu' in bundle 'NSBundle </usr/bin> (I assume that if NibClassLoader.py wasn't used here, it would exit with a similar message from NSApplicationMain().) I'm not sure, but I _think_ it's because 'exec' in /bin/sh isn't exactly the same as execve(). Does this sound plausible? If so, what _is_ the equivalent of execve() in sh? Also: the exporting of PYTHONPATH doesn't work as written above: os.environ doesn't show it. Any clues? (googling for "execve" and "sh" only gives me hits for execve("/bin/sh", ...); ;-) Just |
From: <bb...@ma...> - 2002-11-26 16:32:53
|
On Tuesday, November 26, 2002, at 08:29 AM, Just van Rossum wrote: > I'm not sure, but I _think_ it's because 'exec' in /bin/sh isn't > exactly the > same as execve(). Does this sound plausible? If so, what _is_ the > equivalent of > execve() in sh? Also: the exporting of PYTHONPATH doesn't work as > written above: > os.environ doesn't show it. > > Any clues? (googling for "execve" and "sh" only gives me hits for > execve("/bin/sh", ...); ;-) In the child process, argv[0] -- the name of the process -- must contain the path to the app wrapper or else the resources within can't be found. If you were to 'print NSBundle.mainBundle().bundlePath()', you would find that it points to /usr/local/bin/. This is a limitation of CFBundle/NSBundle -- there is no other way to tell it which directory should be used as the mainBundle. Basically, Apple needs to move the automatic initialization of the main bundle such that the developer can set the path prior to initialization. Python solves a similar problem through the Py_SetProcessName() function. In any case, I don't know if there is an analogy for execve() in shell speak... b.bum |
From: Jack J. <Jac...@or...> - 2002-11-26 23:44:07
|
On dinsdag, nov 26, 2002, at 15:23 Europe/Amsterdam, bb...@ma... wrote: >> Any clues? (googling for "execve" and "sh" only gives me hits for >> execve("/bin/sh", ...); ;-) > > In the child process, argv[0] -- the name of the process -- must > contain the path to the app wrapper or else the resources within can't > be found. If you were to 'print NSBundle.mainBundle().bundlePath()', > you would find that it points to /usr/local/bin/. We could use my trick of a couple of weeks ago: put a symlink to python into the Contents/MacOS directory and use that symlink, I think. (with all the caveats of not being able to switch to another python after creating the applet). -- - Jack Jansen <Jac...@or...> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - |
From: Just v. R. <ju...@le...> - 2002-11-27 15:06:51
|
Jack Jansen wrote: > We could use my trick of a couple of weeks ago: put a symlink to python > into the Contents/MacOS directory and use that symlink, I think. (with > all the caveats of not being able to switch to another python after > creating the applet). That would be ok for applets but is useless for standalone apps. Looks like I'll have to stick with bootstrapping in Python... Just |
From: Ronald O. <ous...@ci...> - 2002-11-27 15:40:44
|
Why would it be useless for standalone apps? I suppose standalone apps have a python interpreter stuffed inside the resources directory. You can then create a relative symlink to this interpreter (e.g. cd MyApp.app/Contents/MacOS && ln -s ../Resources/python .) Ronald On Wednesday, Nov 27, 2002, at 16:06 Europe/Amsterdam, Just van Rossum wrote: > Jack Jansen wrote: > >> We could use my trick of a couple of weeks ago: put a symlink to >> python >> into the Contents/MacOS directory and use that symlink, I think. (with >> all the caveats of not being able to switch to another python after >> creating the applet). > > That would be ok for applets but is useless for standalone apps. Looks > like I'll > have to stick with bootstrapping in Python... > > Just > > > ------------------------------------------------------- > This SF.net email is sponsored by: Get the new Palm Tungsten T > handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en > _______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev > |
From: Just v. R. <ju...@le...> - 2002-11-27 16:08:06
|
Ronald Oussoren wrote: > Why would it be useless for standalone apps? I suppose standalone apps > have a python interpreter stuffed inside the resources directory. They do. > You > can then create a relative symlink to this interpreter (e.g. cd > MyApp.app/Contents/MacOS && ln -s ../Resources/python .) Hm, yes, I suppose. I just found another trick, though: I can put the python executable in Contents/MacOS and directly execute it from there: it works!! Btw: I'm still not able to pass PYTHONPATH to the process started with exec. This doesn't seem to work: export $PYTHONPATH PYTHONPATH=$res Any thoughts? Just |
From: Ronald O. <ous...@ci...> - 2002-11-27 16:27:31
|
On Wednesday, Nov 27, 2002, at 17:07 Europe/Amsterdam, Just van Rossum wrote: > > Btw: I'm still not able to pass PYTHONPATH to the process started with > exec. > This doesn't seem to work: > > export $PYTHONPATH export PYTHONPATH (without the $) Ronald |