[Chicken-users] Re: SWIG stuff again

[John Lenz]

On 10/18/04 01:09:48, felix winkelmann wrote:
> > - 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?

Well actually I tried both ways.  The SWIG file Examples/Makefile.in has  
the ability to compile either using csc or also invoking chicken and then  
the compiler.  Basicly, I link together the c file resulting from compiling  
example.scm with the example_wrap.cxx file which contains the SWIG  
functions into one dynamic library libexample.so.  This one library then  
contains all the code related to the example unit, and is then loaded by  
(load-library) to actually get used.

> >
> > ----------------------------------------------------------------------
> >
> > 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.

Well, they are already prefixed by "primitive:"  We need to do this anyway  
or we would get symbol conflicts.  Say for example there is a low level  
function called "void do_stuff(Foo *f)".  We would export a wrapper  
function called "primitive:do_stuff" which would take a chicken swigpointer  
type.  We would then export something like this into example.scm

(define-method (do-stuff (f <Foo>))
 (primitive:do-stuff (slot-ref f 'swig-this)))

The idea is that every function that has anything to do with classes will  
be wrapped like this, and any function that only takes "low-level" types  
like "void do_stuff(int a, int b)" will just get exported as

(define do-stuff primitive:do-stuff)

Thus I really would like to just completly hide all the primitive: symbols.   
So I really just need some way in the _wrap.cxx file to provide the  
primitive: symbols only into the example.scm file.  Or just some way at the  
end of example.scm to remove the primitive: symbols from the symbol table.   
When running SWIG we know the list of all the primitive: symbols, so it  
would be easy to add something like
(remove-symbols primitive:do-stuff primitive:whatever)

(Of course, if -proxy is not passed, then the symbols in _wrap.cxx are not  
prefixed with primitive: and are just exported normally)

> >   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.

I don't really understand what you mean here :)  Do you mean that say when  
running csi, it will automatically call csc to compile the code and then  
load it in or something?  Or that when chicken encounters a .h file it will  
call swig to parse it somehow?

SWIG has the ability to produce s-expressions of the parse tree.
Check out say
swig -sexp -typemaplang chicken -c++ clientdata_prop_a.h

John