Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Dynamically evaluating OCaml code
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-04-08 (17:55)
From: John Goerzen <jgoerzen@c...>
Subject: Re: [Caml-list] Dynamically evaluating OCaml code
On Thu, Apr 08, 2004 at 06:44:15PM +0200, 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
>   (; 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 Archives:
Bug reports: FAQ:
Beginner's list: