pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] flattening of module/packaging structure

[Bob I. <bo...@re...>]

On Thursday, Aug 21, 2003, at 15:41 America/New_York, Zachery Bir wrote:

> I think the problem with my app distribution is that when it is built 
> out, __main__.py has this:
>
>   from PyObjCTools import AppHelper
>
> but on the Filesystem, this is what gets built:
>
> ~/Desktop/ZopeEditManager v0.5/ZopeEditManager.app/Contents/Resources
> zbir@gorilla $ ls
> AppHelper.py               test_nsarray.py
> AppHelper.pyc              test_nsarray.pyc
> .
> .
> .
> __main__.py                test_nsobject.pyc
>
> So, the package hierarchy is lost, and the app can no longer import 
> "AppHelper" from "PyObjCTools".
>
> Is this a bug? Or am I just at a running stumble? :)

That's kind of.. odd.  It should still work if PyObjC is installed 
correctly (i.e. in site-packages).  What does your bundlebuilder script 
look like?

-bob

Re: [Pyobjc-dev] flattening of module/packaging structure

[Zachery B. <zb...@ur...>]

On Friday, August 22, 2003, at 12:54 PM, Bob Ippolito wrote:

> Or you could do it the other way, as in the examples included with 
> PyObjC.  If you look at them, they're independent of Project Builder 
> (though still used IB to build the interface, of course) and use a 
> bundlebuilder script to build the .app bundle afterwards 
> (bundlebuilder scripts are at least as trivial as a distutils script). 
>  I find this to be a lot more useful, since I write my code in vim 
> anyways and Project Builder doesn't give you anything special with 
> regard to class browsing, debugging, etc. of python code.

I'd like to move more in this direction myself, anyway, though I've got 
Project Builder trained to use the Carbon Vim.app as my editor of 
choice :)

Zac

Re: [Pyobjc-dev] flattening of module/packaging structure

[Bob I. <bo...@re...>]

Or you could do it the other way, as in the examples included with 
PyObjC.  If you look at them, they're independent of Project Builder 
(though still used IB to build the interface, of course) and use a 
bundlebuilder script to build the .app bundle afterwards (bundlebuilder 
scripts are at least as trivial as a distutils script).  I find this to 
be a lot more useful, since I write my code in vim anyways and Project 
Builder doesn't give you anything special with regard to class 
browsing, debugging, etc. of python code.

-bob

On Friday, Aug 22, 2003, at 12:40 America/New_York, b.bum wrote:

> Did you add the various PyObjC modules to your project or did you use 
> one of the templates?
>
> It sounds like that the folder reference in PBX/Xcode is no longer a 
> folder reference, but a hierarchy of file references.
>
> Look in the target inspector and see what files are listed in 
> Resources or the Copy Files phase.   If it is everything, then your 
> reference is broken -- remove all the pyobjc stuff and re-add, making 
> sure to only create references for the top level folders!
>
> This particular features within PBX confuses the heck out of a lot of 
> people -- not limited to PyObjC, by any means.
>
> b.bum
>
> On Thursday, August 21, 2003, at 12:41 PM, Zachery Bir wrote:
>
>> I think the problem with my app distribution is that when it is built 
>> out, __main__.py has this:
>>
>>   from PyObjCTools import AppHelper
>>
>> but on the Filesystem, this is what gets built:
>>
>> ~/Desktop/ZopeEditManager v0.5/ZopeEditManager.app/Contents/Resources
>> zbir@gorilla $ ls
>> AppHelper.py               test_nsarray.py
>> AppHelper.pyc              test_nsarray.pyc
>> .
>> .
>> .
>> __main__.py                test_nsobject.pyc
>>
>> So, the package hierarchy is lost, and the app can no longer import 
>> "AppHelper" from "PyObjCTools".
>>
>> Is this a bug? Or am I just at a running stumble? :)
>>
>> Zac
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: VM Ware
>> With VMware you can run multiple operating systems on a single 
>> machine.
>> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
>> at the same time. Free trial click 
>> here:http://www.vmware.com/wl/offer/358/0
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
> at the same time. Free trial click 
> here:http://www.vmware.com/wl/offer/358/0
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] (no subject)

[b.bum <bb...@ma...>]

On Thursday, August 21, 2003, at 11:45 , Zachery Bir wrote:
> It doesn't run because he doesn't have PyObjCTools in his path. I 
> thought the PB Templates included the modules necessary to run on 
> systems without PyObjC installed. It's even in the PyObjC Framework in 
> my PB Project. Is it supposed to be shimming in the included modules 
> at runtime? Am I missing something?

Did you go to the command line and do 'pbxbuild install' to build the 
app?

The PyObjC module only copies into the app wrapper on install builds to 
save time during the build.

b.bum

Re: [Pyobjc-dev] flattening of module/packaging structure

[b.bum <bb...@ma...>]

Did you add the various PyObjC modules to your project or did you use 
one of the templates?

It sounds like that the folder reference in PBX/Xcode is no longer a 
folder reference, but a hierarchy of file references.

Look in the target inspector and see what files are listed in Resources 
or the Copy Files phase.   If it is everything, then your reference is 
broken -- remove all the pyobjc stuff and re-add, making sure to only 
create references for the top level folders!

This particular features within PBX confuses the heck out of a lot of 
people -- not limited to PyObjC, by any means.

b.bum

On Thursday, August 21, 2003, at 12:41 PM, Zachery Bir wrote:

> I think the problem with my app distribution is that when it is built 
> out, __main__.py has this:
>
>   from PyObjCTools import AppHelper
>
> but on the Filesystem, this is what gets built:
>
> ~/Desktop/ZopeEditManager v0.5/ZopeEditManager.app/Contents/Resources
> zbir@gorilla $ ls
> AppHelper.py               test_nsarray.py
> AppHelper.pyc              test_nsarray.pyc
> .
> .
> .
> __main__.py                test_nsobject.pyc
>
> So, the package hierarchy is lost, and the app can no longer import 
> "AppHelper" from "PyObjCTools".
>
> Is this a bug? Or am I just at a running stumble? :)
>
> Zac
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
> at the same time. Free trial click 
> here:http://www.vmware.com/wl/offer/358/0
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Using PyObjC to reverse engineer iChat's NSArchiver'ed "recent chats" files

[Bob I. <bo...@re...>]

It was kind of bugging me that iChat's chat saving features are only 
slightly better than worthless (they're frigging NSArchiver'ed, and 
iChat offers no searching facilities whatsoever.. as far as I can tell).

I used class-dump to reverse-guessgineer how these things were coded, 
and here's some PyObjC sample code that seems to work.

I also tried hacking into their PrivateFramework (trying to force their 
classes to do the deserialization) to get more information about the 
Presentity (buddyPicture, etc), but it behaves quite strangely and 
demands stuff to be setup beforehand.  Without tapping Apple's 
InstantMessage PrivateFramework (and the iChatAgent, quite possibly), 
the uniqueId+Service of a SavedChat Presentity could probably be merged 
with more info from Address Book, but I haven't tried.

-bob

Re: [Pyobjc-dev] flattening of module/packaging structure

[Zachery B. <zb...@ur...>]

On Friday, August 22, 2003, at 06:45 AM, Bob Ippolito wrote:

> On Thursday, Aug 21, 2003, at 15:41 America/New_York, Zachery Bir 
> wrote:
>
>> I think the problem with my app distribution is that when it is built 
>> out, __main__.py has this:
>>
>>   from PyObjCTools import AppHelper
>>
>> but on the Filesystem, this is what gets built:
>>
>> ~/Desktop/ZopeEditManager v0.5/ZopeEditManager.app/Contents/Resources
>> zbir@gorilla $ ls
>> AppHelper.py               test_nsarray.py
>> AppHelper.pyc              test_nsarray.pyc
>> .
>> .
>> .
>> __main__.py                test_nsobject.pyc
>>
>> So, the package hierarchy is lost, and the app can no longer import 
>> "AppHelper" from "PyObjCTools".
>>
>> Is this a bug? Or am I just at a running stumble? :)
>
> That's kind of.. odd.  It should still work if PyObjC is installed 
> correctly (i.e. in site-packages).  What does your bundlebuilder 
> script look like?

