On Mon, 26 Jan 2004 16:06:15 -0600, John Lenz <address@hidden>
wrote:
Hi, John!
The current chicken SWIG module is useable but broken (it has a major
bug with the runtime code). The original submitter and maintainer of
the SWIG chicken module, Jonah Beckford, seems to have dissappeared and
currently I believe the SWIG chicken module is unmaintained.
Yes, I tried to get in touch with Jonah, but apparently he can't be
found. That's a pity and I hope he just lost interest.
The major problem with the chicken SWIG module is the incorrect usage
of the swig runtime code, see the SWIG bug #782468
http://sourceforge.net/tracker/?func=detail&aid=782468&group_id=1645&atid=101645
I do not know a lot about chicken internals, but it seems to me that
chicken now has some automatic C++ wrapping implemented. Since the
maintainer of the SWIG chicken module is not around anymore and the
SWIG chicken module has some serious bugs in it, my question is
Is it worth fixing and maintaing the SWIG chicken module?
[...]
In my opinion, chicken seems to be growing to include many of the
features of SWIG and duplicate effort should be eliminated. I think
effort should be focused on using and developing either SWIG or the
chicken parser and wrapper, but not both.
I think it would be _very_ worthwhile to keep maintaining the
Chicken SWIG module. The capabilities of Chicken's built in
parser are very limited, and it doesn't even try to come close
to the amount of stuff SWIG handles. But having a built-in parser
is something that I consider valuable, even if that means one
less tool to install...
2) Maintain the SWIG chicken module.
I would be willing to maintain the SWIG chicken module if there is
enough interest in it. If we go this route, a lot of technical
decisions need to be made about how the module will work. The c++
parser and wrapper in chicken could be removed and chicken could call
SWIG to parse c and c++ stuff. This would be an interesting approach,
because then using SWIG would be completly transparent. Chicken would
pass to SWIG the C or C++ definitions and SWIG would then return the
scheme definitions. For example, SWIG would be given the C string "int
add(int a, int b)" and would return say "(define add (foreign-lambda
int "add" int int))" which would then be further processed by chicken.
With this approach, chichen would almost immediatly get all the
features of SWIG!
Actually I would be delighted if you are willing to maintain it. Chickens
FFI parser will definitely not be expanded any further. It's mainly for
quickly adding C/C++ bindings, and it's not intended to be a full-blown
wrapper generator (if you look at the sources ("easyffi.scm"), you will
realize just how simplistic it is ;-).
So I propose keeping the built-in parser for the quick-and-dirty hacks
and to further maintain the SWIG module.
The idea of passing the FFI code to SWIG is intriguing. A simple
command-line option would do the job.
One more question: does SWIG support callbacks?
Again the decision that should be made now is that since chicken and
SWIG overlap in a lot of what they do, does SWIG bring enough new
features and does SWIG provide a useful tool for writing chicken code?
Is there enough interest and is it worth the effort to update and
maintain the SWIG chicken module?
Absolutely.
And then if it is worth maintaining the SWIG chicken module, there are
a bunch of technical decisions to be made on exactly how SWIG and
chicken will interact, which I will discuss in more detail if we choose
this option.
Well, I would be delighted to help. I don't understand the SWIG code,
though (from the little I've read so far), and the SWIG internals look
pretty complicated to me. But for questions regarding Chicken's side of
the fence, I'll be happy to assist.
cheers,
felix