[Bese-devel] Problems compiling 0.2.0 with CMUCL

[Jan Rychter]

[...]
 >> I've gotten past the problems with acl-compat on CMUCL (notably it
 >> having a strange way of loading gray-streams which fails and it
 >> redefining without-package-locks).

 Marco> i think rudi fixed that in a recent enough acl-compat, i seem to
 Marco> recall talking to him about that exact issue.

Seems it isn't fixed in the asdf-installable acl-compat that I use.

 >> I am now at a stage when yaclml and ucw compile and load fine.

 Marco> yippy! were there any specific changes you needed to make to
 Marco> yoclml or ucw? are there some hints i should put into the docs?

Well, I still get this:

  SWANK-BACKEND:SET-DEFAULT-DIRECTORY already names an ordinary function or a
  macro.  If you want to replace it with a generic function, you should remove
  the existing definition beforehand.

Otherwise, things look fine.

 >> ucw.mod-lisp also compiles fine, but when I try to load it, I get:
 >>
 >> Attempt to modify the locked package COMMON-LISP, by redefining
 >> function STREAM [Condition of type LISP::PACKAGE-LOCKED-ERROR]

 Marco> ok, this is a mistake. the class mod-lisp-message has a slot
 Marco> named stream (the stream connected to apache) with an accessor
 Marco> named stream. we don't use that accessor, so it could just as
 Marco> well be removed.

Ahem, actually, we do -- in make-mod-lisp-response. I've removed the
accessor and replaced this access with (slot-value).

 >> Attempting to continue unlocking the package (option [1]) results
 >> in:
 >>
 >>
 >> Execution of a form compiled with errors:

 Marco> this is, afaict, a cmucl odity. basically this is the same
 Marco> problem we had with the standard-whatever classes. the other
 Marco> thing to note is that when you get an "Execution of a form
 Marco> compiled with errors" it's the compiliation pass which has
 Marco> failed, you need to retry compiling that file to see what the
 Marco> real error is.

 Marco> Anyway, sometimes (i can't seem to understand when) CMUCL wants
 Marco> class definitions to be loaded before it can compile code which
 Marco> uses the accessor defined in the defclass form. In this
 Marco> particular case we have the method print-object which uses the
 Marco> raw-url accessor defined in a defclass in that same
 Marco> file. attempting to compile the file without loading it first
 Marco> gives this error. you have two (or three) options: 1) move the
 Marco> defclass form into an eval-when or another file, 2) use
 Marco> (slot-value object 'raw-url) as opposed to (raw-url object) and
 Marco> 3) talk to some people who know cmucl better than I and see
 Marco> whats really going on.

I've chosen option (2). I'd also like to understand why this happens
some day.

Hmm, trying to run UCW feels like walking a minefield. I hit one other
problem about CMUCL complaining about function "package" being
redefined. Seems this is because of the admin-repl component. Renaming
the "package" slot (and the accessor) to "ucw-package" fixed this
problem. And hey, I was ready to run the example! Lo and behold, it all
worked, and the example presented me with a nice login screen, where I
entered "admin/admin". And...  *** BOOM! ***

  [3289250968] Recursive request error #<TYPE-ERROR {580C2A3D}>.
  
  Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
     134249192 is not of type (UNSIGNED-BYTE 27)
     [Condition of type TYPE-ERROR]
  
  Restarts:
    0: [ABORT       ] Abort this request
    1: [RETRY       ] Retry rendering ucw/admin/admin-repl.tal.
    2:                Retry rendering the component.
    3:                Retry rendering ucw/tabbed-pane.tal.
    4:                Retry rendering the component.
    5:                Retry rendering ucw/admin/server-admin-interface.tal.
    6:                Retry rendering the component.
    7:                Clearout the response and retry calling the action.
    8: [SERVER-ERROR] Send the client an internal server error page.
    9: [DESTROY     ] Destroy the process
  
  Debug  (type H for help)
  
  (DEBUG::DEBUG-LOOP)
  Source: 
  ; File: target:code/debug.lisp
  (DEBUG-INTERNALS:TOP-FRAME)
  0] 8

Ok, 8 seems like a good choice. But...

  [3289251043] Reaping dead sessions.
  
  ; [GC threshold exceeded with 49,911,368 bytes in use.  Commencing GC.]
  ; [GC completed with 48,886,432 bytes retained and 1,024,936 bytes freed.]
  ; [GC will next occur when at least 60,886,432 bytes are in use.]
  ; [GC threshold exceeded with 60,894,696 bytes in use.  Commencing GC.]
  ; [GC completed with 60,894,704 bytes retained and -8 bytes freed.]
  ; [GC will next occur when at least 72,894,704 bytes are in use.]
  ; [GC threshold exceeded with 72,904,568 bytes in use.  Commencing GC.]
  ; [GC completed with 72,906,440 bytes retained and -1,872 bytes freed.]
  ; [GC will next occur when at least 84,906,440 bytes are in use.]
  ; [GC threshold exceeded with 84,920,416 bytes in use.  Commencing GC.]
  ; [GC completed with 81,347,584 bytes retained and 3,572,832 bytes freed.]
  ; [GC will next occur when at least 93,347,584 bytes are in use.]
  ; [GC threshold exceeded with 93,356,768 bytes in use.  Commencing GC.]
  ; [GC completed with 93,358,640 bytes retained and -1,872 bytes freed.]
  ; [GC will next occur when at least 105,358,640 bytes are in use.]
  ; [GC threshold exceeded with 105,372,680 bytes in use.  Commencing GC.]
  ; [GC completed with 105,372,688 bytes retained and -8 bytes freed.]
  ; [GC will next occur when at least 117,372,688 bytes are in use.]
  ; [GC threshold exceeded with 117,382,592 bytes in use.  Commencing GC.]
  ; [GC completed with 117,384,464 bytes retained and -1,872 bytes freed.]
  ; [GC will next occur when at least 129,384,464 bytes are in use.]
  ; [GC threshold exceeded with 129,398,496 bytes in use.  Commencing GC.]
  ; [GC completed with 129,395,232 bytes retained and 3,264 bytes freed.]
  ; [GC will next occur when at least 141,395,232 bytes are in use.]
  ; [GC threshold exceeded with 141,405,024 bytes in use.  Commencing GC.]
  ; [GC completed with 141,406,896 bytes retained and -1,872 bytes freed.]
  ; [GC will next occur when at least 153,406,896 bytes are in use.]
  ; [GC threshold exceeded with 153,420,992 bytes in use.  Commencing GC.]
  ; [GC completed with 153,421,040 bytes retained and -48 bytes freed.]
  ; [GC will next occur when at least 165,421,040 bytes are in use.]
  ; [GC threshold exceeded with 165,430,976 bytes in use.  Commencing GC.]
  [...snipped...]
  ; [GC completed with 463,511,624 bytes retained and -80 bytes freed.]
  ; [GC will next occur when at least 475,511,624 bytes are in use.]
  ; [GC threshold exceeded with 475,521,480 bytes in use.  Commencing GC.]
  ; [GC completed with 475,523,352 bytes retained and -1,872 bytes freed.]
  ; [GC will next occur when at least 487,523,352 bytes are in use.]
  ; [GC threshold exceeded with 487,537,384 bytes in use.  Commencing GC.]

  Process inferior-lisp terminated

This is when I finally managed to kill the lisp process after a lengthy
swap session.

I'm scared now. GC showing negative numbers of bytes freed?

For the reference, this is CMUCL snapshot 2003-12, mod-lisp 2.33.

thanks,
--J.