ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] Is this code of interest for Extlib?

[Nicolas C. <war...@fr...>]

> > I added the following to ExtString :
> > 
> > val strip : ?chars:string -> string -> string
> > val nsplit : string -> string -> string list
> > val join : string -> string list -> string ( = concat )
> > 
> > I'm not sure about lstrip, rstrip and rchop_if
> 
> lstrip and rstrip are useful in some cases.  For instance, if you wish
> to remove trailing whitespace such as \n but preserve leading whitespace
> (perhaps it's indentation that you wish to keep), rstrip is useful.

what about : strip ~chars:"\n" then ?

Regards,
NC

Re: [Ocaml-lib-devel] Is this code of interest for Extlib?

[John G. <jgo...@co...>]

On Mon, Apr 26, 2004 at 09:09:45PM +0200, Nicolas Cannasse wrote:
> why not, simply :
> 
> [general]
> accounts = "Persona, Work"
> maxsyncaccounts = 5

Because now you have introduced more complexities for the user:

1. They must know which fields need to be quoted and which don't
2. They must now understand escaping of quotes
3. These configuration files will no longer remain compatible with 
   Python's ConfigParser or other parsers for this same format
4. Forcing people to add a decimal point or some other notation for
   floats is non-obvious
5. Forcing people to omit quotes for booleans is also non-obvious,
   and an ambiguity could occur since 0 and 1 are both possible boolean
   values and possible ints.

Moreover, it works poorly with the RFC822-style multiline capabilities
already present, such as:

[general]
accounts = Red, Green, Black, Chrome, Purple,
           Pink, Silver, Turquoise,
           White, Blue
maxsyncaccounts = 5

> I was just showing the internal data structure.
> You can always have a get_int helper function that do the stuff.

That takes is right back to where I started from, then :-)

> > Not to mention one ConfigParser feature that I haven't yet implemented,
> > but will shortly, such as:
> > 
> > newvalue = %(maxsyncaccounts)s accounts
> > 
> > which will interpolate the maxsyncaccounts value.  Python's ConfigParser
> > module supports only the "s" format type here, and that does indeed make
> > sense.
> 
> I don't understand this.

You can read about it at
http://www.python.org/doc/current/lib/module-ConfigParser.html.

-- John

Re: [Ocaml-lib-devel] Is this code of interest for Extlib?

[John G. <jgo...@co...>]

On Mon, Apr 26, 2004 at 09:06:32PM +0200, Nicolas Cannasse wrote:
> >   probably be implemented without it for Extlib)
> 
> I added the following to ExtString :
> 
> val strip : ?chars:string -> string -> string
> val nsplit : string -> string -> string list
> val join : string -> string list -> string ( = concat )
> 
> I'm not sure about lstrip, rstrip and rchop_if

lstrip and rstrip are useful in some cases.  For instance, if you wish
to remove trailing whitespace such as \n but preserve leading whitespace
(perhaps it's indentation that you wish to keep), rstrip is useful.

-- John

Re: [Ocaml-lib-devel] Is this code of interest for Extlib?

[Nicolas C. <war...@fr...>]

> > > > > >  * Client-side IMAP library
> > >
> > > This is *definitely* something which is outside the realm
> > > of ExtLib. :)
> >
> > Not completely sure...
> > Having a common set of protocols such as HTTP , IMAP , POP3, FTP into
ExtLib
> > is "general use" enough to make it available. Protocols are by
definition
> > the things you don't want to reimplement over and over since they're
already
> > a standard.
>
> ocamlnet already does this -- To my mind this at a
> slightly higher level than what ExtLib should provide.
> These protocols are not really things that are potentially
> useful to *every* program, just net-related ones. I also
> feel that most people who need such functionality would
> just use ocamlnet -- it's easy and convenient. Feel free
> to disagree, though. :)

I was not talking about rewriting ocamlnet.
But just that maybe the protocols would fit well into ExtLib. But maybe a
separate project is better, no strong ideas about it here either :)

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Is this code of interest for Extlib?

[Nicolas C. <war...@fr...>]

> > type data =
> >     | Object of (string * data) list
> >     | Int of int
> >     | Float of float
> >     | String of string
> >     | Bool of bool
> > 
> > as well as :
> > 
> > let load_data :  appname:string -> data
> > let save_data : appname:string -> data -> unit
> 
> You are missing the point, I think.  If I have a file that looks like
> this:
> 
> [general]
> accounts = Personal,Work
> ui = Curses.Blinkenlights
> #ui = Tk.Blinkenlights
> maxsyncaccounts = 5
> 
> (This is a real example, BTW)
> 
> How is the OCaml parser supposed to know whether maxsyncaccounts is a
> string, int, or float?  After all, "accounts = 5" would be perfectly
> valid here, too.  The config file would have to look something like
> this:
> 
> [general]
> accounts = string:Persona,Work
> ui = string:Curses.Blinkenlights
> maxsyncaccounts = int:5

why not, simply :

[general]
accounts = "Persona, Work"
maxsyncaccounts = 5
 
> Not to mention that it's also more difficult for the programmer.  I know
> that I always want an int from maxsyncaccounts.  Calling getint() and
> knowing that it will raise an exception if it does not get an int is
> easier than forcing a match each time such as:
> 
> match get() with
>   Int x -> do_real_stuff x
>   | _ -> raise NotIntException
> 
> every single time you want an int.

I was just showing the internal data structure.
You can always have a get_int helper function that do the stuff.
 
> Not to mention one ConfigParser feature that I haven't yet implemented,
> but will shortly, such as:
> 
> newvalue = %(maxsyncaccounts)s accounts
> 
> which will interpolate the maxsyncaccounts value.  Python's ConfigParser
> module supports only the "s" format type here, and that does indeed make
> sense.

I don't understand this.

[...] 
> There is no problem in my mind with defining a function that the
> programmer can *optionally* use to obtain a standard location.  Forcing
> the programmer to use that is wrong, though.

That's ok for me this way.

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Is this code of interest for Extlib?

[Nicolas C. <war...@fr...>]

[... ]
> > If you think I forgot something that should definitly be added to the
> > ExtLib, please send back an email.
> 
> The main ones that occur to me are:
> 
> Listutil.sub
> Listutil.replace
> Strutil.strip, lstrip, rstrip
>   (These are *not* the same as the chop functions in ExtString)
> Strutil.split
>   (It is defined in terms of Str.split_delim in MissingLib but could
>   probably be implemented without it for Extlib)

I added the following to ExtString :

val strip : ?chars:string -> string -> string
val nsplit : string -> string -> string list
val join : string -> string list -> string ( = concat )

I'm not sure about lstrip, rstrip and rchop_if

Nicolas Cannasse

Re: [Ocaml-lib-devel] Global.isdef wrong?

[Nicolas C. <war...@fr...>]

> Hi,
> 
> Shouldn't the implementation of Global.isdef return true
> iff the global has been set (the documentation sates that
> this is the intended behaviour)? If so, then the
> implementation is currently wrong:
> 
>     (from CVS global.ml):
>     
>       let isdef (r,_) = !r = None
> 
> Returns true iff the global has NOT been set.

You're true, implementation is wrong  :)

Fixed now,
Thanks for the report.

Nicolas Cannasse

[Ocaml-lib-devel] Global.isdef wrong?

[Bardur A. <oca...@sc...>]

Hi,

Shouldn't the implementation of Global.isdef return true
iff the global has been set (the documentation sates that
this is the intended behaviour)? If so, then the
implementation is currently wrong:

    (from CVS global.ml):
    
      let isdef (r,_) = !r = None

Returns true iff the global has NOT been set.

-- 
Bardur Arantsson
<ba...@im...>
<ba...@sc...>

- This is Mr. Death. He's a reaper.
                             | Monty Python's The Meaning of Life

Re: [Ocaml-lib-devel] Is this code of interest for Extlib?

[Bardur A. <oca...@sc...>]

On Mon, Apr 26, 2004 at 05:16:30PM +0200, Nicolas Cannasse wrote:

> > Since you asked, I have a tiny suggestion for ExtString:
> > rchop might be even more useful if it had an optional
> > parameter ~char such that
> >
> >           ExtString.rchop ~char:'/' s
> [...]
> 
> A different function is definitly needed :)
> Please propose a name so I can add it.

Well, "rchop_if" seems appropriate. :)

[--snip--] 
> > >
> > > > >  * Client-side IMAP library
> >
> > This is *definitely* something which is outside the realm
> > of ExtLib. :)
> 
> Not completely sure...
> Having a common set of protocols such as HTTP , IMAP , POP3, FTP into ExtLib
> is "general use" enough to make it available. Protocols are by definition
> the things you don't want to reimplement over and over since they're already
> a standard.

ocamlnet already does this -- To my mind this at a
slightly higher level than what ExtLib should provide.
These protocols are not really things that are potentially
useful to *every* program, just net-related ones. I also
feel that most people who need such functionality would
just use ocamlnet -- it's easy and convenient. Feel free
to disagree, though. :)

Having two different implementations would be a waste of
everyone's time, and I think that the developer(s) of
ocamlnet would probably appreciate any help they can get.
If they could be persuaded to use ExtLib as a foundation
for ocamlnet, then great! If not, I don't think the answer
would be to reimplement all their hard work within/using
ExtLib would be worth it, just for the sake of having it
within ExtLib.

> 
> > Hmm... it doesn't seem that true async I/O is possible
> > with the Unix module. However, you *can* do
> > **non-blocking** I/O by using the select function with a
> > zero timeout. This has been good enough for me so far --
> > and I was actually a bit surprised that the "available"
> > closure on channels doesn't use this (since it also works
> > on sockets); perhaps platform availability has something
> > to do with it?
> 
> Could you explain more about this ?
> 

Well, Unix.select can be given three lists of file descriptors
to "watch", one list of FDs to watch for input, one list
to watch for output and one list to watch for "error
conditions" (whatever that means). By supplying a timeout
of 0 for select, one can in effect ask the system if
anything is available for reading on a given FD. (FDs can
be obtained through Unix.channel_to_file_desc(or some
such)).

That allows you to do non-blocking reads in the sense that
you can simply check (using Unix.select) if the channel you
want to read from actually has anything for you to read
(thus ensuring that "input" will not block), and if it
doesn't then you can simply do some other processing and
try the Unix.select again later.

(Unix.select is also used routinely to multiplex several
input channels for non-threaded servers).

I don't know how well Unix.select from the "fake" Unix
modules works on Windows or OS X, but it is certainly
possible for the O'Caml team to implement Unix.select
versions for those platforms (and probably very easily
too).

HTH.

Cheers,

-- 
Bardur Arantsson
<ba...@im...>
<ba...@sc...>

- If it's hard to do, it's not worth doing.
                                     Homer Simpson | The Simpsons

Re: [Ocaml-lib-devel] Is this code of interest for Extlib?

[John G. <jgo...@co...>]

On Mon, Apr 26, 2004 at 05:08:07PM +0200, Nicolas Cannasse wrote:
> type data =
>     | Object of (string * data) list
>     | Int of int
>     | Float of float
>     | String of string
>     | Bool of bool
> 
> as well as :
> 
> let load_data :  appname:string -> data
> let save_data : appname:string -> data -> unit

You are missing the point, I think.  If I have a file that looks like
this:

[general]
accounts = Personal,Work
ui = Curses.Blinkenlights
#ui = Tk.Blinkenlights
maxsyncaccounts = 5

(This is a real example, BTW)

How is the OCaml parser supposed to know whether maxsyncaccounts is a
string, int, or float?  After all, "accounts = 5" would be perfectly
valid here, too.  The config file would have to look something like
this:

[general]
accounts = string:Persona,Work
ui = string:Curses.Blinkenlights
maxsyncaccounts = int:5

Not to mention that it's also more difficult for the programmer.  I know
that I always want an int from maxsyncaccounts.  Calling getint() and
knowing that it will raise an exception if it does not get an int is
easier than forcing a match each time such as:

match get() with
  Int x -> do_real_stuff x
  | _ -> raise NotIntException

every single time you want an int.

Not to mention one ConfigParser feature that I haven't yet implemented,
but will shortly, such as:

newvalue = %(maxsyncaccounts)s accounts

which will interpolate the maxsyncaccounts value.  Python's ConfigParser
module supports only the "s" format type here, and that does indeed make
sense.

> > Perhaps some would like this, and perhaps ConfigParser could be modified
> > to serve that purpose.  I, OTOH, would not like that.  In general, I
> > think that users do not care what language a program is written in if it
> > does what they want.  Users are more likely to think "Where do I go to
> > configure app foo?" than "What language is app foo written in, and where
> > does it store config data?"
> 
> Then it's best to help with the programmer and enforce the data store where
> it should be, without the need for him to port on other systems.

No.

That is not a help; that is a hindrance, since there is no real
standard.

For instance, some programs such as procmail can have defaults stored
under /etc and have user-configurable values in the user's home
directory.  Other programs, such as OfflineIMAP may have only the latter.  
Still others may have only the former, such as server programs.

It is also useful to be able to send a configuration file over the
network, etc.

Unix administrators may often have multiple versions of a single app
installed.  For instance, version 3.5 is under /opt/app-3.5 and 4.0 is
under /opt/app-4.0.  Each may be configured in
/opt/app-whatever/app.conf.  However, other Unix admins may install it
systemwide, so it could be configured in /etc or /usr/local/etc.  This
flexibility is something that Unix administrators value, and taking it
away in an OCaml module is not a win.

There is no problem in my mind with defining a function that the
programmer can *optionally* use to obtain a standard location.  Forcing
the programmer to use that is wrong, though.

-- John

Re: [Ocaml-lib-devel] Is this code of interest for Extlib?

[Nicolas C. <war...@fr...>]

> > - you will be happy to know that most of the functions in Hashtblutil
are
> > already in ExtLib extHashtbl module
>
> I took a look...  one thing that is unclear to me is the relationship
> between ExtHashtbl.Hashtbl and the standard Hashtbl.  On the surface,
> from the API docs, they look incompatible.  Is that true?

They're compatible. Simply add an "open ExtHashtbl" in the beginning of your
code to switch to ExtLib implementation, with additionnal functions. That's
the way we are dealing with standard library extensions.

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Is this code of interest for Extlib?

[Nicolas C. <war...@fr...>]

> Since you asked, I have a tiny suggestion for ExtString:
> rchop might be even more useful if it had an optional
> parameter ~char such that
>
>           ExtString.rchop ~char:'/' s
[...]

A different function is definitly needed :)
Please propose a name so I can add it.

> This can be quite useful for "path-type" string
> manipulation.
>
> > The main ones that occur to me are:
> >
> > Listutil.sub
>
> This could easily be done if the generalized "enum"
> function (as discussed above) were implemented.

That's what I was thinking. A lazy sub is possible, although not very
interesting (I never used sub on Lists)

> > Strutil.strip, lstrip, rstrip
> >   (These are *not* the same as the chop functions in ExtString)
>
> I agree that these would be useful.
>
> > Strutil.split
> >   (It is defined in terms of Str.split_delim in MissingLib but could
> >   probably be implemented without it for Extlib)
>
> This would probably be useful for quick hacks, when you
> don't want to pull out the power of Pcre.

I agree we need more functions to put into ExtString.

> >
> > > >  * Client-side IMAP library
>
> This is *definitely* something which is outside the realm
> of ExtLib. :)

Not completely sure...
Having a common set of protocols such as HTTP , IMAP , POP3, FTP into ExtLib
is "general use" enough to make it available. Protocols are by definition
the things you don't want to reimplement over and over since they're already
a standard.

> Hmm... it doesn't seem that true async I/O is possible
> with the Unix module. However, you *can* do
> **non-blocking** I/O by using the select function with a
> zero timeout. This has been good enough for me so far --
> and I was actually a bit surprised that the "available"
> closure on channels doesn't use this (since it also works
> on sockets); perhaps platform availability has something
> to do with it?

