Here is the latest Caml Weekly News, for the week of February 09 to 16, 2010.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/0d579e64dd00daff#Deep in this thread, Guillaume Yziquel asked and Alain Frisch replied:
> Is it possible to have polymorphic recursion with vanilla 'let rec' > invocations? This is something that Jacques recently merged in the current development branch. The code below should work with OCaml 3.12. let length v = let rec f : 'a. int -> 'a vec -> int = fun n l -> match l with Nil -> n | Zero ps -> f (2 * n) ps | One (_, ps) -> f (1 + 2 * n) ps in f 0 v
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/c3f20fe95eca55ac#Jun Furuse announced:
I have updated OCamlSpotter, a compiler enhancement for source code browsing, to version 1.1rc2, which is aimed for OCaml 3.11.2 and some enhancements since its first release. OCamlSpotter is a tool which finds definition places of various names (identifiers, type names, modules, etc) in OCaml programs automatically for you. The original OCaml's -annot option provides the same sort of functionality but OCamlSpotter provides much more powerful browsing: it can find definitions hidden in the deep nested module aliases and functor applications. - The -annot option of ocamlc and ocamlopt is extended and creates <module>.spot files (<module>.spit for .mli), which record the location information of the names defined and used in the module. - A small application ocamlspot provides automatic where-about spotting of the definition of the name you are interested in, using <module>.spot files created by the patched compilers. - ocamlspot.el provides interactive ocaml-spotting of definition locations in emacs. - Interfaces for other editors such as vi could be built easily, if you want. This release of OCamlSpotter is quite near to 1.1, but still in a RC state. It will become the real 1.1 after 1 or 2 weeks with minimum bug fixes. Further information and download is available at: http://jun.furuse.info/hacks/ocamlspotter
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/c4c9d58c91f86fee#Andrew Webb asked and Jeff Scofield replied:
> I have a few questions relating to using Ocaml with objective-c for > anyone who programs on a Mac. We've been working with OCaml/ObjC/Cocoa on the iPhone for a while. We also have a small subset working on the Mac and have built Mac apps with it. > I am aware that there aren't any real bindings between ocaml and > objective-c/cocoa, so I am investigating rolling my own. This is what we did. There was some work on an OCaml/Cocoa bridge, but it doesn't appear to be finished, and doesn't look like an active project. The home page is here: http://code.google.com/p/objective-c-caml-bridge > 1) Does anyone have experience in interfacing ocaml and objc? Is it > difficult? The things that make it easier than it could be are: (a) There is good documentation on interfacing OCaml and C, and ObjC is a clean superset of C. So the language tools all work together quite well. (b) The OO subsystem of OCaml is a pretty good match for the Cocoa design. With some work, you can use OCaml objects to represent Cocoa objects, and vice versa. The hard parts are: (a) Cocoa is a very large system, too large for a small number of people to build an interface by hand. A mechanical interface generator would be best, but is also a big project. (b) There's a mismatch between the ObjC reference counting and OCaml GC. For our work, we just add bits to our interface as we need them. Memory management issues are tricky but only need to be solved once in the lowest layer. We don't have any experience with the ObjC GC; this might make things a little trickier. One thing to note is that we like OCaml because it's very flexible and expressive. If you mechanically translate all Cocoa objects and structs into their obvious OCaml corollaries, you lose a lot of the advantage of using OCaml. For example, we map Cocoa NSPoint values into OCaml 2-tuples, not into OCaml records. And we often use OCaml lists (with the correct base type) to represent NSArray objects. Because of this, we don't think a direct mechanical translation of Cocoa into OCaml is going to work. But a mechanical translation with sufficient overrides probably would. > 2) Does anyone have a small example project that does mix these two > languages? I have looked at unison, but it is too big for me to get my > head around. I am thinking more on the scale of the ubiquitous > Currency Converter... I don't know of anything. > 3) Does anyone who is mixing these languages use Xcode to do so? If > so, what steps do you need to go through to set that up? To be honest, we don't currently use Xcode in any non-trivial way. We just use its built-in knowledge about packaging up applications. There was a project to integrate OCaml into Xcode, but again it doesn't look like an active project. The home page is here: http://maxao.free.fr/xcode-ocaml-pluginJohn Whitington also replied:
I've just released a product written in this way: http://www.coherentpdf.com/proview.html I just have a normal makefile which builds a .a library from the ocaml code and its C wrapper as per the instructions in the ocaml manual. The xcode project then uses the .a and the .h of the wrapper and a few extra compilation and linking flags. Doubtless with a little bit more effort, Xcode could be made to call the ocaml makefile. Here's the OCaml makefile: mklib: ocamlc cpdf.mli; ocamlopt -c -I . unix.cmxa str.cmxa bigarray.cmxa cgutil.cmxa camlpdf.cmxa cpdf.ml; ocamlc cpdflib.mli; ocamlopt -c -I . unix.cmxa str.cmxa bigarray.cmxa cgutil.cmxa camlpdf.cmxa cpdf.cmx cpdflib.ml; ocamlc cpdflibc.mli; ocamlopt -c -I . unix.cmxa str.cmxa bigarray.cmxa cgutil.cmxa camlpdf.cmxa cpdf.cmx cpdflib.cmx cpdflibc.ml; ocamlc cpdflibwrapper.c; ocamlopt -output-obj -o cpdflibc.o unix.cmxa str.cmxa bigarray.cmxa cgutil.cmxa camlpdf.cmxa cpdf.cmx cpdflib.cmx cpdflibc.cmx; cp /usr/local/lib/ocaml/libasmrun.a cpdflib.a; ar r cpdflib.a cpdflibc.o cpdflibwrapper.o test: zlibstubs.o cpdflib.a cc -m32 -c cpdflibc-test.c -o cpdflibc-test.o; \ cc -m32 -L'/usr/local/lib/ocaml' -lunix -lbigarray -lstr -lz -o test cpdflibc-test.o zlibstubs.o cpdflib.a (The 'test' target shows you the kind of compiler and linker flags you'd need to put into XCode). Basically, once you've got the usual ocaml/c interface done, the Xcode part is no problem.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/ad37fd7b2313cd2a#Romain Beauxis announced:
Thanks to the great work from Richard Jones on building a OCaml cross-compiler for windows, we now have a similar package in Debian ! The package is called mingw32-ocaml and has just been accepted yesterday.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/620dbd54f0d356f5#Guillaume Yziquel announced:
This post is to announce the 0.2 release of OCaml-R. OCaml-R is a binding embedding the R interpreter into Objective Caml code. Home page: http://home.gna.org/ocaml-r/ Download page: http://download.gna.org/ocaml-r/ Deb packages: http://yziquel.homelinux.org/debian/pool/main/o/ocaml-r/ Tutorial: http://home.gna.org/ocaml-r/gettingstarted.en.html OCamlDoc API: http://yziquel.homelinux.org/topos/api/ocaml-r/index.html http://home.gna.org/ocaml-r/refdoc/index.html The goal of OCaml-R is to provide adequate integration of the R interpreter into Objective Caml, and a framework suitable to bind R library into OCaml code. Version 0.2 is a near-complete rewrite of the 0.1 version by Maxence Guesdon, with an incompatible API. Main features are: - Safe handling of R default environment variables at compile time, following what is done in littler. - R Signal handlers do not conflict with OCaml code. - Integration with findlib, enabling the #require "R.interpreter" to initialise statically the R interpreter. Compiling with 'ocamlfind ocamlopt -package R.interpreter' also initialises the R interpreter at compile-time, so to speak. - Some (most?) functionalities of the R standalone library are wrapped. - Low-level binding, in the sense that you construct low-level R calls to execute them. You can also parse R code to execute it, if you wish. - R exceptions are chained back to Objective Caml. - R's garbage collector is chained with OCaml's garbage collector. This is done rather inefficiently for the moment (freeing n R values in O(n^2) time complexity), and we expect to bring this down to O(n) with a thin garbage collecting layer in the future. - We provide a double typing scheme, with some subtyping features. A first typing mimics the dynamic typing of the R language, while a second typing, for the end-user, aims at providing a static typing of R values and functions. (This can be bettered). - S3 classes are supported (static typing is however still unsatisfying). S4 classes are not yet supported. Help welcome. - Some basic R datatypes, such as dataframes, are wrapped, and a framework to wrap the standard library has been put in place. - Basic data structures can be converted back and forth between OCaml and the R interpreter. - Ability to inspect (read-only) the inner structure of R values, which is quite convenient: you get to know rather quickly what a given piece of R code returns, which you need to know to type R code statically in order to bind it to OCaml. - Not thread-safe at all. At least, not more than R is... Lwt-style multithreading of R code could be possible, modulo some simple and deep (i.e. below R API) changes in the R evaluation functions. POSIX threading a single R thread with multiple OCaml threads is not yet possible, but is within reach. - Doesn't interact well the R "Defaults" package. While most of the code sticks or could stick to the R API, or at least to the public part of the R headers, there are some functionalities which are outright out of the scope of the R API. Some of these functionalities are for convenience only (i.e. inspecting internals of R values), while others are crucial to the binding (chaining R exceptions to OCaml). Hopefully, this lays down a foundation on which one could import R functionalities, libraries and packages to OCaml.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/888b1d3253f5dabb#Sylvain Le Gall announced:
This is a copy and paste version of: https://forge.ocamlcore.org/forum/forum.php?forum_id=532 For the third time, I am proud to invite all OCaml enthusiasts to join us at OCaml Meeting 2010 in Paris. This year event takes place in Paris on Friday 16th April 2010. Subscription is opened and will be closed on Friday 2nd April 2010. Presentations include: * Enforcing Type-Safe Linking using Inter-Package Relationships for * OCaml Debian packages * The Ocamlviz visualization toolkit * Cluster computing in Ocaml * Ocaml in a web startup * React, functional reactive programming for OCaml * OASIS, a Cabal like system for OCaml * OPA, same web, but with types and lambda As last year, participants are invited to give a talk on what they are doing with OCaml. You can submit a description of your talk on the wiki or contact me. The meeting is sponsored by INRIA, the Caml Consortium and OCamlCore. Inscription is free but the number of participants is limited. Further information and inscriptions: http://wiki.cocan.org/events/europe/ocamlmeetingparis2010 The day after OCaml Meeting, Mehdi Dogguy from PPS helps me to organize an informal day where OCaml teams can meet to work. We will have 2 classrooms, each can host 45 persons. There will be an internet access and a blackboard in each room. Inscription is free. Further information and inscriptions: http://wiki.cocan.org/events/europe/ocamlhackingday2010 Volunteers willing to help before/during these events can contact me directly. We are particularly looking for a video team. You can also forward this invitation to any groups that can be interested in (Haskell user group, CUFP mailing list...) For people who need further information, you can contact me (see wiki.cocan.org for contact details).
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/888b1d3253f5dabb/319e3bbb1061007a#319e3bbb1061007aJohn Whitington announced:
Get the demo here: http://www.coherentpdf.com/proview.html The back-end is all code shared with the open-source CamlPDF and our other commercial products. We wrote a C interface, and then compiled it up with objective C for the interface. There will be a new release of CamlPDF in a few weeks, with some new functionality and a new introductory manual, making it easier for people to get into its somewhat complicated API. Thanks to the list for your continuing answers to my questions.
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/. A Staggering Sequence: http://alaska-kamtchatka.blogspot.com/2010/01/staggering-sequence.html OCaml Meeting 2010 second call: http://forge.ocamlcore.org/forum/forum.php?forum_id=532 Heap Up (the Bernstein Sums): http://alaska-kamtchatka.blogspot.com/2010/02/heap-up-bernstein-sums.html OCaml-R 0.2: http://caml.inria.fr/cgi-bin/hump.cgi?contrib=634 OCaml cross compiler for win32 in Debian !: http://blog.rastageeks.org/spip.php?article56 PDF Editor for Mac OS X: http://coherentpdf.com/blog/?p=40
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.