English version
Accueil     Ŕ propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis ŕ jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml ŕ l'adresse ocaml.org.

Browse thread
Road to native windows OCaml...
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-10-14 (19:39)
From: Adrien <camaradetux@g...>
Subject: Re : [Caml-list] Re: Re : Re: Re : Road to native windows OCaml...
2008/10/14, Sylvain Le Gall <sylvain@le-gall.net>:
> On 14-10-2008, Adrien <camaradetux@gmail.com> wrote:
>> 2008/10/14, Sylvain Le Gall <sylvain@le-gall.net>:
>>> On 14-10-2008, Adrien <camaradetux@gmail.com> wrote:
>>>> 2008/10/14, Daniel Bünzli <daniel.buenzli@erratique.ch>:
>>>>> Le 14 oct. 08 ŕ 09:59, David Allsopp a écrit :
>>> Another information, I have various benchmark on cygwin. My conclusion
>>> was not what i have expected. Most of the time cygwin runtime has a good
>>> speed. This is not so slow in fact. I think most of the slowness you can
>>> see is because you are working in a MSDOS/emulated X terminal which
>>> seems slow (but is not, this is just a question of refresh rate).
>>> Seriously, cygwin is not that bad. I would still not recommend using it
>>> for various other reasons.
>> Indeed, runtime has no reason to be affected as long as it's not using
>> external libraries, typically -lws2_32, winsock2). The point is really
>> startup.
>> As for terminal slowness, my computer boots in 16 seconds under linux.
>> I recompiled my kernel yesterday and activated PRINTK_TIME/Show timing
>> information on printks, it gives you the time a kernel message was
>> emitted, related to startup. At the end of the boot, the kernel was
>> giving times 3 seconds better than an independent chronometer. There
>> had been enough things to write on the console for message to take 3
>> seconds to be displayed. Displaying on a terminal is slooow
>> everywhere, not just windows.
> In fact, I cannot really prove what I say, but MSDOS shell windows seems
> to refresh less frequently, giving you a strange feeling that something
> is blocked. It is not a question of being slow but SEEMING to be slow.
> I mean you spend the same amount of time but you get results sooner in
> linux console than in MSDOS. At the end of the process, the chronometer
> is at the same time, but with MSDOS you have the feeling to have spend
> more time.
> I think that the refresh rate of MSDOS is over 125 ms (ergonomic limit
> time to feel that something is not stalled).

Under cygwin, it would take from 1 to 2 seconds to get one line
further in a configure script, so definitely not this

>> Also, I don't think cygwin is bad. I just think it is not the
>> appropriate answer for most of us. IMHO msys/mingw is a better
>> *approach*, however their shell implementation is bastard. They
>> decided to support both forward and backward slashes for instance,
>> this has the awful consequence of giving you "not found" errors when
>> using /c/gnu/msys/home/Adrien/icu\\source (personal experience). That
>> is however something at the msys level, not the mingw one.
> +10 points, "/" and "\\" (and " " for all OS) in pathname is a big pain.
> Spend many hours debugging scripts.
> Another big problem: "\n" in cygwin. For example if you use
> ocamlfind ocamlc -pp "camlp4 `ocamlfind query -a-format sexplib`"
> You are in trouble, because "\r" will pops up in the resulting command
> line not being interpreted by the shell as space....

At some point I thought about making a new shell, with much more
strictness. I'd prefer cross-compilation but if it's not possible,
that would maybe be a good thing, even though it really scares me.


Adrien Nader

> Regards,
> Sylvain Le Gall
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs