Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
perl.perl6.internals
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Freezing and thawing
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Dan Sugalski  
View profile  
 More options Nov 24 2003, 9:48 am
Newsgroups: perl.perl6.internals
From: d...@sidhe.org (Dan Sugalski)
Date: Mon, 24 Nov 2003 09:48:08 -0500 (EST)
Local: Mon, Nov 24 2003 9:48 am
Subject: Re: Freezing and thawing
Print | View thread | Show original | Report this message | Find messages by this author

On Fri, 21 Nov 2003, Leopold Toetsch wrote:
> Dan Sugalski <d...@sidhe.org> 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
d...@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google