Could you explain more about this ?

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Is this code of interest for Extlib?

[Nicolas C. <war...@fr...>]

> On Mon, Apr 26, 2004 at 09:34:42AM +0200, Nicolas Cannasse wrote:
> > Some comments :
> > - the ConfigParser is nice, but lacks some persitency and typing. I
would
>
> By this I assume you mean something akin to Marshal, where you can throw
> an OCaml object at it and always get back the same one (as opposed to
> the getint(), getbool(), etc. that are in ConfigParser).
>
> One problem with that approach is that is goes against the easily
> user-editable goal, where users should be able to just put values in the
> config file and not worry too much about the app.  Note, though, that
> ConfigParser does define functions to write out the in-memory structure
> to a file or string.

Then we need to do it.
Symbols are provinding flexible typing, that means that we can put any type
in a symbol.
If we had a data structure consisting only of,  let's say :

type data =
    | Object of (string * data) list
    | Int of int
    | Float of float
    | String of string
    | Bool of bool

as well as :

let load_data :  appname:string -> data
let save_data : appname:string -> data -> unit

and the module handling well the OS particuliraties (that is : putting the
data in an user-readable format at the good place, whatever it could be)
then we have a winning combinaison of typing and persistence (we're loosing
here only
the openness of types since we're limited by our own parser/printers : a
generic type with custom parser/printers could be enabled).

> > IMHO, it would be nice to have some persistant storage for configuration
> > data which would be stored in a single user database file and made
> > accessible for all ocaml programs ( a little like a portable windows
> > registry )
>
> Perhaps some would like this, and perhaps ConfigParser could be modified
> to serve that purpose.  I, OTOH, would not like that.  In general, I
> think that users do not care what language a program is written in if it
> does what they want.  Users are more likely to think "Where do I go to
> configure app foo?" than "What language is app foo written in, and where
> does it store config data?"

Then it's best to help with the programmer and enforce the data store where
it should be, without the need for him to port on other systems.

> Moreover, a shared file like that brings in locking-related issues that
> are not necessarily present with individual app-specific configuration
> files.  It also goes against the grain of what people expect on a *nix
> system and makes it more difficult for people to write tools to generate
> config files for a given app in an automated fashion.

You're true about this,
I dismiss the idea of having one single big file. But having a file per
application name looks nice.

(more following)

Nicolas Cannasse

Re: [Ocaml-lib-devel] Is this code of interest for Extlib?

[John G. <jgo...@co...>]

On Mon, Apr 26, 2004 at 09:34:42AM +0200, Nicolas Cannasse wrote:
> Some comments :
> - the ConfigParser is nice, but lacks some persitency and typing. I would

By this I assume you mean something akin to Marshal, where you can throw
an OCaml object at it and always get back the same one (as opposed to
the getint(), getbool(), etc. that are in ConfigParser).

One problem with that approach is that is goes against the easily
user-editable goal, where users should be able to just put values in the
config file and not worry too much about the app.  Note, though, that
ConfigParser does define functions to write out the in-memory structure
to a file or string.

> IMHO, it would be nice to have some persistant storage for configuration
> data which would be stored in a single user database file and made
> accessible for all ocaml programs ( a little like a portable windows
> registry )

Perhaps some would like this, and perhaps ConfigParser could be modified
to serve that purpose.  I, OTOH, would not like that.  In general, I
think that users do not care what language a program is written in if it
does what they want.  Users are more likely to think "Where do I go to
configure app foo?" than "What language is app foo written in, and where
does it store config data?"

Moreover, a shared file like that brings in locking-related issues that
are not necessarily present with individual app-specific configuration
files.  It also goes against the grain of what people expect on a *nix
system and makes it more difficult for people to write tools to generate
config files for a given app in an automated fashion.

> - Hashtbloper are pure syntactic sugar and each user should be free to
> define its own bindings.

That's true, and nobody has to open Hashtbloper.  In fact, the reason I
defined the *oper modules is so that people can get the functionality
without the operators if they wish.

> - you will be happy to know that most of the functions in Hashtblutil are
> already in ExtLib extHashtbl module

I took a look...  one thing that is unclear to me is the relationship
between ExtHashtbl.Hashtbl and the standard Hashtbl.  On the surface,
from the API docs, they look incompatible.  Is that true?

The other thing is that those functions return Enums.  While it looks
easy enough to convert those to lists, I'd probably wind up defining my
own functions to do that anyway.

> - current Ocaml Lexer is providing (at last) support for line numbers in
> error messages (see Lexing.position)

Yes, but it does not work.  The line number information in position is
never updated by the ocamllex code.  To be more specific, pos_lnum is
never updated.  And, when you think about it, that makes sense; a line
may be defined differently in different lexers.

Thus the countline function that updates a Lexing.position.  The
raise_syntax_error function does indeed use Lexing.position itself.

> - splices should be interfaced with Enums in order to scale well with the
> increasing number of types to support (string, list, array, bigarray,
> dynarray, hashtbl..... )

Interesting approach there.  Will have to think on that one a bit more.

> If you think I forgot something that should definitly be added to the
> ExtLib, please send back an email.

The main ones that occur to me are:

Listutil.sub
Listutil.replace
Strutil.strip, lstrip, rstrip
  (These are *not* the same as the chop functions in ExtString)
Strutil.split
  (It is defined in terms of Str.split_delim in MissingLib but could
  probably be implemented without it for Extlib)

> >  * Client-side IMAP library
> >  * Asynchronous I/O system (patterned after www.twistedmatrix.com for
> >    Python)
> 
> Theses both are nice.
> Async IO might be tricky to implement correctly in pure caml.

I have not yet looked into that much.  I guess it will depend on how
powerful the Unix module is.  Sigh; my hopes are not high for that one.
Which is a pity, given the poor state of threading in OCaml at the
moment, too.

-- John

[Ocaml-lib-devel] IO nread on channels

[Nicolas C. <war...@fr...>]

Hi list,

On my local version, I slighly modified the behavior of IO.nread on channels
:
Before, it was reading using a single call to "input" without trying to read
more.
Now it's making several calls to input in order to fill the string. This is
different behavior that really_input because is the end of file is reached,
or if "input" is returning <= 0 then nread is returning the number of bytes
readed.
I'll commit if there are no complains on this new behavior.

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] multiset module

[Martin J. <mar...@em...>]

On Mon, 26 Apr 2004, Nicolas Cannasse wrote:

> > Hi all,
> > I'm using this module in my projects and I'm wondering if it's possib=
le
> > to include it in extlib. It's a multiset implemetation based on avl
> > trees.
> >
> > http://lamp.epfl.ch/~sbriais/caml/multiset.tgz
> >
> > I didn't ask to author yet, but it's GPL...
>
> ExtLib is LGPL without linking clauses ( same licence as Ocaml Standar
> Libary ) and is then not compatible with GPL.
> Is a multiset "common usage" enough to be included into ExtLib ?

From multiset.mli, I read:

(* original file set.ml[i] by Xavier Leroy *)
(* upgraded to multiset by S=E9bastien Briais *)
(* other contributors: Haakon Nilsen (union bug) *)

(*  This file is distributed under the terms of the GNU Library General *=
)
(*  Public License, with the special exception on linking described     *=
)
(*  LICENSE file which comes with OCaml distribution.                   *=
)


So, this is LGPL!


Martin

Re: [Ocaml-lib-devel] Is this code of interest for Extlib?

[Nicolas C. <war...@fr...>]

> Hi,
>
> I have found that, as I start programming with OCaml, there are certain
> functions I keep writing and certain features I keep wanting.  I started
> to collect these, and recently released the first "MissingLib".  You can
> find the ocamldoc docs at
> http://quux.org/devel/missinglib/html/index.html.  Among other things,
> there is ConfigParser, a module for parsing sectioned configuration
> files (modeled after Python's ConfigParser module) and various utilities
> for operating on hash tables, lists, and strings.  The module depends on
> nothing outside of the standard OCaml distribution, and consists of pure
> OCaml code (ConfigParser does use ocamllex/yacc though).
>
> Would you be interested in incorpating some or all of this into Extlib?
> Sources are avaiable for inspection at
> gopher://quux.org/1/devel/missinglib or http://quux.org/devel/missinglib.

Some comments :
- the ConfigParser is nice, but lacks some persitency and typing. I would
like to see it unified with the Symbols module proposed recently on this
list (looks like the SF mailling list archives are not up-to-date :'( ).
IMHO, it would be nice to have some persistant storage for configuration
data which would be stored in a single user database file and made
accessible for all ocaml programs ( a little like a portable windows
registry )
- Hashtbloper are pure syntactic sugar and each user should be free to
define its own bindings.
- you will be happy to know that most of the functions in Hashtblutil are
already in ExtLib extHashtbl module
- current Ocaml Lexer is providing (at last) support for line numbers in
error messages (see Lexing.position)
- splices should be interfaced with Enums in order to scale well with the
increasing number of types to support (string, list, array, bigarray,
dynarray, hashtbl..... )
If you think I forgot something that should definitly be added to the
ExtLib, please send back an email.

> Other projects I am considering (which would also be pure OCaml)
> include:
>
>  * Client-side IMAP library
>  * Asynchronous I/O system (patterned after www.twistedmatrix.com for
>    Python)

Theses both are nice.
Async IO might be tricky to implement correctly in pure caml.

Best Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] multiset module

[Nicolas C. <war...@fr...>]

> Hi all,
> I'm using this module in my projects and I'm wondering if it's possible
> to include it in extlib. It's a multiset implemetation based on avl
> trees.
>
> http://lamp.epfl.ch/~sbriais/caml/multiset.tgz
>
> I didn't ask to author yet, but it's GPL...

ExtLib is LGPL without linking clauses ( same licence as Ocaml Standar
Libary ) and is then not compatible with GPL.
Is a multiset "common usage" enough to be included into ExtLib ?

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] IO oo wrappers

[Nicolas C. <war...@fr...>]

> On Sun, Apr 25, 2004 at 10:41:26PM +0200, Nicolas Cannasse wrote:
> > Here's some OO wrappers proposal for IO module.
> >
> > As Yamagata Yoriyuki suggested, theses can be useful in order to provide
> > ExtLib IO compatibility without the need to add a dependency to IO
module
>
> I've just started looking at this project, but I am confused about what
> IO module you're talking about -- I don't see one at
> http://ocaml-lib.sourceforge.net/doc/.
[...]

This documentation is currently only about the 7-months old 1.0b ExtLib
release. I highly recommend you to checkout directly from the CVS : there is
new modules. IO is actually a wrapper on several kind of "files".

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Towards release 1.1

[Nicolas C. <war...@fr...>]

> On Sun, Apr 25, 2004 at 11:14:43AM +0200, Nicolas Cannasse wrote:
> > > waiting for OCaml DBI 's author Richard Johns answer.
> > > Everybody is of course welcome in contributing documentation,
comments, or
> > > code before next release.
> >
> > Today :
> > - added Base64 IO support (for mapping an IO with a Base64 encoding) and
> > documentation
> > - committed dbi.ml and dbi.ml , common DB interfaces for OCamlDBI.
>
> Have you added OcamlDBI itself, or simply some sort of interface to it?
> If the latter, what is the point, given than OcamlDBI is itself a
> generic interface?  If the former, what is the point, given that
> OcamlDBI already exists? :-)

It's OcamlDBI itself, but only the "common headers" since the drivers needs
C code.
It was included in ExtLib with the agreement of Richard Jones, for the sake
of widespread of both librairies. Later, OcamlDBI might be only maintained
into the ExtLib CVS tree, but nothing has been decided yet.

Best Regards,
Nicolas Cannasse

[Ocaml-lib-devel] multiset module

[Pietro A. <Pie...@an...>]

Hi all,
I'm using this module in my projects and I'm wondering if it's possible
to include it in extlib. It's a multiset implemetation based on avl
trees.

