[Gsll-devel] gsll:+edom+ has no value

[Mirko Vukovic]

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 Healy<lhealy at 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 Vukovic<mirko.vukovic at 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 at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
>>
>>
>