Hello
Here is the latest Caml Weekly News, for the week of 16 to 23 August, 2005.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30141
Damien Doligez announced:
We have the pleasure of announcing the release of
Objective Caml version 3.08.4
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.3).
Only the source is available for the moment. We will provide some
binaries in the near future; in the meantime, the binaries on the
Web page are still for OCaml 3.08.3.
OCaml 3.08.4 is available at http://caml.inria.fr/ocaml/release.en.html
-- Damien Doligez for the Caml Team
Objective Caml 3.08.4:
----------------------
New features:
- configure: find X11 config in some 64-bit Linux distribs
- ocamldoc: (**/**) can be canceled with another (**/**) PR#3665
- graphics: added resize_window
- graphics: check for invalid arguments to drawing primitives PR#3595
- lablbrowser: use windows subsystem on mingw
Bug fixes:
- ocamlopt: code generation problem on AMD64 PR#3640
- wrong code generated for some classes PR#3576
- fatal error when compiling some OO code PR#3745
- problem with comparison on constant constructors PR#3608
- better detection of cycles when using -rectypes
- missing case of module equality PR#3738
- better error messages for unbound type variables
- stack overflow while printing type error message PR#3705
- assert failure when typing some classes PR#3638
- bug in type_approx
- better error messages related to type variance checking
- camlp4: cryptic error message PR#3592
- camlp4: line numbers in multi-line antiquotations PR#3549
- camlp4: problem with make depend
- camlp4: parse error with :> PR#3561
- camlp4: ident conversion problem with val/contents/contents__
- camlp4: several small parsing problems PR#3688
- ocamldebug: handling of spaces in executable file name PR#3736
- emacs-mode: problem when caml-types-buffer is deleted by user PR#3704
- ocamldoc: extra backslash in ocamldoc man page PR#3687
- ocamldoc: improvements to HTML display PR#3698
- ocamldoc: escaping of @ in info files
- ocamldoc: escaping of . and \ in man pages PR#3686
- ocamldoc: better error reporting of misplaced comments
- graphics: fixed .depend file PR#3558
- graphics: segfault with threads and graphics PR#3651
- nums: several bugs: PR#3718, PR#3719, others
- nums: inline asm problems with gcc 4.0 PR#3604, PR#3637
- threads: problem with backtrace
- unix: problem with getaddrinfo PR#3565
- stdlib: documentation of Int32.rem and Int64.rem PR#3573
- stdlib: documentation of List.rev_map2 PR#3685
- stdlib: wrong order in Map.fold PR#3607
- stdlib: documentation of maximum float array length PR#3714
- yacc: avoid name capture for idents of the Parsing module
Aleksey Nogin then said:
I've compiled a number of binary packages of OCaml 3.08.4 (Fedora Core
2, 3, and 4, Mandrake 10.1, Red Hat Enterprise Linux 4). They are
available at http://rpm.nogin.org/ocaml.html
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30159
Matt Wade announced:
Wanted: One OCaml Expert to do a technical review on an upcoming book. Pay
is decent for the amount of time involved. You'll also receive a full page
acknowledgement in the book (with picture if you like) and a copy of the
book to use as a business card.
If you are interested, please contact me off list with your qualifications
and resume.
--Matt Wade
Open Source Editor
http://www.apress.com/
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30166
Michael Wohlwend asked and Eric Cooper answered:
> I know this question was asked some time ago, but those little
> devices are getting better every day :) The tungsten T3/T5 have
> 400MHz and 64MB, T5 has 256 MB ram; my sony has 200MHz and 32MB Ram
> (o.k., not much). Could ocaml (not caml-light) run on such a T3 or
> T5? Or just the runtime and cross-compiling?
OCaml runs fine on a Sharp Zaurus (400 MHz ARM with 64 MB of memory);
the ocaml interpreter runs on the device as well as cross-compiled native
code. But of course it's running Linux, not PalmOS.
Porting the runtime would be the main obstacle, I guess, depending on
how much POSIX-compatibility you can get from PalmOS. I've also heard
rumors that Palm will move to an embedded Linux platform, so maybe the
answer is just to be patient.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30177
Nicolas Cannasse announced:
I have released Neko 1.0 which is an intermediate programming language with
its virtual machine. The compiler is written in OCaml and the VM in C. It
might be interesting for people involved in language design, since Neko is
providing a common reusable runtime for language designers.
You can have a look at the documentation and download the release at
http://nekovm.org
Comments and Questions are welcome,
Nicolas
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30190
Norman Ramsey asked and Jacques Garrigue answered:
> I wish to define an abbreviation for the following type:
>
> [> `Nil
> | `Number of float
> | `String of string
> | `Function of func
> | `Table of table
> ]
>
> I am assuming that the underlying machinery involves something like
> row polymorphism, but I don't know how to name the 'row variable'.
> I tried
>
> type 'a t = ['a
> | `Nil
> | `Number of float
> | `String of string
> | `Function of func
> | `Table of table
> ]
>
> but this suggestion was roundly rejected by the compiler.
>
> Does anybody know how to do this? I couldn't find anything in the
> syntax for polymorphic-variant type expressions.
You can write
type 'a t = 'a constraint 'a =
[> `Nil
| `Number of float
| `String of string
| `Function of func
| `Table of table ]
But it seems simpler to write
type t =
[ `Nil
| `Number of float
| `String of string
| `Function of func
| `Table of table ]
and use it as [< t] where needed.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30191
Norman Ramsey asked and Jacques Garrigue answered:
> I'm trying to write a small, extensible interpreter, and I'd like to
> use polymorphic variants as the extension mechanism. But I'm getting
> stuck on very simple things. For example, I would like the value type
> to include a few simple values, but I would also like it to be
> extensible, thus:
>
> type value = [ `Nil
> | `Number of float
> | `String of string
> | `Function of [>value] list -> [>value]
> | `Table of ([>value], [>value]) Hashtbl.t
> ]
>
> However, when I do this, the compiler complains that
>
> The type constructor value is not yet completely defined
>
> Is there some way to define a recursive, *extensible* type using
> polymorphic variants?
Have a look at "Private rows: abstracting the unnamed" and
"Code reuse through polymorphic variants" at
http://www.math.nagoya-u.ac.jp/~garrigue/papers/
They both give examples of how to define extensible languages using
polymorphic variants. The first one relies on an experimental feature
only available in the CVS version of ocaml.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30194
Later in this thread, Jonathan Roewen asked:
Anyways, all that aside, I've been working on test-cases some more,
eliminating code that could possibly be getting in the way, and have
now:
let start_ocaml_os gfx_mode =
Thread.thread_initialize ();
ignore (Thread.create
(fun () -> while true do Console.printf "argh..."; Thread.yield (); done)
()
);
ignore (Thread.create
(fun () -> while true do Console.printf "boo!"; Thread.yield (); done)
()
);
Console.launch (); (* this just clears the screen pretty much, not
needed atm *)
while true do (*Gc.full_major ();*) Thread.yield () done;
"start_ocaml_os" is the entry point to the ocaml kernel. The only
other ocaml code run before this point is during initialising the
ocaml runtime.
What happens is that with Gc.full_major() commented, the system
quickly falls over and dies (strange lockup, which apparently is
somewhere inside GC runtime code -- noted in previous email). If I
uncomment, the system runs flawlessly, my two ocaml threads going nuts
printing to the console. Left it running for around 5minutes before I
got truly bored and convinced it wasn't going to fall over like
before.
So, this proves that this is a GC issue, but I have no idea where to
begin. I followed the win32 systhreads implementation fairly closely,
including hints for GC that win32 code uses. (BTW, I found the posix
version a bit harder to consider implementing with the use of
condition variables, which is why I chose the win32 implementation).
Can some threading and/or GC expert have a decent look at my code
please? Again, URL to current code:
http://moonbeam.purevoid.org/~jonathan/ocaml/ , and svn repo:
http://glek.net/subversion/os/kernel/
Xavier Leroy answered:
> It appears (with the help of a friend good with a debugger) that
> there's something going wrong with my code, and how it's interacting
> with the GC.
Please don't get offended by what I'm going to say, but I have the
feeling that you're attacking extremely hard problems without adequate
debugging tools and without enough understanding of the OCaml runtime
system.
I'll try to provide some explanations nonetheless, but please don't
bombard this list with too many cries for help.
What the debugging session shows is a problem with return address
determination during the stack scanning performed by the GC. To find
heap pointers contained in the stack, the GC scans it one frame at a
time, using compiler-generated frame descriptors to locate the
pointers. The frame descriptors are keyed to the return address in
the Caml code through a hash table (variable frame_descriptors, hash table
lookup at lines 135-141 and 249-255 in file asmrun/roots.c).
Your run appears to be looping in the hash table lookup, indicating
that 1- the return address being looked up (variable retaddr) is not
in the table (this should never happen in normal operation), and 2-
your environment lets you dereference the NULL pointer without
crashing (bad idea!).
A good way to debug this is to print the value of the "retaddr" local
variable at lines 134 and 249 in asmrun/roots.c and correlate it with your
disassembly. It should always refer to code addresses immediately
following a "call camlModule__function" or a "call caml_call_gc"
instruction. While you're at it, print also the "sp" variable: it
should stay within the stack of a thread. The problem is likely to
come from wrong values of the bottom_of_stack and last_return_address
starting points for the stack walk.
Your second test (Gc.full_major() in the main thread) further suggests
that the problem does not occur if the main thread is the one calling
the GC. Try to put Gc.full_major() in another thread to see what
happens. That could narrow the problem to the saving and restoring of
caml_bottom_of_stack and caml_last_return_address globals during
context switches.
Finally, notice that your stacks are tiny (4096 words???). Unless
they are protected by guard pages, expect a lot of trouble when they
overflow (they will).
Julien Verlaguet added:
I have been writing a cooperative thread system for ocaml, it only
works on linux and macosx though ...
you can find it at http://www.pps.jussieu.fr/~emmanuel/Public/Dev/HirondML/
I am giving you this link because I have had the same type of problems
at a time, it gave me a lot of headackes and sleepless nights ... so I
hope this will help
two little notes :
Ignore the thread migration mechanism if you are only interested in
the thread system
Do not expect nice code, the C code is full of hacks and disgusting
things that I don't understand myself anymore
I hope this helps ...
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30211
Jacques Carette asked:
Are there known issues with compilation speed of heavily functorized
code? My code used to use a lot of records, but that was not very
extensible, so I switched to using modules and functors. Now the
compilation time has gone from << 1 second to 5-6 seconds (on my slow
laptop). While not the end of the world, this still surprised me. Are
there known issues in this area? Known pitfalls and work-arounds?
The actual codes are in MetaOCaml, but I did some experiments in pure
Ocaml and got the same results, so it is not due to MetaOCaml (sorry,
these are no longer available). The curious can look at
http://www.metaocaml.org/examples/gausselim/
for record-based code and
http://www.cas.mcmaster.ca/~carette/metamonads/
for functor-based code.
Christian Lindig answered:
At least the Lua-ML interpreter is another example.
http://www.cminusminus.org/rsync/dist/
http://www.cminusminus.org/rsync/qc--/lua/
http://www.cminusminus.org/rsync/qc--/lua/lualib.nw
The construction of the interpreter is discussed in these papers:
http://www.eecs.harvard.edu/~nr/pubs/embed-abstract.html
http://www.eecs.harvard.edu/~nr/pubs/mania-abstract.html
Module lualib.nw links together the library for the interpeter and uses
heavily functorized code. It takes also several seconds to compile this
otherwise small module.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30215
David Mentre announced:
I've just released ocamlscript 1.0. ocamlscript is the very very small
implementation of a simple idea: write shell-like scripts on a Unix
system but in OCaml and optimized for speed.
For example, you can have a file with following content:
--start execute-n-times--
#!./ocamlscript unix.cmxa
let times = int_of_string (Sys.argv.(1))
let program = Sys.argv.(2)
let _ =
for i = 1 to times do
ignore(Unix.system program)
done;
exit 0
--end execute-n-times--
And execute this script as:
./execute-n-times 10 'echo Hello world!'
When this script is executed ("./execute-n-times"), the first time it is
compiled into native code ("./execute-n-times.opt") and then
executed. At second execution, the native code is executed
immediately. Of course, if the original script is modified, the native
code version is automatically recompiled.
A nice project (and from where the original idea of ocamlscript comes
from) would be to do a Linux distribution where all usual shell scripts
are replaced by ocamlscript scripts. I probably won't do it. ;)
Source: http://www.linux-france.org/~dmentre/code/ocamlscript-1.0.tar.gz
License: Public Domain
Have fun! ;)
Geoffrey Washburn asked and David Mentre answered:
> How does this differ from CasH (http://pauillac.inria.fr/cash/)? I've
> actually been writing a number of my shell scripts with it recently.
It's been a long time that I haven't looked at Bruno's work but as far
as I remember, cash tries to provide all the facilities of a shell,
like program control, redirections, etc.
My program is much more simple: it only takes as input regular OCaml programs.
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.