KeyedSets do not have to use a block, if the items respond to #key. Its a bit of a hack but in this case all it needs is for PRKernel to implement #key. As for persistence not working with it, surely that has to be a limitation of a particular persistence solution. As far as Magma is concerned I dont think it is necessary to persist "PRKernel instances". I agree that it would be much nicer if Magma did support KeyedSets fully which it doesnt. I would happily put a KeyedSet in as my repository root. (I already tried it). Keith ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html

In trying to implement MagmaPersistency it turns out that the fact that PRContext holds a local cache to the current session may be a bit of a pain. Not only may there be a lot more stuff accidentally persisted through this reference, there may actually be objects that magma gurus say 'don't persist these if you know what is good for you'. I cant see that this cache is widely used, so I wondered if anyone would object if it was removed i.e. make this method lookup the current session the hard but not all that slow way (about 100 microseconds, on my oldish 700Mhz machine) PRContext>>session ^ WACurrentSession value any thoughts/opinions? Keith ___________________________________________________________ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

What kind of cache? There is a reference to the kernel. To the currently browsed structure and the currently executed command. Moreover there is a time-stamp and an enumerator object. Ideally descriptions on the class-side should tell you what fields have to be persistent. Is it something you added yourself? I am lost :-) Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

I see, this is not really useful if you use a persistency mechanism that dumps out the whole objects. The idea was that Pier knows using the description what parts of the objects to serialize, something that is probably not easily controllable with a framework using the Smalltalk reach-ability to serialize objects. So I would suggest that you remove this cache. What's the trouble with MAProxyObject instances? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Indeed. It seems that most of the properties in PRContext are not very useful when persisted. My current approach explicitly copies the parts of the object that I wish to persist, and so now it is not absolutely necessary to remove this cache. I have removed Pier-Magma's use of this cache, and so it remains to see who else actually uses it. I am not really sure of the ins and outs of this. I think that Magma was attempting to serialise part of the PRContext structure at the time. The proxy was to an Array of Commands, containing 8 items. Magma was looping through them to serialise them and asked for maInstSize which returned 9 rather than 8, owing to the fact that ProtoObject (i.e MAProxyObject) returns maInstSize as (^self class instSize + self basicSize ) differently to Object. I.e. the call to maInstSize is not being proxied. A fix would be to add an explicit maInstSize to MAProxyObject. I suspect that it would be worth setting up a test case for this one and to work out just what the desired behaviour actually is. Keith ___________________________________________________________ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html