Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Sven Luther <luther@dpt-info.u-strasbg.fr>]

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.

Maybe you should try using only 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.

> 1) There is from the main caml page a link to a page where the person
>      claims to have benchmarked C vs caml and caml wins. I had several
> 
>      problems with that page, ( The main one, he uses goto's to 
>      optimise his code. The problem is that the optimiser in a C  
>      compiler has a much harder time with goto's present [ they are 
>      nonlocal branches ]. So I have to trust he does a better job at 
>      optimisation than the compiler would do. Yeah sure. )  but 
>      learning that caml generates C code as an intermediate language 
>      makes his statement false. If caml generates C that creates an 
>      executable, then caml code can never run faster than C.

Well, since ocaml doesn't generate C that is compiled, maybe you should
revise your conclusion. Well, there was a caml->C compiler available
some time ago, but it is _not_ the same thing as ocaml.

> 2) After a bit of thought I realised something. If the compiler 
>     generates C code which gets compiled, then odds are that the
>     debugger is a wrapper of gdb. Big problems on Windows. This
>     may indicate that there is no debugger for Windows. Sure enough
>     ocamldebug is not present. There is the source for ocamldebug in
>     cameleon, but who knows if it compiles.

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.

> The third incident was trying to get cameleon to compile on Windows.

Well, you should not judge the performance of ocaml on windows, by the
behavior of a rather recent library/app like cameleon, which had also
problems on unix/linux.

> And how can I trust caml people to tell me the truth, when they've
> lied to now?

Did they really lie ? I don't think so, 

> Am I going to discover that a prepackaged library doesn't work

And here is your error, these are _not_ prepackaged libraries.

But then, i am the debian maintainer for ocaml, and may have to big
opinions about what a packaging system is, and there is nothing such on
windows, so you are screwed and need to rebuild things, which can be
difficult. But then, there are numerous reports of other people doing
it, so you should beable to do so also.

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