[cwn] Attn: Development Editor, Latest Caml Weekly News

Alan Schmitt alan.schmitt at polytechnique.org
Tue Aug 30 00:02:29 PDT 2005


Hello,

Here is the latest Caml Weekly News, for the week of 23 to 30 August,  
2005.

1) Berkeley DB
2) OPath 0.2 released
3) OCamlDuce 3.08.4
4) GODI news
5) Does LablTk have a future?

========================================================================
1) Berkeley DB
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.

========================================================================
2) OPath 0.2 released
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!

========================================================================
3) OCamlDuce 3.08.4
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).

========================================================================
4) GODI news
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>

========================================================================
5) Does LablTk have a future?
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.

========================================================================
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 at polytechnique.org) and I'll mail it to you, or go take  
a look at
the archive (<http://sardes.inrialpes.fr/~aschmitt/cwn/>) or the RSS  
feed of the
archives (<http://sardes.inrialpes.fr/~aschmitt/cwn/cwn.rss>). If you  
also wish
to receive it every week by mail, you may subscribe online at
<http://lists.idyll.org/listinfo/caml-news-weekly/> .

========================================================================

Alan Schmitt, <http://sardes.inrialpes.fr/~aschmitt/>

-- 
The hacker: someone who figured this out and made something cool happen.
.O.
..O
OOO


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20050830/85443bbd/PGP.bin


More information about the caml-news-weekly mailing list