diff options
| -rw-r--r-- | JOURNAL | 103 | ||||
| -rw-r--r-- | Objective-C/libobjcl.m | 40 |
2 files changed, 128 insertions, 15 deletions
@@ -1,5 +1,106 @@ -*- mode: muse -*- +* 2008-02-24, 22:39:03 CET + +** PCL Problems + +Collecting all Objective-C classes and creating CLOS classes out of +them, which is what the only recently introduced function +COLLECT-CLASSES does, works reliably both on Allegro CL and on GNU +CLISP. There are some serious problems on CMUCL and SBCL, though. + +First, some stats (this is on Wirselkraut, my Dell Inspiron 6400). + + +*** CLISP 2.44 + +OBJCL[3]> (time (collect-classes)) +Real time: 14.182854 sec. +Run time: 14.180886 sec. +Space: 189717640 Bytes +GC: 123, GC time: 2.412143 sec. +0 + + +*** Allegro CL 8.1 + +OBJCL(3): (time (collect-classes)) +; cpu time (non-gc) 2,660 msec user, 10 msec system +; cpu time (gc) 620 msec user, 0 msec system +; cpu time (total) 3,280 msec user, 10 msec system +; real time 3,291 msec +; space allocation: +; 1,816,989 cons cells, 44,365,376 other bytes, 72,082 static bytes +0 + +Note that Allegro CL defers class finalisation until the first instance +of a class is created. Then again, half the classes created are +metaclasses which are immediately instantiated, so the speed is +impressive, either way. + + +*** SBCL 1.0.14.debian + +\* (time (collect-classes)) +STYLE-WARNING: + slot names with the same SYMBOL-NAME but different SYMBOL-PACKAGE (possible + package problem) for class + #<OBJECTIVE-C-META-CLASS NS:++NS-OBJECT {B75E4440}>: + (SB-PCL::NAME NS:NAME) +STYLE-WARNING: + slot names with the same SYMBOL-NAME but different SYMBOL-PACKAGE (possible + package problem) for class #<NS:++NS-OBJECT NS:+NS-OBJECT {B75E4440}>: + (SB-PCL::NAME NS:NAME) +STYLE-WARNING: + slot names with the same SYMBOL-NAME but different SYMBOL-PACKAGE (possible + package problem) for class + #<NS:+NS-OBJECT NS:+GSXMLP-LIST-PARSER {B75ED3E0}>: + (SB-PCL::NAME NS:NAME) + +That's how it starts off. The STYLE-WARNINGs go on and on. At first, +they rush by fast, but each new class seems to take more time than the +previous one to create. I'm not going to wait for it to complete in +order to tell you the TIME stats because it could well take decades... + + +*** CMUCL CVS 19d 19d-release (19D) + +\* (time (collect-classes)) +; Compiling LAMBDA NIL: +; Compiling Top-Level Form: + +Type-error in KERNEL::INVALID-ARRAY-INDEX-ERROR-HANDLER: + 4 is not of type (INTEGER 0 (0)) + [Condition of type TYPE-ERROR] + +Restarts: + 0: [ABORT ] Return to Top-Level. + 1: [DESTROY] Destroy the process + +Debug (type H for help) + +(MAPHASH #<Closure Over Function "DEFUN MAKE-ACCESSOR-TABLE" {5974DC09}> + #<HASH-TABLE :TEST EQ :WEAK-P NIL :COUNT 65 {2824FEBD}>) +Source: +; File: target:code/hash-new.lisp +(AREF KV-VECTOR (* 2 I)) +0] + +I don't have the slightest idea what that could mean. A bug in CMUCL's +hash table code? + + +*** LispWorks Personal 5.0.1 + +Not timed yet. Will do that someday. + + +*** So, What Is To Be Done? + +I'll have to ask some CMUCL and SBCL gurus what's going on in their +respective variations of PCL. + + * 2008-02-03, 10:45:58 CET ** To be compatible or not to be compatible? @@ -14,7 +115,7 @@ Then again, if someone wants to compare Objective-CL with Clozure CL's bridge side-by-side, it's their responsibility to rename packages as needed. Reader macros aren't essential for using Objective-CL, so they may be left disabled in such a case, anyway. I'm going to try hard to -use Objective-CL-specific package names within my code +use Objective-CL-specific package names within my own code (i.e. OBJECTIVE-C-CLASSES rather than NS), so renaming packages won't break things. diff --git a/Objective-C/libobjcl.m b/Objective-C/libobjcl.m index 997553e..36fb811 100644 --- a/Objective-C/libobjcl.m +++ b/Objective-C/libobjcl.m @@ -26,6 +26,7 @@ #ifdef GNUSTEP #import "GNUstepBase/GSLock.h" +#import "GNUstepBase/GSConfig.h" /* #import "GNUstepBase/GSObjCRuntime.h" */ #endif @@ -86,24 +87,31 @@ objcl_memmove (void *dest, void *src, unsigned long length) void objcl_initialise_runtime (void) { -#ifndef __NEXT_RUNTIME__ - if (!process) - { - static char *argv[] = { "" }; - static char *env[] = { (char *) 0 }; - [NSProcessInfo initializeWithArguments: argv - count: 0 - environment: env]; - process = [NSProcessInfo processInfo]; - } -#endif - TRACE (@"Check whether initialisation is pending."); if (init_count <= 0) { TRACE (@"Initialise runtime."); - TRACE (@"Allocate exceptions."); objcl_autorelease_pool = [[NSAutoreleasePool alloc] init]; + +#ifndef __NEXT_RUNTIME__ +#if defined(GS_FAKE_MAIN) || defined(GS_PASS_ARGUMENTS) \ + || defined(LIB_FOUNDATION_LIBRARY) + + TRACE (@"Initialise environment."); + if (!process) + { + static char *argv[] = { "objective-cl", 0 }; + /* static char *environ[] = { (char *) 0 }; */ + extern char **environ; + [NSProcessInfo initializeWithArguments: argv + count: 1 + environment: environ]; + process = [NSProcessInfo processInfo]; + } +#endif +#endif + + TRACE (@"Allocate exceptions."); objcl_oom_exception = [NSException exceptionWithName: @"MLKOutOfMemoryException" reason: @"Out of memory" userInfo: nil]; @@ -372,6 +380,10 @@ objcl_get_method_implementation (id object, TRACE (@"method-impl %p %p", object, selector); #ifdef __NEXT_RUNTIME__ Class target_class; + /* struct objc_super super_struct; + super_struct.receiver = object; + super_struct.super_class = superclass_for_send_super; + */ if (objcl_object_is_class (object)) { @@ -967,7 +979,7 @@ objcl_for_each_class_do (void (*function) (Class)) int i; Class class_list[class_num]; - objc_getClassList (&class_list, class_num); + objc_getClassList (class_list, class_num); for (i = 0; i < class_num; i++) { function (class_list[i]); |