pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Re: FYI: Open Source Scripting Layer For Cocoa

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

>> Any other ideas for something that is much simpler in Python than in
>> ObjC?

XML-RPC and similar.

XML processing is often easier in Python.

File parsing/grepping/filtering.

Image manipulation via something like PIL.

Subprocess/task control -- someone ought to wrap pexpect into a 
Cocoa/Python app that would produce droplets or something.

Re: [Pyobjc-dev] FYI: Open Source Scripting Layer For Cocoa

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

On Monday, Jun 9, 2003, at 10:02 Europe/Amsterdam, Ronald Oussoren 
wrote:

>
> I'm going to dust off my code for writing a Python based plugin 
> bundle, that should make it possible to
>  inspect any Cocoa program that supports plugins :-)

I've checked in a module that allows you to build Python based 
preference panes, as well as an example that makes use of this: A 1 
function calculator PreferencePane :-)

I think we now have everything thats needed to build a plugin that 
allows full inspection of running programs. If someone wants to write 
such a beast I'd be more than willing to add this to our repository!

Ronald

[Pyobjc-dev] Re: FYI: Open Source Scripting Layer For Cocoa

[Michael H. <mw...@py...>]

Jack Jansen <Jac...@cw...> writes:

> Any other ideas for something that is much simpler in Python than in
> ObjC?

I would have thought anything network-y that's in Python standard
library would be a candidate... using XML-RPC to read someone's
advogato diary or something like that?

Of course, I don't know how hard that would be in ObjC, but it's
falling-off-a-log easy in Python.

Cheers,
M.

-- 
  Ya, ya, ya, except ... if I were built out of KSR chips, I'd
  be running at 25 or 50 MHz, and would be wrong about ALMOST
  EVERYTHING almost ALL THE TIME just due to being a computer!
                                              -- Tim Peters, 30 Apr 97

Re: [Pyobjc-dev] notes on Examples/

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

On Monday, Jun 9, 2003, at 10:26 Europe/Amsterdam, Just van Rossum 
wrote:

> I think it would be useful to add my ClassBrowser and PythonBrowser
> examples to the Examples directory. PythonBrowser's use of 
> NSOutlineView
> is quite different from iClass, and we currently don't have any demo's
> for NSBrowser. Another example that has helped me a lot in the past is
> Etienne Posthumus Pythonized DotView example. I would be willing to 
> make
> that one ready for Examples/, too.
>
> I am aware that we won't ever be able to get full coverage of the Cocoa
> frameworks, but simple examples of often needed UI elements can be
> extremely helpful for people starting with PyObjC.

Adding these is fine with me. We currently have to few usefull examples.

>
> We could also do some cleaning-up: at least TableModel2 is redundant, 
> as
> WebServicesTool already demonstrates (among many other things -- it's a
> truly great demo!) how to build Cocoa-Python apps with ProjectBuilder
> quite well. (TableModel and TableModel2 are already quite out of sync,
> which is basically why I bring this up.)

Having two almost identical examples is not very usefull, TableModel2 
should be removed. It might be usefull to add project-builder projects 
to every example, but we then have to find a volunteer to keep these 
up-to-date.

>
> Another useful change would be the incorporation of
> Examples/00ReadMe.txt into the HTML docs. Perhaps this can even be
> automated if we convert that file to reST.

I'd like to add the examples to the website, but haven't really thought 
on how to do this. We could add HTML files with pretty-printed source 
files and a link to an archive containing the sources for the example.

Automaticly converting the readme to HTML would be trivial if it were 
written in ReST.

Ronald

[Pyobjc-dev] notes on Examples/

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

I think it would be useful to add my ClassBrowser and PythonBrowser
examples to the Examples directory. PythonBrowser's use of NSOutlineView
is quite different from iClass, and we currently don't have any demo's
for NSBrowser. Another example that has helped me a lot in the past is
Etienne Posthumus Pythonized DotView example. I would be willing to make
that one ready for Examples/, too.

I am aware that we won't ever be able to get full coverage of the Cocoa
frameworks, but simple examples of often needed UI elements can be
extremely helpful for people starting with PyObjC.

We could also do some cleaning-up: at least TableModel2 is redundant, as
WebServicesTool already demonstrates (among many other things -- it's a
truly great demo!) how to build Cocoa-Python apps with ProjectBuilder
quite well. (TableModel and TableModel2 are already quite out of sync,
which is basically why I bring this up.)

Another useful change would be the incorporation of
Examples/00ReadMe.txt into the HTML docs. Perhaps this can even be
automated if we convert that file to reST.

Objections/suggestions?

Just

Re: [Pyobjc-dev] FYI: Open Source Scripting Layer For Cocoa

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

On Sunday, Jun 8, 2003, at 18:39 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>> or an object
>> browser, packaged in such a way that an ObjC programmer with no Python
>> knowledge can easily plug it in his/her existing program.
>
> Can we reach ivars from objects who's class is not defined in Python,
> from Python?

We could somewhere between 0.6 and 0.7, but then I noticed that 
instance variables often have the same name as the getter method for 
that variable. All machinery is still there, it would not be too hard 
to add 'obj.pyobjc_instanceVariables' as special notation to allow 
access to instance variables (just like we do for methods).

I'm going to dust off my code for writing a Python based plugin bundle, 
that should make it possible to inspect any Cocoa program that supports 
plugins :-)

Ronald

Re: [Pyobjc-dev] FYI: Open Source Scripting Layer For Cocoa

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

Jack Jansen wrote:

> [ ... ] such as the 
> recently mentioned class browser (which, incidentally, I missed??!? I 
> only saw the followups to Just's original message)

Hm, that was from today, and since you also appeared to have missed an
earlier attachment I posted I'm beginning to think you simply don't
receive mime attachments from this list. Possible? I'll send you the
code off-list...

> or an object 
> browser, packaged in such a way that an ObjC programmer with no Python 
> knowledge can easily plug it in his/her existing program.

Can we reach ivars from objects who's class is not defined in Python,
from Python?

Just

Re: [Pyobjc-dev] FoundationMapping.m doesn't compile (from CVS)

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

On Sunday, Jun 8, 2003, at 23:36 Europe/Amsterdam, Jack Jansen wrote:

> I just did a cvs update, and now 
> Modules/Foundation/_FoundationMapping.m no longer
> compiles, it complains about a missing _FoundationMapping_NSDict.m.
>
> Did someone forget to check something in, or is this my mistake?
I didn't check in this file. It's in now.

Ronald

[Pyobjc-dev] FoundationMapping.m doesn't compile (from CVS)

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

I just did a cvs update, and now 
Modules/Foundation/_FoundationMapping.m no longer
compiles, it complains about a missing _FoundationMapping_NSDict.m.

Did someone forget to check something in, or is this my mistake? It 
could well
be the latter, this is on my laptop (where I don't work as often as on 
the
other machines).
--
- 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] FYI: Open Source Scripting Layer For Cocoa

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

On zondag, jun 8, 2003, at 16:53 Europe/Amsterdam, Ronald Oussoren 
wrote:
>> A second advantage is that it should be easy to incorporate in your 
>> ObjC program, according to their website.
>
> Python is not too hard to integrate into your ObjC programs. If you 
> add some ObjC-sauce integrating Python would be as easy as integrating 
> F-script.

I know that it's not too hard, but what I think we really need is "dead 
easy". What I'd prefer is a useful bit of functionality, such as the 
recently mentioned class browser (which, incidentally, I missed??!? I 
only saw the followups to Just's original message) or an object 
browser, packaged in such a way that an ObjC programmer with no Python 
knowledge can easily plug it in his/her existing program.

Alternatively, we should provide an example, probably in tutorial 
style. Hmm, idea: how about taking the currency converter ObjC tutorial 
as a start, and in the tutorial we add Python code to lookup actual 
exchange rates at oanda or x-rates or one of such sites, generating the 
right query and parsing the resulting HTML?
Hmm, too bad: all top currency converters I looked at explicitly forbid 
this in the policy statements:-(

Any other ideas for something that is much simpler in Python than in 
ObjC?
--
- 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] FYI: Open Source Scripting Layer For Cocoa

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

On Friday, Jun 6, 2003, at 13:49 Europe/Amsterdam, Jack Jansen wrote:

>
> On Friday, Jun 6, 2003, at 11:35 Europe/Amsterdam, Dinu Gherman wrote:
>
>>   Open Source Scripting Layer For Cocoa
>>
>>   Philippe Mougin writes "F-Script is a lightweight object-oriented
>>   interactive and scripting layer specifically designed for Mac OS X
>>   object system (i.e. Cocoa). F-Script version 1.2.4 greatly enhances
>>   the integration between F-Script and Cocoa, and comes with extended
>>   documentation.
>>
>>   http://www.macslash.org/articles/03/06/05/1446248.shtml
>
> I had a look at it, uhm, half a year ago. It is only half a bridge, 
> i.e. F-Script can use ObjC but not the other way around.
>
> The main advantage it has over PyObjC is that it has an object/class 
> browser and an interactive window. It's a bit clunky, but it gets you 
> there quickly.

Both should be doable with PyObjC, the class browser has already been 
written at least twice and I think their is also an object browser in 
the mailinglist archives :-).

The archives also contain a hack that allows you to write PyObjC based 
extension bundles, combine all these and you get something *very* 
interesting.

>
> A second advantage is that it should be easy to incorporate in your 
> ObjC program, according to their website.

Python is not too hard to integrate into your ObjC programs. If you add 
some ObjC-sauce integrating Python would be as easy as integrating 
F-script.

Ronald

Re: [Pyobjc-dev] (Class)Browser demo

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

On Sunday, Jun 8, 2003, at 16:40 Europe/Amsterdam, Ronald Oussoren 
wrote:
> The code uses __slots__ and uses instance variables not mentioned in 
> __slots__. That used to work, but no longer does (and quite rightly 
> so). The find class text field almost works for me, if you type a 
> classname + ENTER the tableview changes to the detail view for that 
> class, but the outline view isn't updated as it should.

And now it is. The problem was easier than I thought and is fixed in 
CVS.

Ronald

Re: [Pyobjc-dev] (Class)Browser demo

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

On Sunday, Jun 8, 2003, at 16:30 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>
>> There's also Examples/iClass, which is simular but uses an
>> NSOutlineView for the class-list, and shows more information about
>> methods and includes all methods for the class, including those
>> inherited from base classes.
>>
>> The iClass example is very rough, I wrote for a demo of PyObjC for
>> some dutch Mac programmers.
>
> Nice! Strange, I never noticed iClass before... (Btw. it doesn't work
> with CVS PyObjC, it does with 2.2+0.9, except for the find class text
> field.)

The code uses __slots__ and uses instance variables not mentioned in 
__slots__. That used to work, but no longer does (and quite rightly 
so). The find class text field almost works for me, if you type a 
classname + ENTER the tableview changes to the detail view for that 
class, but the outline view isn't updated as it should.

>
> Jack, you should really have a look at this, it already contains quite 
> a
> bit of what you were asking for.

It is also some very quick&dirty code.

Ronald

Re: [Pyobjc-dev] (Class)Browser demo

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

Ronald Oussoren wrote:

> There's also Examples/iClass, which is simular but uses an
> NSOutlineView for the class-list, and shows more information about
> methods and includes all methods for the class, including those
> inherited from base classes.
> 
> The iClass example is very rough, I wrote for a demo of PyObjC for
> some dutch Mac programmers.

Nice! Strange, I never noticed iClass before... (Btw. it doesn't work
with CVS PyObjC, it does with 2.2+0.9, except for the find class text
field.)

Jack, you should really have a look at this, it already contains quite a
bit of what you were asking for.

Just

Re: [Pyobjc-dev] (Class)Browser demo

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

On Sunday, Jun 8, 2003, at 15:36 Europe/Amsterdam, Just van Rossum 
wrote:

> I've attached a ClassBrowser demo program I just wrote. It's very
> simple, contains an NSBrowser and an NSTableView inside an NSSplitView.
> In the browser you can browse the class hierarchy, beginning with
> NSObject. In the table view you see a list of methods defined in the
> selected class (and only those defined there, it doesn't list inherited
> methods).

There's also Examples/iClass, which is simular but uses an 
NSOutlineView for the class-list, and shows more information about 
methods and includes all methods for the class, including those 
inherited from base classes.

The iClass example is very rough, I wrote for a demo of PyObjC for some 
dutch Mac programmers.

Ronald

[Pyobjc-dev] (Class)Browser demo

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

I've attached a ClassBrowser demo program I just wrote. It's very
simple, contains an NSBrowser and an NSTableView inside an NSSplitView.
In the browser you can browse the class hierarchy, beginning with
NSObject. In the table view you see a list of methods defined in the
selected class (and only those defined there, it doesn't list inherited
methods).

Build the app like so:

    $ python buildapp.py --link build

(--link is useful if you want to play with the source, with --link, you
don't have to rebuild the app after you modify the source or the nib.)

I found NSBrowser fairly simple to work with, but there's one gotcha:
the NSBrowserDelegate informal protocol is not yet defined in
AppKit.__init__. I've included one in the program itself (actually, it
takes up about half of the lines in the program...).

(Note that I'm working on a script that generates definitions for all
protocols from header files; I think this might hit CVS fairly soon.)

Just

Re: [Pyobjc-dev] __subclasses__

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

On Friday, Jun 6, 2003, at 20:24 Europe/Amsterdam, Just van Rossum 
wrote:

> It's amazing how well Ronald managed to integrate ObjC classes with
> Python classes. Eg. cls.__subclasses__() Just Works:
>
>
>   from Foundation import NSObject
>   import AppKit  # just to load the AppKit classes
>
>   def walk(cls, indent=""):
>       subclasses = cls.__subclasses__()
>       print indent + cls.__name__
>       if subclasses:
>           subclasses = [(sub.__name__, sub) for sub in subclasses]
>           subclasses.sort()
>           for name, sub in subclasses:
>               walk(sub, indent + "    ")
>
>   walk(NSObject)
>
>
> I'd say that's pretty neat.

It sure is, and I didn't have to do anything special to get this (e.g. 
I'm as surprised as you that this works).

Ronald

[Pyobjc-dev] __subclasses__

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

It's amazing how well Ronald managed to integrate ObjC classes with
Python classes. Eg. cls.__subclasses__() Just Works:


  from Foundation import NSObject
  import AppKit  # just to load the AppKit classes

  def walk(cls, indent=""):
      subclasses = cls.__subclasses__()
      print indent + cls.__name__
      if subclasses:
          subclasses = [(sub.__name__, sub) for sub in subclasses]
          subclasses.sort()
          for name, sub in subclasses:
              walk(sub, indent + "    ")

  walk(NSObject)


I'd say that's pretty neat.

Just

Re: [Pyobjc-dev] Wanted: a generic object browser

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

Jack Jansen wrote:

> 1. A Python browser, for use in the next-generation MacPython IDE.

Have you missed my PythonBrowser/NSOutlineView demo/prototype? Most
recently posted in this threadlet:

http://sourceforge.net/mailarchive/forum.php?thread_id=2372447&forum_id=
4355

...but it seems the archiver tossed the attachment. Let me know if you
want me to send it to you. It's by no means a generic browser, but I
think it could be made into one. It's mostly the result of me trying to
grok NSOutlineViw.

It would be great if there were a similar demo using NSBrowser instead
of NSOutlineView. Ideally the user should be able to switch between
"list/tree view" and "column view".

Just

[Pyobjc-dev] Wanted: a generic object browser

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

In case someone is looking for an interesting project to do with 
PyObjC: here is one. Unless it's been done already, of course:-)

What I want is a generic class/object browser that can be subclassed to 
create language-specific browsers. I already have three applications 
for such a beast:

1. A Python browser, for use in the next-generation MacPython IDE.

2. An ObjC browser, which could be used not only for PyObjC development 
(it needs a button that flips the naming convention between 
ObjC/PyObjC, definitely) but also to create a self-contained framework 
that ObjC users can easily link into their ObjC application to allow 
interactive inspection of their data, probably including the ability to 
use little bits of Python code to fiddle things.

3. An OSA browser. This would use the MacPython OSA stuff to allow you 
to look at objects inside an OSA-enabled application. Think of 
something like UIElementInspector or UI Browser, but much more general.
--
Jack Jansen, <Jac...@cw...>, 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] FYI: Open Source Scripting Layer For Cocoa

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

On Friday, Jun 6, 2003, at 11:35 Europe/Amsterdam, Dinu Gherman wrote:

