Here is the latest Caml Weekly News, for the week of 27 January to 03 February, 2004.
SoCaml is a binding for the object-oriented 3D scene library Open Inventor (tm) (http://oss.sgi.com/projects/inventor/). Here's what can be done in SoCaml so far: o Create an Inventor scene graph from a string. o Display the scene graph with an examiner viewer. o Type in commands that are echoed in a heads-up display. o Run your own event loop, for greater flexibility and compatibility with other graphical systems. SoCaml is available at http://redwood.ucdavis.edu/~issac/software/socaml-1.1.tar.gz To try it, edit the Makefile to fit your system and then type make. Some demos are created. The documentation is sparse, but the demo sources should be helpful. Requirements: o OCaml 3.07beta2 o Camlidl o g++ 2.95 o SGI's version of Open Inventor Caveats: So far it has only been tested on an Intel/Debian system, using the inventor-dev package. I haven't yet made it work with Coin (www.coin3d.org) because of some linking issues. No attempt has been made to use it with TGS's version of Inventor. Also, lots of things haven't been wrapped yet. License: GPL
I am pleased to announce the first release of PostgreSQL-OCaml, a very complete library for accessing the PostgreSQL-database. This library builds on Alain Frisch's previous interface (postgres-20010808). The code has been cleaned up, a few not so important additions have been made, a few functions, methods and types have been renamed (as well as the library) and may expect or return different types of parameters. The interface is very well-documented now, and the library can be easily installed and used with findlib. It should be fairly straightforward to adapt existing code that uses the old version. You can download the library here: http://www.oefai.at/~markus/home/ocaml_sources.html#postgresql-ocamlStefano Zacchiroli asked and Alain Frisch answered:
> This sentence doesn't clarify an issue: is this library supposed to > supersede Alain's bindings or to be a fork? Markus and I discussed the issue. I'll continue to maintain my library, but it is very stable (no bug reported in 3 years), so in practice, it only means that the package will remain available. However, it is considered deprecated: new users should better use Markus' revision. Existing users can continue with my version if they are happy with it, or switch to the new interface (the transition should be easy; OTOH it will mainly bring an aesthetic improvement). For distribution package maintainers, I think the best thing is to keep my library available and provide Markus' one under another name.Richard Jones proposed:
If people think that the mod_caml DBI approach is the right one (and it may not be, although it certainly Works For Us), then I could spin this off into a separate package to make it easier to install. This is dbi.mli: http://savannah.nongnu.org/cgi-bin/viewcvs/modcaml/modcaml/dbi.mli?rev=HEAD&content-type=text/vnd.viewcvs-markup This is dbi_postgres.mli, which is the driver we use all the time in production at Merjis, hence the most stable / developed: http://savannah.nongnu.org/cgi-bin/viewcvs/modcaml/modcaml/dbi_postgres.mli?rev=HEAD&content-type=text/vnd.viewcvs-markup This is the driver for Perl DBDs: http://savannah.nongnu.org/cgi-bin/viewcvs/modcaml/modcaml/dbi_perl.mli?rev=HEAD&content-type=text/vnd.viewcvs-markup The interface is designed to make it quick to access databases, in the sense that you write the minimum code necessary. It's not type safe, in the sense that if you write garbage SQL, it won't be detected until runtime. Alex Baretta is, I believe, pursuing an alternative approach using Camlp4 which is supposed to be type safe.Richard Jones added:
Here's a few more examples I've culled from our code. We're doing some (I think) neat stuff here, eg. using sth#map and sth#iter to quickly iterate over the results from queries: http://www.annexia.org/tmp/dbi-ex2.txt .... combined with pre-prepared statements: http://www.annexia.org/tmp/dbi-ex3.txt And we have some neat code that lets you tie a variable to a particular field in the database, a kind of (primitive) persistence: http://www.annexia.org/tmp/dbi-ex4.txt We use this to tie Gtk widgets to database fields, using the transaction capabilities of the database to implement Save and Rollback operations in the GUI.Gerd Stolpmann answered Richard Jones:
I think we really need this type of interface. I have some experience with Perl DBI, and although our company did have the need to support several database systems in the same product, this made things a lot easier, simply because you don't have to learn a new API when you switch to a another database system. So I would it really appreciate if this interface were released as independent package. Of course, I have also some technical remarks: - I don't understand why there are several ways to represent NULL. For example, what is the difference between `Null, `TimestampOption None, and `Timestamp ts where ts.ts_is_null=true? - Using host,port,user,password to identify and authenticate a connection works in most cases, but is not very wise for the long-term stability of the interface. For example, it is already possible to authenticate with X509 certificates, which cannot be expressed with this scheme. I would suggest to only have two strings, one called "system_id", the other called "authenticator". In general, these strings are interpreted by the driver, but there are conventions, e.g. "host=XXX,port=XXX" for the system_id, and "user=XXX,password=XXX" or "user=XXX,x509privatekey=XXX,x509passphrase=XXX" for the authenticator. - There is no way to pass options to the driver when one uses the Factory. I think it would be a good idea to have a string for driver options, again in the format "key=value,...". - There should be method for escaping strings (so one can generate SQL statements) - One exception should be special: That transactions are aborted because of conflicts (think of Postgres' MVCC) or deadlocks and should be repeated. I think the other possible errors can be subsumed in one Sql_error exception as it is currently done. - There should be a possibility to coerce a generic connection object back to the driver's class. This can be done by adding a method driver_handle that just raises a driver-specific exception returning the handle. This way it is possible to switch to low-level code at any time, e.g. for optimizations for certain DBMS. - Following the coding guidelines for O'Caml, methods with side-effects should have a functional type, e.g. finish : unit->unit instead of just finish:unit. This has also the advantage of making it simpler to later add optional arguments to methods. - There was the question how to handle BLOBs. I worked with DBMS where TEXT is a BLOB type. I think there should be a BLOB class like class type blob = object method length : int64 method get_chunk : pos:int64 -> len:int -> string method write_file : string -> unit end and there should be methods (of the connection) creating such BLOBs: method create_blob_from_string : string -> blob method create_blob_from_file : string -> blob I think this is the minimal BLOB interface we should support. More advanced BLOB interfaces can be implemented in the drivers. I hope we get a really good generic DBMS layer soon.Richard Jones then said:
I pretty much agree with all of Gerd's comments. I'll accelerate the process of splitting out Dbi from mod_caml so that it can be used and developed separately.
Sylvain Conchon, Julien Signoles and myself have started a graph library for ocaml. Before going further and releasing this library, we would like to get some feedback from people currently using graphs in ocaml applications or willing to do so. More precisely, we would like to know what kind of operations on the graph structure and graph algorithms are commonly used by such users. Could you please tell us if you are the author of a graph library not already mentioned in the ocaml hump?He then clarified:
Thomas Fischbacher writes: > > What do you mean by "graph library"? > > A library of graph algorithms (highly desirable - right now I am working > at a problem where efficient generation of planar graphs is THE main > issue, and I do it in lisp/ocaml), a graph layout library in the sense > of a re-implementation of graphviz in ocaml (would also be very nice to > have), or a plotting library in the sense of gnuplot? > > I think you should clarify this a bit more on the list... You're right, I should have been clearer. We didn't want to give too many details before the first release, but let's go. Our library is currently providing 1. Several data structures for graphs (persistent or imperative, directed or not, with labeled edges or not, etc.), sharing a common minimal signature (iterators over vertices, edges, etc.) 2. Several algorithms over graphs, written as functors and thus independently of the graph implementation (it means you can build your own data structure for graphs and still re-use the algorithms code). Currently we have the following algorithms coded: Tarjan's strongly connected components, Dijkstra's shortest path, Ford-Fulkerson's maximal flow, Warshall's transitive closure, DFS and BFS traversal, cycle detection. We are currently adding random graph generations based on algorithms from Knuth's Stanford GraphBase, including the generation of random planar graphs. (This at least seems to be in connection with what you're doing.) 3. Utilities, such as a graphviz output --- an ascii output in the DOT format to be precise (So we are not re-implementing a graph layout library).
Ocaml-MySQL 1.0.3: Bindings for using MySQL from ocaml. This release hopefully makes it easier to use on systems without dynamic linking or native-code compilation. See http://raevnos.pennmush.org/code/ocaml-mysql/ Extlib 0.11.2: Lots of stuff to complement the standard and unix libraries. Same things as the MySQL changes, plus bugfixes and the getrlimit, setrlimit, and getrusage unix syscalls. See http://raevnos.pennmush.org/code/extlib/ Ethread 1.0.1: Useful stuff for multi-threaded programs: Read/write locks, barriers, a simple thread-safe message queue that can be tested with select. Changes: Better support for systems without native-code compiliation (See a trend here?) http://raevnos.pennmush.org/code/ethread/ Servinfo 1.0.0: A little tool for looking up entries from /etc/services (I got tired of using grep). http://raevnos.pennmush.org/code/servinfo/
Probably not quite what you want, but I have a library for reading and writing comma-separated values (CSV) files here: http://www.merjis.com/developers/csv/ http://www.merjis.com/developers/csv/ocaml-csv-1.0.1.tar.gz
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.