pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] [ pyobjc-Bugs-806372 ] Crash in NSBezierPath.appendBezierPathWithPoints_count_()

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

Bugs item #806372, was opened at 2003-09-15 07:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=806372&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dinu C. Gherman (dinu_gherman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash in NSBezierPath.appendBezierPathWithPoints_count_()

Initial Comment:
Probably a bug... (OS X 10.2.6, /usr/bin/python):



Python 2.2.3 (#1, Sep 10 2003, 11:51:43) 

[GCC 3.1 20020420 (prerelease)] on darwin

Type "help", "copyright", "credits" or "license" for more 

information.

>>> 

>>> import objc

>>> objc.__version__

'1.0b1'

>>> from AppKit import *

>>> path = NSBezierPath.bezierPath()

>>> path.appendBezierPathWithOvalInRect_(((0,0), 

(100,100))) # works fine!

>>> points = [(0,0), (100,0), (100,100)]

>>> path.appendBezierPathWithPoints_count_(points, 

len(points)) # crashes!

Bus error



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

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

[Pyobjc-dev] 1.0rc3

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

And yet another prerelease, this one includes nibclassbuilder and seems 
to fix the problem with NSRectFillList.

The unittests cause a crash, basicly because the ObjC program below 
crashes (Radar #3421569). The next release will disable the crashing 
PyObjC testcase on Jaguar systems.

Ronald

P.S. http://pyobjc.sf.net/prerelease/pyobjc-1.0rc3.tar.gz and 
http://pyobjc.sf.net/prerelease/pyobjc-1.0rc3.dmg

Re: [Pyobjc-dev] conversion of tuples to structs

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

On 12 sep 2003, at 22:39, b.bum wrote:

> On Sep 11, 2003, at 5:36 PM, Tobias Sargeant wrote:
>> I appreciate that the symmetry of the pythonifying/depythonifying is
>> neat, but it would be extremely useful (for example) to be able to 
>> pass
>> Numeric arrays representing points to objc functions without the 
>> overhead
>> (both in terms of execution speed and in terms of typing) of 
>> converting
>> them to tuples.
>
> (You'll need to do a cvs update to grab a version of PyObjC that can 
> support what is described below)
>
> Over Christmas, I did some graphics performance tests and found that 
> the fastest possible way to get points across the bridge and onto the 
> screen was through the use of something like....
>
>             points = array.array('f', [0.0,0.0,1.0,1.0] * colorIter)
>
> That is, allocate points as an array of type float, initialized to 
> contain the sequence 0.0,0.0,1.0,1.0 repeated colorIter times.  Then, 
> update the contents as needed and invoke....
>
>             NSRectFillList(points, colorIter)
>
> ... to draw.   This is possible because NSRectFillList() is bridged in 
> a fashion that accepts both tuples and the array.array() construct.   
> The array.array() construct is very fast mostly because it can be 
> passed directly to NSRectFillList() without any conversion.
>
> Except that the current version of the bridge breaks this with the 
> comment:
>
> 		/* Upto PyObjC 1.0b2 compat_NSRectFillList was the wrapper for 
> NSRectFillList
> 		 * this implementation is not consistant w.r.t. the rest of the 
> bridge and
> 		 * therefore depricated.
> 		 */
>
> Which is really unfortunate because the new version has to allocate a 
> chunk of memory, then loop through every tuple and turn it into an 
> array of floats -- this really adds up when pumping through 100s of 
> thousands of rectangles.  Given that 1x1 rectangles are the most 
> efficient way of pushing non-anti-aliased points or lines to the 
> screen, this situation is common in graphic intensive Cocoa apps.
>
> Some numbers:    I wrote a little app that implements the Hopalong 
> algorithm to draw lots of pretty dots on the screen.  Using the Tuple 
> based conversion, I see....
>
[ that the array.array version is about 6x faster ]


>
> The same carries through to the rest of the APIs that take (NSPoint 
> **) or (NSRect **) type arrays of points/rects/etc...

This change in speed seems a good reason to support array.array or 
Numberic arrays to represent arrays of structs. The best way to do this 
would be adding a (pair of) function(s) to the core bridge and 
pyobjc-api.h, and use those in the wrapper modules.

Something like:

	PyObject* pyRects;
	int rectCount;
	NSRect* rectArray;

	// set pyRects and rectCount

	rectArray =  PyObjC_MakeObjCArray(@encode(NSRect), pyRects, rectCount);

	// use rectArray

	PyObjC_FreeObjCArray(rectArray);


Ronald

[Pyobjc-dev] Bus error in NSBezierPath.appendBezierPathWithPoints_count_()

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

Hi,

is there some other trick to make this work or is it a bug?
appendBezierPathWithOvalInRect_() works ok, but the other
method appendBezierPathWithPoints_count_() crashes reliably:

   >>> from AppKit import *
   >>> path = NSBezierPath.bezierPath()
   >>> path.appendBezierPathWithOvalInRect_(((0,0), (100,100)))
   >>> points = [(0,0), (100,0), (100,100)]
   >>> path.appendBezierPathWithPoints_count_(points, len(points))
   Bus error

Dinu

--
Dinu C. Gherman
......................................................................
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." (Benjamin Franklin)

[Pyobjc-dev] [ pyobjc-Bugs-805318 ] NSRectFillList() malloc bogosity

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

Bugs item #805318, was opened at 2003-09-12 16:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=805318&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Nobody/Anonymous (nobody)
Summary: NSRectFillList() malloc bogosity

Initial Comment:


I introduced some bogosity into NSRectFillList in _AppKit.m 

to fix a crasher.



In particular:



***************

*** 339,343 ****

  	}



! 	rects = malloc(rectCount * sizeof(NSRect));

  	if (rects == NULL) {

  		PyErr_NoMemory();

--- 340,345 ----

  	}



! #warning The (*4) in the following is bogus.   Without it, 

we crash with what appears to be corrupted memory.  I don't 

know why but figure that not crashing is preferable to 

crashing until one of us has time to figure this out.  Really,  I 

suspect Ronald will take one look at this and, being about 

10x brighter than me at this sort of thing, will know exactly 

what is wrong...  :-)

