pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Handling (void *)

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

Ronald,

OK, you've convinced me. I like your passing-an-int idea now.

Peter

Re: [Pyobjc-dev] Handling (void *)

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

On Friday, Nov 8, 2002, at 11:31 Europe/Amsterdam, Ronald Oussoren 
wrote:
> BTW. Jack's solution (None->nil, PyCObject->extract the pointer, ...) 
> is a better solution for almost anything with the possible exception 
> of the userInfo arguments in some Cocoa APIs. This does work correctly 
> with 'void*-as-pointer-to-block-of-memory'.

So the remaining problem is to decide which of two things a (void *) 
is. If it is a pointer to a block of memory we should use my method. On 
the other hand, if it is a callback cookie we should just allow passing 
of any Python object and show the Python object itself on the receiving 
side.

The latter is fairly easy to implement: the 
quick-and-dirty-and-dangerous implementation simply does a cast. And if 
we want to be on the safe side we could use a small wrapper object (so 
we could check on the receiving side that we're actually getting what 
we thing we are).

The difficult bit, I think, would be to decide which void*  argument 
falls into which category.
--
- 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] Handling (void *)

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

On Friday, Nov 8, 2002, at 10:59 Europe/Amsterdam, Peter Montagner 
wrote:
> So you think that we should treat (void*) as an integer rather than a 
> pointer, right? That works for me but it does seem a bit inelegant.
At least for now and only for specific methods. It is not very elegant, 
but at least it allows you to use a number of APIs that are off-limits 
at the moment.

BTW. I did not propose to treat all void* as integers, that would make 
it impossible to use some other APIs.

>
> Is there anything in python (2.2 onwards of course) that isn't an 
> object? If not, I think we should consider (void *) to be synonymous 
> with (id). The other use for (void*), as a pointer to block of memory 
> (eg. write()), can't really be done in python without wrapping it in 
> an object, right? So any API using (void *) for that purpose would 
> need to be specially wrapped anyway. Am I wrong?
Everything in python is an object from at Python 1.0, and probably 
right from the start. This doesn't mean we can just go on and use 
python objects for the userInfo argument, because of reference 
counting: Because the invoked method doesn't know we actually pas in a 
PyObject* or id, it doesn't know that it should increase the refcount. 
This means that the object may be garbage collected before it is passed 
back to us, unless we make sure a reference to it stays alive for as 
long as needed. I'd prefer not to introduce ways to easily memory 
corruption bugs in Python programs ;-).

BTW. Jack's solution (None->nil, PyCObject->extract the pointer, ...) 
is a better solution for almost anything with the possible exception of 
the userInfo arguments in some Cocoa APIs. This does work correctly 
with 'void*-as-pointer-to-block-of-memory'.

BTW2. A python object is _not_ an objective-C object, the pyobjc module 
just hides the differences. In some instances the difference is 
important, mostly when Objective-C code doesn't play by the rules (see 
the iClass example for an example of this)

Ronald

Re: [Pyobjc-dev] Handling (void *)

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

On Friday, November 8, 2002, at 05:41 PM, Ronald Oussoren wrote:

>
> On Thursday, Nov 7, 2002, at 17:12 Europe/Amsterdam, bb...@ma... 
> wrote:
>
>> That seems like about as close to a workable set of behaviors as we 
>> can get without special casing certain methods.   For contexts that 
>> use a (void *) as a bit of userInfo, we simply need to make sure that 
>> a Python object passed in can be recovered during the call back.
> I thought of an simpler way to "fix" this on the way home last night. 
> PyObjC has a mechanism to change the signatures of Objective-C methods 
> as seen from Python. We could use this to change all '(void*)userInfo' 
> arguments to '(int)userInfo' arguments. At the very least this allows 
> us to actually use these methods until we come up with a better 
> solution. If the userInfo will always be passed back to Python code 
> this is solution is good enough for me: Even if you wanted to pass a 
> python object you could stuff that Python object into a list and pass 
> the list index to the selector.
>
> This obviously is not the right fix in general (what if you want to 
> use an existing method that expects a pointer to some data).

So you think that we should treat (void*) as an integer rather than a 
pointer, right? That works for me but it does seem a bit inelegant.

Is there anything in python (2.2 onwards of course) that isn't an 
object? If not, I think we should consider (void *) to be synonymous 
with (id). The other use for (void*), as a pointer to block of memory 
(eg. write()), can't really be done in python without wrapping it in an 
object, right? So any API using (void *) for that purpose would need to 
be specially wrapped anyway. Am I wrong?

Peter

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

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

On Friday, November 8, 2002, at 01:59 AM, Ronald Oussoren wrote:
> The file register.m could also be made smaller by creating slightly 
> smarter functions in their that can detect how many arguments they 
> should have and then ignore any arguments they think to have beyond 
> the actual amount of arguments. This would allow us to use 1 function 
> for
> 	(int)aMeth:(int)arg withArg:someId andArg:(char*)foo
> and
> 	(int)aMeth:(int)arg
> and
> 	(int)doIt
>
> I'd prefer to wait with either change until after the upcoming release.

