[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile Binary Format 0.1
From: |
Keisuke Nishida |
Subject: |
Re: Guile Binary Format 0.1 |
Date: |
Mon, 05 Feb 2001 19:16:03 -0500 |
User-agent: |
Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/21.0.96 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Mon, 5 Feb 2001 23:38:49 +0100 (MET),
Dirk Herrmann wrote:
>
> > 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!
Hmm, probably. I'll leave it now and think about it again.
> > 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?
I thought the following code does not work
/* Undump a cell */
SCM_NEWCELL (obj);
scm_restore_object (&SCM_CDR (obj), dstate);
scm_restore_object (&SCM_CAR (obj), dstate);
but actually, it works... Isn't this dangerous?
> > [\?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?
You need to restore real objects at the end of the undump process,
so you have to memorize what you need to do. I use malloc to
create a list of final update tasks.
> 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.
Yes, I'll create a table that maps stored typecodes to real tc values.
Kei
- 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, 2001/02/05
- Re: Guile Binary Format 0.1,
Keisuke Nishida <=
- 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