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/30141Damien 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 moduleAleksey 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/30159Matt 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/30166Michael 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/30177Nicolas 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/30190Norman 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/30191Norman 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/30194Later 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/30211Jacques 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/30215David 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).
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.