[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

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

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

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

[HENRIKSON, JEFFREY]

Perhaps you mean Forklift?

http://jhenrikson.org/forklift

It attempts to be a more well behaved SWIG.  To my knowledge, I started
the first attempt at a SWIG library.  I got frustrated with the
infrastructure and quit.  Since then there have been at least 2 other
attempts for ocaml swig support and recently I noticed there an official
"ocaml swig".  Anyway, you can read about my complaints and my
alternatives.

Forklift is still very alpha.  The code generation stuff has all been
implemented.  There is a demo to showing how that part can be used by
itself, but it's not nearly as useful as the completed project will be.
What remains to be done is the pattern matching engine.  Sorry but I
started a new job and temporarily suspended development of the first
forklift based application.  I'd be happy to collaborate if somebody
wants to contribute to the pattern matching part.

Please reply to jehenrik@yahoo.com.


Jeff Henrikson







-----Original Message-----
From: owner-caml-list@pauillac.inria.fr
[mailto:owner-caml-list@pauillac.inria.fr] On Behalf Of Michael
Sent: Friday, April 23, 2004 7:36 AM
To: caml-list
Subject: [Caml-list] swig like library...

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

[art yerkes]

On Fri, 23 Apr 2004 08:48:14 -0700
"HENRIKSON, JEFFREY" <JEFHEN@SAFECO.com> wrote:

> It attempts to be a more well behaved SWIG.  To my knowledge, I started
> the first attempt at a SWIG library.  I got frustrated with the
> infrastructure and quit.  Since then there have been at least 2 other
> attempts for ocaml swig support and recently I noticed there an official
> "ocaml swig".  Anyway, you can read about my complaints and my
> alternatives.

I chose to throw in with the SWIG project mainly because I had a C++
component library and no way of automatically wrapping it (About 200
classes, 800 methods).  I did not want to produce another wrapper
generator that takes a non-C++ input, nor do the wrapping by hand.

SWIG does have infrastructure problems.  It's really meant for generating
wrappers for typeless languages.  My first attempt at the SWIG module was
not general enough, which is why I took the approach of making the SWIG
output treat ocaml as a scripting language, too.  As far as I know, it's
the only project out there with as well developed a C++ reader (It
processes most C++ headers unmodified), and I'd recommend using it's s-exp
or xml output as a foundation for further work on wrapping, even if you
use nothing else from it.  That part has been tuned through experience,
and lots of the decisions that need to be taken are not covered by the C++
standard.

If others are interested in the module, I'm always willing to listen to
suggestions and take patches.
-- 
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