! 	rects = malloc((rectCount * sizeof(NSRect)) * 4);

  	if (rects == NULL) {

  		PyErr_NoMemory();



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

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

Re: [Pyobjc-dev] conversion of tuples to structs

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

On Sep 11, 2003, at 5:36 PM, Tobias Sargeant wrote:
> I appreciate that the symmetry of the pythonifying/depythonifying is
> neat, but it would be extremely useful (for example) to be able to pass
> Numeric arrays representing points to objc functions without the 
> overhead
> (both in terms of execution speed and in terms of typing) of converting
> them to tuples.

(You'll need to do a cvs update to grab a version of PyObjC that can 
support what is described below)

Over Christmas, I did some graphics performance tests and found that 
the fastest possible way to get points across the bridge and onto the 
screen was through the use of something like....

             points = array.array('f', [0.0,0.0,1.0,1.0] * colorIter)

That is, allocate points as an array of type float, initialized to 
contain the sequence 0.0,0.0,1.0,1.0 repeated colorIter times.  Then, 
update the contents as needed and invoke....

             NSRectFillList(points, colorIter)

... to draw.   This is possible because NSRectFillList() is bridged in 
a fashion that accepts both tuples and the array.array() construct.   
The array.array() construct is very fast mostly because it can be 
passed directly to NSRectFillList() without any conversion.

Except that the current version of the bridge breaks this with the 
comment:

		/* Upto PyObjC 1.0b2 compat_NSRectFillList was the wrapper for 
NSRectFillList
		 * this implementation is not consistant w.r.t. the rest of the 
bridge and
		 * therefore depricated.
		 */

Which is really unfortunate because the new version has to allocate a 
chunk of memory, then loop through every tuple and turn it into an 
array of floats -- this really adds up when pumping through 100s of 
thousands of rectangles.  Given that 1x1 rectangles are the most 
efficient way of pushing non-anti-aliased points or lines to the 
screen, this situation is common in graphic intensive Cocoa apps.

Some numbers:    I wrote a little app that implements the Hopalong 
algorithm to draw lots of pretty dots on the screen.  Using the Tuple 
based conversion, I see....

2003-09-12 13:26:22.303 Hop[2294] Iterated 104300 points in 8.54 
seconds.
2003-09-12 13:26:30.767 Hop[2294] Iterated 104300 points in 8.45 
seconds.
2003-09-12 13:26:39.306 Hop[2294] Iterated 105700 points in 8.52 
seconds.
2003-09-12 13:26:49.118 Hop[2294] Iterated 112900 points in 9.80 
seconds.
2003-09-12 13:26:57.351 Hop[2294] Iterated 108200 points in 8.22 
seconds.

... whereas the array.array('f', ...) method described above yields....

2003-09-12 13:32:07.441 Hop[2309] Iterated 263200 points in 4.28 
seconds.
2003-09-12 13:32:11.422 Hop[2309] Iterated 283600 points in 3.96 
seconds.
2003-09-12 13:32:15.227 Hop[2309] Iterated 270000 points in 3.74 
seconds.
2003-09-12 13:32:19.042 Hop[2309] Iterated 275600 points in 3.80 
seconds.
2003-09-12 13:32:23.577 Hop[2309] Iterated 273600 points in 4.52 
seconds.

... which is about 6x faster.

The same carries through to the rest of the APIs that take (NSPoint **) 
or (NSRect **) type arrays of points/rects/etc...

b.bum

[Pyobjc-dev] Re: Fwd: NSString.drawAtPoint_withAttributes_()

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

Dinu Gherman wrote:

> in order to use print some text on an NSView I found out I need to do
> first this to have access to the drawAtPoint_withAttributes_() which
> is defined in some NSStringAddition category or so of AppKit:
>
>   from Foundation import NSString
>   from AppKit import *
>
> First question is: how to do this without importing *?

"import AppKit" should suffice. In fact, as long as AppKit has been
imported _somewhere_ in your app before you call this, the category
should be loaded. This should be pretty much automatic, as you can't
draw without AppKit being around to begin with.

> Then I get some string like this (not sure if a Python string would
> magically do as well):
>
>   s = NSString.stringWith...(...)
>
> but when calling
>
>   s.drawAtPoint_withAttributes_((x, y), {...})
>
> I get this error:
>
>   AttributeError: 'objc.pyobjc_unicode' object has no attribute
>   'drawAtPoint_withAttributes_'
>
> Has anybody tried writing a string that way to a view before? Is
> this a bug? I'm on PyObjC 1.0b1.

Not a bug, a feature. NStrings are presented to Python as a subclass of
"unicode", the pyobjc_unicode class. You can do what you want in two
ways:

1) Access the method through the class:

    NSString.drawAtPoint_withAttributes_(s, (x, y), {...})

2) Use the pyobjc_unicode.nsstring() method:

    s.nsstring().drawAtPoint_withAttributes_((x, y), {...})

Just

[Pyobjc-dev] NSString.drawAtPoint_withAttributes_()

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

Hi,

in order to use print some text on an NSView I found out I need to do
first this to have access to the drawAtPoint_withAttributes_() which
is defined in some NSStringAddition category or so of AppKit:

   from Foundation import NSString
   from AppKit import *

First question is: how to do this without importing *?

Then I get some string like this (not sure if a Python string would
magically do as well):

   s = NSString.stringWith...(...)

but when calling

   s.drawAtPoint_withAttributes_((x, y), {...})

I get this error:

   AttributeError: 'objc.pyobjc_unicode' object has no attribute
   'drawAtPoint_withAttributes_'

Has anybody tried writing a string that way to a view before? Is
this a bug? I'm on PyObjC 1.0b1.

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"Some are born great, some achieve greatness, and some hire public
relations officers." (Daniel J. Boorstin)

Re: [Pyobjc-dev] conversion of tuples to structs

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

On 12 sep 2003, at 9:33, Just van Rossum wrote:

> Tobias Sargeant wrote:
>
>> Looking at the code in objc_support.m, it's pretty obvious that
>> structs (and arrays) can currently only be built from tuples. Is
>> there any reason why anything that acts as a sequence won't do?
>
> Not really. In the Carbon(-ish) wrappers that come with MacPython we've
> usually made sure this is possible.

Then there's really no reason to not accept any sequences. The only 
reason I could come up with for not allowing lists when converting to a 
struct is that tuples are often used as struct-like objects in Python.

