[Pythonmac-SIG] @reboot
Hi, [ apologies about this not really being directly related to python mac... ] I am trying ro use an @reboot cron job to start an svn server (used for python development ;) with each restart (of a Panther G5 powermac). I have edited the file /etc/crontab, adding the line: @reboot svnserve -d -r /var/svn but, after restart, there is no svn server daemon running: $ ps -aux | grep svn x449 0.0 0.018172336 std S+ 11:03AM 0:00.01 grep svn $ Cannot tell where the problem is... The system.log contains the following potentially relevant lines: May 27 10:47:15 localhost SystemStarter: Initializing network May 27 10:47:15 localhost cron[176]: (*system*) PARSE (bad username) Any ideas? Thanks, mario ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] PYTHONPATH
How do I set my PYTHONPATH in OS X? I am using python2.4 installed via Darwinports in /opt/local/bin/python. Thanks. Daniel S. Hartmanstorfer II Opportunity is missed by most because it is dressed in overalls and looks like work. -Thomas Edison ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work
I can't find where you said that extensions shouldn't be linking to Python at all. I also can't understand how this could be the case, at least if we're building the extensions using Boost.Python (which we are). I've tried to build without linking to it, and it compiles but I end up with a bunch of missing symbols from Python. When we started this whole project about a year and a half ago, distutils basically didn't work. We now have several extensions and over 100K lines of complex C++ code distributed in several hundred files in a cross-platform application. We had a difficult enough time getting XCode to handle it. After staring at what passes for distutils documentation for a while, I can't even figure out if it will handle a Boost.Python extension, and trying to get it to do our complete build seems like great way to waste several days. We finally did it manually. After the call to setup(), our setup.py iterates over the constructed modules in the built .app using macholib to find all the occurrences of /Libraries/Frameworks/Python.framework etc and convert them to @executable_path/../Frameworks. What I had hoped for was some hint along the lines of here's how you can convince py2app to do that for you automatically. OS X documentation is generally of the class that you only know what you need to know after you've already found it (and tried a zillion wrong answers). It's really pretty horrible to figure this stuff out for the first time. We'd like to do things right, but The One True Way is a hard path to find and follow. Maybe after you've already trod it, you can look back and say that was obvious, but it sure isn't obvious when you're working your way along it for the first time. Kent -Original Message- From: Bob Ippolito [mailto:[EMAIL PROTECTED] Sent: Thursday, May 26, 2005 1:48 PM To: Kent Quirk Cc: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work As I said before, your extensions shouldn't be linking to Python *at all*. Read that part again, and fix the way your extensions are getting linked. (and this is why people should use distutils to link their extensions, because it knows how to link things right) -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] PYTHONPATH
On Friday, May 27, 2005, at 03:12PM, Daniel S. Hartmanstorfer II [EMAIL PROTECTED] wrote: How do I set my PYTHONPATH in OS X? I am using python2.4 installed via Darwinports in /opt/local/bin/python. Thanks. Why do you want to do that? It's often (if not almost always) better to use a pth-file in site-packages. PYTHONPATH can be useful during development (easily switching between various versions of a library), but not in a production environment. Ronald Daniel S. Hartmanstorfer II Opportunity is missed by most because it is dressed in overalls and looks like work. -Thomas Edison ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work
On Friday, May 27, 2005, at 03:33PM, Kent Quirk [EMAIL PROTECTED] wrote: I can't find where you said that extensions shouldn't be linking to Python at all. I also can't understand how this could be the case, at least if we're building the extensions using Boost.Python (which we are). The quick summary: if you link against python you're extension will work with just the variant of python that you linked against. If you do not link against python (as distutils does with current version of python) you can use extensions with multiple variants of python (/Library/Frameworks/Python.framework, /System/Library/Frameworks/Python.framework,/opt/local/bin/python, ...) as long as they have the same major relase. This is very important on Panther because /System/Library/Python.framework and /Library/Python.framework (2.3.0 vs. 2.3.5) share the same site-packages directory. This is explained somewhere on the pythonmac mailinglist. Look for 'Why do I need PantherPythonFix'. Ronald ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] @reboot
On May 27, 2005, at 5:11 AM, Mario Ruggier wrote: Cannot tell where the problem is... The system.log contains the following potentially relevant lines: May 27 10:47:15 localhost SystemStarter: Initializing network May 27 10:47:15 localhost cron[176]: (*system*) PARSE (bad username) Any ideas? Mario, I believe that cron runs as a different effective user (root?), even for tasks in your personal crontab. Also, it doesn't have quite the same environment vars that you'd normally have in the shell. I've had trouble calling Growl (OS X notification) popups from cron for this reason. You might try writing an executable shell script to launch svn, then putting it in the /Library/StartupItems. Yeah, it looks like someone's already doing this: http://svn.haxx.se/users/archive-2004-05/1140.shtml Good luck! =jimA= . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jim Allman Interrobang Digital Media http://www.ibang.com/ (919) 649-5760 ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] making a C extension compatible across OS versions?
On May 27, 2005, at 4:29 AM, has wrote: Bob wrote: Will extensions built on 10.4 work on 10.3, or will I have to create separate OS-specific binaries for those as well? Maybe, it depends. You really should be building packages on the least common denominator, you have to test there anyway. It's hard to do right, Xcode is the only environment that can properly manage SDKs and such, Apple didn't really put that functionality anywhere else, and autoconf REALLY gets in the way (i.e. ./configure). Not a problem for other modules where the APIs are the same over multiple OSes. (I've had no problems so far using .so binaries built on Jaguar under Tiger, for example.) Given that OSATerminology needs to use Tiger's weak-lined OSACopyScriptingDefinition function when running under Tiger, is it possible/practical to build it on Panther? It sounds like the easiest thing would be to put the Tiger-only code in a separate file and build that on Tiger, and build the remainder on an older OS as before; then have osaterminology import or ignore the Tiger- only extension at runtime as appropriate. Yeah, the easiest thing is basically to do that, or to build an entirely separate version for users with Tiger. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] best way to get os version?
Hi all, Apropos to last thread, what's the best way to check Mac OS version from Python at runtime? Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] best way to get os version?
On May 27, 2005, at 12:26 PM, has wrote:
Apropos to last thread, what's the best way to check Mac OS version
from Python at runtime?
platform.mac_ver() is probably the easiest way, but there was a bug
in Python 2.3.0 that prevents it from working there (i.e. Apple
Python on Mac OS X 10.3)
The other way with stock Python is to use gestalt.gestalt('sysv')
directly, which returns the version in BCD.
See also:
http://mail.python.org/pipermail/pythonmac-sig/2004-May/02.html
-bob
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] best way to get os version?
platform.mac_ver() is probably the easiest way, but there was a bug in Python 2.3.0 that prevents it from working there (i.e. Apple Python on Mac OS X 10.3) That seems to make it essentially useless. Why tell us about it? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] SetSystemUIMode in python?
Howdy -- I'm working on a kiosk app, and I'd like to use SetSystemUIMode and friends (defined in MacApplication.h inside HIToolbox.framework). As far as I can tell, the HIToolbox framework isn't exposed in MacPython anywhere, but I might be missing something. Before I start figuring out how to wrap these functions myself, am I right in thinking there's currently no way to get at them from MacPython? Also, if I do end up needing to write an extension to get at them, can anyone suggest the best way to go about this? Specifically, is Pyrex a good tool to use for wrapping Carbon APIs like this? I've not written an extension since I became aware of Pyrex... Thanks, Jacob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] SetSystemUIMode in python?
While Pyrex is a pretty reasonable way to write extensions, PyObjC or ctypes is generally less painful when wrapping a small number of functions. This is very interesting. I thought the basic choices for wrapping C functions were: * Pyrex * ctypes * Write Obj-C and import with PyObjC I hadn't realized that you could import functions with PyObjC and no (additional) intervening Obj-C code. Very very cool. --Dethe ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] SetSystemUIMode in python?
On May 27, 2005, at 3:01 PM, Dethe Elza wrote: While Pyrex is a pretty reasonable way to write extensions, PyObjC or ctypes is generally less painful when wrapping a small number of functions. This is very interesting. I thought the basic choices for wrapping C functions were: * Pyrex * ctypes * Write Obj-C and import with PyObjC * SWIG (ughh) * Write C++ and use Boost.Python (ugh) * Python C API directly (not really *that* bad) ... I hadn't realized that you could import functions with PyObjC and no (additional) intervening Obj-C code. Very very cool. This functionality has been there since 1.2 (2004-12-29). -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] SetSystemUIMode in python?
On May 27, 2005, at 4:18 PM, Dethe Elza wrote: On 27-May-05, at 4:05 PM, Bob Ippolito wrote: I hadn't realized that you could import functions with PyObjC and no (additional) intervening Obj-C code. Very very cool. This functionality has been there since 1.2 (2004-12-29). Yes, I realize I'm late to the party, just discovering this now. It's cool enough to be given more air-time, IMHO. It's sort of black magic, and it's not very convenient unless you really know what you're doing (type signatures, etc.). It's also not as complete as ctypes is with regard to pointers to things (i.e. variable length arrays), because PyObjC doesn't offer that abstraction yet. When the new scanner stuff is prime time, it'll get some air-time (indirectly). That said, for simple functions with simple arguments and return values, it's great if you understand the Objective-C type signatures involved :) -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Apple's python extensions into Quartz2D
Hi, What's the latest with Apple's python extensions to use Quartz2D? I'd like to use them with the latest python release but I can't figure out where the original source code for the extensions are so I can't do a build. It looks like they used SWIG, but that's about as much as I figured out. Or this is something I might be able to do with PyObjC (which I never have used)? Or is there another alternative? thanks, --nickg ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Apple's python extensions into Quartz2D
On May 27, 2005, at 6:32 PM, nickg wrote: What's the latest with Apple's python extensions to use Quartz2D? I'd like to use them with the latest python release but I can't figure out where the original source code for the extensions are so I can't do a build. It looks like they used SWIG, but that's about as much as I figured out. They're not open source. You can't use them with anything but the release of Python that ships with Mac OS X. File a bug. I filed mine over a year ago: rdar://3540071 Python CoreGraphics extension can't readily be used by other Python versions 26-Jan-2004 02:10 PM I updated it this april to say hey, this actually matters now that 2.4.1 is out there, but I still have not received a response. I believe the reason is that the extension does some really horrible nasty SPI hacks in order to lift some of the restrictions that are normally imposed by these APIs (WindowServer connections, etc.) At least, that's what I gathered from reverse engineering it a bit. Or this is something I might be able to do with PyObjC (which I never have used)? Or is there another alternative? It depends on what you're trying to do. The Cocoa APIs are higher level than Quartz2D and imposes a few restrictions along the way. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Apple's python extensions into Quartz2D
thanks for the reply. Odd, the Python API is nearly 1-1 with the CoreGraphics C API so I wouldn't expect any hacks. Oh well. I'm just using it to draw into a PDF or buffer to save a file. No UI or Windows needed. Can PyObjC make these calls? I'm new to the all the mac-python trickery. --nickg On May 27, 2005, at 9:39 PM, Bob Ippolito wrote: On May 27, 2005, at 6:32 PM, nickg wrote: What's the latest with Apple's python extensions to use Quartz2D? I'd like to use them with the latest python release but I can't figure out where the original source code for the extensions are so I can't do a build. It looks like they used SWIG, but that's about as much as I figured out. They're not open source. You can't use them with anything but the release of Python that ships with Mac OS X. File a bug. I filed mine over a year ago: rdar://3540071 Python CoreGraphics extension can't readily be used by other Python versions 26-Jan-2004 02:10 PM I updated it this april to say hey, this actually matters now that 2.4.1 is out there, but I still have not received a response. I believe the reason is that the extension does some really horrible nasty SPI hacks in order to lift some of the restrictions that are normally imposed by these APIs (WindowServer connections, etc.) At least, that's what I gathered from reverse engineering it a bit. Or this is something I might be able to do with PyObjC (which I never have used)? Or is there another alternative? It depends on what you're trying to do. The Cocoa APIs are higher level than Quartz2D and imposes a few restrictions along the way. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Apple's python extensions into Quartz2D
On May 27, 2005, at 7:00 PM, nickg wrote: On May 27, 2005, at 9:39 PM, Bob Ippolito wrote: On May 27, 2005, at 6:32 PM, nickg wrote: What's the latest with Apple's python extensions to use Quartz2D? I'd like to use them with the latest python release but I can't figure out where the original source code for the extensions are so I can't do a build. It looks like they used SWIG, but that's about as much as I figured out. They're not open source. You can't use them with anything but the release of Python that ships with Mac OS X. File a bug. I filed mine over a year ago: rdar://3540071 Python CoreGraphics extension can't readily be used by other Python versions 26-Jan-2004 02:10 PM I updated it this april to say hey, this actually matters now that 2.4.1 is out there, but I still have not received a response. I believe the reason is that the extension does some really horrible nasty SPI hacks in order to lift some of the restrictions that are normally imposed by these APIs (WindowServer connections, etc.) At least, that's what I gathered from reverse engineering it a bit. Or this is something I might be able to do with PyObjC (which I never have used)? Or is there another alternative? It depends on what you're trying to do. The Cocoa APIs are higher level than Quartz2D and imposes a few restrictions along the way. Odd, the Python API is nearly 1-1 with the CoreGraphics C API so I wouldn't expect any hacks. Oh well. Image loading and initialization are whack. It also installs several categories on AppKit classes that probably break stuff if you happen to import CoreGraphics from a GUI app. File a bug. I'm just using it to draw into a PDF or buffer to save a file. No UI or Windows needed. Can PyObjC make these calls? I'm new to the all the mac-python trickery. Again, it depends. The API is different, so for some definitions of draw it will work just fine, but not all of them. You can probably do something equivalent, but it's going to require a WindowServer connection (i.e. invoked by pythonw as root or by the logged-in user). File a bug. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] SetSystemUIMode in python?
Bob wrote: * SWIG (ughh) * Write C++ and use Boost.Python (ugh) * Python C API directly (not really *that* bad) Well, I've looked at all of these, and I've gotta disagree with the Ugh on Boost.Python. At least for large projects. If (like me) you have large quantities of existing C++ to deal with, Boost.Python is actually really nice. You can build Python classes that inherit from C++ classes, you can built C++ classes that inherit from Python classes. You can write free functions, you can construct enums, and you basically use it by writing down some simple definitions. Your C++ code is idiomatic AND your Python code is idiomatic. Example: using Boost.Python, we constructed an Event (publish/subscribe) system that allows for arbitrary data to be passed as Python dictionaries. Events, queues and listeners can be constructed on either side of the fence and interoperate cleanly. You can have an arbitrary number of event queues. It's a remarkably easy and clean way to pass messages around between a collection of otherwise-disconnected components, and lets us keep static coupling to a minimum. Boost.Python isn't for everyone, but in our system it was a lifesaver. Kent ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] SetSystemUIMode in python?
On May 27, 2005, at 7:22 PM, Kent Quirk wrote: Bob wrote: * SWIG (ughh) * Write C++ and use Boost.Python (ugh) * Python C API directly (not really *that* bad) Well, I've looked at all of these, and I've gotta disagree with the Ugh on Boost.Python. At least for large projects. If (like me) you have large quantities of existing C++ to deal with, Boost.Python is actually really nice. Yes, of course, reusing existing code always wins, but in this case there is exactly 0 lines of existing C++ code. Introducing C++ and Boost.Python to the equation sounds quite masochistic to me. I'm not saying Boost.Python sucks, because it doesn't *if you have C+ + code*. It is a hammer best suited for nails manufactured in another universe. You can build Python classes that inherit from C++ classes, you can built C++ classes that inherit from Python classes. You can write free functions, you can construct enums, and you basically use it by writing down some simple definitions. Your C++ code is idiomatic AND your Python code is idiomatic. PyObjC (with Objective-C) gives you this too, minus some of the idiomatic on the Python side -- but it requires no glue and happens at runtime, which is well worth the trade. Example: using Boost.Python, we constructed an Event (publish/ subscribe) system that allows for arbitrary data to be passed as Python dictionaries. Events, queues and listeners can be constructed on either side of the fence and interoperate cleanly. You can have an arbitrary number of event queues. It's a remarkably easy and clean way to pass messages around between a collection of otherwise-disconnected components, and lets us keep static coupling to a minimum. Boost.Python isn't for everyone, but in our system it was a lifesaver. Except for the fact its build system is *crazy* and is causing you unnecessary headaches on the Mac... Anyway, I was referring to the fact that Boost.Python would be introducing new C++ code where there was none before. On top of that, you'd be adding glue code, another programming language, another compiler, a Python extension, and a funky ABI requirement to the mix. Wrapping with Objective-C takes no more effort than C++ (probably less), doesn't introduce a new compiler, and doesn't even tie you to a particular version of Python (since you just pull in the class from your wrapper at runtime, and you have no Python extension module). Wrapping in Pyrex is even easier than Objective-C, except when dealing with CoreFoundation toll-free bridged types, but can be a PITA to debug since it's a pre-processor for C and it does give you a Python extension. Not wrapping at all is best of course, which is why I suggested PyObjC's loadBundleFunctions or ctypes. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Apple's python extensions into Quartz2D
nickg wrote: thanks for the reply. Odd, the Python API is nearly 1-1 with the CoreGraphics C API so I wouldn't expect any hacks. Oh well. I disliked the implementation (undocumented, closed source SWIG bindings are largely unusable), so I wrote my own using Pyrex. I call it, unimaginatively, ABCGI, A Better CoreGraphics Interface. It is part of Kiva, Enthought's graphics library, and has served as ground truth for the other backends. When I get some time, I'll break it out as a separate package. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
