pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Debugging PyObjc Apps

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

On Saturday, Feb 1, 2003, at 15:23 US/Eastern, Just van Rossum wrote:
> I don't think gdb helps all that much when debugging Python. The Python
> debugger (bdb.py/pdb.py) is pure Python, so the startup funkiness
> shouldn't get in the way there.

It helps when something on the compiled side of the bridge crashes... 
:-)

In all seriousness, it can help if you want to catch when a particular 
method on the standard kit of objects is invoked.  In particular, 
setting a breakpoint on NSException's -raise can be very useful in 
determining where the app was in the request/response loop when the 
badness started.

At some point, we really should add a 'debug' module to AppKit or 
Foundation that provides a quick way of starting up pdb and gives some 
kind of a trivial console type interface for interacting with it.  I 
haven't looked at pdb;  does it do remote debugging?

b.bum

[Pyobjc-dev] [ pyobjc-Bugs-678818 ] Missing NSCFNumber to int conversions

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

Bugs item #678818, was opened at 2003-02-01 14:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=678818&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Eppstein (eppstein)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing NSCFNumber to int conversions

Initial Comment:
The attached code shows two problems and one
non-problem with NSCFNumber (a data type that arises
when objc passes an integer value to a python routine
-- in the code, python ints passed to undoManager get
transmogrified into this type when an undo or redo is
requested).

1. if x: should only execute the if clause when x is
nonzero.  But if x is a zero NSCFNumber, the clause
gets executed erroneously (third line of code's output
is "Increment by ..." instead of "Null increment")

2. str(x) should produce a decimal representation of x,
but if x is an NSCFNumber, it instead produces a string
like '<NSCFNumber objective-c instance 0x832ed0>'
(third and fourth lines of code's output).

Given these bobbles, I would have expected to also have
problems with arithmetic expressions involving
NSCFNumber, but that is a non-problem -- the arithmetic
in the attached code behaves correctly.

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

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

Re: [Pyobjc-dev] top level namespaces

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

Just van Rossum wrote:

> This means there will be a folder inside site-packages containing a
> folder (eg.) PyObjC which contains all our stuff. Right next to it in
> site-packages there's a file called PyObjC.pth which contains one
> line "PyObjC", which is the relative path to our dir which will then
> be added to sys.path by site.py. So this solves the cluttering of the
> site-packages dir.

This is all there is to it:

Index: setup.py
===================================================================
RCS file: /cvsroot/pyobjc/pyobjc/setup.py,v
retrieving revision 1.32
diff -c -r1.32 setup.py
*** setup.py    31 Jan 2003 14:34:11 -0000      1.32
--- setup.py    1 Feb 2003 20:59:13 -0000
***************
*** 283,286 ****
--- 283,287 ----
        packages = packages,
        package_dir = package_dir,
        scripts = [ 'Scripts/nibclassbuilder', ],
+       extra_path = "PyObjC",
  )


Shall I go for it?

Just

Re: [Pyobjc-dev] top level namespaces

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

Bill Bumgarner wrote:

> On Saturday, Feb 1, 2003, at 15:02 US/Eastern, Tony Lownds wrote:
> > lowercase for appkit and foundation?
> 
> Follows Python standard?

Nah, there's StringIO, BaseHTTPServer.py, Carbon, and these are just the
first three that popped up in my head...

> > 3. Its not hard to package the modules in a subdirectory, using
> > .pth files in /usr/lib/site-packages and with minimal extra code in
> > bin-python-main.m. Hmm, and some extra code in bundlebuilder.py
> > too, I think. OTOH, extra code somewhere is still extra code, and
> > putting everything in a package doesn't require any extra code.
> 
> I'm not sure what this means....

This means there will be a folder inside site-packages containing a
folder (eg.) PyObjC which contains all our stuff. Right next to it in
site-packages there's a file called PyObjC.pth which contains one line
"PyObjC", which is the relative path to our dir which will then be added
to sys.path by site.py. So this solves the cluttering of the
site-packages dir.

> All in all, I'm not hugely attached to any of this.  

Think of all the articles on line whose examples would stop working ;-)

> I suppose my 
> motivation is largely one of having to uninstall the module 
> semi-regularly to ensure that standalone builds still work correctly.   
> Not a very good reason to modify the dev environment, certainly.

Ok, this .pth thing can help here. It's a simple patch to setup.py, I'll
look into it.

Just

Re: [Pyobjc-dev] 0.9

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

Tony Lownds wrote:

> FWIW, I am -0

Me too.

> 3. Its not hard to package the modules in a subdirectory, using .pth 
> files in /usr/lib/site-packages and with minimal extra code in 
> bin-python-main.m.

Yes, distutils supports this easily. I've used it myself and I know
NumPy does it, too. If we choose to do this I volunteer to patch
setup.py. Note that this makes upgrading harder (once), as you probably
need to manually delete the modules from the "old" place.

> Hmm, and some extra code in bundlebuilder.py too, I think.

Hm, I can't see why. Can you elaborate?

Just

Re: [Pyobjc-dev] Debugging PyObjc Apps

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

bb...@ma... wrote:

> I did confirm that the Wing IDE works with PyObjC correctly,
> including the debugger.

Ah, that's cool. I've never tried it, even though I got a CD at the
EuroPython conference...

[OT: Speaking of conferences: is anyone going to PyCon? I'm not, but it
would be great if someone could do a PyObjC talk there. It's in DC, so
Bill is pretty closeby (compared to me, Ronald and Jack at least ;-) so
I think we should elect him as the official representative ;-]

> Obviously, there is a big issue with the way app startup happens.  
> The situation may improve with an embedded interpreter-- certainly
> makes it possible to use gdb directly-- but I'm not 100% sure.

I don't think gdb helps all that much when debugging Python. The Python
debugger (bdb.py/pdb.py) is pure Python, so the startup funkiness
shouldn't get in the way there.

Just

Re: [Pyobjc-dev] Error compiling latest CVS w/python 2.2

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

Tony Lownds wrote:

> The autoGIL.c module uses some python 2.3 macros. Here is a diff 
> which lets it compile with python 2.2.

Whoops, sorry, I should've tested with 22 myself :-(. Patch applied.

Just

[Pyobjc-dev] Inner namespaces

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

As the wrappers for the NSGraphics API is filled in [on my todo list], 
I would like to move everything into an NSGraphics package that 
contains all of those APIs.   There are numerous functions in that 
package and there will likely also be some pure python support code 
that will be quite handy in using those.

Dividing them out would greatly reduce the noise in the already 
cluttered AppKit namespace...

This is an easy one as NSRectFillList() is currently the only bridged 
function and I'm likely the only one who is using it... :-)

thoughts?

b.bum

[Pyobjc-dev] top level namespaces

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

On Saturday, Feb 1, 2003, at 15:02 US/Eastern, Tony Lownds wrote:
> Hi,
> At 2:15 PM -0500 2/1/03, Bill Bumgarner wrote:
>> As Just mentioned, it is about time to do a 0.9 release.
> Out of curiosity, will 0.9 be FFI only?

Good question.   Personally, I think it should be for two reasons:

- we have FFI only features now [classAddMethods]

- we have already had a situation where the non-FFI stuff broke because 
it went untested... i.e. non-FFI support is being neglected by the dev 
team.

>> If we are going to do any major changes to the namespace, now is the 
>> time.
>>
>> I would like to see *everything* in pyobjc move into a 'pyobjc' 
>> package... and have the other three/four packages hang below that.
>>
>> pyobjc.obj
>> pyobjc.foundation
>> pyobjc.appkit
>> pyobjc.addressbook
>
> lowercase for appkit and foundation?

Follows Python standard?     Personally, I like Foundation and AppKit, 
as well -- of course, AppKit really should be Cocoa for OS X even 
though Cocoa is basically an empty framework...

>> ... etc ...
>>
>> This will make for much easier packaging in app wrappers [simplifies 
>> build targets] and much less clutter in site-packages.
>>
>> thoughts?
>
> FWIW, I am -0
>
> 1. The current flat nesting adds weight to the idea that Foundation 
> and AppKit are big frameworks in their own right

