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

[olczyk@interaccess.com (Thaddeus L. Olczyk)]

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?

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

>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?
This seems to be adding to my rants.
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". )

>
>> 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.
Yes.
>
>> 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.
>
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. )  
I can see that the Win32 port is "crippled".  When I assumed that
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?

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

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