pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] [pygtk] ANN: PyGUI 2.1

[Greg E. <gre...@ca...>]

Luis A. Bastiao Silva wrote:

> But it just works for application wroted from stratch, otherwise 
> application wroted in pygtk need to be ported to work cross-platform.

It's already possible to run pygtk programs on all three
platforms, if you're willing to install the required
libraries. API compatibility with pygtk (or any other
gui library) is not one of PyGUI's goals.

> What are you wrapping in Win32? Windows API directly?

Currently it uses the MFC layer of pywin32. I hope
eventually to replace that with raw win32 via ctypes.

> Anyway seems a good project, although it will be better have a pygtk 
> cross platform :)

That's a matter of opinion. One of the major goals of
PyGUI is to provide an API that doesn't suck. The
pygtk API doesn't meet that requirement, IMO.

-- 
Greg

Re: [Pyobjc-dev] [pygtk] ANN: PyGUI 2.1

[Luis A. B. S. <lui...@gm...>]

Hi,

On Fri, Nov 13, 2009 at 10:53 PM, Greg Ewing <gre...@ca...>wrote:

> PyGUI 2.1 is available:
>
>   http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
>
> Highlights of this version:
>
> * Win32:
>        Fixed bug preventing PyGUI apps from working under pythonw
>        Fixed incorrect mouse coordinates in ScrollableView
>        Added more standard cursors
>
> * MacOSX:
>        Application menu now has working Hide, Hide Others and Show All
>        commands.
>
> Plus a few other bug fixes and improvements.
>
>
> What is PyGUI?
> --------------
>
> PyGUI is a cross-platform GUI toolkit designed to be lightweight
> and have a highly Pythonic API.
>

It seems a awesome project, wrapping others graphical interfaces.

But it just works for application wroted from stratch, otherwise application
wroted in pygtk need to be ported to work cross-platform.

What are you wrapping in Win32? Windows API directly?



>
> --
> Gregory Ewing
> gre...@ca...
> http://www.cosc.canterbury.ac.nz/greg.ewing/
> _______________________________________________
> pygtk mailing list   py...@da...
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/
>


Anyway seems a good project, although it will be better have a pygtk cross
platform :)

Best Regards,
-- 
Luís A. Bastião Silva

Re: [Pyobjc-dev] Objective-P?

[Greg E. <gre...@ca...>]

Ronald Oussoren wrote:

>    $[myObject setValue:42]

Another possibility:

   myObject{setValue: 42}

-- 
Greg

[Pyobjc-dev] ANN: PyGUI 2.1

[Greg E. <gre...@ca...>]

PyGUI 2.1 is available:

   http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

Highlights of this version:

* Win32:
	Fixed bug preventing PyGUI apps from working under pythonw
	Fixed incorrect mouse coordinates in ScrollableView
	Added more standard cursors

* MacOSX:
	Application menu now has working Hide, Hide Others and Show All
	commands.

Plus a few other bug fixes and improvements.


What is PyGUI?
--------------

PyGUI is a cross-platform GUI toolkit designed to be lightweight
and have a highly Pythonic API.

-- 
Gregory Ewing
gre...@ca...
http://www.cosc.canterbury.ac.nz/greg.ewing/

Re: [Pyobjc-dev] objc.BadPrototypeError

[Ronald O. <ron...@ma...>]

(mobilme webmail seems to mess up quoting, hence my toppost).

The callback method should be named 'openPanelDidEnd:returnCode:contextInfo:', (that is "openPanelDidEnd_returnCode_contextInfo_". The name your using contains 4 underscores, and should therefore have 5 arguments (including 'self'), while the sheet expects a method with 3 arguments.

Ronald

On Friday, November 13, 2009, at 07:14AM, "Rob" <rob...@gm...> wrote:
>------------------------------------------------------------------------------
>Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
>trial. Simplify your report design, integration and deployment - and focus on 
>what you do best, core application coding. Discover what's new with
>Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>_______________________________________________
>Pyobjc-dev mailing list
>Pyo...@li...
>https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

[Pyobjc-dev] objc.BadPrototypeError

[Rob <rob...@gm...>]

(Please tell me if this is the wrong list for this kind of thing)

I am trying to port an application written against the stock python+pyobjc
on Leopard to one on snow leopard, and I've hit and error I can't solve.  I
have a sheet that pops in that allows one to select files, and it does this:

self.panel.beginSheetForDirectory_file_types_modalForWindow_modalDelegate_didEndSelector_contextInfo_(
            os.getcwd(),
            None,
            self.filetypes,
            NSApp().mainWindow(),
            self,
            'openPanelDidEnd:panel:returnCode:contextInfo:',
            0)

the key being the 'openPanelDidEnd:panel:returnCode:contextInfo:' part.

The signature of that method seems to have changed between Leopard and Snow
Leopard, but the decorator in pyobjc doesn't appear updated.  I am guess
this is what is going on because my method defined as:

@PyObjCTools.AppHelper.endSheetMethod
def openPanelDidEnd_panel_returnCode_contextInfo_(self, panel, returnCode,
contextInfo):

(which works fine in Leopard) throws the error:

objc.BadPrototypeError: Python signature doesn't match implied Objective-C
signature for <unbound selector
openPanelDidEnd:panel:returnCode:contextInfo: of desktop_uploaderAppDelegate
at 0x2fb6d70>

I've tried to figure out how to write the signature myself, but I seem to
suck badly at doing so. Nothing I have tried has worked.  I've tried (some
were just googled, some I tired to write myself by looking at the apple
docs):

@objc.signature('v@:^@i^v')
@objc.signature('v16@4:8@12i16i20')
@objc.signature('v@:@i^v')

amongst others, but everything I try just throws
that objc.BadPrototypeError: and crashes the program.

Seems like it should be an easy fix if I could sort out the signature - can
anyone help or point me in the right direction?

cheers,
rob

-- 
http://robrohan.com
http://twitter.com/robrohan

Re: [Pyobjc-dev] Objective-P?

[Leonardo S. <san...@gm...>]

On Nov 12, 2009, at 1:05 PM, Ronald Oussoren wrote:
> 
> Yikes, that is ugly. Anders' custom importer is the right way to do this, that's one reason why custom importer hooks are possible in the first place.
> 


I didn't see how it worked. Yes it is much better than hacking encoding. But then, you don't actually have to change cpython ever, this appears to be good enough way of loading opy files.

--
Leonardo Santagada
santagada at gmail.com

Re: [Pyobjc-dev] Objective-P?

[Bill B. <bb...@ma...>]

Oh, good.   I see it is time for another Great Method Calling Syntax Thread again.  (This has come up every 6 to 24 months since PyObjC began in 1994).

This one, though, is a bit different than the last 10 in that it started with a prototype!  (Anders-- thank you!).

This was a particularly signal laden thread about this in 2002:

http://mail.python.org/pipermail/pythonmac-sig/2002-October/006458.html

(For the record, I'm bringing up history because I would encourage folks to not repeat it.  That this one started with a prototype is a sign of hope.  For the record, I don't think anyone particularly *likes* the PyObjC syntax for invoking Objective-C methods, just that nothing has been suggested yet that preserves clarity while being equally as unambiguous)

b.bum

Re: [Pyobjc-dev] Objective-P?

[Ronald O. <ron...@ma...>]

On 12 Nov, 2009, at 15:56, Leonardo Santagada wrote:

> 
> On Nov 12, 2009, at 8:52 AM, Anders Hovmöller wrote:
> 
>> 
>> On Thu, Nov 12, 2009 at 10:59 AM, Ronald Oussoren <ron...@ma...> wrote:
>> 
>> On 12 Nov, 2009, at 0:01, Anders Hovmöller wrote:
>> 
>>> [ .... ]
>>> 
>>> Find attached the source for the custom importer.
>> 
>> While this is a nice trick I'd be much more interested in a syntax-change that at least has a chance of getting accepted into the Python core.   Your syntax for calling a method is ambiguous, at least for the parser using in CPython and possibly in general:
>> 
>>     10 <foo + bar> baz
>> 
>> Python's parser needs to know if the '<' token is the start of a method call or a comparison operator (and so do humans, it's far from clear what's going on here when I look at the code).
>> 
>> Yea, I know. I just chose <> instead of [] to finish my quick and dirty prototype in the two hours I had alloted :P As for trying to get something that can be accepted into Python proper, I think that's a dead end. Python already has a syntax for named parameters. I think this calls for a domain specific extension, not something you'd necessarily want to push up to CPython.
>>  
>>  
>> I've been thinking about syntax enhancements during the summer, the best I could think of was the introduction of a new operator:
>> 
>>     class MyObject (NSObject):
>>          def $[setValue: value]:
>> 		pass
>> 
>>    $[myObject setValue:42]
>> 
>> In this code '$[' would be a new operator, which should be unambigous w.r.t. existing code. Better yet, one could use a simular trick for anonymous functions:
>> 
>> Hmm, yea that's probably a nicer way of doing it. Changing from < and > to $[ and ] should be a rather trivial change in the hack I wrote.
>> 
> 
> I always thought of doing this as a different encoding, so you can put your translation on Lib/encodings/ and just do a # _*_ encoding: objective-c on the source files. I know, it is kinda crazy. 

Yikes, that is ugly. Anders' custom importer is the right way to do this, that's one reason why custom importer hooks are possible in the first place.

Ronald

> 
> Look at pybraces for how to do it:
> http://timhatch.com/projects/pybraces/
> 
> --
> Leonardo Santagada
> santagada at gmail.com
> 
> 
> 

Re: [Pyobjc-dev] Objective-P?

[Leonardo S. <san...@gm...>]

On Nov 12, 2009, at 8:52 AM, Anders Hovmöller wrote:

> 
> On Thu, Nov 12, 2009 at 10:59 AM, Ronald Oussoren <ron...@ma...> wrote:
> 
> On 12 Nov, 2009, at 0:01, Anders Hovmöller wrote:
> 
>> [ .... ]
>> 
>> Find attached the source for the custom importer.
> 
> While this is a nice trick I'd be much more interested in a syntax-change that at least has a chance of getting accepted into the Python core.   Your syntax for calling a method is ambiguous, at least for the parser using in CPython and possibly in general:
> 
>     10 <foo + bar> baz
> 
> Python's parser needs to know if the '<' token is the start of a method call or a comparison operator (and so do humans, it's far from clear what's going on here when I look at the code).
> 
> Yea, I know. I just chose <> instead of [] to finish my quick and dirty prototype in the two hours I had alloted :P As for trying to get something that can be accepted into Python proper, I think that's a dead end. Python already has a syntax for named parameters. I think this calls for a domain specific extension, not something you'd necessarily want to push up to CPython.
>  
>  
> I've been thinking about syntax enhancements during the summer, the best I could think of was the introduction of a new operator:
> 
>     class MyObject (NSObject):
>          def $[setValue: value]:
> 		pass
> 
>    $[myObject setValue:42]
> 
> In this code '$[' would be a new operator, which should be unambigous w.r.t. existing code. Better yet, one could use a simular trick for anonymous functions:
> 
> Hmm, yea that's probably a nicer way of doing it. Changing from < and > to $[ and ] should be a rather trivial change in the hack I wrote.
> 

I always thought of doing this as a different encoding, so you can put your translation on Lib/encodings/ and just do a # _*_ encoding: objective-c on the source files. I know, it is kinda crazy. 

Look at pybraces for how to do it:
http://timhatch.com/projects/pybraces/

--
Leonardo Santagada
santagada at gmail.com

Re: [Pyobjc-dev] Objective-P?

[Ronald O. <ron...@ma...>]

On 12 Nov, 2009, at 11:59, Anders Hovmöller wrote:

> 
> 
> On Thu, Nov 12, 2009 at 11:18 AM, Orestis Markou <or...@or...> wrote:
> 
> On 12 Nov 2009, at 11:59, Ronald Oussoren wrote:
> 
> > What really annoys me though is that I haven't been able to find a way to get clear integration of Cocoa and Python without changing the Python syntax, and without using manual translation of method names (as was used by the Java-Cocoa bridge).
> 
> I've given some thought to that in the past, and of course I know it comes up on the list every couple of months.
> 
> I think an important step is maintaing the order of the **kwargs dictionary:
> 
> def set(self, **kwargs):
>     # construct method name from kwargs
>     # extract positional args from kwargs
>     objc.dispatch(methodname, args)
> 
> 
> foo.set(Value=1, forKey='a')
> foo.set(forKey='a', Value=1)
> 
> If those calls could be differentiated in the body of 'set', would it not help? Some cases could be ambiguous, but in that case a warning could be emitted and the current convention could be used instead.
> 
> Mapping python-style named parameters to objective-c message sending would probably incur quite a bit of overhead, and the end result, in my mind, ends up being not so readable either.

I agree with your readability concerns, a generic interface for sending messages would look somethink like this:

     someObject(setValue=42, forKey="foo")

It is far from obvious that this dispatches to a method, rather than calling a function with keyword arguments. This also doesn't work with methods that do not have arguments.

Ronald

Re: [Pyobjc-dev] Objective-P?

[Orestis M. <or...@or...>]

On 12 Nov 2009, at 11:59, Ronald Oussoren wrote:

> What really annoys me though is that I haven't been able to find a way to get clear integration of Cocoa and Python without changing the Python syntax, and without using manual translation of method names (as was used by the Java-Cocoa bridge).

I've given some thought to that in the past, and of course I know it comes up on the list every couple of months.

I think an important step is maintaing the order of the **kwargs dictionary:

def set(self, **kwargs):
     # construct method name from kwargs
     # extract positional args from kwargs
     objc.dispatch(methodname, args)


foo.set(Value=1, forKey='a')
foo.set(forKey='a', Value=1)

If those calls could be differentiated in the body of 'set', would it not help? Some cases could be ambiguous, but in that case a warning could be emitted and the current convention could be used instead.

Orestis

Re: [Pyobjc-dev] Objective-P?

[Anders H. <bo...@ki...>]

On Thu, Nov 12, 2009 at 10:59 AM, Ronald Oussoren <ron...@ma...>wrote:

>
> On 12 Nov, 2009, at 0:01, Anders Hovmöller wrote:
>
> [ .... ]
>
>
> Find attached the source for the custom importer.
>
>
> While this is a nice trick I'd be much more interested in a syntax-change
> that at least has a chance of getting accepted into the Python core.   Your
> syntax for calling a method is ambiguous, at least for the parser using in
> CPython and possibly in general:
>
>     10 <foo + bar> baz
>
> Python's parser needs to know if the '<' token is the start of a method
> call or a comparison operator (and so do humans, it's far from clear what's
> going on here when I look at the code).
>

Yea, I know. I just chose <> instead of [] to finish my quick and dirty
prototype in the two hours I had alloted :P As for trying to get something
that can be accepted into Python proper, I think that's a dead end. Python
already has a syntax for named parameters. I think this calls for a domain
specific extension, not something you'd necessarily want to push up to
CPython.


>
>
I've been thinking about syntax enhancements during the summer, the best I
> could think of was the introduction of a new operator:
>
>     class MyObject (NSObject):
>          def $[setValue: value]:
> pass
>
>    $[myObject setValue:42]
>
> In this code '$[' would be a new operator, which should be unambigous
> w.r.t. existing code. Better yet, one could use a simular trick for
> anonymous functions:
>
> Hmm, yea that's probably a nicer way of doing it. Changing from < and > to
$[ and ] should be a rather trivial change in the hack I wrote.

Best regards,
Anders

Re: [Pyobjc-dev] Objective-P?

[Anders H. <bo...@ki...>]

On Thu, Nov 12, 2009 at 11:18 AM, Orestis Markou <or...@or...> wrote:

