[cwn] Attn: Development Editor, Latest Caml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue May 6 00:30:05 PDT 2008
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.0
Archive: <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 landed
Archive: <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 opensource at janestcapital.com.
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 pretty
easy 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
(alan.schmitt at polytechnique.org) 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20080506/deffbb73/attachment.htm
-------------- 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/20080506/deffbb73/attachment.pgp
More information about the caml-news-weekly
mailing list