pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] O'Reilly contest

[Just v. R. <ju...@le...>]

O'Reilly has an OSX software contest:
  http://www.macdevcenter.com/mac/developer/

Perhaps PyObjC itself could be a contender? I suppose we'd need an 0.9
release for that...

Just

Re: [Pyobjc-dev] problem with NSTableView

[Martina O. <Ma...@Oe...>]

Hi Chris,

> here is the python code of the knownEntities Object
> that acts as the datasource.
>
> class entityTable(NSObject):
>
change this to:

	from AppKit import NSTableDataSource
	class entityTable(NSTableDataSource):

PyObjc needs to know the method signatures (parameter and return 
types). If it doesn't know them it assumes they are of type ID, which 
causes the crash.

The NSTableDataSource class declares the proper method signatures 
signatures for you.

ciao
Martina

Re: [Pyobjc-dev] problem with NSTableView

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

On Thursday, Mar 13, 2003, at 20:56 Europe/Amsterdam, chris bunker 
wrote:

> Hello, I'm currently experiencing an error with my
> program which lead to the following getting outputted
> to the console


> here is the python code of the knownEntities Object
> that acts as the datasource.
>
> class entityTable(NSObject):

There's your problem. You should also inherit from NSTableDataSource:

	class entityTable(NSObject, NSTableDataSource):
		...

This is necessary to make sure that the bridge knows the right method 
signatures for Objective-C: A number of the methods in the datasource 
protocol use plain C types as arguments or return value, without this 
hint the bridge assumes that all arguments and return values are 
objects.

Ronald

Re: [Pyobjc-dev] problem with NSTableView

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

On Thursday, Mar 13, 2003, at 14:56 US/Eastern, chris bunker wrote:
....
> self.knownEntities is a Python object that inheriting
> from NSObject and implementing the informal
> NSTableDataSource protocol. At this point it contains
> no data to display as I'm just setting the program up
> at this point.
>
> ....
> class entityTable(NSObject):
...

Change the declaration to:

> class entityTable(NSObject, NSTableDataSource):

(BTW:  Normally, that class would be called 'EntityTable' to be 
consistent w/ObjC and Python naming conventions.)

--

When implementing one of the informal protocols, you need to 
specifically declare [in Python] that you are doing so.  This allows 
PyObjC to figure out the correct types for the arguments to the method. 
   The alternative is to use the objc.selector() function to declare the 
appropriate types on the methods -- but that is considerably more 
tedious.

I posted a relatively long message a few days [weeks?] ago that 
explains informal protocols and their implementation in Python via 
PyObjC -- see the list archives.

b.bum
(Stuck in Cocoa/Java land right now.... makes me appreciate 
Cocoa/Python all the more)

Re: [Pyobjc-dev] problem with NSTableView

[<bo...@pa...>]

there are issues right off the bat that you will need to
resolve:

first, declare the "informal" protocol NSTableDataSource, like
this:

	class entityTable(AutoBaseClass, NSTableDataSource):

