Version française
Home     About     Download     Resources     Contact us    
Browse thread
announce: OCaml NAE releases Cf-0.5 and Iom-0.1
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: james woodyatt <jhw@w...>
Subject: announce: OCaml NAE releases Cf-0.5 and Iom-0.1
everyone--

Today, the OCaml Network Application Environment (NAE) has released 
maintenance updates of two of its published libraries.  As its project 
page on SourceForge.Net says, OCaml NAE is "a collection of Objective 
Caml libraries to support the development of concurrent, 
single-threaded Internet application servers."

For downloads and more information, please see:

	<http://sf.net/projects/ocnae/>

The two libraries updated in this release are the Core Foundation (Cf) 
and the Reactive I/O Monad (Iom).  The Cf library was formerly known as 
the Pagoda Core Foundation.  The complete CHANGES records for both 
libraries since their previous releases follows below.


===== OCaml NAE Core Foundation (cf) library =====
===== Version 0.5 =====

Highlights of the changes:

+ Many bugs fixed (some critical).
+ IPv6 socket addresses are now a triple, containing the scope 
identifier.
+ Fixed a very bad stack leak problem in the [Cf_gadget] scheduler.

--- [Cf_deque]
     Fix major bug in [fold] that caused a BUS ERROR (ack!), and also 
fixed
     [filter] so that it uses the non-recursive [fold] function here 
instead of
     going to the extra work of using [Cf_seq.fold].

--- [Cf_rbtree]
     Fix a bug in [iterate] (found by Craig Falls; thanks Craig!) caused 
by a
     stoopid typo.  Caused some elements to be iterated twice, and 
others not
     at all.

--- [Cf_gadget]
     Moderate surgery on the scheduler to fix a bad stack leak.  The new 
code
     is probably a tiny bit more efficient too, because I got rid of some
     unnecessary uses of {Lazy.t} in places, and there is a bit less 
lifting
     between monads.  I didn't benchmark it, though.

--- [Cf_socket]
     Added a special case for Mac OS X to work around a bug in Apple's 
network
     stack that errors in connect(2) on a non-blocking socket do not get 
in
     the errno system variable.  You have to get them out of the socket 
with
     the SO_ERROR socket option.

--- [Cf_ip4_addr]
     Make the network subnet manipulation functions cope with networks 
that
     are not unicast networks.  (Yes, there are multicast ranges that 
can be
     treated like subnets.)

--- [Cf_ip6_proto]
     Add a third element to the socket address type: an int32 for the 
scope id.

--- [Cf_ip6_addr]
     Fix the [v4compat] and [v4mapped] address type tags so that they are
     actually polymorphic variants, like they're supposed to be.  This 
was
     another stoopid typo, but I found it myself.

--- [Cf_netif]
     Fixed the C-language code to call if_nametoindex() with the proper
     arguments.  Again, this was a stoopid typo.

--- [Cf_poll]
     A minor change to the commented bits of debugging code in the 
middle of the
     select loop to use [Cf_journal] instead of my [xprintf] hackery.

--- {TESTS}
     Added a test for the [Cf_gadget] scheduler to detect stack leaks.


===== OCaml NAE Reactive I/O Monad (iom) library =====
===== Version 0.1 =====

Highlights of this release:

+ Rewrote the [Iom_sock_stream.endpoint] reactor to fix bugs (and 
hopefully
   improve performance in some edge cases).
+ More optional tests coded (but they're still suboptimal, and maybe 
buggy).

--- [Iom_sock_stream]
     Rewrote the [endpoint] reactor to use less consing, i.e. the state 
is now
     a couple of mutable objects derived from [Cf_poll.event].  Events 
are
     plumbed around the inside of the reactor in shorter paths.

--- [T_iom]
     Change to be compatible with cf-0.5 notion of IPv6 socket 
addresses, which
     now contain an int32 element for the scope identifier.

--- {New Tests}
     Added a couple of new programs which help me work out bugs.  I 
don't think
     these programs are really done, since they don't quite give me the 
control
     I need to be able to adequately test and benchmark the performance 
of code
     based on the [Iom] library.  I'll probably need to hammer on these 
for
     awhile before I have something to document.  In the meantime, 
consider them
     curiosities for your amusement.

-- 
j h woodyatt <jhw@wetware.com>