* Road to native windows OCaml...
@ 2008-10-13 23:35 Kuba Ober
2008-10-13 23:47 ` [Caml-list] " Seo Sanghyeon
` (5 more replies)
0 siblings, 6 replies; 44+ messages in thread
From: Kuba Ober @ 2008-10-13 23:35 UTC (permalink / raw)
To: caml-list
I've looked briefly at what it'd take to have OCaml
fully working natively (with mingw/VS), without any Cygwin
needed for compilation.
What I've surmised is this:
1. I need some "hacked up" make implementation, good enough just
to let it build; this would be a-la web2c in concept. This "make"
would implement bits and pieces of make, bash and sed -- just
the bare minimum needed to get it going. The goal is for people to
have bare mingw or VC and have OCaml build for them.
The functionality needed is quite minimal, so requiring people to
actually pull full sed, bash and make would not be necessary.
I would prototype it in Qt (it's quicker that way),
and then port it to "bare" C++ as time permits.
2. I need to get OCaml to use nasm instead of masm. I would go as far
as completely pruning any masm references from OCaml -- there is just
no need for masm when a good, free alternative exists. nasm is a single
standalone executable -- you can't get much better than that. Heck, it
works on unixes too, so it could be used on all platforms. gas is horrible
too -- it's only raison-d'etre is to process output from gcc.
Masm exists in "alternate reality" and the legality of its use is dubious.
So-called masm9/masm10 (non-Microsoft products) have licenses which are a
slap in the face and don't deserve a second look.
3. I need to look at the bytecode debugger and figure out why doesn't it work
on non-Cygwin builds.
4. I need to get OCaml to generate C binding code using assembly, without a
need for C compiler. It's easy enough and removes one big dependency from
OCaml. I don't know if OCaml side of things is expressive enough (whether
you can pass parameter/struct descriptions without use of C per se),
but it should generally work just fine.
Can anyone add to/elaborate on this list?
Cheers, Kuba
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [Caml-list] Road to native windows OCaml... 2008-10-13 23:35 Road to native windows OCaml Kuba Ober @ 2008-10-13 23:47 ` Seo Sanghyeon 2008-10-14 21:32 ` Kuba Ober 2008-10-14 5:43 ` Elliott Oti ` (4 subsequent siblings) 5 siblings, 1 reply; 44+ messages in thread From: Seo Sanghyeon @ 2008-10-13 23:47 UTC (permalink / raw) To: Kuba Ober; +Cc: caml-list 2008/10/14 Kuba Ober <kuba@mareimbrium.org>: > 2. I need to get OCaml to use nasm instead of masm. I would go as far > as completely pruning any masm references from OCaml -- there is just > no need for masm when a good, free alternative exists. nasm is a single > standalone executable -- you can't get much better than that. Heck, it > works on unixes too, so it could be used on all platforms. gas is horrible > too -- it's only raison-d'etre is to process output from gcc. nasm is x86-only, so it couldn't be used on all platforms. -- Seo Sanghyeon ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Road to native windows OCaml... 2008-10-13 23:47 ` [Caml-list] " Seo Sanghyeon @ 2008-10-14 21:32 ` Kuba Ober 2008-10-15 9:42 ` David Allsopp 0 siblings, 1 reply; 44+ messages in thread From: Kuba Ober @ 2008-10-14 21:32 UTC (permalink / raw) To: caml-list On Monday 13 October 2008, Seo Sanghyeon wrote: > 2008/10/14 Kuba Ober <kuba@mareimbrium.org>: > > 2. I need to get OCaml to use nasm instead of masm. I would go as far > > as completely pruning any masm references from OCaml -- there is just > > no need for masm when a good, free alternative exists. nasm is a single > > standalone executable -- you can't get much better than that. Heck, it > > works on unixes too, so it could be used on all platforms. gas is > > horrible too -- it's only raison-d'etre is to process output from gcc. > > nasm is x86-only, so it couldn't be used on all platforms. masm is too, right? I'm looking for a free replacement to masm/gas on x86. Cheers, Kuba ^ permalink raw reply [flat|nested] 44+ messages in thread
* RE: [Caml-list] Road to native windows OCaml... 2008-10-14 21:32 ` Kuba Ober @ 2008-10-15 9:42 ` David Allsopp 2008-10-15 12:38 ` Kuba Ober 0 siblings, 1 reply; 44+ messages in thread From: David Allsopp @ 2008-10-15 9:42 UTC (permalink / raw) To: caml-list Kuba Ober write: > On Monday 13 October 2008, Seo Sanghyeon wrote: > > 2008/10/14 Kuba Ober <kuba@mareimbrium.org>: > > > 2. I need to get OCaml to use nasm instead of masm. I would go as far > > > as completely pruning any masm references from OCaml -- there is > > > just no need for masm when a good, free alternative exists. nasm is > > > a single standalone executable -- you can't get much better than > > > that. Heck, it works on unixes too, so it could be used on all > > > platforms. gas is horrible too -- it's only raison-d'etre is to > > > process output from gcc. > > > > nasm is x86-only, so it couldn't be used on all platforms. > > masm is too, right? I'm looking for a free replacement to masm/gas on x86. > > Cheers, Kuba AFAIK masm is part of the Windows DDK so it has to be x64! And the top link googling masm x64... http://msdn.microsoft.com/en-us/library/hb5z4sxd(VS.80).aspx ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Road to native windows OCaml... 2008-10-15 9:42 ` David Allsopp @ 2008-10-15 12:38 ` Kuba Ober 2008-10-15 13:04 ` Seo Sanghyeon 0 siblings, 1 reply; 44+ messages in thread From: Kuba Ober @ 2008-10-15 12:38 UTC (permalink / raw) To: caml-list On Wednesday 15 October 2008, David Allsopp wrote: > Kuba Ober write: > > On Monday 13 October 2008, Seo Sanghyeon wrote: > > > 2008/10/14 Kuba Ober <kuba@mareimbrium.org>: > > > > 2. I need to get OCaml to use nasm instead of masm. I would go as far > > > > as completely pruning any masm references from OCaml -- there is > > > > just no need for masm when a good, free alternative exists. nasm is > > > > a single standalone executable -- you can't get much better than > > > > that. Heck, it works on unixes too, so it could be used on all > > > > platforms. gas is horrible too -- it's only raison-d'etre is to > > > > process output from gcc. > > > > > > nasm is x86-only, so it couldn't be used on all platforms. > > > > masm is too, right? I'm looking for a free replacement to masm/gas on > > x86. > > > > Cheers, Kuba > > AFAIK masm is part of the Windows DDK so it has to be x64! Installing DDK is kind of a long shot. I certainly don't have it installed, even though I use Visual Studio daily. For ia32, OCaml should use nasm where it previously used masm, that's about all I wish for. For ia64, I don't care much, and if DDK provides masm-x64 then that's probably good enough. Cheers, Kuba ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Road to native windows OCaml... 2008-10-15 12:38 ` Kuba Ober @ 2008-10-15 13:04 ` Seo Sanghyeon 2008-10-15 14:32 ` Kuba Ober 0 siblings, 1 reply; 44+ messages in thread From: Seo Sanghyeon @ 2008-10-15 13:04 UTC (permalink / raw) To: Kuba Ober; +Cc: caml-list 2008/10/15 Kuba Ober <kuba@mareimbrium.org>: > For ia64, I don't care much, and if DDK provides masm-x64 then that's probably > good enough. x64 usually means x86_64, not ia64. -- Seo Sanghyeon ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Road to native windows OCaml... 2008-10-15 13:04 ` Seo Sanghyeon @ 2008-10-15 14:32 ` Kuba Ober 0 siblings, 0 replies; 44+ messages in thread From: Kuba Ober @ 2008-10-15 14:32 UTC (permalink / raw) To: caml-list On Wednesday 15 October 2008, Seo Sanghyeon wrote: > 2008/10/15 Kuba Ober <kuba@mareimbrium.org>: > > For ia64, I don't care much, and if DDK provides masm-x64 then that's > > probably good enough. > > x64 usually means x86_64, not ia64. Even so, 64 bit is out of my scope at this moment. Cheers, Kuba ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Road to native windows OCaml... 2008-10-13 23:35 Road to native windows OCaml Kuba Ober 2008-10-13 23:47 ` [Caml-list] " Seo Sanghyeon @ 2008-10-14 5:43 ` Elliott Oti 2008-10-14 21:35 ` Kuba Ober 2008-10-14 7:20 ` Sylvain Le Gall ` (3 subsequent siblings) 5 siblings, 1 reply; 44+ messages in thread From: Elliott Oti @ 2008-10-14 5:43 UTC (permalink / raw) To: caml-list Ocaml works fine on windows with the mingw and msys toolchain. Cygwin is not needed. What you are doing with (1) and (2) would be duplicating msys. With regards to (4), you need at the very least to be able to parse header files correctly, & provide link stubs. This would again be duplicating parts of the mingw toolchain. In addition, binding to C code is not just a matter of wrapping the bare C functions. First C function declarations are underspecified (is char* a string? is int* an array of ints or a pointer to an in-out parameter? How long is the array?). Second, C types do not always match easily to ML types (converting C to ML is easy, the other way round is often harder). Third, it is often necessary to do extra processing in an FFI function i.e. between receiving the ocaml parameters and calling the c function. (3) would be nice, though. And fleshing out the non-functional win32 stubs in the Unix library (fork etc). Regards, Elliott Kuba Ober wrote: > I've looked briefly at what it'd take to have OCaml > fully working natively (with mingw/VS), without any Cygwin > needed for compilation. > > What I've surmised is this: > > 1. I need some "hacked up" make implementation, good enough just > to let it build; this would be a-la web2c in concept. This "make" > would implement bits and pieces of make, bash and sed -- just > the bare minimum needed to get it going. The goal is for people to > have bare mingw or VC and have OCaml build for them. > The functionality needed is quite minimal, so requiring people to > actually pull full sed, bash and make would not be necessary. > I would prototype it in Qt (it's quicker that way), > and then port it to "bare" C++ as time permits. > > 2. I need to get OCaml to use nasm instead of masm. I would go as far > as completely pruning any masm references from OCaml -- there is just > no need for masm when a good, free alternative exists. nasm is a single > standalone executable -- you can't get much better than that. Heck, it > works on unixes too, so it could be used on all platforms. gas is horrible > too -- it's only raison-d'etre is to process output from gcc. > Masm exists in "alternate reality" and the legality of its use is dubious. > So-called masm9/masm10 (non-Microsoft products) have licenses which are a > slap in the face and don't deserve a second look. > > 3. I need to look at the bytecode debugger and figure out why doesn't it work > on non-Cygwin builds. > > 4. I need to get OCaml to generate C binding code using assembly, without a > need for C compiler. It's easy enough and removes one big dependency from > OCaml. I don't know if OCaml side of things is expressive enough (whether > you can pass parameter/struct descriptions without use of C per se), > but it should generally work just fine. > > Can anyone add to/elaborate on this list? > > Cheers, Kuba > > _______________________________________________ > 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 > > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Road to native windows OCaml... 2008-10-14 5:43 ` Elliott Oti @ 2008-10-14 21:35 ` Kuba Ober 0 siblings, 0 replies; 44+ messages in thread From: Kuba Ober @ 2008-10-14 21:35 UTC (permalink / raw) To: caml-list On Tuesday 14 October 2008, Elliott Oti wrote: > Ocaml works fine on windows with the mingw and msys toolchain. Cygwin is > not needed. What you are doing with (1) and (2) would be duplicating msys. Well, maybe (1) is not needed, then, but (2) surely wouldn't hurt as OCaml tries to use masm. Maybe it should simply try to use nasm if present, as it should accept same input, just different command line options. > With regards to (4), you need at the very least to be able to parse > header files correctly, & provide link stubs. This would again be > duplicating parts of the mingw toolchain. Should we not have something like most Lisps' foreign function interfaces, where we actually specify everything natively (in Ocaml)? > (3) would be nice, though. And fleshing out the non-functional win32 > stubs in the Unix library (fork etc). Yup. Cheers, Kuba ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Road to native windows OCaml... 2008-10-13 23:35 Road to native windows OCaml Kuba Ober 2008-10-13 23:47 ` [Caml-list] " Seo Sanghyeon 2008-10-14 5:43 ` Elliott Oti @ 2008-10-14 7:20 ` Sylvain Le Gall 2008-10-14 21:37 ` [Caml-list] " Kuba Ober 2008-10-14 7:59 ` [Caml-list] " David Allsopp ` (2 subsequent siblings) 5 siblings, 1 reply; 44+ messages in thread From: Sylvain Le Gall @ 2008-10-14 7:20 UTC (permalink / raw) To: caml-list On 13-10-2008, Kuba Ober <kuba@mareimbrium.org> wrote: > I've looked briefly at what it'd take to have OCaml > fully working natively (with mingw/VS), without any Cygwin > needed for compilation. > > 3. I need to look at the bytecode debugger and figure out why doesn't it work > on non-Cygwin builds. > OCaml 3.11 will ship a debugger for Win32 (mingw/msvc). Everything should be working except the replay part which depends on fork. I have worked on this, based on a patch provided few months ago by Dimitry Bely. All in all, I have reimplemented "select" for win32 && pipe. Regards, Sylvain Le Gall ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Re: Road to native windows OCaml... 2008-10-14 7:20 ` Sylvain Le Gall @ 2008-10-14 21:37 ` Kuba Ober 2008-10-15 5:52 ` Dmitry Bely 0 siblings, 1 reply; 44+ messages in thread From: Kuba Ober @ 2008-10-14 21:37 UTC (permalink / raw) To: caml-list On Tuesday 14 October 2008, Sylvain Le Gall wrote: > On 13-10-2008, Kuba Ober <kuba@mareimbrium.org> wrote: > > I've looked briefly at what it'd take to have OCaml > > fully working natively (with mingw/VS), without any Cygwin > > needed for compilation. > > > > 3. I need to look at the bytecode debugger and figure out why doesn't it > > work on non-Cygwin builds. > > OCaml 3.11 will ship a debugger for Win32 (mingw/msvc). Everything > should be working except the replay part which depends on fork. > > I have worked on this, based on a patch provided few months ago by > Dimitry Bely. All in all, I have reimplemented "select" for win32 && > pipe. Why do we need fork? I need to look at the code... Cheers, Kuba ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Re: Road to native windows OCaml... 2008-10-14 21:37 ` [Caml-list] " Kuba Ober @ 2008-10-15 5:52 ` Dmitry Bely 2008-10-15 13:50 ` Kuba Ober 0 siblings, 1 reply; 44+ messages in thread From: Dmitry Bely @ 2008-10-15 5:52 UTC (permalink / raw) To: Caml List On Wed, Oct 15, 2008 at 1:37 AM, Kuba Ober <kuba@mareimbrium.org> wrote: >> > I've looked briefly at what it'd take to have OCaml >> > fully working natively (with mingw/VS), without any Cygwin >> > needed for compilation. >> > >> > 3. I need to look at the bytecode debugger and figure out why doesn't it >> > work on non-Cygwin builds. >> >> OCaml 3.11 will ship a debugger for Win32 (mingw/msvc). Everything >> should be working except the replay part which depends on fork. >> >> I have worked on this, based on a patch provided few months ago by >> Dimitry Bely. All in all, I have reimplemented "select" for win32 && >> pipe. > > Why do we need fork? I need to look at the code... http://caml.inria.fr/pub/ml-archives/caml-list/1999/03/f44178e212e78826bcbdee52ddf6fd91.en.html Concerning bytecode debugging under Windows, the major issue is the way our debugger performs periodic checkpointing of the running program (in order to implement reverse execution). We just use the Unix fork() system call, which does everything we want (checkpointing of memory and file descriptors, using lazy copy-on-write to minimize copying). - Dmitry Bely ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Re: Road to native windows OCaml... 2008-10-15 5:52 ` Dmitry Bely @ 2008-10-15 13:50 ` Kuba Ober 0 siblings, 0 replies; 44+ messages in thread From: Kuba Ober @ 2008-10-15 13:50 UTC (permalink / raw) To: caml-list > > Why do we need fork? I need to look at the code... > > http://caml.inria.fr/pub/ml-archives/caml-list/1999/03/f44178e212e78826bcbd >ee52ddf6fd91.en.html > > Concerning bytecode debugging under Windows, the major issue is the > way our debugger performs periodic checkpointing of the running program > (in order to implement reverse execution). We just use the Unix fork() > system call, which does everything we want (checkpointing of memory > and file descriptors, using lazy copy-on-write to minimize copying). Ah-ha, hmm, I guess I will just have to hack on some "state-preserving" machinery for win32 world, then. That's way into the future, but should be doable. Some things cannot be trivially preserved unless you instrument (wrap) the relevant APIs. Example: on Unices, you can read from a network stream, fork, and continue on reading in the child process. The parent process can stop reading and resume at a later point: the kernel will buffer the data as long as it can (till it runs out of memory). On Windows, this is not doable without wrapping the relevant Winsock calls, and potentially all other streaming interfaces that the OCaml application uses either directly or indirectly. The checkpointing for OCaml's debugging can perform much better than Cygwin's fork because the bytecode interpreter controls the application startup and can put everything (including itself) into memory pages that can be made copy-on-write at checkpoints. The only benefit to creating separate processes for each checkpoint is to have more virtual memory available, and to prevent a crash from doing too much damage. Even then, enough functionality should be easy to implement to make this feature "do what you expect it to" on Windows. It's still some work to get it to work, but what the heck: may as well prove to myself it's doable. That'd come after Camelia is in shape, though. Cheers, Kuba ^ permalink raw reply [flat|nested] 44+ messages in thread
* RE: [Caml-list] Road to native windows OCaml... 2008-10-13 23:35 Road to native windows OCaml Kuba Ober ` (2 preceding siblings ...) 2008-10-14 7:20 ` Sylvain Le Gall @ 2008-10-14 7:59 ` David Allsopp 2008-10-14 8:11 ` Daniel Bünzli ` (2 more replies) 2008-10-14 9:25 ` Sylvain Le Gall 2008-10-14 18:19 ` Cross-compilation (was: Re: [Caml-list] Road to native windows OCaml...) Richard Jones 5 siblings, 3 replies; 44+ messages in thread From: David Allsopp @ 2008-10-14 7:59 UTC (permalink / raw) To: caml-list Kuba Ober wrote: > I've looked briefly at what it'd take to have OCaml > fully working natively (with mingw/VS), without any Cygwin > needed for compilation. Can I ask what the motivation is for this (out of interest, not criticism)? It only takes a matter of minutes to install Cygwin and it can be completely ignored once OCaml is compiled (I don't even have Cygwin in my PATH). David ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Road to native windows OCaml... 2008-10-14 7:59 ` [Caml-list] " David Allsopp @ 2008-10-14 8:11 ` Daniel Bünzli 2008-10-14 9:19 ` Sylvain Le Gall ` (2 more replies) 2008-10-14 21:38 ` Kuba Ober 2008-10-26 22:07 ` Markus E L 2 siblings, 3 replies; 44+ messages in thread From: Daniel Bünzli @ 2008-10-14 8:11 UTC (permalink / raw) To: OCaml Mailing List Le 14 oct. 08 à 09:59, David Allsopp a écrit : > Can I ask what the motivation is for this (out of interest, not > criticism)? Maybe because if you want to distribute executables using cygwin you have to release your code under a GPL compatible license [1]. Daniel [1] http://caml.inria.fr/pub/distrib/ocaml-3.10/notes/README.win32 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Road to native windows OCaml... 2008-10-14 8:11 ` Daniel Bünzli @ 2008-10-14 9:19 ` Sylvain Le Gall 2008-10-14 9:41 ` Re : [Caml-list] " Adrien 2008-10-14 9:57 ` Mathias Kende 2 siblings, 0 replies; 44+ messages in thread From: Sylvain Le Gall @ 2008-10-14 9:19 UTC (permalink / raw) To: caml-list On 14-10-2008, Daniel Bünzli <daniel.buenzli@erratique.ch> wrote: > > Le 14 oct. 08 à 09:59, David Allsopp a écrit : > >> Can I ask what the motivation is for this (out of interest, not >> criticism)? > > Maybe because if you want to distribute executables using cygwin you > have to release your code under a GPL compatible license [1]. > You need cygwin to compile MSVC/mingw version of ocaml. But this is only needed for tools like: tput, make, sed and cp. Once compiled ocaml doesn't need cygwin runtime. In other word, there is no contamination of the GPL license to executable compiled by OCaml MSVC with cygwin GNU make. Regards, Sylvain Le Gall ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re : [Caml-list] Road to native windows OCaml... 2008-10-14 8:11 ` Daniel Bünzli 2008-10-14 9:19 ` Sylvain Le Gall @ 2008-10-14 9:41 ` Adrien 2008-10-14 10:13 ` Re : " Sylvain Le Gall ` (2 more replies) 2008-10-14 9:57 ` Mathias Kende 2 siblings, 3 replies; 44+ messages in thread From: Adrien @ 2008-10-14 9:41 UTC (permalink / raw) To: Daniel Bünzli; +Cc: OCaml Mailing List 2008/10/14, Daniel Bünzli <daniel.buenzli@erratique.ch>: > > Le 14 oct. 08 à 09:59, David Allsopp a écrit : > >> Can I ask what the motivation is for this (out of interest, not >> criticism)? > > Maybe because if you want to distribute executables using cygwin you > have to release your code under a GPL compatible license [1]. > > Daniel > > [1] http://caml.inria.fr/pub/distrib/ocaml-3.10/notes/README.win32 I would give another explanation : cygwin is big and slow. A base cygwin install is at least 1GB (when fully configured, after carefully reviewing *each* package), a regular one is 2GB. XP itself is not that big, I've not seen many applications that big, only CAD ones. Cygwin is also slow, though it will probably not impact a student use (networking is slower due to the translation, I have mldonkey in mind). ./configure are also painfully slow, the need to run several small commands where startup time is more important than runtime gives cygwin no chance [1]. On the other hand, mingw on its own is about 80MB. If you add a few things, it will weight at most 200MB which is 10 times smaller than the cygwin solution. I forgot to mention that cygwin has some dead packages. Look at the gtk package, it hasn't been updated in 6 ( six ) years ! But there's something that is worth being mentionned : cross-compilation. Of course it won't help if you want to use the toplevel under windows but it definitely helps when building for windows. A few months ago I got interested in webkit, especially webkit-gtk. Webkit is one of the most advanced web content rendering engine available, it is a big application which takes longer to compile than ocaml, produces a library that is about 10MB (and 300MB with debug enabled). It has a "native" windows version ("port" is the usual terminology but would be misleading here) and a gtk one (and qt, wx, java). I wanted to have webkit-gtk under windows but don't really like COM and VS-specific things which the native version uses. Msys/mingw has been a failure, autotools gave me headaches and I gave up when it started asking me for perl. Cygwin has been about the same, autotools hell and gtk problems. Then I tried cross-compilation, I had to change about ten lines in the whole webkit sourcecode, specifiy a few libraries to link with, nothing more. No autotools problems, no pkg-config hell, no unbearable shell, fully-functionnal perl, most recent versions of gcc/g++ and friends. This produced a well-working webkit-gtk library the first time it compiled (there's a *gtk* bug on xp though, vista unaffected). Sure it can be compiled while staying on windows, it just takes months (I helped somebody who succeeded) and does not even work correctly ! [2] Please ocaml gods, give us a cross-compiler or at least tell us the plans regarding cross-compilation. :) [1] no article but I experimented and in time needed by configure, it is linux < mac osx < msys/mingw < cygwin/mingw. ./configure runs take about 10 to 20 more time under cygwin than under linux and only about 4 more time under msys. It gets quickly painful, 2 seconds per configure line when there will be 300 lines is hard to stand. [2] http://funpidgin.sourceforge.net/2008-08-20/megarian-webkit-sort-of-works-on-windows-now --- Adrien Nader > _______________________________________________ > 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 > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Re : Road to native windows OCaml... 2008-10-14 9:41 ` Re : [Caml-list] " Adrien @ 2008-10-14 10:13 ` Sylvain Le Gall 2008-10-14 11:07 ` Re : [Caml-list] " Adrien 2008-10-14 21:39 ` Kuba Ober 2008-10-14 15:56 ` [Caml-list] " David Allsopp 2008-10-14 17:39 ` Re : " Dmitry Bely 2 siblings, 2 replies; 44+ messages in thread From: Sylvain Le Gall @ 2008-10-14 10:13 UTC (permalink / raw) To: caml-list 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 : >> >>> Can I ask what the motivation is for this (out of interest, not >>> criticism)? >> >> Maybe because if you want to distribute executables using cygwin you >> have to release your code under a GPL compatible license [1]. >> >> Daniel >> >> [1] http://caml.inria.fr/pub/distrib/ocaml-3.10/notes/README.win32 > > I would give another explanation : cygwin is big and slow. > A base cygwin install is at least 1GB (when fully configured, after > carefully reviewing *each* package), a regular one is 2GB. XP itself > is not that big, I've not seen many applications that big, only CAD > ones. > Cygwin is also slow, though it will probably not impact a student use > (networking is slower due to the translation, I have mldonkey in > mind). ./configure are also painfully slow, the need to run several > small commands where startup time is more important than runtime gives > cygwin no chance [1]. > > On the other hand, mingw on its own is about 80MB. If you add a few > things, it will weight at most 200MB which is 10 times smaller than > the cygwin solution. > Welcome in the windows world. For your information, there is a lot of thing in windows that is bigger than cygwin. Just taking a fresh example (install it last sunday): PSDK for AMD64 (platform SDK). This is the recommanded C compiler to compile OCaml for Win64. It takes 935MB (ok this is not 1GB). It is just what is replacing mingw !!!! Other examples: - games - Microsoft Visual Studio 2005 Team, takes ~6GB (official number from microsoft website) If hard disk space were a problem, nobody would install Microsoft products... 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. Regards Sylvain Le Gall ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re : [Caml-list] Re: Re : Road to native windows OCaml... 2008-10-14 10:13 ` Re : " Sylvain Le Gall @ 2008-10-14 11:07 ` Adrien 2008-10-14 11:23 ` Re : " Sylvain Le Gall 2008-10-14 21:41 ` Re : [Caml-list] " Kuba Ober 2008-10-14 21:39 ` Kuba Ober 1 sibling, 2 replies; 44+ messages in thread From: Adrien @ 2008-10-14 11:07 UTC (permalink / raw) To: Sylvain Le Gall; +Cc: caml-list 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 : >>> >>>> Can I ask what the motivation is for this (out of interest, not >>>> criticism)? >>> >>> Maybe because if you want to distribute executables using cygwin you >>> have to release your code under a GPL compatible license [1]. >>> >>> Daniel >>> >>> [1] http://caml.inria.fr/pub/distrib/ocaml-3.10/notes/README.win32 >> >> I would give another explanation : cygwin is big and slow. >> A base cygwin install is at least 1GB (when fully configured, after >> carefully reviewing *each* package), a regular one is 2GB. XP itself >> is not that big, I've not seen many applications that big, only CAD >> ones. >> Cygwin is also slow, though it will probably not impact a student use >> (networking is slower due to the translation, I have mldonkey in >> mind). ./configure are also painfully slow, the need to run several >> small commands where startup time is more important than runtime gives >> cygwin no chance [1]. >> >> On the other hand, mingw on its own is about 80MB. If you add a few >> things, it will weight at most 200MB which is 10 times smaller than >> the cygwin solution. >> > > Welcome in the windows world. For your information, there is a lot of > thing in windows that is bigger than cygwin. > > Just taking a fresh example (install it last sunday): PSDK for AMD64 > (platform SDK). This is the recommanded C compiler to compile OCaml for > Win64. It takes 935MB (ok this is not 1GB). It is just what is replacing > mingw !!!! > > Other examples: > - games > - Microsoft Visual Studio 2005 Team, takes ~6GB (official number from > microsoft website) > > If hard disk space were a problem, nobody would install Microsoft > products... Unreal Tournament 2004 takes 5.3GB, I have it installed on an XFS partition though. ;) It's just games, not games on a microsoft platform (PS3 and Blu-Ray anyone ?). But I dont think you will get many students install a 2GB environment. If they have too, they will of course but they are likely to prefer the 200MB one. And the point is not students, cross-compilation will simply give better results with less troubles. > 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. 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. --- 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 > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Re : Re: Re : Road to native windows OCaml... 2008-10-14 11:07 ` Re : [Caml-list] " Adrien @ 2008-10-14 11:23 ` Sylvain Le Gall 2008-10-14 19:39 ` Re : [Caml-list] " Adrien 2008-10-14 21:41 ` Re : [Caml-list] " Kuba Ober 1 sibling, 1 reply; 44+ messages in thread From: Sylvain Le Gall @ 2008-10-14 11:23 UTC (permalink / raw) To: caml-list 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). > 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.... Regards, Sylvain Le Gall ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re : [Caml-list] Re: Re : Re: Re : Road to native windows OCaml... 2008-10-14 11:23 ` Re : " Sylvain Le Gall @ 2008-10-14 19:39 ` Adrien 0 siblings, 0 replies; 44+ messages in thread From: Adrien @ 2008-10-14 19:39 UTC (permalink / raw) To: Sylvain Le Gall; +Cc: caml-list 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 > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Re : [Caml-list] Re: Re : Road to native windows OCaml... 2008-10-14 11:07 ` Re : [Caml-list] " Adrien 2008-10-14 11:23 ` Re : " Sylvain Le Gall @ 2008-10-14 21:41 ` Kuba Ober 2008-10-15 9:42 ` David Allsopp 1 sibling, 1 reply; 44+ messages in thread From: Kuba Ober @ 2008-10-14 21:41 UTC (permalink / raw) To: caml-list > 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. > > Also, I don't think cygwin is bad. I just think it is not the > appropriate answer for most of us. Cygwin is an answer if you can't code natively. If you insist on using Unix mindset, then sure Cygwin is easiest. I don't see a problem with OCaml doing things the Windows way on Windows, and Unix way on Unices. Cheers, Kuba ^ permalink raw reply [flat|nested] 44+ messages in thread
* RE: Re : [Caml-list] Re: Re : Road to native windows OCaml... 2008-10-14 21:41 ` Re : [Caml-list] " Kuba Ober @ 2008-10-15 9:42 ` David Allsopp 2008-10-15 12:33 ` Kuba Ober 0 siblings, 1 reply; 44+ messages in thread From: David Allsopp @ 2008-10-15 9:42 UTC (permalink / raw) To: caml-list Kuba Ober wrote: > > 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. > > > > Also, I don't think cygwin is bad. I just think it is not the > > appropriate answer for most of us. > > Cygwin is an answer if you can't code natively. If you insist on > using Unix mindset, then sure Cygwin is easiest. I don't see a problem > with OCaml doing things the Windows way on Windows, and Unix way on > Unices. Not quite clear what you mean by this - are you referring to the Cygwin *port* of OCaml or the MinGW port *built* in Cygwin? (though I'm aware that you don't have to use Cygwin to build this any more) While it's not a major issue (especially once OCaml 3.11 comes along and just about everything that can be done in bytecode is possible in native code...), the bytecode interpreter in the MSVC port is considerably slower than in the MinGW port (as documented in the readme) which is the reason I chose it years ago over MSVC... That said, I'd quite like to take advantage of my shiny new x64 quad-core Dell so perhaps it is time to switch 8-) David ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Re : [Caml-list] Re: Re : Road to native windows OCaml... 2008-10-15 9:42 ` David Allsopp @ 2008-10-15 12:33 ` Kuba Ober 0 siblings, 0 replies; 44+ messages in thread From: Kuba Ober @ 2008-10-15 12:33 UTC (permalink / raw) To: caml-list > > > Also, I don't think cygwin is bad. I just think it is not the > > > appropriate answer for most of us. > > > > Cygwin is an answer if you can't code natively. If you insist on > > using Unix mindset, then sure Cygwin is easiest. I don't see a problem > > with OCaml doing things the Windows way on Windows, and Unix way on > > Unices. > > Not quite clear what you mean by this - are you referring to the Cygwin > *port* of OCaml or the MinGW port *built* in Cygwin? (though I'm aware that > you don't have to use Cygwin to build this any more) What I mean is that if something is supposed to work on Windows, it better use Windows APIs to accomplish what it wants, and not a Unix-like environment provided by Cygwin. There may well be native ways to accomplish what Ocaml tries to accomplish using Unix APIs. > While it's not a major issue (especially once OCaml 3.11 comes along and > just about everything that can be done in bytecode is possible in native > code...), the bytecode interpreter in the MSVC port is considerably slower > than in the MinGW port (as documented in the readme) which is the reason I > chose it years ago over MSVC... I haven't looked in OCaml code: in absence of computed goto, you can use switch statements, function pointers or function-like objects (in C++). Some measurements show that function pointers are faster than switch statements (http://www.codeproject.com/KB/architecture/TimingVM.aspx). Cheers, Kuba ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Re: Re : Road to native windows OCaml... 2008-10-14 10:13 ` Re : " Sylvain Le Gall 2008-10-14 11:07 ` Re : [Caml-list] " Adrien @ 2008-10-14 21:39 ` Kuba Ober 1 sibling, 0 replies; 44+ messages in thread From: Kuba Ober @ 2008-10-14 21:39 UTC (permalink / raw) To: caml-list On Tuesday 14 October 2008, Sylvain Le Gall wrote: > 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 : > >>> Can I ask what the motivation is for this (out of interest, not > >>> criticism)? > >> > >> Maybe because if you want to distribute executables using cygwin you > >> have to release your code under a GPL compatible license [1]. > >> > >> Daniel > >> > >> [1] http://caml.inria.fr/pub/distrib/ocaml-3.10/notes/README.win32 > > > > I would give another explanation : cygwin is big and slow. > > A base cygwin install is at least 1GB (when fully configured, after > > carefully reviewing *each* package), a regular one is 2GB. XP itself > > is not that big, I've not seen many applications that big, only CAD > > ones. > > Cygwin is also slow, though it will probably not impact a student use > > (networking is slower due to the translation, I have mldonkey in > > mind). ./configure are also painfully slow, the need to run several > > small commands where startup time is more important than runtime gives > > cygwin no chance [1]. > > > > On the other hand, mingw on its own is about 80MB. If you add a few > > things, it will weight at most 200MB which is 10 times smaller than > > the cygwin solution. > > Welcome in the windows world. For your information, there is a lot of > thing in windows that is bigger than cygwin. Sure, but people who will use OCaml professionally may well have some of it installed and not Cygwin. I'd like a lot someone who has Visual Studio installed to be able to build and tinker with OCaml. Cheers, Kuba ^ permalink raw reply [flat|nested] 44+ messages in thread
* RE: [Caml-list] Road to native windows OCaml... 2008-10-14 9:41 ` Re : [Caml-list] " Adrien 2008-10-14 10:13 ` Re : " Sylvain Le Gall @ 2008-10-14 15:56 ` David Allsopp 2008-10-14 17:39 ` Re : " Dmitry Bely 2 siblings, 0 replies; 44+ messages in thread From: David Allsopp @ 2008-10-14 15:56 UTC (permalink / raw) To: 'Adrien', 'Daniel Bünzli' Cc: 'OCaml Mailing List' Adrien wrote: > 2008/10/14, Daniel Bünzli <daniel.buenzli@erratique.ch>: > > > > Le 14 oct. 08 à 09:59, David Allsopp a écrit : > > > >> Can I ask what the motivation is for this (out of interest, not > >> criticism)? > > > > Maybe because if you want to distribute executables using cygwin you > > have to release your code under a GPL compatible license [1]. > > > > Daniel > > > > [1] http://caml.inria.fr/pub/distrib/ocaml-3.10/notes/README.win32 > > I would give another explanation : cygwin is big and slow. > A base cygwin install is at least 1GB (when fully configured, after > carefully reviewing *each* package), a regular one is 2GB. XP itself That's not a base install of Cygwin - at least not "base" in terms of building OCaml. My base install, for compiling OCaml MinGW only, is 123MB. Once OCaml is built, I use the Win32 ports of the Unix utilities (at some point I'll switch to GnuWin32 as it's a bit more actively maintained) which adds 18MB and then there's ActiveTCL at about 50MB. However, I make no further defence of Cygwin speed or otherwise as I don't know how it compares. David ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Re : [Caml-list] Road to native windows OCaml... 2008-10-14 9:41 ` Re : [Caml-list] " Adrien 2008-10-14 10:13 ` Re : " Sylvain Le Gall 2008-10-14 15:56 ` [Caml-list] " David Allsopp @ 2008-10-14 17:39 ` Dmitry Bely 2008-10-14 19:31 ` Re : " Adrien 2 siblings, 1 reply; 44+ messages in thread From: Dmitry Bely @ 2008-10-14 17:39 UTC (permalink / raw) To: Caml List On Tue, Oct 14, 2008 at 1:41 PM, Adrien <camaradetux@gmail.com> wrote: >>> Can I ask what the motivation is for this (out of interest, not >>> criticism)? >> >> Maybe because if you want to distribute executables using cygwin you >> have to release your code under a GPL compatible license [1]. >> >> Daniel >> >> [1] http://caml.inria.fr/pub/distrib/ocaml-3.10/notes/README.win32 > > I would give another explanation : cygwin is big and slow. > A base cygwin install is at least 1GB (when fully configured, after > carefully reviewing *each* package), a regular one is 2GB. XP itself > is not that big, I've not seen many applications that big, only CAD > ones. No way. My Cygwin installation (quite enough for building Ocaml and many other things) is just 274Mb. Not a big deal. > Cygwin is also slow, though it will probably not impact a student use > (networking is slower due to the translation, I have mldonkey in > mind). What exactly is slow when building Ocaml? make? Can you prove that? > ./configure are also painfully slow, the need to run several > small commands where startup time is more important than runtime gives > cygwin no chance [1]. Where did you find any ./configure script used for building the native Win32 Ocaml? - Dmitry Bely ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re : Re : [Caml-list] Road to native windows OCaml... 2008-10-14 17:39 ` Re : " Dmitry Bely @ 2008-10-14 19:31 ` Adrien 0 siblings, 0 replies; 44+ messages in thread From: Adrien @ 2008-10-14 19:31 UTC (permalink / raw) To: Dmitry Bely; +Cc: Caml List 2008/10/14, Dmitry Bely <dmitry.bely@gmail.com>: > On Tue, Oct 14, 2008 at 1:41 PM, Adrien <camaradetux@gmail.com> wrote: > >>>> Can I ask what the motivation is for this (out of interest, not >>>> criticism)? >>> >>> Maybe because if you want to distribute executables using cygwin you >>> have to release your code under a GPL compatible license [1]. >>> >>> Daniel >>> >>> [1] http://caml.inria.fr/pub/distrib/ocaml-3.10/notes/README.win32 >> >> I would give another explanation : cygwin is big and slow. >> A base cygwin install is at least 1GB (when fully configured, after >> carefully reviewing *each* package), a regular one is 2GB. XP itself >> is not that big, I've not seen many applications that big, only CAD >> ones. > > No way. My Cygwin installation (quite enough for building Ocaml and > many other things) is just 274Mb. Not a big deal. I have to say I am really surprised. All the cygwin installations I've seen were terribly big, with tens of thousands of files, if not hundreds of thousands. Would you (and/or David) mind sharing you configuration file ? (the one created at the root of the package cache, don't remember the name). The point is not that I don't believe you, I just want to *know*. I guess the difference is that I also installed other development tools and libraries >> Cygwin is also slow, though it will probably not impact a student use >> (networking is slower due to the translation, I have mldonkey in >> mind). > > What exactly is slow when building Ocaml? make? Can you prove that? I won't prove that as I've not said *that*. You're talking about something very specific whereas I said something much more general. I'd like to say cygwin slowness is universally known but I'd be told I'm not proving anything. The point is that every operation that requires the cygwin translation layer is slow. Of course, if you don't use anything ocaml doesn't already provide, it won't be slow (but that wouldn't prove cygwin is not slow). Now, if you don't need to deliver/provide/release/... an application that specifically targets windows, I don't really get why you're running ocaml on windows, use a real linux installation, get a virtual machine (virtualbox is great), use ocamljava (which is great !). But anyway. >> ./configure are also painfully slow, the need to run several >> small commands where startup time is more important than runtime gives >> cygwin no chance [1]. > > Where did you find any ./configure script used for building the native > Win32 Ocaml? Again, ocaml is not the only application in the world, nor the *one* I was referring to. Even though this is the ocaml mailing-list and the topic is definitely about ocaml, there exist other things with which ocaml has to interact. And just for the report, you can run the ./configure scripts (they don't give you correct results but are mostly working) and, yes, they are slower. --- Adrien Nader > > - Dmitry Bely > > _______________________________________________ > 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 > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Road to native windows OCaml... 2008-10-14 8:11 ` Daniel Bünzli 2008-10-14 9:19 ` Sylvain Le Gall 2008-10-14 9:41 ` Re : [Caml-list] " Adrien @ 2008-10-14 9:57 ` Mathias Kende 2 siblings, 0 replies; 44+ messages in thread From: Mathias Kende @ 2008-10-14 9:57 UTC (permalink / raw) To: Daniel Bünzli; +Cc: OCaml Mailing List Le mardi 14 octobre 2008 à 10:11 +0200, Daniel Bünzli a écrit : > Maybe because if you want to distribute executables using cygwin you > have to release your code under a GPL compatible license [1]. You could have a look at UWIN [1] which, while not as actively maintained as cygwin, also provide the basic POSIX emulation for Windows but under the Common Public Licence which is more permissive than the GPL. Mathias [1] http://www.research.att.com/sw/tools/uwin/ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Road to native windows OCaml... 2008-10-14 7:59 ` [Caml-list] " David Allsopp 2008-10-14 8:11 ` Daniel Bünzli @ 2008-10-14 21:38 ` Kuba Ober 2008-10-15 0:01 ` Sylvain Le Gall ` (2 more replies) 2008-10-26 22:07 ` Markus E L 2 siblings, 3 replies; 44+ messages in thread From: Kuba Ober @ 2008-10-14 21:38 UTC (permalink / raw) To: caml-list On Tuesday 14 October 2008, David Allsopp wrote: > Kuba Ober wrote: > > I've looked briefly at what it'd take to have OCaml > > fully working natively (with mingw/VS), without any Cygwin > > needed for compilation. > > Can I ask what the motivation is for this (out of interest, not criticism)? > It only takes a matter of minutes to install Cygwin and it can be > completely ignored once OCaml is compiled (I don't even have Cygwin in my > PATH). The motivation is that I'm allergic to Cygwin. And you're not quite right that Cygwin is not needed later on: it is if you need to generate native code, or link with native code. Cheers, Kuba ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Road to native windows OCaml... 2008-10-14 21:38 ` Kuba Ober @ 2008-10-15 0:01 ` Sylvain Le Gall 2008-10-15 12:35 ` [Caml-list] " Kuba Ober 2008-10-15 5:57 ` [Caml-list] " Dmitry Bely 2008-10-15 9:42 ` David Allsopp 2 siblings, 1 reply; 44+ messages in thread From: Sylvain Le Gall @ 2008-10-15 0:01 UTC (permalink / raw) To: caml-list On 14-10-2008, Kuba Ober <kuba@mareimbrium.org> wrote: > On Tuesday 14 October 2008, David Allsopp wrote: >> Kuba Ober wrote: >> > I've looked briefly at what it'd take to have OCaml >> > fully working natively (with mingw/VS), without any Cygwin >> > needed for compilation. >> >> Can I ask what the motivation is for this (out of interest, not criticism)? >> It only takes a matter of minutes to install Cygwin and it can be >> completely ignored once OCaml is compiled (I don't even have Cygwin in my >> PATH). > > The motivation is that I'm allergic to Cygwin. And you're not quite right that > Cygwin is not needed later on: it is if you need to generate native code, > or link with native code. > Not at all. Once compiled, ocaml doesn't use cygwin anymore. With maybe the big exception of some little thing in ocambuild, that should be fixed in ocaml 3.11 (something like needing "tput"). For example, if you download and install OCaml MSVC from http://caml.inria.fr and you open a MS Visual Studio 2005 MSDOS shell, you can perfectly compile a native application (well I have not done it, but I will try tomorrow ;-) All you need is "cl", "ml" and "link" I think (all are MSVC tools). Regards, Sylvain Le Gall ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Re: Road to native windows OCaml... 2008-10-15 0:01 ` Sylvain Le Gall @ 2008-10-15 12:35 ` Kuba Ober 2008-10-15 12:54 ` Dmitry Bely 0 siblings, 1 reply; 44+ messages in thread From: Kuba Ober @ 2008-10-15 12:35 UTC (permalink / raw) To: caml-list On Tuesday 14 October 2008, Sylvain Le Gall wrote: > On 14-10-2008, Kuba Ober <kuba@mareimbrium.org> wrote: > > On Tuesday 14 October 2008, David Allsopp wrote: > >> Kuba Ober wrote: > >> > I've looked briefly at what it'd take to have OCaml > >> > fully working natively (with mingw/VS), without any Cygwin > >> > needed for compilation. > >> > >> Can I ask what the motivation is for this (out of interest, not > >> criticism)? It only takes a matter of minutes to install Cygwin and it > >> can be completely ignored once OCaml is compiled (I don't even have > >> Cygwin in my PATH). > > > > The motivation is that I'm allergic to Cygwin. And you're not quite right > > that Cygwin is not needed later on: it is if you need to generate native > > code, or link with native code. > > Not at all. Once compiled, ocaml doesn't use cygwin anymore. With maybe > the big exception of some little thing in ocambuild, that should be > fixed in ocaml 3.11 (something like needing "tput"). > > For example, if you download and install OCaml MSVC from > http://caml.inria.fr and you open a MS Visual Studio 2005 MSDOS shell, > you can perfectly compile a native application (well I have not done it, > but I will try tomorrow ;-) > > All you need is "cl", "ml" and "link" I think (all are MSVC tools). And you need masm too, right? You're right of course, for whatever reasons I was still thinking of OCaml built with Cygwin :) Cheers, Kuba ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Re: Road to native windows OCaml... 2008-10-15 12:35 ` [Caml-list] " Kuba Ober @ 2008-10-15 12:54 ` Dmitry Bely 2008-10-15 13:18 ` Sylvain Le Gall 2008-10-15 14:35 ` [Caml-list] " Kuba Ober 0 siblings, 2 replies; 44+ messages in thread From: Dmitry Bely @ 2008-10-15 12:54 UTC (permalink / raw) To: Caml List On Wed, Oct 15, 2008 at 4:35 PM, Kuba Ober <kuba@mareimbrium.org> wrote: >> For example, if you download and install OCaml MSVC from >> http://caml.inria.fr and you open a MS Visual Studio 2005 MSDOS shell, >> you can perfectly compile a native application (well I have not done it, >> but I will try tomorrow ;-) >> >> All you need is "cl", "ml" and "link" I think (all are MSVC tools). > > And you need masm too, right? "ml" is just that masm. It's included into MS Visual Studio Professional edition and up. For Standard edition and below there is free www.masm32.com. - Dmitry Bely ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Road to native windows OCaml... 2008-10-15 12:54 ` Dmitry Bely @ 2008-10-15 13:18 ` Sylvain Le Gall 2008-10-15 14:35 ` [Caml-list] " Kuba Ober 1 sibling, 0 replies; 44+ messages in thread From: Sylvain Le Gall @ 2008-10-15 13:18 UTC (permalink / raw) To: caml-list On 15-10-2008, Dmitry Bely <dmitry.bely@gmail.com> wrote: > On Wed, Oct 15, 2008 at 4:35 PM, Kuba Ober <kuba@mareimbrium.org> wrote: > >>> For example, if you download and install OCaml MSVC from >>> http://caml.inria.fr and you open a MS Visual Studio 2005 MSDOS shell, >>> you can perfectly compile a native application (well I have not done it, >>> but I will try tomorrow ;-) >>> >>> All you need is "cl", "ml" and "link" I think (all are MSVC tools). >> >> And you need masm too, right? > > "ml" is just that masm. It's included into MS Visual Studio > Professional edition and up. For Standard edition and below there is > free www.masm32.com. > I think that you always have "ml" (and "ml64" for x64) in MS Visual Studior 2008 even in Standard Edition (the one I have). However, you don't have it with Visual Express (free edition). In this case you should fetch it... In fact for MSVE 2008, you cannot install masm, so you have to extract it by hand and forcibly install it in "cl" directory. I think all (cl, ml and link) is also shipped in MS PSDK, especially for x64... Regards, Sylvain Le Gall ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Re: Road to native windows OCaml... 2008-10-15 12:54 ` Dmitry Bely 2008-10-15 13:18 ` Sylvain Le Gall @ 2008-10-15 14:35 ` Kuba Ober 2008-10-15 15:29 ` Dmitry Bely 1 sibling, 1 reply; 44+ messages in thread From: Kuba Ober @ 2008-10-15 14:35 UTC (permalink / raw) To: caml-list On Wednesday 15 October 2008, Dmitry Bely wrote: > On Wed, Oct 15, 2008 at 4:35 PM, Kuba Ober <kuba@mareimbrium.org> wrote: > >> For example, if you download and install OCaml MSVC from > >> http://caml.inria.fr and you open a MS Visual Studio 2005 MSDOS shell, > >> you can perfectly compile a native application (well I have not done it, > >> but I will try tomorrow ;-) > >> > >> All you need is "cl", "ml" and "link" I think (all are MSVC tools). > > > > And you need masm too, right? > > "ml" is just that masm. It's included into MS Visual Studio > Professional edition and up. For Standard edition and below there is > free www.masm32.com. masm32 has an absolutely horrendous license -- have you read it? It's crazy. ml of course should be used if available, but otherwise nasm is there and is what should be used whenver masm is called for and unavailable. Cheers, Kuba ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Re: Road to native windows OCaml... 2008-10-15 14:35 ` [Caml-list] " Kuba Ober @ 2008-10-15 15:29 ` Dmitry Bely 2008-10-15 16:26 ` Kuba Ober 0 siblings, 1 reply; 44+ messages in thread From: Dmitry Bely @ 2008-10-15 15:29 UTC (permalink / raw) To: caml-list On Wed, Oct 15, 2008 at 6:35 PM, Kuba Ober <kuba@mareimbrium.org> wrote: > On Wednesday 15 October 2008, Dmitry Bely wrote: >> On Wed, Oct 15, 2008 at 4:35 PM, Kuba Ober <kuba@mareimbrium.org> wrote: >> >> For example, if you download and install OCaml MSVC from >> >> http://caml.inria.fr and you open a MS Visual Studio 2005 MSDOS shell, >> >> you can perfectly compile a native application (well I have not done it, >> >> but I will try tomorrow ;-) >> >> >> >> All you need is "cl", "ml" and "link" I think (all are MSVC tools). >> > >> > And you need masm too, right? >> >> "ml" is just that masm. It's included into MS Visual Studio >> Professional edition and up. For Standard edition and below there is >> free www.masm32.com. > > masm32 has an absolutely horrendous license -- have you read it? It's > crazy. OK, I was wrong: masm (ml.exe) is already included into all non-free Visual Studio 2008 editions and into free Express edition since 2008 SP1. So now it's not a problem at all. > ml of course should be used if available, but otherwise nasm is there and > is what should be used whenver masm is called for and unavailable. Nasm and masm syntaxes differ. You cannot simply interchange them. - Dmitry Bely ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Re: Road to native windows OCaml... 2008-10-15 15:29 ` Dmitry Bely @ 2008-10-15 16:26 ` Kuba Ober 2008-10-15 16:39 ` Xavier Leroy 0 siblings, 1 reply; 44+ messages in thread From: Kuba Ober @ 2008-10-15 16:26 UTC (permalink / raw) To: caml-list > >> >> All you need is "cl", "ml" and "link" I think (all are MSVC tools). > >> > > >> > And you need masm too, right? > >> > >> "ml" is just that masm. It's included into MS Visual Studio > >> Professional edition and up. For Standard edition and below there is > >> free www.masm32.com. > > > > masm32 has an absolutely horrendous license -- have you read it? It's > > crazy. > > OK, I was wrong: masm (ml.exe) is already included into all non-free > Visual Studio 2008 editions and into free Express edition since 2008 > SP1. So now it's not a problem at all. > > > ml of course should be used if available, but otherwise nasm is there and > > is what should be used whenver masm is called for and unavailable. > > Nasm and masm syntaxes differ. You cannot simply interchange them. What I meant was that caml would generate one more asm syntax, it already supports two (masm and gas). Any differences are surely easy to code. Since masm is now available and supported, that became a non issue; the windows platform notes have to be updated to reflect that. Cheers, Kuba ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Re: Road to native windows OCaml... 2008-10-15 16:26 ` Kuba Ober @ 2008-10-15 16:39 ` Xavier Leroy 0 siblings, 0 replies; 44+ messages in thread From: Xavier Leroy @ 2008-10-15 16:39 UTC (permalink / raw) To: Kuba Ober; +Cc: caml-list >> Nasm and masm syntaxes differ. You cannot simply interchange them. > > What I meant was that caml would generate one more asm syntax, it already > supports two (masm and gas). ... and it's already a major pain, with quite a bit of code duplication between the masm and gas code emitters. The world doesn't need yet another symtax for x86 assembly language. - Xavier Leroy ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Road to native windows OCaml... 2008-10-14 21:38 ` Kuba Ober 2008-10-15 0:01 ` Sylvain Le Gall @ 2008-10-15 5:57 ` Dmitry Bely 2008-10-15 9:42 ` David Allsopp 2 siblings, 0 replies; 44+ messages in thread From: Dmitry Bely @ 2008-10-15 5:57 UTC (permalink / raw) To: Caml List On Wed, Oct 15, 2008 at 1:38 AM, Kuba Ober <kuba@mareimbrium.org> wrote: > On Tuesday 14 October 2008, David Allsopp wrote: >> Kuba Ober wrote: >> > I've looked briefly at what it'd take to have OCaml >> > fully working natively (with mingw/VS), without any Cygwin >> > needed for compilation. >> >> Can I ask what the motivation is for this (out of interest, not criticism)? >> It only takes a matter of minutes to install Cygwin and it can be >> completely ignored once OCaml is compiled (I don't even have Cygwin in my >> PATH). > > The motivation is that I'm allergic to Cygwin. And you're not quite right that > Cygwin is not needed later on: it is if you need to generate native code, > or link with native code. No, if you use MSVC-build Ocaml it's not needed at all. - Dmitry Bely ^ permalink raw reply [flat|nested] 44+ messages in thread
* RE: [Caml-list] Road to native windows OCaml... 2008-10-14 21:38 ` Kuba Ober 2008-10-15 0:01 ` Sylvain Le Gall 2008-10-15 5:57 ` [Caml-list] " Dmitry Bely @ 2008-10-15 9:42 ` David Allsopp 2 siblings, 0 replies; 44+ messages in thread From: David Allsopp @ 2008-10-15 9:42 UTC (permalink / raw) To: caml-list Kuba Ober wrote: > On Tuesday 14 October 2008, David Allsopp wrote: > > Kuba Ober wrote: > > > I've looked briefly at what it'd take to have OCaml > > > fully working natively (with mingw/VS), without any Cygwin > > > needed for compilation. > > > > Can I ask what the motivation is for this (out of interest, not > > criticism)? > > It only takes a matter of minutes to install Cygwin and it can be > > completely ignored once OCaml is compiled (I don't even have Cygwin in > > my PATH). > > The motivation is that I'm allergic to Cygwin. And you're not quite right > that > Cygwin is not needed later on: it is if you need to generate native code, > or link with native code. Sorry - by "needed" I mean you don't need to run Cygwin's bash to use OCaml. The final stage of my OCaml installation procedure involves copying the required Cygwin binaries (ar.exe, as.exe, cygiconv-2.dll, cygintl-3.dll, cygintl-8.dll, cygwin1.dll, dlltool.exe, gcc.exe and ranlib.exe) to OCaml's bin directory at which point OCaml "uses" Cygwin but I don't have to. I wasn't meaning that you could uninstall it after compilation... David ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Caml-list] Road to native windows OCaml... 2008-10-14 7:59 ` [Caml-list] " David Allsopp 2008-10-14 8:11 ` Daniel Bünzli 2008-10-14 21:38 ` Kuba Ober @ 2008-10-26 22:07 ` Markus E L 2 siblings, 0 replies; 44+ messages in thread From: Markus E L @ 2008-10-26 22:07 UTC (permalink / raw) To: caml-list "David Allsopp" wrote: > Kuba Ober wrote: >> I've looked briefly at what it'd take to have OCaml >> fully working natively (with mingw/VS), without any Cygwin >> needed for compilation. > > Can I ask what the motivation is for this (out of interest, not criticism)? > It only takes a matter of minutes to install Cygwin and it can be completely > ignored once OCaml is compiled (I don't even have Cygwin in my PATH). My motivation (if I tried this) would be that CygWin might be a security risk: AFAIK processes of different users interact via the cygwin.dll. Security implications are not clear (there is a paper from ten years ago which says it might open up a security hole) - but it's difficult these days to get any answer from the cygwin developer community wether this has changed. Regards -- Markus ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Road to native windows OCaml... 2008-10-13 23:35 Road to native windows OCaml Kuba Ober ` (3 preceding siblings ...) 2008-10-14 7:59 ` [Caml-list] " David Allsopp @ 2008-10-14 9:25 ` Sylvain Le Gall 2008-10-14 18:19 ` Cross-compilation (was: Re: [Caml-list] Road to native windows OCaml...) Richard Jones 5 siblings, 0 replies; 44+ messages in thread From: Sylvain Le Gall @ 2008-10-14 9:25 UTC (permalink / raw) To: caml-list On 13-10-2008, Kuba Ober <kuba@mareimbrium.org> wrote: > I've looked briefly at what it'd take to have OCaml > fully working natively (with mingw/VS), without any Cygwin > needed for compilation. > > What I've surmised is this: > > 1. I need some "hacked up" make implementation, good enough just > to let it build; this would be a-la web2c in concept. This "make" > would implement bits and pieces of make, bash and sed -- just > the bare minimum needed to get it going. The goal is for people to > have bare mingw or VC and have OCaml build for them. > The functionality needed is quite minimal, so requiring people to > actually pull full sed, bash and make would not be necessary. > I would prototype it in Qt (it's quicker that way), > and then port it to "bare" C++ as time permits. > You should consider enhancing what is already existing: ocamlbuild is here to bootstrap already some piece of the OCaml build process. I think that it will be quicker to extend ocamlbuild to be able to compile everything well than to recreate a "make". Take a look at the build script in build/*.sh to see what is needed. These are fairly simple script, that can be easily transform automatically into .bat file. Regards, Sylvain Le Gall ^ permalink raw reply [flat|nested] 44+ messages in thread
* Cross-compilation (was: Re: [Caml-list] Road to native windows OCaml...) 2008-10-13 23:35 Road to native windows OCaml Kuba Ober ` (4 preceding siblings ...) 2008-10-14 9:25 ` Sylvain Le Gall @ 2008-10-14 18:19 ` Richard Jones 2008-10-15 0:04 ` Erik de Castro Lopo 5 siblings, 1 reply; 44+ messages in thread From: Richard Jones @ 2008-10-14 18:19 UTC (permalink / raw) To: caml-list On Mon, Oct 13, 2008 at 07:35:52PM -0400, Kuba Ober wrote: > Can anyone add to/elaborate on this list? I'm not sure why you want to do this, but I am interested in something related - namely building an OCaml/Windows cross-compiler running on Fedora[1]. There's a bug about cross-compilation here: http://caml.inria.fr/mantis/view.php?id=4303 Does anyone have detailed steps / HOWTO before I try this? .. probably later this week. If this project comes to fruition then we'll be shipping tools like virt-df and virt-top (written in OCaml) on Windows, and this implies shipping dependent libraries too. Of course we'll be building them entirely from Linux ... Rich. [1] http://fedoraproject.org/wiki/MinGW -- Richard Jones Red Hat ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Cross-compilation (was: Re: [Caml-list] Road to native windows OCaml...) 2008-10-14 18:19 ` Cross-compilation (was: Re: [Caml-list] Road to native windows OCaml...) Richard Jones @ 2008-10-15 0:04 ` Erik de Castro Lopo 0 siblings, 0 replies; 44+ messages in thread From: Erik de Castro Lopo @ 2008-10-15 0:04 UTC (permalink / raw) To: caml-list Richard Jones wrote: > On Mon, Oct 13, 2008 at 07:35:52PM -0400, Kuba Ober wrote: > > Can anyone add to/elaborate on this list? > > I'm not sure why you want to do this, but I am interested in something > related - namely building an OCaml/Windows cross-compiler running on > Fedora[1]. This is one that I'd be very interested in. I'd probably even work to get the package and tools ported to Debian/Ubuntu. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Data is not information, Information is not knowledge, Knowledge is not understanding, Understanding is not wisdom." -- Clifford Stoll ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2008-10-26 22:13 UTC | newest] Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-10-13 23:35 Road to native windows OCaml Kuba Ober 2008-10-13 23:47 ` [Caml-list] " Seo Sanghyeon 2008-10-14 21:32 ` Kuba Ober 2008-10-15 9:42 ` David Allsopp 2008-10-15 12:38 ` Kuba Ober 2008-10-15 13:04 ` Seo Sanghyeon 2008-10-15 14:32 ` Kuba Ober 2008-10-14 5:43 ` Elliott Oti 2008-10-14 21:35 ` Kuba Ober 2008-10-14 7:20 ` Sylvain Le Gall 2008-10-14 21:37 ` [Caml-list] " Kuba Ober 2008-10-15 5:52 ` Dmitry Bely 2008-10-15 13:50 ` Kuba Ober 2008-10-14 7:59 ` [Caml-list] " David Allsopp 2008-10-14 8:11 ` Daniel Bünzli 2008-10-14 9:19 ` Sylvain Le Gall 2008-10-14 9:41 ` Re : [Caml-list] " Adrien 2008-10-14 10:13 ` Re : " Sylvain Le Gall 2008-10-14 11:07 ` Re : [Caml-list] " Adrien 2008-10-14 11:23 ` Re : " Sylvain Le Gall 2008-10-14 19:39 ` Re : [Caml-list] " Adrien 2008-10-14 21:41 ` Re : [Caml-list] " Kuba Ober 2008-10-15 9:42 ` David Allsopp 2008-10-15 12:33 ` Kuba Ober 2008-10-14 21:39 ` Kuba Ober 2008-10-14 15:56 ` [Caml-list] " David Allsopp 2008-10-14 17:39 ` Re : " Dmitry Bely 2008-10-14 19:31 ` Re : " Adrien 2008-10-14 9:57 ` Mathias Kende 2008-10-14 21:38 ` Kuba Ober 2008-10-15 0:01 ` Sylvain Le Gall 2008-10-15 12:35 ` [Caml-list] " Kuba Ober 2008-10-15 12:54 ` Dmitry Bely 2008-10-15 13:18 ` Sylvain Le Gall 2008-10-15 14:35 ` [Caml-list] " Kuba Ober 2008-10-15 15:29 ` Dmitry Bely 2008-10-15 16:26 ` Kuba Ober 2008-10-15 16:39 ` Xavier Leroy 2008-10-15 5:57 ` [Caml-list] " Dmitry Bely 2008-10-15 9:42 ` David Allsopp 2008-10-26 22:07 ` Markus E L 2008-10-14 9:25 ` Sylvain Le Gall 2008-10-14 18:19 ` Cross-compilation (was: Re: [Caml-list] Road to native windows OCaml...) Richard Jones 2008-10-15 0:04 ` Erik de Castro Lopo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).