From sdm7g@virginia.edu Sun May 11 20:23:40 1997 From: sdm7g@virginia.edu (Steven D. Majewski) Date: 11 May 97 15:23:40 -0400 Subject: [PYTHONMAC-SIG] New improved ProgressBar [ MacPython EasyDialogs.py ] Message-ID: I had some time in between projects, while waiting for a vendor to deliver some new drivers, to try to finish up some old half-finished projects. Since Python 1.5 is impending, I thought I'ld try to clean up my changes to EasyDialogs and try to get Guido & Jack to include it in the next Mac Python distribution. ( Jack -- please remember about the changes to the template to allow all files rather than just TEXT files. I have some template Mac file-munger applications that I would like to distribute, and those changes and these below are the things that have kept me from doing it -- I wanted it to be a simple MacPython example, but having to drag out ResEdit right away keeps it from being a simple procedure. ) Here is a new version of EasyDialogs.py with an improved ProgressBar class, which handles Drag events ( so you should change the window type of the resource to a movable modal dialog type window -- the one with a wider drag region, but no close or zoom boxes. ) and clicking on the Cancel/Stop button. I would like to add a second label line. When I tried using this in some file conversion programs, and I wanted to echo pathnames, it often overflowed the space for the text. Most of the progress bars generated by the finder and various utilities like Stuff-it, etc. all have two lines of text. Any preferences towards either allowing PB.label( string1, string2 ) vs. PB.label1( text ) & PB.label2( text ) ? I'm also considering changing the resource numbers to more closely follow Mac conventions - for example, Cancel or Stop button should usually be = 2 as Cancel is defined in some headers to be that value. I don't think changing the resource numbers should have any effect outside this code. Previous changes from EasyDialogs in 1.4 distribution: Changed Progress.Bar.label from an attribute to a method. ProgressBar.label() [with no args] returns the label. ProgressBar.label( text ) sets the label string and causes dialog update. Added ProgressBar.inc( *amount ) to increment the bar and redraw/update. A couple of bug fixes -- one that cures occasional crash on update. Latest changes: ProgressBar._update() handles drag and cancel events. You need to ResEdit the progress bar dialog resource in PythonCore: [1] The cancel button must be enabled. ( Required ) [2] Change the window to a movable dialog type. ( Highly Recommended ) [3] Change the button text from "Cancel" to "Stop" ( Recommended by Mac HI guidelines as less ambiguous ) ( #1 above kept me confused about why some of the dialog routines didn't work as I expected. It seems to have been shipped as disabled in the distribution. ) Comments or suggestions ? -- Steve Majewski """Easy to use dialogs. Message(msg) -- display a message and an OK button. AskString(prompt, default) -- ask for a string, display OK and Cancel buttons. AskYesNoCancel(question, default) -- display a question and Yes, No and Cancel buttons. bar = Progress(label, maxvalue) -- Display a progress bar bar.set(value) -- Set value bar.inc( *amount ) -- increment value by amount (default=1) bar.label( *newlabel ) -- get or set text label. More documentation in each function. This module uses DLOG resources 256, 257 and 258. Based upon STDWIN dialogs with the same names and functions. """ from Dlg import GetNewDialog, SetDialogItemText, GetDialogItemText, ModalDialog import Qd import QuickDraw import Dlg,Win,Evt,Events # sdm7g def Message(msg): """Display a MESSAGE string. Return when the user clicks the OK button or presses Return. The MESSAGE string can be at most 255 characters long. """ id = 256 d = GetNewDialog(id, -1) if not d: print "Can't get DLOG resource with id =", id return tp, h, rect = d.GetDialogItem(2) SetDialogItemText(h, msg) d.SetDialogDefaultItem(1) while 1: n = ModalDialog(None) if n == 1: return def AskString(prompt, default = ""): """Display a PROMPT string and a text entry field with a DEFAULT string. Return the contents of the text entry field when the user clicks the OK button or presses Return. Return None when the user clicks the Cancel button. If omitted, DEFAULT is empty. The PROMPT and DEFAULT strings, as well as the return value, can be at most 255 characters long. """ id = 257 d = GetNewDialog(id, -1) if not d: print "Can't get DLOG resource with id =", id return tp, h, rect = d.GetDialogItem(3) SetDialogItemText(h, prompt) tp, h, rect = d.GetDialogItem(4) SetDialogItemText(h, default) # d.SetDialogItem(4, 0, 255) d.SetDialogDefaultItem(1) d.SetDialogCancelItem(2) while 1: n = ModalDialog(None) if n == 1: tp, h, rect = d.GetDialogItem(4) return GetDialogItemText(h) if n == 2: return None def AskYesNoCancel(question, default = 0): ## """Display a QUESTION string which can be answered with Yes or No. ## ## Return 1 when the user clicks the Yes button. ## Return 0 when the user clicks the No button. ## Return -1 when the user clicks the Cancel button. ## ## When the user presses Return, the DEFAULT value is returned. ## If omitted, this is 0 (No). ## ## The QUESTION strign ca be at most 255 characters. ## """ id = 258 d = GetNewDialog(id, -1) if not d: print "Can't get DLOG resource with id =", id return # Button assignments: # 1 = default (invisible) # 2 = Yes # 3 = No # 4 = Cancel # The question string is item 5 tp, h, rect = d.GetDialogItem(5) SetDialogItemText(h, question) d.SetDialogCancelItem(4) if default == 1: d.SetDialogDefaultItem(2) elif default == 0: d.SetDialogDefaultItem(3) elif default == -1: d.SetDialogDefaultItem(4) while 1: n = ModalDialog(None) if n == 1: return default if n == 2: return 1 if n == 3: return 0 if n == 4: return -1 screenbounds = Qd.qd.screenBits.bounds screenbounds = screenbounds[0]+4, screenbounds[1]+4, \ screenbounds[2]-4, screenbounds[3]-4 class ProgressBar: def __init__(self, label="Working...", maxval=100): self.maxval = maxval self.curval = -1 self.d = GetNewDialog(259, -1) self.label( label ) self._update(0) def __del__( self ): self.d.HideWindow() del self.d def label( self, *newstr ): # sdm7g -- new routine: change text if newstr : self._label = newstr[0] tp, text_h, rect = self.d.GetDialogItem(2) SetDialogItemText(text_h, self._label ) def _update(self, value): self.d.BringToFront() # sdm7g -- this seems to cure Modal bus-error crash tp, h, bar_rect = self.d.GetDialogItem(3) Qd.SetPort(self.d) Qd.FrameRect(bar_rect) # Draw outline inner_rect = Qd.InsetRect(bar_rect, 1, 1) l, t, r, b = inner_rect Qd.ForeColor(QuickDraw.blackColor) Qd.BackColor(QuickDraw.blackColor) Qd.PaintRect((l, t, int(l + (r-l)*value/self.maxval), b)) # Draw bar Qd.ForeColor(QuickDraw.whiteColor) Qd.BackColor(QuickDraw.whiteColor) Qd.PaintRect((int(l + (r-l)*value/self.maxval), t, r, b)) # Clear rest # Restore settings Qd.ForeColor(QuickDraw.blackColor) Qd.BackColor(QuickDraw.whiteColor) # Test for cancel button ready, ev = Evt.WaitNextEvent( Events.mDownMask, 1 ) if ready : what,msg,when,where,mod = ev part = Win.FindWindow( where )[0] if Dlg.IsDialogEvent( ev ): ds = Dlg.DialogSelect( ev ) if ds[0] and ds[1] == self.d and ds[-1] == 1 : raise KeyboardInterrupt, ev else: if part == 4 : # inDrag self.d.DragWindow( where, screenbounds ) else: MacOS.HandleEvent( ev ) def set(self, value): if value < 0: value = 0 if value > self.maxval: value = self.maxval self.curval = value # sdm7g -- didn't update curval self._update(value) def inc( self, *n ): # sdm7g -- add increment method if not n: n = 1 else: n = n[0] self.set( self.curval + n ) import time import MacOS def test(): Message("Testing EasyDialogs.") ok = AskYesNoCancel("Do you want to proceed?") if ok > 0: s = AskString("Enter your first name") Message("Thank you,\015%s" % `s`) text = ( "Working Hard...", "Hardly Working..." , "So far, so good!", "Keep on truckin'" ) bar = ProgressBar( text[0], 100) try: appsw = MacOS.EnableAppswitch( 0 ) for i in range(100): bar.set(i) time.sleep( 0.1 ) if ( i % 10 == 0 ) : bar.label( text[ (i/10) % 4 ] ) bar.label( "Done." ) time.sleep( 0.3 ) # give'em a chance to see the done. finally: del bar MacOS.EnableAppswitch( appsw ) if __name__ == '__main__': try: test() except KeyboardInterrupt: Message( "Operation Canceled." ) _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From jimmy@CS.cofc.EDU Tue May 13 23:33:22 1997 From: jimmy@CS.cofc.EDU (James B. Wilkinson) Date: Tue, 13 May 1997 18:33:22 -0400 Subject: [PYTHONMAC-SIG] ped/framework weirdness Message-ID: I was hoping to use the framework to do some experimenting with a project I've been working on. Finally got sick of trying to do it in C. So I started trying out the framework last week, and ped looked like a good place to start since I want to use TE boxes. The do_activate method in the TEWindow class has a line print "ACTIVATE", onoff right at its beginning. I noticed that if I open two new windows in ped and click back and forth between them, the print statement shows only *deactivate* events in the Python output window: "ACTIVATE 0". Furthermore, the behavior of the grow boxes correlates with that. Once they are gone they don't come back unless I click in some other window, like the Python output window. Then, when I click back in one of the editor windows, I get an activate event in it and the grow box comes back. Hmmm. So I decided to put a print into the dispatch method in the framework and see what's going on. Well, that fixed the problem!!! I started seeing both deactivate and activate events (from the print line in do_activate). So I started moving it around in the dispatch method. Got the most interesting results with it at the bottom: #print 'dispatch', name handler(event) #this is the last true line of code in the method #print 'dispatch', name Like this it acts as I described in the first paragraph. If I remove the # on the line before the handler call, everything works as I think it should. If I put it back there and remove the # on the last line, then I get only *activate* events when I click back and forth between two ped windows: "ACTIVATE 1". I'm totally confused. If this were happening in C, I'd know what it meant, but in an interpreted language? Anybody got any ideas about what's going on here? Contributions gratefully accepted. ------------------------------------------------------------- Jimmy Wilkinson | Perfessor of Computer Science jimmy@cs.cofc.edu | The College of Charleston (803) 953-8160 | Charleston SC 29424 If there is one word to describe me, that word would have to be "profectionist". _______________ 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 May 14 10:09:10 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 14 May 1997 11:09:10 +0200 Subject: [PYTHONMAC-SIG] ped/framework weirdness In-Reply-To: Message by "James B. Wilkinson" , Tue, 13 May 1997 18:33:22 -0400 , Message-ID: <9705140909.AA10371=jack@snelboot.cwi.nl> > I was hoping to use the framework to do some experimenting with a project > I've been working on. Finally got sick of trying to do it in C. So I > started trying out the framework last week, and ped looked like a good > place to start since I want to use TE boxes. The do_activate method in the > TEWindow class has a line print "ACTIVATE", onoff right at its > beginning. I noticed that if I open two new windows in ped and click back > and forth between them, the print statement shows only *deactivate* events > in the Python output window: "ACTIVATE 0". Hmm, you're right. I'm not sure exactly what's going on, but I suspect that it has to do with the debug output: printing causes Sioux to run, and it may eat some events in that case. Try removing all print statements. Another possibility is to look at the waste demos, they show the correct behaviour. These were adapted from ped, so the code is similar. I don't have the time right now to check out what I did correctly in those and wrong in ped, though, so you're on your own. -- 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 just@knoware.nl Wed May 14 11:15:01 1997 From: just@knoware.nl (Just van Rossum) Date: Wed, 14 May 1997 12:15:01 +0200 Subject: [PYTHONMAC-SIG] ped/framework weirdness Message-ID: At 11:09 AM 5/14/97, Jack Jansen wrote: >> I was hoping to use the framework to do some experimenting with a project >> I've been working on. Finally got sick of trying to do it in C. So I >> started trying out the framework last week, and ped looked like a good >> place to start since I want to use TE boxes. The do_activate method in the >> TEWindow class has a line print "ACTIVATE", onoff right at its >> beginning. I noticed that if I open two new windows in ped and click back >> and forth between them, the print statement shows only *deactivate* events >> in the Python output window: "ACTIVATE 0". > >Hmm, you're right. I'm not sure exactly what's going on, but I suspect that >it has to do with the debug output: printing causes Sioux to run, and it may >eat some events in that case. Try removing all print statements. It took me a while, but that's exactly it. Some events were being eaten by SIOUX (the Metroworks console that just doesn't stop to suck), which has it's own event handling stuff, even though it was't supposed to do so: MacOS.EnableAppswitch(-1) was performed in FrameWork, which means that no event should be passed to SIOUX. But, (and this I didn't know), it still eats events during printing... Solution: omit the print statements and you're fine, although the scrollbars still behave a bit strange, but I guess that's ped's or FrameWork.ScrolledWindow's fault (left as an excercise). Besides that, we can fully blame SIOUX. >Another possibility is to look at the waste demos, they show the correct >behaviour. These were adapted from ped, so the code is similar. I don't have >the >time right now to check out what I did correctly in those and wrong in ped, >though, so you're on your own. Waste rocks. It's excellent. Builtin undo. Some tab support. Very flexible. This is supposed to sound cheesy, but it's true: Since I discovered WASTE, I never even looked at TE again... Just _______________ 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 May 14 12:15:27 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 14 May 1997 13:15:27 +0200 Subject: [PYTHONMAC-SIG] ped/framework weirdness In-Reply-To: Message by just@knoware.nl (Just van Rossum) , Wed, 14 May 1997 12:15:01 +0200 , Message-ID: <9705141115.AA10951=jack@snelboot.cwi.nl> > Waste rocks. It's excellent. Builtin undo. Some tab support. Very flexible. > This is supposed to sound cheesy, but it's true: Since I discovered WASTE, > I never even looked at TE again... Waarom heb ik dan zo m'n best moeten doen om je daarvan te overtuigen? :-) -- 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 Wed May 14 12:18:40 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 14 May 1997 13:18:40 +0200 Subject: [PYTHONMAC-SIG] ped/framework weirdness In-Reply-To: Message by just@knoware.nl (Just van Rossum) , Wed, 14 May 1997 12:15:01 +0200 , Message-ID: <9705141118.AA10972=jack@snelboot.cwi.nl> > Waste rocks. It's excellent. Builtin undo. Some tab support. Very flexible. > This is supposed to sound cheesy, but it's true: Since I discovered WASTE, > I never even looked at TE again... Fully agreed. The one thing I would like very much is drag-and-drop support. Waste understands this, but I have no idea how to make use of this in Python. If anyone understands drag-and-drop and could come up with the glue code needed to use it in Python programs that would be very welcome, -- 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 sdm7g@virginia.edu Thu May 15 00:23:31 1997 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Wed, 14 May 1997 19:23:31 -0400 (EDT) Subject: [PYTHONMAC-SIG] CW11 (again) Message-ID: Has anyone done the CW11 rebuild of Python1.4 yet ? Any problems ? I've finally got a need to rebuild it -- I'm working my way thru a handful of Tcl/Tk 8 changes in libraries and access paths to get it to recompile, and I may get around to starting on Python tonight. BTW: I saw a mention of 1.5a1 in the string sig, but I didn't see this on the ftp site anywhere. Any chance of getting a copy to start on Mac CW11 + TK8 mods - or is Jack or someone started on this already ? BTWII: It would be nice to have a more light-weight distribution ( both source and binary ) that, for example, that just expected Tcl/Tk shared libraries to be installed separately in "the usual place" . Anyone have any ideas or suggestions about this ? BTWIII: How much of GUSI is needed now -- I know it's required for socket support, but I think a lot of others posix like things may now be supported in both GUSI and MSL. ( and I noticed that GUSI has been taken out of the Tcl/Tk 8.0 distribution. -- and, I've been unable for some time, to connect to the GUSI ftp site to check on the status of newer versions. ) ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- By doing just a little every day, you can gradually let the task completely overwhelm you. _______________ 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 Thu May 15 11:43:43 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 15 May 1997 12:43:43 +0200 Subject: [PYTHONMAC-SIG] CW11 (again) In-Reply-To: Message by "Steven D. Majewski" , Wed, 14 May 1997 19:23:31 -0400 (EDT) , Message-ID: <9705151043.AA05980=jack@snelboot.cwi.nl> > Has anyone done the CW11 rebuild of Python1.4 yet ? > Any problems ? If you load the "obsolete ANSI libraries" from the CW11 CD and use those in stead of MSL it should build fine. Don't bother trying to convert to MSL: I've already done it and it is an *incredible* amount of excruciatingly boring work (I spent the better part of two weeks on it). > I've finally got a need to rebuild it -- I'm working my > way thru a handful of Tcl/Tk 8 changes in libraries and > access paths to get it to recompile, and I may get around > to starting on Python tonight. Could you keep me updated on what you've had to change? I haven't looked at Tcltk 8 yet, but will do so shortly... > BTW: I saw a mention of 1.5a1 in the string sig, but I > didn't see this on the ftp site anywhere. Any chance of > getting a copy to start on Mac CW11 + TK8 mods - or is > Jack or someone started on this already ? Yup, it's being done. As soon as Guido clears 1.5a-something for general distribution I'll do a mac distribution. > BTWII: It would be nice to have a more light-weight distribution > ( both source and binary ) that, for example, that just expected > Tcl/Tk shared libraries to be installed separately in "the usual > place" . Anyone have any ideas or suggestions about this ? Hmm, probably a good idea, now that there's the tcl/tk shared libraries. Why don't you give it a try? > BTWIII: > How much of GUSI is needed now -- I know it's required for > socket support, but I think a lot of others posix like things > may now be supported in both GUSI and MSL. ( and I noticed > that GUSI has been taken out of the Tcl/Tk 8.0 distribution. > -- and, I've been unable for some time, to connect to the GUSI > ftp site to check on the status of newer versions. ) Beside sockets GUSI also provides select, better "raw" I/O and the hooks for multiple threads (eventually). I'd be reluctant to do away with it, the MSL library is not really that much better than the old ANSI library. GUSI currently lives at . -- 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 roseman@cpsc.ucalgary.ca Thu May 15 13:38:13 1997 From: roseman@cpsc.ucalgary.ca (Mark Roseman) Date: Thu, 15 May 1997 06:38:13 -0600 Subject: [PYTHONMAC-SIG] CW11 (again) In-Reply-To: Your message of "Thu, 15 May 1997 12:43:43 +0200." <9705151043.AA05980=jack@snelboot.cwi.nl> Message-ID: <199705151238.GAA02357@janu.cpsc.ucalgary.ca> btw, the next release (beta 1) of tcl/tk 8 is due out pretty shortly, if you're looking to put off doing some mind numbing work for a couple of weeks.. :-) _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From sdm7g@virginia.edu Thu May 15 16:56:14 1997 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Thu, 15 May 1997 11:56:14 -0400 (EDT) Subject: [PYTHONMAC-SIG] CW11 (again) In-Reply-To: <9705151043.AA05980=jack@snelboot.cwi.nl> Message-ID: On Thu, 15 May 1997, Jack Jansen wrote: > > Has anyone done the CW11 rebuild of Python1.4 yet ? > > Any problems ? > > If you load the "obsolete ANSI libraries" from the CW11 CD and use those in > stead of MSL it should build fine. Don't bother trying to convert to MSL: I've > already done it and it is an *incredible* amount of excruciatingly boring work > (I spent the better part of two weeks on it). > > > I've finally got a need to rebuild it -- I'm working my > > way thru a handful of Tcl/Tk 8 changes in libraries and > > access paths to get it to recompile, and I may get around > > to starting on Python tonight. > > Could you keep me updated on what you've had to change? I haven't looked at > Tcltk 8 yet, but will do so shortly... So far, all the PPC libraries and apps except for Wish have built with simple changes to the prefs ( turn off ANSI strict ) and replacing the old libraries with the new. Wish has some undefined symbols, so I must not yet have the right replacement libraries. ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- By doing just a little every day, you can gradually let the task completely overwhelm you. _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From jimmy@stono.cs.cofc.edu Fri May 16 00:24:46 1997 From: jimmy@stono.cs.cofc.edu (James B. Wilkinson) Date: Thu, 15 May 1997 19:24:46 -0400 Subject: [PYTHONMAC-SIG] A bugfix for ped and a question (possibly long answer) Message-ID: In the method do_contentclick of class TEWindow the line shifted = (modifiers & 0x200) should be shifted = (modifiers & 0x200) != 0 to get correct selection extension with the shift key. I think that what is going on is that the Mac toolbox (because of its Pascal origins?) wants the value 1 for true, and no ordinary nonzero value (like the 512 you get with the incorrect line) will do. You were all waiting breathlessly for this one to be fixed, right? Now here's my question. I put the following code into a class I made: class TAValue: tr = 0, 0, 0, 0 testTE = TE.TENew(tr, tr) #kills me stone dead del tr def TryNewTEChar(self, ch): dhandle = self.TEGetText() data = dhandle.data TAValue.testTE.TESetText(data) TAValue.testTE.TESetSelect(self.selStart, self.selEnd) TAValue.testTE.TEKey(ord(ch)) dhandle = TAValue.testTE.TEGetText() return dhandle.data def __init__(self, x0, y0, x1, y1): #lots more The idea was that testTE is a class attribute that gets set up as the file is read in. Then I can use it in TryNewTEChar to do character by character filtering and updating as the user types. I've been doing this in C (with a global variable rather than a class attribute) for years now, so I know it works. Well, the line testTE = TENew(tr, tr) blasts my Mac into another world. The cursor freezes, and bucky/escape won't kill the application. I have to power down and back up. Is this because TE is not Python but is glued in from the toolbox, or have I completely misunderstood about class methods and attributes? Or should I be looking somewhere else? I looked through the archive of this group last weekend, and saw one, maybe two references to this FrameWork. I wonder whether that means that you guys use something else, like Tk or wxWindows. I've even thought about hacking my C stuff into waste and adding glue for it. But that means that I have to stop what I'm doing and go learn how to do that. I can do my prototyping without input filtering if I remember to type carefully when I'm testing, but it would be nice to have it. Any suggestions? Thanks. ------------------------------------------------------------- Jimmy Wilkinson | Perfessor of Computer Science jimmy@cs.cofc.edu | The College of Charleston (803) 953-8160 | Charleston SC 29424 If there is one word to describe me, that word would have to be "profectionist". _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From just@knoware.nl Fri May 16 09:49:11 1997 From: just@knoware.nl (Just van Rossum) Date: Fri, 16 May 1997 10:49:11 +0200 Subject: [PYTHONMAC-SIG] A bugfix for ped and a question (possibly long answer) Message-ID: >class TAValue: > > tr = 0, 0, 0, 0 > testTE = TE.TENew(tr, tr) #kills me stone dead > del tr > > def TryNewTEChar(self, ch): > dhandle = self.TEGetText() > data = dhandle.data > TAValue.testTE.TESetText(data) > TAValue.testTE.TESetSelect(self.selStart, self.selEnd) > TAValue.testTE.TEKey(ord(ch)) > dhandle = TAValue.testTE.TEGetText() > return dhandle.data > > def __init__(self, x0, y0, x1, y1): > #lots more > >The idea was that testTE is a class attribute that gets set up as the file >is read in. Then I can use it in TryNewTEChar to do character by character >filtering and updating as the user types. I've been doing this in C (with >a global variable rather than a class attribute) for years now, so I know >it works. Well, the line testTE = TENew(tr, tr) blasts my Mac into another >world. The cursor freezes, and bucky/escape won't kill the application. I >have to power down and back up. Is this because TE is not Python but is >glued in from the toolbox, or have I completely misunderstood about class >methods and attributes? TENew picks the current GrafPort to live in, which is probably the SIOUX window in your case. I don't know why that still crashes as bad as it does, but I've seen it happen indeed. How do you do this in C? (Kindof wondering since I have not used TE much in C.) Do you set the GrafPort later manually? If so, you can't do that in Python I think. >Or should I be looking somewhere else? I looked through the archive of >this group last weekend, and saw one, maybe two references to this >FrameWork. I wonder whether that means that you guys use something else, >like Tk or wxWindows. I've even thought about hacking my C stuff into >waste and adding glue for it. But that means that I have to stop what I'm >doing and go learn how to do that. I use FrameWork a lot, but I have written a more abstract layer on top of it. FrameWork is already a lot more abstract than the toolbox, but it's still very cumbersome to make windows, controls, etc. I plan to release my stuff, since I'm sure other people might find it useful, but it's not yet generic enough. >I can do my prototyping without input filtering if I remember to type >carefully when I'm testing, but it would be nice to have it. Any >suggestions? Isn't customizing the 'do_char' method of FrameWork.Window enough? Just _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From jstrout@ucsd.edu Sun May 18 22:07:01 1997 From: jstrout@ucsd.edu (Joseph J. Strout) Date: Sun, 18 May 1997 14:07:01 -0700 Subject: [PYTHONMAC-SIG] apps freeze unless they print! Message-ID: I'm suddenly finding that Python locks up under the following conditions: I have a program in a loop which is working very hard (or snoozing) for a long time without printing anything to the console window (sample code below); I switch to the Finder or any other app; then I switch back -- presto, it's frozen. By "frozen" I mean that the window is not refreshed, I can't move it, and I can't switch back to the Finder or any other app; I have to hit command-period or kill the Python process. Perhaps the Mac guts are only being updated whenever the console window is updated. But I don't really want to clutter up my nice log window with useless garbage (and system.out.write('') doesn't work either, I tried it!). Is there any other way to trigger the Mac event-handling parts? I'm using Python 1.4 PPC, on a PowerBase 180 running MacOS 7.5.5. Sample code: ---------------------------------------------------------------------- from time import sleep t=0 while t < 9999: sleep(1) #print t # if this line is included, it works t = t+1 ---------------------------------------------------------------------- Any suggestions will be greatly appreciated! -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Department of Neuroscience, UCSD | | jstrout@ucsd.edu http://www-acs.ucsd.edu/~jstrout/ | `------------------------------------------------------------------' _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From just@knoware.nl Sun May 18 23:24:28 1997 From: just@knoware.nl (Just van Rossum) Date: Mon, 19 May 1997 00:24:28 +0200 Subject: [PYTHONMAC-SIG] apps freeze unless they print! Message-ID: At 2:07 PM 5/18/97, Joseph J. Strout wrote: >I'm suddenly finding that Python locks up under the following conditions: I >have a program in a loop which is working very hard (or snoozing) for a >long time without printing anything to the console window (sample code >below); I switch to the Finder or any other app; then I switch back -- >presto, it's frozen. By "frozen" I mean that the window is not refreshed, >I can't move it, and I can't switch back to the Finder or any other app; I >have to hit command-period or kill the Python process. Hm, I'm not getting exactly the same what you describe. My window does not get updated, but I can move it and I can go back and forth between apps no problem. The not updating thing is annoying indeed. I found the reason in macglue.c: /* ** We have to be careful, since we can't handle ** things like updates (and they'll keep coming back if we don't ** handle them). Note that we don't know who has windows open, so ** even handing updates off to SIOUX under MW isn't going to work. */ #define MAINLOOP_EVENTMASK (mDownMask|keyDownMask|osMask) Can't we check whether there are custom windows? Say, disable update events as soon as Win.GetNewWindow() and relatives are used? Hmm, not "safe" when a C-extension makes it's own windows. But then again, then you're probably running a custom event loop already. I'd say, if the Appswitching var has the default value (1), there's only small chance there are any other windows open besides SIOUX. Perhaps a new option for MacOS.EnableAppswitch()? So, if you want updates to be handled correctly while a script is running, do MacOS.EnableAppswitch(2). It couldn't be turned on by default I think. I wish I could do Appswitching while a script is running in a FrameWork environment (with all event handling done in Python), but I think we need thread support to do that... Just _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From tismer@tismer.com Mon May 19 02:13:05 1997 From: tismer@tismer.com (Christian Tismer) Date: Mon, 19 May 1997 03:13:05 +0200 Subject: [PYTHONMAC-SIG] apps freeze unless they print! References: Message-ID: <337FA921.70B6@tismer.com> Hi Joseph, [ Python fridge ] > Perhaps the Mac guts are only being updated whenever the console window is > updated. But I don't really want to clutter up my nice log window with > useless garbage (and system.out.write('') doesn't work either, I tried > it!). Is there any other way to trigger the Mac event-handling parts? I have no idea how a Mac works (although here is one :-), but what about this old trick to write space backspace to the log window, would that trash it with garbage? Or writing a null-byte? Works well to keep my internet connections alive without much harm to anything. just my 2 pennies - chris p.s.: which username do you want on starship? _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From billpy@mail.demon.net Mon May 19 12:01:35 1997 From: billpy@mail.demon.net (Bill Bedford) Date: Mon, 19 May 1997 12:01:35 +0100 Subject: [PYTHONMAC-SIG] apps freeze unless they print! In-Reply-To: Message-ID: At 10:07 pm +0100 18/05/97, Joseph J. Strout wrote: ~I'm suddenly finding that Python locks up under the following conditions: I ~have a program in a loop which is working very hard (or snoozing) for a ~long time without printing anything to the console window (sample code ~below); I switch to the Finder or any other app; then I switch back -- ~presto, it's frozen. By "frozen" I mean that the window is not refreshed, ~I can't move it, and I can't switch back to the Finder or any other app; I ~have to hit command-period or kill the Python process. Not quite true, replace the print line with if t % 10 == 0:print t and then have some patience when you bring the consol to the front. You will see after 10 secs a new entry, then after another 10 secs a second new entries and then after a further 10sec there will be a redraw and all the entries will appear. ~ ~Perhaps the Mac guts are only being updated whenever the console window is ~updated. But I don't really want to clutter up my nice log window with ~useless garbage (and system.out.write('') doesn't work either, I tried ~it!). Is there any other way to trigger the Mac event-handling parts? The Mac guts are being up dated, but you are putting null events into the console's event queue and these are having to time out before it redraws. One way round would be to use MacOS.SetScheduleTimes() to make the console check the event queue more often and so speed up the redraw. ----------------------------------------------------------------------- Bill Bedford Designer of Photo-Etches billb@mousa.demon.co.uk owner Brit_Rail-L --- british railways historical list ----------------------------------------------------------------------- _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From jstrout@ucsd.edu Mon May 19 16:15:57 1997 From: jstrout@ucsd.edu (Joseph J. Strout) Date: Mon, 19 May 1997 08:15:57 -0700 Subject: [PYTHONMAC-SIG] apps freeze unless they print! Message-ID: Bill wrote: >Not quite true, replace the print line with > >if t % 10 == 0:print t Yes, I know this, but in my app I don't WANT to print anything when there's nothing going on -- not even every 10 seconds. >The Mac guts are being up dated, but you are putting null events into the >console's event queue and these are having to time out before it redraws. > >One way round would be to use MacOS.SetScheduleTimes() to make the console >check the event queue more often and so speed up the redraw. Hmm, I tried reducing it from the default value (12) to 2, with no effect. It's as if it never checks the event queue at all, until I hit command-period. Regards, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Department of Neuroscience, UCSD | | jstrout@ucsd.edu http://www-acs.ucsd.edu/~jstrout/ | `------------------------------------------------------------------' _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From pr1@club-internet.fr Mon May 19 17:23:52 1997 From: pr1@club-internet.fr (Philippe de Rochambeau) Date: Mon, 19 May 1997 17:23:52 +0100 Subject: [PYTHONMAC-SIG] Python as CGI scripting language Message-ID: Has anybody succeeded in using Python as a CGI language? If so, how did you do it? The instructions provided in the PythonMac package did not help me much. I am using WebStar as server software. Many thanks. Philippe de Rochambeau ______________________________________________________________________________ Philippe de Rochambeau pr1@club-internet.fr _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From sdm7g@Virginia.EDU Mon May 19 17:46:23 1997 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Mon, 19 May 1997 12:46:23 -0400 (EDT) Subject: [PYTHONMAC-SIG] apps freeze unless they print! In-Reply-To: Message-ID: On Sun, 18 May 1997, Joseph J. Strout wrote: > I'm suddenly finding that Python locks up under the following conditions: I > have a program in a loop which is working very hard (or snoozing) for a > long time without printing anything to the console window (sample code > below); I switch to the Finder or any other app; then I switch back -- > presto, it's frozen. By "frozen" I mean that the window is not refreshed, > I can't move it, and I can't switch back to the Finder or any other app; I > have to hit command-period or kill the Python process. > > Perhaps the Mac guts are only being updated whenever the console window is > updated. But I don't really want to clutter up my nice log window with > useless garbage (and system.out.write('') doesn't work either, I tried > it!). Is there any other way to trigger the Mac event-handling parts? > Add the following line to the loop (plus an import MacOS, Evt somewhere): MacOS.HandleEvent(Evt.GetNextEvent(-1)[1]) You get a delay on the screen update from the sleep. I'm not sure why you get the lockup in the first place, but I sometimes see the event effects get done right after I command-dot out, so I expect it has something to do with the event queue. ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- By doing just a little every day, you can gradually let the task completely overwhelm you. _______________ 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 Mon May 19 20:59:23 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 19 May 1997 21:59:23 +0200 Subject: [PYTHONMAC-SIG] apps freeze unless they print! In-Reply-To: Message by "Joseph J. Strout" , Sun, 18 May 1997 14:07:01 -0700 , Message-ID: <9705191959.AA27111=jack@snelboot.cwi.nl> Joe, this has been reported before. It'll be fixed in the next release, until then the print is a workaround. -- 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 jstrout@ucsd.edu Tue May 20 00:21:13 1997 From: jstrout@ucsd.edu (Joseph J. Strout) Date: Mon, 19 May 1997 16:21:13 -0700 Subject: [PYTHONMAC-SIG] apps freeze unless they print! In-Reply-To: <9705191959.AA27111=jack@snelboot.cwi.nl> References: Message by "Joseph J. Strout" , Sun, 18 May 1997 14:07:01 -0700 , Message-ID: At 12:59 PM -0700 5/19/97, Jack Jansen wrote: >this has been reported before. It'll be fixed in the next release, until >then the print is a workaround. OK, but FWIW, Steven's workaround is better in that it doesn't clutter up the output, and it works great for me: MacOS.HandleEvent(Evt.GetNextEvent(-1)[1]) Regards, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Department of Neuroscience, UCSD | | jstrout@ucsd.edu http://www-acs.ucsd.edu/~jstrout/ | `------------------------------------------------------------------' _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From billpy@mail.demon.net Mon May 19 19:28:18 1997 From: billpy@mail.demon.net (Bill Bedford) Date: Mon, 19 May 1997 19:28:18 +0100 Subject: [PYTHONMAC-SIG] apps freeze unless they print! In-Reply-To: References: Message-ID: At 5:46 pm +0100 19/05/97, Steven D. Majewski wrote: ~On Sun, 18 May 1997, Joseph J. Strout wrote: ~ ~> I'm suddenly finding that Python locks up under the following conditions: I ~> have a program in a loop which is working very hard (or snoozing) for a ~ ~ ~Add the following line to the loop (plus an import MacOS, Evt somewhere): ~ ~ MacOS.HandleEvent(Evt.GetNextEvent(-1)[1]) ~ ~ ~You get a delay on the screen update from the sleep. ~I'm not sure why you get the lockup in the first place, but I ~sometimes see the event effects get done right after I command-dot ~out, so I expect it has something to do with the event queue. ~ It will also work as expected if you put a print statement before the loop. Could it be that the event queue cannot start with a null event? ----------------------------------------------------------------------- Bill Bedford Designer of Photo-Etches billb@mousa.demon.co.uk owner Brit_Rail-L --- british railways historical list ----------------------------------------------------------------------- _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From sdm7g@Virginia.EDU Thu May 22 23:16:23 1997 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Thu, 22 May 1997 18:16:23 -0400 (EDT) Subject: [PYTHONMAC-SIG] calldll Message-ID: There doesn't seem to be a external interface to get the names in the symbol table from calldll -- is that correct ? I'm giving calldll a try to use for debugging a third party device driver that isn't too well documented. If it works I'm sure I'll write something up about it, but while doing that, I realized that finding the symbols in a dynamic library is a useful programmers tool. Is there any standard tool that does this ? in Code Warrior or MPW ? When I last had to do this, I used the :verbose switch in my XlispStat CFM import module, which prints out the symbol table, but doesn't give you a list that you can do something with. If there is no tool that does this already, I may try to hack it into Jack's calldll -- either give it a __dict__ , or add a method to return the symbol table entries. ( Any comments Jack ? ) ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- By doing just a little every day, you can gradually let the task completely overwhelm you. _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From sdm7g@Virginia.EDU Thu May 22 23:26:52 1997 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Thu, 22 May 1997 18:26:52 -0400 (EDT) Subject: [PYTHONMAC-SIG] MacPython serial IO Message-ID: Is anyone doing serial com-port I/O with MacPython ? How are you doing it ? Is there an interface other than the Connection Manager module ? ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- By doing just a little every day, you can gradually let the task completely overwhelm you. _______________ 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 Fri May 23 09:34:08 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 23 May 1997 10:34:08 +0200 Subject: [PYTHONMAC-SIG] MacPython serial IO In-Reply-To: Message by "Steven D. Majewski" , Thu, 22 May 1997 18:26:52 -0400 (EDT) , Message-ID: <9705230834.AA01724=jack@snelboot.cwi.nl> > > > Is anyone doing serial com-port I/O with MacPython ? > > How are you doing it ? > Is there an interface other than the Connection Manager module ? I use the CTB connection manager, and it works fine. There were one or two bugs in it at the time of 1.4 (one serious one, a memory leak), the fixed version will be in 1.5 (or let me know if you need it earlier and I can send you the sources). -- 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 billpy@mail.demon.net Fri May 23 12:24:30 1997 From: billpy@mail.demon.net (Bill Bedford) Date: Fri, 23 May 1997 12:24:30 +0100 Subject: [PYTHONMAC-SIG] AppleEvent "every" Message-ID: I am working on an expanded findertools module, and would like to include the ability to get/set the property of every object. As in the applescript : get name of every disk. When I look at the ae that this script sends "every" is represented by seld:abso(=AB616C6C20=BB) Can any one tell me what this long represents? Or where I can find more about it? I don't recall seeing anything in Inside Mac. Thanks. ----------------------------------------------------------------------- Bill Bedford Designer of Photo-Etches billb@mousa.demon.co.uk owner Brit_Rail-L --- british railways historical list ----------------------------------------------------------------------- _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From billpy@mail.demon.net Fri May 23 21:56:14 1997 From: billpy@mail.demon.net (Bill Bedford) Date: Fri, 23 May 1997 21:56:14 +0100 Subject: [PYTHONMAC-SIG] AppleEvent "every" In-Reply-To: Message-ID: At 12:24 pm +0100 23/05/97, Bill Bedford wrote: ~I am working on an expanded findertools module, and would like to include ~the ability to get/set the property of every object. As in the applescript = : ~ ~get name of every disk. ~ ~ ~When I look at the ae that this script sends "every" is represented by ~ ~ seld:abso(=AB616C6C20=BB) ~ ~Can any one tell me what this long represents? Or where I can find more ~about it? ~ ~I don't recall seeing anything in Inside Mac. As usual when ever you ask a stupid question the answer hits you just after you press the send button................ The problem is that gensuitemodule gets confused when parsing the property 'every'. Uniquely this is a double, and should be ('all ', 'abso') and not "c@#!" _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From just@knoware.nl Tue May 27 22:12:28 1997 From: just@knoware.nl (Just van Rossum) Date: Tue, 27 May 1997 23:12:28 +0200 Subject: [PYTHONMAC-SIG] Announce: A Python Programming Environment for Macintosh (alpha) Message-ID: Dear Python People, I've put a binhexed & stuffed file at: ftp://starship.skyport.net/pub/mac/just/PythonIDE.sit.hqx I'll be away for the next week starting tomorrow way too early, so if you find terrible problems with it, let me know *now* ;-). I will respond to other feedback as soon as I get back. Please give it a try, it's pretty cool! Here follows the readme: Python Integrated Developement Environment for the Macintosh alpha 2 -- codenamed "Bruce" copyright 1997 Just van Rossum, Letterror -- just@knoware.nl May 27, 1997 This is the first public release of my stab at a Python programming environment for the Mac. There is still a lot on my wishlist, but I feel it can do enough to justify a release. I'd appreciate any feedback. It features a Python Interactive window, an integrated editor, an object browser, a module browser and a very cool traceback window. I hope to integrate Jack's debugger (TWIT) in a next release. Installation You need Python 1.4 installed; either the PPC, CFM68k or 68k Classic distibution will do. The 68k Small verion will *not* do. Set the interpreter's memory segment to at least 10 megs. (Note for MacOS 7.6.1 CFM68k users: startup might fail with an "ImportError: DragLib: library name not found in Frag registry" error message. You need to install NuDragLib. Mail me if you have trouble finding it) Unpack the archive with StuffIt expander. The unpacked folder may live anywhere, you don't need to edit sys.path. Leave it's contents alone however. Double-click PythonIDE.py. Startup time is a bit long, this should improve when I am able to distribute a semi-self-contained fat-applet under Python 1.5. Python Interactive Window This looks and feels as much as possible like the Python interpreter in interactive mode, minus the SIOUX bugs. It has undo, and the window remembers its size and position (and whether it was left open or not) between sessions. If it's not open when you start, look at the Windos menu. The Editor The are two buttons at the top: Run window and Run selection. The latter expands the selection to whole lines and then runs it. This means that you can only execute snippets at the top level of a module. I'm thinking of making this a bit more tolerant somehow. An edit window has its own namespace. However if a module with a name that matches the window's title has already been imported, the code will be executed in that module's namespace. Which effectively means that if you run such a window, it is equivalent to reload(module). The editor has borrowed some features and shortcuts of BBEdit, like indent/undent. Find & replace shortcut are BBEdit-ish as well. It indents automatically after a colon. There is a popupmenu at the right top side of the edit window which currently has only one entry: Font Settings. It does what you expect. It is not yet possible to set the default font for new windows. At the bottom on the left you find two more items of interest: a field showing the current line number (click on it to enter a different line number, then tab or enter or return or click elsewhere to jump) and a popup menu pointing to all function, class and method definitions in the module. For very big modules it might take some time before the menu gets drawn, especially on slower machines. I find it acceptable on my 68040, however. The Traceback Window Whenever an exception is raised (except in the Python interactive window, this might have to change), instead of the usual printout of the traceback you will be presented with a traceback window, with all stack frames neatly presented in a list. For each entry (stack frame) you can either open the file with the editor (which will jump to the corresponding line) or browse the local variables for that stack frame. There is currently also the option to browse the stack frame itself, but I have *never* used it so far, so I think I'm going to drop that feature. The Module Browser Here you'll find a list of all currently imported modules (= sys.modules). For builtin modules (or shared libs) there's the option to browse the module; for modules written in Python it allows you to open the module with the editor or reload it. An additional option is Open Other, which will give you a prompt to enter a module name (without .py). After you click OK sys.path will be searched for it. When successful, it opens it with the Editor. The Object Browser This is a browser I wrote quite some time ago, it works nicely (except for the still not functioning Update button). I have plans to rewrite it completely, and make it look more like CodeWarriors variable browser (with finder-like foldout arrows). You can start the browser in three different ways: - choose Browse Objects from the Python menu, this will start at sys.modules - choose Browse for one or more modules in the Module Browser - choose Browse Locals in a traceback window Menus Not much to say about the menus, but do check the Windows menu. Widgets All of the windows in the environment (except for the object browser, which is kindof obsolete) are built with a set of widgets, collected in the module W. You'll find some (mostly undocumented) demos in the WidgetsDemos folder. ModuleBrowser.py is a more serious example, while still not overly complex. Don't look at PyEdit.py, it's a mess. The widgets have a very simple interface, with a smart coordinate system (no grid yet, though). I will write up some docs for this at some point. The Python Font I have designed a bitmap font to do all my coding with. It's called Python-Sans. Originally (before it got it's current name, about 10 years ago) I made it as a replacement for Geneva 9 pt, to do Pascal coding. Even if you would rather die than use a proportional font for coding (you can choose a different one...), I recommend you to install it (drop it on the System Folder), since all user interface elements are sort of tuned to it. If you don't, it will default to Geneva, and everything will look a little less slick. Wishlist & Random notes - Intelligent filters for files that use spaces or spaces and tabs for indentation. Right now the editor is rather dumb about this issue. - Get rid of SIOUX (or at least I want to be able to *not* show it) - sys.stdin emulation. Currently SIOUX is still handling that. It's not great, but it works. - Default font settings for edit windows - being able to change tab settings, unfortunately this is currently not possible with the WASTE library. - Double clicking does not work the way I like it. Same problem as tab settings: hard to do with WASTE. - Syntax coloring (working on it!) - Save as Applet, with an option to semi-automatically collect modules. (freeze's findmodules.py would be excellent start for this, but it's not in the Mac distribution!) - A debugger. It's basically there: Jack's wonderful TWIT, but I'd like to adapt the look and feel to my app (= redesign the user interface) - Profiler -- A simple profiler stats window with sort options would be nice. - Modularize function like PTUI. Turn a script into a module. - Run window in __main__. (This to allow to run modules which contain the magic if __name__ == '__main__': etc. code.) Licence I am still pondering what exactly to do with it. For now: You *cannot* re-distribute it without my permission. This release lives exclusively at: ftp://starship.skyport.net/pub/mac/just/PythonIDE.sit.hqx If you have questions, feel free to email me at just@knoware.nl. Thank-you's I'd like to thank my Big Brother Guido and MacPython guru Jack Jansen for always being so patient with me. Also many thanks to Erik van Blokland and his Big Brother Petr for many early input and testing. Dooooh! Enjoy! Just van Rossum _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From sdm7g@Virginia.EDU Wed May 28 23:22:28 1997 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Wed, 28 May 1997 18:22:28 -0400 (EDT) Subject: [PYTHONMAC-SIG] Mac SWIG & dynamic loading MacPython modules Message-ID: Has anyone gotten MacSWIG to work with dynamically loaded Python modules ? I keep getting link problems with the global "__file" variable, which I assume, should not be exported from PythonCorePPC, but should be part of the main program address space. Do I have to take out all of the fprintf's in the wrapper module to get it to work ? Is there an option to do this automagically ? ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- By doing just a little every day, you can gradually let the task completely overwhelm you. _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org _______________ From sdm7g@Virginia.EDU Thu May 29 00:02:08 1997 From: sdm7g@Virginia.EDU (Steven D. Majewski) Date: Wed, 28 May 1997 19:02:08 -0400 (EDT) Subject: [PYTHONMAC-SIG] Mac SWIG & dynamic loading MacPython modules In-Reply-To: Message-ID: [ Partial answer to my own question: ] Taking a flying leap into the hope that something in MSL will try to do the right thing if given uninitialized FILE arrays, I tried: added console.stubs.c to project. added two lines to my wrapper function: #include FILE __files[FOPEN_MAX]; and the SWIG example code builds (with CW11), imports, dynamically loads and appears to run without crashing. ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- By doing just a little every day, you can gradually let the task completely overwhelm you. _______________ 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 Thu May 29 10:41:05 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 29 May 1997 11:41:05 +0200 Subject: [PYTHONMAC-SIG] Mac SWIG & dynamic loading MacPython modules In-Reply-To: Message by "Steven D. Majewski" , Wed, 28 May 1997 18:22:28 -0400 (EDT) , Message-ID: <9705290941.AA00299=jack@snelboot.cwi.nl> > > > Has anyone gotten MacSWIG to work with dynamically loaded Python > modules ? I keep getting link problems with the global "__file" > variable, which I assume, should not be exported from PythonCorePPC, > but should be part of the main program address space. It should definitely be exported from PythonCorePPC, otherwise you can't use stdio in your extension. The trick is that you should put PythonCorePPC *before* the C library in your link sequence, so that the __file symbol (and any other shared global data) is resolved from PythonCorePPC. This is documented somewhere, but the fact that I can't find it right now suggests that it might be stated a bit more clearly:-) -- 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 _______________