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

I've updated my Mac OS X port of Frozen Bubble. I updated all of the dependencies to the latest I could find (SDL_perl 1.20.3a, SDL 1.2.8 with my AltiVec patches, etc.), and now it embeds a DarwinPorts-built Perl rather than links to the /System Perl. I rewrote the port such that the Mac OS X specific changes were isolated, so the same source should run on other platforms.

The interesting part is the new build system. I'm leveraging a Makefile to do (most) everything, rather than using an Xcode project and a series of manual steps (that I don't even remember). The biggest change to the build process is that it now embeds rather than links to Perl, so it needs to create a "standalone" Perl environment. I wrote a script, scan_and_copy.pl, that throws the main script of Frozen-Bubble over Module::ScanDeps to get the list of files that it requires. It simply copies these into the Resources folder of the application bundle, along with everything else. The bootstrap code now removes everything from @INC except for '.', so it does the right thing if the dependencies are in that location. Normally, this wouldn't be enough, because there is no explicit step for bringing in all of the libraries that this depends on. However, I simply leverage macho_standalone, which copies in all dependent libraries and strips the files.

I should submit the Makefile to CPAN and call it perl2app. It wouldn't be much worse than most of the other garbage I've found in there ;)

Now I just need to figure out how to suppress that nasty feeling you get when you touch Perl again after mostly avoiding it for several years...

#macpython quote of the day:

endo: so whats python like i do have knowlege of some programming languages just wonderin what its used for, is it software?

This is painfully old news, but it seems that Tels had forked SDL_perl and released SDL_perl 1.20.3. This distribution is a hybrid of SDL_perl 2.0b2, with a mostly compatible SDL_perl 1.19 interface. Thomas Tongue forked this as SDL_perl 1.20.3a which integrates some of the Mac OS X build patches I had made when I ported Frozen Bubble.

I say mostly compatible, because it almost works unchanged with Frozen Bubble (as far as I can tell). It seems that SDL_perl 1.19 stored SDL::Surface objects as a hash reference, where they are scalar references in SDL_perl 1.20.3a. So, I had to change several lines of code that looked like this:

$surface_reference->{-surface}

To this:

${$surface_reference}

I started screwing around with enhancing Ryan Gordon's AltiVec patch for SDL last weekend. I ended up spending more time on it than I should've, but I think I've optimized all of the 32bit-32bit blits. Even though my AltiVec is probably pretty naive, I'm seeing a ~3-4x speed increase over the scalar code. And the scalar code is probably about as optimized as it's going to get, with duffs, etc.

Another thing I noticed is that my G5 really, really, really beats the snot out of my G4 powerbook for this stuff. For some of the blits, the 2ghz G5 runs about 5.65x faster than the 1ghz G4. That's nearly three times as much work per cycle! This is probably due to the bus speed and memory bandwidth more than anything else, but it's impressive nonetheless.

Now I really want a G5 powerbook. Even if it were clocked at 1ghz like my current G4, it seems like there would still be a large difference in performance.

Once I clean up the patch and do some more testing (read: hopefully this weekend), I'll do a release of pygame that will include this enhanced version of SDL. pygame is overdue for an update, anyway.

PyObjC now (in svn) has a new protocol that makes it significantly easier to handle the special cases of Python -> Objective-C bridging:

• The Python to Objective-C bridge now looks for a __pyobjc_object__ attribute to get a PyObjC object from a Python object.

Although the news item is short, it has far-reaching implications. I'm pretty certain that I've been able to remove hundreds of lines of code in just NSNumber support with this generalization:

• NSNumber instances are bridged to a float, long, or int subclass that uses __pyobjc_object__. NSDecimalNumber is bridged to Foundation.NSDecimal, which now supports __pyobjc_object__. This eliminates a HUGE amount of cruft in objc._conveniences.

Speaking of protocols, I also added support so that the formal ones work!

• PyObjC classes can now declare that they implement formal protocols, for example:

import objc
from Foundation import *
class MyLockingClass(NSObject, objc.protocolNamed('NSLocking')):
    # implementation
    pass

There's still a lot of room for improvement in the Protocol support:

• Protocols are not type checked. Anything in the base list that is a PyObjCObject will get chunked into the protocol list. Will probably crash if you do something really stupid (though there's plenty of that in PyObjC anyway)
• Protocols can not be created from PyObjC
• selectors don't benefit from the Protocol information like they do for informal protocols
• PyObjC doesn't verify that you implement the protocol like it does for informal protocols
• objc.protocolNamed is probably pretty slow, should use a lookup hash

There's also a nice new convenience in PyObjCTools.KeyValueCoding:

• PyObjCTools.KeyValueCoding has a new kvc class that allows Pythonic Key-Value Coding.

  • __getitem__ is mapped to valueForKeyPath:
  • __setitem__ is mapped to setValue:forKeyPath:
  • __getattr__ is mapped to valueForKey:
  • __setattr__ is mapped to setValue:forKey:

  The kvc class uses __pyobjc_object__, so it may cross the bridge as the wrapped object.

I started on some py2app documentation (rst) for the next release. Take a look, suggestions and contributions are appreciated!

Note that the documentation corresponds to the current state of svn trunk, links that point to versions of py2app not yet released will not work, etc.

I started consolidating links to the packages I've built with bdist_mpkg:

http://pythonmac.org/packages/

If anyone needs such an installer hosted, just let me know and I'll add it to the list. Please build packages with py2app 0.1.8 (svn trunk)'s --zipdist option.

Lots of new PyObjC examples made their way to svn this week:

• New IDNSnitch example in Inject that demonstrates how to monitor for the launch of another application, use objc.inject to load code into a target process, and override the implementation of an existing method but still call back into the original implementation (method swizzling).
• objc.IMP should do the right thing now. This type is returned by +[NSObject methodForSelector:] and +[NSObject instanceMethodForSelector:]
• New ToDos example in CocoaBindings that demonstrates how to use two array controllers for the same data, and how to use value transformers to alter the color of text. Originally from "Cocoa Bindings Examples and Hints", converted to PyObjC by u.fiedler.
• New Bookmarks example in CocoaBindings that demonstrates how to subclass NSArrayController to implement the NSTableView delegate drag and drop protocol, including copying of objects between documents and accepting URL drops from other applications. Also demonstrates re-ordering of the content array. Originally from "Cocoa Bindings Examples and Hints", converted to PyObjC by u.fiedler.
• New FilteringController example in CocoaBindings that demonstrates how to subclass NSArrayController to implement filtering of a NSTableView. Also demonstrates the use of indexed accessors. Originally from "Cocoa Bindings Examples and Hints", converted to PyObjC by u.fiedler.
• New ControlledPreferences example in CocoaBindings that demonstrates how to use Cocoa Bindings to simplify storing and retrieving user preferences. Originally from "Cocoa Bindings Examples and Hints", converted to PyObjC by u.fiedler.

py2app 0.1.8 will ship with a new script: macho_standalone (in svn already)

This script takes an application bundle as a parameter, and it does the following:

• Scans every file in the application bundle for Mach-O files
• Builds a dependency graph of every Mach-O file, copying in Mach-O files that are not part of the bundle already and not in a system location (/System or /usr except for /usr/local). Frameworks are a special case, they are copied in wholesale and then also scanned for additional Mach-O files (plugins, etc.).
• Normalizes the Mach-O headers to point to the right place. Normally this means they will point to @executable_path/../Frameworks style paths.
• Strips everything

The functionality in this script is used internally by py2app, with some additional special cases for frameworks. However, this script could be used for applications not written in Python.. perhaps as an alternative to the "copy files build phase" for frameworks in Xcode, or as part of the build process for other py2app-like environments (RubyCocoa, CamelBones, etc.)

Of lesser interest is the new macho_find script. Like the find tool, it walks files/directories and prints each on its own line to stdout. macho_find simply matches files that have the Mach-O signature, and could be used as input to a tool such as strip.

I've put together a quick bdist_mpkg build of PIL 1.1.5b3:

• Imaging-1.1.5b3-py2.3-macosx10.3.zip for Mac OS X 10.3 (Pre-installed Python 2.3.0)

UPDATE: This is out of date. There is a newer version and other installers available at pythonmac packages.

It's statically linked against:

• jpeg 6b (from darwinports)
• tiff 3.7.1 (from darwinports)
• freetype 2.1.9 revision 1 (from darwinports)

_imagingtk is dynamically linked with the Tcl and Tk 8.4 frameworks installed to /Library.

UPDATE:

Apple has properly resolved this issue with Safari, see About Safari International Domain Name Support.

Soon after I got home from ShmooCon, I saw that the Shmoo Group came up with a new domain spoofing exploit for which "no defense exists". It's pretty amazing that browsers actually implement IDN without any kind of protection, so I decided to quickly hack up a defense for Safari on Mac OS X 10.3 (and probably later).

Application:

IDNSnitch.app.tgz (335k) USE AT YOUR OWN RISK. This probably will cause instability in Safari.

Source:

http://svn.red-bean.com/pyobjc/trunk/pyobjc/Examples/Inject/IDNSnitch

The hack is implemented in two parts, an application and a plugin.

Application

IDNSnitch.py is a simple application that scans NSWorkspace for Safari instances, and registers for application launch notifications for new Safari instances. When it sees an instance of Safari, it uses objc.inject to load the plugin into the target pid.

Plugin

IDNSnitchPlugin.py is where all the magic happens. It swizzles NSURLRequest's designated initializer by creating a category after caching the original IMP. This swizzled initializer calls into another method that checks the NSURL and has an opportunity to return a different one. The implemented checker that looks for the ACE (ASCII compatible encoding) prefix in the host of the given NSURL. If it sees an ACE prefix, it presents an alert panel to the user showing them the raw IDN URL, the "display" host name, and the unicode escaped host name. The user can then decide whether to allow or deny requests from this host, and this decision is cached for the rest of their Safari session, but not persisted. If they choose Deny, it simply returns about:blank rather than the original URL.

Discovery

In order to discover how to implement this hack, I attached gdb to Safari, like so:

% ps -auxwww|grep Safari
bob    21062   0.0  3.9   254720  40976  ??  S     5:23PM   0:57.19 /Applications/Safari.app/Contents/MacOS/Safari -psn_0_193331201
bob    21103   0.0  0.0    17052      8 std  R+    5:40PM   0:00.00 grep Safari
[meth:~] bob% gdb attach 21062

I then thought that I could easily pick out when Safari used URLs by putting a break point on NSURL's designated initializer:

(gdb) fb -[NSURL initWithString:relativeToURL:]
Breakpoint 1 at 0x90a2d51c
(gdb) c

After going to a few URLs, I noticed that it would often have the URL cached somehow. So then I looked at a NSURL backtrace and saw that NSURLRequest was probably used more often, so I put a break point on its designated initializer:

^C
Program received signal SIGINT, Interrupt.
0x900074c8 in mach_msg_trap ()
(gdb) fb -[NSURLRequest initWithURL:cachePolicy:timeoutInterval:]
Breakpoint 2 at 0x90a0b0b8
(gdb) c

NSURLRequest is indeed used all the time, so I took a look at what a spoofed URL looks like:

Breakpoint 2, 0x90a0b0b8 in -[NSURLRequest initWithURL:cachePolicy:timeoutInterval:] ()
(gdb) po $r5
https://www.xn--pypal-4ve.com/

At this point I had everything I needed to know, so I wrote the code.

UPDATE:

• Rewritten in pure Python (requires svn trunk of PyObjC), hopefully fixed threading bugs.
• Fixed some more bugs and made it smaller
• An alternate implementation of this is available in Saft v7.5.1 and later (have not tried it myself)
• One of the authors of the IDN standard writes about a more balanced solution to this issue. I had actually considered doing it this way, but I simply didn't have the time or interest in creating the custom dialogs required. This functionality should be in unicodedata, but it's not, though Blocks.txt would be trivial to parse.
• An up and coming Mozilla extension, TrustBar, attempts to solve this and other issues for Mozilla and FireFox