second, there are enough bugs in 0.8 with NSTables, that you are better
off building from scratch out of the CVS depot. make sure you build FFI
first and follow the FFI build/install instructions exactly [especially
the part about creating and cd'ing into the build directory].

--bob



On Thursday, March 13, 2003, at 11:56 AM, chris bunker wrote:

> Hello, I'm currently experiencing an error with my
> program which lead to the following getting outputted
> to the console
>
> 2003-03-07 21:14:33.618 whisper[508] Application did
> finish launching.
> 2003-03-07 21:15:09.902 whisper[508] *** Assertion
> failure in -[NSTableView _locationOfRow:],
> TableView.subproj NSTableView.m:486
> 2003-03-07 21:15:10.028 whisper[508]
> NSInternalInconsistencyException
>
> I haven't actually been able to find the
> _locationOfRow: method in any of Apple's documentation
> or the web. I guess it must be a private call to do
> with the way that the object renders itself to screen.
> So if any of you know what this actually is so I can
> figure out what is going wrong that would be very
> useful.
>
> I'm programming in Python and bridging to Cocoa with
> the PyObjC module (version 0.8). This NSTableView
> instance is pure Obj-C and was created via Interface
> builder.
>
> The error occurs when setting the datasource of the
> NSTableView object using the following Python code.
>
> self.knownEntitiesTable.setDataSource_(self.knownEntities)
>
> self.knownEntities is a Python object that inheriting
> from NSObject and implementing the informal
> NSTableDataSource protocol. At this point it contains
> no data to display as I'm just setting the program up
> at this point.
>
> Any help that you can give would be greatly
> appreciated. Thanks in advance.
>
> Chris
>
> here is the python code of the knownEntities Object
> that acts as the datasource.
>
> class entityTable(NSObject):
>     identitiesList = []
>     counter = 0
>
>     def numberOfRowsInTableView_(self):
>         NSLog(str(self.counter))
>         return self.counter
>
>     def tableView_objectValueForTableColumn_row_(self,
> tableView, tableColumn, row):
>         NSLog(self.identitiesList[row].name)
>         return self.identitiesList[row].name
>
>     def
> tableView_setObjectValue_forTableColumn_row_(self,
> tableView, id, tableColumn, row):
>         self.identitiesList.insert(row,id)
>
>     def setIdentity(self,id,row):
>         if row < len(self.identities):
>             self.identitiesList[row] = id
>         else:
>             self.identitiesList.append(id)
>         self.counter += 1
>
>     def setIdentities(self,ids):
>         self.counter = len(ids)
>         self.identitiesList = ids
>
>     def getIdentity(self,row):
>         return self.identitiesList[row]
>
>     def getIdentities(self):
>         return self.identitiesList
>
>     def append(self,id):
>         self.counter += 1
>         self.identitiesList.append(id)
>
>     #it has been very insistent about these two
> methods
>     def __len__(self):
>         return self.counter
>
>     def __getitem__(self, key):
>         return self.identitiesList[key]
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Web Hosting - establish your business online
> http://webhosting.yahoo.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open!
> Get cracking and register here for some mind boggling fun and
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] problem with NSTableView

[chris b. <por...@ya...>]

Hello, I'm currently experiencing an error with my
program which lead to the following getting outputted
to the console

2003-03-07 21:14:33.618 whisper[508] Application did
finish launching.
2003-03-07 21:15:09.902 whisper[508] *** Assertion
failure in -[NSTableView _locationOfRow:],
TableView.subproj NSTableView.m:486
2003-03-07 21:15:10.028 whisper[508]
NSInternalInconsistencyException

I haven't actually been able to find the
_locationOfRow: method in any of Apple's documentation
or the web. I guess it must be a private call to do
with the way that the object renders itself to screen.
So if any of you know what this actually is so I can
figure out what is going wrong that would be very
useful.

I'm programming in Python and bridging to Cocoa with
the PyObjC module (version 0.8). This NSTableView
instance is pure Obj-C and was created via Interface
builder.

The error occurs when setting the datasource of the
NSTableView object using the following Python code.

self.knownEntitiesTable.setDataSource_(self.knownEntities)

self.knownEntities is a Python object that inheriting
from NSObject and implementing the informal
NSTableDataSource protocol. At this point it contains
no data to display as I'm just setting the program up
at this point.

Any help that you can give would be greatly
appreciated. Thanks in advance.

Chris

here is the python code of the knownEntities Object
that acts as the datasource.

class entityTable(NSObject):
    identitiesList = []
    counter = 0
        
    def numberOfRowsInTableView_(self):
        NSLog(str(self.counter))
        return self.counter
        
    def tableView_objectValueForTableColumn_row_(self,
tableView, tableColumn, row):
        NSLog(self.identitiesList[row].name)
        return self.identitiesList[row].name
        
    def
tableView_setObjectValue_forTableColumn_row_(self,
tableView, id, tableColumn, row):
        self.identitiesList.insert(row,id)
        
    def setIdentity(self,id,row):
        if row < len(self.identities):
            self.identitiesList[row] = id
        else:
            self.identitiesList.append(id)
        self.counter += 1
    
    def setIdentities(self,ids):
        self.counter = len(ids)
        self.identitiesList = ids
        
    def getIdentity(self,row):
        return self.identitiesList[row]
        
    def getIdentities(self):
        return self.identitiesList
        
    def append(self,id):
        self.counter += 1
        self.identitiesList.append(id)
        
    #it has been very insistent about these two
methods
    def __len__(self):
        return self.counter
        
    def __getitem__(self, key):
        return self.identitiesList[key]

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

[Pyobjc-dev] On bug 679748: NSMutableString gets converted to Python string

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

This is bug is basicly fixed, but is still open because of a cosmetic 
issue: the name of the method that is used to access the NSString that 
is proxied by our unicode subclass.

