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