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.