From guido@monty.cnri.reston.va.us Fri Jan 26 20:15:59 1996 From: guido@monty.cnri.reston.va.us (Guido van Rossum) Date: Fri, 26 Jan 1996 15:15:59 -0500 Subject: No subject Message-ID: <199601262015.PAA00855@monty> subscribe guido@python.org -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@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@python.org administrivia to: pythonmac-sig-request@python.org ================= From Jack.Jansen@cwi.nl Tue Jan 30 12:48:30 1996 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 30 Jan 1996 13:48:30 +0100 Subject: [PYTHONMAC-SIG] Using temporary memory for python Message-ID: <9601301248.AA04759=jack@schelvis.cwi.nl> 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@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@python.org administrivia to: pythonmac-sig-request@python.org ================= From guzdial@cc.gatech.edu Tue Jan 30 14:31:34 1996 From: guzdial@cc.gatech.edu (Mark Guzdial) Date: Tue, 30 Jan 1996 09:31:34 -0500 (EST) Subject: [PYTHONMAC-SIG] What are people doing with Mac Python? Message-ID: 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@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@python.org administrivia to: pythonmac-sig-request@python.org ================= From Jack.Jansen@cwi.nl Tue Jan 30 23:42:04 1996 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 31 Jan 1996 00:42:04 +0100 Subject: [PYTHONMAC-SIG] What are people doing with Mac Python? In-Reply-To: Message by guzdial@cc.gatech.edu (Mark Guzdial) , Tue, 30 Jan 1996 09:31:34 -0500 (EST) , Message-ID: <9601302342.AA05566=jack@schelvis.cwi.nl> Clearly a lot of my use of Python on the Mac is for Python development, but besides that I'm currently porting CMIFed, an editor/player for multimedia documents developed here at CWI and written in Python. CMIF was more-or-less designed to be platform-independent ("more" if you ask the researchers, "less" if you ask the programmers:-), and so far the task has proved to be fairly simple. Due to the various levels of abstraction in the design it was reasonably simple to replace the X drawing/windowing code and the SGI (or Sun) audio code with their mac equivalents. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@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@python.org administrivia to: pythonmac-sig-request@python.org ================= From guido@CNRI.Reston.VA.US Wed Jan 31 00:17:40 1996 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Tue, 30 Jan 1996 19:17:40 -0500 Subject: [PYTHONMAC-SIG] Some ideas for Mac Python Message-ID: <199601310017.TAA11453@monty> 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 URL: ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From Jack.Jansen@cwi.nl Wed Jan 31 01:36:50 1996 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 31 Jan 1996 02:36:50 +0100 Subject: [PYTHONMAC-SIG] Some ideas for Mac Python In-Reply-To: Message by Guido van Rossum , Tue, 30 Jan 1996 19:17:40 -0500 , <199601310017.TAA11453@monty> Message-ID: <9601310136.AA05845=jack@schelvis.cwi.nl> 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 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 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@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@python.org administrivia to: pythonmac-sig-request@python.org ================= From powers@petroglyph.com Tue Jan 30 06:56:12 1996 From: powers@petroglyph.com (Michael Powers) Date: Mon, 29 Jan 1996 23:56:12 -0700 Subject: [PYTHONMAC-SIG] What are people doing with MacPython Message-ID: 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@python.org administrivia to: pythonmac-sig-request@python.org ================= From jack@cwi.nl Wed Jan 31 11:42:32 1996 From: jack@cwi.nl (Jack Jansen) Date: Wed, 31 Jan 1996 12:42:32 +0100 Subject: [PYTHONMAC-SIG] What are people doing with MacPython In-Reply-To: Message by powers@petroglyph.com (Michael Powers) , Mon, 29 Jan 1996 23:56:12 -0700 , Message-ID: <9601311142.AA06732=jack@schelvis.cwi.nl> Recently, powers@petroglyph.com (Michael Powers) said: > > Jack, your multimedia work sounds interesting? Can you say more? There are quite some papers on CMIFed and the Amsterdam Hypermedia Model (on which it is loosely based) available at ftp://ftp.cwi.nl/pub/mmpapers, but I can give a quick outline here. A cmif document is a hierarchical structure, with parallel and sequential composition. This structure gives the coarse timing relations, with finer control possible through a mechanism called sync arcs. The leaf nodes, which are the actual media items being played, contain a reference to the data (usually stored outside the cmif document, in a media-dependent form) and a "channel" on which the mode should be played. Channels are abstract devices: there are sound channels which can play audio files, text and html channels which show text, movie channels, image channels, etc. The on-screen channels also hold information about layout, background color, etc. CMIF supports hyperlinks, and has a concept of "context" to allow the author to specify what should happen when a hyperjump is taken (replace whole current presentation with a new one, start a second asynchronous presentation, replace part of the current presentation with a new one, etc). This all fits in nicely in the tree through the use of a choice composition node (similar to the sequential and parallel composition). One of the primary design goals was transportability of documents. The tree model helps a lot here (higher level of abstraction, and hence much easier to adapt playout to a platform than a timeline model), and there's also various other bits and pieces: many image/sound/video formats are supported, data items can be referenced by URL, etc. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@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@python.org administrivia to: pythonmac-sig-request@python.org =================