🌐 Mailman 3 December 2001 - Pythonmac-SIG - python.org

Re: [Pythonmac-SIG] ObjC stuff
by Jack Jansen March 20, 2003

March 20, 2003

Recently, Steve Spicklemire <steve(a)spvi.com> said: > So it's in CVS somewhere? I'll do a check-out and see if I can find it. I don't know, Steven Majewski may know (I think he is the one who looked at it). If it isn't in the repository it probably should be, preferrably in the Modules directory (because it is useful for non-Mac users) but if there's objections against that we'll put it in the Mac/Modules dir. > I just ordered CW-6 today so I might be able to pitch in a bit. While very useful for other things (like MacPython development) you don't need it for OSX unix-Python development: this is all make and gcc-based (and you have those on your OSX developer disc). -- 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

5 4

Re: [Pythonmac-SIG] more on MacPython/OSX/shared lib
by Jack Jansen Aug. 14, 2002

Aug. 14, 2002

Recently, Paul Miller <paul(a)fxtech.com> said: > >My next step is to remove all my Python code and see if I get the error > >without linking against Python. > > Back to square 1 for me. I removed the Python lib and all my Python code > and I have the same problem. It must be something in global initialization > in my own code. For yucks I disabled the __initialize and __terminate entry > points in the linker options and I ended up with an assert in my code > (which was expecting the static initializations to happen). Hmm, my guess would be either a bug in CodeWarrior, or (probably more likely) you using the wrong runtime library. Especially if you use C++ you have to be careful with which runtime library you use where, because the zero-overhead exception handling will fail otherwise. And you shouldn't use Python as an example, because it doesn't follow the rules (but gets away with it being a C program). You might want to spell out the MW Targeting MacOS manual. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

4 5

Speed issues with Applet/Applications?
by Sean Hummel April 12, 2002

April 12, 2002

Hi, I wrote a script which allows me to decompress from a .ZIP file, and appropriately sizing names of files that are longer than 31 characters. However the problem I am encountering, is that when I run the script in the Python IDE, it runs at full speed. When I run the script as a standalone application or applet, then it runs VERY SLOW! I am using Python 2.1, and I am using running this script on a PowerG4. So I am wondering if someone else has had this problem when using the application or applet, and/or if there is a good solution to this problem.

5 5

OSX Tips for Christmas...
by Steven Majewski Jan. 3, 2002

Jan. 3, 2002

[1] Maybe there's a less roundabout method, but I did: /Developer/Tools/DeRez dialogs.rsrc >dialogs.r using the dialogs.rsrc from the MacPython2.2b sources -- the ones in the Mac/Resources directory of the standard source release seem to be corrupted -- at least the tools complain about it when you try to use those files -- maybe they are getting EOL converted when they go to the CVS server? Then: /Developer/Tools/Rez dialogs.r -o /usr/local/bin/python Now I can run MachoPython and EasyDialogs.test() works -- more or less. You need to manually bring the dialogs to the front from behind the Terminal.app window. [2] In case you didn't know, you can send and receive AppleEvents from a unix commandline program. This capability is not likely to go away, as it's used for the osascript commands, etc. I compiled and linked with switches: -I/Developer/Headers/FlatCarbon -framework ApplicationServices -framework Carbon This should also work from MachoPython, although I only did a partial test. (I was trying to debug communication with AppleEvents between two classic apps, and I found it easy to simulate one of the programs with a simple cli program so that I could step thru the calls with gdb. ) And BTW, have you seen: [3] How to enable Translucent Terminal Windows: http://forums.macnn.com/cgi- bin/ultimatebb.cgi?ubb=get_topic&f=39&t=001777 ( I don't know if this is actually USEFUL, but it looks kind of cool! ) [4] And the thread on how to Enable Window Backing Store Compression: http://forums.macnn.com/cgi- bin/ultimatebb.cgi?ubb=get_topic&f=46&t=000100 (I don't know if the 10.1.2 upgrade enables this -- I did the hack before I did the latest upgrade.) [5] And if you haven't checked out: <http://www.macosxhints.com/> yet, you should. Merry Christmas and Happy Hacking! -- Steve Majewski (trying to send this from Mail.app, so I hope it doesn't get mangled as HTML or RTF! )

2 1

strange Tkinter event behavior
by christopher ariza Dec. 31, 2001

Dec. 31, 2001

it has been mentioned many times before, but Tkinter on MacOS Classic (pre OSX) almost always has strange behavior. for instance, in my experience, key-repeating is always broken in every application (BBEdit, for example) when a Python/Tkinter app is running. but there is a better way (and paricularily for those "mac-challenged unix-trained" people). this in no way helps you if you have to run MacOS 9x, but this works so well and easily it needs repeated mentioning: get MacOSX install Fink: http://sourceforge.net/projects/fink/ with Fink, you can easily (did i say easily? i meant very very easily) install Xfree86, XDarwin, Python, and Tk. this is done all in a different directory (/sw), so your system is not changed at all. once this is up, you can run Tkinter in Python from Xwindows just as if it were any unix, without a single problem. you can have multiple instances of Tk, Pmw works, the Grayson examples work, all without any hassel. did i say it was easy? of course, we will someday have Tk in Aqua, but in the meantime... christopher ariza

1 0

Offline for a while
by Jack Jansen Dec. 31, 2001

Dec. 31, 2001

Folks, I will probably be unreacable by mail for the next few days, the backup we put in for our move seems to be non-functional. So don't worry about bounceds to the oratrix.nl address, all should be well again on wednseday or thusrday (and backspace also doesn't work on this machine:-) Jack

1 0

strange Tkinter event behavior
by Michael Halle Dec. 30, 2001

Dec. 30, 2001

Hello, I've been developing my first Mac Python/Tkinter application, and I've come across strange event processing behavior that perhaps someone else has seen before. I'm running MacOS 9.2.1 and Python 2.1.1 and now 2.2. First, the initial mouse click to the application seem to be lost in some cases. For example, try Demos:tkinter:matt:dialog-box.py . The window has focus, but the first mouse click doesn't do anything. A second click works. This behavior is annoying, but not fatal. On the other hand, I would also like it if I could make my MacPython application be more friendly in dealing with other running applications. I understand that tk-based apps don't give lots of time back to the system (as a side note, are there convenient pointers for tuning these params?) but I'm seeing something stranger in some applications. When I run NiftyTelnet at the same time, for instance, its event queue gets screwed up: the printing of output characters is one character behind the processing of typed input characters. Some other applications seem to have the same kinds of problems. Generally, but not always, everything clears up when the python-based app terminates. In my Mac-challenged Unix-trained mind, these "lost or delayed" event problems seem potentially related, so I raise them here in the same message. It also looks like the problem's outside of Tk itself, as Wish 8.3.3 doesn't produce the same problems. I would appreciate any help anyone else can give me. The project is especially frustrating because this code is a full and fast rewrite of a Java app that would crash deep in the VM when accessing the serial port and the network at the same time. I can't say that this Mac development stuff it giving me the warm fuzzies.... Thanks. Michael Halle mhalle(a)media.mit.edu

1 0

Re: [Pythonmac-SIG] Python 2.2 Framework _REENTRANT followup
by Jack Jansen Dec. 30, 2001

Dec. 30, 2001

Recently, Adam Eijdenberg <adam(a)switchedonsoftware.com> said: > Or, if you don't want to spend five minutes waiting to compile, move one > line in your sources file to change: > > #include <Python/Python.h> > #include <Carbon/Carbon.h> > #include <CoreFoundation/CoreFoundation.h> > > so it reads: > > #include <Carbon/Carbon.h> > #include <CoreFoundation/CoreFoundation.h> > #include <Python/Python.h> > > and ta da, no more precompiled header warnings. I'm not sure that this is safe. Python, by defining _REENTRANT, may have changed how the C runtime system works. And if the Python core expects it to work one way and your code expects it to work another way you may run in to problems. But if the~ _REENTRANT stuff only has to do with the way you access errno in multithreaded programs you might well be safe doing 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.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] Python 2.2 Framework _REENTRANT
by Jack Jansen Dec. 30, 2001

Dec. 30, 2001

Recently, Adam Eijdenberg <adam(a)switchedonsoftware.com> said: > > You should probably compile without preprocessed headers (sorry, not > > behind my OSX machine right now so I don't know the exact command line > > switch). > > No switch necessary, it just shoots out about a billion warnings telling > me that it can't use the precompiled headers. That's right, but if you add the switch to the commandline it won't even try the precompiled headers and you won't get the warnings. > > The problem is that Python needs the _REENTRANT macro defined (for the > > reason stated in pyconfig.h, so that you get thread-safe errno and > > such), but that the set of precompile headers supplied by Apple was > > generated with it undefined. This is a general problem with > > precompiled headers: they only work if you don't use any special > > switches. > > Fair enough. Is it feasible to recompile the precompiled headers so that > this will work? That has the disadvantage that all other compilations, which expect _REENTRANT to be undefined, will give the reverse warnings:-( But if you really want to do this: yes, there's a commandline tool that regenrates them. "man -k precompiled" or looking up precompiled headers in Developer section of Apple Help should give you the invocation. The way Apple does precompiled headers (automatically using the precompiled header if applicable) breaks down when defines on which the header depends are different. Incidentally, the way MetroWerks does precompiled headers, where you have to manually precompile them into a .pch file and then #incluyde the .pch in stead of the .h file, is also far from ideal. I don't know of any precompiled header implementation that does it right... (At least the Apple implementation notices the fact that the symbol has a different value from what was used to generate the preprocessed header, so it can fallback to using non-preprocessed header files). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 2

Re: [Pythonmac-SIG] Python 2.2 Framework _REENTRANT
by Jack Jansen Dec. 29, 2001

Dec. 29, 2001

You should probably compile without preprocessed headers (sorry, not behind my OSX machine right now so I don't know the exact command line switch). The problem is that Python needs the _REENTRANT macro defined (for the reason stated in pyconfig.h, so that you get thread-safe errno and such), but that the set of precompile headers supplied by Apple was generated with it undefined. This is a general problem with precompiled headers: they only work if you don't use any special switches. Recently, Adam Eijdenberg <adam(a)switchedonsoftware.com> said: > Hi, > > I'm developing a Mach-O Carbon application that embeds Python and I'm > getting a few funny warnings when I try to compile it. > > I've installed the Unix version of Python with the commands "./configure > --enable-framework && make && make framework" install as per > documentation and that all seems to work fine. > > But when I compile my application with: > cc *.c -framework Carbon -framework Python > > I get the following warnings: (widget.h is one of my files, line 6 > #includes <Python/Python.h>) > > widget.h:6: warning: could not use precompiled header > '/System/Library/Frameworks/Carbon.framework/Headers/Carbon.p', because: > widget.h:6: warning: #ifdef '_REENTRANT' not defined when precompiled, > but now defined: > widget.h:6: warning: at > /Library/Frameworks/Python.framework/Headers/pyconfig.h:208 > > Lines 207 and 208 in pyconfig.h are: > > /* Define to force use of thread-safe errno, h_errno, and other > functions */ > #define _REENTRANT 1 > > Commenting out this line removes all warnings. > > Everything seems to work fine, but could commenting this line out cause > any problems? > > Kind regards, > Adam Eijdenberg > > Switched on Software > adam(a)switchedonsoftware.com > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG(a)python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1