>
> On 12 Nov 2009, at 11:59, Ronald Oussoren wrote:
>
> > What really annoys me though is that I haven't been able to find a way to
> get clear integration of Cocoa and Python without changing the Python
> syntax, and without using manual translation of method names (as was used by
> the Java-Cocoa bridge).
>
> I've given some thought to that in the past, and of course I know it comes
> up on the list every couple of months.
>
> I think an important step is maintaing the order of the **kwargs
> dictionary:
>
> def set(self, **kwargs):
>     # construct method name from kwargs
>     # extract positional args from kwargs
>     objc.dispatch(methodname, args)
>
>
> foo.set(Value=1, forKey='a')
> foo.set(forKey='a', Value=1)
>
> If those calls could be differentiated in the body of 'set', would it not
> help? Some cases could be ambiguous, but in that case a warning could be
> emitted and the current convention could be used instead.
>

Mapping python-style named parameters to objective-c message sending would
probably incur quite a bit of overhead, and the end result, in my mind, ends
up being not so readable either.

Best regards,
Anders

Re: [Pyobjc-dev] Objective-P?

[Ronald O. <ron...@ma...>]

On 12 Nov, 2009, at 11:18, Orestis Markou wrote:

> 
> On 12 Nov 2009, at 11:59, Ronald Oussoren wrote:
> 
>> What really annoys me though is that I haven't been able to find a way to get clear integration of Cocoa and Python without changing the Python syntax, and without using manual translation of method names (as was used by the Java-Cocoa bridge).
> 
> I've given some thought to that in the past, and of course I know it comes up on the list every couple of months.

It sure does, and to Anders credit he did come up with the first original idea in a couple of years ;-)

> 
> I think an important step is maintaing the order of the **kwargs dictionary:
> 
> def set(self, **kwargs):
>     # construct method name from kwargs
>     # extract positional args from kwargs
>     objc.dispatch(methodname, args)
> 
> 
> foo.set(Value=1, forKey='a')
> foo.set(forKey='a', Value=1)
> 
> If those calls could be differentiated in the body of 'set', would it not help? Some cases could be ambiguous, but in that case a warning could be emitted and the current convention could be used instead.

That would help a lot, assuming that the elements in selectors are unique. It would break down for a method like 'strokeFromPoint:toPoint:toPoint:' (which doesn't actually exist). That method would need two 'toPoint' keyword arguments, which is not possible at all.

It should be possible to compile a mapping from the list of keyword arguments to ObjC selectors when a class proxy is initialized, but I'd like to avoid that. I'm not to happy about the current work we're doing when a class proxy is fully initialized (when it is first used), and am thinking about ways to reduce that work not add more. Dynamicly probing should of course also be possible (that is, try 'forKey:setValue' then 'setValue:forKey:' and cache which one works).

Ronald

Re: [Pyobjc-dev] Objective-P?

[Ronald O. <ron...@ma...>]

On 12 Nov, 2009, at 0:01, Anders Hovmöller wrote:

> Ever since I saw Objective-J (http://cappuccino.org/learn/tutorials/objective-j-tutorial.php) it has bothered me a bit how you have to mangle the function calls in pyobjc. The calling syntax in Objective-C is a big part of what makes the API so nice to use and easy to maintain, and it seems pretty trivial to get something similar running for python.
> 
> I implemented a little proof of concept for "Objective-P", which is basically python with support for Objective-C-like method calls. Because I'm not really good with parsers I used < and > instead of [ and ] to not mess with list comprehensions which I have in my code a lot (I know, it breaks other stuff but those cases are more rare and it's just a quick and dirty hack so far). Some example code:
> 
> class Foo:
> 	def <self foo:foo bar:bar>:
> 	    print 'success!'
> 
> foo = Foo()
> <foo foo:1 bar:2>
> 
> This code is converted at import time from a ".opy" file to a ".py" file which is in turn loaded by the standard python loader. 
> 
> Find attached the source for the custom importer.

While this is a nice trick I'd be much more interested in a syntax-change that at least has a chance of getting accepted into the Python core.   Your syntax for calling a method is ambiguous, at least for the parser using in CPython and possibly in general:

    10 <foo + bar> baz

Python's parser needs to know if the '<' token is the start of a method call or a comparison operator (and so do humans, it's far from clear what's going on here when I look at the code).

I've been thinking about syntax enhancements during the summer, the best I could think of was the introduction of a new operator:

    class MyObject (NSObject):
         def $[setValue: value]:
		pass

   $[myObject setValue:42]

In this code '$[' would be a new operator, which should be unambigous w.r.t. existing code. Better yet, one could use a simular trick for anonymous functions:

    foo = $(a, b):
	print a
	print b
	return 4

I've haven't tried to actually implement my ideas yet and have no idea whether they could be implemented in CPython. I am pretty sure though that my ideas have about 0% of getting accepted into CPython (even without the proposed language moratorium).

What really annoys me though is that I haven't been able to find a way to get clear integration of Cocoa and Python without changing the Python syntax, and without using manual translation of method names (as was used by the Java-Cocoa bridge).

Ronald

Re: [Pyobjc-dev] Objective-C to Python converter

[Anders H. <bo...@ki...>]

> This is rather cool, and pretty useful.
>
> One thing you may want to do is to strip all calls to the -release and
> -retain methods, those are handled automaticly by PyObjC.  Looking at the
> source code for the converter that's probably a non-trivial change.
>
> Ronald
>
>
Removing them should be fairly trivial, but you'll probably end up with some
lines that have no side effects, like if you do:
[[foo bar] release];
which would just be translated to:
foo.bar()

If that's a trivial getter then of course the entire line can be removed,
but figuring out from the script if the line has side effects would require
whole program analysis yea.

So in conclusion: yes and no, depending on how good of a result you want :P

Best Regards,
Anders Hovmöller

Re: [Pyobjc-dev] Performing selectors example?

[Luc H. <lu...@ho...>]

On 8 nov. 2009, at 09:18, James Trankelson wrote:

> class MyClass (Foundation.NSObject):
>    def callback(self, arg):
>        print "Test!"
>    def setup(self, arg):
>        self.pyobjc_performSelectorOnMainThread_withObject_('test', 44)

Well, you are trying to call a 'test' selector which clearly does not  
exist, hence the 'unrecognized selector'.

You probably want:

self.pyobjc_performSelectorOnMainThread_withObject_('callback', 44)

-- 
Luc Heinrich - lu...@ho...

[Pyobjc-dev] Performing selectors example?

[James T. <tra...@gm...>]

Hi,

I'm trying to get performSelectorOnMainThread working in PyObjC, based
on an example found on the site:

http://pyobjc.sourceforge.net/documentation/pyobjc-framework-Cocoa/threading-helpers.html

However, I've been unsuccessful in my attempts to receive the
callback. Can anyone point me to a working example of this
functionality?


----------

class MyClass (Foundation.NSObject):
    def callback(self, arg):
        print "Test!"
    def setup(self, arg):
        self.pyobjc_performSelectorOnMainThread_withObject_('test', 44)



 dl = MyClass.alloc().init()
 setup("arg")


--> [MyClass pyobjc_performOnThreadWithResult:]: unrecognized selector
sent to instance ...

Re: [Pyobjc-dev] Problems with Snow Leopard and PyObjC (Possibly Configuration of Templates)

[Ronald O. <ron...@ma...>]

On 1 Nov, 2009, at 20:53, luis cota wrote:

> Need help properly configuring XCode with PyObjC
> Installing templates following: http://ioanna.me/2009/09/installing-pyobjc-xcode-templates-in-snow-leopard/ allows creation of projects correctly
> When creating a class (Python-Cocoa) that contains IBOutlets and IBActions which are then connected by InterfaceBuilder, Application is not able to locate class at runtime. (See enclosed Fusebox.py class as part of Calculator project in Cocoa Programing for Dummies)
> IBOutlets and IBActions need to be added to AppDelegate class to be recognized at runtime?
> Breakpoints - is debugging not available with PyObjC? How do you set breakpoints? I can do it just fine with ObjC...
> Please help with the above...very confused and not sure how to proceed with XCode and PyObjC.

When you add a new Python file to the project you must import it somewhere. In simple project's I tend to add the import statement for classes that are only used in nib files to the 'main.py' file.

When you do that problems 2 and 3 go away.

XCode does not support debugging of Python code (or rather anything that is not Objective-C/C++). I tend to get by with print statements and sometimes fall back to Python's pdb debugger. The latter has lowlevel command-line interface, it doesn't have a nice GUI.

Ronald

Re: [Pyobjc-dev] Objective-C to Python converter

[Ronald O. <ron...@ma...>]

On 31 Oct, 2009, at 2:14, Anders Hovmöller wrote:

> Hi,
> 
> I was getting bored of converting pieces of objective-c from examples  
> and documentation to pyobjc manually so I wrote a little script to do  
> it: http://kodare.wordpress.com/2009/10/13/objective-c-to-python-converter/ 
>  It's not the prettiest code but it gets the job done :P
> 
> I've put the code under public domain and there's a little web form if  
> you want to use it without fiddling around too much with the script.

This is rather cool, and pretty useful.

One thing you may want to do is to strip all calls to the -release and -retain methods, those are handled automaticly by PyObjC.  Looking at the source code for the converter that's probably a non-trivial change.

Ronald

[Pyobjc-dev] py2app alias builds broken on Snow Leopard

[James R E. <Jam...@lr...>]

Hi folks,

I haven't seen anything relating to this on the list, but it appears  
that the version of py2app that ships with Snow Leopard makes broken  
alias builds.  The problems appears to be with the way it symlinks to  
the python interpreter.  On 10.6, it links to /usr/bin/python, whereas  
in 10.5 it would symlink to the /System Python.framework version (see  
below).  The result is that when __boot__.py builds the sys.path, it's  
sys.exec_prefix is /usr, so the proper site-packages (including  
PyObjC!) don't get included.  See transcript below for more info.

I've attached two patches (one for SVN trunk; one for the py2app that  
ships with Snow Leopard) that work for me.  They modify the py2app  
build_alias_executable() method to symlink to sys.prefix/bin/python  
(if it exists) instead of sys.executable.  This works for me, and I  
think it should normally be the correct behavior, but I'm not 100%  
convinced of that.  Ronald: do you agree?

