pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] SQLite and PyObjC

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

On Sat, Jul 5, 2008 at 9:17 AM, John Velman <ve...@co...> wrote:
> Barry,
>
> Thanks for your response.  Of course, XCode is an IDE, I knew that, but in
> my haste  (in the words of H. Clinton) "I said something I knew not to be
> true".  I think I should have said something like "the Cocoa Core Data
> access to SQLite", which I have seen references to, and which, I presume,
> is an Objective C interface to SQLite.

No worries. Sorry if my answer came off as pedantic. CoreData is an
object graph management framework that _happens_ to use SQLite as one
of its backing stores. Apple has been very explicit in stating that
you shouldn't rely on the SQLite schema it uses for your own purposes;
it's an implementation detail and may change. As such, CoreData isn't
really appropriate for reading from arbitrary SQLite databases or as a
a way to write data to SQLite databases in a format that you control.
It is a really strong object graph management system and is worth the
time to grok it--just maybe not for this project.

>
> Anyhow, I am writing in PyObjC, so as you suggest, I'll use the python
> interface.  Have done C and C++ programming in the past, and suppose I
> could learn objective C, but don't want to.  I'm too old (my first
> programming language was Fortran II, followed by the assembly language FAP
> on an IBM 7090).

Given your experience, I would expect that you could pick up
Objective-C in less than a day. It's _much_ easier than C++ to grok
(being a much simpler language). If you've come across smalltalk at
all, you'll see many similarities.  Depending on the scope of the
project, you may find that the greater support provided by Xcode
(including gdb and code completion of user defined types) for
Objective-C vs. python outweighs the small cost of learning
Objective-C. Regardless, I would stick to one or the other, if you can
-- debugging across the language boundaries is not well supported by
the available tools.

>
> Thanks also for your advice on NSTableView.

You bet. Feel free to ping me offline if you need any pointers.

>
> Best,
>
> John V.
>
> On Sat, Jul 05, 2008 at 08:55:49AM -0700, Barry Wark wrote:
>> On Fri, Jul 4, 2008 at 10:16 AM, John Velman <ve...@co...> wrote:
>> > I'm hoping to write a Cocoa application with PyObjC that uses an sqlite
>> > database.  I will want browse views that show (multilple row) results
>> > of a query, as well as forms for data entry or editing, and output of
>> > reports in pdf format.  I need to develop on Leopard intel, and run on
>> > Tiger PPC. (I've looked at a couple of other approaches, but they each
>> > have problems, and I aesthetically like the idea of PyObjC with Cocoa.
>> > Thanks to the PyObjC developers!)
>> >
>> > I'm probably in way over my head.  But here are a couple of initial
>> > questions:
>> >
>> > 1.  Which is better to use for the sqlite interface, the Xcode
>> > interface to sqlite, or the Python interface?  If Xcode is better, how
>> > the heck can I find some documentation? Googling or searching in the
>> > developer documentation hasn't gotten me there yet.  Probably because I
>> > don't know the right search words. The amount of Apple documentation is
>> > enormous.
>> >
>> > Also, some documentation that won't be too hard to translate to use
>> > with PyObjC?
>>
>> When you say Xcode, I assume you mean writing the interface in C or
>> Objective-C. Xcode is an IDE, not a programming language or libaray, and
>> in fact supports development in several languages including Python. There
>> are C and Objective-C interfaces to SQLite, but if you intend to write
>> the rest of your application in Python, I would recommend sticking with
>> Python for the entire codebase.
>>
>> >
>> > 2. For display of tabular query results, is NSTableView the "best" way
>> > to go?
>>
>> Yes.
>>
>> I've had a quick scan of the "Understanding the NSTableView Class,
>> > and a look at one of the examples, and I'm overwhelmed.  I don't need
>> > to edit this in place.  One alternative would appear to be formatting
>> > into columns in Python, and use some form of NSBrowser or NSTextView.
>>
>> Have a look at the NSTableDataSource Protocol Reference. NSTableViews
>> keep a reference to a table data source. The data source supplies the
>> approrpirate table data when requested. NSTableViews can also be
>> populated via an NSArrayController using Cocoa's bindings technology.
>> Given your lack of familiarity with Cocoa technologies, I would recommend
>> the first (NSTableDataSource) approach.
>>
>> >
>> > I think I can handle input and edit forms.  If I can convince myself
>> > that I can handle using sqlite in the Model, and some form of browser
>> > as a view, I'll press on!
>> >
>> > Thanks,
>> >
>> > John Velman
>> >
>> > -------------------------------------------------------------------------
>> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> > Studies have shown that voting for your favorite open source project,
>> > along with a healthy diet, reduces your potential for chronic lameness
>> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> > _______________________________________________ Pyobjc-dev mailing list
>> > Pyo...@li...
>> > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>> >
>

Re: [Pyobjc-dev] SQLite and PyObjC

[Samantha A. <sja...@ma...>]

On Jul 5, 2008, at 9:17 AM, John Velman wrote:

> Barry,
>
> Thanks for your response.  Of course, XCode is an IDE, I knew that,  
> but in
> my haste  (in the words of H. Clinton) "I said something I knew not  
> to be
> true".  I think I should have said something like "the Cocoa Core Data
> access to SQLite", which I have seen references to, and which, I  
> presume,
> is an Objective C interface to SQLite.
>
> Anyhow, I am writing in PyObjC, so as you suggest, I'll use the python
> interface.

Core Data is a general "document" / application data store Cocoa  
framework.  It covers both flat flie, XML and sqlite stores.   Its API  
is the same on all.  Among other things this means that some  
capabilities of a RDBMS are not exposed by Core Data.  Core Data is  
more or less an ORM or rather an OSM where the S is more generic store  
than just relational.   As such it imposes its own layout to the  
underlying sqlite tables to support a subset of object persistence.    
I would not recommend that you programs attempt to grok and correctly  
handle that layout directly.  Instead for a Core Data database you  
should use the Core Data framework from pyobjc.   There are some  
shortcuts that get around some of the Xcode and application centric  
docs on Core Data.  For one thing there is a "MOM" file for any Core  
Data database and Core Data APIs that you can use to dynamically read  
a MOM, parse out the types of Entities and Relationships and then go  
from there to read any data in the Core Data db and show it any way  
you want.

Hope that helps.

- samantha



> Have done C and C++ programming in the past, and suppose I
> could learn objective C, but don't want to.  I'm too old (my first
> programming language was Fortran II, followed by the assembly  
> language FAP
> on an IBM 7090).
>
> Thanks also for your advice on NSTableView.
>
> Best,
>
> John V.
>
> On Sat, Jul 05, 2008 at 08:55:49AM -0700, Barry Wark wrote:
>> On Fri, Jul 4, 2008 at 10:16 AM, John Velman <ve...@co...> wrote:
>>> I'm hoping to write a Cocoa application with PyObjC that uses an  
>>> sqlite
>>> database.  I will want browse views that show (multilple row)  
>>> results
>>> of a query, as well as forms for data entry or editing, and output  
>>> of
>>> reports in pdf format.  I need to develop on Leopard intel, and  
>>> run on
>>> Tiger PPC. (I've looked at a couple of other approaches, but they  
>>> each
>>> have problems, and I aesthetically like the idea of PyObjC with  
>>> Cocoa.
>>> Thanks to the PyObjC developers!)
>>>
>>> I'm probably in way over my head.  But here are a couple of initial
>>> questions:
>>>
>>> 1.  Which is better to use for the sqlite interface, the Xcode
>>> interface to sqlite, or the Python interface?  If Xcode is better,  
>>> how
>>> the heck can I find some documentation? Googling or searching in the
>>> developer documentation hasn't gotten me there yet.  Probably  
>>> because I
>>> don't know the right search words. The amount of Apple  
>>> documentation is
>>> enormous.
>>>
>>> Also, some documentation that won't be too hard to translate to use
>>> with PyObjC?
>>
>> When you say Xcode, I assume you mean writing the interface in C or
>> Objective-C. Xcode is an IDE, not a programming language or  
>> libaray, and
>> in fact supports development in several languages including Python.  
>> There
>> are C and Objective-C interfaces to SQLite, but if you intend to  
>> write
>> the rest of your application in Python, I would recommend sticking  
>> with
>> Python for the entire codebase.
>>
>>>
>>> 2. For display of tabular query results, is NSTableView the "best"  
>>> way
>>> to go?
>>
>> Yes.
>>
>> I've had a quick scan of the "Understanding the NSTableView Class,
>>> and a look at one of the examples, and I'm overwhelmed.  I don't  
>>> need
>>> to edit this in place.  One alternative would appear to be  
>>> formatting
>>> into columns in Python, and use some form of NSBrowser or  
>>> NSTextView.
>>
>> Have a look at the NSTableDataSource Protocol Reference. NSTableViews
>> keep a reference to a table data source. The data source supplies the
>> approrpirate table data when requested. NSTableViews can also be
>> populated via an NSArrayController using Cocoa's bindings technology.
>> Given your lack of familiarity with Cocoa technologies, I would  
>> recommend
>> the first (NSTableDataSource) approach.
>>
>>>
>>> I think I can handle input and edit forms.  If I can convince myself
>>> that I can handle using sqlite in the Model, and some form of  
>>> browser
>>> as a view, I'll press on!
>>>
>>> Thanks,
>>>
>>> John Velman
>>>
>>> -------------------------------------------------------------------------
>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>> Studies have shown that voting for your favorite open source  
>>> project,
>>> along with a healthy diet, reduces your potential for chronic  
>>> lameness
>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>> _______________________________________________ Pyobjc-dev mailing  
>>> list
>>> Pyo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] SQLite and PyObjC

[John V. <ve...@co...>]

Barry,

Thanks for your response.  Of course, XCode is an IDE, I knew that, but in
my haste  (in the words of H. Clinton) "I said something I knew not to be
true".  I think I should have said something like "the Cocoa Core Data
access to SQLite", which I have seen references to, and which, I presume,
is an Objective C interface to SQLite.

Anyhow, I am writing in PyObjC, so as you suggest, I'll use the python
interface.  Have done C and C++ programming in the past, and suppose I
could learn objective C, but don't want to.  I'm too old (my first
programming language was Fortran II, followed by the assembly language FAP
on an IBM 7090).

Thanks also for your advice on NSTableView.

Best,

John V.

On Sat, Jul 05, 2008 at 08:55:49AM -0700, Barry Wark wrote:
> On Fri, Jul 4, 2008 at 10:16 AM, John Velman <ve...@co...> wrote:
> > I'm hoping to write a Cocoa application with PyObjC that uses an sqlite
> > database.  I will want browse views that show (multilple row) results
> > of a query, as well as forms for data entry or editing, and output of
> > reports in pdf format.  I need to develop on Leopard intel, and run on
> > Tiger PPC. (I've looked at a couple of other approaches, but they each
> > have problems, and I aesthetically like the idea of PyObjC with Cocoa.
> > Thanks to the PyObjC developers!)
> >
> > I'm probably in way over my head.  But here are a couple of initial
> > questions:
> >
> > 1.  Which is better to use for the sqlite interface, the Xcode
> > interface to sqlite, or the Python interface?  If Xcode is better, how
> > the heck can I find some documentation? Googling or searching in the
> > developer documentation hasn't gotten me there yet.  Probably because I
> > don't know the right search words. The amount of Apple documentation is
> > enormous.
> >
> > Also, some documentation that won't be too hard to translate to use
> > with PyObjC?
> 
> When you say Xcode, I assume you mean writing the interface in C or
> Objective-C. Xcode is an IDE, not a programming language or libaray, and
> in fact supports development in several languages including Python. There
> are C and Objective-C interfaces to SQLite, but if you intend to write
> the rest of your application in Python, I would recommend sticking with
> Python for the entire codebase.
> 
> >
> > 2. For display of tabular query results, is NSTableView the "best" way
> > to go?
> 
> Yes.
> 
> I've had a quick scan of the "Understanding the NSTableView Class,
> > and a look at one of the examples, and I'm overwhelmed.  I don't need
> > to edit this in place.  One alternative would appear to be formatting
> > into columns in Python, and use some form of NSBrowser or NSTextView.
> 
> Have a look at the NSTableDataSource Protocol Reference. NSTableViews
> keep a reference to a table data source. The data source supplies the
> approrpirate table data when requested. NSTableViews can also be
> populated via an NSArrayController using Cocoa's bindings technology.
> Given your lack of familiarity with Cocoa technologies, I would recommend
> the first (NSTableDataSource) approach.
> 
> >
> > I think I can handle input and edit forms.  If I can convince myself
> > that I can handle using sqlite in the Model, and some form of browser
> > as a view, I'll press on!
> >
> > Thanks,
> >
> > John Velman
> >
> > -------------------------------------------------------------------------
> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> > Studies have shown that voting for your favorite open source project,
> > along with a healthy diet, reduces your potential for chronic lameness
> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> > _______________________________________________ Pyobjc-dev mailing list
> > Pyo...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> >

[Pyobjc-dev] SQLite and PyObjC

[John V. <ve...@co...>]

I'm hoping to write a Cocoa application with PyObjC that uses an sqlite
database.  I will want browse views that show (multilple row) results of a
query, as well as forms for data entry or editing, and output of reports in
pdf format.  I need to develop on Leopard intel, and run on Tiger PPC.
(I've looked at a couple of other approaches, but they each have problems,
and I aesthetically like the idea of PyObjC with Cocoa.  Thanks to the
PyObjC developers!)

I'm probably in way over my head.  But here are a couple of initial
questions:

1.  Which is better to use for the sqlite interface, the Xcode interface to
sqlite, or the Python interface?  If Xcode is better, how the heck can I
find some documentation? Googling or searching in the developer
documentation hasn't gotten me there yet.  Probably because I don't know
the right search words. The amount of Apple documentation is enormous.

Also, some documentation that won't be too hard to translate to use with
PyObjC?

2. For display of tabular query results, is NSTableView the "best" way to
go?   I've had a quick scan of the "Understanding the NSTableView Class,
and a look at one of the examples, and I'm overwhelmed.  I don't need to
edit this in place.  One alternative would appear to be formatting into
columns in Python, and use some form of NSBrowser or NSTextView.

I think I can handle input and edit forms.  If I can convince myself that I
can handle using sqlite in the Model, and some form of browser as a view,
I'll press on!

Thanks,

John Velman

[Pyobjc-dev] Starting up pyobjc from a cocoa bundle, nsthreads not firing correctly

[Gus M. <gus...@gm...>]

I've got a cocoa bundle that I load into my app, which then starts up
python using the same technique a standard 10.5 cocoa-python
application uses in main.m.  The only difference is that my main.py
file doesn't call AppHelper.runEventLoop() because the main event loop
has already been started by the host (cocoa) application.

Everything works great, until I try and use NSThread's
detachNewThreadSelector_toTarget_withObject_ from within python.  It
seems that some sort of runloop needs to be setup or something, but
I'm really not sure that that would be.

If I call NSApp().run() right after I create my thread, then it fires
off and does its work- but then that leaves the rest of my application
in a weird state.  If I click outside my application and then back,
then the thread seems to move forward just a little bit.

Any ideas?  I've also gone the pure python approach to creating the
bundle- and nsthreads work great with this tequnique, but it creates a
massive bundle (16MB!) and I'd rather not bloat my app (vs 84KB).

Here's what the stack for the thread looks like when it's stalled:

Thread 23 (process 27704 thread 0x680f):
#0  0x94c1168e in __semwait_signal ()
#1  0x94c3c986 in _pthread_cond_wait ()
#2  0x94c3c36d in pthread_cond_wait$UNIX2003 ()
#3  0x01d5c74c in PyThread_acquire_lock ()
#4  0x01d336cf in PyEval_RestoreThread ()
#5  0x14c1885e in PyObjCFFI_Caller ()
#6  0x14c2fb63 in PyObjCSelector_GetMetadata ()
#7  0x01ccad3d in PyObject_Call ()
#8  0x01d38b1a in PyEval_EvalFrameEx ()
#9  0x01d3a45b in PyEval_EvalCodeEx ()
#10 0x01ce4c27 in PyFunction_SetClosure ()
#11 0x01ccad3d in PyObject_Call ()
#12 0x14c30700 in PyObjCSelector_NewNative ()
#13 0x01ccad3d in PyObject_Call ()
#14 0x01d38b1a in PyEval_EvalFrameEx ()
#15 0x01d3a45b in PyEval_EvalCodeEx ()
#16 0x01ce4c27 in PyFunction_SetClosure ()
#17 0x01ccad3d in PyObject_Call ()
#18 0x14c126d5 in signature_to_ffi_return_type ()
#19 0x14c01a92 in ffi_prep_cif_machdep ()
#20 0x90210f1d in -[NSThread main] ()
#21 0x90210ac4 in __NSThread__main__ ()
#22 0x94c3b6f5 in _pthread_start ()
#23 0x94c3b5b2 in thread_start ()

thanks,

-gus

[Pyobjc-dev] Different result between PyObjC 1.x and 2.x when calling NSIndexSet. getIndexes_maxCount_inIndexRange_

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

Greetings,

# -- [begin snippet] -------------------------------------------------

import sys
print "PYTHON VERSION:"
print sys.version

import objc
print "PYOBJC VERSION:"
print objc.__version__

from Foundation import NSMutableIndexSet, NSRange
s = NSMutableIndexSet.alloc().init()
for i in range(1,16,2):
     s.addIndex_(i)

print "NSINDEXSET CALL result:"
if objc.__version__.startswith('1'):
     print s.getIndexes_maxCount_inIndexRange_(4, NSRange(0,4))
else:
     print s.getIndexes_maxCount_inIndexRange_(None, 4, NSRange(0,4))

# -- [end snippet] --------------------------------------------------

Here are the results I get...

...on OS X 10.4 using a custom built PyObjC 1.4:

PYTHON VERSION:
2.4.4 (#1, Oct 18 2006, 10:34:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)]
PYOBJC VERSION:
1.4.1a0
NSINDEXSET CALL result:
(4, (1, 3, 5, 7), <Foundation.NSRange location=0 length=4>)

...on OS X 10.5 with the default PyObjC 2.0.1:

PYTHON VERSION:
2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)]
PYOBJC VERSION:
2.0.1
NSINDEXSET CALL result:
(2, ())

...on OS X 10.5 with custom built Python 2.5 and PyObjC 2.1:

PYTHON VERSION:
2.5 (r25:51908, Apr 15 2008, 08:22:04)
[GCC 4.0.1 (Apple Inc. build 5478)]
PYOBJC VERSION:
2.1a0
NSINDEXSET CALL result:
(2, ())


Any idea what happens here ? Since PyObjC 2.x is not backward  
compatible with OS X 10.4 and PyObjC 1.4 does not compile under OS X  
10.5 I have to juggle between the two to work on my app and if there  
are semantic changes for some calls in addition to the version  
incompatibilities, it's quickly going to get painful... :)

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

[Pyobjc-dev] WiiRemote.framework successfully wrapped!

[Ian J. <enj...@gm...>]

After a grueling Saturday coding session, I have finally placed the last
puzzle piece for wrapping the DarwiinRemote WiiRemote.framework.
You can see the resulting code at
http://enja.org/enjapen
(check out WiiMote.py for the informal_protocol)

I want to mention that I think this fix should be documented, as I could
find NO example anywhere in the docs or on any blog on the internet. The
main hang up was wrapping an interface method for the WiiRemoteDelegate:

> - (void) rawIRData: (IRData[4]) irData;
>
Where the IRData is a struct defined as:

typedef struct {
> int x, y, s;
> } IRData;
>
with IRData defined in python like:

IRData = objc.createStructType("IRData", "iii", ["x", "y", "s"])


So our python function needs to accept an array of 4 IRData structs.
The signature for this needs to be:

v@:n^[4{IRData=iii}]
>
Which we define in the informal_protocol (or with python 2.4/2.5 using
@objc.selector(...) )
The problem is, nowhere is it documented that "n^" is necessary. I figured
it out by dumb luck and a slightly intuitive (but probably wrong) feeling
about arrays being pointers in C (true in objective-c?)
This page gave me good info:
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_13_section_9.html
but little did I know what a "method encoding" was. I guess "n" means this
object is given as input.

I'm only guessing, but if I were trying to wrap a function that returned an
array (which you can't do, just like C, I guess you would get a pointer?)
you would have to use "o^"?

I know part of this is my fault for being new to Objective-C and having a
shallow understanding of C, but I'm not the only one who could have been
served by one example of wrapping a function that has a complex data type. I
hope this helps others who might have wrestled with this!

I want to extend a BIG thanks to the pyobjc team for letting me stay in
python paradise when making apps on the mac :)


-- 
Ian Johnson

Ignorance is Piss.

Re: [Pyobjc-dev] Xcode 3 Python NSView subclass template

[s s <li...@in...>]

You have to import your StretchView module into main.py for it to be  
available.

A simple:

import StretchView

Right after where the comment:
# import modules containing classes required to start application and  
load MainMenu.nib

and you should be all set.

Remember to do the same with any other Python modules you need to be  
available.

S

On Jun 12, 2008, at 8:47 AM, Johannes Scholz wrote:

> Pyobjc newbie here. Im trying to draw on a custom view. Here's what  
> i do:
>
> Create Cocoa python application
> Create Python NSView subclass (I named it StretchView)
>
> Go to interface builder, add a custom view, change its class to  
> StretchView in the identify inspector.
>
> Now when i run the application i get this errors in the debugger  
> console:
>
> Unknown class 'StretchView' in nib file, using `(null)' instead.
> Unknown class `StretchView' in nib file, using `NSView' instead.
>
> As a result, the StrechView's drawRect_() method never gets called.
>
> Doing the same steps, but using Cocoa Application and Objective-C  
> NSView subclass results in expected behaviour.
>
> I am using the pyobcj version, that shipped with Leopard.
>
> Any hints/advices?
>
>
> Johannes Scholz
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Xcode 3 Python NSView subclass template

[Johannes S. <lgo...@go...>]

Pyobjc newbie here. Im trying to draw on a custom view. Here's what i  
do:

Create Cocoa python application
Create Python NSView subclass (I named it StretchView)

Go to interface builder, add a custom view, change its class to  
StretchView in the identify inspector.

Now when i run the application i get this errors in the debugger  
console:

Unknown class 'StretchView' in nib file, using `(null)' instead.
Unknown class `StretchView' in nib file, using `NSView' instead.

As a result, the StrechView's drawRect_() method never gets called.

Doing the same steps, but using Cocoa Application and Objective-C  
NSView subclass results in expected behaviour.

I am using the pyobcj version, that shipped with Leopard.

Any hints/advices?


Johannes Scholz

[Pyobjc-dev] Core Data vs other ORMs

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

Hello,

This is not directly related to PyObjC, but I guess people who have  
experience of both Core Data and other Python ORMs would be hard to  
come by in other lists...

So, I've been toying with Core Data, doing mostly standard stuff  
(displaying in a table, add/edit/delete etc). I've found that while  
the automatic setup and the powerful bindings are helpful for a first  
cut, when you try to use them through code and for more advanced  
stuff, the syntax gets wordy and obscure very fast.

I was wondering if I could get away from all this by just using  
Django's ORM (or anything similar). The only downside is that I would  
have to provide my own wrappers for bindings, but since this is so  
simple (once you know what to expect), it's not that big a hassle.

And of course, I'd have to do the initial setup by myself (perhaps  
jump through a few hoops to initialize django, but this is a one-off  
cost).

Any thoughts?

Regards,
--
Orestis Markou
or...@or...
http://orestis.gr/

Re: [Pyobjc-dev] Is there still a good reason for separate macpythonand pyobjc mailing lists?

[Jay F. \(saurik\) <sa...@sa...>]

Personally, I have no interest in any issues relating to Python that don't 
have to do with its integration with Objective-C. In fact, until this e-mail 
I had never heard of the PythonMac list, and now that I have I went and took 
a look at it and it doesn't seem particularly interesting to me: I don't 
actually own a Mac and use PyObjC purely on my iPhone (which means any and 
all topics about Cocoa are lost on me), I've never used Xcode and don't see 
why I would want to, and I have no interest in AppleScript or tk.

I'm almost certainly in the minority, though. (I'm a programming languages 
researcher who focuses on language interop, have written a similar library 
for Java, and maintain a port of PyObjC to the iPhone.)

Out of curiosity, why are you interested in merging the mailing lists? There 
seems to be hardly any converstions (pretty much no conversations, really: 
last one was in January) directly about PyObjC on PythonMac.

Sincerely,
Jay Freeman (saurik)
sa...@sa...
http://www.saurik.com/

----- Original Message ----- 
From: "Jack Jansen" <Jac...@cw...>
To: <pyo...@li...>; "PythonMac mac" 
<pyt...@py...>
Sent: Wednesday, May 28, 2008 2:03 PM
Subject: [Pyobjc-dev] Is there still a good reason for separate macpythonand 
pyobjc mailing lists?


> Now that pyobjc is a first-class citizen of MacPython, is there any
> reason to maintain two mailing lists? Are there any people who are on
> one of the lists and not the other?
> --
> Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma
> Goldman
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> 

[Pyobjc-dev] [ pyobjc-Bugs-1982510 ] Typos in watcher.py example

[SourceForge.net <no...@so...>]

Bugs item #1982510, was opened at 2008-06-02 13:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=1982510&group_id=14534

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: James Snyder (jsnyder)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typos in watcher.py example

Initial Comment:
I see this in trunk and in the released version with leopard:
/Developer/Examples/Python/PyObjC/FSEvents/watcher.py

134c134
< def fsevents_callback(streamRef, clientInfo, numEvents, eventPaths, eventMarsks, eventIDs):
---
> def fsevents_callback(streamRef, clientInfo, numEvents, eventPaths, eventMasks, eventIDs):
167c167
<             print "New total size: %d (change made to %s) for path: %s"(
---
>             print "New total size: %d (change made to %s) for path: %s"%(


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=1982510&group_id=14534

Re: [Pyobjc-dev] Possible memory leak passing Cocoa NSData or NSDictionary instances from python plugin to Objective-C (non-GC) code?

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

Done. Thank you for taking a look at this. Although I can't confirm
this, I suspect the memory leak appeared when we moved from 10.4 to
10.5 and concurently from pyobjc 1.4 to 2.0 (I know that there was no
memory leak on 10.4 with pyobjc 1.4).

barry

On Sun, Jun 1, 2008 at 10:44 PM, Ronald Oussoren <ron...@ma...> wrote:
> Barry,
>
> Could you please file a bug for this on SourceForge when you don't find a
> solution? I don't think I'll be able to look into this this week and will be
> traveling after that.
>
> Ronald
>
> On 2 Jun, 2008, at 3:57, Barry Wark wrote:
>
>> Hi all,
>>
>> I have an Objective-C application that uses plugins to generate some
>> data. THe app is compiled against the 10.5 SDK and is running on
>> Leopard (with the system python and pyobjc). The data is returned as
>> NSData* instances and its parameters as an NSDictionary instance, as
>> defined by the app's plugin formal protocol. Some of our plugins are
>> written in Objective-C and some in Python ("compiled" with py2app).
>> The app is compiled against the 10.5 SDK and is running on Leopard
>> (with the system python and pyobjc).  I've noticed that there's a
>> signficant apparent memory leak in the application when using
>> Python-based plugins, but not when using the Objective-C based
>> plugins. Therefore, I've concluded that the issue is with the plugins,
>> not the main application. I've written a small demo app that exhibits
>> the apparent leak behavior.
>>
>> The relevant sections of the Objective-C side are:
>> - (IBAction)getDataFromPython:(id)sender {
>>   id<TestProtocol> plugin = [[pluginClass alloc ] init];
>>   NSAssert([plugin conformsToProtocol:@protocol(TestProtocol)],
>>            @"Plugin not id<TestProtocol>.");
>>
>>   for(NSUInteger i=0; i<self.nReps; i++) {
>>       NSData *d = [plugin getNumpyData];
>>   }
>>
>>   [plugin release];
>> }
>>
>> - (IBAction)getDictFromPython:(id)sender {
>>   id<TestProtocol> plugin = [[pluginClass alloc ] init];
>>   NSAssert([plugin conformsToProtocol:@protocol(TestProtocol)],
>>            @"Plugin not id<TestProtocol>.");
>>
>>
>>   for(NSUInteger i=0; i<self.nReps; i++) {
>>       NSDictionary *d = [plugin getDictionary];
>>   }
>>
>>   [plugin release];
>> }
>>
>> and the corresponding "getNumpyData" and "getDictFromPython" methods
>> in the plugin are:
>>
>>   import numpy as np
>>
>>   def getNumpyData(self):
>>       return np.zeros(10000)
>>
>>   def getDictionary(self):
>>       return NSDictionary.dictionaryWithObjectsAndKeys_('abc',
>>                                       'string',
>>                                       pkl.dumps(np.zeros(1000)),
>>                                       'pkl_string',
>>                                       None)
>>
>>
>> Investigation with ObjectAlloc in Instruments suggests that the
>> instances of "GeneralBlock" in the first case (getNumpyData) and
>> "GeneralBlock" and CFDictionary in the second (getDictionary) case are
>> created but not released, even after the event loop (and associated
>> NSAutoreleasePool.drain) are completed.
>>
>> Is it possible that this is a memory leak caused by improper reference
>> management across the Objective-C/python bridge?
>>
>> I am happy to file a bug in Apple's radar or the pyobjc sourceforge
>> project, but I'm not sure 1) if this is a bug or my fault and 2) where
>> the bug is most useful...
>>
>> Would anyone be able to help me?
>>
>> I've made a zip file with the Xcode project (app and plugin). The
>> project folder also contains an Instruments file that will drive and
>> record the behavior I describe above. The zip file is available from
>> http://rieke-server.physiol.washington.edu/~barry/python/PyObjCTest.zip
>>
>> Any help would be greatly appreciated!
>>
>> Thanks!
>>
>> Barry
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

[Pyobjc-dev] [ pyobjc-Bugs-1982104 ] Possible memory leak returnig NSData or NSDictionary

[SourceForge.net <no...@so...>]

Bugs item #1982104, was opened at 2008-06-02 06:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=1982104&group_id=14534

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Barry Wark (barrywark)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible memory leak returnig NSData or NSDictionary

Initial Comment:
I have an Objective-C application that uses plugins to generate some
data. THe app is compiled against the 10.5 SDK and is running on
Leopard (with the system python and pyobjc). The data is returned as
NSData instances and its parameters as an NSDictionary instance, as
defined by the app's plugin formal protocol. Some of our plugins are
written in Objective-C and some in Python ("compiled" with py2app).
The app is compiled against the 10.5 SDK and is running on Leopard
(with the system python and pyobjc).  I've noticed that there's a
signficant apparent memory leak in the application when using
Python-based plugins, but not when using the Objective-C based
plugins. Therefore, I've concluded that the issue is with the plugins,
not the main application. I've written a small demo app that exhibits
the apparent leak behavior.

The relevant sections of the Objective-C side are:
- (IBAction)getDataFromPython:(id)sender {
   id<TestProtocol> plugin = [[pluginClass alloc ] init];
   NSAssert([plugin conformsToProtocol:@protocol(TestProtocol)],
            @"Plugin not id<TestProtocol>.");

   for(NSUInteger i=0; i<self.nReps; i++) {
       NSData *d = [plugin getNumpyData];
   }

   [plugin release];
}

- (IBAction)getDictFromPython:(id)sender {
   id<TestProtocol> plugin = [[pluginClass alloc ] init];
   NSAssert([plugin conformsToProtocol:@protocol(TestProtocol)],
            @"Plugin not id<TestProtocol>.");


   for(NSUInteger i=0; i<self.nReps; i++) {
       NSDictionary *d = [plugin getDictionary];
   }

   [plugin release];
}

and the corresponding "getNumpyData" and "getDictFromPython" methods
in the plugin are:

   import numpy as np

   def getNumpyData(self):
       return np.zeros(10000)

   def getDictionary(self):
       return NSDictionary.dictionaryWithObjectsAndKeys_('abc',
                                       'string',
                                       pkl.dumps(np.zeros(1000)),
                                       'pkl_string',
                                       None)


 Investigation with ObjectAlloc in Instruments suggests that the
instances of "GeneralBlock" in the first case (getNumpyData) and
"GeneralBlock" and CFDictionary in the second (getDictionary) case are
created but not released, even after the event loop (and associated
NSAutoreleasePool.drain) are completed. This is not the case with an equivalent Objective-C plugin.

Is it possible that this is a memory leak caused by improper reference
management across the Objective-C/python bridge?


I've included a zip file with the Xcode project (app and plugins (python and objective-c). The
project folder also contains an Instruments file that will drive and
record the behavior I describe above.

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=1982104&group_id=14534

Re: [Pyobjc-dev] Possible memory leak passing Cocoa NSData or NSDictionary instances from python plugin to Objective-C (non-GC) code?

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

Barry,

Could you please file a bug for this on SourceForge when you don't  
find a solution? I don't think I'll be able to look into this this  
week and will be traveling after that.

Ronald

On 2 Jun, 2008, at 3:57, Barry Wark wrote:

> Hi all,
>
> I have an Objective-C application that uses plugins to generate some
> data. THe app is compiled against the 10.5 SDK and is running on
> Leopard (with the system python and pyobjc). The data is returned as
> NSData* instances and its parameters as an NSDictionary instance, as
> defined by the app's plugin formal protocol. Some of our plugins are
> written in Objective-C and some in Python ("compiled" with py2app).
> The app is compiled against the 10.5 SDK and is running on Leopard
> (with the system python and pyobjc).  I've noticed that there's a
> signficant apparent memory leak in the application when using
> Python-based plugins, but not when using the Objective-C based
> plugins. Therefore, I've concluded that the issue is with the plugins,
> not the main application. I've written a small demo app that exhibits
> the apparent leak behavior.
>
> The relevant sections of the Objective-C side are:
> - (IBAction)getDataFromPython:(id)sender {
>    id<TestProtocol> plugin = [[pluginClass alloc ] init];
>    NSAssert([plugin conformsToProtocol:@protocol(TestProtocol)],
>             @"Plugin not id<TestProtocol>.");
>
>    for(NSUInteger i=0; i<self.nReps; i++) {
>        NSData *d = [plugin getNumpyData];
>    }
>
>    [plugin release];
> }
>
> - (IBAction)getDictFromPython:(id)sender {
>    id<TestProtocol> plugin = [[pluginClass alloc ] init];
>    NSAssert([plugin conformsToProtocol:@protocol(TestProtocol)],
>             @"Plugin not id<TestProtocol>.");
>
>
>    for(NSUInteger i=0; i<self.nReps; i++) {
>        NSDictionary *d = [plugin getDictionary];
>    }
>
>    [plugin release];
> }
>
> and the corresponding "getNumpyData" and "getDictFromPython" methods
> in the plugin are:
>
>    import numpy as np
>
>    def getNumpyData(self):
>        return np.zeros(10000)
>
>    def getDictionary(self):
>        return NSDictionary.dictionaryWithObjectsAndKeys_('abc',
>                                        'string',
>                                        pkl.dumps(np.zeros(1000)),
>                                        'pkl_string',
>                                        None)
>
>
> Investigation with ObjectAlloc in Instruments suggests that the
> instances of "GeneralBlock" in the first case (getNumpyData) and
> "GeneralBlock" and CFDictionary in the second (getDictionary) case are
> created but not released, even after the event loop (and associated
> NSAutoreleasePool.drain) are completed.
>
> Is it possible that this is a memory leak caused by improper reference
> management across the Objective-C/python bridge?
>
> I am happy to file a bug in Apple's radar or the pyobjc sourceforge
> project, but I'm not sure 1) if this is a bug or my fault and 2) where
> the bug is most useful...
>
> Would anyone be able to help me?
>
> I've made a zip file with the Xcode project (app and plugin). The
> project folder also contains an Instruments file that will drive and
> record the behavior I describe above. The zip file is available from
> http://rieke-server.physiol.washington.edu/~barry/python/ 
> PyObjCTest.zip
>
> Any help would be greatly appreciated!
>
> Thanks!
>
> Barry
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] NSDate, datetime.datetime and Bindings

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

On 1 Jun, 2008, at 22:50, Orestis Markou wrote:

> I have an NSMutableArray that has dict/NSMutableDict entries, and is
> binding to a table view via  an Array Controller.
>
> If a column has a date formatter, then datetime.datetime objects
> cannot be used. I get:
>
> Cocoa Bindings: Cannot create date from object datetime.datetime(2008,
> 6, 1, 21, 40, 43, 131070) of class OC_PythonObject
>
> a = NSMutableArray.alloc().init()
> a.append(dict(date=datetime.today()))
> a.append(dict(date=NSDate.date()))
>
> The first doesn't work, the second does. I can see that there is a
> proxy for dates in objc/Modules, but perhaps it's not included in the
> Leopard distribution?

That's right. I added that after Leopard was released.

>
>
> Is there an ETA for an updated version of pyobjc?

Somewhere before 2100 CE?  That is, no there is no ETA. I'm working on  
PyObjC in my spare time and don't have much of that at the moment.

Ronald

Re: [Pyobjc-dev] Key Value Observing of lists?

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

On 1 Jun, 2008, at 23:25, Orestis Markou wrote:
>
> Notice how there are three objects in there, but only one complaint.  
> So I guess Python objects don't play well with KVO at the moment,  
> and I should use NSObjects where possible, right?

That's basicly right.  I don't really like this, but that's the best  
we can do without patching the Python interpreter.

Ronald

Re: [Pyobjc-dev] Key Value Observing of lists?

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

On 1 Jun, 2008, at 21:43, Orestis Markou wrote:

> Hi,
>
> I've just stumbled on this again (I'll be writing a short blog post  
> about it when my host is back online). I think I'm a bit confused...
>
>>> Hi,
>>>
>>> I'm trying to bound an NSTableView to a list using an array
>>> controller. This works fine, as long as I don't mutate the list
>>> (list.append, for example).
>>
>> I'm pretty sure this bit is documented somewhere.  It is  
>> technically impossible to make PyObjC do the right thing here  
>> without patching the Python interpreter.
>
> Just to make things very clear, is this not possible even if using a  
> Cocoa collection like NSMutableArray and calling Cocoa methods on it  
> (insertObject_atIndex_)?

No. It is impossible to make PyObjC do the right thing for "pure"  
Python types, like list, dict, and object. The usual magic works just  
fine for subclasses of NSObject.  It works even better than in ObjC:  
NSObject.__setattr__ will do the KVO dance for you, so you can code  
like this and still use KVO:

	class MyClass  (NSObject):
		def doSomething(self):
			self.foo = '42'
			self.bar = 1.2

When you call doSomething PyObjC will automaticly emit willChange/ 
didChange events for the keys 'foo' and 'bar'.
>
>
> So basically, _every_ method that mutates something that needs to be  
> observable must be surround with "willChangeValueForKey_" and  
> "didChangeValueForKey_", right?

Only when you mutate an object without a native Objective-C  
representation, because it is impossible to intercept all mutations of  
a Python object without cooperation of that object.

>
>
> Is there any shortcut for doing this?

Use NSMutableArray instead of list, and likewise for other  
datastructures.

Ronald

>
>
> Regards,
> Orestis

Re: [Pyobjc-dev] Possible memory leak passing Cocoa NSData or NSDictionary instances from python plugin to Objective-C (non-GC) code?

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

The equivalent Objective-C methods look like:

- (NSData*)getNumpyData {
    return [NSMutableData dataWithLength:10000*sizeof(float)];
}

- (NSDictionary*)getDictionary {
    char str[10000];
    str[10000-1]=0;

    return [NSDictionary dictionaryWithObjectsAndKeys:@"abc",
            @"string",
            [NSMutableString stringWithCString:str
                                      encoding:NSUnicodeStringEncoding],
            @"pkl_string",
            nil];
}

I didn't include the Objective-C version in the zip file/project since
calling these methods does NOT produce an increase in memory usage
following the end of the event loop (or any non-deallocated objects in
instruments). In the case of getDictionary, I've tried to replicate an
approximate equivalent string to the pickle.dumps call in the python
protocol.

As you can see, I'm relying on the bridging of buffer
protocol-implementing objects such as numpy's ndarray <-> NSData in
the pyobjc bridge.

Barry

On Sun, Jun 1, 2008 at 7:17 PM, s s <li...@in...> wrote:
>
> On Jun 1, 2008, at 9:57 PM, Barry Wark wrote:
>>
>> and the corresponding "getNumpyData" and "getDictFromPython" methods
>> in the plugin are:
>>
>>   import numpy as np
>>
>>   def getNumpyData(self):
>>       return np.zeros(10000)
>>
>>   def getDictionary(self):
>>       return NSDictionary.dictionaryWithObjectsAndKeys_('abc',
>>                                       'string',
>>                                       pkl.dumps(np.zeros(1000)),
>>                                       'pkl_string',
>>                                       None)
>
> What do the Obj-C test versions of these two same methods look like?
>
> S
>
>
>

Re: [Pyobjc-dev] Possible memory leak passing Cocoa NSData or NSDictionary instances from python plugin to Objective-C (non-GC) code?

[s s <li...@in...>]

On Jun 1, 2008, at 9:57 PM, Barry Wark wrote:
> and the corresponding "getNumpyData" and "getDictFromPython" methods
> in the plugin are:
>
>    import numpy as np
>
>    def getNumpyData(self):
>        return np.zeros(10000)
>
>    def getDictionary(self):
>        return NSDictionary.dictionaryWithObjectsAndKeys_('abc',
>                                        'string',
>                                        pkl.dumps(np.zeros(1000)),
>                                        'pkl_string',
>                                        None)

What do the Obj-C test versions of these two same methods look like?

S

[Pyobjc-dev] Possible memory leak passing Cocoa NSData or NSDictionary instances from python plugin to Objective-C (non-GC) code?

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

Hi all,

I have an Objective-C application that uses plugins to generate some
data. THe app is compiled against the 10.5 SDK and is running on
Leopard (with the system python and pyobjc). The data is returned as
NSData* instances and its parameters as an NSDictionary instance, as
defined by the app's plugin formal protocol. Some of our plugins are
written in Objective-C and some in Python ("compiled" with py2app).
The app is compiled against the 10.5 SDK and is running on Leopard
(with the system python and pyobjc).  I've noticed that there's a
signficant apparent memory leak in the application when using
Python-based plugins, but not when using the Objective-C based
plugins. Therefore, I've concluded that the issue is with the plugins,
not the main application. I've written a small demo app that exhibits
the apparent leak behavior.

The relevant sections of the Objective-C side are:
- (IBAction)getDataFromPython:(id)sender {
    id<TestProtocol> plugin = [[pluginClass alloc ] init];
    NSAssert([plugin conformsToProtocol:@protocol(TestProtocol)],
             @"Plugin not id<TestProtocol>.");

    for(NSUInteger i=0; i<self.nReps; i++) {
        NSData *d = [plugin getNumpyData];
    }

    [plugin release];
}

- (IBAction)getDictFromPython:(id)sender {
    id<TestProtocol> plugin = [[pluginClass alloc ] init];
    NSAssert([plugin conformsToProtocol:@protocol(TestProtocol)],
             @"Plugin not id<TestProtocol>.");


    for(NSUInteger i=0; i<self.nReps; i++) {
        NSDictionary *d = [plugin getDictionary];
    }

    [plugin release];
}

and the corresponding "getNumpyData" and "getDictFromPython" methods
in the plugin are:

    import numpy as np

    def getNumpyData(self):
        return np.zeros(10000)

    def getDictionary(self):
        return NSDictionary.dictionaryWithObjectsAndKeys_('abc',
                                        'string',
                                        pkl.dumps(np.zeros(1000)),
                                        'pkl_string',
                                        None)


 Investigation with ObjectAlloc in Instruments suggests that the
instances of "GeneralBlock" in the first case (getNumpyData) and
"GeneralBlock" and CFDictionary in the second (getDictionary) case are
created but not released, even after the event loop (and associated
NSAutoreleasePool.drain) are completed.

Is it possible that this is a memory leak caused by improper reference
management across the Objective-C/python bridge?

I am happy to file a bug in Apple's radar or the pyobjc sourceforge
project, but I'm not sure 1) if this is a bug or my fault and 2) where
the bug is most useful...

Would anyone be able to help me?

I've made a zip file with the Xcode project (app and plugin). The
project folder also contains an Instruments file that will drive and
record the behavior I describe above. The zip file is available from
http://rieke-server.physiol.washington.edu/~barry/python/PyObjCTest.zip

Any help would be greatly appreciated!

Thanks!

Barry

[Pyobjc-dev] [ pyobjc-Bugs-1981510 ] QTMovie quickTimeMovieController not wrapped

[SourceForge.net <no...@so...>]

Bugs item #1981510, was opened at 2008-06-01 21:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=1981510&group_id=14534

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Orestis Markou (orestis82)
Assigned to: Nobody/Anonymous (nobody)
Summary: QTMovie quickTimeMovieController not wrapped

Initial Comment:
quickTimeMovieController method of QTMovie (of QTKit) is not wrapped: getting "use something else".

See http://thread.gmane.org/gmane.comp.python.pyobjc.devel/4925

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=1981510&group_id=14534

[Pyobjc-dev] [ pyobjc-Bugs-1981509 ] Cannot call objc.super on NSObject

[SourceForge.net <no...@so...>]

Bugs item #1981509, was opened at 2008-06-01 21:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=1981509&group_id=14534

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Orestis Markou (orestis82)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot call objc.super on NSObject

Initial Comment:
While super(type, self) works fine when subclassing types higher up in the class hierarchy, for plain old subclasses of NSObject (a common case with appdelegates), super will not work.

A workaround is to use NSObject.init(self), but it's potentially confusing for newcomers.

Example:

>>> from Foundation import *
>>> class Test(NSObject):
...     def init(self):
...             return super(NSObject, self).init()
... 
>>> t = Test.alloc().init()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in init
AttributeError: 'objc.super' object has no attribute 'init'
>>> from AppKit import *
>>> class Test2(NSDocument):
...     def init(self):
...             return super(NSDocument, self).init()
... 
>>> t = Test2.alloc().init()
>>> 



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=1981509&group_id=14534

Re: [Pyobjc-dev] Key Value Observing of lists?

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

>> I have a workaround where I surround changes to the list with:
>>
>> self.willChangeValueForKey_("selections")
>> self.selections.append("new selection")
>> self.didChangeValueForKey_("selections")
>>
>> This works fine for now, but gives me the following messages in the
>> Console:
>>
>> *** Ignoring *** addObserver:forKeyPath:options:context: for
>> 'partName' (of <NSTableBinder: 0x3fad90>{object: <NSTableView:
>> 0x3eabc0>, bindings: content=arrangedObjects} with 0 in 0x0).
>>
>>
> I don't think I've seen this before, but I usually use  
> NSMutableArray instances when dealing with KVO.
>
> Could you try to reproduce this problem in small script?  Ideally  
> this would be a unittest testcase, but a GUI program would be fine  
> too.

OK, I've done some further investigation. This probably was a result  
of my confusion about how pyobjc works with KVO.

This was only appearing when the items in the list where actual Python  
objects.

Sample Code:

class Hello(NSObject):
     label = objc.ivar()
     def init(self):
         self = NSObject.init(self)
         self.label = "hello"
         return self

class World(object):
     def __init__(self):
         self.label = "world"

class KVO_ListsAppDelegate(NSObject):
     list = objc.ivar()
     def init(self):
         self = NSObject.init(self)
         self.list = [Hello.alloc().init(), World()]
         return self

     def applicationDidFinishLaunching_(self, sender):
         NSLog("Application did finish launching.")
         self.list[0].label = "goodbye"
         self.list[1].label = "people"
         NSLog("adding value")
         self.willChangeValueForKey_("list")
         self.list.append(Hello.alloc().init())
         NSLog("added value")
         self.didChangeValueForKey_("list")
         NSLog("done")


The log is:

[Session started at 2008-06-01 22:23:18 +0100.]
2008-06-01 22:23:19.786 KVO_Lists[1407:10b] *** Ignoring ***  
addObserver:forKeyPath:options:context: for 'label' (of  
<NSTableBinder: 0x1f2f9e0>{object: <NSTableView: 0x1f178e0>, bindings:  
content=arrangedObjects} with 0 in 0x0).
2008-06-01 22:23:20.029 KVO_Lists[1407:10b] Application did finish  
launching.
2008-06-01 22:23:20.032 KVO_Lists[1407:10b] adding value
2008-06-01 22:23:20.033 KVO_Lists[1407:10b] added value
2008-06-01 22:23:20.035 KVO_Lists[1407:10b] *** Ignoring ***  
removeObserver:forKeyPath: for 'label' (of <NSTableBinder:  
0x1f2f9e0>{object: <NSTableView: 0x1f178e0>, bindings:  
content=arrangedObjects}).
2008-06-01 22:23:20.036 KVO_Lists[1407:10b] done
2008-06-01 22:23:20.049 KVO_Lists[1407:10b] *** Ignoring ***  
addObserver:forKeyPath:options:context: for 'label' (of  
<NSTableBinder: 0x1f2f9e0>{object: <NSTableView: 0x1f178e0>, bindings:  
content=arrangedObjects} with 0 in 0x0).

Notice how there are three objects in there, but only one complaint.  
So I guess Python objects don't play well with KVO at the moment, and  
I should use NSObjects where possible, right?

Regards,
Orestis

[Pyobjc-dev] NSDate, datetime.datetime and Bindings

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

I have an NSMutableArray that has dict/NSMutableDict entries, and is  
binding to a table view via  an Array Controller.

If a column has a date formatter, then datetime.datetime objects  
cannot be used. I get:

Cocoa Bindings: Cannot create date from object datetime.datetime(2008,  
6, 1, 21, 40, 43, 131070) of class OC_PythonObject

a = NSMutableArray.alloc().init()
a.append(dict(date=datetime.today()))
a.append(dict(date=NSDate.date()))

The first doesn't work, the second does. I can see that there is a  
proxy for dates in objc/Modules, but perhaps it's not included in the  
Leopard distribution?

Is there an ETA for an updated version of pyobjc?
--
Orestis Markou
or...@or...
http://orestis.gr/