It (bundlebuilder.py) looks unchanged, but I've been building the app 
through Project Builder, using one of the included PB Templates that 
Bill came up with.

Zac

[Pyobjc-dev] (no subject)

[Zachery B. <zb...@ur...>]

So, I've built my app and am having a coworker beta test it for me :)

It doesn't run because he doesn't have PyObjCTools in his path. I 
thought the PB Templates included the modules necessary to run on 
systems without PyObjC installed. It's even in the PyObjC Framework in 
my PB Project. Is it supposed to be shimming in the included modules at 
runtime? Am I missing something?

Zac

[Pyobjc-dev] flattening of module/packaging structure

[Zachery B. <zb...@ur...>]

I think the problem with my app distribution is that when it is built 
out, __main__.py has this:

   from PyObjCTools import AppHelper

but on the Filesystem, this is what gets built:

~/Desktop/ZopeEditManager v0.5/ZopeEditManager.app/Contents/Resources
zbir@gorilla $ ls
AppHelper.py               test_nsarray.py
AppHelper.pyc              test_nsarray.pyc
.
.
.
__main__.py                test_nsobject.pyc

So, the package hierarchy is lost, and the app can no longer import 
"AppHelper" from "PyObjCTools".

Is this a bug? Or am I just at a running stumble? :)

Zac

Re: [Twisted-Python] Re: [Pyobjc-dev] Re: pdb in PyObjC apps?

[Bob I. <bo...@re...>]

On Wednesday, Aug 20, 2003, at 02:25 America/New_York, Ronald Oussoren 
wrote:

> Why didn't you use PyObjC? Is there functionality in CoreFoundation 
> that is not in Cocoa or are there other reasons?

CFSocket notifications, (theoretical) Carbon runloop support, etc.  I 
wrote it in Pyrex after a huge waste of time trying to get it to work 
reliably in ctypes (callbacks would eventually start jumping to random 
locations in memory under load, core dump on uncaught exceptions, 
etc... I think it could be a libffi issue), and I didn't want to go 
through the same ordeal with PyObjC's callbacks after my last failed 
attempt to do Rendezvous callbacks with it.  The Pyrex module was not 
hard to write, and my wrapper does take a  CFRunLoopRef from a PyObjC 
NSRunLoop if you're trying to integrate it with Cocoa or whatever.

-bob

Re: [Pyobjc-dev] Further app breakage

[Zachery B. <zb...@ur...>]

On Thursday, August 21, 2003, at 09:39 AM, Bob Ippolito wrote:

> On Wednesday, Aug 20, 2003, at 16:35 America/New_York, Zachery Bir 
> wrote:
>
>> So, in an attempt to get back to my original working version (finally 
>> a need to get CVS running - d'oh!), I commented out my refactored 
>> class and stubbed in the behavior in my application_openFile_() 
>> method. Unfortunately, I still can't get my app to run 
>> application_openFile_() at all.
>>
>> I've even tried commenting out my new NSTimer and all the behavior in 
>> my init() method except for the creation of a data structure, and it 
>> still won't run.
>>
>> I don't see anything blatantly wrong with the spelling here. Can 
>> anyone shed some light on it?
>>
>> The ZopeEditController object is the application delegate, as its 
>> spelled out in the nib file. I can make the full Project archive 
>> available to anyone who thinks it might shed more light (it's 232Kb 
>> in size, tarred up)
>>
>> Zac
>>
>> <ZopeEditController.py>
>
> You're not calling application.setDelegate_(...) anywhere, that could 
> be it.. unless the NIB is doing that somewhere?

In the nib, I've explicitly set the delegate of Window (does this 
represent the app?) to ZopeEditController. If I wanted to "Belt & 
Suspenders" it, where would I set the setDelegate_() method? In 
ZopeEditController's init() method? or in __main__.py somewhere?

> Also you probably shouldn't use backslash to continue lines, just use 
> parentheses.  I think the backslash thing is one of Guido's python 
> regrets, and I don't think anyone really uses it anymore (just like 
> nobody really uses backticks to do repr() anymore).

Corrected - I had a quick offline discussion with b.bum a while ago 
about reconciling ObjC longish method names with some of the 
traditional python style conventions :)

Zac

Re: [Pyobjc-dev] Further app breakage

[Zachery B. <zb...@ur...>]

On Thursday, August 21, 2003, at 09:39 AM, Bob Ippolito wrote:

> You're not calling application.setDelegate_(...) anywhere, that could 
> be it.. unless the NIB is doing that somewhere?

Aha! Apparently, somewhere down the line, I disconnected the delegate 
connection from File's Owner (note to self: the icon looks like a 
generic Application <wink>) to my ZopeEditController class. 
Reconnected, and blockage cleared :)

Woohoo!

Zac

[Pyobjc-dev] 2002 KOMATSU PC220-7

[DARLING S. INTL. <dar...@ea...>]

<DIV class=Section1>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><STRONG><SPAN style="FONT-SIZE: 36pt; COLOR: green; FONT-FAMILY: Arial">DARLING SONS INTL.</SPAN></STRONG></P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><st1:place><st1:City><STRONG><SPAN style="FONT-SIZE: 24pt; FONT-FAMILY: Arial">SEATTLE</SPAN></STRONG></st1:City><STRONG><SPAN style="FONT-SIZE: 24pt; FONT-FAMILY: Arial">, </SPAN></STRONG><st1:State><STRONG><SPAN style="FONT-SIZE: 24pt; FONT-FAMILY: Arial">WA</SPAN></STRONG></st1:State><STRONG><SPAN style="FONT-SIZE: 24pt; FONT-FAMILY: Arial"> </SPAN></STRONG><st1:country-region><STRONG><SPAN style="FONT-SIZE: 24pt; FONT-FAMILY: Arial">USA</SPAN></STRONG></st1:country-region></st1:place><STRONG><SPAN style="FONT-SIZE: 24pt; FONT-FAMILY: Arial">&nbsp;</SPAN></STRONG></P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><STRONG><SPAN style="FONT-SIZE: 18pt; COLOR: green; FONT-FAMILY: Arial">PHONE:</SPAN></STRONG><STRONG><SPAN style="FONT-SIZE: 18pt; FONT-FAMILY: Arial"> 360-668-7617</SPAN></STRONG></P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><STRONG><SPAN style="FONT-SIZE: 18pt; COLOR: green; FONT-FAMILY: Arial">TOLL FREE:</SPAN></STRONG><STRONG><SPAN style="FONT-SIZE: 18pt; FONT-FAMILY: Arial"> 877-328-8308</SPAN></STRONG></P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><STRONG><SPAN style="FONT-SIZE: 18pt; COLOR: green; FONT-FAMILY: Arial">FAX:</SPAN></STRONG><STRONG><SPAN style="FONT-SIZE: 18pt; FONT-FAMILY: Arial"> 360-668-5558</SPAN></STRONG></P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><v:shapetype id=_x0000_t75 coordsize = "21600,21600" o:preferrelative = "t" o:spt = "75" filled = "f" stroked = "f" path = " m@4@5 l@4@11@9@11@9@5 xe"><v:stroke joinstyle = "miter"></v:stroke><v:formulas><v:f eqn = "if lineDrawn pixelLineWidth 0 "></v:f><v:f eqn = "sum @0 1 0 "></v:f><v:f eqn = "sum 0 0 @1 "></v:f><v:f eqn = "prod @2 1 2 "></v:f><v:f eqn = "prod @3 21600 pixelWidth "></v:f><v:f eqn = "prod @3 21600 pixelHeight "></v:f><v:f eqn = "sum @0 0 1 "></v:f><v:f eqn = "prod @6 1 2 "></v:f><v:f eqn = "prod @7 21600 pixelWidth "></v:f><v:f eqn = "sum @8 21600 0 "></v:f><v:f eqn = "prod @7 21600 pixelHeight "></v:f><v:f eqn = "sum @10 21600 0 "></v:f></v:formulas><v:path o:extrusionok = "f" gradientshapeok = "t" o:connecttype = "rect"></v:path><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:lock aspectratio="t" v:ext="edit"></o:lock></v:shapetype><v:shape id=_x0000_i1025 style="WIDTH: 375pt; HEIGHT: 281.25pt" type = "#_x0000_t75" coordsize = "21600,21600"><v:imagedata o:title="1808f4770" src = "pc220_files/image001.jpg"></v:imagedata></v:shape></P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><STRONG><SPAN style="FONT-SIZE: 18pt; FONT-FAMILY: Arial">2002 KOMATSU PC220-7 1,000 HRS.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>NEW BUCKET WITH A STANDARD STICK. $112,000.00 <SPAN style="COLOR: red"><o:p></o:p></SPAN></SPAN></STRONG></P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><STRONG><SPAN style="FONT-SIZE: 18pt; FONT-FAMILY: Arial"><A href="http://www.darlingsons.com/excavators/id336.htm"><SPAN style="FONT-WEIGHT: normal">CLICK HERE FOR MORE PICTURES</SPAN></A><o:p></o:p></SPAN></STRONG></P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><STRONG><SPAN style="FONT-SIZE: 18pt; FONT-FAMILY: Arial">FOR MORE DETAILS CALL OR VISIT OUR WEBSITE</SPAN></STRONG></P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><STRONG><SPAN style="FONT-SIZE: 13.5pt; COLOR: green; FONT-FAMILY: Arial">CONTACT: JAKE DARLING,&nbsp;LOREN COWAN&nbsp;OR ERIC DARLING</SPAN></STRONG></P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><STRONG><SPAN style="FONT-SIZE: 13.5pt; COLOR: green; FONT-FAMILY: Arial">VISIT OUR WEBSITE</SPAN></STRONG></P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;<A href="http://www.darlingsons.com/"><STRONG><SPAN style="FONT-SIZE: 18pt; FONT-FAMILY: Arial">WWW.DARLINGSONS.COM</SPAN></STRONG></A></SPAN></P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><STRONG><SPAN style="FONT-SIZE: 18pt; COLOR: green; FONT-FAMILY: Arial">E-MAIL US AT</SPAN></STRONG><SPAN style="FONT-SIZE: 10pt; COLOR: green; FONT-FAMILY: Arial"> </SPAN></P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><STRONG><U><SPAN style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"><A href="mailto:DAR...@EA..."><SPAN style="FONT-WEIGHT: normal">DAR...@EA...</SPAN></A></SPAN></U></STRONG></P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center>&nbsp;</P>
<P class=MsoNormal style="TEXT-ALIGN: center" align=center><B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">IF</SPAN></B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <STRONG><SPAN style="FONT-FAMILY: Arial">YOU WOULD LIKE TO BE REMOVED FROM THIS LIST PLEASE REPLY TO THE FOLLOWING ADDRESS AND USE SUBJECT REMOVE. </SPAN></STRONG><A href="mailto:dar...@ya..."><STRONG><SPAN style="FONT-FAMILY: Arial">dar...@ea...</SPAN></STRONG></A></SPAN></P>
<P class=MsoNormal>&nbsp;</P>
<P class=MsoNormal><o:p>&nbsp;</o:p></P>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV>

