[Caml-list] re: swig like library...

[Caml-list] re: swig like library...

[Micha]

ok, now there are forklift, idl and swig. swig seems to be the only lib which 
can create an interface to a c++ lib. The IDL docu mentions c++ but only with 
com; or did I misunderstand something?
So to interface to a c++ lib I first have to create the relevant c-lib and 
then with idl or forklift the rest, or use swig from the beginning, or by 
hand, which seems much to type :-)

Has someone experiences interfacing to a c++ - lib? 

 Michael

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: swig like library...

[Jeff Henrikson]

> Any interest in an Ocaml based SWIG like tool?

When I put on hiatus my Forklift development, I was thinking a lot about the following problem, which I made up to focus my path.

==> Make precise the relationship between the immutable C header files and the assignments of stubs, HLL types, and HLL modules.  In order to separate pattern matching from stub generation, output an abstract representation.  Suppose we choose IDL as that abstract representation.  Then give a pattern matching system that filters C header ASTs according to pattern rules and generates both a IDL file to make them CORBA callable, and C function wrappers to make them conform to the CORBA->C language mapping.

Here is the CORBA->C language mapping:

http://www.omg.org/technology/documents/formal/corba_language_mapping_specs.htm

Hey, as a bonus, if we solve this problem we build a machine for making arbitrary C code easily CORBA callable, a useful ability in its own right.  I have seen requests on CORBA lists for solutions to this problem.

Last time I tried to work on this, I got very frustrated just trying to find a IDL that would compile on Darwin.  Geesh.  I gues one of the things that happens when you build a layer that has an ability to translate every last type is you make a monster in its configure script.


Jeff Henrikson



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] swig like library...

[Brandon J. Van Every]

skaller wrote:
>
> However SWIG isn't very satisfactory.. I'm thinking of
> writing an Ocaml program for building wrappers.

What is so unsatisfactory about SWIG that you would start a new effort
and avoid improving SWIG?  SWIG provides interop between a number of
different languages, and as such is valuable to the open source
community.  What do you find so objectionable that you would Balkanize
things further?

What kinds of wrappers are you interested in?  A lot of people want C++
wrappers.  People who are shopping for new languages are generally stuck
with C++ and want a migration path.  Also various industrial APIs will
remain C++ for the forseeable future.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.643 / Virus Database: 411 - Release Date: 3/25/2004

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] swig like library...

[skaller]

On Sun, 2004-04-25 at 03:12, Brandon J. Van Every wrote:
> skaller wrote:
> >
> > However SWIG isn't very satisfactory.. I'm thinking of
> > writing an Ocaml program for building wrappers.
> 
> What is so unsatisfactory about SWIG that you would start a new effort
> and avoid improving SWIG? 

First, I do not have CVS access to SWIG,
and David Beazly has been singularly uncooperative
despite the promise in the release notice welcoming
contributors. 

(a) refused my language module

(b) refused to incorporate dynamic loading patch
which would have allowed independent development of it

(c) failed to fix minor preprocessing bug posted
to the bug tracker

Second, the technology used to implement it is very weak:
the core is written in very unsafe C in a style emulating
Python dynamic typing -- it doesn't even bother to use
ctors/dtors to manage memory. Many of the functions
are mutators when they should have been purely functional.

Thirdly, despite saying he is interested in input
automation, and despite working right now on C++ parsing,
SWIG is very weak on the input side. A significant
part of my SWIG language module spends its time
'undoing' or bypassing SWIG machinery.

My requirement is to automatically process a large number 
of C/C++ header files. When I say 'large' I really mean LARGE. 
I mean all the include files in /usr/include plus an arbitrary
collection of client specific files. Annotations are OK,
but not for every single function! The process must
be platform independent (that's the whole point of it).

I have no need for 90% of the Swig machinery.
Much of SWIG is devoted to type mapping, providing
functions to remodel class methods as functions
so they can be lifted into the target as method again.
Quite a bit focuses on  crossing complex API boundaries.
I have no need for any of that: my target language
uses the C/C++ object model directly. I don't need
'API interface glue' because my target generates C++
source code: its not an interpreter.

SWIG fails to handle BASIC conversions: there is no mechanism
for handling callbacks, for example. It isn't able
to pattern match well enough to detect distinctions
I require .. it actively gets in the way of some
of the ones I wish to detect.

The bottom line is: it isn't that hard to reach a point
where writing a C parser in Ocaml is easier than
hacking about with badly written C and an uncooperative
project manager .. especially when several Ocaml
projects already have a what would appear to be
a superior parser (eg the Cilly parser, which passes
exhaustive stress testing and handles GNU extensions).

Right now my own project is broken by this problem.
I need bindings for common libraries: a new
language is useless without a library.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] swig like library...

[art yerkes]

On 25 Apr 2004 06:11:56 +1000
skaller <skaller@users.sourceforge.net> wrote:

> On Sun, 2004-04-25 at 03:12, Brandon J. Van Every wrote:
> > skaller wrote:
> > >
> > > However SWIG isn't very satisfactory.. I'm thinking of
> > > writing an Ocaml program for building wrappers.
> > 
> > What is so unsatisfactory about SWIG that you would start a new effort
> > and avoid improving SWIG? 

SWIG has been burned before by adding too many languages too quickly. 
Ocaml probably wouldn't have been added as easily when you came as it was
earlier when I started my module.  Currently, we are essentially missing 
maintainers for TCL, php, and chicken scheme.  Obviously, the other
maintainers have to work harder when we need to make changes in SWIG's
core.  I do agree that dynamic loading would partially solve this problem,
by allowing modules to be pulled out into separate projects.

SWIG isn't strictly *for C*, it's for standard C++ and is not designed
to accept core C headers or GNU extensions (this is part of why it works
with incomplete type information, and missing includes).  It's assumed
that the language SWIG will process for already has a standard library,
even if it's not specifically stated.

I agree that the lack of further automation is a bottleneck for SWIG
users. I have considered forking some of the core type functions into the
ocaml module for that reason.
-- 
Hey, Adam Smith, keep your invisible hands to yourself!

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] swig like library...

[skaller]

On Sun, 2004-04-25 at 11:24, art yerkes wrote:
> On 25 Apr 2004 06:11:56 +1000
> skaller <skaller@users.sourceforge.net> wrote:
> 
> > On Sun, 2004-04-25 at 03:12, Brandon J. Van Every wrote:
> > > skaller wrote:
> > > >
> > > > However SWIG isn't very satisfactory.. I'm thinking of
> > > > writing an Ocaml program for building wrappers.
> > > 
> > > What is so unsatisfactory about SWIG that you would start a new effort
> > > and avoid improving SWIG? 
> 
> SWIG has been burned before by adding too many languages too quickly. 

Yes, I think it is bloated. 

I discussed inclusion of my module with David and suggested
a dynamic loading solution would be an option I would find
acceptable, and he prefered this option: I have no
problem with that, Felix *is* a new language.

I submitted a patch. But he didn't incorporate it.

I think the whole system should be reorganised so the core SWIG
builds independently of ANY language module (except perhaps
an XML or debugging output module), and each language module
should be an independent 'add on' in a separate CVS module.

This reorganisation would be more work. But just adding dynamic loading
would have taken about 1/2 an hour.

>  I do agree that dynamic loading would partially solve this problem,
> by allowing modules to be pulled out into separate projects.

So does David .. so why doesn't he just apply my patch?

> SWIG isn't strictly *for C*, it's for standard C++ and is not designed
> to accept core C headers or GNU extensions (this is part of why it works
> with incomplete type information, and missing includes).  It's assumed
> that the language SWIG will process for already has a standard library,
> even if it's not specifically stated.

Unfortunately that isn't correct. SWIG has an option to
follow all includes.. and it stupidly delves into system
headers when it does. 

Without this option, you can't follow nested includes that
you DO need to follow to get enough information: quite a few
GNU headers just #include other ones (eg gtk.h).

The workaround of including things manually is a pain,
and only works for one level ..

I could fix this easily. If I had CVS access..

> I agree that the lack of further automation is a bottleneck for SWIG
> users.

Most SWIG users don't seem to care: they have to make
typemaps and things anyhow, so they can always just
write out the interfaces by hand: that still saves a HEAP
of work compared to hand writing the wrappers for an Ocaml
or Python binding.

However there are some of us that need to process
larger headers 'as is' without being able to modify them,
and where it is impractical to assume they're stable
and so can't be copied: for some people because they're
wrapping 'in development' libraries, and others, such
as me, because the wrapper annotations have to work
on a large number of distinct platforms.

>  I have considered forking some of the core type functions into the
> ocaml module for that reason.

That's basically what I did. But I can't hook everything
I need to: some libraries, for example gmp, provide
'convenience' macros I can't see precisely because they're macros.
I also depend on 'details of the implementation' that could
be changed at any time.

In other cases it is frustrating: I have developed
a technique for automating callback handling, which
is something useful to all language users, and am unable
to share the technology -- sharing is useful to me
for the usual reason: user feedback improves quality,
and also makes me feel good contributing something useful :)

The bottom line is: I can't distribute wrapper generation
technology for Felix at the moment without redistributing
a copy of SWIG. Which is a not an acceptable solution.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: swig like library...

[Jeff Henrikson]

> I think the whole system should be reorganised so the core SWIG
> builds independently of ANY language module (except perhaps
> an XML or debugging output module), and each language module
> should be an independent 'add on' in a separate CVS module.

> > SWIG isn't strictly *for C*, it's for standard C++ and is not designed
> > to accept core C headers or GNU extensions (this is part of why it works
> > with incomplete type information, and missing includes).  It's assumed

GCC can output its own XML tree.

http://www.gccxml.org/HTML/Index.html

(I wish this would get incorporated into the main branch.)

When I set up Forklift the way I have, I never envisioned C++ to be a grammar to base a wrapper generator on.  C++ does not expand the ABI of C.  Just the syntax.  I pictured writing a preprocessing front end to get C++ into a C library.  In the old days of C++, many libraries included these C headers as a matter of course.  (Eg: OpenInventor from SGI)  That transformation, unlike wrapper generation, _is_ well defined from only the information given in the header files.

This approach would place on equal grounds Oop styled C libs (eg: GTK) from Oop syntaxed C++ libs (eg: OpenInventor).


Jeff Henrikson


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners