pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] PythonBrowser example/study + bug report

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

On Saturday, Nov 30, 2002, at 16:07 Europe/Amsterdam, Just van Rossum 
wrote:
> Question:
>
> I needed to subclass NSObject and was a little confused that it 
> doesn't by
> default behave more like a Python object. I wrote a __new__ method in 
> my
> subclass that does this:
>
>     def __new__(cls, *args, **kwargs):
>         return cls.alloc().init()

Cute. I knew this works, but didn't add this to PyObjC at the time 
because I didn't put much effort into thinking about the usefullness of 
this. On the one hand this does make Objective-C classes more like 
Python classes, but on the other hand this introduces API differences 
w.r.t. the Objective-C classes.

All in all I'm slightly in favor of adding an __new__ that does 
'cls.alloc().init()' (but without optional and keyword arguments). It 
might even be usefull to add more specialized versions of new for some 
classes (e.g. to add keyword arguments that allow us to call a more 
usefull version of init).

>
> Bug/Feature request:
>
> When an exception is raised in a method that is called by the objc 
> runtime, only
> a very brief error is printed to Console.app. Can this be changed so 
> it does
> PyErr_Print(), which prints a complete Python traceback? Oh, and 
> _after_ the
> brief error is printed, the program usually crashes hard:
>
> 2002-11-30 15:31:22.990 python2.3[21902] An uncaught exception was 
> raised
> 2002-11-30 15:31:22.991 python2.3[21902] No attribute allow
> 2002-11-30 15:31:22.992 python2.3[21902] *** Uncaught exception:
> <OC_PythonException> No attribute allow
> Nov 30 15:27:25 python last message repeated 13 times

I'll look into this. What I'm currently thinking of:

1) objc.setVerbose(newValue) -> None
    newValue is a boolean. If newValue is true the PyObjC runtime is 
more verbose,
    this includes calling PyErr_Print when translating from Python to 
Objective-C
    exceptions.

2) The exception raised when converting from Python to Objective-C 
exceptions
    should always include the file+line where the exception was raised.

BTW. 'objc.setVerbose' should IMHO be a property ('objc.verbose = 1' 
instead of 'objc.setVerbose(1)'), but I'm pretty sure that it is 
impossible to add properties to a module without subclassing 
types.ModuleType. This is too bad because module-properties would be a 
neat way to proxy global variables in Objective-C frameworks.

Ronald

Re: [Pyobjc-dev] NSAutoreleasePool retain?

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

There is a workaround for this, but for some reason it doesn't work.

BTW. The error is triggered by the call to init().

Ronald

On Sunday, Dec 1, 2002, at 05:02 Europe/Amsterdam, Bill Bumgarner wrote:

> In the current code from CVS, I'm seeing the following problem.   Not 
> a big deal -- easy to work around -- but I thought there was already a 
> workaround in place...?
>
> [bumbox:pyobjc/Modules/objc] bbum% python
> 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 *
> >>> NSAutoreleasePool.alloc().init()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ValueError: NSInvalidArgumentException - *** -[NSAutoreleasePool 
> retain]: Cannot retain an autorelease pool
> >>> NSAutoreleasePool.new()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ValueError: NSInvalidArgumentException - *** -[NSAutoreleasePool 
> retain]: Cannot retain an autorelease pool
> >>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T 
> handheld. Power & Color in a compact size! 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] crashing bug

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

This one was easy: The (C) code sometimes failed to initialize a struct 
member, with disasterous (sp?) results. I checked in a fix for this, 
including a test-case.

Ronald

On Sunday, Dec 1, 2002, at 14:15 Europe/Amsterdam, Just van Rossum 
wrote:

> The following snippet crashes hard, both in Python 2.2 and CVS Python:
>
>
>   from Foundation import NSObject
>   class Foo(NSObject):
>       def foo(self):
>           pass
>   print Foo.foo
>
>
> (Made my object browser crash ;-)
>
> I've pasted Console.app output below.
>
> Just
>
>
> 2002-12-01 14:09:06.577 Console[22849] Exception raised during posting 
> of
> notification.  Ignored.  exception: *** NSRunStorage, 
> _NSBlockNumberForIndex():
> index (53353) beyond array bounds (53353)
>
>
> Date/Time:  2002-12-01 14:11:46 +0100
> OS Version: 10.2.2 (Build 6F21)
> Host:       python.xs4all.nl
>
> Command:    python2.3
> PID:        22927
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x5f5f6e69
>
> Thread 0 Crashed:
>  #0   0x006b14f0 in pysel_repr (selector.m:797)
>  #1   0x00031380 in PyObject_Str (object.c:283)
>  #2   0x0003109c in PyObject_Print (object.c:184)
>  #3   0x000799e4 in eval_frame (ceval.c:1439)
>  #4   0x0007bdb8 in PyEval_EvalCodeEx (ceval.c:2554)
>  #5   0x0007ea44 in PyEval_EvalCode (ceval.c:478)
>  #6   0x0000bca8 in run_node (pythonrun.c:1090)
>  #7   0x0000b470 in PyRun_SimpleFileExFlags (pythonrun.c:701)
>  #8   0x000062b4 in Py_Main (main.c:385)
>  #9   0x00001f64 in _start (crt.c:267)
>  #10  0x00001de4 in start
>
> PPC Thread State:
>   srr0: 0x006b14f0 srr1: 0x0200f030                vrsave: 0x00000000
>    xer: 0x20000000   lr: 0x006b14d0  ctr: 0x9068af84   mq: 0x00000000
>     r0: 0x00e9d6d0   r1: 0xbffff7d0   r2: 0x007d81fc   r3: 0xbffff810
>     r4: 0x00000100   r5: 0x007d1cb0   r6: 0x00e9d6d0   r7: 0x0008da68
>     r8: 0x000799e4   r9: 0x5f5f6e61  r10: 0x9068af90  r11: 0x007dabc8
>    r12: 0x9068af84  r13: 0x0037dffc  r14: 0x003cd4b0  r15: 0x00000000
>    r16: 0x000d848c  r17: 0x00000000  r18: 0x00078788  r19: 0x00000000
>    r20: 0x0007848c  r21: 0x00000003  r22: 0x0037a800  r23: 0x003ee960
>    r24: 0x0037deb0  r25: 0x003c2058  r26: 0x003c8376  r27: 0x00000001
>    r28: 0x000f1300  r29: 0xa0000d2c  r30: 0xbffff7d0  r31: 0x006b149c
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] crashing bug

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

The following snippet crashes hard, both in Python 2.2 and CVS Python:


  from Foundation import NSObject
  class Foo(NSObject):
      def foo(self):
          pass
  print Foo.foo


(Made my object browser crash ;-)

I've pasted Console.app output below.

Just


2002-12-01 14:09:06.577 Console[22849] Exception raised during posting of
notification.  Ignored.  exception: *** NSRunStorage, _NSBlockNumberForIndex():
index (53353) beyond array bounds (53353)


Date/Time:  2002-12-01 14:11:46 +0100
OS Version: 10.2.2 (Build 6F21)
Host:       python.xs4all.nl

Command:    python2.3
PID:        22927

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x5f5f6e69

Thread 0 Crashed:
 #0   0x006b14f0 in pysel_repr (selector.m:797)
 #1   0x00031380 in PyObject_Str (object.c:283)
 #2   0x0003109c in PyObject_Print (object.c:184)
 #3   0x000799e4 in eval_frame (ceval.c:1439)
 #4   0x0007bdb8 in PyEval_EvalCodeEx (ceval.c:2554)
 #5   0x0007ea44 in PyEval_EvalCode (ceval.c:478)
 #6   0x0000bca8 in run_node (pythonrun.c:1090)
 #7   0x0000b470 in PyRun_SimpleFileExFlags (pythonrun.c:701)
 #8   0x000062b4 in Py_Main (main.c:385)
 #9   0x00001f64 in _start (crt.c:267)
 #10  0x00001de4 in start

PPC Thread State:
  srr0: 0x006b14f0 srr1: 0x0200f030                vrsave: 0x00000000
   xer: 0x20000000   lr: 0x006b14d0  ctr: 0x9068af84   mq: 0x00000000
    r0: 0x00e9d6d0   r1: 0xbffff7d0   r2: 0x007d81fc   r3: 0xbffff810
    r4: 0x00000100   r5: 0x007d1cb0   r6: 0x00e9d6d0   r7: 0x0008da68
    r8: 0x000799e4   r9: 0x5f5f6e61  r10: 0x9068af90  r11: 0x007dabc8
   r12: 0x9068af84  r13: 0x0037dffc  r14: 0x003cd4b0  r15: 0x00000000
   r16: 0x000d848c  r17: 0x00000000  r18: 0x00078788  r19: 0x00000000
   r20: 0x0007848c  r21: 0x00000003  r22: 0x0037a800  r23: 0x003ee960
   r24: 0x0037deb0  r25: 0x003c2058  r26: 0x003c8376  r27: 0x00000001
   r28: 0x000f1300  r29: 0xa0000d2c  r30: 0xbffff7d0  r31: 0x006b149c

[Pyobjc-dev] NSAutoreleasePool retain?

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

In the current code from CVS, I'm seeing the following problem.   Not a 
big deal -- easy to work around -- but I thought there was already a 
workaround in place...?

[bumbox:pyobjc/Modules/objc] bbum% python
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 *
 >>> NSAutoreleasePool.alloc().init()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
ValueError: NSInvalidArgumentException - *** -[NSAutoreleasePool 
retain]: Cannot retain an autorelease pool
 >>> NSAutoreleasePool.new()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
ValueError: NSInvalidArgumentException - *** -[NSAutoreleasePool 
retain]: Cannot retain an autorelease pool
 >>>

[Pyobjc-dev] PythonBrowser example/study + bug report

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

To finally really get starting and building a little Cocoa app myself, I tried
to build a rudimentary Python Object browser. I've attached the code + nib etc,
I'd be happy to check it into the Examples directory.


Question:

I needed to subclass NSObject and was a little confused that it doesn't by
default behave more like a Python object. I wrote a __new__ method in my
subclass that does this:

    def __new__(cls, *args, **kwargs):
        return cls.alloc().init()

Now I can instantiate an NSObject subclass like I would instantiate an Python
object: even the __init__() is now also called. Is there anything against adding
some more Python flavor to the Python wrapper of NSObject? Hm, that's probably a
very naive request, and might interfere with the Obj-C idiom. I'm I right that
the above will only work when instantiation is done from Python, and not from
Obj-C? Ok, forget about it, I'll just use the above in a superclass of my own
somewhere until I understand more of the implications...


Bug/Feature request:

When an exception is raised in a method that is called by the objc runtime, only
a very brief error is printed to Console.app. Can this be changed so it does
PyErr_Print(), which prints a complete Python traceback? Oh, and _after_ the
brief error is printed, the program usually crashes hard:

2002-11-30 15:31:22.990 python2.3[21902] An uncaught exception was raised
2002-11-30 15:31:22.991 python2.3[21902] No attribute allow
2002-11-30 15:31:22.992 python2.3[21902] *** Uncaught exception:
<OC_PythonException> No attribute allow
Nov 30 15:27:25 python last message repeated 13 times

Nov 30 15:31:24 python crashdump: Crash report written to:
/Users/just/Library/Logs/CrashReporter/python2.3.crash.log

2002-11-30 15:31:24.633 Console[20835] Exception raised during posting of
notification.  Ignored.  exception: *** NSRunStorage, _NSBlockNumberForIndex():
index (36561) beyond array bounds (36561)

This makes it quite painful to debug an app.

Just

[Pyobjc-dev] import order dependency bug

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

If Foundation is imported before AppKit, it breaks the 
pass-by-reference mechanism.

[bumbox:~] bbum% python
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 *
 >>> from AppKit import NSWorkspace
 >>> 
NSWorkspace.sharedWorkspace().getInfoForFile_application_type_('/tmp')
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: Need 3 arguments, got 1
 >>>
[bumbox:~] bbum% python
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 AppKit import NSWorkspace
 >>> from Foundation import *
 >>> 
NSWorkspace.sharedWorkspace().getInfoForFile_application_type_('/tmp')
(1, '/System/Library/CoreServices/Finder.app', '')
 >>>

Re: [Pyobjc-dev] bootstrapping with execve in /bin/sh?

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

On Wednesday, Nov 27, 2002, at 17:07 Europe/Amsterdam, Just van Rossum 
wrote:
>
> Btw: I'm still not able to pass PYTHONPATH to the process started with 
> exec.
> This doesn't seem to work:
>
> export $PYTHONPATH
export PYTHONPATH
(without the $)

Ronald

Re: [Pyobjc-dev] bootstrapping with execve in /bin/sh?

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

Ronald Oussoren wrote:

> Why would it be useless for standalone apps? I suppose standalone apps 
> have a python interpreter stuffed inside the resources directory.

They do.

> You 
> can then create a relative symlink to this interpreter (e.g. cd 
> MyApp.app/Contents/MacOS && ln -s ../Resources/python .)

Hm, yes, I suppose. I just found another trick, though: I can put the python
executable in Contents/MacOS and directly execute it from there: it works!!

Btw: I'm still not able to pass PYTHONPATH to the process started with exec.
This doesn't seem to work:

export $PYTHONPATH
PYTHONPATH=$res

Any thoughts?

Just

Re: [Pyobjc-dev] bootstrapping with execve in /bin/sh?

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

Why would it be useless for standalone apps? I suppose standalone apps 
have a python interpreter stuffed inside the resources directory. You 
can then create a relative symlink to this interpreter (e.g. cd 
MyApp.app/Contents/MacOS && ln -s ../Resources/python .)

Ronald

On Wednesday, Nov 27, 2002, at 16:06 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>> We could use my trick of a couple of weeks ago: put a symlink to 
>> python
>> into the Contents/MacOS directory and use that symlink, I think. (with
>> all the caveats of not being able to switch to another python after
>> creating the applet).
>
> That would be ok for applets but is useless for standalone apps. Looks 
> like I'll
> have to stick with bootstrapping in Python...
>
> Just
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] bootstrapping with execve in /bin/sh?

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

Jack Jansen wrote:

> We could use my trick of a couple of weeks ago: put a symlink to python 
> into the Contents/MacOS directory and use that symlink, I think. (with 
> all the caveats of not being able to switch to another python after 
> creating the applet).

That would be ok for applets but is useless for standalone apps. Looks like I'll
have to stick with bootstrapping in Python...

Just

Re: [Pyobjc-dev] Supporting (NSString **) API (and the like)

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

The error your getting from extract_byref_signatures was introduced 
when I converted from the old function names to 
getClassList/lookUpClass :-(

BTW. This script should only be run when there are new classes or 
methods, the _AppKitSignatures.py module is updated using the script 
create_byref_module.py.

I've checked in both changes.

Ronald

On Wednesday, Nov 27, 2002, at 14:55 Europe/Amsterdam, bb...@ma... 
wrote:

> python Scripts/extract_byref_signatures.py 
> /System/Library/Frameworks/AppKit.framework /tmp/k

Re: [Pyobjc-dev] Supporting (NSString **) API (and the like)

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

Wow. Cool.  You have obviously mastered Guido's time machine... :-)

     set_signature_for_selector("NSWorkspace", 
"getInfoForFile:application:type:", "c16@4:8@12o^@16o^@20")

There is still the matter of the other byref method in NSWorkspace -- 
it takes three byref BOOL's in its arguments.  For some reason, I can't 
run the byref generator script.

[bumbox:~/bbum-developer/sourceforge/pyobjc] bbum% python 
Scripts/extract_byref_signatures.py 
/System/Library/Frameworks/AppKit.framework /tmp/k
Traceback (most recent call last):
   File "Scripts/extract_byref_signatures.py", line 50, in ?
     classes = load_bundle(sys.argv[1])
   File "Scripts/extract_byref_signatures.py", line 46, in load_bundle
     classes = [ cls
TypeError: lookUpClass() takes exactly 1 argument (0 given)

BTW:  don't BOOLs have an identifier other than 'c' in 10.2??

b.bum

On Wednesday, November 27, 2002, at 01:43 AM, Ronald Oussoren wrote:
> Sorry for the late reply, I didn't have e-mail connectivity yesterday.
>
> There is no need to add (Objective-)C code for this method, or any 
> method that has pass-by-reference type arguments. I've just checked in 
> a missing definition that allows you to just call 
> NSWorkspace.getInfoForFile_application_type_(fname).
>
> I'll work on some documentation for this feature.

Re: [Pyobjc-dev] Supporting (NSString **) API (and the like)

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

Sorry for the late reply, I didn't have e-mail connectivity yesterday.

There is no need to add (Objective-)C code for this method, or any  
method that has pass-by-reference type arguments. I've just checked in  
a missing definition that allows you to just call  
NSWorkspace.getInfoForFile_application_type_(fname).

I'll work on some documentation for this feature.

Ronald

On Wednesday, Nov 27, 2002, at 00:48 Europe/Amsterdam, bb...@ma...  
wrote:

> Definitely an improvement, but raises another question.... what to do  
> if the method returns BOOL, but we want it to return a tuple like  
> thing.
>
> For example, consider:
>
> >>> app, docType =  
> NSWorkspace.sharedWorkspace().pyobjcGetInfoForFile_("/tmp/ 
> opt5_faq.pdf")
> >>> print app
> /Applications/Preview.app
> >>> print docType
> pdf
>
> But:
>
> >>> app, docType =  
> NSWorkspace.sharedWorkspace().pyobjcGetInfoForFile_("/tmp/something  
> that isn't there")
> 2002-11-26 18:47:05.074 python[23743] LSGetApplicationForURL()  
> returned -43 for file /tmp/something that isn't there.
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: unpack non-sequence
>
> This is because the current implementation returns nil -- not (nil,  
> nil).   There isn't really a way for it to return (nil, nil).
>
> A possible answer is to raise FileError -- but this fairly radically  
> changes the behavior of the underlying API.
>
> Are there examples from within the python library of things that  
> return a tuple vs. None??
>
> Hmmm.....
>
> b.bum
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten  
> Thandheld. Power & Color in a compact  
> size!http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Supporting (NSString **) API (and the like)

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

Definitely an improvement, but raises another question.... what to do  
if the method returns BOOL, but we want it to return a tuple like thing.

For example, consider:

 >>> app, docType =  
NSWorkspace.sharedWorkspace().pyobjcGetInfoForFile_("/tmp/opt5_faq.pdf")
 >>> print app
/Applications/Preview.app
 >>> print docType
pdf

But:

 >>> app, docType =  
NSWorkspace.sharedWorkspace().pyobjcGetInfoForFile_("/tmp/something  
that isn't there")
2002-11-26 18:47:05.074 python[23743] LSGetApplicationForURL() returned  
-43 for file /tmp/something that isn't there.
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: unpack non-sequence

This is because the current implementation returns nil -- not (nil,  
nil).   There isn't really a way for it to return (nil, nil).

A possible answer is to raise FileError -- but this fairly radically  
changes the behavior of the underlying API.

Are there examples from within the python library of things that return  
a tuple vs. None??

Hmmm.....

b.bum

Re: [Pyobjc-dev] bootstrapping with execve in /bin/sh?

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

On dinsdag, nov 26, 2002, at 15:23 Europe/Amsterdam, bb...@ma... wrote:

>> Any clues? (googling for "execve" and "sh" only gives me hits for
>> execve("/bin/sh", ...); ;-)
>
> In the child process, argv[0] -- the name of the process -- must 
> contain the path to the app wrapper or else the resources within can't 
> be found.   If you were to 'print NSBundle.mainBundle().bundlePath()', 
> you would find that it points to /usr/local/bin/.

We could use my trick of a couple of weeks ago: put a symlink to python 
into the Contents/MacOS directory and use that symlink, I think. (with 
all the caveats of not being able to switch to another python after 
creating the applet).
--
- 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] Supporting (NSString **) API (and the like)

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

On Tuesday, November 26, 2002, at 06:26 PM, Jack Jansen wrote:
> Good idea. And this also solves the issue about what to do for 
> python-specific modules (a Python subpackage or a prefix): use a 
> prefix there too. Even though I had a slight preference for a 
> subpackage I think that if we use prefixes for methods that have no 
> ObjC equivalent we should also use prefixes for modules that have no 
> ObjC equivalent.

It wasn't really intended to be a suggestion regarding the use of 
module, more a suggestion of how we might provide access to API that 
cannot generically work with PyObjC.    In this case, the additional 
functionality is rather simple pure ObjC and is, IMHO, a heck of a lot 
easier to create and maintain than the code found in _AppKitMapping.m 
(which isn't currently used).

The alternative would be to return an NSArray from the method w/the 
contents in the same order as they appear in the original method.  This 
could easily be mapped to the slightly-more-standard Python pattern of 
using tuples as return values...

Actually, come to think of it, I like the idea of returning tuples *a 
lot* more than the current dictionary -- it is faster and more 
consistent with the whole coding paradigm.    Since this is all proof 
of concept, I'm going to experiment with returning an array and see if 
it proves to more useful in practice.

---

The current category is used as such....

                 infoDictionary = 
workspace.pyobjcGetInfoForFile_(fullPath)
                 if not infoDictionary:
                     NSLog("Failed to find application to open file %s" 
% fullPath)
                     return
                 workspace.openFile_withApplication_(fullPath, 
infoDictionary['application'])

... and the implementation looks like the following.   I didn't see a 
reason to declare this in a formal header file type arrangement since 
it is unlikely to ever be used directly from the ObjC side of the 
bridge.

Make sense?

#import <Cocoa/Cocoa.h>

@interface NSWorkspace (PyObjCSupport)
@end
@implementation NSWorkspace (PyObjCSupport)
// - (BOOL)getInfoForFile:(NSString *)fullPath application:(NSString 
**)appName type:(NSString **)type;
- (NSDictionary *) pyobjcGetInfoForFile:(NSString *)fullPath;
{
   NSString *appName, *type;
   if ( [self getInfoForFile: fullPath application: &appName type: 
&type] ) {
     NSMutableDictionary *returnDict = [NSMutableDictionary dictionary];

     if (appName) [returnDict setObject: appName forKey: @"application"];
     if (type) [returnDict setObject: type forKey: @"type"];

     return returnDict;
   }

   return nil;
}

// - (BOOL)getFileSystemInfoForPath:(NSString *)fullPath 
isRemovable:(BOOL *)removableFlag isWritable:(BOOL *)writableFlag 
isUnmountable:(BOOL *)unmountableFlag description:(NSString 
**)description type:(NSString **)fileSystemType;
- (NSDictionary *) pyobjcGetFileSystemInfoForPath: (NSString *) 
fullPath;
{
   BOOL removableFlag, writableFlag, unmountableFlag;
   NSString *description, *fileSystemType;

   if ([self getFileSystemInfoForPath: fullPath
	    isRemovable: &removableFlag
	    isWritable: &writableFlag
	    isUnmountable: &unmountableFlag
	    description: &description
	    type: &fileSystemType]) {
     NSMutableDictionary *returnDict = [NSMutableDictionary dictionary];

     [returnDict setObject: [NSNumber numberWithBool: removableFlag] 
forKey: @"isRemovable"];
     [returnDict setObject: [NSNumber numberWithBool: writableFlag] 
forKey: @"isWritable"];
     [returnDict setObject: [NSNumber numberWithBool: unmountableFlag] 
forKey: @"isUnmountable"];

     if (description) [returnDict setObject: description forKey: 
@"description"];
     if (fileSystemType) [returnDict setObject: description forKey: 
@"description"];
   }

   return nil;
}
@end

Re: [Pyobjc-dev] Supporting (NSString **) API (and the like)

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

On dinsdag, nov 26, 2002, at 17:37 Europe/Amsterdam, Bill Bumgarner 
wrote:

> I ran across the need to call...
>
>     - (BOOL)getInfoForFile:(NSString *)fullPath application:(NSString 
> **)appName type:(NSString **)type;
>
> ... today.  Obviously, the appName and type parameters pose a problem. 
>   Instead of trying to magically wrap 'em, how about simply creating a 
> category on [in this case] NSWorkspace that offers...
>
>     - (NSDictionary *) pyobjcGetInfoForFile: (NSString *) fullPath;
>
> ... and the implementation simply returns a dictionary with the keys 
> 'application' and 'type'?
>
> The 'pyobjc' prefix will prevent namespace collisions and using a 
> category will continue to associate the functionality with the class.

Good idea. And this also solves the issue about what to do for 
python-specific modules (a Python subpackage or a prefix): use a prefix 
there too. Even though I had a slight preference for a subpackage I 
think that if we use prefixes for methods that have no ObjC equivalent 
we should also use prefixes for modules that have no ObjC equivalent.
--
- 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] Supporting (NSString **) API (and the like)

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

I ran across the need to call...

     - (BOOL)getInfoForFile:(NSString *)fullPath application:(NSString 
**)appName type:(NSString **)type;

... today.  Obviously, the appName and type parameters pose a problem.  
  Instead of trying to magically wrap 'em, how about simply creating a 
category on [in this case] NSWorkspace that offers...

     - (NSDictionary *) pyobjcGetInfoForFile: (NSString *) fullPath;

... and the implementation simply returns a dictionary with the keys 
'application' and 'type'?

The 'pyobjc' prefix will prevent namespace collisions and using a 
category will continue to associate the functionality with the class.

(I did the same thing years ago when writing PyServices w/PyObjC under 
OpenStep 4.2 -- it works quite well and is easy to maintain.  Since we 
pretty much have to do case-by-case support on the methods anyway, this 
doesn't add that much maintenance overhead.)

This would seem to be easier than the implementation found in 
_AppKitMapping.m...?

I committed changes to setup.py and the AppKit module as an example;  
see NSWorkspaceSupport.m in Modules/AppKit/.  If there is a better way, 
feel free to rip it out and make changes.  I went ahead and committed 
because (a) the change is isolated, (b) it works with a minimal amount 
of code that is quite straightforward in its implementation and (c) I 
needed support for NSWorkspace in something else I'm working on (as 
long as support continues to exist in whatever form, I don't care what 
the implementation looks like).

b.bum

Re: [Pyobjc-dev] bootstrapping with execve in /bin/sh?

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

On Tuesday, November 26, 2002, at 08:29 AM, Just van Rossum wrote:
> I'm not sure, but I _think_ it's because 'exec' in /bin/sh isn't 
> exactly the
> same as execve(). Does this sound plausible? If so, what _is_ the 
> equivalent of
> execve() in sh? Also: the exporting of PYTHONPATH doesn't work as 
> written above:
> os.environ doesn't show it.
>
> Any clues? (googling for "execve" and "sh" only gives me hits for
> execve("/bin/sh", ...); ;-)

In the child process, argv[0] -- the name of the process -- must 
contain the path to the app wrapper or else the resources within can't 
be found.   If you were to 'print NSBundle.mainBundle().bundlePath()', 
you would find that it points to /usr/local/bin/.

This is a limitation of CFBundle/NSBundle -- there is no other way to 
tell it which directory should be used as the mainBundle.   Basically, 
Apple needs to move the automatic initialization of the main bundle 
such that the developer can set the path prior to initialization.

Python solves a similar problem through the Py_SetProcessName() 
function.

In any case, I don't know if there is an analogy for execve() in shell 
speak...

b.bum

[Pyobjc-dev] bootstrapping with execve in /bin/sh?

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

Ok, ok, I take it all back about requiring Jaguar just so we can use
/usr/bin/python for bootstrapping...

This was Ronald's suggestion from a while back:

> sh?
> 
> #!/bin/bash
> 
> res=$(dirname $(dirname ${0}))/Resources
> main=${res}/main.py
> export PYTHONPATH
> PYTHONPATH=$res
> 
> exec /usr/local/bin/python ${main}
> # end of file

I've actually managed to make it sortof work (hey, I've never written a shell
script before! ;-).

But I'm running into a problem: the runtime can't find the path for the main
nib:

Traceback (most recent call last):
  File
"/Users/just/code/pyobjc/Examples/TableModel/build/TableModel.app/Contents/
Resources/TableModel.py", line 19, in ?
    NibClassBuilder.extractClasses("MainMenu")
  File "/usr/lib/python2.2/site-packages/AppKit/NibClassBuilder.py", line 128,
in extractClasses
    self._extractClassesFromNibFromBundle(nibName, bundle)
  File "/usr/lib/python2.2/site-packages/AppKit/NibClassBuilder.py", line 144,
in _extractClassesFromNibFromBundle
    raise NibLoaderError, ("Could not find nib named '%s' "
AppKit.NibClassBuilder.NibLoaderError: Could not find nib named 'MainMenu' in
bundle 'NSBundle </usr/bin> 

(I assume that if NibClassLoader.py wasn't used here, it would exit with a
similar message from NSApplicationMain().)

I'm not sure, but I _think_ it's because 'exec' in /bin/sh isn't exactly the
same as execve(). Does this sound plausible? If so, what _is_ the equivalent of
execve() in sh? Also: the exporting of PYTHONPATH doesn't work as written above:
os.environ doesn't show it.

Any clues? (googling for "execve" and "sh" only gives me hits for
execve("/bin/sh", ...); ;-)

Just

Re: [Pyobjc-dev] Embedding in Apps & Loading preferences Bundles

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

On Tuesday, Nov 26, 2002, at 02:56 Europe/Amsterdam, Peter Montagner 
wrote:

>
> On Tuesday, November 26, 2002, at 01:24 AM, Ronald Oussoren wrote:
>
>> On Monday, Nov 25, 2002, at 14:37 Europe/Amsterdam, bb...@ma... 
>> wrote:
>>
>>> Key challenge:   The classes that are subsequently subclassed by the 
>>> loaded module must have instance variables that look/feel/act 
>>> exactly like the iVars in the original parent class....
>>
>> That should be no problem, PyObjC can already to that. For me the key 
>> challenge is finding a way to initialize an embedded python 
>> interpreter and run a python script when the plugin bundle is loaded 
>> (and for bonus points: Initialize exactly 1 interpreter, even when 
>> loading more than 1 python-based plugin)
>
> Will this work with Apple's python? Or are you planning on shipping a 
> full python distro with the plugin? Otherwise it'd be a nice hack but 
> it wouldn't be distributable.

It won't work with Apple's python. You'd therefore be required to 
either ship a partial python distribution with the plugin or somehow 
build a Python shared library that is compatible with Apple's python. 
The latter would be kind of a hack, but probably doable.

Ronald

Re: [Pyobjc-dev] Embedding in Apps & Loading preferences Bundles

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

On Monday, November 25, 2002, at 08:56 PM, Peter Montagner wrote:
> On Tuesday, November 26, 2002, at 01:24 AM, Ronald Oussoren wrote:
>> On Monday, Nov 25, 2002, at 14:37 Europe/Amsterdam, bb...@ma... 
>> wrote:
>>> Key challenge:   The classes that are subsequently subclassed by the 
>>> loaded module must have instance variables that look/feel/act 
>>> exactly like the iVars in the original parent class....
>> That should be no problem, PyObjC can already to that. For me the key 
>> challenge is finding a way to initialize an embedded python 
>> interpreter and run a python script when the plugin bundle is loaded 
>> (and for bonus points: Initialize exactly 1 interpreter, even when 
>> loading more than 1 python-based plugin)
> Will this work with Apple's python? Or are you planning on shipping a 
> full python distro with the plugin? Otherwise it'd be a nice hack but 
> it wouldn't be distributable.

It would only work with a distribution of python that has an embeddable 
library.... i.e. not the Apple build.

>>>> Finding a way to automaticly execute a function when 'our' shared 
>>>> library is loaded will probably the most problematic part of this. 
>>>> That is: Whenever the 'pyobjcextension' shared libary is loaded 
>>>> 'initPyObjCExtension' in that library should run. I haven't looked 
>>>> into this yet and this may well be either trivial or impossible.
>>> Assuming that the target application is ObjC, simply creating a 
>>> +(void)load in a class/category within the dylib should be enough to 
>>> cause a hunk of code to be executing that can call 
>>> -initPyObjCExtension.   There is also a similar mechanism in the 
>>> pure C++ world.
>> I hadn't though of using a (dummy) class to do this. Thanks for the 
>> tip.
> There are problems with +(void)load. Namely, you can't guarantee the 
> order of +(void)load methods, so you can't rely on any other classes. 
> Well, certainly not those in the same bundle. This doesn't sound like 
> a problem in this case but it is something to be wary of.

Not really a problem;   in any given hunk o' dynamically loadable code, 
provide a single +load or ensure that your initialization code is only 
executed once.   Alternatively, the code invoked as a part of the 
static initializer (which +load really is) should *only* initialize the 
class in question, never touching anything else.

If the initialization code *must* be executed at a point in time when 
the rest of the framework has been loaded/initialized, then one can 
typically use something like NSNotificationCenter to cause a notif to 
be sent (exact mechanism varies according to environment).

[In all my experience as a developer, I find it surprising the number 
of times folks have been tripped up by the undefined order of execution 
inflicted upon really early initialization code...   The NS 3.3 and OS 
4.2 AppKit's both suffered from really nasty bugs if you touched 
classes in the wrong order, thereby causing +initialize to b executed 
in an "unexpected" order, very bad things would happen.  I'm surprised 
at the number of times I have tripped over this and I should *really* 
know better by now!  In any case, unless explicitly defined... don't 
assume anything prior to main() or at dyna-load time.]

b.bum

Re: [Pyobjc-dev] F-script may be worth a look

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

On Tuesday, November 26, 2002, at 12:28 AM, Peter Montagner wrote:

>
> On Tuesday, November 26, 2002, at 12:02 AM, Ronald Oussoren wrote:
>
>> On Monday, Nov 25, 2002, at 13:01 Europe/Amsterdam, Peter Montagner 
>> wrote:
>>
>>> On Monday, November 25, 2002, at 10:24 PM, Ronald Oussoren wrote:
>>>
>>>> That might be usefull for PyObjC as well. I have something like 
>>>> this on my private wishlist: I'd like to be able to write (system) 
>>>> prefpanes in Python.
>>>
>>> Interesting. Well, if you want to take a crack at it, F-Script 
>>> Anywhere uses libPatch to force itself into a running application. 
>>> libPatch seems to be a very hard to get bit of code. 
>>> http://www.phasic.com/~arwyn/libPatch-1.2.tgz
>>
>> Some time in the future I will probably try to write whatever is 
>> needed to get prefpanes to work. That is probably simular to what is 
>> needed to write plugins for programs that use Objective-C classes as 
>> plugins (e.g. which is basicly what the system preferences 
>> application is doing). I probably won't work on forcing this onto 
>> unwilling applications.
>>
>> Finding a way to automaticly execute a function when 'our' shared 
>> library is loaded will probably the most problematic part of this. 
>> That is: Whenever the 'pyobjcextension' shared libary is loaded 
>> 'initPyObjCExtension' in that library should run. I haven't looked 
>> into this yet and this may well be either trivial or impossible.
>
> Well, you could override +alloc on the Principal Class and when the 
> plugin is loaded you could do what ever is needed to do the python 
> stuff. I'm not sure how you are going to get a python interpreter into 
> a running third party app (ie, SysPrefs). One solution would be to use 
> Distributed Objects. The bundle loaded could launch a python 
> interpreter and start listening for a DO connection. The python 
> interpreter would then connect to the loaded bundle. When the 
> connection is made, the loaded module would return the DO proxy (from 
> the +alloc method). Returning from +alloc before a connection is made 
> would be pretty pointless. The Principal Class would never really 
> exist as an instance because a remote object would take its place.
>
> I haven't exactly thought this through but it seems possible. It is a 
> bit of a kludge but I don't see any other way to do it, especially 
> with Apple's non-embeddable python. It would be fun if someone killed 
> the python interpreter while System Preferences was still open! Also, 
> this method relies on DO working in PyObjC which it currently doesn't 
> seem to.

OK, I can answer my own question. This is basically impossible. You 
can't pass an NSView across an NSConnection and expect it to work in 
the new application. The reason is very obvious: It will try to do its 
GUI stuff locally instead of on the other side of the connection. This 
is entirely reasonable. Ignore the above message.

Peter

Re: [Pyobjc-dev] Embedding in Apps & Loading preferences Bundles

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

On Tuesday, November 26, 2002, at 01:24 AM, Ronald Oussoren wrote:

> On Monday, Nov 25, 2002, at 14:37 Europe/Amsterdam, bb...@ma... wrote:
>
>> Key challenge:   The classes that are subsequently subclassed by the 
>> loaded module must have instance variables that look/feel/act exactly 
>> like the iVars in the original parent class....
>
> That should be no problem, PyObjC can already to that. For me the key 
> challenge is finding a way to initialize an embedded python 
> interpreter and run a python script when the plugin bundle is loaded 
> (and for bonus points: Initialize exactly 1 interpreter, even when 
> loading more than 1 python-based plugin)

Will this work with Apple's python? Or are you planning on shipping a 
full python distro with the plugin? Otherwise it'd be a nice hack but 
it wouldn't be distributable.


>>> Finding a way to automaticly execute a function when 'our' shared 
>>> library is loaded will probably the most problematic part of this. 
>>> That is: Whenever the 'pyobjcextension' shared libary is loaded 
>>> 'initPyObjCExtension' in that library should run. I haven't looked 
>>> into this yet and this may well be either trivial or impossible.
>>
>> Assuming that the target application is ObjC, simply creating a 
>> +(void)load in a class/category within the dylib should be enough to 
>> cause a hunk of code to be executing that can call 
>> -initPyObjCExtension.   There is also a similar mechanism in the pure 
>> C++ world.
>
> I hadn't though of using a (dummy) class to do this. Thanks for the 
> tip.

There are problems with +(void)load. Namely, you can't guarantee the 
order of +(void)load methods, so you can't rely on any other classes. 
Well, certainly not those in the same bundle. This doesn't sound like a 
problem in this case but it is something to be wary of.

Peter