Previous week Up Next week

Hello

Here is the latest Caml Weekly News, for the week of January 08 to 15, 2008.

  1. OCaml release 3.10.1
  2. OCaml first meeting in Paris, 26th Jan 2008
  3. On module distribution

OCaml release 3.10.1

Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/1b2ad14aa8bb706f#5c686757342eb1fd

Damien Doligez annonced:
It is our pleasure to announce the release of OCaml version 3.10.1. 
This is mainly a bug-fix release, see the list of changes below. 

It is available here: 
ftp://ftp.inria.fr/INRIA/cristal/caml-light/ocaml-3.10/ocaml-3.10.1.tar.bz2
and here: 
ftp://ftp.inria.fr/INRIA/cristal/caml-light/ocaml-3.10/ocaml-3.10.1.tar.gz

It will soon be available on the OCaml download page: 
http://caml.inria.fr/download.en.html 

Happy hacking, 
-- Damien Doligez for the OCaml team. 

Objective Caml 3.10.1: 
---------------------- 

Bug fixes: 
- PR#3830 small bugs in docs 
- PR#4053 compilers: improved compilation time for large variant types 
- PR#4174 ocamlopt: fixed ocamlopt -nopervasives 
- PR#4199 otherlibs: documented a small problem in Unix.utimes 
- PR#4280 camlp4: parsing of identifier (^) 
- PR#4281 camlp4: parsing of type constraint 
- PR#4285 runtime: cannot compile under AIX 
- PR#4286 ocamlbuild: cannot compile under AIX and SunOS 
- PR#4288 compilers: including a functor application with side effects 
- PR#4295 camlp4 toplevel: synchronization after an error 
- PR#4300 ocamlopt: crash with backtrace and illegal array access 
- PR#4302 camlp4: list comprehension parsing problem 
- PR#4304 ocamlbuild: handle -I correctly 
- PR#4305 stdlib: alignment of Arg.Symbol 
- PR#4307 camlp4: assertion failure 
- PR#4312 camlp4: accept "let _ : int = 1" 
- PR#4313 ocamlbuild: -log and missing directories 
- PR#4315 camlp4: constraints in classes 
- PR#4316 compilers: crash with recursive modules and Lazy 
- PR#4318 ocamldoc: installation problem with Cygwin (tentative fix) 
- PR#4322 ocamlopt: stack overflow under Windows 
- PR#4325 compilers: wrong error message for unused var 
- PR#4326 otherlibs: marshal Big_int on win64 
- PR#4327 ocamlbuild: make emacs look for .annot in _build directory 
- PR#4328 camlp4: stack overflow with nil nodes 
- PR#4331 camlp4: guards on fun expressions 
- PR#4332 camlp4: parsing of negative 32/64 bit numbers 
- PR#4336 compilers: unsafe recursive modules 
- PR#4337 (note) camlp4: invalid character escapes 
- PR#4339 ocamlopt: problems on HP-UX (tentative fix) 
- PR#4340 camlp4: wrong pretty-printing of optional arguments 
- PR#4348 ocamlopt: crash on Mac Intel 
- PR#4349 camlp4: bug in private type definitions 
- PR#4350 compilers: type errors with records and polymorphic variants 
- PR#4352 compilers: terminal recursion under Windows (tentative fix) 
- PR#4354 ocamlcp: mismatch with ocaml on polymorphic let 
- PR#4358 ocamlopt: float constants wrong on ARM 
- PR#4360 ocamldoc: string inside comment 
- PR#4365 toplevel: wrong pretty-printing of polymorphic variants 
- PR#4373 otherlibs: leaks in win32unix 
- PR#4374 otherlibs: threads module not initialized 
- PR#4375 configure: fails to build on bytecode-only architectures 
- PR#4377 runtime: finalisation of infix pointers 
- PR#4378 ocamlbuild: typo in plugin.ml 
- PR#4379 ocamlbuild: problem with plugins under Windows 
- PR#4382 compilers: typing of polymorphic record fields 
- PR#4383 compilers: including module with private type 
- PR#4385 stdlib: Int32/Int64.format are unsafe 
- PR#4386 otherlibs: wrong signal numbers with Unix.sigprocmask etc. 
- PR#4387 ocamlbuild: build directory not used properly 
- PR#4392 ocamldep: optional argument of class 
- PR#4394 otherlibs: infinite loops in Str 
- PR#4397 otherlibs: wrong size for flag arrays in win32unix 
- PR#4402 ocamldebug: doesn't work with -rectypes 
- PR#4410 ocamlbuild: problem with plugin and -build 
- PR#4411 otherlibs: crash with Unix.access under Windows 
- PR#4412 stdlib: marshalling broken on 64 bit architectures 
- PR#4413 ocamlopt: crash on AMD64 with out-of-bound access and reraise 
- PR#4417 camlp4: pretty-printing of unary minus 
- PR#4419 camlp4: problem with constraint in type class 
- PR#4426 compilers: problem with optional labels 
- PR#4427 camlp4: wrong pretty-printing of lists of functions 
- PR#4433 ocamlopt: fails to build on MacOSX 10.5 
- PR#4435 compilers: crash with objects 
- PR#4439 fails to build on MacOSX 10.5 
- PR#4441 crash when build on sparc64 linux 
- PR#4442 stdlib: crash with weak pointers 
- PR#4446 configure: fails to detect X11 on MacOSX 10.5 
- PR#4448 runtime: huge page table on 64-bit architectures 
- PR#4450 compilers: stack overflow with recursive modules 
- PR#4470 compilers: type-checking of recursive modules too restrictive 
- PR#4472 configure: autodetection of libX11.so on Fedora x86_64 
- printf: removed (partially implemented) positional specifications 
- polymorphic < and <= comparisons: some C compiler optimizations 
   were causing incorrect results when arguments are incomparable 

