Dan Sugalski wrote: > > On Fri, 29 Aug 2003, Leopold Toetsch wrote: > >> Dan Sugalski <[EMAIL PROTECTED]> wrote: >>> I think we'd be better served getting the freeze/thaw stuff in and >> >> We were just discussing this in the f'up. > > I read those, but I wanted to make sure the discussion went this way. :) > >>> If we make the initial dump scheme something mildly human readable >>> (XML, YAML, whatever) then the debugger doesn't have to worry about >>> formatting it for a while. (And we're going to want a pluggable dump >>> scheme anyway, to make experimentation eaiser) >> >> Pluggable implies a dump() vtable method, doesn't it? > > Nope. Pluggable implies freezethaw.c provides all the functionality to > freeze or thaw a PMC, with code in there to handle the right final > encoding or decoding of the data. > > I thought we had a freeze and thaw entry in the vtables, but I see not. > The signatures (since I don't have source handy to check them in) should > be: > > STRING *freeze() > PMC* thaw(STRING*) > > With thaw ignoring its initial PMC parameter. (It's a class method, > essentially)
Actually, I think the following interface would be better: void freeze(PMC *freezer); void thaw (PMC *thawer); When you freeze a pmc, it's passed a handle into the freezing mechansim, which it can then use to record the data that will be necessary to reconstitute itself later. This is done using the VTABLE_push_<type> methods. Pushing a pmc does *not* instantly result in that other pmc being frozen; that only happens *after* the freeze() function returns. In effect, it marks the other pmc as needing serialization, which then happens later. During thawing, a pmc header is created for you, morphed into your class, and then has VTABLE_thaw called on it. It can then reconsititute itself using VTABLE_shift_<type> on the handle to the thawer that's been passed in to it. Just as serialization of external pmcs in freeze wasn't immediate, any pmc which you shift_<> out of the Thawer object might not be fully thawed... it might be a pmc header which has been created as a placeholder, and which has not had VTABLE_thaw called on it yet. Freezing and thawing would have algorithms similar to the mark-and-sweep of the DoD (but simple fifos, or simple stacks, not any kind of priority queue;)). I'm not *entirely* sure, but I think we might need/want to allow STRING*s returned by shift_<> to be placeholders too. This allow the freezer to print out the string data after the pmcs if it choses to. If it does, it can perhaps write the strings in a more compact manner. Almost certainly moving the strings to the end would make compression by gzip or whatever easier. (I vaguely recall hearing that the following problem is NP-hard, but I don't remember. Does anyone know for sure? Given a set of N strings, construct a single larger string, of which all N strings are substrings. This allows all N strings to be represented on disk using nothing more than the large string, and an offset and length for each substring.) -- $a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca );{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED] ]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}