HD> Which of stable/unstable do you recommend using? i think we'll eventually switch to "unstable", so if you're planning for the future, this would be a better option. also the more people use it, faster we will find all bugs in a new version. OTOH in a short term perspective "stable" is more tested.
HD> instrumenting it shows that when the problem occurs, the crippled HD> pm-btree is being recreated (not in cache). aha, thanks for finding this out -- it appears that recreation code in unstable is severely broken. i do not understand the idea behind these changes, i hope Ian can clarify this so we'll find a way to fix this. in old version recreate-instance-using class for standard-class objects was just called make-instance, so it went through the normal initialization procedure. in a new version it just calls allocate-instance, so pm-btree has absolutely no chance to initialize itself -- neither initialize-instance is called to fill slots with iniforms, nor shared-initialize is called, and we end up with a blank object. here's a piece of documentation: (defmethod recreate-instance-using-class ((class standard-class) &rest initargs &key &allow-other-keys) (declare (ignore initargs)) "Simply allocate store, the state of the slots will be filled by the data from the database. We do not want to call initialize-instance and re-evaluate the initforms; we are just fetching the object & values from the store" (allocate-instance class)) but i fail to understand the point -- how exactly are we "feching the object & values from the store" for standard-class classes? is that some new object serialization mechanism or just an error? _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
