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;}
