Here is the latest Caml Weekly News, for the week of 17 to 24 May, 2005.
Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/05/11606a0aa656fdaf1c0f0d99fc8293b6.en.htmlArnaud Rouanet announced:
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 <firstname.lastname@example.org>.
Archive: http://caml.inria.fr/pub/ml-archives/caml-list/2005/05/c5385095b48c488bf80d7ab7cbe6f014.en.htmlYamagata Yoriyuki announced:
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.htmlJohn Carr announced:
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.htmlRichard Jones announced:
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.htmlRobert Roessler asked and Jacques Garrigue answered:
> 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.Nicolas Cannasse also answered:
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.Robert Roessler then asked and Nicolas Cannasse answered:
> 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/).
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.