See the transcript below for an illustration of the problem.

Cheers!
James


### Differences in built applications between 10.6 (above) and 10.5  
(below)

lri11-245:~/Projects/LRI/Scotty/Viewer/dist/Scotty.app/Contents/MacOS  
$ ll
total 216
-rwxr-xr-x  1 eaganj  eaganj  103292 Jul  1 08:26:26 2009 Scotty*
lrwx------  1 eaganj  eaganj      15 Nov  2 10:34:05 2009 python@ -> / 
usr/bin/python

lri11-245:~/Projects/LRI/ScottySVNSucks/Viewer/dist/Scotty.app/ 
Contents/MacOS $ ll
total 176
-rwxr-xr-x  1 eaganj  eaganj  83840 Sep 24 06:50:46 2007 Scotty*
lrwx------  1 eaganj  eaganj     99 Jul 27 15:00:42 2009 python@ -> / 
System/Library/Frameworks/Python.framework/Versions/2.5/Resources/ 
Python.app/Contents/MacOS/Python



### Differences in running python via symlink:

# First with python found on PATH
lri11-245:~ $ which python
/usr/bin/python
lri11-245:~ $ python
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import sys; sys.executable
'/usr/bin/python'
 >>> sys.prefix
'/System/Library/Frameworks/Python.framework/Versions/2.6'


# Now with Python via symlink
lri11-245:~ $ ln -s /usr/bin/python symlink-python
lri11-245:~ $ ./symlink-python
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import sys; sys.executable
'/Users/eaganj/symlink-python'
 >>> sys.prefix
'/usr'
 >>> # The prefixes are different depending on how the same python  
exec is invoked!

# Note that /usr/bin/python is not a symlink
lri11-245:~ $ ll /usr/bin/python*
-rwxr-xr-x  2 root  wheel  86000 Jul  8 08:57:10 2009 /usr/bin/python*
-rwxr-xr-x  5 root  wheel    925 Jul  8 08:57:08 2009 /usr/bin/python- 
config*
lrwxr-xr-x  1 root  wheel     75 Aug 29 14:00:38 2009 /usr/bin/ 
python2.5@ -> ../../System/Library/Frameworks/Python.framework/ 
Versions/2.5/bin/python2.5
lrwxr-xr-x  1 root  wheel     82 Aug 29 14:00:38 2009 /usr/bin/ 
python2.5-config@ -> ../../System/Library/Frameworks/Python.framework/ 
Versions/2.5/bin/python2.5-config
lrwxr-xr-x  1 root  wheel     75 Aug 29 14:00:38 2009 /usr/bin/ 
python2.6@ -> ../../System/Library/Frameworks/Python.framework/ 
Versions/2.6/bin/python2.6
lrwxr-xr-x  1 root  wheel     82 Aug 29 14:00:38 2009 /usr/bin/ 
python2.6-config@ -> ../../System/Library/Frameworks/Python.framework/ 
Versions/2.6/bin/python2.6-config
-rwxr-xr-x  2 root  wheel  86000 Jul  8 08:57:10 2009 /usr/bin/pythonw*
lrwxr-xr-x  1 root  wheel     76 Aug 29 14:00:38 2009 /usr/bin/ 
pythonw2.5@ -> ../../System/Library/Frameworks/Python.framework/ 
Versions/2.5/bin/pythonw2.5
lrwxr-xr-x  1 root  wheel     76 Aug 29 14:00:38 2009 /usr/bin/ 
pythonw2.6@ -> ../../System/Library/Frameworks/Python.framework/ 
Versions/2.6/bin/pythonw2.6

# And that /usr/bin/python is apparently some kind of a wrapper  
program (sizes are different)
lri11-245:~ $ ll /System/Library/Frameworks/Python.framework/Versions/ 
2.6/bin/python2.6
-rwxr-xr-x  1 root  wheel  50720 Jul  8 08:56:58 2009 /System/Library/ 
Frameworks/Python.framework/Versions/2.6/bin/python2.6*


Patch for SVN trunk (made from py2app/trunk):

[Pyobjc-dev] Objective-C to Python converter

[Anders H. <bo...@ki...>]

Hi,

I was getting bored of converting pieces of objective-c from examples  
and documentation to pyobjc manually so I wrote a little script to do  
it: http://kodare.wordpress.com/2009/10/13/objective-c-to-python-converter/ 
  It's not the prettiest code but it gets the job done :P

I've put the code under public domain and there's a little web form if  
you want to use it without fiddling around too much with the script.

Best Regards,
Anders Hovmöller

Re: [Pyobjc-dev] Snowleopard GC & 64-bit (also easy_install)

[Ronald O. <ron...@ma...>]

On 19 Oct, 2009, at 20:31, Jonathan Wight wrote:

>> On 19 Oct, 2009, at 16:36, Jonathan Wight wrote:
>>
>> * AFAIK Python is not build correctly to link into GC enabled
>> applications
>>
>> * While I try to ensure that PyObjC's reference management is safe
>> w.r.t. GC (using CFRetain/CFRelease rather than -retain/-release) I
>> have never tested if this is sufficient. That means PyObjC is almost
>> certainly unsafe w.r.t. GC.
>
> Anything I can do to help?

Probably not. Getting PyObjC into a GC-safe state requires code review  
and while others could do that I'm probably the only one that can do  
this with a reasonable amount of effort.  The pyobjc-core code is  
rather hairy :-(
>
> Would love to get PyObjc up and running on GC/64-bit.

Me too ;-)

Ronald
>
> 	Jon.
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Snowleopard GC & 64-bit (also easy_install)

[Jonathan W. <jwi...@to...>]

> On 19 Oct, 2009, at 16:36, Jonathan Wight wrote:
>
> * AFAIK Python is not build correctly to link into GC enabled  
> applications
>
> * While I try to ensure that PyObjC's reference management is safe  
> w.r.t. GC (using CFRetain/CFRelease rather than -retain/-release) I  
> have never tested if this is sufficient. That means PyObjC is almost  
> certainly unsafe w.r.t. GC.

Anything I can do to help?

Would love to get PyObjc up and running on GC/64-bit.

	Jon.