Re: [Pythonmac-SIG] Building a debug framework build of Python
Apple has the sources of the open-source components of OSX on their website, the python bits for 10.5.7 are here: http://www.opensource.apple.com/source/python/python-30.1.3/ . I haven't checked if this includes the configure invocation, although you could always use distutils to query the value of 'CONFIG_ARGS' . Ronald On 2 Jun, 2009, at 2:14, Bill Janssen wrote: I'd like to be able to connect to my Python programs, mainly long-running servers, and see what's going on in specific threads. To do that, I need a version of Python that's compiled with debug symbols in it. What's the correct invocation to build a debug version of Python (2.5) which matches what ships with OS X 10.5.7? I don't intend to replace the system Python; I just want to match it as closely as possible for debugging. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Can't get ASDictionary to work (py2app problems?)
On 2 Jun, 2009, at 7:11, Nicholas Riley wrote: On Mon, Jun 01, 2009 at 09:19:01PM +0100, has wrote: Odd. The osax module appears to be puking on a System Events command (it uses SE to get a list of installed osaxen). What versions of appscript and ASDictionary? What happens if you try to import the osax module into a regular script? Anything unusual about your setup (permissions, haxies, etc.)? Gah, I should have thought of this. I've got Default Folder X installed, which loads itself by pretending to be an osax. When I disabled it, ASDictionary opened successfully. I'll report it as a bug in Default Folder X. PyObjC/py2app questions I'll leave to those that know more about these things. (FWIW, I build ASDictionary using user-installed Python 2.5.2 framework + PyObjC 1.x for portability.) Anyone (Ronald?) have any idea about these problems? They're less important given that I have a fix for my ASDictionary issue, but still seem pretty serious. I don't have time to look into the py2app issues right now. That said, I wouldn't install a new version of pyobjc in the system install of python because this might break other bits of the system. Ronald Thanks, -- Nicholas Riley njri...@uiuc.edu x ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Can't get ASDictionary to work (py2app problems?)
To bring a (temporary) conclusion to all of this, the reason I upgraded the system version of py2app (or rather its dependency, modulegraph) was that it was incompatible with the current version of setuptools (0.7a1). I think this is actually a setuptools bug, which I've reported: http://bugs.python.org/setuptools/issue74 After removing my compiled versions of PyObjC, py2app, modulegraph *and* setuptools, then installing aemreceive, osaterminology and HTMLTemplate, ASDictionary built and runs fine against the stock 10.5 Python/PyObjC/py2app. That was painful, but hopefully this thread means nobody else will have to go through it :-) -- Nicholas Riley njri...@uiuc.edu ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Can't get ASDictionary to work (py2app problems?)
On Jun 2, 2009, at 1:58 AM, Ronald Oussoren wrote: I don't have time to look into the py2app issues right now. That said, I wouldn't install a new version of pyobjc in the system install of python because this might break other bits of the system. Thanks for the warning - you may want to make this clear in big letters on the PyObjC Web site. --Nicholas ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building a debug framework build of Python
Thanks, Ronald. It looks to me as if MacPython already includes the -g flags appropriately (at least build-script.py does); could I just download 2.5.4 from python.org and use that for debugging? Bill Ronald Oussoren ronaldousso...@mac.com wrote: Apple has the sources of the open-source components of OSX on their website, the python bits for 10.5.7 are here: http://www.opensource.apple.com/source/python/python-30.1.3/ . I haven't checked if this includes the configure invocation, although you could always use distutils to query the value of 'CONFIG_ARGS' . Ronald On 2 Jun, 2009, at 2:14, Bill Janssen wrote: I'd like to be able to connect to my Python programs, mainly long-running servers, and see what's going on in specific threads. To do that, I need a version of Python that's compiled with debug symbols in it. What's the correct invocation to build a debug version of Python (2.5) which matches what ships with OS X 10.5.7? I don't intend to replace the system Python; I just want to match it as closely as possible for debugging. Bill ___ 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] Building a debug framework build of Python
On 2 Jun, 2009, at 17:26, Bill Janssen wrote: Thanks, Ronald. It looks to me as if MacPython already includes the -g flags appropriately (at least build-script.py does); could I just download 2.5.4 from python.org and use that for debugging? Not necessarily. Apple's version of python includes a number of patches, some of which will affect the debug symbols (such as some support for dtrace). What I tend to do when I need to debug C code is to develop using the python.org installer which, as you mentioned, contains debugging symbols. The resulting C code should then work fine with the Apple installation of python. For really annoying bugs I have yet another seperate installation that was compiled using --with-pydebug, this tends to be the most helpful when dealing with refcounting bugs in C extensions. Ronald Bill Ronald Oussoren ronaldousso...@mac.com wrote: Apple has the sources of the open-source components of OSX on their website, the python bits for 10.5.7 are here: http://www.opensource.apple.com/source/python/python-30.1.3/ . I haven't checked if this includes the configure invocation, although you could always use distutils to query the value of 'CONFIG_ARGS' . Ronald On 2 Jun, 2009, at 2:14, Bill Janssen wrote: I'd like to be able to connect to my Python programs, mainly long-running servers, and see what's going on in specific threads. To do that, I need a version of Python that's compiled with debug symbols in it. What's the correct invocation to build a debug version of Python (2.5) which matches what ships with OS X 10.5.7? I don't intend to replace the system Python; I just want to match it as closely as possible for debugging. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building a debug framework build of Python
Actually, I'm debugging Python code, but it's running in a multi-threaded Python server. So I need to attach with gdb to see what's going on. It would be nice if Thread Viewer had the ability to decode Python stack traces. Thanks for the info. I'll try building using the Apple sources. Bill Ronald Oussoren ronaldousso...@mac.com wrote: On 2 Jun, 2009, at 17:26, Bill Janssen wrote: Thanks, Ronald. It looks to me as if MacPython already includes the -g flags appropriately (at least build-script.py does); could I just download 2.5.4 from python.org and use that for debugging? Not necessarily. Apple's version of python includes a number of patches, some of which will affect the debug symbols (such as some support for dtrace). What I tend to do when I need to debug C code is to develop using the python.org installer which, as you mentioned, contains debugging symbols. The resulting C code should then work fine with the Apple installation of python. For really annoying bugs I have yet another seperate installation that was compiled using --with-pydebug, this tends to be the most helpful when dealing with refcounting bugs in C extensions. Ronald Bill Ronald Oussoren ronaldousso...@mac.com wrote: Apple has the sources of the open-source components of OSX on their website, the python bits for 10.5.7 are here: http://www.opensource.apple.com/source/python/python-30.1.3/ . I haven't checked if this includes the configure invocation, although you could always use distutils to query the value of 'CONFIG_ARGS' . Ronald On 2 Jun, 2009, at 2:14, Bill Janssen wrote: I'd like to be able to connect to my Python programs, mainly long-running servers, and see what's going on in specific threads. To do that, I need a version of Python that's compiled with debug symbols in it. What's the correct invocation to build a debug version of Python (2.5) which matches what ships with OS X 10.5.7? I don't intend to replace the system Python; I just want to match it as closely as possible for debugging. Bill ___ 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
[Pythonmac-SIG] Python Core Graphics Question (resent)
Hi all (I just resent this message as I couldn't it find it on the digest even after days - again, I apologise for any cross-posting) Below is a piece of code that I found over in the quartz-dev list. I've been using this function unchanged in a batch processor, and it appears to leak memory quite substantially. So much so that my test machine (1Gb memory) , a mac mini, and my production xserve (2 Gb memory) both crashed using it. My dev machine, an imac (4Gb memory) slowed, but stayed up. I think I have the problem down to croppedimg = srcimg.createWithImageInRect(cliprect). If used with an image of suffient size, it quickly sucks up all available memory. Has anyone experienced similar problems using this method? Its Obj-C name is CGContextCreateWithImageInRect. And I should think that one would only see something bad happening in some sort of batch processing. Incidentally, my workaround was to lower the size of the source image. But the process is still quite unstable. It brought down my xserve after processing 7000 of the 7600 odd items. I've pasted the original post below. And sorry for any cross - posting. Cheers, Geert -- Geert Dekkers Web Studio | 2e Keucheniusstraat 8HS 1051VR Amsterdam | +31(0)627224301 | http://nznl.net -- Thanks for you detailed reply Glen - much appreciated. You helped me to solve what i was trying to do by using CGImageCreateWithImageinRect as suggested. For anyone else interested here is some simple python code for making cropped thumbnails of any proportion and not loosing the aspect ratio of the original image. ...and its damn fast! --- #!/usr/bin/python from __future__ import division import CoreGraphics def resizeimage(srcimage,targetimage, tw, th): srcimg = CoreGraphics .CGImageImport (CoreGraphics.CGDataProviderCreateWithFilename(srcimage)) sw = srcimg.getWidth() sh = srcimg.getHeight() aspect = tw/th widthfactor = tw/sw heightfactor = th/sh if widthfactor heightfactor: #src height stays the same #src width gets cropped cropwidth = sh * aspect x1 = ((sw-cropwidth)/2) y1 = 0 x2 = sw-((sw-cropwidth)) y2 = sh else: #src height gets cropped #src width stays the same cropheight = sw / aspect x1 = 0 y1 = ((sh-cropheight)/2) x2 = sw y2 = sh-((sh-cropheight)) cliprect = CoreGraphics.CGRectMake(x1, y1, x2, y2) croppedimg = srcimg.createWithImageInRect(cliprect) cs = CoreGraphics.CGColorSpaceCreateDeviceRGB() c = CoreGraphics.CGBitmapContextCreateWithColor(tw, th, cs, (0,0,0,0)) c.setInterpolationQuality(CoreGraphics.kCGInterpolationLow) newRect = CoreGraphics.CGRectMake(0, 0, tw, th) c.drawImage(newRect, croppedimg) c.writeToFile(targetimage, CoreGraphics.kCGImageFormatJPEG) resizeimage(/users/adam/Desktop/bootlogo4pa8.jpg, /users/adam/ Desktop/a.jpg , 80,80) On Aug 12, 2008, at 3:41 AM, Glenn Cole wrote: Hi, Adam -- I'm no expert, but until others more knowledgeable respond, here's my understanding. First, I suspect the fact that you're using Python won't matter at all here. (It does in other circumstances, but I don't think so here.) It sounds like you're looking for more support from Quartz for your task than what's really there. In the end, I think it's going to be more a choice of algorithm on your part. For example, given different aspect ratios, the new image could either: 1. ignore the difference (i.e., the current behaviour) 2. show the entire original image within the new target, respecting the aspect ratio 3. clip the original image to match the new aspect ratio For #2, you could shrink the target rect to match the aspect ratio of the original image. For #3 (your goal), you could clip the original image to match the target aspect ratio. However, page 250 of the outstanding Programming With Quartz notes a few downsides to this, and suggests using CGImageCreateWithImageInRect instead (first available in Tiger) to define a subimage of the original image. Again, though, you would need to determine yourself that the subimage should ignore 100 pixels from the left and right sides of the original image. At least, that's my take on things. We'll see what others say (though they've tended to ignore Python questions in the past). Incidentally, the subject line says Core Image resize question. The code below has no reference to Core Image, and I'm pretty sure that Core Image need not be involved in this task at all. (Perhaps you mentioned Core Image because of the existence of its CICrop filter, but I think that's not the best direction for the task at hand.) --Glenn On Aug 11, 2008, at 5:33 AM, Adam Jones wrote: Hi there i am wondering if someone can help me with this. Below is the code i am using to resize and save a jpeg
Re: [Pythonmac-SIG] Building a debug framework build of Python
Yes, I do use the threading module, but it's not quite that simple. Some of my threads are actually running Java code, for PyLucene. This is part of UpLib, at http://uplib.parc.com/. Thanks for the pointers. Is there a home site for rpdb2? Or is it just part of winpdb? The nice thing about gdb is that it doesn't need to be on top; you can attach to a server you started without any magic invocation. UpLib has a complicated startup dance, and it's hard to start it with the kind of invocation needed for debuggers like rpdb2. Bill THREADING = None HAVE_PYLUCENE = None if @USE_PYLUCENE@ == jcc: # make sure the JVM DLL is on our path, a side-effect of finding the JAVAHOME find_JAVAHOME() HAVE_PYLUCENE = jcc THREADING = python class JavaCapableThread(threading.Thread): def run(self): if uthread.JAVA_ENV: uthread.JAVA_ENV.attachCurrentThread(self.getName(), self.isDaemon()) super(JavaCapableThread, self).run() if uthread.JAVA_ENV: uthread.JAVA_ENV.detachCurrentThread() class uthread: conf = configurator.default_configurator() maxheap = conf.get(java-max-heap, 512m) maxstack = conf.get(java-max-stack, 100m) vmargs = conf.get(java-vm-args, -Djava.awt.headless=true) def initialize(cls): import lucene cls.JAVA_ENV = lucene.getVMEnv() or lucene.initVM(classpath=lucene.CLASSPATH, vmargs=cls.vmargs, initialheap=64m, maxheap=cls.maxheap, maxstack=cls.maxstack) # make sure we can call in on the main thread cls.JAVA_ENV.attachCurrentThread(threading.currentThread().getName(), threading.currentThread().isDaemon()) initialize=classmethod(initialize) def get_ident(): return repr(threading.currentThread()) get_ident = staticmethod(get_ident) def create_new_thread(name, fn, args): t = JavaCapableThread(None, fn, name, args) note(0, creating new thread %s, t) t.setDaemon(true) return t create_new_thread=staticmethod(create_new_thread) def start_new_thread(fn, args, name=None): t = JavaCapableThread(None, fn, name, args) note(0, starting new thread %s, t) t.setDaemon(true) t.start() return t start_new_thread = staticmethod(start_new_thread) def allocate_lock(): return threading.RLock() allocate_lock = staticmethod(allocate_lock) if (not HAVE_PYLUCENE): THREADING = python class uthread: def initialize(cls): pass initialize=classmethod(initialize) def get_ident(): return repr(threading.currentThread()) get_ident = staticmethod(get_ident) def create_new_thread(name, fn, args): t = threading.Thread(None, fn, name, args) t.setDaemon(true) note(0, creating new thread %s, t) return t create_new_thread=staticmethod(create_new_thread) def start_new_thread(fn, args, name=None): t = threading.Thread(None, fn, name, args) t.setDaemon(true) note(0, starting new thread %s, t) t.start() return t start_new_thread = staticmethod(start_new_thread) def allocate_lock(): return threading.RLock() allocate_lock = staticmethod(allocate_lock) Leonardo Santagada santag...@gmail.com wrote: On Jun 2, 2009, at 1:18 PM, Bill Janssen wrote: Actually, I'm debugging Python code, but it's running in a multi-threaded Python server. So I need to attach with gdb to see what's going on. It would be nice if Thread Viewer had the ability to decode Python stack traces. Thanks for the info. I'll try building using the Apple sources. Is the server a multi-threaded python program, using thread or Threading? Then I think you could use rpdb2 or winpdb to debug it. -- Leonardo Santagada santagada at gmail.com ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
