pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Calling methods on nil

[Marcel W. <ma...@me...>]

On Sunday, May 11, 2003, at 11:34  Uhr, Just van Rossum wrote:

> Marcel Weiher wrote:
>
>>> The mechanics differ, but it's the same thing (OO with dynamic
>>> method dispatching).
>>
>> Exactly.  There is dynamic dispatch.  So when you "send a message",
>> you get dynamic dispatch, and THEN the method is called.  If you just
>> say "the method is called", you are simply *verbally* omitting the
>> dynamic dispatch, though of course it is still happening.
>
> That's just a matter of perspective <wink>: to me "the method foo of
> this object" means the method you'd get when dispatching.

Yes.  This means that you have *implied* a dispatching mechanism when 
you speak of "the method foo of this object".  (You didn't mention it 
explicitly, but it is there -> implied).

What about this is difficult?

> Since dynamic
> method dispatching is so deeply integrated in Python, I don't see how 
> it
> could mean anything else, so I disagree I'm omitting something crucial.

I am not saying that you are "omitting" anything.  I am saying you are 
not mentioning *explicitly*, but *implicitly*.  This behavior is 
implied by what you are saying.

> I'm not arguing against sending messages to nil in ObjC (although I
> don't like it, see below), but against supporting it by PyObjC in
> *Python*.

I have no problem with handling it one way or the other.  I had a 
problem with the 'reasoning' you presented, which was quite wrong.

> (Just yesterday I was working on some code where a (Cocoa) method
> unexpectedly returned nil (translated to None in Python). I was
> extremely happy to get a traceback instead of silent failure; since 
> None
> is an actual object, it dispatches methods just like most other 
> objects,
> ie. raise an exception if a method isn't found. A silent failure surely
> would've cost me much more time to figure out what I did wrong. 
> Ignoring
> messages to nil is convenient when you expect it, but it's a liability
> when you don't. I much rather explicitly test for nil than shoot myself
> in the foot.)

Well, I am just as happy that I don't have to obscure my code with 
clutter...

So there we are, two happy people ;-)

Marcel

-- 
Marcel Weiher				Metaobject Software Technologies
ma...@me...		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.

Re: [Pyobjc-dev] Calling methods on nil

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

bb...@ma...:

> Over the last-- jeez, nearly 15 years-- I have seen novice and 
> experienced developers-- myself included-- waste many many hours 
> trying to track down a problem that turned out to be an unexpected 
> nil.   Going with a 'message to nil raises' model may have required 
> the addition of quite a few extra if () statements here and there over 
> the years, but that route would have considerably decreased the 
> frustration factor for quite a large number of developers.

While one can surely argue about the value of "messages to nil being
eaten or not", I think all OO purists will agree that checking for
the type of an object (which here includes: comparing to nil/None)
is a very bad idea! You save lots of if-statements if you can dele-
gate your decission-making to the message dispatching mechanism.

Nil is just another singleton value to compare with (like null poin-
ters in C). So, sometimes it might just suffice for it to "eat your
messages", but to obtain clean code you more often want to have a
single but special value of some class which behaves differently in
*some* respect (leaves in trees, etc.). This is where the "Null"
pattern comes in, because you can also use it as a subclass of your
"real" representation (class). See my original link for further info.

If you use a Null object that way you won't have the kind of trouble
that you and Just are citing, because you have only "regular" objects
and (mostly) one special case object. I guess, the creators of ObjC
just were trying to help people using nil like this. But as I said,
it won't always be enough to "eat everything."

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"I want to put a ding in the universe." (Steve Jobs)

Re: [Pyobjc-dev] libffi on OSX 10.1

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

I now have a version of PyObjC that mostly works 10.1, it passes the 
entire testset with one exception: Conversion of to 'long long' values. 
These should not be to important in "normal" code.

I did run into a problem: evaluating 
NSObject.__pyobjc_PythonObject__.signature causes a core-dump. This is 
not something you would normally do, but the bridge sometimes does this 
for you. I work around this by checking for __pyobjc_PythonObject__ on 
the one location where this matters. The core-dump may be a real 
problem with the code.

I won't be working on 10.1 support for the forseeable future. I'll 
leave the remaining issues for someone that has real use for a 10.1 
port.

Ronald

Re: [Pyobjc-dev] Calling methods on nil

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

On Sunday, May 11, 2003, at 05:46 US/Eastern, Ronald Oussoren wrote:
> This is the most important reason for not having a 'nil' object that 
> behaves ignores all method calls. Implementing such an object is easy 
> enough, but it is too easy to mis actual errors this way. And IIRC 
> this feature doesn't even work perfectly in Objective-C (what if the 
> method returns anything other than an 'id', like a 
> float/double/struct).

Having done ObjC development since 1989 -- 4 or 5 years prior to diving 
into Python -- you might be surprised to learn that I very strongly 
prefer the behavior of Python's (and Java's) 'message to nil throws' 
behavior vs. ObjC's 'message to nil silently eaten'.

When everything is working correctly 'message to nil silently eaten' is 
a great convenience.  When something somewhere unexpectedly returns 
nil, it becomes an incredibly nasty pain to try and figure out exactly 
where the problem might be.   By the time it crops up, you may be many 
cycles through the run loop away from where the problem actually is.

Over the last-- jeez, nearly 15 years-- I have seen novice and 
experienced developers-- myself included-- waste many many hours trying 
to track down a problem that turned out to be an unexpected nil.   
Going with a 'message to nil raises' model may have required the 
addition of quite a few extra if () statements here and there over the 
years, but that route would have considerably decreased the frustration 
factor for quite a large number of developers.

Even though objc_msgSend() supports the other dispatch model, you can't 
mix and match within a single application for obvious reasons.

In the context of PyObjC, I consider 'message to nil throws' to be a 
feature (and not just because it is the Python way).

b.bum

Re: [Pyobjc-dev] Calling methods on nil

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

On Sunday, May 11, 2003, at 11:34 Europe/Amsterdam, Just van Rossum 
wrote:
> (Just yesterday I was working on some code where a (Cocoa) method
> unexpectedly returned nil (translated to None in Python). I was
> extremely happy to get a traceback instead of silent failure; since 
> None
> is an actual object, it dispatches methods just like most other 
> objects,
> ie. raise an exception if a method isn't found. A silent failure surely
> would've cost me much more time to figure out what I did wrong. 
> Ignoring
> messages to nil is convenient when you expect it, but it's a liability
> when you don't. I much rather explicitly test for nil than shoot myself
> in the foot.)

This is the most important reason for not having a 'nil' object that 
behaves ignores all method calls. Implementing such an object is easy 
enough, but it is too easy to mis actual errors this way. And IIRC this 
feature doesn't even work perfectly in Objective-C (what if the method 
returns anything other than an 'id', like a float/double/struct).

Ronald

Re: [Pyobjc-dev] Calling methods on nil

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

Marcel Weiher wrote:

> > The mechanics differ, but it's the same thing (OO with dynamic
> > method dispatching).
> 
> Exactly.  There is dynamic dispatch.  So when you "send a message",
> you get dynamic dispatch, and THEN the method is called.  If you just
> say "the method is called", you are simply *verbally* omitting the
> dynamic dispatch, though of course it is still happening.

That's just a matter of perspective <wink>: to me "the method foo of
this object" means the method you'd get when dispatching. Since dynamic
method dispatching is so deeply integrated in Python, I don't see how it
could mean anything else, so I disagree I'm omitting something crucial.

> > (I agree with you there's some implicity involved in method calling,
> > it's just that it doesn't feel that way to me since the rules are
> > clearly defined.)
> 
> Exactly my point, thank you!  :-)   The fact that it doesn't *feel* 
> like that any longer for you just shows how implicit message sending 
> (or dynamic dispatch, if you prefer) has become.
> 
> So it goes with ignoring messages to nil:  the rules are very clearly
> defined (a lot simpler than messages to other receivers), so there is
> no "general principle" that is being violated.  It is just that you
> are used to something different, and haven't assimilated these
> particular rules (yet ;-).

I'm not arguing against sending messages to nil in ObjC (although I
don't like it, see below), but against supporting it by PyObjC in
*Python*. In ObjC it makes more sense since all dispatching goes through
objc_msgSend(), so it can easily special-case nil. It simply doesn't
work like that in Python, but I've explained that before (in case you
missed it "bound method" is the key word).

(Just yesterday I was working on some code where a (Cocoa) method
unexpectedly returned nil (translated to None in Python). I was
extremely happy to get a traceback instead of silent failure; since None
is an actual object, it dispatches methods just like most other objects,
ie. raise an exception if a method isn't found. A silent failure surely
would've cost me much more time to figure out what I did wrong. Ignoring
messages to nil is convenient when you expect it, but it's a liability
when you don't. I much rather explicitly test for nil than shoot myself
in the foot.)

Just

Re: [Pyobjc-dev] Calling methods on nil

[Marcel W. <ma...@me...>]

On Friday, May 9, 2003, at 09:48  Uhr, Just van Rossum wrote:

> Marcel Weiher wrote:
>
>>> Bad example (I'm calling _this_ method on _that_ instance, I don't
>>> see what's implicit about that),
>>
>> Well, you aren't "calling" a "method" on an instance.  You are sending
>> a message to that instance, and that's not just a difference in
>> wording, although getting the terminology right also generally helps.
>
> That's just a matter of perspective.

That turns out not to be the case.

>  In Objective-C you call it "sending
> a message to an instance", in Python we call it "calling a method".

Well, then you say it wrong "in Python".  Seriously, there are other 
things you could call it, but "calling a method" is definitely not all 
that is happening.  "Calling a method" would be correct if you already 
*had* the method and just invoked it.  But that isn't what is happening:

>  The mechanics differ, but it's the same thing (OO with dynamic method
> dispatching).

Exactly.  There is dynamic dispatch.  So when you "send a message", you 
get dynamic dispatch, and THEN the method is called.  If you just say 
"the method is called", you are simply *verbally* omitting the dynamic 
dispatch, though of course it is still happening.

Of course, this just re-enforces my point that the dynamic dispatch of 
message sending is *implicit* in OO  [it is being done, but it is not 
mentioned *explicitly* in the program code].  You seem to have even 
edited it out of your mental-model!  ;-)

>  PyObjC demonstrates that clearly.

Very clearly!

> However, the differences in the mechanics between Python and 
> Objective-C
> make that "sending messages to nil" is a viable construct in
> Objective-C, but not in Python.
>
> (I agree with you there's some implicity involved in method calling,
> it's just that it doesn't feel that way to me since the rules are
> clearly defined.)

Exactly my point, thank you!  :-)   The fact that it doesn't *feel* 
like that any longer for you just shows how implicit message sending 
(or dynamic dispatch, if you prefer) has become.

So it goes with ignoring messages to nil:  the rules are very clearly 
defined (a lot simpler than messages to other receivers), so there is 
no "general principle" that is being violated.  It is just that you are 
used to something different, and haven't assimilated these particular 
rules (yet ;-).

Regards,

Marcel

-- 
Marcel Weiher				Metaobject Software Technologies
ma...@me...		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.

[Pyobjc-dev] [ pyobjc-Bugs-735815 ] ivar leak & crash

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

Bugs item #735815, was opened at 2003-05-10 22:34
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=735815&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Nobody/Anonymous (nobody)
Summary: ivar leak & crash

Initial Comment:
There is problem with assigning Python objects (that are not derived 
from NSObject) to ivars:

  >>> from objc import ivar
  >>> from Foundation import NSObject
  >>> class Foo(NSObject):
  ...   x = ivar("x")
  ... 
  >>> class Doo(object):
  ...   def __del__(self):
  ...     print "deleting Doo instance %x" % id(self)
  ... 
  >>> f = Foo.alloc().init()
  >>> f.y = Doo()  # assinging to non-ivar
  >>> f.y = 12
  deleting Doo instance 47bd10
  >>> f.x = Doo()  # assigning to ivar
  >>> f.x = 12  # look, no delete message
  >>> f.x = Doo()
  >>> del f.x
  Bus error

Two problems:
1) when *replacing* an ivar, the referenced object leaks
2) when *deleting* an ivar, there's a crash (btw. the bus error also
occurs if you try to delete an ivar that's not yet set (nil).

(Note that the leak does _not_ seem to occur when the referenced 
object's class is derived from NSObject, but the del crash occurs 
indepent of the type of the object.)

However, we have a bigger problem: ivars/outlets that are set by 
Cocoa during nib-awakening-time are weak references (not retained), 
so we can't simply release an ivar when we overwrite it with 
something else. Likewise during dealloc: currently ivars are _not_ 
released, which causes leaks for those ivars that are set from Python 
(x.y = z implies a retain for z).

Except perhaps for the Bus Error (which smells like a different 
problem altogether), these things are not easily fixed.

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

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

Re: [Pyobjc-dev] Packaging python with the app?

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

On Thursday, May 8, 2003, at 17:00 US/Eastern, Gary Robinson wrote:
> My understanding is that to do that, Python has to be compiled for SSL.
>
> That would mean that I couldn't use the Python on the client's 
> machine, even
> though all OS X 10.2 users have it.

Actually -- the ssl module builds fine for OS X 10.2 and it is simply a 
matter of adding _socket.so to the PyObjC copy files phase to make it 
all "just work".

See:

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

For a downloadable tarball.

b.bum

Re: [Pyobjc-dev] Calling methods on nil

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

Marcel Weiher wrote:

> > Bad example (I'm calling _this_ method on _that_ instance, I don't
> > see what's implicit about that),
> 
> Well, you aren't "calling" a "method" on an instance.  You are sending 
> a message to that instance, and that's not just a difference in 
> wording, although getting the terminology right also generally helps.

That's just a matter of perspective. In Objective-C you call it "sending
a message to an instance", in Python we call it "calling a method". The
mechanics differ, but it's the same thing (OO with dynamic method
dispatching). PyObjC demonstrates that clearly.

However, the differences in the mechanics between Python and Objective-C
make that "sending messages to nil" is a viable construct in
Objective-C, but not in Python.

(I agree with you there's some implicity involved in method calling,
it's just that it doesn't feel that way to me since the rules are
clearly defined.)

Just

Re: [Pyobjc-dev] Calling methods on nil

[Marcel W. <ma...@me...>]

On Thursday, May 8, 2003, at 07:43  Uhr, Just van Rossum wrote:

> Marcel Weiher wrote:
>
>>> "Explicit is better than implicit".
>>
>> Not necessarily.  For example, the polymorphism you get with OO is
>> *implicit*.  You didn't say which exact method you wanted, you just
>> sent the message and let the system decide which specific
>> implementation to use.  And yes, there are still a number of people
>> who consider this 'evil'.
>
> Bad example (I'm calling _this_ method on _that_ instance, I don't see
> what's implicit about that),

Well, you aren't "calling" a "method" on an instance.  You are sending 
a message to that instance, and that's not just a difference in 
wording, although getting the terminology right also generally helps.

The message dispatch algorithm that is run implicitly each time you 
send a message (or do you see an explicit invocation of that 
algorithm?) tries to locate the method for the message sent, and it 
will search the superclass chain until it finds such a method, and even 
do something special (depending on the language) if it doesn't.

Marcel

-- 
Marcel Weiher				Metaobject Software Technologies
ma...@me...		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.

Re: [Pyobjc-dev] Packaging python with the app?

[Gary R. <gro...@tr...>]

Whoah! That sounds great! Thanks!!

I may have more questions about it later -- but you have resolved my
immediate question about whether it's possible to do what I want.

--Gary

-- 
[http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org]

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454


> From: bb...@ma...
> Date: Thu, 8 May 2003 22:09:13 -0400
> To: Gary Robinson <gro...@tr...>
> Cc: <pyo...@li...>
> Subject: Re: [Pyobjc-dev] Packaging python with the app?
> 
> On Thursday, May 8, 2003, at 17:00 US/Eastern, Gary Robinson wrote:
>> My understanding is that to do that, Python has to be compiled for SSL.
>> 
>> That would mean that I couldn't use the Python on the client's
>> machine, even
>> though all OS X 10.2 users have it.
> 
> Actually -- the ssl module builds fine for OS X 10.2 and it is simply a
> matter of adding _socket.so to the PyObjC copy files phase to make it
> all "just work".
> 
> See:
> 
>    http://pyobjc.sourceforge.net/software/index.php
> 
> For a downloadable tarball.
> 
> b.bum
> 

[Pyobjc-dev] Packaging python with the app?

[Gary R. <gro...@tr...>]

Hi,

The app I'm building should be able to handle secure SOAP RPC via SSL.

My understanding is that to do that, Python has to be compiled for SSL.

That would mean that I couldn't use the Python on the client's machine, even
though all OS X 10.2 users have it.

Now, my understanding is that bundleapp lets one include the Python
interpreter itself. Correct?

If I do that is it completely independent of the user's regular Python? That
is, use of one Python interpreter won't interfere at all with the use of the
other? 

--Gary

-- 
[http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org]

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454

Re: [Pyobjc-dev] Calling methods on nil

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

Marcel Weiher wrote:

> > "Explicit is better than implicit".
> 
> Not necessarily.  For example, the polymorphism you get with OO is
> *implicit*.  You didn't say which exact method you wanted, you just
> sent the message and let the system decide which specific
> implementation to use.  And yes, there are still a number of people
> who consider this 'evil'.

Bad example (I'm calling _this_ method on _that_ instance, I don't see
what's implicit about that), but of course explicit isn't *always*
better than implicit, it's merely a general guideline for how things
work in Python (for example "12" + 13 raises an exception in Python,
whereas Perl thinks "hey, this string looks like a number, lets treat it
like that").

A _good_ counter example is Python's reference counting: it's implicit,
yet better than manual ref counting. (To be completely explicit <wink>:
in the context of Python at least.)

Just

Re: [Pyobjc-dev] Question about method name mangling

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

Jack Jansen wrote:

> > In "Writing the Code - Step 8." we explain after the fact that we
> > won't be doing the name mangling. This seems awkward. Since the
> > code works with the name mangling, is there any reason not to go
> > ahead with it?

There's no reason to do the mangling, so why bother?

> > class Converter(NibClassBuilder.AutoBaseClass):
> >     # the actual base class is NSObject
> >
> >     def convertAmount_atRate_(self, amt, rate):
> >         return amt * rate
> >
> > Other than that, the tutorial is excellent! Kudos to all involved.
> 
> I explicitly didn't do name mangling here to explain this point: that
> you don't have to use it your method is only going to be used from
> Python.
> 
> But if more people feel that this is obscure I can take it out...

I think it's a important point to make. The mangling is only needed when
calling ObjC methods or when ObjC is going to call Python methods. For
all other stuff it's best to follow Python conventions. It's not that
the name mangling makes things _better_ on the Python side, it's a
neccesary evil to be able to bridge to ObjC. I quite like this example:

sp.beginSheetForDirectory_file_modalForWindow_modalDelegate_didEndSelector_contextInfo_(
            None, None, self.glyphView.window(), self,
            "savePanelDidEnd:returnCode:contextInfo:", 0)

I'm definetely not going to name a method like that if it's never intended to be called
from ObjC ;-)

Just

[Pyobjc-dev] ***15.6 MILLION OPT-IN, TARGETED EMAIL ADDRESSES!

[Unussa<Inc...@ex...>]

SGVsbG8sDQoNClRoaXMgZW1haWwgaXMgdG8gaW5mb3JtIHlvdSB0aGF0IHRoaXMgaXMgeW91ciBs
YXN0IGNoYW5jZSB0byBnZXQgaW4gDQpvbiB0aGlzIG9mZmVyLi4uLi4xNS42IE1JTExJT04gT1BU
LUlOLCBUQVJHRVRFRCBFTUFJTCBBRERSRVNTRVMuLi4NClBMVVMgJDIsMDAwIFdPUlRIIE9GIEZS
RUUgRU1BSUwgTUFSS0VUSU5HIFNPRlRXQVJFIQ0KDQpXT1VMRCBZT1UgTElLRSBUTyBIQVZFIFlP
VVIgTUVTU0FHRSBTRUVOIEJZDQpPVkVSIDE1LjYgTUlMTElPTiBPUFQtSU4sIFRBUkdFVEVEIFBF
T1BMRSBEQUlMWT8NCg0KQkVMT1cgSVMgSlVTVCBBIFNBTVBMRSBPRiBXSEFUIFdFIEhBVkUgVE8g
T0ZGRVIgWU9VLi4uDQoNCj4+PldFIFdJTEwgU1VQUExZIFlPVSBXSVRIIE9WRVIgMTUuNiBNSUxM
SU9OIE9QVC1JTiBFTUFJTA0KQUREUkVTU0VTIFRPIEdFVCBZT1UgU1RBUlRFRCBSSUdIVCBBV0FZ
IQ0KDQo+Pj5GUkVFIEVNQUlMIEFERFJFU1MgRE9XTkxPQURTIEZPUiBMSUZFIQ0KDQo+Pj5ZT1Ug
V0lMTCBSRUNFSVZFIE9WRVIgJDIsMDAwIFdPUlRIIE9GIA0KRU1BSUwgTUFSS0VUSU5HIFNPRlRX
QVJFIEZSRUUhDQoNCkluY2x1ZGluZy4uLi4uLg0KDQpCUk9BRENBU1QgRU1BSUwgU0VORElORyBT
T0ZUV0FSRS4uLihzZW5kIG1pbGxpb25zIG9mIGVtYWlsDQphZHZlcnRpc2VtZW50cyBkYWlseSB3
aXRoIGEgZmV3IGNsaWNrcyBvZiB5b3VyIG1vdXNlLiBOZXcgYnVpbHQgaW4gDQpzdGVhbHRoIHRl
Y2hub2xvZ3kpLiBCZSBvbmUgb2YgdGhlIGZpcnN0IHBlb3BsZSB0byB1c2UgaXQuIFdlIHVzZWQg
dGhlIA0Kc2FtZSBzb2Z0d2FyZSB0byBzZW5kIHlvdSB0aGlzIGVtYWlsIG1lc3NhZ2UuDQoNCkVN
QUlMIEVYVFJBQ1RJT04gU09GVFdBUkUuLi4oUmV0cmVpdmUgbmV3IHRhcmdldGVkIGVtYWlsDQph
ZGRyZXNzZXMgZGFpbHkuIEh1bmRyZWRzIG9mIHRob3VzYW5kcyBvZiB0aGVtKQ0KDQpMSVNUIE1B
TkFHRU1FTlQgU09GVFdBUkUuLi4oS2VlcCB5b3VyIGxpc3RzIGNsZWFuLCBvcHQtaW4NCmFuZCBt
YW5hZ2UgYWxsIHlvdXIgcmVtb3ZlIHJlcXVlc3RzLCBsZWFkcywgc2FsZXMgZXRjLi4uKQ0KDQpQ
T1AtVVAgQURWRVJUSVNFUi4uLk5vIG5lZWQgdG8gcGF5IHNvbWVvbmUgZWxzZSBmb3IgDQpwb3At
dXAgYWR2ZXJ0aXNpbmcuIFNhdmUgJDEsMDAwcyB3ZWVrbHkuIEl0J3MgeW91cnMgdG9kYXkgZnJl
ZSEgDQpQbHVzIHlvdSBjYW4gcmVzZWxsIHRoaXMgc29mdHdhcmUgYW5kIGtlZXAgMTAwJSBvZiB0
aGUgcHJvZml0IG9yDQpzaW1wbHkgZ2l2ZSBpdCBhcyBhIGZyZWUgZ2lmdCBhbG9uZyB3aXRoIHlv
dXIgY3VycmVudCBzZXJ2aWNlcy4NCg0KYW5kIG11Y2guLi5tdWNoIG1vcmUhDQoNCkh1cnJ5Li4u
VGhpcyBleHRyYW9yZGluYXJ5IG9mZmVyIGVuZHMgc29vbiENCg0KVG8gZmluZCBvdXQgbW9yZSBp
bmZvcm1hdGlvbiwgRG8gbm90IHJlc3BvbmQgYnkgZW1haWwuIEluc3RlYWQsIGNsaWNrDQpvbiB0
aGUgbGluayBiZWxvdyAuDQoNCjxicj48QSBIUkVGPSJodHRwOi8vd3d3LmNyZWRpdGNhcmRiaXou
dXMvNDA5MzI0L2Jyb2FkY2FzdC5odG0iPkNsaWNrIEhlcmUgRm9yIE1vcmUgSW5mb3JtYXRpb248
L0E+PGJyPg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCldhbnQgdG8gYmUgUkVNT1ZFRCBmcm9tIG91ciBlbWFpbCBsaXN0Pw0K
WW91IHdlcmUgc2VudCB0aGlzIGVtYWlsIGJlY2F1c2UgeW91IHVzZWQgb3VyIE9wdC1pbiBzZXJ2
aWNlLg0KV2UgaG9wZSB5b3UgZW5qb3kgcmVhZGluZyBvdXIgbWVzc2FnZXMuIEhvd2V2ZXIsIGlm
IHlvdSdkIHJhdGhlcg0Kbm90IHJlY2VpdmUgZnV0dXJlIGUtbWFpbHMgZnJvbSB1cywgQ2xpY2sg
b24gdGhlIGxpbmsgYmVsb3cuDQo8YnI+PEEgSFJFRj0iaHR0cDovL3d3dy5jcmVkaXRjYXJkYml6
LnVzLzQwOTMyNC9yZW1vdmVtZS5odG0iPkNsaWNrIEhlcmUgVG8gYmUgcmVtb3ZlZCBmcm9tIG91
ciBsaXN0LjwvQT48YnI+DQpUaGFuayB5b3UgZm9yIHlvdXIgY29vcGVyYXRpb24uDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw==

Re: [Pyobjc-dev] Question about method name mangling

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

On woensdag, mei 7, 2003, at 19:19 Europe/Amsterdam, Zachery Bir wrote:

> In "Writing the Code - Step 8." we explain after the fact that we 
> won't be doing the name mangling. This seems awkward. Since the code 
> works with the name mangling, is there any reason not to go ahead with 
> it?
>
> class Converter(NibClassBuilder.AutoBaseClass):
>     # the actual base class is NSObject
>
>     def convertAmount_atRate_(self, amt, rate):
>         return amt * rate
>
> Other than that, the tutorial is excellent! Kudos to all involved.

I explicitly didn't do name mangling here to explain this point: that 
you don't have to
use it your method is only going to be used from Python.

But if more people feel that this is obscure I can take it out...
--
- 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] CVS build failing

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

On Thursday, May 8, 2003, at 01:08 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald_Oussoren wrote:
>
>> Your using an older snapshot of libffi. The snapshot that is
>> currently on SF should work.
>
> Does libffi contain a version macro we could check? Remember I had a
> libffi which mostly worked but caused an extremely hard to find bug...

Not AFAIK, and a quick check of the header-files didn't find such a 
macro either. Even if they did we probably wouldn't be able to use it 
anyway: We're using an unreleased CVS version, which means both the 
non-working version and the working version would contain the same 
version macro's.

Luckily things are not as bad as it looks: If the CVS version of PyObjC 
links without errors you have the right version of libffi, otherwise 
you don't. This heuristic breaks down when we add GNUstep support 
and/or need to move to a newer version of libffi.

Ronald

Re: [Pyobjc-dev] CVS build failing

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

Ronald_Oussoren wrote:

> Your using an older snapshot of libffi. The snapshot that is
> currently on SF should work.

Does libffi contain a version macro we could check? Remember I had a
libffi which mostly worked but caused an extremely hard to find bug...

Just

Re: [Pyobjc-dev] ASSISTANCE

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

On Wednesday, May 7, 2003, at 21:43 Europe/Amsterdam, Alhaji Abba Sani 
Abacha wrote:

>
> Dear Friend=2C
> This mail should come to you as a surprise=2C but not to worry as I 
> shall
> explain the reason of my writing=2C but for clarity sake=2C I am Abba 
> Sani Abacha=2C
> son of former Head of State Nigeria=2C Late General Sani Abacha=2E
>

Our advertizing effort seems to pay off :-).

Ronald

[Pyobjc-dev] ASSISTANCE

[Alhaji A. S. A. <abb...@ca...>]

Dear Friend=2C
This mail should come to you as a surprise=2C but not to worry as I shall
explain the reason of my writing=2C but for clarity sake=2C I am Abba Sani Abacha=2C
son of former Head of State Nigeria=2C Late General Sani Abacha=2E

Let me start by saying that I didn t just pick on you=2C but had found your
personal details in my search for a trust worthy and reliable foriegn associate
who will cooperation and assist my family to safe guard the sum of US$26=2E5
m which our late father had kept with security company as family treasure=2E

All things being equal=2C I shouldn t have contacted you=2C but for the fact
that this present Government is bent on confiscating all sums of money in
account abroad which belonged to my late father=2C has made it unavoidable=2E
To this end=2C the entire Abacha family has mandated me to contact and arrange
with you=2C so that you can front for the family in the process of claiming
the money from the security company=2E The reason being that we want a full
proof arrangement with a foreign associate who can not be easily traced=2C
so as to blind the Government and create a diversion from the family=2E

In the event that your conscience shall not betray the family to this present
Government and your conviction to assist=2C the family shall part with 5%
of the total sum for all your troubles=2E I shall also throw more light as
I await your response=2EI have attached some WEB SITES as a prove of reality
of the plight of my family=2E

