From wtbridgman@radix.net Mon Mar 1 02:47:25 1999 From: wtbridgman@radix.net (W.T. Bridgman) Date: Sun, 28 Feb 1999 21:47:25 -0500 Subject: [Pythonmac-SIG] Python Mode with Alpha v7.1 Message-ID: I recently upgraded to Alpha v7.1 from Alpha v6.52. I tried to install the Python mode, including the fix recommended to me by Rob Managan at LLNL: >Look at line 575 of Pythjonmode.tcl and change it to > >source "$HOME:Tcl:Modes:PythonKeys.tcl" However, this fix no longer seems to work. Is a different patch necessary or is there a location for getting a version of Python Mode that will work in Alpha v7.1? Thanks, Tom From managan@llnl.gov Mon Mar 1 17:19:36 1999 From: managan@llnl.gov (Rob Managan) Date: Mon, 1 Mar 1999 09:19:36 -0800 Subject: [Pythonmac-SIG] Python Mode with Alpha v7.1 In-Reply-To: Message-ID: At 9:47 PM -0500 2/28/99, W.T. Bridgman wrote: >I recently upgraded to Alpha v7.1 from Alpha v6.52. I tried to install the >Python mode, including the fix recommended to me by Rob Managan at LLNL: > >>Look at line 575 of Pythjonmode.tcl and change it to >> >>source "$HOME:Tcl:Modes:PythonKeys.tcl" > >However, this fix no longer seems to work. > >Is a different patch necessary or is there a location for getting a version >of Python Mode that will work in Alpha v7.1? I looked at my version of Alpha 7 and found a python mode package. Then I couldn't find it with 7.1 so I put it on my ftp site. Check out This is where the latest macintosh copy of LLNL's Numeric module os kept as well. I will put up others that come in LLNL's releases as I find time and interest from others. *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan mailto://managan@llnl.gov LLNL ph: 925-423-0903 P.O. Box 808, L-098 FAX: 925-423-5804 Livermore, CA 94551-0808 From sdm7g@virginia.edu Mon Mar 1 19:50:06 1999 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Mon, 1 Mar 1999 14:50:06 -0500 (EST) Subject: [Pythonmac-SIG] new EasyDialogs In-Reply-To: <36D5310C.A5D1380F@oratrix.nl> Message-ID: ftp://ftp.virginia.edu/public_access/fromUVA/sdm7g/ contains newdlg.py -- a new (beta) version of EasyDialogs newpy.res.hqx -- new resources to be added to Python core: DLOG 255 MovableQuestion DLOG 254 UserItemQuestion (for password dialog) DITL 254 (for password) .pwd FONT (for password) optional: dctb for color progress bar DLOG 259 (changed Progress Bar dialog to use Color) There is one bug I'm still chasing down -- the movable modal dialogs can be made to crash if you change to another app at the wrong time while it's in progress. Joe -- give the new progress bar a try and see if you like the new look. You can change the defaults for color and pattern for the class, or set them for any instance. ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From joe@strout.net Mon Mar 1 21:04:28 1999 From: joe@strout.net (Joseph J. Strout) Date: Mon, 1 Mar 1999 13:04:28 -0800 Subject: [Pythonmac-SIG] Re: new EasyDialogs In-Reply-To: References: <36D5310C.A5D1380F@oratrix.nl> Message-ID: At 11:50 AM -0800 03-01-99, Steven D. Majewski wrote: >Joe -- give the new progress bar a try and see if you like the >new look. You can change the defaults for color and pattern >for the class, or set them for any instance. Will do. I'm not going to be too picky, though, since this is something which really ought to be handled by the Appearance Manager nowadays, anyway. Any thoughts on when and how Appearance support might be rolled into MacPython? Cheers, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From sdm7g@virginia.edu Mon Mar 1 23:36:53 1999 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Mon, 1 Mar 1999 18:36:53 -0500 (EST) Subject: [Pythonmac-SIG] Re: new EasyDialogs In-Reply-To: Message-ID: On Mon, 1 Mar 1999, Steven D. Majewski wrote: | |There is one bug I'm still chasing down -- the movable modal |dialogs can be made to crash if you change to another app at |the wrong time while it's in progress. | Commenting out the last two "else: MacOS.HandleEvent(ev)" lines in Handle1Event cures the occasional crashing problem, but makes the dialog Movable but Globally Modal (I think that's TK term for the behaviour) in that you can no longer switch to another app when that dialog is up, and you can only drag the dialog window. Switching apps was the behaviour that was causing the crash. However, that did usually(*) work with the old progress bar code and I would like to figure out how to get it to work and NOT crash. [ i.e. "locally modal" ] ( I was able to occasionally get functions from the origianal EasyDialogs to crash Python but it was a much more rare occasion. ) elif what == mouseDown: part, win = Win.FindWindow(where) if part == inDrag and win: win.DragWindow(where, screenbounds) # else: MacOS.HandleEvent(ev) # else: MacOS.HandleEvent(ev) return None ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From wtbridgman@radix.net Tue Mar 2 01:09:32 1999 From: wtbridgman@radix.net (W.T. Bridgman) Date: Mon, 1 Mar 1999 20:09:32 -0500 Subject: [Pythonmac-SIG] Python Mode with Alpha v7.1 In-Reply-To: References: Message-ID: Rob, Thanks for the pointer, but it tells me I don't have access privileges. Tom At 12:19 PM -0500 3/1/1999, Rob Managan wrote: >At 9:47 PM -0500 2/28/99, W.T. Bridgman wrote: >>I recently upgraded to Alpha v7.1 from Alpha v6.52. I tried to install the >>Python mode, including the fix recommended to me by Rob Managan at LLNL: >> >>>Look at line 575 of Pythjonmode.tcl and change it to >>> >>>source "$HOME:Tcl:Modes:PythonKeys.tcl" >> >>However, this fix no longer seems to work. >> >>Is a different patch necessary or is there a location for getting a version >>of Python Mode that will work in Alpha v7.1? > >I looked at my version of Alpha 7 and found a python mode package. Then I >couldn't find it with 7.1 so I put it on my ftp site. Check out > > > >This is where the latest macintosh copy of LLNL's Numeric module os kept as >well. I will put up others that come in LLNL's releases as I find time and >interest from others. >*-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- >Rob Managan mailto://managan@llnl.gov >LLNL ph: 925-423-0903 >P.O. Box 808, L-098 FAX: 925-423-5804 >Livermore, CA 94551-0808 From Jack.Jansen@cwi.nl Tue Mar 2 12:54:53 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 02 Mar 1999 13:54:53 +0100 Subject: [Pythonmac-SIG] Re: new EasyDialogs In-Reply-To: Message by "Joseph J. Strout" , Mon, 1 Mar 1999 13:04:28 -0800 , Message-ID: Recently, "Joseph J. Strout" said: > > Any thoughts on when and how Appearance support might be rolled into MacPytho > n? > Does anyone have any idea how this could be done in a backwards-compatible way? Or should we just forget about backwards compatability, and leave thatto the Python programmer? -- 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 From sdm7g@virginia.edu Tue Mar 2 17:52:50 1999 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Tue, 2 Mar 1999 12:52:50 -0500 (EST) Subject: [Pythonmac-SIG] Re: new EasyDialogs In-Reply-To: Message-ID: On Tue, 2 Mar 1999, Jack Jansen wrote: | |Recently, "Joseph J. Strout" said: |> |> Any thoughts on when and how Appearance support might be rolled |> into MacPython? |> | |Does anyone have any idea how this could be done in a |backwards-compatible way? Or should we just forget about backwards |compatability, and leave thatto the Python programmer? I've been thinking about this since looking at the hefty additions to the 8.0 and 8.5 docs. The 8.5 docs are even labeled as "Window Manager 2.0", "Control Manager 2.0" , ... etc. I'ld like to avoid complicating the MacPython programming process with a lot of Gestalt calls and the like. Perhaps we should make a break: leave the current toolbox shared libs as legacy support -- if you need you can still write Mac Python code for the widest Mac OS legacy systems, but start on a set of Win2, Dlg2, etc. interfaces, also targeting Carbon compatability. I think it likely that the Mac Python programmer would choose to either program for the new interfaces or the old, but if you wanted to handle both optionally, you could "try: import Win2; except: import Win" . ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From joe@strout.net Tue Mar 2 18:24:28 1999 From: joe@strout.net (Joseph J. Strout) Date: Tue, 2 Mar 1999 10:24:28 -0800 Subject: [Pythonmac-SIG] Re: new EasyDialogs In-Reply-To: References: Message-ID: At 9:52 AM -0800 03-02-99, Steven D. Majewski wrote: >I'ld like to avoid complicating the MacPython programming process >with a lot of Gestalt calls and the like. > >Perhaps we should make a break: leave the current toolbox shared >libs as legacy support -- if you need you can still write Mac Python >code for the widest Mac OS legacy systems, but start on a set of >Win2, Dlg2, etc. interfaces, also targeting Carbon compatability. This sounds like a good solution to me. Widget toolsets (basically, Just's W classes) will probably gradually add backwards-compatible support (i.e., use Win2 if available, else use Win), but putting such compatibility cruft into the Python core libraries sounds like too much work. My $0.02, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From wtbridgman@radix.net Tue Mar 2 03:11:39 1999 From: wtbridgman@radix.net (W.T. Bridgman) Date: Mon, 1 Mar 1999 22:11:39 -0500 Subject: [Pythonmac-SIG] MacPython 1.5.1 + MacOS 8.5.1 'Drag-n-Drop' Message-ID: As part of my massive system rebuild where I updated to Alpha v7.1, I also was upgrading to MacOS 8.5.1. The basics of Python still seem to work, but I used to be able to drag-n-drop a text file with a .py extension onto the Python icon and Python would fire right up. That doesn't seem to work any more. If the text file has 'Pyth' as the creator, drag-n-drop works fine. However, files created by SimpleText or Alpha are unresponsive. Any suggestions? Thanks, Tom From sdm7g@virginia.edu Wed Mar 3 00:31:44 1999 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Tue, 2 Mar 1999 19:31:44 -0500 (EST) Subject: [Pythonmac-SIG] OS 8.0, 8.5 docs [Was: new EasyDialogs] In-Reply-To: Message-ID: BTW: The Inside Mac books were always good reference books but awful as tutorials. The same goes for the new 8.0 & 8.5 reference material. Unfortunately, most of the Mac programming books out there have been 7.x based. I've finally found something. If you're trying to come up to speed on the new features, the 2.0 version of the macintosh-c book (in PDF and HTML) at http://cafe.AmbrosiaSW.com/ covers much of the new API's: Appearence Mgr., new Control Mgr,, etc. ( The older 1.2 version of macintosh-c still covers pre 8.x Mac programming. ) If any of you know of any other resources, let me know! ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From Jack.Jansen@cwi.nl Wed Mar 3 10:22:25 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 03 Mar 1999 11:22:25 +0100 Subject: [Pythonmac-SIG] Re: new EasyDialogs In-Reply-To: Message by "Steven D. Majewski" , Tue, 2 Mar 1999 12:52:50 -0500 (EST) , Message-ID: Recently, "Steven D. Majewski" said: > I'ld like to avoid complicating the MacPython programming process > with a lot of Gestalt calls and the like. > > Perhaps we should make a break: leave the current toolbox shared > libs as legacy support -- if you need you can still write Mac Python > code for the widest Mac OS legacy systems, but start on a set of > Win2, Dlg2, etc. interfaces, also targeting Carbon compatability. > > I think it likely that the Mac Python programmer would choose to > either program for the new interfaces or the old, but if you wanted > to handle both optionally, you could "try: import Win2; > except: import Win" . The toolbox modules aren't so much a problem: since I use bgen for creating the modules from the C header files they are already slowly but surely going towards the Appearance Manager calls. The problem I was thinking of is actually _using_ the new calls in modules like FrameWork or programs like EditPythonPrefs. Once we start doing this Python becomes quite a bit less functional on non-appearance machines. Does anyone happen to know whether the appearance manager is available for older machines and, if it is, whether it is freely distributable? -- 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 From A.M.INGRALDI@larc.nasa.gov Wed Mar 3 13:30:18 1999 From: A.M.INGRALDI@larc.nasa.gov (Anthony M. Ingraldi) Date: Wed, 03 Mar 1999 08:30:18 -0500 Subject: [Pythonmac-SIG] Re: new EasyDialogs Message-ID: <199903031330.IAA05791@express.larc.nasa.gov> > > Does anyone happen to know whether the appearance manager is available > for older machines and, if it is, whether it is freely distributable? The Appearance Manager SDK is available for downloading at ftp://ftp.apple.com/developer/Development_Kits/Appearance_SDK_1.0.3_v1.0.1.s it.hqx The SDK includes the Appearance Extension and Control Panel and the README implies that the software can be bundled with applications. It also makes reference to installation on 7.x systems. I know it works with System 7.5.5 because I used to use it before I upgraded to 8.5.1. -- Tony Ingraldi A.M.INGRALDI@LaRC.NASA.GOV Phone : (757) 864-3039 Fax : (757) 864-7892 From joe@strout.net Wed Mar 3 16:42:08 1999 From: joe@strout.net (Joseph J. Strout) Date: Wed, 3 Mar 1999 08:42:08 -0800 Subject: [Pythonmac-SIG] Re: new EasyDialogs In-Reply-To: References: Message by "Steven D. Majewski" , Tue, 2 Mar 1999 12:52:50 -0500 (EST) , Message-ID: At 2:22 AM -0800 03-03-99, Jack Jansen wrote: >The problem I was thinking of is actually _using_ the new calls in >modules like FrameWork or programs like EditPythonPrefs. Once we start >doing this Python becomes quite a bit less functional on >non-appearance machines. I think the first step is to make the AM (and NavServices, etc.) calls available to Python programmers. Those like me, who are using it in an 8.5-only environment, can immediately make use of them for writing AM-savvy apps. Whether, when, and how to incorporate those calls into the core Python utilities is a separate issue. >Does anyone happen to know whether the appearance manager is available >for older machines and, if it is, whether it is freely distributable? It is, and it is. IIRC, it is available as an extension for MacOS 7.5 or later. I didn't like it much when I was using 7.5 (a few months ago), though, but that was just me -- most people seemed to tolerate it. John Stiles, emulation guru of emulation.net, has packed up the Appearance Manager in a neat downloadable package: http://www.emulation.net/nintendo/appearance.sit.hqx Cheers, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From joe@strout.net Wed Mar 3 20:41:19 1999 From: joe@strout.net (Joseph J. Strout) Date: Wed, 3 Mar 1999 12:41:19 -0800 Subject: [Pythonmac-SIG] disabling menus in FrameWork/W? Message-ID: I'm trying to find a simple way to disable menus in a FrameWork app when my custom window is frontmost. I thought I knew what was going on when I found FrameWork.MenuBar.fixmenudimstate; it's looking for somebody to have a domenu_whatever method defined, and enables the menu item if so, else disables it. "Aha!" thought I, "we just need to check whether the domenu_whatever member is actually something other than None; if it's None, then we'll ignore it." The trouble is that it didn't work. In fact no amount of changes I make to fixmenudimstate seem to have any effect at all; but I can't figure out what in the IDE might be overriding it, or how the menu states might be getting updated. What I'd really like is to be able to do something like this: >>> import W >>> w = W.Window( (40,40,200,200), "spam") >>> w.open() >>> w.domenu_close = None # disable "close" for this window! ...but I'm stumped. Any ideas? Thanks, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From joe@strout.net Wed Mar 3 23:17:05 1999 From: joe@strout.net (Joseph J. Strout) Date: Wed, 3 Mar 1999 15:17:05 -0800 Subject: [Pythonmac-SIG] whither time.strptime? Message-ID: Both time.__doc__ and the library reference manual claim that there should be a time.strptime: strptime() -- parse string to time tuple according to format specification But it doesn't exist! There's a strftime, but its partner strptime is just plain missing from my distribution (1.5.2b1). I don't know if this is a problem with MacPython, or with Python in general, but I thought I should draw some attention to it. (Where would I file an official bug report?) Thanks, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From just@letterror.com Wed Mar 3 23:24:06 1999 From: just@letterror.com (Just van Rossum) Date: Thu, 4 Mar 1999 00:24:06 +0100 Subject: [Pythonmac-SIG] disabling menus in FrameWork/W? In-Reply-To: Message-ID: At 12:41 PM -0800 3/3/99, Joseph J. Strout wrote: >I'm trying to find a simple way to disable menus in a FrameWork app when my >custom window is frontmost. I thought I knew what was going on when I >found FrameWork.MenuBar.fixmenudimstate; it's looking for somebody to have >a domenu_whatever method defined, and enables the menu item if so, else >disables it. > >"Aha!" thought I, "we just need to check whether the domenu_whatever member >is actually something other than None; if it's None, then we'll ignore it." >The trouble is that it didn't work. In fact no amount of changes I make >to fixmenudimstate seem to have any effect at all; but I can't figure out >what in the IDE might be overriding it, or how the menu states might be >getting updated. > >What I'd really like is to be able to do something like this: > >>>> import W >>>> w = W.Window( (40,40,200,200), "spam") >>>> w.open() >>>> w.domenu_close = None # disable "close" for this window! > >...but I'm stumped. Any ideas? Ah, with W, you can define a method can_close(), which should return true or false: def can_close(self, menuitem): return 0 This should do nicely, together with your Wwindows.py patch. With FrameWork, I forgot... Just From savageb@pacbell.net Thu Mar 4 03:51:38 1999 From: savageb@pacbell.net (savageb) Date: Wed, 03 Mar 1999 19:51:38 -0800 Subject: [Pythonmac-SIG] whither time.strptime? Message-ID: <0F810036JXE4LZ@mta3.snfc21.pbi.net> Joe, I'm really glad you brought this up. I found the 'strptime' module (though I don't have the URL here -- it is at work), but I am very interested in seeing the other time modules available for the Mac. I tried the 'strptime' module on my Mac, and it worked, but the more interesting time modules available with Zope seem to be dependant upon the 'mxtime' module which needs to be compiled. http://starship.skyport.net/~lemburg/mxDateTime.html The 'strptime' module does as the time module suggests (the opposite of strftime) but mxDateTime includes strptime *and* adds ISOdate formatting, and (especially interesting) the ability to add times and talk about intervals, so you could say that >> now() + RelativeDateTime(weeks=+2) this example is from the URL above: >>while 1: >> d = Date(2000,1,1) - now() >> print 'Y2000... time left: %2i days %2i hours ' >> '%2i minutes %2i seconds\r' % \ >> (d.day,d.hour,d.minute,d.second), >> sleep(1) I know I personally could use this functionality immediately. Unfortunately I don't know anything about compiling C extensions. If someone were to compile this module I would greatly appreciate the opportunity to download it. Bob ---------- >From: "Joseph J. Strout" >To: Python-Mac SIG >Subject: [Pythonmac-SIG] whither time.strptime? >Date: Wed, Mar 3, 1999, 3:17 PM > > Both time.__doc__ and the library reference manual claim that there should > be a time.strptime: > > strptime() -- parse string to time tuple according to format specification > > But it doesn't exist! There's a strftime, but its partner strptime is just > plain missing from my distribution (1.5.2b1). I don't know if this is a > problem with MacPython, or with Python in general, but I thought I should > draw some attention to it. (Where would I file an official bug report?) > > Thanks, > -- Joe > ,------------------------------------------------------------------. > | Joseph J. Strout Biocomputing -- The Salk Institute | > | joe@strout.net http://www.strout.net | > `------------------------------------------------------------------' > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://www.python.org/mailman/listinfo/pythonmac-sig > From Jack.Jansen@cwi.nl Thu Mar 4 11:23:49 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 04 Mar 1999 12:23:49 +0100 Subject: [Pythonmac-SIG] Re: new EasyDialogs In-Reply-To: Message by "Joseph J. Strout" , Wed, 3 Mar 1999 08:42:08 -0800 , Message-ID: Recently, "Joseph J. Strout" said: > I think the first step is to make the AM (and NavServices, etc.) calls > available to Python programmers. Those like me, who are using it in an > 8.5-only environment, can immediately make use of them for writing AM-savvy > apps. I know that some of the AM calls are already included in the various toolbox modules, as they are bgen-generated. Could people who are more AM-versed than me have a look at what is already in the current (152b1) distribution, and what essential bits are missing? NavServices is a bit of a problem, because a lot of the communication goes through a big structure, with callbacks, etc. I'll definitely want to create an interface to this some time, but it'll need a bit of thought before I start hacking code. -- 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 From joe@strout.net Thu Mar 4 16:24:08 1999 From: joe@strout.net (Joseph J. Strout) Date: Thu, 4 Mar 1999 08:24:08 -0800 Subject: [Pythonmac-SIG] whither time.strptime? In-Reply-To: <0F810036JXE4LZ@mta3.snfc21.pbi.net> Message-ID: At 7:51 PM -0800 03/03/99, savageb wrote: >I'm really glad you brought this up. I found the 'strptime' module (though I >don't have the URL here -- it is at work), but I am very interested in >seeing the other time modules available for the Mac. But I'm confused -- from what I can tell (from docs and docstrings), strptime isn't supposed to be a module, it's supposed to be a function within the time module. Jack? Any idea what's the deal with this? >... the more interesting time modules >available with Zope seem to be dependant upon the 'mxtime' module which >needs to be compiled. > >http://starship.skyport.net/~lemburg/mxDateTime.html > >I know I personally could use this functionality immediately. Unfortunately >I don't know anything about compiling C extensions. If someone were to >compile this module I would greatly appreciate the opportunity to download >it. Well, I can probably do it -- though note that you can do relative times and intervals with the standard time module as well; there's really no reason to need a new compiled module for that. But if nobody else volunteers, I'll try to compile this for you -- but it probably won't be till next week, as the rest of this week is quite busy for me. Cheers, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From billpy@mousa.demon.co.uk Thu Mar 4 20:01:41 1999 From: billpy@mousa.demon.co.uk (Bill Bedford) Date: Thu, 4 Mar 1999 20:01:41 +0000 Subject: [Pythonmac-SIG] gensuitemodule, Filemaker In-Reply-To: <199902051322.OAA24050@kalvermarkt.denhaag.dataweb.net> Message-ID: <992442305691747674430@mousa.demon.co.uk> At 2:28 pm +0200 05/02/99, Erik van Blokland wrote: >Is there someone in this SIG who has experience with gensuitemodule and >FileMaker Pro? Letting gensuitemodule sniff at FileMaker results >FileMaker_Suite.py, URL_Suite.py and something called (shudder!) >Subset_of_the_Core_2c__Table_2c. > You can ignore the last one and use Table_Suite.py which is in Mac:Lib:Scripting. -- It's just an extention of the Standard suite that adds classes and properties relevent to databases and spreadsheets. Bill Bedford Owner Brit_Rail-L mailto://autoshare@mousa.demon.co.uk For the history of Railways in Britain. From sdm7g@virginia.edu Thu Mar 4 21:35:48 1999 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Thu, 4 Mar 1999 16:35:48 -0500 (EST) Subject: [Pythonmac-SIG] Re: new EasyDialogs In-Reply-To: Message-ID: On Thu, 4 Mar 1999, Jack Jansen wrote: | |Recently, "Joseph J. Strout" said: |> I think the first step is to make the AM (and NavServices, etc.) calls |> available to Python programmers. Those like me, who are using it in an |> 8.5-only environment, can immediately make use of them for writing AM-savvy |> apps. | |I know that some of the AM calls are already included in the various |toolbox modules, as they are bgen-generated. Could people who are more |AM-versed than me have a look at what is already in the current |(152b1) distribution, and what essential bits are missing? | I couldn't find any DrawTheme*, GetTheme*, SetTheme* calls anywhere in toolboxmodules.prj. ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From Jack.Jansen@cwi.nl Thu Mar 4 21:38:11 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 04 Mar 1999 22:38:11 +0100 Subject: [Pythonmac-SIG] disabling menus in FrameWork/W? In-Reply-To: Message by Just van Rossum , Thu, 4 Mar 1999 00:24:06 +0100 , Message-ID: Recently, Just van Rossum said: > Ah, with W, you can define a method can_close(), which should return true > or false: > > def can_close(self, menuitem): > return 0 > > This should do nicely, together with your Wwindows.py patch. > > With FrameWork, I forgot... FrameWork sort-of has two opinions on how menus should be enabled. Originally it provided no help with enabling/disabling menus and you had to do it all yourself. Then Just contributed the domenu_* automatic routing of menus to the frontmost window, but apparently the canmenu_ stuff got lost somewhere along the way. It should be easy to add in, just call the appropriate canmenu_XXX() method of either the window or application (if it exists) in fixmenudimstate(). I'll gladly accept these fixes, of course:-) The real way to do this, IMNSHO, is to add an extra level of abstraction. In a framework-derived module I use (that isn't fit to be shared, unfortunately) I map menuitems to abstract thnigs called "commands", and each window has a dictionary mapping commands to callbacks. There's such a dictionary for the application too (and even for other things like window groups and currently-active-widget). Windows can now easily disable commands by removing entries in the dictionary when the command has to be disabled. Moreover, not only menus map to commands, but buttons can too (as in toolbars), or appleevents (and you can even address them to specific windows or other objects). The extra indirection also allows you to easily play with menubar layout: moving entries from one menu to another have no impact on the rest of the application. And before we go into the eventloop, if we know that something in the command structure has possibly changed, we simply run along the menus and disable each one for which the command-dict hierarchy currently doesn't have an entry. -- 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 From Jack.Jansen@cwi.nl Thu Mar 4 21:42:08 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 04 Mar 1999 22:42:08 +0100 Subject: [Pythonmac-SIG] whither time.strptime? In-Reply-To: Message by "Joseph J. Strout" , Thu, 4 Mar 1999 08:24:08 -0800 , Message-ID: Recently, "Joseph J. Strout" said: > But I'm confused -- from what I can tell (from docs and docstrings), > strptime isn't supposed to be a module, it's supposed to be a function > within the time module. > > Jack? Any idea what's the deal with this? Simple: the MetroWerks C library doesn't have strptime. If someone has a distributable strptime() C function for me I'll gladly add it. Otherwise we'll have to wait until MW put it in their C library... -- 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 From joe@strout.net Thu Mar 4 21:59:21 1999 From: joe@strout.net (Joseph J. Strout) Date: Thu, 4 Mar 1999 13:59:21 -0800 Subject: [Pythonmac-SIG] disabling menus in FrameWork/W? In-Reply-To: References: Message by Just van Rossum , Thu, 4 Mar 1999 00:24:06 +0100 , Message-ID: At 1:38 PM -0800 03/04/99, Jack Jansen wrote: >The real way to do this, IMNSHO, is to add an extra level of >abstraction. ... map menuitems to abstract thnigs called >"commands", and each window has a dictionary mapping commands to >callbacks. There's such a dictionary for the application too (and even >for other things like window groups and >currently-active-widget).... >Moreover, not only menus map to commands, but buttons can >too (as in toolbars), or appleevents (and you can even address them to >specific windows or other objects). Makes sense to me. That's the way some C++ frameworks I've seen work. It works especially well when building the interface with ResEdit; you can embed command numbers in menu and button labels, or widget names. Then map these command numbers to action in the program (and strip them off the menus/buttons before displaying, of course). Sounds like a fairly major rewrite, though. In my book, it's way lower in priority than, say, being able to test/run Mac apps from the IDE. Cheers, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From Jack.Jansen@cwi.nl Thu Mar 4 22:03:12 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 04 Mar 1999 23:03:12 +0100 Subject: [Pythonmac-SIG] Living dangerously or not? Message-ID: The appearance manager talk recently has reminded me of something that probably not too many Pythoneers are aware of, but there are quite a few toolbox calls that are exported to Python even when they're not available on the current machine. The new appearance calls in the various modules like Menu and Dlg are examples of this: the module has AppearanceLib weakly linked, otherwise the module won't load on a machine that has no appearance support. If, however, on such a machine you subsequently try to call, say, SetMenuKeyModifiers the interpreter will happily jump to address 0 and crash. Something similar holds for trying to access quicktime 3 functions on a quicktime 2.5 machine, for instance. Or on a machine with no quicktime at all:-) I _could_ do something about this, by adding code to the bgenned modules that checks that the function actually is non-zero before trying to call it, but this'll incur an overhead for each and every call. And, since noone has yet flamed me this behaviour it has apparently gone unnoticed until now, I'm a bit reluctant to put work in something that hasn't bothered me, and will make everything slower too.... -- 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 From Jack.Jansen@cwi.nl Thu Mar 4 22:08:23 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 04 Mar 1999 23:08:23 +0100 Subject: [Pythonmac-SIG] Re: new EasyDialogs In-Reply-To: Message by "Steven D. Majewski" , Thu, 4 Mar 1999 16:35:48 -0500 (EST) , Message-ID: Recently, "Steven D. Majewski" said: > I couldn't find any DrawTheme*, GetTheme*, SetTheme* calls anywhere > in toolboxmodules.prj. Ah, that's Appearance.h, and it looks reasonably simple. I'll see what I can do. -- 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 From sdm7g@virginia.edu Thu Mar 4 22:09:27 1999 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Thu, 4 Mar 1999 17:09:27 -0500 (EST) Subject: [Pythonmac-SIG] Re: new EasyDialogs In-Reply-To: Message-ID: On Thu, 4 Mar 1999, Steven D. Majewski wrote: || ||I know that some of the AM calls are already included in the various ||toolbox modules, as they are bgen-generated. Could people who are more ||AM-versed than me have a look at what is already in the current ||(152b1) distribution, and what essential bits are missing? || | |I couldn't find any DrawTheme*, GetTheme*, SetTheme* calls anywhere |in toolboxmodules.prj. However, I'm not very AM-versed yet, and on second look, it doesn't look like you need those low level calls if you're using the new controls. ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From joe@strout.net Thu Mar 4 22:29:02 1999 From: joe@strout.net (Joseph J. Strout) Date: Thu, 4 Mar 1999 14:29:02 -0800 Subject: [Pythonmac-SIG] Living dangerously or not? In-Reply-To: Message-ID: At 2:03 PM -0800 03/04/99, Jack Jansen wrote: >If, however, on such a machine >you subsequently try to call, say, SetMenuKeyModifiers the interpreter >will happily jump to address 0 and crash. Something similar holds for >trying to access quicktime 3 functions on a quicktime 2.5 machine, for >instance. Or on a machine with no quicktime at all:-) Hmm. >I _could_ do something about this, by adding code to the bgenned >modules that checks that the function actually is non-zero before >trying to call it, but this'll incur an overhead for each and every >call. And, since noone has yet flamed me this behaviour it has >apparently gone unnoticed until now, I'm a bit reluctant to put work in >something that hasn't bothered me, and will make everything slower >too.... There's already quite a bit of overhead for a system call -- probably more so when it's a shared library function. Would an additional compare add that much? It'd be one assembly instruction, I'd think... "if (func) func(args); else throwFuncUnavailable();" or some such, right? I think it'd be better to do it. One of the chief attractions of Python is that it's harder to crash your machine in it than in, say, C. This sounds like a good opportunity to keep it that way. If I'm outvoted on this, then we should at least provide, document, and encourage the use of functions for determining whether certain modules are available. Cheers, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From sdm7g@virginia.edu Thu Mar 4 23:36:12 1999 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Thu, 4 Mar 1999 18:36:12 -0500 (EST) Subject: [Pythonmac-SIG] Living dangerously or not? In-Reply-To: Message-ID: I suspect: Most developers and serious Mac users are up to at least 8.0. You haven't got most of the 8.5 calls wrapped yet, so 8.0 vs 8.5 hasn't been an issue. ( You need to have the Universal Interfaces 3.2 for your headers to have those calls, and I don't believe CW4 shipped with those -- you have to download them from Apple. ) Most Python users aren't attempting most of those feature yet. ( I know I'm just trying to figure them out myself, and as I noted when I mentioned macintosh C v2.0 -- most of the mac programming books don't cover these features yet, so they are likely to be overlooked. ) So I'm not sure we can count on luck lasting! I tend to agree with Joe -- there is so much overhead in a Python function call, that a check for NULL in the C code would likely be unnoticed. I would LIKE Python to be uncrashable -- as it is now, you can certainly find ways of crashing it with the toolbox functions, so it's not near ideal, but I'ld still like to minimize the dangerous cases, if possible. I already mentioned the alternative of having Win|Win2, Ctl|Ctl2 modules -- the appropriate gestalts calls could be done on import of the *2 modules. But that only handles a single split for 8.5 or greater. I suppose the other trick would be some sort of fixup done on either module init or during import. On module init (in C) it would have to test a list of pairs of (C-entry-point-symbol, Python-function) and revector the Python functions for which C-entry-point is NULL to an error function. (In XlispStat, you can unload as well as load dynamic libraries, and when you unload a library, the symbols get mapped to a function that reports that the library is unloaded.) It could also be done on import from Python with a wrapper -- sort of a specialized Bastion -- that would need a table of functions to export (or exclude) for a given set of Gestalt return values. Is Gestalt callable from Python ? I said before I'ld like to avoid MacPython programmers having to worry about it, but in this case, it would be low level and mostly invisible. The NULL test sounds easier, but it defers the error until you try to call the function. Not finding the symbol might be better and easier to test for. On the other hand, I don't think I'm going to be ambitious enough to try to write Python code for all the options -- I'll be happy to say "Requires 8.5 of better" if MacPython can give a reasonable indication that that's the problem. ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From cwalker@pixar.com Fri Mar 5 01:37:03 1999 From: cwalker@pixar.com (Chris Walker) Date: Thu, 4 Mar 1999 17:37:03 -0800 Subject: [Pythonmac-SIG] os.path.join() Message-ID: I'm writing a program to copy many files of certain types to a network volume. I'm using os.path.join() to attach a directory to the front of the absolute paths of the files to mimic the directory structure on the network volume. The net volume is mounted as 'cwalker', and the drive is called 'Macintosh HD'. >>> import os >>> os.path.join('cwalker', 'Macintosh HD:Devel:Python:myscript') 'Macintosh HD:Devel:Python:myscript' I'm using string.join() to get around it for now, but os.path.join() seems like the cross-platform, 'right' way to do it. What I'd like it to return is 'cwalker:Macintosh HD:Devel:Python:myscript'. Is this the way it's supposed to behave? If so, why? --- Chris Walker Pixar Animation Studios UNIX Systems Administrator (510) 620-3736 cwalker@pixar.com If it wasn't for disappointment, I wouldn't have any appointments. From savageb@pacbell.net Fri Mar 5 05:53:55 1999 From: savageb@pacbell.net (savageb) Date: Thu, 04 Mar 1999 21:53:55 -0800 Subject: [Pythonmac-SIG] whither time.strptime? Message-ID: <199903050553.VAA20051@mail-gw5.pacbell.net> >>... the more interesting time modules >>available with Zope seem to be dependant upon the 'mxtime' module which >>needs to be compiled. >> >>http://starship.skyport.net/~lemburg/mxDateTime.html >> > Well, I can probably do it -- though note that you can do relative times > and intervals with the standard time module as well; there's really no > reason to need a new compiled module for that. But if nobody else > volunteers, I'll try to compile this for you -- but it probably won't be > till next week, as the rest of this week is quite busy for me. > Hmm... you mean convert a date into seconds (combination of strptime & time.mktime) then subtract then divide the result by something? That will get me working in the meantime. I downloaded GCC for the Mac, if I can figure out how to compile mxDateTime tomorrow I will send word that you don't have to bother, as well as putting the binary someplace accessible for others to download if they want it. If it turns out that I flounder for hours with no idea of what I'm doing, and never accomplish a damn thing, I won't be mentioning it on the list. In other words, assume I'm incompetent unless you hear otherwise. ~bob From just@letterror.com Fri Mar 5 12:47:15 1999 From: just@letterror.com (Just van Rossum) Date: Fri, 5 Mar 1999 13:47:15 +0100 Subject: [Pythonmac-SIG] os.path.join() In-Reply-To: Message-ID: At 5:37 PM -0800 3/4/99, Chris Walker wrote: >I'm writing a program to copy many files of certain types to a network volume. >I'm using os.path.join() to attach a directory to the front of the absolute >paths of the files to mimic the directory structure on the network volume. > >The net volume is mounted as 'cwalker', and the drive is called 'Macintosh >HD'. > >>>> import os >>>> os.path.join('cwalker', 'Macintosh HD:Devel:Python:myscript') >'Macintosh HD:Devel:Python:myscript' > >I'm using string.join() to get around it for now, but os.path.join() seems >like >the cross-platform, 'right' way to do it. > >What I'd like it to return is 'cwalker:Macintosh >HD:Devel:Python:myscript'. Is >this the way it's supposed to behave? If so, why? Two things: - the path to a root directory needs to end with a colon - a relative path has to start with a colon If your ariginal paths are correct, os.path.join() works like a charm: >>> os.path.join('cwalker:', ':Macintosh HD:Devel:Python:myscript') 'cwalker:Macintosh HD:Devel:Python:myscript' Just From joe@strout.net Fri Mar 5 16:05:09 1999 From: joe@strout.net (Joseph J. Strout) Date: Fri, 5 Mar 1999 09:05:09 -0700 Subject: [Pythonmac-SIG] whither time.strptime? In-Reply-To: <199903050553.VAA20051@mail-gw5.pacbell.net> Message-ID: At 9:53 PM -0800 03/04/99, savageb wrote: >Hmm... you mean convert a date into seconds (combination of strptime & >time.mktime) then subtract then divide the result by something? That will >get me working in the meantime. Yes, dates in Python are already in the form of seconds since Jan 1, 1900. Just define MINUTE=60, HOUR=60*MINUTE, DAY=24*HOUR, etc. Then you can do relative dates by, for example, -4*DAY. >I downloaded GCC for the Mac, if I can figure out how to compile mxDateTime >tomorrow I will send word that you don't have to bother, as well as putting >the binary someplace accessible for others to download if they want it. Don't bother -- it's going to be *very* difficult to make proper MacOS shared libraries with GCC, I think, and anyway I've already done it. I'm just working with Marc-Andre to sort out a few issues and make sure the conversion from local to universal time is correct. Cheers, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From cwalker@pixar.com Fri Mar 5 20:07:26 1999 From: cwalker@pixar.com (Chris Walker) Date: Fri, 5 Mar 1999 12:07:26 -0800 Subject: [Pythonmac-SIG] findertools.copy() Message-ID: Thanks again for all of your help. Here's another one. Copying the Prefs folder to another volume and get the following exception: >>> import findertools >>> findertools.copy('Macintosh HD:System Folder:Preferences', 'cwalker:') Traceback (innermost last): File "", line 1, in ? File "Macintosh HD:Utilities:Python 1.5.1:Mac:Lib:findertools.py", line 49, in copy return finder.copy_to(dst_alias, _from=[src_alias]) File "Macintosh HD:Utilities:Python 1.5.1:Mac:Lib:lib-scripting:Finder_7_0_Suite.py", line 52, in copy_to _reply, _arguments, _attributes = self.send(_code, _subcode, File "Macintosh HD:Utilities:Python 1.5.1:Mac:Lib:lib-toolbox:aetools.py", line 174, in send return self.sendevent(self.newevent(code, subcode, parameters, attributes)) File "Macintosh HD:Utilities:Python 1.5.1:Mac:Lib:lib-toolbox:aetools.py", line 167, in sendevent reply = event.AESend(self.send_flags, self.send_priority, Mac OS Error: (-1712, 'the AppleEvent timed out') Yet the copy does not fail. I'm assuming that the AppleEvent goes through, but the script is waiting for a response. Is it safe to just 'except: pass' this excption? TIA --- Chris Walker Pixar Animation Studios UNIX Systems Administrator (510) 620-3736 cwalker@pixar.com If it wasn't for disappointment, I wouldn't have any appointments. From sdm7g@virginia.edu Fri Mar 5 20:27:54 1999 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Fri, 5 Mar 1999 15:27:54 -0500 (EST) Subject: [Pythonmac-SIG] OS8/AppearanceMgr-savvy ProgressBar [was: new EasyDialogs] In-Reply-To: Message-ID: To add an OS8/AppearanceMgr-savvy Progress indicator to a dialog, you need to add a CNTL resource, with a ProcID that is the CDEF for the progress indicator, and put this CNTL into the DITL for the DLOG: DLOG -> DITL -> CNTL, CNTL.ProcID = CDEF for Progress Indicator = 80 ( 5 * 16 ) The visual update becomes a lot simpler. Once the control max is set, you just have to call SetControlValue(). Having to require new resources for Python code snippets is a bit of a pain (and having things defined in a separate resource isn't as much of a gain for Python as it is for compiled C/C++). I was trying to figure out how to do it all from Code but I got stumped in a couple of places. AppendDITL can add items to the dialog, but the have to be in a DITL, and the path to get from an object (like the Control returned by NewControl) to a (DITL) resource isn't very clear. I found a way that seems to punt around that, but I'm not sure how kosher it is. I get the user-item from the existing progress dialog: useri = self.d.GetDialogItem(3) create a new control in the dialog window with the rect from that user-item: self.c = Ctl.NewControl( self.d, useri[2],"ProgressBar", 1, 0, 0, self.maxval, 80, 0 ) [ 80 is CDEF for progress indicator ) and reset the dialog item to the new control: self.d.SetDialogItem( 3, 3, self.c.as_Resource(),useri[2] ) [ second 3 indicates item is a Control. ] The last step is probably not necessary for this in Python, as the control is kept in a instance var, and you don't need to fetch it from the dialog item, however, I'm trying to see if that works in general for controls, or do you have to go back to ResEdit to do this sort of patch. ( I'll have to try it on a control that has some event interaction to find out though, as progress indicator is just output -- which is why that last step is prob. not required.) Here's an unguaranteed, minimally tested addition to the newdlg code that puts up a Real OS8 progress bar. ( I also changed the test code to call AMProgressBar() creator rather than ProgressBar(). ) import Ctl class AMProgressBar(ProgressBar): def __init__(self, title="Working...", maxval=100, label="",id=259 ): self.maxval = maxval self.curval = 0 self.d = GetNewDialog(id, -1) useri = self.d.GetDialogItem(3) self.c = Ctl.NewControl( self.d, useri[2],"ProgressBar", 1, 0, 0, self.maxval, 80, 0 ) self.d.SetDialogItem( 3, 3, self.c.as_Resource(),useri[2] ) self.title(title) self.label(label) self.d.DrawDialog() self.appsw = MacOS.SchedParams(1, 0) def _update(self,value): self.c.SetControlValue(value) # Test for cancel button if Handle1Event( self.d, None, 1 ) == 1: raise KeyboardInterrupt, 'Cancel' ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From joe@strout.net Fri Mar 5 20:57:43 1999 From: joe@strout.net (Joseph J. Strout) Date: Fri, 5 Mar 1999 12:57:43 -0800 Subject: [Pythonmac-SIG] findertools.copy() In-Reply-To: Message-ID: At 12:07 PM -0800 03/05/99, Chris Walker wrote: >Thanks again for all of your help. Here's another one. Copying the Prefs >folder to another volume and get the following exception: > >>>> import findertools >>>> findertools.copy('Macintosh HD:System Folder:Preferences', 'cwalker:') Why are you using findertools? Wouldn't it be easier to use macostools.copy? That's what I use for my backup script (copies all newly modified files to the server), and it seems to work just fine. The only caveat is that, when it copies folders, it doesn't seem to also copy the contents -- you have to do that separately. Cheers, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From sdm7g@virginia.edu Fri Mar 5 21:12:40 1999 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Fri, 5 Mar 1999 16:12:40 -0500 (EST) Subject: [Pythonmac-SIG] [Bug] control.GetControlTitle() Message-ID: Just ran into this. control.SetControlTitle('name') works ok, but control.GetControlTitle() gives the error: TypeError: function requires exactly 1 argument; 0 given and in fact, the doc says it's the same as SetControlTitle: >>> control.GetControlTitle.__doc__ '(Str255 title) -> None' and calling it with an arg returns None, so it's non-functional. [ BTW: Tried the SetDialogItem trick with a real control and got mixed results -- the old control seems to persist when DialogDraw is called, even though GetDialogItem returns the new control. ] ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From sdm7g@virginia.edu Sat Mar 6 00:22:11 1999 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Fri, 5 Mar 1999 19:22:11 -0500 (EST) Subject: [Pythonmac-SIG] Latest EasyDialogs Message-ID: Latest snap of new EasyDialog: http://galen.med.virginia.edu/~sdm7g/Python/Mac/newdlg.py & /newpy.res.hqx or in ftp://ftp.virginia.edu/public_access/fromUVA/sdm7g Has the OS8 progress look and uses that in test() function. ( Most likely only works on OS8 with Appearance Mgr or later. ) Uses ModalDialog with a filter proc for Movable Modal Dialogs. ( The other code is still there -- the defaults have been changed. I'm trying to figure out the best options. ) BTW: I noticed the ModalDialog filter function should not return ZERO for false, but should return None. Looks like returning ZERO from Python will cause the C callback to return a 1 as True with the Item number set to 0. ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From Jack.Jansen@cwi.nl Sat Mar 6 12:47:01 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Sat, 06 Mar 1999 13:47:01 +0100 Subject: [Pythonmac-SIG] [Bug] control.GetControlTitle() In-Reply-To: Message by "Steven D. Majewski" , Fri, 5 Mar 1999 16:12:40 -0500 (EST) , Message-ID: Recently, "Steven D. Majewski" said: > > Just ran into this. > > control.SetControlTitle('name') works ok, but > control.GetControlTitle() gives the error: > > TypeError: function requires exactly 1 argument; 0 given > > and in fact, the doc says it's the same as SetControlTitle: > > >>> control.GetControlTitle.__doc__ > '(Str255 title) -> None' Fixed in the next release. -- 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 From JWight@bigfoot.com Mon Mar 8 01:58:14 1999 From: JWight@bigfoot.com (Jonathan Wight) Date: Sun, 07 Mar 1999 20:58:14 -0500 Subject: [Pythonmac-SIG] MacPython IDE doesn't reload edited files Message-ID: <199903080157.UAA28514@camel7.mindspring.com> I've been doing some Python development using Win95 (at work) and now I've taken the code home and tried to develop it further using the Mac IDE for Python (V1.0b1). When I make modifications to a python module and save it the IDE refuses to run the new version and persists in running the older version of the module. The only way to force the IDE to reload the file is to quit it and re-launch it. YUK. I'm sure this isn't correct behaviour Am I the only one this is happening to? Thanks. Jon. From savageb@pacbell.net Mon Mar 8 04:29:01 1999 From: savageb@pacbell.net (savageb) Date: Sun, 07 Mar 1999 20:29:01 -0800 Subject: [Pythonmac-SIG] MacPython IDE doesn't reload edited files Message-ID: <199903080429.UAA28233@mail-gw2.pacbell.net> > When I make modifications to a python module and save it the IDE refuses to > run the new version and persists in running the older version of the module. > The only way to force the IDE to reload the file is to quit it and re-launch > it. YUK. > > I'm sure this isn't correct behaviour Am I the only one this is happening > to? > If I understand you correctly the only thing is you have to 'reload' the module. Since Python is compiled on the fly, it compliles a module and holds onto that in memory. changing the file doesn't change the version in memory. What you need to do is specifically ask the compiler to reload the module: reload module_name (I hope I am understanding you correctly). Good luck, Bob From joe@strout.net Mon Mar 8 04:30:58 1999 From: joe@strout.net (Joseph J. Strout) Date: Sun, 7 Mar 1999 20:30:58 -0800 Subject: [Pythonmac-SIG] MacPython IDE doesn't reload edited files In-Reply-To: <199903080157.UAA28514@camel7.mindspring.com> Message-ID: I find that the IDE will reload your module if you Run it again. (It doesn't matter whether you save it or not.) This is obvious if you have a single-module project, less obvious for more complex projects. Suppose your main program is in A.py, which calls stuff in B.py. Simply editing B.py and saving is not enough; running A.py will run the old B, since it still has a reference to the old B data in its namespace. You have to run B (even if running B has no apparent effect, because it has no main program), and then run A. In very complex projects, where lots of modules have lots of references to other modules, it can difficult to force all the different modules to forget their references to old code. I have one project like this, where the easiest thing to do is to quit and restart the IDE. I hate that too, but I don't know what to do about it -- reloading modules has always been a pain, even in traditional console-mode Python. HTH, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From just@letterror.com Mon Mar 8 10:53:08 1999 From: just@letterror.com (Just van Rossum) Date: Mon, 8 Mar 1999 11:53:08 +0100 Subject: [Pythonmac-SIG] MacPython IDE doesn't reload edited files In-Reply-To: References: <199903080157.UAA28514@camel7.mindspring.com> Message-ID: At 8:30 PM -0800 3/7/99, Joseph J. Strout wrote: >I find that the IDE will reload your module if you Run it again. (It >doesn't matter whether you save it or not.) This is obvious if you have a >single-module project, less obvious for more complex projects. Suppose >your main program is in A.py, which calls stuff in B.py. Simply editing >B.py and saving is not enough; running A.py will run the old B, since it >still has a reference to the old B data in its namespace. You have to run >B (even if running B has no apparent effect, because it has no main >program), and then run A. You can save yourself a lot of trouble if you try to avoid from module import * imports. Usually, if module A.py does "import B", editing and running module B does what you would expect. However, if module A defines a class which subclasses from a class from B, you will need to run (or reload) A as well; otherwise the class in A would still reference the old superclass. In general, running a module is the same as reloading a module. So there are three options: - open the module and choose "Run" - select the module in the module browser and choose "Reload" - use the reload() function. I unually find the first option most convenient. >In very complex projects, where lots of modules have lots of references to >other modules, it can difficult to force all the different modules to >forget their references to old code. I have one project like this, where >the easiest thing to do is to quit and restart the IDE. I hate that too, >but I don't know what to do about it -- reloading modules has always been a >pain, even in traditional console-mode Python. There is one feature of the IDE which can help an awful lot in complex situations: you can run *parts* of classes. Just select a single method (or more) and choose "Run selection". This will update that section without creating a new class, so all existing references (even "live" objects!) will still be ok. Very powerful. I use it all the time when working on the IDE itself: I hardly ever have to restart it. Two gotchas: - if the method is stored as a callback somewhere, that callback will *not* be updated (it still references the old code) - linenumbers as stored in code objects may not be valid anymore after you edit and run preceding code. This may cause tracebacks that appear to lie. Just From Jack.Jansen@cwi.nl Mon Mar 8 14:11:25 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 08 Mar 1999 15:11:25 +0100 Subject: [Pythonmac-SIG] MacPython IDE doesn't reload edited files In-Reply-To: Message by Just van Rossum , Mon, 8 Mar 1999 11:53:08 +0100 , Message-ID: Recently, Just van Rossum said: > In general, running a module is the same as reloading a module. So there > are three options: > - open the module and choose "Run" > - select the module in the module browser and choose "Reload" > - use the reload() function. Just, when you save a module, would it be possible to look in sys.modules to see whether a module with that name is already loaded and, if so, present the user with a dialog "Do you want to reload the module?"? Or would that be too cumbersome? An alternative would be to do a reload of all modules when you hit run, or even keep a complete administration (a list of tuples (modulename, filename, modificationtime), sorted by order of import), and quickly run through this when the user "run"s reloading everything from the first changed module. -- 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 From WIGHTJ@dstm.com Mon Mar 8 14:13:03 1999 From: WIGHTJ@dstm.com (Jon Wight) Date: Mon, 8 Mar 1999 09:13:03 -0500 Subject: [Pythonmac-SIG] MacPython IDE doesn't reload edited files Message-ID: > -----Original Message----- > From: Just van Rossum [mailto:just@letterror.com] > Sent: Monday, March 08, 1999 5:53 AM > To: Joseph J. Strout; Jonathan Wight; Pythonmac-SIG@python.org > Subject: Re: [Pythonmac-SIG] MacPython IDE doesn't reload edited files > You can save yourself a lot of trouble if you try to avoid from module > import * imports. Well luckily I never use import * anyway... > Usually, if module A.py does "import B", editing and running > module B does > what you would expect. However, if module A defines a class which > subclasses from a class from B, you will need to run (or > reload) A as well; > otherwise the class in A would still reference the old superclass. Yeah, I've got a few of those in my code. Knickers! > In general, running a module is the same as reloading a > module. So there > are three options: > - open the module and choose "Run" > - select the module in the module browser and choose "Reload" > - use the reload() function. > > I unually find the first option most convenient. Unfortunately I've got a lot of modules and I don't really want to wade through them to find which I need to reload and which I don't (I'm lazy). So basically this is the old python doesn't reload problem. I was assuming this was kind of fixed in the IDE. Guess not. My current solution is to edit the files in BBEdit and then just launch the main module from the finder. Slow but it works. Oh well, thanks for your help. Jon. From just@letterror.com Mon Mar 8 15:20:34 1999 From: just@letterror.com (Just van Rossum) Date: Mon, 8 Mar 1999 16:20:34 +0100 Subject: [Pythonmac-SIG] MacPython IDE doesn't reload edited files In-Reply-To: Message-ID: At 9:13 AM -0500 3/8/99, Jon Wight wrote: >Unfortunately I've got a lot of modules and I don't really want to wade >through them to find which I need to reload and which I don't (I'm lazy). You could just reload them all... Or write a little script that does that for you. >So basically this is the old python doesn't reload problem. I was assuming >this was kind of fixed in the IDE. Guess not. ?? The IDE can't "fix" Python... It's a complicated problem: if you edit something in B.py, there is no way to know that A.py depends on it and would need reloading. >My current solution is to edit >the files in BBEdit and then just launch the main module from the finder. >Slow but it works. Please try the partial class reloading mechanism I described earlier. Just From just@letterror.com Mon Mar 8 15:24:29 1999 From: just@letterror.com (Just van Rossum) Date: Mon, 8 Mar 1999 16:24:29 +0100 Subject: [Pythonmac-SIG] MacPython IDE doesn't reload edited files In-Reply-To: References: Message by Just van Rossum , Mon, 8 Mar 1999 11:53:08 +0100 , Message-ID: At 3:11 PM +0100 3/8/99, Jack Jansen wrote: >Just, >when you save a module, would it be possible to look in sys.modules to >see whether a module with that name is already loaded and, if so, >present the user with a dialog "Do you want to reload the module?"? Or >would that be too cumbersome? It's possible, but wouldn't help much, since other modules that depend on the one being saved may still use old code. >An alternative would be to do a reload of all modules when you hit >run, Ouch! I suppose you rather mean all modules belonging to a project? I intend to add a project manager at some point, so that may be possible. >or even keep a complete administration (a list of tuples >(modulename, filename, modificationtime), sorted by order of import), >and quickly run through this when the user "run"s reloading everything >from the first changed module. That doesn't fix the problem of non-changed modules which *do* need a reload... Just From Jack.Jansen@cwi.nl Mon Mar 8 17:07:46 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 08 Mar 1999 18:07:46 +0100 Subject: [Pythonmac-SIG] MacPython IDE doesn't reload edited files In-Reply-To: Message by Just van Rossum , Mon, 8 Mar 1999 16:24:29 +0100 , Message-ID: Recently, Just van Rossum said: > > >or even keep a complete administration (a list of tuples > >(modulename, filename, modificationtime), sorted by order of import), > >and quickly run through this when the user "run"s reloading everything > >from the first changed module. > > That doesn't fix the problem of non-changed modules which *do* need a reload. > .. Hmm, that depends on the order in which you keep the list. If you add a hook to the import mechanism, and in that hook add a module to your administration _when the import finishes_ then reloading everything for which the import finished after the module that was changed should do the trick, no? A module whose import was over and done before the changed module was imported can't be affected by it, after all... -- 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 From cwalker@pixar.com Mon Mar 8 23:43:12 1999 From: cwalker@pixar.com (Chris Walker) Date: Mon, 8 Mar 1999 15:43:12 -0800 Subject: [Pythonmac-SIG] macostools.copy() Message-ID: More questions... I get the following exception when using macostools.copy() Traceback (innermost last): File "Macintosh HD:Documents:Devel:Python:test.py", line 52, in visit macostools.copy(fullpath, destFile) File "::Mac:Lib:macostools.py", line 77, in copy dstfss = macfs.FSSpec(dst) ValueError: (-50, 'error in user parameter list') Does anyone know what might be causing this? --- Chris Walker Pixar Animation Studios UNIX Systems Administrator (510) 620-3736 cwalker@pixar.com If it wasn't for disappointment, I wouldn't have any appointments. From joe@strout.net Mon Mar 8 23:57:28 1999 From: joe@strout.net (Joseph J. Strout) Date: Mon, 8 Mar 1999 15:57:28 -0800 Subject: [Pythonmac-SIG] macostools.copy() In-Reply-To: Message-ID: At 3:43 PM -0800 03/08/99, Chris Walker wrote: >More questions... I get the following exception when using macostools.copy() > >Traceback (innermost last): > File "Macintosh HD:Documents:Devel:Python:test.py", line 52, in visit > macostools.copy(fullpath, destFile) > File "::Mac:Lib:macostools.py", line 77, in copy > dstfss = macfs.FSSpec(dst) >ValueError: (-50, 'error in user parameter list') > >Does anyone know what might be causing this? It'd be easier to guess if you showed us what destFile is. Most likely it's not a valid pathname. Cheers, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From sdm7g@virginia.edu Tue Mar 9 00:49:40 1999 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Mon, 8 Mar 1999 19:49:40 -0500 (EST) Subject: [Pythonmac-SIG] macostools.copy() In-Reply-To: Message-ID: On Mon, 8 Mar 1999, Joseph J. Strout wrote: |At 3:43 PM -0800 03/08/99, Chris Walker wrote: | |>More questions... I get the following exception when using macostools.copy() |> |>Traceback (innermost last): |> File "Macintosh HD:Documents:Devel:Python:test.py", line 52, in visit |> macostools.copy(fullpath, destFile) |> File "::Mac:Lib:macostools.py", line 77, in copy |> dstfss = macfs.FSSpec(dst) |>ValueError: (-50, 'error in user parameter list') |> |>Does anyone know what might be causing this? | |It'd be easier to guess if you showed us what destFile is. Most likely |it's not a valid pathname. | Yeah -- the -50 is a Mac OS return code just being propagated by Python. I can feed macostools.copy nonsence and manage to get a -35 'no such volume' or a C library error 2 - 'no such file or directory', and with: macostools.copy( 'FUCK YOU! you rotten stinking son-of-bitch!', 'xxx' ) I even managed to make it squeak: (-37, 'there may be no bad names in the final system!') but I doubt we can guess what causes a -50 unless you tell us. ( Enjoy that last error message while you can: it may go away in a future release when the toolbox fully supports the new filesystem. ;-) ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From Jack.Jansen@cwi.nl Tue Mar 9 09:50:09 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 09 Mar 1999 10:50:09 +0100 Subject: [Pythonmac-SIG] macostools.copy() In-Reply-To: Message by "Steven D. Majewski" , Mon, 8 Mar 1999 19:49:40 -0500 (EST) , Message-ID: Recently, "Steven D. Majewski" said: > > macostools.copy( 'FUCK YOU! you rotten stinking son-of-bitch!', 'xxx' ) > > I even managed to make it squeak: > > (-37, 'there may be no bad names in the final system!') > Brilliant, brilliant, brilliant!! Unfortunately the error message is not due to some parental guidance software in MacOS that scans for bad language in filenames, it is simply due to the filename being longer than 32 (or was that 31) characters... -- 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 From A.M.INGRALDI@larc.nasa.gov Tue Mar 9 13:32:39 1999 From: A.M.INGRALDI@larc.nasa.gov (Anthony M. Ingraldi) Date: Tue, 09 Mar 1999 08:32:39 -0500 Subject: [Pythonmac-SIG] macostools.copy() Message-ID: <199903091332.IAA18758@express.larc.nasa.gov> > > macostools.copy( '**** YOU! you rotten stinking ************!', 'xxx' ) > Please keep your profanity to yourself. I don't subscribe to the list to fill my inbox with trash. -- Tony Ingraldi A.M.INGRALDI@LaRC.NASA.GOV Phone : (757) 864-3039 Fax : (757) 864-7892 From sdm7g@elvis.med.virginia.edu Wed Mar 10 21:36:23 1999 From: sdm7g@elvis.med.virginia.edu (Steven D. Majewski) Date: Wed, 10 Mar 1999 16:36:23 -0500 Subject: [Pythonmac-SIG] Ctl.CreateRootControl( window ) always returns None Message-ID: <199903102136.QAA17523@elvis.med.Virginia.EDU> Every attempt at calling Ctl.CreateRootControl( window ) returns None. I've tried with various flavors of Dialog and plain windows, visible and invisible (just in case that made a difference) but it always returns None, and calling Ctl.GetRootControl( window ) also returns None. Am I missing a step in how to use this function or is it a bug? ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From sdm7g@elvis.med.virginia.edu Wed Mar 10 22:44:21 1999 From: sdm7g@elvis.med.virginia.edu (Steven D. Majewski) Date: Wed, 10 Mar 1999 17:44:21 -0500 Subject: [Pythonmac-SIG] Ctl.CreateRootControl( window ) always returns None Message-ID: <199903102244.RAA17468@elvis.med.Virginia.EDU> Actually, I can get something other than None as a return value. If I call it twice on the same window I get an error on the second call: >>> w = Win.NewCWindow((50,50,480,220),'',0,1,-1,0,0) >>> Ctl.CreateRootControl(w) >>> Ctl.CreateRootControl(w) Traceback (innermost last): File "", line 1, in ? Mac OS Error: (-30587, 'Mac OS error code -30587') But I can't find error code -30587 in the master list ResultCodes.pdf though maybe it's defined in an include file somewhere. - Steve M. From sdm7g@elvis.med.virginia.edu Wed Mar 10 22:51:11 1999 From: sdm7g@elvis.med.virginia.edu (Steven D. Majewski) Date: Wed, 10 Mar 1999 17:51:11 -0500 Subject: [Pythonmac-SIG] Ctl.CreateRootControl( window ) always returns None Message-ID: <199903102251.RAA14964@elvis.med.Virginia.EDU> Sorry -- didn't look far enough. Error code not in ResultCodes.pdf, but it is in the appendix of the OS8 Control Manager Reference: errRootAlreadyExists -30587 Root control already exists so it would look as the root control is being successfully created, but the Python wrapper is not returning the correct value. (guess!) -- Steve M. From sdm7g@elvis.med.virginia.edu Wed Mar 10 23:39:04 1999 From: sdm7g@elvis.med.virginia.edu (Steven D. Majewski) Date: Wed, 10 Mar 1999 18:39:04 -0500 Subject: [Pythonmac-SIG] Ctl.CreateRootControl( window ) always returns None Message-ID: <199903102339.SAA14029@elvis.med.Virginia.EDU> On Mar 10, 17:51, "Steven D. Majewski" wrote: > Subject: Re: [Pythonmac-SIG] Ctl.CreateRootControl( window ) always return > > Sorry -- didn't look far enough. Error code not in ResultCodes.pdf, > but it is in the appendix of the OS8 Control Manager Reference: > > errRootAlreadyExists -30587 Root control already exists > > so it would look as the root control is being successfully created, > but the Python wrapper is not returning the correct value. (guess!) and as verification, Ctl.DumpControlHierarchy( win, fss ) produces: Dumping info for window 0x2D0E870 Window found. Dumping panes... Root pane (-32768,-32768,32767,32767), Embedder, Visible, Enabled -- Steve M. From Jack.Jansen@cwi.nl Thu Mar 11 09:04:56 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 11 Mar 1999 10:04:56 +0100 Subject: [Pythonmac-SIG] Ctl.CreateRootControl( window ) always returns None In-Reply-To: Message by "Steven D. Majewski" , Wed, 10 Mar 1999 16:36:23 -0500 , <199903102136.QAA17523@elvis.med.Virginia.EDU> Message-ID: Recently, "Steven D. Majewski" said: > > Every attempt at calling Ctl.CreateRootControl( window ) returns None. > I've tried with various flavors of Dialog and plain windows, visible > and invisible (just in case that made a difference) but it always > returns None, and calling Ctl.GetRootControl( window ) also returns > None. > > Am I missing a step in how to use this function or is it a bug? This is a bug. I'll look into it. -- 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 From sdm7g@virginia.edu Thu Mar 11 17:26:21 1999 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Thu, 11 Mar 1999 12:26:21 -0500 (EST) Subject: [Pythonmac-SIG] Ctl.CreateRootControl( window ) always returns None In-Reply-To: Message-ID: On Thu, 11 Mar 1999, Jack Jansen wrote: > > Recently, "Steven D. Majewski" said: > > > > Every attempt at calling Ctl.CreateRootControl( window ) returns None. > > I've tried with various flavors of Dialog and plain windows, visible > > and invisible (just in case that made a difference) but it always > > returns None, and calling Ctl.GetRootControl( window ) also returns > > None. > > > > Am I missing a step in how to use this function or is it a bug? > > This is a bug. I'll look into it. > Thanks. Looks like the same bug infects GetSuperControl, so the wrapper funcion CtlObj_WhichControl is suspect. Is it supposed to be calling GetControlReference() ? Shouldn't it be the control itself and not the RefCon value ? Anyway -- the good news for all you appearance manager fans out there is that, except for these couple bugs, auto-embedding of controls seems to work properly as far as I can tell. Some of the more complex emdedding controls need additional resources, so it's a bit trickier to generate, say a set of tabbed folders dynamically from Python if you haven't set up the appropriate 'tab#' resources beforehand. BTW: There is a password control with appearance mgr. but I tried sticking one in a dialog and it doesn't seem to do anything visible when ModalDialog is called on it. Something is missing -- maybe it has to request the keyboard focus explicitly. If anyone has a clue let me know. Re: appearance mgr support for dialogs present? Any more thoughts about how to protect function calls if support is not there ? For progress-indicator and (I assume) password control, which require a CDEF that's included with appearance mgr extension or is included in 8.x, failing to find that resource could be the test. Is there an interface to the gestalt calls ? ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From joe@strout.net Thu Mar 11 22:02:42 1999 From: joe@strout.net (Joseph J. Strout) Date: Thu, 11 Mar 1999 14:02:42 -0800 Subject: [Pythonmac-SIG] dlmodule for MacOS? Message-ID: I've just learned of dlmodule, which supposedly allows you to call arbitrary C functions from Python. I understand this is somewhat dangerous, but it may be just what I need to interface shared libraries we're currently using with Lisp, with Python as well. But though I see dlmodule.c in the source tree, I don't seem to have a compiled dlmodule in my MacOS distribution. Anybody know if & how dlmodule works under MacOS? Thanks, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From just@letterror.com Fri Mar 12 01:00:00 1999 From: just@letterror.com (Just van Rossum) Date: Fri, 12 Mar 1999 02:00:00 +0100 Subject: [Pythonmac-SIG] dlmodule for MacOS? In-Reply-To: Message-ID: At 2:02 PM -0800 3/11/99, Joseph J. Strout wrote: >I've just learned of dlmodule, which supposedly allows you to call >arbitrary C functions from Python. I understand this is somewhat >dangerous, but it may be just what I need to interface shared libraries >we're currently using with Lisp, with Python as well. But though I see >dlmodule.c in the source tree, I don't seem to have a compiled dlmodule in >my MacOS distribution. Anybody know if & how dlmodule works under MacOS? I don't even know dlmodule, but on MacOS we have Jack's wonderful calldll. It's in the standard distribution. Unfortunately it's only for PPC, but... what the heck. It's very cool. It could use some improvements, but for simple cases it works rather well. Be sure to read samplecalldll.py in the demo folder, too. Just From Jack.Jansen@cwi.nl Fri Mar 12 09:11:13 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 12 Mar 1999 10:11:13 +0100 Subject: [Pythonmac-SIG] Ctl.CreateRootControl( window ) always returns None In-Reply-To: Message by "Steven D. Majewski" , Thu, 11 Mar 1999 12:26:21 -0500 (EST) , Message-ID: Recently, "Steven D. Majewski" said: > > Thanks. > Looks like the same bug infects GetSuperControl, so the wrapper funcion > CtlObj_WhichControl is suspect. Is it supposed to be calling > GetControlReference() ? Shouldn't it be the control itself and not > the RefCon value ? The problem is deeper, it is a deisng problem. Let me explain, and if someone knows an answer please help me in the right direction. When FindControl() or various other Ctl routines return a control they return an existing control, and I would like to return the correct Python object to the Python program. So, for all controls created through NewControl or GetNewControl we set the refcon field to the Python object, and we can go back and forth between Python object and control. Controls that have been created by other means (in dialog boxes, for instance) are a problem, though. They don't have a corresponding Python object and no refcon field, so it is a bit unclear what I should do with them. Currently I just refuse to return them, which is clearly not the optimal solution. I could create the control object and put in the refcon link, or I could create it without the refcon link. The first solution has the advantage that if the control is returned twice you get the same Python object twice, but the disadvantage that memory will be leaked (as the control is freed by some other package you won't get the chance to free the Python object). The second method doesn't leak memory, but if you call FindControl twice it will return two different Python objects pointing to the same Control object. Comments and insights, anyone? -- 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 From just@letterror.com Fri Mar 12 14:05:27 1999 From: just@letterror.com (Just van Rossum) Date: Fri, 12 Mar 1999 15:05:27 +0100 Subject: [Pythonmac-SIG] Ctl.CreateRootControl( window ) always returns None In-Reply-To: References: Message by "Steven D. Majewski" , Thu, 11 Mar 1999 12:26:21 -0500 (EST) , Message-ID: At 10:11 AM +0100 3/12/99, Jack Jansen wrote: >The problem is deeper, it is a deisng problem. Let me explain, and if >someone knows an answer please help me in the right direction. > >When FindControl() or various other Ctl routines return a control they >return an existing control, and I would like to return the correct >Python object to the Python program. So, for all controls created >through NewControl or GetNewControl we set the refcon field to the >Python object, and we can go back and forth between Python object and >control. > >Controls that have been created by other means (in dialog boxes, for >instance) are a problem, though. They don't have a corresponding >Python object and no refcon field, so it is a bit unclear what I >should do with them. Currently I just refuse to return them, which is >clearly not the optimal solution. I could create the control object >and put in the refcon link, or I could create it without the refcon >link. The first solution has the advantage that if the control is >returned twice you get the same Python object twice, but the >disadvantage that memory will be leaked (as the control is freed by >some other package you won't get the chance to free the Python >object). > >The second method doesn't leak memory, but if you call FindControl >twice it will return two different Python objects pointing to the same >Control object. > >Comments and insights, anyone? I'd go for #2, and try to implement a compare method which will look at the actual control instead of the Python object. Seems relatively nice and clean. It's just like methods: >>> class foo: ... def a(self): pass ... >>> foo.a == foo.a 1 >>> foo.a is foo.a 0 >>> Just From sdm7g@virginia.edu Fri Mar 12 21:48:21 1999 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Fri, 12 Mar 1999 16:48:21 -0500 (EST) Subject: [Pythonmac-SIG] Ctl.CreateRootControl( window ) always returns None In-Reply-To: Message-ID: On Fri, 12 Mar 1999, Jack Jansen wrote: > The problem is deeper, it is a deisng problem. Let me explain, and if > someone knows an answer please help me in the right direction. > > When FindControl() or various other Ctl routines return a control they > return an existing control, and I would like to return the correct > Python object to the Python program. So, for all controls created > through NewControl or GetNewControl we set the refcon field to the > Python object, and we can go back and forth between Python object and > control. > Thanks. I was wondering about this -- how some of these calls keep from duplicating objects in Python. I was also wondering: I currently use the following function def ditl(): return Res.Resource(struct.pack( 'h', -1 )) to generate an empty DITL reference for calls to NewDialog, and I was wondering if using this anonymously is a problem? -- the toolbox will expect that bit of memory to continue existing, while Python may dispose of it. Do I need to keep a reference to it somewhere ? > Controls that have been created by other means (in dialog boxes, for > instance) are a problem, though. They don't have a corresponding > Python object and no refcon field, so it is a bit unclear what I > should do with them. Currently I just refuse to return them, which is > clearly not the optimal solution. I could create the control object > and put in the refcon link, or I could create it without the refcon > link. The first solution has the advantage that if the control is > returned twice you get the same Python object twice, but the > disadvantage that memory will be leaked (as the control is freed by > some other package you won't get the chance to free the Python > object). > > The second method doesn't leak memory, but if you call FindControl > twice it will return two different Python objects pointing to the same > Control object. > > Comments and insights, anyone? I would say try method #2, and add a function to set refcon to self so that it can be registered. Doing it automatically (#1) would not be a problem for any of my code, but I could imagine that using Python in embedded apps or with other GUI extensions could likely be a problem. For example, doesn't PowerPlant use the RefCon ? ( Wrapping PowerPlant or maybe MacZoop is still one of my one-of-these-days-when-I-have-more-time-to-play day dreams. [*]) [ Wasn't there a thread a while back in the newsgroup about the inverse of id() -- wanted to do some sort of similar registration in Windows ? i.e. a find-Python-object-by-address function. ] [(*) However, at the moment I'm on a history binge after reading a bunch of Patrick O'Brian novels. I'm reading about what a bunch of bloodthirsty warlike imperialists you Dutch used to be a couple hundred years ago! ] ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From managan@llnl.gov Sat Mar 13 00:00:21 1999 From: managan@llnl.gov (Rob Managan) Date: Fri, 12 Mar 1999 16:00:21 -0800 Subject: [Pythonmac-SIG] SWIG Message-ID: I just updated my projects for the Mac version of SWIG. This is based on the latest snapshot. The complete source code is included. If you grab the source snapshot I think all you have to do is copy over the Mac folder and compile. You will need the latest version of Tcl/Tk. That folder needs to be at the same level as the MacSwig folder. It is available at . *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan mailto://managan@llnl.gov LLNL ph: 925-423-0903 P.O. Box 808, L-098 FAX: 925-423-5804 Livermore, CA 94551-0808 From Jack.Jansen@cwi.nl Sat Mar 13 21:46:25 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Sat, 13 Mar 1999 22:46:25 +0100 Subject: [Pythonmac-SIG] Ctl.CreateRootControl( window ) always returns None In-Reply-To: Message by "Steven D. Majewski" , Fri, 12 Mar 1999 16:48:21 -0500 (EST) , Message-ID: Recently, "Steven D. Majewski" said: > I currently use the following function > > def ditl(): > return Res.Resource(struct.pack( 'h', -1 )) > > > to generate an empty DITL reference for calls to NewDialog, and > I was wondering if using this anonymously is a problem? -- the > toolbox will expect that bit of memory to continue existing, while > Python may dispose of it. Do I need to keep a reference to it > somewhere ? In this case: no. Res.Resource objects are among the ones that don't get cleaned up automatically, mainly because the cleanup depends on what is in the object (a real resource, a handle, or something like a DialogHandle, etc). What I'd like to do some day is to have some way of doing the right cleanup for the object, plus methods to change the "class" of the object (which is needed when you DetachResource(), for instance). The class hierarchy should be something like class UnmanagedHandle: all handle methods, including DisposeHandle magic methods to_ManagedHandle, to_Resource, etc that change the class of the object class Handle(UnmanagedHandle): __del__ does implicit DisposeHandle class Resource(UnmanagedHandle): resource methods, __del__ does FreeResource class UnmanagedMenuHandle(UnmanagedHandle): all the things you do to menus class MenuHandle(UnmanagedMenuHandle): __del__ does FreeMenu or whatever ... etc I think I'd have to change the actual object type (in stead of the more normal-python-paradigm-conforming cast that copies the object) because one of the reasons you'd want to cast the object is to change the disposal semantics: if you have created a menu but you subsequently pass it to some other (C-)package you don't want to dispose it when you drop the Python object. Something similar holds for Controls, where Apple in their infinite wisdom have decided to auto-dispose them when the window containing them is disposed. Fine in C, but pretty gruesome in Python because if we'd automatically dispose the controls when the Python object dies this would mean serious trouble if the window got garbage-collected first and the control object later... > [(*) However, at the moment I'm on a history binge after reading a > bunch of Patrick O'Brian novels. I'm reading about what a bunch > of bloodthirsty warlike imperialists you Dutch used to be a > couple hundred years ago! ] Ah, but that doesn't concern me. I'm half Irish, after all, and the Irish are well-known for their abhorrence of violence:-) -- 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 From Jack.Jansen@cwi.nl Sat Mar 13 22:04:18 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Sat, 13 Mar 1999 23:04:18 +0100 Subject: [Pythonmac-SIG] Any volunteers to maintain a MacPython packages page? Message-ID: I think the community would be helped if there was a webpage (on starship, for instance, but anywhere is fine really) where MacPython users could go for one-stop shopping for Mac versions of Python extensions. Rob just announced SWIG, there's my Mac version of pyexpat, and various other things. I'd do it myself, but I really don't have the time right now.... -- 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 From just@letterror.com Sat Mar 13 22:40:37 1999 From: just@letterror.com (Just van Rossum) Date: Sat, 13 Mar 1999 23:40:37 +0100 Subject: [Pythonmac-SIG] Any volunteers to maintain a MacPython packages page? In-Reply-To: Message-ID: At 11:04 PM +0100 3/13/99, Jack Jansen wrote: >I think the community would be helped if there was a webpage (on >starship, for instance, but anywhere is fine really) where MacPython >users could go for one-stop shopping for Mac versions of Python >extensions. Rob just announced SWIG, there's my Mac version of >pyexpat, and various other things. I'd do it myself, but I really >don't have the time right now.... What would be really helpful if we had some sort of standard extension install mechanism, which moves the stuff to a standard place (the Extensions folder probably) and automatically modify the system-wide sys.path prefs accordingly. I have a starship account, so I would be able to make a page, as long as we can collectively create a smoother packaging and install procedure, to make the contribution process as painless as possible. [I have written a module which is basically a stuffit/tar-gzip-like thingy (but fully incompatible with both of course ;-). I can imagine building Self Extracting Archives with this, by creating an applet which contains the compressed archive in a resource or in the data fork after the code fragments. Since Python should be installed when installing extensions this could work. Here's my filepacker module, in case anyone is interested: http://starship.python.net/crew/just/code/FilePacker.py It has not been extensively tested, but it appears to be stable. It fully supports Mac files of course.] Just From A.J.Jansen@cable.A2000.nl Sat Mar 13 23:15:12 1999 From: A.J.Jansen@cable.A2000.nl (A.J. Jansen) Date: Sun, 14 Mar 1999 00:15:12 +0100 Subject: [Pythonmac-SIG] Control objects and such Message-ID: <36EAF17F.DE24F9A8@cable.A2000.nl> Okay, under the well-known dutch motto "U vraagt en wij draaien" I've implemented the compare and hash methods for control objects, and in the next release you should always get a control object back when expected, even if the C object was not created through Python. Moreover different Python objects pointing to the same C object will compare equal and behave correctly in dictionaries. The next question is for which other objects this behaviour should be implemented. Windows are the first candidate, but I'm a bit reluctant here because there's a lot of eventloop code out there that does something like w = FindWindow(event) if not w: MacOS.HandleEvent(event) i.e. it expects that all windows that are not Python-created (like the SIOUX console) are returned as None. Requests? Comments? Suggestions? From Jack.Jansen@cwi.nl Sat Mar 13 23:19:49 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Sun, 14 Mar 1999 00:19:49 +0100 Subject: [Pythonmac-SIG] Any volunteers to maintain a MacPython packages page? In-Reply-To: Message by Just van Rossum , Sat, 13 Mar 1999 23:40:37 +0100 , Message-ID: Recently, Just van Rossum said: > What would be really helpful if we had some sort of standard extension > install mechanism, which moves the stuff to a standard place (the > Extensions folder probably) and automatically modify the system-wide > sys.path prefs accordingly. > > I have a starship account, so I would be able to make a page, as long as we > can collectively create a smoother packaging and install procedure, to make > the contribution process as painless as possible. I think the two things are related, but separate. If you're willing to maintain the page you could add all packages that people advertise, but nudge people towards providing the package in the preferred format, for instance by adding a prominent PyMacAutoInstall icon to all packages that use that installer. Other packages would get a boring text link only:-) And there are also links to non-installable things like manuals in various formats, 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 From joe@strout.net Mon Mar 15 19:42:00 1999 From: joe@strout.net (Joseph J. Strout) Date: Mon, 15 Mar 1999 11:42:00 -0800 Subject: [Pythonmac-SIG] calldll: what about floats? Message-ID: calldll is extremely cool! But the Readme suggests we discuss here what we need for it. I need to be able to pass (and get back) floats. How about 'InFloat' and 'InDouble' (and corresponding Out types)? Also, why is it that the Mac:Demo:calldll folder seems to be in the 1.5.1 distribution, but not the 1.5.2b1? Is this module going away (pray not)? Cheers, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From gordon@mindspring.com Tue Mar 16 22:50:00 1999 From: gordon@mindspring.com (Richard Gordon) Date: Tue, 16 Mar 1999 17:50:00 -0500 Subject: [Pythonmac-SIG] Lurker Questions Message-ID: <199903162250.RAA03102@smtp4.mindspring.com> I've been lurking this list for a couple of months and have finally decided to get serious about Python, so I hope that you can answer a few questions that I have yet to resolve on my own: 1. Does anyone know of a free (or very cheap) web hosting service that permits you to run Python cgi's? What I am looking for is something like www.hypermart.net which is very cool but they only permit Perl cgis. 2. I am still trying to find a Mac editor that supports Python with syntax coloring, etc. I was under the impression that Alpha would do this, but the current version doesn't include a Python mode and its status is rather unclear. Does anyone have any suggestions? 3. Along somewhat related lines, is there a Python tool that would work with MPW/ToolServer in the same way that the MacPerl Tool does? 4. I think that I already know the answer, but is there a utility that will convert Perl to Python sort of like a2p will convert awk to Perl? I've got some fairly large Perl stuff that I would like to convert, but don't have much stomach for doing the whole thing manually. Thanks for any help that you may be able to offer. Richard Gordon Gordon Consulting & Design maccgi@bellsouth.net From joe@strout.net Tue Mar 16 23:18:28 1999 From: joe@strout.net (Joseph J. Strout) Date: Tue, 16 Mar 1999 15:18:28 -0800 Subject: [Pythonmac-SIG] Lurker Questions In-Reply-To: <199903162250.RAA03102@smtp4.mindspring.com> Message-ID: At 2:50 PM -0800 03/16/99, Richard Gordon wrote: >1. Does anyone know of a free (or very cheap) web hosting service that permits >you to run Python cgi's? What I am looking for is something like >www.hypermart.net which is very cool but they only permit Perl cgis. I'm just now switching from web2010.com to dreamhost.com, which has Python installed and running no problem. They're cheap and seem pretty good so far. (Be sure to tell hypermart why they're not getting your money -- I gave web2010 two long letters and a phone call.) >2. I am still trying to find a Mac editor that supports Python with syntax >coloring, etc. I was under the impression that Alpha would do this, but the >current version doesn't include a Python mode and its status is rather >unclear. >Does anyone have any suggestions? The Python IDE is definately the way to go. Write to Just van Rossum and tell him that you really, really want the option of syntax coloring in the next release, even if it doesn't handle multi-line strings properly. We've got it, it mostly works, but there's a bug or two which has made Just reluctant to enable it -- I'm sure he'll appreciate your input. >3. Along somewhat related lines, is there a Python tool that would work with >MPW/ToolServer in the same way that the MacPerl Tool does? I don't know what these are and do. Maybe if you provide more detail, we can find/make something? >4. I think that I already know the answer, but is there a utility that will >convert Perl to Python sort of like a2p will convert awk to Perl? I've got >some >fairly large Perl stuff that I would like to convert, but don't have much >stomach for doing the whole thing manually. Hmm, not that I know of, but you should post this question to the comp.lang.python newsgroup. Cheers, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From managan@llnl.gov Tue Mar 16 23:34:35 1999 From: managan@llnl.gov (Rob Managan) Date: Tue, 16 Mar 1999 15:34:35 -0800 Subject: [Pythonmac-SIG] Lurker Questions In-Reply-To: <199903162250.RAA03102@smtp4.mindspring.com> Message-ID: Richard Gordon wrote: >I've been lurking this list for a couple of months and have finally decided to >get serious about Python, so I hope that you can answer a few questions that I >have yet to resolve on my own: > ... >2. I am still trying to find a Mac editor that supports Python with syntax >coloring, etc. I was under the impression that Alpha would do this, but the >current version doesn't include a Python mode and its status is rather >unclear. >Does anyone have any suggestions? > Somewhere I ended up with a Python mode for Alpha that works with the current version. It is available at . *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan mailto://managan@llnl.gov LLNL ph: 925-423-0903 P.O. Box 808, L-098 FAX: 925-423-5804 Livermore, CA 94551-0808 From wtbridgman@radix.net Wed Mar 17 02:12:27 1999 From: wtbridgman@radix.net (W.T. Bridgman) Date: Tue, 16 Mar 1999 21:12:27 -0500 Subject: [Pythonmac-SIG] Mac Numerical 1.9 Problem In-Reply-To: References: Message-ID: Rob, I tried installing the new Numeric. I added the Numerical:Mac folder to the path, the one with all the .slb files. However, when I try to run test_all.py, I get: Starting Testing Suite Traceback (innermost last): File "Beta:Python 1.5.1:Extensions:Numerical:Test:test_all.py", line 61, in ? test_lines(fp.readlines()) File "Beta:Python 1.5.1:Extensions:Numerical:Test:test_all.py", line 58, in test_lines exec(line) File "", line 1, in ? File "Beta:Python 1.5.1:Extensions:Numerical:Lib:Numeric.py", line 6, in ? import multiarray ImportError: PythonCore: An import library was too old for a client. >>> What does this mean? Tom From savageb@pacbell.net Wed Mar 17 07:57:20 1999 From: savageb@pacbell.net (savageb) Date: Tue, 16 Mar 1999 23:57:20 -0800 Subject: [Pythonmac-SIG] OT: MacOS X Server Message-ID: <199903170757.XAA08760@mail-gw.pacbell.net> Hi all. This is kindof off topic I s'pose, but I thought I would let people know. MacOS X Server was released today, the price was dropped by 400 dollars from the announced price ($499 regular, $249 academic). Also "Darwin" was announced which is Apple's foray into Open Source-ing the MacOS. here is a newstory about the open source stuff: http://cbs.marketwatch.com/archive/19990316/news/current/aapl.htx?source=htx /http2_mw but the best place to go for information seems to be the Apple site itself: http://www.apple.com This is really exciting because I think MacOS X and MOSX Server will be great platforms for Python development. The current release of MOSX S does not include Carbon, so MacPython will only run inside the Blue-Box, but there should also be a version that runs on the 'mostly POSIX' side as well. There is also a very interesting sounding free tool available from TipTop software: http://www.tiptop.com/ which claims to allow you to mix-n-match Tcl, Perl, Python, Objective C, and more. Python will be usable to write both 'yellow' and 'carbon' apps. I expect there to be a certain amount of confusion at first, but this sounds like a very interesting period in Mac/Python history is about to begin. Sorry for the interruption, go back to what you were doing... -bob From just@letterror.com Wed Mar 17 11:54:57 1999 From: just@letterror.com (Just van Rossum) Date: Wed, 17 Mar 1999 12:54:57 +0100 Subject: [Pythonmac-SIG] Mac Numerical 1.9 Problem In-Reply-To: References: Message-ID: At 9:12 PM -0500 3/16/99, W.T. Bridgman wrote: >Rob, > >I tried installing the new Numeric. I added the Numerical:Mac folder to >the path, the one with all the .slb files. However, when I try to run >test_all.py, I get: [ ... ] >ImportError: PythonCore: An import library was too old for a client. >>>> > >What does this mean? It means that it was compiled for a different Python version. At the moment, all C extensions are bound to one particular Python version (yeah, we know, that's bad). We're working on a way that will keep extensions working as long as the Python C API doesn't change. Solutions: - upgrade to the Python version that NumPy was compiled for (note that you get NumPy 1.9 with MacPython 1.5.2b1!) - get someone to compile it for 1.5.1 (I could do it for you, but not at this very moment... Let me know) Just From steve@estel.uindy.edu Wed Mar 17 17:50:46 1999 From: steve@estel.uindy.edu (Steve Spicklemire) Date: Wed, 17 Mar 1999 12:50:46 -0500 (EST) Subject: [Pythonmac-SIG] Director Python plug-in.... Mac Port Message-ID: <199903171750.MAA16047@estel.uindy.edu> I've had a little time to work on the Mac port of my Xtra for Director. The readme follows. The code is at http://opensource.spvi.com. Any help with the project would be really appreciated. The Problem now seems to be getting the PYTHONPATH from the correct resource from within the plugin. I don't know enough about Mac resources to instantly figure this one out. I'm guessing it's because the application that's using the XTra is not Python, but Director. I think I've correctly included all the Python resources in my XTra project. I'm building a 'standalone' Xtra (not using the PythonCore library) since that seems to cause all sorts of problems..... and was difficult to debug. thanks for any ideas! -steve ---------------------------------------------------------------------- Hi Folks, I'm happy, but mildly embarrassed (at the current state of the code) to say that one of my customers, Thomson Consumer Electronics, has agreed to allow me to release the source to a tool I've developed to help me help them... it's a (crude) Python XTra for Macromedia Director. This is a very eary, crude, but useful Scripting XTra that allows you to use Python from within Macromedia Director. There are only a few commands From the current CREGISTER.CPP static char msgTable[] = { "xtra XPython\n" \ "new object me\n" /* standard first handler entry in all message tables */ "-- Template handlers --\n" "* PyRun_SimpleString string command -- processes one Python command\n" "* Py_Initialize -- Initializes Python\n" "* Py_GetObject string objectname -- get a string from python\n" "* Py_GetList string listname -- get a list from python\n" }; So you can put the XTra in your XTras folder and: Py_Initialize() -- init the interpreter.. PyRun_SimpleString("x = Spam()") -- call the Python interpreter Py_GetObject("x") -- retrieve the object called 'x'... only works with strings now.. Py_GetList("parrots") -- get a list of strings... (assuming you already have Python installed). I need all the help I can get... 1) Make the 'Py_GetXXX' functions more general, functional, safe.... 2) Do the 'extension' half of this.. so that you can manipulate Director objects from withan a Python script. 3) Get the Mac port working.... I've made some progress on this front. I've included the current state of the project with this release. There is a file XPython.sea that includes my source tree. You will need the Python sources from Jack's ftp site: ftp://ftp.cwi.nl/pub/jack/python/mac (These go in the "Python 1.5.2b1 src", and CWGUSI as described in the buildmac document that comes with Jack's sources....) The XDK from macromedia: http://www.macromedia.com/support/xtras/xdks/xdk_d6a4.html (This goes in the XDK folder.. you should only need 'includes') My stuff goes in the 'XPython' folder. Right now the plugin is crashing when it tries to snoop through the resources to discover the PYTHONPATH. This is being released as OpenSource... do anything you like but let me know if you find bugs or want to contribute improvements! I'd be more than happy to incorporate good stuff back into this code. For my part I'll do my best to maintain the sources and make new XTras available as they are created. ---------------------------------------------------------------------- Steve Spicklemire Silicon Prairie Ventures, Inc. (and) University of Indianapolis steve@spvi.com steve@estel.uindy.edu Software/Hardware Development Physics and Earth-Space Science (317) 917-1411 (317) 788-3313 From Jack.Jansen@cwi.nl Wed Mar 17 21:22:00 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 17 Mar 1999 22:22:00 +0100 Subject: [Pythonmac-SIG] Director Python plug-in.... Mac Port In-Reply-To: Message by Steve Spicklemire , Wed, 17 Mar 1999 12:50:46 -0500 (EST) , <199903171750.MAA16047@estel.uindy.edu> Message-ID: Recently, Steve Spicklemire said: > > I've had a little time to work on the Mac port of my Xtra for Director. > The readme follows. The code is at http://opensource.spvi.com. Any help > with the project would be really appreciated. The Problem now seems to > be getting the PYTHONPATH from the correct resource from within the > plugin. Steve, I don't have time right now to really dig into this, but I do have a suggestion. If the plugin is a shared library, as most of them usually are, you could try adding an initialize() entrypoint (look in the cfm or ppc loader section in codewarrior). In the initialize routine you have access to the fsspec of the library/extension being loaded, so you could add it to list of resource files being searched. Look at the tkinter module for an example of how this works. initialize_with_resources is the function you're looking for, and there's a bit more glue in the init_tkinter routine, if I remember correctly. Once you have a known resource fork open you can make sure that the correct STR#, Popt and GUI resources are in there. Usually simply dropping the executable (or library, or extension) on EditPythonPrefs will do the trick. If the extension isn't a shared library your best bet is to do something similar in the startup code, but then you'll have to open a file with a wellknown (to your extension) name. -- 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 From A.J.Jansen@cable.A2000.nl Wed Mar 17 21:43:36 1999 From: A.J.Jansen@cable.A2000.nl (A.J. Jansen) Date: Wed, 17 Mar 1999 22:43:36 +0100 Subject: [Pythonmac-SIG] calldll: what about floats? References: Message-ID: <36F02207.83B3C727@cable.A2000.nl> "Joseph J. Strout" wrote: > calldll is extremely cool! But the Readme suggests we discuss here what we > need for it. I need to be able to pass (and get back) floats. How about > 'InFloat' and 'InDouble' (and corresponding Out types)? I will look into it. Don't hold your breath, though, I seem to remember that there was some problem with floats (maybe they're passed in strange registers or something). > Also, why is it that the Mac:Demo:calldll folder seems to be in the 1.5.1 > distribution, but not the 1.5.2b1? Is this module going away (pray not)? Grmpf, apparently I've done something stupid:-) I'll try and recover the Demo folder (but don't laugh at me if I come back to the whole group tomorrow asking whether someone happens to have a copy lying around:-). From schliep@zpr.uni-koeln.de Thu Mar 18 13:17:04 1999 From: schliep@zpr.uni-koeln.de (Alexander Schliep) Date: Thu, 18 Mar 1999 14:17:04 +0100 Subject: [Pythonmac-SIG] Tk 8.04 / which CW version needed / MPW ? Message-ID: <9903181417.ZM28684@Octopussy.MI.Uni-Koeln.DE> Hi, if I can trust Tkinter.TkVersion (and some bugs in Tkinter which do not surface in Tk 8.0.4) it seems that MacPython 1.5.2b1 is build using Tk 8.0. Does anybody have a _tkinter.ppc.slb build with Tk 8.0.4 which (s)he could mail me ? Also, I'd like to see Tk 8.0.4 (or even 8.0.5 if it is ported to the Mac early enough) used in MacPython 1.5.2 final. And now for something completely different: What CodeWarrior version do I need to compile the MacPython sources ? Does anybody feel like pointing out why one cannot use MPW (except getting Makefiles up-and-running etc.) instead ? Thanks, Alexander -- Alexander Schliep schliep@zpr.uni-koeln.de ZPR/ZAIK Tel: +49-221-470-6011 (w) University of Cologne FAX: +49-221-470-5160 Weyertal 80 http://www.zpr.uni-koeln.de/~schliep 50931 Cologne, Germany Tel: +49-231-143083 (h) From A.M.INGRALDI@larc.nasa.gov Thu Mar 18 13:40:34 1999 From: A.M.INGRALDI@larc.nasa.gov (Anthony M. Ingraldi) Date: Thu, 18 Mar 1999 08:40:34 -0500 Subject: [Pythonmac-SIG] Tk 8.04 / which CW version needed / MPW ? Message-ID: <199903181339.IAA08039@express.larc.nasa.gov> On Thursday, March 18, 1999, Alexander Schliep wrote: > Does anybody feel like pointing out why one cannot use MPW (except > getting Makefiles up-and-running etc.) instead ? > Aside from the non-trivial Makefile set-up, there may be issues with the version of GUSI (Grand Unified Socket Interface) that's available for MPW. I'm not certain, but I think the version of GUSI that's available for MPW is only applicable when building programs that run within the MPW environment (i.e. command line tools.) -- Tony Ingraldi A.M.INGRALDI@LaRC.NASA.GOV Phone : (757) 864-3039 Fax : (757) 864-7892 From joe@strout.net Thu Mar 18 17:39:00 1999 From: joe@strout.net (Joseph J. Strout) Date: Thu, 18 Mar 1999 09:39:00 -0800 Subject: [Pythonmac-SIG] calldll and Cobject Message-ID: I'm using the calldll more and more these days... it (and shared libraries in general) are the greatest thing since sliced bread. But I have a question about the "CObject" type. Who owns this data? In other words, when the last Python reference to a CObject is removed, and the python wrapper is garbage-collected, does it try to delete the data pointed to or any such thing? I'm assuming not, since it wouldn't know what sort of deletion is appropriate. And that's fine with me -- I just wanted to make sure. Thanks, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From Jack.Jansen@cwi.nl Sun Mar 21 22:48:15 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Sun, 21 Mar 1999 23:48:15 +0100 Subject: [Pythonmac-SIG] Tk 8.04 / which CW version needed / MPW ? In-Reply-To: Message by "Alexander Schliep" , Thu, 18 Mar 1999 14:17:04 +0100 , <9903181417.ZM28684@Octopussy.MI.Uni-Koeln.DE> Message-ID: Recently, "Alexander Schliep" said: > > > Hi, > > if I can trust Tkinter.TkVersion (and some bugs in Tkinter which > do not surface in Tk 8.0.4) it seems that MacPython 1.5.2b1 is build > using Tk 8.0. I gave various newer Tk's a try (8.1beta and one if the 8.0.X releases) but as they didn't even compile out-of-the-box and I don't use Tk myself and I'm very short on time I had to drop the project. Working code is, however, gladly accepted:-) -- 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 From sdm7g@virginia.edu Wed Mar 24 22:26:24 1999 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Wed, 24 Mar 1999 17:26:24 -0500 (EST) Subject: [Pythonmac-SIG] Control objects and such In-Reply-To: <36EAF17F.DE24F9A8@cable.A2000.nl> Message-ID: On Sun, 14 Mar 1999, A.J. Jansen wrote: > > The next question is for which other objects this behaviour should be implemented. > Windows are the first candidate, but I'm a bit reluctant here because there's a lot > of eventloop code out there that does something like > w = FindWindow(event) > if not w: > MacOS.HandleEvent(event) > i.e. it expects that all windows that are not Python-created (like the SIOUX console) > are returned as None. > > Requests? Comments? Suggestions? > I've been mulling this over for a while, and I'm still not sure. Ignoring backward compatability with that code example for the moment, in principle: [1] All windows should be accessible from Python. [2] there should be a way to distinguish non-Python (ie. SIOUX) windows from Python created windows. Maybe the solution is that if windows are created from SIOUX or some other source, they should follow the current behaviour, however, there should be a function to return the SIOUX console window as a Python object, which has the side effect of "registering" that window to Python -- which would then cause FindWindow to return a value. I'm thinking not only of SIOUX, but for establishing a precedent in case we should try interfaces to MacApp or PowerPlant or MacZoop or some other framework. ---| 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 |--- Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*) (*) From cwalker@pixar.com Tue Mar 30 03:45:20 1999 From: cwalker@pixar.com (Chris Walker) Date: Mon, 29 Mar 1999 19:45:20 -0800 Subject: [Pythonmac-SIG] module Res Message-ID: I'm trying to run a Python distro off a CD that's also the startup disk. The CD is burned from a partition with Python installed. However, I get errors indicating that the module 'Res' could not be found. I cannot find this module anywhere in the Mac Python distribution. Can anyone shed some light on this? --- Chris Walker Pixar Animation Studios UNIX Systems Administrator (510) 620-3736 cwalker@pixar.com From Jack.Jansen@cwi.nl Tue Mar 30 09:18:33 1999 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 30 Mar 1999 11:18:33 +0200 Subject: [Pythonmac-SIG] module Res In-Reply-To: Message by Chris Walker , Mon, 29 Mar 1999 19:45:20 -0800 , Message-ID: Recently, Chris Walker said: > I'm trying to run a Python distro off a CD that's also the startup disk. The > CD is burned from a partition with Python installed. However, I get errors > indicating that the module 'Res' could not be found. I cannot find this modu > le > anywhere in the Mac Python distribution. Can anyone shed some light on this? In the next release your problems will probably be gone, because Res and a few other selected modules will live in the core. In the current release it lives in toolboxmodules.???.slb, and the only program that understands how to find it is ConfigurePython, which will drag it in and then create all the symlinks (after which everyone can find it). You can create a runnable Python on a bootable CD, but it's a bit convoluted. First build up your disk on a harddisk, and make sure the volumename is the same as what your CD is going to be called. Boot from that disk, install python and run ConfigurePython. This will create the preference file and the aliases. Then burn the CD. The aliases will be incorrect (the volume sequence number or whatever it is called changes when you burn the CD), but they will be automatically fixed because the volume name is the same. It'll probably be a tad slower but I don't think you'll really notice. -- 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