MacPython Logo from __future__ import *

buy music albums Silver Apples buy mp3 albums Tarrus Riley buy tracks mp3 Kravits buy Reaper albums mp3 buy Kravits albums music buy music Evita CD online albums mp3 Silver Apples download Madonna CD music buy tracks music Kravits download music albums Silver Apples

2005-05-23

Talking Panda Update

Filed under: General, PyObjC, iPod, java, macosx, perl, pil, py2app, python — bob @ 11:37 pm

We've (finally) updated talkingpanda.com today with a fresh new look and a new product: iBar.

iBar turns your iPod (any iPod with a screen and a dock connector) into an "ultimate bartending tool" with over a thousand drink recipes, mixing techniques, and even a couple history lessons. Like any good bar should be, it's stocked. Altogether, the Notes content adds up to over 3 megabytes (yes, that's text!) with more than 40 minutes of original, professionally recorded, audio.

Like its sibling iLingo, iBar ships with installers for Mac OS X and Windows XP/2000 (everywhere iTunes is supported) that make installation painless.

And for relevance, here's a little bit about how it's all put together:

  • The Mac OS X installer was developed with Python 2.3, PyObjC 1.2, and bundled up with py2app.
  • The Win32 installer was developed with Python 2.4, win32all, Tkinter, PIL and is bundled up with py2exe and then made self-contained with NSIS.
  • The build scripts for the installer application actually use even more open source stuff. We use JExcelAPI to convert Excel spreadsheets to XML, and Win32::Exe to swap out the ICO resource out of win32 executables -- but no Java or Perl makes it into the redistributable :)

We're also blogging updates and podcasting some of our content, so point your NetNewsWire or Safari RSS over to Talking Panda News!

2005-05-19

ANN: PyObjC 1.3.6

Filed under: PyObjC, macosx, python — bob @ 12:40 pm

PyObjC 1.3.6 is now available for download at http://pyobjc.sourceforge.net/

This release fixes an issue with plugins.

Version 1.3.6 (2005-05-19)

  • Fixed bugs in the ProgressViewPalette example
  • Fixed a bug in the class builder that caused most plugins to break
  • Removed all references to Project Builder
  • Mac OS X 10.2 (Jaguar) no longer supported

2005-05-18

ANN: py2app 0.2

Filed under: PyObjC, py2app, python — bob @ 2:57 pm

py2app 0.2 is a minor bug fix release. You can download it from pythonmac.org packages. PyObjC 1.3.5 ships with py2app 0.2, so if you have that, you have already upgraded to py2app 0.2!

Functional changes:

  • New datamodels option to support CoreData. Compiles .xcdatamodel files and places them in the Resources dir (as .mom).
  • New use-pythonpath option. The py2app application bootstrap will no longer use entries from PYTHONPATH unless this option is used.
  • py2app now persists information about the build environment (python version, executable, build style, etc.) in the Info.plist and will clean the executable before rebuilding if anything at all has changed.
  • bdist_mpkg now builds packages with the full platform info, so that installing a package for one platform combination will not look like an upgrade to another platform combination.

Bug Fixes:

  • Fixed a bug in standalone building, where a rebuild could cause an unlaunchable executable.
  • Plugin bootstrap should compile/link correctly with gcc 4.
  • Plugin bootstrap no longer sets PYTHONHOME and will restore PYTHONPATH after initialization.
  • Plugin bootstrap swaps out thread state upon plug-in load if it is the first to initialize Python. This fixes threading issues.

What’s new in PyObjC 1.3.5?

Filed under: PyObjC, py2app, python — bob @ 2:54 pm
  • Importing objc now ensures that Foundation is multi-threaded, previously it only ensured that Python was.

  • New objc.RegisterCFSignature used to register CFTypeRef-like signatures with the runtime.

  • PyObjCTools.Conversion functions now support all property list types with the following conversions:

    • NSData <-> buffer
    • NSDecimalNumber <-> decimal.Decimal (if present)
    • NSDate <-> datetime.datetime

    New toPythonDecimal, fromPythonDecimal functions which convert between NSDecimalNumber and decimal.Decimal using an intermediate string.

    New serializePropertyList and deserializePropertyList functions which serialize (Objective-C) property lists to and from NSData.

  • OC_PythonObject, the proxy for Python objects that do not have an Objective-C superclass and are not otherwise special-cased, now act slightly more like typical Objective-C objects (supporting -isEqual:, -hash, and -compare:). This allows them to work with Key-Value Coding if they are contained by an Objective-C object, among other things.

  • New objc.signature decorator that allows easier specification of objc.selector wrappers for functions when using Python 2.4:

    @objc.signature('i@:if')
    def methodWithX_andY_(self, x, y):
        return 0
    
  • PyObjCTools.KeyValueCoding.getKeyPath now supports all of the Array Operators supported by Mac OS X 10.4.

  • Key-Value Coding of Python objects (whether or not using an Objective-C base class) should act like Objective-C now. In previous versions there were inconsistencies with the use of capitalization, the underscore postfix in setters, and Key-Value Observing.

  • The formal protocol list is now complete. A new internal function, objc.protocolsForProcess() enumerates over all mach headers and returns all of the protocols defined in the expected place. This fixes the scenario where an application uses a protocol but does not define any classes that conform to that protocol (i.e. to check plugin conformity). Previously it was not possible to reach these protocols simply by walking over all of the classes.

  • A special value, objc.NULL, may now be passed in the place of 'in' and 'inout' arguments. This tells the bridge to pass a NULL pointer to the Objective-C method, instead of a pointer to the value. The return value will still be a tuple of the expected size.

  • Some of the new Tiger frameworks now have wrappers:

    • AppleScriptKit
    • Automator
    • CoreData
    • DiscRecording
    • DiscRecordingUI
    • OSAKit
    • Quartz
    • QTKit
    • SyncServices
    • XgridFoundation

    Documentation and tests not yet written.

  • New OutlineEditor example in Examples/CoreData, it is a Python version of the identically named Apple example.

  • The last argument of selectors that end with ':error:' is now assumed to be 'out' if its type is an object pointer.

  • More conveniences for list-like and dict-like objects: __reversed__, reverse, pop, remove, fromkeys.

  • OC_PythonDictionary and OC_PythonArray now return NSNull to Objective-C callers as appropriate.

  • New WebKitInterpreter example in Examples/Plugins. Uses the new WebKit Cocoa plugin API available in Safari 1.3 and later to embed a PyInterpreter in the browser.

  • Fixed a CFBundleRef reference counting bug in Foundation._Foundation. The symptom of this is usually a crashing application after having loaded a PyObjC-based plugin into an otherwise Objective-C app.

  • New PyObjCTools.AppHelper functions: callAfter and callLater, conveniences for calling Python functions on the main thread as soon as possible, or after a delay.

  • Twisted examples changed to use threadedselectreactor instead of cfreactor. cfreactor is deprecated. Needs Twisted newer than 2.0 (svn r13575 or later).

  • objc.inject now injects on main thread by default, and takes an optional third useMainThread argument to change this behavior. This is a complete rewrite which should be correct, stable, Tiger compatible, and synchronized with mach_* 1.1.

  • Removed an NSAutoreleasePool category hack that has been deprecated for quite some time.

  • New objc.removeAutoreleasePool function that will remove PyObjC's global NSAutoreleasePool, which may be useful for plugins.

  • Fixed bug in the NSBundle hack that caused a NULL pointer dereference if looking up a non-existent class using NSBundle API.

  • Added OC_PythonUnicode and OC_PythonString classes that preserve the identity of str and unicode objects across the bridge. The bridge for str now uses the default encoding of NSString, rather than sys.getdefaultencoding() from Python. For Mac OS X, this is typically MacRoman. The reason for this is that not all Python str instances could cross the bridge at all previously. objc.setStrBridgeEnabled(False) will still trigger warnings, if you are attempting to track down an encoding bug. However, the symptoms of the bug will be incorrectly encoded text, not an exception.

  • New Xcode project template "PyObjC Mixed Application" that is a py2app based Python application that loads an Objective-C plug-in built as a separate target.

  • New py2app based Xcode templates "PyObjC Application" and "PyObjC Document-based Application", these replace the older "Cocoa-Python Application" and "Cocoa-Python Document-based Application" respectively.

  • New InjectBrowser example in Examples/Inject that demonstrates injection of the ClassBrowser example into another application using objc.inject.

  • NSData and NSMutableData instances now support the Python buffer protocol.

  • NSData instances now support a convenience API that allow them to act like a buffer instance for str() and slicing.

  • Objects that support the Python buffer protocol, such as buffer and array.array (but not str or unicode) are now bridged as NSData subclasses.

