> BTW, I'm very interested in what you're doing with the Win32 GUI version.
> I downloaded the stuff on ftp.cwi.nl; is that the 'official' version?
> I want to give it a try when I get some free time here.
This version is quite old. A new version should be out in a couple of
weeks. Recently I had my computer stolen from my home, so this has stuffed
me for quite a while.
> Awhile back, I worked on a "C-like" scripting/extension language, and
> got to write a GUI development environment for it, with an integrated
> debugger interface. Basically, the GUI just spawned the language
> interpreter as a seprate process, and sent/received commands/results
> using pipes (fifos). There was a 'break' button to interrupt/signal
> the interpreter, etc. My debugger was more of a 'classic' system
> (with symbol/code offset maps,...); the GUI worked alot like most
> UNIX debugger gui's (dbxtool, xgdb,...).
>
> This system never made it to the outside-world [who wants a scripting
> language that's just like C?], but I'm curious if your Win32 Python
> system is structured simlarly (?)
Not really. My program started as a standard C++ GUI application. Then, I
added a mechanism to allow GUI type messages to be handled in Python code -
using the "register" system I mailed about before. From Python's point of
view, it has really just had its sys.stdout/err redirected to a GUI window.
There is a C++ module that exposes much of the Win32api (actually, the MFC
api, with Python objects for each MFC object). This is getting quite
comprehensive (ie, most windows controls and window types, menus, DC's,
fonts etc have Python objects)
The Python command handlers execute in the same thread as the Win32 message
loop - ie, it is just a "call" mechanism - the C++ message handler looks for
a registered handler, and performs "call_object()" on it. The message loop
and handler lookups remain in C++.
I have experimented to some extent with threads. These seem to work fine
(ie, a command handler can spawn a new thread) but I have some problems with
Python locking itself out that I havent fully resolved. A problem with
Python threads is that it assumes there is a "main" python thread - usually
the interactive interpreter itself, usually blocked in a "read" from
sys.stdin, and it seems to be compounded by the recursive nature of my
external modules. Guido has offered to help here, but I dont understand the
problem enough yet, and it is a low priority.
The debugger is really just a subclassed pdb, which uses a dialog box.
There were a couple of tricks I had to play here, but basically it is just
pdb in a dialog!
The system currently takes some advantage of DLL's, in that Python and its
modules are in a single, stand-alone DLL, and the C++ GUI itself is really
all there is in the .EXE (actually, this is 1/2 implemented, and I am moving
towards it).
I hope this has answered your question...
Mark.