[Gbbopen-list] Dimensional values error - GBBopen 0.9.7 with CLISP 2.43

[Dan Corkill]

> I'm a new GBBopen user. I'm going through the tutorial.  At §7. Adding
> dimensions, I got an error when asking to describe the unit instance
> with dimensional values.
> I was using GBBopen 0.9.7 with CLISP 2.43 and SLIME 2.0 on Windows XP.

Eric,

Thanks for your report.  It appears that the problem is specific to
running GBBopen on CLISP (replicated on both 2.43 and 2.44 on a Linux
platform).  The problem is associated with how CLISP is behaving when
redefining a unit-class (compiling and loading in the same image session).

> I managed to fix the problem by using GBBopen 0.9.6 with CLISP 2.43 and
> SLIME 2.0.

I'm surprised that using GBBopen 0.9.6 made a difference.  I've been
able to replicate the problem with 0.9.6 as well.

We're looking into what exactly is going on when running CLISP.  The
following "tutorial-example.lisp" test file illustrates the issue:

;;; ----------------------------------------------------

(in-package :gbbopen-user)

(define-unit-class location ()
  (x
   y
   (next-location
    :link (location previous-location :singular t)
    :singular t)
   (previous-location
    :link (location next-location :singular t)
    :singular t))
  (:dimensional-values
   (x :point x)
   (y :point y)))

(define-unit-class bad ()
  (x y)
  (:dimensional-values
   (x :point x)
   (y :point y)))

(defun show ()
  (printv "LOCATION")
  (print (gbbopen::standard-unit-class.effective-dimensional-values
          (find-class 'location)))
  (printv "BAD")
  (print (gbbopen::standard-unit-class.effective-dimensional-values
          (find-class 'bad)))
  (values))

;;; ----------------------------------------------------

If, after loading the :gbbopen-user module, the following expressions
are evaluated:

> (load (compile-file "tutorial-example.lisp"))
> (show)

something similar to the following is printed:

> ;; LOCATION
> 
> ((x :point #<compiled-function #:|3 14 (define-unit-class location nil ...)-2-2|> nil nil)
>  (y :point #<compiled-function #:|3 14 (define-unit-class location nil ...)-2-1|> nil nil)) 
> ;; BAD
> 
> ((x :point #:f20532 nil nil) (y :point #:f20533 nil nil)) 

Note that the uninterned symbols #:f20532 and #:f20533 for unit-class
bad have not been fixed-up by GBBopen.  Removing either of the link-slot
definitions from the location unit-class definition will make it "BAD"
(!?!).

If, however, a fresh CLISP is started, the :gbbopen-user module is
loaded, and the previously compiled *.fas file is loaded:

> (load "tutorial-example")
> (show)

then show indicates that all is correct (and the *.fas file is the same
one as above):

> ;; LOCATION
> 
> ((x :point #<compiled-function #:|3 14 (define-unit-class location nil ...)-2-2|> nil nil)
>  (y :point #<compiled-function #:|3 14 (define-unit-class location nil ...)-2-1|> nil nil)) 
> ;; BAD
> 
> ((x :point #<compiled-function #:|16 20 (define-unit-class bad nil ...)-3-2|> nil nil)
>  (y :point #<compiled-function #:|16 20 (define-unit-class bad nil ...)-3-1|> nil nil)) 

We're looking into this change in *.fas loading behavior (based on
whether or not the file was compiled in the same image) under CLISP.
Stay tuned.

For now, assume that once you move a bit further along into the
Tutorial, behavior on CLISP will be correct (for reasons that remain to
be understood...)

Thanks again for the report.





-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.