Re: [Caml-list] Dynamic loading on Mac OS X
Le 15 oct. 08 à 22:14, Harrison, John R a écrit : Am I just plain wrong, or has this really only started to work recently? Dynamic linking of C libraries worked for me on macosx (at least ppc) a long time ago. According to the release notes this happened in 3.07, i.e. in 2003. Best, Daniel ___ 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
[Caml-list] Dynamic loading on Mac OS X
This discussion of dynamic loading in 3.11 reminded me of a more basic question I meant to ask, but never did. On certain platforms, e.g. all Linuxes I've ever used, the following works in a plain OCaml toplevel: #load "nums.cma";; On other platforms, notably Cygwin, it doesn't. (At least, for OCaml 3.10 on my version of Cygwin, which is not very old.) # #load "nums.cma";; Cannot load required shared library dllnums. Reason: dllnums.so: dynamic loading not supported on this platform. I was sure that Mac OS X was among the platforms where this *doesn't* work, based on experiments a year or two ago. However I recently found that apparently it *does* after all work on my Mac. Since the original experiments I've upgraded the Mac to Leopard, and maybe I've even changed my OCaml version, though I don't remember for sure. Am I just plain wrong, or has this really only started to work recently? John. ___ 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] OCaml version 3.11.0+beta1
On Oct 15, 2008, at 12:03 PM, Xavier Leroy wrote: Native dynlink used to work on Mac OS X < 10.5 (x86 only). The new linker in 10.5 does not support linking shared libraries with non- PIC code. It is still possible to use the old linker, called ld_classic, but some libraries (like X11) does not work, so this has been disabled in the configure script. The clean solution to make natdynlink work on recent Mac OS X systems (beside convincing Apple to support the old behavior of their linker in their new implementation) is to change OCaml's x86 backend so that it produces only PIC code (this has been done for the AMD64 port). I don't think there is currently any plan to work on that. Ouch, this makes it almost a dead end for us. I can offer some time to help in this effort, working in the port, or providing feedback. The native dynlink and toplevel are, at least to me, the killer features in 3.11, but adding another hole for Mac OS X intel (in addition to not supporting x86_64) does not seem like the best choice for an increasingly popular architecture. Well, we'd very much like to support native dynlink on OS X 10.5, but Apple is not helping in the least by crippling their linker compared with the one in 10.4. If anyone from Apple is on this list, feel free to contact us at [EMAIL PROTECTED] for more information on this regression. I'm glad to report that I just tried with XCode 3.1.1 and the linker did not complain (as it did with XCode 3.0). I wrote a little test and the native Dynlink worked with that version of XCode (using 10.5.5, Intel -- I had to drop an -I flag in the linker call from the OCaml compiler when I was trying it). Andres - Xavier Leroy ___ 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] Quantifier in the type
> I put 'a in the interface:
> val fu : 'a -> 'a
> and int in the implementation:
> let fu x = x + 1
this interface doesn't reflect the implementation, ocaml will reject it in any
way
> So I have universal quantification: for any type 'a function fu can
> consume the argument.
No it is not universal, imagine all the types that a user can create, you
cannot handle them all (except maybe with the Obj module, but it's another
question)
Anyway if you handle different types, you still have to join them in a single
type :
type generic =
| Int of int
| Float of float
| Int64 of int64
... and so on
> So my implementation doesn't comply with that
> universal quatification. And the message I get is following:
>
> Values do not match: val fu : int -> int is not included in val fu : 'a
> -> 'a
Yes it doesn't match at all, the type of the implementation is int, nothing
else.
> So the declaration of value in mli file is called simply a 'value'. Is
> it intentional?
It is just the word in the English language to designate this thing.
> I thought that value and it's declaration are separate notions?
a value is handle by a identifier and has a type
let ident = some_value in
here ident and some_value are of some type
> My reading of " val fu : 'a -> 'a " is:
> some partiular value vvv that belongs to set of values that satisfy
> "forall 'a : (vvv can be used with ('a -> 'a) type)"
here are some examples of functions with type ('a -> 'a) :
let id v = (v)
let return_sleep v = Unix.sleep 3; (v)
let feedback_kind v =
let r = Obj.repr v in
if Obj.is_int r then print_endline "value similar to int";
(v)
;;
# let (duplicate : 'a -> 'a) = function v ->
Obj.obj(Obj.dup(Obj.repr v)) ;;
val duplicate : 'a -> 'a =
# let str = "AAA" ;;
val str : string = "AAA"
# let str2 = duplicate str ;;
val str2 : string = "AAA"
# str.[0] <- 'B' ;;
- : unit = ()
# str, str2 ;;
- : string * string = ("BAA", "AAA")
# let reminder = ref [] ;;
val reminder : '_a list ref = {contents = []}
# let remind_through v =
if List.exists (fun this -> Obj.magic v = this) !reminder
then failwith "allready processed"
else begin
reminder := Obj.magic v :: !reminder;
(v)
end
;;
val remind_through : 'a -> 'a =
# let a, b, c, d =
"Hello",
4096,
4.0 *. atan 1.0,
None;;
val a : string = "Hello"
val b : int = 4096
val c : float = 3.14159265358979312
val d : 'a option = None
# remind_through a ;;
- : string = "Hello"
# remind_through b ;;
- : int = 4096
# remind_through c ;;
- : float = 3.14159265358979312
# remind_through d ;;
- : 'a option = None
# remind_through a ;;
Exception: Failure "allready processed".
> But if I write
> let (bar : 'a -> 'a ) = (fun x -> x + 1)
> I create a value that belongs to set "exists 'a : (vvv can be used with
> ('a -> 'a) type)"
> So it's the other quantifier.
int can be used for a function which takes 'a, but this opposite is not true:
a function that implements with ints can not take 'a parameters.
> I think that the quantifier has to be part of type, since a type is set
> of values (and the quantifier plays important role when describing some
> of such sets).
> So my question is: since we see the same string " 'a -> 'a " that refers
> to different types in different contexts, what are the rules? How is
> type definition in OCaml translated to a type?
type definition in OCaml are translated to actual types by inference.
http://en.wiktionary.org/wiki/inference
(fun x -> x + 1) will be easily infered to (int -> int)
The only way to do a generic function to make addition on generic types as
float, int, or a number in a string, is like the example below.
But those kind of things are HIGHLY discouraged !
Please consider each Obj.magic as a hammer hit,
you will understand that programming with a hammer is discouraged :-)
# let gen_add v =
let r = Obj.repr v in
let tag = Obj.tag r in
if tag = Obj.int_tag then
(Obj.magic((Obj.magic v) + 1))
else if tag = Obj.double_tag then
(Obj.magic((Obj.magic v) +. 1.0))
else
try if tag = Obj.string_tag then
(Obj.magic(Scanf.sscanf (Obj.magic v) "%f"
(fun v -> string_of_float(v +. 1.0
else
(v)
with Scanf.Scan_failure _ -> (v)
;;
val gen_add : 'a -> 'a =
# gen_add 3 ;;
- : int = 4
# gen_add 3.0 ;;
- : float = 4.
# gen_add "3" ;;
- : string = "4."
--
Florent
___
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] OCaml version 3.11.0+beta1
On Wed, Oct 15, 2008 at 03:40:01PM +0200, Damien Doligez wrote: > We are pleased to celebrate the birthday of Friedrich Nietzsche > by releasing OCaml version 3.11.0+beta1. We need YOU to test > it thoroughly and report any problems you might have. Does > your favorite software work with it? Excellent news. For Fedora we'll probably leave this until Fedora 11, which should begin in a week or two. Rich. -- Richard Jones Red Hat ___ 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] OCaml version 3.11.0+beta1
Le 15 oct. 08 à 17:27, Andres Varon a écrit : The native Dynlink is known to work under Linux x86, Linux AMD64, Win32 (mingw/msvc ports). It has been lightly tested under Win64, some flavors of BSDs and also the Cygwin port. And on macosx ? It seems here on 10.5.5 that only dynlink.cma and dynlink.cmi for bytecode get installed. So I guess there's no support. What about the future ? It was installed here: Mac OS X 10.5.5 x86. Maybe this is an issue that I mentioned before in the list and got no response?: At least one cmxa only get installed if you make opt.opt. camlp4fulllib.cmxa was not installed with only make opt (which led to broken installations that would not let my apps compile). In fact it was compiled but not installed. I'm using fastword.sh on 10.5.5. x86 and it seems install.sh doesn't install dynlink.cmxa and dynlink.mli Best, Daniel ___ 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: Road to native windows OCaml...
>> 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 ___ 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] Native win32 OCaml: recap
On Wednesday 15 October 2008, Kuba Ober wrote: > 6. ocamlopt can use either ml or masm for assembler; ml comes with > recent Visual Studios. When ml is not present, it would be good > to have it use nasm instead. Replying to myself: ml == masm, and ml is present in all VS 2008 SP1, including Express, so no problems there and no need for nasm. 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: [Caml-list] Re: Road to native windows OCaml...
> >> >> 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 ___ 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] OCaml version 3.11.0+beta1
>> Native dynlink used to work on Mac OS X < 10.5 (x86 only). The new >> linker in 10.5 does not support linking shared libraries with non-PIC >> code. It is still possible to use the old linker, called ld_classic, >> but some libraries (like X11) does not work, so this has been disabled >> in the configure script. >> >> The clean solution to make natdynlink work on recent Mac OS X systems >> (beside convincing Apple to support the old behavior of their linker >> in their new implementation) is to change OCaml's x86 backend so that >> it produces only PIC code (this has been done for the AMD64 port). I >> don't think there is currently any plan to work on that. > > Ouch, this makes it almost a dead end for us. I can offer some time to > help in this effort, working in the port, or providing feedback. The > native dynlink and toplevel are, at least to me, the killer features in > 3.11, but adding another hole for Mac OS X intel (in addition to not > supporting x86_64) does not seem like the best choice for an > increasingly popular architecture. Well, we'd very much like to support native dynlink on OS X 10.5, but Apple is not helping in the least by crippling their linker compared with the one in 10.4. If anyone from Apple is on this list, feel free to contact us at [EMAIL PROTECTED] for more information on this regression. - Xavier Leroy ___ 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] OCaml version 3.11.0+beta1
On Oct 15, 2008, at 11:32 AM, Alain Frisch wrote: Daniel Bünzli wrote: And on macosx ? It seems here on 10.5.5 that only dynlink.cma and dynlink.cmi for bytecode get installed. So I guess there's no support. What about the future ? Native dynlink used to work on Mac OS X < 10.5 (x86 only). The new linker in 10.5 does not support linking shared libraries with non- PIC code. It is still possible to use the old linker, called ld_classic, but some libraries (like X11) does not work, so this has been disabled in the configure script. The clean solution to make natdynlink work on recent Mac OS X systems (beside convincing Apple to support the old behavior of their linker in their new implementation) is to change OCaml's x86 backend so that it produces only PIC code (this has been done for the AMD64 port). I don't think there is currently any plan to work on that. Ouch, this makes it almost a dead end for us. I can offer some time to help in this effort, working in the port, or providing feedback. The native dynlink and toplevel are, at least to me, the killer features in 3.11, but adding another hole for Mac OS X intel (in addition to not supporting x86_64) does not seem like the best choice for an increasingly popular architecture. Again, thanks for the good work! Andres Alain ___ 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 ___ 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] OCaml version 3.11.0+beta1
Andres Varon wrote: OK. Would you recommend that configure scripts use this test to verify if the functionality is supported? Yes. -- Alain ___ 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] OCaml version 3.11.0+beta1
On Oct 15, 2008, at 11:37 AM, Alain Frisch wrote: Andres Varon wrote: One more question: is it always compiled? or is dynlink.cmxa simply not available in some architectures? if yes, what are those? As far as I can tell, dynlink.cmxa is always compiled. You will get error when "ocamlopt -shared" on those architecture where natdynlink is not supported. OK. Would you recommend that configure scripts use this test to verify if the functionality is supported? Andres -- Alain ___ 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] OCaml version 3.11.0+beta1
Andres Varon wrote: One more question: is it always compiled? or is dynlink.cmxa simply not available in some architectures? if yes, what are those? As far as I can tell, dynlink.cmxa is always compiled. You will get error when "ocamlopt -shared" on those architecture where natdynlink is not supported. -- Alain ___ 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] OCaml version 3.11.0+beta1
Daniel Bünzli wrote: And on macosx ? It seems here on 10.5.5 that only dynlink.cma and dynlink.cmi for bytecode get installed. So I guess there's no support. What about the future ? Native dynlink used to work on Mac OS X < 10.5 (x86 only). The new linker in 10.5 does not support linking shared libraries with non-PIC code. It is still possible to use the old linker, called ld_classic, but some libraries (like X11) does not work, so this has been disabled in the configure script. The clean solution to make natdynlink work on recent Mac OS X systems (beside convincing Apple to support the old behavior of their linker in their new implementation) is to change OCaml's x86 backend so that it produces only PIC code (this has been done for the AMD64 port). I don't think there is currently any plan to work on that. Alain ___ 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] OCaml version 3.11.0+beta1
On Wednesday 15 October 2008 15:40:01 Damien Doligez wrote: > We are pleased to celebrate the birthday of Friedrich Nietzsche > by releasing OCaml version 3.11.0+beta1. We need YOU to test > it thoroughly and report any problems you might have. Does > your favorite software work with it? For ease of testing, I've very quickly updated the FreeBSD port (lightly tested, as in "it seems to work for me"). It is available at http://www.pps.jussieu.fr/~boender/ocamlport.tar.gz (to be untarred at the root of your ports tree). Have fun, Jaap Boender -- On two occasions I have been asked [by members of Parliament!], "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. -- Charles Babbage ___ 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] OCaml version 3.11.0+beta1
On Wed, Oct 15, 2008 at 05:04:46PM +0200, Alain Frisch wrote: > Andres Varon wrote: >> Thanks for the good work. I would like to know exactly what >> architectures support the native Dynlink? I did not see this >> information in the release notes. > The native Dynlink is known to work under Linux x86, Linux AMD64, Win32 > (mingw/msvc ports). It has been lightly tested under Win64, some flavors > of BSDs and also the Cygwin port. [ Sorry for being lazy to check by myself, but apparently the question is of wide-interest. ] Is that something that packagers should worry about or not? I mean, the specific modules/libraries/... are already detected by configure and not built/installed/... on architectures missing them or should we (packages) enforce that? Many thanks in advance (and for native Dynlink of course :-))! Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach ___ 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: Road to native windows OCaml...
On Wed, Oct 15, 2008 at 6:35 PM, Kuba Ober <[EMAIL PROTECTED]> wrote: > On Wednesday 15 October 2008, Dmitry Bely wrote: >> On Wed, Oct 15, 2008 at 4:35 PM, Kuba Ober <[EMAIL PROTECTED]> 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 ___ 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] OCaml version 3.11.0+beta1
On Oct 15, 2008, at 11:22 AM, Daniel Bünzli wrote: The native Dynlink is known to work under Linux x86, Linux AMD64, Win32 (mingw/msvc ports). It has been lightly tested under Win64, some flavors of BSDs and also the Cygwin port. And on macosx ? It seems here on 10.5.5 that only dynlink.cma and dynlink.cmi for bytecode get installed. So I guess there's no support. What about the future ? It was installed here: Mac OS X 10.5.5 x86. Maybe this is an issue that I mentioned before in the list and got no response?: At least one cmxa only get installed if you make opt.opt. camlp4fulllib.cmxa was not installed with only make opt (which led to broken installations that would not let my apps compile). Andres Thanks, Daniel ___ 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 ___ 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] OCaml version 3.11.0+beta1
Le 15 oct. 08 à 16:55, Andres Varon a écrit : Thanks for the good work. I would like to know exactly what architectures support the native Dynlink? I did not see this information in the release notes. I was looking for the same information. This should be added to the release notes. Le 15 oct. 08 à 17:04, Alain Frisch a écrit : The native Dynlink is known to work under Linux x86, Linux AMD64, Win32 (mingw/msvc ports). It has been lightly tested under Win64, some flavors of BSDs and also the Cygwin port. And on macosx ? It seems here on 10.5.5 that only dynlink.cma and dynlink.cmi for bytecode get installed. So I guess there's no support. What about the future ? Thanks, Daniel ___ 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] OCaml version 3.11.0+beta1
On Oct 15, 2008, at 11:04 AM, Alain Frisch wrote: Andres Varon wrote: Thanks for the good work. I would like to know exactly what architectures support the native Dynlink? I did not see this information in the release notes. The native Dynlink is known to work under Linux x86, Linux AMD64, Win32 (mingw/msvc ports). It has been lightly tested under Win64, some flavors of BSDs and also the Cygwin port. Great, thanks for the info. Is there a set of tests that I can run? I would like to see how it works in Mac OS X which is my primary development environment and the second most important among our users. One more question: is it always compiled? or is dynlink.cmxa simply not available in some architectures? if yes, what are those? Andres -- Alain ___ 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] File inclusion with Ocamldoc
Excerpts from Dario Teixeira's message of Wed Oct 15 16:43:32 +0200 2008: > Hi, > > > It works for me with the 3.10.1. I just tried to write a > > file test.ml, and a file truc.odocl with "Test" in it, and then > > ran ocamlbuild : > > ocamlbuild truc.docdic/index.html > > And it worked. Or maybe I didn't understand what you want? > > You're right. I took the Ocamlbuild manual at face value, since > it states it cannot handle implementation files. Nevertheless, > I'm still running into some problems with Ocamlbuild+Ocamldoc. > First, while Ocamldoc will by default merge the comments from .ml > and .mli files (with precedence given to the .mli file, unless > -inv-merge-ml-mli is given), when I use Ocamlbuild to generate > the documentation I notice the following pattern: if only the .ml > file is present then it's used for generating the documentation; > If, however, both .ml and .mli are present, then only the .mli > is taken into account (no merging is done). Second, how does one > tell Ocamlbuild to include .txt files in the documentation? The manual states that implementation files are not handled because if you have a .ml and .mli then ocamlbuild will choose the .mli. -- Nicolas Pouillard aka Ertai ___ 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] OCaml version 3.11.0+beta1
Andres Varon wrote: Thanks for the good work. I would like to know exactly what architectures support the native Dynlink? I did not see this information in the release notes. The native Dynlink is known to work under Linux x86, Linux AMD64, Win32 (mingw/msvc ports). It has been lightly tested under Win64, some flavors of BSDs and also the Cygwin port. -- Alain ___ 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
[Caml-list] Quantifier in the type
Just an elementary question.
I put 'a in the interface:
val fu : 'a -> 'a
and int in the implementation:
let fu x = x + 1
So I have universal quantification: for any type 'a function fu can
consume the argument. So my implementation doesn't comply with that
universal quatification. And the message I get is following:
Values do not match: val fu : int -> int is not included in val fu : 'a
-> 'a
So the declaration of value in mli file is called simply a 'value'. Is
it intentional?
I thought that value and it's declaration are separate notions?
My reading of " val fu : 'a -> 'a " is:
some partiular value vvv that belongs to set of values that satisfy
"forall 'a : (vvv can be used with ('a -> 'a) type)"
But if I write
let (bar : 'a -> 'a ) = (fun x -> x + 1)
I create a value that belongs to set "exists 'a : (vvv can be used with
('a -> 'a) type)"
So it's the other quantifier.
I think that the quantifier has to be part of type, since a type is set
of values (and the quantifier plays important role when describing some
of such sets).
So my question is: since we see the same string " 'a -> 'a " that refers
to different types in different contexts, what are the rules? How is
type definition in OCaml translated to a type?
Dawid
___
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] OCaml version 3.11.0+beta1
On Oct 15, 2008, at 9:40 AM, Damien Doligez wrote: Dear OCaml Users, We are pleased to celebrate the birthday of Friedrich Nietzsche by releasing OCaml version 3.11.0+beta1. We need YOU to test it thoroughly and report any problems you might have. Does your favorite software work with it? Thanks for the good work. I would like to know exactly what architectures support the native Dynlink? I did not see this information in the release notes. I need to update configure scripts to include it or not in the link step because dynlink.cmxa is needed by camlp4fulllib.cmxa, but now I realize that it's not just a matter of having OCaml >= 3.11. many thanks again, Andres It is available as a source release only (plus documentation), from this address: < http://caml.inria.fr/pub/distrib/ocaml-3.11/ > It is also available from our CVS server at: < http://camlcvs.inria.fr/ > Use tag "ocaml3110beta1" to get the beta release, and tag "release311" to track the bug fixes between this and the final release of 3.11.0. Have fun and PLEASE send us some feedback, positive or negative. -- The OCaml team. - Camlp5 HOW-TO Camlp5 version 5.09 does not work with OCaml 3.11.0+beta1 out of the box. A new version compatible with OCaml 3.11.0 should be released very soon. In the meantime you can use the following commands (in the root directory of the Camlp5 5.09 sources) to compile Camlp5 5.09 with OCaml 3.11.0+beta1. Note that you will need to provide the path name to a copy of the OCaml 3.11.0+beta1 sources at the line labelled "HERE". cp -R ocaml_stuff/3.11 ocaml_stuff/3.11.0 cp ocaml_src/main/ast2pt.ml_3.11 ocaml_src/main/ast2pt.ml_3.11.0 ed main/ast2pt.ml <<-EOF g/OCAML_3_11/s//& OR OCAML_3_11_0/ wq EOF ed top/rprint.ml <<-EOF g/OCAML_3_11/s//& OR OCAML_3_11_0/ wq EOF ./configure --transitional make steal OCAML_SRC= # HERE make core make bootstrap_sources ./configure --transitional make world.opt That's all. Now you can "make install" as usual. ___ 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 ___ 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] File inclusion with Ocamldoc
Hi, > It works for me with the 3.10.1. I just tried to write a > file test.ml, and a file truc.odocl with "Test" in it, and then > ran ocamlbuild : > ocamlbuild truc.docdic/index.html > And it worked. Or maybe I didn't understand what you want? You're right. I took the Ocamlbuild manual at face value, since it states it cannot handle implementation files. Nevertheless, I'm still running into some problems with Ocamlbuild+Ocamldoc. First, while Ocamldoc will by default merge the comments from .ml and .mli files (with precedence given to the .mli file, unless -inv-merge-ml-mli is given), when I use Ocamlbuild to generate the documentation I notice the following pattern: if only the .ml file is present then it's used for generating the documentation; If, however, both .ml and .mli are present, then only the .mli is taken into account (no merging is done). Second, how does one tell Ocamlbuild to include .txt files in the documentation? Thanks again for your attention, Dario Teixeira ___ 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
[Caml-list] Native win32 OCaml: recap
Here's the recap from the discussion so far. I'm only considering win32 platform, nothing else. Please pitch in if I didn't get it right this time: 1. OCaml 3.11 will have a non-replaying bytecode debugger that runs on native ports (built with msvc or mingw). 2. OCaml requires an installed C compiler, linker and assmebler -- same ones as used during build - to link with native code. 3. Bytecode OCaml requires no external tools to "compile" and run OCaml code that does not call upon newly defined native functions. 4. ocamlopt does require assembler and linker to produce the executable. 5. OCaml requires at least msys to build itself using either msvc or mingw compilers. msys is provides bash, make and friends. OCaml does not build using nmake. 6. ocamlopt can use either ml or masm for assembler; ml comes with recent Visual Studios. When ml is not present, it would be good to have it use nasm instead. 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: [Caml-list] Re: Road to native windows OCaml...
On Wednesday 15 October 2008, Dmitry Bely wrote: > On Wed, Oct 15, 2008 at 4:35 PM, Kuba Ober <[EMAIL PROTECTED]> 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 ___ 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...
On Wednesday 15 October 2008, Seo Sanghyeon wrote: > 2008/10/15 Kuba Ober <[EMAIL PROTECTED]>: > > 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 ___ 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] OCaml version 3.11.0+beta1
Hi, > We are pleased to celebrate the birthday of Friedrich > Nietzsche by releasing OCaml version 3.11.0+beta1. We need YOU > to test it thoroughly and report any problems you might have. > Does your favorite software work with it? Great news, thanks! One note to GODI users: trying out the beta version is very simple; just ask GODI to build the godi-ocaml and godi-ocaml-src packages, and configure the latter one by setting OCAML_CVS_CHECKOUT to "yes" and OCAML_CVS_REVISION to "release311" (or "ocaml3110beta1" if you want the Beta 1 static snapshot). GODI will then automatically recompile all packages. Btw, I noticed that type-conv will *not* compile with this beta (a Camlp4 incompatibility?). Anyone experiencing a similar problem? The GODI protocol is listed at the end. Kind regards, Dario Teixeira /bin/mkdir -p /home/dario/.godi_3.11/build/godi/godi-type-conv/work/type-conv-1.6.2 ===> Patching for godi-type-conv-1.6.2godi1 ===> Configuring for godi-type-conv-1.6.2godi1 ===> Building for godi-type-conv-1.6.2godi1 make[1]: Entering directory `/home/dario/.godi_3.11/build/godi/godi-type-conv/work/type-conv-1.6.2/lib' ocamlc -c -I +camlp4 pa_type_conv.mli ocamlc -c -pp "camlp4orf " -I +camlp4 pa_type_conv.ml File "pa_type_conv.ml", line 190, characters 16-17: While expanding quotation "ctyp" in a position of "patt": Parse error: [a_LIDENT] expected after "?" (in [ctyp]) File "pa_type_conv.ml", line 1, characters 0-1: Error: Preprocessor error make[1]: *** [pa_type_conv.cmo] Error 2 make: *** [all] Error 2 make[1]: Leaving directory `/home/dario/.godi_3.11/build/godi/godi-type-conv/work/type-conv-1.6.2/lib' *** Error code 2 Stop. godi_make: stopped in /home/dario/.godi_3.11/build/godi/godi-type-conv *** Error code 1 ___ 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
[Caml-list] ICFP09: Call for Workshop Proposals
CALL FOR WORKSHOP PROPOSALS ICFP 2009 14th ACM SIGPLAN International Conference on Functional Programming 31st August - 2nd September, 2009 Edinburgh, Scotland http://www.icfpconference.org/icfp2009 The 14th ACM SIGPLAN International Conference on Functional Programming will be held in Edinburgh, Scotland from 31st August to 2nd September 2009. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops to be affiliated with ICFP 2009 and sponsored by SIGPLAN. These workshops should be more informal and focused than ICFP itself, include sessions that enable interaction among the workshop attendees, and be fairly low cost. The preference is for one-day workshops, but other schedules can also be considered. The workshops themselves will be held between August 30th and September 5th, as capacity allows. -- Submission details Deadline for submission: 19th November 2008 Notification of acceptance: 17th December 2008 Prospective workshop organisers are invited to submit a completed workshop proposal form in plain text format to the ICFP 2009 workshop co-chairs (Chris Stone and Mike Sperber), via email to icfp09-workshops at cs.hmc.edu by 19th November 2008. Please note that this is a firm deadline. Organisers will be notified if their proposal is accepted by 17th December 2008, and if successful are required to produce a final report after the workshop has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2009/workshops/icfp09-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://acm.org/sigplan/sigplan_workshop_proposal.htm -- Selection committee The workshop proposals will be evaluated by a committee comprising the following members of the ICFP 2009 organising committee, together with the members of the SIGPLAN executive committee. Chris Stone Harvey Mudd CollegeWorkshops co-chair Mike SperberDeinProgramm Workshops co-chair Graham Hutton University of Nottingham General Chair Andrew Tolmach Portland State University Program Chair -- Further information Any queries regarding ICFP 2009 workshop proposals should be addressed to the workshops co-chairs (Chris Stone and Mike Sperber), via email to icfp09-workshops at cs.hmc.edu ___ 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: Road to native windows OCaml...
> > 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 ___ 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
[Caml-list] OCaml version 3.11.0+beta1
Dear OCaml Users, We are pleased to celebrate the birthday of Friedrich Nietzsche by releasing OCaml version 3.11.0+beta1. We need YOU to test it thoroughly and report any problems you might have. Does your favorite software work with it? It is available as a source release only (plus documentation), from this address: < http://caml.inria.fr/pub/distrib/ocaml-3.11/ > It is also available from our CVS server at: < http://camlcvs.inria.fr/ > Use tag "ocaml3110beta1" to get the beta release, and tag "release311" to track the bug fixes between this and the final release of 3.11.0. Have fun and PLEASE send us some feedback, positive or negative. -- The OCaml team. - Camlp5 HOW-TO Camlp5 version 5.09 does not work with OCaml 3.11.0+beta1 out of the box. A new version compatible with OCaml 3.11.0 should be released very soon. In the meantime you can use the following commands (in the root directory of the Camlp5 5.09 sources) to compile Camlp5 5.09 with OCaml 3.11.0+beta1. Note that you will need to provide the path name to a copy of the OCaml 3.11.0+beta1 sources at the line labelled "HERE". cp -R ocaml_stuff/3.11 ocaml_stuff/3.11.0 cp ocaml_src/main/ast2pt.ml_3.11 ocaml_src/main/ast2pt.ml_3.11.0 ed main/ast2pt.ml <<-EOF g/OCAML_3_11/s//& OR OCAML_3_11_0/ wq EOF ed top/rprint.ml <<-EOF g/OCAML_3_11/s//& OR OCAML_3_11_0/ wq EOF ./configure --transitional make steal OCAML_SRC= # HERE make core make bootstrap_sources ./configure --transitional make world.opt That's all. Now you can "make install" as usual. ___ 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
[Caml-list] Re: Road to native windows OCaml...
On 15-10-2008, Dmitry Bely <[EMAIL PROTECTED]> wrote: > On Wed, Oct 15, 2008 at 4:35 PM, Kuba Ober <[EMAIL PROTECTED]> 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 ___ 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...
2008/10/15 Kuba Ober <[EMAIL PROTECTED]>: > 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 ___ 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: Road to native windows OCaml...
On Wed, Oct 15, 2008 at 4:35 PM, Kuba Ober <[EMAIL PROTECTED]> 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 ___ 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...
On Wednesday 15 October 2008, David Allsopp wrote: > Kuba Ober write: > > On Monday 13 October 2008, Seo Sanghyeon wrote: > > > 2008/10/14 Kuba Ober <[EMAIL PROTECTED]>: > > > > 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 ___ 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: Road to native windows OCaml...
On Tuesday 14 October 2008, Sylvain Le Gall wrote: > On 14-10-2008, Kuba Ober <[EMAIL PROTECTED]> 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 ___ 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 : [Caml-list] Re: Re : Road to native windows OCaml...
> > > 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 ___ 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
[Caml-list] ocamlbuild: ml -> cmx & cmi & o ?
Hi, I observe that ocamlbuild does not build cmx cmi and o files from a ml file (which has no associated mli) directly. Do others see different behavior? Instead it builds cmo and cmi from the ml using ocamlc, and then builds the cmx and o files from there using ocamlopt. Is there a reason I'm missing that ocamlbuild does not have a default rule for this case, using only one call to ocamlopt? If so, is there an easy way to do this with a plugin? Cheers, Josh ___ 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 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 ___ 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 write: > On Monday 13 October 2008, Seo Sanghyeon wrote: > > 2008/10/14 Kuba Ober <[EMAIL PROTECTED]>: > > > 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 ___ 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 : [Caml-list] Re: Re : Road to native windows OCaml...
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 ___ 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] File inclusion with Ocamldoc
You can use .txt files to do this. Simply type ocamldoc
comment (without (** *)) in a file.txt file and pass it to
ocamldoc like any .ml or .mli file. This will be considered
as a File module and you can refer to it by {!File} from any
ocamldoc comment.
Excellent! Thanks for the tip. Incidentally, the 3.10 version
of Ocamlbuild does not support the generation of documentation
from implementation files. Will 3.11 fix this?
It works for me with the 3.10.1. I just tried to write a file test.ml,
and a file truc.odocl with "Test" in it, and then ran ocamlbuild :
ocamlbuild truc.docdic/index.html
And it worked. Or maybe I didn't understand what you want?
--
Romain Bardou
___
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
