pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

[code committed]

Unfortunately, I'm not having any luck modifying WebServicesTool to use  
the loader.  If I do:

from AppKit import NibLoader

NibLoader.addNibFromBundle( "MainMenu.nib" )

class WSTApplicationDelegate (NibLoader):
   def newConnectionAction_(self, sender):
      
WSTConnectionWindowController.connectionWindowController().showWindow_(s 
ender)

   def applicationDidFinishLaunching_(self, aNotification):
     self.newConnectionAction_(None)

... then, at runtime, I see ...

2002-11-15 11:26:58.092 Web Services Tool[24489] Process ID is: 24489 (
	gdb /usr/bin/python 24489
  to debug)
2002-11-15 11:27:08.624 Web Services Tool[24489] Unknown class  
`WSTApplicationDelegate' in nib file, using `NSObject' instead.
2002-11-15 11:27:08.639 Web Services Tool[24489] Could not connect the  
action newConnectionAction: to target of class NSObject

... It seems that the WSTApplicationDelegate class is not being defined  
in a fashion that is found by the ObjC side of the bridge?   Actually,  
If I do...

     print WSTApplicationDelegate
     print dir(WSTApplicationDelegate)

... after the class definition, the output changes to ...

<module '?' (built-in)>
[]
2002-11-15 11:29:30.565 Web Services Tool[24519] Unknown class  
`WSTApplicationDelegate' in nib file, using `NSObject' instead.
2002-11-15 11:29:30.567 Web Services Tool[24519] Could not connect the  
action newConnectionAction: to target of class NSObject

I'm confused now.

b.bum

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

On Thursday, November 14, 2002, at 07:09 PM, Just van Rossum wrote:
> Today, instead of learning how to do useful things with Cocoa <wink>, 
> I wrote a
> replacement for mknibwrapper/objc.classnib.py, that does the same 
> thing at
> runtime, making nibwrapper.py files superfluous.

Excellent.

> This abviously has some startup time hit, but it seems quite quick. 
> Not that I
> think that having to generate nibwrapper.py files is all that bad, I 
> was just
> looking for an opportunity to learn a thing or two, eg. about 
> metaclasses...

The startup is minor in comparison to other startup issues and to the 
unarchival of the object graph contained in the NIB [I would think].   
Small price to pay in return for one less dependency within the 
development environment.

> It will parse all nibs specified and will build dummy test classes for 
> all found
> nib classes and print some blurb to stdout. I've tested this on a few 
> nibs found
> in apps that came with the OS as well as with all the nibs in the 
> Examples
> folder, and apart from some classes that don't seem to have a 
> SUPERCLASS
> attribute, building the test classes seems to work.

If a class doesn't have a SUPERCLASS, it should default to NSObject, I 
would think.  I'll look into this as I convert some of my projects over 
to using NibLoader.

> Obviously much of the code is ripped straight from objc/classnib.py.
>
> Useful?

Very.

Added to the CVS repository as Lib/AppKit/NibLoader.py.   I modified it 
to skip FirstResponder -- a class does not need to be created for 
FirstResponder (target/action directed at first responder indicates to 
the event handling system that the action should be sent to the first 
object in the responder chain that responds to the action).

I also added an addNibFromBundle() function that can be used like this:

     NibLoader.addNibFromBundle( "MainMenu.nib" )

It takes an optional second argument if you want to point it at a 
particular bundle or framework;  defaults to NSBundle.mainBundle().   
It uses NSBundle's pathForResource:ofType: method to find the NIB and, 
as such, will automatically load the NIB of the correct language in 
localized apps.

Ronald:  Does this supersede classnib?  I.e. should classnib be removed?

b.bum


b.bum
No Chunks...
	... No Foul!

[Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

Today, instead of learning how to do useful things with Cocoa <wink>, I wrote a
replacement for mknibwrapper/objc.classnib.py, that does the same thing at
runtime, making nibwrapper.py files superfluous.

This abviously has some startup time hit, but it seems quite quick. Not that I
think that having to generate nibwrapper.py files is all that bad, I was just
looking for an opportunity to learn a thing or two, eg. about metaclasses...

The attached module lets you do this:


  [...more imports snipped...]
  from NibLoader import NibLoader, addNib
  
  # (the addNib() could be done elewhere, or could be done more
  # concisely with a helper funciton in the NibLoader module)
  addNib(os.path.join(sys.path[0], "English.lproj/MainMenu.nib"))
  
  class PyModel(NibLoader, NSTableDataSource):
      ...etc...


addNib() parses a nib file and sucks the class info out of it.
NibLoader is a magic class (or rather, has a magic superclass) that will make
sure the subclass has the right base class, and will populate it with all the
stuff that was normally generated in the nibwrapper file.

So far I've only tested it with the TableModel demo: it works for me.

The NibLoader module contains a tiny test program: you can invoke it from the
command line like so:

  % python NibLoader.py <path-to-nib> [more paths to nibs]

It will parse all nibs specified and will build dummy test classes for all found
nib classes and print some blurb to stdout. I've tested this on a few nibs found
in apps that came with the OS as well as with all the nibs in the Examples
folder, and apart from some classes that don't seem to have a SUPERCLASS
attribute, building the test classes seems to work.

Obviously much of the code is ripped straight from objc/classnib.py.

Useful?

Just

[Pyobjc-dev] Re: current CVS won't build on Dual 1 GHz/Jaguar

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

I have made some other changes in my tree that are not yet good enough 
to be pushed into the repository. I therefore tried to be smart and 
checked in only the files that I changed while debugging your problem 
... or so I though.

It should build if you update now or you can just add 
Modules/objc/alloc_hack.m to the list of files in setup.py (just above 
module.m works fine for me).

Ronald
On Thursday, Nov 14, 2002, at 03:38 Europe/Amsterdam, Steven D. Arnold 
wrote:

> On 11/13/02 4:16 PM, "Ronald Oussoren" <ous...@ci...> wrote:
>
>> I've reproduced the problem in some pure Objective-C code:
>>  #import <AppKit/AppKit.h>
>>
>>  int main(void)
>>  {
>>        id nil_obj = nil;
>>        id pool = [[NSAutoreleasePool alloc] init];
>>
>>        id inv = [NSInvocation invocationWithMethodSignature:
>>                [NSMethodSignature signatureWithObjCTypes:"@@:"]];
>>
>>        [inv retain];
>>        [inv setTarget:[NSTextView class]];
>>        [inv setSelector:@selector(alloc)];
>>        [inv invoke];
>>        [inv setReturnValue:&nil_obj];
>>        return 0;
>>  }
>>
>> This crashes when using NSTextView, and works when using NSTableView.
>>
>> This looks like a problem with Apple code.
>
> Interesting...
>
>> I've checked in a workaround that at least should allow
>> NSTextView.alloc().init().
>
> I updated from CVS and tried unsuccessfully to build.  The session is 
> below:
>
> [thoth@paranoia:~/Source/pyobjc] > python setup.py clean
> running clean
> removing 'build/temp.darwin-6.1-Power Macintosh-2.3' (and everything 
> under
> it)
> [thoth@paranoia:~/Source/pyobjc] > sudo python setup.py install
> running install
> running build
> running build_py
> running build_ext
> building 'objc._objc' extension
> creating build/temp.darwin-6.1-Power Macintosh-2.3
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c 
> Modules/objc/objc-class.m
> -o build/temp.darwin-6.1-Power Macintosh-2.3/objc-class.o -g -O0
> -DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c
> Modules/objc/instance-var.m -o build/temp.darwin-6.1-Power
> Macintosh-2.3/instance-var.o -g -O0 -DOBJC_PARANOIA_MODE
> -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c 
> Modules/objc/selector.m -o
> build/temp.darwin-6.1-Power Macintosh-2.3/selector.o -g -O0
> -DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
> Modules/objc/selector.m: In function `objcsel_call':
> Modules/objc/selector.m:457: warning: unused variable `obj'
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c 
> Modules/objc/module.m -o
> build/temp.darwin-6.1-Power Macintosh-2.3/module.o -g -O0
> -DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
> Modules/objc/module.m: In function `init_objc':
> Modules/objc/module.m:233: warning: implicit declaration of function
> `ObjC_RegisterStdStubs'
> Modules/objc/module.m:247: warning: implicit declaration of function
> `ObjC_InstallAllocHack'
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c 
> Modules/objc/class-list.m
> -o build/temp.darwin-6.1-Power Macintosh-2.3/class-list.o -g -O0
> -DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c
> Modules/objc/OC_PythonString.m -o build/temp.darwin-6.1-Power
> Macintosh-2.3/OC_PythonString.o -g -O0 -DOBJC_PARANOIA_MODE
> -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c
> Modules/objc/objc_support.m -o build/temp.darwin-6.1-Power
> Macintosh-2.3/objc_support.o -g -O0 -DOBJC_PARANOIA_MODE
> -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c 
> Modules/objc/objc_util.m
> -o build/temp.darwin-6.1-Power Macintosh-2.3/objc_util.o -g -O0
> -DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c
> Modules/objc/OC_PythonObject.m -o build/temp.darwin-6.1-Power
> Macintosh-2.3/OC_PythonObject.o -g -O0 -DOBJC_PARANOIA_MODE
> -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c
> Modules/objc/informal-protocol.m -o build/temp.darwin-6.1-Power
> Macintosh-2.3/informal-protocol.o -g -O0 -DOBJC_PARANOIA_MODE
> -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c
> Modules/objc/OC_PythonDictionary.m -o build/temp.darwin-6.1-Power
> Macintosh-2.3/OC_PythonDictionary.o -g -O0 -DOBJC_PARANOIA_MODE
> -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c
> Modules/objc/OC_PythonInt.m -o build/temp.darwin-6.1-Power
> Macintosh-2.3/OC_PythonInt.o -g -O0 -DOBJC_PARANOIA_MODE
> -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c
> Modules/objc/OC_PythonArray.m -o build/temp.darwin-6.1-Power
> Macintosh-2.3/OC_PythonArray.o -g -O0 -DOBJC_PARANOIA_MODE
> -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c 
> Modules/objc/pyobjc-api.m
> -o build/temp.darwin-6.1-Power Macintosh-2.3/pyobjc-api.o -g -O0
> -DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c 
> Modules/objc/objc-object.m
> -o build/temp.darwin-6.1-Power Macintosh-2.3/objc-object.o -g -O0
> -DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c 
> Modules/objc/super-call.m
> -o build/temp.darwin-6.1-Power Macintosh-2.3/super-call.o -g -O0
> -DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c 
> Modules/objc/register.m -o
> build/temp.darwin-6.1-Power Macintosh-2.3/register.o -g -O0
> -DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
> Modules/objc/register.m:12: warning: function declaration isn't a 
> prototype
> Modules/objc/register.m: In function `ObjC_RegisterStdStubs':
> Modules/objc/register.m:56720: warning: passing arg 2 of pointer to 
> function
> from incompatible pointer type
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c 
> Modules/objc/ObjCPointer.m
> -o build/temp.darwin-6.1-Power Macintosh-2.3/ObjCPointer.o -g -O0
> -DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
> -no-cpp-precomp -I/usr/local/include/python2.3 -c
> Modules/objc/class-builder.m -o build/temp.darwin-6.1-Power
> Macintosh-2.3/class-builder.o -g -O0 -DOBJC_PARANOIA_MODE
> -DPyOBJC_UNIQUE_PROXY -DMACOSX
> gcc -bundle -bundle_loader /usr/local/bin/python 
> build/temp.darwin-6.1-Power
> Macintosh-2.3/objc_util.o build/temp.darwin-6.1-Power
> Macintosh-2.3/objc_support.o build/temp.darwin-6.1-Power
> Macintosh-2.3/class-builder.o build/temp.darwin-6.1-Power
> Macintosh-2.3/class-list.o build/temp.darwin-6.1-Power
> Macintosh-2.3/ObjCPointer.o build/temp.darwin-6.1-Power
> Macintosh-2.3/objc-class.o build/temp.darwin-6.1-Power
> Macintosh-2.3/informal-protocol.o build/temp.darwin-6.1-Power
> Macintosh-2.3/objc-object.o build/temp.darwin-6.1-Power
> Macintosh-2.3/super-call.o build/temp.darwin-6.1-Power
> Macintosh-2.3/selector.o build/temp.darwin-6.1-Power
> Macintosh-2.3/instance-var.o build/temp.darwin-6.1-Power
> Macintosh-2.3/OC_PythonInt.o build/temp.darwin-6.1-Power
> Macintosh-2.3/OC_PythonObject.o build/temp.darwin-6.1-Power
> Macintosh-2.3/OC_PythonString.o build/temp.darwin-6.1-Power
> Macintosh-2.3/OC_PythonArray.o build/temp.darwin-6.1-Power
> Macintosh-2.3/OC_PythonDictionary.o build/temp.darwin-6.1-Power
> Macintosh-2.3/register.o build/temp.darwin-6.1-Power
> Macintosh-2.3/pyobjc-api.o build/temp.darwin-6.1-Power
> Macintosh-2.3/module.o -o build/lib.darwin-6.1-Power
> Macintosh-2.3/objc/_objc.so -g -framework AppKit
> ld: Undefined symbols:
> _ObjC_InstallAllocHack
> Traceback (most recent call last):
>   File "setup.py", line 155, in ?
>     package_dir = { '':'Lib' }
>   File "/usr/local/lib/python2.3/distutils/core.py", line 155, in setup
>     raise SystemExit, "error: " + str(msg)
> SystemExit: error: command 'gcc' failed with exit status 1
>
> steve
> -- 
>
>
>

[Pyobjc-dev] current CVS won't build on Dual 1 GHz/Jaguar

[Steven D. A. <st...@ne...>]

On 11/13/02 4:16 PM, "Ronald Oussoren" <ous...@ci...> wrote:

> I've reproduced the problem in some pure Objective-C code:
>  #import <AppKit/AppKit.h>
> 
>  int main(void)
>  {
>        id nil_obj = nil;
>        id pool = [[NSAutoreleasePool alloc] init];
> 
>        id inv = [NSInvocation invocationWithMethodSignature:
>                [NSMethodSignature signatureWithObjCTypes:"@@:"]];
> 
>        [inv retain];
>        [inv setTarget:[NSTextView class]];
>        [inv setSelector:@selector(alloc)];
>        [inv invoke];
>        [inv setReturnValue:&nil_obj];
>        return 0;
>  }
> 
> This crashes when using NSTextView, and works when using NSTableView.
> 
> This looks like a problem with Apple code.

Interesting...

> I've checked in a workaround that at least should allow
> NSTextView.alloc().init().

I updated from CVS and tried unsuccessfully to build.  The session is below:

[thoth@paranoia:~/Source/pyobjc] > python setup.py clean
running clean
removing 'build/temp.darwin-6.1-Power Macintosh-2.3' (and everything under
it)
[thoth@paranoia:~/Source/pyobjc] > sudo python setup.py install
running install
running build
running build_py
running build_ext
building 'objc._objc' extension
creating build/temp.darwin-6.1-Power Macintosh-2.3
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c Modules/objc/objc-class.m
-o build/temp.darwin-6.1-Power Macintosh-2.3/objc-class.o -g -O0
-DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c
Modules/objc/instance-var.m -o build/temp.darwin-6.1-Power
Macintosh-2.3/instance-var.o -g -O0 -DOBJC_PARANOIA_MODE
-DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c Modules/objc/selector.m -o
build/temp.darwin-6.1-Power Macintosh-2.3/selector.o -g -O0
-DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
Modules/objc/selector.m: In function `objcsel_call':
Modules/objc/selector.m:457: warning: unused variable `obj'
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c Modules/objc/module.m -o
build/temp.darwin-6.1-Power Macintosh-2.3/module.o -g -O0
-DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
Modules/objc/module.m: In function `init_objc':
Modules/objc/module.m:233: warning: implicit declaration of function
`ObjC_RegisterStdStubs'
Modules/objc/module.m:247: warning: implicit declaration of function
`ObjC_InstallAllocHack'
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c Modules/objc/class-list.m
-o build/temp.darwin-6.1-Power Macintosh-2.3/class-list.o -g -O0
-DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c
Modules/objc/OC_PythonString.m -o build/temp.darwin-6.1-Power
Macintosh-2.3/OC_PythonString.o -g -O0 -DOBJC_PARANOIA_MODE
-DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c
Modules/objc/objc_support.m -o build/temp.darwin-6.1-Power
Macintosh-2.3/objc_support.o -g -O0 -DOBJC_PARANOIA_MODE
-DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c Modules/objc/objc_util.m
-o build/temp.darwin-6.1-Power Macintosh-2.3/objc_util.o -g -O0
-DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c
Modules/objc/OC_PythonObject.m -o build/temp.darwin-6.1-Power
Macintosh-2.3/OC_PythonObject.o -g -O0 -DOBJC_PARANOIA_MODE
-DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c
Modules/objc/informal-protocol.m -o build/temp.darwin-6.1-Power
Macintosh-2.3/informal-protocol.o -g -O0 -DOBJC_PARANOIA_MODE
-DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c
Modules/objc/OC_PythonDictionary.m -o build/temp.darwin-6.1-Power
Macintosh-2.3/OC_PythonDictionary.o -g -O0 -DOBJC_PARANOIA_MODE
-DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c
Modules/objc/OC_PythonInt.m -o build/temp.darwin-6.1-Power
Macintosh-2.3/OC_PythonInt.o -g -O0 -DOBJC_PARANOIA_MODE
-DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c
Modules/objc/OC_PythonArray.m -o build/temp.darwin-6.1-Power
Macintosh-2.3/OC_PythonArray.o -g -O0 -DOBJC_PARANOIA_MODE
-DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c Modules/objc/pyobjc-api.m
-o build/temp.darwin-6.1-Power Macintosh-2.3/pyobjc-api.o -g -O0
-DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c Modules/objc/objc-object.m
-o build/temp.darwin-6.1-Power Macintosh-2.3/objc-object.o -g -O0
-DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c Modules/objc/super-call.m
-o build/temp.darwin-6.1-Power Macintosh-2.3/super-call.o -g -O0
-DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c Modules/objc/register.m -o
build/temp.darwin-6.1-Power Macintosh-2.3/register.o -g -O0
-DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
Modules/objc/register.m:12: warning: function declaration isn't a prototype
Modules/objc/register.m: In function `ObjC_RegisterStdStubs':
Modules/objc/register.m:56720: warning: passing arg 2 of pointer to function
from incompatible pointer type
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c Modules/objc/ObjCPointer.m
-o build/temp.darwin-6.1-Power Macintosh-2.3/ObjCPointer.o -g -O0
-DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double
-no-cpp-precomp -I/usr/local/include/python2.3 -c
Modules/objc/class-builder.m -o build/temp.darwin-6.1-Power
Macintosh-2.3/class-builder.o -g -O0 -DOBJC_PARANOIA_MODE
-DPyOBJC_UNIQUE_PROXY -DMACOSX
gcc -bundle -bundle_loader /usr/local/bin/python build/temp.darwin-6.1-Power
Macintosh-2.3/objc_util.o build/temp.darwin-6.1-Power
Macintosh-2.3/objc_support.o build/temp.darwin-6.1-Power
Macintosh-2.3/class-builder.o build/temp.darwin-6.1-Power
Macintosh-2.3/class-list.o build/temp.darwin-6.1-Power
Macintosh-2.3/ObjCPointer.o build/temp.darwin-6.1-Power
Macintosh-2.3/objc-class.o build/temp.darwin-6.1-Power
Macintosh-2.3/informal-protocol.o build/temp.darwin-6.1-Power
Macintosh-2.3/objc-object.o build/temp.darwin-6.1-Power
Macintosh-2.3/super-call.o build/temp.darwin-6.1-Power
Macintosh-2.3/selector.o build/temp.darwin-6.1-Power
Macintosh-2.3/instance-var.o build/temp.darwin-6.1-Power
Macintosh-2.3/OC_PythonInt.o build/temp.darwin-6.1-Power
Macintosh-2.3/OC_PythonObject.o build/temp.darwin-6.1-Power
Macintosh-2.3/OC_PythonString.o build/temp.darwin-6.1-Power
Macintosh-2.3/OC_PythonArray.o build/temp.darwin-6.1-Power
Macintosh-2.3/OC_PythonDictionary.o build/temp.darwin-6.1-Power
Macintosh-2.3/register.o build/temp.darwin-6.1-Power
Macintosh-2.3/pyobjc-api.o build/temp.darwin-6.1-Power
Macintosh-2.3/module.o -o build/lib.darwin-6.1-Power
Macintosh-2.3/objc/_objc.so -g -framework AppKit
ld: Undefined symbols:
_ObjC_InstallAllocHack
Traceback (most recent call last):
  File "setup.py", line 155, in ?
    package_dir = { '':'Lib' }
  File "/usr/local/lib/python2.3/distutils/core.py", line 155, in setup
    raise SystemExit, "error: " + str(msg)
SystemExit: error: command 'gcc' failed with exit status 1

steve
-- 

Re: [Pyobjc-dev] NSTextView weirdness

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

Is it the case that the class object is being released to the point of 
death by the NSInvocation (and, subsequently, by the Python wrapper for 
the ObjC object)?

No... that isn't it... more like NSTextView.alloc() is returning 
something similar to NSArray.alloc() that behaves in a slightly 
different and more volatile fashion?

Nuts.

Yes, this was a part of debugging Steve's earlier problem and it still 
doesn't address that problem.

> If I evaluate NSTextView.setEditable_ before calling obj.setEditable_ 
> all goes well. I'm still checking why this is necessary.

I have not a clue and will be quite interested in the answer!

b.bum

On Wednesday, November 13, 2002, at 04:16 PM, Ronald Oussoren wrote:

> Some more debugging shows:
>
> The test code is too complex, the code below also causes a crash:
>
> from AppKit import NSTextView
> NSTextView.alloc()
>
> .....

Re: [Pyobjc-dev] NSTextView weirdness

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

Some more debugging shows:

The test code is too complex, the code below also causes a crash:

from AppKit import NSTextView
NSTextView.alloc()

What I don't fully understand is the output of the following program:
   #import <AppKit/AppKit.h>

   int main(void)
   {
         id pool = [[NSAutoreleasePool alloc] init];

         id obj = [NSTextView alloc];

         NSLog(@"obj: %p [%d]\n", obj, [obj retainCount]);

         id withInit = [obj init];

         NSLog(@"withInit: %p [%d]\n", withInit, [withInit retainCount]);
         NSLog(@"same? %d", obj == withInit);

         [pool release];
         NSLog(@"obj: %p [%d]\n", obj, [obj retainCount]);

         return 0;
   }

This emits:
   2002-11-13 20:46:02.303 t[1448] obj: 0xb0890 [1]
   2002-11-13 20:46:02.355 t[1448] withInit: 0xb0890 [3]
   2002-11-13 20:46:02.357 t[1448] same? 1
   2002-11-13 20:46:02.359 t[1448] obj: 0xb0890 [2]

The retainCount after [[NSTextView alloc] init] is 3, and then 
autoreleased???

I've reproduced the problem in some pure Objective-C code:
   #import <AppKit/AppKit.h>

   int main(void)
   {
         id nil_obj = nil;
         id pool = [[NSAutoreleasePool alloc] init];

         id inv = [NSInvocation invocationWithMethodSignature:
                 [NSMethodSignature signatureWithObjCTypes:"@@:"]];

         [inv retain];
         [inv setTarget:[NSTextView class]];
         [inv setSelector:@selector(alloc)];
         [inv invoke];
         [inv setReturnValue:&nil_obj];
         return 0;
   }

This crashes when using NSTextView, and works when using NSTableView.

This looks like a problem with Apple code.

I've checked in a workaround that at least should allow 
NSTextView.alloc().init(). The following code now works:
   from AppKit import NSTextView

   for i in range(10):
         print NSTextView.alloc().init()
   print "done"

The workaround consists of adding custom wrappers for +alloc. This is 
intented to be a temporary workaround.

Hmm, if your debugging the NSInternalConsistency problem from Arnolds 
message earlier today this isn't very helpfull, the problem doesn't go 
away.

If I evaluate NSTextView.setEditable_ before calling obj.setEditable_ 
all goes well. I'm still checking why this is necessary.

Ronald

[Pyobjc-dev] NSTextView weirdness

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

Steve Arnold and I have been tracking down a bug related to NSTextView 
in the current [from cvs] version of the module.  It is a nasty bug 
that can cause crashes, etc...

I updated Examples/method-weirdness.py to demonstrate the bug 
[basically, generalized the code such that we can trivially add new 
class/method tests -- I smell a unit test in here somewhere].

As it currently stands, method-weirdness.py causes the bridge to crash. 
   If you change the #if 1 to #if 0 in the middle of 
execute_and_pythonify_objc_method() in objc_sumpport.m, the crash moves 
until later-- until the objc_object is dealloc'd.

It looks like the bridge is sending -release to a class object-- 
NSTextView-- and this leads to the crash, but I'm not 100% certain this 
is the case.   Hopefully, it is as it would be a bug in the AppKit that 
is very easy to work around (is class?:  don't release!).

b.bum

Re: [Pyobjc-dev] Python rather than ObjC for main?

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

On Tuesday, Nov 12, 2002, at 16:43 Europe/Amsterdam, bb...@ma... wrote:

>> Done.  Main.py is now __main__.py? Good idea. My only problem with 
>> the current scheme is that you have to add import statements for your 
>> source. Is there away this could be automatically, or better yet 
>> dynamically? It would be nice if the user didn't have to touch 
>> __main__.py manually. It would be even nicer if __main__.py could 
>> figure out where the other stuff is itself.
>
> It would be nice if the __main__.py could have a bunch of the 
> repetitive code ripped out.  Wouldn't be hard;  the whole framework 
> bootstrapper could be moved to the AppKit module as an extension and 
> that is the bulk of the code.
>

It might be usefull to make __main__.py a part of pyobjc that is copied 
into
the application and use that to load the 'PrincipalPythonFile'. That 
way we can
perform all magic that is needed to startup the .app without bothering 
the user with it (e.g. user code would keep working if/when we move to 
a CFBundleExecutable with an embedded python).

Ronald

Re: [Pyobjc-dev] Possibly dumb question

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

bb...@ma... wrote:

Thanks for the explanation, it makes sense.

> In any case, that final '_' is useful in that it gives immediate 
> indication that "Hey, I'm writing this method or call that method very 
> much in light of the presence of Objective-C".

I see. Ah, (light bulb goes on), the underscores are a 1/1 replacement of :'s.
Good to think about it that way.

Just

[Pyobjc-dev] NSInternalInconsistencyException when calling a method on an NSTextView

[Steven D. A. <st...@ne...>]

I'm running into a problem trying to control an NSTextView from code.  Here
is a truncated view of my controller class:

class DictManager( Foundation.NSObject, AppKit.NSTableDataSource ):

    commentary = objc.IBOutlet( 'commentary' )
    definition = objc.IBOutlet( 'definition' )
        
    def toggle_word_inspector( self ):
        if self.word_inspector_enabled:
            self.word_inspector_enabled = enabled = 0
        else:
            self.word_inspector_enabled = enabled = 1
        self.definition.setEditable_( enabled )
        self.commentary.setEditable_( enabled )

Note that both commentary and definition are NSTextView objects.  I created
the form in IB, dragged the two objects to the form, created outlets for the
class named as above, and connected them.  When I click a line in an
NSTableView in the same form, toggle_word_inspector() is called.  When it
reaches the first setEditable line, it raises an
NSInternalInconsistencyError.

Note that I run into the same problem if I use some other method from the
NSTextView class as well, such as isEditable().

Anyone seen this before?

steve
-- 

Re: [Pyobjc-dev] Possibly dumb question

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

It eliminates an ambiguity for methods that take no arguments vs. one 
argument.

I.e. there is a difference between this...

     foo.doSomething()

...  and this ...

     foo.doSomething( bar )

The first is the method 'doSomething', the second should be 
'doSomething:'.   While we could have the bridge count the args and 
silently fix the second case, such actions generally lead to ambiguity 
and confusion -- and, potentially, maintenance nightmares.

In any case, that final '_' is useful in that it gives immediate 
indication that "Hey, I'm writing this method or call that method very 
much in light of the presence of Objective-C".

b.bum

On Tuesday, November 12, 2002, at 04:10 PM, Just van Rossum wrote:

> Do the trailing underscores in (Py)Obj-C method names have a purpose? 
> I don't
> (yet) see why this (for example)
>
>    [path setLineDash:dash count:4 phase:20.0]
>
> should translate to
>
>    path.setLineDash_count_phase_(dash, 4, 20.0)
>
> instead of
>
>    path.setLineDash_count_phase(dash, 4, 20.0)
>
> Just
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> To learn the basics of securing your web site with SSL,
> click here to get a FREE TRIAL of a Thawte Server Certificate:
> http://www.gothawte.com/rd522.html
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
b.bum
Are you laughing?
	... they are.

[Pyobjc-dev] Possibly dumb question

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

Do the trailing underscores in (Py)Obj-C method names have a purpose? I don't
(yet) see why this (for example)

   [path setLineDash:dash count:4 phase:20.0]

should translate to

   path.setLineDash_count_phase_(dash, 4, 20.0)

instead of

   path.setLineDash_count_phase(dash, 4, 20.0)

Just

Re: [Pyobjc-dev] Python rather than ObjC for main?

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

Just van Rossum wrote:

> Here's what I just cooked up, and works for me:

Slight improvement:

  #!/usr/bin/env python

  import os
  from sys import argv, executable
  realmain = os.path.join(os.path.dirname(os.path.dirname(argv[0])),
                          "Resources", "realmain.py")
  argv.insert(1, realmain)
  os.execve(executable, argv, os.environ)

Just

Re: [Pyobjc-dev] Python rather than ObjC for main?

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

> >>> BTW:  There is nothing app specific about the bootstrap executable.  
> >>> You don't even need to compile it to use it in another project-- 
> >>> just add a copy files phase that copies the executable into the 
> >>> Executables area of the app wrapper and make sure that the 
> >>> executable name attribute in the info dictionary of the app wrapper 
> >>> is set correctly.
> >>
> >> Yeah, the first thing I tried was a python script as the executable 
> >> that mirrors bin-python-main.m ie. it calls the python version of 
> >> exec(). It works without any problems but as you said, there isn't 
> >> any point.
> >
> > There might be -- if it allows the bootstrapper to check for the 
> > presence of a working pyobjc environment without a huge amount of 
> > cost, that could be very valuable.
> >
> > Do you happen to have the code around?

Here's what I just cooked up, and works for me:

  #!/usr/bin/env python
  
  import os
  from sys import argv
  realmain = os.path.join(os.path.dirname(argv[0]), "realmain.py")
  argv.insert(1, realmain)
  os.execve("/usr/bin/python", argv, os.environ)

I must say, compared to the overhead of loading objc, AppKit, Foundation, etc.,
the overhead of having this in Python rather than Obj-C seems neglectable.

It took me a (relatively) long time (being an Obj-C newbie) to figure out that
main.m boils down to the above... It also has the advantage (for me at least)
that you I build apps without using Project Builder.

Just

Re: [Pyobjc-dev] Python rather than ObjC for main?

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

On Wednesday, November 13, 2002, at 02:43 AM, bb...@ma... wrote:

> On Friday, November 8, 2002, at 09:38 PM, Peter Montagner wrote:
>> On Saturday, November 9, 2002, at 04:56 AM, bb...@ma... wrote:
>>> BTW:  There is nothing app specific about the bootstrap executable.  
>>> You don't even need to compile it to use it in another project-- 
>>> just add a copy files phase that copies the executable into the 
>>> Executables area of the app wrapper and make sure that the 
>>> executable name attribute in the info dictionary of the app wrapper 
>>> is set correctly.
>>
>> Yeah, the first thing I tried was a python script as the executable 
>> that mirrors bin-python-main.m ie. it calls the python version of 
>> exec(). It works without any problems but as you said, there isn't 
>> any point.
>
> There might be -- if it allows the bootstrapper to check for the 
> presence of a working pyobjc environment without a huge amount of 
> cost, that could be very valuable.
>
> Do you happen to have the code around?

Nope, I trashed it. It really wasn't anything special. I just took the 
Objective-C code and line by line converted it to Python code. I also 
took a lot of shortcuts such as hardcoding the framework paths send to 
__main__.py.


>>>> I think I know what will help me: a proper build of python. So what 
>>>> is recommended? CVS python? Stable python? Fink?
>>>
>>> Fink rocks.
>>
>> I haven't got fink for 10.2 yet. How different is it from stable 
>> python?
>
> There are two python 2.2 packages in Fink;  with X11 and without.   
> Take your pick.   The resulting build isn't different from a stable 
> python build except that it does not build with SSL support in the 
> socket module [long list of reasons-- some good, some not].  Not a big 
> deal;   building the socket module standalone proved to be very > easy...
>
>     http://pyobjc.sourceforge.net/software/

In that case I'll just download it from www.python.org. OK, done.

Hmm... the embeddable library it builds seems to be a static archive. 
How does one turn that into a dylib? Otherwise it isn't much cheaper 
code size wise to just including a full python build in the .app 
wrapper.

>>
>>>>> In any case, all of this-- the whole execve() style bootstrapper-- 
>>>>> is just a hack that'll go away as soon as we have an embeddable 
>>>>> build of Python shipping with OS X.
>>>>
>>>> Yeah, I know. I just had the kluge alert going off in my head and I 
>>>> felt compelled to try and fix it. Anything other than the current 
>>>> hack is going to be an even bigger hack. You guys have done a great 
>>>> job.
>>>
>>> Thanks.  It just got better.  If you cvs update the pyobjc source 
>>> tree, the new Cocoa-Python project template has been cleaned up a 
>>> bit.   BTW:  You can create a symlink from /Developer/ProjectBuilder 
>>> Extras/Project Templates/... wherever ... to the project template(s) 
>>> in the pyobjc source tree directly.   Just make sure you don't end 
>>> up w/a .pbxuser file in the template pbproj....
>>
>> Done.  Main.py is now __main__.py? Good idea. My only problem with 
>> the current scheme is that you have to add import statements for your 
>> source. Is there away this could be automatically, or better yet 
>> dynamically? It would be nice if the user didn't have to touch 
>> __main__.py manually. It would be even nicer if __main__.py could 
>> figure out where the other stuff is itself.
>
> It would be nice if the __main__.py could have a bunch of the 
> repetitive code ripped out.  Wouldn't be hard;  the whole framework 
> bootstrapper could be moved to the AppKit module as an extension and 
> that is the bulk of the code.
>
> The path setup pretty much has to be done in a context like that-- 
> chicken and egg.  Without the path setup, we can't find the pyobjc 
> module and, as such, can't move the path setup into PyObjC itself.
>
> The problem with autoloading the code are two fold;   first, there may 
> be order dependencies that would be difficult to resolve.  Secondly, 
> it is very likely that the developer does not want all of the python 
> files loaded!  In particular, the window controller for a preferences 
> panel really doesn't need to be loaded until the first time [if they 
> do] the user selects the 'Preferences...' menu item.
>
> The situation becomes more complex if the developer needs to load 
> third party python modules or NSBundles [or other bits of dynamic 
> code].

I was just wondering if we could change the way the developer registers 
their python modules. Either put them in a separate module that 
__main__.py imports or put the names of the ones you want preloaded 
into the Info.plist or something like that. I just think it's more 
professional to not mix user code and essential bootstrap code in the 
same module.

Peter

Re: [Pyobjc-dev] Newbie: Can't get TableModel to work

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

On Wednesday, November 13, 2002, at 02:27 AM, bb...@ma... wrote:

> It struck me that if you were to turn off the 'copy only when 
> installing' flag on the build phase that copies the pyobjc module 
> [you'll likely need to adjust the filesystem reference as it is 
> hardwired to a pyobjc module installed against Apple's build of 
> python], the resulting builds will 'just work' regardless of which 
> interpreter is used (as long as the interpreter remains compatible 
> with the build of python on the dynamic loading front).

Yeah, I was wondering about that too. Probably because I don't usually 
use the concept of install builds.


>
> Not the best of solutions, really, given the fragility of playing 'mix 
> and match' with interpreters and modules.
>
> I'm thinking that the bootstrap executable should first check to see 
> if there is a pyobjc directory in Resources and, if not, derive the 
> library path from the python binary that will be used and subsequently 
> figure out if the pyobjc module is installed in that interpreter's 
> environment.
>
> The first test is very inexpensive;  I'm going to throw it in 
> regardless-- if the pyobjc directory isn't available, the bootstrap 
> executable can assume that it is in a developer mode and can dump a 
> quick summary of the interpreter that will be used.
>
> The second test is more expensive and generally only applicable in a 
> developer type environment.  I'm not sure if it is worth going there 
> or not -- maybe only if a particular flag is available?   It's too bad 
> that the bootstrap binary can't fork() instead of using execve(), but 
> doing so causes problems with mach ports and the applications 
> integration into the rest of OS X [at least, it used to, I haven't 
> checked].

Unless it is *really* expensive I wouldn't worry about it. I've done 
some quick benchmarking (read: putting in lots of print statements) and 
the amount of time spent in the bootstrap executable is really 
negligible compared to the dynamic loading of the frameworks a bit 
latter on.


> As always -- just a bunch of hacks to workaround the lack of an 
> embeddable Python shipping with OS X.   Even if Apple doesn't move to 
> 2.3 in the near future, I hope they at least fix the current build!
>
> b.bum
>
> On Monday, November 11, 2002, at 04:01 AM, Just van Rossum wrote:
>> Ronald Oussoren wrote:
>>
>>> You might want to try TableModel2, this contains the same code but 
>>> now
>>> part of a ProjectBuilder project. This project does work with python
>>> 2.2.
>>
>> I actually did, the app builds fine, but when I launch it it 
>> immediately quits,
>> no trace of any error in the Console, no crash, nothing. Hm, I just 
>> tried again
>> with Python 2.2 instead of CVS, and it works! Hey, that's great!
>>
>> I guess I'll rebuild my FrameWork install and see how far I get with 
>> running the
>> examples with that.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing 
> your web site with SSL, click here to get a FREE TRIAL of a Thawte 
> Server Certificate: http://www.gothawte.com/rd522.html
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Python rather than ObjC for main?

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

On Friday, November 8, 2002, at 09:38 PM, Peter Montagner wrote:
> On Saturday, November 9, 2002, at 04:56 AM, bb...@ma... wrote:
>> BTW:  There is nothing app specific about the bootstrap executable.  
>> You don't even need to compile it to use it in another project-- just 
>> add a copy files phase that copies the executable into the 
>> Executables area of the app wrapper and make sure that the executable 
>> name attribute in the info dictionary of the app wrapper is set 
>> correctly.
>
> Yeah, the first thing I tried was a python script as the executable 
> that mirrors bin-python-main.m ie. it calls the python version of 
> exec(). It works without any problems but as you said, there isn't any 
> point.

There might be -- if it allows the bootstrapper to check for the 
presence of a working pyobjc environment without a huge amount of cost, 
that could be very valuable.

Do you happen to have the code around?

>>> I think I know what will help me: a proper build of python. So what 
>>> is recommended? CVS python? Stable python? Fink?
>>
>> Fink rocks.
>
> I haven't got fink for 10.2 yet. How different is it from stable 
> python?

There are two python 2.2 packages in Fink;  with X11 and without.   
Take your pick.   The resulting build isn't different from a stable 
python build except that it does not build with SSL support in the 
socket module [long list of reasons-- some good, some not].  Not a big 
deal;   building the socket module standalone proved to be very easy...

     http://pyobjc.sourceforge.net/software/

>
>>>> In any case, all of this-- the whole execve() style bootstrapper-- 
>>>> is just a hack that'll go away as soon as we have an embeddable 
>>>> build of Python shipping with OS X.
>>>
>>> Yeah, I know. I just had the kluge alert going off in my head and I 
>>> felt compelled to try and fix it. Anything other than the current 
>>> hack is going to be an even bigger hack. You guys have done a great 
>>> job.
>>
>> Thanks.  It just got better.  If you cvs update the pyobjc source 
>> tree, the new Cocoa-Python project template has been cleaned up a 
>> bit.   BTW:  You can create a symlink from /Developer/ProjectBuilder 
>> Extras/Project Templates/... wherever ... to the project template(s) 
>> in the pyobjc source tree directly.   Just make sure you don't end up 
>> w/a .pbxuser file in the template pbproj....
>
> Done.  Main.py is now __main__.py? Good idea. My only problem with the 
> current scheme is that you have to add import statements for your 
> source. Is there away this could be automatically, or better yet 
> dynamically? It would be nice if the user didn't have to touch 
> __main__.py manually. It would be even nicer if __main__.py could 
> figure out where the other stuff is itself.

It would be nice if the __main__.py could have a bunch of the 
repetitive code ripped out.  Wouldn't be hard;  the whole framework 
bootstrapper could be moved to the AppKit module as an extension and 
that is the bulk of the code.

The path setup pretty much has to be done in a context like that-- 
chicken and egg.  Without the path setup, we can't find the pyobjc 
module and, as such, can't move the path setup into PyObjC itself.

The problem with autoloading the code are two fold;   first, there may 
be order dependencies that would be difficult to resolve.  Secondly, it 
is very likely that the developer does not want all of the python files 
loaded!  In particular, the window controller for a preferences panel 
really doesn't need to be loaded until the first time [if they do] the 
user selects the 'Preferences...' menu item.

The situation becomes more complex if the developer needs to load third 
party python modules or NSBundles [or other bits of dynamic code].

b.bum

Re: [Pyobjc-dev] Newbie: Can't get TableModel to work

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

Ahhh... the 'wrong interpreter' bug strikes again.   If you have any 
suggestions as to how we might address this problem a bit more 
effectively such that it causes less confusion, it would be most 
welcome.

It struck me that if you were to turn off the 'copy only when 
installing' flag on the build phase that copies the pyobjc module 
[you'll likely need to adjust the filesystem reference as it is 
hardwired to a pyobjc module installed against Apple's build of 
python], the resulting builds will 'just work' regardless of which 
interpreter is used (as long as the interpreter remains compatible with 
the build of python on the dynamic loading front).

Not the best of solutions, really, given the fragility of playing 'mix 
and match' with interpreters and modules.

I'm thinking that the bootstrap executable should first check to see if 
there is a pyobjc directory in Resources and, if not, derive the 
library path from the python binary that will be used and subsequently 
figure out if the pyobjc module is installed in that interpreter's 
environment.

The first test is very inexpensive;  I'm going to throw it in 
regardless-- if the pyobjc directory isn't available, the bootstrap 
executable can assume that it is in a developer mode and can dump a 
quick summary of the interpreter that will be used.

The second test is more expensive and generally only applicable in a 
developer type environment.  I'm not sure if it is worth going there or 
not -- maybe only if a particular flag is available?   It's too bad 
that the bootstrap binary can't fork() instead of using execve(), but 
doing so causes problems with mach ports and the applications 
integration into the rest of OS X [at least, it used to, I haven't 
checked].

As always -- just a bunch of hacks to workaround the lack of an 
embeddable Python shipping with OS X.   Even if Apple doesn't move to 
2.3 in the near future, I hope they at least fix the current build!

b.bum

On Monday, November 11, 2002, at 04:01 AM, Just van Rossum wrote:
> Ronald Oussoren wrote:
>
>> You might want to try TableModel2, this contains the same code but now
>> part of a ProjectBuilder project. This project does work with python
>> 2.2.
>
> I actually did, the app builds fine, but when I launch it it 
> immediately quits,
> no trace of any error in the Console, no crash, nothing. Hm, I just 
> tried again
> with Python 2.2 instead of CVS, and it works! Hey, that's great!
>
> I guess I'll rebuild my FrameWork install and see how far I get with 
> running the
> examples with that.

[Pyobjc-dev] BTW: the new site

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

It ain't great, I'm not attached to it... if someone has the time to 
fix it, do better, replace it, or whatever -- PLEASE do so!!!

b.bum

[Pyobjc-dev] New site

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

Instead of sleeping, I combined everything that Jim Tittsler did with 
the Fink style of web site to create a 'real' (not all the content is 
complete) web site for PyObjC.

     http://pyobjc.sourceforge.net/index.php

Have to give some thought as to how to integrate news, changes, 
examples, etc... from the source tree into the web site in a more 
automated fashion.

Everything is checked into the pyobjc-web directory in the pyobjc 
repository.  I didn't want to shove it into the source tree as it is 
already bloated enough (and this stuff isn't really appropriate within 
the distribution).

If you want to play with this on your OS X box, you'll need to enable 
PHP.  See my 'blog post today [yesterday]...

     http://radio.weblogs.com/0100490/

... for a recipe on doing so.   Once php is enabled, simply create a 
symlink from /Library/WebServer/Documents/pyobjc to the docroot 
directory within pyobjc-web.  Everything is designed to be deployed 
with relative URLs, etc-- it should be fairly easy to port, move or 
restructure.

Now, I'm going to sleep.

b.bum

[Pyobjc-dev] Protocols and Proxies

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

Do protocols and proxies work? I'm trying to track down why distributed 
objects doesn't work.

NSProxy test:

from Foundation import *

class ProxyTest(NSProxy):
	def test(self):
		return 'Hello, world!'

p = ProxyTest.alloc()
p.test()

It segfaults. I little experimentation shows that it segfaults on 
alloc().

Also, are (formal) protocols supported? How do you create a new one?

Peter

Re: [Pyobjc-dev] implementation of NSComboBoxDataSource informal protocol

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

Spelling error in Lib/AppKit/__init__.py (comboxBox... instead of 
comboBox...).

Fixed.

Update your PyObjC module installation from the CVS source and it 
should work much better now.

b.bum

On Monday, November 11, 2002, at 05:06 PM, Steven D. Arnold wrote:
> TypeError: class WordTypeManager does not implement protocol
> NSComboBoxDataSource: no implementation for
> comboxBox:objectValueForItemAtIndex:
>

[Pyobjc-dev] implementation of NSComboBoxDataSource informal protocol

[Steven D. A. <st...@ne...>]

I have a combo box on a form which I am populating via a data source.  I
have a manager class that handles the data source, as follows (some material
omitted to save space):

class WordTypeManager( Foundation.NSObject, AppKit.NSComboBoxDataSource ):
        
    def comboBox_objectValueForItemAtIndex_( self, comboBox, index ):
        return self.query[ index ][ 'long_type' ]

When I run my program, I get the following error:

AttributeError: No selector comboxBox:objectValueForItemAtIndex:
Traceback (most recent call last):
  File 
"/Users/thoth/Source/Build/dictionary.app/Contents/Resources/Main.py", line
13, in ?
    class WordTypeManager( Foundation.NSObject, AppKit.NSComboBoxDataSource
):
TypeError: class WordTypeManager does not implement protocol
NSComboBoxDataSource: no implementation for
comboxBox:objectValueForItemAtIndex:

I thought I was defining this function correctly -- replace `:' with `_'.
Any ideas what's going on?

Thanks in advance,

steve
-- 

Re: [Pyobjc-dev] Re: libffi

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

On Monday, Nov 11, 2002, at 13:10 Europe/Amsterdam, Ronald Oussoren 
wrote:
>> And if that doesn't work we should try to fix darwin_closure.S. 
>> Without known any PowerPC assembler (i.e. this paragraph should be 
>> considered as near-zero-content:-) my first guess is that the jump 
>> table at .L60 is the problem. Either the table itself (although the 
>> .L44-.L60 form of the entries should have removed any relocation) or 
>> the loading of its address, a few lines above. Examining how the C 
>> compiler creates code for switch statements if -dynamic is in effect 
>> should give us a clue.
> Fixing darwin_closure.S might be usefull anyway. If anyone want to 
> show of their PPC assembly skills: here's your change. I've posted a 
> question about this on the libffi mailinglist, but that seems to be 
> dead. I suppose the developers migrated to the gcc related 
> mailinglists.

A further experiment indicates that the problem is probably the loading 
of the base address of the jump table. If I compile a switch statement 
with "cc -static" the base address is loaded with a code sequence 
similar to the one in darwin_closure.S:
	lis r9,ha16(L10)
	la r0,lo16(L10)(r9)
If I compile with cc -dynamic (or plain cc, apparently -dynamic is 
default?) I get a sequence I don't fully understand,
but the key bit seems to be
	bcl 20,31,L1$pb
L1$pb:
	mflr r10
      ....
	addis r9,r10,ha16(L10-L1$pb)
	la r9,lo16(L10-L1$pb)(r9)
so it seems they're using some sort of a relative subroutine jump to 
get the address of L1$pb into r10, and subsequently address relative to 
that to get rid of relocation. I've attached the code in case someone 
wants to have a look.