Hello

Here is the latest Caml Weekly News, for the week of June 05 to 12, 2012.

1. Beta release of OCaml 4.00.0
2. Parmap 0.9.9, and call for contributors
3. Distributed computing libraries
4. Windows installer for OCaml 4.00.0 beta 2
5. findlib-1.3.2 with support for ocaml-4.00
6. PXP-1.2.3 for OCaml-4.00
7. Official OCaml-4.00 patch for ocamlnet
8. ounit v1.1.2: Unit testing framework
9. OCaml-on-iOS resources updated for Lion
10. Other Caml News

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-06/msg00030.html

The release of OCaml version 4.00.0 is approaching. We have
created a beta version for your testing pleasure. Please
download the sources, compile, install, and test your favourite
software with it. Then let me know what happened, one way or
the other.

We are especially interested in testing done on exotic
architectures (i.e. non-Linux and non-Mac, or 32-bit processors).

This beta version is available as source code at this
address: http://caml.inria.fr/pub/distrib/ocaml-4.00/

The version number is 4.00.0+beta2, note that beta1 was not
released.

Happy hacking,

-- Damien Doligez for the OCaml team.


OCaml 4.00.0:
-------------

(Changes that can break existing programs are marked with a "*")

- The official name of the language is now OCaml.

Language features:
- Added Generalized Abstract Data Types (GADTs) to the language.
See chapter "Language extensions" of the reference manual for documentation.
- It is now possible to omit type annotations when packing and unpacking
first-class modules. The type-checker attempts to infer it from the context.
Using the -principal option guarantees forward compatibility.
- New (module M) and (module M : S) syntax in patterns, for immediate
unpacking of a first-class module.

