Hello
Here is the latest Caml Weekly News, for the week of 15 to 22 March, 2005.
Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/3dc634700a29951757a216a8ccc002a8.en.html
Oliver Bandel said:
A small tool I wrote (mbox-cleaner) was mentioned in
the current BraveGNUWorld.
OCaml was mentioned there too and it was written,
that "for a scripting language it's fast". ;-)
So maybe OCaml will be more known in the future, if people
would do more marketing on it. ;-)
(But other things written in that article were not all correct :(
but ... well...... )
http://www.linux-magazin.de/Artikel/ausgabe/2005/04/gnuwelt/gnu.html
(in german only)
(I don't know why since many months there are no english translations of the
BraveGNUWorld ...)...)
Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/656798aa05be7a035311a2ecb0eac80d.en.html
Christian Stork asked and Richard Jones answered:
> This must be a dumb question, but I couldn't find an answer.
>
> How can I print values of my own data types in the default way, eg, as
> the debugger or the toplevel does it? Is there a standard formatter
> that I can use (or generate), or do I have to write a new formatter for
> each data type?
One solution is to use Std.dump in Extlib[1]. It's not (AFAIAA)
available in any released version of Extlib, so you'd have to use the
CVS version, or use the original standalone version from which it is
derived:
http://merjis.com/developers/dumper
Rich.
[1] http://ocaml-lib.sourceforge.net/
Yoann Padioleau also answered:
you can try this:
http://www.irisa.fr/prive/padiolea/hacks/generic_print.ml
or this (better):
http://www.seedwiki.com/wiki/shifting_focus/tywith
Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/eaca75b29d80b5dd3d3ed34cbf7e7afe.en.html
Continuing the thread from last week, Ken Rose asked and Damien Doligez answered:
> > So if you allocate some things that go directly into the major heap
> > (for example reasonably large arrays or strings) you need a big major
> > heap as well as a big minor heap:
> > setenv OCAMLRUNPARAM 's=500M,h=500M,v=0x1ff'
>
> Is there some way to do this from inside the OCaml program? I don't
> see anything in a quick look at the documents for GC.
Look for "minor_heap_size" and "verbose" in the "control" record type.
As for the initial heap size, of course it cannot be set from inside
the program, but "major_heap_increment" will do in this case.
Reference: < http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html >
Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/44507729f8aece831b714090bf012a83.en.html
Spawning a huge thread, Karl Zilles said:
http://developers.slashdot.org/article.pl?sid=05/03/14/2258219
Jon Harrop said, Yoann Padioleau asked, and William D.Neumann answered:
> > I spent a little time on it but some Anonymous Coward has already done a much
> > better job and posted the resulting code on Jacques Garrigue's website. ;-)
>
> where ?
http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/garden2.ml
Jacques Garrigue said:
Well, since it seems difficult to hide that I'm an anonymous coward,
I add a few comments for the list.
Yoann Padioleau wrote:
> Yes but this ocaml code use array ?
> In that case it supports what the "troll" said, that is
> the resulting code is no more "functionnal".
> I agree with eijro sumii that ocaml is not just about functionnal
> programming but in the mind of many people advocating ocaml is advocating
> functionnal programming.
>
> I think the way to answer to those trolls is to teach them the way
> to do, in that case to use Map instead of associative list, and
> not to be pretentious and to tell that he is just a newbie.
> He is not a newbie, this garden optimization problem is not that simple.
In this particular case, I believe the trouble is rather that the
problem is really geared toward a specific solution. Efficient
memoization requires efficient access to memoized results, which in
this case can be obtained by mapping states to integers. And there
happens to be a trivial mapping. Then any solution will have to
iterate on the states.
If you look at my translation, I do not mutate arrays (except for
memoization), and use no references. That is, the mapping from states
to integers is actually produced in a purely functional way, and
arrays are only there to provide O(1) access. Moreover state
representation uses lists and natural sharing, so that it is
reasonably space efficient.
I also use lists, pattern matching, and recursion, so I believe this
fulfills his requirement about being written in functional style.
Out of curiosity, I also wrote a purely functional version, where
memoizing is done through an array of lazy values.
http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/garden3.ml
The code is actually slightly shorter. Performance is rather close.
On a Pentium M 1.8, for a 8x8 garden, I obtain (including memory usage)
Garden.cpp 5.8s 6.1MB (g++ -O)
Garden.cpp 4.5s 6.2MB (g++ -O3)
garden2.ml 5.9s 8.3MB (ocamlopt)
garden3.ml 10s 27.4MB (ocmalopt)
So you can see that garden2, while being almost purely functional,
is really equivalent in performance to his C++ code (which is a bit
dumb, but garden2 doesn't try to be more clever), while garden3 uses
more memory (as expected).
The only thing this example shows is that writing in a functional
language doesn't dispense you of doing a complexity analysis. In
particular the use of structural equality and association lists may
cost a lot in practice.
Some people may have a mystical belief that the compiler will
automatically improve your code through program transformation, but at
least in ocaml the situation is simple: the compiler does no
transformation whatsoever, so you get what you write.
And of course, SICP is a good reading before starting to write
in a functional programming language; I suppose all the structures I
used are explained there in detail.
Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/f8103b8be3f5d3fd4e3ac1d82473aa0e.en.html
Matthieu Dubuget said:
I asked a question related to Event usage there:
http://groups.yahoo.com/group/ocaml_beginners/message/2968
and Rémi Vanicat answered with clean explanations:
http://groups.yahoo.com/group/ocaml_beginners/message/2969
Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/696007fabd3f76fddc53d81588c5cbb1.en.html
David Mentre announced:
I'm pleased to announce the availability of stable release 0.4.0 of
demexp. Of course, demexp is programmed in OCaml.
What is demexp?
===============
demexp is a client/server system for direct democracy. It makes it
possible to ask questions in the system, add new answers to those
questions, and vote on proposed answers. The voting procedure used is
Condorcet voting. Questions are classified, and a delegation system (not
yet implemented) allows one's vote for certain questions to be assigned
to a chosen delegate. The software is tailored to the needs of the
Democratic Experience project.
What's new since latest annoucement[1]?
=======================================
Since last september we have added:
- a nice graphical client using lablgtk2 toolkit;
- save/load of server base in XML format using CDuce;
- redesign of classification system;
- disabling of delegation;
- various bug fixes to make it usable.
demexp can now be used for testing purpose in small groups.
What about the future?
======================
We know that the client is far from perfect and we plan to improve it in
the short term.
After that, we plan to do (in probable order): delegation;
internationalization and localisation; security.
*We are still looking for motivated OCaml developers.* :)
Where can I get a client?
=========================
Source code:
http://www.linux-france.org/~dmentre/demexp/latest-src/
Linux binary:
http://www.linux-france.org/~dmentre/demexp/binaries/
Debian package:
http://thomas.enix.org/pub/debian/packages/
Windows binary:
http://christophe.gisquet.free.fr/
Side note: in all above sites, client 0.3.8 or 0.3.9 is similar to
0.4.0.
How can I test it?
==================
A demonstration server is available at:
host: tuxinette.linux-france.org
port: 50000
A demonstration account:
login: demo
password: demo
Let me know if you want to have your user account.
Web links
=========
Development website:
http://savannah.nongnu.org/projects/demexp
The democratic experience project:
http://www.demexp.org
Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/ec607825ebe014084b365ddfa3d12dbd.en.html
Tyson Whitehead asked:
I was wondering about the status of map and friends with regard to tail
recursion. There was a big discussion back in 2003 about specific solutions
(implementation of the those functions using Obj) and more general compiler
support for holes/destination passing. It started with the following
message:
http://caml.inria.fr/pub/ml-archives/caml-list/2003/01/4a9754e53ff07723caf21b4496d1d267.en.html
It sounded to me like the general consensus was to immediately implement the
specific tail recursive versions of these functions for List and friends
(which were provided in the discusion), and then improve the compiler by
adding support for advanced hole/destination passing solutions.
Looking at the list implementation in the OCaml Debian unstable source, it
doesn't look like the more efficient version has been implemented. Further,
looking at the assembler emitted for the code it doesn't look like the
compiler supports holes/destination passing either.
January 2003 was quite a while ago, anybody know what's up here?
Richard Jones answered:
The extlib implementations are supposedly all tail-recursive.
http://cvs.sourceforge.net/viewcvs.py/ocaml-lib/extlib-dev/extList.mli?rev=1.18&view=markup
Jacques Garrigue also answered:
> It sounded to me like the general consensus was to immediately implement the
> specific tail recursive versions of these functions for List and friends
> (which were provided in the discusion), and then improve the compiler by
> adding support for advanced hole/destination passing solutions.
The result of this consensus is the extlib library. It provides those
tail-recursive functions.
http://ocaml-lib.sourceforge.net/
There is no project to include specific support in the compiler, but
the extlib implementation shows that this is not required if a bit of
magic is permitted.
Note that this list is not the core developers list, so the result of
discussions here does not imply anything on the ocaml distribution
itself.
> Looking at the list implementation in the OCaml Debian unstable source, it
> doesn't look like the more efficient version has been implemented. Further,
> looking at the assembler emitted for the code it doesn't look like the
> compiler supports holes/destination passing either.
To correct a misunderstanding: tail-recursive versions are not
necessarily more efficient (at least on short lists; short meaning
less than 10000 elements), but they are safer.
Non tail-recursive functions are carefully marked in the list module,
and alternative functions are included.
For instance:
let safe_map f l = List.rev (List.rev_map f l)
let safe_append l1 l2 = List.rev_append (List.rev l1) l2
provide you with tail recursive versions of map and append.
In practice they perform relatively well, if you don't want to
download extlib.
Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/0e35fc80c2c88cf805f3e8a4c4fedbbf.en.html
Eijiro Sumii announced:
I've written a simple OCaml script (using OCurl) that detects
seat/schedule changes of your flights on one particular airline (guess
which:-).
http://www.cis.upenn.edu/~sumii/united/
In case anybody (other than myself) uses this program, please let me
know whether it works - it is a little hard to test because it
requires real reservations and changes! (It worked for me at least a
few times in the last several months.)
If you don't understand why such a thing is useful, either (A) you
don't fly much, (B) you are _so_ patient that you don't feel much pain
when sitting in a non-bulkhead economy-class seat for 14 hours, (C)
you are rich enough to fly in business/first class without winning the
waitlisting competitions for free upgrades, or (D) you haven't yet
discovered the crazy world of frequent flyers.;-) In the last case,
you would have some fun by taking a look at
http://www.seatguru.com/
and
http://www.flyertalk.com/
for example.
Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/5917aa71d1502aace293a562028b1b1f.en.html
Damien Doligez announced:
We have the pleasure of announcing the release of
Objective Caml version 3.08.3
This is mostly a bug-fix release; see below for the list of
changes. Upgrading is not urgent unless you have problems with
one of the bugs listed below.
Please note that we do not guarantee binary compatibility with
previous versions (including 3.08.2).
Only the source is available for the moment. We will provide some
binaries in the near future.
It is available at http://caml.inria.fr/ocaml/release.en.html
-- Damien Doligez for the Caml Team
Objective Caml 3.08.3:
----------------------
New features:
- support for ocamlopt -pack under Mac OS X (PR#2634, PR#3320)
- ignore unknown warning options for forward and backward compatibility
- runtime: export caml_compare_unordered (PR#3479)
- camlp4: install argl.* files (PR#3439)
- ocamldoc: add -man-section option
- labltk: add the "solid" relief option (PR#3343)
- compiler: ocamlc -i now prints variance annotations
Bug fixes:
- typing: fix unsoundness in type declaration variance inference.
Type parameters which are constrained must now have an explicit
variant
annotation, otherwise they are invariant. This is not backward
compatible, so this might break code which either uses subtyping or
uses the relaxed value restriction (i.e. was not typable before
3.07)
- typing: erroneous partial match warning for polymorphic variants
(PR#3424)
- runtime: handle the case of an empty command line (PR#3409, PR#3444)
- stdlib: make Sys.executable_name an absolute path in native code
(PR#3303)
- runtime: fix memory leak in finalise.c
- runtime: auto-trigger compaction even if gc is called manually
(PR#3392)
- stdlib: fix segfault in Obj.dup on zero-sized values (PR#3406)
- camlp4: correct parsing of the $ identifier (PR#3310, PR#3469)
- windows (MS tools): use link /lib instead of lib (PR#3333)
- windows (MS tools): change default install destination
- autoconf: better checking of SSE2 instructions (PR#3329, PR#3330)
- graphics: make close_graph close the X display as well as the window
(PR#3312)
- num: fix big_int_of_string (empty string) (PR#3483)
- num: fix big bug on 64-bit architecture (PR#3299)
- str: better documentation of string_match and string_partial_match
(PR#3395)
- unix: fix file descriptor leak in Unix.accept (PR#3423)
- unix: miscellaneous clean-ups
- unix: fix documentation of Unix.tm (PR#3341)
- graphics: fix problem when allocating lots of images under Windows
(PR#3433)
- compiler: fix error message with -pack when .cmi is missing (PR#3028)
- cygwin: fix problem with compilation of camlheader (PR#3485)
- stdlib: Filename.basename doesn't return an empty string any more
(PR#3451)
- stdlib: better documentation of Open_excl flag (PR#3450)
- ocamlcp: accept -thread option (PR#3511)
- ocamldep: handle spaces in file names (PR#3370)
- compiler: remove spurious warning in pattern-matching on variants
(PR#3424)
- windows: better handling of InterpreterPath registry entry (PR#3334,
PR#3432)
Aleksey Nogin said:
I have compiled RPM packages of OCaml 3.08.3 :
- Fedora Core, all releases (1, 2, and 3)
- Red Hat Linux 8.0
- Mandrake 10.0
- Source RPM
Download them from http://rpm.nogin.org/ocaml.html
Sven Luther said:
Well, Debian packages should be in experimental in a bit, pending a full
rebuild of the 50+ ocaml-related packages which should take us a couple of
weeks.
Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/f8a04fe159222746c4ca17271cc44863.en.html
Michel Quercia announced:
The new Numerix release is available at the following URL:
http://pauillac.inria.fr/~quercia/cdrom/bibs/numerix.tar.gz
Numerix is a big integer library designed for a use with the Caml-Light and
Ocaml languages (among others). This new release implements faster algorithms
for very big integers (with several thousands bits or more) as well a SSE2
machine code for Pentiums >= 4 roughly twice as fast as the standard x86
machine code. Numerix-0.21 was sucessfuly tested with the following Operating
Systems :
Linux-PC, processors AMD-Athlon and Pentium-4
OpenBSD-PC, processor i386
Digital-Unix
Mac-OSX
I want to thank here Mark Shields for his great help in the Mac-OSX port.
Numerix-0.21 is expected to run on any Unix system similar to one of those, at
least with the Clong version (this is standard C code). The machine code
version (module Slong) if only available for x86 processors.
Documentation :
http://pauillac.inria.fr/~quercia/cdrom/bibs/numerix-eng.pdf
Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/379d29454b8c48aa6e8a020c09fe0485.en.html
Christian Szegedy asked and Jacques Garrigue answered:
> Is this possible in ocaml to dynamically load some (bytcode) OCaml file
> and run it in a safe environment, that is only using a small subset of
> selected functions instead of the whole Pervasives?
This is the intent of Dynlink.allow_only.
Not however that allowing is done on a unit base, so if you want to
allow only some functions in a unit, you must create a new one
containing only those, and compile your file against those (otherwise you
won't be able to load it).
This is the way MMM applets are made safe.
Also, there is no bytecode verifier. That is, a hand-crafted bytecode
file could break the above safety. In this respect, the bytecode
interpreter does not provide real sandboxing. If you want to protect
yourself, you have to use other ways, like a certified signature
scheme. The following paper explains this strategy to safety:
Xavier Leroy and Francois Rouaix. Security properties of typed
applets. In J. Vitek and C. Jensen, editors, Secure Internet
Programming - Security issues for Mobile and Distributed Objects,
volume 1603 of Lecture Notes in Computer Science, pages
147-182. Springer-Verlag, 1999.
Christian Szegedy then asked and Jacques Garrigue answered:
> Excellent! This sounds exactly what I want. Can I forbid
> the Pervasives unit while linking the applet?
Sure: just omit it from the allowed units.
The applet should then be compiled with the -nopervasives option.
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}$'?'<1':1
zM
If you know of a better way, please let me know.
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.