summaryrefslogtreecommitdiff
path: root/JOURNAL
diff options
context:
space:
mode:
Diffstat (limited to 'JOURNAL')
-rw-r--r--JOURNAL103
1 files changed, 102 insertions, 1 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.