From ronaldoussoren at mac.com Mon Jul 21 14:39:06 2014 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 21 Jul 2014 14:39:06 +0200 Subject: [Pythonmac-SIG] Building compatible dependencies In-Reply-To: References: Message-ID: On 11 Jun 2014, at 17:58, Chris Barker wrote: > Hi folks, > > I know it'a at least theoretically possible to build libs under 10.9 that will work on 10.6 -- specifically compatible with the python.org python binaries. > > But I"m having trouble finding documentation of what flags you need. > > MACOSX_DEPLOYMENT_TARGET=10.6 > > should be required -- but anything else? > > personally, I've solved this by building on the oldest machine I want to support, but that's not always possible anymore. > > Anyone have an example? Setting MACOSX_DEPLOYMENT_TARGET should be enough, but you may need to do more work depending on the code that you try to build. In particular, code using configure scripts might find APIs or libraries that are available on 10.9 and not on 10.6. Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Mon Jul 21 14:43:03 2014 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 21 Jul 2014 14:43:03 +0200 Subject: [Pythonmac-SIG] py2app & pillow In-Reply-To: <4C5CE95D-8943-4438-8428-1DC8043D2F13@googlemail.com> References: <4C5CE95D-8943-4438-8428-1DC8043D2F13@googlemail.com> Message-ID: <9986EFF7-93F2-4B48-8494-59E67FD04285@mac.com> On 13 Jun 2014, at 21:45, Karsten Wolf wrote: > Hi, > > in an py2app app I replaced the thumbnail mechanism from sips (via os.system) to Pillow. The resulting app size went from 11MB to 50 MB for the inclusion of the complete TCL/TK stuff. > > Is there an easy way to reduce that? > > Both, Python 2.7.6 and Pillow are compiled for intel 32bit on OSX10.6 The quickest way is to explicitly exclude Tkinter using a py2app option. You can also create a Pillow recipe based on the PIL one (in py2app.recipes.PIL), or update the PIL one when Pillow is imported the same way as PIL. Ronald > > > -karsten > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG From rowen at uw.edu Mon Jul 21 22:35:30 2014 From: rowen at uw.edu (Russell E. Owen) Date: Mon, 21 Jul 2014 13:35:30 -0700 Subject: [Pythonmac-SIG] Building compatible dependencies References:

