Previous week Up Next week
Hello,
Here is the latest Caml Weekly News, week 22 to 29 July, 2003.
1) More on OCaml packaging
2) Discovering inconsistencies
3) OCaml interface for Apache API
4) Call for test programs for Baire
==============================================================================
1) More on OCaml packaging
------------------------------------------------------------------------------
** Xavier Leroy said:
I have followed this discussion with interest, although other
commitments prevented me from replying earlier.
I think there are two completely orthogonal issues:
1- Caml library packaging: standardizing and automating the
configuration, compilation, installation, dependency handling and
re-compilation when dependents change.
2- Name space management: avoiding the unfortunate situation where
several packages define compilation units that have the same names.
I agree with Gerd that the first issue (library packaging) is by far
the most acute. The lack of a packaging framework currently makes
using third-party Caml libs in a development much harder than it
should be.
Someone objected that this isn't a Caml-specific issue and that it can
be handled by standard packaging tools. Perhaps, but the problem is
that there are no standard packaging tools. Even among Linux
distributions, the packaging tools vary widely. Not to mention other
Unixes (BSD, Solaris, Tru64, ...), and MS Windows. This flies in the
face of the cross-platform portability offered by the core Caml
system. It's not reasonable to expect that the world will convert
overnight to Debian's "apt". It's not reasonable either to expect
library writers to package their libs for 8 different packaging
systems, especially when most of them wouldn't touch Windows with a pole.
That's why other cross-platform programming environments
such as Perl and Python have developed their own packaging technology.
Library packaging is one of those "soft", un-glamorous problems: there
are no hard, open problems, just an endless series of small problems
to be solved and policy decisions to be taken. I had interesting
discussions with several of you concerning possible designs, but
apparently these efforts ran out of steam. I'm very happy to see that
Gerd (with his eminent practical sense) is giving it a try, and I wish
he'd get more constructive feedback on this.
Now, the name space management issue seems over-inflated to me.
Yes, it can happen, and may become a serious issue once we have
hundreds of libs that need to coexist. But I think we can still get
a lot of mileage out of the current "global namespace for compilation
units" model. In particular, most libraries can be set up so that
they define only *one* top-level module (i.e. compilation unit):
- put all sources in one file, possibly with sub-modules
(not as ugly as it sounds -- see my Cryptokit library for an example);
- put all user-visible definitions in one file, say Mylib.ml, and
put internal definitions in other files with unlikely names such as
MylibInternalFoo.ml, MylibInternalBar.ml, etc
- use ocamlc -pack to assemble the library files into one compilation
unit.
Some people reject ocamlc -pack on the grounds that it prevents
link-time elimination of unused sub-modules. I think they are jumping
to conclusions. First, for many libraries, there is essentially no
opportunity for this link-time elimination, as every sub-module is
used. Second, many libraries are small enough that the increase in
code size doesn't matter much. Third, this is a "quality of
implementation" issue: I might be able to implement this link-time
elimination for the native-code compiler (ocamlopt -pack) at some
future time. The problem remains for bytecode, though, but is perhaps
less acute due to the small size of bytecode.
Finally, as this discussion demonstrates eloquently, there is no
obviously good solution to the name space management problem. Yes,
various things can be done either at the language level or at the
compiler level to support finer identification and re-naming of
compilation units. But I'd rather not settle on a half-baked solution
to a non-acute problem.
==============================================================================
2) Discovering inconsistencies
------------------------------------------------------------------------------
** Xavier Leroy said and Stefano Zacchiroli announced:
> If you try to use these libraries without recompiling them, you'll get
> plenty of "Files xxx and yyy make inconsistent assumptions about
> module Z".
If you think it's useful you can try a tool we are using for debian
packaging to discover where those inconsistencies are. The tool (namely
"tofubar") scans a set of ocaml objects/interfaces or the ocaml standard
library and, using objinfo to discover them, print out inconsistencies.
tofubar is a simple ocaml _script_ and is available here:
http://bononia.it/zack/stuff/tofubar.ml
==============================================================================
3) OCaml interface for Apache API
------------------------------------------------------------------------------
** Richard Jones announced:
There seems to be a lot of interest in real OCaml wrappers for the
Apache API. I've written some test code (attached). The model is
mod_perl - attempting to encapsulate all the Apache API calls.
Comments etc welcome.
** (the code is available in the original message
http://caml.inria.fr/archives/200307/msg00292.html)
==============================================================================
4) Call for test programs for Baire
------------------------------------------------------------------------------
** Diego Olivier Fernandez Pons said:
The next version of Baire will contain two kind of test suites :
- pure performance tests
- (almost) real situation tests
For the latter, we are looking for small applications (up to 1500
lines) using some of the following data structures :
- sets, maps, tries, bags
- priority queues, heaps
- functional arrays, random access lists
- graphs (ephemeral or persistent)
- automata
Applications are not required to be interfaced with Baire (in fact we
even prefer them to use a separate module or the standard library to
allow correction and performance tests)
Applications should conform to the licence of Baire (which follows the
license of the Caml standard library that is (up to now) the LGPL with
a special exception on ... confer to the LICENSE file of the Caml
distribution for complete description).
All suggestions are of course welcome.
Last point, the next release of Baire is not planned before a couple
of months.
==============================================================================
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
(alan.schmitt@inria.fr) and I'll mail it to you, or go take a look at
the archive (http://pauillac.inria.fr/~aschmitt/cwn/). If you also wish
to receive it every week by mail, just tell me so.
==============================================================================
Alan Schmitt