ANN: PyObjC 1.3.5

Filed under: PyObjC, macosx, python — bob @ 2:52 pm

PyObjC 1.3.5 is now available for download at http://pyobjc.sourceforge.net/

PyObjC is a bridge between Python and Objective-C. It allows full featured Cocoa applications to be written in pure Python. It is also easy to use other frameworks containing Objective-C class libraries from Python and to mix in Objective-C, C and C++ source.

Python is a highly dynamic programming language with a shallow learning curve. It combines remarkable power with very clear syntax.

The installer package includes a number of Xcode templates for easily creating new Cocoa-Python projects, as well as py2app, a suite of tools for building redistributable Python applications and plugins.

PyObjC also supports full introspection of Objective-C classes and direct invocation of Objective-C APIs from the interactive interpreter.

PyObjC requires Mac OS X 10.2 or later and Python 2.3 or later. PyObjC works with the Apple provided Python installation in Mac OS X 10.3 (and later), MacPython 2.3, and MacPython 2.4.

This release features several bugfixes, improved documentation, new Xcode templates, Tiger support and many major enhancements. See the news file at http://pyobjc.sourceforge.net/NEWS-1.3.5.txt for more information.

PyObjC is released with an open source license (MIT style).

2005-05-03

xattr - Darwin 8 Extended Filesystem Attributes from Python

Filed under: macosx, python — bob @ 9:03 pm

Darwin 8.0, the underpinnings of Mac OS X 10.4 (Tiger) ships with a new API at the filesystem layer: Extended Attributes. I haven't really seen much documentation thrown about, but effectively they can be used to associate arbitrary metadata with files (note that this is entirely separate from Spotlight Metadata Attributes). Extended attributes are the new way that the resource fork and finder information is looked up and stored. They're also used by the obscure copyfile that lives beneath all of the changes to cp, mv, tar, etc.

I whipped up a quick wrapper for the APIs today, xattr. This extension module exposes an xattr object that wraps paths or file descriptors (either as an int, or as an object with a fileno()), and it acts like a dict. Usage looks like this:

>>> import xattr
>>> x = xattr.xattr('tiger_8a428_userdvd.dmg')
>>> x
<xattr file='tiger_8a428_userdvd.dmg'>
>>> x.keys()
[u'com.apple.diskimages.recentcksum']
>>> dict(x)
{u'com.apple.diskimages.recentcksum': 'i:969254 ...more stuff'}
>>> x['com.apple.diskimages.recentcksum']
'i:969254 ...more stuff'
>>> x['com.apple.adc'] = 'select'
>>> dict(x)
{u'com.apple.adc': 'select',
 u'com.apple.diskimages.recentcksum': 'i:969254 ...more stuff'}
>>> del x['com.apple.adc']
>>> dict(x)
{u'com.apple.diskimages.recentcksum': 'i:969254 ...more stuff'}    

Note that keys are limited to 128 bytes and values appear to be limited to 3800 bytes. I think the resource fork is special cased to be longer, though.

You can download xattr 0.1 from http://pythonmac.org/packages/ for Tiger's Python 2.3.5 or Python 2.4.1 (installed on Tiger).

svn trunk:
http://svn.red-bean.com/bob/xattr/trunk/
0.1 source:
http://svn.red-bean.com/bob/xattr/releases/xattr-0.1/
UPDATE:
It looks like there is some relevant information and an xattr command line tool in the arstechnica tiger review.

Mac OS X 10.4 (Tiger)’s copyfile()

Filed under: c, macosx — bob @ 8:40 am

