Here is the latest Caml Weekly News, for the week of July 31 to August 07, 2012.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-08/msg00010.htmlHendrik Tews announced:
I would like to announce The Enhanced OCaml Documentation Version 4.00 available via http://www.askra.de/software/ocaml-doc/4.00 This version of the OCaml manual enhances the original html version in the following way: - Changes (wrt version 3.12) are tagged with icons and color - an additional appendix contains all grammar rules
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-08/msg00012.htmlXavier Clerc announced:
The OCaml-Java is a project whose goal is to allow compilation of OCaml sources to Java bytecode, thus allowing execution on any JVM. The objectives are to gain access to a greater number of libraries, and to be able to take advantage of multiple cores. Quite a lot of work has been done in order to greatly improve the performances of the code generated by the "ocamljava" compiler. Roughly speaking, some preliminary benchmarks seem to indicate that ocamljava-generated code is most of the time less than three times slower than ocamlopt-generated one. This very mail is sent to try to gather feedback from the community. As of today, the source is neither stabilized nor complete, and only a binary version is available. Installation is very simple: uncompress the archive, and put the "bin" subdirectory in your path. More information can be found in the "README" file of the archive. The archive can be downloaded at the following address: http://ocamljava.x9c.fr/ocamljava-2.0-early-access.tar.gz For this version, I am mostly interested in compatibility reports, and performance considerations. Although the compiler is already able to compile itself, it is probably wise to start with smaller examples...
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-08/msg00018.htmlIvan asked and Alain Frisch replied:
> I've mentioned that in some cases ocaml can't infer type (or maybe it > can, but didn't want to...) of some objects. > Right to this moment, I've just do as ocaml wants - annotate a type and > move forward. But now I want to make things more consciously. The reason > is simple - sometimes ocaml infers types correctly and denotes a type > error in my code, but I, mistakenly thinking that it can't infer type of > object, loose my time in useless type annotating of different > identifiers. Or vice versa, the code is correct, except for some > undecidable object type, and I spend h^Wminutes in checking my code for > errors. > > So, I'would like to know the rules of type inference failures with > object types. In what cases an object type can and must be inferred, and > in what it must be annotated explicitly? > > Can someone share this arcane knowledge or, at least, point me at some > sources, explaining this issue? I don't know if this covers all the case, but you need to keep in mind the following points. Feel free to add to the list. 1. The type-checker will never infer that a method is polymorphic. You need to tell it. object(this) method f = (this # g 1, this # g true) method g x = x end ===> object(this) method f = (this # g 1, this # g true) method g: 'a. 'a -> 'a = fun x -> x end 2. Same for labeled and optional arguments on methods, when the type for the method to be called is not known. class virtual c = object(this) method f = this # g ~x:1 ~y:2 + this # g ~y:1 ~x:2 end ===> class virtual c = object(this) method f = this # g ~x:1 ~y:2 + this # g ~y:1 ~x:2 method virtual g: x:int -> y:int -> int end (Note: this is really not specific to objects, a simple (fun g -> g ~x:1 ~y:2 + g ~y:1 ~x:2) has the same effect, but it's likely to hit you if you use virtual classes.) 3. When declaring classes, the inferred type must have no free variable. So while the expression "object method f x = x end" is allowed and is inferred to have a type "< f : 'a -> 'a >", the following class declaration is rejected: class c = object method f x = x end Depending on what you want to do, you can either force a specific type or make the class parametric: class c = object method f x : int = x end class ['a] c = object method f x : 'a = x endIvan then asked and Jacques Garrigue replied:
> Thanks for nice and structured answer! > > I'll try to expand it with my cases, but due to lack of comprehension they > will not be so clear =) > > So the setup is follows: I have a class with a type explicitly specified in > mli file. No inference on it's methods. And a function, that takes some > object and type system tries to infer what objects it can accept. > > Starting from a simple case: > > let reset_env_model state v = > let q = Queue.create () in > Queue.iter (fun p -> v#expand_row p) q > > produces an error: > This expression has type GTree.view > but an expression was expected of type < expand_row : 'a -> unit; .. > > > Types for method expand_row are incompatible > > because expand_row method of type GTree.view has type: > expand_row : Gtk.tree_path -> unit; > I think, that compiler have a reason to refuse this code: function wants a > method, that can take an arbitrary value of type 'a, but I pass a method > that has a covariant type Gtk.tree_path in position left to arrow. So he > complains correctly. I agree =) I think that this case has some > correspondence with your case #1. Your assumption is wrong. A function never "requires" polymorphism from an argument. It may require a polymorphic method, but only if the type of this argument is given explicitly. The fact is that, at least in lablgtk-2.14.2 (the current version), the type is expand_row : ?all:bool -> Gtk.tree_path -> unit So this enters the second category of methods with optional arguments. > But, why in the following code: > > let reset_env_model state v = > let q = Queue.create () in > let m,_,_ = State.env_model state in > m#foreach (fun p _ -> if v#row_expanded p then Queue.push p q; false); > set_env_model state v; > Queue.iter (fun p -> v#expand_row p) q > > compiler cannot infer, that object p has type Gtk.tree_path, and with this > proposition imply, that the expand_row method has a type "Gtk.tree_path -> > unit"? This is exactly the same problem as above. In some situations it may be a good idea to use the -principal flag, to get more regular behavior from the type checker with respect to required type annotations.Ivan then asked and Jacques Garrigue replied:
>The first thing I've tried was specifying explicitly argument ~all. But >compiler refused to accept this too, with exactly the same error message... For the ~all argument to be properly processed, you first need the type of the method to be known. The best solution is to put a type annotation on v. The next solution is to pass an explicit optional argument: v#expand_row ?all:None x I don't like it much because parameter order matters.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-08/msg00025.htmlAdrien Nader announced:
I'm happy to announce the release of Yypkg 1.5. Yypkg is a small, fast, platform-agnostic package manager. It can be used to manage any directory. It is built to help cross-compilation setups and it works both for and on Windows. Functionality changes: - doesn't rely on sexplib's camlp4 extension anymore (*) - handles running shell scripts when installing a package (yypkg) - skips packaging libtool's .la files (makeypkg) - doesn't try to adapt hard-coded paths in .pc files to the location they are installed to: there are too many hard-coded paths anyway - improve the GUI (still work to do) Fixes: - bad code with select() when reading bsdtar's output (yypkg -install) - don't mix bsdtar warnings with filenames during package installation (yypkg -install) - properly extract files in directories which are not ".". Yypkg is hosted on the OCaml forge at: http://yypkg.forge.ocamlcore.org It can be download from: http://forge.ocamlcore.org/frs/download.php/955/yypkg-1.5.0.tar.gz
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-08/msg00037.htmlXavier Clerc announced:
This post announces the 1.1 release of the Argot project, whose goal is to provide an enhanced HTML generator for ocamldoc, released under the GPL v3. Home page: http://argot.x9c.fr Preview page (for search feature): - http://argot.x9c.fr/distrib/argot-4.00-libref-frame/argot_index.html - http://argot.x9c.fr/distrib/argot-4.00-libref-popup/index.html Forge page: https://forge.ocamlcore.org/projects/argot/ Main changes since 1.0: - full-text search over comments - search by type can now take advantage of type manifests - search by type now handles labeled parameters - search by type now handles optional parameters - new '-search-frame' command-line switch to have search panel in a frame, rather than in a window - update for OCaml 4.00.0rixed asked and Xavier Clerc replied:
> I can't build it on ocaml 3.12.1: > > File "src/search.mli", line 21, characters 30-54: > Error: Unbound module Odoc_html.Generator > > According to ocamlobjinfo, Odoc_html module is not present in odoc_info.cma. > OCaml's ocamldoc/Makefile lists odoc_html in EXECMOFILES but not in CMOFILES, > which is the list of modules gathered in odoc_info.cma. Aparently it was > not deemed worth of installation back then. :-) Well, sorry about that but 3.12 is no longer supported. The ocamldoc APIs are different in 3.12 and 4.00, and I don't want to support both.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-08/msg00040.htmlNicolas FRANCOIS asked:
I'd like to create a 3D dynamic geometry application. I developped DrGeoCaml a few years ago, but it's now quite old, and my Caml practice is a bit rusty. So a few questions to start on the right tracks : 1) I'd like to create a parser, with the help of ocamllex/yacc, but I don't find the help pages very instructive. Is there a good tutorial like "Ocamllex for complete numbs" ? 2) I'd like to use lablgtk for the graphic interface, and lablgl for the 3D visualization. It's mentionned in lablgtk documentation that this can be done, but once again, i didn't find much help. Any clue ?Gerd Stolpmann replied to the first question:
I don't know of any such tutorial, but you can also watch out for a lex tutorial (i.e. for C), because the matching algorithm is exactly the same. The syntax is of course different, but I guess this is the easier part, and extractable from the manual (or sample code). Regarding ocamlyacc, consider to use Menhir instead. It includes a mode where grammar conflicts are explained by example, and in my experience this is the difficult part of developing a grammar. And it has macros, and other convenience features.Oliver also replied:
Ocamllex-Tutorial: http://plus.kaist.ac.kr/~shoh/ocaml/ocamllex-ocamlyacc/ocamllex-tutorial/ Ocamlyacc-Tutoprial: http://plus.kaist.ac.kr/~shoh/ocaml/ocamllex-ocamlyacc/ocamlyacc-tutorial/Florent Monnier replied to the second question:
We can use LablGTK for OpenGL windowing with any OCaml-OpenGL bindings. There are currently 3 OCaml-OpenGL bindings: - LablGL (the older one) http://forge.ocamlcore.org/projects/lablgl/ - GLCaml (generated code) http://glcaml.sourceforge.net/ - glMLite () http://www.linux-nantes.org/%7Efmonnier/ocaml/GL/ As long as I know, if you want to write forward compatible OpenGL code in OCaml, you can only do so with glMLite. If you need some help for LablGTK-OpenGL (any binding) or OpenGL in OCaml (any binding) just ask.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-08/msg00060.htmlAdrien Nader announced:
Following the new version of yypkg, here is a release of mingw-builds, a whole build environment for windows, with all the benefits of a package manager, everywhere. The website is currently at: http://notk.org/~adrien/yypkg/index.html The doc to run build scripts yourself is currently a bit hidden since it's a first release and I can't drown people in details, but be assured the system is portable and reproducible, easily. Compared to the previous releases, this: - changes the build infrastructure to something much better - requires less work for new packages - has its own builds of the toolchain - runs in a chroot (no other sane way) It still doesn't provide ocaml packages because of the lack of an upstream cross-compiler. I expect this to be solved relatively soon.
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the recent posts from the ocamlcore planet blog at http://planet.ocamlcore.org/. Merge Right: http://alaska-kamtchatka.blogspot.com/2012/08/merge-right.html Opa 1.0.5 released: great improvements in Node.js backend: http://blog.opalang.org/2012/08/opa-105-released-improvements-on-nodejs.html A Helping Phantom Hand: http://alaska-kamtchatka.blogspot.com/2012/08/a-helping-phantom-hand.html Register allocation in CompCert: http://gallium.inria.fr/~scherer/gagallium/register-allocation/index.html OCaml Asterisk: https://forge.ocamlcore.org/projects/astml/
If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.
If you also wish to receive it every week by mail, you may subscribe online.