pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] Headache over hacking an XML editor

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

Hi, I'm banging my head against NSOutlineView's dataSource methods,
trying to hack a little XML editor, and I'm not sure if it's just
my sillyness or some bad surprises of PyObjC type conversion, sigh!

In any case these methods don't seem to work as expected passing
None as an item value far more often than I'd expect, so I wonder
if anybody here has some simple code to share? I'd be glad to pro-
vide the little test code I'm running myself...

Dinu

--
Dinu C. Gherman
......................................................................
"The pure and simple truth is rarely pure and never simple."
(Oscar Wilde)

Re: [Pyobjc-dev] Templates thought

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

Bill Bumgarner:

> Instead of creating a bazillion different templates, how about merging 
> the [possibly three, maybe four] variants on Cocoa-Python Application 
> and Cocoa-Python Multiple Document Application into one that includes 
> support for the Apple Python, the Framework Python and the 
> Fink/command line Python builds?

If the templates all allow to chose from different Python versions,
fine! Having different templates for single/multi document apps,
tools, etc. does still make sense to me.

Dinu

--
Dinu C. Gherman
......................................................................
"No one has ever had an idea in a dress suit."
(Sir Frederick G. Banting)

[Pyobjc-dev] Templates thought

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

Instead of creating a bazillion different templates, how about merging 
the [possibly three, maybe four] variants on Cocoa-Python Application 
and Cocoa-Python Multiple Document Application into one that includes 
support for the Apple Python, the Framework Python and the Fink/command 
line Python builds?

It would simply be a matter of creating multiple targets.  The 
developer could delete ones they aren't using or keep them around -- 
matters not.

It would also create a separate and justifiable reason to maintain a 
Python target that works with all other targets and will eventually do 
syntax checking and compilation of the Python files.

Most importantly, it'll reduce the maintenance associated with 
templates considerably by reducing the amount of copying or 
near-copying that has to be done across multiple templates with each 
change (already a pain).

Thoughts?

b.bum

Re: [Pyobjc-dev] Access to 'hidden' class-methods

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

On Sunday, Jan 12, 2003, at 22:36 Europe/Amsterdam, Jack Jansen wrote:

>
> On zondag, jan 12, 2003, at 20:36 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>>
>> Right. A class is an instance of its meta-class and class-methods are 
>> in fact normal methods of the meta-class [...]
>
> Are you sure this is the case? Then how can I access "self" in a class 
> method (which would be the class)? Or is the only reason I can't get 
> at self in a class method is that the ObjC syntactic sugar doesn't 
> allow it?
You can, but inside a class method 'self' refers to the class instead 
of instances of the class.

$ cat t.m
#include <Foundation/Foundation.h>

@interface TestClass :NSObject
{
}

+classMethod;

@end

@implementation TestClass

+classMethod
{
         printf("%p: Self of class method\n", self);
         printf("%p: Class TestClass\n", [TestClass class]);
         return 0;
}
@end

int main(void)
{
         [TestClass classMethod];
}

$ cc -o t t.m -framework Foundation
$ ./t
0x400c: Self of class method
0x400c: Class TestClass


>
> Hmm, another wild idea: would this mean that by declaring a category 
> on the metaclass you could influence creation of all ObjC objects?
You probably could, but: the metaclass has the same name as the normal 
class which makes it hard to define a category on it. But is guess 
defining a category containing class-mehods on a normal class would do 
what you want.

Ronald

Re: [Pyobjc-dev] Access to 'hidden' class-methods

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

On zondag, jan 12, 2003, at 20:36 Europe/Amsterdam, Ronald Oussoren 
wrote:
>
> Right. A class is an instance of its meta-class and class-methods are 
> in fact normal methods of the meta-class [...]

Are you sure this is the case? Then how can I access "self" in a class 
method (which would be the class)? Or is the only reason I can't get at 
self in a class method is that the ObjC syntactic sugar doesn't allow 
it?

Hmm, another wild idea: would this mean that by declaring a category on 
the metaclass you could influence creation of all ObjC objects?
--
- 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] Access to 'hidden' class-methods

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

On Sunday, Jan 12, 2003, at 16:08 Europe/Amsterdam, bb...@ma... wrote:

> On Sunday, Jan 12, 2003, at 02:16 US/Eastern, Ronald Oussoren wrote:
>> Sounds good, but methodForSelector: is simular to description in that 
>> it is both a class and instance methods, and in your example your 
>> using the class method. Because of the way the bridge and python are 
>> working you cannot access the class-method at the moment.
>
> methodSignatureForSelector_ is only an instance method -- but is also 
> an instance method on the Class metaobject and, therefore, acts like a 
> class method?

Right. A class is an instance of its meta-class and class-methods are 
in fact normal methods of the meta-class (the meta-class itself is an 
instance of NSObject if you compile a normal Objective-C class 
definitions; it is of course possible to let the meta-class be an 
instance of another class if you define the class in C). You normally 
don't notice the existence of the metaclass, unless you start to do 
lowlevel hacking.

Ronald

[Pyobjc-dev] Bootstrapping (Was: Project Templates)

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

Bill Bumgarner:

> Dinu Gherman wrote:
>> Also, it should be stated somewhere what's needed to change the names
>> of these "standard" filenames, including MyAppDelegate.py, especially,
>> if the __main__.py needs to be changed...
>
> See 00README.txt in the Cocoa-Python Application project template.   
> Good enough?

Well, I'm trying to follow what is mandates for running an install
build on a different (10.1) box with Python in /usr/local/bin. So
far I tried skipping some of the environment variables, but with no
luck. In any case, I think I can't assume a non-Python user to go
through the list in order to run any pyobjc app.

Could they maybe bootstrap themselves using a shell script that de-
termines the location of the current Python interpreter and does
the rest magically before kicking off the app itself?

Dinu

--
Dinu C. Gherman
......................................................................
"CNN is one of the participants in the war. I have a fantasy where
Ted Turner is elected president but refuses because he doesn't want
to give up power. (Arthur C. Clarke)

Re: [Pyobjc-dev] Project Templates

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

On Sunday, Jan 12, 2003, at 09:12 US/Eastern, Dinu Gherman wrote:
> Bill Bumgarner:
>
>> I have added a bunch of [ReST] documentation to the 00README.txt in 
>> Project Templates.   If any of you has a chance, have a read and let 
>> me know if there are major holes.   I really don't want to create a 
>> project template for every possible permutation -- some projects can 
>> provide examples for how to set up features of others.
> Sounds good to me! Just a minor question: "Document-based app." means
> there there will be something like MyDocumentController.py and MyDoc\
> ument.nib files available and prelinked to parts of the menu and
> available as object instances in MainMenu.nib, isn't it?

Correct.   The templates are designed to be exactly like their pure 
ObjC counterparts save for that the implementation is in Python.   
Because it is in Python, I also made sure each example builds an 
application that at least does some minimal target/action as an example 
of how to do such tasks in PyObjC.

> Also, it should be stated somewhere what's needed to change the names
> of these "standard" filenames, including MyAppDelegate.py, especially,
> if the __main__.py needs to be changed...

See 00README.txt in the Cocoa-Python Application project template.   
Good enough?

b.bum

Re: [Pyobjc-dev] Access to 'hidden' class-methods

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

On Sunday, Jan 12, 2003, at 02:16 US/Eastern, Ronald Oussoren wrote:
> Sounds good, but methodForSelector: is simular to description in that 
> it is both a class and instance methods, and in your example your 
> using the class method. Because of the way the bridge and python are 
> working you cannot access the class-method at the moment.

methodSignatureForSelector_ is only an instance method -- but is also 
an instance method on the Class metaobject and, therefore, acts like a 
class method?

I think.   If so, raises an interesting question regarding meta objects 
-- one that I can't currently intelligently quantify.

b.bum

Re: [Pyobjc-dev] Confusion over PB targets and build styles

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

Hi Dinu,

> Now for a silly question: how do I add this? Is it really a new
> "taregt" or rather an install "build style"? I can't find a mean-
> ingful "install" target to add and it's not obvious how to make
> use of an "install" build style.

You'll have to do it from the command line. Run this in your project 
directory:

pbxbuild install

ciao
Martina

[Pyobjc-dev] Confusion over PB targets and build styles

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

Hi, in pyobjc/Project Templates/00README.txt it says:

   Cocoa-Python Application
   ------------------------
   [...]
   When building the 'install' target, the resulting application
   wrapper will included the PyObjC module and can be launched on
   any stock OS X 10.2 system without requiring PyObjC to be pre-
   installed.

Now for a silly question: how do I add this? Is it really a new
"taregt" or rather an install "build style"? I can't find a mean-
ingful "install" target to add and it's not obvious how to make
use of an "install" build style.

Thanks,

Dinu

--
Dinu C. Gherman
......................................................................
Fire in the Library - panic in Washington. ABC news is reporting that
a small fire damaged part of the White House's South Wing this mor-
ning, destroying the personal library of president Bush. Ari Fleisher
later announced that both of the President's books have been lost and
that he is devastated. It seems that he had not finished coloring the
second one. (Anonymous)

Re: [Pyobjc-dev] Project Templates

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

Bill Bumgarner:

> I have added a bunch of [ReST] documentation to the 00README.txt in 
> Project Templates.   If any of you has a chance, have a read and let 
> me know if there are major holes.   I really don't want to create a 
> project template for every possible permutation -- some projects can 
> provide examples for how to set up features of others.

Sounds good to me! Just a minor question: "Document-based app." means
there there will be something like MyDocumentController.py and MyDoc\
ument.nib files available and prelinked to parts of the menu and
available as object instances in MainMenu.nib, isn't it?

Also, it should be stated somewhere what's needed to change the names
of these "standard" filenames, including MyAppDelegate.py, especially,
if the __main__.py needs to be changed...

Thanks,

Dinu

--
Dinu C. Gherman
......................................................................
"Who controls the past, controls the future: who controls the present
controls the past." (George Orwell, 1984)

Re: [Pyobjc-dev] Access to 'hidden' class-methods

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

On Sunday, Jan 12, 2003, at 05:17 Europe/Amsterdam, bb...@ma... wrote:

> On Saturday, Jan 11, 2003, at 17:31 US/Eastern, Ronald Oussoren wrote:
>> Some time ago there was a discussion about access to class-methods 
>> with the same name as an instance-method. Currently this is not 
>> possible.
>>
>> One of suggestions was to add pyobjc-specific attributes to proxy 
>> objects. I've implemented, but not yet fully tested this. After I 
>> check this in you can do:
>>
>> 	NSObject.pyobjc_classMethods.description()	# Call +description
>> 	a = NSObject.new()
>> 	a.pyobjc_classMethods.description()  # Also call +description
>> 	a.pyobjc_instanceMethods.description() # Call -description
>>
> Could this be simplified by requiring the developer to go through 
> class() to get to the class method?
No, that's why one of the tests in Lib/objc/tes/test_objc.py is 
failing. If a class has a class and instance method with the same name, 
the former will be inaccessible from Python using the normal 
mechanisme. In python, attributes are first looked up in the __dict__ 
of the instance and then in the __dict__ of its class (and 
superclasses). All methods are only present in the class dict.

Note that my patch doesn't change the default behaviour, 
NSObject.alloc() will still work.

>
> NSObject.pyobjc_classMethods.description() # invoke class method
> a = NSObject.new()
> a.class().description() # invoke class method
> a.description() # invoke instance method
>
> This doesn't solve the overall problem that Ronald's solution 
> addresses, but it would work most of the time [I think].
>
>> I've not yet added an pyobjc_instanceMethods attribute to 
>> class-proxies. Another restriction is that reflection doesn't work 
>> yet for the contents of these attributes, 
>> dir(NSObject.pyobjc_classMethods) will not return a list of class 
>> methods.
>
> Since we have to go through this extra hoop anyway, maybe the answer 
> is to hang the classMethods and instanceMethods attribute off of the 
> class object?
>
> a.class().pyobjc_classMethod('description')
> a.class().pyobjc_instanceMethod('description')
>
> Actually -- maybe the right thing to do is to bridge the following two 
> methods on NSObject...
>
>     - (IMP)methodForSelector:(SEL)aSelector;
>     + (IMP)instanceMethodForSelector:(SEL)aSelector;
>
> ... such that they return unbound class/instance methods, as 
> appropriate.  This would make it possible to do:
>
>     a.class().methodForSelector_("description")(a.class())
>     a.class().instanceMethodForSelector("description")(a)
>
> May look odd, but it is certainly 'pythonic' in that returning a 
> callable from a method/function is fairly common practice.
>
> This also obviates the need for doing introspection at the level of 
> generating an inventory of methods for the class with some 
> categorization.

Sounds good, but methodForSelector: is simular to description in that 
it is both a class and instance methods, and in your example your using 
the class method. Because of the way the bridge and python are working 
you cannot access the class-method at the moment.

Ronald

Re: [Pyobjc-dev] Using pathForResource_

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

On Saturday, Jan 11, 2003, at 21:01 US/Eastern, David Casti wrote:
> image = NSBundle.mainBundle().pathForResource_of_Type_inDirectory_(
> 'no_tunnels.png', 'png', '' )

You need to literally replace the ':' in the method name with '_'.

I.e. NSBundle's method...

     pathForResource:ofType:inDirectory:

... becomes ...

     pathForResource_ofType_inDirectory_()

So:

      
NSBundle.mainBundle().pathForResource_ofType_inDirectory_('no_tunnels.pn 
g', 'png', '')

But that won't work either.  You probably want:

     NSBundle.mainBundle().pathForResource_ofType_('no_tunnels', 'png')

Or:

     NSBundle.mainBundle().pathForResource_ofType_('no_tunnels.png',  
None)

b.bum

Re: [Pyobjc-dev] Access to 'hidden' class-methods

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

On Saturday, Jan 11, 2003, at 17:31 US/Eastern, Ronald Oussoren wrote:
> Some time ago there was a discussion about access to class-methods 
> with the same name as an instance-method. Currently this is not 
> possible.
>
> One of suggestions was to add pyobjc-specific attributes to proxy 
> objects. I've implemented, but not yet fully tested this. After I 
> check this in you can do:
>
> 	NSObject.pyobjc_classMethods.description()	# Call +description
> 	a = NSObject.new()
> 	a.pyobjc_classMethods.description()  # Also call +description
> 	a.pyobjc_instanceMethods.description() # Call -description
>
Could this be simplified by requiring the developer to go through 
class() to get to the class method?

NSObject.pyobjc_classMethods.description() # invoke class method
a = NSObject.new()
a.class().description() # invoke class method
a.description() # invoke instance method

This doesn't solve the overall problem that Ronald's solution 
addresses, but it would work most of the time [I think].

> I've not yet added an pyobjc_instanceMethods attribute to 
> class-proxies. Another restriction is that reflection doesn't work yet 
> for the contents of these attributes, 
> dir(NSObject.pyobjc_classMethods) will not return a list of class 
> methods.

Since we have to go through this extra hoop anyway, maybe the answer is 
to hang the classMethods and instanceMethods attribute off of the class 
object?

a.class().pyobjc_classMethod('description')
a.class().pyobjc_instanceMethod('description')

Actually -- maybe the right thing to do is to bridge the following two 
methods on NSObject...

     - (IMP)methodForSelector:(SEL)aSelector;
     + (IMP)instanceMethodForSelector:(SEL)aSelector;

... such that they return unbound class/instance methods, as 
appropriate.  This would make it possible to do:

     a.class().methodForSelector_("description")(a.class())
     a.class().instanceMethodForSelector("description")(a)

May look odd, but it is certainly 'pythonic' in that returning a 
callable from a method/function is fairly common practice.

This also obviates the need for doing introspection at the level of 
generating an inventory of methods for the class with some 
categorization.

> I'm not yet completely happy with this solution because you cannot 
> override these hidden methods in subclasses, that is you cannot define 
> a class-method 'description' in your subclass of NSObject(*). But 
> because this should rarely be necessary I can live with this.

Still a problem with the above ...  but more a problem with method 
declarations themselves.

Maybe the answer is to have specific API for adding methods to a class. 
  I.e.:

     a.class().pyobjc_addClassMethod("description", <callable>)
     a.class().pyobjc_addInstanceMethod("description", <callable>)

The developer could declare this something like:

class MyClass(NSObject):
     def class_description(self):
	    ... do whatever here ...

MyClass.pyobjc_addClassMethod("description", MyClass.class_description)

Or something like that.

b.bum

Re: [Pyobjc-dev] Using pathForResource_

[David C. <da...@ne...>]

On 1/11/03 1:39 PM, "Dinu Gherman" <gh...@da...> wrote:

> You're almost there, try this:
> 
>  NSBundle.mainBundle().pathForResource_of_Type_inDirectory_(...)

Hm.  That did change the error message, but still no luck.  The line --

image = NSBundle.mainBundle().pathForResource_of_Type_inDirectory_(
'no_tunnels.png', 'png', '' )

-- produces the error message --

2003-01-11 20:58:28.903 NewTunnels[3208] Exception raised during posting of
notification.  Ignored.  exception: No attribute
pathForResource_of_Type_inDirectory_

-- I am importing NSBundle from Foundation... which is the only one I know
of.  I can find the pathForResource call in the Cocoa help, but I must still
be missing something.

Thanks,
David.

Re: [Pyobjc-dev] Project Templates

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

On Saturday, Jan 11, 2003, at 16:46 US/Eastern, Ronald Oussoren wrote:
> It seems complete enough. The only project-type not on your list that 
> I'd like to add some day is a project for python based plugins for 
> Cocoa programs (like prefpanes). But we should add full thread-safety 
> before doing that.

One of my next projects will be a PB plugin [or something like it] -- 
more on that later.   Out of that, a template may fall.

I have just committed a new project template -- Cocoa-Python-ObjC 
Application.   It is compatible with Apple's build of python and allows 
one to freely mix Objective-C and Python in the project.   The ObjC all 
goes in an embedded framework.  The Python can go anywhere.

I also added a bunch of documentation to a 00README.txt file in 
Cocoa-Python Application -- I'll be adding the 'Classes & NIB' section 
next.   That document really ought to be moved to somewhere else as it 
isn't totally specific to that template.

b.bum

[Pyobjc-dev] Using pathForResource_

[David C. <da...@ne...>]

Right now I am using an absolute path to reference my icons... naturally I
want to change things so the icons are a resource in the project.  I have
moved the files into the project and added them to the copy phase.

I think I should be able to do something like this --

no_tunnel_image = NSBundle.mainBundle.pathForResource_ofType_inDirectory_(
"no_tunnels", "png", '' )

-- but I consistently get this error --

2003-01-11 13:16:51.664 NewTunnels[2990] Exception raised during posting of
notification.  Ignored.  exception: 'objc.native_selector' object has no
attribute 'pathForResource_ofType_inDirectory_'

-- I have also tried just 'pathForResource_' and a few other permutations
unsuccessfully.

Ideas?
David.

Re: [Pyobjc-dev] In and out of NSData

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

Yes.   I believe that would solve more problems than it would cause.

On Saturday, Jan 11, 2003, at 17:18 US/Eastern, Ronald Oussoren wrote:
> BTW. Shall I set this flag for all instance-methods whose selector 
> starts with 'init'? This is simple enough to do and is probably 
> exactly what's needed.

[Pyobjc-dev] Access to 'hidden' class-methods

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

Some time ago there was a discussion about access to class-methods with 
the same name as an instance-method. Currently this is not possible.

One of suggestions was to add pyobjc-specific attributes to proxy 
objects. I've implemented, but not yet fully tested this. After I check 
this in you can do:

	NSObject.pyobjc_classMethods.description()	# Call +description
	a = NSObject.new()
	a.pyobjc_classMethods.description()  # Also call +description
	a.pyobjc_instanceMethods.description() # Call -description

I've not yet added an pyobjc_instanceMethods attribute to 
class-proxies. Another restriction is that reflection doesn't work yet 
for the contents of these attributes, dir(NSObject.pyobjc_classMethods) 
will not return a list of class methods.

I'm not yet completely happy with this solution because you cannot 
override these hidden methods in subclasses, that is you cannot define 
a class-method 'description' in your subclass of NSObject(*). But 
because this should rarely be necessary I can live with this.

Ronald

(*) Hmm, now that I think of it, you should be able to override the 
class-method description, you just cannot name your version 
'description': The objc.selector function has an optional argument for 
specifying the selector.

I've not yet tested if this actually works and now that I think of it, 
the testsuite doesn't seem to contain a test for overriding a 
class-method at all.

Re: [Pyobjc-dev] In and out of NSData

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

On Saturday, Jan 11, 2003, at 04:56 Europe/Amsterdam, bb...@ma... 
wrote:

> On Friday, Jan 10, 2003, at 16:28 US/Eastern, Ronald Oussoren wrote:
>> I found where this problem originates: inside Cocoa :-(. I can 
>> probably get a simular crash using pure objective-C code (I've not 
>> tested this, hence the 'probably').
>
> Ugh...
>
> Maybe we need to create a list of selectors for which the return value 
> should be followed as 'self' and not the initial target of the method 
> call.
>
> This would also address situations like the following:
>
> - init
> {
>     if (self = [super init]) {
> 	    // local initialization
>     }
>
>     return self;
> }
That should not be a problem, unless [super init] invalidates the value 
of self (before the assignment).

I agree that we should add a generic mechanism for this. I'm busy added 
a flag-bit to selectors, the flag can be changed from Python code. This 
allows us to add Python-code to objc._convenience that correctly sets 
this flag.

I'll check-in this change when I'm done with this.

BTW. Shall I set this flag for all instance-methods whose selector 
starts with 'init'? This is simple enough to do and is probably exactly 
what's needed.

Ronald

Re: [Pyobjc-dev] Project Templates

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

On Saturday, Jan 11, 2003, at 17:42 Europe/Amsterdam, Bill Bumgarner 
wrote:

> I have added a bunch of [ReST] documentation to the 00README.txt in 
> Project Templates.   If any of you has a chance, have a read and let 
> me know if there are major holes.   I really don't want to create a 
> project template for every possible permutation -- some projects can 
> provide examples for how to set up features of others.
>
> I have framework python installed on my machine and am going to do the 
> embedded project templates against that -- it is much more likely that 
> anyone with an embeddable command line version of Python will know how 
> to modify the framework project to embed their command line 
> interpreter.

It seems complete enough. The only project-type not on your list that 
I'd like to add some day is a project for python based plugins for 
Cocoa programs (like prefpanes). But we should add full thread-safety 
before doing that.

Ronald

Re: [Pyobjc-dev] Using pathForResource_

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

David Casti:

> no_tunnel_image = 
> NSBundle.mainBundle.pathForResource_ofType_inDirectory_(
> "no_tunnels", "png", '' )

You're almost there, try this:

   NSBundle.mainBundle().pathForResource_of_Type_inDirectory_(...)

Dinu

--
Dinu C. Gherman
......................................................................
What a wonderful world: http://BowlingForColumbine.com/library/wonderful

[Pyobjc-dev] Using pathForResource_

[David C. <da...@ne...>]

Right now I am using an absolute path to reference my icons... naturally I
want to change things so the icons are a resource in the project.  I have
moved the files into the project and added them to the copy phase.

I think I should be able to do something like this --

no_tunnel_image = NSBundle.mainBundle.pathForResource_ofType_inDirectory_(
"no_tunnels", "png", '' )

-- but I consistently get this error --

2003-01-11 13:16:51.664 NewTunnels[2990] Exception raised during posting of
notification.  Ignored.  exception: 'objc.native_selector' object has no
attribute 'pathForResource_ofType_inDirectory_'

-- I have also tried just 'pathForResource_' and a few other permutations
unsuccessfully.

Ideas?
David.

[Pyobjc-dev] Re: PyObjC - 404 Not Found

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

It isn't done yet....  You might want to have a look at the pyobjc-dev 
mailing list archives.   Lots of information there.

On Saturday, Jan 11, 2003, at 07:57 US/Eastern, Mikael Gripenstedt 
wrote:
> hi,
>
> I am trying to access the documentation and examples on the PyObjC 
> site, but
> I only get "404 Not Found". I thought you might want to know about 
> it...
>
> regards,
>
>    Mikael