🌐 Mailman 3 January 2002 - Pythonmac-SIG - python.org

Built Python (fwd)
by Bruce Sherwood Jan. 27, 2002

Jan. 27, 2002

Many thanks to our call for help. As you'll see below, David Andersen found that most of our problems seem to have been caused by something entirely different..... Bruce Sherwood ---------- Forwarded Message ---------- Date: Saturday, January 26, 2002 11:10 -0500 From: David Andersen <dma(a)andrew.cmu.edu> To: Bruce Sherwood <bas(a)andrew.cmu.edu> Subject: Built Python > The problem seems to have been due to compiling with CodeWarrior 6 before > switching to CodeWarrior 7. > > I downloaded fresh copies of the Python source, the GUSI/Carbon stuff and > deleted CodeWarrior 6 (except for a few files it said I didn't have > adequate permissions for). > > I was able to build PythonCore except for errors referring to > GUSI_MSL.CW7.PPC.Lib and GUSI_Core.CW7.PPC.Lib. I then built the two > *.CW7 GUSI libraries with no errors, and was then able to build Python. > > ---------- End Forwarded Message ----------

1 0

Menus for wxPythonMac
by Kevin & Masako Ollivier Jan. 27, 2002

Jan. 27, 2002

Sorry for the cross-posting, but I thought I'd cover all my bases! =) I'll briefly explain where I'm at. I'm using the Carbon version of Python 2.2, along with wxWindows and wxPython on OS X 10.1.2. I've pulled all the sources from CVS. Everything compiles, and so far I've been able to run wxPython scripts with a limited degree of success. However, the major problem is that I'm still having troubles with the menus. When I load a wxPython script in Python, Python's menubars stay active and the menus created by the script are nowhere to be found. Has anyone else experienced this? Also, when I run the script it does not open as a separate application in OS X. All windows are listed as child windows of the Python application. I'm wondering if these two issues are related. wxPython may not be able to modify Python's menus, and since it does not have its own application, it has no way of showing its own menus. Does this make sense? I admit I'm pretty new to Mac programming, and as such I'm a bit stuck as to what can be done about this problem. Any help would be appreciated! Thanks, Kevin

5 4

install problems
by Bruce Sherwood Jan. 26, 2002

Jan. 26, 2002

In the service of the VPython project (http://vpython.org), we are trying to compile Python 2.2 from source on a Mac. "Out of the box" we can't get compiles to work. We take the source for Python 2.2 and for GUSI2, and try to build using Metrowerks 7.0. We can't get GUSI to build because we get lots of compile errors. We can't build Python because it needs to link some missing GUSI libraries. We also got Python by CVS from sourceforge and tried to build, but an attempt to build gives large numbers of errors talking about missing files. The project settings for access paths in fact look wrong, listing only (Project): and (Compiler):. We thought we saw various statements about being able to compile "out of the box" (and also that the CVS download would give us everything, including GUSI files). Help? Thanks. David Andersen and Bruce Sherwood

3 2

Re: Carbon Tkinter/Python 2.2
by Christopher Smith Jan. 25, 2002

Jan. 25, 2002

>From: "Schollnick, Benjamin" <Benjamin.Schollnick(a)usa.xerox.com> >Crazy question... > >Are any of you running Multiprocessor systems? no, just regular 9.2.1 > > > >And what version of the Carbon Libraries are you folks using? I had an older verion (1.4, I think). I now installed 1.5. Here is the behavior that I note now (though this may not be due to library changes, just a different sequence of user events): I drop the recon.py script on the interpreeter I do not see any cursor ==> If I press a key then the Pointer cursor appears but I can't do anything with it in the console. I *can* however, collapse the window. I can also select the interpreter's window which makes it active, but then when I reclick on the console's window it doesn't come forward but it can still be collapsed. Furthermore, if I click in the menu bar (anywhere) the program crashes with a 1010 error. (After doing this several times, the system finally crashed as well with a bomb and error 10.) ==> If I click the mouse first, the cursor does not appear until the second click. I can successfully navigate between text boxes but when the mouse gets down in the check box region, it disappears but remains active (so I can blindly click on the check boxes even though I can't see the cursor). I can get the "event delayed" behavior that Jack noted by clicking on the desktop first AND THEN clicking in the console. If I anticipate where the console is going to be and move my mouse there before it disappears, then I can sussessfully navigate the window as I started this paragraph by saying. /c

3 2

Problems building 2.2
by Jon Bradley Jan. 25, 2002

Jan. 25, 2002

Hey everyone, Up and running with the new version - minus one thing. I can't get ConfigurePythonCarbon to run. ;( The traceback is a path that obviously doesn't exist - something on Jack's machine. Not only that but the application can't find the OS module, which is very odd. Doesn't make sense to me. I've tried a bunch of things, to no avail. Anyone have this problem or is able to help? thanks in advance! Jon Bradley Multimedia Developer

1 0

RE: [Pythonmac-SIG] Re: Carbon Tkinter/Python 2.2
by Schollnick, Benjamin Jan. 25, 2002

Jan. 25, 2002

> I confirmed that the program does work under the classic > configuration under OS 9.2 but not under the Carbon version. > I did notice that under the Classic version a double click is needed > to initially to get the program responding to my mouse, but after >that, everything works fine: mouse clicks switch me between boxes >and toggle checkboxes. > Under Carbon, as I mentioned, there is no cursor until I press a > key, but after I press a key there is not further response. I >cannot even get your observed sporadic behavior. When I did it > tonight, the system froze and I needed to reboot. Crazy question... Are any of you running Multiprocessor systems? I realize that the MOSX issue was with Multiprocessors, but I'm just curious if some version of the carbon libraries may also have issues with multiprocessors? And what version of the Carbon Libraries are you folks using? Has anyone tried the most recent release, I believe v1.5? - Benjamin

1 0

Carbon Tkinter/Python 2.2
by Christopher Smith Jan. 25, 2002

Jan. 25, 2002

Hello all, I'm having problems getting a program I use to be able to run to run under the new release (2.2) with Carbon/Tk upgrades. BACKGROUND The program is recon (a regular expression console) located at http://erburley.home.netcom.com/recon.py I have installed the "fourth attempt" PythonCoreCarbon and _tkinter* library file. I am using MacOS 8.6. BEHAVIOR The script is executed by the interpreter and successfully builds the console. However, as soon as I press any key, the cursor appears and the program does not respond to mouse clicks or typing (you are suppose to be able to enter text in a couple different text boxes and interact with check-boxes. I *was* able to see Hanoi from the Demo folder run successfully, so I know that it is possible to run a tkinter program. I am able to run the program under Classic (not Carbon) IDE and the interpreter on my non-carbon OS 8.5.1 system. Any ideas about why this is happening? /c

2 2

OS X import bug?
by Manoj Plakal Jan. 24, 2002

Jan. 24, 2002

Hello, I've just noticed a weird problem with importing modules on MacOS X 10.1 and Python 2.2. Say I have two modules foo and bar, both of which are built with a common file baz.c with some variables defined in it. I make a setup.py which specifies that module foo is built from foomodule.c and baz.c, and module bar is built from barmodule.c and baz.c. On Red Hat Linux 7.2 with Python 2.2, this builds fine and I can import both foo and bar into the same interpreter session. On OS X 10.1 with Python 2.2, this builds fine but I can only import *ONE* of foo or bar into the same interpreter session. E.g., if I import foo first and then bar, Python craps out saying "Failure linking new module". Similary for bar first and then foo. This is both with a version built from the 2.2 source release, as well as a binary version from Fink (fink.sourceforge.net). I've attached the files which can be used to reproduce this: setup.py, foomodule.c, barmodule.c, baz.c. In case the attachments don't work, you can grab them off the web: http://yumpee.org/python/setup.py http://yumpee.org/python/foomodule.c http://yumpee.org/python/barmodule.c http://yumpee.org/python/baz.c Is this a bug? Undefined behavior? Feature? Is it a fluke that it works on Linux? If someone else with OS X can reproduce this error, (and people on other OSes can confirm that it's working), that would be great ... Manoj # # Targets: build test install help # from distutils.core import setup, Extension # Distutils setup call setup ( ext_modules = [Extension('foo', ['foomodule.c', 'baz.c'], ), Extension('bar', ['barmodule.c', 'baz.c'], ), ] ) #include <stdio.h> #include <Python.h> extern int var_for_foo; static char foofun_doc[] = "Function fun in module foo"; static PyObject* foofun(PyObject* self, PyObject* args) { printf( "In foofun()\n" ); printf( "var_for_foo = %d\n", var_for_foo); return NULL; } static PyMethodDef kModuleMethods[] = { {"foofun", foofun, METH_VARARGS, foofun_doc}, {NULL, NULL } /* sentinel */ }; void initfoo() { PyObject* module; module = Py_InitModule("foo", kModuleMethods); printf( "var_for_foo = %d\n", var_for_foo); return; } #include <stdio.h> #include <Python.h> extern int var_for_bar; static char barfun_doc[] = "Function fun in module bar"; static PyObject* barfun(PyObject* self, PyObject* args) { printf( "In barfun()\n" ); printf( "var_for_bar = %d\n", var_for_bar); return NULL; } static PyMethodDef kModuleMethods[] = { {"barfun", barfun, METH_VARARGS, barfun_doc}, {NULL, NULL } /* sentinel */ }; void initbar() { PyObject* module; module = Py_InitModule("bar", kModuleMethods); printf( "var_for_bar = %d\n", var_for_bar); return; } int var_for_foo = 1; int var_for_bar = 6;

1 0

Locale on MacOS 9
by Francois Granger Jan. 24, 2002

Jan. 24, 2002

I am currently working on a multilinguale module. At the same time, PythonCard team is starting to think about localisation. So I did some search. On MacPython ther is an emulation of locale. But it does not work exactly the way I'd like ;-) On Windows: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'French_France.1252' >>> locale.getdefaultlocale() ('fr_FR', 'cp1252') On the Mac: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'C' >>> locale.getdefaultlocale() (None, 'mac-roman') Inside the file lib:locale.py line 303 it is said : To maintain compatibility with other platforms, not only the LANG variable is tested, but a list of variables given as envvars parameter. The first found to be defined will be used. envvars defaults to the search path used in GNU gettext; it must always contain the variable name 'LANG'. Where the list is 'LANGUAGE', 'LC_ALL', 'LC_CTYPE', 'LANG' I test defining os.envar before calling locale, but same answer. Any idea where I can look for this ?

3 4

package structure for OSA interfaces
by Michael J. Barber Jan. 24, 2002

Jan. 24, 2002

I've been taking a closer look at the structure of the packages produced by gensuitemodule. I'm a bit confused about the logic of the Standard Suites package. The StdSuites package is used to build packages for other applications, so is a fundamental part of gensuitemodule. As far as I can tell, the structure is suboptimal; hopefully someone can let me know what I'm missing, if anything. The modules I'm concerned with are StdSuites.Required_Suite and StdSuites.Standard_Suite. The required events are open, run, print, and quit. These four events are defined in Pythonic terms in StdSuites.Standard_Suite rather than StdSuites.Required_Suite. Apps that define the required events in their 'AppleScript Dictionary' work fine with this approach. However, many apps don't specify the required events, just relying on the default behavior (how that's done in terms of the apps' resources, I don't know) for AppleScript. For Python, gensuitemodule overlooks these four events, so that basic functionality is missing. One way to get that functionality is to copy the definitions for the required events from StdSuites.Standard_Suite into the Required_Suite for the app. It is also necessary to copy the _Enum_savo dictionary and the _enumdeclaration for 'savo' in order to get quit to work properly. I learned this trick from this list some time ago, and have applied it myself to a couple of apps since. It works, but I think there is a better way. If those definitions are in StdSuites.Required_Suite, then every app has them, no editing needed. It doesn't matter if the required events are also defined in StdSuites.Standard_Suite - no harm done either way. I've tried this out some, and it seems to work just fine. Another advantage to this set up is that we could easily generate interfaces for 'unscriptable' apps (which respond to the four required events regardless). All that would be needed is to include a skeleton for the __init__.py file, which can be changed to get the correct application signature, and maybe a 'friendlier' name for the main class. The only downside that I can see to defining the required events in StdSuites.Required_Suite is that gensuitemodule doesn't currently generate the appropriate structure, so if someone were to rebuild StdSuites, they'd have a problem. I've briefly looked through the source for gensuitemodule.py to see if that could be changed, but do not yet understand it well enough to say. Given a little more free time, I'll dig deeper. Does this make sense? Am I missing something important, or would this be a real improvement? -- Michael

5 12