That method is currently called 'pyobjc_NSString' which is overly 
verbose. I'm inclined to change this to 'nsstring'. Another convenient 
name is 'asNSString', but that implies conversion (which we don't do).

BTW. Should we add a method to resync the unicode-object contents to 
the data in the NSString? Adding
this isn't too hard and might be convenient when dealing with mutable 
strings.

Ronald

[Pyobjc-dev] [ pyobjc-Bugs-700076 ] Crash instead of exception

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

Bugs item #700076, was opened at 2003-03-08 21:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=700076&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash instead of exception

Initial Comment:
The following snippet crashes:

from AppKit import NSBitmapImageRep
im = NSBitmapImageRep.alloc().init()

Sure, NSBitmapImageRep doesn't have an init() method, but still...

The output is:
2003-03-08 21:38:15.498 python2.3[2740] *** -[NSBitmapImageRep init]: selector not recognized
2003-03-08 21:38:15.500 python2.3[2740] *** -[NSBitmapImageRep init]: selector not recognized
2003-03-08 21:38:15.504 python2.3[2740] *** Uncaught exception: <NSInvalidArgumentException> *** -[NSBitmapImageRep init]: selector not recognized
Trace/BPT trap

Here's the trace:

Date/Time:  2003-03-08 21:38:16 +0100
OS Version: 10.2.3 (Build 6G30)
Host:       python.xs4all.nl

Command:    python2.3
PID:        2740

Exception:  EXC_BREAKPOINT (0x0006)
Code[0]:    0x00000001Code[1]:    0x90844988

Thread 0 Crashed:
 #0   0x90844988 in _NSRaiseError
 #1   0x90844810 in +[NSException raise:format:]
 #2   0x93244e00 in -[NSBitmapImageRep init]
 #3   0x0058a264 in object_dealloc (objc-object.m:178)
 #4   0x00024408 in subtype_dealloc (typeobject.c:692)
 #5   0x0058bf74 in sel_dealloc (selector.m:362)
 #6   0x0007eb28 in call_function (ceval.c:3388)
 #7   0x0007c5ac in eval_frame (ceval.c:2056)
 #8   0x0007d8c0 in PyEval_EvalCodeEx (ceval.c:2602)
 #9   0x0008072c in PyEval_EvalCode (ceval.c:535)
 #10  0x0000c07c in run_node (pythonrun.c:1134)
 #11  0x0000b828 in PyRun_SimpleFileExFlags (pythonrun.c:745)
 #12  0x00006344 in Py_Main (main.c:412)
 #13  0x00001f1c in _start (crt.c:267)
 #14  0x00001d9c in start

PPC Thread State:
  srr0: 0x90844988 srr1: 0x0002f030                vrsave: 0x00000000
   xer: 0x00000000   lr: 0x90844964  ctr: 0x907e4270   mq: 0x00000000
    r0: 0x00000000   r1: 0xbffff770   r2: 0x2400424e   r3: 0xa07ed3b8
    r4: 0x9068d51c   r5: 0x20000000   r6: 0xbffff450   r7: 0x00000000
    r8: 0x00390010   r9: 0xa07e0294  r10: 0x00000001  r11: 0x00000000
   r12: 0x2400424e  r13: 0x003b5abc  r14: 0x0046d4b0  r15: 0x000ea298
   r16: 0x00000000  r17: 0x00000000  r18: 0x0007a594  r19: 0x00000000
   r20: 0x0007a298  r21: 0x000f4170  r22: 0x00024160  r23: 0x000ecf98
   r24: 0x000ecf98  r25: 0x00000008  r26: 0x00440ad0  r27: 0x0044bf50
   r28: 0x00bd0ac0  r29: 0x00396b10  r30: 0xbffff880  r31: 0x908448a8

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

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

Re: [Pyobjc-dev] FFI problems

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

On Saturday, Mar 8, 2003, at 01:53 US/Eastern, Ronald Oussoren wrote:
> According to the license file in the libffi tree it is licensed under 
> an X11-style license, that should be fully compatible with our 
> license. If it were licensed under GPL I wouldn't have used it for 
> this project because of licensing issues.

Excellent -- thank you for the clarification.   I have been burned one 
time too many by the GPL to not be paranoid.

b.bum

Re: [Pyobjc-dev] FFI problems

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

On Friday, Mar 7, 2003, at 22:23 Europe/Amsterdam, bb...@ma... wrote:

> Can you toss together a new libffi.tar for the web site?   we really 
> ought to see about building libffi as a separate Python module that we 
> can import.  This would very effectively eliminate the licensing 
> issues of mixing in LGPL'd code [if it is just GPL, it'll help, but 
> maybe not fix the problem...].
>
> b.bum