[Pyobjc-dev] Further app breakage

[Zachery B. <zb...@ur...>]

So, in an attempt to get back to my original working version (finally a 
need to get CVS running - d'oh!), I commented out my refactored class 
and stubbed in the behavior in my application_openFile_() method. 
Unfortunately, I still can't get my app to run application_openFile_() 
at all.

I've even tried commenting out my new NSTimer and all the behavior in 
my init() method except for the creation of a data structure, and it 
still won't run.

I don't see anything blatantly wrong with the spelling here. Can anyone 
shed some light on it?

The ZopeEditController object is the application delegate, as its 
spelled out in the nib file. I can make the full Project archive 
available to anyone who thinks it might shed more light (it's 232Kb in 
size, tarred up)

Zac

Re: [Pyobjc-dev] Re: Cocoa/Objective-C equiv to __del__?

[Ronald O. <ous...@ci...>]

On Wednesday, 20 August, 2003, at 11:36, Michael Hudson wrote:

> Ronald Oussoren <ous...@ci...> writes:
>
>> On Tuesday, 19 August, 2003, at 16:55, Zachery Bir wrote:
>>
>>> Since we're not using __init__() for Cocoa-derived objects
>>> (delegates and the like), is there an analogous means for providing
>>> for cleanup, like the __del__() method?
>>
>> Yes, there is. The method is named __del__ :-)
>>
>> Dealloc won't work, I'm pretty sure the bridge will throw an exception
>> if you try to define that method.
>
> Yup.  Found that out just last night :-)

