[Caml-list] swig like library...

[Caml-list] swig like library...

[Michael]

some time ago there was a library announced here on the list, which is similar 
to swig. I have no clue how it was named and so cannot find it. Does anybody 
know that lib?

thanks,
 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

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

[Richard Jones]

On Fri, Apr 23, 2004 at 04:36:07PM +0200, Michael wrote:
> some time ago there was a library announced here on the list, which
> is similar to swig. I have no clue how it was named and so cannot
> find it. Does anybody know that lib?

Swig itself exists for OCaml ...

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MOD_CAML lets you run type-safe Objective CAML programs inside the Apache
webserver. http://www.merjis.com/developers/mod_caml/

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

[Kenneth Knowles]

Maybe you are referring to CamlIDL?

http://caml.inria.fr/camlidl/

Kenn

On Fri, Apr 23, 2004 at 04:36:07PM +0200, Michael wrote:
> some time ago there was a library announced here on the list, which is similar 
> to swig. I have no clue how it was named and so cannot find it. Does anybody 
> know that lib?
> 
> thanks,
>  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

-------------------
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 Sat, 2004-04-24 at 00:36, Michael wrote:
> some time ago there was a library announced here on the list, which is similar 
> to swig. I have no clue how it was named and so cannot find it. Does anybody 
> know that lib?

There is an Ocaml module in SWIG (Author: A. Yerkes)
There is also a tool for generating wrappers from
MS-IDL (Author: X. Leroy).

However SWIG isn't very satisfactory.. I'm thinking of
writing an Ocaml program for building wrappers.
There is a C parser which perhaps can be used.
A preprocessor is needed. The SWIG back end model
just uses a class which should be easy.

Any interest in an Ocaml based SWIG like tool?

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

[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

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

[Yamagata Yoriyuki]

From: art yerkes <ayerkes@speakeasy.net>
Subject: Re: [Caml-list] swig like library...
Date: Sat, 24 Apr 2004 20:24:43 -0500

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

I think swig is nice.  It does the supposed job, quick and dirty
interface to C.

I have only minor complaints.  First, the access to structure fields
involves searching assoc lists, using string as a key.  As a result,
my program spends a lot of time in comparing strings.  A possible and
easy improvement is making access functions for structure fields
accessible from the outside.

Another problem, which may not be a swig problem, is that my program
occasionally crash.  malloc in a structure creation function (new_*)
causes seg fault.  Could you give me a suggestion where I have to
look?

--
Yamagata Yoriyuki

-------------------
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 19:11, Yamagata Yoriyuki wrote:
> From: art yerkes <ayerkes@speakeasy.net>
> Subject: Re: [Caml-list] swig like library...
> Date: Sat, 24 Apr 2004 20:24:43 -0500
> 
> > 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.
> 
> I think swig is nice.  It does the supposed job, quick and dirty
> interface to C.

But that isn't what I need. I need a complete fully functional
interface to GTK, GMP, Xlib, Freetype, Pango,  ... blah blah ..
 ... all generated automatically for any available installation 
using distributed *immutable* annotation files.

Hand crafting this number of wrappers -- and getting 
a portable result -- just isn't an option. Hand crafting
annotation files can be made to work. I can actually

(a) call some GDK functions
(b) use callbacks successfully

-- 
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 Sun, 25 Apr 2004 18:11:00 +0900 (JST)
Yamagata Yoriyuki <yoriyuki@mbg.ocn.ne.jp> wrote:

> From: art yerkes <ayerkes@speakeasy.net>
> Subject: Re: [Caml-list] swig like library...
> Date: Sat, 24 Apr 2004 20:24:43 -0500
> 
> > 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.
> 
> I think swig is nice.  It does the supposed job, quick and dirty
> interface to C.
> 
> I have only minor complaints.  First, the access to structure fields
> involves searching assoc lists, using string as a key.  As a result,
> my program spends a lot of time in comparing strings.  A possible and
> easy improvement is making access functions for structure fields
> accessible from the outside.
> 
> Another problem, which may not be a swig problem, is that my program
> occasionally crash.  malloc in a structure creation function (new_*)
> causes seg fault.  Could you give me a suggestion where I have to
> look?

Please send me more details privately about the crash.  That may indeed
be a bug in my module.

You make a good point about method lookup, I will make that faster.
In order to make the accessors for structs available outside the object,
I would have to decorate some names in ugly, and possibly difficult to
remember ways.  I wonder if you (or other SWIG users) have any suggestions
which would eliminate that or make it easier.

The simplest way I considered was to have a repository of method names, as
I do with enum labels:

type methods_of_foo = [ `Constructor | `Foo | `foo | `_foo | `fOo ... 
                      | `operatorLessThanOrEqual ]

And then do the obvious thing in the method call function.  This means
that code written without camlp4 will be much uglier, and that you may
have to cast your method names.  The operators will also be uglified.

I could make member variable accessors different from the methods...
Would that be desirable?
-- 
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

[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

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

[Yamagata Yoriyuki]

From: art yerkes <ayerkes@speakeasy.net>
Subject: Re: [Caml-list] swig like library...
Date: Mon, 26 Apr 2004 10:17:46 -0500

> 
> Please send me more details privately about the crash.  That may indeed
> be a bug in my module.

I lost the ocaml part of the code, so I could not help.  (I will
rewrite everything in C) And the problem is hard to reproduce.

However, I found the symptom worsens when I add a finalization
function to a structure.  Does swig pass a C pointer directly to a ml
value, and add its own finalization function to a structure?  This
would corrupt the C heap, and thus explains the symptom.

If any chance swig does like this, then you perhaps would want C
pointers wrapped by custom blocks.

> The simplest way I considered was to have a repository of method names, as
> I do with enum labels:
> 
> type methods_of_foo = [ `Constructor | `Foo | `foo | `_foo | `fOo ... 
>                       | `operatorLessThanOrEqual ]
> 
> And then do the obvious thing in the method call function.  This means
> that code written without camlp4 will be much uglier, and that you may
> have to cast your method names.  The operators will also be uglified.

Assign ids to method names (Polymorphic variant work too), and
associate them to method functions by Hashtbl?  The current design of
"invoke" (?) does not need to change, since invoke will translate a
method name to its id.  Camlp4 could translate a method name to id by
the compilation time as an optimization.

--
Yamagata Yoriyuki

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

[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