Compilers:
- Revised simplification of let-alias (PR#5205, PR#5288)
- Better reporting of compiler version mismatch in .cmi files
* Warning 28 is now enabled by default.
- New option -absname to use absolute paths in error messages
- Optimize away compile-time beta-redexes, e.g. (fun x y -> e) a b.
- Added option -bin-annot to dump the AST with type annotations.
- Added lots of new warnings about unused variables, opens, fields,
constructors, etc.
* New meaning for warning 7: it is now triggered when a method is overridden
with the "method" keyword. Use "method!" to avoid the warning.

Native-code compiler:
- Optimized handling of partially-applied functions (PR#5287)
- Small improvements in code generated for array bounds checks (PR#5345,
PR#5360).
* New ARM backend (PR#5433):
. Supports both Linux/EABI (armel) and Linux/EABI+VFPv3 (armhf).
. Added support for the Thumb-2 instruction set with average code size
savings of 28%.
. Added support for position-independent code, natdynlink, profiling and
exception backtraces.
- In -g mode, generation of CFI information and a few filename/line
number debugging annotations, enabling in particular precise stack
backtraces with the gdb debugger. Currently supported for x86 32-bits
and 64-bits only. (PR#5487)
- New tool: ocamloptp, the equivalent of ocamlcp for the native-code compiler.

OCamldoc:
- PR#5544: improve HTML output (less formatting in html code)
- PR#5522: allow refering to record fields and variant constructors
- fix PR#5419 (error message in french)
- fix PR#5535 (no cross ref to class after dump+load)
* Use first class modules for custom generators, to be able to
load various plugins incrementally adding features to the current
generator
* PR#5507: Use Location.t structures for locations.
- fix: do not keep code when not told to keep code.

Standard library:
- Added float functions "hypot" and "copysign" (PR#3806, PR#4752, PR#5246)
* Arg: options with empty doc strings are no longer included in the usage
string
(PR#5437)
- Array: faster implementations of "blit", "copy", "sub", "append" and
"concat"
(PR#2395, PR#2787, PR#4591)
* Hashtbl:
. Statistically-better generic hash function based on Murmur 3 (PR#5225)
. Fixed behavior of generic hash function w.r.t. -0.0 and NaN (PR#5222)
. Added optional "random" parameter to Hashtbl.create to randomize
collision patterns and improve security (PR#5572, CVE-2012-0839)
. Added "randomize" function and "R" parameter to OCAMLRUNPARAMS
to turn randomization on by default (PR#5572, CVE-2012-0839)
. Added new functorial interface "MakeSeeded" to support randomization
with user-provided seeded hash functions.
. Install new header <caml/hash.h> for C code.
- Filename: on-demand (lazy) initialization of the PRNG used by "temp_file".
- Marshal: marshalling of function values (flag Marshal.Closures) now
also works for functions that come from dynamically-loaded modules (PR#5215)
- Random:
. More random initialization (Random.self_init()), using /dev/urandom
when available (e.g. Linux, FreeBSD, MacOS X, Solaris)
. Faster implementation of Random.float
- Scanf: new function "unescaped" (PR#3888)
- Set and Map: more efficient implementation of "filter" and "partition"
- String: new function "map" (PR#3888)

Installation procedure:
- Compiler internals are now installed in `ocamlc -where`/compiler-libs.
The files available there include the .cmi interfaces for all compiler
modules, plus the following libraries:
ocamlcommon.cma/.cmxa modules common to ocamlc, ocamlopt, ocaml
ocamlbytecomp.cma/.cmxa modules for ocamlc and ocaml
ocamloptcomp.cma/.cmxa modules specific to ocamlopt
ocamltoplevel.cma modules specific to ocaml
(PR#1804, PR#4653, frequently-asked feature).
* Some .cmi for toplevel internals that used to be installed in
`ocamlc -where` are now to be found in `ocamlc -where`/compiler-libs.
Add "-I +compiler-libs" where needed.
* toplevellib.cma is no longer installed because subsumed by
ocamlcommon.cma ocamlbytecomp.cma ocamltoplevel.cma
- Added a configuration option (-with-debug-runtime) to compile and install
a debug version of the runtime system, and a compiler option
(-runtime-variant) to select the debug runtime.

Bug Fixes:
- PR#1643: functions of the Lazy module whose named started with 'lazy_' have
been deprecated, and new ones without the prefix added
- PR#3571: in Bigarrays, call msync() before unmapping to commit changes
- PR#4292: various documentation problems
- PR#4511, PR#4838: local modules remove polymorphism
- PR#4549: Filename.dirname is not handling multiple / on Unix
- PR#4688: (Windows) special floating-point values aren't converted to strings
correctly
- PR#4697: Unix.putenv leaks memory on failure
- PR#4705: camlp4 does not allow to define types with `True or `False
- PR#4746: wrong detection of stack overflows in native code under Linux
- PR#4869: rare collisions between assembly labels for code and data
- PR#4880: "assert" constructs now show up in the exception stack backtrace
- PR#4892: Array.set could raise "out of bounds" before evaluating 3rd arg
- PR#4937: camlp4 incorrectly handles optional arguments if 'option' is
redefined
- PR#5024: camlp4r now handles underscores in irrefutable patern matching of
records
- PR#5064, PR#5485: try to ensure that 4K words of stack are available
before calling into C functions, raising a Stack_overflow exception
otherwise. This reduces (but does not eliminate) the risk of
segmentation faults due to stack overflow in C code
- PR#5084: sub-sub-module building fails for native code compilation
- PR#5120: fix the output function of Camlp4.Debug.formatter
- PR#5159: better documentation of type Lexing.position
- PR#5171: Map.join does more comparisons than needed
- PR#5176: emacs mode: stack overflow in regexp matcher
- PR#5179: port OCaml to mingw-w64
- PR#5211: updated Genlex documentation to state that camlp4 is mandatory for
'parser' keyword and associated notation
- PR#5224: confusing error message in non-regular type definition
- PR#5231: camlp4: fix parsing of <:str_item< type t = $x$ >>
- PR#5238, PR#5277: Sys_error when getting error location
- PR#5261, PR#5497: Ocaml source-code examples are not "copy-paste-able"
- PR#5290: added hash functions for channels, nats, mutexes, conditions
- PR#5295: OS threads: problem with caml_c_thread_unregister()
- PR#5301: camlp4r and exception equal to another one with parameters
- PR#5305: prevent ocamlbuild from complaining about links to _build/
- PR#5306: comparing to Thread.self() raises exception at runtime
- PR#5309: Queue.add is not thread/signal safe
- PR#5310: Ratio.create_ratio/create_normalized_ratio have misleading names
- PR#5311: better message for warning 23
- PR#5313: ocamlopt -g misses optimizations
- PR#5316: objinfo now shows ccopts/ccobjs/force_link when applicable
- PR#5318: segfault on stack overflow when reading marshaled data
- PR#5319: %r11 clobbered by Lswitch in Windows AMD64 native-code compilation
- PR#5322: type abbreviations expanding to a universal type variable
- PR#5325: (Windows) blocked Unix.recv in one thread blocks Unix.send in
another thread
- PR#5328: under Windows, Unix.select leaves sockets in non-blocking mode
- PR#5330: thread tag with '.top' and '.inferred.mli' targets
- PR#5331: ocamlmktop is not always a shell script
- PR#5335: Unix.environment segfaults after a call to clearenv
- PR#5338: sanitize.sh has windows style end-of-lines (mingw)
- PR#5343: ocaml -rectypes is unsound wrt module subtyping
- PR#5344: some predefined exceptions need special printing
- PR#5349: Hashtbl.replace uses new key instead of reusing old key
- PR#5356: ocamlbuild handling of 'predicates' for ocamlfind
- PR#5364: wrong compilation of "((val m : SIG1) : SIG2)"
- PR#5370: ocamldep omits filename in syntax error message
- PR#5374: camlp4 creates wrong location for type definitions
- PR#5380: strange sscanf input segfault
- PR#5382: EOPNOTSUPP and ENOTSUPP different on exotic platforms
- PR#5383: build failure in Win32/MSVC
- PR#5387: camlp4: str_item and other syntactic elements with Nils are
not very usable
- PR#5389: compaction sometimes leaves a very large heap
- PR#5393: fails to build from source on GNU/kFreeBSD because of -R link
option
- PR#5394: documentation for -dtypes is missing in manpage
- PR#5397: Filename.temp_dir_name should be mutable
- PR#5410: fix printing of class application with Camlp4
- PR#5416: (Windows) Unix.(set|clear)_close_on_exec now preserves blocking
mode
- PR#5435: ocamlbuild does not find .opt executables on Windows
- PR#5436: update object ids on unmarshaling
- PR#5442: camlp4: quotation issue with strings
- PR#5453: configure doesn't find X11 under Ubuntu/MultiarchSpec
- PR#5461: Double linking of bytecode modules
- PR#5463: Bigarray.*.map_file fail if empty array is requested
- PR#5465: increase stack size of ocamlopt.opt for windows
- PR#5469: private record type generated by functor loses abbreviation
- PR#5475: Wrapper script for interpreted LablTk wrongly handles command line
parameters
- PR#5476: bug in native code compilation of let rec on float arrays
- PR#5477: use pkg-config to configure graphics on linux
- PR#5481: update camlp4 magic numbers
- PR#5482: remove bashism in test suite scripts
- PR#5495: camlp4o dies on infix definition (or)
- PR#5498: Unification with an empty object only checks the absence of
the first method
- PR#5503: error when ocamlbuild is passed an absolute path as build directory
- PR#5509: misclassification of statically-allocated empty array that
falls exactly at beginning of an otherwise unused data page.
- PR#5510: ocamldep has duplicate -ml{,i}-synonym options
- PR#5511: in Bigarray.reshape, unwarranted limitation on new array
dimensions.
- PR#5513: Int64.div causes floating point exception (ocamlopt, x86)
- PR#5516: in Bigarray C stubs, use C99 flexible array types if possible
- PR#5518: segfault with lazy empty array
- PR#5531: Allow ocamlbuild to add ocamldoc flags through -docflag
and -docflags switches
- PR#5543: in Bigarray.map_file, try to avoid using lseek() when growing file
- PR#5538: combining -i and -annot in ocamlc
- PR#5551: repeated calls to find_in_path degrade performance
- PR#5552: Mac OS X: unrecognized gcc option "-no-cpp-precomp"
- PR#5555: add Hashtbl.reset to resize the bucket table to its initial size
- PR#5560: incompatible type for tuple pattern with -principal
- PR#5575: Random states are not marshallable across architectures
- PR#5579: camlp4: when a plugin is loaded in the toplevel,
Token.Filter.define_filter has no effect before the first syntax error
- PR#5585: typo: "explicitely"
- PR#5587: documentation: "allows to" is not correct English
- PR#5593: remove C file when -output-obj fails
- PR#5598: add backslash-space support in strings in ocamllex
- PR#5603: wrong .file debug info generated by ocamlopt -g
- PR#5604: fix permissions of files created by ocamlbuild itself
- PR#5610: new unmarshaler (from PR#5318) fails to freshen object identifiers
- PR#5614: add missing -linkall flag when compiling ocamldoc.opt
- PR#5616: move ocamlbuild documentation to the reference manual
- PR#5619: Uncaught CType.Unify exception in the compiler
- PR#5620: invalid printing of type manifest (camlp4 revised syntax)
- problem with printing of string literals in camlp4 (reported on caml-list)
- emacs mode: colorization of comments and strings now works correctly
- problem with forall and method (reported on caml-list on 2011-07-26)

Feature wishes:
- PR#352: new option "-stdin" to make ocaml read stdin as a script
- PR#1164: better error message when mixing -a and .cmxa
- PR#1284: documentation: remove restriction on mixed streams
- PR#1496: allow configuring LIBDIR, BINDIR, and MANDIR relative to $(PREFIX)
- PR#1835: add Digest.from_hex
- PR#1898: toplevel: add option to suppress continuation prompts
- PR#4278: configure: option to disable "graph" library
- PR#4444: new String.trim function, removing leading and trailing whistespace
- PR#4549: make Filename.dirname/basename POSIX compliant
- PR#4830: add option -v to expunge.ml
- PR#4898: new Sys.big_endian boolean for machine endianness
- PR#4963, PR#5467: no extern "C" into ocaml C-stub headers
- PR#5199: tests are run only for bytecode if either native support is
missing,
or a non-empty value is set to "BYTECODE_ONLY" Makefile variable
- PR#5215: marshalling of dynlinked closure
- PR#5236: new '%revapply' primitive with the semantics 'revapply x f = f x',
and '%apply' with semantics 'apply f x = f x'.
- PR#5295: OS threads: problem with caml_c_thread_unregister()
- PR#5297: compiler now checks existence of builtin primitives
- PR#5329: (Windows) more efficient Unix.select if all fd's are sockets
- PR#5358: first class modules don't allow "with type" declarations for types
in sub-modules
- PR#5385: configure: emit a warning when MACOSX_DEPLOYMENT_TARGET is set
- PR#5396: ocamldep: add options -sort, -all, and -one-line
- PR#5397: Filename.temp_dir_name should be mutable
- PR#5403: give better error message when emacs is not found in PATH
- PR#5411: new directive for the toplevel: #load_rec
- PR#5420: Unix.openfile share mode (Windows)
- PR#5421: Unix: do not leak fds in various open_proc* functions
- PR#5434: implement Unix.times in win32unix (partially)
- PR#5437: warning for useless open statements
- PR#5438: new warnings for unused declarations
- PR#5439: upgrade config.guess and config.sub
- PR#5445 and others: better printing of types with user-provided names
- PR#5454: Digest.compare is missing and md5 doc update
- PR#5455: .emacs instructions, add lines to recognize ocaml scripts
- PR#5456: pa_macro: replace __LOCATION__ after macro expansion; add
LOCATION_OF
- PR#5461: bytecode: emit warning when linking two modules with the same name
- PR#5478: ocamlopt assumes ar command exists
- PR#5479: Num.num_of_string may raise an exception, not reflected in the
documentation.
- PR#5501: increase IO_BUFFER_SIZE to 64KiB
- PR#5532: improve error message when bytecode file is wrong
- PR#5555: add function Hashtbl.reset to resize the bucket table to
its initial size.
- PR#5586: increase UNIX_BUFFER_SIZE to 64KiB
- PR#5599: Add warn() tag in ocamlbuild to control -w compiler switch
- ocamldebug: ability to inspect values that contain code pointers
- ocamldebug: new 'environment' directive to set environment variables
for debuggee
- configure: add -no-camlp4 option

Shedding weight:
* Removed the obsolete native-code generators for Alpha, HPPA, IA64 and MIPS.
* The "DBM" library (interface with Unix DBM key-value stores) is no
longer part of this distribution. It now lives its own life at
https://forge.ocamlcore.org/projects/camldbm/
* The "OCamlWin" toplevel user interface for MS Windows is no longer
part of this distribution. It now lives its own life at
https://forge.ocamlcore.org/projects/ocamltopwin/

Other changes:
- Copy VERSION file to library directory when installing.
      

> This beta version is available as source code at this
> address: http://caml.inria.fr/pub/distrib/ocaml-4.00/
A beta version of the reference manual is not available at
the same address.
			

I'm now maintaining an out-of-tree ppc64 backend (note: not Rhapsody,
this is for IBM POWER and Linux on Mac G5s). In fact I fixed two bugs
in it just today.

http://git.fedorahosted.org/git/?p=fedora-ocaml.git

If someone wants to pull together all the out-of-tree backends into
one place, let me know. I'm sort of interested in maintaining the
dropped Itanic backend too, since customers will insist on using it
for some reason.
			

For people interrested MIPS support is back in, there:

http://github.com/rixed/ocaml-4-for-mips

It was pretty easy, since almost nothing had changed in the backend.
So it was perhaps more work required to remove mips support than to
reintroduce it. :-/
			

Ok so I've just created the retired-camels organization in github,
with a fork of Benedikt mirror, and then cherry picked the two
commits you mentioned above the 4.00 branch (in a branch named
ppc64). I've done as well with the mips commits.

Could you please check that this ppc64 branch works on ppc64?
I will check as well the mips branch in a few days. When both are
OK we should merge them into a a 'more-arch' branch that we'll
just have to rebase regularly, until a better solution emerge.

(Editor note: find this repository here:
https://github.com/retired-camels.)
			

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-06/msg00042.html

a few lines to announce the (much improved) version
0.9.9 of Parmap, the minimalistic library which can be useful
to exploit your multicore processor with minimal modifications
to your OCaml programs.

A full description is in the README file, as well as several
examples, and an article on Parmap has just appeared here:
http://www.sciencedirect.com/science/article/pii/S1877050912003237

Main changes
------------

- the new combinator pariter iterates over a sequence; since
no result is returned to the main process, this code is
faster than calling parmap and ignoring the result

- new functions that provide as argument the index of the
element of the sequence: parmapi, parmapifold,
array_parmapi, array_float_parmapi

- it is now possible to set the default number of cores used
when calling the combinators without the optional parameter
ncores

- eliminated dependencies on external libraries: this code
should now build out of the box on any machine

- added configure support for use with legacy OCaml 3.11
and tested to build correctly with OCaml 4.00

- initial support for Oasis packaging

In a nutshell
-------------

If you want to use your many cores to accelerate an operation which
happens to be a map, fold or map/fold (map-reduce), just use Parmap's
parmap, parfold and parmapfold primitives in place of the standard
List.map and friends; you can specify the number of subprocesses to
use with the optional parameter ncores, and the size of granularity
of the paralle computation with the optional parameter chunksize.

For example, in the classical Mandelbrot present in the example
directory, the line

Parmap.parmap ~ncores: !ncores ~chunksize: !chunksize pixel (Parmap.L tasks)

allows to spawn ncores separate processes, each working on sublists of
size chunksize of the tasks list.

How to get it
-------------

Project home: https://gitorious.org/parmap

The release announced in this message has hash
1c5b5eac61eda2454034a43eb124ab490885ef3a
and is tagged Released-0.9.9

To compile and install:

git clone git://gitorious.org/parmap/parmap.git
git checkout master
aclocal -I m4
autoconf
./configure
make
make install

How to help
-----------

We would use some help on

- writing unit tests, both for functionality, and
speedup estimation

- adding support for automatically determining
the number of available physical cores on the
different unix-like operating systems (can be tricky)

Enjoy

-- Marco Danelutto and Roberto Di Cosmo

P.S.: many thanks to Francois Berenger for extensive testing, to Jerome
Maloberti for GODI packaging, and to Markus Weissman for suggestion the
default for ncores.
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-06/msg00043.html

There exists several different "distributed computing libraries" in OCaml:

- Functory http://functory.lri.fr/
- JoCaml http://jocaml.inria.fr/ (not really a library, though)
- Nproc https://github.com/MyLifeLabs/nproc
- OCaml for multicore http://www.algo-prog.info/ocmc/web/ (not a library
either)
- Parmap https://gitorious.org/parmap/parmap
- Plasma Map/Reduce http://plasma.camlcity.org/plasma/

And I am pretty sure that this list is not exhaustive, looking at
http://caml.inria.fr/cgi-bin/hump.en.cgi?sort=0&browse=77

Maybe it would be interesting for the community if someone could sum
up the pros and cons of each of this "libraries", and maybe give some
information about their status (still in development, mature, etc)?
      

CamlP3l http://camlp3l.inria.fr/eng.htm

> Maybe it would be interesting for the community if someone could sum
> up the pros and cons of each of this "libraries", and maybe give some
> information about their status (still in development, mature, etc)?

Yes this would be fine.
And maybe "someone" could also mean some people...
...maybe there are people out there, that now one or two of them well,
and other of these libs not or not well.

...so that the information can be gathered by a lot of people.

But it would be fine to have some criteria for classifying.

For example:

- one / multicore
- local machine / distributed via net
- threads / processes
- just library calls, language extension, or seperate language
- toplevel-runtime / byte code / native-code
- necessity of code rewrite for local and remote/distributive stuff,
or possibility of transparent usage
			

- compatibility with commonly used libraries
			

I was one of the two authors of the ocamlpvm interface. It works well and has
been used for large "industrial" projects without any particular
problems. These bindings are especially interesting when you need simple
communications between different processes, and you also need to be able to
launch processes by hand. The PVM bindings are stable and robust, PVM works
for multi-core and network parallelism but PVM is also slowly dying.

We have also been using lately the MPI bindings written by Xavier Leroy. The
Ocaml bindings+MPI are an extremely efficient way to write parallel
applications in the MPI paradigm. We compared it to a "home-made" shared
memory system for exchanging objects between ocaml processes, and MPI is much
faster (we were using MPICH2 MPI implementation), with, as a bonus, all the
MPI goodies (such as transparent network parallelism). Well, that's a lesson
to learn: leave parallelism implementation to the professionals.
We had to add one or two functions to Xavier's bindings to do the job (the MPI
bindings are not complete, and if I remember correctly the iprobe function was
not implemented). The modification is trivial.
If there are people interested, I could probably dig up the code.
			

These are very different pieces of software, because they tackle problems at
various abstraction levels. ocmc is the most level-level here, as it "only"
tries to improve the runtime so that threads can be run in parallel on
multiple cores. That's it, there is no additional abstraction on top of the
standard threading API - no distribution, no computing.

JoCaml uses the normal multi-threading in the runtime, but integrates it
differently into the language. So, it adds abstraction, but you are still
limited to a single core.

So far I know, all the other libraries base on multi-processing to run
programs on multiple cores. Plasma is the only one with true distribution
capabiltiies beyond a single computer, but the price is that you must use the
map/reduce scheme, whereas functory or parmap leave you more freedom. However,
all multi-processing approaches share the property that the data flow is
limited by process boundaries (unless you go really low-level and also take
Netmulticore into consideration (part of Ocamlnet), which uses shared memory
to overcome these limitations).

I don't know what you are exactly looking for. Knowing the problem it would be
easier to recommend something.
			

> Functory is able to run across a network, with clients listening for
> connections from the master to give them work to do. It is
> restricted to a variant of map/reduce, so it doesn't give you that
> much freedom.

OCamlP3l allows computations transparently local or runnuning over many hosts.
			

> As you know Functory a bit better: how is the data delivered to network
> clients? Just via the network connection that also assigns the work to
> do? That would be a bit lame, and not really useful.

Yes, the input parameters of the function to be run are sent over the network
connection that assigns work to do, and the results come back over that same
connection. That said, it's possible to use a network file system to
distribute the real data and just pass filenames over the control channel.
			

> Don't hesitate, jump on it, that's really a nice technology.
> The "minimal disruption" concept is quite interesting.
> For example, if your List.iter is changed to a Parmap.pariter,
> the parallelization of this portion of the code is done.
>
> It's quite comfortable to develop and debug in single core mode (List.iter)
> and switch to the // version only once you're happy with
> the sequential one.

I see. However, looking at, e.g., Functory,
http://www.lri.fr/~filliatr/functory/doc/Functory.Cores.html it seems
that I can use it in the same fashion (Using Functory.Cores.map
instead of List.map) and that I can debug my code using
Functory.Sequential.map.

So this does not really discriminate between the two libraries. Note,
however, that I cannot find Parmap's API described on line (using
ocamldoc). Right now, it seems that I have to download it, to generate
the doc.

Note that Gerd's Plasma Map/Reduce has a nice and comprehensive
documentation available, but, being more ambitious maybe, it is harder
for a beginner to find his/her way in: the entry cost is higher.

By comparison, JOcaml's manual is written in a quasi-tutorial fashion
( http://jocaml.inria.fr/doc/index.html ) which makes it more easy to
start hacking stuff, even if the scope is a bit different.

And what about CamlP3l? What is its status? Is it superseded by Parmap
(the lists of authors of the two softwares have a non-empty
intersection)?

Maybe that I should add some criteria to Oliver's list:
- active / inactive
- used in the wild
- documentation (API, manual)
- examples / tutorials
			

Functory can distribute computations while parmap can only parallelize them on
your local machine.  I'm pretty sure that parmap is faster at doing what they
can be compared on because it has specialized optimizations that you cannot
use if your data has to be distributed over the network.

The last time I looked at Functory:
- Functory had several not tail recursive functions and blew my stack
(it was about one year ago, maybe things have changed)
- not any mailing list for functory
- while parmap has:
parmap-devel
<parmap-devel AT inria.fr>
and
parmap-users
<parmap-users AT inria.fr>
- no GODI package for functory
- parmap has a GODI package (thanks to Jerome
Maloberti) and maybe very soon an oasis one

> Note that Gerd's Plasma Map/Reduce has a nice and comprehensive
> documentation available, but, being more ambitious maybe, it is harder
> for a beginner to find his/her way in: the entry cost is higher.

It's also for distributed computing, parmap is for local parallelization.

> By comparison, JOcaml's manual is written in a quasi-tutorial fashion
> ( http://jocaml.inria.fr/doc/index.html ) which makes it more easy to
> start hacking stuff, even if the scope is a bit different.


I'm not sure it's standard OCaml code then.
At least with parmap and functory, they are just libraries that
you can plug into any plain vanilla OCaml source code.
			

Roberto Di Cosmo just created a home page:
http://www.dicosmo.org/code/parmap/

The ocamldoc-generated pages are here:
http://www.dicosmo.org/code/parmap/doc/Parmap.html
			

Quite a good point, and it really goes beyond just the bunch of
(very useful) libraries that try to speed-up computations by
leveraging multicore/multiprocessors/clusters etc.

I think OCaml is a wonderful language, and it has the potential
to attract much more users if we can make it easy to find, build,
install, compare and assess the various libraries, packages
and tools that are available.

If I can dream with my eyes open (which is a decent way of
spending time while waiting for a plane in the middle
of Nebraska, after all :-)), I could imagine:

(1) a central repository for OCaml projects where
packages are uploaded, with their different versions, tagged,
and classified, with pointers to the current, active development
platform (github, gitorious, sourceforge, whatever) (Oasis DB?)

(2) a continuous integration server testing buildability of the
different versions of the packages, with different versions
of the compiler, and on all available architectures, reporting
errors in a meaningful way to their authors, and providing
extremely valuable information to users that will know
beforehand what works and what does not work on which
configuration, instead of discovering this the hard way
(Debian OCamlers lurking here surely know what is the source
of inspiration of this part of my dream; and yes, Debian does
all this for the Debian OCaml packages, but we need to cater
to *all* users :-))

(3) an organised OCamlPedia site where, for each 'class' of
problem (parallelism, parsing, graph algorithms, numerical
computation, code transformation, you name it) developers and users
can contribute to maintain up-to-date summaries, comparisons,
test results, code snippets, pointers to scientific papers
and the like...
And for each "feature" of the language, I'd love to see tutorials,
code examples, pointers to the relevant literature, and to
packages showing them off.

To get there, we need to make our collaborative hidden side shine,
and complete the effort started by some of us to organise the community...
maybe this will happen during the coffee break at the next OCaml meeting.

Ok, time to stop dreaming, to go back to reality, and to catch that flight

--Roberto

P.S.: hey, I just checked, and ocamlpedia.* is available,
so I registered ocamlpedia.org, and I'll be more than happy
to offer it to whomever will run the site, if it happens :-)
			

> I completely agree with what you just said, and that was the point of
> my question: trying to assess, in a single thread, the various
> possibilities that exist to solve a given problem [1]. Now, it happens
> that I had been thinking about the same kind of mail about package
> managers, because there is also a huge variety of solutions. So, I
> could ask, what are the pros and cons of the following package
> managers?
> 
> - https://github.com/thelema/odb
> - https://github.com/hcarty/ocamlbrew
> - https://github.com/OCamlPro/opam
> - http://godi.camlcity.org/godi/index.html
> - http://oasis.forge.ocamlcore.org/oasis-db.html

Here is my personal experience with some of them (ocamlbrew, odb, oasis and
oasis-db):
- ocamlbrew can be used to bootstrap odb (get OCaml and findlib from
scratch)
- from there, odb can install other OCaml libraries and programs
- odb can install oasis and then use oasis-db to get packages
- you can modify a 'packages' file so that odb can install things
that are not available publicly or that are not yet packaged for oasis

From my point of view, these tools definitely have the UNIX taste:
they are fast, they are easy to use and quite easy to troubleshoot in case
something doesn't work as expected; which make them excellent in my opinion
compared to other solutions.

> But I do not want to fork that thread yet ;).
> 
> I think a more general perspective on this was given a while ago on
> this list by Xavier, a while ago on this list (trying to paraphrase):
> - the community needs a common packaging system
> - there is often a lack of convergence between related projects (in
> this case, libraries, for instance).
> 
> >   And for each "feature" of the language, I'd love to see tutorials,
> >   code examples, pointers to the relevant literature, and to
> >   packages showing them off.
> 
> On a related note, I was delighted to see that there are two books
> about OCaml in the pipes currently, and I think this is great.
> 
> Thomas
> [1] Actually, I did that also a while ago, about openGL bindings, and
> the following discussion was quite fruitful
			

> (3) an organised OCamlPedia site where

The ocamlweb project announced at last year's OCaml User's Meeting can serve
this purpose. Please see the master repo here [1] and the live site here
[2]*. We welcome and need the community to add more content. We've attempted
to make contributing easier. You just checkout a git project, add simple html,
and submit a pull request. This is perhaps not as nice as a wiki, but it let's
us scale up to other features that wikis are not suitable for.

If you need help getting a larger section started, such as on the topic of
this thread, just email me or the mailing list [3].

[1] https://github.com/agarwal/ocamlweb
[2] http://www.ocaml-lang.org/
[3] https://lists.forge.ocamlcore.org/cgi-bin/listinfo/ocamlweb-devel
* Note the live site is behind the master repo as we have some cleaning up yet
to do in the master branch.
			

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-06/msg00044.html

A new version of the windows installer for OCaml is now available at
http://protz.github.com/ocaml-installer/. It features all the fixes
described in my previous message
https://groups.google.com/d/msg/fa.caml/3Nq9wtlTJ4Q/gtZ8z66O0BcJ. There's a
companion blog post on the gagallium blog that describes my journey in the
land of windows
http://gallium.inria.fr/~scherer/gagallium/the-ocaml-installer-for-windows.

All feedback is welcome -- there's currently one know issue
https://github.com/protz/ocaml-installer/issues.
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-06/msg00091.html

I've just released findlib-1.3.2. The most interesting change is that it works
now for ocaml-4.00.

For details, download, manual, etc, look at
http://projects.camlcity.org/projects/findlib.html. A complete list of
changes can be found in README.
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-06/msg00100.html

I've just released PXP-1.2.3, and the only change is the port to OCaml-4.00
(based on a patch from Richard Jones).

Download, manual etc. under http://projects.camlcity.org/projects/pxp.html
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-06/msg00101.html

as there are some incomplete patches around, here are the official ones
(against ocamlnet-1.5.1):

https://godirepo.camlcity.org/svn/godi-build/trunk/godi/godi-ocamlnet/patches/patch-ac-netsys-and-ocaml4
https://godirepo.camlcity.org/svn/godi-build/trunk/godi/godi-ocamlnet/patches/patch-ad-netstring-and-ocaml4

Note that type definitions like

type open_flag1 = Unix.open_flag =
O_RDONLY | O_WRONLY | O_RDWR | O_NONBLOCK | O_APPEND | O_CREAT | O_TRUNC
| O_EXCL | O_NOCTTY | O_DSYNC | O_SYNC | O_RSYNC

are not meaningless in the presence of stub libraries, and work like
assertions for types. The addition of O_SHARE_DELETE makes this fail. Very
good, because the corresponding list in the stub needs to be extended, too
(which the other patches do not do, and this can lead to segfaults).

There will also be a release of Ocamlnet soon, but this overlaps currently
with the final QA testing of the regular development cycle.
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-06/msg00105.html

The main point of this release is to update the generated setup.ml to be
compatible with upcoming OCaml v4.0.0.

OUnit is a unit testing framework for OCaml, inspired by the JUnit tool for
Java, and the HUnit tool for Haskell.

More information on [HUnit](http://hunit.sourceforge.net)

Homepage:
http://ounit.forge.ocamlcore.org

Get source code:
$ darcs get http://darcs.ocamlcore.org/repos/ounit

Browse source code:
http://darcs.ocamlcore.org/cgi-bin/darcsweb.cgi?r=ounit;a=summary
      

OUnit 1.1.2 is now also in Godi v4.0.0.
			

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2012-06/msg00106.html

For those interested in OCaml apps on iOS, I've updated all the
resources on our site to work with OS X 10.7 (Lion).

Right now, there are compilers for iOS itself and the iOS Simulator, an
OpenGL ES interface, and 5 example apps (with sources). If you already
have the iOS Simulator (part of Xcode), I repackaged 3 of the apps to
run immediately in the simulator (with just a few clicks). So you can
try them just for fun.

Everything is listed on the main OCaml page:

http://psellos.com/ocaml/

The old versions of the pages are still available on an archives page:

http://psellos.com/ocaml/ocaml-archives.html

The next thing to look at (I think) is support for OCaml 4.

As always, I'm very happy to hear from anybody interested in running
OCaml on iOS (or anything else I can help with).
      

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/.

OCaml 4.00.0 beta 2 is in Rawhide:
  http://rwmj.wordpress.com/2012/06/09/ocaml-4-00-0-beta-2-is-in-rawhide/

Ocsigen Eliom 2.2 released:
  http://ocsigen.org/

OCaml 4 beta:
  http://gaiustech.wordpress.com/2012/06/07/ocaml-4-beta/

Gallium submissions to the ML Workshop 2012:
  http://gallium.inria.fr/~scherer/gagallium/ml-workshop-2012-submissions/index.html

Batteries updates:
  https://forge.ocamlcore.org/forum/forum.php?forum_id=839

New release: Opa 0.9.3:
  http://blog.opalang.org/2012/06/new-release-opa-093.html
      

Old cwn

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.

Alan Schmitt