>   Open Source Scripting Layer For Cocoa
>
>   Philippe Mougin writes "F-Script is a lightweight object-oriented
>   interactive and scripting layer specifically designed for Mac OS X
>   object system (i.e. Cocoa). F-Script version 1.2.4 greatly enhances
>   the integration between F-Script and Cocoa, and comes with extended
>   documentation.
>
>   http://www.macslash.org/articles/03/06/05/1446248.shtml

I had a look at it, uhm, half a year ago. It is only half a bridge, 
i.e. F-Script can use ObjC but not the other way around.

The main advantage it has over PyObjC is that it has an object/class 
browser and an interactive window. It's a bit clunky, but it gets you 
there quickly.

A second advantage is that it should be easy to incorporate in your 
ObjC program, according to their website.

And a final one, for ObjC programmers, is that the smalltalk dialect 
they use is closer to ObjC than Python is.

I think that if we want to think of using PyObjC to rule the world 
F-Script would be a good target. If we can incorporate the same 
functionality as it has it would make PyObjC useful to more people. 
I'll post a separate mail on the class browser in a minute.
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

[Pyobjc-dev] FYI: Open Source Scripting Layer For Cocoa

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

Might be of interest (if only as something to compare with),
haven't looked deep inside, though...

Dinu

"""
   Open Source Scripting Layer For Cocoa

   Philippe Mougin writes "F-Script is a lightweight object-oriented
   interactive and scripting layer specifically designed for Mac OS X
   object system (i.e. Cocoa). F-Script version 1.2.4 greatly enhances
   the integration between F-Script and Cocoa, and comes with extended
   documentation.

   http://www.macslash.org/articles/03/06/05/1446248.shtml
"""

--
Dinu C. Gherman
......................................................................
"Never advice anyone to go to war or to marry." (Spanish Proverb)

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

[Riressi<Gen...@ex...>]

DQogSGVsbG8sDQoNClRoaXMgaXMgeW91ciBsYXN0IGNoYW5jZSB0byBnZXQgaW4gb24gdGhpcyBl
eHRyYW9yZGluYXJ5IG9mZmVyDQppZiB5b3UgaGF2ZSBub3QgZG9uZSBzbyB5ZXQuDQoNCldPVUxE
IFlPVSBMSUtFIFRPIEhBVkUgWU9VUiBNRVNTQUdFIFNFRU4gQlkNCk9WRVIgMTUuNyBNSUxMSU9O
IE9QVC1JTiwgVEFSR0VURUQgUEVPUExFIERBSUxZPw0KDQpQTFVTIFJFQ0VJVkUgJDIsMDAwIFdP
UlRIIE9GIEZSRUUgRU1BSUwgTUFSS0VUSU5HIFNPRlRXQVJFIQ0KDQpCZWxvdyBjb250YWlucyBh
bGwgdGhlIGluZm9ybWF0aW9uIHlvdSB3aWxsIGV2ZXIgbmVlZCB0byBtYXJrZXQNCnlvdXIgcHJv
ZHVjdCBvciBzZXJ2aWNlIG9uIHRoZSBJbnRlcm5ldC4NCg0KSWYgeW91IGhhdmUgYSBwcm9kdWN0
LCBzZXJ2aWNlLCBvciBtZXNzYWdlIHRoYXQgeW91IHdvdWxkIGxpa2UgdG8gZ2V0DQpvdXQgdG8g
VGhvdXNhbmRzLCBIdW5kcmVkcyBvZiBUaG91c2FuZHMsIG9yIGV2ZW4gTWlsbGlvbnMgb2YgcGVv
cGxlLA0KeW91IGhhdmUgc2V2ZXJhbCBvcHRpb25zLiBUcmFkaXRpb25hbCBtZXRob2RzIGluY2x1
ZGUgcHJpbnQgYWR2ZXJ0aXNpbmcsDQpkaXJlY3QgbWFpbCwgcmFkaW8sIGFuZCB0ZWxldmlzaW9u
IGFkdmVydGlzaW5nLiBUaGV5IGFyZSBhbGwgZWZmZWN0aXZlLCBidXQNCnRoZXkgYWxsIGhhdmUg
dHdvIGNhdGNoZXM6IFRoZXkncmUgRVhQRU5TSVZFIGFuZCBUSU1FDQpDT05TVU1JTkcuIE5vdCBv
bmx5IHRoYXQsIHlvdSBvbmx5IGdldCBPTkUgU0hPVCBhdCBtYWtpbmcNCnlvdXIgbWVzc2FnZSBo
ZWFyZCBieSB0aGUgcmlnaHQgcGVvcGxlLiBBbHNvLCBJbnRlcm5ldCBTZWFyY2ggRW5naW5lDQpT
dWJtaXNzaW9ucywgQ2xhc3NpZmllZCBBZHMsIE5ld3Nncm91cCBQb3N0aW5ncyBzaW1wbHkgRE8g
Tk9UDQpXT1JLIGVmZmVjdGl2ZWx5Lg0KDQpOb3cgdGhpcyBoYXMgYWxsIGNoYW5nZWQhDQoNClRo
YW5rcyB0byB0aGUgdG9wIHByb2dyYW1tZXJzIGluIHRoZSB3b3JsZCBhbmQgdGhlaXIgTkVXIEVN
QUlMDQpURUNITk9MT0dZLCBZb3UgY2FuIHNlbmQgbWlsbGlvbnMgb2YgZW1haWwgbWVzc2FnZXMg
ZGFpbHkgZm9yDQpGUkVFLi4uV2l0aG91dCBnZXR0aW5nIHRlcm1pbmF0ZWQgZnJvbSB5b3VyIGN1
cnJlbnQgSW50ZXJuZXQgY29ubmVjdGlvbiENCg0KSXQncyB2ZXJ5IHNpbXBsZSB0byBkbyBhbmQg
eW91IGNhbiBiZSBpbmNyZWFzaW5nIHlvdXIgc2FsZXMgd2l0aGluIG1pbnV0ZXMNCm9mIGluc3Rh
bGxpbmcgdGhpcyBleHRyYW9yZGluYXJ5IG5ldyBzb2Z0d2FyZSENCg0KQmVzaWRlcy4uLkl0J3Mg
dGhlIG9ubHkgcmVhbCB3YXkgdG8gYWR2ZXJ0aXNlIG9uIHRoZSBJbnRlcm5ldCB0aGF0IHdvcmtz
Li4uUGVyaW9kIQ0KDQpCRUxPVyBJUyBKVVNUIEEgU0FNUExFIE9GIFdIQVQgV0UgSEFWRSBUTyBP
RkZFUiBZT1UuLi4NCg0KPj4+V0UgV0lMTCBTVVBQTFkgWU9VIFdJVEggT1ZFUiAxNS43IE1JTExJ
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] A better way to deal w/sig 10 & 11 exceptions

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

On Wednesday, Jun 4, 2003, at 07:30 US/Eastern, bb...@ma... wrote:
> If I get a chance, I'll look into adding an ExceptionHandling module 
> that wraps the framework of the same name.

Ooops... that framework is undocumented and, as far as I can tell, 
designed to handle exceptions related to Distributed Objects.

Fortunately, the lower level C API -- see man signal -- is 
straightforward.

b.bum

Re: [Pyobjc-dev] A better way to deal w/sig 10 & 11 exceptions

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

On Wednesday, Jun 4, 2003, at 04:09 US/Eastern, Just van Rossum wrote:
> That would be extremely useful. However, I can't get it to work when
> there's a real crash. I don't get a Python stack trace when I patch 
> your
> demo like this:

As it turns out, it doesn't trigger nearly as often as one would like.  
The Python signal handlers are too wrapped up in the interpreter state 
such that crashes in a lot of places will not trigger the stack trace.

Unfortunate, that, but there is an easy-- though ugly-- solution.

The entire signal handling mechanism should be moved to C.   Once in C, 
it'll-- at least-- trigger reliably.

> Could this ever work to begin with? It seems that upon such a crash the
> state of the program is undefined, and executing Python code may no
> longer work.

In these situations, I always take a "something is better than nothing" 
approach.  If it works once in ten, that is better than what we have 
now.

In general, when a crash occurs it is not because the entire app's 
memory is trashed but more because there is some local fault.   As 
such, the Python interpreter should still be viable enough to dump a 
backtrace.

If I get a chance, I'll look into adding an ExceptionHandling module 
that wraps the framework of the same name.

b.bum