pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Testsuite adventures

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

On Friday, May 16, 2003, at 11:44 Europe/Amsterdam, Dinu Gherman wrote:

> Hi,
>
> I'm investigating a little bit the shape of the testsuite and
> find it to be in a slightly undesirable state. I assume this is
> because there is no global testing module which you could easily
> run to execute all test modules anywhere in the source tree. So
> I've written one such module, allTestsTogether.py, which gives
> interesting results (please change the name to something like
> alltests.py):
>
> [localhost:~/Desktop/pyobjc] dinu% python allTestsTogether.py
> ..E....EEE.E..EEEEEE....EEE.E..EEEEE.........................
> ...............E..E..EEEEE..E................................
> .2003-05-16 09:41:08.155 python[6095] *** -[NSBitmapImageRep
> init]: selector not recognized................EBus error

The changes I checked in earlier this week seem to fix most problems 
your seeing, there are 2 errors left related to the reuse of a class 
name (which the ObjC runtime doesn't support). The bus error is not 
fixed (yet).

> After this investigation I'd like to know more about what the
> PyObjC testing policy is? Maybe a topic for some part of the
> documentation?

We try to cover as much functionality as possible with unittests. We 
are getting closer and closer to that goal, but we are not there yet.

I regulary run the unittests using the runalltests script. I also try 
to remember to add a unittest whenever I fix bugs, but I often forget 
to do that.

Ronald

Re: [Pyobjc-dev] Testsuite adventures

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

On Friday, May 16, 2003, at 12:40 Europe/Amsterdam, Dinu Gherman wrote:
>
>> Some of the tests use the AppKit frameworks, while some others
>> will fail if you have loaded the AppKit framework.
>
> Why's that?
I'm pretty sure we have a test that loads AppKit during the test to 
check if the AppKit categories on NSAttributedString appear when you do 
so. If we do not have such a test it should be added.

However, this could and should probably done using one or two C 
extensions (e.g. define our own category on NSObject, check that those 
methods are not available, load the extension module and check that the 
methods are now available).

Ronald

Re: [Pyobjc-dev] Just's PythonBrowser and NSOutlineView

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

Dinu Gherman wrote:

> Hi, this is mainly for Just, but perhaps also of interest for others.
> I'm fiddling again with NSOutlineViews and while running my version
> of PythonBrowser (unchanged for 0.9) - unfortunately it doesn't seem
> to have a version label - I find it to show some abnormal behaviour
> on 0.9 (haven't rechecked on 0.8, but remember it worked fine there).
> 
> Basically, it comes up ok with a filled outline view, but as soon
> as you unfold an item or resize the window all entries become some-
> thing like this: <root> | dict | {'AutoBaseClass': <...>, ...}
> 
> Has anybody noticed problems with outline views in PyObjC 0.9?

Hm, dunno, things seem to work fine here upon brief inspection. However,
I can't guarantee you're looking at the same version as I... I attached
my version so you can check.

Just

[Pyobjc-dev] Just's PythonBrowser and NSOutlineView

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

Hi, this is mainly for Just, but perhaps also of interest for others.
I'm fiddling again with NSOutlineViews and while running my version
of PythonBrowser (unchanged for 0.9) - unfortunately it doesn't seem
to have a version label - I find it to show some abnormal behaviour
on 0.9 (haven't rechecked on 0.8, but remember it worked fine there).

Basically, it comes up ok with a filled outline view, but as soon
as you unfold an item or resize the window all entries become some-
thing like this: <root> | dict | {'AutoBaseClass': <...>, ...}

Has anybody noticed problems with outline views in PyObjC 0.9?

Thanks,

Dinu

--
Dinu C. Gherman
......................................................................
"The only way to get rid of a temptation is to yield to it."
(Oscar Wilde)

[Pyobjc-dev] Unstable code in CVS

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

I've just checked in a major update to the implementation of 
subclasses. This means the CVS HEAD will be less stable for a while.

We now store all state for instances in the Objective-C instance, 
previously some state was stored in a Python object. This simplifies 
the code of the bridge (especially conceptually).

There is one known bug with this code: __del__ doesn't work as 
expected. Use __pyobjcdel__ if you want to play with this version of 
the bridge.

Ronald

Re: [Pyobjc-dev] Testsuite adventures

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

Ronald Oussoren:

> We use 'Scripts/runalltests'.

I see some of these scripts have no .py extension so they escaped
my attention... Is there any reason for not having such an exten-
sion?

> This starts every test module in a fresh interpreter. This makes
> it a lot easier to add tests.

Test methods and modules can be easily added anytime, I think. Or
what exactly do you mean? Also, the way runalltests works makes
it very hard if not impossible to be reused by GUI test runners.

> Some of the tests use the AppKit frameworks, while some others
> will fail if you have loaded the AppKit framework.

Why's that?

Dinu

--
Dinu C. Gherman
......................................................................
"Of course America had often been discovered before Columbus,
but it had always been hushed up." (Oscar Wilde)

Re: [Pyobjc-dev] Testsuite adventures

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

On Friday, May 16, 2003, at 11:44 Europe/Amsterdam, Dinu Gherman wrote:

> Hi,
>
> I'm investigating a little bit the shape of the testsuite and
> find it to be in a slightly undesirable state. I assume this is
> because there is no global testing module which you could easily
> run to execute all test modules anywhere in the source tree.

We use 'Scripts/runalltests'. This starts every test module in a fresh 
interpreter. This makes it a lot easier to add tests. Some of the tests 
use the AppKit frameworks, while some others will fail if you have 
loaded the AppKit framework.

That said, even if you run all tests from 1 interpreter session you 
shouldn't give you bus errors.

Ronald

[Pyobjc-dev] Testsuite adventures

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

Hi,

I'm investigating a little bit the shape of the testsuite and
find it to be in a slightly undesirable state. I assume this is
because there is no global testing module which you could easily
run to execute all test modules anywhere in the source tree. So
I've written one such module, allTestsTogether.py, which gives
interesting results (please change the name to something like
alltests.py):

[localhost:~/Desktop/pyobjc] dinu% python allTestsTogether.py
..E....EEE.E..EEEEEE....EEE.E..EEEEE.........................
...............E..E..EEEEE..E................................
.2003-05-16 09:41:08.155 python[6095] *** -[NSBitmapImageRep
init]: selector not recognized................EBus error

It then halts instead of giving a detailed list of failures and
errors. Further inspection reveils that two modules are really
bad performers:

   Lib/objc/test/test_methods.py  (28 errors, seg. fault)
   Lib/objc/test/test_ivar.py     (bus error)

This is too much for unittest to recover from... Taking them out
gives you the following list of only four errors left (slightly
compressed):

[localhost:~/Desktop/pyobjc] dinu% python allTestsTogether.py
..2003-05-16 10:01:34.426 python[6124] *** -[NSBitmapImageRep init]:
selector not recognized................E..........E.................
.....................E...........E...
======================================================================
ERROR: testPythonSourcedMethods 
(test_methodedits.TestFromPythonClassToObjCClass)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "test_methodedits.py", line 92, in testPythonSourcedMethods
TypeError: All objects in methodArray must be of type <objc.selector>.
======================================================================
ERROR: test_mixSliceNDice (test_nsarray.TestNSArrayInteraction)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "test_nsarray.py", line 132, in test_mixSliceNDice
TypeError: must assign list (not "NSCFArray") to slice
======================================================================
ERROR: testPosing (test_posing.TestPosing)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "test_posing.py", line 9, in testPosing
error: Class already exists in Objective-C runtime
======================================================================
ERROR: testSubclassOfSubclass (test_subclass.TestSubclassing)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "test_subclass.py", line 9, in testSubclassOfSubclass
error: Class already exists in Objective-C runtime
----------------------------------------------------------------------
Ran 84 tests in 4.471s
FAILED (errors=4)

I'm attaching my umbrella test module for others to check. Just
putting it in your local PyObjC root folder and executing it
from anywhere on the command line should work as expected.

After this investigation I'd like to know more about what the
PyObjC testing policy is? Maybe a topic for some part of the
documentation?

Regards,

Dinu

[Pyobjc-dev] PyObjC CVS RSS Newsflash available

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

Hi!

For whatever it's worth for the people on this list... This is an
hourly updated RSS newsflash of the latest PyObjC CVS changes and
contains links to the PyObjC ViewCVS on SF:

   http://me.in-berlin.de/~darwin/cvspyobjcsf.rdf

You can use it on OS X with tools like SlashDock:

   http://homepage.mac.com/stas/slashdock.html

Regards,

Dinu

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

Re: [Pyobjc-dev] Re: Subclassing NSCell?

[Mitch C. <mit...@ea...>]

On Thursday, May 15, 2003, at 01:58  AM, Just van Rossum wrote:

> Mitch Chapman wrote:
>
>> I'm not sure where to go from here.  Any suggestions?
>
> Me neither, but it would be great if you could post a minimal app that
> exhibits the problem.

A bug report with attached PB project is here:

http://sourceforge.net/tracker/ 
index.php?func=detail&aid=738252&group_id=14534&atid=114534

--
Mitch

[Pyobjc-dev] [ pyobjc-Bugs-738252 ] Crash on override of NSCell.drawInteriorWithFrame_inView_

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

Bugs item #738252, was opened at 2003-05-15 08:25
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=738252&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mitch Chapman (mitchchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash on override of NSCell.drawInteriorWithFrame_inView_

Initial Comment:
Using Python 2.3b1 with PyObjC 0.9, if I define a subclass of
NSCell, override drawInteriorWithFrame_inView_, and assign
an instance of that cell as the dataCell (via setDataCell_) of
an NSTableColumn, a SEGV occurs on the next attempt to
render a data cell in that column.

The attached, gzipped tarball contains a Cocoa-Python application
which demonstrates the problem.  If you comment out
the definition of drawInteriorWithFrame_inView_ in the
CrashCell class in MyAppDelegate.py, build and run, and
click the Crash button, the app should run successfully.
If you uncomment the definition, the app should crash when you
click the Crash button.

(Note:  bin-python-main.m has been modified to use
/usr/local/bin/python rather than /usr/bin/python.)


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

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

[Pyobjc-dev] [ pyobjc-Bugs-738168 ] Simpifying testsuite code

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

Bugs item #738168, was opened at 2003-05-15 10:49
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=738168&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: Simpifying testsuite code

Initial Comment:
All functions named suite() in all test_*.py modules can be safely 
deleted whenever there are two lines like this at the end of each test 
module (which is always the case):

if __name__ == '__main__':
    unittest.main()

The Pycotine Unittest GUI v. 0.3, also in PyObjC, runs the resulting 
suite as expected (except for some issues inside the test code, which 
also cause problems on the commandline).


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

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

[Pyobjc-dev] [ pyobjc-Bugs-738151 ] methods of NSObject subclasses don't take keyword arguments

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

Bugs item #738151, was opened at 2003-05-15 11:40
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=738151&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: methods of NSObject subclasses don't take keyword arguments

Initial Comment:
>>> from Foundation import *
>>> class Foo(NSObject):
...   def foo(self, anArg):
...     pass
... 
>>> f = Foo.alloc().init()
>>> f.foo(1)
>>> f.foo(anArg=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: foo() takes exactly 2 arguments (1 given)
>>>


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

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

Re: [Pyobjc-dev] Re: Subclassing NSCell?

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

Mitch Chapman wrote:

> I'm not sure where to go from here.  Any suggestions?

Me neither, but it would be great if you could post a minimal app that
exhibits the problem.

Just

[Pyobjc-dev] Pycotine 0.3 available!

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

Hi,

I've updated Pycotine to 0.3 to run on PyObjc 0.8 and 0.9. The most
important new feature compared to 0.2 is that it will now find top-
level unittest.TestCase subclasses of a Python file and test those
if no suite() or makeSuite() function returning a testsuite is found.
You can get it here:

   http://python.net/~gherman/#pycotine

Please let me know if you have any trouble with it! Note, that the
PyObjC 0.9 testsuite causes some strange behaviour which I'm going
to address in a subsequent message.

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"Les jours de notre vie passent comme les nuages, fais donc le bien
tant que tu es vivant." (Hazrat Ali)

Re: [Pyobjc-dev] Re: Subclassing NSCell?

[Mitch C. <mit...@ea...>]

On Wednesday, May 14, 2003, at 12:55  PM, Ronald Oussoren wrote:
> I usually look for the right process-id from the shell and then start 
> 'gdb /usr/local/bin/pyton THEPID' (THEPID being the process-id).
>
> Are you using the Project Builder templates? These use /usr/bin/python 
> unless you change the bin-python-main.m file.

Well, thanks to the in-line documentation y'all wrote in 
bin-python-main.m,
I wasn't having trouble figuring out which python executable to target 
with gdb,
or which process ID to attach to.  My problem turned out to be that I 
wasn't  setting
DYLD_FRAMEWORK_PATH properly,  so gdb couldn't load the Python dynamic 
library.

With DYLD_FRAMEWORK_PATH set to refer to the system frameworks 
directory,
like so:
	DYLD_FRAMEWORK_PATH=/Library/Frameworks
gdb was happy again.


Now I'm stuck trying to learn why [methinfo getArgumentTypeAtIndex:i] 
(libffi_support.m,
line 323) would return an invalid value for i == 3, when 
methinfo->_nargs == 4.

It seems to be extracting a bogus id for the second argument to
drawInteriorWithFrame_inView_, which is supposed to be the control view 
into
which the NSCell subclass draws.

The signature in methinfo matches that generated for my
drawInteriorWithFrame_inView_ method, to wit:

NSMethodSignature: types=v@:{_NSRect={_NSPoint=ff}{_NSSize=ff}}@ 
nargs=4 sizeOfParams=160 returnValueLength=0;

or, as gdb puts it:
(gdb) print *methinfo
$14 = {
   isa = 0xa07ed538,
   _types = 0x46ec60 "v@:{_NSRect={_NSPoint=ff}{_NSSize=ff}}@\000"...,
   _nargs = 4,
   _sizeofParams = 160,
   _returnValueLength = 0,
   _parmInfoP = 0x46ec10,
   _fixup = 0x0,
   _reserved = 0x0
}

The code is failing on the retobject assignment in the following code 
fragment
(near line 673 in pythonify_c_value, in Modules/objc/objc_support.m).
obj has the "out of bounds" value 0x3f800000, so I guess the problem
starts before the attempt to invoke __pyobjc_PythonObject__:

	case _C_ID:
	{
		id obj = *(id *) datum;

		if (obj == nil) {
			retobject = Py_None;
			Py_INCREF (retobject);
		} else {
			retobject = [obj  __pyobjc_PythonObject__];


I'm not sure where to go from here.  Any suggestions?
--
Mitch

Re: [Pyobjc-dev] Re: Subclassing NSCell?

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

On Wednesday, May 14, 2003, at 16:29 Europe/Amsterdam, Mitch Chapman 
wrote:

> On Monday, May 12, 2003, at 11:35  PM, Mitch Chapman wrote:
>
>> I can create instances of the subclass, defined roughly as
>>
>> from AppKit import *
>> class MyCell(NSCell):
>> 	...
>>
>> and can install these instances as data cells for NSTableColumns in 
>> an NSTableView.
>> All cool.  But if I try to override drawInteriorWithFrame_inView_, as 
>> follows,
>> I get a segmentation fault on the first attempt to draw cell 
>> contents.  What's more,
>> I don't get the output from the print statement.
>
> I should probably be asking this elsewhere, but:
> Can anyone summarize how to use gdb to debug a Python2.3b1 application?
> In this case I've set SHOWPID and  tried to attach to the running 
> Python process, but
> gdb encounters errors during startup.  It turns out that it does this 
> even if I just try to
> debug the Python interpreter, without attaching to any running 
> processes.
> (See below.)

I usually look for the right process-id from the shell and then start 
'gdb /usr/local/bin/pyton THEPID' (THEPID being the process-id).

Are you using the Project Builder templates? These use /usr/bin/python 
unless you change the bin-python-main.m file.

Ronald

[Pyobjc-dev] [ pyobjc-Bugs-737729 ] proxy objects have a __dict__

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

Bugs item #737729, was opened at 2003-05-14 18:10
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=737729&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: proxy objects have a __dict__

Initial Comment:
Proxies for plain objective-C objects have an __dict__.
This is not the intended behavious, the proxy should
not add new functionality.

Example:

import objc
o = objc.runtime.NSObject.new()
o.foobar = 3

print o.foobar

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

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

[Pyobjc-dev] Re: Subclassing NSCell?

[Mitch C. <mit...@ea...>]

On Monday, May 12, 2003, at 11:35  PM, Mitch Chapman wrote:

> I can create instances of the subclass, defined roughly as
>
> from AppKit import *
> class MyCell(NSCell):
> 	...
>
> and can install these instances as data cells for NSTableColumns in an 
> NSTableView.
> All cool.  But if I try to override drawInteriorWithFrame_inView_, as 
> follows,
> I get a segmentation fault on the first attempt to draw cell contents. 
>  What's more,
> I don't get the output from the print statement.

I should probably be asking this elsewhere, but:
Can anyone summarize how to use gdb to debug a Python2.3b1 application?
In this case I've set SHOWPID and  tried to attach to the running 
Python process, but
gdb encounters errors during startup.  It turns out that it does this 
even if I just try to
debug the Python interpreter, without attaching to any running 
processes.
(See below.)

I get the same output even after setting DYLD_FRAMEWORK_PATH et al to 
match
the settings used by bin-python-main:

----
gdb /Library/Frameworks/Python.framework/Versions/2.3/bin/python
GNU gdb 5.3-20021014 (Apple version gdb-250) (Sat Dec  7 02:14:27 GMT 
2002)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and 
you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
This GDB was configured as "powerpc-apple-macos10".
unable to open symbol file: /Users/mitchchapman/lib/Python: No such 
file or directory.

warning: Unable to read symbols from 
"Python.framework/Versions/2.3/Python"; reading from memory.
/SourceCache/gdb/gdb-250/src/gdb/macosx/macosx-nat-dyld-process.c:505: 
internal-error: assertion failure in function "dyld_load_library": 
e->dyld_valid

A problem internal to GDB has been detected.  Further
debugging may prove unreliable.
Quit this debugging session? (y or n)
----



Meanwhile, Console.app has this to say about the original problem, a 
SEGFAULT
when invoking drawInteriorWithFrame_inView_ on a Python-based subclass
of NSCell:

----
Date/Time:  2003-05-14 07:52:40 -0600
OS Version: 10.2.6 (Build 6L60)
Host:       CallMeLuxo.local.

Command:    python
PID:        19097

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x3f800000

Thread 0 Crashed:
  #0   0x9068ba4c in objc_msgSend
  #1   0x0021b228 in pythonify_c_value (objc_support.m:672)
  #2   0x00229530 in method_stub (libffi_support.m:351)
  #3   0x0022a1f4 in ffi_closure_helper_DARWIN (ffi_darwin.c:712)
  #4   0x0022a568 in ffi_closure_ASM
  #5   0x930a0758 in -[NSTableView drawRow:clipRect:]
[...]
----

Thanks again for any clues.

--
Mitch

Re: [Pyobjc-dev] Pycotine issues on pyobjc 0.9

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

Just van Rossum:

> 0.9 mostly handles release/retain automatically so I would look for
> retains in your code. Ok, I had a look, and indeed: try to remove
> task.release(). It probably causes a crash when the task variable goes
> out of scope, when it is released _again_...

Oops - indeed! Thanks,

Dinu

--
Dinu C. Gherman
......................................................................
"It's clearly a budget. It's got a lot of numbers in it."
(George W. Bush, 5 May 2000)

Re: [Pyobjc-dev] Pycotine issues on pyobjc 0.9

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

Dinu Gherman wrote:

> Hi,
> 
> after finding that the existing pyobjc testsuite could be slightly
> improved (by deleting code) I've run some tests with Pycotine, my
> Unittest-GUI which sort of worked as expected on pyobjc 0.8.
> 
> Unfortunately, it does mysteriously crash on 0.9 after finishing the
> tests. I just reinstalled 0.8 and there it does work, again. On 0.9
> I get this error "Pycotine has exited due to signal 11 (SIGSEGV)."
> 
> All I had to change from 0.8 to 0.9 is to make use of PyObjCTools
> like this (before NibClassBuilder was in AppKit):
> 
>    from PyObjCTools.NibClassBuilder import AutoBaseClass
>    from PyObjCTools import NibClassBuilder
> 
> Any ideas?

0.9 mostly handles release/retain automatically so I would look for
retains in your code. Ok, I had a look, and indeed: try to remove
task.release(). It probably causes a crash when the task variable goes
out of scope, when it is released _again_...

Just

Re: [Pyobjc-dev] Pycotine issues on pyobjc 0.9

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

Dinu Gherman:

> Unfortunately, it does mysteriously crash on 0.9 after finishing the
> tests. I just reinstalled 0.8 and there it does work, again. On 0.9
> I get this error "Pycotine has exited due to signal 11 (SIGSEGV)."

I should have added that this behaviour is independant of the tests
being performed. Particularly, it has nothing to do with running the
tests in pyobjc 0.8 or 0.9...

Dinu

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

[Pyobjc-dev] Pycotine issues on pyobjc 0.9

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

Hi,

after finding that the existing pyobjc testsuite could be slightly
improved (by deleting code) I've run some tests with Pycotine, my
Unittest-GUI which sort of worked as expected on pyobjc 0.8.

Unfortunately, it does mysteriously crash on 0.9 after finishing the
tests. I just reinstalled 0.8 and there it does work, again. On 0.9
I get this error "Pycotine has exited due to signal 11 (SIGSEGV)."

All I had to change from 0.8 to 0.9 is to make use of PyObjCTools
like this (before NibClassBuilder was in AppKit):

   from PyObjCTools.NibClassBuilder import AutoBaseClass
   from PyObjCTools import NibClassBuilder

Any ideas?

Thanks/regards,

Dinu

PS: You can find Pycotine here:
     http://python.net/~gherman/#Pycotine

--
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] Feedback needed for documentation

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

On Tuesday, May 13, 2003, at 10:04 Europe/Amsterdam, Dinu Gherman wrote:

> I wrote:
>
>> Ronald Oussoren:
>>
>>> The most important target for a 1.0 release is providing good 
>>> documentation. To get things going I'd like to hear about problems 
>>> with our current documentation, and hopefully also some suggestions 
>>> on how to improve on it.
>>>
>>> Another important point I'd like to get feedback on is what new 
>>> users of PyObjC find hard when starting to use it, that might give 
>>> us pointers on how to improve the bridge itself as well as find 
>>> items that should be mentioned the introduction to PyObjC. Please 
>>> mention if you are/were new to Python and/or Cocoa.
>>
>> Before starting giving feedback: isn't (wasn't) there a Wiki
>> to collect such pieces?
>
> Sorry to be so insisting... Is there such a Wiki or not?
> I don't think a mailing list is appropriate to really work
> on some text.

Sorry about not responding to your orginal messages. There was one at 
http://www.devoesquared.com/pyobjc-moin.cgi?, but that is probably gone 
as we never really used it.

Ronald

Re: [Pyobjc-dev] Feedback needed for documentation

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

On Tuesday, May 13, 2003, at 07:30 AM, Dinu Gherman wrote:

> Zachery Bir:
>
>> It's a blank ZWiki Web. It's open for all to edit. I've given 
>> everyone the ability to create and edit wiki pages, add documents and 
>> images (patches, etc), and subscribe to wiki pages.
>
> Great - thanks! For the paranoids among us: could you also make
> a daily archive and upload it somewhere, perhaps? Maybe, SF would
> be a natural place, but I don't know if that works smoothly.

Sure, that should be doable. It will most likely be a Zope Export file 
(.zexp).

Zac