Here is the latest Caml Weekly News, for the week of 14 to 21 September, 2004.
Archive: http://caml.inria.fr/archives/200409/msg00275.htmlErik de Castro Lopo asked and Jean-Christophe Filliatre answered:
> > I've got a little problem which I can't seem to get to the > bottom of. The following code snippet won't compile: > > let rec print_string_pairs (fmt:string) = > function >  -> print_endline "" > | a :: b -> > Printf.printf fmt (fst a) (snd a) ; > print_string_pairs fmt b > ;; A format is not of type "string" but of type "('a,'b,'c) format". Here is how you can write such a function: ====================================================================== let rec print_string_pairs (fmt:(string->string->'a,'b,'c) format) = ... ====================================================================== But the type of fmt can be inferred, thus you can simply write: ====================================================================== let rec print_string_pairs fmt = ... ====================================================================== Note that this second version is now polymorphic : it applies to any format of type ('a -> 'b -> 'c, out_channel, unit) format and a list of type ('a * 'b) list: ====================================================================== # print_string_pairs "%s->%s\n" [ ("a", "b") ; ("c", "d") ; ("e", "f") ];; a->b c->d e->f # print_string_pairs "%d->%d\n" [ 1,2; 3,4; 5,6 ];; 1->2 3->4 5->6 ====================================================================== > let fmt = Printf.sprintf " %%%ds == %%s\n" 20 ;; > > print_endline fmt ;; > > let pairs = [ ("a", "b") ; ("c", "d") ; ("e", "f") ] ;; > > print_string_pairs fmt pairs ;; There is a additional difficuly here, because you want to build a format string dynamically. With the code above, fmt will be of type string, and then cannot be passed to print_string_pairs. As suggested by Michael, you can use format_of_string to convert a string into a format: ====================================================================== # let fmt = format_of_string "%20s == %s\n";; val fmt : (string -> string -> '_a, '_b, '_c, '_a) format4 = <abstr> # print_string_pairs fmt [ ("a", "b") ; ("c", "d") ; ("e", "f") ];; a == b c == d e == f ====================================================================== But format_of_string only applies to a _constant_ string, not to a string built from an evaluation: ====================================================================== # let fmt = format_of_string (Printf.sprintf " %%%ds == %%s\n" 20) ;; Characters 27-71: let fmt = format_of_string (Printf.sprintf " %%%ds == %%s\n" 20) ;; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This expression has type string but is here used with type ('a, 'b, 'c, 'd) format4 ====================================================================== Indeed, there is no static way to check that the resulting format is indeed of type (string->string->'a,'b,'c) format.
Archive: http://caml.inria.fr/archives/200409/msg00320.htmlChris Danx asked and Richard Jones answered:
> Was looking on the web for an alternative to using GTK+ on Windows (no > flames please) and found WxWidgets. It looks like a quite nice GUI > toolkit. There seemed to be some interest in developing a OCaml binding > via Swig according to the net, but I can't find any such binding. > > Has anyone made such a binding? If not I was thinking about using swig > and the wxpython interfaces as the starting point for a wxwidgets > binding for ocaml. Has anyone tried to do this in the past? Any > thoughts on the issue? I've looked into this in the past, but we ended up using Gtk + Gtk-Wimp on Windows, which worked quite well. Here are my observations on going the WxWindows route though: (1) WxWindows is pretty good. (Ah, looking at their website, I see they've renamed it to WxWidgets!). WxWIDGETS is pretty good. It's a very complete way to develop cross-platform applications. In particular, it has platform-specific file and print dialogs, which you won't get if you use Gtk. In fact if you use Gtk you won't get print dialogs at all - I had to write my own print dialog for Windows which was no fun at all. (2) There seem to be three decent approaches to using WxWidgets under OCaml: Python, Perl or native. Native is going to be the best, but is going to take a heck of a lot of effort. (3) Python or Perl: it's easiest just to use PyCaml or Perl4Caml to interface with the Wx* libraries under those languages. I don't see why you'd want to go through SWIG for this. (4) Native: definitely the best performance and the cleanest approach, however it's lots of work. (Now of course if you wanted to *hire* Merjis to do the work, contact me off-list ... :-)Daan Leijen said:
I have created a binding from Haskell to wxWidgets, called wxHaskell. You can find more information (and nice screenshots) at http://wxhaskell.sourceforge.net There is also a paper about it at http://www.cs.uu.nl/~daan/pubs.html I also know that there is a student in France that has made a lot of progress on an O'Caml binding to wxWidgets (as he contacted me a few times about technical issues). He also used the wxEiffel C wrapper (that wxHaskell uses) Personally, I am very impressed with wxWidgets: wxHaskell works very well across the main platforms (MacosX, Windows, and GTK) and is quite stable. It is also nice that wxWidgets uses native controls on each platform, giving an application native look-and-feel. A particularly pragmatic route to implementing a wxWidgets binding to wxHaskell would adapt the wxDirect program of wxHaskell to generate O'Caml bindings and just copy the wxHaskell model -- it would fit O'Caml quite well, especially when OCaml objects are used to model the C++ classes.Micha answered the OP:
> Has anyone made such a binding? If not I was thinking about using swig > and the wxpython interfaces as the starting point for a wxwidgets > binding for ocaml. Has anyone tried to do this in the past? Any > thoughts on the issue? I have started some time ago with this and interfaced a few classes of wxwidgets, just to see how it works. I implemented (parts of) the application , window and menu classes and parts of the event system ( you can use 'connect' to connect ocaml functions to menus events); So the basic way was ok. I just wanted to do something different ;-) I don't like the swig way so I didn't use it, but it's a pain to go c++ -> c -> ocaml, massive typing :-), maybe c++ -> c -> ocamlidl would be better...Basile Starynkevitch also answered:
> Was looking on the web for an alternative to using GTK+ on Windows (no > flames please) and found WxWidgets. It looks like a quite nice GUI > toolkit. .... There is also the FOX toolkit www.fox-toolkit.org which claims also to be both on Unix & Windows. It is a nice (cross-platform) GUI toolkit (in C++) also (but there is no Ocaml binding to it). > Has anyone made such a binding? If not I was thinking about using swig > and the wxpython interfaces as the starting point for a wxwidgets > binding for ocaml. Has anyone tried to do this in the past? Any > thoughts on the issue? If there is a Python binding to it already, you might also consider coding a WXwidget "server" by coding (in C) the few hooks to make a program using WxWidgets which listen on a pipe (or whatever the Windows equivalent is) for Python instructions, and sending back (to your application) some textual protocol. I already coded this in GUIS (see http://starynkevitch.net/Basile/guisdoc.html for more) for GTK2 (and you can borrow some code if you like). IMHO, the costly coding is to interface all the WXWidget API. If it has been done once (for Python) you might try reusing it - either with Swig (for Ocaml) or by pluggin a python interpreter. The GUI could even (as GUIS suggest) run in a different process than your Ocaml application. NB: I've got no knowledge on Windows, and no significant experience with Swig or WxWidgets. So take all above with several grains of salt.SooHyoung Oh answered as well:
I tried to implement Ocaml binding for wxWidgets a few months ago which followed the same method as wxHaskell (http://wxhaskell.sourceforge.net/). Anyone who has interest in this job can find some comments and tar ball at http://pllab.kaist.ac.kr/~shoh/ocaml/wxcaml/doc/index.html . There is an example program which uses frame, menubar, menu, statusbar widgets. Current Status: I used "ocamlidl" to generat types and functions for ocaml which was done without any problem. And then I tried to implement "wxcaml" as object-oriented style like LablGtk but it required too much time. Any comments?
Archive: http://caml.inria.fr/archives/200409/msg00057.htmlAlex Baretta said:
skaller wrote: > Alex Baretta wrote: > > > I wish to let you know that the first application of ocaml to realtime > > industrial control has succeeded. > > > Nice job! Now we all want to know -- how did the > Ocaml GC stand up? How did you tweak it? :) > Sorry for not answering earlier. GC simply is not an issue. We allocate a lot, but newly allocated blocks tend to have a very short life. The GC is kept latent during PLC rounds and activated between rounds with heap compaction disabled. The full_major collection is an order of magnitude faster than the cycle time we require, and since we run it sistematically between rounds it runs in constant and predictable time. The only unpredictable latencies are due to heap compaction, but we only run heap compaction when the system is known to be in quiescent state until user input.
Archive: http://caml.inria.fr/archives/200409/msg00350.htmlYutaka Oiwa announced:
From the computer room at ICFP2004 in Snowbird Resort, I announce a beta version of my combinator-based regular-expression match library which supports list (Kleene-*) binding. This library provide a set of typed "combinators" which can be used to construct "regular expression matcher", which tests strings against regexps and capture the matched substring in various ways. Especially, powerful "repeat" combinator, which corresponds to * and + operators in conventional regular expression notation, returns all values captured inside as a list value. For example, the small code below open Regexp_pp_ng let s = "1 2 3 4 5" in match_string s (repeat ~sep:spacesA int_decimal) (fun x -> x) returns [1; 2; 3; 4; 5]: int list. All combinators are given static types and any mismatch of value types and matcher types are statically rejected. The implementation is available from a subversion repository. Using subversion, you can checkout the URL https://www.oiwa.jp/svn/regexp-ocaml/branches/combinators/ to get the up-to-date implementation, or you can directly access the above address by web browsers to see the latest revision. There is also a ViewCVS interface at the following address. http://www.oiwa.jp/viewcvs/regexp-ocaml/branches/combinators/ See regexp_pp_ng.mli for interfaces, and regexp_pp_ng_test.ml for some example of the use of this library. It may work partially on some older OCaml, but for real use it requires a newer version (3.07 or later) which supports the relaxed value restriction. I plan to construct a neat syntax sugar over this library and build a next-generation version of Regexp/OCaml library. Any comments are welcome.Skaller asked and Yutaka Oiwa answered:
> Can you explain why/how Pcre is being used? The reason is simply current implemenentation convenience. It is stable, has enough features (e.g. unlimited number of captures, non-capturing groups, much of helper functions and runtime features, and is well-performing. My intension is not to implement automata engine by myself, at least in near future. However, as you can see in README in Regexp-OCaml (main version), my future plan includes supporting backends other than PCRE/OCaml. Having its own regexp parser and limiting regexp syntax to strict regular language are the provision for possible future. At the time of OCaml 3.07 released, I really considered to support the standard Str module, but unfortunately current Str lacks some of the features required by current Regexp/OCaml implementation. Anyway, backend is backend. And also, frontend is frontend. Period. It can be highly independent once it designed so, and my interests are mainly in the frontend part. I highly appreciete supports from people working on the backend part. Multilingualization is one in current high-priority to-do list. At least one of the users requested me to support EUC-JP patterns, and you might be the second person :-) I am considering how to support M17N feature: it may depends to underlying backends (e.g. Camomile?), or it may be supported solely in the frontend layer, by encoding multibyte handling into regexps. This trick is used in the Japanese port of Perl interpreter on MS-DOS, and (at least) one of Japanese handling module for Perl5. # As you can imagine, just using M17N feature of underlying library is # not sufficient: internal regexp parser must also modified to accept # multibyte-encoded regular expression. This is one of the reason that # curent Regexp/OCaml does not support UTF8 option of PCRE/OCaml. For supporting list-binding of Kleene-stars, I am very interested in richer backends which supports such features. Alain Frisch's recent posting has interested me. There is also a talk with related title in ICFP04, although I had not yet read the paper. However, I feel at the same time that backend is not a current show-stopper: it is truly better to have such backends, but it can be emulated without that, As I had shown in the combinators. I can wait for a while for theretical/practical progresses. Current problem is mainly the frontend: there are many language-design problems once we introduce nested bindings. I already had a discussion with some people in ICFP04, and I hope more.
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.