On Mon, 24 Nov 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Mon, 24 Nov 2003, Leopold Toetsch wrote:
>
> >> In the mean time I've checked in freeze/thaw for PerlHash. It uses an
> >> element count as list does. We could of course use your proposed scheme
> > ^^^^^
> > You mis-spelled "will" here.
>
> Your explanation about the start/stop pairs just arrived after I had
> coded the PerlHash freezing. But that's small and easy to change.
Sorry. Bad day yesterday, and I was cranky -- that was uncalled-for.
> >> with start/end-markers too. But thawing a list of a (first) unknown amount
> >> of items isn't really as simple as having a count.
>
> > Right -- it's even simpler, and makes doing logical skips through the
> > frozen data easier for code doing external examination, since there's
> > structure in the frozen data rather than a glob of random data elements.
>
> Having a count in front is as structured as having items in between start
> stop markers and I don't see any randomness.
It's not structure, it's convention. Something inspecting the data from
the outside would have no idea that that particular integer was any
different from any other integer. More importantly is the optional name
that can be attached to the data elements (including entire lists and pair
sets). I'd really like to make sure this works and gets used by the base
PMCs so there are good examples. It future-proofs things to some extent as
it removes ordering-dependencies--elements can be identified by their
labels rather than the position of things in the stream.
The easiest thing to do would be to have tag bytes that mark what's in the
stream. We're going to have to do this to some extent anyway so the
thawing engine knows what's being thawed--it's good to be able to
distinguish between int, float, string, or PMC (not to mention all the
string attributes) so we might as well have pair, list, and list-of-pair
markers as well.
Yes, this does bloat out the format some, but it
> I seem currently missing some detail bits.
>
> e.g. freezing and IntList would be now:
>
> [ pmc-id pmc-type N (int-values)*N ]
>
> I don't have a clue, how the end-marker could transparently be coded to
> discern the end of the list from a value. Or do you mean
> start/end-markers plus a count?
I haven't really addressed the thaw API, which is something of a problem.
Try this:
STRING *thaw_string()
INTVAL *thaw_int()
NUMVAL *thaw_num()
PMC *thaw_pmc()
PAIR *thaw_pair()
THING *thaw_next()
STRING *cur_label()
INTVAL last_error()
int next_type()
STRING *next_label()
skip_item()
THING is a union of a float, int, PMC *, STRING *, and PAIR *.
PAIR is a struct:
struct PAIR {
INTVAL labeltype;
union {INTVAL; NUMVAL; PMC *; STRING *} label;
INTVAL valtype;
union {INTVAL; NUMVAL; PMC *; STRING *} value;
}
(Only syntactically correct)
Everything returns temporary pointers--if something's not available
because you've run out you get a NULL pointer. This includes being within
a list and running off the end even if there's more data.
last_error() tells you what went wrong most recently, which is how you can
tell that the last NULL was because you ended the list being processed
rather than ran off the end of the PMC, or asked for a string and the next
type was an INTVAL instead.
next_type and next_label tell you what's coming up next and what it's
named, if its named. skip_next skips the next thing (which may be an
entire list or set of pairs). cur_label returns the label of the most
recently thawed thing.
I'm not sure if we want to have any sort of random access functionality.
It'd be nice, certainly, but it adds a certain complexity, and may be in
general infeasable (If we're thawing from a socket or pipe it'd require
buffering, which with potentially large data sets might be unreasonable)
so I think we'll skip it for now and consider adding it later, unless
people think we can add in an optional random-access API and not get so
dependent on it that it's no longer optional.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