> For example the Carbon.CG module
> accepts any length-6 sequence where it expects an affine transform. 
> Very
> useful (especially since I have a Transform class that also behaves as 
> a
> length-6 sequence ;-). The same goes voor points and rects.
>
>> I appreciate that the symmetry of the pythonifying/depythonifying is
>> neat, but it would be extremely useful (for example) to be able to
>> pass Numeric arrays representing points to objc functions without the
>> overhead (both in terms of execution speed and in terms of typing) of
>> converting them to tuples.
>>
>> If there's no reason (technical or otherwise) why this shouldn't be
>> the case, I'm happy to make the change and submit a patch.
>
> I've been thinking the same thing every now and then. I don't know how
> easy it would be to fix. If those structs were unpacked with
> PyArg_ParseTuple (and I think they aren't), the fix would be easy: just
> use PyArg_Parse instead and add parenthesis to the format strings, eg.
> "ff" would have to become "(ff)". But I have no idea where the struct
> conversions live in the PyObjC code base... Ronald?

The code lives in objc_support.m and doesn't use PyArg_Parse*, we 
directly deconstruct tuples based on the Objective-C type signature. 
The easiest way to add support for arbitrary sequences would be to use 
the PySequence_Fast interface.

BTW. I'm sitting on a patch for objc_support.m that also touches this 
code, I'll add support for arbitrary sequences to that patch. I'd like 
to get the 1.0 release out before adding this to the source tree.

The only item on my TODO-list for 1.0 is a bug that causes a crash of 
the interpreter when working with WebKit on Jaguar (the same code works 
fine on Panther, and when rewritten in ObjC).

Ronald

Re: [Pyobjc-dev] conversion of tuples to structs

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

Tobias Sargeant wrote:

> Looking at the code in objc_support.m, it's pretty obvious that
> structs (and arrays) can currently only be built from tuples. Is
> there any reason why anything that acts as a sequence won't do?

Not really. In the Carbon(-ish) wrappers that come with MacPython we've
usually made sure this is possible. For example the Carbon.CG module
accepts any length-6 sequence where it expects an affine transform. Very
useful (especially since I have a Transform class that also behaves as a
length-6 sequence ;-). The same goes voor points and rects.

> I appreciate that the symmetry of the pythonifying/depythonifying is
> neat, but it would be extremely useful (for example) to be able to
> pass Numeric arrays representing points to objc functions without the
> overhead (both in terms of execution speed and in terms of typing) of
> converting them to tuples.
> 
> If there's no reason (technical or otherwise) why this shouldn't be
> the case, I'm happy to make the change and submit a patch.

I've been thinking the same thing every now and then. I don't know how
easy it would be to fix. If those structs were unpacked with
PyArg_ParseTuple (and I think they aren't), the fix would be easy: just
use PyArg_Parse instead and add parenthesis to the format strings, eg.
"ff" would have to become "(ff)". But I have no idea where the struct
conversions live in the PyObjC code base... Ronald?

Just

[Pyobjc-dev] conversion of tuples to structs

[Tobias S. <to...@pe...>]

Looking at the code in objc_support.m, it's pretty obvious that structs
(and arrays) can currently only be built from tuples. Is there any 
reason
why anything that acts as a sequence won't do?

I appreciate that the symmetry of the pythonifying/depythonifying is
neat, but it would be extremely useful (for example) to be able to pass
Numeric arrays representing points to objc functions without the 
overhead
(both in terms of execution speed and in terms of typing) of converting
them to tuples.

If there's no reason (technical or otherwise) why this shouldn't be the
case, I'm happy to make the change and submit a patch.

Toby.

-- 
url: http://permuted.net/ id: D9E15866 key: 
http://permuted.net/tjs.gpgkey.asc
                fingerprint: EDD8 E1EC 440A D2B6 89BF  AFA4 FBFC 19B6 
D9E1 5866

Re: [Pyobjc-dev] 1.0rc2

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

On 10 sep 2003, at 22:58, Bob Ippolito wrote:

> On Wednesday, Sep 10, 2003, at 15:57 America/New_York, Ronald Oussoren 
> wrote:
>
>> Hi,
>>
>> It's long overdue, but here's another prerelease of 1.0. I haven't 
>> actually tested the installer yet, please let me know of any 
>> problems.
>>
>> source tarball: http://pyobjc.sf.net/prerelease/pyobjc-1.0rc2.tar.gz
>> installer for Python 2.2 on Jaguar: 
>> http://pyobjc.sf.net/prerelease/pyobjc-1.0rc2.dmg
>>
>> This snapshot includes a different version of libffi, one that should 
>> correctly solve the issues in bug #738252. Many thanks to Andreas 
>> Tobler for correctly fixing libffi.
>>
>> I'm hunting down 1 bug that I'd really like to fix before a 1.0 
>> release, otherwise this is it.
>
> In file included from Modules/Foundation/_Foundation.m:283:
> build/codegen/_Fnd_Enum.inc:99: error: 
> `NSHTTPCookieAcceptPolicyAlways' undeclared here (not in a function)
> build/codegen/_Fnd_Enum.inc:99: error: initializer element is not 
> constant
> build/codegen/_Fnd_Enum.inc:99: error: (near initialization for 
> `enum_table[21].value')
> build/codegen/_Fnd_Enum.inc:99: warning: missing initializer
> ................
> build/codegen/_Fnd_Enum.inc:366: error: (near initialization for 
> `enum_table[158]')
> error: command 'gcc' failed with exit status 1
> [crack:~/download/pyobjc-1.0rc2] bob% gcc -v
> Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
> Thread model: posix
> gcc version 3.3 20030304 (Apple Computer, Inc. build 1435)
>
> This is xcode on jaguar.

The regular DevTools on Jaguar (and Xcode on Panther) do work 
correctly. I noticed that the definition of this constant is guarded by 
a version macro (e.g. #if MACOS_X_VERSION >= 10.2), could your compiler 
be configured to build 10.1 binaries?

Ronald

Re: [Pyobjc-dev] 1.0rc2

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

On 10 sep 2003, at 22:46, Russell Finn wrote:

> On Wednesday, September 10, 2003, at 03:57  PM, Ronald Oussoren wrote:
>> It's long overdue, but here's another prerelease of 1.0. I haven't 
>> actually tested the installer yet, please let me know of any 
>> problems.
>>
>> source tarball: http://pyobjc.sf.net/prerelease/pyobjc-1.0rc2.tar.gz
>> installer for Python 2.2 on Jaguar: 
>> http://pyobjc.sf.net/prerelease/pyobjc-1.0rc2.dmg
>
> I get an error on installation, during the postflight script; the log 
> says,
>
> "cp: /usr/lib/python2.2/site-packages/PyObjC/bin/*: No such file or 
> directory"
> "Could not move scripts to the correct location"
>
> which is not surprising because there is no such "bin" directory in 
> the distribution, according to the file listing.
>

That's because I'm an idiot, I had disabled the installation of the 
scripts in setup.py and forgot to enable that again before building the 
package :-(

With some luck I'll build a new installer later today. The installation 
you have now should work  correctly, you just don't have a 
'nibclassbuilder' script.

Ronald

Re: [Pyobjc-dev] 1.0rc2

[Bob I. <bo...@re...>]

On Wednesday, Sep 10, 2003, at 15:57 America/New_York, Ronald Oussoren 
wrote:

> Hi,
>
> It's long overdue, but here's another prerelease of 1.0. I haven't 
> actually tested the installer yet, please let me know of any problems.
>
> source tarball: http://pyobjc.sf.net/prerelease/pyobjc-1.0rc2.tar.gz
> installer for Python 2.2 on Jaguar: 
> http://pyobjc.sf.net/prerelease/pyobjc-1.0rc2.dmg
>
> This snapshot includes a different version of libffi, one that should 
> correctly solve the issues in bug #738252. Many thanks to Andreas 
> Tobler for correctly fixing libffi.
>
> I'm hunting down 1 bug that I'd really like to fix before a 1.0 
> release, otherwise this is it.

In file included from Modules/Foundation/_Foundation.m:283:
build/codegen/_Fnd_Enum.inc:99: error: `NSHTTPCookieAcceptPolicyAlways' 
undeclared here (not in a function)
build/codegen/_Fnd_Enum.inc:99: error: initializer element is not 
constant
build/codegen/_Fnd_Enum.inc:99: error: (near initialization for 
`enum_table[21].value')
build/codegen/_Fnd_Enum.inc:99: warning: missing initializer
................
build/codegen/_Fnd_Enum.inc:366: error: (near initialization for 
`enum_table[158]')
error: command 'gcc' failed with exit status 1
[crack:~/download/pyobjc-1.0rc2] bob% gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1435)

This is xcode on jaguar.

-bob

Re: [Pyobjc-dev] 1.0rc2

[Russell F. <rf...@op...>]

On Wednesday, September 10, 2003, at 03:57  PM, Ronald Oussoren wrote:
> It's long overdue, but here's another prerelease of 1.0. I haven't 
> actually tested the installer yet, please let me know of any problems.
>
> source tarball: http://pyobjc.sf.net/prerelease/pyobjc-1.0rc2.tar.gz
> installer for Python 2.2 on Jaguar: 
> http://pyobjc.sf.net/prerelease/pyobjc-1.0rc2.dmg

I get an error on installation, during the postflight script; the log 
says,

"cp: /usr/lib/python2.2/site-packages/PyObjC/bin/*: No such file or 
directory"
"Could not move scripts to the correct location"

which is not surprising because there is no such "bin" directory in the 
distribution, according to the file listing.

-- Russell

-- 
Russell S. Finn
Principal Software Engineer, Software Architecture and Design
OPNET Technologies, Inc.
Phone: +1-240-497-3000 / Fax: +1-240-497-3001
Web: <http://www.opnet.com>
====================================================
Register for OPNET's Online Technology Workshops
<http://www.opnet.com/TechWorkshops/>
====================================================

[Pyobjc-dev] 1.0rc2

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

Hi,

It's long overdue, but here's another prerelease of 1.0. I haven't 
actually tested the installer yet, please let me know of any problems.

source tarball: http://pyobjc.sf.net/prerelease/pyobjc-1.0rc2.tar.gz
installer for Python 2.2 on Jaguar: 
http://pyobjc.sf.net/prerelease/pyobjc-1.0rc2.dmg

This snapshot includes a different version of libffi, one that should 
correctly solve the issues in bug #738252. Many thanks to Andreas 
Tobler for correctly fixing libffi.

I'm hunting down 1 bug that I'd really like to fix before a 1.0 
release, otherwise this is it.

Ronald

Re: [Pyobjc-dev] Using bundlebuilder on PB projects

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

Just van Rossum:

> I can't be bothered to compare directory structures, but I'll do you 
> the
> favor of translating the relevant portion of your Info.plist to Python.
> See below.

Thanks! I didn't mean to bother you, but while taking notes and
executing commands I was happy to find some hackish way to get
a working app... I'm making progress in understanding what's
going on and will look deeper into the source.

Something I seem to miss in bundlebuilder is the ability to build
not only in a specific output directory but also to take an in-
put from a specific directory. At least the options below don't
indicate this. Maybe this is because bundlebuilder try following
the philosophy of Distutils? BTW, what about having bundlebuilder
as a plugin for Distutils, so you can generate OS X bundles, like
RPMs, say?

Here is a result of a maybe useful application that I've just
build with Python included, please let me know if it causes any
strange (startup) effects for any of you:

   http://python.net/~gherman/RegexPlor.html

Thanks and regards,

Dinu


Usage:
   python bundlebuilder.py [options] command
   python mybuildscript.py [options] command

Commands:
   build      build the application
   report     print a report

Options:
   -b, --builddir=DIR     the build directory; defaults to "build"
   -n, --name=NAME        application name
   -r, --resource=FILE    extra file or folder to be copied to Resources
   -e, --executable=FILE  the executable to be used
   -m, --mainprogram=FILE the Python main program
   -p, --plist=FILE       .plist file (default: generate one)
       --nib=NAME         main nib name
   -c, --creator=CCCC     4-char creator code (default: '????')
   -l, --link             symlink files/folder instead of copying them
       --link-exec        symlink the executable instead of copying it
       --standalone       build a standalone application, which is fully
                          independent of a Python installation
   -x, --exclude=MODULE   exclude module (with --standalone)
   -i, --include=MODULE   include module (with --standalone)
       --package=PACKAGE  include a whole package (with --standalone)
       --strip            strip binaries (remove debug info)
   -v, --verbose          increase verbosity level
   -q, --quiet            decrease verbosity level
   -h, --help             print this message

Re: [Pyobjc-dev] Using bundlebuilder on PB projects

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

Dinu Gherman wrote:

> > Multi-doc app: make sure you either create an Info.plist file or
> > manually create a plist object in your buildapp.py script.
> 
> I've tried that, but I still don't get it. It's not clear what kind
> of entries I need for what kind of file (file types?)? You example
> has too much of a font context for me... 

Well, check what you get when you do Plist.fromFile("yourplist"). You
only need to fill in those values that bundlebuilder can fill in for
you, in many cases you only need to worry about CFBundleDocumentTypes.

I can't be bothered to compare directory structures, but I'll do you the
favor of translating the relevant portion of your Info.plist to Python.
See below.

> I can safely remove the pbdevelopment.plist and the app still launches
> ok. So I guess all your plist magic deals with generating the 
> Info.plist,
> right? Ok, let's keep going.

Why do you think it's magic? The "plist" argument of buildapp is indeed
for Info.plist, it does nothing else. Read the source, it's pretty
simple. Bundlebuilder usually creates one for you, but you can give it
one for stuff it can't guess, such as CFBundleDocumentTypes.

> As expected this application doesn't work as it should. It starts up,
> but doesn't show any window! But... drumrolls...! If you replace its
> top Info.plist with the one previously saved the app runs just fine!!

Which is why (drumroll!) I pointed you towards buildapp's plist to begin
with.

Snipping those entries filled in by bundlebuilder if not given:

> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" 
> "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
> <plist version="1.0">
> <dict>
[ ... ]
>   <key>CFBundleDocumentTypes</key>
>   <array>
>       <dict>
>           <key>CFBundleTypeExtensions</key>
>           <array>
>               <string>????</string>
>           </array>
>           <key>CFBundleTypeName</key>
>           <string>DocumentType</string>
>           <key>CFBundleTypeOSTypes</key>
>           <array>
>               <string>????</string>
>           </array>
>           <key>CFBundleTypeRole</key>
>           <string>Editor</string>
>           <key>NSDocumentClass</key>
>           <string>MyDocument</string>
>       </dict>
>   </array>
[ ... ]
> </dict>
> </plist>

plist = Plist(
    CFBundleDocumentTypes = [
        Dict(
            CFBundleTypeExtensions = ["????"],
            CFBundleTypeName = "DocumentType",
            CFBundleTypeOSTypes = ["???"],
            CFBundleTypeRole = "Editor",
            NSDocumentClass = "MyDocument",
        ),
    ]
)

Instead of plistlib's Dict() you can also use 2.3's dict(), it also
accepts keyword args to construct the dict. The following is equivalent
to the above:

plist = Plist()
plist.update({
    "CFBundleDocumentTypes": [
        {
            "CFBundleTypeExtensions": ["????"],
            "CFBundleTypeName": "DocumentType",
            "CFBundleTypeOSTypes": ["???"],
            "CFBundleTypeRole": "Editor",
            "NSDocumentClass": "MyDocument",
        },
    ]
})

Just

Re: [Pyobjc-dev] Using bundlebuilder on PB projects

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

Just van Rossum:

> Multi-doc app: make sure you either create an Info.plist file or
> manually create a plist object in your buildapp.py script.

I've tried that, but I still don't get it. It's not clear what kind
of entries I need for what kind of file (file types?)? You example
has too much of a font context for me... Also, I'm uncertain if I
really need a new Main.py or if the template's __main__.py will do
and what the Main.py file should contain compared to __main__.py?

Let's make a laboratory experiment. If it works out ok, I'll become
a very happy user of bundlebuilder! let's use the PB template for
a "Cocoa Python Document-based Application" and save it using a name
like CocoaPyDocApp. "pbxbuild build" turns that into an application
just as I'd expect it. Before running it I have this list of files:

dinu% tree2.py -f CocoaPyDocApp/
|  /
|  |  00README.txt
|  |  __main__.py
|  |  bin-python-main.m
|  |  CocoaPyDocApp.pbproj/
|  |  |  dinu.pbxuser
|  |  |  project.pbxproj
|  |  English.lproj/
|  |  |  Credits.rtf
|  |  |  InfoPlist.strings
|  |  |  MainMenu.nib/
|  |  |  |  classes.nib
|  |  |  |  info.nib
|  |  |  |  keyedobjects.nib
|  |  |  MyDocument.nib/
|  |  |  |  classes.nib
|  |  |  |  info.nib
|  |  |  |  objects.nib
|  |  MyAppDelegate.py
|  |  MyDocument.py

After running "pbxbuild build" I get this list (only the output
app wrapper is listed):

dinu% tree2.py -f CocoaPyDocApp/
|  /
|  |  build/
|  |  |  CocoaPyDocApp.app/
|  |  |  |  Contents/
|  |  |  |  |  Info.plist
|  |  |  |  |  MacOS/
|  |  |  |  |  |  CocoaPyDocApp
|  |  |  |  |  pbdevelopment.plist
|  |  |  |  |  PkgInfo
|  |  |  |  |  Resources/
|  |  |  |  |  |  __main__.py
|  |  |  |  |  |  English.lproj/
|  |  |  |  |  |  |  Credits.rtf
|  |  |  |  |  |  |  InfoPlist.strings
|  |  |  |  |  |  |  MainMenu.nib/
|  |  |  |  |  |  |  |  classes.nib
|  |  |  |  |  |  |  |  info.nib
|  |  |  |  |  |  |  |  keyedobjects.nib
|  |  |  |  |  |  |  MyDocument.nib/
|  |  |  |  |  |  |  |  classes.nib
|  |  |  |  |  |  |  |  info.nib
|  |  |  |  |  |  |  |  objects.nib
|  |  |  |  |  |  MyAppDelegate.py
|  |  |  |  |  |  MyDocument.py

I can safely remove the pbdevelopment.plist and the app still launches
ok. So I guess all your plist magic deals with generating the 
Info.plist,
right? Ok, let's keep going.

Remove the build folder after copying the following file to some safe
place: build/CocoaPyDocApp.app/Contents/Info.plist . Write a simpple
buildapp.py like this in the project root folder:

#! /usr/bin/env python

from bundlebuilder import buildapp

buildapp(
     name = "CocoaPyDocApp",
     mainprogram = "__main__.py",
     resources = ["English.lproj",
                  "MyAppDelegate.py",
                  "MyDocument.py"],
     nibname = "MainMenu",
)

Now rebuild the application using "buildapp.py build". This is what we
get (only app wrapper listed):

[localhost:~/Developer/Cocoa/CocoaPyDocApp] dinu% tree2.py -f .
./
|  build/
|  |  CocoaPyDocApp.app/
|  |  |  Contents/
|  |  |  |  Info.plist
|  |  |  |  MacOS/
|  |  |  |  |  CocoaPyDocApp
|  |  |  |  |  python
|  |  |  |  PkgInfo
|  |  |  |  Resources/
|  |  |  |  |  __main__.py
|  |  |  |  |  English.lproj/
|  |  |  |  |  |  Credits.rtf
|  |  |  |  |  |  InfoPlist.strings
|  |  |  |  |  |  MainMenu.nib/
|  |  |  |  |  |  |  classes.nib
|  |  |  |  |  |  |  info.nib
|  |  |  |  |  |  |  keyedobjects.nib
|  |  |  |  |  |  MyDocument.nib/
|  |  |  |  |  |  |  classes.nib
|  |  |  |  |  |  |  info.nib
|  |  |  |  |  |  |  objects.nib
|  |  |  |  |  MyAppDelegate.py
|  |  |  |  |  MyDocument.py

As expected this application doesn't work as it should. It starts up,
but doesn't show any window! But... drumrolls...! If you replace its
top Info.plist with the one previously saved the app runs just fine!!

The big question then is how to generate this Info.plist below using
bundlebuilder tool?? (At least it seems like I could simply keep the
__main__.py file.) Also, the same copy-trick works when using the
longer version: "buildapp.py --standalone --strip build".

Your-turn-again,-Sherlock'ly,

Dinu



<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CFBundleDevelopmentRegion</key>
	<string>English</string>
	<key>CFBundleDocumentTypes</key>
	<array>
		<dict>
			<key>CFBundleTypeExtensions</key>
			<array>
				<string>????</string>
			</array>
			<key>CFBundleTypeName</key>
			<string>DocumentType</string>
			<key>CFBundleTypeOSTypes</key>
			<array>
				<string>????</string>
			</array>
			<key>CFBundleTypeRole</key>
			<string>Editor</string>
			<key>NSDocumentClass</key>
			<string>MyDocument</string>
		</dict>
	</array>
	<key>CFBundleExecutable</key>
	<string>CocoaPyDocApp</string>
	<key>CFBundleInfoDictionaryVersion</key>
	<string>6.0</string>
	<key>CFBundlePackageType</key>
	<string>APPL</string>
	<key>CFBundleSignature</key>
	<string>????</string>
	<key>CFBundleVersion</key>
	<string>0.1</string>
	<key>NSMainNibFile</key>
	<string>MainMenu</string>
	<key>NSPrincipalClass</key>
	<string>NSApplication</string>
</dict>
</plist>

Re: [Pyobjc-dev] Using bundlebuilder on PB projects

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

Dinu Gherman wrote:

> > But... when creating two vanilla PB projects from the PyCocoaApp
> > and PyCocoaDocApp templates and adjusting the buildapp.py script
> > as below (run with python buildapp.py --standalone --strip build)
> > I get a working app only for the single document version. The multi-
> > document version launches, but never shows any window. Any idea?
> > What's the role of the myseterious Main.py files in some of the
> > sample projects?
> 
> I still don't think I understand how to convert an existing PB
> project into one to be created by bundlebuilder. The existing
> PyObjC samples rarely use multiple NIB files and I'm missing
> some short description of what the "canonical" way of writing
> a call to bundlebuilder really is...
> 
> Thanks for any insight,

Multi-doc app: make sure you either create an Info.plist file or
manually create a plist object in your buildapp.py script.

Example of the latter:

from bundlebuilder import buildapp
from plistlib import Plist, Dict, True


plist = Plist(
    CFBundleDocumentTypes = [
        Dict(
            CFBundleTypeExtensions = ["*"],
            CFBundleTypeName = "Universal Font Object",
            LSTypeIsPackage = True,
            CFBundleTypeRole = "Viewer",
            NSDocumentClass = "GlyphSetDocument",
        ),
        Dict(
            CFBundleTypeExtensions = ["ttf", "otf"],
            CFBundleTypeName = "OpenType Font",
            CFBundleTypeRole = "Viewer",
            NSDocumentClass = "GlyphSetDocument",
        ),
        Dict(
            CFBundleTypeExtensions = ["pfb", "pfa"],
            CFBundleTypeName = "Type1 Font",
            CFBundleTypeRole = "Viewer",
            NSDocumentClass = "GlyphSetDocument",
        ),
        Dict(
            CFBundleTypeExtensions = ["*"],
            CFBundleTypeOSTypes = ["LWFN"],
            CFBundleTypeName = "Type1 Font",
            CFBundleTypeRole = "Viewer",
            NSDocumentClass = "GlyphSetDocument",
        ),
    ]
)

buildapp(
    mainprogram = "GlyphViewer.py",
    resources = ["MainMenu.nib", "GlyphSetWindow.nib"],
    nibname = "MainMenu",
    plist = plist,
)

Alternatively you can add --plist=myinfo.plist to the command line, or
replace the above with

plist = Plist.fromFile("myinfo.plist")

Just

Re: [Pyobjc-dev] Detecting Python interpreters on startup

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

Dinu Gherman wrote:

> #! /usr/bin/env python
> 
> import os
> from bundlebuilder import buildapp
> 
> src = [ fn for fn in os.listdir('.')
>          if fn.endswith('.py') and fn not in ('buildapp.py',) ]
> 
> buildapp(
>   name = "TestTest2",
>   mainprogram = "__main__.py",
>   resources = ["English.lproj"] + src,
>   nibname = "MainMenu",
> )

Btw, you don't *need* to include all sources from "." as resources,
_as_long_as_ you either use --standalone or --link.

With --link, you basically create an applet that contains symlinks to
everything you  specify, so it's very much tied to your setup. But: also
the main .py program is symlinked, and with the way Python handles the
main script, it turns out the the directory of the _original_ main
script (not the dir that contains the symlink!) gets on sys.path. So
things "just work". (But the truly best thing about --link is that you
don't have to rebuild your app(let) when you edit sources or nibs!)

And with --standalone, modulefinder.py will pick up the needed modules
anyway, so you *also* don't need to add your other modules to the
resources list.

In retrospect, I find the option-less "python buildapp.py build"
invocation pretty useless. I personally never use it.

Time to write documentation! :)

Just

Re: [Pyobjc-dev] Threading?

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

On 6 sep 2003, at 2:25, Bob Ippolito wrote:

>
> On Friday, Sep 5, 2003, at 20:15 America/New_York, Jiva DeVoe wrote:
>
>> How hard is the non-threadsafeness problem with PyObjC?  Just 
>> curious...
>>
>> And any suggestions for a workaround if I need to create a thread.
>>
>> (ie: the fact that one basically can't create threads in a pyobjc app)
>
> That's not true.  It's only a little less thread-safe than a typical 
> ObjC application.

<nod> You can use threads as long as you create them with the Python 
threading primitives. Some of the examples use this to run blocking 
code in a seperate worker thread.

I'm working on a patch that will make it possible to create threads 
using the NSThread interface, but that won't get in before 1.0.

Ronald

Re: [Pyobjc-dev] Threading?

[Bob I. <bo...@re...>]

On Friday, Sep 5, 2003, at 20:15 America/New_York, Jiva DeVoe wrote:

> How hard is the non-threadsafeness problem with PyObjC?  Just 
> curious...
>
> And any suggestions for a workaround if I need to create a thread.
>
> (ie: the fact that one basically can't create threads in a pyobjc app)

That's not true.  It's only a little less thread-safe than a typical 
ObjC application.  Some of the PyObjC examples use threads, look at 
those.  There's a lot of things in Cocoa that can only happen on the 
main thread (the application runloop thread), regardless of what 
language you're programming in.

Threading is generally pretty cumbersome in general, in many cases you 
don't even need it.  For example, I've written a CoreFoundation reactor 
for Twisted that allows one to do all the networking you could possibly 
want without using additional threads in a Cocoa application.

-bob

[Pyobjc-dev] Threading?

[Jiva D. <ji...@de...>]

How hard is the non-threadsafeness problem with PyObjC?  Just curious...

And any suggestions for a workaround if I need to create a thread.

(ie: the fact that one basically can't create threads in a pyobjc app)
--
jiva at devoesquared.com
http://www.devoesquared.com

[Pyobjc-dev] Using bundlebuilder on PB projects

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

I wrote:

> But... when creating two vanilla PB projects from the PyCocoaApp
> and PyCocoaDocApp templates and adjusting the buildapp.py script
> as below (run with python buildapp.py --standalone --strip build)
> I get a working app only for the single document version. The multi-
> document version launches, but never shows any window. Any idea?
> What's the role of the myseterious Main.py files in some of the
> sample projects?

I still don't think I understand how to convert an existing PB
project into one to be created by bundlebuilder. The existing
PyObjC samples rarely use multiple NIB files and I'm missing
some short description of what the "canonical" way of writing
a call to bundlebuilder really is...

Thanks for any insight,

Dinu

--
Dinu C. Gherman
......................................................................
"There are causes worth dying for, but none worth killing for."
(Albert Camus)