Hello
Here is the latest Caml Weekly News, for the week of 23 to 30 August, 2005.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30200
Continuing the thread from last week, Christopher Alexander Stein said:
I actively maintain a BDB OCaml interface
(http://www.eecs.harvard.edu/~stein/ocamlbdb-4.3.21.tar.gz). It
currently works with BDB 4.3.21. Please send me any bug reports
and bug fixes.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30241
Jamie Clarkson announced:
I'm pleased to announce the availability of OPath 0.2.
OPath is a physically based 3D renderer written in OCaml. It takes a scene
description written in a simple declarative language and runs various
ray or
path tracing algorithms to generate high dynamic range images.
This release is mostly for architecture stabilization and improving
robustness. One or two new features have been added however:
* Thin lens camera (for depth of field rendering)
* 2D texturing
* Dielectric materials (e.g. glass)
Homepage with some nice renders:
http://opath.sourceforge.net/
Source under MIT license and a Win32 binary are available:
http://sourceforge.net/project/showfiles.php?group_id=96645&package_id=103321
All comments appreciated, enjoy!
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30230
Alain Frisch announced:
OCamlDuce 3.08.4 is now available (http://www.cduce.org/ocaml#ocaml).
As the version number says, it has been synchronized with OCaml 3.08.4.
More importantly and due to overwhelming popular demand, OCamlDuce now
comes with some amount of binary-compatibility with OCaml. This should
make it easier to try OCamlDuce.
OCaml-generated files (.cmi/.cmx/.cmo) can be used by OCamlDuce without
recompilation. You can thus install OCamlDuce and re-use already
installed libraries from an existing OCaml installation. Provided that
the OCaml and OCamlDuce versions match, of course.
It is even possible to have a mixed OCaml/OCamlDuce project, where
OCamlDuce is only used to compile some modules whose interface are pure
OCaml (OCaml and OCamlDuce produce identical .cmi files for the same
pure OCaml .mli file).
John Skaller wondered and Alain Frisch answered:
For what concerns John's question about the integration of OCamlDuce in
OCaml, there are many answers. 1) I'm not directly involved in the
development of OCaml. 2) The -Duce part, taken from CDuce, is a big
piece of code which still evolves in some experimental ways and which
couldn't be easily maintained by someone else in its current state. 3)
OCaml is a general purpose language, and the extension adds support for
a specific domain (and OCaml is already big enough). 4) One of the
design guidelines for OCamlDuce was to obtain an easy merger between two
existing implementations; due to this constraint the result is not as
elegant or integrated with the rest of the language as one might expect
from an ML+CDuce merger written from scratch (but it works). The
constraint of being able to compile any existing OCaml program with
OCamlDuce, for instance, resulted in the introduction of explicit
delimiters {{..}} for all the new constructions, which is syntactically
heavy and theoretically useless. 5) It's too early to say whether
OCamlDuce is useful or not compared to a simpler solution with two
compilers (OCaml, CDuce).
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30301
Gerd Stolpmann announced:
Welcome to GODI news, the newsletter that informs you about updates of
GODI, the source-based O'Caml distribution.
------------------------------------------------------------
TABLE OF CONTENTS:
1. GODI upgrades to O'Caml 3.08.4
2. Various problems solved
3. Current GODI development
4. Where to find more information about GODI
------------------------------------------------------------
1. GODI UPGRADES TO O'CAML 3.08.4
The GODI project recently upgraded to O'Caml 3.08.4. This means that the
"3.08" branch of the distribution now bases on this O'Caml version
instead of the formerly used version 3.08.3. The old version is
discontinued at the same moment.
Existing installations of GODI can be easily upgraded using the standard
mechanism. This works in an almost fully automatic way, GODI takes care
not to only build the new O'Caml base but also rebuilds all dependent
libraries. Although well tested, it is recommended to save a copy of the
old installation before trying the update.
To start the update, invoke godi_console in interactive mode, and do:
- Update the list of packages
- Go into the menu where one can select the packages. Press 'u'
to upgrade the packages, and confirm with 'o'. Start the installation
as usual. There is one special point that requires manual
intervention: Because godi_console updates itself, the user is
warned about potential problems, and another confirmation ('o')
is required. You will see a describing message at that point.
- Enjoy the updated installation
It is also possible to do the same from the command-line:
$ godi_console update
$ godi_console wish -rebuild
$ godi_console perform -wishes -newer
$ godi_console wish -reset
2. VARIOUS PROBLEMS SOLVED
As more and more operating systems are shipping with GCC 4 as default
compiler, it became urgent to fix the incompatibilities with this GCC
version. Partly, the problem could be solved by the upgrade to O'Caml
3.08.4. However, GODI still uses some C programs that could not be
compiled. These had to be additionally fixed.
It is recommended that users of GCC 4 bootstrap GODI from the beginning.
(You can find out the GCC version by entering the command
"gcc --version".)
Another problem in the past months affected only Mac OS X 10.4 users.
Because of a change of a system call some programs had to adapted to the
new style.
3. CURRENT GODI DEVELOPMENT
Current versions of godi_console include an integrated rewrite of the
"BSD make" utility GODI uses to drive all sorts of shell scripts. One
can call this version of the "make" utility by calling "godi_console
make ..." instead of "godi_make ...". It is still experimental, although
it seems to be good enough to replace the old C program that is
currently being used.
For a discussion of the consequences, see this thread:
https://gps.dynxs.de/pipermail/godi-list/2005-July/000627.html
4. WHERE TO FIND MORE INFORMATION ABOUT GODI
GODI is a source-based O'Caml distribution. It consists of a framework
that automatically builds the O'Caml core system, and additionally
installs a growing number of pre-packaged libraries. GODI is available
for O'Caml-3.07 and 3.08. It runs on Linux, Solaris, FreeBSD, NetBSD,
Cygwin, HP-UX, MacOS X.
Advantages of using GODI:
* Automatic installation of new libraries: GODI knows where a
library can be downloaded, which prerequisites are needed to
build it, and which commands must be invoked to compile and
install it
* Complete package management of the installation: A library is
installed as a package (a managed set of files), so it is
possible to remove it later without any hassle.
* GODI implements the necessary logic to upgrade installations:
Because of the way O'Caml works, all dependent libraries must be
recompiled if a library is upgraded to a newer version. GODI
automates this process.
* Integration with the operating system: If additional C libraries
are needed to build an O'Caml library, and the operating system
includes them, they will usually be automatically found and
used. Non-standard locations can be configured (there is only
one configuration file for the whole installation).
* GODI has a menu-based user interface that makes it simple to use
even for beginners.
* GODI tries to standardize the directory layout of library
installations, so it becomes simpler to find files of interest.
GODI currently supports 73 add-on libraries and 12 applications written
in O'Caml.
Read more on the GODI homepage: http://godi.ocaml-programming.de
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30293
Matt Gushee said:
I've been thinking about GUI toolkits lately, and particularly Tk. I
know there are a lot of people who believe Tk is dead, or should die.
Personally, I'm not so sure. If you look at the features of Tk 8.5, and
the development roadmap for future versions--perhaps it's too little,
too late--but it is clear that the core Tcl/Tk developers are far from
giving up. Indeed, they seem lately to have gotten a clue about what is
needed to keep Tk a viable GUI toolkit.
Regardless of the status of Tk itself, LablTk seems to be going nowhere
(note that I am not implying any criticism of the OCaml team--they have
other, quite legitimate, priorities). It is poorly documented and is not
keeping up with the recent improvements in Tk. Those who try to use it
often run into trouble, and have difficulty getting their questions
answered. Yet, for whatever reason, it remains the default GUI toolkit
for OCaml.
I believe that Tk, while certainly not an ideal GUI, is still adequate
for many applications, and if the above deficiencies are remedied, could
still serve as OCaml's default GUI library for some time to come. And it
occurs to me that, having several years' experience with Tk in various
forms, and having studied much of the LablTk source code, I am in a
position to do several things that might help revive LablTk. My purpose
today is to inquire whether there is enough interest in the community to
justify any or all of these projects. If there is, I am prepared to work
on one or more of them--preferably with collaborators, but alone if
necessary. If there is little or no interest, maybe it is time to
consider (again) dropping LablTk entirely. Who wants to maintain code
that isn't used or usable?
1) A Quick Reference
This document would outline (with little or no explanation) the
complete LablTk API, including all widget commands and the possible
values of all LablTk-specific types. Currently the latter information
can only be obtained by digging through the source code.
Actually, I wrote a LablTk quick reference some time ago. It may need
a bit of work, but no more than a couple of hours, I'm sure. So I
*will* do this if there is any interest at all in it.
2) A Book
This would be an in-depth tutorial on how to develop useful
applications with LablTk. It would assume some programming
experience, but it would not require advanced knowledge of OCaml, nor
any knowledge of Tcl.
I'm thinking to publish both a print edition and an inexpensive
electronic edition. Though I need to research the costs a bit more, I
believe I can offer the print edition--self-published using Print On
Demand--at a reasonable price, comparable to what you pay for
programming books at a bookstore (no, I don't hope to get rich off
this--just to be modestly compensated for my efforts :).
3) A Community-based Modernization Project
The idea here is to provide a Tk-based GUI library that is complete
and in sync with the latest stable version of Tk. Other features that
would be nice to have include (a) support for a few Tcl commands that
are not strictly part of Tk, but are useful and commonly used in Tk
programs--in particular I'm thinking of the 'after' command; and (b)
a framework that allows downstream developers to create custom
widgets with interfaces analogous to the builtin widgets. I'm not
sure if (b) is feasible or not within the constraints of the OCaml
type system--I've tried and failed in the past--but I imagine
there's some way to do it.
Two other interrelated questions are whether this project should be
done in parallel with LablTk or as a replacement, and whether the
LablTk API should be preserved or something new designed. But it's
probably not necessary to decide these questions immediately.
I eagerly await your comments.
Francois Rouaix said and Matt Gushee answered:
> I'm not active in the LablTk or CamlTk community anymore, but as the
> writer of the (probably) largest piece of CamlTk code lying around (the
> MMM browser), I want to let you know to feel free to pilfer code from
> MMM, if useful or relevant.
Thanks!
> Also, you mention "extra Tcl" commands such as "after". I remember after
> and timers to be present in CamlTk. Maybe they weren't ported to LablTk.
Yes, I think that's right. I wrote an app about a year ago that needed
'after'. Though for some reason I can't recall, I didn't want to use the
CamlTk version verbatim, I did model my implementation after it.
Jon Harrop said and Matt Gushee answered:
>>Regardless of the status of Tk itself, LablTk seems to be going nowhere
>
> It is odd that you should bring this up now. I've spent the past week writing
> a simple database for a new veterinary surgery in OCaml using labltk. I had
> tried lablgtk before but failed to get to grips with it. By comparison, the
> labktk examples explained everything that I needed and I had a decent GUI up
> and running within a few hours.
Yes, it does have that simplicity about it.
>>1) A Quick Reference
> I haven't used anything exotic (or even non-trivial) but it seems to me that
> the API is already so simple that there isn't really a need for a quick
> reference.
Well, you need some source of information other than the OCaml manual.
To give just one example, if you want to do anything serious with
Listbox widgets, you need to know the Listbox.index type, which isn't
described in the manual.
Now, I have lately realized that you can explore LablTk with
ocamlbrowser, so a reference doc isn't strictly necessary. But you could
say the same about any OCaml module ... anyway, the document mostly
exists, and some people may find it more convenient/pleasant to use a
Web page or a printed document.
>>2) A Book
> I think labltk is too specific to be commercially viable.
Specific in what sense? And do you mean LablTk as a tool, or as a book
topic?
> Also, unless I've
> missed some hidden complexities in Tk programming, I think you'd have a job
> filling enough pages to call the result a book.
Ever used the Canvas or Text widgets? There's a lot going on there.
Besides, there are several mainstream (i.e. published by major tech
publishers and available in any well-stocked bookstore) books about Tk
programming (including at least Tcl/Tk, Perl/Tk and Tkinter). They've
mostly been available for several years, so there must be some market
for them.
Of course--and as an author/publisher, I'm sure you know this--the
questions of what to write about, and how and how much, depend a great
deal on the audience.
I can tell you that when I read _Effective Tcl/Tk Programming_ in about
'98, when my GUI-coding experience was limited to a few toy apps in
Visual Basic, I found it tremendously useful, with its in-depth
explanation and extended examples of the more complex widgets, geometry
managers, and the event handling mechanism. Properly described, it was a
book about GUI programming *with* Tk, rather than strictly about Tk itself.
Maybe today's OCamlers are by and large beyond needing that sort of
book. But it's kind of self-defeating to take for granted that the
status quo will continue. I'm inclined to think that as OCaml gains in
popularity--as it is certainly doing--there will be more people who need
more hand-holding. Which doesn't necessarily mean there's much of market
for a book such as I've proposed, just that I see some reason to hope.
> However, I would be very interested in a book that described how to write GUIs
> using OCaml.
That might indeed be a good thing. I don't think, in my current state of
knowledge, I'm the one to write it.
> As I'm the author of the only existing self-published book on OCaml, you may
> be interested to know that it is doing well (~500UKP per month for 6 months
> so far).
Well, at 85 quid a pop, I should think so (what is that in US money,
about $120?)! But you're targeting an audience that has significant
institutional support. I doubt very much that any and all OCaml books
can be sold for that kind of money.
>>3) A Community-based Modernization Project
> I think it would be more constructive to create a decent cross-platform GUI
> library from the ground up for FPLs/OCaml.
Great idea! But it sounds to me like the kind of thing that will never
get finished.
> This wouldn't need to be anything
> fancy, just easy access to the simplest GUI elements to start with.
What kind of apps do you envision writing with only the simplest elements?
> I'd like to see GUIs described by purely functional data structures. I'm
> still factoring my current code so I'll let you know what I come up with.
> Also, despite GUI code being a pedagogical example for OO, I'm not yet
> convinced that OO adds anything useful.
Agreed. Once I too was among the benighted souls, those who worship the
false god of OO. But then I saw the functional light, and I was saved!
Amen, brother!
Thanks for the comments. Lots of good food for thought there.
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.