From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA17081; Fri, 18 Oct 2002 18:43:23 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA17390 for ; Fri, 18 Oct 2002 18:43:22 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from athlon.baretta.com ([62.211.4.138]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g9IGhKD14497 for ; Fri, 18 Oct 2002 18:43:21 +0200 (MET DST) Received: from baretta.com (localhost.localdomain [127.0.0.1]) by athlon.baretta.com (Postfix) with ESMTP id 6FDA527250; Fri, 18 Oct 2002 18:54:02 +0200 (CEST) Message-ID: <3DB03CAA.8080202@baretta.com> Date: Fri, 18 Oct 2002 18:54:02 +0200 From: Alessandro Baretta Organization: Baretta srl -- www.baretta.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: it, en MIME-Version: 1.0 To: olczyk@interaccess.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] Is Caml a fraud ( especially on Windows )? References: <3daf2a4f.865261093@smtp.interaccess.com> <20021018105617.GA4848@iliana> <3db1215f.928509171@smtp.interaccess.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Thaddeus L. Olczyk wrote: > On Fri, 18 Oct 2002 12:56:17 +0200, Sven Luther > wrote: > >> > > But then why does it call cl.exe? To support linking with C libraries. >>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)? This has nothing to do with debugging: ocamlc compiles to bytecode, which is fast and guarantees a very high degree of portability; ocamlopt produces native code. This requires an assembler and a linker from a C compiler. The linker is platform-specific and makes native executables not portable, although the code can be recompiled with absolutely no differences on all supported platforms. >>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. In order to link to C code you must first write special C functions called "stubs" (Java might be a good choice as your next language, so that you may discover that such functions exist elsewhere, too). Stubs are necessary to pass data back and forth from caml functions in a way compatible with the caml runtime, debugger and calling conventions. > 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. ) Very well. If you are unable to use Cygwin get yourself a Debian distro and you won't have to compile anything at all. Sven is the one who does the job for you. > 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? Don't blame the Caml team if Windows is crippled OS. Cygwin uses gcc to generate code. So Cygwin code is neither faster nor slower than equivalent gcc code under Linux. However, Cygwin code is linked with a POSIX emulation library which runs on top of the standard Win32 C library and kernel. This is less efficient than linking directly with a POSIX conformat c library like glibc. >>>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 ). You want the a library? Then, please, go on and write the stubs for it. Everybody will be thankful to you. You wanna rant about it. Then go on ranting till you please, but it's not going to serve much, either to you or to anybody else. Alex ------------------- 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