On Thu, Apr 08, 2004 at 06:44:15PM +0200, Bruno.Verlyck@inria.fr wrote:
> - read-write file handles: You can get them wit Unix.openfile and
>   Unix.dup.  Then with Unix.{in,out}_channel_of_descr, you can use
>   the Pervasives I/O functions.

I have discovered that, but it seems that I don't fully understand the
buffering semantics over on the Pervasives side.  For instance, it's not
entirely clear what happens if I write something to an out channel, then
seek somewhere via that channel, then read via the other channel.  The
results have not always been what I expected.  I've also tried to use
that trick to work with sockets, and the results there are *definately*
not what I expected.  But I didn't look into it in any great detail, so
I may have been missing something obvious.  (Pervasives appears to
sometimes make an underlying call to read or write a different number of
bytes than I requested -- which can be a problem for network protocols
where this can cause deadlock)

> - string handling: look at my (rather full-featured) Cstr library
>   (http://pauillac.inria.fr/cash/cstr/); it doesn't answer syntax
>   questions, but those are a different matter.  It doesn't implement
>   negative indices, but if you dare looking at the sources, *maybe*
>   only the check- macros have to be modified.

That looks great.  Has a lot of stuff I'd use.  It looks like it's
separate from cash; is that correct?  (If so, I'll package it up for
Debian right away <g>)

> As for flags that aren't in Unix (or ulimit), you touch a strong
> problem for library implementors: they are defined only for some OSes,
> and are a pain to implement and test when you have no personal use for
> them.  Yes, laziness.  On the other hand, you ask for free lunch.

I know what you mean.  It's going to mean a lot of autoconf tests :-)

And yeah, I know about volunteer time...  I try to do what I can to help
out (such as packaging things for Debian).  I don't have the requisite
experience yet to touch anything that deals with C or camlp4.  In time,
perhaps. :-)  I am, however, working on an IMAP library, time
permitting.  I have everything necessary to make that go and the basic
parser is complete already (I've gotta say -- OCaml streams are the
nicest thing since sliced bread for parsing complex grammars <g>)

> (Another pain is making any general library, moreover part-time; even
> Cstr, which is not big, nor very complicated, that I didn't design,
> took me five times what I thought; OK, I played some games with
> camlp4, but documenting and testing it is a lot of boring work).

That's true.  I have found OUnit to be very nice for testing, BTW.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners