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.htmlOliver 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.htmlChristian 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. 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.  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.htmlContinuing 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.htmlSpawning a huge thread, Karl Zilles said:
http://developers.slashdot.org/article.pl?sid=05/03/14/2258219Jon 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.mlJacques 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.htmlMatthieu 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.htmlDavid 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? ======================================= 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.htmlTyson 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=markupJacques 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.htmlEijiro 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.htmlDamien 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.htmlSven 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.htmlMichel 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.htmlChristian 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).
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.