I completely agree on the timing issue, but wanted to add a detail 
while it was fresh in my head.

We could do exactly what you describe above-- the many arg versions of 
a method could handle all versions w/fewer args of the same signature 
as it stands now.  The second argument to any ObjC method invocation is 
always the selector and that selector can be used [directly or 
indirectly] to determine the # of args intended.

b.bum

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

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

On Thursday, Nov 7, 2002, at 16:40 Europe/Amsterdam, bb...@ma... wrote:

> On Thursday, November 7, 2002, at 12:48 AM, Peter Montagner wrote:
>> On Thursday, November 7, 2002, at 07:13 AM, bb...@ma... wrote:
>>> On Wednesday, November 6, 2002, at 09:23 AM, Peter Montagner wrote:
>>>> Is there any reason why the executable pointed to by 
>>>> CFBundleExecutable has to be a Mach-O file?
>>>
>>> Not in and of itself... but it fixes a separate problem with the 
>>> lightest possible solution I could come up with (faster than 
>>> launching Python interpreter).
>>
>> OK, it was just an experiment to see if we could avoid C code in the 
>> app completely. Of course if you are shipping a couple of MBs of 
>> pyobjc in the Resources folder, it's a moot point. Is there anything 
>> that can be done to reduce that code size? I'm thinking of register.m 
>> ...
>
> I was wondering the same.   In particular, the size of the pyobjc-- 
> specifically, mostly in _objc.so-- module jumped from 550k to 3.5MB 
> recently.   I believe it is because Ronald regenerated the register.m 
> file to contain a more complete set of potential selectors?  Not sure.
>
> In any case, Yes-- register.m needs to be addressed.  There should be 
> a way using a third party library or some other mechanism to 
> effectively eliminate the need for each individual function.   Ronald 
> knows a heck of a lot more about this than I do.

register.m is an alternative to dynamicly building function invocations 
at runtime. For normal method calls we use NSInvocation for that, but 
that class cannot be used for calls to the superclass implementation of 
a method. That is calls using 'objc_msgSendSuper' instead of 
'objc_msgSend'.

The file also contains a lot of stub functions that can be used as 
method implementations in the dispatch table of an Objective-C class. 
These are required if you want to override the implementation of a 
method in a Python-based subclass.

If we'd use libffi (homepage is on sources.redhat.com, the latest 
version is in the GCC CVS tree, license is BSD-like) this file could be 
replaced by a much shorter file. I've more or less writting a function 
to dynamicly generate the method IMPs, but ran into a problem: I cannot 
get libffi to build into object files that can be made part of a shared 
library.

The file register.m could also be made smaller by creating slightly 
smarter functions in their that can detect how many arguments they 
should have and then ignore any arguments they think to have beyond the 
actual amount of arguments. This would allow us to use 1 function for
	(int)aMeth:(int)arg withArg:someId andArg:(char*)foo
and
	(int)aMeth:(int)arg
and
	(int)doIt

I'd prefer to wait with either change until after the upcoming release.

>
>>> (This really isn't a bug in NSBundle -- more of a lacking feature.  
>>> There needs to be a way to tell NSBundle that yes, in fact, you 
>>> really want to point the main bundle HERE and not THERE before it 
>>> initializes.  An enhancement request has been filed at 
>>> bugreport.apple.com.)
>>
>> I'd say it *is* a bug. Anything after NSApplicationMain() should use 
>> the launch arguments passed to it rather than trying to get the 
>> arguments itself. Otherwise, what is the point of that function 
>> having those arguments?
>
> A lot of Foundation/CFBundle applications (and a number of AppKit 
> applications) never use NSApplicationMain().  As well, one could 
> easily implement something like:

As Bill noted Cocoa seems to fetch the value of argv[0] from somewhere 
else. It is not even fetched from the argv vector (e.g. argv[0] = "foo" 
wouldn't be usable). I guess it is fetched directly from the 
datastructure passed in by execv(), which is only the source from which 
the argv vector is build.

IIRC a couple of months ago someone on the MacPython list suggested how 
to deal with this using some undocumented function calls.
>
> Jim Tittsler was kind enough to send a brand spanking new web site to 
> me.  Includes a make environment, FAQ, documentation, examples, and 
> everything else... and a really cool dog/snake icon.   I have asked 
> him to forward along a discussion of it to the list so that we can 
> review it before it gets shoved into CVS.

Please stuff it into CVS as-is, we can discus it afterwards.

Even without seeing the site I'd like to say: Thanks a lot Jim.

Ronald

Re: [Pyobjc-dev] Handling (void *)

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

On Thursday, Nov 7, 2002, at 17:12 Europe/Amsterdam, bb...@ma... wrote:

> That seems like about as close to a workable set of behaviors as we 
> can get without special casing certain methods.   For contexts that 
> use a (void *) as a bit of userInfo, we simply need to make sure that 
> a Python object passed in can be recovered during the call back.
I thought of an simpler way to "fix" this on the way home last night. 
PyObjC has a mechanism to change the signatures of Objective-C methods 
as seen from Python. We could use this to change all '(void*)userInfo' 
arguments to '(int)userInfo' arguments. At the very least this allows 
us to actually use these methods until we come up with a better 
solution. If the userInfo will always be passed back to Python code 
this is solution is good enough for me: Even if you wanted to pass a 
python object you could stuff that Python object into a list and pass 
the list index to the selector.

This obviously is not the right fix in general (what if you want to use 
an existing method that expects a pointer to some data).

Ronald

Re: [Pyobjc-dev] pyobjc website possibility

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

On Friday, November 8, 2002, at 02:44 PM, Jim Tittsler wrote:

> I have started playing with Barry Warsaw's ht2html
> <http://ht2html.sf.net> to make some templates for a pyobjc
> website.  I also thought the Python FAQ Wizard might be a
> useful addition since it allows easy delegation of updates
> which can be handy during rapid expansion.
>
> <http://starship.python.net/crew/jwt/pyobjc/> is my playground.

Looks good. One bug though. The FAQ section is missing the link bar on 
the side. Of course, the FAQ section is also missing a FAQ but I guess 
that's not your fault :-)

I love the logo! It sums up the project perfectly.

Congrats on the clever build system.

Peter

[Pyobjc-dev] pyobjc website possibility

[Jim T. <jw...@On...>]

I have started playing with Barry Warsaw's ht2html
<http://ht2html.sf.net> to make some templates for a pyobjc
website.  I also thought the Python FAQ Wizard might be a
useful addition since it allows easy delegation of updates
which can be handy during rapid expansion.

<http://starship.python.net/crew/jwt/pyobjc/> is my playground.

I did this partly to try out the ht2html templating system
and partly to make a nice big place to hold all of the
documentation I am hoping everyone is busy writing.  :-)

The top level of the site has an .ht file for each .html file.
The .ht file is basically just the "body" fragment of standard
HTML. A links.h file makes the upper part of the sidebar.

For the documentation page, I tried fetching the Doc tree out
of CVS and then running those files through reStructured text's
html generator (and today tried combining it with Ollie
Rutherfurd's extension that does reStructured text to .ht,
making the doc pages fit in the template).  An adddocs.py hack
finds the files in the Doc subdirectory and adds them to the
documentation.h file to make the documentation.ht file.  Feels
a bit dirty, but allows easy reuse of the Doc tree and could be
made a cron job.  This allows 'make' to easily regenerate the
site.

A tarball of the site (and a separate ht2html directory with
the generator class I used) is at
http://starship.python.net/crew/jwt/pyobjcweb.tgz if you would
like to see the source.  Additional things needed outside the
tarball are the current docutils snapshot and the Python FAQ
wizard from the source distribution.  The process could be run
remotely and rsync'ed to SourceForge (or run there if all of
the modules are available).

Jim

[Pyobjc-dev] Handling (void *)

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

That seems like about as close to a workable set of behaviors as we can 
get without special casing certain methods.   For contexts that use a 
(void *) as a bit of userInfo, we simply need to make sure that a 
Python object passed in can be recovered during the call back.

This will likely require a 
treat-that-void-thing-as-a-python-object-reference and also raises the 
what-if-it-should-really-be-an-NSObject specter.

b.bum

On Wednesday, November 6, 2002, at 06:26 AM, Jack Jansen wrote:
> What I tend to do if I run into this situation when wrapping an API is 
> the following:
> - If the Python object is None I pass NULL, else
> - If the Python object conforms to the buffer protocol we use 
> bf_getreadbuffer() or bf_getwritebuffer(), else
> - if it's a PyCObject we use PyCObject_AsVoidPtr().

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

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

On Thursday, November 7, 2002, at 12:48 AM, Peter Montagner wrote:
> On Thursday, November 7, 2002, at 07:13 AM, bb...@ma... wrote:
>> On Wednesday, November 6, 2002, at 09:23 AM, Peter Montagner wrote:
>>> Is there any reason why the executable pointed to by 
>>> CFBundleExecutable has to be a Mach-O file?
>>
>> Not in and of itself... but it fixes a separate problem with the 
>> lightest possible solution I could come up with (faster than 
>> launching Python interpreter).
>
> OK, it was just an experiment to see if we could avoid C code in the 
> app completely. Of course if you are shipping a couple of MBs of 
> pyobjc in the Resources folder, it's a moot point. Is there anything 
> that can be done to reduce that code size? I'm thinking of register.m 
> ...

I was wondering the same.   In particular, the size of the pyobjc-- 
specifically, mostly in _objc.so-- module jumped from 550k to 3.5MB 
recently.   I believe it is because Ronald regenerated the register.m 
file to contain a more complete set of potential selectors?  Not sure.

In any case, Yes-- register.m needs to be addressed.  There should be a 
way using a third party library or some other mechanism to effectively 
eliminate the need for each individual function.   Ronald knows a heck 
of a lot more about this than I do.

>> (This really isn't a bug in NSBundle -- more of a lacking feature.  
>> There needs to be a way to tell NSBundle that yes, in fact, you 
>> really want to point the main bundle HERE and not THERE before it 
>> initializes.  An enhancement request has been filed at 
>> bugreport.apple.com.)
>
> I'd say it *is* a bug. Anything after NSApplicationMain() should use 
> the launch arguments passed to it rather than trying to get the 
> arguments itself. Otherwise, what is the point of that function having 
> those arguments?

A lot of Foundation/CFBundle applications (and a number of AppKit 
applications) never use NSApplicationMain().  As well, one could easily 
implement something like:

int main(...) {
     ... release pool ...
     [[NSBundle mainBundle] ...];
}

Which would cause the mainBundle to come into existence almost 
immediately upon program execution.  It can also boil down to a 
chicken-and-egg problem;  we need NSBundle like API to be able to find 
things in the app wrapper to initialize the interpreter, but we can't 
touch the API without causing mainBundle to be created.

In effect, we need a call that can be made to NSBundle or, likely, 
CFBundle (as that API doesn't have the auto initialization behavior of 
ObjC classes) that sets the main bundle path as basically the very 
first thing to happen upon entry into the application.   This would 
have to be built into the PyObjC project as a separate module from the 
ones we have now;  a module whose sole purpose is to control this 
particular parameter.

> Is there a way of physically changing argv[0] from the C side of the 
> bridge to the correct value? That couldn't break anything any more 
> than passing the wrong argv[0] when it execve()'s. As you say though, 
> it probably isn't worth it. It would be cleaner if we could avoid that 
> execve() but I guess env just does a similar exec() anyway.

All of this is just a bunch of hacks to work around the fact that Apple 
doesn't ship the libraries necessary to embed their build of python 
into applications.   A bug has been filed regarding that via 
bugreport.apple.com, but it always helps if others file the same bug-- 
gives Apple an idea of how many developers are interested in the 
problem-- so, if you haven't done so, please go file an enhancement 
request at bugreport.apple.com asking that Apple please ship a complete 
python distribution that (a) includes a linkable library for embedding 
and (b) includes the full set of unit tests that normally ship with 
python.

>> A symlink to the python interpreter could be included in the app 
>> wrapper, but that would be extremely fragile for all but the Apple 
>> provided interpreter.   The call to execve() doesn't add *that* much 
>> overhead to the startup process and the current main() and Main.py 
>> can do things like automatically loading frameworks based on what is 
>> linked into the executable (as well as a handful of other features).
>
> Unless everyone symlinks /usr/bin/python to their real interpreter but 
> I guess that really isn't worth it. The current approach is much more 
> flexible.

The alternative would be for the app to symlink to the real interpreter 
directly within the app wrapper upon installation, but that pretty much 
kills the drag-n-drop style of installation -- unacceptable as far as 
I'm concerned.

In general, I shy away from symlinks for problems like this because 
they tend to break in the most unlikely of contexts...

>> I'm going to clean up everything, including the project template, in 
>> preparation for a 0.8.0 release.   Take what we have now and release 
>> it so people don't stumble on 0.6.x any longer...   Want to have it 
>> out by end of this weekend.
>
> Good idea. I've been playing with PyObjC since last year and have been 
> looking for a new version frequently. I thought the project was dead. 
> It was only when I decided to look at the mailing list that I realised 
> how far it's come. There *really* needs to be a new version released.

Yes.   There will be very soon.  I'll do a cut on Sunday evening, 
regardless of what state everything is in [as long as it continues to 
work as well as it does right now-- which is really, really well].

Jim Tittsler was kind enough to send a brand spanking new web site to 
me.  Includes a make environment, FAQ, documentation, examples, and 
everything else... and a really cool dog/snake icon.   I have asked him 
to forward along a discussion of it to the list so that we can review 
it before it gets shoved into CVS.

It has a couple of advantages over what was recently discussed-- 
namely, it exists, it works right now, it is really simple, and it can 
be configured to automatically regenerate the site on sourceforge's 
server as we push out new releases.

Very, very cool -- a HUGE thank you to Jim for doing this as it is 
definitely going to take the project to the next level!

b.bum


b.bum
....lying there snoring,
	breath smelling like a 1948 buick.


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

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

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

On Thursday, November 7, 2002, at 07:13 AM, bb...@ma... wrote:

> On Wednesday, November 6, 2002, at 09:23 AM, Peter Montagner wrote:
>> Is there any reason why the executable pointed to by 
>> CFBundleExecutable has to be a Mach-O file?
>
> Not in and of itself... but it fixes a separate problem with the 
> lightest possible solution I could come up with (faster than launching 
> Python interpreter).

OK, it was just an experiment to see if we could avoid C code in the 
app completely. Of course if you are shipping a couple of MBs of pyobjc 
in the Resources folder, it's a moot point. Is there anything that can 
be done to reduce that code size? I'm thinking of register.m ...


> (This really isn't a bug in NSBundle -- more of a lacking feature.  
> There needs to be a way to tell NSBundle that yes, in fact, you really 
> want to point the main bundle HERE and not THERE before it 
> initializes.  An enhancement request has been filed at 
> bugreport.apple.com.)

I'd say it *is* a bug. Anything after NSApplicationMain() should use 
the launch arguments passed to it rather than trying to get the 
arguments itself. Otherwise, what is the point of that function having 
those arguments?