That's not too surprising, my previous mail is probably the first time 
this got mentioned anywhere :-(. I'll add this to the documentation.

Ronald

[Pyobjc-dev] Re: Cocoa/Objective-C equiv to __del__?

[Michael H. <mw...@py...>]

Ronald Oussoren <ous...@ci...> writes:

> On Tuesday, 19 August, 2003, at 16:55, Zachery Bir wrote:
>
>> Since we're not using __init__() for Cocoa-derived objects
>> (delegates and the like), is there an analogous means for providing
>> for cleanup, like the __del__() method?
>
> Yes, there is. The method is named __del__ :-)
>
> Dealloc won't work, I'm pretty sure the bridge will throw an exception
> if you try to define that method.

Yup.  Found that out just last night :-)

Cheers,
mwh

-- 
  Clue: You've got the appropriate amount of hostility for the
  Monastery, however you are metaphorically getting out of the
  safari jeep and kicking the lions.                         -- coonec
               -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html

Re: [Twisted-Python] Re: [Pyobjc-dev] Re: pdb in PyObjC apps?

[Ronald O. <ous...@ci...>]

On Tuesday, 19 August, 2003, at 16:06, Bob Ippolito wrote:

> On Tuesday, Aug 19, 2003, at 05:45 America/New_York, Michael Hudson 
> wrote:
>
>> Zachery Bir <zb...@ur...> writes:
>>
>>> Note to self: Don't use pdb and try to catch it through
>>> double-clicking  the app :)
>>
>> :-)
>>
>> It shouldn't be *too* outrageously hard to teach my pyrepl interactive
>> tool how to cooperate with the Cocoa run loop (you need a way to give
>> an fd to Cocoa and say "give me control when there's something to read
>> on this" and I'm sure I saw one of them somewhere) in which case you
>> could have an interactive session running alongside your
>> application... Hmm, where's that can of tuits?
>
> I've developed a CoreFoundation reactor for Twisted that would 
> facilitate this sort of thing.  It's not mainline yet because I 
> haven't had time to fully test and write enough examples -- it does 
> work, but I'm not currently comfortable putting it in the rest of 
> Twisted yet (especially due to the Pyrex build dependency).
>
> Here's what you would do (this obviously needs Developer Tools 
> installed):
>
> Download Pyrex 0.8.2
>
> Modify Pyrex/Compiler/Nodes.py .. change the block starting on line 
> 160 to this (small fix to allow system includes):
>     for filename in env.include_files:
>       if not (filename.startswith('<') and filename.endswith('>')):
>         filename = '"%s"' % filename
>       code.putln('#include %s' % filename)
>
> Install Pyrex
>
> Checkout CVS HEAD of Twisted
>
> Build and install Twisted (or put twisted into your PYTHONPATH, I have 
> a symlink of ~/src/Twisted/twisted at 
> ~/Library/Python/2.3/site-packages/twisted)
>
> Go into Twisted/sandbox/etrepum/cfsupport
>
> python setup.py build_ext -i
>
> cd TWISTEDPACKAGE/internet
> ln -s TWISTEDCVS/sandbox/etrepum/cfreactor.py .
> ln -s TWISTEDCVS/sandbox/etrepum/cfsupport/cfsupport.so .
>
> That should work, to test it check out the examples in 
> TWISTEDCVS/sandbox/etrepum/examples/PyObjC (which obviously require 
> PyObjC, you can get that from PackageManager)
>
> Also note that the cfsupport module is enough to just get 
> notifications on the fd, but I recommend using Twisted for anything 
> that talks sockets anyway.

Why didn't you use PyObjC? Is there functionality in CoreFoundation 
that is not in Cocoa or are there other reasons?

Ronald

Re: [Pyobjc-dev] NSRunAlertPanel signature?

[Ronald O. <ous...@ci...>]

On Wednesday, 20 August, 2003, at 02:06, Bob Ippolito wrote:

>
> On Tuesday, Aug 19, 2003, at 15:16 America/New_York, Zachery Bir wrote:
>
>> In the AppKit docs, it spells the method NSRunAlertPanel like this:
>>
>> int NSRunAlertPanel(NSString *title, NSString *msg, NSString 
>> *defaultButton, NSString *alternateButton, NSString *otherButton, 
>> ...)
>>
>> I assumed that the ellipsis in argument list meant the additional 
>> buttons were unbounded. However, PyObjC complains when more than 5 
>> parameters are passed. UI issues aside, is one or the other 
>> (signature or implementation) incorrect?
>
> ellipsis at the end of a C function prototype means that it's one of 
> those nasty magical C functions that take a variable number of 
> arguments (arglist_t, va_args, or whatever).  Key offenders would be 
> stuff like printf and NSLog.
>
> If you pop open Scripts/CodeGenerators/cocoa_generator.py in the 
> PyObjC source and search for NSRunAlertPanel, you'll see that the 
> current code generator ignores the fact that NSRunAlertPanel can take 
> a variable number of arguments.
>
> So basically, the current code generator isn't smart enough to do 
> anything useful for a few kinds of "complex functions", so you'll have 
> to live with a non-varargs version of NSRunAlertPanel until someone 
> writes a smarter code generator (IIRC, the libffi code for this 
> madness isn't trivial, and the python bridge would be NO fun.. but I 
> think ctypes might have support for it) and you upgrade to whatever 
> version of PyObjC that may be.

The main problem with varargs functions is that there is no easy way to 
detect which amount and type of arguments the function want to see. The 
only way to do that is to reimplement the code that walks through the 
vararg list, and there's lots of different, non-trivial, ways to do 
that. For the NSRun.*Panel functions you'd have to parse the message 
and interpret the %X arguments.

My current strategy is to ignore varargs functions unless that would 
remove functionality. For the NSRun.*Panel functions we can savely 
ignore the additional arguments, and use the printf operator in python.

BTW. libffi explicitly states that it doesn't support varargs function. 
It happens to work on the PPC because argument passing for varargs 
functions is simular enough to that of normal functions.

Ronald

Re: [Pyobjc-dev] Cocoa/Objective-C equiv to __del__?

[Ronald O. <ous...@ci...>]

On Tuesday, 19 August, 2003, at 16:55, Zachery Bir wrote:

> Since we're not using __init__() for Cocoa-derived objects (delegates 
> and the like), is there an analogous means for providing for cleanup, 
> like the __del__() method?

Yes, there is. The method is named __del__ :-)

Dealloc won't work, I'm pretty sure the bridge will throw an exception 
if you try to define that method. That's because the bridge defines 
it's own dealloc method that is needed to clean up the python state 
(clear the __dict__, ...).

Ronald

Re: [Pyobjc-dev] NSRunAlertPanel signature?

[Bob I. <bo...@re...>]

On Tuesday, Aug 19, 2003, at 15:16 America/New_York, Zachery Bir wrote:

> In the AppKit docs, it spells the method NSRunAlertPanel like this:
>
> int NSRunAlertPanel(NSString *title, NSString *msg, NSString 
> *defaultButton, NSString *alternateButton, NSString *otherButton, ...)
>
> I assumed that the ellipsis in argument list meant the additional 
> buttons were unbounded. However, PyObjC complains when more than 5 
> parameters are passed. UI issues aside, is one or the other (signature 
> or implementation) incorrect?

ellipsis at the end of a C function prototype means that it's one of 
those nasty magical C functions that take a variable number of 
arguments (arglist_t, va_args, or whatever).  Key offenders would be 
stuff like printf and NSLog.

If you pop open Scripts/CodeGenerators/cocoa_generator.py in the PyObjC 
source and search for NSRunAlertPanel, you'll see that the current code 
generator ignores the fact that NSRunAlertPanel can take a variable 
number of arguments.

