Hello
Here is the latest Caml Weekly News, for the week of September 18 to 25, 2007.
Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/c0bb621b9d3c91ad/34ffa30420633f18
Continuing the thread from last week, Erik de Castro Lopo said:
What wasn't mentioned in this announcement was the existance of a
mailing list. I posted to the mailing list:
http://sourceforge.net/mailarchive/forum.php?forum_name=cothreads-discuss
but I suspect that I may be the only person on the list :-).
Vu Ngoc San asked and Zheng Li answered:> this looks like something I'd be very happy to use. Have you tried compiling > lablgtk2 with it ? > (so that I could get rid of the following:) > [ > The files /usr/lib/ocaml/3.10.0/process/thread.cmi > and /usr/lib/ocaml/3.10.0/lablgtk2/gtkThread.cmi > make inconsistent assumptions over interface Thread > ] I'm not sure what you're trying to do, but the reason of error seems obvious: lablgtk2 seems to have been compiled with the Thread module of system threads or VM thread (both come with OCaml's standard distribution), while you're linking them with other modules compiled against the Thread module of process engine. The Thread module interfaces from the three engines differ with each other! Note that this is not the problem from coThreads, it's a problem of standard Threads library: - The Thread interfaces of system threads and VM threads coming with the standard distribution *already* differ with each other, so that the objects compiled with system Thread won't be able to mix with objects compiled with VM thread, vice versa. (The problem is the same as in your case) - We have no way to unify the three of them without modifying the files from original distribution, which is exactly what we manage to avoid. On the other hand, the Cothread module (a super set of the Thread interface) is provided to achieve object-level compatibility, so that the objects compiled with different engines can mix. All other modules from Threads and coThreads, e.g. Mutex, Event, don't have this problem. You'd like to read the compatibility page for more explanation: http://cothreads.sourceforge.net/doc/compatibilityskaller asked and Zheng Li answered:
First note that the naming convention follows the standard threads library in OCaml: Threads and coThreads (both with 's') refer to the library (*.cm(x)a); Thread and Cothread (neither with 's') are modules (*.cm[ox]) inside. > > The Thread module interfaces from the three engines differ with each > > other! Note that this is not the problem from coThreads, it's a problem of > > standard Threads library: > Why don't you just use a different module name? The different module name *is* Cothread, a compatible super set of Thread module. Use this module instead if you want to have object-level compatibility. In short, all the three engines have the two libraries with isomorphic structures (quite simple) : <code> threads.cm(x)a = threads.cm[ox], mutex.cm[ox], condition.cm[ox], event.cm[ox] cothreads.cm(x)a = threads.cm[ox], mutex.cm[ox], condition.cm[ox], event.cm[ox], cothread.cm[ox], stm.cm[ox] </code> See, we also provide the compatible "threads.cm(x)a" for the process engine. Think about the following scenario: - If you're working on legacy code, you don't care STM and don't care object-level compatibility, the only thing you're interested is to running your code with process to speedup, then the only thing to change in your Makefile is the include path e.g. "-I +threads" -> "-I +process", you can still using Thread module and "threads.cma", they are present in process engine. - You have several projects, some of them using traditional Threads, some using coThreads, you don't want to bother to remember that. So simply changing all linking library from threads.cma to cothreads.cma is fine, because coThreads library contains every modules in Threads library. - You have some legacy code written in standard Threads, and you'd like to have it run with processes. Though you don't care about the newly introduced modules of coThreads, you do want to have a single copy of object files for each engines. In such case, you need to add one line to any source code which makes use of the Thread module: module Thread = Cothread because Thread module (the only module in Threads and coThreads) don't have object-level compatibility, and change any occurrence of “threads.cm(x)a” to “cothreads.cm(x)a” in your Makefile. For more explanation, see http://cothreads.sourceforge.net/doc/compatibility
Here is a little patch to get access to stack traces inside a running program, for use with long-running servers. It is like Markus Mottl's patch but uses the standard backtrace mechanism. It works with both bytecode and native code. Patch and instructions here: http://skydeck.com/blog/programming/stack-traces-in-ocaml/ I hope that you find it useful.
We are considering to remove ocamldbi [1] from Debian for various reasons (upstream development idle for some time, not yet ported to sqlite3, popcon score quite low). Before doing so however we are trying to figure out how many users are still using it by other means than popcon. So, here it goes, if someone here is actively using ocamldbi (preferably on Debian but not strictly necessary) can she please send me a private mail stating so? Even mails stating thinks like «I was using it but I stopped doing so for this and that ...» would help. Many thanks in advance, Cheers. [1] http://cvs.savannah.gnu.org/viewvc/modcaml/ocamldbi/
Dans le cadre d'une startup en cours de constitution, nous recherchons une personne compétente en TAO (Traduction Assistée par Ordinateur) et en Ocaml. Elle devra être ne mesure de mener à terme un projet de création d'un service Internet d'aide à la traduction utilisant OcamlDuce, et Ocsigen. En plus des compétences requises (dans les grammaires et l'analyse des langues naturelles), pour la réalisation des traducteurs "langue native <-> pivot linguistique", elle devra être capable de maintenir et poursuivre les travaux d'Alain Frisch réalisés dans OcamlDuce. Je me tiens à votre disposition pour tous compléments d'information sur ce projet pour lequel nous souhaitons regrouper les meilleurs talents.
This is to announce the release of the OCaml Network Application
Environment (OCaml NAE) Core Foundation library version 0.9 (cf-0.9).
Download the source and ocamldoc output from the project page on
SourceForge:
http://sourceforge.net/projects/ocnae
This is a maintenance release to fix bugs and improve compatibility
with OCaml-3.10.0.
===== OCaml NAE Core Foundation (cf) library =====
This distribution is the Objective Caml Network Application
Environment (NAE)
Core Foundation library, which is a collection of miscellaneous
extensions to
the Objective Caml standard library.
Highlighted features include:
- Functional streams and stream processors (extended).
- Functional bootstrapped skew-binomial heap.
- Functional red-black binary tree (associative array).
- Functional sets based on red-black binary tree.
- Functional real-time catenable deque.
- Functional LL(x) parsing using state-exception monad.
- Functional lazy deterministic finite automaton (DFA).
- Functional lexical analyzer (using lazy DFA and monadic parser).
- Functional substring list manipulation (message buffer chains).
- Gregorian calendar date manipulation.
- Standard time manipulation.
- System time in Temps Atomique International (TAI).
- Unicode transcoding.
- Universal resource identifier (URI) manipulation.
Additionally, the following noteworthy features are provided for
compatibility
with earlier versions of this library. Further developments to these
features
are expected to move to a new, separate [Nx] library. These features
are not
expected to improve in the [Cf] library for the version 0.x series,
and they
will be removed in the 1.x series.
- Extended socket interface (supports more options, and UDP w/
multicast).
- I/O event multiplexing (with Unix.select).
Note: see the ISSUES file for a list of open problems in this release.
===== Version 0.9 =====
Highlights of the changes:
+ Compatibility with OCaml-3.10+beta.
+ Fix bug in Cf_rbtree.nearest_(incr|decr) functions.
+ Minor performance improvement.
+ Minor bugs in tests fixed.
+ Noted that socket extensions and event multiplexing are moving to the
forthcoming Nx library.
===== Required Components =====
This library requires the following external components:
- Objective Caml (v3.10.0 or newer)
- Findlib (tested with v1.1.2p1)
Principal development was on Mac OS X 10.4 w/ XCode 2.4.1 using GCC
4.0. Other
platforms with POSIX-like environments should require a minimal
porting effort.
One major open issue: the extended socket interface is broken under
WIN32.
(The author invites help porting the library to other environments.)
JOURNAL OF FORMALIZED REASONING
http://jfr.cib.unibo.it/
ISSN: 1972-5787
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Charter and Scope:
The journal encourages submission of papers describing significant
formalization efforts in any area, including classical math,
constructive math, formal algorithms, and program verification.
The emphasis of the journal is on proof techniques and methodologies
and their impact on the formalization process. In particular, the
journal provides a forum for comparing alternative approaches,
enhancing reusability of solutions and offering a clear view of the
current state of the field.
------------------------------------------------------------------
Editorial Board:
Andrea Asperti, University of Bologna
Jeremy Avigad, Carnegie Mellon University
Michael Beeson, San Jose State University
Thierry Coquand, Chalmers University
Herman Geuvers, Radboud University
Georges Gonthier, Microsoft reasearch
John Harrison, Intel Corporation
Xavier Leroy, INRIA Paris
Cesar Munoz, NASA LaRC
Christine Paulin-Morhing, INRIA Saclay and Universite Paris-Sud
Natarajan Shankar, SRI International
Peter Sewell, University of Cambridge
Carlos Simpson, Nice University
Andrzej Trybulec, University of Bialystok
Freek Wiedijk, Radboud University
--------------------------------------------------------------------
Editorial Policy:
The Journal of Formalized Reasoning is a purely electronic publication.
The Journal provides immediate open access to its content on the
principle that making research freely available to the public supports
a greater global exchange of knowledge.
The Journal encourages the submission of interesting, insightful, and
informative papers, preferably accompanied by formal scripts. Although
the journal is not meant to become a repository for proof scripts, an
effort will be made to ensure that the "experimental data" backing
formalisation papers will remain accessible.
Each new contribution must be original, and not submitted before different
journals for consideration.
Detailed instructions can be found at the journal home page
http://jfr.cib.unibo.it/.
A new vim plugin to handle annot files is available at: http://www.vim.org/scripts/script.php?script_id=2025 Differences with previous plugins: - ocamlbuild is handled (even if you change the '_build' to another name, but cross fingers in this case) - no more need for python support, only vim inside - little bonus : handling of latin1 accents, of parenthesized expressions, lists, arrays (no need for visual mode) see details on the page.
> I would like to know if there are references on the OCaml VM other
> than
> the source code of bytecomp/byterun, I found none on the OCaml
> website.
> My aim would be to write a small compiler that would target the OCaml
> runtime systems.
While developping OCaml-Java, I had to reverse-engineer this
information.
I produced two pdf files available at http://cadmium.x9c.fr/
downloads.html :
- caml-formats.pdf describes both the marshalled data format and the
bytecode file format;
- caml-instructions.pdf describes all the instructions used by the
OCaml VM.
Hope this helps,
Xavier
PS: I would be happy to hear about every mistake you find in these
documents
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.