Is there a way of physically changing argv[0] from the C side of the 
bridge to the correct value? That couldn't break anything any more than 
passing the wrong argv[0] when it execve()'s. As you say though, it 
probably isn't worth it. It would be cleaner if we could avoid that 
execve() but I guess env just does a similar exec() anyway.


> A symlink to the python interpreter could be included in the app 
> wrapper, but that would be extremely fragile for all but the Apple 
> provided interpreter.   The call to execve() doesn't add *that* much 
> overhead to the startup process and the current main() and Main.py can 
> do things like automatically loading frameworks based on what is 
> linked into the executable (as well as a handful of other features).

Unless everyone symlinks /usr/bin/python to their real interpreter but 
I guess that really isn't worth it. The current approach is much more 
flexible.


> I'm going to clean up everything, including the project template, in 
> preparation for a 0.8.0 release.   Take what we have now and release 
> it so people don't stumble on 0.6.x any longer...   Want to have it 
> out by end of this weekend.

Good idea. I've been playing with PyObjC since last year and have been 
looking for a new version frequently. I thought the project was dead. 
It was only when I decided to look at the mailing list that I realised 
how far it's come. There *really* needs to be a new version released.

Peter

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

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

On Wednesday, November 6, 2002, at 09:23 AM, Peter Montagner wrote:
> Is there any reason why the executable pointed to by 
> CFBundleExecutable has to be a Mach-O file?

Not in and of itself... but it fixes a separate problem with the 
lightest possible solution I could come up with (faster than launching 
Python interpreter).

> Now, I've been experimenting with making a modified Main.py the 
> CFBundleExecutable, hoping to avoid the execve(). I can't seem to get 
> it working though. NSApplicationMain() dies complaining about not 
> finding the Info.plist file. I'm not sure I understand what's 
> happening. The launch arguments seem to carry across OK.
>
> Am I reinventing the broken wheel here? Do we have the execve() 
> procedure because the simpler approach fails?
>
> Obviously this approach would be inferior to having an embeddable 
> version of python in an ObjC wrapper but could this approach be used 
> to remove the execve()?

Whatever actually executes the application-- be it a direct executable 
or the python interpreter-- must be physically located within the app 
wrapper (can be a symlink).  As Ronald noted, NSBundle's mainBundle 
doesn't initialize correctly otherwise.

For example, say I have the following script as /tmp/b.py:

#!/usr/bin/env python
from Foundation import *
print NSBundle.mainBundle().bundlePath()

Then:

[bumbox:~] bbum% python /tmp/b.py
/usr/bin
[bumbox:~] bbum% /tmp/b.py
/usr/bin

The problem is that NSBundle determines the directory of the main 
bundle based on argv[0] -- not sys.argv, but the argument list passed 
into the python interpreter itself (which removes itself from argv 
before passing control to the script).

The execve() based main() simply constructs a set of arguments that 
points to the script inside the app wrapper as argv[0] before passing 
control to the python interpreter.   This way, NSBundle initializes 
correctly after control is passed to the python interpreter.

(This really isn't a bug in NSBundle -- more of a lacking feature.  
There needs to be a way to tell NSBundle that yes, in fact, you really 
want to point the main bundle HERE and not THERE before it initializes. 
  An enhancement request has been filed at bugreport.apple.com.)

A symlink to the python interpreter could be included in the app 
wrapper, but that would be extremely fragile for all but the Apple 
provided interpreter.   The call to execve() doesn't add *that* much 
overhead to the startup process and the current main() and Main.py can 
do things like automatically loading frameworks based on what is linked 
into the executable (as well as a handful of other features).

I'm going to clean up everything, including the project template, in 
preparation for a 0.8.0 release.   Take what we have now and release it 
so people don't stumble on 0.6.x any longer...   Want to have it out by 
end of this weekend.

b.bum

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

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

I've repeated your experiment and see the same problem. The problem 
seems to be caused by a wrong mainBundle. I've added the following 
lines to the start of the python script:
	import objc
	print sys.argv[0]
	print  objc.lookup_class('NSBundle').mainBundle().bundlePath()

The first print statement emits the full path of the script inside the 
.app bundle. The second line prints /usr/local/bin, which is where my 
python interpreter is living.

Ronald

On Wednesday, Nov 6, 2002, at 15:23 Europe/Amsterdam, Peter Montagner 
wrote:

> Is there any reason why the executable pointed to by 
> CFBundleExecutable has to be a Mach-O file?
>
> As a quick test I threw the HelloWorld.py example into a .app Bundle, 
> copied and edited a reasonable Info.plist and I now have a double 
> clickable version of hello world that still doesn't use any C code.
>
> I just added #!/usr/bin/env python to the top of HelloWorld.py and ran 
> chmod +x on it.
>
> Now, I've been experimenting with making a modified Main.py the 
> CFBundleExecutable, hoping to avoid the execve(). I can't seem to get 
> it working though. NSApplicationMain() dies complaining about not 
> finding the Info.plist file. I'm not sure I understand what's 
> happening. The launch arguments seem to carry across OK.
>
> Am I reinventing the broken wheel here? Do we have the execve() 
> procedure because the simpler approach fails?
>
> Obviously this approach would be inferior to having an embeddable 
> version of python in an ObjC wrapper but could this approach be used 
> to remove the execve()?
>
> Just a thought,
> Peter
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm Tungsten T 
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

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

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

Is there any reason why the executable pointed to by CFBundleExecutable 
has to be a Mach-O file?

As a quick test I threw the HelloWorld.py example into a .app Bundle, 
copied and edited a reasonable Info.plist and I now have a double 
clickable version of hello world that still doesn't use any C code.

I just added #!/usr/bin/env python to the top of HelloWorld.py and ran 
chmod +x on it.

Now, I've been experimenting with making a modified Main.py the 
CFBundleExecutable, hoping to avoid the execve(). I can't seem to get 
it working though. NSApplicationMain() dies complaining about not 
finding the Info.plist file. I'm not sure I understand what's 
happening. The launch arguments seem to carry across OK.

Am I reinventing the broken wheel here? Do we have the execve() 
procedure because the simpler approach fails?

Obviously this approach would be inferior to having an embeddable 
version of python in an ObjC wrapper but could this approach be used to 
remove the execve()?

Just a thought,
Peter

Re: [Pyobjc-dev] NSDocument based app

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

On Wednesday, Nov 6, 2002, at 11:19 Europe/Amsterdam, Ronald Oussoren 
wrote:
>> So (void *) arguments are broken? Hmm... well I can avoid that in my 
>> example app by using the print panel rather than the sheet. The panel 
>> doesn't require a call back. There are a few things that use the 
>> (void *)contextInfo paradigm though, so we should probably fix it. 
>> What's the current scheme?
>>
> Not really broken, just not working as you want :-) Problem is that it 
> hard to automaticly translate from a Python object to a void*: Do you 
> want to pass the object itself (like you probably want to do here) or 
> should the object be translated to some native type (like you'd want 
> to do with 'int write(int fd, void* buf, int len)').
>
> The current scheme is that you'll have to manually write methods that 
> do the right thing. But, I'll probably add a mechanism to get this 
> type of void* arguments to work without writing C code.

What I tend to do if I run into this situation when wrapping an API is 
the following:
- If the Python object is None I pass NULL, else
- If the Python object conforms to the buffer protocol we use 
bf_getreadbuffer() or bf_getwritebuffer(), else
- if it's a PyCObject we use PyCObject_AsVoidPtr().
--
- 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] NSDocument based app

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

On Wednesday, November 6, 2002, at 09:19 PM, Ronald Oussoren wrote:

>
> On Wednesday, Nov 6, 2002, at 10:52 Europe/Amsterdam, Peter Montagner 
> wrote:
>>> The last argument is problematic: void pointers currently require 
>>> manual assistance. We can at least support automatic translation 
>>> from None to a NULL pointer.
>>
>> So (void *) arguments are broken? Hmm... well I can avoid that in my 
>> example app by using the print panel rather than the sheet. The panel 
>> doesn't require a call back. There are a few things that use the 
>> (void *)contextInfo paradigm though, so we should probably fix it. 
>> What's the current scheme?
>>
> Not really broken, just not working as you want :-) Problem is that it 
> hard to automaticly translate from a Python object to a void*: Do you 
> want to pass the object itself (like you probably want to do here) or 
> should the object be translated to some native type (like you'd want 
> to do with 'int write(int fd, void* buf, int len)').
>
> The current scheme is that you'll have to manually write methods that 
> do the right thing. But, I'll probably add a mechanism to get this 
> type of void* arguments to work without writing C code.

Doing a quick grep of the AppKit.framework headers reveals that there 
are about 40 methods with a (void *) argument and a few that return a 
(void *). Almost all of those that use (void *) as an argument use it 
in the same way as my method, as an extra bit of user data. Even if 
nobody uses it, PyObjC will still choke on all of those methods. If I 
understand this correctly of course.

The Foundation.framework has about 20 but most of those aren't the kind 
of thing you'd call from Python.

Peter

Re: [Pyobjc-dev] NSDocument based app

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

On Wednesday, Nov 6, 2002, at 10:52 Europe/Amsterdam, Peter Montagner 
wrote:
>> The last argument is problematic: void pointers currently require 
>> manual assistance. We can at least support automatic translation from 
>> None to a NULL pointer.
>
> So (void *) arguments are broken? Hmm... well I can avoid that in my 
> example app by using the print panel rather than the sheet. The panel 
> doesn't require a call back. There are a few things that use the (void 
> *)contextInfo paradigm though, so we should probably fix it. What's 
> the current scheme?
>
Not really broken, just not working as you want :-) Problem is that it 
hard to automaticly translate from a Python object to a void*: Do you 
want to pass the object itself (like you probably want to do here) or 
should the object be translated to some native type (like you'd want to 
do with 'int write(int fd, void* buf, int len)').

The current scheme is that you'll have to manually write methods that 
do the right thing. But, I'll probably add a mechanism to get this type 
of void* arguments to work without writing C code.

Ronald

Re: [Pyobjc-dev] NSDocument based app

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

On Wednesday, November 6, 2002, at 08:34 PM, Ronald Oussoren wrote:

>
> On Wednesday, Nov 6, 2002, at 10:21 Europe/Amsterdam, Peter Montagner 
> wrote:
>
>>
>> On Wednesday, November 6, 2002, at 07:28 PM, Ronald Oussoren wrote:
>>
>>>
>>> On Wednesday, Nov 6, 2002, at 08:53 Europe/Amsterdam, Peter 
>>> Montagner wrote:
>>>
>>>> The app works correctly in all the cases you mentioned. It will 
>>>> also correctly open a new window when it is brought to the front by 
>>>> clicking on the dock icon, if no other documents are open. Like I 
>>>> said, everything else I've tried works.
>>> The Todo application that is part of the source-tree has the same 
>>> problem. That's not very helpfull, but at least this shows the 
>>> problem is probably in PyObjC.
>>
>> Good to hear. No wait, that's bad. Any idea what's causing it?
> Not yet...

I'll take a look. I'm pretty new to PyObjC, but I've been programming 
in Objective-C since the Mac OS X PB came out.


>> For some unknown reason, that isn't working. It dies while executing
>>
>> - (void)runModalPrintOperation:(NSPrintOperation *)printOperation 
>> delegate:(id)delegate didRunSelector:(SEL)didRunSelector 
>> contextInfo:(void *)contextInfo
>
> The last argument is problematic: void pointers currently require 
> manual assistance. We can at least support automatic translation from 
> None to a NULL pointer.

So (void *) arguments are broken? Hmm... well I can avoid that in my 
example app by using the print panel rather than the sheet. The panel 
doesn't require a call back. There are a few things that use the (void 
*)contextInfo paradigm though, so we should probably fix it. What's the 
current scheme?

Peter

Re: [Pyobjc-dev] NSDocument based app

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

On Wednesday, Nov 6, 2002, at 10:21 Europe/Amsterdam, Peter Montagner 
wrote:

>
> On Wednesday, November 6, 2002, at 07:28 PM, Ronald Oussoren wrote:
>
>>
>> On Wednesday, Nov 6, 2002, at 08:53 Europe/Amsterdam, Peter Montagner 
>> wrote:
>>
>>> The app works correctly in all the cases you mentioned. It will also 
>>> correctly open a new window when it is brought to the front by 
>>> clicking on the dock icon, if no other documents are open. Like I 
>>> said, everything else I've tried works.
>> The Todo application that is part of the source-tree has the same 
>> problem. That's not very helpfull, but at least this shows the 
>> problem is probably in PyObjC.
>
> Good to hear. No wait, that's bad. Any idea what's causing it?
Not yet...

>
>
>>> Except printing. How do selectors work? Specifically I need to call
>>>
>>> runModalPageLayoutWithPrintInfo:delegate:didRunSelector:contextInfo:
>>>
>>> How do I pass a selector to this? I actually want to send a NULL for 
>>> the selector (I have nothing to do when the sheet is closed). In 
>>> ObjC I'd do something like:
>>>
>>>     [self runModalPrintOperation:op
>>>                 delegate:nil
>>>                 didRunSelector:NULL
>>>                 contextInfo:NULL];
>> Selectors (type SEL in Objective-C) are represented as strings in 
>> Python:
>>
>> self.runModalPrintOperation_delagate_didRunSelector_contextInfo_(
>> 	op, nil, "mySelector:", None)
>
> For some unknown reason, that isn't working. It dies while executing
>
> - (void)runModalPrintOperation:(NSPrintOperation *)printOperation 
> delegate:(id)delegate didRunSelector:(SEL)didRunSelector 
> contextInfo:(void *)contextInfo

The last argument is problematic: void pointers currently require 
manual assistance. We can at least support automatic translation from 
None to a NULL pointer.

The error message is not very helpfull.

Ronald

Re: [Pyobjc-dev] NSDocument based app

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

On Wednesday, November 6, 2002, at 07:28 PM, Ronald Oussoren wrote:

>
> On Wednesday, Nov 6, 2002, at 08:53 Europe/Amsterdam, Peter Montagner =20=

> wrote:
>
>> The app works correctly in all the cases you mentioned. It will also =20=

>> correctly open a new window when it is brought to the front by =20
>> clicking on the dock icon, if no other documents are open. Like I =20
>> said, everything else I've tried works.
> The Todo application that is part of the source-tree has the same =20
> problem. That's not very helpfull, but at least this shows the problem =
=20
> is probably in PyObjC.

Good to hear. No wait, that's bad. Any idea what's causing it?


>> Except printing. How do selectors work? Specifically I need to call
>>
>> runModalPageLayoutWithPrintInfo:delegate:didRunSelector:contextInfo:
>>
>> How do I pass a selector to this? I actually want to send a NULL for =20=

>> the selector (I have nothing to do when the sheet is closed). In ObjC =
=20
>> I'd do something like:
>>
>>     [self runModalPrintOperation:op
>>                 delegate:nil
>>                 didRunSelector:NULL
>>                 contextInfo:NULL];
> Selectors (type SEL in Objective-C) are represented as strings in =20
> Python:
>
> self.runModalPrintOperation_delagate_didRunSelector_contextInfo_(
> 	op, nil, "mySelector:", None)

For some unknown reason, that isn't working. It dies while executing

- (void)runModalPrintOperation:(NSPrintOperation *)printOperation =20
delegate:(id)delegate didRunSelector:(SEL)didRunSelector =20
contextInfo:(void *)contextInfo

Here the method:

     # Print our document
     def printShowingPrintPanel_(self, showPanels):
         printInfo =3D self.printInfo()
         printOp =3D =20
NSPrintOperation.printOperationWithView_printInfo_(self.rtfTextView,prin=20=

tInfo)
         printOp.setShowPanels_(showPanels)
         =20
self.runModalPrintOperation_delegate_didRunSelector_contextInfo_(
             printOp, self, "printOperationDidRun:success:contextInfo:", =
=20
None)

It gets this error:

  objc_sizeof_type: Unhandled type '=00'

I'm probably doing something stupid.

Peter=

Re: [Pyobjc-dev] NSDocument based app

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

On Wednesday, Nov 6, 2002, at 08:53 Europe/Amsterdam, Peter Montagner 
wrote:

> The app works correctly in all the cases you mentioned. It will also 
> correctly open a new window when it is brought to the front by 
> clicking on the dock icon, if no other documents are open. Like I 
> said, everything else I've tried works.
The Todo application that is part of the source-tree has the same 
problem. That's not very helpfull, but at least this shows the problem 
is probably in PyObjC.

>
> Except printing. How do selectors work? Specifically I need to call
>
> runModalPageLayoutWithPrintInfo:delegate:didRunSelector:contextInfo:
>
> How do I pass a selector to this? I actually want to send a NULL for 
> the selector (I have nothing to do when the sheet is closed). In ObjC 
> I'd do something like:
>
>     [self runModalPrintOperation:op
>                 delegate:nil
>                 didRunSelector:NULL
>                 contextInfo:NULL];
Selectors (type SEL in Objective-C) are represented as strings in 
Python:

self.runModalPrintOperation_delagate_didRunSelector_contextInfo_(
	op, nil, "mySelector:", None)

Re: [Pyobjc-dev] NSDocument based app

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

The app works correctly in all the cases you mentioned. It will also 
correctly open a new window when it is brought to the front by clicking 
on the dock icon, if no other documents are open. Like I said, 
everything else I've tried works.

Except printing. How do selectors work? Specifically I need to call

runModalPageLayoutWithPrintInfo:delegate:didRunSelector:contextInfo:

How do I pass a selector to this? I actually want to send a NULL for 
the selector (I have nothing to do when the sheet is closed). In ObjC 
I'd do something like:

     [self runModalPrintOperation:op
                 delegate:nil
                 didRunSelector:NULL
                 contextInfo:NULL];

If you can't do a NULL selector in PyObjC, I'd settle for knowing how 
to specify a valid selector :-)

Thanks,
Peter

On Wednesday, November 6, 2002, at 05:05 PM, bb...@ma... wrote:

> Cool!   This sounds like an excellent example to (a) include in the 
> Examples/ directory and (b) model the Multi-Document project template 
> after!
>
> In terms of the bug:  Does the app work correctly when you drag-n-drop 
> a file onto the dock icon to open the document?   I recently put 
> together a multi-doc architecture app and everything works perfectly 
> but that-- I didn't notice the lack of an untitled doc on launch 
> because I implemented the method that *should* disable it from the 
> start (but never checked that the method was actually invoked).
>
> b.bum

Re: [Pyobjc-dev] NSDocument based app

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

Cool!   This sounds like an excellent example to (a) include in the 
Examples/ directory and (b) model the Multi-Document project template 
after!

In terms of the bug:  Does the app work correctly when you drag-n-drop 
a file onto the dock icon to open the document?   I recently put 
together a multi-doc architecture app and everything works perfectly 
but that-- I didn't notice the lack of an untitled doc on launch 
because I implemented the method that *should* disable it from the 
start (but never checked that the method was actually invoked).

b.bum

[Pyobjc-dev] NSDocument based app

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

Hi,

First, I'd like to say "nice work!".

Second, I've built a python NSDocument based RTF text editor. It's the 
classic bit of example code that shows how easy Cocoa is. It works, but 
there is a bug. When the application is first launched it doesn't 
create the standard untitled window. File -> New works, as does pretty 
much everything else. I created an Objective-C version of the program 
that is identical to the python one (I copied the project folder, 
removed the python source and added the Objective-C Document subclasses 
and a normal main.m). It has the proper behaviour on start, which means 
that it isn't my code (I think).

My guess is that it has something to do with the execve() call. It's 
only a guess though. Maybe I should test it with an embeddable python 
install (I'm using Apple's). If I just grab the standard python.org 
distribution and install it, will it work? Or do I need to get fink?

BTW, do you want it as sample code? Other than that small bug it's a 
working editor.

Peter