http://lamp.epfl.ch/~sbriais/caml/multiset.tgz

I didn't ask to author yet, but it's GPL...

p

-- 
++ "All great truths begin as blasphemies." -George Bernard Shaw
++ Please avoid sending me Word or PowerPoint attachments.
   See http://www.fsf.org/philosophy/no-word-attachments.html

Re: [Ocaml-lib-devel] properties of symbols

[Martin J. <mar...@em...>]

About functors, I saw that there is defunctorizer which name is
"ocamldefun":
  http://www.lri.fr/~signoles/ocamldefun/manual.html

It is supposed to inline all the code and thus produce efficient code, but
you must have the source (.ml) of the functor.

Until yesterday, I really thought that functor application was more or
less like using a macro...


Martin

[Ocaml-lib-devel] Is this code of interest for Extlib?

[John G. <jgo...@co...>]

Hi,

I have found that, as I start programming with OCaml, there are certain
functions I keep writing and certain features I keep wanting.  I started
to collect these, and recently released the first "MissingLib".  You can
find the ocamldoc docs at
http://quux.org/devel/missinglib/html/index.html.  Among other things,
there is ConfigParser, a module for parsing sectioned configuration
files (modeled after Python's ConfigParser module) and various utilities
for operating on hash tables, lists, and strings.  The module depends on
nothing outside of the standard OCaml distribution, and consists of pure
OCaml code (ConfigParser does use ocamllex/yacc though).  

Would you be interested in incorpating some or all of this into Extlib?
Sources are avaiable for inspection at
gopher://quux.org/1/devel/missinglib or http://quux.org/devel/missinglib.

Other projects I am considering (which would also be pure OCaml)
include:

 * Client-side IMAP library
 * Asynchronous I/O system (patterned after www.twistedmatrix.com for
   Python)

-- John

Re: [Ocaml-lib-devel] IO oo wrappers

[John G. <jgo...@co...>]

On Sun, Apr 25, 2004 at 10:41:26PM +0200, Nicolas Cannasse wrote:
> Here's some OO wrappers proposal for IO module.
> 
> As Yamagata Yoriyuki suggested, theses can be useful in order to provide
> ExtLib IO compatibility without the need to add a dependency to IO module

I've just started looking at this project, but I am confused about what
IO module you're talking about -- I don't see one at
http://ocaml-lib.sourceforge.net/doc/.

In any case, I have thought about some sort of generic wrapper for I/O
as well.  In OCaml, there are already two different I/O capabilities in
the standard distribution -- the channels in Pervasives, and the Unix
module's capabilities.

It would be useful to, IMHO, define a standardized interface that can be
implemented for both these and other types.  For instance, one might
have:

ReadableFile
  Methods: read(), readline(), readlines(), etc.
WritableFile
  Methods: write(), flush(), truncate(), etc.
SeekableFile
  Methods: seek(), tell(), etc.

Any given implementation could inherit and implement one or both of
ReadableFile and optionally SeekableFile.  There would be other benefits
to this as well.  For instance, one could implement a virtual file
object using Buffers.  This would be similar in concept to Python's
StringIO, which lets you pass a file-like object to any function
expecting to do I/O; that I/O is emulated, and the contents of the
string can be accessed later.

-- John

Re: [Ocaml-lib-devel] Towards release 1.1

[John G. <jgo...@co...>]

On Sun, Apr 25, 2004 at 11:14:43AM +0200, Nicolas Cannasse wrote:
> > waiting for OCaml DBI 's author Richard Johns answer.
> > Everybody is of course welcome in contributing documentation, comments, or
> > code before next release.
> 
> Today :
> - added Base64 IO support (for mapping an IO with a Base64 encoding) and
> documentation
> - committed dbi.ml and dbi.ml , common DB interfaces for OCamlDBI.

Have you added OcamlDBI itself, or simply some sort of interface to it?
If the latter, what is the point, given than OcamlDBI is itself a
generic interface?  If the former, what is the point, given that
OcamlDBI already exists? :-)

-- John