Re: Interest in xfig

[Telford Tendys <telford@eng.uts.edu.au>]

I got distracted from xfig by looking at the gEDA project's schematic editor
which is also quite nice. The approach suggested below sounds pretty good.
I have a feeling that this sort of problem is going to turn up in various
scripting applications and we should probably get together some list of standard
approaches which guile is intended to support.

I might point out that the approach below should fall into the general
category of reference counting, although it is a highly specialised form
of such. Effectively, there is a maximum reference count of two, one reference
being from scheme, the other from C. The various states described below
represent the counter.

Another approach which occured to me the other day was to encapsulate
the entire xfig picture database inside a SMOB. This would then have its
own garbage collector that scans out all SMOBs contained within that
database. This would probably be too massive for a retrofit but it would
be in closer keeping with the guile GC philosophy. Mind you it would probably
run a lot slower because of the extra work in the mark phase.

> Here's another approach.
> 
> Add a field to each xfig object which points back at its smob, or is
> zero if no smob has been created for it.
> 
> When you free an xfig object, if its back pointer is non-zero, it has
> a smob, so zero the smob's cdr.
> 
> When a smob dies, if its cdr is non-zero, then its xfig object is
> still alive, so zero the object's back pointer.
> 
> All operations on the smob should check that its CDR is non-zero, and
> signal a "dead xfig object" error otherwise.  If you forget to check,
> you'll get a segfault.
> 
> The function which creates a smob for an xfig object should check the
> object's back pointer, and return the existing smob if it exists.
> 
> 
> Thus, we have four possible states for each past and present xfig
> object, and ways to recognize each:
> 
> - object is alive, but has no live smob.  back pointer is zero.
> - object is alive, and has a live smob.  object's back pointer points
>   to smob; smob's cdr points to object.
> - object is dead, but smob lives on.  smob's CDR is zero.
> - object and smob are both dead.  Nobody cares.
> 
> The nice thing about this is that the interpretation of the data
> structures is pretty intuitive ("This is zero?  Oh, that object must
> not exist any more."), and when something dies, you can free it
> immediately.  No zombies.

Well there sort of are zombies, there are the SMOBs with zero pointers
in them. I guess that these zombies are using very little memory (one cell)
and in theory cannot be harmful so it is better than having big malloced
structs floating around waiting to be collected.

Is there a suggested manner for handling the ``dead object'' error?
Should functions return #f or should the script crash? For that matter,
is there any centralised method for handling errors in guile? Suppose I
write a handy couple of scheme routines... is it OK to call (error) in
the middle of one of them or will this lead to a situation where those
routines cannot be used by some project?

I've noticed that in ``scwm'', errors usually fall out onto the console
that called scwm which is quite often not visible or even accessible from
within X. I haven't looked too closely at other guile projects in this
regard, I guess I'll try throwing some errors at gschem and see how it
handles it.

	- Tel