I still think they should be nested, just under a single roof....

> 2. This adds some text for every import (and there tend to be a lot in 
> pyobjc programs)

True.

> 3. Its not hard to package the modules in a subdirectory, using .pth 
> files in /usr/lib/site-packages and with minimal extra code in 
> bin-python-main.m. Hmm, and some extra code in bundlebuilder.py too, I 
> think. OTOH, extra code somewhere is still extra code, and putting 
> everything in a package doesn't require any extra code.

I'm not sure what this means....

> 4. If I see "Declared in: AppKit/NSMatrix.h" in Apple's docs, I write:
> "from AppKit import NSMatrix". One-to-one correspondence!

Which would change to:

     from pyobjc.AppKit import NSMatrix

Strictly speaking, this emphasizes that one is using the 'pyobjc' 
gateway into the 'AppKit' framework -- a more correct nomenclature 
because the pyobjc bridge changes the way the AppKit is accessed.

 > Just my 2 cents...

Thanks...

All in all, I'm not hugely attached to any of this.   I suppose my 
motivation is largely one of having to uninstall the module 
semi-regularly to ensure that standalone builds still work correctly.   
Not a very good reason to modify the dev environment, certainly.

b.bum

Re: [Pyobjc-dev] 0.9

[Tony L. <to...@lo...>]

Hi,

At 2:15 PM -0500 2/1/03, Bill Bumgarner wrote:
>As Just mentioned, it is about time to do a 0.9 release.

Out of curiosity, will 0.9 be FFI only?

>If we are going to do any major changes to the namespace, now is the time.
>
>I would like to see *everything* in pyobjc move into a 'pyobjc' 
>package... and have the other three/four packages hang below that.
>
>pyobjc.obj
>pyobjc.foundation
>pyobjc.appkit
>pyobjc.addressbook

lowercase for appkit and foundation?

>... etc ...
>
>This will make for much easier packaging in app wrappers [simplifies 
>build targets] and much less clutter in site-packages.
>
>thoughts?

FWIW, I am -0

1. The current flat nesting adds weight to the idea that Foundation 
and AppKit are big frameworks in their own right

2. This adds some text for every import (and there tend to be a lot 
in pyobjc programs)

3. Its not hard to package the modules in a subdirectory, using .pth 
files in /usr/lib/site-packages and with minimal extra code in 
bin-python-main.m. Hmm, and some extra code in bundlebuilder.py too, 
I think. OTOH, extra code somewhere is still extra code, and putting 
everything in a package doesn't require any extra code.

4. If I see "Declared in: AppKit/NSMatrix.h" in Apple's docs, I write:
"from AppKit import NSMatrix". One-to-one correspondence!

Just my 2 cents...

-Tony

Re: [Pyobjc-dev] Debugging PyObjc Apps

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

On Saturday, Feb 1, 2003, at 14:16 US/Eastern, Just van Rossum wrote:
> I don't think it currently gets much better than using print and
> catching exceptions from NSApplicationMain, but one thing I'd like to
> try at one point is to use the Python debugger from an PyObjC app.
> Perhaps one day we'll have a proper graphical debugger that can debug 
> an
> app from a different process.

I did confirm that the Wing IDE works with PyObjC correctly, including 
the debugger.

Obviously, there is a big issue with the way app startup happens.   The 
situation may improve with an embedded interpreter-- certainly makes it 
possible to use gdb directly-- but I'm not 100% sure.

b.bum

Re: [Pyobjc-dev] Debugging PyObjc Apps

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

Martina Oefelein wrote:

> How can one debug PyObjc Apps effectively?

For one, upgrade to the CVS version: it gives much better error messages
(ie. prints a traceback when your app dies).

> Currently I'm inserting print statements at various points. I'm sure 
> there must be a better way.

I don't think it currently gets much better than using print and
catching exceptions from NSApplicationMain, but one thing I'd like to
try at one point is to use the Python debugger from an PyObjC app.
Perhaps one day we'll have a proper graphical debugger that can debug an
app from a different process.

Just

[Pyobjc-dev] Error compiling latest CVS w/python 2.2

[Tony L. <to...@lo...>]

Hi,

The autoGIL.c module uses some python 2.3 macros. Here is a diff 
which lets it compile with python 2.2.

-Tony



tlownds@SilverSurfer:~/Compile/Py/objc/pyobjc% cvs diff Modules/autoGIL.c
Index: Modules/autoGIL.c
===================================================================
RCS file: /cvsroot/pyobjc/pyobjc/Modules/autoGIL.c,v
retrieving revision 1.1
diff -u -d -b -w -r1.1 autoGIL.c
--- Modules/autoGIL.c   31 Jan 2003 14:34:13 -0000      1.1
+++ Modules/autoGIL.c   1 Feb 2003 19:03:12 -0000
@@ -1,6 +1,14 @@
  #include "Python.h"
  #include <CoreFoundation/CFRunLoop.h>

+/* These macros are defined in Python 2.3 but not 2.2 */
+#ifndef PyMODINIT_FUNC
+#define PyMODINIT_FUNC void
+#endif
+#ifndef PyDoc_STRVAR
+#define PyDoc_STRVAR(Var,Str) static char Var[] = Str
+#endif
+

  static PyObject *AutoGILError;

[Pyobjc-dev] 0.9

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

As Just mentioned, it is about time to do a 0.9 release.

If we are going to do any major changes to the namespace, now is the 
time.

I would like to see *everything* in pyobjc move into a 'pyobjc' 
package... and have the other three/four packages hang below that.

pyobjc.obj
pyobjc.foundation
pyobjc.appkit
pyobjc.addressbook

... etc ...

This will make for much easier packaging in app wrappers [simplifies 
build targets] and much less clutter in site-packages.

thoughts?

b.bum

[Pyobjc-dev] [ pyobjc-Bugs-678759 ] Subclassing NSUndoManager fails

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

Bugs item #678759, was opened at 2003-02-01 11:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=678759&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Eppstein (eppstein)
Assigned to: Nobody/Anonymous (nobody)
Summary: Subclassing NSUndoManager fails

Initial Comment:
I attempted to create a python subclass of
NSUndoManager, and set it as my document's undoManager with
doc.setUndoManager_(MyUndoManager.alloc().init())

However, the new manager fails to work -- whenever I
try running
prepareWithInvocationTarget_(target).someMethod()
I get AttributeError: No selector someMethod

Changing MyUndoManager to NSUndoManager in the
setUndoManager_ call causes the AttributeError to go away.
My subclass is not shadowing
prepareWithInvocationTarget_ nor any related method of
NSUndoManager (I wanted merely to change the behavior
of the undo() and redo() calls).  Is
prepareWithInvocationTarget_ doing some magic that
needs to be propagated to subclasses?


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

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

[Pyobjc-dev] Debugging PyObjc Apps

[Martina O. <Ma...@Oe...>]

Hi All,

How can one debug PyObjc Apps effectively?

Currently I'm inserting print statements at various points. I'm sure 
there must be a better way.

ciao
Martina

Re: [Pyobjc-dev] Article on MacDevCenter

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

On Saturday, Feb 1, 2003, at 13:37 US/Eastern, Dinu Gherman wrote:
>> http://www.macdevcenter.com/pub/a/mac/2003/01/31/pyobjc_one.html
>
> Nice and a good move! All I have to "criticize" is that there is not
> quite enough of an emphasis on mutable vs. unmutable objects, both
> in Python and the Foundation framework (Tuples/Lists vs. NSArray/
> NSMutableArray, say) and the PyObjC bridging between them. Or is
> that no issue at all?

Definitely an issue -- but the bridge "handles" it in the same fashion  
that ObjC "handles" it:

 >>> a = NSArray.arrayWithArray_([1,2,3,4,5])
 >>> a
<NSCFArray objective-c instance 0x50290>
 >>> a[0] = 5
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File  
"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- 
packages/objc/_convenience.py", line 173, in <lambda>
     ('__setitem__', lambda self, index, anObject:  
self.replaceObjectAtIndex_withObject_(index, anObject)),
objc.error: NSInternalInconsistencyException - *** -[NSCFArray  
replaceObjectAtIndex:withObject:]: mutating method sent to immutable  
object

