guile-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]