Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
From: Bruno.Verlyck@i...
Subject: Re: [Caml-list] Dynamically evaluating OCaml code
   Date: Thu, 8 Apr 2004 12:55:19 -0500
   From: John Goerzen <jgoerzen@complete.org>

   On Thu, Apr 08, 2004 at 06:44:15PM +0200, Bruno.Verlyck@inria.fr wrote:
   > - read-write file handles: You can get them with 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.
You aren't a lot better in C.  What does Posix/SUS V2 says for fopen ?
    When a file is opened with update mode (+ as the second or third
    character in the mode argument), both input and output may be
    performed on the associated stream.  However, output must not be
    directly followed by input without an intervening call to fflush()
    or to a file positioning function (fseek, fsetpos() or rewind()),
    and input must not be directly followed by output without an
    intervening call to a file positioning function, unless the input
    operation encounters end-of-file.
This is error-prone at least.

As for OCaml buffering semantics:
- you begin to understand why there's no read-write channel: a lot of
  complexity for a seldom used functionality;
- those having been banned, the OCaml I/O system makes no effort to
  ease things for you: the two channels are independently buffered,
  they don't known of each other, reading won't see your last
  modifications if nothing forces an update of the buffer.
Beware: this is what I remember, io.c is of course the ultimate
reference.

   (Pervasives appears to sometimes make an underlying call to read or
   write a different number of bytes than I requested -- which can be
This is called (you guessed it) buffering.
   a problem for network protocols where this can cause deadlock)
If it gets in your way, don't use Pervasives (but Unix.{read,write}).

   > - string handling: look at my (rather full-featured) Cstr library
   >   (http://pauillac.inria.fr/cash/cstr/);
   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>)
That's correct.  Thank you for the packaging.  Some bugs are fixed in
the CVS version (hopefully none introduced.. :-).

Bruno.

-------------------
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