pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] using objc.inject

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

Hi Dan,

I actually use objc.inject for a few projects, and it's a great  
debugging tool.  I believe that your problem looks more like a bug in  
the InjectInterpreter code rather than in the lower-level objc.inject  
code (which works great!).  In particular, try changing line 365 of  
InjectInterpreterPlugin.py from NSAnyEventMask to NSUIntegerMax.

Logically, the use of NSAnyEventMask is correct in the above code.  On  
the PyObjC side, however, it's a signed integer (at least in the  
PyObjC that comes with Leopard) instead of an unsigned integer.   
That's why NSUIntegerMax is functionally correct (even if logically  
incorrect) here.  As for why NSAnyEventMask is signed instead of  
unsigned, that might be a bug in PyObjC.  Maybe.

 >>> NSUIntegerMax
4294967295L
 >>> NSAnyEventMask
-1
 >>> struct.unpack('L', struct.pack('l', NSAnyEventMask))[0] # cast to  
unsigned
4294967295L

Cheers!
James

Le 29 juil. 09 à 18:18, Daniel Ashbrook a écrit :

> Re: "does anyone use objc.inject" from a few months ago, I think I
> would like to. I'm hoping to get at the internals of a program and
> extract some hard-to-get-at information. However, trying the
> InjectInterpreter example code doesn't seem to work, so any hints
> would be appreciated. Doing:
>
>   sudo python test.py 71755
>
> (where 7155 is the pid of TextEdit) returns without comment, but
> prints to the system log:
>
> TextEdit[71755]: InjectInterpreterPlugin has encountered a fatal
> error, and will now terminate.
> TextEdit[71755]: An uncaught exception was raised during execution of
> the main script:^M^MSystemError: NULL result without error in
> PyObject_Call^M^MThis may mean that an unexpected error has occurred,
> or that you do not have all of the dependencies for this bundle.
> [0x0-0x48d48d].com.apple.TextEdit[71755]: Traceback (most recent call
> last):
> [0x0-0x48d48d].com.apple.TextEdit[71755]:   File "/tmp/
> InjectInterpreter/dist/InjectInterpreterPlugin.plugin/Contents/
> Resources/__boot__.py", line 23, in <module>
> [0x0-0x48d48d].com.apple.TextEdit[71755]:
> _run('InjectInterpreterPlugin.py')
> [0x0-0x48d48d].com.apple.TextEdit[71755]:   File "/tmp/
> InjectInterpreter/dist/InjectInterpreterPlugin.plugin/Contents/
> Resources/__boot__.py", line 20, in _run
> [0x0-0x48d48d].com.apple.TextEdit[71755]:     execfile(path,
> globals(), globals())
> [0x0-0x48d48d].com.apple.TextEdit[71755]:   File "/tmp/
> InjectInterpreter/dist/InjectInterpreterPlugin.plugin/Contents/
> Resources/InjectInterpreterPlugin.py", line 187, in <module>
> [0x0-0x48d48d].com.apple.TextEdit[71755]:     class
> PyInterpreter(NSTextView):
> [0x0-0x48d48d].com.apple.TextEdit[71755]: SystemError: NULL result
> without error in PyObject_Call
>
> Any hints?
>
> Thanks,
>
>
> dan
>
> ------------------------------------------------------------------------------
> 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

Re: [Pyobjc-dev] using objc.inject

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

On 29 Jul, 2009, at 18:18, Daniel Ashbrook wrote:

> Re: "does anyone use objc.inject" from a few months ago, I think I
> would like to. I'm hoping to get at the internals of a program and
> extract some hard-to-get-at information. However, trying the
> InjectInterpreter example code doesn't seem to work, so any hints
> would be appreciated. Doing:
>
>   sudo python test.py 71755
>
> (where 7155 is the pid of TextEdit) returns without comment, but
> prints to the system log:
>
> TextEdit[71755]: InjectInterpreterPlugin has encountered a fatal
> error, and will now terminate.
> TextEdit[71755]: An uncaught exception was raised during execution of
> the main script:^M^MSystemError: NULL result without error in
> PyObject_Call^M^MThis may mean that an unexpected error has occurred,
> or that you do not have all of the dependencies for this bundle.
> [0x0-0x48d48d].com.apple.TextEdit[71755]: Traceback (most recent call
> last):
> [0x0-0x48d48d].com.apple.TextEdit[71755]:   File "/tmp/
> InjectInterpreter/dist/InjectInterpreterPlugin.plugin/Contents/
> Resources/__boot__.py", line 23, in <module>
> [0x0-0x48d48d].com.apple.TextEdit[71755]:
> _run('InjectInterpreterPlugin.py')
> [0x0-0x48d48d].com.apple.TextEdit[71755]:   File "/tmp/
> InjectInterpreter/dist/InjectInterpreterPlugin.plugin/Contents/
> Resources/__boot__.py", line 20, in _run
> [0x0-0x48d48d].com.apple.TextEdit[71755]:     execfile(path,
> globals(), globals())
> [0x0-0x48d48d].com.apple.TextEdit[71755]:   File "/tmp/
> InjectInterpreter/dist/InjectInterpreterPlugin.plugin/Contents/
> Resources/InjectInterpreterPlugin.py", line 187, in <module>
> [0x0-0x48d48d].com.apple.TextEdit[71755]:     class
> PyInterpreter(NSTextView):
> [0x0-0x48d48d].com.apple.TextEdit[71755]: SystemError: NULL result
> without error in PyObject_Call
>
> Any hints?

Not really. Debugging objc.inject is a pain, especially because it is  
very lowlevel code and I haven't written the code myself.

And anyway, I'll remove it before the next release. In theory it  
should be possible to take the relevant code and create a separate  
project for it.

Ronald
>
> Thanks,
>
>
> dan
>
> ------------------------------------------------------------------------------
> 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

Re: [Pyobjc-dev] Explicit conversion from ObjC to PyObject?

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

On 1 Aug, 2009, at 2:08, Greg Abbas wrote:

> FWIW I think I figured out how to do this: pyobjc-api.h defines
> several macros including PyObjC_ObjCToPython and PyObjC_PythonToObjC.
> The only wrinkle is that you need to make sure you call
> PyObjC_ImportAPI first (and be a little clever because of how it
> stores a function table pointer in a static variable), but it seems to
> work great.
>
> Well actually, there's sort of another wrinkle which is that as far as
> I can tell PyObjC_ImportAPI isn't an official or supported API. So
> caveat emptor, but hopefully it's pretty stable at this point.

The API is unsupported, but is used by the framework wrappers as well.  
I might clean up the API in a future release, but that should be  
doable while retaining backward compatibility for the bits of  
interface that are retained.

Using PyObjC_ObjCToPython and PyObjC_PythonToObjC will definitely be  
retained in future editions of the API.

Ronald

>
> On Jul 27, 2009, at 10:29 PM, Greg Abbas wrote:
>
>> Hi,
>>
>> Is it feasible to mix the "old-fashioned" Python C API with PyObjC?
>> Specifically, I'm exposing some C++ classes to Python using
>> PyType_Ready and all of that, but some of those methods are actually
>> Objective-C++ code and return Objective C instances such as  
>> NSColor. I
>> could manually wrap them too, but that seems wasteful considering all
>> the excellent work that's gone into creating PyObjC. Is there a way  
>> to
>> explicitly ask PyObjC to wrap an Objective C object and turn it  
>> into a
>> PyObject* proxy that I can return to the Python interpreter?
>>
>> All the PyObjC examples that I've found so far assume that you're not
>> using any other low-level interface, and so everything is magically
>> wrapped & unwrapped whenever it crosses the Python<->ObjC boundary.
>> But what if I want to participate in that boundary manually? Is there
>> a "PyObject * convertObjCToPython(id)" function that I can call? (Or
>> convertPythonToObjC, for that matter?)
>>
>> Thanks very much in advance for any insights.
>>
>> -greg abbas.
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
> ------------------------------------------------------------------------------
> 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

Re: [Pyobjc-dev] PyObjC and DBApi2

[Dirk S. <dir...@me...>]

Hi Marco,

A Python list is the equivalent of an NSMutableArray, so you can e.g.  
call setContent on an arrayController with the result of your query,  
you can then bind the table to the arrayController.

Also take a look at SQLObject, SQLAlchemy and Twisted for more  
sophisticated ways to interact with an SQL database.

Cheers,

- Dirk

---
Sent from my iPhone

On Aug 10, 2009, at 12:13 PM, Alexander Mail <ale...@gm...>  
wrote:

> Hi,
> I'm new in PyObjC/Cocoa programming. I read a lot of
> documentation. But now I have this problem:
> I'm developing an application that gets data form a
> Posgtres database. To connect to PG I used PsycoPg2.
> But I don't understand how to manage the result of PG
> (lists) with the cocoa bindings. My goal is to show
> the get data in a NSTableView.
> There is some documentations?
>
> Thank a lot.
>
> Marco
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> 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] PyObjC and DBApi2

[Alexander M. <ale...@gm...>]

Hi,
I'm new in PyObjC/Cocoa programming. I read a lot of
documentation. But now I have this problem:
I'm developing an application that gets data form a
Posgtres database. To connect to PG I used PsycoPg2.
But I don't understand how to manage the result of PG
(lists) with the cocoa bindings. My goal is to show
the get data in a NSTableView.
There is some documentations?

Thank a lot.

Marco

[Pyobjc-dev] PyObjC 2.2 on PPC 10.4?

[Aahz <aa...@py...>]

Has anyone successfully built/run a PyObjC 2.2 app on PPC 10.4?  I'm
getting NameError on NSDefaultRunLoopMode after 

    from Foundation import *
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

"...string iteration isn't about treating strings as sequences of strings, 
it's about treating strings as sequences of characters.  The fact that
characters are also strings is the reason we have problems, but characters 
are strings for other good reasons."  --Aahz

Re: [Pyobjc-dev] Explicit conversion from ObjC to PyObject?

[Greg A. <ga...@ap...>]

FWIW I think I figured out how to do this: pyobjc-api.h defines  
several macros including PyObjC_ObjCToPython and PyObjC_PythonToObjC.  
The only wrinkle is that you need to make sure you call  
PyObjC_ImportAPI first (and be a little clever because of how it  
stores a function table pointer in a static variable), but it seems to  
work great.

Well actually, there's sort of another wrinkle which is that as far as  
I can tell PyObjC_ImportAPI isn't an official or supported API. So  
caveat emptor, but hopefully it's pretty stable at this point.

On Jul 27, 2009, at 10:29 PM, Greg Abbas wrote:

> Hi,
>
> Is it feasible to mix the "old-fashioned" Python C API with PyObjC?
> Specifically, I'm exposing some C++ classes to Python using
> PyType_Ready and all of that, but some of those methods are actually
> Objective-C++ code and return Objective C instances such as NSColor. I
> could manually wrap them too, but that seems wasteful considering all
> the excellent work that's gone into creating PyObjC. Is there a way to
> explicitly ask PyObjC to wrap an Objective C object and turn it into a
> PyObject* proxy that I can return to the Python interpreter?
>
> All the PyObjC examples that I've found so far assume that you're not
> using any other low-level interface, and so everything is magically
> wrapped & unwrapped whenever it crosses the Python<->ObjC boundary.
> But what if I want to participate in that boundary manually? Is there
> a "PyObject * convertObjCToPython(id)" function that I can call? (Or
> convertPythonToObjC, for that matter?)
>
> Thanks very much in advance for any insights.
>
> -greg abbas.
>
>
> ------------------------------------------------------------------------------
> 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] pyobjc/py2app/Xcode

[Aahz <aa...@py...>]

I tried posting to pythonmac-sig yesterday without response, so I'll try
here today.  ;-)

I'm working on an app that has previously been built with PyObjC 1.4;
there's another app built on PyObjC 2.2, and I'm trying to move the
older app to 2.2 to simplify builds.  However, just using 2.2 fails
because 2.2 no longer has PyObjCTools/XcodeSupport, and there's no
mention in pyobjc-core/NEWS.txt.  What's the proper upgrade path?

I'm also generally finding it difficult to get information on how to
integrate an Xcode project into PyObjC and py2app, where I should I look?
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer

[Pyobjc-dev] using objc.inject

[Daniel A. <an...@cc...>]

Re: "does anyone use objc.inject" from a few months ago, I think I  
would like to. I'm hoping to get at the internals of a program and  
extract some hard-to-get-at information. However, trying the  
InjectInterpreter example code doesn't seem to work, so any hints  
would be appreciated. Doing:

   sudo python test.py 71755

(where 7155 is the pid of TextEdit) returns without comment, but  
prints to the system log:

TextEdit[71755]: InjectInterpreterPlugin has encountered a fatal  
error, and will now terminate.
TextEdit[71755]: An uncaught exception was raised during execution of  
the main script:^M^MSystemError: NULL result without error in  
PyObject_Call^M^MThis may mean that an unexpected error has occurred,  
or that you do not have all of the dependencies for this bundle.
[0x0-0x48d48d].com.apple.TextEdit[71755]: Traceback (most recent call  
last):
[0x0-0x48d48d].com.apple.TextEdit[71755]:   File "/tmp/ 
InjectInterpreter/dist/InjectInterpreterPlugin.plugin/Contents/ 
Resources/__boot__.py", line 23, in <module>
[0x0-0x48d48d].com.apple.TextEdit[71755]:      
_run('InjectInterpreterPlugin.py')
[0x0-0x48d48d].com.apple.TextEdit[71755]:   File "/tmp/ 
InjectInterpreter/dist/InjectInterpreterPlugin.plugin/Contents/ 
Resources/__boot__.py", line 20, in _run
[0x0-0x48d48d].com.apple.TextEdit[71755]:     execfile(path,  
globals(), globals())
[0x0-0x48d48d].com.apple.TextEdit[71755]:   File "/tmp/ 
InjectInterpreter/dist/InjectInterpreterPlugin.plugin/Contents/ 
Resources/InjectInterpreterPlugin.py", line 187, in <module>
[0x0-0x48d48d].com.apple.TextEdit[71755]:     class  
PyInterpreter(NSTextView):
[0x0-0x48d48d].com.apple.TextEdit[71755]: SystemError: NULL result  
without error in PyObject_Call

Any hints?

Thanks,


dan

[Pyobjc-dev] Explicit conversion from ObjC to PyObject?

[Greg A. <ga...@ap...>]

Hi,

Is it feasible to mix the "old-fashioned" Python C API with PyObjC?  
Specifically, I'm exposing some C++ classes to Python using  
PyType_Ready and all of that, but some of those methods are actually  
Objective-C++ code and return Objective C instances such as NSColor. I  
could manually wrap them too, but that seems wasteful considering all  
the excellent work that's gone into creating PyObjC. Is there a way to  
explicitly ask PyObjC to wrap an Objective C object and turn it into a  
PyObject* proxy that I can return to the Python interpreter?

All the PyObjC examples that I've found so far assume that you're not  
using any other low-level interface, and so everything is magically  
wrapped & unwrapped whenever it crosses the Python<->ObjC boundary.  
But what if I want to participate in that boundary manually? Is there  
a "PyObject * convertObjCToPython(id)" function that I can call? (Or  
convertPythonToObjC, for that matter?)

Thanks very much in advance for any insights.

-greg abbas.

[Pyobjc-dev] Best way to use modules from The Python Package Index

[Andreas K. <ka...@xo...>]

Hi all!


First a little introduction of myself: I'm working as a Zope / Plone  
developer in my "day job". So I'm quite comfortable with Python.  
However, I recently decided to spend some of my spare time on a  
private project: a Cocoa application (for my personal (apparently  
quite uncommon) music library management needs). I'm reading Aaron  
Hillegass' "Cocoa Programming for Mac OS X" to become familiar with  
Cocoa, which works out quite well so far. No real problems to map the  
Objective-C code in the book to Python.

Now for my question, which I was unable to answer myself by searching  
the web and the mailing list archive…

What is the best way to use modules from "The Python Package Index" in  
my application?

As a Zope / Plone developer I'm used to buildout, which basically  
automates the task to create a virtualenv with custom modules. So far  
I'm manually downloading source distributions of the modules I want to  
use in my application, unpack them and add the directories to my Xcode  
project. Although it does work this way, it's already beginning to  
annoy me, especially when using namespace packages within the same  
namespace.

Any pointers on that subject are highly appreciated!


TIA,

Andreas

Re: [Pyobjc-dev] TypeError: cannot change a method

[Daniel M. <mil...@gm...>]

On Jul 17, 2009, at 12:53 AM, Ronald Oussoren wrote:
> On 17 Jul, 2009, at 3:09, Daniel Miller wrote:
>>
>>
>> FWIW, it seems to be possible to replace a method directly on the  
>> PyObjC type. For example:
>>
>> # this works
>> fake = descriptor_mock()
>> NSDocument.removeWindowController_ = fake
>>
>> Assuming the 'fake' object implements the descriptor protocol, the  
>> fake/mocked method will get called as expected.
>> But it then it fails when trying to restore the original method:
>>
>> NSDocument.removeWindowController_ = original
>> # TypeError: Assigning native selectors is not supported
>>
>> However, this seems to restore the original:
>>
>> del NSDocument.removeWindowController_
>>
>> Strange... while I may be able to use this approach, it has the  
>> disadvantage of replacing the method on ALL instances of the type  
>> rather than on just a the instance that I'm testing--I may need to  
>> rewrite some tests to work with that restriction, but it probably   
>> wouldn't be the end of the world.
>
> You're not going to like this, but the behaviour you describe here  
> sounds like a bug. In particular, it is possible to overwrite an  
> existing method using a new function object but it should not be  
> possible to overwrite it with something else. Removing the fake  
> descriptor should also not result in revival of the original method  
> because a replacement method should result in a changed method in  
> the ObjC runtime.

Does a descriptor (i.e. an object with a __get__() member) count as a  
function object?

Also, since it is possible to overwrite a method with a function,  
wouldn't it make sense to provide some way to restore it to its  
original state? That should be all I need.

I can understand the motivation to make it illegal to overwrite a  
method on an instance with a non-callable object. However, could the  
restriction be relaxed to allow a callable object (function, object  
with __call__, etc.) to overwrite a method on an instance? As far as I  
know any attempt to replace a method on an instance raises an error  
right now.


> I need to think about your testing needs, if it is possible to  
> support those and if so how.

If there is some way to replace a method with some other callable, and  
then restore to the original state, I think that's all I need. I can  
even deal if it can only be done on the type (not instance), but I  
think my above proposal to allow overwriting an instance method with  
some other callable would probably make sense, while still protecting  
the newbies from overwriting methods unintentionally.


> A number of limititations in PyObjC, such as this one, are caused by  
> the need to interact with the Objective-C runtime. In particular  
> "objc.selector" objects for native methods are basicly references to  
> a named selector on the ObjC class, they do not contain a reference  
> to the code that will be called when you call the method. That's why  
> it is not possible to assign objc.selector instances to a class  
> attribute.

So you're saying the name to which the selector is bound is the  
important part, not the contents of the selector itself? That's  
interesting... That should not cause a problem as long as there is  
some way to restore the selector to its original state after it has  
been overwritten with a mock method. Maybe PyObjCTools could gain a  
special setattr-like function that could be used to overwrite  
selectors. This function would carry a warning that it should only be  
used by people who know what they are doing. It's more kludgy than  
normal for python, but in this case PyObjC violates the normal python  
conventions, so a kludge may be justified.


> BTW. How does your mocking library deal with other native types:
>
> >>> l = list()
> >>> l.append = 42
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> AttributeError: 'list' object attribute 'append' is read-only
> >>>

I have not needed to mock methods on built-in types, such as  
list.append(), because they do not generally have wide-reaching side  
affects (unlike NSWindowController.window() for example). In a case  
where I really did not want to mutate a list, I would mock/replace the  
entire list instance for the duration of the test (I do this quite  
often). In a framework such as PyObjC, with unconventional write  
restrictions and where many objects are created and/or owned privately  
by the framework, this type of replacement becomes difficult or  
impossible. Hence the need to be able to replace methods with far- 
reaching side affects. If I can't do that then it becomes nearly  
impossible to write tests for code that interacts with the GUI.


> Or more interesting, how does it deal with special methods like  
> __getitem__, those always get resolved through the class:
>
> >>> class List (list): pass
> ...
> >>> l = List()
> >>> l.append(42)
> >>> l[0]
> 42
> >>> l.__getitem__ = 42
> >>> l[0]
> 42
> >>>

Well, in this case I would replace List.__getitem__ (i.e. replace the  
method on the subclass) which is completely legal and possible. PyObjC  
types do not allow this. They are more restrictive than the python  
built-in types because they do not allow me to overwrite a method of  
my own subtype.

> As you can see setting __getitem__ on an instance has no effect on  
> which special method is actually used.

Yes, but if you replace __getitem__ on the subtype, then it works.  
Special methods need to be handled specially. For my test framework,  
PyObjC methods are one class of special method. PyObjC 2 has made them  
harder to deal with, but it's not impossible (yet). Although it sounds  
like you might be making it harder (if the scenario I pointed out  
above is actually a bug).

~ Daniel

[Pyobjc-dev] Fwd: TypeError: cannot change a method

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

Begin forwarded message:

> From: Ronald Oussoren <ron...@ma...>
> Date: 17 July, 2009 6:53:01 GMT+02:00
> To: Daniel Miller <mil...@gm...>
> Subject: Re: [Pyobjc-dev] TypeError: cannot change a method
>
>
> On 17 Jul, 2009, at 3:09, Daniel Miller wrote:
>>>
>>
>> I'm not quite sure what to say other than I'll need to look into  
>> rewriting my test framework. FWIW, it seems to be possible to  
>> replace a method directly on the PyObjC type. For example:
>>
>> # this works
>> fake = descriptor_mock()
>> NSDocument.removeWindowController_ = fake
>>
>> Assuming the 'fake' object implements the descriptor protocol, the  
>> fake/mocked method will get called as expected.
>> But it then it fails when trying to restore the original method:
>>
>> NSDocument.removeWindowController_ = original
>> # TypeError: Assigning native selectors is not supported
>>
>> However, this seems to restore the original:
>>
>> del NSDocument.removeWindowController_
>>
>> Strange... while I may be able to use this approach, it has the  
>> disadvantage of replacing the method on ALL instances of the type  
>> rather than on just a the instance that I'm testing--I may need to  
>> rewrite some tests to work with that restriction, but it probably   
>> wouldn't be the end of the world.
>
> You're not going to like this, but the behaviour you describe here  
> sounds like a bug. In particular, it is possible to overwrite an  
> existing method using a new function object but it should not be  
> possible to overwrite it with something else. Removing the fake  
> descriptor should also not result in revival of the original method  
> because a replacement method should result in a changed method in  
> the ObjC runtime.
>
> I need to think about your testing needs, if it is possible to  
> support those and if so how.
>
> A number of limititations in PyObjC, such as this one, are caused by  
> the need to interact with the Objective-C runtime. In particular  
> "objc.selector" objects for native methods are basicly references to  
> a named selector on the ObjC class, they do not contain a reference  
> to the code that will be called when you call the method. That's why  
> it is not possible to assign objc.selector instances to a class  
> attribute.
>
> BTW. How does your mocking library deal with other native types:
>
> >>> l = list()
> >>> l.append = 42
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> AttributeError: 'list' object attribute 'append' is read-only
> >>>
>
> Or more interesting, how does it deal with special methods like  
> __getitem__, those always get resolved through the class:
>
> >>> class List (list): pass
> ...
> >>> l = List()
> >>> l.append(42)
> >>> l[0]
> 42
> >>> l.__getitem__ = 42
> >>> l[0]
> 42
> >>>
>
> As you can see setting __getitem__ on an instance has no effect on  
> which special method is actually used.
>
> Ronald
>>
>> ~ Daniel
>>
>

Re: [Pyobjc-dev] TypeError: cannot change a method

[Daniel M. <mil...@gm...>]

RESENDING -- inadvertently sent this directly to Ronald


> Could you post some code that shows what you're trying to do?

# test something involving NSDocument.removeWindowContorller_
doc = MyNSDocumentSubclass.alloc().init()
original = doc.removeWindowController_
fake = mocker.mock()
doc.removeWindowController_ = fake
try:
    fake(arg) # simulate call (record expectation)
    ...
    # replay
    ...
    # our fake method is called by the routine we are testing
    doc.removeWindowController_(arg)
    ...
finally:
    doc.removeWindowController_ = original
    ...
    # verify that simulated calls actually happened
    assert was_called(fake)


This is obviously only pseudo code. My framework makes it much more  
convenient to mock one or more methods and then replace them during  
the verify phase.

> I haven't checked the source code yet, but one reason to be careful  
> about overwriting methods in Cocoa classes is that will affect the  
> actual Cocoa class as wel.
>
> Footnote [0] refers to replacing a method in an instance by  
> something else, e.g.:
>
>    o = NSObject.alloc().init()
>    o.description = 42

Yeah, that's what I'm doing.

> That's not allowed because this can lead to very hard to diagnose  
> bugs, and the people that are most likely to run into those are  
> people new to PyObjC that translate existing ObjC sample code into  
> Python (the reason of that is that ObjC has different namespaces for  
> methods and instance variables, while Python has only a single  
> namespace for both of them).

I'm not quite sure what to say other than I'll need to look into  
rewriting my test framework. FWIW, it seems to be possible to replace  
a method directly on the PyObjC type. For example:

# this works
fake = descriptor_mock()
NSDocument.removeWindowController_ = fake

Assuming the 'fake' object implements the descriptor protocol, the  
fake/mocked method will get called as expected. But it then it fails  
when trying to restore the original method:

NSDocument.removeWindowController_ = original
# TypeError: Assigning native selectors is not supported

However, this seems to restore the original:

del NSDocument.removeWindowController_

Strange... while I may be able to use this approach, it has the  
disadvantage of replacing the method on ALL instances of the type  
rather than on just a the instance that I'm testing--I may need to  
rewrite some tests to work with that restriction, but it probably   
wouldn't be the end of the world.

~ Daniel

Re: [Pyobjc-dev] TypeError: cannot change a method

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

Could you post some code that shows what you're trying to do?

I haven't checked the source code yet, but one reason to be careful  
about overwriting methods in Cocoa classes is that will affect the  
actual Cocoa class as wel.

Footnote [0] refers to replacing a method in an instance by something  
else, e.g.:

      o = NSObject.alloc().init()
      o.description = 42

That's not allowed because this can lead to very hard to diagnose  
bugs, and the people that are most likely to run into those are people  
new to PyObjC that translate existing ObjC sample code into Python  
(the reason of that is that ObjC has different namespaces for methods  
and instance variables, while Python has only a single namespace for  
both of them).

BTW, PyObjC breaks another Python idiom as well: "Explicit is better  
than implicit.", and completely on purpuse ;-)

Ronald

On 16 Jul, 2009, at 4:30, Daniel Miller wrote:

> My testing framework for the app I've been developing (previously with
> PyObjC 1.4, now attempting to migrate to PyObjC 2) is giving lots of
> errors due to a restriction in PyObjC 2 that methods cannot be
> overwritten [0]. My testing framework mocks Cocoa API calls to verify
> that the calls are being made as expected without actually hitting
> Cocoa (which would cause all sorts of unwanted side-affects). My first
> question is about circumventing this read-only method restriction for
> my tests. Is it possible to (temporarily?) make PyObjC methods
> writable? Maybe through some hack that would only be activated as a
> pre-test setup task, allowing me to overwrite methods just during the
> testing phase?
>
> My second question is why such a restriction has been added? I'm not
> trying to start a flame war here, so please don't get that idea.
> Python is generally very liberal in what it allows one to do, even
> potentially damaging things such as shooting ones self in the foot:
>
> "Python culture tends towards "we're all consenting adults here". If  
> you
> attempt to shoot yourself in the foot, you should get some kind of
> warning that perhaps it is not what you really want to do, but if you
> insist, hey, go ahead, it's your foot!" [1]
>
> "...this is Python, where we vigorously defend the right to shoot
> ourselves in the foot." [2]
>
>  Is there any particular technical reason why PyObjC tries harder-
> than-normal-for-Python to protect me from doing things that most
> people probably do not want to do? Thanks in advance for taking time
> to answer my questions.
>
> ~ Daniel
>
> [0] http://www.mail-archive.com/mat...@li.../msg05035.html
> [1] http://mail.python.org/pipermail/tutor/2006-December/051569.html
> [2] http://www.gossamer-threads.com/lists/python/python/753888#753888
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited  
> time,
> vendors submitting new applications to BlackBerry App World(TM) will  
> have
> the opportunity to enter the BlackBerry Developer Challenge. See  
> full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] TypeError: cannot change a method

[Daniel M. <mil...@gm...>]

My testing framework for the app I've been developing (previously with  
PyObjC 1.4, now attempting to migrate to PyObjC 2) is giving lots of  
errors due to a restriction in PyObjC 2 that methods cannot be  
overwritten [0]. My testing framework mocks Cocoa API calls to verify  
that the calls are being made as expected without actually hitting  
Cocoa (which would cause all sorts of unwanted side-affects). My first  
question is about circumventing this read-only method restriction for  
my tests. Is it possible to (temporarily?) make PyObjC methods  
writable? Maybe through some hack that would only be activated as a  
pre-test setup task, allowing me to overwrite methods just during the  
testing phase?

My second question is why such a restriction has been added? I'm not  
trying to start a flame war here, so please don't get that idea.  
Python is generally very liberal in what it allows one to do, even  
potentially damaging things such as shooting ones self in the foot:

"Python culture tends towards "we're all consenting adults here". If you
attempt to shoot yourself in the foot, you should get some kind of
warning that perhaps it is not what you really want to do, but if you
insist, hey, go ahead, it's your foot!" [1]

"...this is Python, where we vigorously defend the right to shoot  
ourselves in the foot." [2]

  Is there any particular technical reason why PyObjC tries harder- 
than-normal-for-Python to protect me from doing things that most  
people probably do not want to do? Thanks in advance for taking time  
to answer my questions.

~ Daniel

[0] http://www.mail-archive.com/mat...@li.../msg05035.html
[1] http://mail.python.org/pipermail/tutor/2006-December/051569.html
[2] http://www.gossamer-threads.com/lists/python/python/753888#753888

Re: [Pyobjc-dev] NSError.localizedDescription() and Application Bundles

[Jean-Pierre <cho...@fr...>]

Le 14 juil. 09 à 15:45, Ronald Oussoren a écrit :

> The attached version of app delegate should work. You should not use  
> "decode('utf-8')" on unicode strings that you use with Cocoa API's.
>
> Ronald

Ok, I missed the fact that I had to convert the string only to print  
it to stdout, everything works fine now.
Thanks.

Best regards,

  - Jean-Pierre.

Re: [Pyobjc-dev] NSError.localizedDescription() and Application Bundles

[Jean-Pierre <cho...@fr...>]

Le 14 juil. 09 à 13:52, Ronald Oussoren a écrit :

> If you want to display the message in a window you should be able  
> use it as is, that is use  
> aTextField.setStringValue_(error.localizedDescription()) should work  
> just fine.

That's what I am trying to do indeed.

> If that doesn't work: could you please create a small program that  
> shows the problem (that is, a complete Xcode project)?
>
> Ronald

Here you are, a small Xcode 3 project with just a Text Label  
displaying the error message from an NSURLConnection failure.

  - Jean-Pierre.

Re: [Pyobjc-dev] NSError.localizedDescription() and Application Bundles

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

The attached version of app delegate should work. You should not use  
"decode('utf-8')" on unicode strings that you use with Cocoa API's.

Ronald

On 14 Jul, 2009, at 15:34, Jean-Pierre wrote:

> Le 14 juil. 09 à 13:52, Ronald Oussoren a écrit :
>
>> If you want to display the message in a window you should be able  
>> use it as is, that is use aTextField.setStringValue_ 
>> (error.localizedDescription()) should work just fine.
>
> That's what I am trying to do indeed.
>
>> If that doesn't work: could you please create a small program that  
>> shows the problem (that is, a complete Xcode project)?
>>
>> Ronald
>
> Here you are, a small Xcode 3 project with just a Text Label  
> displaying the error message from an NSURLConnection failure.
>
> - Jean-Pierre.
>
> <Localized.zip>
>
>

Re: [Pyobjc-dev] NSError.localizedDescription() and Application Bundles

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

On 14 Jul, 2009, at 9:53, Jean-Pierre wrote:

> Hi James,
>
> Le 11 juil. 09 à 12:45, James R Eagan a écrit :
>
>> Hi Jean-Pierre,
>>
>> The problem you're having is actually at the print statement at the  
>> very end.  The problem is that your sys.stdout.defaultencoding is  
>> usually set to US-ASCII rather than UTF8.  Unfortunately, the  
>> pythonic way of changing this encoding is via the site-config file,  
>> which you can't very well distribute with your python application.   
>> You can either restrict yourself to NSLog, which does properly  
>> output UTF-8 encoded unicode text, or you can manually encode your  
>> output via:
>>
>> 	print error.localizedDescription().encode('utf8')
>>
>> This approach is better suited if you can bury that deep inside  
>> your own logging-like mechanism, since you don't want a single  
>> missed ".encode('utf8')" to introduce a unicode bug to your code.
>
>
> I first thought my problem was solved, until I tried to concatenate  
> an utf8 string to the error message returned by the NSURLConnection  
> object, and I still have an UnicodeEncodeError exception.
> The problem seems to be that the localizedDescription() function  
> returns an ascii string containing utf-8 characters, instead of an  
> unicode one.
> The following code fails for localized error messages containing non  
> ascii characters, returned by the system:
>
> from Foundation import *
> url = NSURL.URLWithString_("http://invalid")
> request = NSURLRequest.requestWithURL_(url)
> (data, response, error)=  
> NSURLConnection.sendSynchronousRequest_returningResponse_error_ 
> (request)
> print u"error: " + error.localizedDescription().encode('utf-8')
>
> This also fails using the Terminal.
>
> I didn't dig yet into the PyObjc bridge, but could it be a problem  
> in the declared encoding for the NSError.localizedDescription()  
> function ?

The bridge is fine. There are three ways to fix the error:

1) Copy a sitecustomize.py file into your application bundle (if you  
use an Xcode project to build the application you can just add the  
file to the project, using py2app adding the file to the directory  
containing setup.py should be enough). That file should contain the  
following code:

     import sys
     sys.setdefaultencoding('utf-8')

2) Explicitly encode unicode strings to UTF-8 before printing them,  
your print statement would end up as:

      print (u"error:" + error.localizedDescription()).encode('utf-8')

3) Use NSLog instead of print to print debug information:


       NSLog("error: %@", error.localizedDescription())

NOTE: all code was typed in Mail.app, I haven't actually tested the  
code.

The problem you run into is that the python interpreter needs to  
convert a unicode string (either Python's unicode or NSString) to a  
sequence of bytes when you print it. The interpreter uses the default  
encoding for that. On the command-line the default encoding is  
'utf-8', but for some reason the default encoding in an app bundle is  
'ascii'. The latter encoding is a problem for you because the  
localizedDescription contains some characters that are not pure ASCII  
(most likely some fancy accent).

Ronald

>
> Thanks,
>
>  - Jean-Pierre.
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited  
> time,
> vendors submitting new applications to BlackBerry App World(TM) will  
> have
> the opportunity to enter the BlackBerry Developer Challenge. See  
> full prize
> details at: http://p.sf.net/sfu/Challenge_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] NSError.localizedDescription() and Application Bundles

[Jean-Pierre <cho...@fr...>]

Hi James,

Le 11 juil. 09 à 12:45, James R Eagan a écrit :

> Hi Jean-Pierre,
>
> The problem you're having is actually at the print statement at the  
> very end.  The problem is that your sys.stdout.defaultencoding is  
> usually set to US-ASCII rather than UTF8.  Unfortunately, the  
> pythonic way of changing this encoding is via the site-config file,  
> which you can't very well distribute with your python application.   
> You can either restrict yourself to NSLog, which does properly  
> output UTF-8 encoded unicode text, or you can manually encode your  
> output via:
>
> 	print error.localizedDescription().encode('utf8')
>
> This approach is better suited if you can bury that deep inside your  
> own logging-like mechanism, since you don't want a single missed  
> ".encode('utf8')" to introduce a unicode bug to your code.


I first thought my problem was solved, until I tried to concatenate an  
utf8 string to the error message returned by the NSURLConnection  
object, and I still have an UnicodeEncodeError exception.
The problem seems to be that the localizedDescription() function  
returns an ascii string containing utf-8 characters, instead of an  
unicode one.
The following code fails for localized error messages containing non  
ascii characters, returned by the system:

from Foundation import *
url = NSURL.URLWithString_("http://invalid")
request = NSURLRequest.requestWithURL_(url)
(data, response, error)=  
NSURLConnection.sendSynchronousRequest_returningResponse_error_(request)
print u"error: " + error.localizedDescription().encode('utf-8')

This also fails using the Terminal.

I didn't dig yet into the PyObjc bridge, but could it be a problem in  
the declared encoding for the NSError.localizedDescription() function ?

Thanks,

  - Jean-Pierre.

Re: [Pyobjc-dev] bus error in CGEventTapCreate... found the problem

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

It has taken me way to long to get around to this, but I finally  
commited a fix for this (revision 2266 and 2267). I still have to  
write a unittest that uses this API, but that can wait.

On 30 Jun, 2009, at 0:38, Ratko Jagodic wrote:

> I am trying to capture some mouse events using CGEventTapCreate and  
> I found out that the following causes a bus error every time:
>
> eventMask = (1<<kCGEventMouseMoved)
> eventTap = CGEventTapCreate(kCGSessionEventTap,  
> kCGHeadInsertEventTap, 0, eventMask, myCGEventCallback)
>
>
> I've traced it down to two problems, both in Quartz framework in  
> _callbacks.m in the function m_CGEventTapCreate:
>
> (1) the function expects 5 inputs and yet it tries to assign 6, last  
> one being "info"... which ends up being an uninitialized pointer.  
> That seems to cause a bus error further down when it tries to create  
> a tuple of "callback" and "info":
>                   PyObject* real_info = Py_BuildValue("OO",  
> callback, info);
> For my purposes, I just changed CGEventTapCreate to accept 6th input  
> when parsing arguments ("OOOOOO"), as it does in carbon. Not sure if  
> that's the right approach...

Adding an extra "O" was the correct fix here.

>
>
> (2) After fixing that, I encountered the next bus error with the  
> line further down in the same function:
>                   CFRelease(retval);
> I have no idea why this is crashing but I just commented it out for  
> now. I am assuming the worst that can happen is a memory leak and  
> considering that I call this only once, I didn't think it was a big  
> problem.

This should have been "if (result) { CFRelease(result); }".

Ronald

Re: [Pyobjc-dev] Bug in objc.synthesize

[Barry W. <bar...@gm...>]

+1!


On Mon, Jul 13, 2009 at 12:08 PM, Ronald Oussoren<ron...@ma...> wrote:
>
> W.r.t. objc.synthesize: I've been experimenting with Python's
> "property" function as a decorator. In Python 2.6 you can do something
> like this:
>
>
> class MyClass (object):
>
>      @property
>      def stringValue(self):
>           return self._value
>
>
>      @stringValue.setter
>      def setStringValue(self, value):
>            self._value = value
>
>
> It should be doable to do something simular for objc properties, such
> as:
>
>
> class MyController (NSObject):
>
>       stringValue = objc.property(rw=True, copy=True,
> ivar='_stringValue')
>
>       @stringValue.getter
>       def get(self):
>             return self._stringValue
>
> objc.property would define an ivar and getter and setter methods.
> Those methods would only be visible on the ObjC side, Python users
> always access the property using regular attribute access (the bridge
> would also ensure that the correct selectors are used for the accessor
> methods, regardless of the name used in the Python code).
>
> With some effort this could be extended to add other KVC/KVO related
> methods where needed, such as an objc.set_property that uses an
> NSMutableSet as the backing storage and ensure that manipulation of
> the set is done using the right KVC accessor methods.
>
> As sketched above this would need some support in the C code,
> simularly to how objc.ivar is handled.  I do think this could be a
> useful addition to PyObjC, and will try to find some time to write a
> proper specification and testsuite for this (followed by an
> implementation once we're happy about the first two).
>
> The scary future scenario for this is to expose existing ObjC
> properties using the same mechanism. This is "scary" because doing
> this is incompatible with existing code, and hence something I'd only
> implement once the basic support is stable (and included in a
> release). With some luck lib2to3 (the python2.x to 3.x translation
> tool) can be coaxed into translating the current syntax
> (aField.setStringValue_(v)) to the new syntax (aField.stringValue =
> v), but that's something I'll look into when its needed.
>
> Ronald
>
>
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Bug in objc.synthesize

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

W.r.t. objc.synthesize: I've been experimenting with Python's  
"property" function as a decorator. In Python 2.6 you can do something  
like this:


class MyClass (object):

      @property
      def stringValue(self):
           return self._value


      @stringValue.setter
      def setStringValue(self, value):
            self._value = value


It should be doable to do something simular for objc properties, such  
as:


class MyController (NSObject):

       stringValue = objc.property(rw=True, copy=True,  
ivar='_stringValue')

       @stringValue.getter
       def get(self):
             return self._stringValue

objc.property would define an ivar and getter and setter methods.  
Those methods would only be visible on the ObjC side, Python users  
always access the property using regular attribute access (the bridge  
would also ensure that the correct selectors are used for the accessor  
methods, regardless of the name used in the Python code).

With some effort this could be extended to add other KVC/KVO related  
methods where needed, such as an objc.set_property that uses an  
NSMutableSet as the backing storage and ensure that manipulation of  
the set is done using the right KVC accessor methods.

As sketched above this would need some support in the C code,  
simularly to how objc.ivar is handled.  I do think this could be a  
useful addition to PyObjC, and will try to find some time to write a  
proper specification and testsuite for this (followed by an  
implementation once we're happy about the first two).

The scary future scenario for this is to expose existing ObjC  
properties using the same mechanism. This is "scary" because doing  
this is incompatible with existing code, and hence something I'd only  
implement once the basic support is stable (and included in a  
release). With some luck lib2to3 (the python2.x to 3.x translation  
tool) can be coaxed into translating the current syntax  
(aField.setStringValue_(v)) to the new syntax (aField.stringValue =  
v), but that's something I'll look into when its needed.

Ronald

Re: [Pyobjc-dev] Bug in objc.synthesize

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

On 12 Jul, 2009, at 15:32, Dirk Stoop wrote:

> Hi all,
>
> We've been trying to use the objc.synthesize method in our project,
> but ran into some issues with it.
>
> After peeking in pyobjc-core for a bit, I think I might have found a
> bug.

Good catch. That's my punishment for not adding unittests for this  
feature...

>
> @Ronald: Please let me know if you want to hear about specific
> problems building on 10.5 right now, (or if you'd like me to submit
> patches with fixes for those problems, let me know how you prefer
> those patches to be formatted).

I'm interested in both bugreports and patches. I'd prefer patches in  
unified diff format ('diff -u', or the default output of 'svn diff').

My laptop is currently running a SL preview and I'm not testing on  
Leopard at the moment.

Ronald