On 3/11/10 7:11 PM, Peter Lobsinger wrote:
While I want the ability to do both deep and shallow clones, I think the responsibility for deep cloning is not something we want to push into PMCs if we don't have to. TT #1015 is caused by Hash PMC not being able to handle that responsibility.
This is a similar issue to the old method of creating Array/Hash iterators, the current strategy is just too promiscuous with the internals of the item it's traversing.
The three visitor API PMCs that have already been created (ImageIO and ImageIOSize from trunk, VisitClone from tt1015 branch), use a hash (called 'seen') to keep track of this for PMCs, so can store arbitrary information about already visited elements. Eliminating duplicate STRING buffers is not something that is being done ATM, but would probably be fairly easy to add. AFAIK, you cannot communicate between components at a PIR/HLL level by modifying a shared string buffer because these are COW / immutable. So this would only be an optimization, not a functionality change. freeze/thaw/visit already take a parameter for the registry: PMC *info (also known as visit_info, visit).
+1
These PMCs are expected to provide a certain vtable-based API (I should document that somewhere)
Yes, please write up briefly for PDD 17, and pass the patch around the list for review.
but are free to provide that as they see fit. For example, freezing and cloning traversals can keep their state in a "seen" hash; marking traversal (which probably shouldn't allocate while traversing, but is hopefully unique per-interpreter at a given time) might keep its state in PObj flags.
To be clear, the "seen" hash is stored as an attribute of the VisitClone PMC? And each deep-cloning process is a unique instance of the VisitClone PMC, in much the same way that each iterator is a unique instance of HashIterator/ArrayIterator?
Allison _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
