Hello
Here is the latest Caml Weekly News, for the week of July 11 to 18, 2006.
There won't be any CWN next week as I'll be in vacations without internet access.
I've started a short comparison of OCaml web frameworks for WDialog,
Ex-Nunc, Ocsigen and mod_caml:
http://www.demexp.org/en/doku.php?id=web_client_development_framework#comparison_of_ocaml_frameworks
This page is a Wiki. Feel free to fix any error or omission you might
see (please add a meaningful comment in that case), as I have not tested
each framework (except WDialog).
I'm also interested into other criteria of comparison you might see
interesting.
Nicolas Cannasse added:
I added both haXe (http://haxe.org) and Neko (http://nekovm.org) to the
list of your web frameworks.
Since the haXe compiler is written in OCaml, that might interest some
people on this list as well. haXe is an high-level OO language with a
modern type system (type inference, enums, ML polymorphism). It targets
three platforms :
- it has a Javascript/AJAX code generator so you can use it to code
the client side of your website.
- it has a Neko code generator that can be used with NekoVM to write
the server side of your website : NekoVM is a small embeddable VM with a
"mod" for Apache.
- it has a Flash/SWF generator so you can use haXe to develop Flash
RIA and other applications.
Just a heads up: registration opened about a week ago for the 2006 ICFP
Programming Contest. This year's contest is being organized by the POP
group at Carnegie Mellon, and promises to be quite a bit different from
previous years' competitions -- hopefully better :)
The somewhat cryptic theme offered is "computational archaeolinguistics".
O'Caml teams have traditionally made a strong showing in the past, though
the coveted first and second prizes have eluded them in recent years.
Maybe it's time for a triumphant return!
The standard announcement follows below. Stay tuned to icfpcontest.org for
details as they develop.
cheers,
William
--- 9th annual ICFP Programming Contest ---
Language lovers:
Registration is now open for the 9th Annual ICFP Programming Contest!
http://icfpcontest.org/
The contest, associated with the International Conference on
Functional Programming, will be held on the weekend of July 21-24. The
contest task will be released at noon EDT on Friday, and entries will
be accepted until noon EDT on Monday. Registration is free and open to
all. Teams may participate from any location, and may use any
programming language(s). Last year, 360 participants formed 161 teams
from 26 countries.
Prize money totaling $1750 US will be awarded to help defray the costs
of travel to the conference for the winners and for small cash prizes.
In addition, the winners of the contest will receive bragging rights
for the programming language of their choice. This makes the contest a
popular avenue for demonstrating the superiority of a favorite
language, or for exercising an experimental tool.
Though the specifics are secret until the contest begins, we promise
that this year's task will be very different from past competitions.
The theme is "computational archaeolinguistics."
Stay tuned for more information as the contest approaches!
This is a letter of introduction and a request of expressions of
interest in commercial support for Objective Caml.
xrnd is a technology research and systems development company. We
provide a broad range of professional services including contract
systems R&D, high-level consulting, software development and training.
We are currently investigating extending our use and support of
Objective Caml to include commercial support for users of the system.
This will provide a number of services:
- industrial strength proprietary software development
using Objective Caml
- training and proof of concept pathfinder projects
- long term supported Objective Caml distribution with
additional libraries and extended Windows support
- implementation and contribution of features such as improved
64 bit code generation, vectorization and Windows support
- crisis support for urgent bugs in custom code, distribution
or libraries
We consider our relationship with INRIA and the greater community to
be vital. Our contributions will have copyright assigned to INRIA
where the Caml team would like to include the code in their
distribution. While not every change will make it into the standard
distribution in this manner, our distribution will differ only where
necessary to provide requested features or pending changes to the
standard version. We expect that this will include, for example,
extended Windows support, which INRIA will not be pursuing.
We would be grateful for serious expressions of interest by email to
us directly so that we can gauge the practical market for this
support, and are happy to answer initial inquiries off-list.
We look forward to working with you.
Regards,
Fermin Reig, for the xrnd team.
> For Mac, I notice that there is a pre-compiled Mac binaries for
> the compiler:
> http://caml.inria.fr/distrib/ocaml-3.09/ocaml-3.09.0.dmg
> I presume that these are PowerPC binaries. Is that correct?
Yes.
> Is there likely to be a version soon targetting the Intel CPU soon?
The source distribution for 3.09.2 contains full support for MacOSX/Intel,
including native-code generation. There are still a few small
ocamlopt bugs in this port, which I'm currently ironing out.
> So, on to GUIs. My GUI requirements are rather simple. In fact
> the lablTk libraries should do the trick. Has anyone actually
> done any Ocaml development with a lablTk GUI targeting all three
> platforms? If so, how did it work out?
In the standard distribution, there's ocamlbrowser, which has a
labltk-based GUI and works on all three platforms.
Jacques Garrigue said and Janne Hellsten answered:
> Unfortunately, on MacOSX ocamlbrowser only works properly with the X11
> version of Tk (which is very easy to install.)
> I tried several times to make it work with the Aqua version, but was
> never completely successful.
I tried compiling ocamlbrowser directly from GODI and it worked out of
the box on my MacBook Pro. AFAIK this was using the Aqua version --
at least it didn't launch X11 like all the other X11 apps do.
i think there are more than one available SQLite bindings for OCaml,
including some that are just for versions of SQLite before the API
was changed in version 3 and others engineered directly for SQLite3.
I am using Báröur Árantsson's bindings that are available at:
http://www.imada.sdu.dk/~bardur/personal/45-programs/
These particular OCaml bindings in many ways directly mirror the
SQLite3 C API; they are not a DBI-like interfaces, but work well if
you are familiar with SQLite3.
I have modified the bindings slightly for my own needs by adding a
few methods and fixing a few bugs (any fixes of which I plan to
eventually contribute back to Bárður), but it works very well with
the latest version of SQLite3. I am using it just fine with version
3.3.6 of SQLite. I have successfully used it to create database
files of several gigabytes (populated with marshaled OCaml objects
using Sqlite3's blob type).
The OCaml Network Application Environment (NAE) released updates to
the Core Foundation (Cf) and I/O Monad (Iom) library modules today.
See the project page on SourceForge.Net for downloads.
http://sf.net/projects/ocnae
The update to Cf is mostly bug fixes, but type names were changed
almost everywhere to remove confusing "_t" suffixes. Also, the
[Cf_gadget] interface was significantly altered. The update to Iom
is completely overhauled (again, <sigh/>).
===== OCaml NAE Core Foundation (cf) library =====
This distribution is the Objective Caml Network Application
Environment (NAE)
Core Foundation library, which is a collection of miscellaneous
extensions to
the Objective Caml standard library.
Highlighted features include:
- Functional streams and stream processors (extended).
- Functional bootstrapped skew-binomial heap.
- Functional red-black binary tree (associative array).
- Functional sets based on red-black binary tree.
- Functional real-time catenable deque.
- Functional LL(x) parsing using state-exception monad.
- Functional lazy deterministic finite automaton (DFA).
- Functional lexical analyzer (using lazy DFA and monadic parser).
- Functional substring list manipulation (message buffer chains).
- Gregorian calendar date manipulation.
- Standard time manipulation.
- System time in Temps Atomique Internationale (TAI).
- Unicode transcoding.
- Extended socket interface (supports more options, and UDP w/
multicast).
- Universal resource identifier (URI) manipulation.
- I/O event multiplexing (with Unix.select).
Note: see the ISSUES file for a list of open problems in this release.
===== OCaml NAE Reactive I/O Monad (iom) library =====
This distribution is the Objective Caml Network Application
Environment (NAE)
Reactive I/O Monad library, which implements I/O monad functions
designed to
facilitate writing of concurrent, reactive, single-threaded network
application
services in a functional style.
Note: see the ISSUES file for a list of open problems in this release.
===== Required Components =====
This library requires the following external components:
- Objective Caml (v3.09 or newer)
- Findlib (tested with v1.0.4)
- OCaml NAE Core Foundation (cf-0.8)
Principal development was on Mac OS X 10.4 w/ XCode 2.3 using GCC
4.0. No
other platforms were tested for interoperability.
===== Changes in Cf-0.8 =====
Highlights of the changes:
+ Fix bugs and remove warnings generated when compiling with OCaml
3.09 series.
+ Changed named of types to remove [_t] suffixes (that were never a
good idea).
+ Rewrote the gadget monad again, to permit input backtracking on the
flow
resulting from evaluation.
+ Minor changes to event polling to simplify interface.
+ Modularity improvements to socket API.
+ Update the hard-coded TAI-UTC leap second archive.
+ Update copyrights and author email address.
+ Minor improvements to lazy sequences and functional messages.
+ Removed obsolete modules.
--- [Makefile]
Use -warn-error A on debug builds.
--- [Cf_deque]
Use recursive module instead of magic. Add [to_list], [of_list]
and
[of_seq] convenience functions.
--- [Cf_rbtree]
Optimizations for better performance. (Further optimizations
are possible.
While these modules offer more adaptability than the standard
OCaml library
data structures, they do not offer superior performance. In
some cases,
performance is a little better than the standard, but in most
cases, the
standard library is runs faster. This is particularly true for
the binary
set operator functions.)
--- [Cf_ip4_addr,Cf_ip6_addr]
Fixed an awful bug in the [compare] functions that caused the
return value
to be mistyped.
--- [Cf_tai64]
Update the hard-coded TAI-UTC leap second archive. Add a
comment describing
where to retrieve the data.
--- [Cf_scan_parser]
Fix brokenness surfaced by OCaml 3.09 series.
--- [Cf_gadget]
Re-engineered, again. This time, the integrated state is
dropped from the
monad, and the scheduler is no longer implemented in the
imperative style.
As a result, evaluating the monad now produces a flow that permits
backtracking on the input.
--- [Cf_state_gadget]
This is the old [Cf_gadget] from version 0.7, with some minor
improvements.
Use [try... with] to catch only the [Queue.Empty] exceptions
raised by the
calls to [Queue.take] in the scheduler itself. All other
exceptions are
passed through the flow produced by [Cf_gadget.eval].
Added [abort] and [wirepair] monads. Simplified by removing
[fsimplex]
monad, and the [simplex_t] and [duplex_t] types.
--- [Cf_machine]
Obsolescent. Use the [start] and [next] classes in [Cf_gadget]
instead.
--- [Cf_message, Cf_seq]
Add [to_function] for convenience constructing [Scanf.scanbuf]
objects.
The indirection is required to keep [Scanf] from having to be
loaded if it
isn't used.
--- [Cf_journal]
Add [`Notice] event level, and associated method in [agent]
class. Cleared
up some ambiguous language in the documentation.
--- [Cf_nameinfo]
Interface was busted for all queries except with the default hints.
Refined interface to support narrowed queries.
--- [Cf_poll]
Unified ['a state_t] and ['a file_state_t] into a single
concrete variant
type and removed the polymorphism on the state variant in all
the derived
event classes. Event classes are now parameterized by event
type alone.
Changed [time] class to be a repeating interval timer event.
Fixed [idle] so that events that reload themselves are not
serviced until
the next cycle.
--- [Cf_ipX_proto, Cf_xxx_socket]
Moved the definitions of the protocol modules into the
[Cf_ipX_proto]
modules. This will allow [Iom] to link with the core socket API
without
also linking in all the convenience classes for synchronous I/O.
--- [Cf_lexer]
Obsolete, therefore removed.
--- Changed names of types to remove [_t] suffixes.
Module Type names changed
------ ------------------
[Cf_journal] [invalid_t], [fail_t], [error_t], [warn_t],
[info_t],
[debug_t], [basic_t], [enable_t], [level_t]
[Cf_seq] [cell_t]
[Cf_flow] [cell_t]
[Cf_gadget_t] [work_t], [gate_t], [wire_t], [guard_t]
[Cf_lex] [counter_t]
[Cf_socket] [socktype_t], [domain_t], [protocol_t],
[sockaddr_t],
[sockopt_t], [tag_t], [address_t], [msg_flag_t]
[Cf_sock_common] [address_t]
[Cf_ip4_addr] [network_t]
[Cf_ip4_proto] [tag_t], [address_t]
[Cf_ip6_proto] [tag_t], [address_t], [mreq_t]
[Cf_uri] [host_t], [server_t], [authority_t],
[segment_t],
[abs_path_v], [rel_path_v], [path_t],
[absolute_t],
[relative_t], [reference_t] [abs_special_t],
[abs_special_hier_t]
--- [t_cf]
Test Cf_scan_parser.scanfx "%!".
===== Changes in Iom-0.3 =====
This release is yet another major overhaul. The programming
interfaces are
all new again and coded from scratch-- this time with more extensive,
but still
far from exhaustive, testing and regression.
Previous release were rough drafts, and this new one is every bit as
much of a
rough draft as those were, but I feel more confident than before that
no major
overhauls of this design will be required. Minor design flaws may
require
corrections, and bugs are very likely to be exposed over time with
usage, but
future changes in the 0.xxx version sequence should be incremental,
rather than
total.
All along, I have been aiming for a framework that appears to be as
adaptable
as the venerable STREAMS framework from Unix SVR4. With this
release, I feel
like I have finally succeeded in that effort. Only time will tell,
however, if
I am right.
Highlights of the new design:
+ Uses new stateless [Cf_gadget] module (from Cf-0.8) with state classes
instead of the old stateful [Cf_gadget] (from Cf-0.7).
+ Conventions established for multiplexing communication between
gadgets on
multiple wires, i.e. a [jack] is used for sending control and
receiving
notification, and a [plug] is used for receiving control and sending
notification.
+ Support for Unix pipes.
+ Redesigned interface to TCP streams.
+ Generalized support for simplex and duplex octet stream processsing
layers,
e.g. framing discipline, packet multiplexing, etc.
See t/t-relay.ml for an undocument example of how to use the new Iom
modules.
I just finished a new release of OCamlTeX, which fixes several bugs,
provides much more useful error reporting, and significantly more
documentation. You can grab the latest using the darcs version control
system by running
darcs get http://free-the-mallocs.com/repos/ocamltex
For more information, check out
http://free-the-mallocs.com/index.php?n=Software.OCamlTeX.
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.
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.