🌐 Mailman 3 January 1996 - Pythonmac-SIG - python.org

What are people doing with MacPython
by powers＠petroglyph.com Jan. 31, 1996

Jan. 31, 1996

Evaluating it :) More to the point, evaluating whether to move ahead with extending the Mac version or the Windows version for use in CD-ROM products. About a year and a half ago I extended Python on an SGI with objects for full screen video playback, sega game controller events, and multiple bitmap animation layers. We then used it for a Pilot of an animated Interactive TV channel for kids. Some of this work can be seen on my web site (at least the visuals) under the tag of the company, daVinci Time and Space [http://www.petroglyph.com]. Earlier I worked on the ill-fated but forward thinking ScriptX from Kaleida Labs. In fact, I just received version 1.5 which they nudged out the door before being sucked back into Apple. Someone at Kaleida should have made an early decision to use Python instead. Now I am moving into the development of PC pased entertainment products. This means extending the language to include the game sdks on Mac or Windows 95. Does anyone have experience on both systems with Python?? Jack, your multimedia work sounds interesting? Can you say more? Michael Petroglyph 940 Scott St Palo Alto, CA 94301 www.petroglyph.com "Incarnation: bodying forth. Is this not our whole concern? The bodying forth of our sense of life? Is this not a sense fully as actual as our sense of touch...That is what form is: the bodying forth. The bodying forth of the living vessel in the shapes of clay." M.C. Richards ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org =================

2 1

Re: [PYTHONMAC-SIG] Some ideas for Mac Python
by Jack Jansen Jan. 30, 1996

Jan. 30, 1996

This is going to be a long reply to a long message (especially since it tackles almost all of the issues in the charter:-). Maybe we should split the discussion into multiple parts? Non-C-hackers: please bear with me, there's some design issues in here as well that I would welcome discussion on. Recently, Guido van Rossum <guido(a)CNRI.Reston.VA.US> said: > Here are some areas where I think MacPython can use some improvement. > > 1) CFM-68K support. This is shared libraries, PPC style, for the > 68K. Guido: the miniPythonCFM68K project in the source tree appeared to work under CW7.5 (with the exception of the math module), so that would probably be a good starting point. Others: if anyone is interested in looking into cfm68k: drop me a note and I'll put the project up for ftp. > 2) GUSI support. Yes, this would definitely be nice, especially since it would probably make the MacTk integration quite a bit easier. The #include <GUSI.h> isn't a problem: put it in the prefix file (mwerks_whatever_config.h). If you (or anyone else) is going to look into it: make sure you check that os.stat() still works as expected afterwards. I had problems with GUSI stat(). > 3) Tk. Definitely! One serious problem with Tk, though, is that it expects malloc to succeed. Always. There is no code whatsoever that checks return values, so tkpython programs running out of memory will have extremely rude things done to them (along the lines of "nobody expects the spanish inquisition":-). > 4) Configure some Mac specific hacks dynamically (at run-time) instead > of through #ifdefs. Yes. I've already created a Python library (similar to PythonCore but as a static library) that I used in my first experimentations with Netscape extensions. Hmm, speaking of that: is anyone willing to take over the work on a python-interpreter netscape extension? > a) Program argument processing. This is fairly simple to fix, by moving the init_mac_stuff() routine to another place and using a different main program that doesn't call the argc/argv emulation routine. There's a related problem, though: the Py_Exit() call in core-python is better split in two: Py_JustBeforeExit() and Py_Exit(). In some cases (such as a netscape extension) you want to do all of the exit processing *except* exiting. > b) Event checking. There is some code that normally checks for > Command-period (turning it into a KeyboardInterrupt exception) > but which can be disabled; it can optionally also check for > other events, passing them to SIOUX (the CodeWarrior stdio > window) or stdwin or elsewhere. I think this should probably be > done in such a way that even in order to enable Command-period > checking the main program would have to register some kind of > callback (even though the callback function could be part of the > standard library). (Of course this interface should still be > accessible from Python code, so Framework.py can take care of > its own needs.) Hmm, not sure I like this one. The callback function is a good idea, I think, but only for programs that know about it. It think that the default behaviour should be as it currently is: if the python program doesn't make any "funny" calls (like the misnamed MacOS.EnableAppswitch, which disables all python's event processing) it should work as it currently does. The issue is, however, tied to the next one. > c) Standard I/O window. I would like to make it possible that an > embedding app can completely disable to console window > (essentially all writes to the C level stdout/stderr would yield > write errors (or be ignored?) and all reads from stdin would > raise EOFError). The app can them use some Python code that > substitutes something else for sys.stdout etc. so that it is > redirected to a window that it manages for itself. This would > be useful for Tk, for instance (Tk dies when you click in the > SIOUX window, but it would be easy to connect the console to a > Tk text widget). Definitely agreed. Here's an idea: - Someone writes a console output window driver (in C). This is something that has an interface similar to the SIOUX low-level interface (writecharstoconsole(), readcharsfromconsole(), etc) but does not ever ever ever look at the event queue itself. CW7 SIOUX was advertised as doing this, but messed some things up (cut/paste handling). Also, the names should, unfortunately, be different so we can't use sioux. Finally, since the driver should never ever read an event the should be a callback (to call from readcharsfromconsole()) which is called until enough events have been passed to handleoneevent() to satisfy the outstanding request. - We create a builtin module that allows access to the functionality of the above. - We write routines writecharstoconsole(), etc. that will call the appropriate python methods of a 'sioux object'. The initial sioux object will, of course, be the thing created previously, so when you start a normal python interpreter everything behaves as it does now. However, there's also an interface that allows a python program (or a C program, if python is embedded in another application) to divert all sioux I/O to your own object. You could even implement your own object using a sioux object (or multiple sioux objects if the implementation in the first step allows it, which would be a big benefit for someone implementing a python IDE). - We redo the event loop (which is used by default, and entered once every umpteen python machine instructions, or when we're waiting for user input) to allow modules (such as the sioux module, or framework, or stdwin) to subscribe to the event loop. When there's an event available everyone subscribed gets a chance to look at it, with the return specifying whether the event has been handled or not. The sioux module will subscribe (if it is active), and also two other modules, one that handles command-dot and one that handle "the outside world", clicks in the desktop, that sort of thing. There's one potential problem: the menu bar. One possibility would be to do a generalized menu interface, but a better (albeit slightly clumsier) one would be to have the event loop peek at the current top window and install the correct menu. This will have the advantage of working better when embedding python. Of course, you can still turn off the event loop and handle all events by yourself, possibly passing events to this code with MacOS.HandleEvent. So what does all this buy us? The main thing is that, given a scriptable external editor, a minimal IDE is now simple. Create a Python program that sets up a few menus and starts the interpreter inside a try/except clause. Upon an exception you point the editor at the offending line with an appleevent. Similarly, if you get a "run script" appleevent you open a window and run the script. Thinking of the rest of the possibilities is left as an exercise to the reader:-) > 5) Preferences. Still not as smooth as could be. I guess that the > run-time options that can currently only be set by hitting Option > while Python is being launched should also be taken care of by a > preferences panel. Definitely, the defaults for the option-launch options should be settable from EditPythonPrefs. Actually, I'm still undecided about the EditPythonPrefs program. Initially the implementation of setting the preference file was completely in C in the interpreter, but I felt that that was a bit silly, so I removed it and created EditPythonPrefs. What do people think: is a separate preference-setting program a good idea or should the code move back into the interpreter? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org =================

1 0

Some ideas for Mac Python
by Guido van Rossum Jan. 30, 1996

Jan. 30, 1996

Here are some areas where I think MacPython can use some improvement. 1) CFM-68K support. This is shared libraries, PPC style, for the 68K. I just received CodeWarrior 8 which (again) claims improved CFM-68K support. Perhaps it will work this time? It would be really great to be able to use Python applets on the 68K Mac (yes, I've still got one -- I had to pay for it myself, see :-) It would also be really useful to be able to e.g. import stdio, Tk or the Mac toolkit modules ("bgen" stuff) dynamically. 2) GUSI support. This is the Grand Unified Socket Interface, a third-party partial replacement for the standard C library that lets you use select() and socket() C function. This shouldn't be hard -- in fact I've already built an experimental version of it that does exactly this. (Too bad it requires "#include "GUSI.h" everywhere.) 3) Tk. OK, I'm supposed to be working on this, but I got sidetracked and decided to wait for the promised 4.1a3 release. Actually, some of the following ideas were inspired by my attempts to get Tk working by embedding Python in Tk instead of vice versa :-) 4) Configure some Mac specific hacks dynamically (at run-time) instead of through #ifdefs. This will make embedding easier. I'm thinking of three things in particular: a) Program argument processing. I believe this is currently in a file that also contains some other stuff that's always needed; but when I'm embedding Python in another app, the arguments will be passed in totally different. b) Event checking. There is some code that normally checks for Command-period (turning it into a KeyboardInterrupt exception) but which can be disabled; it can optionally also check for other events, passing them to SIOUX (the CodeWarrior stdio window) or stdwin or elsewhere. I think this should probably be done in such a way that even in order to enable Command-period checking the main program would have to register some kind of callback (even though the callback function could be part of the standard library). (Of course this interface should still be accessible from Python code, so Framework.py can take care of its own needs.) c) Standard I/O window. I would like to make it possible that an embedding app can completely disable to console window (essentially all writes to the C level stdout/stderr would yield write errors (or be ignored?) and all reads from stdin would raise EOFError). The app can them use some Python code that substitutes something else for sys.stdout etc. so that it is redirected to a window that it manages for itself. This would be useful for Tk, for instance (Tk dies when you click in the SIOUX window, but it would be easy to connect the console to a Tk text widget). Also, the default action when the program exits should be controllable by the embedding app. (Note that I see the "stand-alone" Python interpreter as just another app that embeds Python...) 5) Preferences. Still not as smooth as could be. I guess that the run-time options that can currently only be set by hitting Option while Python is being launched should also be taken care of by a preferences panel. --Guido van Rossum <guido(a)CNRI.Reston.VA.US> URL: <http://www.python.org/~guido/> ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org =================