So basically, the current code generator isn't smart enough to do 
anything useful for a few kinds of "complex functions", so you'll have 
to live with a non-varargs version of NSRunAlertPanel until someone 
writes a smarter code generator (IIRC, the libffi code for this madness 
isn't trivial, and the python bridge would be NO fun.. but I think 
ctypes might have support for it) and you upgrade to whatever version 
of PyObjC that may be.

-bob

Re: [Pyobjc-dev] NSRunAlertPanel signature?

[b.bum <bb...@ma...>]

On Tuesday, August 19, 2003, at 12:16 , Zachery Bir wrote:
> In the AppKit docs, it spells the method NSRunAlertPanel like this:
>
> int NSRunAlertPanel(NSString *title, NSString *msg, NSString 
> *defaultButton, NSString *alternateButton, NSString *otherButton, ...)
>
> I assumed that the ellipsis in argument list meant the additional 
> buttons were unbounded. However, PyObjC complains when more than 5 
> parameters are passed. UI issues aside, is one or the other (signature 
> or implementation) incorrect?

The additional arguments are just the formatting arguments to be 
combined with msg in a fashion similar to...

[NSString stringWithFormat: msg, ...]

So, just use Python's string composition functionality instead and pass 
a fixed set of five args.

b.bum

Re: [Pyobjc-dev] Cocoa/Objective-C equiv to __del__?

[Bob I. <bo...@re...>]

On Tuesday, Aug 19, 2003, at 10:55 America/New_York, Zachery Bir wrote:

> Since we're not using __init__() for Cocoa-derived objects (delegates  
> and the like), is there an analogous means for providing for cleanup,  
> like the __del__() method?

dealloc is what you're looking for, but I'd imagine __del__ may also  
work, because the Python object doesn't get collected until the same  
time (or later) that it would get collected from ObjC land.

http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ 
ObjC_classic/Classes/NSObject.html#//apple_ref/doc/uid/20000050/dealloc

I've never tried overriding this from PyObjC, but I would imagine it  
does the right thing.  I'd take a look at the PyObjC examples and/or  
sourcecode to see if anyone is using it (or __del__).

-bob

[Pyobjc-dev] NSRunAlertPanel signature?

[Zachery B. <zb...@ur...>]

In the AppKit docs, it spells the method NSRunAlertPanel like this:

int NSRunAlertPanel(NSString *title, NSString *msg, NSString 
*defaultButton, NSString *alternateButton, NSString *otherButton, ...)

I assumed that the ellipsis in argument list meant the additional 
buttons were unbounded. However, PyObjC complains when more than 5 
parameters are passed. UI issues aside, is one or the other (signature 
or implementation) incorrect?

Zac

Re: [Pyobjc-dev] Cocoa/Objective-C equiv to __del__?

[Zachery B. <zb...@ur...>]

On Tuesday, August 19, 2003, at 01:56 PM, Bob Ippolito wrote:

> On Tuesday, Aug 19, 2003, at 10:55 America/New_York, Zachery Bir wrote:
>
>> Since we're not using __init__() for Cocoa-derived objects (delegates  
>> and the like), is there an analogous means for providing for cleanup,  
>> like the __del__() method?
>
> dealloc is what you're looking for, but I'd imagine __del__ may also  
> work, because the Python object doesn't get collected until the same  
> time (or later) that it would get collected from ObjC land.

Cool.

> http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ 
> ObjC_classic/Classes/NSObject.html#//apple_ref/doc/uid/20000050/> dealloc
>
> I've never tried overriding this from PyObjC, but I would imagine it  
> does the right thing.  I'd take a look at the PyObjC examples and/or  
> sourcecode to see if anyone is using it (or __del__).

Thanks, yeah, looks like the example apps use __del__ (with comments  
that say: "dealloc in Obj-C" :)

Zac

[Pyobjc-dev] Cocoa/Objective-C equiv to __del__?

[Zachery B. <zb...@ur...>]

Since we're not using __init__() for Cocoa-derived objects (delegates 
and the like), is there an analogous means for providing for cleanup, 
like the __del__() method?

Thanks,

Zac