the problem was actually quite easy -- pm-btree needs to initialize it's transient each time it's created or deserialized. it participates both as descendant from "persistent" as pm-btree itself, and as persistent-object in form of pm-indexed-btree.
(so pm-btree is quite a good test for a new system) as we've found out, now initialization of transient slots should be done in shared-initialize :after (it's funny, nobody have replied directly to my concrete question, but it was mentioned in some 'proposals'). unfortunately original implementation of recreate-instance-using-class deprives "persistent" from any kind of initialization, including shared-initialize. i believe it's a bug and recreate-instance-using-class either should call normal make-instance for everything except persistent-object. or, at least, it should call shared-initialize. (again, this was in my original question but nobody addressed this issues directly. is my English that poor so nobody understand me??). so, fix consists of two parts: 1. `persistent' gets normal initialization via make-instance (i've already posted code), so pm-btree has chance to initialize itself; 2. initialize-instance :after of pm-btree is changed to shared-initialize so it will work for pm-indexed-btree which is persistent-object. does this make sense according to original design? if it does, i'll send a patch. if part 1 is against the spirit of this recreate thing we can just add shared-initialize call in recreate-instance of `persistent'. i don't see how it will change anything though.. p.s. fixing this was somewhat complicated because it didn't clearly report problem that pm-btree is not initialized, but tried to initialize itself in erroneous and confusing way in some obsoleted code path. i'm going to delete these code pathes, so we won't be confused if something like that happens again _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
