ocamlnet-devel — Developer discussion

Re: [Ocamlnet-devel] I am writing a NNTP client using Ocamlnet.

[Gerd S. <in...@ge...>]

On 2002.03.15 05:58 Patrick M Doane wrote:
> You mention one of my main complaints I have with current POP interface --
> messages are read completely before returned to the client.  Initially,
> the object channel returned to the client would read data on demand.
> Unfortunately, if a client didn't read all of the data out of the channel,
> then the protocol would be in an inconsistent state.
> 
> To avoid this, I added a quick fix to read the entire message before
> returning it.
> 
> Here are the choices I see related to this issue:
> 
>   - API has invariants that can't be checked by the compiler (e.g. it is
> an error to not cloes the channel before sending another command).  A
> custom in_obj_channel could be written that could fix the problem
> discussed above.
> 
>   - API takes a higher order function to ensure proper control flow.  For
> example:
> 
>   method retr : msgno:int -> (string -> unit) -> unit
> 
> Here the callback is invoked for each line in the message body.  This
> complicates usage because it requires the use of side effects to be
> useful.  An additional accumulator value can be used to make this more
> like a fold function:
> 
>   method retr : msgno:int -> (string -> 'a -> 'a) -> 'a -> 'a
> 
> But this needs polymorphic methods, which are not currently available.
> Or, the OO interface could be dropped for a Module based interface.
> You'll find that the NNTP prototype code was done in this fashion.
> 
>   - API can remain inefficent but simple.  Ignore the problem completely.
> 
> Any opinions?

The higher-order functions seem to be similar to an out_obj_channel:

  method retr : msgno:int -> out_obj_channel -> unit

retr would call output_string until the message is complete, and then close the
channel. So the protocol state is fully controlled by the POP module, and not 
by the user of the module.

This could also be the solution for the NNTP client. If used as proxy, the
message must be written to the output descriptor anyway, so the out_obj_channel
may be easier to use than an in_obj_channel.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   ge...@ge...
Germany                     
----------------------------------------------------------------------------

Re: [Ocamlnet-devel] I am writing a NNTP client using Ocamlnet.

[Gerd S. <in...@ge...>]

Hi,
On 2002.03.15 04:14 Glyn Webster wrote:
> Well, I have it written, and I am currently testing it.  If you would like to 
> see what I have done so far, please let me know.

Yes, I am curious.

> There are two parts to it: 
> 
> Newnews:  
> The NNTP client.  This is low level: the methods correspond to NNTP commands. 
> I made its interface as similar to the experimental Pop3 client's interface 
> as possible.
> 
> Netresponse: 
> Input and output filter channel classes for NNTP and POP3 "text responses".  
> 
> I saw that the experimental Pop3 client read whole text responses into string 
> channel objects.  I didn't really like that idea because I mean to use my 
> NNTP client to write a killfiling proxy. If that read in whole responses 
> before writing them it would cause unnecessary delays.  (It might also be a 
> good idea to use something like this in the Pop3 client, because some emails 
> can be enormous.)  

This is an important point. It is not a good idea to collect large messages
in memory. Not only because of the delays and the waste of memory, but there
is effectively a limit of 16MB for strings on 32 bits architectures. It actually
limits functionality.

> Unfortunately I didn't use the Netchannels.input_filter and 
> Netchannels.ouput_filter classes: I plowed ahead without realizing what they
> where for!  So maybe I should rewrite Netresponse.  

These classes have been designed to apply a low-level encoding to a byte stream,
e.g. base64. Maybe I should mention that in the description of input/output_filter?

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   ge...@ge...
Germany                     
----------------------------------------------------------------------------

Re: [Ocamlnet-devel] I am writing a NNTP client using Ocamlnet.

[Patrick M D. <pa...@wa...>]

Thanks for putting together an NNTP client!  If you're interested, there
was also some earlier prototyping of the NNTP protocol that is available
in the CVS repository.  It is under the prototype directory.

You mention one of my main complaints I have with current POP interface --
messages are read completely before returned to the client.  Initially,
the object channel returned to the client would read data on demand.
Unfortunately, if a client didn't read all of the data out of the channel,
then the protocol would be in an inconsistent state.

To avoid this, I added a quick fix to read the entire message before
returning it.

Here are the choices I see related to this issue:

  - API has invariants that can't be checked by the compiler (e.g. it is
an error to not cloes the channel before sending another command).  A
custom in_obj_channel could be written that could fix the problem
discussed above.

  - API takes a higher order function to ensure proper control flow.  For
example:

  method retr : msgno:int -> (string -> unit) -> unit

Here the callback is invoked for each line in the message body.  This
complicates usage because it requires the use of side effects to be
useful.  An additional accumulator value can be used to make this more
like a fold function:

  method retr : msgno:int -> (string -> 'a -> 'a) -> 'a -> 'a

But this needs polymorphic methods, which are not currently available.
Or, the OO interface could be dropped for a Module based interface.
You'll find that the NNTP prototype code was done in this fashion.

  - API can remain inefficent but simple.  Ignore the problem completely.

Any opinions?

On Fri, 15 Mar 2002, Glyn Webster wrote:

> Well, I have it written, and I am currently testing it.  If you would like to
> see what I have done so far, please let me know.
>
> There are two parts to it:
>
> Newnews:
> The NNTP client.  This is low level: the methods correspond to NNTP commands.
> I made its interface as similar to the experimental Pop3 client's interface
> as possible.
>
> Netresponse:
> Input and output filter channel classes for NNTP and POP3 "text responses".
>
> I saw that the experimental Pop3 client read whole text responses into string
> channel objects.  I didn't really like that idea because I mean to use my
> NNTP client to write a killfiling proxy. If that read in whole responses
> before writing them it would cause unnecessary delays.  (It might also be a
> good idea to use something like this in the Pop3 client, because some emails
> can be enormous.)
>
> Unfortunately I didn't use the Netchannels.input_filter and
> Netchannels.ouput_filter classes: I plowed ahead without realizing what they
> where for!  So maybe I should rewrite Netresponse.
>
> --
> Glyn Webster ~  Simplicity himself.
>
> _______________________________________________
> Ocamlnet-devel mailing list
> Oca...@li...
> https://lists.sourceforge.net/lists/listinfo/ocamlnet-devel
>

[Ocamlnet-devel] I am writing a NNTP client using Ocamlnet.

[Glyn W. <gl...@wa...>]

Well, I have it written, and I am currently testing it.  If you would like to 
see what I have done so far, please let me know.

There are two parts to it: 

Newnews:  
The NNTP client.  This is low level: the methods correspond to NNTP commands. 
I made its interface as similar to the experimental Pop3 client's interface 
as possible.

Netresponse: 
Input and output filter channel classes for NNTP and POP3 "text responses".  

I saw that the experimental Pop3 client read whole text responses into string 
channel objects.  I didn't really like that idea because I mean to use my 
NNTP client to write a killfiling proxy. If that read in whole responses 
before writing them it would cause unnecessary delays.  (It might also be a 
good idea to use something like this in the Pop3 client, because some emails 
can be enormous.)  

Unfortunately I didn't use the Netchannels.input_filter and 
Netchannels.ouput_filter classes: I plowed ahead without realizing what they 
where for!  So maybe I should rewrite Netresponse.  

-- 
Glyn Webster ~  Simplicity himself. 

[Ocamlnet-devel] Announcement: ocamlnet-0.92 has been released

[Gerd S. <in...@ge...>]

Hi,

The ocamlnet project releases a new version of its library, the successor of
the well-known netstring library. This release mainly focuses on smoothing
the interoperation of its modules, especially by using the concept of
channel objects everywhere. There are also a number of new features, see
below.

Ocamlnet has now a rich set of functions for the following tasks:

- Dealing with stacks of channel transformers, e.g. "read a certain section
  of a file and decode the BASE64 strings, and then convert everything
  to UTF-8". This can usually be done without allocating large buffers,
  but by processing the data block by block.
  (NEW)

- Separate a channel into sections, and process the sections independently.
  For example, one can define a boundary string, and read a file section
  by section.
  (NEW)

- Encode and decode strings, convert between character sets.
  (The character set conversion needs to be revised.)

- Parse and print date strings

- Parse and print HTML text

- Parse and print MIME mail messages. There are now high-level functions
  for manipulating mail messages (NEW)

- Compose mail messages and send them (using sendmail). The message
  composer creates MIME messages, too, and can deal with arbitrary 
  character sets.
  (NEW)

- Parse and print URLs (This module is not yet up to date)

- Ocamlnet includes a complete and modularized implementation of the CGI
  protocol.
  (UPDATED)

- Ocamlnet has experimental support for building application servers
  with Apache and the Jserv protocol
  (NEW)

- Ocamlnet includes an experimental POP3 client

The library has been rewritten such that many functions accept so-called
netchannels (or channel objects) as input/output media. The idea is very
simple: a netchannel either represents a real channel, a buffer, a string,
a lexer buffer, a filter (or some of the more complicated entities). A
netchannel for input has methods for reading from the channel, for example

let line = ch # input_line()

to read the next line, and an output netchannel provides the usual output
methods, like

ch # output_string "xyz"

to output a string to the netchannel. The same type is used no matter
what kind of thing the netchannel really is:

let ch1 = new output_channel stdout ;;

let buf = Buffer.create 100 ;;
let ch2 = new output_buffer buf ;;

Here, ch1 is a netchannel on top of O'Caml's built-in out_channel, and
ch2 is on top of a buffer. Ocamlnet contains many functions that can be
applied to any kind of netchannel, for example

write_mime_message msg ch1 msg    (* write msg to stdout *)
write_mime_message msg ch2 msg    (* write msg to the buffer buf *)

This helps a lot because it saves the programmer from providing the
same functionality for various data types.

A more complicated netchannel is

let ch3 = new output_filter (new Base64.encoding_pipe()) ch2 ;;

Any output to ch3 is BASE64-encoded and transferred to ch2. The netchannels
can be stacked without any restriction, and if the stack is not too high,
the performance loss is quite minimal. For instance, the BASE64 encoding 
is applied block by block, so that the additional costs for method lookups
must only be paid for a whole block, not for a single byte.

Another interesting means of programming are the so-called netstreams.
These are input channels with look-ahead, i.e. you can look at the
bytes you will read in the future. The look-ahead buffer can by enlarged
as needed. It is possible to form substreams of netstreams, in order to
view only a certain section of the whole stream. The substream will return
EOF where the section ends, but the main stream can of course read beyond
the section boundary. (See Netstream.) Again, it is possible to recursively
apply substreaming to itself. An application is the parser for nested
multipart MIME messages.

Netchannels and netstreams are two examples illustrating the current
direction of Ocamlnet development. We are trying to find out the basic
types that are needed everywhere, and that make up the glue between
the various parts of the library. 

And before I forget it the second time: Ocamlnet includes a routine to
translate Str regular expressions to Pcre regular expressions (because
we are only using Pcre now).

Ocamlnet can be found here:
- Project page: http://sourceforge.net/projects/ocamlnet
- Home page: http://ocamlnet.sourceforge.net
- Download of release 0.92:
  http://prdownloads.sourceforge.net/ocamlnet/ocamlnet-0.92.tar.gz
  http://www.ocaml-programming.de/packages/ocamlnet-0.92.tar.gz

If you want to join the Ocamlnet developers team, please subscribe to the
ocamlnet mailing list, and describe what you want to contribute.
(More information on the project page.)

Enjoy it,

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   ge...@ge...
Germany                     
----------------------------------------------------------------------------

[Ocamlnet-devel] Next release coming soon

[Gerd S. <in...@ge...>]

Hi list,

I think it is now time for the next release of ocamlnet. I am
going to test the baby more intensively the next days. The test
release it at:

http://ocamlnet.sourceforge.net/testrel/ocamlnet-0.92-test1.tar.gz

Especially the netcgi library, and here especially the file
upload stuff have more or less been rewritten. It would be nice
to have the same degree of stability as usual, so I would be
glad if somebody else would do some tests, too.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   ge...@ge...
Germany                     
----------------------------------------------------------------------------

[Ocamlnet-devel] [ ocamlnet-Patches-510144 ] update to ocaml 3.04

[<no...@so...>]

Patches item #510144, was opened at 2002-01-29 05:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=319774&aid=510144&group_id=19774

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pierre Boulet (pboulet)
Assigned to: Nobody/Anonymous (nobody)
Summary: update to ocaml 3.04

Initial Comment:
Due to the change in the dealing with labeled
arguments, the labels are now mandatory when using the
PCRE library. Two calls to this library have to be
modified.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=319774&aid=510144&group_id=19774

Re: [Ocamlnet-devel] DNS protocol

[Guillaume V. <do...@fr...>]

hi,


>   (This is also a possibility to "market" your code, because the
>   standard library functions for DNS block all threads.)

I didn't understand that ...

What is market ?

> Sorry that I cannot comment on the quality of your code. I am not a
> DNS
> expert, but I am sure others are.

Did you test the host command ?

Bye,
guillaume
--
mailto:do...@my...

ICQ uin : 1752110   PGP key id : 0x61BF5A03
Page ouebe : http://guedou.penguinpowered.com

     "Everybody be cool. You be cool" - Seth Gecko

Re: [Ocamlnet-devel] DNS protocol

[Gerd S. <in...@ge...>]

Guillaume wrote:
>hi guys,
>
>My school project is 'finish', it's an attempt to do an host command
>and a dns server in ocaml.
>
>Maybe that i can modify the Dns module and add it to ocamlnet.
>
>If you have time to look at it:
>http://guillaume.valadon.net/odns/
>
>There is a README and a manual in docs/ if you are curious.
>
>bye,
>guillaume

Hi Guillaume,

a DNS implementation would surely be attractive for ocamlnet. I had a
quick glance at your code, and before you add to the CVS repository,
I would like you to change the following:

- Please use prefixes for your toplevel modules, e.g. 
  dns_resolver instead of just resolver. 

- We are using PCRE instead of Str for regular expressions. This is not
  only a cosmetic change, because Str bases on the GNU regex library
  which is under the GPL. There is the module Netstring_str that helps
  migrating to PCRE. Your code even benefits from this change, because
  PCRE is thread-safe while Str is not.

  (This is also a possibility to "market" your code, because the
  standard library functions for DNS block all threads.)

- Please remove the 'x' bit from the files that are not executables.

- It would be nice to have mli interfaces for all modules. At least interfaces
  for the modules making up the API are necessary, "internal" modules
  like Tools are not that important

- We give the users of ocamlnet the possibility to choose whether they
  want to install with findlib or not. This affects mainly your Makefile.
  It will even become simpler if you integrate dns into the ocamlnet
  infrastructure (see for example the Makefile for pop).

- We have not yet decided about the overall documentation. The direction
  seems to be ocamldoc.

Sorry that I cannot comment on the quality of your code. I am not a DNS
expert, but I am sure others are.

You will need a sourceforge account. Once you have it, I can add you 
to the list of developers.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             64293 Darmstadt     EMail: ge...@ge...
Germany                     
----------------------------------------------------------------------------

[Ocamlnet-devel] My latest changes

[Gerd S. <in...@ge...>]

Hi list,

In the last weeks I have worked on the netstring library, and
I think this is now the time to report my efforts.

A major point is to "channelize" the library, i.e. use the
Netchannels objects as often as possible. There are now several
new types of channels:

- An [io_obj_channel] has both, input and output interfaces.
  The class [pipe] is an example of an [io_obj_channel]. It
  has two buffers, one for the input side and one for the
  output side, i.e. the input methods read from the input
  buffer, and the output methods write into the output buffer.
  The buffers are connected by a configurable function that
  copies data from the output buffer to the input buffer.
  By default, this function is the identity, but it can also
  perform any conversions. 

  There are four predefined pipe classes that have such 
  conversions:
  Netencoding.Base64.encoding_pipe,
  Netencoding.Base64.decoding_pipe,
  Netencoding.QuotedPrintable.encoding_pipe,
  Netencoding.QuotedPrintable.decoding_pipe

  For example, you can write any string into a 
  Netencoding.Base64.encoding_pipe, and when you read from this
  pipe, the data is BASE64-encoded.

  In Netchannels, there are two classes [input_filter], and
  [output_filter] that simplify usage of pipes. You can 
  combine them with already existing [in_obj_channel]s or
  [out_obj_channel]s.

- The Netstream module bases on channels, too. An [in_obj_stream]
  is an [in_obj_channel] with look-ahead, i.e. you can look at
  characters that will be read by the input methods in the future.

  There is the very important class [sub_stream] allowing to
  restrict an existing stream to a certain subsection. For example,
  you can define a substream that consist of the first n characters
  of the main stream. If you read from the substream, it will
  signal EOF after n characters. However, the main stream is not
  at the end, and you can read the rest (or begin a new substream
  at the point).

  You cannot only restrict the length of substreams, but also
  define a boundary. This is an arbitrary string, and the substream
  ends just before the boundary occurs in the main stream. In the
  netstring library, this is used to split MIME messages very
  effectively up into their parts.

  Forming substreams is a rather efficient operation. First,
  substreams use the same buffer as the main stream, and so
  double-buffering is avoided. Second, the Knuth-Morris-Pratt
  algorithm is used to find the boundaries in linear time, no
  matter how tricky the message is. (Thanks to Alain Frisch
  for his hint and quite good implementation.)

  It is allowed to recursively define substreams, i.e. the 
  substream of the substream of the subtream ... The MIME parser
  uses this feature to decode nested messages very quickly.

The "channelization" is not yet done. The character set conversion
routines should be rewritten such that they take advantage
of the new structure. This would also help to convert from and
to stateful character sets (e.g. Shift-JIS).

The Netmime module is completely new. It contains a definition
for nested MIME messages:

type complex_mime_message = mime_header * complex_mime_body
and complex_mime_body =
  [ `Body of mime_body
  | `Parts of complex_mime_message list
  ]

where [mime_header] and [mime_body] are objects (also defined
in Netmime). There is a parser for MIME messages:

val read_mime_message : Netstream.in_obj_stream -> complex_mime_message

It has an [in_obj_stream] as input. The stream must be positioned
right at the beginning of the MIME header of the whole message.
The function parses the message and returns it. Simple, isn't it.
Well, I have left out that there are a number of options that
configure some aspects of the parser (see netmime.mli for details).

There is also the reverse function:

val write_mime_message : 
      Netchannels.out_obj_channel -> complex_mime_message -> unit

It writes the MIME message to the channel. It is designed for
simple usage, for example you need not to set a MIME boundary.
The function will add a suitable boundary.

Despite these high-level functions, there are also a lot of
new lower level routines in Mimestring. There is now support for
RFC 2231-style parameters. There are also a number of functions
that were necessary to program Netmime, e.g. [write_header]
writes a MIME header while fixing end-of-line conventions.

Last but not least I have worked on the netcgi library. It does
no longer depend on the old Cgi module (there are still some
references, but the called functions are quite stupid, and could
be easily moved to another module). All MIME parsing and printing
is done using the new features of the Netmime module.

So far I have done most items that were on the "TODO" list I
posted several weeks ago. In detail, the character set conversion
stuff is not yet done, and Neturl has not been touched. Nevertheless,
I think it is time for a new release (0.92), and it is especially
time for you to test the new features and play with them.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   ge...@ge...
Germany                     
----------------------------------------------------------------------------

[Ocamlnet-devel] DNS protocol

[Guillaume V. <gui...@va...>]

hi guys,

My school project is 'finish', it's an attempt to do an host command
and a dns server in ocaml.

Maybe that i can modify the Dns module and add it to ocamlnet.

If you have time to look at it:
http://guillaume.valadon.net/odns/

There is a README and a manual in docs/ if you are curious.

bye,
guillaume
-- 
mailto:gui...@va...
ICQ uin : 1752110

Page ouebe : http://guillaume.valadon.net

     "Everybody be cool. You ... be cool" - Seth Gecko

Re: [Ocamlnet-devel] Str labels

[Patrick M D. <pa...@wa...>]

On Wed, 19 Dec 2001, Gerd Stolpmann wrote:

> This is a bit messy... I would suggest to follow ocaml-3.04's policy
> and to remove the non-optional labels. Otherwise, we'll get difficulties
> when we try to write code working for 3.04 and for earlier versions
> of ocaml.

Sounds like a wise idea. The transition has already been tricky to get
right.

> 3.04 is very strict. For example, you cannot pass an optional argument,
> and omit the non-optional labels (which was possible in the old
> classical mode):

I'm not sure I understand why this is the case - but Jacques has mentioned
that there were problems specifical with optional arguments so this may be
why.

> I think we should avoid non-optional labels unless there is a real
> benefit from them (e.g. many arguments with the same type).

Agreed.

Patrick

[Ocamlnet-devel] Str labels

[Gerd S. <in...@ge...>]

Hi list,

the modules Netstring_str and Netstring_pcre currently define more
labels than Str, and more labels than the module Netstring_str
I have originally distributed in netstring-0.10. Example:

ocamlnet's Netstring_str (and Netstring_pcre):

    val search_forward: 
      ?groups:int -> pat:regexp -> string -> pos:int -> (int * result)

ocaml-3.04's Str:

    val search_forward :
      regexp -> string -> int -> int

    (* 3.02 had: pat:regexp -> string -> pos:int -> int *)

netstring-0.10's Netstring_str:

    val search_forward: 
      ?groups:int -> regexp -> string -> int -> (int * result)

This is a bit messy... I would suggest to follow ocaml-3.04's policy
and to remove the non-optional labels. Otherwise, we'll get difficulties
when we try to write code working for 3.04 and for earlier versions
of ocaml.

3.04 is very strict. For example, you cannot pass an optional argument,
and omit the non-optional labels (which was possible in the old
classical mode):

# let f ?(x=1) ~y = x+y;;
Warning: This optional argument cannot be erased
val f : ?x:int -> y:int -> int = <fun>
# f 3;;
- : int = 4
# f ~x:2 3;;
Expecting function has type y:int -> int
This argument cannot be applied without label
# f ~x:2 ~y:3;;
- : int = 5

I think we should avoid non-optional labels unless there is a real
benefit from them (e.g. many arguments with the same type).

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   ge...@ge...
Germany                     
----------------------------------------------------------------------------

Re: [Ocamlnet-devel] Re: How to make the library PCRE dynamically loadable

[Markus M. <ma...@oe...>]

Gerd Stolpmann schrieb am Dienstag, den 18. Dezember 2001:
> This may work, but see below. You can create dllpcre.so by
> 
> ocamlmklib -o pcre pcre_intf.o -lpcre

Actually, it seems that things are much easier (thanks to the cleverness
of ocamlmklib):

Just compile the C-library in "pcre-C" like this:

  ./configure --enable-shared
  make

Then go to directory "pcre-OCaml" and do this:

  make
  cp ../pcre-C/.libs/libpcre.a .
  cp ../pcre-C/.libs/libpcre.so.0.0.1 libpcre.so.0
  ocamlmklib -o pcre pcre.cmo pcre.cmx pcre_intf.o -lpcre -L.

That was it!

Try, for example:

  $ ocaml
  # #load "pcre.cma";;
  # Pcre.split "foo bar";;
  - : string list = ["foo"; "bar"]

Nice! :-)

This also works:

file: foo.ml
---------------------------------------------------------------------------
#directory ".";;
#load "pcre.cma";;
List.iter print_endline (Pcre.split "foo bar")
---------------------------------------------------------------------------

Start it with: "ocaml foo.ml". Really useful for scripting if you don't
want to build monster toplevels!

And this also works:

  ocamlc -dllpath . pcre.cma foo.ml -o foo
  ./foo

If you want to compile to native code with shared libraries, you'll
have to do this in "pcre-OCaml" (seems a bit inconsistent, though,
because there is also libpcre.so.1, which is a different beast):

  ln -s dllpcre.so libpcre.so
  ocamlopt pcre.cmxa foo.ml -o foo

The original C-library "libpcre.a" gets destroyed during the compilation
steps further above, which prevents you from compiling this example to
static native code. But you can easily correct this as follows:

  cp ../pcre-C/.libs/libpcre.a .
  ar r libpcre.a pcre_intf.o

Now compile like this to get a statically compiled executable:

  ocamlopt -ccopt -static pcre.cmxa foo.ml -o foo

> and this adds libpcre.so as dependent library. I think this is the reason
> why Xavier changed the naming conventions between OCaml 3.03 and 3.04;
> now all OCaml-specific libraries follow the name pattern dll*.<extension>
> so you can have a OCaml library dllpcre.so and a generic library libpcre.so.

This seems reasonable.

> But: Many people already have pcre on their disk (especially
> the users of free OS), but probably the wrong version. It would not be a
> good idea forcing them to replace the system-wide library, and it can
> become difficult to have two shared libraries with the same name.

I don't know whether there can be any clashes here, but things seem to
work fine on my machine, even with very old versions of pcre.

> I don't really know whether the PCRE stubs only work for certain PCRE
> versions, or whether they are generic enough such that they will work
> with every installed system-wide PCRE library.

Interface changes in the C-version of PCRE are extremely rare (it's
pretty stable by now). I suppose the stubs will work with versions that
are even two years old.

It's actually rather the static version about which I am concerned,
because I'd need to add pcre_intf.o to the library. Another possibility
would be to generate a separate library out of it, similar in spirit to
"dllpcre.so", and let OCaml add both automatically during linking as is
nowadays possible with the new linking semantics. When I'll have a bit
more time (next week?) I might have a look at this.

> - Have two libraries libpcre.so and dllpcre.so with the outlined problems

This may not be so severe, I think. It doesn't seem to cause problems
on my machine at work, which has a very old (most likely incompatible)
version of PCRE installed in a standard place. This way, we could almost
get rid of the C-distribution, which I'd still prefer to keep, because
not everybody has installed PCRE (or a recent version).

This is currently my preferred way of creating the library.

> - Because it is not possible to add objects later to a shared library,
>   pcre_intf.o must be added to the command creating the shared library.
>   There are again two ways:
>  
>    * Keep the current Makefile in pcre-C and patch it
> 
>    * Replace the whole Makefile in pcre-C with a self-written one. Especially
>      drop libtool, it is not really helpful. Compile the C files 
>      with ocamlc -c; this will add the necessary -fPIC options, too.
>      Make the shared library with ocamlmklib.

It might be better to copy the Makefile from another place so that one
can upgrade pcre-C more easily (it's a verbatim copy). But I am still
not too happy about this patching or replacing strategy. Sounds like more
work in the future. I'd prefer leaving the "pcre-C"-directory untouched.

> I think the last alternative is by far the simplest one. I am able to compile
> PCRE and create the library with only two commands:
> 
> ocamlc -ccopt -I. -c maketables.c study.c get.c pcre.c pcre_intf.c
> ocamlmklib -o pcre maketables.o study.o get.o pcre.o pcre_intf.o

> And these commands work on all platforms that support shared libraries under
> OCaml, so there is no need for libtool.

This is better than the previous method, I think. The only problem I
have with it is that it makes my compilation process more dependent on
the implementation of PCRE. Maybe there is even a copyright problem if
I tear apart the distribution of the C-library.

I'd therefore still opt for the first method, which means that we would
have two libraries. - Any suggestions?

Regards,
Markus

-- 
Markus Mottl                                             ma...@oe...
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus

Re: [Ocamlnet-devel] Task list for netstring

[Patrick M D. <pa...@wa...>]

On Tue, 18 Dec 2001, Gerd Stolpmann wrote:

>
> On 2001.12.16 20:53 Patrick M Doane wrote:
> > On Wed, 12 Dec 2001, Gerd Stolpmann wrote:
> >
> > > - Netchannels:
> > >
> > >   * class input_descr: bases on Unix.read
> > >
> > >   * class output_descr: bases on Unix.write
> > >
> > >   * class socket_descr: is both input and output. close_in
> > >     does shutdown RECV, close_out does shutdown SEND, closing both
> > >     sides closes the descriptor.
> >
> > If input_descr and output_descr satisfy the in_obj_channel and
> > out_obj_channel types respectively, then their implementations should be
> > buffered for performance reasons. I would like to decouple the buffering
> > aspects from the raw reading/writing aspects so that the buffering code
> > could be used for other reasons.
>
> Sometimes buffer semantics is useful, sometimes not. I am not sure whether
> we need our own buffer implementation, because we can make an
> in/out_channel from a descriptor. Of course, we cannot control the
> behavior of the channel buffer in detail, and it only works for
> descriptors.

Yes, this makes sense. Putting off the work until later sounds like a good
plan too.

If (and when) we want to implement general-purpose buffering code, I have
a pure OCaml version of input_line that calls the low-level socket
version. I have tested it through the raw_channel interface and there is
only a slight perfomance degradation. This is not quite a full buffering
implementation, but it is one of the more difficult functions to write.

> Something like
>
> class buffered_input_descr d =
>   new input_channel (in_channel_of_descr d)
>
> For the bidirectional case:
>
> class buffered_socket_descr d =
>   object
>     val descr = d
>     inherit input_channel (in_channel_of_descr d)
>     inherit output_channel (out_channel_of_descr d)
>
>     (* Override close_in and close_out *)
>   end
>
> For the unbuffered case, we can use Unix.read/write directly. This would
> be much less work, and maybe a temporary solution until we come to the
> conclusion that we really need our own buffering code.

Agreed.

> > Perhaps the existing class 'buffered_output_channel' should be changed to
> > 'buffered_trans_channel'?
>
> A good idea. And tempfile_trans_channel.

Okay.

> I would also suggest to have the descriptor classes with unbuffered semantics:
>
>   class direct_in_channel : raw_in_channel -> in_obj_channel
>   class direct_out_channel : raw_out_channel -> out_obj_channel
>   class direct_io_channel : raw_io_channel -> io_obj_channel
>
> That should be straight-forward to implement. input_line would read char by
> char until it finds \n, ineffective but working.
>
> Maybe we put the direct methods into in/output_descr classes, so they
> are the default?

Do you mean here the mixin class that was suggested before, or that the
in/output_descr classes should satisfy the obj_channel interface instead
of the raw_channel interface?

> I would also suggest to export the class functions
> raw_in/out_channel -> in/out_obj_channel as functions, not classes,
> i.e.
>
>   val  buffer_in_channel : raw_in_channel -> in_obj_channel
>
> The difference is that you can call buffer_in_channel without "new".
> I think it is more a transformation of something already existing, and
> "new" would be confusing.

I'm confused here - did you want both the functional and class based
interface for the transformation from raw_channel -> obj_channel? And for
this functional version, is this really meant to provide a buffered
implementation, or simply the direct version called above that does not do
any buffering?

It looks like we are close enough in agreement to the changes that I'll
start working on these changes.  We can fix up any minor issues easily
enough.

Patrick

Re: [Ocamlnet-devel] Task list for netstring

[Gerd S. <in...@ge...>]

On 2001.12.16 20:53 Patrick M Doane wrote:
> On Wed, 12 Dec 2001, Gerd Stolpmann wrote:
> 
> > - Netchannels:
> >
> >   * class input_descr: bases on Unix.read
> >
> >   * class output_descr: bases on Unix.write
> >
> >   * class socket_descr: is both input and output. close_in
> >     does shutdown RECV, close_out does shutdown SEND, closing both
> >     sides closes the descriptor.
> 
> If input_descr and output_descr satisfy the in_obj_channel and
> out_obj_channel types respectively, then their implementations should be
> buffered for performance reasons. I would like to decouple the buffering
> aspects from the raw reading/writing aspects so that the buffering code
> could be used for other reasons.

Sometimes buffer semantics is useful, sometimes not. I am not sure whether
we need our own buffer implementation, because we can make an
in/out_channel from a descriptor. Of course, we cannot control the
behavior of the channel buffer in detail, and it only works for
descriptors.

Something like

class buffered_input_descr d =
  new input_channel (in_channel_of_descr d)

For the bidirectional case:

class buffered_socket_descr d =
  object
    val descr = d
    inherit input_channel (in_channel_of_descr d)
    inherit output_channel (out_channel_of_descr d)

    (* Override close_in and close_out *)
  end

For the unbuffered case, we can use Unix.read/write directly. This would
be much less work, and maybe a temporary solution until we come to the
conclusion that we really need our own buffering code.

> I propose that we modify the class type hierarchy as follows (note that
> this has one incompatible change with the current version):
> 
> class type raw_in_channel = object
>   method input : string -> int -> int -> int
>   method close_in : unit -> unit
>   method pos_in : int
> end
> 
> class type raw_out_channel = object
>   method output : string -> int -> int -> int
>            (* NOTE: type signature changes here! *)
>   method close_out : unit -> unit
>   method pos_out : int
> end
> 
> class type raw_io_channel = object
>   inherit raw_in_channel
>   inherit raw_out_channel
> end
> 
> class type in_obj_channel = object
>   inherit raw_in_channel
>   method really_input : string -> int -> int -> unit
>   method input_char : unit -> char
>   method input_line : unit -> string
>   method input_byte : unit -> int
> 
>   (* Transitional method: *)
>   method _rep_in : [ `Chan of in_channel | `Other ]
> end
> 
> class type out_obj_channel = object
>   inherit raw_out_channel
>   method really_output : string -> int -> int -> unit
>            (* NOTE: new method! *)
>   method output_char : char -> unit
>   method output_string : string -> unit
>   method output_byte : int -> unit
>   method output_buffer : Buffer.t -> unit
>   method output_channel : ?len:int -> in_obj_channel -> unit
> 
>   method flush : unit -> unit
>   method close_out : unit -> unit
> 
>   (* Transitional method: *)
>   method _rep_out : [ `Chan of out_channel | `Other ]
> end
> 
> class type io_obj_channel = object
>   inherit in_obj_channel
>   inherit out_obj_channel
> end
> 
> This would introduce an incompatible change - namely that the method
> 'output' has become 'really_output'. I think this a cleaner design and
> impact on users would be fairly minor.

Agreed.

> Then the proposed descriptor based classes have the following types:
> 
>   class input_descr : Unix.file_descr -> raw_in_channel
>   class output_descr : Unix.file_descr -> raw_out_channel
>   class socket_descr : Unix.file_descr -> raw_io_channel
> 
> We then want two additional classes that will turn a raw_*_channel into a
> buffered form. There is a possible name confusion here as
> 'buffered_output_channel' currently implements the transactional channel
> which is slightly different than buffering because of the rollback
> capabilities. So we want to have something like this (names to discuss):
> 
>   class buffer_in_channel : raw_in_channel -> in_obj_channel
>   class buffer_out_channel : raw_out_channel -> out_obj_channel
>   class buffer_io_channel : raw_io_channel -> io_obj_channel
> 
> Perhaps the existing class 'buffered_output_channel' should be changed to
> 'buffered_trans_channel'?

A good idea. And tempfile_trans_channel.

I would also suggest to have the descriptor classes with unbuffered semantics:

  class direct_in_channel : raw_in_channel -> in_obj_channel
  class direct_out_channel : raw_out_channel -> out_obj_channel
  class direct_io_channel : raw_io_channel -> io_obj_channel

That should be straight-forward to implement. input_line would read char by
char until it finds \n, ineffective but working. 

Maybe we put the direct methods into in/output_descr classes, so they
are the default?

I would also suggest to export the class functions 
raw_in/out_channel -> in/out_obj_channel as functions, not classes,
i.e.

  val  buffer_in_channel : raw_in_channel -> in_obj_channel

The difference is that you can call buffer_in_channel without "new".
I think it is more a transformation of something already existing, and
"new" would be confusing.

> Patrick
> 
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   ge...@ge...
Germany                     
----------------------------------------------------------------------------

Re: [Ocamlnet-devel] ocamlnet-0.91 and O'Caml 3.04

[Patrick M D. <pa...@wa...>]

On Tue, 18 Dec 2001, Gerd Stolpmann wrote:

>
> On 2001.12.16 18:55 Patrick M Doane wote:
> > Yes, a patch is a good idea, but so is a new release soon--the jserv code
> > would be of use to many people.
> >
> > You recently sent an e-mail with a list of changes to netstring for
> > improved netchannel support. I would suggest that we finish these items
> > for a 0.92 release. I'll be working on some of those items today.
>
> Well, I will have time for that after Christmas, but not before. So
> it would become a "happy new year release".

That sounds fine with me. If you'd like me to do any of the coding work
for that, let me know. I've made the relevant changes to Nethtml as that
was something that I understood well enough. I have questions about
what to do for the other items, and since this is principally your code, I
certainly don't want to step on your feet with any unwanted changes.

Of course, discussion of these items can wait until the new year too. :)