All of the snazzy ACL-and-metadata-copying features in Darwin 8 / Tiger live in one function, copyfile(). Unfortunately, Apple forgot to include the header for it in the version of Xcode that ships with Mac OS X 10.4.

It is defined in libSystem, so you can use it if you knew its prototype, and you can pick up the copyfile.h (may not be newest!) from the Libc package from Darwin releases.

Since this isn't a static library, and probably depends on New Stuff, using it in a backwards compatible way (i.e. to get resource-fork copying in Panther) probably isn't going to work. Oh well.

2005-05-01

Python on Mac OS X 10.4 (Tiger)

Filed under: macosx, python — bob @ 12:46 pm

Mac OS X 10.4 (Tiger) ships with Python 2.3.5.

  • Built as a framework (./configure --enable-framework) and installed to /System/Library/Frameworks/Python.framework.

  • Has "faked" unix-style organization by way of symlinks. This is new in Tiger, but I'm not sure why they bothered. It's not really very useful to do it this way because building against these things directly is probably going to fail anyway. Especially because Mac OS X typically requires different linker options than other GCC platforms. The correct way, of course, is to use distutils or at least read values from Python's Makefile, which also works on other platforms. Some people are stubborn and like to do things the wrong way, and this is only going to make them think it's acceptable to do it that way. It's not.

    • /usr/lib/libpython2.3.dylib -> Python.framework/Versions/2.3/Python
    • /usr/include/python2.3 -> Python.framework/Versions/2.3/include/python2.3
    • /usr/lib/python2.3 -> Python.framework/Versions/2.3/lib/python2.3
  • The site-packages folder is symlinked to /Library/Python/2.3/site-packages. This differs from Mac OS X 10.3 (Panther)'s Python 2.3.0, which was symlinked to /Library/Python/2.3. However, it is now consistent with ~/Library/Python/2.3/site-packages.

  • Ships with a proprietary closed-source CoreGraphics extension, which is a SWIG wrapper plus magic private API hackery on top of Apple's framework of the same name. Mac OS X 10.3 also shipped with this extension. I'm not sure whether there's any meaningful difference between the two, since it's not well documented and it's not open source.

  • Ships with a "unicode" build of wxPython 2.5.3. Mac OS X 10.3 did not ship with any wxPython or wxWidgets. I'm not sure whether this is good or bad, wxPython development moves pretty fast and the current Mac version isn't quite up to snuff yet.

  • Ships with TclTkAqua, so Python has a working Tkinter out of the box. Tkinter is also a little weird on Mac OS X, but development of this stuff moves slowly enough, so this was almost definitely a good idea.

  • Tiger pretends to have GNU libreadline, but it's really BSD libedit. Python isn't fooled, so it still ships without readline support.

The packages in pythonmac packages intended for Mac OS X 10.3's Python 2.3.0 are compatible with Tiger's Python 2.3.5, but you must install the TigerPython23Compat package before they will work. This package simply adds a .pth file that adds /Library/Python/2.3 as a site directory.

Using the Python 2.4.1 installer works almost exactly as you'd expect it to on Tiger, with two exceptions:

  • Extensions won't build properly out of the box until you install the TigerPython24Fix package from pythonmac packages, because Apple's headers are anal about POSIX (non-)compliance (rdar:4075943).

  • There's a regression such that at least one of Mac OS X 10.4's math functions gives incorrect results. This effects Python 2.4's float/long comparisons and conversions. This is a pretty serious bug, and I expect it to be fixed in 10.4.1, whenever that is. Python 2.4's test.test_long fails due to this bug.

    Specifically, the bug is caused because modf will return "fractional parts" of >= 1.0 for some input values (rdar:4069461). If you're doing anything important with floating point, I suggest waiting for 10.4.1 or at least verifying your results elsewhere. Off-by-one errors can get out of hand pretty quickly. A really quick test of this bug is:

    >>> 9007199254740991.0 == 9007199254740991L
    False    

    Obviously not the answer I was hoping for. modf is probably not very commonly used, but it definitely throws up warning flags that they'd cause a regression like this and not have a test suite that reproduces it. As far as I know, I was the first/only person to report this bug. It was reported on March 28th, which I guess was just too late to incorporate a fix.

Powered by WordPress