This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Guile Plug-In for Gnumeric


On Thu, Nov 12, 1998 at 09:29:48AM -0500, Russ McManus wrote:
> When I worked on a scheme spreadsheet I called these the raw and
> cooked values, respectively.  It sounds like you want to make each
> cell visible from scheme, where the cell gives the programmer access
> to the raw and cooked values.

correct.

> When you have a C data structure whose lifetime is determined in C,
> (Xt Widgets are a good example), there are strategies you can use.  I
> have adapted some code I have to your example:

first, i doubt that miguel will allow me to extend the Cell type in
order to contain a reference to the scheme object, which i don't want
to do anyway, so i will have to make that association externally, which
is not a problem, however.

second, are you sure the following function is ok?

> static scm_sizet
> cell_sweep(SCM obj)
> {
>   cell->obj_init_p = 0;
>   cell->obj = SCM_UNDEFINED;  
>   cell_decrease_refcount(cell);  /* this will only happen when the scheme */
>                                  /* object's lifetime ends */
> }

> My code above shows how to keep the consing to a minimum for this.
> Only when a particular cell is exported to scheme is the cost of
> preparing a scheme representation incurred.  If the same cell is
> exported to scheme twice, the scheme representation is reused.

that's what i though of, too. sounds pretty reasonable.

> >   * CellRefs can be (and usually are) relative. This means that in
> >     order to evaluate an ExprTree its cell must be known in order to
> >     resolve the relative CellRefs. Thus, most functions dealing with
> >     ExprTrees would need to be passed the original CellRef. Another
> >     possibility would be to store the CellRef in the smob. Yet another
> >     solution would be to have a 'current CellRef' variable. Somehow,
> >     none of these solutions appeal to me. Suggestions, anyone?
> 
> Does my code above provide a potential solution?  I think it does,
> unless I don't quite understand your question.

the latter is the case :-).

the problem is that it is possible to refer to cells by absolute
and by relative position. the latter makes it necessary to have some
refernence point (the current cell). i don't want to introduce the
notion of a current cell, though, neither do i want to pass around
a CellRef through all functions just in case somebody wants to eval
a relative CellRef.

bye
schani

-- 
Mark Probst
Student, Programmer
http://www.unix.cslab.tuwien.ac.at/~schani/