Hello
Here is the latest Caml Weekly News, for the week of August 24 to 31, 2010.
Welcome to the back-to-school mega edition.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/5b170ac0b269ba09#
Christophe TROESTLER said:
If you haven't yet read it, this paper “The Promises of Functional
Programming”, from Computing in Science & Engineering, shows the
growing interest for functional programming in scientific circles
(OCaml is even mentioned!).
http://www.computer.org/portal/web/computingnow/0609/whatsnew/cise
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/6d259477f2ddef35#
Yoann Padioleau asked and Philippe Veber replied:
> Is there a way to draw text on GlGtk.area ? with a specific font ?
> I've seen mentions of FTGL but there is no binding for it in lablgl
> apparently :(
I use the part of glMLite dedicated to FTGL
http://www.linux-nantes.org/~fmonnier/ocaml/GL/
http://www.linux-nantes.org/~fmonnier/OCaml/GL/doc/Ftgl.html
The binding is close to the library (and thus inherits some of its defects)
but has been working very well up to now.
Florent Monnier added:
the FTGL bindings are provided in the glMLite tarball in order to ease
distribution, but it is really agnostic from any opengl bindings, it even has
its own Makefile (Makefile.ftgl) and you can check that if you build it
nothing else will be build, and you can install it alone, so you can right use
it with LablGL.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/f66fe843864fc16e#
Jun Furuse announced:
I have updated OCamlSpotter, a compiler enhancement for source code
browsing, to version 3.12.0.0.0, which supports new syntax constructs
introduced in OCaml 3.12.0+rc1. This is a very quick porting version
for people who are already using OCamlSpotter with OCaml 3.11.2.
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.
The source code is available from Mercurial repo at ocamlforge:
Further information and download is available at:
http://hg.ocamlcore.org/cgi-bin/hgwebdir.cgi/ocamlspotter/ocamlspotter/
Documents are available currently at:
http://jun.furuse.info/hacks/ocamlspotter
which will be moved to ocamlforge soon.
Yoann Padioleau asked and Jun Furuse replied:
> Really ? What is the difference between -annot and -dtypes. To me
> -dtypes only help to print type information under the cursor (With C-c C-t).
> It does not help to find the definition of a name (like otags).
No difference. -dtype was superseded by -annot while ago. OCamlSpotter
extends these options to produce extra files for code browsing.
>> but OCamlSpotter provides much more
>> powerful browsing: it can find definitions hidden in the deep nested
>> module aliases and functor applications.
>
> This looks really useful. Any chance of this being integrated in the official
> OCaml distribution ? I don't feel comfortable overwriting my current
> ocaml binaries. Also how does it interact with previously compiled object files ?
> I am using godi so once I have overwritten the ocaml binaries from godi, do
> I have to reinstall all the libraries ?
The patch does not touch any part of compilation, or at least I was
careful to keep the compilation part untouched. This means patched
compiler and the orignal should produce the same object codes. It
should be safe linking of objects from the original and the patched
together, as far as you use the same compiler versions. Of course,
there are no spot/spit files for library modules compiled by the
original compiler and you cannot browse them.
If you want to be very careful, use the patched compiler just for
spot/spit file creation and use the object files from the original
compiler. In this case you need to tweak your build scripts (Makefile,
OMakefile, ocamlbuild or whatever) somehow. Probably I can add
-annotonly option for the next version of OCamlSpotter to make it
easier.
I am not sure about the possibility of official integration of the
patch. Caml-dev team is generally conservative for a good reason: they
are responsible for keeping ocaml maintenable by themselves.
OCamlSpotter was made based on some non-trivial (probably wrong)
design choices. Maybe some people find OCamlWizard
(http://ocamlwizard.lri.fr/) is better. Or others like pretty heavy
weight solutions like Scion server for Haskell.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/3ea1310f49a48972#
Damien Doligez announced:
We have the pleasure of announcing the release of OCaml version 3.12.0.
This version brings many new features, see the list of changes below.
It is available here: http://caml.inria.fr/download.en.html
This is released as source for the time being, but the binary
versions should be available soon.
This release of OCaml is dedicated to the memory of Robin Milner.
-- the OCaml team.
=========================================================================
Objective Caml 3.12.0:
----------------------
(Changes that can break existing programs are marked with a "*" )
Language features:
- Shorthand notation for records: in expressions and patterns,
{ lbl } stands for { lbl = lbl } and { M.lbl } for { M.lbl = lbl }
- Record patterns of the form { lbl = pat; _ } to mark that not all
labels are listed, purposefully. (See new warning below.)
- Explicit naming of a generic type; in an expression
"fun ... (type t) ... -> e", the type t is considered abstract in its
scope (the arguments that follow it and the body of the function),
and then replaced by a fresh type variable. In particular, the type
t can be used in contexts where a type variable is not allowed
(e.g. for defining an exception in a local module).
- Explicit polymorphic types and polymorphic recursion. In let
definitions, one can write an explicit polymorphic type just
immediately the function name; the polymorphism will be enforced,
and recursive calls may use the polymorphism.
The syntax is the same as for polymorphic methods:
"let [rec] <ident> : 'a1 ... 'an. <typexp> = ..."
- First-class packages modules.
New kind of type expression, for packaged modules: (module PT).
New kind of expression, to pack a module as a first-class value:
(module MODEXPR : PT).
New kind of module expression, to unpack a first-class value as a module:
(val EXPR : PT).
PT is a package type of the form "S" or
"S with type t1 = ... and ... and type tn = ..." (S refers to a module type).
- Local opening of modules in a subexpression.
Syntax: "let open M in e", or "M.(e)"
- In class definitions, method and instance variable override can now
be made explicit, by writing "method!", "val!" or "inherit!" in place of
"method", "val" and "inherit". It is an error to override an
undefined member (or to use overriding inheritance when nothing get
overridden). Additionally, these constructs disactivate respectively
warnings 7 (method override, code 'M') and 13 (instance variable
override, code 'V'). Note that, by default, warning 7 is inactive
and warning 13 is active.
- "Destructive" substitution in signatures.
By writing "<signature> with type t := <typeconstr>" and
"<signature> with module M := <module-path>" one replaces "t" and "M"
inside the signature, removing their respective fields. Among other
uses, this allows to merge two signatures containing identically
named fields.
* While fixing PR#4824, also corrected a gaping hole in the type checker,
which allowed instantiating separately object parameters and instance
variables in an interface. This hole was here since the beginning of
ocaml, and as a result many programs using object inheritance in a non
trivial way will need to be corrected. You can look at lablgtk2 for an
example.
Compilers and toplevel:
- Warnings are now numbered and can be switched on and off individually.
The old system with letters referring to sets of warnings is still
supported.
- New warnings:
+ 9 (code 'R') to signal record patterns without "; _" where
some labels of the record type are not listed in the pattern.
+ 28 when giving a wildcard argument to a constant constructor in
a pattern-matching.
+ 29 when an end-of-line appears unescaped in a string constant.
+ 30 when the same constructor or record field is defined twice in
mutually-recursive type definitions.
* The semantics of warning 7 (code 'M', method override) have changed
(it now detects all overrides, not just repeated definitions inside
the same class body), and it is now inactive by default.
- Better error report in case of unbound qualified identifier: if the module
is unbound this error is reported in the first place.
- Added option '-strict-sequence' to force left hand part of sequence to have
type unit.
- Added option '-no-app-funct' to turn applicative functors off.
This option can help working around mysterious type incompatibilities
caused by the incomplete comparison of applicative paths F(X).t.
Native-code compiler:
- AMD64: shorter and slightly more efficient code generated for
float comparisons.
Standard library:
- Format: new function ikfprintf analoguous to ifprintf with a continuation
argument.
* PR#4210, #4245: stricter range checking in string->integer conversion
functions (int_of_string, Int32.of_string, Int64.of_string,
Nativeint.of_string). The decimal string corresponding to
max_int + 1 is no longer accepted.
- Scanf: to prevent confusion when mixing Scanf scanning functions and direct
low level input, value Scanf.stdin has been added.
* Random: changed the algorithm to produce better randomness. Now passes the
DieHard tests.
- Map: implement functions from Set that make sense for Map.
Other libraries:
* Str: letters that constitute a word now include digits 0-9 and
underscore _. This changes the interpretation of '\b' (word boundary)
in regexps, but is more consistent with other regexp libraries. (PR#4874).
Ocamlbuild:
- Add support for native dynlink.
New tool:
- ocamlobjinfo: displays various information, esp. dependencies, for
compiled OCaml files (.cmi, .cmo, .cma, .cmx, .cmxa, .cmxs, and bytecode
executables). Extends and makes more official the old objinfo tool
that was installed by some OCaml packages.
All tools:
- PR#4857: add a -vnum option to display the version number and nothing else
Bug Fixes:
- PR#4012: Map.map and Map.mapi do not conform to specification
- PR#4478: better error messages for type definition mismatches
- PR#4683: labltk script uses fixed path on windows
- PR#4742: finalisation function raising an exception blocks other finalisations
- PR#4775: compiler crash on crazy types (temporary fix)
- PR#4824: narrowing the type of class parameters with a module specification
- PR#4862: relaxed value restriction and records
- PR#4884: optional arguments do not work when Some is redefined
- PR#4964: parenthesized names for infix functions in annot files
- PR#4970: better error message for instance variables
- PR#4975: spelling mistakes
- PR#4988: contravariance lost with ocamlc -i
- PR#5004: problem in Buffer.add_channel with very large lengths.
- PR#5008: on AMD64/MSVC port, rare float corruption during GC.
- PR#5018: wrong exception raised by Dynlink.loadfile.
- PR#5057: fatal typing error with local module + functor + polymorphic variant
- Wrong type for Obj.add_offset.
- Small problem with the representation of Int32, Int64, and Nativeint constants.
- Use RTLD_LOCAL for native dynlink in private mode.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/18e33beb939db08f#
Mathieu Baudet announced:
I thought the Caml community might be interested by this new job offer at
MLstate.
****
Job offer: system administrator and system expert with good skills in
functional programming and Unix / Windows security.
Based in Paris, MLstate is a startup specialized in functional programming
languages and web applications. Our R&D team, composed of 20+ passionate
computer scientists, doctors or engineers, is currently building and
maintaining the compiler of OPA, a new functional language dedicated to web
applications and designed with strong objectives of security, reliability and
scalability in mind.
As MLstate is growing fast, we are now considering the need for a system
administrator to take daily responsibility of our IT infrastructure (Linux /
MAC / Windows intranet, routers, firewalls, distant or local servers, etc).
Our business implies to be able to deploy web portals and web applications in
a fast and secure way in a variety of environments. For that reason, our
system administrator will also work as a system expert and contribute to our
products, mostly developped in OPA and Ocaml, so as to make them benefit from
his skills in Unix / Windows administration and security.
If you are a high-level computer scientist, self-organized, resourceful, with
strong skills in the administration of software and hardware systems, good
skills in functional programming (experience of Ocaml or another modern
strongly-typed functional programming language), and good skills in Unix and
Windows security, please feel free to contact us by email at
careers@mlstate.com. Ideal candidates, with some industry experience, will
also have a background in application servers, distributed systems and
databases, and should be able to live and work in a multilingual environment.
****
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/46308810d78c3956#
Matthew Fluet announced:
The 2010 ACM SIGPLAN Workshop on ML
http://www.cs.rit.edu/~mtf/ml2010
Baltimore, Maryland, United States
Sunday, September 26, 2010
co-located with ICFP 2010
Call for Participation
ML is a family of programming languages that includes dialects known
as Standard ML, Objective Caml, and F#. The development of these
languages has inspired a large amount of computer science research,
both practical and theoretical. This workshop aims to provide a forum
to encourage discussion and research on ML and related technology
(higher-order, typed, or strict languages).
The format of the 2010 Workshop on ML will be different than that of
recent years, returning to a more informal model: a workshop with
presentations selected from submitted abstracts but without published
proceedings. We hope that this format will encourage the presentation
of more exciting (if unpolished) research and deliver a more lively
workshop atmosphere.
Invited Speaker
~~~~~~~~~~~~~~
Luke Hoban (Microsoft) -- Bringing F# to Visual Studio 2010
Program
~~~~~~
9:00 Invited Talk
Visual F#: Bringing F# to Visual Studio 2010
Luke Hoban (Microsoft Research)
10:00 Break
10:30 Probabilistic programming using first-class stores and
first-class continuations
Oleg Kiselyov (FNMOC); Chung-chieh Shan (Rutgers University)
10:55 Effective progamming in ML
Daan Leijen (Microsoft Research); Ross Tate (University of
California, San Diego)
11:20 Discussion
11:30 First-class modules and composable signatures in Objective
Caml 3.12
Alain Frisch (LexiFi); Jacques Garrigue (Nagoya University
Graduate School of Mathematics)
11:55 First-class modules: hidden power and tantalizing promises
Jeremy Yallop (Applicative Ltd); Oleg Kiselyov (FNMOC)
12:20 Discussion
12:30 Lunch break
14:00 Deriving a Typed Implementation for Coroutines in ML
Konrad Anton (Universitat Freiburg); Peter Thiemann (Universitat
Freiburg)
14:25 The Design Rationale for Multi-MLton
Suresh Jagannathan (Purdue University); Armand Navabi (Purdue
University); KC Sivaramakrishnan (Purdue University);
Lukasz Ziarek (Purdue University)
14:50 Discussion
15:00 Mirage: high-performance ML kernels in the cloud
Anil Madhavapeddy (University of Cambridge); Thomas Gazagnaire
(INRIA Sophia Antipolis)
15:25 Hosting a Standard ML compiler in a Web Browser: Status Report
Martin Elsman
15:50 Discussion
16:00 Break
16:30 A simple and effective method for assigning blame for type errors
David MacQueen (University of Chicago)
16:55 The MetaOCaml files: Status report and research proposal
Oleg Kiselyov (FNMOC); Chung-chieh Shan (Rutgers University)
17:20 Discussion
17:30 Closing
Registration and Local Arrangements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* https://regmaster3.com/2010conf/ICFP10/register.php
* http://www.icfpconference.org/icfp2010/local.html
Program Chair
~~~~~~~~~~~~
Matthew Fluet Rochester Institute of Technology
Program Committee
~~~~~~~~~~~~~~~~
Kathleen Fisher AT&T Labs Research
Adam Granicz IntelliFactory
Daan Leijen Microsoft Research
Johan Nordlander Lulea University of Technology
Sungwoo Park Pohang University of Science and Technology
Daniel Spoonhower Google
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/0b14327ac8bab37c#
Oleg announced:
The library delimcc directly implementing delimited continuations on
OCaml now supports native code (ocamlopt) on selected platforms.
http://okmij.org/ftp/continuations/caml-shift.tar.gz
The library delimcc implements shift/reset, prompt/control, shift0,
control0 delimited continuation operators with multiple, arbitrarily
typed prompts. The delimcc implementation is direct: it copies only
the relevant fragment of the OCaml stack. The implementation is fully
integrated with OCaml exceptions: exception handlers may be captured
in delimited continuations (and re-instated when the captured
continuation is installed); exceptions remove the prompts along the
way. The implementation has no typing problems, no bizarre 'a cont
types, and no use for magic.
The library delimcc does *no* patching of the OCaml system and is a
regular (static or dynamically-loaded) library. The library is
therefore _perfectly_ compatible with any existing OCaml code, source
or binary.
The native- and byte-code versions of the library implement the
identical interface, described in delimcc.mli. Furthermore, the OCaml
code for the two versions is identical. Only the C code files,
implementing scAPI, differ for native-code.
Using the native-code version is identical to the byte-code version of
delimcc. No source code has to be changed; it has to be compiled using
ocamlopt rather than ocamlc.
This is the first release of the library, for OCaml 3.11. It has been
tested on i386 (x86_32) platform, on FreeBSD and Linux. The library
could perhaps be used on other platforms (on which stack grows
downwards); x86_32 is the only platform available to me. At any write,
the library contains no custom-written assembly code (although I
couldn't avoid reading a lot of assembly code).
This is the first release of the native-code version, hence stressing
correctness at the expense of performance. A notable performance drain
is emulating data types with a custom GC scanning
function. Custom-scanned data types are possible without any changes
to OCaml, thanks to the provided GC hooks. Alas, the emulation doesn't
seem to be efficient. A co-operation from the OCaml system would be
greatly appreciated. I have a hunch that custom-scan data types could
be useful for many other applications, for heap-allocating structures
with OCaml values intermixed with unboxed data.
It should be noted that the very operation of capturing and
reinstalling a delimited continuations will always be faster in
byte-code than in the native code. First of all, the byte-code
delimited continuation is smaller. Second, it is a uniform a sequence
of values or code pointers. In contrast, the corresponding captured
native-code delimited continuation -- the portion of the C stack -- is
not only bigger, but also contains unboxed values. We have to use
frame tables to figure out which stack slots contain live heap
pointers. Saving native-code delimited continuation is inherently more
complex. In fact, all the complexity of the native-code delimcc was
tidying the stack to please GC.
One should keep in mind the fundamental limitation of native-code
delimited continuations -- the limitation that also holds for Scheme
and other systems with delimited control. The limitation concerns
capturing continuations in the OCaml code invoked as a call-back from
C code, which was, in turn, called from OCaml. It is safe to capture a
delimited continuation in the callback _provided_ the extent of the
captured continuation is limited to the call-back. The continuation
captured in the callback may be resumed within the call-back or after
the call-back has exited. One must not capture the continuation
through the C code that invoked the call-back. In short, no C frames
may be captured in delimited continuations. The library detects C
frames in captured continuations, and throws a run-time error. Such a
behavior of delimcc is consistent with the behavior of native-code
Scheme systems.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/72e80cf4252056d3#
Nicolas Ojeda Bar asked and Daniel de Rauglaudre replied:
> 1. When I load my grammar in a suitable Ocaml toplevel, I get
> wonderful error messages for the parser, but when I am running
> my compiler stand alone, I only get an exception. Is there a
> way to recover the error messages that I get when running under
> the toplevel for my use?
When a Camlp5 grammar entry fails, it raises an exception defined in
the Camlp5 module Ploc. This exception encloses the location and the
real exception. Do:
try Grammar.Entry.parse your_entry with
Ploc (loc, exn) ->
... print the location 'loc' of the error if you want using
the module Ploc
... print the real exception 'exn' using the OCaml module Printexc
or raises it to make the OCaml runtime display it
> 2. What is the simplest way of replacing (not extending) Ocaml's
> grammar using Camlp5 ? Or equivalently, if I have a parser that
> generates Ocaml AST using q_MLast, how do I do to feed that to
> the Ocaml compiler?
If your grammar is in the file 'foo.ml', compile it with ocamlc. It
produces the file 'foo.cmo'. And to compile a file 'bar.ml' using your
grammar, do:
ocamlc -pp 'camlp5 ./foo.cmo pr_dump.cmo' bar.ml
Later on, Daniel de Rauglaudre added:
I added a (small) chapter about how to make one's syntax for OCaml
using Camlp5. This chapter will be in next version (5.16) but you
can see it there:
http://pauillac.inria.fr/~ddr/camlp5/doc/html/redef.html
For the current Camlp5 version (5.15), this part works except that
you have to compile the file "mysyntax.ml" (of that chapter) by:
ocamlc -pp "camlp5r pa_extend.cmo q_MLast.cmo" -I $(camlp5 -where) -c mysyntax.ml
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/4797e8482a96b332#
Jianzhou Zhao asked and Hugo Ferreira replied:
> I am looking for an eclipse plugin for OCaml.
> http://www.cocan.org/ocaml_and_eclipse lists three plugins. The last
> one http://www.algo-prog.info/ocaide/ seems supporting more features
> (including debugging). Does anyone have any experience with them, or
> other plugins?
>
The plug-in in http://www.algo-prog.info/ocaide/ is good.
I only have experience using ocambuild. It works well.
You also have a forum in case you have any questions.
It also supports camlp4 compilation (I use it for sexplib).
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/aeb68608e47f5b0e#
Marc Weber announced:
I'd like to notify you that I wrote some very basic omni completion for
Vim and Ocaml. It may speed up your typing a little bit.
At the moment it only knows how to complete functions found in .mli
filse and let bindings of the current file.
eg
:string->int will find int_of_string
ios will also expand to int_of_string
repo:
http://github.com/MarcWeber/vim-addon-ocaml
I highly recommend using vim-addon-manager to install the plugin because
it depends on some other vim script reepositories (see top level *info*
file)
I'm still bloody new to ocaml - So I expect that you have some ideas to
make the completion system even smarter.
If you have any trouble setting it up contact me on irc or by mail.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/d8d996ff1eb76d16#
Eray Ozkural announced:
I have just uploaded an implementation of Fiat and Shamir's zero-knowledge
network authentication protocol on ocamlforge. It was written for a grad-level
cryptology course. I thought this was more useful than my half-baked attempts
at writing a cryptanalysis library, so here you go :) Given that this protocol
has some performance advantages, I might implement a remote secure shell on
top of it (after perhaps looking at some low-level optimizations to save some
constant factors). SSH is kind of obsolete anyway. Parts of the program are
based on Xavier Leroy's wonderful cryptokit, so I thank him in earnest. I
think we should really go ahead and implement all sorts of cryptographic
protocols in ocaml and release them under GPL.
Description:
This program implements a cryptographic network authentication scheme
based on the work of Fiat-Shamir. The system is described in Section
6.8 of Network Security: Private Communication in a Public World by
Kaufman et al.
Homepage: http://forge.ocamlcore.org/projects/fiat-shamir-zkp/
License: This library and the example client/server is licensed under GNU
Affero General Public License version 3, to maximize its freedom.
Comments and contributions most welcome.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/edd8a11542cdd1a4#
Oege de Moor announced:
FACULTY POSITION IN PROGRAMMING LANGUAGES AT OXFORD
The University of Oxford is offering a tenure-track faculty position
in the area of programming languages. Full details can be found at:
http://www.comlab.ox.ac.uk/news/231-full.html
The closing date for applications is September 24.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/518c3f4a0d46f67e#
Adrien Nader announced:
I am pleased to announce a preview release of cowboy, a framework for
the generation of C bindings. It is currently used to generate
bindings for glib-based libraries.
It's not a magical binding writer however: work is still needed in
order to create bindings. But it can ease their generation, help avoid
regular expression stunts and allow writing the generator in ocaml.
It provides an access to the list of a library's functions, enums,
structs... Yohann Padioleau's yacfe[2] C/C++/Java parser actually does
most of the work. It can "parse" cpp (the preprocessor kind), giving
access to valuable human-readable information.
The code in cowboy takes yacfe's output and simplifies it: dropping
function's implementation and only keeping names and prototypes. It
also keeps comments which often (doxygen, gtk-doc...) contain
annotations to tell an 'int array' from an 'out parameter', both being
'int*' in C.
Cowboy also provides a few helper functions and a sort of templates
for META, OCamlMakefile and OASIS files.
Currently, cowboy is used to generate bindings to glib-based libraries
(webkit-gtk is almost ready, others will follow). However it is not to
be used for everything.
Stating the obvious, it is only interesting when automation is worth
it. If the library is not big enough or if its API does not follow a
set of conventions, writing bindings by hand will be easier.
In any case, do not hesitate to ask me: on the mailing-list, through
private e-mail, or on IRC (freenode network, #ocaml or #ocaml-fr
channels, which I'm always connected to).
PS: Some have seen and might remember "ocaml-gir" which did a similar
job: cowboy has a more general scope and is also easier to work with
(gobject-introspection is very complex and under-documented, and it's
... weird).
PS2: I am aware that cowboy is unevenly documented. If you start
anything, again, do not hesitate to ask me.
[1] http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=cowboy/cowboy.git
(use the "snapshot" feature to download)
[2] http://padator.org/software-yacfe.php (see doc/yacfe on how to install it!)
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/82b3678f479382d7#
Vincent Rahli and Joe Wells announced:
We are happy to announce the release of two things:
* Technical report HW-MACS-TR-0079 "A constraint system for a SML
type error slicer" which explains how our type error
slicing software works.
* The new version 0.6 of our type error slicing software for the SML
programming language.
The abstract of the technical report is:
Existing compilers for many languages have confusing type error
messages. Type error slicing (TES) helps the programmer by
isolating the part of a program contributing to a type error, but
unfortunately TES was initially done for a tiny toy language.
Extending TES to a full programming language is extremely
challenging, and for SML we needed a number of innovations and
generalisations. Some issues would be faced for any language, and
some are SML-specific but representative of the complexity of
language-specific issues likely to be faced for other languages.
We solve both kinds of issues and present a simple, general
constraint system for providing type error slices for ill-typed
programs. Our constraint system elegantly and efficiently handles
features like the intricate "open" SML feature. We show how the
simple clarity of type error slices can demystify language
features known to confuse users.
We also provide in an appendix a case study on how to use TES to
help modifying user data types, and extend the core language
presented in the main body of this report to handle more of the
implementation of our system. These extensions allow handling
local declarations, type declarations and some uses of signatures.
Regarding the software, major improvements over the previous release
include:
* The slicer is 10 to 100 times faster in many cases, and can
reasonably be used on programs containing 10 thousand lines of
code.
* We support some uses of functors (that is, we report some type
errors involving functors).
* We report more kinds of errors and the error messages have been
improved.
* We provide a source archive (that is, a .tar.gz file which you
unpack and run “./configure; make; make install” in the unpacked
directory).
Other less important improvement is:
* The slicer now quickly sends non-minimal error slices to the user
interface and then sends a minimal replacement error slice after
doing more time-consuming work.
* We partially support fixity declarations in that we parse and type
check programs using them correctly. Highlighting of infix
declarations and identifiers in error slices is not yet correct.
Even more changes are documented in the ChangeLog file.
The aim of our type error slicer is to provide useful type error
reports for pieces of code written in SML:
* It identifies all of the program points that contribute to a type
error, including the spot with the actual programming error that
caused the type error.
* It highlights these program points in the original, unchanged
source code.
* It avoids showing internal details of the operation of the type
inference machinery.
A new source archive and new Ubuntu (Debian based) and Fedora (Red-Hat
based) packages of our type error slicer can be found at this URL:
http://www.macs.hw.ac.uk/ultra/compositional-analysis/type-error-slicing/
The technical report can be found at this URL:
http://www.macs.hw.ac.uk:8080/techreps/view_record.jsp?id=0079
Known limitations:
* We have not yet built the software for other operating systems
than Linux.
* The currently supported user interfaces are via a terminal window,
GNU Emacs (or our web demo). We are currently developing a Vim
interface.
* Some type errors are not yet discovered (the user will need to
rely on their usual type checker in these cases). Notable spots
where the implementation is incomplete are equality types and
sharing constraints.
* The details of the SML basis library are incomplete (fortunately
the user can add any additional details they are using).
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/0c80bb9fe8416960#
Fabrice Le Fessant announced:
The OCamlPro initiative at INRIA aims at the creation in 2011 of a
company to help the Objective-Caml programming thrive as a major
professional technological asset. To support this initiative, the
Digiteo foundation is funding a "Collaborative Technology Transfer
Readiness Program" (OMTE), mainly through the funding of a one-year
developer at INRIA Saclay.
The task of the developer will be:
1/ to study the set of all open source softwares developed in OCaml
(programs, libraries) and identify the best items among them, in terms
of stability, quality, usefulness and which distribution licence
allows their reuse in a commercial environment;
2/ to collect these items and to gather them in a qualitative and
useful set, consistent regarding distribution licences;
3/ to compare this set with other existing programming languages'
environments (Java, Haskell, Python, etc.), and to propose which items
should be improved or which new ones should be developed;
4/ to plan a roadmap for the development of these items and start
developing them.
This task is an essential stage for the OCamlPro initiative;
candidates should master OCaml, should have a strong desire to
contribute to the professional diffusion of this excellent language,
and should be able to integrate strongly in the dynamic and ambitious
team we are creating.
According to their aspirations and profiles (professional experience
and knowledge of OCaml and its insights), candidates might be proposed
other positions within the OCamlPro initiative.
Candidates should contact Fabrice LE FESSANT
(fabrice.le_fessant@inria.fr), with a detailed CV and an application
letter.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/f79290a1cf3b165d#
William Le Ferrand announced:
Sorry for spoiling the list, but hypios is seeking for OCaml
developers to join its technical division in Paris for a 60 days
mission. It consists in developing an open innovation platform for a
famous international firm, from the 15th of september to the 15th of
november.
Familiarity with the ocsigen framework would be a plus, but ocaml
developers learn quickly don't they ;) ?
Permanent positions are also available.
We'll take at our charge all the expenses and we provide a nice
package; if you are interested please get in touch with me by mail at
william@hypios.com or by phone at +33 6 31 27 18 55.
About hypios:
hypios.com uses intelligent crowdsourcing to help organizations solve
Research & Development (R&D) problems. The 120,000 “Solvers” on its
platform, representing diverse disciplines and industries, hailing
from over 150 countries. “Seekers” can post R&D problems to the
network and select a deadline and a price for the “Solver.” hypios is
only paid when solutions are found. Our website :
http://www.hypios.com
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/60b9852b24e0e447#
Adrien Nader announced:
Following the preview release of cowboy, I am happy to announce
cowboy/glib[1] and its first output: bindings to webkit-gtk.
cowboy/glib is a generator using facilities from cowboy. The goal is not
to replace lablgtk2: it actually relies on it a lot. It was named
"glib" because it generates bindings for glib-based libraries which
follow glib-like conventions.
Last year, I released "ocaml-gir" which used gobject-introspection[2]
(GI) to generate bindings. GI is hopefully two things: a program
outputting an xml description of a glib library, but also the annotation
of these libraries in order to ease the creation of bindings. This
second part can be used by anyone.
I wasn't pleased with the gobject-introspection program (it's very
complex and not documented) but also with my own code. This new project
currently handles most of webkit-gtk: functions, signals, properties
while being cleaner.
The bindings to webkit-gtk are working fairly well and are installed
through findlib, which means they can be easily test and uninstalled.
I've generated sources for webkit-gtk 1.2.3[3] (latest stable) and
1.3.3[4] (latest non-stable).
Of course, it's also possible to generate the bindings on your own
machine (see doc/webkit_gtk).
You'll also need an additional (trivial) wrapper around g_thread_init()
which webkit-gtk requires to be called and which is currently not in
lablgtk2[5] (simply run 'make && make install').
You will find a small test named 'webkit_test.ml' in the 'misc' folder
of cowboy. Its compilation command is given in the comments.
Of course, I will continue working on this project in order to increase
the compatibility with other glib-based libraries.
[1] http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=cowboy/cowboy.git;a=summary
[2] http://live.gnome.org/GObjectIntrospection
[3] https://forge.ocamlcore.org/frs/download.php/450/lablwebkit-1.2.3.tar.gz
[4] https://forge.ocamlcore.org/frs/download.php/449/lablwebkit-1.3.3.tar.gz
[5] https://forge.ocamlcore.org/frs/download.php/448/g_thread_init.tar.gz
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/64733f18bbe823b5#
Jeffrey Barber announced:
I've been working with libevent2 and OCaml for the past couple of weeks to
build node.ocaml. It is far from done, but it is interesting enough to share.
node.ocaml as of now contains a web server and a terminal server that provides
asynchronous programming to OCaml to enable some of my research. The first
example server is a key value pair server that brings OCaml's Hashtbl to http
and terminal IO:
example code:
http://github.com/mathgladiator/node.ocaml/blob/master/test/kvp.ml
This is the first test program, and it works fairly well in a single threaded
environment. I was inspired by node.js to build an evented io system, and so I
begged the question "how does 'OCaml's FFI' compare with v8's in node.js". In
my virtual machine environment (ubuntu 10.04), I got the following results
doing 10,000 requests 50 at a time:
node.js with the "Hello World" script:
2100 requests/second
node.ocaml with kvp.ml:
5300 requests/second
This seems to me to be a very positive first benchmark considering I haven't
optimized anything yet nor have I hacked caml_copy_string yet.
The code is licensed under BSD and available
http://github.com/mathgladiator/node.ocaml .
Any thoughts/questions are appreciated; thank you for your time.
Jake Donham suggested and Jeffrey Barber replied:
> Have you considered using Lwt (http://ocsigen.org/lwt) as a layer on
> top of raw continuation-passing style? It has a lot of nice functions
> for writing asynchronous code, as well as a syntax extension to make
> it look more like direct-style code. It provides a select loop
> already, but you don't need to use it, or you could integrate
> libevent2 with Lwt's event loop.
No I haven't, thanks for the link. In looking through the docs, it seems
similiar at some level to what I am doing. I'm trying to get away from the
language of threading (In my code, I use chain and io_pumps for context
storage) since I'm thinking of node.ocaml as an event based io library. This
is probably just a marketing decision, :/, rather than a technical decision.
More context on node.ocaml:
I was recently inspired by unix, memcache, and redis and realized that all you
need as a packet format is a single line, so I'm taking that as the packet
format and am going to try to build some neat things with it for both my own
research/education.
For my research, I want to build a fault tolerant JSON data store where I can
get the performance benefits of Redis/Memcache but also have transactional
transformations over indexed sets. But not only that, I want it to be easy to
build them so it can be extended down the road. I've noticed that from using
Redis, there are a lot of design patterns emerging that would be better
migrated from the application server to a redis-like server.
For my education, I really want to do something with Paxos that's useful. I'm
not sure what, but I've yet to master it and it sounds fun. I'm tempted to
build a chubby clone for distributed locking, but who knows.
Oh, I may also cause the universe to explode since I may enable OCaml to call
JavaScript via v8... In case it does, I'm sorry now.
Gerd Stolpmann suggested:
You may also look at ocamlnet
(http://projects.camlcity.org/projects/ocamlnet.html), which provides a
stack of abstractions for event-driven programming:
- The Netsys library defines an object type for sets of file
descriptors one can poll:
http://projects.camlcity.org/projects/dl/ocamlnet-3.0test5/doc/html-main/Netsys_pollset.pollset.html
There is right now only an implementation for poll(), but
no fancy things like what libevent provides (but this is
just lack of time).
- Above that, there is the equeue library with its main
interface Unixqueue:
http://projects.camlcity.org/projects/dl/ocamlnet-3.0test5/doc/html-main/Unixqueue.html
This provides a queue of events, and a mechanism to consume
events.
- Above that, there is the engines API:
http://projects.camlcity.org/projects/dl/ocamlnet-3.0test5/doc/html-main/Uq_engines.html
This is an abstraction allowing easy composition of code. An
engine represents a suspended I/O operation to which one can
attach continuations.
There are even implementations of high-level protocols using these APIs
(most hooking in at the Unixqueue level), and this includes HTTP,
Telnet, FTP (partly), and SunRPC. Companies are using this already in
products, so this is really a mature implementation.
It is interesting that in your code the callbacks are implemented on the
C side. I think this is generally more complicated than doing the same
in Ocaml which is way more a "callback-friendly" language.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/d4ca429e7935033c#
Oleg announced:
The library delimcc implements multi-prompt delimited control operators
for byte- and native-code OCaml. The library now can be used with
OCaml 3.12.0, on x86_32 and x86_64 (aka amd64) platforms.
The byte-code part of the previous versions of delimcc could
already be used with OCaml 3.12 (although I didn't know that). Since
OCaml byte-code is portable, the byte-code delimcc should work on
any supported architecture. In this version, some adjustments have
been made to scAPI to make in more portable. It should be stressed
that there are _no_ distinct versions of the native-code delimcc, for
32- and 64-bit architectures. Rather, the same code (without any
64-bit--specific ifdefs) works on x86_32 and x86_64. Only
C code differs between byte-code and native-code versions of the
library; the OCaml code is shared, across the versions and the
architectures. The current version of delimcc probably works on other
architectures like arm, although I have no means of testing that.
The byte- and native-code versions of library has been tested on i386
Linux and FreeBSD platform and on amd64 Linux platform. The code is at
http://okmij.org/ftp/continuations/caml-shift.tar.gz
I thank Jim Pryor for help with testing.
Yoann Padioleau asked and Jake Donham replied:
> Is there any tutorial on why such features are useful ?
> Concrete examples of their use. For instance can you implement
> python generators and its yield stuff by using this library ?
Here is an example of a particular use of Delimcc to implement fibers for Lwt:
http://ambassadortothecomputers.blogspot.com/2010/08/mixing-monadic-and-direct-style-code.html
I don't know exactly how python generators work but I would imagine
that you can implement them with Delimcc.
Oleg also replied:
> Is there any tutorial on why such features are useful ?
> Concrete examples of their use.
Thank you for the question! I think you may find many examples
of delimited continuations on the following web site:
http://okmij.org/ftp/Computation/Continuations.html
Notable examples are the probabilistic programming language HANSEI,
normalization of MapReduce bodies by evaluation, and a framework to
program CGI applications in `direct style' (as if they were regular
console applications). Delimited continuations proved quite useful for
writing code generators: to perform let- or if-insertions in the
generated code, one has two choices: write the generator in a monadic
style or CPS, or use a `direct style' relying on delimited
control. Experience seems to show that direct-style generators are
more perspicuous.
> For instance can you implement python generators and its yield stuff
> by using this library ?
Yes! Here is the complete code
http://okmij.org/ftp/ML/generator.ml
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/1ca70b6fc4e8ede1#
Mathieu Baudet proposed this other job:
It looks like the Ocaml industry is doing very well and as a member of the
OCaml consortium we are delighted !
We also would like to propose a new job offer in Paris, related to Web
programming in functional languages.
MLstate is a 25+ people startup specialized in web applications and functional
programming languages. Our development team has been developing a new product
for building up high quality portals and social networks in a very fast and
easy way. We are currently seeking for a new programmer to strengthen our team
and contribute to a business extension crafted for a customer.
If you are a talented programmer with good skills in web programming and good
knowledge of OCaml (or any comparable functional language), do not hesitate to
contact us by email at careers@mlstate.com. Ideal candidates will also have
some industry experience in building web applications and a sensibility to
human-computer interaction.
The position begins with a 6-month contract starting NOW (September 1st), with
a highly motivating compensation package. A permanent position is clearly an
option if there's a fit.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/581f5d9dfc70ff9f#
malc announced:
New version of llpp is available at [1] new features include:
* Outline (aka Table of contents) mode
(including quick search and narrowing)
* Bookmarks
* Link highlighting
* Windows and Mac OS X "support"
* Some important bugs were fixed upstream in MuPDF[2]
* Added helper script which tries to fetch MuPDF, lbig2dec, openjpeg
and LablGL build them locally and then build llpp against that
llpp has so far been built and ran on:
Linux (ppc32,ppc64,x86_64,i386)
Windows XP (i386)
Windows Vista (amd64)
Mac OS X (Tiger on ppc32, (some) Leopard x86_64)
Building on Windows is not pleasant but definitely doable.
[1] http://repo.or.cz/w/llpp.git
[2] http://mupdf.com/
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/8eea939255728cd3#
Hendrik Tews announced:
I would like to announce that the first release of OTAGS RELOADED
is available at
http://askra.de/otags/
Otags reloaded generates tags tables for emacs and vi/vim.
Currently it is only available for ocaml 3.11, work for 3.12
will start after the first wave of bug reports and feature
requests.
Otags reloaded has been rewritten from scratch for camlp4 and is
thought as a replacement for the old otags, which nowadays
depends on camlp5. The new otags version has the following new
features:
- parse files without launching camlp4 subprocesses (for the
syntax extensions distributed with camlp4)
- tag files that require different syntax extensions in one run
- produce sorted vi tags tables
Otags reloaded is distributed under GPL v3.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/077c10dd188232cf#
Maxence Guesdon asked:
For those who don't know, I'm the maintainer of the Caml Hump.
For this reason, I have a look at every project announced on the caml-list
and it seems to me that there are more and more projects providing only
links to tarballs or git repositories.
I think these projects would take advantage of having at least one web page
giving all basic information: description, status, license, author(d),
download links.
Indeed, having to look for this information in a tarball of a git repos
(with gitweb) is not very convenient. Even the project page on a forge is
not the best way to get the information quickly. It's more a view for a
developer/contributor, not for a potential user.
Even if this main web page should point to the developer ressources
(repository, forge project, ...), the main access to the project should
be a web page with hand-written text, even a simple one.
Sylvain Le Gall replied:
I am working on OASIS and OASIS-DB. The latter aims to translate _oasis
file into simple web pages (including markdown translation).
Have a look at:
http://oasis.ocamlcore.org/dev/browse?ver=0.2.0~alpha1&pkg=oasis
This web page has been translated from:
http://darcs.ocamlcore.org/cgi-bin/darcsweb.cgi?r=oasis;a=headblob;f=/_oasis
(this package is pretty complex, so there is a lot a library/exec/tests
but what is translated is basically Synopsis + Description).
If you add an _oasis file to your project and upload it to
oasis.ocamlcore.org it will generate this kind of pages.
Maxence, does it fit your requirement?
(the project is still at an early stage, but the upload is working)
> Indeed, having to look for this information in a tarball of a git repos
> (with gitweb) is not very convenient. Even the project page on a forge is
> not the best way to get the information quickly. It's more a view for a
> developer/contributor, not for a potential user.
>
Every project on forge.ocamlcore.org can upload a simple webpage and it
will be displayed on http://PROJECT.forge.ocamlcore.org. Just add html
files to /home/groups/PROJECT/htdocs on ssh.ocamlcore.org, same ssh key
as git/darcs/svn login. You can use rsync, scp or unison.
Feel free to contact me if you need further utilities for your project.
Sylvain Le Gall later added:
Examples of web pages:
http://oasis.forge.ocamlcore.org/
http://ocaml-lua.forge.ocamlcore.org/
http://ounit.forge.ocamlcore.org/
http://pa-do.forge.ocamlcore.org/
http://ocamlviz.forge.ocamlcore.org/
http://cmdline-args.forge.ocamlcore.org/
http://camlbz2.forge.ocamlcore.org/
http://ocaml-autoconf.forge.ocamlcore.org/
If you lack inspiration, just copy/adapt these webpages. They are all
accessible on /home/groups/PROJECT/htdocs/.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/ddaf245414a80948#
Jake Donham announced:
I am happy to announce version 0.3 of ocamljs. Ocamljs is a system for
compiling OCaml to Javascript. It includes a Javascript back-end for
the OCaml compiler, as well as several support libraries, such as
bindings to the browser DOM. Ocamljs also works with orpc
(http://jaked.github.com/orpc) for RPC over HTTP, and froc
(http://jaked.github.com/froc) for functional reactive browser
programming.
Changes since version 0.2 include:
* support for OCaml 3.11.x and 3.12.0
* jQuery binding (contributed by Dave Benjamin)
* full support for OCaml objects (interoperable with Javascript objects)
* Lwt 2.x support
* ocamllex and ocamlyacc support
* better interoperability with Javascript
* many small fixes and improvements
Development of ocamljs has moved from Google Code to Github; see
* project page: http://github.com/jaked/ocamljs
* documentation: http://jaked.github.com/ocamljs
* downloads: http://github.com/jaked/ocamljs/downloads
I hope you find this work useful.
Mihamina Rakotomandimby asked and Sylvain Le Gall replied:
> What are the differences between:
> - OBrowser (http://www.pps.jussieu.fr/~canou/obrowser/tutorial/)
OBrowser seems to be replaced by Js_of_OCaml
> - Js_of_OCaml (http://ocsigen.org/js_of_ocaml/overview)
> - OcamlJS
Have a look at:
http://ambassadortothecomputers.blogspot.com/2010/08/ocamljs-03.html
Dario Teixeira also replied:
These three projects have one goal in common -- running Ocaml code
inside a browser -- but approach it differently:
- O'Browser implements in Javascript an interpreter of Ocaml bytecode
(the code produced by ocamlc).
- js_of_ocaml compiles Ocaml bytecode into Javascript.
- ocamljs is a new backend for the Ocaml compiler that translates
Ocaml's intermediate representation (the "lambda" representation)
into Javascript.
bluestorm added:
[nacl-ocaml], wich patches the ocaml compiler to produce native code
compatible with [Google Native Client] technology (verified native code for
sandboxed environments such as browsers) may also be relevant here.
[nacl-ocaml] http://code.google.com/p/nacl-ocaml/
[Google Native Client] http://code.google.com/p/nativeclient/
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/3864e903327ee3b2#
Jeremy Bem announced:
I'm pleased to announce Llama Light, an implementation of the core Caml
language. It features a typechecker that is small enough to read through and
grasp as a whole, thereby making it easy to modify and extend.
Llama Light is derived from Caml Light and OCaml. I'm grateful to the
developers at INRIA for allowing derivative works to be created.
The system is available for download at http://llamalabs.org/light.html. All
feedback is greatly appreciated (even if it's just to let me know that you
tried it out).
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/.
Updated DrSync to Racket:
http://feedproxy.google.com/~r/WisdomAndWonder/~3/oGb-9dpow0c/updated-drsync-to-racket
Installed tailbrights on my Connie:
http://feedproxy.google.com/~r/WisdomAndWonder/~3/1TQpA24OMHU/installed-tailbrights-on-my-connie
ExtUnix - extended Unix module:
https://forge.ocamlcore.org/projects/extunix/
New SSL certificate for ocamlcore.org:
http://forge.ocamlcore.org/forum/forum.php?forum_id=660
ocamljs 0.3:
http://ambassadortothecomputers.blogspot.com/2010/08/ocamljs-03.html
CentOS 5 chroot with schroot:
http://le-gall.net/sylvain+violaine/blog/index.php?2010/08/26/63-centos-5-chroot-with-schroot
BOFs, Tutorials and Talks, oh my!:
http://ocaml.janestcapital.com/?q=node/83
Frama-C Boron-20100401:
http://caml.inria.fr/cgi-bin/hump.cgi?contrib=643
Otags 3.11.1:
http://caml.inria.fr/cgi-bin/hump.cgi?contrib=294
OASIS-DB: alpha website available:
http://www.ocamlcore.com/wp/?p=80
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.