Re: Need help embedding Guile

[Dimitris Papavasiliou <dpapavas@protonmail.ch>]

Hi Olivier,

Thanks for chiming in!

On Wednesday, December 22nd, 2021 at 12:39 AM, Olivier Dion wrote:

> From this description, what I understand is that you want to use Scheme
> as a configuration file for batching the operations to be done in a
> second phase in C++.

From an architectural point of view, the situation is probably similar
to simple configuration parsing, as you say.  In practice though, the
scope of Guile's role won't be nearly as limited as what this might
imply.

In a way, what I'm working on, can be described as a "compiler" for
geometry.  That is to say, it reads in the description of geometry in
some language and then evaluates it and dumps it in a format that can
be used for e.g. 3D printing.  Guile (amongst other options) supplies
the language frontend.  For example, one might invoke it on the shell
like this:

$ compile hollow_cube.scm

Here, `hollow_cube.scm' would contain, say:

(write-stl
  "hollow_cube.stl"
  (difference
    (cube 2 2 2)
    (cube 1 1 1)))

When the `cube' procedure is evaluated, it creates a node in the C++
backend that evaluates to the geometry of a cube.  Similarly
`difference' creates a node, with edges to the two cubes, which when
evaluated computes their boolean difference and so on.  Of course, in
this instance, the Scheme code amounts to little more than what might
be termed a configuration file, but imagine the code to create a
complex mechanical part and the situation is (conceptually) quite
different.

Creating the complete graph before evaluation begins in the second
phase is probably not necessary (nodes could be evaluated as they're
created), but it creates the opportunity for certain optimizations
(like dead code elimination for instance).  This makes some sort of
forcing/ensuring that Guile has terminated desirable.

> However, I failed to see why you need to finalize these objects
> since you're going to use them in your second phase?

Foreign objects currently come in two categories:

1. Complete geometric operations such as `cube' and `difference'
   above.  These are allocated on the C++ side and a so-called "smart
   pointer" (shared_ptr) is exported to Scheme.  Failure to finalize
   this retains a reference on the C++ side, which would prevent
   destroying the operation.  Since these can get quite large in terms
   of memory, destroying them after they're no longer needed can be
   essential.

2. "Complex" arguments to the above operations such as
   transforamtions, planes, points, etc. which are C++ classes, for
   which the destructor needs to be called in one way or the other.
   These are generally passed by value to the operations and can
   therefore be freed once the first phase is complete.

> One way I think of would be to fork the process and create your C++
> objects in a shared memory area between the parent and the child. Once
> Guile is done reading your inputs, the child process dies and all its
> memory is reclaimed by the OS.

I have considered that but, besides the fact that it seems a bit
heavy-handed, it still won't allow me to make sure the C++ objects are
properly finalized.  This creates two problems: for one, some object
might need finalization that's more than just freeing memory and I'd
have to make sure that this isn't the case for each specific type
(which typically come from external libraries).  And for another,
these would show up as leaks in tools such as Valgrind, which would
make checking for memory bugs difficult.

One idea would be to simply call `scm_gc()' and `scm_run_finalizers()'
until the latter returns 0.  As far as I can see, this should ensure
all finalizers are called, assumming no references to any foreign
objects remain, but I see no way of ensuring the latter short of
process termination...

Dimitris