Hello
Here is the latest Caml Weekly News, for the week of 28 December 2004 to 04 January 2005.
Happy New Year to everyone.
Archive: http://caml.inria.fr/archives/200412/msg00344.html
SooHyoung Oh asked:
Is there anyone who has ever tried to compile ocaml on .NET environment?
I can find lots of infomation from the ocaml-mailing list:
Mono project: http://www.mono-project.com/about/index.html
F#: http://research.microsoft.com/projects/ilx/fsharp.aspx
sml.net: http://www.cl.cam.ac.uk/Research/TSG/SMLNET/
Nemerle: http://nemerle.org/
John Goerzen's message: http://caml.inria.fr/archives/200408/msg00424.html
After some test on F#, my feeling is that it's not so good as Ocaml.
So I'm looking for Ocaml implementation on .NET environment.
(Interoperability is not my concern.)
There is a message that because the type system of Ocaml is so complex
that it's not easy to make Ocaml.net. But I think it's not so difficult
to compile Ocaml on .NET, is it?
Tom Hirschowitz suggested:
What about this work by Raphael Montelatici and others?
http://www.pps.jussieu.fr/~montela/
Richard Jones also answered:
One possibility is running .NET code on the Mono VM, embedded in an
OCaml process. It seems like it should be possible, although the
specifics of how the two garbage collectors might behave together is
unclear.
http://www.go-mono.com/embedded-api.html
Archive: http://caml.inria.fr/archives/200412/msg00327.html
Romildo asked and Jørgen Hermanrud Fjeld suggested:
> Is there a library that implements a parser
> for configuration files similar to the *.ini
> files from windows? For instance:
>
> [section 1]
> key1 = value1
> key2 = value2
>
> [section 2]
> key3 = value3
> key4 = value4
> key5 = value5
May I suggest ConfigParser from missinglib:
http://gopher.quux.org:70/devel/missinglib/html/ConfigParser.html
Archive: http://caml.inria.fr/archives/200412/msg00365.html
Anastasia Gornostaeva asked and John Skaller answered:
> Is it possible to compile such files?
>
> mod1.ml:
> let get a =
> if Mod2.mem a then 1 else 2
>
> mod2.ml:
> let mem a = List.mem a [1;2;3]
> let other () =
> print_int (Mod1.get 5)
No. There is a new experimental feature which provides
some support for intra-module recursion,
but at present the modules must reside
in the same file.
The two common workaround for functions are:
(a) pass Mod2.get to Mod1.get as an argument
(b) create a reference in mod1.ml initialised to
fun (x:int) -> raise Not_found; 1
and in mod2.ml store Mod2.get into it, call it in mod1.ml
by first dereferencing it.
Another technique is to use classes, which automate
the late binding more safely.
Archive: http://caml.inria.fr/archives/200412/msg00370.html
James Woodyatt announced:
Today, the OCaml Network Application Environment (NAE) has released
maintenance updates of two of its published libraries. As its project
page on SourceForge.Net says, OCaml NAE is "a collection of Objective
Caml libraries to support the development of concurrent,
single-threaded Internet application servers."
For downloads and more information, please see:
http://sf.net/projects/ocnae/
The two libraries updated in this release are the Core Foundation (Cf)
and the Reactive I/O Monad (Iom). The Cf library was formerly known as
the Pagoda Core Foundation. The complete CHANGES records for both
libraries since their previous releases follows below.
===== OCaml NAE Core Foundation (cf) library =====
===== Version 0.5 =====
Highlights of the changes:
+ Many bugs fixed (some critical).
+ IPv6 socket addresses are now a triple, containing the scope
identifier.
+ Fixed a very bad stack leak problem in the [Cf_gadget] scheduler.
--- [Cf_deque]
Fix major bug in [fold] that caused a BUS ERROR (ack!), and also fixed
[filter] so that it uses the non-recursive [fold] function here instead of
going to the extra work of using [Cf_seq.fold].
--- [Cf_rbtree]
Fix a bug in [iterate] (found by Craig Falls; thanks Craig!) caused by a
stoopid typo. Caused some elements to be iterated twice, and others not
at all.
--- [Cf_gadget]
Moderate surgery on the scheduler to fix a bad stack leak. The new code
is probably a tiny bit more efficient too, because I got rid of some
unnecessary uses of {Lazy.t} in places, and there is a bit less lifting
between monads. I didn't benchmark it, though.
--- [Cf_socket]
Added a special case for Mac OS X to work around a bug in Apple's network
stack that errors in connect(2) on a non-blocking socket do not get in the
errno system variable. You have to get them out of the socket with the
SO_ERROR socket option.
--- [Cf_ip4_addr]
Make the network subnet manipulation functions cope with networks that are
not unicast networks. (Yes, there are multicast ranges that can be
treated like subnets.)
--- [Cf_ip6_proto]
Add a third element to the socket address type: an int32 for the scope id.
--- [Cf_ip6_addr]
Fix the [v4compat] and [v4mapped] address type tags so that they are
actually polymorphic variants, like they're supposed to be. This was
another stoopid typo, but I found it myself.
--- [Cf_netif]
Fixed the C-language code to call if_nametoindex() with the proper
arguments. Again, this was a stoopid typo.
--- [Cf_poll]
A minor change to the commented bits of debugging code in the middle of
the select loop to use [Cf_journal] instead of my [xprintf] hackery.
--- {TESTS}
Added a test for the [Cf_gadget] scheduler to detect stack leaks.
===== OCaml NAE Reactive I/O Monad (iom) library =====
===== Version 0.1 =====
Highlights of this release:
+ Rewrote the [Iom_sock_stream.endpoint] reactor to fix bugs (and
hopefully improve performance in some edge cases).
+ More optional tests coded (but they're still suboptimal, and maybe
buggy).
--- [Iom_sock_stream]
Rewrote the [endpoint] reactor to use less consing, i.e. the state is now
a couple of mutable objects derived from [Cf_poll.event]. Events are
plumbed around the inside of the reactor in shorter paths.
--- [T_iom]
Change to be compatible with cf-0.5 notion of IPv6 socket addresses, which
now contain an int32 element for the scope identifier.
--- {New Tests}
Added a couple of new programs which help me work out bugs. I don't think
these programs are really done, since they don't quite give me the control
I need to be able to adequately test and benchmark the performance of code
based on the [Iom] library. I'll probably need to hammer on these for a
while before I have something to document. In the meantime, consider them
curiosities for your amusement.
Archive: http://caml.inria.fr/archives/200501/msg00008.html
Don Syme announced:
On behalf of those at Microsoft Research, Cambridge, I would like to announce
that applications for intern positions at our lab for 2005 are now being
accepted. Our lab has a number of groups, but of particular interest may be
the Distributed Systems group (http://research.microsoft.com/camdis/), the
Programming Principles and Tools group (http://research.microsoft.com/ppt/) and
the Security group (http://research.microsoft.com/security/) For myself I am
particularly interested in applications for projects related to type systems,
virtual machines and/or aspects of language design and implementation related
to .NET, ML and F# (http://research.microsoft.com/projects/fsharp). Specific
interests of other researchers are detailed on their home pages, and in general
you should consider discussing potential projects with a specific researcher
soon after applying.
Cambridge is a great place to work, and Internships normally last 12 weeks and
most commonly occur over the summer. Applicants should be graduate students on
PhD programs.
For summer 2005 Internships, the deadline for complete applications is 28th
February 2005, and references have to be received by this date. The admission
process is quite competitive, and we encourage applications in good time before
the deadline. We aim to notify candidates of the outcome of their applications
by the end of April 2005.
Full details and application forms can be found at the following link:
http://research.microsoft.com/aboutmsr/jobs/internships/cambridge.aspx
In addition, we are always open to applications for a smaller number of
post-doctoral positions. Full details can be found at
http://research.microsoft.com/aboutmsr/jobs/cambridgepostdoc.aspx
Archive: http://caml.inria.fr/archives/200412/msg00368.html
Mary Fernandez asked and Jacques Garrigue answered:
> I have a question regarding the ./configure options for MacOS/Darwin.
>
> ./configure selects the -bundle option for MKSHAREDLIB, which
> has the effect of creating MacOS bundle type files for the dynamically
> linked libraries in lib/ocaml/stublibs. I have had trouble linking
> these bundle files with the standard dynamically linked libraries
> created with the -dynamiclib option. As an experiment, I replaced
> -bundle by -dynamiclib and attempted to rebuild the O'Caml compiler,
> but got an error deep in compilation of the compiler. Ultimately,
> I just made the otherlibs/* libraries by hand with -dynamiclib and was
> able to link my application.
>
> I will admit that I am overwhelmed by the Darwin documentation
> that explains how to port a Linux application to MacOS.
> Can someone explain why the -bundle option is necessary to the compiler
> compilation?
> Is it because the O'Caml compiler a full-fledged Mac application?
Could you explain exactly what you are trying to do?
The dlls in stublibs are only intended to be dynamically loaded by an
ocaml application. The reason bundles are used rather than dynamic
libraries is that the API for bundles is simpler, and that their
explicit intent (plugins) seems close enough to the use of dlls in
ocaml.
Note that a bundle can depend on dynamic libraries, so this should not
induce other limitations.
Mary Fernandez replied:
Thanks for your message. Here is what I am trying to do.
My O'Caml application is an XQuery engine. It has three
APIs: one for O'Caml, one for C, and one for Java applications.
We create a native-code, dynamically linked
C library that includes our O'Caml library, the O'Caml runtime,
and several other C libraries that our application depends upon
the unix, nums, str libraries plus an external PCRE library.
We actually do this by hand with ocamlopt (not ocamlmklib)
because in the past, we found ocamlmklib did not work consistently
on all platforms.
What I have found is that if the dll*.so libraries are Mac bundle
files, then I get a linking error of the form
"...ld: /Users/mff/ocaml-3.08.2/lib/ocaml/stublibs/libstr.dylib is input
for the dynamic link editor, is not relocatable by the static link
editor again..."
(Note that the default name of dllstr.so is not recognized by the
Darwin linker). If I re-compile the otherlibs/ in stublibs/
to be dynamically linked libraries, then I have no problems.
Also, if I just use the archive files, that works too -- but
I typically use O'Caml with dynamic libs enabled which is how
I tripped over this problem.
We only create a dynamically linked library, because
our Java library call the C library, and the Java JNI requires
dynamically linked C libraries.
So, in short, I have something that works, but still dont'
understand why bundles and dynamically linked libraries caused
me trouble.
Jacques Garrigue answered:
> My O'Caml application is an XQuery engine. It has three
> APIs: one for O'Caml, one for C, and one for Java applications.
>
> We create a native-code, dynamically linked
> C library that includes our O'Caml library, the O'Caml runtime,
> and several other C libraries that our application depends upon
> the unix, nums, str libraries plus an external PCRE library.
> We actually do this by hand with ocamlopt (not ocamlmklib)
> because in the past, we found ocamlmklib did not work consistently
> on all platforms.
To be more precise, ocamlmklib produces two kinds of output: a DLL for
dynamic loading in bytecode programs, and a static library for custom
and native programs.
What you seem to want is a dynamic library to link with native
programs, which is out of the specification.
On most architectures, the DLL can be used as a dynamic library, but
this is not true on darwin, and only partly true on windows (you also
need a binding library, which is not kept.)
If your concern is darwin, then there is a simple answer: you can just
get the installed static library, and turn it into a dynamic library,
as all C code on darwin is position independent. Just look for the
correct linker incantation in the darwin manual.
It's better not to try to meddle with the core ocaml compilation,
which has different goals in mind.
Jacques Garrigue then added:
In case you could not find it, here is the incantation:
ld -dylib -all_load -flat_namespace -undefined suppress
/usr/local/lib/ocaml/libunix.a -ldylib1.o -o libunix.dylib
You can also link all these libraries directly in your dynamic linked
C library, without creating individual dlls (but this works only for
platforms such as darwin, where all code is position independent).
Archive: http://caml.inria.fr/archives/200501/msg00021.html
Thomas Fischbacher announced:
Ladies and Gentlemen,
a happy new year to all readers of this list.
For a non-mainstream language like Ocaml, it is evidently of great
importance to have good answers to the question about its practical
relevance. It seems as if we now have another nice application to add to
the list: in today's official arxiv.org listing, the following
preprint paper (by myself and two colleagues from the Albert Einstein
Institute) appeared:
http://www.arxiv.org/abs/hep-th/0412331
Physically speaking, one of the hot topics in string theory today is the
conjectured equivalence of certain quantum field theories which neither at
the classical level nor as quantum theories have an intrinsic length scale
on the one side - so-called conformal field theories - and string theory
on a space-time which approaches constant negative curvature at infinity
(i.e. anti deSitter space) - see e.g.
http://www.phys.lsu.edu/mog/mog18/node10.html
What we did was to provide further strong evidence that the physical key
property of integrability holds, however another important property known
as BMN scaling (sorry, I cannot go into details) is violated in
quite non-obvious ways.
Computationally, what we had to do in order to achieve this result was to
develop a fast algorithm which furthermore can be implemented close to the
machine level that allows us to sum literally billions of contributions
from different planar feynman graphs with four loops in them. Planarity is
the key property here that makes this calculation feasible - if we
included the non-planar graphs as well, we would have had to deal with an
estimated number of contributions of about half a quadrillion.
At the much simpler three loop level, our approach is faster than
previous ones (using the FORM program which was built explicitly for fast
quantum field theoretic calculations) by about a factor of 100. This comes
in part from our improved algorithm that singles out planar graphs (and
hence scales much better than algorithms which do not), in part from
doing term transformations not in an interpreted fashion, but
directly at machine code level (via compiled ocaml), furthermore from
carefully ensuring not to do unnecessary work when simplifying terms,
from evil hacks (such as abusing the FPU to do exact(!) fraction
arithmetics for fractions of the form <small numerator>/<small power of 2>),
and - quite important - from certain algorithmic tricks from the
functional programmer's toolbox such as continuation coding and lazy
evaluation. In other words, it would not at all have been possible
in anything else but a fast compiled functional language. Nevertheless,
we still had to burn 88 000+ CPU-hours on 2 GHz Athlon (and Opteron)
hardware to do the largest piece of the calculation and we are very
grateful towards our numerical colleagues for providing us with
appropriate resources - this is true symbolic supercomputing.
While we (the authors) are not yet sure about this, we think to have
strong reason to believe that this may be the (presumably by orders of
magnitude) largest symbolic algebra calculation performed so far -
counting the number of term transformations. (Excluding cypher breaking
and prime search attempts, as the underlying questions hardly can be
regarded as of symbolic nature.) We know that there have been quite large
four-loop QCD calculations before involving something like 50 000
individual graphs that furthermore had to deal with some transformations
on integrals (which we do not have, due to a certain kind of reduction we
perform in our model) and hence are somewhat more difficult to calculate
than our graphs - but certainly not by a factor of 100 000. If anyone
knows better and can tell us about an even larger symbolic calculation, we
would be glad to hear about it.
While our paper is essentially for physicists, it features a
self-contained appendix explaining the algorithmic and implementation
aspects of our work that should be readable especially for people with a
computer science background. Furthermore, one can download (details in the
paper) our source. Unfortunately, in order to actually build the program,
one needs a somewhat large development environment, as some of the ocaml
source and data files are machine generated by perl and CMU Common Lisp.
Admittedly, the code could be cleaner, but one should keep in mind here
a few external factors (i.e. pressure to publish new physical
results) which are different for computer scientists and physicists.
Well, it's not as bad as quite a lot of code in physics, and I
think I can show it around without having to pull a brown paper bag over
my head, but the style is certainly not one I'd like to see in textbooks.
Given the time (which I at present do not have), I'd like to clean it up
a bit more.
Archive: http://caml.inria.fr/archives/200501/msg00015.html
Anastasia Gornostaeva asked and SooHyoung Oh answered:
> Does exist Timer module, that allows me add/reset/remove timed events?
> Currently I use Unix.setitimer() for my simple implementation that allows
> only adding new events into a queue, but my skills is not enough to implement
> reset and remove events from the Timer queue.
> And I'm not sure if using Unix.sleep() with setitimer() is safely (without
> Threads).
I have one at http://pllab.kaist.ac.kr/~shoh/ocaml/libs/timer/ .
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.