Thread: [Pyobjc-dev] GNUstep.
Brought to you by:
ronaldoussoren
Menu
▾
▴
pyobjc-dev
|
From: Mirko V. <mi...@ob...> - 2003-01-04 09:43:14
|
Ciao! I'm trying to get pyobjc working on gnustep... I don't know the pyobjc internals yet but should it be possible to rename objc_error to something else ? extern void objc_error(id object, int code, const char* fmt, ...); extern void objc_verror(id object, int code, const char* fmt, va_list ap); building 'objc._objc' extension cc -DNDEBUG -O2 -s -pipe -D_THREAD_SAFE -fPIC -I/usr/local/include/python2.2 -c Modules/objc/objc_util.m -o build/temp.freebsd-4.7-PRERELEASE-i386-2.2/objc_util.o -DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DGNU_RUNTIME -Wno-import -I/usr/local/GNUstep/System/Headers -I/usr/local/GNUstep/System/Headers/gnustep -I/usr/local/GNUstep/System/Headers/ix86/freebsd Modules/objc/objc_util.m:12: `objc_error' redeclared as different kind of symbol /usr/local/GNUstep/System/Headers/objc/objc-api.h:100: previous declaration of `objc_error' Modules/objc/objc_util.m: In function `ObjC_UpdateConvenienceMethods': Modules/objc/objc_util.m:301: warning: comparison of distinct pointer types lacks a cast error: command 'cc' failed with exit status 1 -- Ciao Mirko |
|
From: Lele G. <le...@se...> - 2003-01-04 11:30:17
|
>>>>> On Sat, 4 Jan 2003 09:42:55 -0000, "Mirko Viviani" <mi...@ob...> said:
MV> Ciao! I'm trying to get pyobjc working on gnustep... I don't
MV> know the pyobjc internals yet but should it be possible to
MV> rename objc_error to something else ?
Ciao Mirko! Nice to know this. I'm going to spend some time on it
too, but I'm afraid not very soon. Anyway, please, let's keep in
touch&sync on this!
ciao&grazie,
lele.
--
nickname: Lele Gaifax | Quando vivro' di quello che ho pensato ieri
real: Emanuele Gaifas | comincero' ad aver paura di chi mi copia.
email: le...@se... | -- Fortunato Depero, 1929.
|
|
From: Ronald O. <ous...@ci...> - 2003-01-04 12:43:36
|
On Saturday, Jan 4, 2003, at 10:42 Europe/Amsterdam, Mirko Viviani wrote: > Ciao! > > I'm trying to get pyobjc working on gnustep... I don't know the pyobjc > internals > yet but should it be possible to rename objc_error to something else ? Sure, especially given the name-clash your having. I've renamed objc_error to ObjCExc_error. Ronald |
|
From: Jack J. <Jac...@or...> - 2003-01-04 16:12:47
|
On zaterdag, jan 4, 2003, at 13:42 Europe/Amsterdam, Ronald Oussoren wrote: > > On Saturday, Jan 4, 2003, at 10:42 Europe/Amsterdam, Mirko Viviani > wrote: > >> Ciao! >> >> I'm trying to get pyobjc working on gnustep... I don't know the >> pyobjc internals >> yet but should it be possible to rename objc_error to something else ? > Sure, especially given the name-clash your having. I've renamed > objc_error to ObjCExc_error. Why not make all externally visible symbols (at the C level, I'm not talking about Python here) start with "pyobjc_" or some such? -- - 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 - |
|
From: Ronald O. <ous...@ci...> - 2003-01-04 17:53:49
|
On Saturday, Jan 4, 2003, at 17:12 Europe/Amsterdam, Jack Jansen wrote: > > On zaterdag, jan 4, 2003, at 13:42 Europe/Amsterdam, Ronald Oussoren > wrote: > >> >> On Saturday, Jan 4, 2003, at 10:42 Europe/Amsterdam, Mirko Viviani >> wrote: >> >>> Ciao! >>> >>> I'm trying to get pyobjc working on gnustep... I don't know the >>> pyobjc internals >>> yet but should it be possible to rename objc_error to something else >>> ? >> Sure, especially given the name-clash your having. I've renamed >> objc_error to ObjCExc_error. > > Why not make all externally visible symbols (at the C level, I'm not > talking about Python here) start with "pyobjc_" or some such? We currently use 'OC_' as the prefix on Objective-C class names (such as OC_PythonArray) and ObjC as the prefix on most newer C code (objc_error was one of the exceptions). Older code uses no prefix or 'objc_' as the prefix. I agree that it would be wise to use a prefix on all externally visible symbols. We could use either 'OC', 'ObjC' or 'PyObjC', with mixed case identifiers. Now that I've put some more thought in it I think that PyObjC would be the best choice because it is highly unlike that anyone else uses this prefix. I initialy choose ObjC because it was already in use (ObjCPointer is a surviving example of this) and because the 'Py' prefix is claimed by Python. Summary of my proposal: Use the same naming scheme as the Python core, but using 'PyObjC' instead of 'Py' (see also PEP 7 at http://www.python.org/peps/pep-0007.html) I'll write a coding style document for PyObjC that mentions this. If everyone agrees we can then rename all externally visible symbols, preferably only once. Ronald |
|
From: Mirko V. <mi...@ob...> - 2003-01-04 17:51:43
|
Ronald Oussoren <ous...@ci...> ha scritto: > Sure, especially given the name-clash your having. I've renamed > objc_error to ObjCExc_error. Ok, thanks. I've modified some things in class-builder.m (see attach) but as you can see the source loose readability. How to proceed ? I think we can use a rename Method and IVar to something different and use a typedef for gnu/next. I've implemented a couple of missing runtime function in objc_support.m but how to do with the one with different names ? (ie class_get_instance_method/class_getInstanceMethod) Use the GNU_RUNTIME switch or a function wrapper ? -- Ciao Mirko |
|
From: Ronald O. <ous...@ci...> - 2003-01-04 18:19:42
|
On Saturday, Jan 4, 2003, at 18:51 Europe/Amsterdam, Mirko Viviani wrote: > Ronald Oussoren <ous...@ci...> ha scritto: > >> Sure, especially given the name-clash your having. I've renamed >> objc_error to ObjCExc_error. > > Ok, thanks. > > I've modified some things in class-builder.m (see attach) but as you > can see > the source loose readability. > > How to proceed ? Lot's of ifdefs is not the right solution. The code in class-builder.m should use the definitions from objc_support.h instead of the native Apple/NexStep definitions. Hopefully this mechanism solves most of your problems. BTW. I noticed GNUstep has a build-option for using a garbage-collector. Using that option might cause problems with subclassing Objective-C classes from Python, the current code depends on reference-counts in both Python and Objective-C to detect if objects are alive. Ronald |
|
From: Mirko V. <mi...@ob...> - 2003-01-05 13:29:28
|
Ronald Oussoren <ous...@ci...> ha scritto: > > How to proceed ? > Lot's of ifdefs is not the right solution. The code in class-builder.m > should use the definitions from objc_support.h instead of the native > Apple/NexStep definitions. Hopefully this mechanism solves most of your > problems. Ok, I've modified all the code to use objc_support. There are yet some GNU_RUNTIME/GNUSTEP but it is much much better now. The runtime support, apart for bugs and missing objc_addClass() implementation, should be quit ok, but unfortunately it dumps core: (gdb) r Starting program: /usr/local/bin/python dictionary.py (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x805471b in PyObject_Print () (gdb) where #0 0x805471b in PyObject_Print () #1 0x80a4dce in PyFile_WriteObject () #2 0x8070230 in PyEval_EvalCode () #3 0x807246c in PyEval_EvalCodeEx () #4 0x806ee79 in PyEval_EvalCode () #5 0x8089117 in PyRun_FileExFlags () #6 0x80890d2 in PyRun_FileExFlags () #7 0x80890a6 in PyRun_FileExFlags () #8 0x8088438 in PyRun_SimpleFileExFlags () #9 0x8087f54 in PyRun_AnyFileExFlags () #10 0x8052c59 in Py_Main () #11 0x8052570 in main () #12 0x80524cb in _start () It prints correctly the class returned by objc.lookUpClass() but it hangs when it try to print the object. Any hints where should I start looking ? Thanks. > BTW. I noticed GNUstep has a build-option for using a > garbage-collector. Using that option might cause problems with > subclassing Objective-C classes from Python, the current code depends > on reference-counts in both Python and Objective-C to detect if objects > are alive. I know, but I've never used it and it seems to remember that is a bit untested. -- Ciao Mirko |
|
From: Ronald O. <ous...@ci...> - 2003-01-05 14:13:37
|
On Sunday, Jan 5, 2003, at 14:28 Europe/Amsterdam, Mirko Viviani wrote: > Ronald Oussoren <ous...@ci...> ha scritto: > >>> How to proceed ? >> Lot's of ifdefs is not the right solution. The code in class-builder.m >> should use the definitions from objc_support.h instead of the native >> Apple/NexStep definitions. Hopefully this mechanism solves most of >> your >> problems. > > Ok, I've modified all the code to use objc_support. There are yet some > GNU_RUNTIME/GNUSTEP but it is much much better now. > > The runtime support, apart for bugs and missing objc_addClass() > implementation, > should be quit ok, but unfortunately it dumps core: You might want to rebuild python with debugging enabled (or at least building with '-g'), that makes debugging a lot easier. The stacktrace doesn't mention PyObjC code, which of course doesn't help in finding the problem :-(. You may want to add lots of print statements to dictionary.py, to check how far into the script python is crashing. This script doesn't use python subclassing, which rules out problems in class-builder.m. Ronald |
|
From: Mirko V. <mi...@ob...> - 2003-01-05 17:17:42
|
Ronald Oussoren <ous...@ci...> ha scritto:
> > The runtime support, apart for bugs and missing objc_addClass()
> > implementation,
> > should be quit ok, but unfortunately it dumps core:
> You might want to rebuild python with debugging enabled (or at least
> building with '-g'), that makes debugging a lot easier.
PyObjc was already compiled with -g else I become mad ! :-)
> The stacktrace doesn't mention PyObjC code, which of course doesn't
> help in finding the problem :-(.
I've fixed and now it works.
I've done a couple of test using lookUpClass() with success but when I run
the tests it fails to lookup the classes:
[mirko@rey] /usr/home/mirko/src/gnustep/pyobjc> Scripts/runalltests
-- Running 'Lib/Foundation/test/test_nsarray.py'
EEEEEEEEE
======================================================================
ERROR: testContains (__main__.TestNSArrayInteraction)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib/Foundation/test/test_nsarray.py", line 19, in testContains
x = NSArray.arrayWithArray_( ["foo", "bar", "baz"] )
NameError: global name 'NSArray' is not defined
======================================================================
ERROR: testIn (__main__.TestNSArrayInteraction)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib/Foundation/test/test_nsarray.py", line 30, in testIn
x = NSMutableArray.array()
NameError: global name 'NSMutableArray' is not defined
How to check ?
Thanks.
--
Ciao
Mirko
|
|
From: Ronald O. <ous...@ci...> - 2003-01-05 17:45:18
|
On Sunday, Jan 5, 2003, at 18:17 Europe/Amsterdam, Mirko Viviani wrote: > Ronald Oussoren <ous...@ci...> ha scritto: > >>> The runtime support, apart for bugs and missing objc_addClass() >>> implementation, >>> should be quit ok, but unfortunately it dumps core: >> You might want to rebuild python with debugging enabled (or at least >> building with '-g'), that makes debugging a lot easier. > > PyObjc was already compiled with -g else I become mad ! :-) > >> The stacktrace doesn't mention PyObjC code, which of course doesn't >> help in finding the problem :-(. > > I've fixed and now it works. > > I've done a couple of test using lookUpClass() with success but when I > run > the tests it fails to lookup the classes: > > [mirko@rey] /usr/home/mirko/src/gnustep/pyobjc> Scripts/runalltests > -- Running 'Lib/Foundation/test/test_nsarray.py' > EEEEEEEEE > ====================================================================== > ERROR: testContains (__main__.TestNSArrayInteraction) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "Lib/Foundation/test/test_nsarray.py", line 19, in testContains > x = NSArray.arrayWithArray_( ["foo", "bar", "baz"] ) > NameError: global name 'NSArray' is not defined > This is probably a problem in Modules/objc/class-list.m:ObjC_GetClassList. As the comment above the GNUstep version indicates that the GNUstep is mostly a placeholder. Ronald |
|
From: Mirko V. <mi...@ob...> - 2003-01-05 20:25:28
|
Ronald Oussoren <ous...@ci...> ha scritto: > This is probably a problem in > Modules/objc/class-list.m:ObjC_GetClassList. As the comment above the > GNUstep version indicates that the GNUstep is mostly a placeholder. In fact, PyList does not work so I have replaced it with PyTuple. In attach there is the patch against the current cvs that works with GNUstep. 'Works' is a big word since there are dumps with some tests yet, but simple things work great ! -- Ciao Mirko |
|
From: Mirko V. <mi...@ob...> - 2003-01-05 20:37:43
|
Mirko Viviani <mi...@ob...> ha scritto: Unfortunately I left hardcored path in setup.py Here the new one. -- Ciao Mirko |
|
From: Ronald O. <ous...@ci...> - 2003-01-05 20:55:37
|
On Sunday, Jan 5, 2003, at 21:25 Europe/Amsterdam, Mirko Viviani wrote: > In attach there is the patch against the current cvs that works with > GNUstep. > 'Works' is a big word since there are dumps with some tests yet, but > simple > things work great ! Thanks. I haven't checked the entire patch yet, but I expect that most of it will turn up in the repository later this week. Some remarks based on a first glance at your patch: * Could you please sent context-diffs in the future (diff -C) that makes it easier to grasp just what is changed. * You changed a number of generated files in Modules/Cocoa (the .inc files). These files are generated using cocoa_generator.py in Modules/Cocoa/scripts. Could you check if that script is useable with GNUstep? Ronald |
|
From: Ronald O. <ous...@ci...> - 2003-01-06 22:03:46
|
I've applied the entire patch, which some changed (minor changes in Modules/objc, larger ones in Modules/Cocoa). Ronald |
|
From: Mirko V. <mi...@ob...> - 2003-01-07 17:14:29
|
Ronald Oussoren <ous...@ci...> ha scritto: > I've applied the entire patch, which some changed (minor changes in > Modules/objc, larger ones in Modules/Cocoa). Ok, I've tested a bit and it seems to work. Pathes for subclassing and Cocoa/scripts will follow. -- Ciao Mirko |
|
From: <bb...@ma...> - 2003-01-05 21:36:48
|
Wow! I'm really happy to see that the GNUstep effort has such
momentum. Very cool! I'm going to add a news item to that effect
shortly.
I'm thinking that it might be wise to start a pyobjc-dev-gnustep
mailing list as the GNUstep effort is going to generate a lot of
traffic that is highly specific in nature. It would give people new
to the project an easy way to scan the archives to find relevant notes
regarding the state of GNUstep compatibility.
Also-- for those working on GNUstep, there are a couple (maybe only one
now?) of places where the PyObjC module does something like the
following (found in objc/__init__.py):
try:
import _FoundationMapping
del _FoundationMapping
except ImportError:
pass
As the port progresses, it is likely that an import error will occur in
this context that is indicative of a real problem.
b.bum
|
|
From: Ronald O. <ous...@ci...> - 2003-01-06 06:58:35
|
On Sunday, Jan 5, 2003, at 19:19 Europe/Amsterdam, bb...@ma... wrote: > Wow! I'm really happy to see that the GNUstep effort has such > momentum. Very cool! I'm going to add a news item to that effect > shortly. > > I'm thinking that it might be wise to start a pyobjc-dev-gnustep > mailing list as the GNUstep effort is going to generate a lot of > traffic that is highly specific in nature. It would give people new > to the project an easy way to scan the archives to find relevant notes > regarding the state of GNUstep compatibility. I don't think this is worth the effort. Porting to GNUstep is likely to generate a lot of specific traffic, but only for a short time. After that people on GNUstep will have the same questions as those on MacOS. BTW. Is there anyone that is still using NeXTstep and is interested in using PyObjC? Porting to NeXTstep shouldn't be too much of an effort ;-) ;-) > > Also-- for those working on GNUstep, there are a couple (maybe only > one now?) of places where the PyObjC module does something like the > following (found in objc/__init__.py): > > try: > import _FoundationMapping > del _FoundationMapping > except ImportError: > pass We might as wel remove the try:except: block. I had what I thought was a good reason for doing it this way, but I forgot was it is. > > As the port progresses, it is likely that an import error will occur > in this context that is indicative of a real problem. It is also likely that there is a real problem when this occurs on MacOS X. Ronald |
|
From: Jack J. <Jac...@cw...> - 2003-01-06 12:15:38
|
In case anyone is looking for a real project to do with PyObjC: have a look at ImgSeek, <http://imgseek.sourceforge.net>. This is a Python program that searches an image database based on a sketch you make of the sort of image you're looking for. I haven't inspected the code, but from the screen shots and the readme it looks really impressive. And if you think of something like this with a Cocoa interface I think you have something that would communicate the power of Python the Apple-people and the power of Cocoa to Python-people (aside from being pretty darn useful:-). -- 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X