On Fri, 21 Nov 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > 5) The vtable API
>
> [ ... ]
>
> > thawfinish()
>
> This is very probably necessary to perform some final state adjustemnt,
> when all the contained PMCs are done but not as a general "to be
> called on each". E.g. a plain scalar PMC doesn't need it. I'd rather
> have such functionality on demand i.e. a PMC on freezing sets a flag:
> "I need post-processing".
If we want to add a flag, or a call as part of the freeze API that lets a
PMC note that it needs post-processing, that's fine. The default vtable
entry should just do nothing.
> > 6) The freeze/thaw library needs to consist of the following calls (some
> > of which we already have)
>
> [ ... ]
>
> > startlist(name)
> > endlist(name)
> > startpairs(name)
> > endpairs(name)
>
> Do you have some more info about above functions and what they are
> intended to perform?
A list is just a series of values in this context -- the sort of thing
you'd use to dump out an array or a struct. If you had a PMC that
represented this:
struct foo {
INTVAL bar;
INTVAL baz;
STRING *name;
INTVAL count;
}
the calls the PMC freeze would make would look like
startlist("foo")
freezeint(bar)
freezeint(baz)
freezestring(name)
freezeint(count)
endlist()
start/end pairs does the same thing, only what gets frozen is a series of
pairs (key/value things) rather than individual entries. And yes, I
realize that you can simulate pairs with alternating key/value entries in
the freeze stream, but I'd rather keep them separate.
> > addpmctolist(pmc *)
>
> Doesn't fit into the scheme.
Sure it does. This puts a PMC on the list of PMCs being frozen, assuming
that PMC isn't already on the list. The freeze list drives everything that
gets frozen.
> The latter tells the engine, to put a PMC
> on the todo_list. That ought to be part of the context (info) structure.
> All the other library functions are serializer-specific.
Its not necessarily overridable, true, but it's conceptually one of the
core freeze routines. That's the imprtant part here.
> > The freezepmc routine here, it should be noted, acts as a mark routine of
> > sorts, which is why we don't need one on the PMC itself for this.
>
> That doesn't play with other usage of vtable->visit like destruction
> ordering. When going that way, we are loosing the generalization that
> currently is in the scheme. (At least if you are using the term "mark"
> here as what vtable->visit() now is).
Well, there's the problem. the ->mark vtable entry is really "mark your
children" rather than "mark yourself", which means that the freeze entry
for a PMC corresponds to the mark entry for DOD. When ->freeze is called
for a PMC all the children should be frozen. (Or all the children it
ultmately cares about) This is separate from the mark routine Parrot's API
provides, which is a "put this PMC on the list of PMCs to be visited, if
its not already on the list" routine.
It would've been better if the vtable entry was "mark_children" and the
DOD routine "add_to_todo" but alas they aren't named that, even if its
what's going on.
> > Leo's idea of passing in a struct as part of the freeze is a good one, as
> > one of the things hanging off it can be a vtable with all these calls in
> > it, so we can have multiple freeze methods active at once. (Arguments as
> > to why that's a good thing are separate and I don't want to go there :)
>
> Actually, I'm (longterm) thinking of making a PMC out of PackFile_<xxx>
> and what's now called IMAGE_IO. The generalization could be finally:
> Writing a .pbc file image is freezing/writing such a PackFile PMC. Or
> adding an item to a packfile is appending a frozen image. Having all
> this functionality inside one or more PMCs, makes it easy to change
> these formats - even to xml (brrr).
I'm picturing some interesting recursive definition issues there. At the
moment I'm thinking we'd be better off keeping the freeze format separate
from the bytecode format. Some of the limits on bytecode (like
mmappability) may conflict with how we'd prefer to do serialization by
default. We can look to unify them later, but for now lets keep things
separate.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