New features: 
- made configure script work on PlayStation 3 
- ARM port: brought up-to-date for Debian 4.0 (Etch) 
- many other small changes and bugfixes in camlp4, ocamlbuild, labltk, 
   emacs files
			

OCaml first meeting in Paris, 26th Jan 2008

Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/56d70f62fcfefe71#0a86d791b0147e33

Richard Jones announced:
First OCaml users conference, Sat 26th Jan 2008, at ENST Paris site 
Barrault, Paris, France. 

    http://wiki.cocan.org/events/europe/ocamlmeetingparis2008 

It's been about a month since the official announcement, and already 
21 people have signed up (quite a success I think).  If anyone else is 
intending to come, please sign up as soon as possible by editing the 
page above.  The conference is free and open to everyone, and there 
will be some speakers and workshops.
			

On module distribution

Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/e0089f39ec07151c#3a8422f00434fd85

Bünzli Daniel said:
A few month ago, after a discussion on cherry-picking modules in the   
reins library I thought a little bit about devising a system to   
facilitate module sharing. A system to simplify the tedious and   
uninteresting actions needed to be able to use and publish modules. At   
that time I started a design document for it, but as is expected in   
such cases the effort didn't last long. 

However since people will be meeting in Paris in a few week to discuss   
these things I thought there may be some ideas to take in this very   
rough and incomplete draft of a system that I will never implement. So   
FWIW here's a link [1] to this document. In summary the main ideas   
were : 

1. A decentralized system, anyone who can publish on a web server can   
publish a package. A central authority is a bottleneck to publication. 

2. Use atom feeds [2] as the distribution medium. Atom feeds contain   
all the semantic information (authors, contributors, entries, rights,   
link to enclosure, labels etc.) needed to represent a package and its   
versions with release notes. Shortly a package is a feed, a version is   
an entry with an enclosure link to an archive. The only extensions   
needed (Atom allows this via xml name spaces) are new link attributes   
to describe version dependencies. Packages as feeds allow to follow   
their evolution with a plain newsfeed reader (which would also   
facilitates the maintenance of repositories like the hump). To avoid   
angle brackets, package feeds are generated from a tagged plain text   
README file. 

3. Manage packages per project (vs. per machine) to make project   
dependencies explicit. Thus a single command can install you the   
(OCaml + C stubs only) dependencies of your project on a fresh system.   
If your project is a package itself, it facilitates its packaging . 

4. Rely on ocamlbuild to do the hard work. Grosso modo in the way   
described here [3], which may be unrealistic for big projects, but on   
unices ressource consumption could be mitigated by making hard links   
to a cache maintained per user or machine (inspired by ideas in this   
message [4]). 

Best, 
Daniel 
[1] http://erratique.ch/writings/mod.pdf 
[2] http://tools.ietf.org/html/rfc4287 
[3] http://brion.inria.fr/gallium/index.php/Working_on_dependent_projects_with_ocamlbuild
[4] http://caml.inria.fr/pub/ml-archives/caml-list/2007/04/ea46e76c646854347ad02dc10862a6ee.fr.html
			
Berke Durak suggested and Gerd Stolpmann answered:
> I'm not a big fan of hardlinking external stuff into the _build directory. 
> 
> I think we should rather add to Ocamlbuild a module for calling 
> ocamlfind, parsing its output, etc. This way ocamlbuild plugins could 
> easily call ocamlfind, be it for configuration or compilation. 
> 
> Pursuing the ocamlbuild philosophy of having a simple solution for 
> simple problems, a built-in tag syntax and associated rules should allow 
> such simple (e.g. regular) projects to easily use a package registered 
> in ocamlfind. 
> 
> I'm thinking of a tag use_ocamlfind(PROJECTNAME) so that you could write: 
> 
>    <myproject.{byte,native}>: use_ocamlfind(pcre), use_ocamlfind(mysql) 
> 
> Of course you still need to register those packages in ocamlfind. 
> 
> As Ocaml binaries are brittle, a solution for compiling from source such 
> as Godi is welcome. 
> 
> However Godi needs to be kept up-to-date with respect to the Ocaml 
> distribution... it is currently only available for 3.09!

Sorry, but this is not true. You can use Godi with Ocaml 3.10 by passing 
"-section 3.10" to the bootstrap script. 

It is right is that Godi for Ocaml 3.10 is not yet publicly announced. 
The reason is that a few libraries are not kept up-to-date. In 
particular, there are still libraries using camlp4 that are not 
available for 3.10. So we simply cannot recommend blindly upgrading to 
3.10 yet. 

It is unclear how we go on. Maybe we drop some libraries.
			
Sylvain Le Gall answered the OP:
> 1. A decentralized system, anyone who can publish on a web server can   
> publish a package. A central authority is a bottleneck to publication. 

Unfortunately, a decentralized system has also several drawbacks: 
* initial specification on how to be part of the decentralized system 
 must be precise and complete enough to not need to update it -- 
 decentralized system always need a clear "contract" to collaborate. 
 This part is by far not tricky if you are not 100% sure of what you 
 want to build and if you have never done it before (it is just 
 like designing a network protocol). 
* you need to provide a backup foreach node of your system. Otherwise, 
 every node will become a point of failure. This is critical: lets 
 consider you have a package A that build depends on package B, C and 
 D. With a centralized system you "download" point of failure is the 
 central location, either it is up or down. With a decentralized 
 approach your "download" point of failure will be the location of A, 
 B, C and D. You have to find a way to circumvent this problem... 
* automatic build and different checkup are more easily done in a 
 central repository (because everything is at the same place) 
* hijack of modules is more easily done in a central repository. This 
 point is important because, OSS developper tends to be Missing In 
 Action. 
* ... 

In fact, Debian user reading this will see that i am having the same 
sort of arguments that Debian has concerning the other distributions. 
Debian has developped a very centric repository for all its packages 
which other Linux distribution have not done. This tends to lead to have 
more control on the QA of everything. Which is better to my mind. 

> 2. Use atom feeds [2] as the distribution medium. Atom feeds contain   
> all the semantic information (authors, contributors, entries, rights,   
> link to enclosure, labels etc.) needed to represent a package and its   
> versions with release notes. Shortly a package is a feed, a version is   
> an entry with an enclosure link to an archive. The only extensions   
> needed (Atom allows this via xml name spaces) are new link attributes   
> to describe version dependencies. Packages as feeds allow to follow   
> their evolution with a plain newsfeed reader (which would also   
> facilitates the maintenance of repositories like the hump). To avoid   
> angle brackets, package feeds are generated from a tagged plain text   
> README file. 

You should have a look to DOAP 
http://usefulinc.com/doap/ 

> 3. Manage packages per project (vs. per machine) to make project   
> dependencies explicit. Thus a single command can install you the   
> (OCaml + C stubs only) dependencies of your project on a fresh system.   
> If your project is a package itself, it facilitates its packaging . 

I don't agree project and package are not the same thing. You should 
take into consideration that different distribution have different 
packaging policy.  Trying to have the same packaging policy for every 
distribution is not feasable (well in fact it is possible but it is a 
very long term wokr -- something like the Grand Unification Theory).
			

Using folding to read the cwn in vim 6+

Here is a quick trick to help you read this CWN if you are viewing it using vim (version 6 or greater).

:set foldmethod=expr
:set foldexpr=getline(v:lnum)=~'^=\\{78}$'?'&lt;1':1
zM

If you know of a better way, please let me know.


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