According to the license file in the libffi tree it is licensed under 
an X11-style license, that should be fully compatible with our license. 
If it were licensed under GPL I wouldn't have used it for this project 
because of licensing issues.

Ronald

Re: [Pyobjc-dev] FFI problems

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

On Friday, Mar 7, 2003, at 17:47 Europe/Amsterdam, bb...@ma... wrote:

> On Friday, Mar 7, 2003, at 03:20 US/Eastern, Ronald Oussoren wrote:
>>         assert(ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 0,
>>         &ffi_type_sint, cl_arg_types) == FFI_OK);
>
> Changing the ffi_type_sint to ffi_type_double makes the program "work" 
> in that the right value is printed.  However, it still crashes at exit 
> without any kind of a usable backtrace.   Smells like a stack muncher.


It seems to be a bug in the snapshot of libffi that we're using. I've 
copied the version of darwin_closure.S from the GCC CVS to our tree, 
and this solves my problems. I had to disable the .data section from 
the assembly file, libffi won't build with it.

Struct returns still don't work, but that might be unrelated.

Ronald

Re: [Pyobjc-dev] FFI problems

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

On Friday, Mar 7, 2003, at 03:20 US/Eastern, Ronald Oussoren wrote:
>         assert(ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 0,
>         &ffi_type_sint, cl_arg_types) == FFI_OK);

Changing the ffi_type_sint to ffi_type_double makes the program "work" 
in that the right value is printed.  However, it still crashes at exit 
without any kind of a usable backtrace.   Smells like a stack muncher.

b.bum

[Pyobjc-dev] FFI problems

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

It looks like I've run into a bug in libffi, or (more likely) I should 
dig for more documentation. The following program works fine when 
RETTYPE is int and crashes when RETTYPE is double. Problem is that this 
is how we use libffi in the bridge, the effect of this is that you 
cannot define methods that return anything other than id, char, short 
or int (and unsigned variants) at the moment. Luckily returning other 
types (double, long long, structs) is not that common in Cocoa.

Ronald

#include <ffi.h>
#include <assert.h>

#define RETTYPE double

static void closure_test_fn4(ffi_cif* cif,void* resp,void** args,
                              void* userdata)
{
         *(RETTYPE*)resp = 42;
}

typedef RETTYPE (*closure_test_type4)(void);

void doit(void)
{
         ffi_cif cif;
         ffi_type* cl_arg_types[17];
         static ffi_closure cl;
         double res;

         cl_arg_types[0] = NULL;

         /* Initialize the cif */
         assert(ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 0,
         &ffi_type_sint, cl_arg_types) == FFI_OK);

         assert(ffi_prep_closure(&cl, &cif, closure_test_fn4,
         (void *) 3 /* userdata */)  == FFI_OK);
         res = ((closure_test_type4)(&cl))();
         printf("%f\n", res);
}


int main(void)
{
         doit();
}

Re: [Pyobjc-dev] 0.9, anytime soon?

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

On Tuesday, Mar 4, 2003, at 09:07 US/Eastern, Dinu Gherman wrote:
> Hi, is there any reason to believe in an 0.9 release, anytime soon?

Yes.

We have fixed many bugs and cleaned up lots of various features.   It 
is time for a new release, docs be damned (though 1.0 can't ship 
without docs -- not even 1.0a1.  Really.  I mean it. ;-).

I want to get a 0.9 out the door before the end of March.  There will 
be another PyObjC article out there around the beginning of April or so 
and it'll depend on features in the current version of PyObjC.

b.bum

[Pyobjc-dev] Problem with conversion of NSNumbers and property lists

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

I ran into a little snag regarding the current treatment of NSNumber, 
esp. the conversion to python numbers.

The following scriptlet writes a plist containing two keys 'int' and 
'bool', with the current version of the bridge both have an integer 
value (tag <integer>).

 > from Foundation import NSMutableDictionary, NSNumber
 >
 > d = NSMutableDictionary.dictionary()
 > d['int'] = 1
 > d['bool'] = NSNumber.numberWithBool_(1)
 >
 > d.writeToFile_atomically_("foo.plist", 0)

My problem is that I wanted to write a boolean value for key 'bool', 
<true/> instead of
<integer>1</integer>. Python might not care about the difference 
between booleans and integers, but I ran into a program that does care.

If I disable the conversion of NSNumbers to Python numbers my script 
writes a plist containing <true/> and <false/> tags and the target 
program interpretes my plist as expected.

Ideas? Should we introduce our own boolean type on python 2.2 (aliasing 
the builtin bool type on 2.3)?

Ronald

P.S. This is with python 2.2, in Python 2.3 this is less of a problem 
because python booleans are then converted to boolean NSNumbers.

[Pyobjc-dev] 0.9, anytime soon?

[Dinu G. <gh...@da...>]

Hi, is there any reason to believe in an 0.9 release, anytime soon?

Dinu

--
Dinu C. Gherman
......................................................................
"Questions are never indiscreet. Answers sometimes are." (Oscar Wilde)

Re: [Pyobjc-dev] caution with BOOL parameters

[Chris R. <cp...@em...>]

Bob--

On Saturday, March 1, 2003, at 01:35  PM, Bob Pasker wrote:
> if you try to pass an int whose magnitude is greater than can
> be stored in a char (-256/+255), then you will get
> 	objc.error: depythonifying 'char', got int of wrong magnitude
> for example, with a table with greater than 255 rows, the following
> will fail:
>     self.theButton.setEnabled_(self.theTableView.numberOfRows())
> but
>     self.theButton.setEnabled_(self.theTableView.numberOfRows() != 0)
> works as expected.

But isn't the latter MUCH more clearly expressive of what you're doing? 
I think the first is the typical C-style "pun" and is an abomination...

Cheers!
--Chris Ryland / Em Software, Inc. / www.emsoftware.com

Re: [Pyobjc-dev] Python as an AppleScript Replacement?

[Jack J. <Jac...@or...>]

On zondag, maa 2, 2003, at 17:55 Europe/Amsterdam, Ronald Oussoren 
wrote:
>> Sounds like it does 90% of what I meant. IMHO, it would be more 
>> elegant to do it all on the fly with a call like 
>> osa.getApp("Finder"). After all, PyObjC doesn't generate a whole set 
>> of python modules to implement Cocoa, it does it all dynamically.
>>
>> I'm just throwing this out as a suggestion BTW. I probably won't have 
>> the time to actually implement it. I might take a bash at it though. 
>> Thanks for your help.
>
> If you want to help out with this I'd suggest asking around on the 
> macpython list, the subscribers there are more likely to know about 
> using OSA from Python. I'd say a function like the getApp you propose 
> would be a usefull addition, but that's from someone that hasn't used 
> OSA before.

It's been on my todo list for ages, but I think I would implement it by 
running gensuitemodule on the fly and caching the results.

Gensuitemodule is old (more than 7 years) and on the hardware of those 
days Python wasn't up to parsing thee aete/aeut's on the fly. And it's 
very tricky code, due to OSA's intricate (and largely undocumented) 
inheritance rules. I'm happy it works, I don't really want to break it.

But, of course, if someone else wants to give this a go: be my guest!
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [Pyobjc-dev] Python as an AppleScript Replacement?

[Jack J. <Jac...@or...>]

Taking this over to pythonmac-sig too, in the hope someone knows the 
solution.

On zondag, maa 2, 2003, at 10:29 Europe/Amsterdam, Donovan Preston 
wrote:
[talking about gensuitemodule]
> 1) It currently asks you to select an application with a Carbon file 
> picker. The Carbon file picker exposed by python requires a 
> type/creator mask, and won't let you pick application bundles.
>
> 2) It currently opens the resource fork of the application you chose 
> and reads the binary data off disk, which it then parses to discover 
> the english names and corresponding four character codes.
>
> The solution to these problems is to instead send the 'ascr' 'gdte' 
> event directly to the application you wish to create a python module 
> for, by addressing the application's four character code.

I would love to do this in gensuitemodule, but there's bits and pieces 
I don't know. Maybe someone can enlighten me?

1. Where is the ascr/gdte described? What is the return value, just raw 
AEUT/AETE data, or is it somehow encoded in OSA objects?
2. It appears there's a higher level interface too, because if I do 
"get dictionary" in the script editor some applications are indeed 
fired up, but some are not. So, it seems that sometimes the ascr/gdte 
event is used to get the dictionary, but sometimes it's grabbed from 
the resource fork. At least, it seems that way...
3. Is there an API to get the "pick application" dialog that script 
editor puts up when you do a get dictionary? The way it seems to find 
scriptable applications all over the place I get the impression it 
works together with launch services or something...

