pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Running tests in one python session

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

>> Posing also introduces another, possibly more serious, problem: If 
>> someone poses as NSObject after you import Foundation, 
>> Foundation.NSObject still references the original NSObject (which is 
>> now %NSObject). This can be fixed for 'import Foundation', but not 
>> for 'from Foundation import *'. Sadly enough the latter is how most 
>> peoply import the module.

This problem is universal to ObjC and generally fatal in the context of 
the Java/ObjC bridge.

In general, if the developer is going to do any posing, that posing 
should *always* be done before a class is used at all (beyond 
triggering +initialize and +load, obviously).   Any other use of the 
class that results in instantiation or permanent references to the 
class will cause problems.

That PyObjC can fix the problem in any case puts PyObjC beyond the 
capabilities of the default runtime!

Bottom line:  posing is always problematic.  If the developer is going 
to use posing, the limitation that it must be done before a reference 
to the class is created is nothing new.

Attempting to automatically fix the references to the old class after 
posing is a feature request, not a bug fix. ;-)

b.bum

Re: [Pyobjc-dev] Running tests in one python session

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

On Thursday, May 29, 2003, at 21:02 Europe/Amsterdam, Ronald Oussoren 
wrote:

>
> On Thursday, May 29, 2003, at 20:39 Europe/Amsterdam, bb...@ma... 
> wrote:
>
>> On Thursday, May 29, 2003, at 10:49 US/Pacific, Ronald Oussoren wrote:
>>> - Add script to run all tests in 1 python session, this is a script 
>>> by
>>>   Dinu Gherman with minor updates by me.
>>
>> Excellent change -- much speedier, I presume.
>
> It is much speedier, and it caught more bugs than the previous script. 
> This is probably because the bridge gets to do more work in a single 
> session.
>
>>
>> Is there still an option to run the tests in different sessions?
> Sure, the previous script is still present.
>
>>
>> We had some problems early on that were only caught because the 
>> different tests loaded things in different order or because one test 
>> could influence another test (classAddMethods(), for example).
>
> I've updated a number of tests (test_posing and test_methodedits): 
> They used to modify NSObject, which is not very usefull when those 
> classes will be used later on. Both currently use another Foundation 
> class and both should be changed to use a custom Objective-C class.
>
> BTW. test_posing should work with NSObject, but that causes a crash. 
> I'm working on this, until that is resolved I'll keep using a class 
> that isn't used by the other unittests.
>
> Posing also introduces another, possibly more serious, problem: If 
> someone poses as NSObject after you import Foundation, 
> Foundation.NSObject still references the original NSObject (which is 
> now %NSObject). This can be fixed for 'import Foundation', but not for 
> 'from Foundation import *'. Sadly enough the latter is how most peoply 
> import the module.

I'm going to disable poseAs for now, getting it to work will be a lot 
of work: class_poseAs (the implementation of +poseAs:) copies the 
imposter class, and that won't work with our code (class-builder.m 
embeds the class into a larger structure and does pointer casts at 
several locations).

The meta class isn't copied, and with some reordering in 
class-builder.m we could use that fact, but a comment in the 
implementation of class_poseAs claims that not copying the meta class 
is a hack. Relying on not copying the meta-class is probably unsafe.

Ronald

Re: [Pyobjc-dev] Running tests in one python session

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

On Thursday, May 29, 2003, at 22:53 Europe/Amsterdam, Jack Jansen wrote:

>
> On donderdag, mei 29, 2003, at 21:02 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>> Posing also introduces another, possibly more serious, problem: If 
>> someone poses as NSObject after you import Foundation, 
>> Foundation.NSObject still references the original NSObject (which is 
>> now %NSObject). This can be fixed for 'import Foundation', but not 
>> for 'from Foundation import *'. Sadly enough the latter is how most 
>> peoply import the module.
>
> I thought about this for a while, and I can't see why this is a 
> python-specific problem. If posing modifies the ObjC NSObject in-place 
> then the Python wrapper would see the changes. If posing modifies it 
> out-of-place then ObjC problems should also have the problem that any 
> references to NSObject created before the posing will still refer to 
> the old one.
>
> Or am I missing something (I assume I am, I just don't see it:-)?

It's not the created objects, but the class itself. Objective-C:

	[SomeClass poseAs:[NSObject class]];
	o = [[NSObject alloc] init];

o is now actually an instance of SomeClass. If you do 
cls=objc.lookUpClass('NSObject') in Python (which is basically what the 
Foundation module does) you get a pointer to a class structure. This 
structure is not changed when someone calls poseAs, and therefore 'cls' 
refers to the previous version of NSObject, that is now called 
'%NSObject'. Which means you never really get to see the effects of the 
call to poseAs.

Ronald

Re: [Pyobjc-dev] Running tests in one python session

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

On donderdag, mei 29, 2003, at 21:02 Europe/Amsterdam, Ronald Oussoren 
wrote:
> Posing also introduces another, possibly more serious, problem: If 
> someone poses as NSObject after you import Foundation, 
> Foundation.NSObject still references the original NSObject (which is 
> now %NSObject). This can be fixed for 'import Foundation', but not for 
> 'from Foundation import *'. Sadly enough the latter is how most peoply 
> import the module.

I thought about this for a while, and I can't see why this is a 
python-specific problem. If posing modifies the ObjC NSObject in-place 
then the Python wrapper would see the changes. If posing modifies it 
out-of-place then ObjC problems should also have the problem that any 
references to NSObject created before the posing will still refer to 
the old one.

Or am I missing something (I assume I am, I just don't see it:-)?
--
- 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] Running tests in one python session

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

On Thursday, May 29, 2003, at 20:39 Europe/Amsterdam, bb...@ma... 
wrote:

> On Thursday, May 29, 2003, at 10:49 US/Pacific, Ronald Oussoren wrote:
>> - Add script to run all tests in 1 python session, this is a script by
>>   Dinu Gherman with minor updates by me.
>
> Excellent change -- much speedier, I presume.

It is much speedier, and it caught more bugs than the previous script. 
This is probably because the bridge gets to do more work in a single 
session.

>
> Is there still an option to run the tests in different sessions?
Sure, the previous script is still present.

>
> We had some problems early on that were only caught because the 
> different tests loaded things in different order or because one test 
> could influence another test (classAddMethods(), for example).

I've updated a number of tests (test_posing and test_methodedits): They 
used to modify NSObject, which is not very usefull when those classes 
will be used later on. Both currently use another Foundation class and 
both should be changed to use a custom Objective-C class.

BTW. test_posing should work with NSObject, but that causes a crash. 
I'm working on this, until that is resolved I'll keep using a class 
that isn't used by the other unittests.

Posing also introduces another, possibly more serious, problem: If 
someone poses as NSObject after you import Foundation, 
Foundation.NSObject still references the original NSObject (which is 
now %NSObject). This can be fixed for 'import Foundation', but not for 
'from Foundation import *'. Sadly enough the latter is how most peoply 
import the module.

Ronald

[Pyobjc-dev] Running tests in one python session

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

On Thursday, May 29, 2003, at 10:49 US/Pacific, Ronald Oussoren wrote:
> - Add script to run all tests in 1 python session, this is a script by
>   Dinu Gherman with minor updates by me.

Excellent change -- much speedier, I presume.

Is there still an option to run the tests in different sessions?

We had some problems early on that were only caught because the 
different tests loaded things in different order or because one test 
could influence another test (classAddMethods(), for example).

b.bum

Re: [Pyobjc-dev] PyObjC sources bundled with pbxbuild install

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

bb...@ma...:

> And, yes, you'll have to do this for each project.   Inconvenient, but 
> how many projects are you planning on building?  Hundreds?  It takes 
> less than a minute per project given that there are only three things 
> to change;  INSTALL_PATH, the addition of the python cleanup script 
> and a shell script build phase that cleans up that script.

Well, I'm just trying to automate and test as much and as thoroughly
as possible, reducing the number of manual steps as much down to zero
as is feasible...

> If you want something "pure pythonic", use the buildapp.py script and 
> control the entire build from within Python.

I'll look into that, too... thanks!

Dinu

--
Dinu C. Gherman
......................................................................
"Any sufficiently advanced technology is indistinguishable
from magic." (Arthur C. Clarke)

Re: [Pyobjc-dev] PyObjC sources bundled with pbxbuild install

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

On Wednesday, May 28, 2003, at 08:24 US/Pacific, Dinu Gherman wrote:
> bb...@ma...:
>> That is certainly one way to do it.... an equivalent that doesn't 
>> involve hacking the pbxproj (which will potentially break with a 
>> complex set of targets or in other situations):
> BTW, isn't there a specification for these formats, somewhere?
> There is just too much magic IDs, I assume for linking and what
> not...

There is no specification.  It is a closed format and it changes with 
each release of the dev tools.

>> Set INSTALL_PATH environment variable appropriately before calling 
>> out to 'pbxbuild install'.
>> Add a 'shell script' build phase at the end of the build phases that 
>> checks to see if it is an install phase and, if so, does your clean 
>> up on the install tree.
>
> But then, I'll have to do this for each project individually,
> isn't it? Not sure if this is the most "pythonic" way to do it...

But you aren't building a python project, you are building Cocoa 
applications in Project Builder that happen to use Python as the 
language of implementation.   What I described is a way to solve this 
problem using the Apple provided tools in a supported fashion.

And, yes, you'll have to do this for each project.   Inconvenient, but 
how many projects are you planning on building?  Hundreds?  It takes 
less than a minute per project given that there are only three things 
to change;  INSTALL_PATH, the addition of the python cleanup script and 
a shell script build phase that cleans up that script.

If we want something that is both "pythonic" while still playing by 
Apple's rules, then we should write a generic python script that can be 
dropped in as the final build phase in the PBX templates.   It could do 
the various random bits of cleanup, etc, as needed.   The INSTALL_PATH 
configuration is more of a developer preference than anything else -- I 
set my INSTALL_PATH to something fairly specific to facilitate 
packaging (and I should refactor my solution out so other's can take 
advantage of it-- it is fairly useful).

If you want something "pure pythonic", use the buildapp.py script and 
control the entire build from within Python.

b.bum

Re: [Pyobjc-dev] PyObjC sources bundled with pbxbuild install

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

bb...@ma...:

> That is certainly one way to do it.... an equivalent that doesn't 
> involve hacking the pbxproj (which will potentially break with a 
> complex set of targets or in other situations):

BTW, isn't there a specification for these formats, somewhere?
There is just too much magic IDs, I assume for linking and what
not...

> Set INSTALL_PATH environment variable appropriately before calling out 
> to 'pbxbuild install'.
> Add a 'shell script' build phase at the end of the build phases that 
> checks to see if it is an install phase and, if so, does your clean up 
> on the install tree.

But then, I'll have to do this for each project individually,
isn't it? Not sure if this is the most "pythonic" way to do it...

Dinu

--
Dinu C. Gherman
......................................................................
"There is more to life than increasing its speed." (Mahatma Ghandi)


--
Dinu C. Gherman
......................................................................
"Bigamy is having one wife too many. Monogamy is the same."
(Oscar Wilde)


--
Dinu C. Gherman
......................................................................
"Whenever you find yourself on the side of the majority, it's time
to pause and reflect." (Mark Twain)

Re: [Pyobjc-dev] PyObjC sources bundled with pbxbuild install

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

On Wednesday, May 28, 2003, at 03:01 US/Pacific, Dinu Gherman wrote:
> <deploy.py>

That is certainly one way to do it.... an equivalent that doesn't 
involve hacking the pbxproj (which will potentially break with a 
complex set of targets or in other situations):

Set INSTALL_PATH environment variable appropriately before calling out 
to 'pbxbuild install'.

Add a 'shell script' build phase at the end of the build phases that 
checks to see if it is an install phase and, if so, does your clean up 
on the install tree.

I would highly recommend that folks not hack the pbxproj file 
directly... even if temporarily.

b.bum

Re: [Pyobjc-dev] More tests needed?

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

On Wednesday, May 28, 2003, at 15:23 Europe/Amsterdam, Dinu Gherman 
wrote:

> Hi,
>
> if you see my last bug report it looks like we'd need more tests.
> I can probably provide some more I've written back, when I still had
> thought that Cocoa would be usable via Jython, which was not exactly
> such a clever idea... I'd have to dig them out somewhere, but I'd
> prefer to have checkin rights to add them to CVS instead of posting
> them each via the SF trackers... Please let me know what you think.

What is your SF account? You send your tests directly to me while I try 
to find the right way to give you checkin permissions.

We definitly need more tests for the convenience methods (like 
'items()' on NSDictionary), as well as for all methods that require 
special behaviour in the bridge.

Ronald

[Pyobjc-dev] More tests needed?

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

Hi,

if you see my last bug report it looks like we'd need more tests.
I can probably provide some more I've written back, when I still had
thought that Cocoa would be usable via Jython, which was not exactly
such a clever idea... I'd have to dig them out somewhere, but I'd
prefer to have checkin rights to add them to CVS instead of posting
them each via the SF trackers... Please let me know what you think.

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"Journalism largely consists of saying 'Lord Jones is Dead' to people
who never knew that Lord Jones was alive." (G. K. Chesterton)

[Pyobjc-dev] [ pyobjc-Bugs-744879 ] NSDictionary and NSMutableDictionary have no items() method

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

Bugs item #744879, was opened at 2003-05-28 13:04
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=744879&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: NSDictionary and NSMutableDictionary have no items() method

Initial Comment:
Python 2.2.2 (#1, Mar 13 2003, 12:11:28) 
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Welcome to rlcompleter2 0.95 for nice experiences hit <tab> multiple 
times

>>> import objc
>>> objc.__version__
'0.9'

>>> d = {}
>>> d.items()
[]

>>> from Foundation import NSDictionary
>>> d = NSDictionary.alloc().init()
>>> d.items()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: No attribute items

>>> from Foundation import NSMutableDictionary
>>> d = NSMutableDictionary.alloc().init()
>>> d.items()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: No attribute items

Observed on Mac OS X 10.2.6.


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

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

Re: [Pyobjc-dev] PyObjC sources bundled with pbxbuild install

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

bb...@ma...:

> In any case, everything is defined via PBX itself.  See the build
> phases for the main app target.

I sort of knew that, but was looking for something smarter... In
the absence of that (or given my incapability to find it), I wrote
a little script that hacks a given PB project, runs pbxbuild, prunes
superfluous stuff away from the included PyObjC and makes a tarball
of the resulting app. See the attached file for more comments.

It does what I wont it to do, but feel free to make suggestions for
improvements! ;-)

Regards,

Dinu

[Pyobjc-dev] ***Last Chance...15.6 MILLION EMAIL ADDRESSES

[Martha Ellen<Gen...@ex...>]

DQogSGVsbG8sDQoNClRoaXMgaXMgeW91ciBsYXN0IGNoYW5jZSB0byBnZXQgaW4gb24gdGhpcyBl
eHRyYW9yZGluYXJ5IG9mZmVyDQppZiB5b3UgaGF2ZSBub3QgZG9uZSBzbyB5ZXQuDQoNCldPVUxE
IFlPVSBMSUtFIFRPIEhBVkUgWU9VUiBNRVNTQUdFIFNFRU4gQlkNCk9WRVIgMTUuNiBNSUxMSU9O
IE9QVC1JTiwgVEFSR0VURUQgUEVPUExFIERBSUxZPw0KDQpQTFVTIFJFQ0VJVkUgJDIsMDAwIFdP
UlRIIE9GIEZSRUUgRU1BSUwgTUFSS0VUSU5HIFNPRlRXQVJFIQ0KDQpCZWxvdyBjb250YWlucyBh
bGwgdGhlIGluZm9ybWF0aW9uIHlvdSB3aWxsIGV2ZXIgbmVlZCB0byBtYXJrZXQNCnlvdXIgcHJv
ZHVjdCBvciBzZXJ2aWNlIG9uIHRoZSBJbnRlcm5ldC4NCg0KSWYgeW91IGhhdmUgYSBwcm9kdWN0
LCBzZXJ2aWNlLCBvciBtZXNzYWdlIHRoYXQgeW91IHdvdWxkIGxpa2UgdG8gZ2V0DQpvdXQgdG8g
VGhvdXNhbmRzLCBIdW5kcmVkcyBvZiBUaG91c2FuZHMsIG9yIGV2ZW4gTWlsbGlvbnMgb2YgcGVv
cGxlLA0KeW91IGhhdmUgc2V2ZXJhbCBvcHRpb25zLiBUcmFkaXRpb25hbCBtZXRob2RzIGluY2x1
ZGUgcHJpbnQgYWR2ZXJ0aXNpbmcsDQpkaXJlY3QgbWFpbCwgcmFkaW8sIGFuZCB0ZWxldmlzaW9u
IGFkdmVydGlzaW5nLiBUaGV5IGFyZSBhbGwgZWZmZWN0aXZlLCBidXQNCnRoZXkgYWxsIGhhdmUg
dHdvIGNhdGNoZXM6IFRoZXkncmUgRVhQRU5TSVZFIGFuZCBUSU1FDQpDT05TVU1JTkcuIE5vdCBv
bmx5IHRoYXQsIHlvdSBvbmx5IGdldCBPTkUgU0hPVCBhdCBtYWtpbmcNCnlvdXIgbWVzc2FnZSBo
ZWFyZCBieSB0aGUgcmlnaHQgcGVvcGxlLiBBbHNvLCBJbnRlcm5ldCBTZWFyY2ggRW5naW5lDQpT
dWJtaXNzaW9ucywgQ2xhc3NpZmllZCBBZHMsIE5ld3Nncm91cCBQb3N0aW5ncyBzaW1wbHkgRE8g
Tk9UDQpXT1JLIGVmZmVjdGl2ZWx5Lg0KDQpOb3cgdGhpcyBoYXMgYWxsIGNoYW5nZWQhDQoNClRo
YW5rcyB0byB0aGUgdG9wIHByb2dyYW1tZXJzIGluIHRoZSB3b3JsZCBhbmQgdGhlaXIgTkVXIEVN
QUlMDQpURUNITk9MT0dZLCBZb3UgY2FuIHNlbmQgbWlsbGlvbnMgb2YgZW1haWwgbWVzc2FnZXMg
ZGFpbHkgZm9yDQpGUkVFLi4uV2l0aG91dCBnZXR0aW5nIHRlcm1pbmF0ZWQgZnJvbSB5b3VyIGN1
cnJlbnQgSW50ZXJuZXQgY29ubmVjdGlvbiENCg0KSXQncyB2ZXJ5IHNpbXBsZSB0byBkbyBhbmQg
eW91IGNhbiBiZSBpbmNyZWFzaW5nIHlvdXIgc2FsZXMgd2l0aGluIG1pbnV0ZXMNCm9mIGluc3Rh
bGxpbmcgdGhpcyBleHRyYW9yZGluYXJ5IG5ldyBzb2Z0d2FyZSENCg0KQmVzaWRlcy4uLkl0J3Mg
dGhlIG9ubHkgcmVhbCB3YXkgdG8gYWR2ZXJ0aXNlIG9uIHRoZSBJbnRlcm5ldCB0aGF0IHdvcmtz
Li4uUGVyaW9kIQ0KDQpCRUxPVyBJUyBKVVNUIEEgU0FNUExFIE9GIFdIQVQgV0UgSEFWRSBUTyBP
RkZFUiBZT1UuLi4NCg0KPj4+V0UgV0lMTCBTVVBQTFkgWU9VIFdJVEggT1ZFUiAxNS42IE1JTExJ
T04gT1BULUlOIEVNQUlMDQpBRERSRVNTRVMgVE8gR0VUIFlPVSBTVEFSVEVEIFJJR0hUIEFXQVkh
DQoNCj4+PkZSRUUgRU1BSUwgQUREUkVTUyBET1dOTE9BRFMgRk9SIExJRkUhDQoNCj4+PllPVSBX
SUxMIFJFQ0VJVkUgT1ZFUiAkMiwwMDAgV09SVEggT0YgDQpFTUFJTCBNQVJLRVRJTkcgU09GVFdB
UkUgRlJFRSENCg0KSW5jbHVkaW5nLi4uLi4uDQoNCkJST0FEQ0FTVCBFTUFJTCBTRU5ESU5HIFNP
RlRXQVJFLi4uKHNlbmQgbWlsbGlvbnMgb2YgZW1haWwNCmFkdmVydGlzZW1lbnRzIGRhaWx5IHdp
dGggYSBmZXcgY2xpY2tzIG9mIHlvdXIgbW91c2UuIE5ldyBidWlsdCBpbiANCnN0ZWFsdGggdGVj
aG5vbG9neSkuIEJlIG9uZSBvZiB0aGUgZmlyc3QgcGVvcGxlIHRvIHVzZSBpdC4gV2UgdXNlZCB0
aGUgDQpzYW1lIHNvZnR3YXJlIHRvIHNlbmQgeW91IHRoaXMgZW1haWwgbWVzc2FnZS4NCg0KRU1B
SUwgRVhUUkFDVElPTiBTT0ZUV0FSRS4uLihSZXRyZWl2ZSBuZXcgdGFyZ2V0ZWQgZW1haWwNCmFk
ZHJlc3NlcyBkYWlseS4gSHVuZHJlZHMgb2YgdGhvdXNhbmRzIG9mIHRoZW0pDQoNCkxJU1QgTUFO
QUdFTUVOVCBTT0ZUV0FSRS4uLihLZWVwIHlvdXIgbGlzdHMgY2xlYW4sIG9wdC1pbg0KYW5kIG1h
bmFnZSBhbGwgeW91ciByZW1vdmUgcmVxdWVzdHMsIGxlYWRzLCBzYWxlcyBldGMuLi4pDQoNClBP
UC1VUCBBRFZFUlRJU0VSLi4uTm8gbmVlZCB0byBwYXkgc29tZW9uZSBlbHNlIGZvciANCnBvcC11
cCBhZHZlcnRpc2luZy4gU2F2ZSAkMSwwMDBzIHdlZWtseS4gSXQncyB5b3VycyB0b2RheSBmcmVl
ISANClBsdXMgeW91IGNhbiByZXNlbGwgdGhpcyBzb2Z0d2FyZSBhbmQga2VlcCAxMDAlIG9mIHRo
ZSBwcm9maXQgb3INCnNpbXBseSBnaXZlIGl0IGFzIGEgZnJlZSBnaWZ0IGFsb25nIHdpdGggeW91
ciBjdXJyZW50IHNlcnZpY2VzLg0KDQphbmQgbXVjaC4uLm11Y2ggbW9yZSENCg0KSHVycnkuLi5U
aGlzIGV4dHJhb3JkaW5hcnkgb2ZmZXIgZW5kcyBzb29uIQ0KDQpUbyBmaW5kIG91dCBtb3JlIGlu
Zm9ybWF0aW9uLCBEbyBub3QgcmVzcG9uZCBieSBlbWFpbC4gSW5zdGVhZCwgY2xpY2sNCm9uIHRo
ZSBsaW5rIGJlbG93IG9yIGNvcHkgYW5kIHBhc3RlIHRoZSBjb21wbGV0ZSB3ZWIgYWRkcmVzcyBp
bnRvIA0KeW91ciBJbnRlcm5ldCBicm93c2VyLg0KDQo8YnI+PEEgSFJFRj0iaHR0cDovL3d3dy5m
b3J0aGViZXN0dC5jb20vNDA5MzI0L2Jyb2FkY2FzdDYuaHRtIj5DbGljayBIZXJlIEZvciBNb3Jl
IEluZm9ybWF0aW9uPC9BPjxicj4NCg0KaHR0cDovL3d3dy5mb3J0aGViZXN0dC5jb20vNDA5MzI0
L2Jyb2FkY2FzdDYuaHRtDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpXYW50IHRvIGJlIFJFTU9WRUQgZnJvbSBvdXIgZW1h
aWwgbGlzdD8NCllvdSB3ZXJlIHNlbnQgdGhpcyBlbWFpbCBiZWNhdXNlIHlvdSB1c2VkIG91ciBP
cHQtaW4gc2VydmljZS4NCldlIGhvcGUgeW91IGVuam95IHJlYWRpbmcgb3VyIG1lc3NhZ2VzLiBI
b3dldmVyLCBpZiB5b3UnZCByYXRoZXINCm5vdCByZWNlaXZlIGZ1dHVyZSBlLW1haWxzIGZyb20g
dXMsIENsaWNrIG9uIHRoZSBsaW5rIGJlbG93Lg0KaHR0cDovL3d3dy5mb3J0aGViZXN0dC5jb20v
NDA5MzI0L3JlbW92ZW1lLmh0bQ0KVGhhbmsgeW91IGZvciB5b3VyIGNvb3BlcmF0aW9uLg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18=

Re: [Pyobjc-dev] PyObjC sources bundled with pbxbuild install

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

On Tuesday, May 27, 2003, at 01:42 US/Pacific, Dinu Gherman wrote:
> bb...@ma...:
>> For PBX builds, you could add a shell script build phase that
>> invokes a script-- python, likely-- to walk the built tree and
>> remove any cruft (including CVS directories!).
>
> Of course, but it would be cleaner and more consistent to include
> only what's needed from the start. So far, I have no idea where
> and when it is defined what ends up in the PyObjC folder. Is it
> in the PB templates?

For normal builds, the pyobjc resources are not copied at all as an 
optimization.   As well, this allows the build templates to work for 
all but installs regardless of where PyObjC is installed (though there 
is a default that has to be set to control how the app finds the python 
binary).

In any case, everything is defined via PBX itself.  See the build 
phases for the main app target.

A Project Builder template is merely a PBX project shoved into the 
Templates directory.   When a new project is created from a Template, 
certain strings are automatically replaced.    If you want to adjust 
the templates, you can edit an existing template directly in PBX, just 
make sure you remove the pbxuser file from the pbxproj -- likely 
gherman.pbxuser, in your case.

> Another related thing is that doing a "pbxbuild build" is just not
> enough to create the full thing and "pbxbuild install" copies the
> final .app into a temporary directory from where I have to move it
> out again. I suppose this is a setting in PB, maybe in the targets?
> Ok, in fact, if you deselect an install directory there it ends up
> in build/UninstalledProducts, which is more predictable, I guess.

All controlled via PBX....

Build just creates the app for the purposes of running in PBX.   
Install [tries to] creates an app that can be packaged for 
distribution.  The location is entirely determined by PBX settings;   
see the build settings target editor.

> Also, it seems that a project.pbxproj file contains an item like
> this:
>
> 		77AD459403ECA7A6004B557F = {
> 			includeInIndex = 1;
> 			isa = PBXFolderReference;
> 			name = PyObjC;
> 			path = "/usr/lib/python2.2/site-packages/PyObjC";
> 			refType = 0;
> 		};
>
> I'm not sure, if one can provide regular expressions in these items
> like with Unix find. Probably one could do something equivalent when
> building the template (at the risk of being out of being out of synch
> after the next CVS compile, but ok, distutils could update the tem-
> plates as well). What do you think?

REGEX, no... but you could provide environment variables, I believe, 
and that could entirely be done from within PBX (all of the FOO=BAR 
settings within the PBX target editor are just passed to pbxbuild as 
environment variables).   Some experimentation would be necessary.

The distutils build doesn't touch the PBX templates.  Maybe 'pbxbuild 
install' should do so and, as Dinu indicates, should update the 
templates based on

> Ideally, there would be a hook for PB to do something during the in-
> stantiation of such a template (like with the Installer.app), but I'm
> not sure if there is such a functionality...

I don't think that exists.

b.bum

[Pyobjc-dev] [ pyobjc-Bugs-744285 ] NSBundle.principalClass() in sample code hangs

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

Bugs item #744285, was opened at 2003-05-27 14:17
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=744285&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: NSBundle.principalClass() in sample code hangs

Initial Comment:
The announcement of PyObjC 0.8 on the Cocoa-Dev mailinglist 
contained the following code snippet, the last line of which is hanging 
on my 0.9/10.2.6 installation. I'm not entirely sure, but I assume this 
should not be the case(?).

from objc import *
from Foundation import *
b = NSBundle.bundleWithPath_("/System/Library/PrivateFrameworks/
PBXCore.framework")
b.principalClass()



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

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

Re: [Pyobjc-dev] Another sheet bug

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

Ronald Oussoren wrote:

> I think I didn't see this one before, otherwise this is another
> duplicate. Did anyone else receive old pyobjc-dev messages this
> morning (CEST)?
> 
> The bug is already fixed in CVS, Just managed to get it into the SF
> bugtracker after all ;-)

This was a weird one: 1) sf wasn't down, but I was looking at a chached
page that told me so, 2) somehow sf took a looong time to deliver this
message, so the bug report came in first...

Just

Re: [Pyobjc-dev] PyObjC sources bundled with pbxbuild install

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

bb...@ma...:

> For PBX builds, you could add a shell script build phase that
> invokes a script-- python, likely-- to walk the built tree and
> remove any cruft (including CVS directories!).

Of course, but it would be cleaner and more consistent to include
only what's needed from the start. So far, I have no idea where
and when it is defined what ends up in the PyObjC folder. Is it
in the PB templates?

Another related thing is that doing a "pbxbuild build" is just not
enough to create the full thing and "pbxbuild install" copies the
final .app into a temporary directory from where I have to move it
out again. I suppose this is a setting in PB, maybe in the targets?
Ok, in fact, if you deselect an install directory there it ends up
in build/UninstalledProducts, which is more predictable, I guess.

Also, it seems that a project.pbxproj file contains an item like
this:

		77AD459403ECA7A6004B557F = {
			includeInIndex = 1;
			isa = PBXFolderReference;
			name = PyObjC;
			path = "/usr/lib/python2.2/site-packages/PyObjC";
			refType = 0;
		};

I'm not sure, if one can provide regular expressions in these items
like with Unix find. Probably one could do something equivalent when
building the template (at the risk of being out of being out of synch
after the next CVS compile, but ok, distutils could update the tem-
plates as well). What do you think?

Ideally, there would be a hook for PB to do something during the in-
stantiation of such a template (like with the Installer.app), but I'm
not sure if there is such a functionality...

Dinu

--
Dinu C. Gherman
......................................................................
"One of the common denominators I found is that expectations rise
above that which is expected."
(George W. Bush, 27 Sep. 2000)

Re: [Pyobjc-dev] PyObjC sources bundled with pbxbuild install

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

On Monday, May 26, 2003, at 14:23 US/Pacific, Dinu Gherman wrote:
> Ronald Oussoren:
>> Including the python sources is not necessary. I don't have time
>> to work on this, a patch would be appreciated.
>
> Ok, but give me a quick hint where to start digging, please!

For PBX builds, you could add a shell script build phase that invokes a 
script-- python, likely-- to walk the built tree and remove any cruft 
(including CVS directories!).

b.bum

Re: [Pyobjc-dev] Another sheet bug

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

On Saturday, May 24, 2003, at 21:45 Europe/Amsterdam, Just van Rossum 
wrote:

> SF is down again, so I'll post here.
>
> If you close the window the attached app (build with "python 
> buildapp.py
> --link build") a sheet with one button pops up. If you click the 
> button,
> and action is called which is tries to end the sheet by doing

I think I didn't see this one before, otherwise this is another 
duplicate. Did anyone else receive old pyobjc-dev messages this morning 
(CEST)?

The bug is already fixed in CVS, Just managed to get it into the SF 
bugtracker after all ;-)

