chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] SWIG stuff again


From: John Lenz
Subject: [Chicken-users] SWIG stuff again
Date: Sat, 16 Oct 2004 21:19:06 +0000

I have been working on some other areas of SWIG, but I finally came back and looked at the chicken module again. I have committed something into the SWIG cvs, but it is still very rough.

I completly changed how the exported code is organized, and I would like to revisit the issue of how SWIG wrapped functions interact with chicken code.

First, what I changed:

- 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

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

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

-----------------------------------------------------------------

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

----------------------------------------------------------------------

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.

- Instead of using C_alloc all over the place, can we just use C_heaptop? Is that thread safe?

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

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

----------------------------------------------------------------------

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

And most of the time, SWIG is going to be used to connect together modules that are pretty complicated (where FFI wouldn't work as well), and in these cases, SWIG is designed to parse the header files directly so you don't have to retype the whole interface...

John







reply via email to

[Prev in Thread] Current Thread [Next in Thread]