Hello

Here is the latest Caml Weekly News, for the week of 17 to 24 May, 2005.

1. Job Offer at INRIA / AOSTE Team
2. Mana 0.0.2
3. bug fix to 64 bit SPARC code generator
4. OCaml SimpleSOAP 0.1.1 released
5. ocamlopt and *using* DLLs

Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/05/11606a0aa656fdaf1c0f0d99fc8293b6.en.html

The AOSTE Team at INRIA Rocquencourt is looking for an engineer with a
solid experience in OCaml programming to maintain and improve SynDEx, a
system-level CAD software consisting of approximately 20.000 lines of
OCaml code.  For more information on SynDEx, please visit
http://www.syndex.org/

The contract is a one year contract, and is renewable once.  A knowledge
of real-time embedded systems would be appreciated, but is not a
requirement.

For more details, the job offer (in French) is here:

http://www.syndex.org/jobs/ODLSyndex.htm

You can get a roughly translated version (using Google) via the
following URL:

http://translate.google.com/translate?u=http%3A%2F%2Fwww.syndex.org%2Fjobs%2FODLSyndex.htm&langpair=fr%7Cen

Please send a resume by email to Yves Sorel <yves.sorel@inria.fr>.
    

Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/05/c5385095b48c488bf80d7ab7cbe6f014.en.html

I'm pleased to announce mana-0.0.2, a Japanese input engine based on
a hidden Markovian model.  It is more accurate than previously used
engines, in particular for the case of long input.

Mana is written C and OCaml.  Currently, Emacs interface using Egg is
provided.

The project page is
http://sourceforge.jp/projects/shinji/
(Unfortunately, English page is still missing.)

Any opinions, suggestiona and contributions are appreciated.
    

Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/05/348d1df3a9d23cfd580e425405a518a2.en.html

I found a bug in my SPARC code generator: multiplication by constant 0
could give the wrong answer.  Few people explicitly write x*0 but it
can be generated internally by function inlining.  A new version with
the bug fixed, dated May 22 2005 GMT (the previous evening EDT), is
available at:

http://www.mit.edu/~jfc/ocaml-3.08.3-sparc64.tar.gz
    

Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/05/7dd4baaa9251ab90a80b0e935bbdf51c.en.html

I'm pleased to announce the release of version 0.1.1 of the simple,
experimental SOAP client library written in pure 100% OCaml.  The
library is released under the GNU LGPL with OCaml linking exception.

http://merjis.com/developers/simplesoap
http://merjis.com/_file/simplesoap-doc.html

Development continues rapidly.  This version has a limited
understanding of XML Schema datatypes so it can parse responses from
the server which have been encoded, for example in base-64.  It comes
with a more extensive test suite and regression tests.  We have used
it sucessfully against several SOAP::Lite servers and a Java
AXIS-based server.  We now set SOAPAction HTTP headers correctly and
SOAP can be used in direct or proxy mode, even over SSL.  It comes
with several example programs.

To run this release you will need:

        - Extlib
                http://ocaml-lib.sourceforge.net/
        - Marcus Mottl's ocaml-pcre
                http://ocaml.info/ocaml_sources/
        - Gerd Stolpmann's equeue
                http://www.ocaml-programming.de/programming/equeue.html
        - Gerd's ocamlnet
                http://www.ocaml-programming.de/programming/ocamlnet.html
        - Gerd's PXP (XML parser)
                http://www.ocaml-programming.de/programming/pxp.html

        - Perl and SOAP::Lite if you want to run examples and tests.
    

Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/05/a36fd4aef9cd201c1ad33f6b4cda255d.en.html

> I tried this on the beginners list, but may not have been asking the 
> right question(s)... :)

Doesn't look like a beginner question...

> 1) Can DLLs appear as input to the ocamlopt compiler like they can 
> with ocamlc?  The manual says "yes": "Arguments ending in .o, .a or 
> .so (.obj, .lib and .dll under Windows) are assumed to be C object 
> files and libraries. They are linked with the program."
> 
> I get "ocamlopt.opt: don't know what to do with ml_scintilla.dll."

Indeed, looking at the sources, .so/.dll is only handled in ocamlc,
not in ocamlopt.
That means that, in ocamlopt, you must either provide a static
library, or use the -cclib option and hope that the system linker does
the right thing. In practice, -cclib ml_scintilla.so should work on
Unix, but the .dll equivalent is not going to work on Windows, as the
linker does not support it.

> 2) If DLLs can in fact be used with ocamlopt, is the model the same as 
> with ocamlc?  In particular,
> 
> 2a) can I use them *without* stub libraries?

If by stub you mean the ml_scintilla.lib that the windows librarian
builds for you, then you will need it with ocamlopt (but not with
ocamlc).
Of course in both cases you also need an ocaml specific stub library
to wrap calls.

> 2b) can I in general expect that an app that works well with ocamlc 
> and a collection of OCaml cma libs and compiled DLLs (LablGTK and 
> associated runtime) will work with ocamlopt - assuming that I generate 
> and replace cmo/cma files with cmx/cmxa files?

Except these linking problems, you can assume identical behaviour.
If there are significant discrepancies, please report them.
    

I was not maybe clear enough on the beginner list :)
The main problem is that your DLL need to call Ocaml API, which it is linked
with.

In bytecode there is no problem since the whole API is inside ocamlrun.dll
so your DLL and ocamlrun.exe will simply use this API dll together.
In native compilation however there is no more ocamlrun.dll, since the API
is staticly linked into your executable. That means that your DLL that was
working in bytecode will load ocamlrun.dll and call it while your executable
is calling staticly linked API. This will result quite quickly in a crash
since ocamlrun.dll is not initialized correctly.

The only possible way to get the DLL working is to patch it so it loads its
API inside your.exe and not inside ocamlrun.dll. But then you will need a
different version of the DLL for each application (!). It would be nice if
OCaml could provide the equivalent of ocamlrun.dll for the native
compilation mode.
    

> Actually, it looks like Nicolas brings up a large conceptual difference... I
> was at first tempted to say that his points about ocamlrun.dll did not apply to
> my case, but then I realized that my DLL, while primarily concerned with
> interfacing between OCaml and the C-land Scintilla editing widget, does in fact
> call on the OCaml runtime for things like string and tuple allocation.
> 
> Put a different way, ml_scintilla.dll definitely has a dependence on
> ocamlrun.dll - which logical need would not go away even if I repackaged the
> DLL as a static lib.
> 
> So, where (in both a conceptual as well as linking-specific terms) do I find
> the hooks (caml_alloc_string, caml_alloc_tuple, caml_named_value etc) into the
> OCaml runtime when it is embedded in my ocamlopt-generated executable?

Actually the symbols are only imported from ocamlrun.dll if you compile-with
or define the CAML_DLL preprocessor variable.
If you don't have CAML_DLL defined, symbols will be resolved at linking
time, and will then be found in your executable.
So it's possible to have a staticly linked library in both bytecode
(with -custom) and nativecode.

You can have a look at the OCaml Win32 API library Makefile that have
different ways of building and linking it
(http://ocaml-win32.sourceforge.net/).
    

Using folding to read the cwn in vim 6+

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.

Old cwn

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.

Alan Schmitt