Liam,
My reading of hyperspec is that defconstant is evaluated as a top-level form. Thus the need to use the `eval-when'
I generated the following example code. I had to add `eval-when's to make it work: (eval-when (:compile-toplevel :load-toplevel :execute) (defconstant +names+ '(one two three)))
#.(cons 'progn (eval-when (:compile-toplevel :load-toplevel :execute) (loop for i from 0 to (length +names+) for name = (nth i +names+) collect `(defconstant ,(intern (format nil "+~:@(~a~)+" name)) ,i))))
(format t "value of one is ~a~%" +one+) ;; this one tests that we can access +one+'s value
However, when I made a similar modification in conditions.lisp: #.(cons 'progn (eval-when (:compile-toplevel :load-toplevel :execute) (loop for i from (cffi:foreign-enum-value 'gsl-errorno :continue) to (cffi:foreign-enum-value 'gsl-errorno :eof) for name = (string (cffi:foreign-enum-keyword 'gsl-errorno i)) collect `(defconstant ,(intern (format nil "+~:@(~a~)+" name) :gsll) ,i))))
I still got the message that +edom+ has no value. Maybe you can see something that I am missing.
I will ask on the clisp mailing list, but I want to ask something meaningful.
On Mon, Jun 15, 2009 at 12:13 AM, Liam Healylhealy@common-lisp.net wrote:
This shows up in the Debian version of CLISP, 2.44.1 as well. It appears to be a bug in CLISP. If I replace the first form in conditions.lisp (which creates the defconstants) with the literal defconstants, it still gets this error. I think that a defconstant must be useable immediately after it is defined, even in the same file.
If you are on the CLISP mailing list, can you post a question there and confirm this?
Liam
On Fri, Jun 12, 2009 at 8:49 PM, Mirko Vukovicmirko.vukovic@gmail.com wrote:
Hello,
on loading a fresh gsll (no fasl, lib, exe) on clisp+cygwin+windows, I get:
#<ADDRESS #x44C9D500>: variable GSLL::+EDOM+ has no value [Condition of type SYSTEM::SIMPLE-UNBOUND-VARIABLE]
Restarts: 0: [USE-VALUE] You may input a value to be used instead of GSLL::+EDOM+. 1: [STORE-VALUE] You may input a new value for GSLL::+EDOM+. 2: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL #x1018B8A1> on #<ASDF:CL-SOURCE-FILE "conditions" #x10465C61>. 3: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL #x1018B8A1> on #<ASDF:CL-SOURCE-FILE "conditions" #x10465C61> as having been successful. 4: [ABORT] Return to SLIME's top level. 5: [ABORT] Abort --more--
The call stack seems to originate in the `define-gsl-condition' (see attached file)
Any ideas?
Thanks,
Mirko
PS BTW, I had to teach cffi-grovel how to access gcc under cygwin. I posted a message to cffi-grovel, so hopefully you will not need to do anything on the gsll side
Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel