Dan Sugalski <[EMAIL PROTECTED]> wrote:On Fri, 29 Aug 2003, Leopold Toetsch wrote:
I think, we need a general solution for freeze, dump and clone. As shown the latter is broken. That would be IMHO an iterator interface with a callback function taking and returning a void*.
Right, what I want is for the system freeze/thaw routines to have a standard way to encode a variety of core types (ints, floats, strings), lists, and hashes, as well as a way to handle self-referential, circular, and shared data in the dumped PMC data. It's the only way to safely do this, since we can't count on all the different PMC classes to handle dumping arrays of arrays of references to the same end PMC properly. Which we have to if we want this to work right.
The freeze(), dump() and clone() would be vtables which are called by the iterator. So this functions hould have the same signature.
No iterator. When you call freeze on a PMC, that PMC is responsible for any sort of iteration that may have to be done. (Though there is the issue of blowing stack, which we'll have to address)
Aren't you saying the opposite of above here? I want to be able to traverse from a given start point (being it the own interpreter or some PMC) as deeply down as there is something. You did say, that we don't recursively mark() because of recursion depth. clone(), dump(), freeze() all have these same issues (plus self-referntial structures).
No, I'm just not being clear, so lets fix that.
We don't need any special iterator, since we already have one--the DOD iterator, which is not only sufficient for our needs its likely the only thing that *can* have sufficient information to do the iteration.
The ->freeze or ->thaw methods in the vtables are sufficient to freeze or thaw a PMC, but aren't going to be driving the freezing/thawing. The way things work is this:
The freeze opcode takes a PMC as a parameter. The DOD tracing system is set up. The first PMC's freeze vtable function is called. When it returns (and we'll get to what it does later) the freeze op follows the chain and calls the next PMC's freeze, then the next, and so forth until it runs out of PMCs to freeze. This may, for simple PMCs, stop after the first--there may be no traversal at all.
The freeze vtable method of a PMC is responsible for handing off parts of the PMC to the freezing and thawing encoding subsystem (which itself turns those parts into bits on the wire or characters in a file or string). The encoding subsystem should have a way to encode:
Single values: STRING * (so we can save encoding, charset, and language) Integers Floats Binary data PMCs frozen bytecode
Name/value pair (where the value is one of the above bits, or a set of name/value pairs, or a list of values)
Lists of values (where the list can be a set of name/value pairs, or lists of values)
Meta data--Internal structure stuff (flags, PMC class name, and whatnot)
Not that complex -- this gets 95% of what any PMC class would need, and the remaining 5% can get shoved as binary data into a value thing.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