--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

[Pyobjc-dev] NSNumber.alloc().initWithFloat_ crashes

[Martina O. <Ma...@Oe...>]

Hi,

Apparently the bridge now tries to translate NSNumber to native python 
types:

Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from Foundation import *
 >>> n = NSNumber.numberWithFloat_(1.0)
 >>> n
1.0

That's nice, now I can get rid of a lot of stupid floatValue() calls. 
Actually I must remove them, because they no longer work:
 >>> n.floatValue()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
AttributeError: 'float' object has no attribute 'floatValue'

Even worse, the following snippet crashes python, perhaps because it 
tries to translate an uninitialized NSNumber:

 >>> m = NSNumber.alloc().initWithFloat_(1.0)
2003-03-02 18:13:34.879 python[1524] Did you forget to nest alloc and 
init?
2003-03-02 18:13:34.883 python[1524] *** Uncaught exception: 
<NSInvalidArgumentException> *** -objCType only defined for abstract 
class.  Define -[NSPlaceholderNumber objCType]!
Trace/BPT trap

Date/Time:  2003-03-02 18:13:35 +0100
OS Version: 10.2.4 (Build 6I32)
Host:       iBook.local.

Command:    python
PID:        1524

Exception:  EXC_BREAKPOINT (0x0006)
Code[0]:    0x00000001Code[1]:    0x90844988

Thread 0 Crashed:
  #0   0x90844988 in _NSRaiseError
  #1   0x90844810 in +[NSException raise:format:]
  #2   0x908882a8 in -[NSPlaceholderValue objCType]
  #3   0x0027093c in -[NSNumber(PyObjCSupport) __pyobjc_PythonObject__] 
(objc_support.m:70)
  #4   0x00272368 in pythonify_c_value (objc_support.m:654)
  #5   0x00284118 in supercall_NSObject_alloc (alloc_hack.m:66)
  #6   0x0027e4ec in objcsel_call (selector.m:633)
  #7   0x00045930 in PyObject_Call
  #8   0x0005df64 in PyEval_GetFuncDesc
  #9   0x0005b32c in PyEval_EvalCode
  #10  0x0005c634 in PyEval_EvalCodeEx
  #11  0x00058a80 in PyEval_EvalCode
  #12  0x00027e90 in PyRun_FileExFlags
  #13  0x00026c70 in PyRun_InteractiveOneFlags
  #14  0x00026a58 in PyRun_InteractiveLoopFlags
  #15  0x000268f0 in PyRun_AnyFileExFlags
  #16  0x000069f0 in Py_Main
  #17  0x00002970 in start
  #18  0x000027f0 in start

PPC Thread State:
   srr0: 0x90844988 srr1: 0x0002f030                vrsave: 0x00000000
    xer: 0x00000000   lr: 0x90844964  ctr: 0x907e4270   mq: 0x00000000
     r0: 0x00000000   r1: 0xbffff1d0   r2: 0x2422224d   r3: 0xa07ed3b8
     r4: 0x9068d51c   r5: 0x00000000   r6: 0xbfffeeb0   r7: 0x00000000
     r8: 0x00103010   r9: 0xa07e0294  r10: 0x00000001  r11: 0x00000000
    r12: 0x2422224d  r13: 0x00000083  r14: 0x0011c7fc  r15: 0x00000000
    r16: 0x00000000  r17: 0x00000000  r18: 0x00000000  r19: 0x0011c7fc
    r20: 0x005438e3  r21: 0x0010b7e0  r22: 0x00000000  r23: 0x0011c6b0
    r24: 0x00000000  r25: 0x00000000  r26: 0x00543660  r27: 0x0046f190
    r28: 0xbffff964  r29: 0x0046ede0  r30: 0x001635f0  r31: 0x908448a8


ciao
Martina

Re: [Pyobjc-dev] Python as an AppleScript Replacement?

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

On Sunday, Mar 2, 2003, at 12:00 Europe/Amsterdam, Peter Montagner 
wrote:

>
> On Sunday, March 2, 2003, at 08:29  PM, Donovan Preston wrote:
>
>> On Saturday, March 1, 2003, at 11:46 PM, Peter Montagner wrote:
>>> I may be missing something, but I thought that MacPython's OSA 
>>> support was limited to the AppleEvents level. AppleEvents are the 
>>> low level interapplication messaging protocol. The code would still 
>>> be useful of course, but it wasn't what I was thinking of (unless 
>>> I'm missing something). You *could* look up the 4 char AppleEvent 
>>> codes for the call you want manually and then send them and wait for 
>>> a response, but this is nothing like 
>>> osa.getApp("Finder").empty_trash. It is the core though.
>>
>> You are missing something -- gensuitemodule.
>
> I thought I must be.
>
>> gensuitemodule is a script that writes the python code which creates 
>> and sends the low level apple events for you, based on the high level 
>> AppleScript terminology. There are a few issues (resolvable) with 
>> using it to it's fullest potential on OS X:
>>
>> 1) It currently asks you to select an application with a Carbon file 
>> picker. The Carbon file picker exposed by python requires a 
>> type/creator mask, and won't let you pick application bundles.
>>
>> 2) It currently opens the resource fork of the application you chose 
>> and reads the binary data off disk, which it then parses to discover 
>> the english names and corresponding four character codes.
>>
>> The solution to these problems is to instead send the 'ascr' 'gdte' 
>> event directly to the application you wish to create a python module 
>> for, by addressing the application's four character code. If you are 
>> attempting to talk to a bundled application, the four character code 
>> is usually in the plist file inside the bundle.
>>
>> I have some experimental code which allows you to use gensuitemodule 
>> much more effectively on OS X by using the above apple event; 
>> however, I still haven't found a way to discover an application's 
>> four character code automatically. Unfortunately I am working on it 
>> in my spare time, but I will attempt to get a patch enhancing 
>> gensuitemodule for use on OS X into the sourceforge patch tracker 
>> sometime this week.
>
> Sounds like it does 90% of what I meant. IMHO, it would be more 
> elegant to do it all on the fly with a call like osa.getApp("Finder"). 
> After all, PyObjC doesn't generate a whole set of python modules to 
> implement Cocoa, it does it all dynamically.
>
> I'm just throwing this out as a suggestion BTW. I probably won't have 
> the time to actually implement it. I might take a bash at it though. 
> Thanks for your help.

If you want to help out with this I'd suggest asking around on the 
macpython list, the subscribers there are more likely to know about 
using OSA from Python. I'd say a function like the getApp you propose 
would be a usefull addition, but that's from someone that hasn't used 
OSA before.

Ronald

Re: [Pyobjc-dev] Python as an AppleScript Replacement?

[Peter M. <zig...@po...>]

On Sunday, March 2, 2003, at 08:29  PM, Donovan Preston wrote:

> On Saturday, March 1, 2003, at 11:46 PM, Peter Montagner wrote:
>> I may be missing something, but I thought that MacPython's OSA 
>> support was limited to the AppleEvents level. AppleEvents are the low 
>> level interapplication messaging protocol. The code would still be 
>> useful of course, but it wasn't what I was thinking of (unless I'm 
>> missing something). You *could* look up the 4 char AppleEvent codes 
>> for the call you want manually and then send them and wait for a 
>> response, but this is nothing like osa.getApp("Finder").empty_trash. 
>> It is the core though.
>
> You are missing something -- gensuitemodule.

I thought I must be.

> gensuitemodule is a script that writes the python code which creates 
> and sends the low level apple events for you, based on the high level 
> AppleScript terminology. There are a few issues (resolvable) with 
> using it to it's fullest potential on OS X:
>
> 1) It currently asks you to select an application with a Carbon file 
> picker. The Carbon file picker exposed by python requires a 
> type/creator mask, and won't let you pick application bundles.
>
> 2) It currently opens the resource fork of the application you chose 
> and reads the binary data off disk, which it then parses to discover 
> the english names and corresponding four character codes.
>
> The solution to these problems is to instead send the 'ascr' 'gdte' 
> event directly to the application you wish to create a python module 
> for, by addressing the application's four character code. If you are 
> attempting to talk to a bundled application, the four character code 
> is usually in the plist file inside the bundle.
>
> I have some experimental code which allows you to use gensuitemodule 
> much more effectively on OS X by using the above apple event; however, 
> I still haven't found a way to discover an application's four 
> character code automatically. Unfortunately I am working on it in my 
> spare time, but I will attempt to get a patch enhancing gensuitemodule 
> for use on OS X into the sourceforge patch tracker sometime this week.

Sounds like it does 90% of what I meant. IMHO, it would be more elegant 
to do it all on the fly with a call like osa.getApp("Finder"). After 
all, PyObjC doesn't generate a whole set of python modules to implement 
Cocoa, it does it all dynamically.

I'm just throwing this out as a suggestion BTW. I probably won't have 
the time to actually implement it. I might take a bash at it though. 
Thanks for your help.

Peter

Re: [Pyobjc-dev] Python as an AppleScript Replacement?

[Donovan P. <ds...@ma...>]

On Saturday, March 1, 2003, at 11:46 PM, Peter Montagner wrote:
> I may be missing something, but I thought that MacPython's OSA support 
> was limited to the AppleEvents level. AppleEvents are the low level 
> interapplication messaging protocol. The code would still be useful of 
> course, but it wasn't what I was thinking of (unless I'm missing 
> something). You *could* look up the 4 char AppleEvent codes for the 
> call you want manually and then send them and wait for a response, but 
> this is nothing like osa.getApp("Finder").empty_trash. It is the core 
> though.

You are missing something -- gensuitemodule. gensuitemodule is a script 
that writes the python code which creates and sends the low level apple 
events for you, based on the high level AppleScript terminology. There 
are a few issues (resolvable) with using it to it's fullest potential 
on OS X:

1) It currently asks you to select an application with a Carbon file 
picker. The Carbon file picker exposed by python requires a 
type/creator mask, and won't let you pick application bundles.

2) It currently opens the resource fork of the application you chose 
and reads the binary data off disk, which it then parses to discover 
the english names and corresponding four character codes.

The solution to these problems is to instead send the 'ascr' 'gdte' 
event directly to the application you wish to create a python module 
for, by addressing the application's four character code. If you are 
attempting to talk to a bundled application, the four character code is 
usually in the plist file inside the bundle.

I have some experimental code which allows you to use gensuitemodule 
much more effectively on OS X by using the above apple event; however, 
I still haven't found a way to discover an application's four character 
code automatically. Unfortunately I am working on it in my spare time, 
but I will attempt to get a patch enhancing gensuitemodule for use on 
OS X into the sourceforge patch tracker sometime this week.

Donovan

Re: [Pyobjc-dev] Python as an AppleScript Replacement?

[Peter M. <zig...@po...>]

On Sunday, March 2, 2003, at 06:05  PM, Ronald Oussoren wrote:

>
> On Sunday, Mar 2, 2003, at 07:10 Europe/Amsterdam, Peter Montagner 
> wrote:
>
>> I don't know if this has been asked before (I couldn't access the 
>> list archives) but has anyone thought of using PyObjC as an 
>> AppleScript replacement? Complete Open Scripting Architecture 
>> compliance (Script Editor support, etc) probably isn't worth it but 
>> what about doing something functionally similar? Something like:
>
> Did you look at the OSA support in MacPython? It already does most of 
> what you want, adding the missing features is probably less work than 
> starting from scratch.

I may be missing something, but I thought that MacPython's OSA support 
was limited to the AppleEvents level. AppleEvents are the low level 
interapplication messaging protocol. The code would still be useful of 
course, but it wasn't what I was thinking of (unless I'm missing 
something). You *could* look up the 4 char AppleEvent codes for the 
call you want manually and then send them and wait for a response, but 
this is nothing like osa.getApp("Finder").empty_trash. It is the core 
though.

Here's what emptying the trash is like with AppleEvents (pseudocode, 
but you get the idea):

AppleEvent ('MACS', 'fndr', 'empt', '----', objspec ('trsh'))

Not pleasant, and that is a simple example.

Peter

Re: [Pyobjc-dev] Python as an AppleScript Replacement?

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

On Sunday, Mar 2, 2003, at 07:10 Europe/Amsterdam, Peter Montagner 
wrote:

> I don't know if this has been asked before (I couldn't access the list 
> archives) but has anyone thought of using PyObjC as an AppleScript 
> replacement? Complete Open Scripting Architecture compliance (Script 
> Editor support, etc) probably isn't worth it but what about doing 
> something functionally similar? Something like:
>
> import osa
>
> finder = osa.getApp("Finder")
> finder.empty_trash()
>
> textEdit = osa.getApp("TextEdit")
> text = textEdit.doument[1].text
> print text


Did you look at the OSA support in MacPython? It already does most of 
what you want, adding the missing features is probably less work than 
starting from scratch.

Ronald