Hello,Here is the latest Caml Weekly News, for the week of April 29 to May 06, 2008.
1) ocaml-gettext v0.3.0 2) Core has landed ======================================================================== 1) ocaml-gettext v0.3.0Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/a0364b8f859d5c93# >
------------------------------------------------------------------------ ** Sylvain Le Gall announced: General: ocaml-gettext is a library that enables string translation in OCaml. The API is based on GNU gettext. It comes with a tool to extract the string which needs to be translated from OCaml source file. This enable OCaml program to output string in the native language of the user (if you also provide a file containing the translation of the english string contains in the program to the one in the native language of the user).The translation is based on string (this means that you need to provide a
string and not a unique identifier, like in some other catalog system). This string is in english, and will be returned if the native language of the user doesn't have translation catalog. Changes: v 0.3.0 has been long awaited but is now ready. It fix a lot of bugs concerning merging PO and POT file (multiline comments, UTF-8...). This is also the first release that works with camlp4 3.10. This new version doesn't need camlidl and ocaml-ast-analyze anymore, in order to simplify installation. When building, it is also possible to not use Camomile in favor of a simple gettext C library. Links: <http://le-gall.net/sylvain+violaine/ocaml-gettext.html><http://le-gall.net/sylvain+violaine/download/ocaml- gettext-0.3.0.tar.gz>
======================================================================== 2) Core has landedArchive: <http://groups.google.com/group/fa.caml/browse_frm/thread/4760abaf6c68ea7d# >
------------------------------------------------------------------------ ** Yaron Minsky announced, spawning a huge thread: We are proud to announce the first public release of core, Jane Street's own alternative to OCaml's standard library. We use this library as the base for our own development, and we hope people on the outside will find some use for it as well. People should be warned that core is still in flux: there are interfaces that we have plans to change, so if you're not willing to come along for the ride, you shouldn't use it. Also, be warned that conformance with the OCaml standard library is not a goal, and we have already deviated from it in a number of ways. It's also worth noting that we have only used and tested this library on x86 and x86-64 on Linux, and we make no claims about other platforms. You can find the library here: <http://ocaml.janestcapital.com/?q=node/13> along with three other libraries that you will need to use along with it: type-conv, sexplib and bin-prot. These three libraries provide macros for generating functions for serializing and deserializing types. sexplib uses a human-readable s-expression format, and bin-prot uses a high-performance binary protocol, and type-conv is the common base of the other two libraries. This is also the first public release of bin-prot, and like sexplib, that library can be used independently of core. If you have any comments or patches, we'd love to hear about it. Our blog is a great place for comments: <http://ocaml.janestcapital.com/?q=node/27> and patches should be sent to [EMAIL PROTECTED] All of the released libraries are licensed under the LGPL-plus-linking-exception that is used by the OCaml standard library. ** Richard Jones added: Thanks - I think this is an impressive contribution to OCaml & open source. For those not aware of the full extent of this library, I went through and noted down this non-exhaustive list of features: - Bag (set type with duplicates) - Bigbuffer (unlimited Buffer type) - Bigstring (unlimited String type) - 8/16/32/64-bit signed/unsigned binary packing functions - Bool type - Safe finalization for reading/writing files - Function composition operators - Enhanced versions of stdlib modules such as Arg, Array, Printf, etc. - Mutexes - CRC functions - Dequeue type - Doubly-linked list type - Enhanced exception module - Fast hash table - Force once (thunk that can be forced only once) - Functional queue type - Min-heap type - Enhanced input/output channels - Closed interval type - Interval set type - Read files as lines - Linux-specific syscalls such as sendfile, get/set TCP options, epoll, splice - Memoization - Piece-wise linear interpolation of floats - Polymorphic map and set - Find size of OCaml structures - Space-efficient tuples - Synchronized queues - Thread-safe queues - Convenience functions for Unix times - Timed events - Tuple convenience functions - Extended Unix module filling in some missing syscalls such as sync, getrusage, inigroups, etc. There's a Fedora package here: <https://bugzilla.redhat.com/show_bug.cgi?id=445074> but note you will also need these dependencies: <https://bugzilla.redhat.com/showdependencytree.cgi?id=445074> It would be nice to have bin-prot working on all architectures ... ** Markus Mottl replied: > It would be nice to have bin-prot working on all architectures ... The biggest obstacle to this is that the current implementation assumes little endian machines. Both 64bit and 32bit are fully supported on these platforms. It would certainly be possible to support other architectures, but good portability and performance are not easily combined here. If performance does not matter, it would be easiest to just convert all data to the protocol already used by little endian machines. This would noticably slow down communication with/among machines that are not little endians. Since the vast majority of computers are little endians, this won't matter for most people. OCaml takes a similar approach. Note that communication _among_ machines with different endianness, assuming that they all have the same byte layout, should work, too, with the current binary protocol. At least if you do not mix 32/64bit machines there... ** Stefano Zacchiroli then said and Markus Mottl replied: > Sounds like a reasonable solution indeed. Way better than not having> bin-prot on some archs (this is particularly annoying in Debian, where
> we support several big endian machines; the status quo would mean no> Core on them and in turn no application using Core on them. Currently we > patched Core on that architecture to remove the bin-prot dependency, but
> is a rather hackish solution I would like to get rid off). > Do you plan to implement such a solution in forthcoming releases? We currently do not have any immediate need and man power to fully support big-endian machines (we also don't have access to any), but we'll gladly accept patches. This could be implemented using platform-specific macros as is the case with 32/64bit. This is what works / doesn't work as of now: *) Big-endian and little-endian machines cannot communicate with each other for anything but very specific cases. Don't use the binary protocol in such heterogeneous environments. *) 32 and 64 bit, little-endian architectures can communicate freely, assuming, of course, that integers do not overflow on 32bit. This is tested at runtime to prevent hard to debug errors. *) 32bit big-endian machines can communicate with each other freely. 64 bit big-endians can communicate with each other freely, too, but not necessarily with 32bit big-endians: values of type int64, etc., may not necessarily be communicated correctly. Note, too, that you should exclusively use the automatically generated converters on big-endian machines. The hand-written (slower) ones for the basic types are intended mostly for testing purposes only, and will not work when mixed with a different endianness (they assume little-endians). Thus, it certainly makes sense to package the binary protocol for big-endians, too, as long as people are informed of what works. Since almost nobody uses big-endian machines, most users won't care. But I'd surely be happy to see a patch to fully support all architectures...** Following a comment on the absence of a Windows port, Yaron Minsky said:
Agreed. We have a limited amount of energy to devote to a Windows port at this time, but we would be happy for core to work well on Windows. Most of
the library depends only on the version of OCaml, so it should be prettyeasy to port. We've done a bit of ifdef work to make it a tad more portable
(it's known to compile so far on FC5, Centos/RHE 4 and 5, and OS X.) ======================================================================== 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([EMAIL PROTECTED]) and I'll mail it to you, or go take a look at
the archive (<http://alan.petitepomme.net/cwn/>) or the RSS feed of the archives (<http://alan.petitepomme.net/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://alan.petitepomme.net/>The hacker: someone who figured things out and made something cool happen.
.O. ..O OOO
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ caml-news-weekly mailing list caml-news-weekly@lists.idyll.org http://lists.idyll.org/listinfo/caml-news-weekly