Q: freeze/thaw data format and PBC
Leopold Toetsch
Currently I'm writing plain ASCII strings, which is quite handy for testing.
The Plan(tm) is to use PBC constant format (or extensions to this)
later, so that PMC constants nicely integrate into byte-code and that
freezing closures can use the existing infra structure.
The interface now looks like this:
typedef void (*push_item_f)(Parrot_Interp, struct _visit_info *,
PARROT_DATA_TYPES, void*);
typedef void* (*shift_item_f)(Parrot_Interp, struct _visit_info *,
PARROT_DATA_TYPES);
typedef struct _visit_info {
...
push_item_f push_item; /* write item to image */
shift_item_f shift_item; /* get item from image */
} visit_info;
... so switching to different formats is rather simple.
leo
Dan Sugalski
> Are there already any plans for the frozen image data format?
> Currently I'm writing plain ASCII strings, which is quite handy for testing.
I'd prefer it to be as dense as possible. Besides the format used in
bytecode files (so it'll take up memory space when mmapped in) it's also
going to be the over-the-wire serialization format and, while disk space
is reasonably cheap, bandwidth still isn't.
> typedef struct _visit_info {
> ...
> push_item_f push_item; /* write item to image */
> shift_item_f shift_item; /* get item from image */
> } visit_info;
Though I'm still not sure we need a unified structure here. (And if we do,
we need to do something different, a single function pointer for read or
write is insufficient)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> On Tue, 4 Nov 2003, Leopold Toetsch wrote:
>> Are there already any plans for the frozen image data format?
>> Currently I'm writing plain ASCII strings, which is quite handy for testing.
> I'd prefer it to be as dense as possible.
Sure. The ASCII image is for testing/debugging only. The questions was,
if a PBC-like format is ok.
>> typedef struct _visit_info {
>> ...
>> push_item_f push_item; /* write item to image */
>> shift_item_f shift_item; /* get item from image */
>> } visit_info;
> Though I'm still not sure we need a unified structure here.
We can separate that stuff later.
> ... (And if we do,
> we need to do something different, a single function pointer for read or
> write is insufficient)
Enough with the type information as parameter. But we might have
individual entries later for speed reasons.
Do you want to have a look at current state? Its already
freezing/thawing nested and self-refed Arrays.
> Dan
leo
Dan Sugalski
> Dan Sugalski <d...@sidhe.org> wrote:
> > On Tue, 4 Nov 2003, Leopold Toetsch wrote:
>
> >> Are there already any plans for the frozen image data format?
> >> Currently I'm writing plain ASCII strings, which is quite handy for testing.
>
> > I'd prefer it to be as dense as possible.
>
> Sure. The ASCII image is for testing/debugging only. The questions was,
> if a PBC-like format is ok.
I'll have to go look at the pbc format and see. Probably, though.
> >> typedef struct _visit_info {
> >> ...
> >> push_item_f push_item; /* write item to image */
> >> shift_item_f shift_item; /* get item from image */
> >> } visit_info;
>
> > Though I'm still not sure we need a unified structure here.
>
> We can separate that stuff later.
>
> > ... (And if we do,
> > we need to do something different, a single function pointer for read or
> > write is insufficient)
>
> Enough with the type information as parameter.
No, I don't think so, not without going with a varargs scheme, and I
*really* don't want to do that. For this I think we're better off with
specific API functions since the set is small and bounded. If we really
want we can put them in some sort of vtable structure, which might not be
a bad thing.
> But we might have
> individual entries later for speed reasons.
>
> Do you want to have a look at current state? Its already
> freezing/thawing nested and self-refed Arrays.
Yeah, I'd like to have a look. I definitely want to get the API nailed
down.
Leopold Toetsch
[ freeze/thaw writer/reader ]
> ... For this I think we're better off with
> specific API functions since the set is small and bounded. If we really
> want we can put them in some sort of vtable structure, which might not be
> a bad thing.
Sort of vtable could be a real vtable too. I.e. we could have:
- a PackFile PMC
- on creation it gets the info structure attached to struct_val
- outputting items goes into push_<item> vtables
- inputting items is done by shift_<item> vtables
- uncoverd items (e.g. key/value pair) could go into _keyed variants
Currently writing packfiles includes two passes: 1) calculate needed
space (and after allocating that) 2) actually pack into this space. This
doesn't really play together with e.g. freezing a constant class
definition PMC, which would need these 2 passes too.
So to unify this more, writing packfiles could use the same PackFile PMC
by generating (and reallocating) the (opcode_t) image in one pass.
And, as mentioned several times, the image format should be overridable:
This is then just providing the required methods for the PackFile PMC.
Comments welcome,
leo