Here is the latest Caml Weekly News, for the week of September 13 to 20, 2011.
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-09/msg00092.htmlContinuing an old thread, Benedikt Meurer announced:
> I'll push the i386 version once cleaned up and integrated with the approach > implemented for the amd64 version now. The i386 version is also fully functional now, and our current prototype is available from the ocamlnat-jit branch from my "ocaml-experimental" repository at: https://github.com/bmeurer/ocaml-experimental/tree/ocamlnat-jit > It should be noted that there's still some room left for optimizations > (i.e. use short jumps whenever possible, etc.), but the results so far are > already quite promising: The new ocamlnat beats both the old ocamlnat as > well as the byte code toplevel in every benchmark I've tried. I'll prepare > a detailed comparison when time permits. I did a preliminary comparison today, results are available at: http://ps.informatik.uni-siegen.de/~meurer/tmp/ocamlnat-benchmark-20110914.pdf The results are given as speedup compared to the OCaml 3.12.1 byte code toplevel. "OCamlNat/jit" is ours, "OCamlNat/ext" is the ocamlnat thing that silently ships with OCaml 3.12.1, and "OCamlJIT2" is my previous byte code JITter. Time was measured as combined user+system time for the toplevel process plus all child processes. As you can see, we achieved speedups of up to 100 times faster than the byte code toplevel (which is in part related to the fact that llvm-gcc is the default compiler with OS X Lion, and thereby disables the register assignment optimizations for the byte code interpreter).
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-09/msg00128.htmlSatoshi Ogasawara announced:
I'd like to announce the release of PEC, a push style event combinator. PEC : https://github.com/osiire/Pec This small module(about 350 LOC) provides - a composable event. - map, choose, never, join and several useful functions. - immediate reactions corresponds sending data to events. - no memory leaks. I think PEC is useful to write event driven systems. The signature is as follows. type 'a event (** [make ()] makes a new event and sender function.*) val make : unit -> 'a event * ('a -> unit) val map : ('a -> 'b) -> 'a event -> 'b event (** [choose l] is a event which will be raised when one of specified events occurred. *) val choose : 'a event list -> 'a event val never : 'a event (** [join ee] is a event which will be raised when a inner event occurred. "Inner event" is a event comes from outer event [ee]. *) val join : 'a event event -> 'a event (** [bind e f] is [join (map f e)] *) val bind : 'a event -> ('a -> 'b event) -> 'b event val scan : ('a -> 'b -> 'a) -> 'a -> 'b event -> 'a event val filter : ('a -> bool) -> 'a event -> 'a event val filter_map : ('a -> 'b option) -> 'a event -> 'b event val zip : 'a event -> 'b event -> ('a * 'b) event val take_while : ('a -> bool) -> 'a event -> 'a event val take_while_in : ('a -> bool) -> 'a event -> 'a event val take_n : int -> 'a event -> 'a event val once : 'a event -> 'a event val drop_while : ('a -> bool) -> 'a event -> 'a event val drop_n : int -> 'a event -> 'a event val delay : int -> 'a event -> 'a event val pairwise : 'a event -> ('a * 'a) event (** [subscribe f e] attaches the [f] to the specified event. The [f] will be called when the [e] will occurred. *) val subscribe : ('a -> unit) -> 'a event -> unit (** [value e] returns a reference cell which store a latest value *) val value : 'a -> 'a event -> 'a ref (** [run ()] runs PEC event system and returns a number of queuing size of sended data. *) val run : unit -> int e.g. Using PEC, you can write a drag event from mouse events like this. let (+>) f g = g f (* E is PEC module *) let dragging mouse_down mouse_up mouse_move = E.bind mouse_down (fun dloc -> E.choose [ E.map (fun uloc -> `Drop (dloc, uloc)) mouse_up; E.map (fun mloc -> `Drag (dloc, mloc)) mouse_move; ] +> E.take_while_in (function `Drop _ -> false | _ -> true))Philippe Veber asked and Satoshi Ogasawara replied:
> How would you compare it with react (http://erratique.ch/software/react) > which, AFAIU, can > be used for similar purposes ? At least I can see there is no notion of > signal (continuous > function of time) in PEC (or maybe signals can be emulated somehow ?). Also > could you > comment on the 'no memory leaks' feature ? Yes, both the react and PEC can be used for similar purpose. But there are some different points between the two libraries. - PEC is "subscribe" centered. If you leave a event alone without subscribing, no actions will be occurred even if you send data to the event. The react library's system always runs update cycle at sending data to events. - Instead of signal, PEC have "value" function. "value" function attaches a event and returns a reference cell which contains latest occurrence data of the event. I think it's enough because signal is only terminal point of reactive events. - PEC's inside representation of event is not dependency graph but just nested variants. Let me assume a event A depends on other event B. In case of using dependency graph, event B has pointer of event A. This caused difficulty about memory leaks because there is no good timing to free the event A. PEC's event is just a nested variants. It means that event A has pointer of event B. So the event A will be garbage-collected automatically when the reference to the event A from application layer disappeared. That is the reason why "no memory leaks".
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-09/msg00132.htmlJun Furuse announced:
I have written a patch to detect redundant opens in OCaml source code, which is useful to keep your opened module list minimum. Keeping the list smaller is good to avoid name space contamination. You can obtain the latest diff for OCaml 3.12.1 from my repo at https://bitbucket.org/camlspotter/mutated_ocaml . After cloning, get it by: hg diff -r ocaml-3.12.1-11110 -r redundant_open_warning After patching, building is as usual: make core coreboot world opt opt.opt install # Beware what you are doing! I have found nearly 150 redundant opens in OCaml source code! You should check your OCaml code with it, too! http://camlspotter.blogspot.com/2011/09/redundant-open-module-warning-for-ocaml.htmlMehdi Dogguy then asked and Jun Furuse replied:
> It looks interesting. Thanks for your contribution ! Can you open a > bugreport on mantis  and attach the patch there? so that it doesn't > get lost. > >  http://caml.inria.fr/mantis/ Done. http://caml.inria.fr/mantis/view.php?id=5357
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-09/msg00137.htmlContinuing this thread, Markus Mottl announced:
this seems like a good occasion to announce the availability of the latest versions of Jane Street Core, Core Extended, and related libraries (type-conv, bin-prot, sexplib, fieldslib, variantslib) in Godi. Your preprocessing problem should be fixed in the latest versions of these packages. For manual installation you may need to download some of them from OCaml Forge instead, which is more up-to-date. All packages should build on both Linux and Mac OS X. Jane Street's "patdiff" tool should also become available in Godi some time later today.
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-09/msg00145.htmlDeep in this thread, Dmitry Grebeniuk said and Jérémie Dimino replied:
> When I began to use Lwt, I was badly surprised > by the fact that Lwt.t values are not real I/O actions. > So I had to get a new habit: if the top-level module > value has type Lwt.t 'a, I have to defer its > computation by wrapping it under "fun () -> <expr>". > And I have to remember which of my functions return > Lwt.t values, which of my abstract types really have > type Lwt.t 'a or contain the Lwt.t 'a values, to defer > their computations/sideeffects too. You are comparing Lwt with the IO monad. They are two different monads: IO deals with actions while Lwt deals with threads. If you write: let m = IO.read_char IO.stdin then [m] is just the description of the action of reading a character from [stdin]. On the contrary, if you write: let m = Lwt_io.read_char Lwt_io.stdin then [m] is really a thread waiting for a character from [stdin]. If you use "fun () -> ..." everywhere then this becomes actions but it is not threads anymore and you loose most of the advantages of Lwt. For example with Lwt you can write: let t1 = f1 () and t2 = f2 () ... and tn = fn () in Lwt.bind t1 (fun x1 -> Lwt.bind t2 (fun x2 -> ... Lwt.bind tn (fun xn -> return (x1, x2, ..., xn)) ...)) and this will let [t1], ..., [tn] run concurrently. With the IO monad this is just exactly the same as: let x1 = f1 () in let x2 = f2 () in ... let xn = fn () in (x1, x2, ..., xn) in a non-monadic world. There is no concurrency at all.
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-09/msg00147.htmlJonathan Protzenko announced:
I created an installer for Windows. I'd be happy if you could try it out, give me feedback, and tell me if it works for you. Download it there: http://yquem.inria.fr/~protzenk/caml-installer.html. What does the installer do? The installer is built using mingw/msys (*not* cygwin), 32bit flavor. The installer : - installs a full ocaml distribution, - sets up the path, env variables, ld.conf, etc. - downloads the right activetcl installer and launches its setup if the user doesn't have the right version of activetcl installed already, - unless the user opts-out, the installer will download emacs, install the caml-mode files, associate .ml and .mli files with emacs in the windows explorer, and write the right .el files so that the caml-mode is operational without requiring any extra configuration, - the installer will also add start menu entries and register uninstall information for the control panel "add/remove programs" thingy. Basically, once the installer is done, you can fire up an emacs and do M-x run-caml, and it works. Because I'm not bundling any as.exe, users will need extra steps to enjoy native compilation. The recommended procedure (also described at the link above) is to install mingw/msys to get a working unix-like environment, and export the right FLEXLINKFLAGS. Because I'm bundling flexlink in the installer, this is the only manual action that's required. Target audience My main target is students / non-geeks who just want an emacs to play with, and possibly a little bit extra environment to try out compilation. I don't intend on investing a lot of time / energy into this. My goal is not to provide anything like a full ocaml distribution (I've been told godi works on windows), more like a quick and easy way to get setup. I would like you to implement feature X If you have any feature requests, please submit a patch. The project lives on GitHub https://github.com/protz/ocaml-installer so please do send pull requests if you feel so inclined.
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-09/msg00151.htmlStéphane Legrand announced:
This is an annoucement for the first release of the OCMySQLProtocol (OCMP) project . OCMP is a native (no link with the MySQL C library) implementation of the MySQL client protocol. Requirements: - Bitstring. - Cryptokit. - and optional oUnit. Home page: https://forge.ocamlcore.org/projects/ocmysqlprotocol/ Usage example: http://forge.ocamlcore.org/scm/loggerhead/ocmysqlprotocol/main/annotate/head:/examples/client.ml Licence: GPL v2 (same as MySQL open-source version). Suggestions, comments and bug reports are welcome.
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-09/msg00154.htmlJeremy Fix announced in French:
En m'inspirant du papier de Hughes (1990): "Why functional programming matters", j'ai écrit une page sous la forme d'un sujet de TP pour coder l'algorithme minimax et alpha-beta pour résoudre le jeu de Morpion en voulant illustrer l'évaluation paresseuse et en se passant le plus possible des mots clefs impératifs (notemment les boucles) et sans utiliser les mots clefs d'évaluation paresseuse de Caml (Lazy.force, ..) Ca se trouve ici : http://jeremy.fix.free.fr/spip.php?article32 La solution se trouve tout en bas de la page. Toutes les critiques sont les bienvenues.
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-09/msg00158.htmlYaron Minsky asked:
For some reason, 1st-class modules have more restrictive "with" syntax, which turns out to be a practical problem. The main constraint is that with constraints do not seem to be able to refer to sub-modules. Consider the following code snippet: > module type Foo = sig type t end > module type Bar = sig module Foo : Foo end > > (* compiles *) > let g (type a) (m : (module Foo with type t = a)) = () > > (* fails to compile with a syntax error *) > let f (type a) (m : (module Bar with type Foo.t = a)) = () Of course, ordinary modules have no such constraint. Any thoughts as to what is going on here, and whether it can be fixed? This has really restricted designs I've been using, forcing me to flatten out structures that are more naturally nested.Alain Frisch then replied:
The important point is that package types (the ... in a type expression (module ...) or in an expression (module M : ...)) are not module types. Syntactically, they are indeed a subset of module types, but it is a strict subset, and they obey different rules than module types. Package types live at the boundary between types and module types. In a packing expression (module M : ...), the package type must produce a well-typed module type. This is why you cannot write (module M : S with type t = 'a), because "S with type t = 'a" is not a proper module type. But (module S with type t = 'a) is a correct type. Package types must also support all operations on types, including equality, unification, etc. For instance, unifying (module S1 with type t = 'a) and (module S2 with type t = 'b) is defined as checking than S1 and S2 are equivalent paths and unifying 'a and 'b. The fact that a package type can also be seen as a module type is nowhere used in this definition. (Of course, one must be careful when defining equality of package types that it does not allow to cast a module from one module type to an incompatible one.) There is some flexibility in both the definition of admissible package types and the definition of equality between package types. For instance, I don't see any problem or difficulty in your proposal of allowing constraints on types nested in sub-modules (but this should be checked carefully). Feel free to open a feature request for this! Similarly, one could allow "with type t :=" constraints in addition to "with type t =". Is there a need for that? One could also relax equality of package types (module S1 with ...) and (module S2 with ...) by checking that S1 and S2 expand to structurally equivalent module types (with the exact same ordering between value components!).
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-09/msg00168.htmlContinuing the thread from last week, Gerd Stolpmann and Richard Jones discussed:
> > Gerd, have you tried to interoperate with any other language? > > Well, this was developed for Mylife in a project where the sender was > written in Python. (I don't have access to this code anymore, though, > since I left Mylife.) > > > I tried examples/t_sender.ml along with the following Python receiver > > (all on the same RabbitMQ instance), but the Python code didn't appear > > to see any messages at all. I'm quite probably doing something stupid. > > What's missing here is that you need to bind the queue to an exchange. > Remember that t_sender only sends the message to the exchange amq.direct > with a routing key of test_xy_routing_key. It does not send the message > to test_xy directly (which is not possible). Without binding, the > exchange just drops unroutable messages. > > Don't know exactly how to bind in Python, but watch out for a method > queue_bind. Thanks, that works. For future reference, below is the full working receiver. Rich. ---------------------------------------------------------------------- #!/usr/bin/python import pika connection = pika.BlockingConnection(pika.ConnectionParameters( 'localhost')) channel = connection.channel() channel.queue_declare(queue='test_xy') channel.queue_bind(exchange='amq.direct', queue='test_xy', routing_key='test_xy_routing_key') def callback(ch, method, properties, body): print " [x] Received %r" % (body,) channel.basic_consume(callback, queue='test_xy', no_ack=True) print ' [*] Waiting for messages. To exit press CTRL+C' channel.start_consuming() ----------------------------------------------------------------------
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/. Logistic Regression in OCaml: https://forge.ocamlcore.org/forum/forum.php?forum_id=806 Higher Order Fun: http://alaska-kamtchatka.blogspot.com/2011/09/higher-order-fun.html New logo and new Website for the Ocsigen project: http://ocsigen.org/ iOS is anti-UNIX and anti-programmer.: http://blog.dbpatterson.com/post/10244529137 PG'OCaml: https://forge.ocamlcore.org/projects/pgocaml/ Redundant open module warning for OCaml: http://camlspotter.blogspot.com/2011/09/redundant-open-module-warning-for-ocaml.html Coming to ICFP/CUFP? Propose a BOF!: http://ocaml.janestcapital.com/?q=node/97
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.