[Chicken-users] Re: SWIG stuff again

[felix winkelmann]

On Sat, 16 Oct 2004 21:19:06 +0000, John Lenz <address@hidden> wrote:
> 
> - I got rid of the -clos.scm and -generic.scm files.  What happens now is
> by default no CLOS wrapping is exported.  If you pass SWIG the -proxy
> argument, it sticks the CLOS definitions directly into module.scm

Ok. 

> 
> - module.scm is always declared as a unit.  This means that you need to use
> (load-library) to load the module if you compile it dynamicly.  Will
> (declare (uses module)) automaticly load it?

It's a linking instruction, really, and module will be required for
the link stage. But the toplevel expressions will be invoked, once
the executable starts.

> 
> - Notice as well that that since the CLOS stuff is stuck right into
> module.scm, it gets compiled into the unit.  Thus code that uses the
> wrapped module no longer (include)s a file.

Very good.

> 
> -----------------------------------------------------------------
> 
> A more detailed description:
> 
> - In the SWIG generated _wrap.cxx file, there is a function called
> swig_module_init, that calls C_intern to register functions.  If -proxy was
> not passed, the names are the names from the header.  If -proxy is passed,
> all the names are prefixed by "primitive:"
> 
> - newobject2.scm now looks like so (this is from newobject2.i from the SWIG
> test-suite)
> 
> (declare (unit newobject2))
> 
> (declare
>     (hide swig-init)
>     (foreign-declare "C_extern void swig_newobject2_init(int,C_word,C_word)
> C_noret;"))
> (define swig-init (##core#primitive "swig_newobject2_init"))
> (swig-init)
> 
> ;; If -prefix is passed, the CLOS definitions go here
> 
> ;; If -prefix is passed, do something like
> ;; (declare (hide primitive:new-Foo primitive:whatever))
> 
> - What happens is that the CLOS definitions use the primitive: symbols, and
> so we want to hide the primitive: symbols from appearing in the list of
> exportedsymbols in the unit.
> 
> - This is causing a problem, because the linkage doesn't work for some
> reason.  The generated chicken code uses C_retrieve2 to get the primitive:
> symbol, but it can't be found....

How do you link? If you link statically, you will have to pass
libchicken last. Are you using csc?

> 
> ----------------------------------------------------------------------
> 
> Now some questions:
> 
> - Is there a different way to export symbols in the generated wrapper file
> than C_intern so that we can use them later on and then hide them?  In SWIG
> we can choose which of the two, so if we should use C_intern if the symbol
> should be globally visible (-proxy is not passed) and something else if (-
> proxy) is passed.

The only thing that comes to my mind is prefixing the hidden symbol
with something, but that's not really completely satisfying. Chicken
internally supports having multiple symbol-tables, perhaps one could
use that somehow. The "hide" declaration works only inside a single
compilation unit, and effectively turns global variables into static
C variables (instead of interning them into the (default) symbol table).
I'll check the symbol-table stuff, perhaps I can find a better solution.

> 
> - Instead of using C_alloc all over the place, can we just use C_heaptop?

If you use C_heaptop, you will have to check for heap-exhaustion.
(which you have to do with C_alloc as well, of course, but in this
case you check the stack - the difference is ). You can take a look
at the toplevel function that is generated for normal Scheme files
to see it in action: C_demand_2 (yes, a stupid name) checks whether
the remaining heap-space is sufficient, and C_h_intern interns
into heap (this is different from the normal C_intern, because of
weird GC/write-barrier issues).

> Is that thread safe?

The Chicken runtime-system is not thread-safe in general.

> 
> - Is there a better way than C_kontinue to return?  Doesn't that keep
> around the C stack frame?  Won't these things keep accumulating?

If invoked inside a ##core#primitive (i.e. a normal CPS function), no.
Well, they *do* accumulate, but once the stack-size exceeds a certain
limit (the nursery size computed at build-time), all live data will be
moved from the stack into the heap and then a longjmp() pops
the stack-frames. This is the method used to implement continuations
and tail-calls. I recommend reading Henry Baker's paper
"Cheney on the MTA" for a better description of the compilation
scheme used in Chicken.

> 
> Basicly, I am asking if the current way SWIG gets symbols and funtions into
> chicken is the best way.

I think, yes. It's quite similar to the code generated by chicken.
Generating ##sys#primitives (CPS functions) will give you the
most information and control.

> 
> ----------------------------------------------------------------------
> 
> SWIG/Chicken interaction
> 
> I will revist this after the above few issues are taken care of, but what I
> think would be the best and easiest way would be to just teach csc about .i
> files...  You could do something like
> 
> csc module.i module_impl.cxx use_module.scm
> 
> where module_impl.cxx would contain the implementation of the functions you
> are wrapping in the .i file.  use_module.scm would then have the code to
> use the code.

Yes, that's trivial to add. 

>  SWIG even has the ability to parse most C header files by
> itself if you don't want to have any directives.
> 
> csc module.h module_impl.cxx use_module.scm
> 
> The reason I don't think doing something like
> 
> #>(swig foo) #<
> 
> while it might work, each swig wrapped file is now declared as its own
> unit...

Ok. But I would like to support passing .h files to Chicken's internal
C parser. Perhaps a "-swig <file.h>" option?

chicken supports passing information back into csc, so it
should be quite easy to let SWIG generate code that communicates
extra files and/or compile-/link-options to csc. For more
specific information, just ask.


cheers,
felix