If you need a mutable array, you can create one in a couple of  
different ways:

 >>> a = a.mutableCopy()
 >>> a[0] = 5
 >>> from Foundation import Conversion
 >>> x = Conversion.pythonCollectionFromPropertyList(a)

Well, that last one *will* work after I fix a bug in the Conversion  
module. :-)

> I'm curious for the next parts! Any hints on when to expect them?

After 0.9...

The next article will discuss the construction of a trimmed down  
version of Web Services Tool -- WST without the dynamic toolbar,  
basically.

A good example as it nicely demonstrates how to build a multi-window  
style app [actually -- I *could* do it as a multi-doc app example] that  
leverages the incredible ease with which Python can communicate to  
XML-RPC servers.

b.bum

Re: [Pyobjc-dev] Sockets, Files, Fun

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

Hi Martina,

> I would like to try this out, but all I get is a bus error:
> 
> Python 2.2 (#1, 07/14/02, 23:25:09)
> [GCC Apple cpp-precomp 6.14] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> from TelnetInspect import TelnetServer
>  >>> server = TelnetServer(port=9090)
>  >>> from Foundation import NSRunLoop
>  >>> NSRunLoop.currentRunLoop().run()
> 
> Now, when I try to connect to this server in a second terminal window:
> [iBook:~] martina% telnet localhost 9090
> Trying ::1...
> telnet: connect to address ::1: Connection refused
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> In the first terminal window, python exits with:
> Bus error
> 
> I'm using PyObjc 0.8 on MacOS 10.2.3 with the Apple-supplied Python

Hm, I can't reproduce it with current CVS of PyObjC, neither with Python
2.2 nor CVS Python. A lot has changed since 0.8, and I think it's time
for a 0.9 release...

I _did_ manage to get a crash this way:

- start TelnetServer like you did
- open a telnet session (works)
- type cmd-. or ctl-C in the window running the server. This does
nothing (not surprisingly...)
- type return in the telnet window.
Boom goes the server process:

Thread 0 Crashed:
 #0   0x00034044 in PyObject_GetAttrString (object.c:1133)
 #1   0x004f91d8 in ObjCErr_ToObjC (objc_util.m:136)
 #2   0x004f91d8 in ObjCErr_ToObjC (objc_util.m:136)
 #3   0x004fde78 in ObjC_call_to_python (class-builder.m:1128)
 #4   0x0050ac84 in method_stub (libffi_support.m:250)
 #5   0x0050b7d8 in ffi_closure_helper_DARWIN (ffi_darwin.c:710)
 #6   0x0050bb48 in ffi_closure_ASM
 #7   0x907eaf7c in _nsNotificationCenterCallBack
 #8   0x90168580 in _postNotification
 #9   0x90165ca0 in _CFNotificationCenterPostLocalNotification
 #10  0x908b83ac in _performFileHandleSource
 #11  0x90149534 in __CFRunLoopDoSources0
 #12  0x90148918 in __CFRunLoopRun
 #13  0x90180fe4 in CFRunLoopRunSpecific
[ snippo ]

Just

Re: [Pyobjc-dev] Sockets, Files, Fun

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

On Saturday, Feb 1, 2003, at 13:25 US/Eastern, Martina Oefelein wrote:
> I'm using PyObjc 0.8 on MacOS 10.2.3 with the Apple-supplied Python

It will likely work fine if you were to build PyObjC from the source as 
it is found in CVS.   A lot of changes have been made since 0.8, 
including a tremendous number of new features.

b.bum

Re: [Pyobjc-dev] Article on MacDevCenter

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

> http://www.macdevcenter.com/pub/a/mac/2003/01/31/pyobjc_one.html

Nice and a good move! All I have to "criticize" is that there is not
quite enough of an emphasis on mutable vs. unmutable objects, both
in Python and the Foundation framework (Tuples/Lists vs. NSArray/
NSMutableArray, say) and the PyObjC bridging between them. Or is
that no issue at all?

I'm curious for the next parts! Any hints on when to expect them?

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"Women give to men the very gold of their lives. But they invariably
want it back in small change." (Oscar Wilde)

Re: [Pyobjc-dev] Sockets, Files, Fun

[Martina O. <Ma...@Oe...>]

Am Samstag, 01.02.03 um 19:25 Uhr schrieb Martina Oefelein:

> I would like to try this out, but all I get is a bus error:

Maybe the crash log is helpful:

Date/Time:  2003-02-01 19:14:33 +0100
OS Version: 10.2.3 (Build 6G30)
Host:       iBook.local.

Command:    python
PID:        2416

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000001

Thread 0 Crashed:
  #0   0x0046cb94 in execute_and_pythonify_objc_method 
(objc_support.m:1292)
  #1   0x00475904 in objcsel_call (selector.m:505)
  #2   0x00045930 in PyObject_Call
  #3   0x0005df64 in PyEval_GetFuncDesc
  #4   0x0005b32c in PyEval_EvalCode
  #5   0x0005c634 in PyEval_EvalCodeEx
  #6   0x0006d870 in PyFunction_SetClosure
  #7   0x00045930 in PyObject_Call
  #8   0x00476950 in pysel_call (selector.m:882)
  #9   0x00045930 in PyObject_Call
  #10  0x0005df64 in PyEval_GetFuncDesc
  #11  0x0005b32c in PyEval_EvalCode
  #12  0x0005c634 in PyEval_EvalCodeEx
  #13  0x0006d870 in PyFunction_SetClosure
  #14  0x00045930 in PyObject_Call
  #15  0x00056d74 in PyMethod_New
  #16  0x00045930 in PyObject_Call
  #17  0x0002073c in _PyObject_SlotCompare
  #18  0x000176a4 in _Py_ReleaseInternedStrings
  #19  0x00045930 in PyObject_Call
  #20  0x0005df64 in PyEval_GetFuncDesc
  #21  0x0005b32c in PyEval_EvalCode
  #22  0x0005c634 in PyEval_EvalCodeEx
  #23  0x0006d870 in PyFunction_SetClosure
  #24  0x00045930 in PyObject_Call
  #25  0x00476814 in pysel_call (selector.m:862)
  #26  0x00045930 in PyObject_Call
  #27  0x00470218 in ObjC_call_to_python (class-builder.m:1136)
  #28  0x004d8054 in meth_imp_208 (register.m:18306)
  #29  0x907eaf7c in _nsNotificationCenterCallBack
  #30  0x90168580 in _postNotification
  #31  0x90165ca0 in _CFNotificationCenterPostLocalNotification
  #32  0x908b83ac in _performFileHandleSource
  #33  0x90149534 in __CFRunLoopDoSources0
  #34  0x90148918 in __CFRunLoopRun
  #35  0x90180fe4 in CFRunLoopRunSpecific
  #36  0x907f5a0c in -[NSRunLoop runMode:beforeDate:]
  #37  0x90809244 in -[NSRunLoop run]
  #38  0x9068c258 in objc_msgSendv
  #39  0x907ed17c in -[NSInvocation invoke]
  #40  0x0046cda4 in execute_and_pythonify_objc_method 
(objc_support.m:1341)
  #41  0x00475904 in objcsel_call (selector.m:505)
  #42  0x00045930 in PyObject_Call
  #43  0x0005df64 in PyEval_GetFuncDesc
  #44  0x0005b32c in PyEval_EvalCode
  #45  0x0005c634 in PyEval_EvalCodeEx
  #46  0x00058a80 in PyEval_EvalCode
  #47  0x00027e90 in PyRun_FileExFlags
  #48  0x00026c70 in PyRun_InteractiveOneFlags
  #49  0x00026a58 in PyRun_InteractiveLoopFlags
  #50  0x000268f0 in PyRun_AnyFileExFlags
  #51  0x000069f0 in Py_Main
  #52  0x00002970 in start
  #53  0x000027f0 in start

Thread 1:
  #0   0x90000e2c in read
  #1   0x908b52cc in _backgroundActivity
  #2   0x90020d48 in _pthread_body

PPC Thread State:
   srr0: 0x0046cb94 srr1: 0x0000f030                vrsave: 0x00000000
    xer: 0x00000000   lr: 0x0046c958  ctr: 0x0046a22c   mq: 0x00000000
     r0: 0x00000072   r1: 0xbfffced0   r2: 0x28228244   r3: 0x00000004
     r4: 0x00000000   r5: 0x00000000   r6: 0xbfffceb0   r7: 0x00002546
     r8: 0x00734346   r9: 0x00000001  r10: 0x00000001  r11: 0xa00044b0
    r12: 0x9005e2d8  r13: 0x00000083  r14: 0x0099144c  r15: 0x00000000
    r16: 0x00000000  r17: 0x00000000  r18: 0x00000000  r19: 0x00991454
    r20: 0x0016459f  r21: 0x0010b7e0  r22: 0x00000002  r23: 0x00991300
    r24: 0x00000000  r25: 0x00000000  r26: 0x00000002  r27: 0x009b4a80
    r28: 0xbfffd514  r29: 0x00000000  r30: 0xbfffcef0  r31: 0x0046c2c8



ciao
Martina

Re: [Pyobjc-dev] Sockets, Files, Fun

[Martina O. <Ma...@Oe...>]

Hi Just,

Am Dienstag, 21.01.03 um 23:34 Uhr schrieb Just van Rossum:

> I've played around a bit with NSFileHandle for sockets and came up with
> a little demo that might actually be useful. It's called
> TelnetInspect.py (see enclosed), and allows you to run a simple telnet
> sever in your Cocoa app. Add this to your main program:

I would like to try this out, but all I get is a bus error:

Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from TelnetInspect import TelnetServer
 >>> server = TelnetServer(port=9090)
 >>> from Foundation import NSRunLoop
 >>> NSRunLoop.currentRunLoop().run()

Now, when I try to connect to this server in a second terminal window:
[iBook:~] martina% telnet localhost 9090
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

In the first terminal window, python exits with:
Bus error

I'm using PyObjc 0.8 on MacOS 10.2.3 with the Apple-supplied Python

Any idea?

ciao
Martina

[Pyobjc-dev] Article on MacDevCenter

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

http://www.macdevcenter.com/pub/a/mac/2003/01/31/pyobjc_one.html

:-)

