OCaml ExtLib

On Fri, 19 Mar 2004, Nicolas Cannasse wrote:

> - base64 encode/decode
> - abstract high level I/O with support for C basic types ( read_i16 ,
> write_f16 ..... )
> - zlib deflate/inflate written in pure OCaml.

One of the things I've been nooddling around with is a radicaly new I/O 
arhitecture.  The basic idea is to make i/o more like java and less like 
C.  The core idea is that there would be four classes of objects:

1) sinks and sources.  These would be the fundamental sources/destinations 
of the data- files, sockets, and strings would all be sinks and/or 
sources.  Most likely these will be built on top of the old-style Ocaml 
I/O routines.

2) filters.  These look like a sink or source, but wrap either a 
sink/source or another filter.  Examples of filters would 
compression/decompression, encryption/decryption, mime or uu 
encode/decode, eoln conversion, etc.  Also, a filter might just collect 
statistics on the stuff as it goes by, not changing the data- so line 
counters, word counters, and check summers would be filters.

3) formatters and parsers.  Formatters take the fundamental datatypes of
ocaml (int, float, etc) and convert them into strings and write the
strings to a filter or source/sink.  Parsers take strings and parse them 
back into the fundamental types of ocaml.

4) Directories- collections of one or more sources or sinks or
subdirectories.  This is so we can deal with "multi-file" streams, like
tar or zip files.  This might also be a way to generically handle file 
system issues.  This might also be the way to deal with file forks on 
MacOS.

The questions I haven't answered yet are:

1) Unicode or no unicode?  It's not that converting to/from unicode into 
one of the utf- formats is so hard, it's just that now a stream of 
characters is a different concept than a stream of bytes, with different 
filters working on different types streams.  And a conversion object stuck 
in between.  All pipes would now be at least three objects deep 
(formatter, unicode conversion, source/sink), instead of just two.

2) What are the semantics of directories?  Do we want to include file 
system fun?

3) How to deal with the lack of polymorphism on formatters.  All of the 
implementations of this structure I've seen (ab)use polymorphism to 
implement the formatters- they have a print function which is overloaded 
for the specific types- print(int), print(float), etc.  Often they have an 
operator overloaded or defined as well.  I'd love to be able to have a 
print function with a signature filter -> 'a -> filter, but I can't think 
of how to do it.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

Before anything, I'd like to mention the recent exchange about another
"extlib" in the caml-list and others.  I'm little embarrassed in the
current situation.  If I remember correctly, another "extlib" is older
than ours, so, in my opinion, we have to change the name.  Whatever
reasons there are, we have to give a due credit to the previous work.
If we are going to change the nature of our library, then it is a good
opportunity to change the name.

From: "Nicolas Cannasse" <warplayer@...>
Subject: [Ocaml-lib-devel] Future of ExtLib
Date: Fri, 19 Mar 2004 09:29:01 +0100

> That's convenient, but in fact since we're keeping 99% compability
> with stdlib, having the user to port the small parts of his code and
> then he can use all extensions provided as if he was using stdlib
> seems to be a fair trade.  Of course this means some changes to
> current project, and that's why I would like to get your comments
> and advices about this - I'm especialy interested in current
> ExtLib's contributors opinions.

I'm not clear about what you want to do.  But if you mean, say, we
provide List module in extlib, so that override List of the stdlib,
then I think it is definitely a bad idea. In addition to forcing to
use the new stdlib in order to access some module in extlib, it will
cause incomprehensive "inconsistent assumption" error if modules using
old stdlib and using new stdlib are mixed up.  If we use -pack option,
then the change would be more bearable, but I prefer to split extlib
to several packages, one for replacing stdlib, another for providing
new features.  Maybe we could split the packages for their purpose,
like providing new data structure, I/O, etc, too.

From: "Nicolas Cannasse" <warplayer@...>
Subject: [Ocaml-lib-devel] Future of ExtLib
Date: Fri, 19 Mar 2004 09:29:01 +0100

> Concerning additionnals modules here's what's on my wish-list (which is
> somehow also on my current todo-list) :
> - base64 encode/decode
> - abstract high level I/O with support for C basic types ( read_i16 ,
> write_f16 ..... )
> - zlib deflate/inflate written in pure OCaml.

Do you interested in diet set and map? (set and map over integer,
internally represented as sets and maps over intervals.)  I could
contribute them.  Also, I'd like to change install.ml so that it
ignores findlib if the destination directory is explicitly given by
the arguments. 

--
Yamagata Yoriyuki

> > - base64 encode/decode
> > - abstract high level I/O with support for C basic types ( read_i16 ,
> > write_f16 ..... )
> > - zlib deflate/inflate written in pure OCaml.
>
> One of the things I've been nooddling around with is a radicaly new I/O
> arhitecture.  The basic idea is to make i/o more like java and less like
> C.  The core idea is that there would be four classes of objects:
[...]

Hi Brian,
What we need is an high-level IO abstraction that will offer a wide API for
most of the common usages.
The IO module I posted earlier on this list was a beginning of answer to
this. It didn't made his way to the CVS because I lacked time, but looks
like there was no people against it.
In this IO module, I made the following choices regarding polymorphism :

(quoting myself)

For efficiency reason each input/output have two ways of reading/writing
data : for example a channel input can write char by char or directly
strings. it's then a (char,string) input. An ouput takes a third parameter
which is the value returned by a call to close.


(end-of-quote)

So we have here :
    * ('a,'b) input  : an input to a file is a (char,string) input
    * ('a,'b,'c) output : an output to a buffer is a (char,string,string)
output since "closing" the buffer returns the total string written into
we can provide several conversion "parsers" functions such as
    * val in_ord : (char,string) input -> (int,int list) input
    * val in_chr : (int,int list) input -> (char,string) input
or "filters" such as :
    * val in_b64 : (char,string) input -> (char,string) input
    * val out_zlib : (char,string,'a) output -> (char,string,'a) output

Concerning the "Directories", I think its even more high level and should be
handled in a different module that will be built on top of IO. Please
remember that the "file" concept have no meaning in an abstract IO.
Concerning Unicode, adding a filter to handle this looks okay (not by
default). For the "polymorphism" of formatters, this is not really possible
in the OCaml type system. One choice is to use printf/scanf on an output :
that's exactly what's I'm doing in IO module.

Regards,
Nicolas Cannasse

Hello,

On Sat, Mar 20, 2004 at 12:33:07PM +0900, Yamagata Yoriyuki wrote:
> Before anything, I'd like to mention the recent exchange about another
> "extlib" in the caml-list and others.  I'm little embarrassed in the
> current situation.  If I remember correctly, another "extlib" is older
> than ours, so, in my opinion, we have to change the name.  Whatever
> reasons there are, we have to give a due credit to the previous work.
> If we are going to change the nature of our library, then it is a good
> opportunity to change the name.
> 

I don't agree with your point of view. The so called "older" version of
extlib is only "older" because before it was named "stew". And one day,
the upstream decided to recall it extlib. I see no reason to change the
name of extlib because one guy thinks it was a prettier name.

It is a personnal point of view, but i keep considering that extlib is
"tm" to sf library ( and not the other one ).

Regard
Sylvain Le Gall

> Before anything, I'd like to mention the recent exchange about another
> "extlib" in the caml-list and others.  I'm little embarrassed in the
> current situation.  If I remember correctly, another "extlib" is older
> than ours, so, in my opinion, we have to change the name.  Whatever
> reasons there are, we have to give a due credit to the previous work.
> If we are going to change the nature of our library, then it is a good
> opportunity to change the name.

I'll answer this one separatly.
Shawn Wagner actually have a library known has ExtLib.
He contacted me directly when we first released "our" ExtLib in order to ask
if we were planing to change the name. I answered no. The reason was that :
- no announcement of his library have been made on the official caml list
- it was not registered in the Humps
The first info I found concerning Shawn ExtLib was on 6 Jul 2003, at this
time we were actively working to release 1.0.
I'm not sure that the first released hold the name (or tomorrow I'll feel
like releasing some "Longhorn" software !-)
IMHO, there is nothing to change, having a name conflict is okay as long as
the people can make the difference, and I think we have more user than other
Extlib. But if most of people here agree to change the name, then let's do
so...

Regards,
Nicolas Cannasse

> I'm not clear about what you want to do.  But if you mean, say, we
> provide List module in extlib, so that override List of the stdlib,
> then I think it is definitely a bad idea. In addition to forcing to
> use the new stdlib in order to access some module in extlib, it will
> cause incomprehensive "inconsistent assumption" error if modules using
> old stdlib and using new stdlib are mixed up.  If we use -pack option,
> then the change would be more bearable, but I prefer to split extlib
> to several packages, one for replacing stdlib, another for providing
> new features.  Maybe we could split the packages for their purpose,
> like providing new data structure, I/O, etc, too.

I don't agree on this "inconsistent assumption" since the user, when
actually "switching" to ExtLib, will only have to compile its codebase using
ExtLib instead of stdlib. It's not an easy jump, and I'm little concerned
about the problems that extlib incompabilities (such as different exception
policy) will show in 3rd party librairies that the user will not be able to
modify in order to use with ExtLib...

> > Concerning additionnals modules here's what's on my wish-list (which is
> > somehow also on my current todo-list) :
> > - base64 encode/decode
> > - abstract high level I/O with support for C basic types ( read_i16 ,
> > write_f16 ..... )
> > - zlib deflate/inflate written in pure OCaml.
>
> Do you interested in diet set and map? (set and map over integer,
> internally represented as sets and maps over intervals.)  I could
> contribute them.  Also, I'd like to change install.ml so that it
> ignores findlib if the destination directory is explicitly given by
> the arguments.

Don't hesitate to change install.ml.
Concerning diet set/map, I'm not sure I understand for what kind of general
purpose they're useful ?

Regards,
Nicolas Cannasse

On Fri, Mar 19, 2004 at 01:37:14PM -0600, Brian Hurt wrote:
> 1) Unicode or no unicode?  It's not that converting to/from unicode into 
> one of the utf- formats is so hard, it's just that now a stream of 
> characters is a different concept than a stream of bytes, with different 
> filters working on different types streams.  And a conversion object stuck 
> in between.  All pipes would now be at least three objects deep 
> (formatter, unicode conversion, source/sink), instead of just two.

UTF-8 support should be there, and should be driven from the LANG /
LC_* / locale.  It's a non-trivial amount of work to get this to work
of course.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
PTHRLIB is a library for writing small, efficient and fast servers in C.
HTTP, CGI, DBI, lightweight threads: http://www.annexia.org/freeware/pthrlib/

From: "Nicolas Cannasse" <warplayer@...>
Subject: Re: [Ocaml-lib-devel] Future of ExtLib
Date: Sat, 20 Mar 2004 11:20:18 +0100

> It's not an easy jump, and I'm little concerned
> about the problems that extlib incompabilities (such as different exception
> policy) will show in 3rd party librairies that the user will not be able to
> modify in order to use with ExtLib...

Perhaps many people would want to stay with old stdlib because of
the stability issue, and just because it is easier.

Concerning libraries, I want my library depend to Extlib.  But if a
user have to switch to new stdlib just for using my library, then I
feel it is too much to ask.

> Concerning diet set/map, I'm not sure I understand for what kind of general
> purpose they're useful ?

Diet uses less memory for sets which contain large intervals, but I
agree that it may not be especially useful for the general use.

--
Yamagata Yoriyuki

From: "Nicolas Cannasse" <warplayer@...>
Subject: Re: [Ocaml-lib-devel] Future of ExtLib
Date: Sat, 20 Mar 2004 11:15:45 +0100

> Shawn Wagner actually have a library known has ExtLib.
> He contacted me directly when we first released "our" ExtLib in order to ask
> if we were planing to change the name. I answered no. The reason was that :
> - no announcement of his library have been made on the official caml list
> - it was not registered in the Humps
> The first info I found concerning Shawn ExtLib was on 6 Jul 2003, at this
> time we were actively working to release 1.0.
> I'm not sure that the first released hold the name (or tomorrow I'll feel
> like releasing some "Longhorn" software !-)
> IMHO, there is nothing to change, having a name conflict is okay as long as
> the people can make the difference, and I think we have more user than other
> Extlib. But if most of people here agree to change the name, then let's do
> so...

OK.  I follow your decision.  However, there is still issue of name
collision of modules.  I'd like to propose doing optionally -pack the
module for a name chosen by a user.

--
Yamagata Yoriyuki

From: Richard Jones <rich@...>
Subject: Re: [Ocaml-lib-devel] Future of ExtLib
Date: Sat, 20 Mar 2004 10:20:16 +0000

> UTF-8 support should be there, and should be driven from the LANG /
> LC_* / locale.  It's a non-trivial amount of work to get this to work
> of course.

I could contribute this.  I have working code for Camomile.  But, it
requires small C code to call ISO-C functions.  What do you think,
Nocolas?

Windows (proper) supports all ISO-C functions?  and (for the future
reference) how about strcol?

In addition, I'm thinking of UTF-16 support (for Windows and Java)  A
major problem is lack of 16-bit interger array in OCaml.  We could use
a string and do type-cast when it is passed to C functions.  This
would  involve detecting endianness in installtion time and providing
some C-macros.

Alternatively, we could use Bigarray, but Bigarray is not efficient.

I'm interested in other people's opinions.

--
Yamagata Yoriyuki

> > UTF-8 support should be there, and should be driven from the LANG /
> > LC_* / locale.  It's a non-trivial amount of work to get this to work
> > of course.
>
> I could contribute this.  I have working code for Camomile.  But, it
> requires small C code to call ISO-C functions.  What do you think,
> N(i)colas?

That's little troublesome.
Even if we have only one C little file, the installation, compilation --- 
for a lot of different kind of systems --- is troublesome.
Oh ! just's got a good idea.
If we have to add a C part, then what we should do is a C emulator.
How does it works ?
- it's a C program that can resolve and call dynlinked C functions
- it can also manipulate basic C data structures (convert from and to OCaml
data, and also "raw" access , a little like Obj module)
- it can alloc and free some C memory
Then when we need to add some C parts, we just need to write some Caml code
that will use Emu-C, and which will handle the system particularities... at
runtime.

exemple (far from being correct, just give an idea) :

let strstr = EmuC.resolve "libc" "strstr" in
let found = EmuC.call strstr ["my_string";"_s"] in
if found = EmuC.null then
    None
else
    Some (EmuC.alloc_string found)

> Windows (proper) supports all ISO-C functions?  and (for the future
> reference) how about strcol?

I don't know about that. There is strcoll ANSI compatible function. ( and
wcscoll for Unicode strings )

> In addition, I'm thinking of UTF-16 support (for Windows and Java)  A
> major problem is lack of 16-bit interger array in OCaml.  We could use
> a string and do type-cast when it is passed to C functions.  This
> would  involve detecting endianness in installtion time and providing
> some C-macros.
>
> Alternatively, we could use Bigarray, but Bigarray is not efficient.
>
> I'm interested in other people's opinions.

Use (future) EmuC :-)

let block = EmuC.alloc size in
and then EmuC.setw / EmuC.getw to access 16-bits values into block.

Nicolas Cannasse

(getting back to some old thread)

> > - base64 encode/decode
> > - abstract high level I/O with support for C basic types ( read_i16 ,
> > write_f16 ..... )
> > - zlib deflate/inflate written in pure OCaml.
>
> One of the things I've been nooddling around with is a radicaly new I/O
> arhitecture.  The basic idea is to make i/o more like java and less like
> C.  The core idea is that there would be four classes of objects:
>
> 1) sinks and sources.  These would be the fundamental sources/destinations
> of the data- files, sockets, and strings would all be sinks and/or
> sources.  Most likely these will be built on top of the old-style Ocaml
> I/O routines.
>
> 2) filters.  These look like a sink or source, but wrap either a
> sink/source or another filter.  Examples of filters would
> compression/decompression, encryption/decryption, mime or uu
> encode/decode, eoln conversion, etc.  Also, a filter might just collect
> statistics on the stuff as it goes by, not changing the data- so line
> counters, word counters, and check summers would be filters.

Theses two are now reality in the IO module.
For example, I managed to wrap CamlZip module on an IO and - without
changing a line of my code - I can now read/write over normal or compressed
files. Here's the code that's converting a standard IO into a
compressed/uncompressed one. I think it's worth including into the ExtLib
but the problem is it rely on another module (CamlZip, by Xavier Leroy)
which itself contains C stubs using the ZLib. I think we need an additional
folder into the ExtLib called "tools" that will be useful parts of code -
yet not installed because of external dependencies.
What do you think about the idea ?

Here's the code - the inflate method is still broken since it requires to
know the available data size, and is not "inflating on demand".

Nicolas Cannasse

----
let inflate i =
 let available = ref (match IO.available i with None -> assert false | Some
size -> size) in
 let buf = Buffer.create 0 in
 let refill str =
  let len = String.length str in
  if !available >= len then begin
   let data = IO.nread i len in
   String.blit data 0 str 0 len;
   available := !available - len;
   len
  end else begin
   let size = !available in
   let data = IO.nread i size in
   String.blit data 0 str 0 size;
   available := 0;
   size
  end
 in
 let flush str n =
  Buffer.add_substring buf str 0 n
 in
 Zlib.uncompress ~header:true refill flush;
 IO.input_string (Buffer.contents buf)

let deflate o =
 let buf = Buffer.create 0 in
 let flush() =
  let data = Buffer.contents buf in
  let pos = ref 0 in
  let available = ref (String.length data) in
  let refill str =
   let len = String.length str in
   if !available >= len then begin
    String.blit data !pos str 0 len;
    available := !available - len;
    pos := !pos + len;
    len
   end else begin
    let size = !available in
    String.blit data !pos str 0 size;
    available := 0;
    pos := !pos + size;
    size
   end
  in
  let flush str n =
   if n = String.length str then
    IO.nwrite o str
   else
    IO.nwrite o (String.sub str 0 n)
  in
  Zlib.compress ~level:9 ~header:true refill flush;
  IO.flush o;
  Buffer.reset buf;
 in
 IO.create_out (Buffer.add_char buf) (Buffer.add_string buf) (fun () ->
Buffer.length buf) (fun () -> flush(); IO.flush o) (fun () -> flush();
IO.close_out o)

On Fri, 9 Apr 2004, Nicolas Cannasse wrote:

> > 1) sinks and sources.  
> > 2) filters.  
> Theses two are now reality in the IO module.

This is good- these two were the "core" of the idea, the rest was 
decoration.

> For example, I managed to wrap CamlZip module on an IO and - without
> changing a line of my code - I can now read/write over normal or compressed
> files. Here's the code that's converting a standard IO into a
> compressed/uncompressed one. I think it's worth including into the ExtLib
> but the problem is it rely on another module (CamlZip, by Xavier Leroy)
> which itself contains C stubs using the ZLib. I think we need an additional
> folder into the ExtLib called "tools" that will be useful parts of code -
> yet not installed because of external dependencies.
> What do you think about the idea ?

Actually, this is a deep problem, and not limited to just compression.  I
could see reimplementing zlib in pure Ocaml.  But the #2 thing to do is
encryption/decryption.  For which you should not only call out to C, but
have the C call hand tuned assembly.
 
20 cycles/byte encryption speed (approx. the speed of a good symmetric key
crypto system like AES or Twofish) sounds real good, until you realize
that this means 10 milliseconds to encrypt a megabyte of data on a 2GHz
machine.  Similiarly, I'm willing to be that RSA encryption using GMP will
be signifigantly faster than using the Ocaml bignum library.  Every cycle
counts in this special case- even C is too slow.

Compression we might want to reimplement in Ocaml.  Reimplementing the 
crypto libraries in pure Ocaml, while theoretically possible, would impose 
severe performance limits.

So, there are three possibilities:

	- Stick with implementing everything in Ocaml.  This gives us 
portability and library independence (you don't need zlib nor gmp 
installed) at the cost of performance

	- Allow C/ASM callouts for performance

	- Provide both, and some mechanism for choosing between them (with 
the attendent problems)

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

> Actually, this is a deep problem, and not limited to just compression.  I
> could see reimplementing zlib in pure Ocaml.  But the #2 thing to do is
> encryption/decryption.  For which you should not only call out to C, but
> have the C call hand tuned assembly.
[...]
> So, there are three possibilities:
>
> - Stick with implementing everything in Ocaml.  This gives us
> portability and library independence (you don't need zlib nor gmp
> installed) at the cost of performance
>
> - Allow C/ASM callouts for performance
>
> - Provide both, and some mechanism for choosing between them (with
> the attendent problems)

The problem is also the cost of reimplemeting.
It was little painful for me to have to use the zlib, since I know it will
requires all my sub-projects to compile and deploy some C code : the zlib
itself - but also the CamlZip stubs (for which an Win32 Makefile was not
given). But after looking at the ZLib format RFC, I somehow thought that it
would take me quite a lot of time to reimplement it, and in the end maybe
get a lower quality result (since zlib itself is quite a nice piece of code,
highly suppported and optimized).

If I had enough time, this is what I will do :
- write a small C library that can alloc/access C memory , load dynlinked
libraries, retreive and call functions from it
- add Ocaml interface to this C library
- port this C library to all architectures were Ocaml is working (including
the good compilation parameters)
- add this C library to ExtLib and install it by default
and then we can write all the stubs to external C librairies in pure OCaml
using this small C library ( let's call it EmuC ).
We can then provide a lot of stubs for a lot of different C libraries
according that :
    - theses libraries are dynlinkable
    - they can be accessed using EmuC

Good points :
- theses stubs will be pure ocaml and depends only on EmuC so we are
minimizing the dependencies
- the user can compile the stubs without actually having the library
compiled/installed.
- we only have to maintain and port one file of C code : emuC

Bad points :
- we have to correctly write the stubs in order to support several versions
of the dynlinked library (while only a recompilation would have been needed
for C stubs)
- a little speed tradeoff since we're adding an C layer over every memory
access we're doing

Regards,
Nicolas Cannasse

On Fri, 9 Apr 2004, Nicolas Cannasse wrote:

> The problem is also the cost of reimplemeting.
> It was little painful for me to have to use the zlib, since I know it will
> requires all my sub-projects to compile and deploy some C code : the zlib
> itself - but also the CamlZip stubs (for which an Win32 Makefile was not
> given). But after looking at the ZLib format RFC, I somehow thought that it
> would take me quite a lot of time to reimplement it, and in the end maybe
> get a lower quality result (since zlib itself is quite a nice piece of code,
> highly suppported and optimized).

Hmm.  Poking at a little bit, it doesn't look that bad.  Actually, Ocaml 
might be a better language to implement them in, as several of the core 
data structures are already implemented.

> 
> If I had enough time, this is what I will do :
    [ write EmuC ]

The performance I'm not worried about- I don't think it'd be that bad.  
Nor the writting of stubs.  EmuC would just be a library that shouldn't be 
used except by knowledgable people.  Rather like the tricks we do in the 
optimized List module.  We're already saying "do as we say, not as we do."  
This is one of the purposes of libraries, IMHO- the library gets the 
tricky stuff right, and everyone else uses the library.

No, the problems I have with this idea are:

1) You'd still have C dependencies, breaking the Ocaml-only nature of 
ExtLib.

2) You would still have to deal with impedence mismatches- C API's that
don't translate well into Ocaml.  For example, routines which take
pointers to variables to return more than one value.  Or APIs that depend 
upon the "shape" of variables (for example, using unions).  Or that want 
to use Macros to inline code.  I'm not sure what all the impedence 
problems might be.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

Hello,

On Fri, Apr 09, 2004 at 12:33:12PM -0500, Brian Hurt wrote:
> On Fri, 9 Apr 2004, Nicolas Cannasse wrote:
> 
> No, the problems I have with this idea are:
> 
> 1) You'd still have C dependencies, breaking the Ocaml-only nature of 
> ExtLib.
> 
> 2) You would still have to deal with impedence mismatches- C API's that
> don't translate well into Ocaml.  For example, routines which take
> pointers to variables to return more than one value.  Or APIs that depend 
> upon the "shape" of variables (for example, using unions).  Or that want 
> to use Macros to inline code.  I'm not sure what all the impedence 
> problems might be.
> 

Even if i am not an Extlib developper, i permit myself to raise my
voice... Sorry if you don't agree.

I think extlib is a great project by the 100% Pure Ocaml coding style. I
think putting 1 byte of C in it is not a good idea. It will break a lot
of things, need to be maintained over a lot of arch ( including Ms Win,
Linux, Unix, Irix et al ). I think it is far too complicated to be
interessant.

My opinion, is that you can create a new repository especially for
project related to extlib... It will be far more simple, and will gives
dependency on C only on this external module. Just to give you an
example : 
CVSROOT/
extlib/
extlib-io-zip/
extlib-io-aes/
...

I think it is the less complicated you can do...
Off course, the compilation will require to load other module than
extlib, but i think it is worth the effort.

Thank you for reading
Kind regard
Sylvain Le Gall

> > No, the problems I have with this idea are:
> >
> > 1) You'd still have C dependencies, breaking the Ocaml-only nature of
> > ExtLib.
> >
> > 2) You would still have to deal with impedence mismatches- C API's that
> > don't translate well into Ocaml.  For example, routines which take
> > pointers to variables to return more than one value.  Or APIs that
depend
> > upon the "shape" of variables (for example, using unions).  Or that want
> > to use Macros to inline code.  I'm not sure what all the impedence
> > problems might be.
> >
>
> Even if i am not an Extlib developper, i permit myself to raise my
> voice... Sorry if you don't agree.
>
> I think extlib is a great project by the 100% Pure Ocaml coding style. I
> think putting 1 byte of C in it is not a good idea. It will break a lot
> of things, need to be maintained over a lot of arch ( including Ms Win,
> Linux, Unix, Irix et al ). I think it is far too complicated to be
> interessant.
>
> My opinion, is that you can create a new repository especially for
> project related to extlib... It will be far more simple, and will gives
> dependency on C only on this external module. Just to give you an
> example :
> CVSROOT/
> extlib/
> extlib-io-zip/
> extlib-io-aes/
> ...
>
> I think it is the less complicated you can do...
> Off course, the compilation will require to load other module than
> extlib, but i think it is worth the effort.

The point about EmuC is :
- do we write and maintain C stubs for each of the external librairies we
might need
or
- do we use EmuC only and write stubs in OCaml using EmuC
If we choose the EmuC way, then we have only one - quite small - C file to
maintain. That's might still be quite big, so maybe we don't have to put
EmuC in the default install at the beginning, but after we have stubs for
let's say 5 or more librairies, it will be worth it.

Other choice is to keep away from C, but there is some times (zlib,
cryptography, ipv6 support, and many others... ) that we can't or that the
effort to write it again in ocaml is simply to big compare to writing stubs
and maintaining EmuC. I don't want also to put C code into ExtLib, but maybe
one day we'll have to :-)

Regards,
Nicolas Cannasse

Hello,

On Fri, Apr 09, 2004 at 08:59:51PM +0200, Nicolas Cannasse wrote:
> 
> The point about EmuC is :
> - do we write and maintain C stubs for each of the external librairies we
> might need
> or
> - do we use EmuC only and write stubs in OCaml using EmuC
> If we choose the EmuC way, then we have only one - quite small - C file to
> maintain. That's might still be quite big, so maybe we don't have to put
> EmuC in the default install at the beginning, but after we have stubs for
> let's say 5 or more librairies, it will be worth it.
> 
> Other choice is to keep away from C, but there is some times (zlib,
> cryptography, ipv6 support, and many others... ) that we can't or that the
> effort to write it again in ocaml is simply to big compare to writing stubs
> and maintaining EmuC. I don't want also to put C code into ExtLib, but maybe
> one day we'll have to :-)
> 

Well, i have nothing against emuc... I think it can come along extlib, but
i don't think it is good to have it in extlib ( just my point of view ).

However, have you considered some tools like camlidl ?

I use it to wrap some C stuff, and it is very simple and powerful ( but
it is not very flexible... ). It allows you to 
cp zlib.h camlzlib.idl
vim camlzlib.idl -> explain that this structure, should this one in
ocaml, this function returns, if the return is this, then it is an error
etc
camlidl camlzlib.idl -> camlzlib.c camlzlib.ml camlzlib.mli
compile

It is very easy to write stubs with it... 

I think it is a good tool to write easily C stub in Ocaml ( moreover it
is written by a guy you should know : X. Leroy )

http://caml.inria.fr/camlidl/

I don't say the solution is perfect, but i have so many problem using
C on different architecture comparing to ocaml portability ( which is
sometime partial -- essentially when it depends on C code ).

Kind regard
Sylvain Le Gall

On Fri, 9 Apr 2004 sylvain.le-gall@... wrote:

> Hello,
> 
> Even if i am not an Extlib developper, i permit myself to raise my
> voice... Sorry if you don't agree.

IMHO, If you're an Extlib user, you have the right to a voice here.

> 
> I think extlib is a great project by the 100% Pure Ocaml coding style. I
> think putting 1 byte of C in it is not a good idea. It will break a lot
> of things, need to be maintained over a lot of arch ( including Ms Win,
> Linux, Unix, Irix et al ). I think it is far too complicated to be
> interessant.

Actually, writting portable C isn't the problem.  I routinely write C code 
which is much more widely portable than Ocaml is.  

But the more I think about it, the more I think linking to external 
libraries has other problems.  For example, zlib and gmp both are 
standard installs on Linux systems.  They both exist for Windows, but are 
not part of the standard installs.  So now, to use extlib on windows, you 
now not only need to get ocaml and extlib, but also zlib and gmp.  Plus, 
the code I'm thinking of grabbing for symmetric key crypto aren't 
standardly packaged in any library I'm aware of.  How we connect to this 
code is almost irrelevent, the code still needs to be there.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

Hello,

On Fri, Apr 09, 2004 at 04:00:37PM -0500, Brian Hurt wrote:
> On Fri, 9 Apr 2004 sylvain.le-gall@... wrote:
> 
> > Hello,
> > 
> > Even if i am not an Extlib developper, i permit myself to raise my
> > voice... Sorry if you don't agree.
> 
> IMHO, If you're an Extlib user, you have the right to a voice here.
> 

Thanks ;-)

> > 
> > I think extlib is a great project by the 100% Pure Ocaml coding style. I
> > think putting 1 byte of C in it is not a good idea. It will break a lot
> > of things, need to be maintained over a lot of arch ( including Ms Win,
> > Linux, Unix, Irix et al ). I think it is far too complicated to be
> > interessant.
> 
> Actually, writting portable C isn't the problem.  I routinely write C code 
> which is much more widely portable than Ocaml is.  
> 

Well, most of the time, porting from BE to LEndian and trading with
different int size is a great problem ( for me at least ). You need a
lot of #define #ifdef... I don't like this... Test coverage for code is
enough difficult. Adding compile time condition give you more code to
test...

> But the more I think about it, the more I think linking to external 
> libraries has other problems.  For example, zlib and gmp both are 
> standard installs on Linux systems.  They both exist for Windows, but are 
> not part of the standard installs.  So now, to use extlib on windows, you 
> now not only need to get ocaml and extlib, but also zlib and gmp.  Plus, 
> the code I'm thinking of grabbing for symmetric key crypto aren't 
> standardly packaged in any library I'm aware of.  How we connect to this 
> code is almost irrelevent, the code still needs to be there.
> 

I agree...

The idea of having zlib, encryption is good but i think it should be not
part of extlib.

Kind regard
Sylvain Le Gall

ps : do you plan to use cryptokit and cryptgps for your library ?

> > Hello,
> >
> > Even if i am not an Extlib developper, i permit myself to raise my
> > voice... Sorry if you don't agree.
>
> IMHO, If you're an Extlib user, you have the right to a voice here.

Same opinion here.

> > I think extlib is a great project by the 100% Pure Ocaml coding style. I
> > think putting 1 byte of C in it is not a good idea. It will break a lot
> > of things, need to be maintained over a lot of arch ( including Ms Win,
> > Linux, Unix, Irix et al ). I think it is far too complicated to be
> > interessant.
>
> Actually, writting portable C isn't the problem.  I routinely write C code
> which is much more widely portable than Ocaml is.
>
> But the more I think about it, the more I think linking to external
> libraries has other problems.  For example, zlib and gmp both are
> standard installs on Linux systems.  They both exist for Windows, but are
> not part of the standard installs.  So now, to use extlib on windows, you
> now not only need to get ocaml and extlib, but also zlib and gmp.  Plus,
> the code I'm thinking of grabbing for symmetric key crypto aren't
> standardly packaged in any library I'm aware of.  How we connect to this
> code is almost irrelevent, the code still needs to be there.

As I told you : you don't need to have the libs installed to compile stubs.
Now if you want to use the features that are needind the libs, you only need
to have the dynamic library in your path so that EmuC can find it. All
linking is done dynamicly at runtime. As for the zlib - and many other
libraries - there is always some binary available for windows, because we -
windows programmers - are known to be not clever enough to rebuild from a
Makefile :-)

To answer to Sylvain, crypto was just an example of external library, I'm
not sure it should be part of ExtLib (or maybe only the MD5 - useful enough
to be standard : anyone contributing ? ).

Regards,
Nicolas Cannasse

Hello,

On Fri, Apr 09, 2004 at 11:00:34PM +0200, Nicolas Cannasse wrote:
> > > Hello,
> > >
> > > Even if i am not an Extlib developper, i permit myself to raise my
> > > voice... Sorry if you don't agree.
> >
> > IMHO, If you're an Extlib user, you have the right to a voice here.
> 
> Same opinion here.
> 
> > > I think extlib is a great project by the 100% Pure Ocaml coding style. I
> > > think putting 1 byte of C in it is not a good idea. It will break a lot
> > > of things, need to be maintained over a lot of arch ( including Ms Win,
> > > Linux, Unix, Irix et al ). I think it is far too complicated to be
> > > interessant.
> >
> > Actually, writting portable C isn't the problem.  I routinely write C code
> > which is much more widely portable than Ocaml is.
> >
> > But the more I think about it, the more I think linking to external
> > libraries has other problems.  For example, zlib and gmp both are
> > standard installs on Linux systems.  They both exist for Windows, but are
> > not part of the standard installs.  So now, to use extlib on windows, you
> > now not only need to get ocaml and extlib, but also zlib and gmp.  Plus,
> > the code I'm thinking of grabbing for symmetric key crypto aren't
> > standardly packaged in any library I'm aware of.  How we connect to this
> > code is almost irrelevent, the code still needs to be there.
> 
> As I told you : you don't need to have the libs installed to compile stubs.
> Now if you want to use the features that are needind the libs, you only need
> to have the dynamic library in your path so that EmuC can find it. All
> linking is done dynamicly at runtime. As for the zlib - and many other
> libraries - there is always some binary available for windows, because we -
> windows programmers - are known to be not clever enough to rebuild from a
> Makefile :-)
> 

Yep... But i think it could be achieve by doing an external module... It
has three benefits :
- don't imply C code in extlib
- don't imply dependency on external library
- is a good example to know if you can let people build their own
  external module for extlib ( ie by this way you can test the
  completeness of the interface given to external people to build things
  with extlib ).

> To answer to Sylvain, crypto was just an example of external library, I'm
> not sure it should be part of ExtLib (or maybe only the MD5 - useful enough
> to be standard : anyone contributing ? ).
> 

INRIA has already contribut to this ;-)

( Hash of string are MD5 sums, cryptokit use it directly, cryptokit has
already a MD5 module )

Regard
Sylvain Le Gall

On Fri, 9 Apr 2004, Sylvain LE GALL wrote:

> > Actually, writting portable C isn't the problem.  I routinely write C code 
> > which is much more widely portable than Ocaml is.  
> > 
> 
> Well, most of the time, porting from BE to LEndian and trading with
> different int size is a great problem ( for me at least ). You need a
> lot of #define #ifdef... I don't like this... Test coverage for code is
> enough difficult. Adding compile time condition give you more code to
> test...

Worse yet, I've worked on systems which were *neither* BE nor LE (hint:
DEC tried to switch horses in midstream).  BE/LE only come into play when
you're reading/writting binary data, or playing games with unions.  In the
first case, I tend to construct my ints by hand to control endianess.  If 
you're doing I/O, the extra shift/ors aren't that big of a problem.  As 
for playing games with unions, these are bad ideas anyways, don't do them.

As for int sizes, all this means is you need to think about what types 
things are.  One of the worst habits C coders get into is not thinking 
about what types variables should be.  I'd argue this is more important in 
C than it is in Ocaml.  An example: what type should the variable i be in 
the following code?
    for (i = 0; i < sizeof(arr)/sizeof(arr[0]); ++i) {
        arr[i] = 0;
    }
My answer: i should have the type size_t.  Thinking about what types 
variables should be solves most of the problems (and eliminates the vast 
majority of pointless typecasts).

I hate ifdefs, except for providing imdepotence for header files (at which 
point I insist on them).  But it's surprising how portable you can get 
without them.

> I agree...
> 
> The idea of having zlib, encryption is good but i think it should be not
> part of extlib.

That's where I'm ending up as well.  Or at least not C-based encryption 
and compression.  Ocaml code only.  Note that there might be a sister 
project spawned to use the C code for higher performance.

> ps : do you plan to use cryptokit and cryptgps for your library ?

I hadn't thought about it much.  Last time I took a spin through the 
crypto libraries, I was more than a little surprised that not one used GMP 
for RSA.  Which I found quite surprising, as I'm willing to bet that GMP 
would give you the best possible RSA performance with the least work from 
the implementor.  IIRC, GMP already has an "exponentiate in a modular 
field" operation, implemented with tuned assembly code.  This is the core 
operation of RSA.  For symmetric key and hashing, I was thinking of 
rounding up the hand-tunned assembly versions kicking around.  I haven't 
decided what to do with Elliptic curve yet.

Thinking about it a second, there's a problem with providing Ocaml 
implementations of various symmetric key crypto systems- most of them
assume you have access to efficient 32-bit integers.  Which means you 
either use Int32 at a serious performance and memory hit.  

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

On Apr 9, 2004, at 4:24 PM, Brian Hurt wrote:

> I hadn't thought about it much.  Last time I took a spin through the
> crypto libraries, I was more than a little surprised that not one used 
> GMP
> for RSA.  Which I found quite surprising, as I'm willing to bet that 
> GMP
> would give you the best possible RSA performance with the least work 
> from
> the implementor.  IIRC, GMP already has an "exponentiate in a modular
> field" operation, implemented with tuned assembly code.  This is the 
> core
> operation of RSA.

I was a bit surprised by this as well, so I modified cryptokit to use 
GMP, and I also added in a number of additional features, like DSA, 
SHA-{265, 384, 512}, a number of random number and prime generation 
routines, hash chains, etc.  I've been meaning to package it up for 
quite a while now, but I'm an idiot when it comes to things like 
makefiles, and I was barely able to cobble one together for my own 
needs...  And oh yeah... my ocamldoc code is a bit farkled.

Plus there's the whole issue of getting GMP and MLGMP up and running.  
Anyway, if you have a need for this, I'd be happy to sent you what I 
have.

> For symmetric key and hashing, I was thinking of
> rounding up the hand-tunned assembly versions kicking around.  I 
> haven't
> decided what to do with Elliptic curve yet.

As always, the problem with hand tuned assembly is the portability 
issue, that's why I try to stay away from it where I can -- plus, I'm 
not sure you really get significant enough benefits from assembly 
coding the modern symmetric ciphers and hashes.

And I've been meaning to add some EC stuff to cryptokit-gmp for a long 
time.  Laziness, it'll get you every time.

> Thinking about it a second, there's a problem with providing Ocaml
> implementations of various symmetric key crypto systems- most of them
> assume you have access to efficient 32-bit integers.  Which means you
> either use Int32 at a serious performance and memory hit.

Yep.  And this is one of the biggest pains-in-the-ass for me when it 
comes to OCaml (I do crypto research for a living).  There are times I 
would kill for an efficient  word32/64 datatype... Thank goodness we at 
least have string_unsafe_get and set.

William D. Neumann

"Here come the bunnies with the sugar water,
  Do a little dance with the farmer's daughter."

		-- The Halo Benders

Hi list,

It's been long time without activity on this list, I have been quite busy
lately but I keep on fixing bugs when reports are coming sometimes ;). Right
now the ExtLib acheivements are pretty good : I am a happy ExtLib user and I
don't feel anymore when I write Ocaml that I miss all theses functions from
Stdlib. That's good, and I hope you feel same.

As for the future, I am not certain which path we should follow. I tend to
appreciate the current shape of ExtLib and I'm not wishing to include a lot
more modules, but other people might think different. What I would like to
be included in ExtLib would be small Xml and Date modules, but I'm not sure
we can reach agreement on what should be put inside theses ;). Any insights
or wishes are welcome !

Regards,
Nicolas Cannasse

On Thu, Dec 16, 2004 at 10:22:05AM +0100, Nicolas Cannasse wrote:

> Hi list,
> 
> It's been long time without activity on this list, I have been quite busy
> lately but I keep on fixing bugs when reports are coming sometimes ;). Right
> now the ExtLib acheivements are pretty good : I am a happy ExtLib user and I
> don't feel anymore when I write Ocaml that I miss all theses functions from
> Stdlib. That's good, and I hope you feel same.
> 
> As for the future, I am not certain which path we should follow. I tend to
> appreciate the current shape of ExtLib and I'm not wishing to include a lot
> more modules, but other people might think different. What I would like to
> be included in ExtLib would be small Xml and Date modules, but I'm not sure
> we can reach agreement on what should be put inside theses ;). Any insights
> or wishes are welcome !
> 

I am also quite happy with it as is, but there are a
couple of things I miss:

1) More flexible String functions, e.g.:

   - lchop_if: Only removes char if matching some set of
     chars (and *never* throws an exception). Actually,
     I'd probably rename lchop to lchop_any and add a
     "which-chars" argument to lchop. Alternatively, one
     could just use an optional argument for one lchop
     function.
     
   - nsplit should take an optional maximum-number-of-splits argument
   
   - rstrip/lstrip instead of just strip
   
   - A few more less important, but nonetheless occasionally useful
   additions

   Currently, I'm very busy with Real Life(tm), but I hope to
   submit patches for comment/inclusion in the not too
   distant future.

   
2) Path manipulation: An extended and "regularized" (think
   'principle of least surprise') version of Filename.

   In fact, I have a "Path" module up at

     http://www.imada.sdu.dk/~bardur/personal/45-programs/index.html
     (search for "ocaml-path")

   with various commonly needed functions which I'd love
   feedback on. It's currently UNIX-only, but that can be
   remedied (however, probably not by me since I don't
   have any other platforms to test on, and probably don't
   have sufficient knowledge of the idiosyncrasies of
   those platforms anyway).

   Clearly, this needs to be as cross-platform as possible
   before inclusion is even considered.   

Cheers,   
   
-- 
Bardur Arantsson
<bardur@...>
<bardur@...>

- Who do you think actually compresses and decompresses an MP3 or
a DivX file? Magical forest smurfs?
                                  bugmaster | http://kuro5hin.org

On Thu, Dec 16, 2004 at 10:22:05AM +0100, Nicolas Cannasse wrote:
> Hi list,
>=20
> It's been long time without activity on this list, I have been quite busy
> lately but I keep on fixing bugs when reports are coming sometimes ;). Ri=
ght
> now the ExtLib acheivements are pretty good : I am a happy ExtLib user an=
d I
> don't feel anymore when I write Ocaml that I miss all theses functions fr=
om
> Stdlib. That's good, and I hope you feel same.
>=20
> As for the future, I am not certain which path we should follow. I tend to
> appreciate the current shape of ExtLib and I'm not wishing to include a l=
ot
> more modules, but other people might think different. What I would like to
> be included in ExtLib would be small Xml and Date modules, but I'm not su=
re
> we can reach agreement on what should be put inside theses ;). Any insigh=
ts
> or wishes are welcome !

ExtLib works great for me.  The only thing I'd like to see is more of
the same.  Some ideas:

List.takewhile and List.dropwhile still seem to be missing (I posted a
patch for this on list some time ago).

Simple config file parsing.  YAML-compatibility would be awesome.  Or
take a look at ConfigParser in JG's MissingLib.

List.range:

    let rec range a b =3D
      if a <=3D b then
        a :: range (a+1) b
      else
        []

String.truncate:

    let truncate ?(with_dots =3D false) ?(dots =3D " ...") n str =3D
      if String.length str < n then
        str
      else (
        if not with_dots then
          String.sub str 0 n
        else (
          let n =3D n - String.length dots in
          let str =3D String.sub str 0 n in
          str ^ dots
        )
      )

Controversial, because they only work on ASCII-compatible string
encodings (ie. ASCII, UTF-8, ISO-8859-1, but not UCS-2), but extremely
useful:

    val isspace : char -> bool
    val isalpha : char -> bool
    val isdigit : char -> bool
    val isalnum : char -> bool
    val islower : char -> bool
    val isupper : char -> bool
    val isxdigit : char -> bool

=46rom this you can have trimming functions:

    let triml ?(test =3D isspace) str =3D
      let i =3D ref 0 in
      let n =3D ref (String.length str) in
      while !n > 0 && test str.[!i]; do
        decr n;
        incr i
      done;
      if !i =3D 0 then str
      else String.sub str !i !n
   =20
    let trimr ?(test =3D isspace) str =3D
      let n =3D ref (String.length str) in
      while !n > 0 && test str.[!n-1]; do
        decr n
      done;
      if !n =3D String.length str then str
      else String.sub str 0 !n
   =20
    let trim ?test str =3D
      trimr ?test (triml ?test str)

And also String.for_all / String.exists functions:

    let string_for_all f str =3D
      let len =3D String.length str in
      let rec loop i =3D
        if i =3D len then true
        else (
          let c =3D str.[i] in
          if not (f c) then false
          else loop (i+1)
        )
      in
      loop 0
   =20
    let string_exists f str =3D
      let len =3D String.length str in
      let rec loop i =3D
        if i =3D len then false
        else (
          let c =3D str.[i] in
          if f c then true
          else loop (i+1)
        )
      in
      loop 0

    let string_is_whitespace =3D string_for_all isspace

List.uniq and List.sort_uniq:

    let rec uniq ?(cmp =3D Pervasives.compare) =3D function
        [] -> []
      | [x] -> [x]
      | x :: y :: xs when compare x y =3D 0 ->
          uniq (x :: xs)
      | x :: y :: xs ->
          x :: uniq (y :: xs)
   =20
    let sort_uniq ?cmp xs =3D
      let xs =3D List.sort ?cmp xs in
      let xs =3D uniq ?cmp xs in
      xs

List.group_by is useful when you're pulling stuff out of a database:

    let group_by ?(cmp =3D Pervasives.compare) ls =3D
      let ls' =3D
        List.fold_left
          (fun acc (day1, x1) ->
             match acc with
                 [] -> [day1, [x1]]
               | (day2, ls2) :: acctl ->
                   if cmp day1 day2 =3D 0
                   then (day1, x1 :: ls2) :: acctl
                   else (day1, [x1]) :: acc)
          []
          ls
      in
      let ls' =3D List.rev ls' in
      List.map (fun (x, xs) -> x, List.rev xs) ls'

Meta-functions, like in standard ML:

    let notf f =3D
      fun v -> not (f v)

That'll do for the moment, I think!

Rich.

--=20
Richard Jones.  http://www.annexia.org/  http://www.j-london.com/
>>>   http://www.team-notepad.com/ - collaboration tools for teams   <<<
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
Write Apache modules in OCaml - http://www.merjis.com/developers/mod_caml

On Thu, Dec 16, 2004 at 12:03:24PM +0000, Richard Jones wrote:

> On Thu, Dec 16, 2004 at 10:22:05AM +0100, Nicolas Cannasse wrote:
> > Hi list,
> > 
> > It's been long time without activity on this list, I have been quite busy
> > lately but I keep on fixing bugs when reports are coming sometimes ;). Right
> > now the ExtLib acheivements are pretty good : I am a happy ExtLib user and I
> > don't feel anymore when I write Ocaml that I miss all theses functions from
> > Stdlib. That's good, and I hope you feel same.
> > 
> > As for the future, I am not certain which path we should follow. I tend to
> > appreciate the current shape of ExtLib and I'm not wishing to include a lot
> > more modules, but other people might think different. What I would like to
> > be included in ExtLib would be small Xml and Date modules, but I'm not sure
> > we can reach agreement on what should be put inside theses ;). Any insights
> > or wishes are welcome !
> 
> ExtLib works great for me.  The only thing I'd like to see is more of
> the same.  Some ideas:
> 
> List.takewhile and List.dropwhile still seem to be missing (I posted a
> patch for this on list some time ago).
> 
> Simple config file parsing.  YAML-compatibility would be awesome.  Or
> take a look at ConfigParser in JG's MissingLib.
> 
> List.range:
> 
>     let rec range a b =
>       if a <= b then
>         a :: range (a+1) b
>       else
>         []

IMO, it's usually a bad idea to make both ends of a range
inclusive, because you usually use a length to either
derive the endpoints or expect the number of returned
elements to be (b-a).

... and wouldn't range be better as an Enum constructor?

> 
> String.truncate:
> 
>     let truncate ?(with_dots = false) ?(dots = " ...") n str =
>       if String.length str < n then
>         str
>       else (
>         if not with_dots then
>           String.sub str 0 n
>         else (
>           let n = n - String.length dots in
>           let str = String.sub str 0 n in
>           str ^ dots
>         )
>       )

I'm not sure this is "generally useful" in any meaningful
way...

When you need to truncate (with dots) you usually want
more control, eg. truncation of paths would usually
truncate some characters in the middle.

In the simple case (without dots) you can just use
String.slice (which will never throw an excpetion, just
like truncate).

[--snip--]
> From this you can have trimming functions:
> 
>     let triml ?(test = isspace) str = ...
>     let trimr ?(test = isspace) str = ...
>     let trim ?test str = ...

... or lstrip/rstrip/strip as they would be known
according to the current naming conventions. :)

The fact that trim takes a "test" closure instead of
string with characters should IMHO be regarded as a
feature and the 'old' strip should just be removed... Of
course it may mean that the compiler cannot inline the
"test" calls, but that is, again IMHO, a compiler issue.

[--snip--]
> 
> List.uniq and List.sort_uniq:
> 
>     let rec uniq ?(cmp = Pervasives.compare) = function
>         [] -> []
>       | [x] -> [x]
>       | x :: y :: xs when compare x y = 0 ->

                            ^--- you mean "cmp", right?

>           uniq (x :: xs)
>       | x :: y :: xs ->
>           x :: uniq (y :: xs)
>     
>     let sort_uniq ?cmp xs =
>       let xs = List.sort ?cmp xs in
>       let xs = uniq ?cmp xs in
>       xs
> 
[--snip--]

Cheers,

-- 
Bardur Arantsson
<bardur@...>
<bardur@...>

- Slow down, sir! You're going to give yourself skin failure!
                                          Dr. Nick | The Simpsons

On Thu, Dec 16, 2004 at 01:48:04PM +0100, Bardur Arantsson wrote:
> > From this you can have trimming functions:
> >=20
> >     let triml ?(test =3D isspace) str =3D ...
> >     let trimr ?(test =3D isspace) str =3D ...
> >     let trim ?test str =3D ...
>=20
> ... or lstrip/rstrip/strip as they would be known
> according to the current naming conventions. :)
>=20
> The fact that trim takes a "test" closure instead of
> string with characters should IMHO be regarded as a
> feature and the 'old' strip should just be removed... Of
> course it may mean that the compiler cannot inline the
> "test" calls, but that is, again IMHO, a compiler issue.

Or have both ...

Rich.

--=20
Richard Jones.  http://www.annexia.org/  http://www.j-london.com/
>>>   http://www.team-notepad.com/ - collaboration tools for teams   <<<
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
Use Perl libs in OCaml - http://www.merjis.com/developers/perl4caml

On Thu, Dec 16, 2004 at 12:03:24PM +0000, Richard Jones wrote:
>     let rec uniq ?(cmp =3D Pervasives.compare) =3D function
>         [] -> []
>       | [x] -> [x]
>       | x :: y :: xs when compare x y =3D 0 ->
>           uniq (x :: xs)
>       | x :: y :: xs ->
>           x :: uniq (y :: xs)

This function is somewhat broken w.r.t its handling of the optional
?cmp argument, but I hope you understood what I meant to do ...

Rich.

--=20
Richard Jones.  http://www.annexia.org/  http://www.j-london.com/
>>>   http://www.team-notepad.com/ - collaboration tools for teams   <<<
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
Write Apache modules in OCaml - http://www.merjis.com/developers/mod_caml

On Thu, Dec 16, 2004 at 01:38:06PM +0000, Richard Jones wrote:

> On Thu, Dec 16, 2004 at 01:48:04PM +0100, Bardur Arantsson wrote:
> > > From this you can have trimming functions:
> > > 
> > >     let triml ?(test = isspace) str = ...
> > >     let trimr ?(test = isspace) str = ...
> > >     let trim ?test str = ...
> > 
> > ... or lstrip/rstrip/strip as they would be known
> > according to the current naming conventions. :)
> > 
> > The fact that trim takes a "test" closure instead of
> > string with characters should IMHO be regarded as a
> > feature and the 'old' strip should just be removed... Of
> > course it may mean that the compiler cannot inline the
> > "test" calls, but that is, again IMHO, a compiler issue.
> 
> Or have both ...
> 

It's not that I'm dead set against having both, but it
just seems like interface bloat... but the functionality
is certainly needed. :)

-- 
Bardur Arantsson
<bardur@...>
<bardur@...>

- Homer no function beer well without.
                                     Homer Simpson | The Simpsons

Make the interface as big as it needs to be.

Rich.

--=20
Richard Jones.  http://www.annexia.org/  http://www.j-london.com/
>>>   http://www.team-notepad.com/ - collaboration tools for teams   <<<
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
Write Apache modules in OCaml - http://www.merjis.com/developers/mod_caml

On Thu, 2004-12-16 at 20:47, Bardur Arantsson wrote:
   
> 2) Path manipulation: An extended and "regularized" (think
>    'principle of least surprise') version of Filename.
> 
>    In fact, I have a "Path" module up at
> 
>      http://www.imada.sdu.dk/~bardur/personal/45-programs/index.html
>      (search for "ocaml-path")

I guess this is the best around:

http://webperso.easyconnect.fr/gildor/ocaml-fileutils.html

It supports MacOS, Windows, Cygwin and Unix using functors,
one of which is the host system. Documentation here:

http://webperso.easyconnect.fr/gildor/ocaml-fileutils/index.html

AUTHOR:  Sylvain LE GALL <sylvain.le-gall@...>

----------------
ocaml-fileutils.
----------------
 
This library is intended to provide a basic interface to the most
common file and filename operation. It provides different filename
function : reduce, make_absolute, make_relative... It also enables
to manipulate real file : cp, mv, rm, touch...
 
It is separated in two modules : SysUtil and SysPath. The first
one manipulate files ( real one ), the second one is made for
manipulating abstract filename.
 

   
-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

On Fri, Dec 17, 2004 at 06:38:58PM +1100, skaller wrote:

> On Thu, 2004-12-16 at 20:47, Bardur Arantsson wrote:
>    
> > 2) Path manipulation: An extended and "regularized" (think
> >    'principle of least surprise') version of Filename.
> > 
> >    In fact, I have a "Path" module up at
> > 
> >      http://www.imada.sdu.dk/~bardur/personal/45-programs/index.html
> >      (search for "ocaml-path")
> 
> http://webperso.easyconnect.fr/gildor/ocaml-fileutils.html

This looks *very* interesting and the license seems to be
ExtLib-compatible. :)

However, for glancing at the code there are a couple of
minor issues:

- It uses lexers and parsers for reducing path names to an
  internal representation which seems like overkill. (Or
  is it just me?)

- The FileUtil module seems a bit rough around the edges,
  for instance FileUtil.cmp uses Stream.of_channel to
  compare files character-by-character -- hopefully the
  channel itself does readahead, but even so it is
  probably still hideously slow. The size handling also
  seems strange (why not just always convert input sizes
  to number of bytes?), but again, maybe that's just me.

Overall, I must say I like it a lot. It has very little in
the way of OS-specific code and it already has a
reasonable set of test cases.

... which brings up another thing which ExtLib is missing:
A test suite (and some mechanism for executing it).

We have already seen examples of bugs which unit testing
could easily have caught (read_i32, DynArray.append). It
also provides some reasonable degree of regression testing
if implementations are changed.

I think we should definitely add one, especially since
there are quite a few modules already which could benefit
from it.

-- 
Bardur Arantsson
<bardur@...>
<bardur@...>

Anyone who is capable of getting themselves made President should
on no account be allowed to do the job.
                  Douglas Adams | Hitchiker's Guide to the Galaxy

On Fri, 2004-12-17 at 20:09, Bardur Arantsson wrote:
> > http://webperso.easyconnect.fr/gildor/ocaml-fileutils.html
> 
> This looks *very* interesting and the license seems to be
> ExtLib-compatible. :)
> 
> However, for glancing at the code there are a couple of
> minor issues:
> 
> - It uses lexers and parsers for reducing path names to an
>   internal representation which seems like overkill. (Or
>   is it just me?)

Doing things 'the right way' can't be overkill can it?
I would expect this to be lightning fast and it should
make it easy to generalise/extend ..?

> - The FileUtil module seems a bit rough around the edges,

Perhaps -- but I think the interface is the primary
concern .. the implementation can always be improved later.

> ... which brings up another thing which ExtLib is missing:
> A test suite (and some mechanism for executing it).

I raise that issue before -- as I recall, Nicolas correctly
said that's it is a *big* job.

For Felix, I merge the tests and tutorial.. an added incentive.
Learn how to use Extlib by studying the test cases.. 

But it is a big job .. more is involved that just writing
the test case (a test harness is needed too ..)

-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

On Fri, Dec 17, 2004 at 09:13:04PM +1100, skaller wrote:

> On Fri, 2004-12-17 at 20:09, Bardur Arantsson wrote:
> > > http://webperso.easyconnect.fr/gildor/ocaml-fileutils.html
> > 
> > This looks *very* interesting and the license seems to be
> > ExtLib-compatible. :)
> > 
> > However, for glancing at the code there are a couple of
> > minor issues:
> > 
> > - It uses lexers and parsers for reducing path names to an
> >   internal representation which seems like overkill. (Or
> >   is it just me?)
> 
> Doing things 'the right way' can't be overkill can it?
> I would expect this to be lightning fast and it should
> make it easy to generalise/extend ..?

I'm not sure there will ever be any need to
generalise/extend, but anyway...

To my mind, using full-blown parsers is overkill for
splitting UNIX paths into their constituent parts, but
I guess that's just an implementation detail, so let's
ignore that for the moment.

Another concern, which is more related to the interface is
that the module seems to raise exceptions in situations
one wouldn't normally expect. An an example:

    FilePath.check_extension p ext

raises an exception if the filename doesn't have an
extension. I can't tell whether this is a part of the
interface of check_extension since no ocamldoc comment is
present, but it certainly is *not* following the principle
of least surprise. That's the kind of thing that can be
*really* annoying to a library user.

Apart from that, I feel that simple 'shortcut' path
queries like is_dir, is_link, etc. should be added to the
FilePath module. I realize that this removes the
separation of purely abtract paths and concrete files, but
it's just too convenient to pass up IMO. Constrast

     if Path.is_dir p then

with

     if FileUtil.test FileUtil.Is_dir p then

Not a huge difference, but it is significant enough, IMO.
     
> 
> > - The FileUtil module seems a bit rough around the edges,
> 
> Perhaps -- but I think the interface is the primary
> concern .. the implementation can always be improved later.

You're right, of course.

All of the above is stuff that's fixable, so I guess the
best idea would be to just decide on an answer to the
question

     Do we want a path/file query/manipulation module in ExtLib?     

My answer would definitely be 'yes' (regardless of
which particular module it would end up being). This is an
area where the standard library is very weak and such a
module would be useful to most people using ExtLib.
     
I would be quite happy to use FilePath/FileUtil as the
basis for such a module.

> 
> > ... which brings up another thing which ExtLib is missing:
> > A test suite (and some mechanism for executing it).
> 
> I raise that issue before -- as I recall, Nicolas correctly
> said that's it is a *big* job.

Agreed, but IMHO it is becoming increasingly necessary as
the amount of code in ExtLib grows. Just an example from
real life: When I was writing OptParse I would have a test
program invoke the parser with various test cases just to
make sure that the various modifications I was doing
didn't create new bugs. When it was included in ExtLib,
those test cases couldn't be included and any future
modifications would run the risk of causing regressions.
This may also cause people who don't know the code
intimately to be relucant to try to improve/fix it. (In
some cases this even extends to the original authors if
they haven't looked at the code in question for a long
time).

> For Felix, I merge the tests and tutorial.. an added incentive.
> Learn how to use Extlib by studying the test cases.. 

I'm not sure how necessary an ExtLib tutorial is, but that
sound like a good idea. :)

> But it is a big job .. more is involved that just writing
> the test case (a test harness is needed too ..)

Maybe I'm just stupid, but I don't see why a test harness
would require lots of work...?

My suggestion would be something like this: Use OUnit for
running individual test cases/sets, add a lazy global
'test_cases' value to all the relevant modules. Finally,
add a Test module containing something along the lines of

       let all_test_cases = 
             ... [ Lazy.force ExtString.test_cases;
                   Lazy.force OptParse.test_cases;
                   ... ]
       in let counters =
          OUnit.run_test_tt_main all_test_cases
       in let rc =
          if counters.errors > 0 then 1 
          else if counters.failures > 0 then 2 
          else 0
       in
         printf "statistics: ....";
         exit rc;

This would enable all the installation methods to run the
test cases with very little effort.

Of course, writing individual test cases for all the
modules would be a lot of work, but this is work that can
be done incrementally.

Am I missing something?

-- 
Bardur Arantsson
<bardur@...>
<bardur@...>

> Of course, writing individual test cases for all the
> modules would be a lot of work, but this is work that can
> be done incrementally.
> 
> Am I missing something?

Yes : who is volunteering for such a work ?
I'll skip ;)

Nicolas

On Fri, Dec 17, 2004 at 01:05:56PM +0100, Nicolas Cannasse wrote:

> > Of course, writing individual test cases for all the
> > modules would be a lot of work, but this is work that can
> > be done incrementally.
> > 
> > Am I missing something?
> 
> Yes : who is volunteering for such a work ?
> I'll skip ;)
> 

Actually, I would, but I'm currently too busy :(. Maybe in
a month or two...

-- 
Bardur Arantsson
<bardur@...>
<bardur@...>

- This is the worst kind of discrimination. The kind against me!
                                                Bender | Futurama

On Fri, 2004-12-17 at 22:36, Bardur Arantsson wrote:

> > Doing things 'the right way' can't be overkill can it?
> > I would expect this to be lightning fast and it should
> > make it easy to generalise/extend ..?
> 
> I'm not sure there will ever be any need to
> generalise/extend, but anyway...

Consider:

(a) C has certain rules for resolving #include filenames.
Recall eveb "kjkjh" and <kjhgkjg> are distinct ..

(b) Felix (and Interscript) also have rules for resolving
filenames. Interscript rules are in fact quite interesting:

Names of include files in interscript are *required* to
be Unix relative filenames. From the command line,
a native filename prefix is taken.
The two are spliced together, after converting
the interscript name to a native one.
[This ensures everything 'in document' is as OS independent
as possible]

(c) There are several conventions for PATH names.
The unix one (separator ':') is one, but TeX uses
kpathsea ..

(d) I have used an archaic system which is much better
than any of the above .. a TI os which has no subdirectories
at all. Instead it has something much better: an environment
plus structured filename convention. Filename components
are replaced from the environment, subsuming the current
directory idea completely.

(e) Hmm what about URL/URI things .. :)

In any case the idea of using a parser for filenames
isn't overkill IMHO .. on the contrary the problem is 
more likely to be that mere LALR1 parsing and Ocamllex
lexing simply isn't good enough (some OS use
UCS-2 filenames .. solaris and Win32 for example ..)

Ocamllex, for example, can't even translate UTF-8 
(I tried once, it blows the lexer generators brains out).

The real advantage of a lexer/parser combination seems
to be that the specification is heavily declarative.

> To my mind, using full-blown parsers is overkill for
> splitting UNIX paths into their constituent parts, 

But we're not restricted to Unix..

> Another concern, which is more related to the interface is
> that the module seems to raise exceptions in situations
> one wouldn't normally expect. An an example:
> 
>     FilePath.check_extension p ext
> 
> raises an exception if the filename doesn't have an
> extension. I can't tell whether this is a part of the
> interface

Agree. I think exceptions should be reserved for
unrecoverable errors if possible, but in any case
it should be documented.

> Apart from that, I feel that simple 'shortcut' path
> queries like is_dir, is_link, etc. should be added to the
> FilePath module. I realize that this removes the
> separation of purely abtract paths and concrete files, but
> it's just too convenient to pass up IMO.

I think the separation is an *essential* feature.
It's there by design and for a good reason: you can
have Unix, MacOS, and Win32 modules all available at once.
These modules must not be permitted to touch the
file system.

However short version in the FileUtil module,
OR, a third module, (eg FileQuery) may make sense.
(Especially as 'fstat' and friends are fairly
OS specific animals)

> All of the above is stuff that's fixable, so I guess the
> best idea would be to just decide on an answer to the
> question
> 
>      Do we want a path/file query/manipulation module in ExtLib?     
> 
> My answer would definitely be 'yes' 

Mine too. Filenames are needed even in Pervasives ..

> Maybe I'm just stupid, but I don't see why a test harness
> would require lots of work...?

Because it has to

(a) Collate all the tests
(b) Run the tests -- terminating rogues 
(c) Collate the results
(d) Standardise a way to actually report results

Point (d) is extremely difficult.

> Of course, writing individual test cases for all the
> modules would be a lot of work, but this is work that can
> be done incrementally.

Yes, I don't think writing the tests is the issue.
We can start with just half a dozen, and make sure
for every bug there is a regression test generated.

> Am I missing something?

Yeah -- designing a test system is probably harder
than designing a library or an average application.
This is especially the case for Ocaml I suspect,
since it doesn't support dynamic loading and unloading. 
That seems to mean each test must be a separate process.

In addition some tests are dangerous, especially ones
that mess with the filesystem or network -- usually you'd run
your tests in a suitably restricted environment
as an low privilege user.. which makes the test
harnes OS specific ..

In addition, we will need community support:
something like a web page for submitting tests,
so that they're easy to install, and meet requirements,
such as having a description, expected output, etc ..

I personally think 'unit' testing is a bit silly.
It rarely finds bugs because it can't cover enough cases,
can't handle integration, etc.. I prefer a more sloppy
concept of just collecting whatever test code you can
and running it, just to get some confidence you didn't
completely mess something up whilst committing a minor
change to CVS.

-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

On Sat, Dec 18, 2004 at 12:07:30AM +1100, skaller wrote:

> > To my mind, using full-blown parsers is overkill for
> > splitting UNIX paths into their constituent parts, 
> 
> But we're not restricted to Unix..

I was thinking specifically of the UNIX case...

[--snip--] 
> > Maybe I'm just stupid, but I don't see why a test harness
> > would require lots of work...?
> 
> Because it has to
> 
> (a) Collate all the tests
> (b) Run the tests -- terminating rogues 
> (c) Collate the results
> (d) Standardise a way to actually report results

... all of which my small code snippet does (well, would
do if it were actually syntactically valid...) when
combined with OUnit...?!?

   (a) Tests are combined in all_tests.
   (b) OUnit takes care of that (there is no parallel
       execution, but that's hardly a huge problem for
       testing ExtLib code).
   (c) OUnit
   (d) ./test returns 0 if all tests were succesful,
       non-zero otherwise. This enables the "make check"
       target to fail, install.ml can run ./test and check its
       return code.

I think we may be discussing different things... I'm only
talking about something which ExtLib developers can use
exclusively for testing ExtLib itself, not about making a
test harness available to ExtLib users.

> > Am I missing something?
> 
> Yeah -- designing a test system is probably harder
> than designing a library or an average application.
> This is especially the case for Ocaml I suspect,
> since it doesn't support dynamic loading and unloading. 
> That seems to mean each test must be a separate process.

In general, yes, but it doesn't mean that we can't agree
on an *internal* method for testing ExtLib itself.

> 
> In addition some tests are dangerous, especially ones
> that mess with the filesystem or network -- usually you'd run
> your tests in a suitably restricted environment
> as an low privilege user.. which makes the test
> harnes OS specific ..

Sure, but what I'm talking about is much simpler: *We*
would be the ones writing the tests, so we simply avoid
writing test cases for potentially dangerous things (ie.
tests with side effects outide of the "virtual machine").
Thus, there is no need to protect from such secondary
effects. Of course it means less coverage, but I can
certainly live with that, especially since the alternative
is *no* coverage.

> 
> I personally think 'unit' testing is a bit silly.
> It rarely finds bugs because it can't cover enough cases,
> can't handle integration, etc.. I prefer a more sloppy
> concept of just collecting whatever test code you can
> and running it, just to get some confidence you didn't
> completely mess something up whilst committing a minor
> change to CVS.

Yes, perhaps I shouldn't have used the term 'unit test',
but I was thinking along the same lines you are, ie. basic
sanity/logic tests and regression tests. Trusting unit
tests to find all bugs is silly, but they can provide a
bit more confidence that you haven't introduced really
obvious bugs...

-- 
Bardur Arantsson
<bardur@...>
<bardur@...>

- "Eternal happiness for one dollar? I'd be happier with the
dollar."
                                  Montgomery Burns | The Simpsons

Bardur Arantsson wrote:

>
>>I personally think 'unit' testing is a bit silly.
>>It rarely finds bugs because it can't cover enough cases,
>>can't handle integration, etc.. I prefer a more sloppy
>>concept of just collecting whatever test code you can
>>and running it, just to get some confidence you didn't
>>completely mess something up whilst committing a minor
>>change to CVS.
>>    
>>
>
>Yes, perhaps I shouldn't have used the term 'unit test',
>but I was thinking along the same lines you are, ie. basic
>sanity/logic tests and regression tests. Trusting unit
>tests to find all bugs is silly, but they can provide a
>bit more confidence that you haven't introduced really
>obvious bugs...
>  
>
I find these types of tests extremely handy for developing any 
software.  In fact we use this kinds of sanity/regression tests in all 
our software at our company.  What I normally do (for C and O'Caml) is 
that I use a lot of asserts to do sanity checks in library code and then 
write a tester (sometimes called smoketester) that calls the library 
functions with heavily biased random input.  The input is biased towards 
corner cases, such as array length zero etc.  Every test case will 
naturally test that the function(s) it is testing is working in the 
expected manner.

The tester's "coverage" can be easily metered with gcov.  This way you 
can get sort of profiling of your test code.. E.g., only spend time 
writing test cases that actually reach yet unentered parts of the library.

I have personally found this technique to really effective in 
development.  Modifying large parts of code is much easier if you have a 
good tester that actually tests everything.

I guess for Extlib, you're always assumed to pass *all* tests before 
making a release or committing changes.  If this is the case, I don't 
see much need for fancy logging machinery, since the tests would pretty 
much just report PASSED.

I don't think it would be so hard to find volunteers for this kind of 
testing.  In fact I'd be willing to write a few tests for it myself.

Best regards,
Janne Hellsten

On Sat, 2004-12-18 at 09:42, Janne Hellsten wrote:

> I find these types of tests extremely handy for developing any 
> software.  In fact we use this kinds of sanity/regression tests in all 
> our software at our company.  What I normally do (for C and O'Caml) is 
> that I use a lot of asserts to do sanity checks in library code and then 
> write a tester (sometimes called smoketester) that calls the library 
> functions with heavily biased random input.  The input is biased towards 
> corner cases, such as array length zero etc.  Every test case will 
> naturally test that the function(s) it is testing is working in the 
> expected manner.

How do you (a) generate the input and (b) predict the
expected result?

> I have personally found this technique to really effective in 
> development.  Modifying large parts of code is much easier if you have a 
> good tester that actually tests everything.

I *rely* heavily on my tests in Felix.
In fact they're part of the distro and the build always runs the
basic ones.

I do lots of 'refactoring' and enhancements and I'd be screwed
without the testing harness.

> I guess for Extlib, you're always assumed to pass *all* tests before 
> making a release or committing changes.  

Yup, but when a test fails you need to know which one :)

> I don't think it would be so hard to find volunteers for this kind of 
> testing.  In fact I'd be willing to write a few tests for it myself.

So would I. The main obstacle is just to specify how
to structure the tests. I'm sure a couple of us could write
the test harness once that is done, and someone can volunteer
to collect tests from this mailing list and glue them into CVS.

How about this:

(a) Each test is called 'test_*.ml'.
(b) Each is a program linked against ExtLib.
(c) The test passes if 

   i) it exits with 0
  ii) stderr is empty
  iii) stdout agrees with 'test_*.expected'

(d) Each test optionally has a file 'test_*.input'
which is passed via stdin.

An alternative is: the first line of the test
is the checker: eg:

(* env FRED=something test_298 <somein >tmp.tmp && diff tmp.tmp
test_298.expected *)

which allows command line args etc.

-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

On Sat, 2004-12-18 at 00:40, Bardur Arantsson wrote:

> I think we may be discussing different things... I'm only
> talking about something which ExtLib developers can use
> exclusively for testing ExtLib itself, not about making a
> test harness available to ExtLib users.

No, we're talking about the same thing.

> In general, yes, but it doesn't mean that we can't agree
> on an *internal* method for testing ExtLib itself.

Well, can you could write a specification?

Assume a directory containing tests, people can dump
tests in it. The tests need names -- what names? 
it must be possible to specify expected result,
the harness must report which test(s) (if any) fail.

You can use an 'assert' test (if the code runs at 
all it passes). The problem with that is that
library function are hard to test like that..

How do you test 'string.split'? This is not so easy!
Try:

	assert (x = combine "/" (split x "/"))

Which suggests making the split char vary.
How do you test ExtSet? You need stuff to put in it,
where does it come from?

-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

On Sat, Dec 18, 2004 at 11:16:53AM +1100, skaller wrote:

> On Sat, 2004-12-18 at 00:40, Bardur Arantsson wrote:
> 
> > I think we may be discussing different things... I'm only
> > talking about something which ExtLib developers can use
> > exclusively for testing ExtLib itself, not about making a
> > test harness available to ExtLib users.
> 
> No, we're talking about the same thing.
> 
> > In general, yes, but it doesn't mean that we can't agree
> > on an *internal* method for testing ExtLib itself.
> 
> Well, can you could write a specification?
> 
> Assume a directory containing tests, people can dump
> tests in it. The tests need names -- what names? 
> it must be possible to specify expected result,
> the harness must report which test(s) (if any) fail.
> 
> You can use an 'assert' test (if the code runs at 
> all it passes). The problem with that is that
> library function are hard to test like that..
> 
> How do you test 'string.split'? This is not so easy!
> Try:
> 
> 	assert (x = combine "/" (split x "/"))
> 
> Which suggests making the split char vary.

Uh, and...? If you want to try different splitter characters, just do

  let l = [ ("/", "a/b", ["a";"b"]);
            ("/", "a/b/c", ["a";"b"]);
            ("#", "a#b", ...) ]	    
  in
    List.map (fun sep str exp_values -> assert (exp_values = split sep str));
    List.map (fun sep str exp_values -> assert (str = combine sep exp_values))

in your test code. This also buys separate tests for split
and combine (and thus tests more than whether the two are
"inverses" of each other).

If you want more flexibility you can always generate the l
list as a cartesian product of separators and field
values/strings.

I think you may be overdesigning/overthinking this...

> How do you test ExtSet? You need stuff to put in it,
> where does it come from?

Same idea as above, you just hardcode the test data into
your test_*.ml files...

-- 
Bardur Arantsson
<bardur@...>
<bardur@...>

A morning without coffee is like something without something
else.

On Sat, Dec 18, 2004 at 10:51:54AM +1100, skaller wrote:

> > I guess for Extlib, you're always assumed to pass *all* tests before 
> > making a release or committing changes.  
> 
> Yup, but when a test fails you need to know which one :)

What about just having a -verbose switch for the ./test_*.ml
program which prints the number of each test before
running it...? Seems simple enough to me...

Of course, stack traces would really be the optimal way to
do this, but OCaml doesn't support stack traces for
exceptions (although the debugger does... go figure).

> 
> > I don't think it would be so hard to find volunteers for this kind of 
> > testing.  In fact I'd be willing to write a few tests for it myself.
> 
> So would I. The main obstacle is just to specify how
> to structure the tests. I'm sure a couple of us could write
> the test harness once that is done, and someone can volunteer
> to collect tests from this mailing list and glue them into CVS.
> 
> How about this:
> 
> (a) Each test is called 'test_*.ml'.

It might be a bit less cluttered to have a directory (or
multiple directories?) exclusively for tests, but I guess
any convention which clearly separates test from non-test
would be fine.

> (b) Each is a program linked against ExtLib.

Yup.

> (c) The test passes if 
> 
>    i) it exits with 0
>   ii) stderr is empty
>   iii) stdout agrees with 'test_*.expected'
> 
> (d) Each test optionally has a file 'test_*.input'
> which is passed via stdin.

Wouldn't it be easier to just hardcode input/expected
values into the test_*.ml files themselves instead of
relying on "external" files? Certainly, all the things
I've thought about writing test cases for would be just as
easy to hardcode input/output values for.

> 
> An alternative is: the first line of the test
> is the checker: eg:
> 
> (* env FRED=something test_298 <somein >tmp.tmp && diff tmp.tmp
> test_298.expected *)
> 
> which allows command line args etc.

Wouldn't this necessitate a UNIX-ish environment?

-- 
Bardur Arantsson
<bardur@...>
<bardur@...>

Friends are like plants. They need attention and they need to
drink.
                                    SPYvSPY | http://kuro5hin.org

> How do you (a) generate the input and (b) predict the
> expected result?

It is wholly dependent on the test, of course.  For example, random 
strings with random length and contents, possibly having zero elements 
in it.  Then feeding it into a function and verifying with asserts that 
the output is what it's supposed to be.

The randomness depends heavily on the problem domain.  With programs 
such as compilers, you want a lot of randomness, but for simple things 
like string functions you're fine with just a few carefully selected inputs.

In one compiler project I used an AST and a code generator that 
generated code based on that AST.  When generating code, you have a lot 
of opportunities for randomly creating different variations so that the 
generated output still does the same thing.

I fed the randomly generated programs through the compiler, ran them and 
compared the results against a direct interpretation of the AST (the AST 
was conveniently interpretable, as it was created for this purpose only).

To predict the output, you of course need to create cases where you in 
some way (programmatically) know the result.  For example, if you know 
that a function should raise an exception with some input, you feed it 
with that input and then assert that it actually raises it.  I'm sure 
everyone is familiar with this sort of testing.

I don't have my tester for one of my libraries at hand, but perhaps 
tomorrow I can post some examples if you're interested.

> I *rely* heavily on my tests in Felix.
> In fact they're part of the distro and the build always runs the
> basic ones.
> 
> I do lots of 'refactoring' and enhancements and I'd be screwed
> without the testing harness.

Yep, same here.

>>I guess for Extlib, you're always assumed to pass *all* tests before 
>>making a release or committing changes.  
> 
> 
> Yup, but when a test fails you need to know which one :)

Because I use assertions.  I can do just:

export OCAMLRUNPARAM=b=1
make all
make test

and then examine the callstack to see where something went wrong.

Or use a debugger.  I don't see any reason why it should be any more 
complicated than that.  As Extlib, at least in its current, form is 
relatively small, running the full test suite probably is a matter of 
few seconds.

> So would I. The main obstacle is just to specify how
> to structure the tests. I'm sure a couple of us could write
> the test harness once that is done, and someone can volunteer
> to collect tests from this mailing list and glue them into CVS.
> 
> How about this:
> 
> (a) Each test is called 'test_*.ml'.
> (b) Each is a program linked against ExtLib.
> (c) The test passes if 
> 
>    i) it exits with 0
>   ii) stderr is empty
>   iii) stdout agrees with 'test_*.expected'
> 
> (d) Each test optionally has a file 'test_*.input'
> which is passed via stdin.
> 
> An alternative is: the first line of the test
> is the checker: eg:
> 
> (* env FRED=something test_298 <somein >tmp.tmp && diff tmp.tmp
> test_298.expected *)
> 
> which allows command line args etc.

What I have done for my O'Caml libraries, is just to write one .ml file 
per module and then have separate tests as functions inside this file. 
Then I create one executable that links all these different test modules 
together to form the full tester for the library.  I just call all the 
modules from my "main".

It is somewhat unclear to me what we would gain by having all tests as 
separate executables.  I believe this kind of a framework is well suited 
for a program like GCC, but I believe it is a little overkill for Extlib.

But then again, having this machinery might make it more easy and 
convenient to add new tests into the suite.

Best regards,
Janne Hellsten

Sorry, forgot to say that..

> Because I use assertions.  I can do just:
> 
> export OCAMLRUNPARAM=b=1
> make all
> make test
> 
> and then examine the callstack to see where something went wrong.

The above works only for bytecode (callstack).

But asserts print out the file:line information where the assertion 
failed.  So if something goes wrong, you always get notified and can see 
easily what went wrong and where.

Best regards,
Janne Hellsten

On Sat, 2004-12-18 at 11:30, Bardur Arantsson wrote:

> I think you may be overdesigning/overthinking this...

Yes I am. Devils Advocately... :)


-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

On Sat, 2004-12-18 at 11:34, Janne Hellsten wrote:

> It is somewhat unclear to me what we would gain by having all tests as 
> separate executables.  I believe this kind of a framework is well suited 
> for a program like GCC, but I believe it is a little overkill for Extlib.

> But then again, having this machinery might make it more easy and 
> convenient to add new tests into the suite.

That was my thought -- we want to encourage community
contribution, which I think implies being able to
write lots of little self contained tests, in particular
to actually check them separately.

However it is slower to run the tests this way
and needs more external machinery.


-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

skaller wrote:
> That was my thought -- we want to encourage community
> contribution, which I think implies being able to
> write lots of little self contained tests, in particular
> to actually check them separately.

After thinking about this a little, I think I'd still rather
go for the the simple assertion-based system I proposed.  This is 
because the framework is almost non-existent and thus doesn't take much 
time to implement (~none).

The assertion-based tests work well with other systems as well, and you 
could integrate these kinds of tests easily into a system that you were 
proposing -- just make sure you compile all these executables with 
asserts turned on.

> However it is slower to run the tests this way
> and needs more external machinery.

Yes, much slower, depending on the tests.  Especially Cygwin where 
process invokation is dead slow for some reason.

The testing suite also needs to build and run easily on Windows.

Best regards,
Janne Hellsten

On Sat, Dec 18, 2004 at 09:33:13AM +0200, Janne Hellsten wrote:
> Yes, much slower, depending on the tests.  Especially Cygwin where=20
> process invokation is dead slow for some reason.
>=20
> The testing suite also needs to build and run easily on Windows.

How about lots of tiny test programs (test1.ml, test2.ml,
test_string_exists.ml, ...) which are linked together into a main
program.  The main program (test.ml) would be generated by the
Makefile and would basically consist of something like:

let () =3D
  Test1.test ();
  Test2.test ();
  Test_string_exists.test ();
  (* ... *)
  print_endline "Tests OK"

Rich.

--=20
Richard Jones.  http://www.annexia.org/  http://www.j-london.com/
>>>   http://www.team-notepad.com/ - collaboration tools for teams   <<<
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
Learn Objective CAML - http://www.merjis.com/developers

> How about lots of tiny test programs (test1.ml, test2.ml,
> test_string_exists.ml, ...) which are linked together into a main
> program.  The main program (test.ml) would be generated by the
> Makefile and would basically consist of something like:
> 
> let () =
>   Test1.test ();
>   Test2.test ();
>   Test_string_exists.test ();
>   (* ... *)
>   print_endline "Tests OK"

This is pretty much what I was proposing, although I'd probably put more 
tests into one .ml file.

I will make an initial test today and post a link to the results here. 
Perhaps interested people could take a look and we could continue after 
the initial review.

I'm considering the use of OMake for the tester.  I wonder if people are 
much against that?  At least it works on all platforms and is much much 
nicer than GNU Make.

ciao,
janne

On Sat, Dec 18, 2004 at 01:47:15PM +0200, Janne Hellsten wrote:

> I'm considering the use of OMake for the tester.  I wonder if people are 
> much against that?  At least it works on all platforms and is much much 
> nicer than GNU Make.

I've been playing around with OMake and it *is* much nicer
than GNU Make (and SCons, jam, and cook, IMO), but there
are still some relatively serious issues with the current
(pre-1.0) releases, so I don't think it would be a good
idea to use it for ExtLib just yet.

Most of the issues are being addressed and it looks like
OMake may become a very nice build system (not only for
OCaml-based projects, but also in general).

Cheers,

-- 
Bardur Arantsson
<bardur@...>
<bardur@...>

- Witty remarks are like... uh, the things with... um. Uh, I
think they went over there.
                                                  Emily Dickinson

Bardur Arantsson wrote:

> I've been playing around with OMake and it *is* much nicer
> than GNU Make (and SCons, jam, and cook, IMO), but there
> are still some relatively serious issues with the current
> (pre-1.0) releases, so I don't think it would be a good
> idea to use it for ExtLib just yet.
> 
> Most of the issues are being addressed and it looks like
> OMake may become a very nice build system (not only for
> OCaml-based projects, but also in general).
> 
> Cheers,

Yes, I guess you're right.  And I maybe it's not a good idea to require 
OMake installation in order to run the testing suite.

ciao,
janne

On Sat, 2004-12-18 at 22:38, Richard Jones wrote:
>  The main program (test.ml) would be generated by the
> Makefile and would basically consist of something like:
> 
> let () =
>   Test1.test ();
>   Test2.test ();
>   Test_string_exists.test ();
>   (* ... *)
>   print_endline "Tests OK"


OK, but the naming 'test999.ml' sux :)

Random contributions require a more consistent naming scheme.
So how about:

test_<author>_<module>_<name>.ml

<author> is the authors initials eg rj, js, nc, jh.
<module> is the Extlib module being tested, or 'multi' if more
than one.

<name> is a suggestion what the test is about, possibly with
some digits, abbreviated, or just a random code of some kind.

All the letters shall be lower case.

Example:

test_js_enum_iter01.ml

The tests all get checked into a CVS repository module
distinct from the library. 

Nicolas will name and create it?

Within that module, a directory 'utests' will contain the
actual tests .. and nothing else. The Makefile, mainline,
etc should be kept separate from the tests. The idea is basically
anyone can add tests, but one person should be responsible for
the harness.

Comments, improvements, violent disagreements?


-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

On Sat, Dec 18, 2004 at 11:38:31PM +1100, skaller wrote:
> OK, but the naming 'test999.ml' sux :)

Yup.

> Random contributions require a more consistent naming scheme.
> So how about:
>=20
> test_<author>_<module>_<name>.ml

Seems sensible.

> <author> is the authors initials eg rj, js, nc, jh.
> <module> is the Extlib module being tested, or 'multi' if more
> than one.

Should we have tests which test more than one module?

Rich.

--=20
Richard Jones.  http://www.annexia.org/  http://www.j-london.com/
>>>   http://www.team-notepad.com/ - collaboration tools for teams   <<<
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
http://subjectlink.com/ - Lesson plans and source material for teachers

>> Random contributions require a more consistent naming scheme.
>> So how about:
>>
>> test_<author>_<module>_<name>.ml
>
> Seems sensible.
>
>> <author> is the authors initials eg rj, js, nc, jh.
>> <module> is the Extlib module being tested, or 'multi' if more
>> than one.
>
> Should we have tests which test more than one module?

We should have tests which test more than one module.  But I think we 
should run single module tester first to ease debugging.

I already started working on the tester, hope to post an initial tester 
for review in a few hours.

ciao,
janne

Hello,

I made an initial version of the tester.  I think something like this 
should suffice for the time being.  I used the module naming scheme 
proposed by John Max Skaller.  Otherwise it's pretty much what everyone 
else has been talking here on the list.

You can download the source from:

http://www.saunalahti.fi/~jjhellst/extlib/

It doesn't have many tests yet, just a few placeholders to demonstrate the 
file layout.

I found one issue: BitSet.is_set does not throw Negative_index at all. 
Other functions tend seem to raise this exception.  Is this the expected 
behaviour?

ciao,
janne


On Sat, 18 Dec 2004, Richard W.M. Jones wrote:

> On Sat, Dec 18, 2004 at 11:38:31PM +1100, skaller wrote:
>> OK, but the naming 'test999.ml' sux :)
>
> Yup.
>
>> Random contributions require a more consistent naming scheme.
>> So how about:
>>
>> test_<author>_<module>_<name>.ml
>
> Seems sensible.
>
>> <author> is the authors initials eg rj, js, nc, jh.
>> <module> is the Extlib module being tested, or 'multi' if more
>> than one.
>
> Should we have tests which test more than one module?
>
> Rich.
>
> -- 
> Richard Jones.  http://www.annexia.org/  http://www.j-london.com/
>>>>   http://www.team-notepad.com/ - collaboration tools for teams   <<<
> Merjis Ltd. http://www.merjis.com/ - improving website return on investment
> http://subjectlink.com/ - Lesson plans and source material for teachers
>
>

On Sun, 2004-12-19 at 04:15, Janne Hellsten wrote:

> You can download the source from:
> 
> http://www.saunalahti.fi/~jjhellst/extlib/
> 
> It doesn't have many tests yet, just a few placeholders to demonstrate the 
> file layout.

Ok this looks great. The most important issue right now IMHO is
not how the test manager works, but where it lives in CVS.

Nicolas said at one stage that the test suite shouldb't be
part of the distribution. Whether or not this is the case,
I would say it should be easily separable.

IMHO test code and library code should be siblings,
the tests should be in a subdir of the src (just my opinion).


-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

> > You can download the source from:
> >
> > http://www.saunalahti.fi/~jjhellst/extlib/
> >
> > It doesn't have many tests yet, just a few placeholders to demonstrate
the
> > file layout.
>
> Ok this looks great. The most important issue right now IMHO is
> not how the test manager works, but where it lives in CVS.
>
> Nicolas said at one stage that the test suite shouldb't be
> part of the distribution. Whether or not this is the case,
> I would say it should be easily separable.
>
> IMHO test code and library code should be siblings,
> the tests should be in a subdir of the src (just my opinion).

If Janne or anybody else is willing to take over the test suite CVS
maintenance, I will give CVS write access.
As for the repository, I prefer having it in a separate module, so anybody
checking out extlib sources does not automaticaly get test suite too.
Something like :

/CVSROOT
/extlib-dev
/extlib-test

Nicolas Cannasse

> Ok this looks great. The most important issue right now IMHO is
> not how the test manager works, but where it lives in CVS.
> 
> Nicolas said at one stage that the test suite shouldb't be
> part of the distribution. Whether or not this is the case,
> I would say it should be easily separable.

Thank you for taking a look!

> IMHO test code and library code should be siblings,
> the tests should be in a subdir of the src (just my opinion).

I agree.  However, I'll have to familiarize myself with the current 
state of the ExtLib CVS before I can say anything more about this though.

BTW: Perhaps I should add the license/copyright notice from ExtLib to 
test suite files?

ciao,
janne

Nicolas Cannasse wrote:
> If Janne or anybody else is willing to take over the test suite CVS
> maintenance, I will give CVS write access.
> As for the repository, I prefer having it in a separate module, so anybody
> checking out extlib sources does not automaticaly get test suite too.
> Something like :
> 
> /CVSROOT
> /extlib-dev
> /extlib-test

I am willing to take over the suite..

Having it as a separate module is OK for me.  The only thing I'm 
concerned about is building and setting up file paths.  E.g., I want it 
to be easy to checkout both and then be able compile extlib-test 
out-of-the-box without an explicit "configure".

I don't remember my CVS well anymore.. Is it easy to setup the CVS 
modules so that when I checkout extlib-test, I also get extlib-dev as a 
sibling?

ciao,
janne

On Mon, Dec 20, 2004 at 10:59:27AM +0100, Nicolas Cannasse wrote:

> > > You can download the source from:
> > >
> > > http://www.saunalahti.fi/~jjhellst/extlib/
> > >
> > > It doesn't have many tests yet, just a few placeholders to demonstrate
> the
> > > file layout.
> >
> > Ok this looks great. The most important issue right now IMHO is
> > not how the test manager works, but where it lives in CVS.
> >
> > Nicolas said at one stage that the test suite shouldb't be
> > part of the distribution. Whether or not this is the case,
> > I would say it should be easily separable.
> >
> > IMHO test code and library code should be siblings,
> > the tests should be in a subdir of the src (just my opinion).
> 
> If Janne or anybody else is willing to take over the test suite CVS
> maintenance, I will give CVS write access.
> As for the repository, I prefer having it in a separate module, so anybody
> checking out extlib sources does not automaticaly get test suite too.
> Something like :
> 
> /CVSROOT
> /extlib-dev
> /extlib-test
> 

I'm wondering why you'd prefer to keep them separate...
Does it provide any tangible benefits?

(It certainly does have the drawback of making it more
cumbersome to keep the test suite and the library in
sync.)

-- 
Bardur Arantsson
<bardur@...>
<bardur@...>

- We interrupt this programme to annoy you and make things
generally irritating.
                     BBC Announcer | Monty Python's Flying Circus

On Mon, 2004-12-20 at 20:59, Nicolas Cannasse wrote:

> If Janne or anybody else is willing to take over the test suite CVS
> maintenance, I will give CVS write access.

Don't all developers have that anyhow?

> As for the repository, I prefer having it in a separate module, so anybody
> checking out extlib sources does not automaticaly get test suite too.
> Something like :
> 
> /CVSROOT
> /extlib-dev
> /extlib-test

That looks good.

-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Just to inform everyone, I have just imported the testing suite into CVS. 
The module layout is as proposed by Nicolas.

I will add copyright notices to the source files.  Currently the tester is 
using Markus Mottl's OCamlMakefile, I'm hoping to replace it by something 
simpler.

Currently the most complete tester exists for BitSet.  Unfortunately the 
best part of it is currently disabled, as it uses the new BitSet API 
(diff, union, et al.)

ciao,
janne

> If Janne or anybody else is willing to take over the test suite CVS
> maintenance, I will give CVS write access.
> As for the repository, I prefer having it in a separate module, so anybody
> checking out extlib sources does not automaticaly get test suite too.
> Something like :
>
> /CVSROOT
> /extlib-dev
> /extlib-test

Bardur Arantsson wrote:
> On Mon, Dec 20, 2004 at 10:59:27AM +0100, Nicolas Cannasse wrote:
> 
> 
>>>>You can download the source from:
>>>>
>>>>http://www.saunalahti.fi/~jjhellst/extlib/
>>>>
>>>>It doesn't have many tests yet, just a few placeholders to demonstrate
>>
>>the
>>
>>>>file layout.
>>>
>>>Ok this looks great. The most important issue right now IMHO is
>>>not how the test manager works, but where it lives in CVS.
>>>
>>>Nicolas said at one stage that the test suite shouldb't be
>>>part of the distribution. Whether or not this is the case,
>>>I would say it should be easily separable.
>>>
>>>IMHO test code and library code should be siblings,
>>>the tests should be in a subdir of the src (just my opinion).
>>
>>If Janne or anybody else is willing to take over the test suite CVS
>>maintenance, I will give CVS write access.
>>As for the repository, I prefer having it in a separate module, so anybody
>>checking out extlib sources does not automaticaly get test suite too.
>>Something like :
>>
>>/CVSROOT
>>/extlib-dev
>>/extlib-test
>>
> 
> 
> I'm wondering why you'd prefer to keep them separate...
> Does it provide any tangible benefits?
> 
> (It certainly does have the drawback of making it more
> cumbersome to keep the test suite and the library in
> sync.)

I agree that the two should be kept together to support code coding. 
Any additional steps that a developer has to do to check their new code 
  just gets in the way, even if it's done only once.

As practice, I don't think I know of any package that has a test suite 
that doesn't ship with it.  Most GNU software has a make test that you 
can run after you build it.

Regards,
Blair

-- 
Blair Zajac <blair@...>
Plots of your system's performance - http://www.orcaware.com/orca/

On Tue, 2004-12-21 at 07:24, Janne Hellsten wrote:
> Just to inform everyone, I have just imported the testing suite into CVS. 
> The module layout is as proposed by Nicolas.
> 

OK, I import it like this:

My system has the structure:

/usr/local/src/extlib/extlib-dev

So I did this:

cd /usr/local/src/extlib
export CVS_RSH=ssh
cvs -z3 -d:ext:skaller@... co
extlib-test

Now I have this:

[skaller@...] /usr/local/src/extlib>ls
extlib-dev  extlib-test


[skaller@...] /usr/local/src/extlib>ls extlib-test/
CVS       test_Base64.ml   test_ExtString.ml  test_jh_ExtList.ml   
test.mak
Makefile  test_BitSet.ml   test_jh_Base64.ml  test_jh_ExtString.ml 
util.ml
README    test_ExtList.ml  test_jh_BitSet.ml  test_main.ml



[skaller@...] /usr/local/src/extlib>cd extlib-test/
/usr/local/src/extlib/extlib-test



[skaller@...] /usr/local/src/extlib/extlib-test>make
cd ../extlib-dev && make all
make[1]: Entering directory `/mnt/local/src/extlib/extlib-dev'
ocamlc -a -o extLib.cma enum.mli bitSet.mli dbi.mli dynArray.mli
extHashtbl.mli
extList.mli extString.mli global.mli IO.mli option.mli pMap.mli std.mli
uChar.mli uTF8.mli base64.mli unzip.mli refList.mli optParse.mli
dllist.mli enum.ml bitSet.ml dbi.ml dynArray.ml extHashtbl.ml extList.ml
extString.ml global.ml IO.ml option.ml pMap.ml std.ml uChar.ml uTF8.ml
base64.ml unzip.ml refList.ml optParse.ml dllist.ml extLib.ml
make[1]: Leaving directory `/mnt/local/src/extlib/extlib-dev'
make -f test.mak all
make[1]: Entering directory `/mnt/local/src/extlib/extlib-test'
ocamlc -I ../extlib-dev -g extLib.cma util.ml test_jh_Base64.ml
test_Base64.ml test_jh_BitSet.ml test_BitSet.ml test_jh_ExtList.ml
test_ExtList.ml test_jh_ExtString.ml test_ExtString.ml test_main.ml  -o
extlib_test
make[1]: Leaving directory `/mnt/local/src/extlib/extlib-test'

[skaller@...] /usr/local/src/extlib/extlib-test>make run
make -f test.mak run
make[1]: Entering directory `/mnt/local/src/extlib/extlib-test'
./extlib_test
Extlib tester started..
 
run: Base64
run: jh_Base64.test
run: BitSet
run: jh_BitSet.test_intersect
run: jh_BitSet.test_diff
run: jh_BitSet.test_rnd_creation ..FAILED
  reason:
test_jh_BitSet.ml:60:4 test jh_BitSet.test_rnd_creation failed
 
run: jh_BitSet.test_empty
run: jh_BitSet.test_exceptions ..FAILED
  reason:
test_jh_BitSet.ml:116:2 test jh_BitSet.test_exceptions failed

run: ExtString
run: jh_ExtString.t_starts_with
run: jh_ExtString.t_map
run: jh_ExtString.t_lchop
run: jh_ExtString.t_rchop
run: jh_ExtString.t_split
run: ExtList
run: jh_ExtList.iteri
run: jh_ExtList.mapi
run: jh_ExtList.exceptions
run: jh_ExtList.find_exc
All tests completed.
make[1]: Leaving directory `/mnt/local/src/extlib/extlib-test'


All this is expected, including the failures (hmm .. it says
all tests completed, but doesn't report how many faiures .. still
this can be fixed later, for now the important step seems
achieved .. there is a place to put tests and a protocol for
constructing them.

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

I added a test for Dynarray (just a stub at the moment).
I got this:

....

Checking in test_main.ml;
/cvsroot/ocaml-lib/extlib-test/test_main.ml,v  <--  test_main.ml
new revision: 1.3; previous revision: 1.2
done
sh: line 1: /cvsroot/ocaml-lib/CVSROOT/commit.log: Permission denied
**********************************************************************

Looks like the commits worked, but the log wasn't updated??

[Comments on test harness next post]

-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

On Tue, 2004-12-21 at 07:24, Janne Hellsten wrote:
[Makefile .. test structure]

Janne currently has a three level test structure:

1. The mainline calls the test for each module.
2. The module test calls individual tests for each module
3. Individual tests call subtests 

In all 3 cases the call looks like this:

let test () = 
  Util.run_test ~test_name:"jh_ExtList.iteri" test_iteri;
  Util.run_test ~test_name:"jh_ExtList.mapi" test_mapi;
  Util.run_test ~test_name:"jh_ExtList.exceptions" test_exceptions;
  Util.run_test ~test_name:"jh_ExtList.find_exc" test_find_exc

In addition each file has to be listed in the file

test.mak

which is 'triple handling', in fact worse, since the test name
has to be written as well.. :)

Ideally, the test.mak, mainline, and module level
test function should be generated, not hand coded,
that is the Makefile should generate the these things
using a refined equivalent of 'ls test_*.ml'.

I.e. the to create a new test you just commit the
test file -- you don't change any existing files,
instead the files are constructed.

I suppose I can write an Ocaml program which will create these
files. This would work as follows:

(1) Look in extlib-dev for all mli files, to find the
names of top level modules. [Alternative -- hard code
the list of module names]

(2) Generate the mainline 'test_mail.ml' using these module names.

(3) For each module, generate a test file test_<module>.ml,
which calls each test for that module in the extlib-test directory
found with name

test_*_<module>_*.ml

Note this implies names like

test_jh_ExtList.ml

would not be allowed, a suffix would be required.
That could be fixed by also allowing names of that form.
I personally think we should mandate the suffix:
we'd better decide fast, before there are too many tests:
CVS isn't good at file renaming .. :)

Capitalisation rules would apply (the module names must
be exactly as used in Ocaml code). I'm not sure how this
will work on systems that aren't strict about filenames..

An alternative to an Ocaml program to do this would
be a bash script.. probably easier to write but could
be less portable, considering native Win32 environment
for example.

A BIG advantage of automatically generating the
test call protocol, apart from ease of adding new
tests, is that the actual protocol can be changed
to do things like count success/failure, generate
error reports blah blah .. without manual recoding,
except possibly at the individual test level.

It may actually be possible to build the individual
test() functions too, if the test functions within
the individual test files are annotated with
some special kind of mark eg:

TEST inner_test_name
 ......

which is replaced by

let inner_test_name () =

but which also gets added to the harness at the bottom of the
file like this:

let test () =
  Util.run_test ~test_name:"js_DynArray.inner_test_name" inner_test_name
  ...


Thus fully automating the whole suite construction, requiring
only the special form of declaration. This would imply changing
the CVS filenames to something like

test_jh_ExtLib_123.tst

[to avoid overwriting them when generating the *.ml file]

Comments?

-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Hi,

thank you for taking a peek.

A nice way to checkout whole extlib is just to do

cvs -d :ext:username@... co .

(note the dot)

This will checkout both extlib-dev and extlib-test.  If you then go to 
extlib-test and run "make all" it will build both the ExtLib and the 
testing suite.

While I agree with some people here about making the test suite an 
integral part of extlib, I think the current CVS layout allows people to 
both checkout and build&run the tester without a hassle.

Logging fail/success:  Actually I can easily do this with Util.run_test. 
  Perhaps I will add this in the near future.

Commit.log: I have no idea what that's all about.. I wondered about the 
same thing, but figured it's not a problem since the commit worked and 
individual file logs seem to be working OK.

I will address your (Skaller) other e-mail later (hopefully today).

ciao,
janne

skaller wrote:
> On Tue, 2004-12-21 at 07:24, Janne Hellsten wrote:
> 
>>Just to inform everyone, I have just imported the testing suite into CVS. 
>>The module layout is as proposed by Nicolas.
>>
> 
> 
> OK, I import it like this:
> 
> My system has the structure:
> 
> /usr/local/src/extlib/extlib-dev
> 
> So I did this:
> 
> cd /usr/local/src/extlib
> export CVS_RSH=ssh
> cvs -z3 -d:ext:skaller@... co
> extlib-test
> 
> Now I have this:
> 
> [skaller@...] /usr/local/src/extlib>ls
> extlib-dev  extlib-test
> 
> 
> [skaller@...] /usr/local/src/extlib>ls extlib-test/
> CVS       test_Base64.ml   test_ExtString.ml  test_jh_ExtList.ml   
> test.mak
> Makefile  test_BitSet.ml   test_jh_Base64.ml  test_jh_ExtString.ml 
> util.ml
> README    test_ExtList.ml  test_jh_BitSet.ml  test_main.ml
> 
> 
> 
> [skaller@...] /usr/local/src/extlib>cd extlib-test/
> /usr/local/src/extlib/extlib-test
> 
> 
> 
> [skaller@...] /usr/local/src/extlib/extlib-test>make
> cd ../extlib-dev && make all
> make[1]: Entering directory `/mnt/local/src/extlib/extlib-dev'
> ocamlc -a -o extLib.cma enum.mli bitSet.mli dbi.mli dynArray.mli
> extHashtbl.mli
> extList.mli extString.mli global.mli IO.mli option.mli pMap.mli std.mli
> uChar.mli uTF8.mli base64.mli unzip.mli refList.mli optParse.mli
> dllist.mli enum.ml bitSet.ml dbi.ml dynArray.ml extHashtbl.ml extList.ml
> extString.ml global.ml IO.ml option.ml pMap.ml std.ml uChar.ml uTF8.ml
> base64.ml unzip.ml refList.ml optParse.ml dllist.ml extLib.ml
> make[1]: Leaving directory `/mnt/local/src/extlib/extlib-dev'
> make -f test.mak all
> make[1]: Entering directory `/mnt/local/src/extlib/extlib-test'
> ocamlc -I ../extlib-dev -g extLib.cma util.ml test_jh_Base64.ml
> test_Base64.ml test_jh_BitSet.ml test_BitSet.ml test_jh_ExtList.ml
> test_ExtList.ml test_jh_ExtString.ml test_ExtString.ml test_main.ml  -o
> extlib_test
> make[1]: Leaving directory `/mnt/local/src/extlib/extlib-test'
> 
> [skaller@...] /usr/local/src/extlib/extlib-test>make run
> make -f test.mak run
> make[1]: Entering directory `/mnt/local/src/extlib/extlib-test'
> ./extlib_test
> Extlib tester started..
>  
> run: Base64
> run: jh_Base64.test
> run: BitSet
> run: jh_BitSet.test_intersect
> run: jh_BitSet.test_diff
> run: jh_BitSet.test_rnd_creation ..FAILED
>   reason:
> test_jh_BitSet.ml:60:4 test jh_BitSet.test_rnd_creation failed
>  
> run: jh_BitSet.test_empty
> run: jh_BitSet.test_exceptions ..FAILED
>   reason:
> test_jh_BitSet.ml:116:2 test jh_BitSet.test_exceptions failed
> 
> run: ExtString
> run: jh_ExtString.t_starts_with
> run: jh_ExtString.t_map
> run: jh_ExtString.t_lchop
> run: jh_ExtString.t_rchop
> run: jh_ExtString.t_split
> run: ExtList
> run: jh_ExtList.iteri
> run: jh_ExtList.mapi
> run: jh_ExtList.exceptions
> run: jh_ExtList.find_exc
> All tests completed.
> make[1]: Leaving directory `/mnt/local/src/extlib/extlib-test'
> 
> 
> All this is expected, including the failures (hmm .. it says
> all tests completed, but doesn't report how many faiures .. still
> this can be fixed later, for now the important step seems
> achieved .. there is a place to put tests and a protocol for
> constructing them.
> 
> ------------------------------------------------------------------------
> 
> I added a test for Dynarray (just a stub at the moment).
> I got this:
> 
> ....
> 
> Checking in test_main.ml;
> /cvsroot/ocaml-lib/extlib-test/test_main.ml,v  <--  test_main.ml
> new revision: 1.3; previous revision: 1.2
> done
> sh: line 1: /cvsroot/ocaml-lib/CVSROOT/commit.log: Permission denied
> **********************************************************************
> 
> Looks like the commits worked, but the log wasn't updated??
> 
> [Comments on test harness next post]
>

Hi,

> which is 'triple handling', in fact worse, since the test name
> has to be written as well.. :)

Well, it depends on how many test contributors and how many tests we're 
expecting.  I'm not expecting that many, so I don't consider adding 
tests such a big problem.

> Ideally, the test.mak, mainline, and module level
> test function should be generated, not hand coded,
> that is the Makefile should generate the these things
> using a refined equivalent of 'ls test_*.ml'.

This might be doable with GNU Make's $(wildcard) and some other tricks. 
  I never tried, but it seems doable.

Then again, if I *don't* do this, the Makefile would be more 
straightforward and would even allow test contributors to write their 
own small utility modules.  If I want to use wildcards, I will also need 
a portable way to automatically make the .ml files topologically sorted.

However, as to your other suggestions, frankly, I think you're making 
the build process unnecessarily complicated.  I don't see how adding new 
tests can ever become a bottleneck.  Nor do I think it can be somehow 
unsafe (even if a couple of files need to be modified), due to O'Caml's 
strong static typing.

Anyhow.. If someone will make a more sophisticated build system in the 
future, I'm OK with that.. Just make 100% sure that it ports to Windows. 
  I noticed there's been some talk about adding path handling into 
ExtLib.  These *definitely* need to be tested on Windows to make sure 
they work as expected!

Currently my main concern though is getting more meaningful tests into 
the suite..

> test_*_<module>_*.ml
> 
> Note this implies names like
> 
> test_jh_ExtList.ml
> 
> would not be allowed, a suffix would be required.
> That could be fixed by also allowing names of that form.
> I personally think we should mandate the suffix:
> we'd better decide fast, before there are too many tests:
> CVS isn't good at file renaming .. :)

Surely you can just check if the suffix is missing and if so, 
automatically name it "untitled".

I find it perfectly OK to have more than one test in one file.  In some 
cases it allows to share some code between individual tests.  See 
test_jh_BitSet.ml for an example (bitset_of_int, etc).

As for renaming.. Grrr I wish we could use Subversion.. :)

ciao,
janne

On Wed, 2004-12-22 at 05:57, Janne Hellsten wrote:

> Logging fail/success:  Actually I can easily do this with Util.run_test. 
>   Perhaps I will add this in the near future.
> 
> Commit.log: I have no idea what that's all about.. I wondered about the 
> same thing, but figured it's not a problem since the commit worked and 
> individual file logs seem to be working OK.

I think one of the two administrators will need to address
this issue. Probably just a minor permission glitch.

-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

On Wed, 2004-12-22 at 07:18, Janne Hellsten wrote:
> Hi,
> 
> > which is 'triple handling', in fact worse, since the test name
> > has to be written as well.. :)
> 
> Well, it depends on how many test contributors and how many tests we're 
> expecting.  I'm not expecting that many, so I don't consider adding 
> tests such a big problem.

But you are only one contributor to the project.
Even if you personally don't expect many contributions,
you probably shouldn't make a decision without consulting
list members.

> This might be doable with GNU Make's $(wildcard) and some other tricks. 
>   I never tried, but it seems doable.

> Then again, if I *don't* do this, the Makefile would be more 
> straightforward and would even allow test contributors to write their 
> own small utility modules.  If I want to use wildcards, I will also need 
> a portable way to automatically make the .ml files topologically sorted.

> However, as to your other suggestions, frankly, I think you're making 
> the build process unnecessarily complicated.  I don't see how adding new 
> tests can ever become a bottleneck.  

It already has been for me. It took me 10 times longer than
necessary to add a single 3 line test.

I need to question your assumption that automating the build
of the test system will make it more complicated.

In fact, I believe the opposite is true: we can probably
dispense *completely* with any makefile, and would provide
one only as a convenience.

I have had this reaction before -- automation is one of
my specialities, it really *isn't* that hard to do.

> Nor do I think it can be somehow 
> unsafe (even if a couple of files need to be modified), due to O'Caml's 
> strong static typing.

The static typing does not

(a) guarrantee a test will be called
(b) ensure the test is in the correct category
(c) the test is properly named


However it is worse. Remember we're using CVS. A system which
cleanly separates changes into files is obviously better
than the current situation, where every tester is going
to modify files *other* testers will also have to modify.

Whether CVS can handle simultaneous changes or not,
it is probably better to make it easier than harder :)

> Anyhow.. If someone will make a more sophisticated build system in the 
> future, I'm OK with that.. Just make 100% sure that it ports to Windows.

Indeed this is a strong argument against Makefiles and shell
script. An Ocaml based solution is more likely to be portable.
 
>   I noticed there's been some talk about adding path handling into 
> ExtLib.  These *definitely* need to be tested on Windows to make sure 
> they work as expected!

Yes.

> Currently my main concern though is getting more meaningful tests into 
> the suite..

This will come over time. I wouldn't worry so much about that
as setting up the mechanism so that it is as easy as possible
for people to contribute tests.

> > test_*_<module>_*.ml
> > 
> > Note this implies names like
> > 
> > test_jh_ExtList.ml
> > 
> > would not be allowed, a suffix would be required.

> Surely you can just check if the suffix is missing and if so, 
> automatically name it "untitled".

Of course once could do this -- the question is: do we want to?
I'm in favour of strictness and simplicity, and this format breaks
those guidelines.

> I find it perfectly OK to have more than one test in one file.  In some 
> cases it allows to share some code between individual tests.  See 
> test_jh_BitSet.ml for an example (bitset_of_int, etc).

I have no problem with that. Nor the current 3 level design
I described before. I'm not sure it is the best, but I'm quite
happy to work with it for the moment.

My concern is solely to limit the work of test designers
to making a file containing tests and then submitting it,
perhaps to CVS, and perhaps just posting on the mailing list
so someone else with access can 'cut and paste' the example
into the test suite with minimal effort.


> As for renaming.. Grrr I wish we could use Subversion.. :)

LOL! Whatever, the time to make this kind of change is 
right now, before it is too hard and we're stuck with
a possibly suboptimal design.

-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

> > Logging fail/success:  Actually I can easily do this with Util.run_test.
> >   Perhaps I will add this in the near future.
> >
> > Commit.log: I have no idea what that's all about.. I wondered about the
> > same thing, but figured it's not a problem since the commit worked and
> > individual file logs seem to be working OK.
>
> I think one of the two administrators will need to address
> this issue. Probably just a minor permission glitch.

Yes but I don't have access to the file rights on the CVSROOT directory. I
tried several times to disable the log and it failed, and I asked one time
to SF managers but they didn't fix it right. Not so big deal...

Nicolas

My apologies for being silent for so long (life intervened).  One 
question on this subject: is there a reason we're not using OUnit?  I have 
some minor annoyances with it (it needs findlib installed is the biggest 
one), but not enough to write my own.

I'm about 1/2 way done with a module implementing Chris Okasaki's random 
access lists, if people are interested.  For those who don't know, these 
are lists that work mostly like normal linked lists, except that getting 
the nth element is O(log N), and not O(N).  Several other operations are 
similiarly more efficient.  The reason I bring this up is that I'm 
writting the test suite in OUnit.

Brian

On Mon, 2005-01-17 at 11:37, Brian Hurt wrote:
> My apologies for being silent for so long (life intervened).  One 
> question on this subject: is there a reason we're not using OUnit? 

Dependencies. The test mechanism needs to be independent
of everything that isn't either in standard Ocaml 
distro or Extlib.

This problem would go away if GODI was standard
but it isn't ..

-- 
John Skaller, mailto:skaller@...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

On Mon, Jan 17, 2005 at 12:38:28PM +1100, skaller wrote:

> On Mon, 2005-01-17 at 11:37, Brian Hurt wrote:
> > My apologies for being silent for so long (life intervened).  One 
> > question on this subject: is there a reason we're not using OUnit? 
> 
> Dependencies. The test mechanism needs to be independent
> of everything that isn't either in standard Ocaml 
> distro or Extlib.

It seems that OUnit doesn't actually depend on anything
else (well, except findlib for the build procedure, but
that's easily remedied -- it's just one module after all),
so I'm guessing you mean that you don't want ExtLib to
become dependent on OUnit...?

What about just bundling a version of OUnit with ExtLib?
The code seems to be under a BSD-ish license (w/o
advertising clause), so this would be permitted and it
shouldn't really cause any maintenance issues as the OUnit
code (nor any code using OUnit) shouldn't be installed
anyway.

Cheers,

-- 
Bardur Arantsson
<bardur@...>
<bardur@...>

Light a man a fire, you warm him for a night. Light a man on
fire, he'll be warm the rest of his life.

Hi all,

I am willing to help if you have any trouble with the existing ExtLib 
tester.  I think the assertion mechanism is easy to use and easy to 
understand, but of course I'm biased since I wrote the suite.

extlib-test/readme.html has a some documentation on how to make new tests.

When I embarked on writing the test suite, I was more interested in 
making the actual tests rather than discussing on what kind of a 
framework to use for the tests.

Perhaps someone could clarify what is gained by using OUnit instead of 
the current suite?  I personally feel that the real test cases are what 
counts, not the testing framework.

Best regards,
Janne

skaller wrote:
> On Mon, 2005-01-17 at 11:37, Brian Hurt wrote:
> 
>>My apologies for being silent for so long (life intervened).  One 
>>question on this subject: is there a reason we're not using OUnit? 
> 
> 
> Dependencies. The test mechanism needs to be independent
> of everything that isn't either in standard Ocaml 
> distro or Extlib.
> 
> This problem would go away if GODI was standard
> but it isn't ..
>

I agree here.

The one willing to write the tests are free to choose how they want to write
them.

Nicolas

> Hi all,
>
> I am willing to help if you have any trouble with the existing ExtLib
> tester.  I think the assertion mechanism is easy to use and easy to
> understand, but of course I'm biased since I wrote the suite.
>
> extlib-test/readme.html has a some documentation on how to make new tests.
>
> When I embarked on writing the test suite, I was more interested in
> making the actual tests rather than discussing on what kind of a
> framework to use for the tests.
>
> Perhaps someone could clarify what is gained by using OUnit instead of
> the current suite?  I personally feel that the real test cases are what
> counts, not the testing framework.
>
> Best regards,
> Janne
>
> skaller wrote:
> > On Mon, 2005-01-17 at 11:37, Brian Hurt wrote:
> >
> >>My apologies for being silent for so long (life intervened).  One
> >>question on this subject: is there a reason we're not using OUnit?
> >
> >
> > Dependencies. The test mechanism needs to be independent
> > of everything that isn't either in standard Ocaml
> > distro or Extlib.
> >
> > This problem would go away if GODI was standard
> > but it isn't ..