Here is the latest Caml Weekly News, for the week of 23 to 30 March, 2004.
I'd like to announce my preliminary bindings for libxml's XmlTextReader API for OCaml. This API is modelled on the XmlReader classes found originally in C# (I think?) and is quite convenient for some applications. This site has the download: http://neugierig.org/software/ocaml/ocaml-xmlr/ I'm still sorta new to OCaml, so any advice (even as simple as misused technology or findlib fixes) is very welcome.  http://xmlsoft.org/  http://xmlsoft.org/xmlreader.html
Richard Jones wrote: > Oliver Bandel wrote: > > I once have asked here for a library, that can be used to parse > > html-files and write cgi-scripts more easily. > > To write CGI scripts, use mod_caml - > http://www.merjis.com/developers/mod_caml/ > > You can find lots of example mod_caml scripts here to get you started: > http://www.j-london.com/dist/ > > To parse HTML files, I use perl4caml > http://www.merjis.com/developers/perl4caml/ and specifically the > Pl_HTML_Parser module which is a wrapper around Perl HTML::Parser. > You can also look at Ocamlnet (http://sourceforge.net/projects/ocamlnet) for CGI and WDialog (http://wdialog.sourceforge.net/) for a more complete system to create web applications.
I'm please to announce Perl4Caml 0.3.10, available here: http://www.merjis.com/developers/perl4caml/ This version includes a wrapper around the Template Toolkit, contributed by Dave Benjamin, and some cleanups for memory handling (although memory handling still isn't quite right, and for this reason the library doesn't free Perl objects - any help getting this right is welcomed). [From the website ...] perl4caml allows you to use Perl code within Objective CAML (OCaml), thus neatly side-stepping the old problem with OCaml which was that it lacked a comprehensive set of libraries. Well now you can use any part of CPAN in your OCaml code. perl4caml has both a low-level interface to Perl, eg: Perl.eval "$a = 3"; printf "$a contains %d\n" (Perl.int_of_sv (Perl.get_sv "a")); and it contains high-level wrappers around some CPAN libraries (more to come later), eg: open Pl_LWP_UserAgent open Pl_HTTP_Request (* Create the UserAgent object. *) let ua = Pl_LWP_UserAgent.new_ ~env_proxy:true () in (* Fetch the page. *) let req = Pl_HTTP_Request.new_ "GET" ~uri:site () in let res = ua#request req in if not res#is_success then failwith ("Error while fetching " ^ site ^ ": " ^ res#status_line);
> After quite a long hiatus when we weren't distributing packages for > mod_caml (instead everyone was chasing the CVS version), I'm pleased > to announce the availability of stable packages for the latest > OCamlDBI and mod_caml. I have also updated the ocamldoc on the website, which was getting rather out of date. You can find the browsable documentation here: http://www.merjis.com/developers/mod_caml/ http://www.merjis.com/developers/mod_caml/html/index.html http://www.merjis.com/developers/mod_caml/html-dbi/index.html
A long thread on shared libraries and dynamic linking has started this week. It began with the following message from the archive: http://caml.inria.fr/archives/200403/msg00371.html Here is one extract form this thread.Richard Jones asked and Xavier Leroy answered:
> I think this must have something to do with Dynlink. The manual > states: > > All toplevel expressions in the loaded compilation units are > evaluated. Yes, indeed. Compilation units loaded at top-level or dynamically via Dynlink are always loaded and their initialization code executed, because there is no way for the system to determine whether they'll be needed later. Static linking can determine this, and therefore removes unreferenced units from .cma libraries. J. Skaller unhelpfully suggests: > Hassle the ocaml team for generation of shared libraries? Shared libs will definitely not help here (and elsewhere). By definition, linking with a shared lib is like dynamically loading all units contained in this lib, hence no way to eliminate unneeded ones. Only static linking can do that. (As far as "hassling" goes, this will only reinforce my conviction that shared libraries are useless. So, don't do that.) Coming back to Rich Jones' problem, there are two ways to go about this: 1- Since you're dynamically loading the Caml modules anyway, couldn't you arrange so that only those you really need are loaded? 2- Instead of doing let _ = eval "use LWP::UserAgent" let somefun x y = ... you could implement on-demand evaluation of the "use" bit, e.g. let inited = ref false let init() = if not !inited then begin eval "use LWP::UserAgent"; inited := true end let somefun x y = init(); ... Every function needs to be protected by a call to init(). If you export constants and not just functions, this won't work, of course, but maybe this doesn't happen too often. A nicer way to write the above is let init = lazy (eval "use LWP::UserAgent") let somefun x y = Lazy.force init; ...
See at http://contfrac.sourceforge.net (unfortunately, I don't know how to use CVS, so you will have to download the 9ko compressed file as a whole). It performs exact arithmetic on real numbers by using continued fraction. The purpose is similar to creal and surreal, but algorithms are deeply different. I implement Gosper's algorithm for computing operations between continued fractions. Many functions are provided, including support for algebraic numbers of arbitrary degree (of course, exp, log, tan, sin, cos, atan, sqrt, etc. are included). Though my initial purpose was not to implement an efficient and quick module (I was rather interested by the theoretical aspects of the thing), some very quick and empirical comparisons with CREAL make me think that my module is quicker for the superficial tests I tried. This is an alpha release; it is undocumented, except that the .mli file is understandable and commented. Some little changes since the announce on fr.comp.lang.caml: - licence now is MIT (rather than GNU) - a few functions added (mainly conversion functions: conversions from/to continued fractions can be done with many types (including now streams, objects having a "next" method, lists, etc.) - a support for converting continued fractions to convergents has been added (a ratio_from_cf function, and a class for building successive convergents).
Announcing ocamlconf-0.2; new in this release: * A slightly different API (with radically improved backend) for specifying targets, with more options for libraries and less for scripts. * Better makefile, with doc targets for each format known to ocamldoc, and generally better management of "make all" vs "make opt" * Finer control over what is installed with findlib, and under what package name * Many bug-fixes for combined C/ocaml libraries. http://kenn.frap.net/ocamlconf/ http://kenn.frap.net/ocamlconf/ocamlconf-0.2.tar.bz2 ----- cut here ----- Description of ocamlconf: Ocamlconf is a build helper for ocaml programs. It takes a 'configure.ml' and creates a 'configure' script. This script prompts for compile time toggles and variable settings, and outputs an automatically-generated makefile. Features: * Simple "./configure; make; make install" operation. * MakeMake module for outputting your makefile based on specifications * Conf module for prompting the user for compile-time options, as well as locating libraries (usually via findlib) * Util module with some useful shell and string functions How Good is the Generated Makefile? * Makefile is about as simple as a hand-written one. * Contains a 'normal' and a '.opt' target for each program or library * Typical targets for: install, install-opt, uninstall, clean, distclean, doc, * all, opt, byte, tar, gzip, bzip2
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.