On 17 Jun, 2007, at 17:57, Kevin Walzer wrote:

Ronald Oussoren wrote:
On 14 Jun, 2007, at 22:42, Ronald Oussoren wrote:

On Jun 14, 2007, at 1:21 PM, Nicholas Riley wrote:

On Thu, Jun 14, 2007 at 01:16:08PM -0700, Christopher Barker wrote:
However, if was nice to have some stuff without any external
dependencies -- is there a lightweight way to do just Easy Dialogs,
without all of PyObjC?

It shouldn't be hard to simply wrap a Cocoa EasyDialogs implementation in C to construct a traditional Python module, but it make ssense to wait and see how much of Carbon is no longer going to be supported in 64-bit on Leopard (probably the WWDC attendees find out today but it's
NDA'd).  Cocoa doesn't have a generic API that matches that of
EasyDialogs as much as Carbon does.

The WWDC attendees (me included) already know but as you say that info
is under NDA ;-).
But luckily the situation is explained on a mailinglist:
http://lists.apple.com/archives/Carbon-dev/2007/Jun/msg00260.html
The summary: no 64-bit Carbon GUI libraries. I haven't even tried to compile Python's Carbon wrapper in 64-bit mode, I'd be surprised if they compiled cleanly because Apple has done some serious spring-cleaning in 64-bit mode.
Ronald

A couple of questions:

1. Will applications that are 32 bit have any problems running under Leopard?

Apple has a rather good track record with respect to backward compatibility, so I expect that all 32-bit programs that work properly on Tiger will do the same on Leopard (except for problems that are caused by using private interfaces).

As was mentioned in the keynote, Leopard will by 4-way universal throughout except for some exceptions. This means that 32-bit builds for applications will run on all Leopard machines, there are no seperate Leopard builds for 32-bit and 64-bit machines. This in turn means you don't have to provide a 64-bit build unless you want to, which would most likely be because you can make use of the additional resources that a 64-bit build brings (both a larger addressspace and on Intel more registers).

2. Would Python have to be specifically compiled as 64-bit to support PyObjC, or would 32-bit Python be OK?

Porting PyObjC to 64-bit is a work in progress, but one that I expect to finish soon. The biggest problem is 64-bit support in libffi, but luckily I can build on someone else's work there.

32-bit support in PyObjC is already there and won't disappear. Likewise for support for Tiger systems.

Speaking of PyObjC: I'm working on a new major release of PyObjC. The code is not yet available in the public repository because I'm targetting Leopard (with a backward compatibility layer for Tiger and Panther) and didn't want to have to think too much about which parts of the code are covered by the Leopard NDA. I'll starting writing more about this in the near future, but let me say I'm really excited about the enhancements in the 2.0 tree.

Ronald


--Kevin


--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Reply via email to