www=2Elagos-online=2Ecom=2Ffq=5Fdetails=5Floot-from-abacha=2Ehtm
www=2Eallafrica=2Ecom=2Fstories=2F200012070247=2Ehtml
www=2Eallafrica=2Ecom=2Fstories=2F200010230279=2Ehtml

Thanks=2FMa Salam=2C
Abba Sani Abacha=2E
Tel=3A234-80-4213-9380
Alternative email=3Aabba=2Eibn=40caramail=2Ecom

[Pyobjc-dev] MacUpdate Dev: PyObjC 0.9 added

[<mac...@ma...>]

the PyObjC team,

PyObjC 0.9 has been added to MacUpdate. Check it out at:

http://www.macupdate.com/info.php/id/11709

Please keep MacUpdate informed of any new Mac version releases of your products, so we can promote them for you. You can update your listing by sending us an email or going to:

http://www.macupdate.com/email/submission.php

-Joel Mueller
www.macupdate.com

[You're being notified of this update because you're listed as the developer of PyObjC. Please email us if you are not the developer: mac...@ma...].

Re: [Pyobjc-dev] VersionTracker updated!

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

On Wednesday, May 7, 2003, at 14:43 Europe/Amsterdam, Bill Bumgarner 
wrote:

> VersionTracker updated.
>
> Maybe we should add a link on the home page of the site that points to 
> a fixed Tutorial.html published via pyobjc.sf.net until we drop a new 
> release?

I'll update the website.

Ronald

[Pyobjc-dev] Question about method name mangling

[Zachery B. <zb...@ur...>]

In "Writing the Code - Step 8." we explain after the fact that we won't 
be doing the name mangling. This seems awkward. Since the code works 
with the name mangling, is there any reason not to go ahead with it?

class Converter(NibClassBuilder.AutoBaseClass):
     # the actual base class is NSObject

     def convertAmount_atRate_(self, amt, rate):
         return amt * rate

Other than that, the tutorial is excellent! Kudos to all involved.

Zac

[Pyobjc-dev] VersionTracker updated!

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

VersionTracker updated.

Maybe we should add a link on the home page of the site that points to 
a fixed Tutorial.html published via pyobjc.sf.net until we drop a new 
release?

b.bum