Message-ID: In article , Ronald Oussoren wrote: > On 11 Jun 2014, at 17:58, Chris Barker wrote: > > > Hi folks, > > > > I know it'a at least theoretically possible to build libs under 10.9 that > > will work on 10.6 -- specifically compatible with the python.org python > > binaries. > > > > But I"m having trouble finding documentation of what flags you need. > > > > MACOSX_DEPLOYMENT_TARGET=10.6 > > > > should be required -- but anything else? > > > > personally, I've solved this by building on the oldest machine I want to > > support, but that's not always possible anymore. > > > > Anyone have an example? > > Setting MACOSX_DEPLOYMENT_TARGET should be enough, but you may need to do > more work depending on the code that you try to build. In particular, code > using configure scripts might find APIs or libraries that are available on > 10.9 and not on 10.6. Also, X11 moved at one point. If you build on too new a machine then any attempt to use X11 will work on older operating systems. - Russell From ronaldoussoren at mac.com Sun Jul 27 11:00:05 2014 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 27 Jul 2014 11:00:05 +0200 Subject: [Pythonmac-SIG] PyObjC 3.0.1 on PyPI Message-ID: <8EEE996A-133A-4DE0-BCC8-E36A9D85831E@mac.com> Hi, I?ve just pushed PyObjC 3.0.1 to PyPI. This is a major update to the previously uploaded release and contains a rewrite of the core bridge itself. All tests pass without problems, but there could still be problems. With this update the bridge is a lot lazier about when to add methods to the class proxy __dict__: methods are now only added when they are actually used. This should result in slightly better performance, and more importantly removes some very ugly code that tried very hard to keep the __dict__ up to date without there being support for detecting changes to a class in the Objective-C runtime. Because of this it is more important that ever to have ?from objc import super? at the top of modules that use super calls in subclasses of Cocoa classes. In previous releases this was already necessary to avoid a race condition, but with this release you will definitely run into problems when using builtin.super. I am working on a PEP that adds a new API to Python that would remove the need of a custom super class, but that will at best be present in Python 3.5 (and that?s assuming the PEP is accepted). The metadata and framework wrappers have not yet been updated with support of OSX 10.9, let alone support of 10.10. That means that those wrappers work fine on OSX 10.9, but any special support for API?s introduced in OSX 10.9 is not present yet. Adding such support is on my todo list, but is a significant amount of work and sadly enough requires updating some tooling I used previously (which means yet more work). Getting out this release took way to much time, I started work on this during a Dropbox hack week in Januari 2013 (!). It?s highly unlikely that this rewrite and cleanup would have happend without the uninterrupted week of hacking during that event, it what just not something I could have managed in the couple of (fragmented) hours a week I can spent on PyObjC at the moment. Ronald P.S. I?ve also done some more optimisation work with PyObjC 3.0 which has sped up method calls by removing malloc calls in a number of cases. That seems to have been more effective for speed enhancements than the core rewrite itself ;-) From ronaldoussoren at mac.com Sun Jul 27 11:05:08 2014 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 27 Jul 2014 11:05:08 +0200 Subject: [Pythonmac-SIG] py2app 0.9 on PyPI Message-ID: <9FD2A8B5-82DC-4D41-B475-7A1770A18149@mac.com> Hi, Now that I?m writing announcements anyway? I?ve also uploaded a new release of py2app. This release uses a new version of modulegraph that records more information about the links in the graph. This makes it possible to provide more interesting information on modules that py2app couldn?t find while building the app bundle: py2app now shows if a missing module was imported conditionally or not, and if it was imported as ?from Y import mod? or ?import mod? (the latter is more likely to be a real problem). This required some restructuring of the modulegraph code base, while the modulegraph unit tests are still not good enough. I think I?ve found and fixed all problems introduced by the refactoring, but I?m not 100% about that. There will be further refactoring, and test updates, in upcoming releases of both modulegraph and py2app. Ronald From ronaldoussoren at mac.com Sun Jul 27 16:50:10 2014 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 27 Jul 2014 16:50:10 +0200 Subject: [Pythonmac-SIG] [Pyobjc-dev] PyObjC 3.0.1 on PyPI In-Reply-To: References: <8EEE996A-133A-4DE0-BCC8-E36A9D85831E@mac.com> Message-ID: On 27 Jul 2014, at 15:49, Marc Van Olmen wrote: > hi Ronald, > > Thanks for you work and keep this project alive! > We shipped in July Checkout 4.0 with the pyobjc 3.0 of 2014-05-30. + Python 2.7.6 > > Q: > Any speeds ups mentioned here happened after that? Nope. Almost all that work happened early in 2013. > > Remarks: > So far the release seems stable the only issue we had was that since the latest upgrade to pyobjc 3.0 of 2014-05-30. + Python 2.7.6 > The startup time of our app was about 10 seconds longer. I haven't had the time yet to investigate what caused it but profiler indicated it was in gzip. > So I changed our packaging and distribute site-packages as unzipped and notice at 10 seconds startup speed up. > Hopefully in the coming months I have sometime to investigate what caused it. The metadata system may be at fault here, although it is supposed to be faster than before. Do you use ?from Foundation import *?? It is highly advisable to avoid that because the framework wrapper modules lazily instantiate their contents and star-imports forces greedy initialisation. At least 3.0 should avoid the additional slowdown that was in 2.5 in the code that handles __all__. BTW. According to one of the talks at EP14 translating your source code using Cython could help in startup time. They started looking into Cython to get obfuscated code (to make it harder to reverse engineer their application) and noticed some performance improvements as well. That?s with plain Python code and no Cython-specific annotations. It would be cool to teach py2app to do this automatically and I have filed a feature request for that. I don?t know when I?ll get around to that though. The talk: https://ep2014.europython.eu/en/schedule/sessions/31/ (video and slides are available). Ronald > > best > > marc > > > > On Jul 27, 2014, at 5:00 AM, Ronald Oussoren wrote: > >> Hi, >> >> I?ve just pushed PyObjC 3.0.1 to PyPI. This is a major update to the previously uploaded release and contains a rewrite of the core bridge itself. All tests pass without problems, but there could still be problems. >> >> With this update the bridge is a lot lazier about when to add methods to the class proxy __dict__: methods are now only added when they are actually used. This should result in slightly better performance, and more importantly removes some very ugly code that tried very hard to keep the __dict__ up to date without there being support for detecting changes to a class in the Objective-C runtime. >> >> Because of this it is more important that ever to have ?from objc import super? at the top of modules that use super calls in subclasses of Cocoa classes. In previous releases this was already necessary to avoid a race condition, but with this release you will definitely run into problems when using builtin.super. I am working on a PEP that adds a new API to Python that would remove the need of a custom super class, but that will at best be present in Python 3.5 (and that?s assuming the PEP is accepted). >> >> The metadata and framework wrappers have not yet been updated with support of OSX 10.9, let alone support of 10.10. That means that those wrappers work fine on OSX 10.9, but any special support for API?s introduced in OSX 10.9 is not present yet. Adding such support is on my todo list, but is a significant amount of work and sadly enough requires updating some tooling I used previously (which means yet more work). >> >> Getting out this release took way to much time, I started work on this during a Dropbox hack week in Januari 2013 (!). It?s highly unlikely that this rewrite and cleanup would have happend without the uninterrupted week of hacking during that event, it what just not something I could have managed in the couple of (fragmented) hours a week I can spent on PyObjC at the moment. >> >> Ronald >> >> P.S. I?ve also done some more optimisation work with PyObjC 3.0 which has sped up method calls by removing malloc calls in a number of cases. That seems to have been more effective for speed enhancements than the core rewrite itself ;-) >> ------------------------------------------------------------------------------ >> Want fast and easy access to all the code in your enterprise? Index and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight - the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> _______________________________________________ >> Pyobjc-dev mailing list >> Pyobjc-dev at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >