From: WoodHacker
Subject: SBCL Error
Date: 
Message-ID: <1144673865.382863.58660@t31g2000cwb.googlegroups.com>
I had a major meltdown of my system when I lost my harddrive.   I
rebuilt everything using Gentoo linux and am back in business - except
that now the code that used to compile perfectly no longer compiles a
second time.   I am getting the following errror when I try to
RECOMPILE my code.   (It compiles correctly the first time and only
gives me this error if I make a change in the code and rerun REQUIRE in
the REPL)

* (require :vl)

debugger invoked on a TYPE-ERROR: The value NIL is not of type REAL.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(MAX NIL)
0]

This happens even if I take all the code away except for a list of
parameters!!!
Any ideas what has gone wrong?

From: Christophe Rhodes
Subject: Re: SBCL Error
Date: 
Message-ID: <sqveth37in.fsf@cam.ac.uk>
"WoodHacker" <········@verizon.net> writes:

> (MAX NIL)
> 0]
>
> Any ideas what has gone wrong?

If you take a backtrace, you might find out more.  The debugger allows
you to inspect the current execution stack, examine local variables,
find the source location for the current function, perform arbitrary
computations, and generally poke around the running system; you might
find it productive to learn to use it.  (Learning one debugger helps
significantly in interacting with others, too, so you'll gain
transferrable skills.)

At a guess, though, this is essentially due to some brokenness in your
Gentoo/common-lisp-controller system whereby the association between
source and fasl file is lost, so that when asdf asks the filesystem
whether the fasl is newer than the source, it fails to find one or
other file, so probe-file or file-write-date returns nil.  (There's
probably a bug in asdf lurking there as well; ideally it shouldn't let
distributors or users shoot themselves in the foot like this.)

Christophe
From: WoodHacker
Subject: Re: SBCL Error
Date: 
Message-ID: <1144674933.085225.152090@z34g2000cwc.googlegroups.com>
It never fails.   The minute I send off the message, I have a
revelation.   (and I also always forget to add a key piece of info....)

This code uses CLX.   At the end of my asd file I have a line
:depends-on ("clx").   By removing that and requireing CLX on it's own,
the problem goes away.

Now the question is, why did this work before and why doesn't it work
now?
From: Troels Henriksen
Subject: Re: SBCL Error
Date: 
Message-ID: <87d5fpwn6v.fsf@sigkill.dk>
"WoodHacker" <········@verizon.net> writes:

> Now the question is, why did this work before and why doesn't it work
> now?

I use Gentoo as well and suffer under the same problem (interestingly,
only with the ASDF in SBCL, standalone ASDF with CMUCL is
unaffected). I solve it by redefining asdf::operation-done-p in my
initialization file:

(in-package #:asdf)

(defmethod operation-done-p ((o operation) (c component))
  (let ((out-files (output-files o c))
	(in-files (input-files o c)))
    (cond ((and (not in-files) (not out-files))
	   ;; arbitrary decision: an operation that uses nothing to
	   ;; produce nothing probably isn't doing much 
	   t)
	  ((not out-files) 
	   (let ((op-done
		  (gethash (type-of o)
			   (component-operation-times c))))
	     (and op-done
		  (>= op-done
		      (or  0)))))
	  ((not in-files) nil)
	  (t
	   (and
	    (every #'probe-file out-files)
	    (> (apply #'min (mapcar #'file-write-date out-files))
	       (apply #'max (mapcar #'(lambda (file)
                                        ;; If no file-write-date can
                                        ;; be found, assume 0. This is
                                        ;; a hacky fix.
                                        (or (file-write-date file)
                                            0))
                                    in-files))))))))

I have not yet discovered any problems with this approach, although it
is quite unelegant.

-- 
\  Troels "Athas" Henriksen
/\ - Insert witty signature
From: WoodHacker
Subject: Re: SBCL Error
Date: 
Message-ID: <1144701244.517098.153690@i40g2000cwc.googlegroups.com>
Thanks....

That, indeed, solves the problem.   Do the folks at SBCL know about
this?

Bill
From: Tchavdar Roussanov
Subject: Re: SBCL Error
Date: 
Message-ID: <1144678178.444557.215670@i39g2000cwa.googlegroups.com>
I have the same problem with loading cxml. I found out that the latest
version of sbcl does not handle correctly asdf file components that
have :pathname parameter. Here is a snippet from cxml.asd:

....
     (:file runes
            :pathname
             #-rune-is-character "runes"
             #+rune-is-character "characters"
	    :depends-on ("package" dependent))
...
With sbcl  the reader uses the line with #+rune-is-character. On the
first compile/load it works fine and creates character.fasl but on the
next load it searches for runes.fasl.

Tchavdar