🌐 Mailman 3 December 2001 - Pythonmac-SIG - python.org

Re: [Pythonmac-SIG] Mach-O MacPython IDE!!!
by Jack Jansen Dec. 21, 2001

Dec. 21, 2001

Recently, Jack Jansen <jack(a)oratrix.nl> said: > > Recently, Donovan Preston <dp(a)ulaluma.com> said: > > I suppose the problems with slash delimited paths could therefore be > > solved by changing the FSSpec_New code to first create an FSRef and then > > convert it to an FSSpec. Sorry, in my previous mail I went off on a tangent. What I should have said in answer to this suggestion is: "Good idea! Let's do it!". So, here's the current design: - FSSpec expected: if arg-is-fsspec: fine elif arg-is-3-tuple: turn-into-fsspec elif arg-is-string and (arg2 == 'mac' or (arg2==None and MacPython)): Turn from : separated path into fsspec else: try to turn into FSref if it isn't one turn FSRef into fsspec - FSRef expected: if arg-is-fsref: fine #ifdef MACHO_PYTHON elif arg-is-string and (arg2 == 'unix' or arg2==None): Turn into FSref from / separated path #endif else: Try to turn into FSSpec if it isn't one turn fsspec into fsref. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] Mach-O MacPython IDE!!!
by Jack Jansen Dec. 21, 2001

Dec. 21, 2001

Recently, Donovan Preston <dp(a)ulaluma.com> said: > Hmm. Well, I suppose the only way to get around this is to explicitly > state which type of path is being used as Jack suggested, or to always > assume slash-delimited paths on X and colon-delimited paths on 9. I assume you mean "MacPython" where you say 9 and "MachoPython" where you say X, right? Pathname interpretation is more a function of the runtime library than of the OS, in the case of Python. > Since os.path.join creates slash-delimited strings on X, all of the > places in the IDE where there is code that looks like > os.path.join(rootdir, 'my:subdir:etc') are going to have to be replaced > anyway. I suggest replacing them with os.path.join(*[rootdir, 'my', > 'subdir', 'etc']) which works no matter what OS you are running under. Or, alternatively, use macpath. Os.path is great to get rid of platform dependencies, but only if you add single components. If you're using my:subdir:etc you have a Mac dependency anyway, so there's little to be gained from using os.path. While the *[rootdir, 'my', 'subdir'] construct is really really nifty (applause!) methinks it's almost obfuscated enough to make it into Perl:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs
by Martin Miller Dec. 21, 2001

Dec. 21, 2001

On Thu, 20 Dec 2001 15:27:48 Donovan Preston wrote: > >On Thursday, December 20, 2001, at 12:59 PM, Jack Jansen wrote: > > > > Recently, Donovan Preston <dp(a)ulaluma.com> said: > > [ discussion of loading code in CFM/PEF libraries from MachoPython ] > > > This isn't worth it. We discussed it about a year ago (both here and > > on the GUSI list) and by getting the BSD sockets you would also get > > (unless you do major surgery) all the rest of glibc, so you would get > > Unix filenames, Sioux would go down the drain, etc. > > I think there's a bit of confusion as to why one would still want to > load code from a CFM library EVEN on MachoPython. Of course, if a Mach-O > library is available it should be used. However, there will be occasions > where a Mach-O library will not be available. > > Probably the most obvious example would be closed-source VST plugins. If > the plugin author even bothers to relink the plugin with Carbon, it will > most definitely be as a CFM library, not a Mach-O library. Thus the > necessity of loading and running code in a CFM library from a Mach-O > binary. > > It sounds like Jeff Harmon is also in a similar situation where he > already has a bunch of CFM libraries that he doesn't want to have to > recompile as Mach-O to get working with MachoPython. As I was saying, it > is technically possible and has been discussed on the Carbon-dev mailing > list. > > Just thought I'd try to clear things up a little bit. > > p.s. MachoPython -- heh heh. Village people references aside, It'll do > as a temporary name until CFM MacPython on OS X dies a horrible death. > > Donovan (Sorry about the subject line, but I hesitate to change it now.) Hi, my name is Martin and I work with Jeff at Adobe. I would like to try clarify the situation we are in. Donovan is right on target with his comments above with respect to how we would like to use Python on the Mac. I cannot be specific, but essentially we have a body of CFM libraries, which must stay in that format, that we would like to access as Python extensions on OS X (from both single and multi-processor equipped systems). Being unable to do this could force us to abandon the use of Python altogether for this particular use and project -- which would make a number of us, shall we say, unhappy. Unfortunately, we just don't have the resources needed available to try fix it ourselves at this point. Donovan wrote: > ...until CFM MacPython on OS X dies a horrible death. This especially concerns me because it sounds like the problem will never be solved, even if we could wait a while for the GUSI multi-tasking problem be worked out. Guess there really is "no such thing as a free lunch." ;-) Best regards, Martin

1 0

Mach-O MacPython IDE!!!
by Donovan Preston Dec. 21, 2001

Dec. 21, 2001

Well, since I noticed Jack had gotten the WASTE module compiling and linking under command-line Mach-O Python in the CVS, I decided to take another stab at getting the IDE up and running as a Mach-O bundle. After downloading WASTE, putting it in the right place (as mentioned in the comment in setup.py in CVS) and running ranlib on the libWASTE.a file, I was able to get the WASTE module to compile and link. So far so good. Then, I dropped PythonIDEMain.py on the Python.app. Error on MacOS.EnableAppSwitch. No problem, just comment it out. I was able to get as far as macresource.need before having tough problems. It turns out that while os.path.join and the like create '/asdf/zxcv/wqr' slash delimited strings, the code that converts a python string into a C FSRef (? or FSSpec?) needs ':' delimited strings. Or the Carbon library itself needs colon delimited strings. I didn't look into it too much except to determine that slash delimited path strings were the problem. Anyway, I wrote an awful hack in macresource.py that converts any slash delimited paths to colon delimited and allows the IDE to get up and running!!! There are caveats, however. I had to comment out quite a few more MacOS.EnableAppSwitch calls as well as the call that installs the Console and Output windows in the IDE. But I only worked on it for about an hour, and already, I can create new python files, execute them (output goes to the Console application), use the module browser, see nice traceback windows, and bring up a post-mortem debugger! Awesome. Screenshots are available at http://www.ulaluma.com/pyx/ Just, here's the ugly, ugly hack to macresource.py that got me going down the path towards things working (Lots more commentings-out were required, however): [localhost:src/Mac/Lib] dsp% cvs diff -c macresource.py Index: macresource.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Lib/macresource.py,v retrieving revision 1.3 diff -c -r1.3 macresource.py *** macresource.py 2001/08/30 21:19:42 1.3 --- macresource.py 2001/12/20 07:02:30 *************** *** 54,67 **** searchdirs = sys.path # And look for the file for dir in searchdirs: ! pathname = os.path.join(dir, filename) if os.path.exists(pathname): break else: ! raise ResourceFileNotFoundError, filename ! refno = Res.FSpOpenResFile(pathname, 1) # And check that the resource exists now if type(resid) is type(1): --- 54,80 ---- searchdirs = sys.path # And look for the file + import string + print "filename:",filename + splt = filename.split(':') + splt = [x for x in splt if x] + fn = string.join(splt, '/') for dir in searchdirs: ! print "yo:", dir, fn ! pathname = os.path.join(dir, fn) if os.path.exists(pathname): + print "exist",pathname break else: ! print pathname ! raise ResourceFileNotFoundError, fn ! print pathname ! foo = pathname.split('/') ! foo[0] = 'MacOSX' # my root hard drive name ! newpth = string.join(foo, ':') ! print newpth ! refno = Res.FSpOpenResFile(newpth, 1) # And check that the resource exists now if type(resid) is type(1):

3 5

Re: [Pythonmac-SIG] Mach-O MacPython IDE!!!
by Jack Jansen Dec. 21, 2001

Dec. 21, 2001

Recently, Donovan Preston <dp(a)ulaluma.com> said: > Ah. I had read some discussion about FSRefs vs FSSpecs on Carbon-dev, > but never had to deal with it so didn't pay much attention; can an FSRef > be used wherever an FSSpec is called for in a Carbon call? Or do you > have to create an FSRef and convert it to an FSSpec? In C you have to do the conversion yourself. In Python you don't: anywhere an FSRef is required you can also pass either an FSSpec or a pathname, and anywhere an FSSpec is required you can also pass an FSRef or a pathname. Lovely language, Python :-) > I suppose the problems with slash delimited paths could therefore be > solved by changing the FSSpec_New code to first create an FSRef and then > convert it to an FSSpec. > > Then the only problem remaining is all of the hardcoded colon delimited > strings littered throughout the MacPython IDE code. They should all be > replaced with calls to os.path.join. That way it works on either 9 or X. How about the following (I think I suggested this before but didn't get any answer): macfs.FSSpec() and macfs.FSRef() get an optional second parameter, which can be either "mac" or "unix". If you pass a string first parameter then the second parameter governs how the pathname is interpreted. Also, fsspec.as_pathname() and fsref.as_pathname() get an optional parameter "mac" or "unix" which give the type of pathname you want. Default is "mac" for MacPython, "unix" for MachoPython. Hmm, we could even add "url" as a third choice, although that's probably feeping creaturism. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs
by Jack Jansen Dec. 20, 2001

Dec. 20, 2001

Recently, Donovan Preston <dp(a)ulaluma.com> said: > OS X already has an implementation of socket-based IO -- it's called > BSD. :-) And OS X already has a Python which will compile to use it -- > command line Python. What OS X Python is missing, therefore, is the IDE > running on top of the command-line Python binary. Stay tuned, hopefully > we'll have it soon. See my message about Mach-O MacPython IDE if you're > interested in knowing more. > > first files, etc.)? An alternative thought I have to work on is "how > hard > will it be to glue the OS X CL interpreter (not MacPython) to PEF a > gaggle > of libs?" It looks doable but I've never traveled this road before. This isn't worth it. We discussed it about a year ago (both here and on the GUSI list) and by getting the BSD sockets you would also get (unless you do major surgery) all the rest of glibc, so you would get Unix filenames, Sioux would go down the drain, etc. And you'd end up with something almost identical to MachoPython, but with a funny (and slower) CFM component. It's better then to do away with MacPython altogether and base something on MachoPython. And that's also what is being worked on, with porting all the modules, etc. (No doubt we'll call it MacPython when it's finished, but for the time being it's better to make a distinction between MacPython (CW-based Python with PythonInterpreter and IDE which runs on 9 and X) and MachoPython (basically unix command line Python with frameworks and Carbon modules and the rough Python.app added)). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 2

Re: [Pythonmac-SIG] Pygame on OS X : Anyone had success?
by Pete Moore Dec. 20, 2001

Dec. 20, 2001

Bob! You don't know how pleased that makes me, I started coding when I was about 11 years old, my interest was in doing graphicsy stuff, weird animations, simple games, etc. and I am looking forward to doing it again (with much more elegance, hopefully, thanks to Python) now I'm 30 something!! I'll be checking the Pygame site for updates, SDL installed nicely as a packaged OS X framework...but after digging around in Distutils, I realised I was out of my depth as far as the issues that need resolving there. Big thanks Pete On Thursday, December 20, 2001, at 10:05 PM, Bob Ippolito wrote: > I'm pretty close to having pygame 1.3 ported to OS X. I have the > latest python 2.2c1, Numeric, SDL and _all_ of its dependencies working > great, and I have pygame compiling (with some trickery), but there are > some OS X specific implementation details that will probably take > another few days because pygame doesn't link with SDLmain > > I'll make an installer available from the pygame.org website when I'm > done, hopefully this week > > (feel free to fwd this to pythonmac-sig, I'm not subscribed there at > the moment) > > -bob >

1 0

Re: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs
by Jack Jansen Dec. 20, 2001

Dec. 20, 2001

Recently, Steven Majewski <sdm7g(a)Virginia.EDU> said: > Jack: > I love your spelling of "mach-o Python" as "MachoPython" ! > I wonder if we can get the Village People to record a theme song > for mach-o MachoPython! :-) > [ But will Guido dress up in Indian feathers or a hardhat for > the video ? ] Any special reason for mentioning the Indian? He's supposedly the only one in the Village People who's really gay:-) > Maybe there's inspiration for a new icon there somewhere. Ah yes, icons! I did a couple of quick-and-dirty icons for MachoPython (they're in the Mac/OSXResources directory), does anyone want to do some decent ones to replace them? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] Mach-O MacPython IDE!!!
by Jack Jansen Dec. 20, 2001

Dec. 20, 2001

Recently, Tony Lownds <tony(a)metanet.com> said: > So, if like me you don't have CodeWarrior, where do you get libWASTE? It's in the standard WASTE distribution. > Here is some more Mac/Unix path wierdness: > > >>> macpath.abspath('') > ':/Users/tlownds/Desktop' Ah, this needs to be fixed. Could you file a bug report? (note that in general using xyzzypath.abspath() on anything but the xyzzy platform is a no-no, but for Mac OS X I think we should try to get macpath and posixpath working for both MachoPython and MacPython). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: Pythonmac-SIG digest, Vol 1 #929 - 12 msgs
by Jeff Harmon Dec. 20, 2001

Dec. 20, 2001

on 12/19/01 09:01 AM, pythonmac-sig-request(a)python.org wrote: > But, just to make sure that you're not seeing a different issue: could you > post the symptoms you see when you try to use MacPython on OSX? Here is a summary of what I've encountered. The machine in question is a dual500 (g4) (with gobs o' RAM and perty much all the fix'ns). It's running a fully current (as of yesterday) 10.1.1 that started from an "consumer boxed" 10. I work for Adobe, btw. I'm sure you've seen a lot of traffic from some of us later since were thinking of adopting Python for some internal use. The jury is still out... I've downloaded both "full" distributions (2.1x and 2.2x), run the installer, got the the "I'll bet the cofg tool will puke" message, watched the config tool puke, quit the installer, launch the config tool directly, watch as the config tool stops dead in its tracks at the point mentioned in a previous email (GUSI fLocked > 0). Failing that I drug my know good MacPython (carbon of course) 211 dist from my 9.1 TiBook to the dual. The interpreter launches (and more or less appears to run) but has bogus (as wrong bad not corrupt) data in sys.path. As a result it can't find anything and bitches when it tries to load, err... import site and macfsn. If I hack sys.path at runtime it seems to work but I still don't know enough about the "world of python" (only been doing this for a week so far) to know if there are other init things that never went off when it bailed after failing to find macfsn. The questions I'm trying to track down at present is where does MacPython acquire the data it writes into sys.path. (what file, etc.), what (specifically) does the config tool do (so I can attempt to replicate it's effect manually) and what does MacPython do at launch (execution sequence, first files, etc.)? An alternative thought I have to work on is "how hard will it be to glue the OS X CL interpreter (not MacPython) to PEF a gaggle of libs?" It looks doable but I've never traveled this road before. Any expertise you can add or light you can shed would be VERY, VERY welcome. Cheers! JR

2 1