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

Imported carbon C lib not allowed if using Tkinter?
by Sung H. Kim June 27, 2002

June 27, 2002

I have a Python extension question. Python script imports a C library (a carbonized lib), and that python script also uses Tkinter. Not allowed? Thank you. --Sung H. Kim

2 1

porting PyOpenGL to Mac OS X
by John Schmitt June 24, 2002

June 24, 2002

Did you guys receive this? Does this answer your question about why they're using the old SWIG? John -----Original Message----- From: Mike C. Fletcher [mailto:mcfletch@rogers.com] Sent: Sunday, June 23, 2002 7:17 PM To: Python List; PyOpenGL Subject: [PyOpenGL] Need for a C (lead) developer... Summary: PyOpenGL (the Python binding to the OpenGL graphics library) is in need of a C developer (preferably with SWIG experience) to work on maintaining and extending the package. Need is both short-term and long-term; we could use an immediate helping hand, but we're also looking for someone interested in long term work. PyOpenGL is a fairly large project (source-size), which is used by a considerable number of people (latest version has been downloaded something like 16,000 times). Developers looking to take on a popular project and make a name for themselves would find this a good opportunity. Current Tasks: PyOpenGL is currently generated using an old version of the SWIG wrapper generator (originally chosen because of missing features in other versions of SWIG with the idea that the missing features would eventually be adopted in newer SWIG versions (status of this unknown, but some work is definitely required to use the newer versions)). This build process tends to create lots of problems for those porting to new architectures, and we'd like to move off the (old, beta) version soon. This is a fairly extensive project, and will require familiarising yourself with the code base before making the attempt. We have a number of cross-platform build issues that need to be coordinated and integrated. In one case, we have already-submitted patches/fixes for fixing bug(s), in others, there are patches not yet submitted, but available. We need these integrated and tested. Integration is the developer requirement, we can get users with the exotic architectures to test the fixed versions. We have reports of complete meltdown under OpenGL 1.3 implementations under Linux. This is likely a trivial build or configuration problem, but it needs to be tracked down. Future Tasks: Maintenance of the package. Creation of new wrappers for common OpenGL modules (optional). Simplification of the build system for exotic architectures. Insert your PyOpenGL dreams here. Resources: The project has 3 administrators, myself (a designer with minimal (read non-existent) C coding skills), Tarn (author of the current code (current missing in action)) and Rene (who is/was primarily interested in the building and porting work). I work primarily on the OpenGLContext side (which provides a series of tests for the base implementation, and tends to uncover errors as I develop it). I tend to do the work on the web-site, and general answering of questions when I can. At the moment, we have no active C developers, and just myself working on the administrative front. The PyOpenGL work I'm doing is minimal due to other projects and the fact that I'm largely unqualified for the work that needs to be done. I am working on a way to use fonttools for rendering 3D text in PyOpenGL+OpenGLContext, but that's not going to help with the general coding that needs to get done. How to Get Involved: If you'd be interested in working as a developer, let me know and I'll see about adding you to the developer list. People familiar with the PyOpenGL codebase and project would be especially welcome. http://pyopengl.sourceforge.net/ With thanks, Mike Fletcher _______________________________________ Mike C. Fletcher http://members.rogers.com/mcfletch/ -- http://mail.python.org/mailman/listinfo/python-list

1 0

porting PyOpenGL to Mac OS X
by Andrew Straw June 24, 2002

June 24, 2002

Hi everyone, I am writing to inquire about the current state of PyOpenGL on Mac OS X. (I am cross-posting this email to both the PyOpenGL devel list and the Python Mac SIG list.) I have been "frozen" on Bob Ippolito's mega-build of Python with PyOpenGL (along with just about everything else) because I need PyOpenGL on Mac OS X, and I have been unable to get it to compile on Mac OS X myself. I am willing to put in some effort to bring the CVS version up to scratch, but I don't want to duplicate effort that others have put in. Has anyone successfully compiled PyOpenGL for Mac OS X since Bob did it in January? If so, I'd love to get a copy of your sources, a diff file, advice, or whatever other help you can offer. I hope some of the recent Python changes (especially the Mac specific ones -- thanks Jack and everyone else!) may make the process smoother, but PyOpenGL is notorious for difficult builds, and I'm certainly no Mac expert. (Cocoa, two level namespaces, and all the rest are way out of my realm of familiarity.) Thanks, Andrew ________________________________________________________ Andrew Straw Ph.D. student -- Department of Physiology, University of Adelaide, Australia Developer -- The Vision Egg -- http://www.visionegg.org/ andrew.straw(a)adelaide.edu.au ________________________________________________________

3 3

Warning: building MacPython from CVS instable
by Jack Jansen June 23, 2002

June 23, 2002

Folks, if you're building MacPython from CVS things may be unstable for a couple of days. I'm getting rid of classic builds, (finally) using precompiled headers wherever possible and restructuring the mess of mwerks_foo_config.h files. I'll try to check in bits and pieces only when they're finished, but I'm afraid I can't promise this'll work as I would like it to, so you may want to refrain from cvs updates for a few days. Note that this is only important to people building MacPython with CodeWarrior, MachoPython isn't affected. -- - Jack Jansen <Jack.Jansen(a)oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

1 0

Python and LabVIEW (yet another thought)
by Marcus H. Mendenhall June 21, 2002

June 21, 2002

>On Friday, June 21, 2002, at 03:27 , Marcus H. Mendenhall wrote: >>>To be completely sure that Python (and the underlying GUSI and >>>SIOUX libraries) don't touch any windows you can call >>>PyMac_SetConsoleHandler(PyMac_DummyReadHandler, >>>PyMac_DummyWriteHandler, PyMac_DummyWriteHandler) before calling >>>PyMac_Initialize(). See >> >> OK, I went ahead and looked at the source for the PyMac stuff to see whether this type of solution is feasible. The problem probably arises even earlier in the startup process than setting up the console handlers, since init_common initializes all the Mac toolbox stuff, even in the fully embedded (faceless) case. I may try to dredge up a Mac with a current copy of CW7, and build a custom PythonCore which does no mac UI initialization, and see if this can be made compatible with LabVIEW. If this works, it might not be a bad idea to add some switches so that it is easy to build versions of Python which can be embedded in full-fledged mac apps, which already have a running UI, and are likely to take exception to anyone reinitializing stuff. Basically, what I need is a copy of the unix Python compiled into the form of a Mac shared library, since most of the things I plan to do with it will have no need for Mac interface elements to be accessed from Python. Any thoughts? Marcus

3 2

Python and OSA
by Russell E Owen June 21, 2002

June 21, 2002

Jack asked (probably rhetorically): "(btw: are Bill and myself the only two people interested in Interface Builder and such, or is everyone just too busy?...)". Interesting question. If I understand correctly, making python a full OSA component means: - It could be used for easily for controlling programs via Apple Events (for instance any application that edits or runs AppleScript would edit or run Python scripts). - Perhaps (based on your reference to IB) Python could be used for programs with native Mac look and feel via InterfaceBuilder. Sounds like a good thing in principal, but not something I'd personally make use of right now. I certainly don't see myself writing Mac-specific anything, as most of my coworkers have moved off of the Mac platform. All my Python work at the moment is in cross-platform GUI programming (in Tkinter, sigh) and in basic utility scripts for text processing and such. I did a lot with AppleScript in the past. I wrote ROFM CGI, a free CGI for serving FileMaker Pro data, and it was painful because of the limitations in AppleScript. Python would have been wonderful. I've toyed with reviving ROFM with Python (now that FMPro has crippled web-serving capabilities in the affordable version), but I understand there's a PHP interface and plan to try that first. -- Russell

3 2

RE: [Pythonmac-SIG] error trying to run c extension from carbon P ython
by Magladry, Stephen June 21, 2002

June 21, 2002

Alright, with the information shared with me, found below, the standalone version is not the way to good. It will not jive well with what the code base on the PC side of project is doing. It looks like I'll set up an embedded python with a stub for our initialization. Our PC guys are using http://www.mcmillan-inc.com/install1.html. It packages up all the pyc files and redirects import calls to use this pre-packaged library and is totally free of any other version of Python that may exist on the machine. It looks like macfreeze will at least get me started. Anyone who wants to share their experiences with something think this, their input would be appreciated. I'll start exploring macfreeze and embedding Python. Thanks again for getting me going in the right direction. Stephen Magladry -----Original Message----- From: Jack Jansen [mailto:Jack.Jansen@cwi.nl] Sent: Friday, June 21, 2002 2:23 AM To: Magladry, Stephen Cc: 'pythonmac-sig(a)python.org' Subject: Re: [Pythonmac-SIG] error trying to run c extension from carbon P ython Ok, now I see what you're doing. It is possible to build applications this way (the Mac version fo our GRiNS product is done like this), but there are some gotchas. One important one is that you cannot load dynamic modules into a static Python.

1 0

Embedded: application delivery?
by John Stewart June 21, 2002

June 21, 2002

Hello, We're working on embedding python as a scripting language within a shared library for MacOS 8/9. We have the interpreter starting up, and have managed to kill the console window by editing the prefs. The big question now is this: we need to use various modules (networking, for example), and need to have the prefs set. What is the recommended manner for delivery and installation of an application along with the python libs and modules and pre-set prefs, so that we can use a single installer? Thanks, jds

1 0

Design question - where should resources go?
by Jack Jansen June 21, 2002

June 21, 2002

Folks, playing with Bill's wonderful new OSA stuff (btw: are Bill and myself the only two people interested in Interface Builder and such, or is everyone just too busy? In just one week two people announce stuff that allows Python to be used with IB, and nobody else seems interested....) I noticed a problem with MachoPython that I already knew was there, but managed to ignore up until now. The problem is that I don't know where to put various resources (.rsrc files, in other words). Historically, MacPython has been sloppy about where resources were. Some were in the application (although that's mainly to allow them to be overridden with EditPythonPrefs) and most were in PythonCore. Actually, there's some stuff in PythonCore that doesn't really belong there. For example the DLOG resources and such used by EasyDialogs: they've always been in PythonCore, but they really belong in Mac/Lib/EasyDialogs.rsrc (just like all other private resources). For MachoPython i took the quick and dirty approach of stuffing all resources into a Python.rsrc file inside the Python.app application. This is fine if you are using Python.app (or a copy of it) to run your stuff, but breaks in other cases (such as when using Python through Script Editor with Bill's python scripting component). If you attempt to use EasyDialogs it simply won't work (resource not found) and other things also work sub-optimal (i.e. no explanatory strings for MacOS error codes are available). What I'm planning to do is to move the core resources into /Library/Framework/Python.framework, where they belong. What I'm not 100% sure about is the EasyDialogs resources (and similar ones). I'm tempted to put them in their own .rsrc file in the Lib folder. But: this may break things if people expect these resources to be available outside of EasyDialogs. Any ideas on this matter? -- - Jack Jansen <Jack.Jansen(a)oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

2 1

Python embedding in LabVIEW on Mac? (oops, found part of the problem)
by Marcus H. Mendenhall June 21, 2002

June 21, 2002

>Hi, All. > >I recently came across a need to access Python code from inside of >LabVIEW to do some data analysis. Under LabVIEW 6i for Windows, >calling Py_Initialize works fine. Using LabVIEW 5.0.1 under MacOS >8.x and 9.x (OK, I haven't updated my LabVIEW install yet to >anything approaching current... anyone know if it is OK under LV6 >for Mac?) calling Py_Initialize results in LabVIEW quietly exiting. >It appears that ExitToShell() is called, since there is no sign of >of a crash. > >Under what conditions does Py_Initialize fail in such a way? I have >tried starting LabVIEW from various directories, including the one >containing PythonCore, in case paths are bad resulting in inability >to find resources. If have also called Py_SetProgrameName before >PyInitialize, with the full path to PythonCore as the name, just in >case that would help. No luck. > >Since it is likely a quite painful process to follow through the >innards of LabVIEW with a debugger, it seems more likely to be >fixable by following through the Python startup. > >Thanks for any ideas anyone might have, before I waste a lot of time >poking around my self rather blindly. > >Marcus Mendenhall >Vanderbilt University Free Electron Laser Center OK, in response to my own post (sorry), I found an oops involving calling Py_Initialize instead of PyMac_Initialize . Now, LabVIEW gets much farther into the embedding startup, but still doesn't quite work. The remaining, important question is whether any has had this work under newer version of LabVIEW, since the 5.0.1 release is quite old. thanks again. Marcus Mendenhall

3 3