summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--JOURNAL103
-rw-r--r--Objective-C/libobjcl.m40
2 files changed, 128 insertions, 15 deletions
diff --git a/JOURNAL b/JOURNAL
index 882571c..fa4b72d 100644
--- a/JOURNAL
+++ b/JOURNAL
@@ -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]);