Road to native windows OCaml...

Road to native windows OCaml...

[Kuba Ober]

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

Re: [Caml-list] Road to native windows OCaml...

[Seo Sanghyeon]

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

Re: [Caml-list] Road to native windows OCaml...

[Elliott Oti]

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

Re: Road to native windows OCaml...

[Sylvain Le Gall]

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

RE: [Caml-list] Road to native windows OCaml...

[David Allsopp]

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

Re: [Caml-list] Road to native windows OCaml...

[Daniel Bünzli]

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

Re: Road to native windows OCaml...

[Sylvain Le Gall]

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

Re: Road to native windows OCaml...

[Sylvain Le Gall]

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

Re : [Caml-list] Road to native windows OCaml...

[Adrien]

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
>

Re: [Caml-list] Road to native windows OCaml...

[Mathias Kende]

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/

Re: Re : Road to native windows OCaml...

[Sylvain Le Gall]

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

Re : [Caml-list] Re: Re : Road to native windows OCaml...

[Adrien]

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
>

Re: Re : Re: Re : Road to native windows OCaml...

[Sylvain Le Gall]

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

RE: [Caml-list] Road to native windows OCaml...

[David Allsopp]

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

Re: Re : [Caml-list] Road to native windows OCaml...

[Dmitry Bely]

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

Cross-compilation (was: Re: [Caml-list] Road to native windows OCaml...)

[Richard Jones]

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

Re : Re : [Caml-list] Road to native windows OCaml...

[Adrien]

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
>

Re : [Caml-list] Re: Re : Re: Re : Road to native windows OCaml...

[Adrien]

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
>

Re: [Caml-list] Road to native windows OCaml...

[Kuba Ober]

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

Re: [Caml-list] Road to native windows OCaml...

[Kuba Ober]

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

Re: [Caml-list] Re: Road to native windows OCaml...

[Kuba Ober]

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

Re: [Caml-list] Road to native windows OCaml...

[Kuba Ober]

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

Re: [Caml-list] Re: Re : Road to native windows OCaml...

[Kuba Ober]

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

Re: Re : [Caml-list] Re: Re : Road to native windows OCaml...

[Kuba Ober]

> 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

Re: Road to native windows OCaml...

[Sylvain Le Gall]

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

Re: Cross-compilation (was: Re: [Caml-list] Road to native windows OCaml...)

[Erik de Castro Lopo]

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

Re: [Caml-list] Re: Road to native windows OCaml...

[Dmitry Bely]

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

Re: [Caml-list] Road to native windows OCaml...

[Dmitry Bely]

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

RE: [Caml-list] Road to native windows OCaml...

[David Allsopp]

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

RE: Re : [Caml-list] Re: Re : Road to native windows OCaml...

[David Allsopp]

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

RE: [Caml-list] Road to native windows OCaml...

[David Allsopp]

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

Re: Re : [Caml-list] Re: Re : Road to native windows OCaml...

[Kuba Ober]

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

Re: [Caml-list] Re: Road to native windows OCaml...

[Kuba Ober]

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

Re: [Caml-list] Road to native windows OCaml...

[Kuba Ober]

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

Re: [Caml-list] Re: Road to native windows OCaml...

[Dmitry Bely]

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

Re: [Caml-list] Road to native windows OCaml...

[Seo Sanghyeon]

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

Re: Road to native windows OCaml...

[Sylvain Le Gall]

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

Re: [Caml-list] Re: Road to native windows OCaml...

[Kuba Ober]

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

Re: [Caml-list] Road to native windows OCaml...

[Kuba Ober]

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

Re: [Caml-list] Re: Road to native windows OCaml...

[Kuba Ober]

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

Re: [Caml-list] Re: Road to native windows OCaml...

[Dmitry Bely]

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

Re: [Caml-list] Re: Road to native windows OCaml...

[Kuba Ober]

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

Re: [Caml-list] Re: Road to native windows OCaml...

[Xavier Leroy]

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

Re: [Caml-list] Road to native windows OCaml...

[Markus E L]

"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