b.bum

Re: [Pyobjc-dev] more on beginSheet

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

On Friday, Jan 31, 2003, at 01:09 Europe/Amsterdam, David Eppstein 
wrote:

> I worked around the missing selector by passing "missingSelector:" as 
> the argument.
> Since it shouldn't get called without a modalDelegate, that should be 
> ok as a workaround.
> Next question: why is the selector for the contextInfo: argument 'i'?  
> The objc spec is for this to be a (void *), but I am prevented from 
> passing None here (workaround: pass 0 instead).

We use an int argument instead of a (void*) argument on purpose. The 
only reasonably valid alternative would be to require a buffer-like 
object (or None for a NULL  pointer). Even then you would be required 
to store a reference to that buffer-like object somewhere, otherwise 
the buffer might be garbage collected before your callback is called.

When we first ran into this problem we did choose the current solution 
because this (a) makes it explicit that you must keep a reference to 
the data you want to use and (b) you cannot cause memory corruption by 
not following the rules (which might happen if we did expose 
contentInfo as a pointer).

Ronald

[Pyobjc-dev] [ pyobjc-Bugs-677963 ] beginSheet fifth arg type shouldn't be int

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

Bugs item #677963, was opened at 2003-01-30 20:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=677963&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Eppstein (eppstein)
Assigned to: Nobody/Anonymous (nobody)
Summary: beginSheet fifth arg type shouldn't be int

Initial Comment:
In
NSApplication.beginSheet_modalForWindow_modalDelegate_didEndSelector_contextInfo_,
the type for the final argument is specified as 'i'
(integer) even though the Cocoa docs list it as (void
*).  This setting prevents None being passed in this
position.  Easily worked around by passing 0 instead of
None, but could be a problem in case someone wants to
pass something nontrivial instead.


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

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