Ronald

Re: [Pyobjc-dev] PyObjC sources bundled with pbxbuild install

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

On Monday, May 26, 2003, at 23:23 Europe/Amsterdam, Dinu Gherman wrote:

> Ronald Oussoren:
>
>> Including the python sources is not necessary. I don't have time
>> to work on this, a patch would be appreciated.
>
> Ok, but give me a quick hint where to start digging, please!

You got me there, I haven't got the slightest idea on where you should 
make changes :-( My PB experience is limited to using the existing 
templates.

Ronald

Re: [Pyobjc-dev] PyObjC sources bundled with pbxbuild install

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

Ronald Oussoren:

> Including the python sources is not necessary. I don't have time
> to work on this, a patch would be appreciated.

Ok, but give me a quick hint where to start digging, please!

Dinu

--
Dinu C. Gherman
......................................................................
"One of the great things about books is sometimes there are some
fantastic pictures."
(George W. Bush, 3 Jan. 2000)

Re: [Pyobjc-dev] PyObjC sources bundled with pbxbuild install

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

On Monday, May 26, 2003, at 14:59 Europe/Amsterdam, Dinu Gherman wrote:

>
> So the question is: do we really need to include the .py and .pyo
> files? If we don't, we'd save about 373 KB in the resulting app,
> which is about 14 % of an empty doc-based Python app, installed
> from the PB template. I deleted the .py and .pyo files and it
> still works.

Including the python sources is not necessary. I don't have time to 
work on this, a patch would be appreciated.

Ronald

Re: [Pyobjc-dev] PyObjC sources bundled with pbxbuild install

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

Dinu Gherman wrote:

> Another question is if the __main__.py in Contents/Resources
> really needs to be a source file or if it could also be a byte-
> compiled one? This only for consistency reasons...

Could be byte code.

Just