Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Is Caml a fraud ( especially on Windows )?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Sven Luther <luther@d...>
Subject: Re: [Caml-list] Is Caml a fraud ( especially on Windows )?
On Fri, Oct 18, 2002 at 03:42:05PM +0000, Thaddeus L. Olczyk wrote:
> On Fri, 18 Oct 2002 12:56:17 +0200, Sven Luther
> <luther@dpt-info.u-strasbg.fr> wrote:
> 
> >On Fri, Oct 18, 2002 at 09:35:34AM +0000, Thaddeus L. Olczyk wrote:
> >> The second incident involves ocamlc and cameleon. Trying to get
> >> cameleon to compile ( more on that later ), I discovered that ocamlc
> >> called cl.exe ( MS C/C++ compiler ). The reason is obvious. ocamlc
> >> translates ocaml to c and then passes it to the compiler. This creates
> >> two things I have difficulties with:
> >
> >I don't understand what you are talking about, ocamlc generates
> >bytecode which gets interpreted in a virtual machine, not c, or
> >something such, and ocamlopt generates native code, that is assembly
> >which needs to be assembled by an assembler (gasm on linux/unix, and a
> >windows assembler on windows). The bytecode you compile on unix should
> >run without problem on the windows virtual machine (ocamlrun), provided
> >you don't use the -custom flag to ocamlc.
> >
> But then why does it call cl.exe?

As was explained in another mail, it is used to build C files. When you
interface with a C library, you first have to write something called a
stub library, which is a kind of smallish C code which wraps the C
library calls to interact correctly with ocaml.
D> 
> >Maybe you should try using only ocamlopt.
> >
> But then why does cameleon use ocamlc?
> Obviously you want to use ocamlc when debugging,
> but I would think there are Debug and Release versions in
> the make. If so then why is Debug the default ( and why isn't it in
> the documentation)?

Well, the debugger only works on bytecode.

But if you would use a normal build system, you would just have to
change a variable or something such to rebuild the same source to
bytecode or nativecode. I use two different makefile targets to do so.
so you can run the bytecode version, it works well most of the time, and
if you really need the extra performance, you can rebuild with ocamlopt.

> >That said, there are a few library which are only bindings to C code
> >(the FFI you spoke about previously) and which need a C compiler. But
> >once they are compiled, you can use them without problems.
> What do you need the compiler for?
> To build the C library or to actually build the bindings?

Explained above, and please read the chapter of the ocaml doc about C
binding, and you will understand this.

> This seems to be adding to my rants.

Please, make informed rants, you were told two times already to read the
docs before ranting, why do you not do it ?

> When I asked about FFI, I asked whether you need to recompile ocaml.
> ( Something you have to do with some languages--eg Python. I'm not big
> fan of recompiling things. ) I was told no. I should have been told
> something like "not the whole thing, but you do need to compile the
> bindings". )

This is stupid.

The ocaml suite is composed of the two compilers and the toplevel plus
assorted tools. In addition there is the pervasive library (builtin) and
the standard library. All of this is built with ocaml, and don't need
any kind of C, except for the bootstraping phase (well you need an ocaml
compiler to compile ocaml).

Additionally there is a serie of libraries included in the ocaml suite
(otherlibs) where some may need C for performance or compatibility or
what have you.

If you want to add support for another C library, like gtk+ for example,
you need to write the stubs, which are C function wrapping the C
library, and then have the ocaml library making calls to this stups. 

This is all done externally, no need to rebuild the ocaml compiler to do
it.

> >Check again your facts, the ocaml reference manual clearly says that :
> >
> >This chapter (16) describes the Objective Caml source-level replay debugger
> >ocamldebug.
> >
> >  Unix:
> >    The debugger is available on Unix systems that provides BSD sockets.
> >  Windows:
> >    The debugger is available under the Cygwin port of Objective Caml, but
> >    not under the native Win32 port.   
> >
> >So, you would like to install the cygwin port, and you get access to the
> >debugger.
> >
> Ok. But why. IIRC the cygwin stuff you have to compile yourself. (
> Something I am loathe to do, especially since I see some people have
> had problems. )  

Yes, i think INRIA could make a cygwin binary distribution available for
download.

> I can see that the Win32 port is "crippled".  When I assumed that

Because windows is an inferior plateform which does not provide all the
stuff needed to easily port all of the unix libraries and
functionalities, not to speak about the assembler. So it is much easier
to use cygwin.

> the compile used a C compiler, it made sense--cygwin creates code
> that is significantly slower. But if ocamlopt generates native code
> then the speed of the executables produced should be the same speed in
> both ports. So then why distribute the Win32 port as the main port?

Because people like to use MSVC++ as their IDE, because the cygwin port
is more recent than the native port.

> >> Am I going to discover that a prepackaged library doesn't work
> >
> >And here is your error, these are _not_ prepackaged libraries.
> >
> No but about nine months ago I tried ocaml very briefly. I had
> a set of programs I had to write which basically encapsulated
> database with little processing. It seemed like the perfect
> opportunity to try out a new language because it involved little
> actual coding. At the time the dbm library was unavaile ( on Linux ).

Well, that is totally wrong.

I have been building debian ocaml packages since 1997, and gdbm has been
available since then, the first dated changelog entry of the libgdbm1
debian packages even goes back to version 1.7.3-11.1 on Fri, 13 Dec 1996.
Earlier dates are lost because the changelog entries were not dated
previous to this one.

Anyway, what linux distribution are you using, and are you sure you set
it up correctly ? I would strongly suggest you install debian, and try :

apt-get install ocaml liblablgtk-ocaml-dev cameleon

(you have to track unstable though for cameleon, since it was just
packaged) 
And you will have a working setup and no need to bother everyone by
petty complaints.

Friendly,

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