🌐 Mailman 3 April 2000 - Pythonmac-SIG - python.org

Tkinter canvas in MacPython 1.5.2-C -- does Find_Closest work?
by Russell E Owen April 20, 2000

April 20, 2000

I have a canvas called "cnv" with the following objects on it: - 10 stars: tiny filled ovals tagged 'star' - 9 grid markings: large unfilled ovals not tagged at all I am trying to use find_closest to find the closest star, ignoring the grid markings. The following code in a mouse moved even handler prints the text following it: ----- code snippet ----- nearestStar = self.cnv.find_closest (x=event.x, y=event.y, halo=0, start='star') print "found star ", nearestStar[0] objList = self.cnv.find_withtag('star') print "star list = ", objList ----- portion of output ------ found star 23 star list = (23, 24, 25, 26, 27, 28, 29, 30, 31, 32) found star 20 star list = (23, 24, 25, 26, 27, 28, 29, 30, 31, 32) Notice that self.cnv.find_withtag('star') returned 10 numbers -- presumably the object ID numbers of the 10 stars. However, self.cnv.find_closest (x=event.x, y=event.y, halo=0, start='star') found things that are in the star list and things that are not -- by inspection it is finding the grid circles as well as the stars. I realize that find_closest will act as if start is not specified if it is given bad data, but I think the call to self.cnv.find_withtag proves that I am supplying a valid tag. I also tried numeric values (object IDs) to start, just to see if I could get it to do anything at all. They did nothing either. As far as I can tell, the start keyword is simply being ignored. Can anybody see an obvious mistake, or has anybody gotten the start keyword to work in find_closest? -- Russell

1 0

Re: [Pythonmac-SIG] time screwed up
by Chris April 20, 2000

April 20, 2000

>I know of no calls in the Mac toolbox which use other than Jan 1 1904 as >the zero point of time (I wrote "start" but that's not the case, since the >modern routines are happy with negative time...happy in some sense but I >don't know what calendar is used). > >At 9:45 -0700 4/18/2000, Corran Webster wrote: >>> >>> from time import * >>> >>> primt asctime(localtime(0)) That's correct, but asctime(), etc or not mac tool box calls, they're C library calls. With MetroWerks Standard Library, these calls, follow the POSIX standard in using 1900 as the epoch. Dosn't someone have a date/time class? Perhaps converting all times to this might be easer than remembering to add 60*60*24*365*4 to all the mac times.

3 3

Feedback on the 1.6a1 release, please?
by Jack Jansen April 20, 2000

April 20, 2000

Folks, aside from the threading problems discussion I have gotten no feedback on the 1.6a1 installer. And, I can't believe that it is flawless, actually, I know of one or two problems already:-) I really need your feedback at this time, MacPython has to contend with Brendan, GRiNS and Uit de Sloot for my time nowadays, and it doesn't come in first:-) Aside from general issues with the installer I also definitely want feedback on contributions people sent me that aren't in this installer yet. I know there are quite a few lying around in various of my mailboxes, so please don't be shy and speak up if you sent me something that isn't in the alfa-installer and you think it should be. And the same goes more-or-less for stuff in Contrib that shouldn't be in there anymore. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] FInfo object - how to make invisible files?
by Jack Jansen April 20, 2000

April 20, 2000

Recently, Craig Hagerman <craig(a)osa.att.ne.jp> said: > I understand that I have to use the macfs module as well to set the flags > for invisible but I can't seem to get it right. I think that I have to > create a FInfo object and then use the > finfo.Flags > method. From the Apple developer web site I seem to remember that 17 > represents invisible files (?). BUT... what exactly IS an "FInfo" object. I > have been searching and searching to no avail. How do I set the flags of a > file to invisible? import macfs, MACFS fss = macfs.FSSpec("thefile") finfo = fss.GetFInfo() finfo.Flags = finfo.Flags | MACFS.kIsInvisible fss.SetFInfo(finfo) > Also; Is it possible to specify the file type/creator when I open a new > file? or do I have to open it then use=> > macfs.SetCreatorType(creator,type) > to do this? No. I've been at the point of doing this various times, but because it would make open() incompatible with non-Macintosh Pythons I've so far refrained from doing it. You're stuck with the SetCreatorType calls, so. Note that you'l also have to tell the finder about the change, for reasons I don't fully understand, otherwise it can take a long time for the change to appear. I think findertools.touched() is the call to do, but have a look at something like BuildApplet.py which uses this. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] configuration lost
by Jack Jansen April 20, 2000

April 20, 2000

Recently, Dante <dante(a)oz.net> said: > I'm having to run ConfigurePython every time I reboot or my applets > are unable to find PythonCore. Is this the standard behavior? Definitely not. Try rebuilding te desktop (the standard MacOS cure for any strange behaviour). If that doesn't work clean out any files with "python" in the name from the system folder (PythonCore in the extensions folder, python prefs in the preferences folder) and rerun ConfigurePython. If that doesn't work start Python, type >>> import sys, os >>> print os.getcwd() >>> print os.listdir(':') >>> print sys.path and send the results of that to the list (or to me) and we'll see what we can do. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] Reloading C extension modules ??
by Jack Jansen April 20, 2000

April 20, 2000

Recently, "Louis M. Pecora" <pecora(a)anvil.nrl.navy.mil> said: > Anyone know anything about reloading C extensions? I am successful at writin > g one, but when I change the C code and recompile to make a share lib module, > the reload command does NOT put the new one into Python. I'm stuck with the > old one until I quit Python, launch it again and re-import everything again. > Bummer for developing an extension. This is definitely doable, but it would require a lot of work: the old dll has to be unloaded (which needs code in probably importdl.c) and also a different CodeWarrior runtime library should be used (the DropIn one in stead of the SharedLib one, if I remember correctly). I don't have any time to spend on this, but if anyone else wants to implement this I'll incorporate it. But, on a tangent, if my extension is so complicated it needs debugging I usually debug it by incorporating it into PythonStandSmall. The CodeWarrior debugger always seems to work better for me if I use it on a statically linked program in stead of on a plugin. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

configuration lost
by Dante April 20, 2000

April 20, 2000

I'm having to run ConfigurePython every time I reboot or my applets are unable to find PythonCore. Is this the standard behavior? Michael -- i am redundant/from knowledge to mastery/i am redundant ... Michael Esveldt mailto:dante@oz.net - http://velocity.editthispage.com/ #FightThePower on irc.openprojects.net

1 0

Reloading C extension modules ??
by Louis M. Pecora April 20, 2000

April 20, 2000

Anyone know anything about reloading C extensions? I am successful at writing one, but when I change the C code and recompile to make a share lib module, the reload command does NOT put the new one into Python. I'm stuck with the old one until I quit Python, launch it again and re-import everything again. Bummer for developing an extension. Thanks for any help. Cheers, Lou Pecora

1 0

Re: [Pythonmac-SIG] Crash in MacPython 1.5.2c2 and Tk oddities
by Bob Savage April 20, 2000

April 20, 2000

on 4/19/00 4:14 PM, Russell E Owen wrote: > Here is a sample script from Grayson's "Python and Tkinter". Note the > use of root.quit (without the (); I'm not sure if that's optional or > I had it wrong). In this context the name root.quit is being assigned to a member element of the button, not actually calling it; the button will 'add' the parentheses itself, later on when it calls the function. > I find that pushing the button neither closes the window nor quits > anything. However, unlike some other things I've tried, I can > actually quit using cmd-Q (twice, as usual, once for Tk, once for the > interpreter) instead of having to force exit. An improvement. Thank goodness for small favors :) <code snipped> Well that didn't work for me because I didn't have the "options" file, so I tried this: ################### # test of root.quit from Tkinter import * root = Tk() root.title('Quit Me') Button(root, text="What's gonna happen?", command=root.quit).pack() root.mainloop() # end of test code ################## And when I clicked on the button everything quit quite nicely. I also tried cmd-Q and got the same behavior you describe, that is, I needed to do either cmd-Q twice or cmd-Q once and ctrl-D the second time. Incidentally, after the first time a zero appears in the Python Out window, so I believe that the first quit is terminating the TK/Wish process, which is in some way a sub-process to the Python Interpreter (so it receives the exit code when the Tkinter-based app terminates). Not really sure where the problem is. Do you have "Keep stdio window open on normal exit" checked? I am starting to think that what you want to do to get rid of the double quit is to bind that root.quit (once we figure out why it is working for me but not for you) to both cmd-Q and to the menu option File:Quit. Then your app will behave as expected. Bob BTW, thanks for pointing out that root.quit bit; I never ran across that before. I might have to look into the Grayson book myself if it is full of things like that.

1 0

Re: [Pythonmac-SIG] time screwed up
by pf＠artcom-gmbh.de April 19, 2000

April 19, 2000

Hi! Schollnick, Benjamin: [...] > Guys, > > I think your forgetting two things here in this discussion. > > 1) Python is cross platform, and not Mac Exclusive > 2) There are two "time" sections in here. > - Python Time Calls > - Macintosh Time Calls > > All Python related Time calls *HAVE* to use a 1900 base. Period. > End of story. Hmmm..... Look: Python 1.5.2 (#1, Jul 23 1999, 06:38:16) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import time >>> time.gmtime(0) (1970, 1, 1, 0, 0, 0, 3, 1, 0) And quoting from TFM: """The epoch is the point where the time starts. On January 1st of that year, at 0 hours, the ``time since the epoch'' is zero. For Unix, the epoch is 1970. To find out what the epoch is, look at gmtime(0).""" > If python time calls are *NOT* based off of 1900, then we will have > to modify > code, and lose cross platform support, for all other platforms. epoch is different on all platforms anyway. If your code relies on a special value for 'epoch', it is broken^H^H^H^H^H^H less portable anyway. > All of the Macintosh *ONLY* time calls, ala Apple Events, etc, > should > be based off the 1904. > > If we don't follow that basic rule, then it'll be difficult to be > fully cross platform. > > Right now, I developed on a WIN NT box, and then copy the files over > to a Mac to create a applet. Works great (other than the CR/LF vs > CR > problems). You should not forget Linux/Unix. Especially on the Internet "real" operating systems (as opposed to WinXX and MacOS <wink> ;-) ) have a very strong user base. BTW: According to c't (a very respected german computer magacine) only 10% of the Top100 Webservers run on NT, where Linux allone is 29% and Solaris is 58%. c't did some research about procentual down times of these TOP-100 servers. The result was not very surprising: NT downtimes were about 1.6% where the Solaris and Linux down times were ranging from 0.2 to 0.4 percent. May be this more related to Apache vs. IIS than to Linux vs. NT. But from my experience Win NT sucks and I'm very happy about Python running my programs unchanged on this brain dead platform without having to bother with it myself. Regards, Peter

1 0