[elephant-devel] Re: more allegro edits to avoid compiler warnings

[Robert L. Read]

Thank you, Andrew.

This seems very relevant to a problem that Waldo Rubinstein is trying to
solve under OpenMCL.

The following code breaks on OpenMCL at the first accessor try:

(asdf:operate 'asdf:load-op :elephant)
(asdf:operate 'asdf:load-op :ele-bdb)
(asdf:operate 'asdf:load-op :elephant-tests)
(in-package "ELEPHANT-TESTS")

(open-store *testdb-path*)



      (defclass update-class () 
((slot1 :initform 1 :accessor slot1))
(:metaclass persistent-metaclass))
(setq *auto-commit* t)
(setq foo (make-instance 'update-class :sc *store-controller*))
(slot1 foo)
(defclass update-class ()
  ((slot2 :initform 2 :accessor slot2))
  (:metaclass persistent-metaclass))
(slot2 foo)
(slot1 foo)


Waldo, execute the above code under OpenMCL.
It should fail on the last statement, but I suspect it will fail on
(slot2 foo).
Send me the transcript.

I wonder if what that does under ACL?  I will attempt to run the code
you sent me today under SBCL.

It is clear that there are some implementation-specific differences that
are tripping us up on these 
features (which, after all, are very advanced; one cannot contemplate
dynamically changing a class
definition under Java!)  

On Tue, 2006-01-10 at 15:15 -0800, Andrew Philpot wrote:

> I wrote:
> 
>   Finally, I think things are working enough to prototype making my
>   knowledge base persistent.  Yet, I still get lots of segmentation
>   faults and seeming configuration level errors such as "The slot SLOT1
>   is missing from the object #<PFOO @ #x720bb22a> of class
>   #<PERSISTENT-METACLASS PFOO> during operation SETF."  I'm mostly
>   unclear as to why code which works inside a RT:DEFTEST doesn't always
>   work at top level, or in my client code.  I seem to do a lot of
>   deleting the database, stopping lisp, rebuilding elephant, and trying
>   my example again.  I fear I'm corrupting either the BDB store, the
>   local Lisp connection to it, and/or CLOS with my missteps.  Symptoms
>   are things like [sic]
> 
> I left out the symptoms before.  Sorry.
> 
> I've since gone further, and so I have a sample case that I would like
> to show you.  I would be interested in whether this happens on other
> platforms as well.  Again, if it comes down a question of why doesn't
> YYY work on ACL as it does on SBCL et al, I can submit to Franz.
> 
> Essentially, I have found that reDEFCLASSing persistent classes tends
> to stir things up in a way that slots are no longer visible after the
> redefinition.  Mostly by accident, I also found that explicitly
> calling CLOS::FINALIZE-INHERITANCE after the redefinition and before
> any use of the class usually does the right thing.
> 
> See the attached code and transcript, abstracted from my real
> application.  If you set the variable user::*EAGERLY-FINALIZE* to
> non-NIL, then at COMPILE/LOAD/EVAL it will try to finalize the
> definition (if such already exists).  I'm trying to be
> hyperconservative about when to define things, so that's why it does
> OPEN-STORE/CLOSE-STORE so globally before tinkering with the
> definitions.
> 
> #Andrew
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20060114/a3ecd47e/attachment.html>