1 0

What are people doing with Mac Python?
by guzdial＠cc.gatech.edu Jan. 30, 1996

Jan. 30, 1996

I'm curious what people are doing with Mac Python. I've been using it for two projects: (1) To analyze log files (recordings of UI events) for experiments, and (2) To create databases of pedagogical knowledge (about Smalltalk) for use in generating HTML pages. We're considering using Python for a project where we'd actually be more Mac-ish: Running QuickTime movies and sending AppleEvents, as the back-end of a multimedia sort-of-intelligent-tutor. Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org =================

2 1

Using temporary memory for python
by Jack Jansen Jan. 30, 1996

Jan. 30, 1996

Well, now that the pythonmac SIG has been created let's start it off with a question. Does anyone have any experiences with using temporary memory? Currently, python (using its own malloc()) allocates memory from the application heap, but it is possible to allocate so-called "temporary memory", which lives on the system heap. The advantage of using this for Python would be that the 'SIZE' of Python application heap could be a lot smaller, and that python can allocate as much memory as is available in the system currently. Moreover, it wouldn't use the memory if it didn't actually need it. However, before I implement this (it seems not to be too difficult) I'd like of any drawbacks... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org =================

1 0

None
by Guido van Rossum Jan. 29, 1996

Jan. 29, 1996

subscribe guido(a)python.org -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org =================

1 0