[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile Binary Format 0.1
From: |
Dirk Herrmann |
Subject: |
Re: Guile Binary Format 0.1 |
Date: |
Mon, 5 Feb 2001 23:38:49 +0100 (MET) |
On Mon, 5 Feb 2001, Keisuke Nishida wrote:
> I have implemented this version. Now objects are stored using a stack.
> When scm_dump_object is called and the object has not been stored yet,
> it is pushed into a stack and the rest of tasks are automatically
> scheduled. So a smob writer don't need to think about it.
That is much more comfortable.
> An undump function looks like this:
>
> SCM
> foo_undump (SCM dstate)
> {
> struct foo *p = scm_must_malloc (sizeof (struct foo), "foo_undump");
> p->x = scm_undump_word (dstate);
> p->y = scm_undump_word (dstate);
> scm_undump_object (&p->bar, dstate);
> scm_undump_object (&p->baz, dstate);
> SCM_RETURN_NEWSMOB (scm_tc16_foo, p);
> }
>
> It's not symmetry, but probably this is easier to use. [...]
Well, I liked your symmetric version better. Otherwise, the interface has
become quite elegant!
> [...] If you want
> to dump/undump a cell object, you should write it as follows:
>
> SCM
> foo_dump (SCM obj, SCM dstate)
> {
> scm_dump_cell_object (SCM_CELL_OBJECT_1 (obj), dstate);
> }
>
> SCM
> foo_updump (SCM dstate)
> {
> SCM smob;
> SCM_NEWSMOB (scm_tc16_foo, smob, 0);
> scm_undump_cell_object (smob, 1, dstate);
> return smob;
> }
I don't understand this. Why do you treat cell objects differently from
other objects?
> There are some potential places of improvement, though. Since
> objects are dumped from the beginning, lots of reference linking
> can be delayed during undump. For example, a list (foo bar) is
> stored as follows:
>
> [\?GBF ][-0.1][ 4]
> [cons ][ #1][ #2]
> [symbol][foo ]
> [cons ][ #3][ ()]
> [symbol][bar ]
>
> When the first cons is undumped, object #1 and #2 are not yet
> created, so linking are delayed and scheduled using malloc.
> This may produce a number of of malloc calls. [...]
What do you need malloc calls for? I would say, if the first cons object
is undumped, you create exactly the cons cell that you want to
create. However, you fill it with #f instead of with the real
objects. No malloc needed, or am I missing something?
> I haven't fixed the smob tc problem yet. Only file ports
> with mmap are supported. Only one object can be read.
> No documentation yet. I'll add them some time later.
The point about the smob tc (and, actually any tc) problem is, that you
probably wouldn't want to store a full type description with any single
object: If you were to store a couple of integers, it would be very space
consuming to write out the string "integer" ahead of every single
number. So, one could alternatively allocate typecodes dynamically during
writing/reading, comparable to the way that object reference numbers are
generated dynamically.
> I appreciate any comments.
It looks very promising. Thanks for working on it!
Best regards,
Dirk Herrmann
- Guile Binary Format 0.0, Keisuke Nishida, 2001/02/03
- Re: Guile Binary Format 0.0, Dirk Herrmann, 2001/02/03
- Guile Binary Format 0.1, Keisuke Nishida, 2001/02/05
- Re: Guile Binary Format 0.1,
Dirk Herrmann <=
- Re: Guile Binary Format 0.1, Keisuke Nishida, 2001/02/05
- Re: Guile Binary Format 0.1, Michael Livshin, 2001/02/05
- Re: Guile Binary Format 0.1, Keisuke Nishida, 2001/02/05
- Re: Guile Binary Format 0.1, Michael Livshin, 2001/02/06
- Re: Guile Binary Format 0.1, Keisuke Nishida, 2001/02/06
- Re: Guile Binary Format 0.1, Michael Livshin, 2001/02/07
- Re: Guile Binary Format 0.1, Keisuke Nishida, 2001/02/08
- Re: Guile Binary Format 0.1, Michael Livshin, 2001/02/19
Re: Guile Binary Format 0.0, Miroslav Silovic, 2001/02/04