> > After that, I would like to see 0.93 focus on standardized support for I/O
> > multiplexing.
>
> I hope we come to a common understanding of that. It isn't simple, isn't it.

This is definitely one of the most difficult aspects of the project, and
really this is the part that keeps me from writing all the little wrappers
needed for these various protocols. The technical details of the protocol
are usually fairly straight-forward. Coming up with a nice reusable design
that fits well into most applications is the challenging (and most
interesting) part!

Sounds like we are aligned with similar goals for what to work on
next.

Patrick

Re: [Ocamlnet-devel] How to make the library PCRE dynamically loadable

[Patrick M D. <pa...@wa...>]

On Tue, 18 Dec 2001, Gerd Stolpmann wrote:

> > > cp .libs/libpcre.so.0.0.1 ../pcre-OCaml/dllpcre.so
> > > cp .libs/libpcre.a ../pcre-OCaml
> > > cd ../pcre-OCaml
> > > ocamlc pcre.mli
> > > ocamlc pcre.ml
> > > ocamlopt pcre.ml
> > > ocamlmklib -o pcre pcre.cma
>
> This line is also wrong, see the other mail.

I fixed this line while doing the compilation. Since I didn't have a
pcre.cma file built at the time, it was easy enough to catch.

> > > ocamlmklib -o pcre pcre.cmx
>
> > I was not able to build the example programs, but perhaps I don't have the
> > ocaml/ld.conf in my path setup correctly. How does one get the system to
> > recognize that file?
>
> It takes it by default. This file is read by the bytecode interpreter when
> searching the libraries to load.

Interesting - I'll have to look in more detail then as to why things might
be failing.

Patrick

Re: [Ocamlnet-devel] How to make the library PCRE dynamically loadable

[Gerd S. <in...@ge...>]

On 2001.12.16 20:12 Patrick M Doane wrote:
> On Sun, 16 Dec 2001, Gerd Stolpmann wrote:
> 
> > This make will fail (it cannot make pcretest). Look into pcre-C/.libs,
> > and check if there is libpcre.so.0.0.1. If so, the part of the build we
> > need has succeeded.
> 
> The compilation of pcretest worked for me (I am running FreeBSD 4.x). The
> shared object made in my case was libpcre.so and libcre.so.0

This is strange, because libpcre.so contains symbols that are defined in
the OCaml runtime. Maybe FreeBSD looks symbols up only on demand.

> > cp .libs/libpcre.so.0.0.1 ../pcre-OCaml/dllpcre.so
> > cp .libs/libpcre.a ../pcre-OCaml
> > cd ../pcre-OCaml
> > ocamlc pcre.mli
> > ocamlc pcre.ml
> > ocamlopt pcre.ml
> > ocamlmklib -o pcre pcre.cma

This line is also wrong, see the other mail.

> > ocamlmklib -o pcre pcre.cmx
 
> I was not able to build the example programs, but perhaps I don't have the
> ocaml/ld.conf in my path setup correctly. How does one get the system to
> recognize that file?

It takes it by default. This file is read by the bytecode interpreter when
searching the libraries to load.
 
> This is the error that I get:
> 
>   Error while linking
>   /home/patrick/local/lib/ocaml/site-lib/pcre/pcre.cma(Pcre):
>   The external function `pcre_exec_wrapper_bc' is not available

Maybe this is because of the wrong ocamlmklib line.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   ge...@ge...
Germany                     
----------------------------------------------------------------------------

Re: [Ocamlnet-devel] ocamlnet-0.91 and O'Caml 3.04

[Gerd S. <in...@ge...>]

On 2001.12.16 18:55 Patrick M Doane wote:
> Yes, a patch is a good idea, but so is a new release soon--the jserv code
> would be of use to many people.
> 
> You recently sent an e-mail with a list of changes to netstring for
> improved netchannel support. I would suggest that we finish these items
> for a 0.92 release. I'll be working on some of those items today.

Well, I will have time for that after Christmas, but not before. So
it would become a "happy new year release".

> After that, I would like to see 0.93 focus on standardized support for I/O
> multiplexing.

I hope we come to a common understanding of that. It isn't simple, isn't it.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   ge...@ge...
Germany                     
----------------------------------------------------------------------------

Re: [Ocamlnet-devel] Datagrams

[Gerd S. <in...@ge...>]

On 2001.12.16 19:18 Patrick M Doane wrote:
> On Wed, 12 Dec 2001, Gerd Stolpmann wrote:
> 
> > Guillaume aked me whether netchannels will support datagrams. This is
> > not only a question of supporting UDP-style protocols, but every
> > message-oriented protocol.
> >
> > I am thinking about a parameterized class:
> >
> > class ['a] out_obj_message_service :
> > object
> >   method send : 'a -> unit
> >   method flush : unit -> unit
> >   method close_out : unit -> unit
> > end
> >
> > class ['a] in_obj_message_service :
> > object
> >   method receive : unit -> 'a
> >     (* raises End_of_file if no more message available *)
> >   method close_in : unit -> unit
> > end
> 
> This seems like a good idea, is your intention that receive will be
> blocking or non-blocking in the case that no message is currently
> available. The End_of_file condition is appropriate for when the service
> has actually closed.
> 
> If the behavior is to be non-blocking, then we will need some additional
> machinery to simplify the job of writing clients.

I suggest to start with blocking semantics. We must first see whether
the interface is useful at all before fine-tuning it.

> > What do you think about this idea?
> 
> It will be very useful to standardize these concepts. Another one to
> consider is an API for state models. This would allow user code to execute
> in response to a transition, entering/exiting particular states or
> substates, etc.

Can you give an example?

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   ge...@ge...
Germany                     
----------------------------------------------------------------------------

Re: [Ocamlnet-devel] Re: How to make the library PCRE dynamically loadable

[Gerd S. <in...@ge...>]

Sorry for the small mistakes. I was a bit tired when writing
the instructions up.

On 2001.12.16 19:20 Markus Mottl wrote:
> Gerd Stolpmann schrieb am Sonntag, den 16. Dezember 2001:
> > because ocamlnet depends on PCRE, I have tried to compile PCRE (4.8-1) as 
> > DLL. It works as follows:
> 
> The newest version of PCRE for OCaml (4.10-1) uses an upgraded version
> of Phil Hazel's PCRE-library. I am not sure whether this can make a
> difference.
> 
> > This make will fail (it cannot make pcretest). Look into pcre-C/.libs,
> > and check if there is libpcre.so.0.0.1. If so, the part of the build we
> > need has succeeded.
> 
> Everything's fine up to here.
> 
> > Now:
> > 
> > cp .libs/libpcre.so.0.0.1 ../pcre-OCaml/dllpcre.so
> > cp .libs/libpcre.a ../pcre-OCaml
> > cd ../pcre-OCaml
> > ocamlc pcre.mli
> > ocamlc pcre.ml
> > ocamlopt pcre.ml
> 
> Shouldn't this be:
> 
>   ocamlc -c pcre.ml
>   ocamlopt -c pcre.ml

Yes, of course.
 
> > ocamlmklib -o pcre pcre.cma

ocamlmklib -o pcre pcre.cmo

is right. ocamlmklib has a strange interface. It appends the suffix (.cma
or .cmxa) to the output name.

> > ocamlmklib -o pcre pcre.cmx
> 
> This doesn't seem to work: pcre.cma would obviously be overwritten
> during reading.
> 
> I am not sure what mode of installation the users would prefer most.
> Maybe it would be better to have two separate shared libraries, one for
> the C-library and another for the stubs? I have just taken my first look
> at the documentation of the new ocamlmklib-tool and it would probably
> work more smoothly this way.

This may work, but see below. You can create dllpcre.so by

ocamlmklib -o pcre pcre_intf.o -lpcre

and this adds libpcre.so as dependent library. I think this is the reason
why Xavier changed the naming conventions between OCaml 3.03 and 3.04;
now all OCaml-specific libraries follow the name pattern dll*.<extension>
so you can have a OCaml library dllpcre.so and a generic library libpcre.so.

(Note that ocamlmklib -o pcre now creates dllpcre.so! It depends on the type 
of the other objects you give on the command line.)

But: Many people already have pcre on their disk (especially
the users of free OS), but probably the wrong version. It would not be a
good idea forcing them to replace the system-wide library, and it can
become difficult to have two shared libraries with the same name.

I don't really know whether the PCRE stubs only work for certain PCRE
versions, or whether they are generic enough such that they will work
with every installed system-wide PCRE library.

> If anybody manages to improve the build process such that a shared
> PCRE-library is built automatically (if possible) in a portable way,
> I'd be glad to add this to the PCRE-distribution... :)

I think there are only two choices:

- Have two libraries libpcre.so and dllpcre.so with the outlined problems

- Because it is not possible to add objects later to a shared library,
  pcre_intf.o must be added to the command creating the shared library.
  There are again two ways:
 
   * Keep the current Makefile in pcre-C and patch it

   * Replace the whole Makefile in pcre-C with a self-written one. Especially
     drop libtool, it is not really helpful. Compile the C files 
     with ocamlc -c; this will add the necessary -fPIC options, too.
     Make the shared library with ocamlmklib.

I think the last alternative is by far the simplest one. I am able to compile
PCRE and create the library with only two commands:

ocamlc -ccopt -I. -c maketables.c study.c get.c pcre.c pcre_intf.c
ocamlmklib -o pcre maketables.o study.o get.o pcre.o pcre_intf.o

And these commands work on all platforms that support shared libraries under
OCaml, so there is no need for libtool.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   ge...@ge...
Germany                     
----------------------------------------------------------------------------

Re: [Ocamlnet-devel] Task list for netstring

[Patrick M D. <pa...@wa...>]

On Wed, 12 Dec 2001, Gerd Stolpmann wrote:

> - Nethtml:
>
>   * parse: reads from arbitrary netchannel
>   * output: writes into arbitrary netchannel
>
>   * The old parse_* and write functions will become deprecated

Completed. I've also added a test case to verify that the channel
interface is working and that the recent tag minimization bug was fixed.
This is located in tests/test_nethtml.ml

Patrick

Re: [Ocamlnet-devel] Task list for netstring

[Patrick M D. <pa...@wa...>]

On Wed, 12 Dec 2001, Gerd Stolpmann wrote:

> - Netchannels:
>
>   * class input_descr: bases on Unix.read
>
>   * class output_descr: bases on Unix.write
>
>   * class socket_descr: is both input and output. close_in
>     does shutdown RECV, close_out does shutdown SEND, closing both
>     sides closes the descriptor.

If input_descr and output_descr satisfy the in_obj_channel and
out_obj_channel types respectively, then their implementations should be
buffered for performance reasons. I would like to decouple the buffering
aspects from the raw reading/writing aspects so that the buffering code
could be used for other reasons.

I propose that we modify the class type hierarchy as follows (note that
this has one incompatible change with the current version):

class type raw_in_channel = object
  method input : string -> int -> int -> int
  method close_in : unit -> unit
  method pos_in : int
end

class type raw_out_channel = object
  method output : string -> int -> int -> int
           (* NOTE: type signature changes here! *)
  method close_out : unit -> unit
  method pos_out : int
end

class type raw_io_channel = object
  inherit raw_in_channel
  inherit raw_out_channel
end

class type in_obj_channel = object
  inherit raw_in_channel
  method really_input : string -> int -> int -> unit
  method input_char : unit -> char
  method input_line : unit -> string
  method input_byte : unit -> int

  (* Transitional method: *)
  method _rep_in : [ `Chan of in_channel | `Other ]
end

class type out_obj_channel = object
  inherit raw_out_channel
  method really_output : string -> int -> int -> unit
           (* NOTE: new method! *)
  method output_char : char -> unit
  method output_string : string -> unit
  method output_byte : int -> unit
  method output_buffer : Buffer.t -> unit
  method output_channel : ?len:int -> in_obj_channel -> unit

  method flush : unit -> unit
  method close_out : unit -> unit

  (* Transitional method: *)
  method _rep_out : [ `Chan of out_channel | `Other ]
end

class type io_obj_channel = object
  inherit in_obj_channel
  inherit out_obj_channel
end

This would introduce an incompatible change - namely that the method
'output' has become 'really_output'. I think this a cleaner design and
impact on users would be fairly minor.

Then the proposed descriptor based classes have the following types:

  class input_descr : Unix.file_descr -> raw_in_channel
  class output_descr : Unix.file_descr -> raw_out_channel
  class socket_descr : Unix.file_descr -> raw_io_channel

We then want two additional classes that will turn a raw_*_channel into a
buffered form. There is a possible name confusion here as
'buffered_output_channel' currently implements the transactional channel
which is slightly different than buffering because of the rollback
capabilities. So we want to have something like this (names to discuss):

  class buffer_in_channel : raw_in_channel -> in_obj_channel
  class buffer_out_channel : raw_out_channel -> out_obj_channel
  class buffer_io_channel : raw_io_channel -> io_obj_channel

Perhaps the existing class 'buffered_output_channel' should be changed to
'buffered_trans_channel'?

Patrick

Re: [Ocamlnet-devel] How to make the library PCRE dynamically loadable

[Patrick M D. <pa...@wa...>]

On Sun, 16 Dec 2001, Gerd Stolpmann wrote:

> This make will fail (it cannot make pcretest). Look into pcre-C/.libs,
> and check if there is libpcre.so.0.0.1. If so, the part of the build we
> need has succeeded.

The compilation of pcretest worked for me (I am running FreeBSD 4.x). The
shared object made in my case was libpcre.so and libcre.so.0

> cp .libs/libpcre.so.0.0.1 ../pcre-OCaml/dllpcre.so
> cp .libs/libpcre.a ../pcre-OCaml
> cd ../pcre-OCaml
> ocamlc pcre.mli
> ocamlc pcre.ml
> ocamlopt pcre.ml
> ocamlmklib -o pcre pcre.cma
> ocamlmklib -o pcre pcre.cmx

I needed to add the '-c' option to the compilation commands and ran
ocamlmklib with pcre.cmo instead of pcre.cma

> Now install pcre.cmi, pcre.cma, pcre.cmxa, pcre.a, dllpcre.so, libpcre.a,
> and make sure that the directory containing dllpcre.so is listed in
> <stdlib>/ld.conf. If you have findlib, do it this way:
>
> META file is as follows:
>
> requires = ""
> description = "Perl compatible regular expressions"
> version = "4.8-1"
> archive(byte) = "pcre.cma"
> archive(native) = "pcre.cmxa"
>
> Install with:
> ocamlfind install pcre *.cmi *.mli *.cma *.cmxa *.a dll* META
>
> findlib >= 0.6.1 will update ld.conf automatically.

I was not able to build the example programs, but perhaps I don't have the
ocaml/ld.conf in my path setup correctly. How does one get the system to
recognize that file?

This is the error that I get:

  Error while linking
  /home/patrick/local/lib/ocaml/site-lib/pcre/pcre.cma(Pcre):
  The external function `pcre_exec_wrapper_bc' is not available