ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] Future of ExtLib

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

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
<ba...@im...>
<ba...@sc...>

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

Re: [Ocaml-lib-devel] Future of ExtLib

[Janne H. <ja...@hy...>]

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

Re: [Ocaml-lib-devel] Future of ExtLib

[Janne H. <ja...@hy...>]

> 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

Re: [Ocaml-lib-devel] Future of ExtLib

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

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

Re: [Ocaml-lib-devel] Future of ExtLib

[skaller <sk...@us...>]

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:sk...@us...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Ocaml-lib-devel] a bug in BitSet?

[skaller <sk...@us...>]

On Sun, 2004-12-19 at 23:11, Bardur Arantsson wrote:

> If they're changed to behaving in a non-destructive way,
> then the names should *definitely* be changed. For the
> sake of consistency I would suggest using the same names
> as are used in the standard library's Set:
> 
>      union, inter, diff

There many be a good reason for a non-functional
API as well (performance) -- but please note I said 'may'.
In C it would definitely be the case, but in Ocaml it may
not be so -- the functional interface is vital, and the
same names as Set module is clearly the way to go where
appropriate.

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

[Ocaml-lib-devel] ExtLib testing suite + BitSet bug fixes

[Janne H. <ja...@hy...>]

Hi all,

I put a new version of the ExtLib testing suite on my homepage at:

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

It now contains failure/test logging and new tests.  The BitSet tester 
(test_jh_BitSet2.ml) is fairly complete.

I'd appreciate if someone had the time to take a look and comment on it.

* *

I have included a patched version of BitSet module in the package 
(test/bitSet2.ml/mli).  This version adds union, diff and inter functions. 
These work the same way as their counterparts in stdlib's Set module.

The BitSet.unite was left as is, old implementations of differentiate and 
intersect were removed and re-written on top of diff and inter.

I didn't have time to fix BitSet.compare yet.

ciao,
janne

Re: [Ocaml-lib-devel] a bug in BitSet?

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

> In my opinion overusing unsafe_get/set sets a bad example
> because people will assume they'll always write bug-free
> code and just end up using unsafe_get/set "by default".

I agree in general : I never use "unsafe" features in my application code.
But ExtLib is a library, and one used for very basic operations. It should
then provide the user with the best speed available, or users interested in
speed might end up rewriting the code themselves with is not what we want.
As for bitset, checks should be done when the interface functions are called
(negative index and others) so if they're correctly done we don't need
additionnal checks. If they're not, this is a bug and have to be fixed.

Nicolas

Re: [Ocaml-lib-devel] a bug in BitSet?

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

On Sun, Dec 19, 2004 at 03:44:54PM +0200, Janne Hellsten wrote:

> 
> On Sun, 19 Dec 2004, Bardur Arantsson wrote:
> >I'm no expert on OCaml optimization, but I believe there
> >is a considerable performance benefit in using unsafe_get
> >(bget), unsafe_set (bset), etc. because you can avoid
> >bounds checking and always get proper inlining. Whether
> >this level of optimization is really necessary for BitSet
> >I'll leave as an exercise for the reader. :)
> 
> ...
> 
> >I don't think the compiler is currently clever enough (or
> >maybe the language semantics are not strict enough?) to do
> >all the needed inlining, and the bounds checking would
> >still slow you down.
> 
> I took the current BitSet module, modified bget and bset to just use 
> String.[] normally and added the couple of necessary char_of_ints and 
> int_of_chars.  I then went on a compiled the BitSet module with ocamlopt 
> -unsafe (to turn off bounds checking).  The resulting assembly is pretty 
> much the same as with the Obj.magic+unsafe_get trickery, except that 
> ocamlopt seems to be unable to inline int_of_char calls (which was a 
> surprise to me).

Generally I would say one should always compile without
-unsafe and use unsafe_get and companions in those
instances where it can be *guaranteed* to stay within the
bounds *AND* where it matters for performance.

Even in cases where it is easy to prove that the index is
always within bounds, I wouldn't use unsafe_get/set unless
it actually matters a great deal for performance. It
reduces readability and makes code harder to modify later.

> 
> >I think compiling without bounds checking for "release"
> >builds is unwise since it may obscure serious bugs which
> >haven't been caught by the test suite. It's basically rude
> >to anyone using the library to (possibly) obscure bugs
> >within the library this way.
> 
> Yes.  However, it seems that many parts of the library
> *are* already using unsafe_gets.

Yup. Personally, I'd like to see some instances of such
use removed from some ExtLib code, but I don't care enough
to submit patches :). Examples include Dbi.string_escaped
and UTF8.look where the performance difference is most
likely tiny.

In my opinion overusing unsafe_get/set sets a bad example
because people will assume they'll always write bug-free
code and just end up using unsafe_get/set "by default".

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

- If you can remember drinking it, you obviously didn't drink
enough of it.
                                                               Me

Re: [Ocaml-lib-devel] a bug in BitSet?

[Janne H. <ja...@hy...>]

On Sun, 19 Dec 2004, Bardur Arantsson wrote:
> I'm no expert on OCaml optimization, but I believe there
> is a considerable performance benefit in using unsafe_get
> (bget), unsafe_set (bset), etc. because you can avoid
> bounds checking and always get proper inlining. Whether
> this level of optimization is really necessary for BitSet
> I'll leave as an exercise for the reader. :)

...

> I don't think the compiler is currently clever enough (or
> maybe the language semantics are not strict enough?) to do
> all the needed inlining, and the bounds checking would
> still slow you down.

I took the current BitSet module, modified bget and bset to just use 
String.[] normally and added the couple of necessary char_of_ints and 
int_of_chars.  I then went on a compiled the BitSet module with ocamlopt 
-unsafe (to turn off bounds checking).  The resulting assembly is pretty 
much the same as with the Obj.magic+unsafe_get trickery, except that 
ocamlopt seems to be unable to inline int_of_char calls (which was a 
surprise to me).

> I think compiling without bounds checking for "release"
> builds is unwise since it may obscure serious bugs which
> haven't been caught by the test suite. It's basically rude
> to anyone using the library to (possibly) obscure bugs
> within the library this way.

Yes.  However, it seems that many parts of the library *are* already using 
unsafe_gets.

But I guess people can go and compile with -unsafe themselves if they want 
the extra performance (if any).

ciao,
janne

Re: [Ocaml-lib-devel] a bug in BitSet?

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

On Sun, Dec 19, 2004 at 03:07:03PM +0200, Janne Hellsten wrote:

[--snip--]
> >If they're changed to behaving in a non-destructive way,
> >then the names should *definitely* be changed. For the
> >sake of consistency I would suggest using the same names
> >as are used in the standard library's Set:
> >
> >    union, inter, diff
> 
> I will add non-destructive union, diff and inter and make the old ones use 
> the new non-destructive ones.  They will make unite et al. just a little 
> slower -- but I guess slower is better than unsafely reading past the 
> arrays.

Speed is irrelevant if the correctness isn't there. So,
always go for correctness over speed. If someone is
concerned about the speed they can always implement/submit
a faster version later.

> 
> I wonder if anyone has any ideas about the Obj.magic trickery in BitSet? 
> To me it seems that using string.[] with int_of_char would do the same 
> thing.  Is it just an optimization?

Yes, Obj.magic is basically just a typecast... which works
as long as the internal representations of types are
"compatible" in some useful way. An example: If I recall
correctly,

     ('a list)

is compatible with the record type

     { elem : 'a; tail : mutable 'a list }

In this case Obj.magic can be exploited to implement lists
with mutable tails (and similar trickery).

I'm no expert on OCaml optimization, but I believe there
is a considerable performance benefit in using unsafe_get
(bget), unsafe_set (bset), etc. because you can avoid
bounds checking and always get proper inlining. Whether
this level of optimization is really necessary for BitSet
I'll leave as an exercise for the reader. :)

> I would assume that ocamlopt with proper inlining should
> be able to do pretty good job on it without the added
> trickery.

I don't think the compiler is currently clever enough (or
maybe the language semantics are not strict enough?) to do
all the needed inlining, and the bounds checking would
still slow you down.

> 
> It would be nice to be able to compile ExtLib with bounds
> checking on, at least when running the test suite.
> 

I think compiling without bounds checking for "release"
builds is unwise since it may obscure serious bugs which
haven't been caught by the test suite. It's basically rude
to anyone using the library to (possibly) obscure bugs
within the library this way.

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

God is REAL unless explicitly declared INTEGER.
                                       Unknown FORTRAN programmer

Re: [Ocaml-lib-devel] a bug in BitSet?

[Janne H. <ja...@hy...>]

On Sun, 19 Dec 2004, Bardur Arantsson wrote:
> Compare seems completely broken to me too, at least if one
> expects it to work like you suggest (which is IMHO the
> correct way).
>
> It doesn't seem to properly account for the two bitsets
> possibly being of different lengths, it just starts
> comparing at the MSB even if the difference between the
> lengths of the sets is more than a byte. It gets more
> complicated because you can't even use |t1|>|t2| as an
> indication that t1>t2, because there is AFAICT no
> guarantee that the leading bit (or even just one bit in
> the first byte of the representation!) is set.

I'll fix this one as well.

> If they're changed to behaving in a non-destructive way,
> then the names should *definitely* be changed. For the
> sake of consistency I would suggest using the same names
> as are used in the standard library's Set:
>
>     union, inter, diff

I will add non-destructive union, diff and inter and make the old ones use 
the new non-destructive ones.  They will make unite et al. just a little 
slower -- but I guess slower is better than unsafely reading past the 
arrays.

I wonder if anyone has any ideas about the Obj.magic trickery in BitSet? 
To me it seems that using string.[] with int_of_char would do the same 
thing.  Is it just an optimization?

I would assume that ocamlopt with proper inlining should be able to do 
pretty good job on it without the added trickery.

It would be nice to be able to compile ExtLib with bounds checking on, at 
least when running the test suite.

ciao,
janne

Re: [Ocaml-lib-devel] a bug in BitSet?

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

On Sun, Dec 19, 2004 at 01:34:26PM +0200, Janne Hellsten wrote:

> 
> >Looks like all intersect, unite, and friends have serious flaws.
> >They have been posted on this list by some people, and I added them without
> >checking. Next time I will ;)
> 
> Yep, that's what I figured as well.  But decided I will point my 
> finger at only the ones that I have a tester ready :)
> 
> I am not yet 100% sure, but it also seems that BitSet.compare is broken. 
> According to the docs, it is not absolutely clear how the comparison 
> should be interpreted, but to me a sensible compare would work the same 
> way as forming a bignum of the bitset and comparing the bignums.

Compare seems completely broken to me too, at least if one
expects it to work like you suggest (which is IMHO the
correct way). 

It doesn't seem to properly account for the two bitsets
possibly being of different lengths, it just starts
comparing at the MSB even if the difference between the
lengths of the sets is more than a byte. It gets more
complicated because you can't even use |t1|>|t2| as an
indication that t1>t2, because there is AFAICT no
guarantee that the leading bit (or even just one bit in
the first byte of the representation!) is set.

> 
> Currently this does not appear to be the case.
> 
> >The functions themselves are not designed correctly, I would like to change
> >them from :
> >
> >val intersect : t -> t -> unit
> >
> >to :
> >
> >val intersect : t -> t -> t
> >
> >which will produce a new bitset. Sounds more logical to me in Ocaml world.
> >Any volunteer for implementation ?
> 
> Yes, this is one nitpick that I had in mind.  Is it possible to just go 
> and change the API on these?

I think the general concensus on this list is to avoid
gratuitous changes, but necessary changes for a
cleaner/better API are OK.

> 
> I also think that "union" would be a nicer name "unite" and "difference" 
> (or "subtract") instead of "differentiate".  In my mind differentiate 
> associates to calculating derivatives.

If they're changed to behaving in a non-destructive way,
then the names should *definitely* be changed. For the
sake of consistency I would suggest using the same names
as are used in the standard library's Set:

     union, inter, diff

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

- I'm not evil, I'm... differently motivated!

Re: [Ocaml-lib-devel] a bug in BitSet?

[Janne H. <ja...@hy...>]

> Looks like all intersect, unite, and friends have serious flaws.
> They have been posted on this list by some people, and I added them without
> checking. Next time I will ;)

Yep, that's what I figured as well.  But decided I will point my 
finger at only the ones that I have a tester ready :)

I am not yet 100% sure, but it also seems that BitSet.compare is broken. 
According to the docs, it is not absolutely clear how the comparison 
should be interpreted, but to me a sensible compare would work the same 
way as forming a bignum of the bitset and comparing the bignums.

Currently this does not appear to be the case.

> The functions themselves are not designed correctly, I would like to change
> them from :
>
> val intersect : t -> t -> unit
>
> to :
>
> val intersect : t -> t -> t
>
> which will produce a new bitset. Sounds more logical to me in Ocaml world.
> Any volunteer for implementation ?

Yes, this is one nitpick that I had in mind.  Is it possible to just go 
and change the API on these?

I also think that "union" would be a nicer name "unite" and "difference" 
(or "subtract") instead of "differentiate".  In my mind differentiate 
associates to calculating derivatives.

I might have a little time during the next couple of weeks.  So if there's 
no hurry, perhaps I could volunteer for making these changes.

ciao,
janne

Re: [Ocaml-lib-devel] a bug in BitSet?

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

> I was writing a test for Extlib's BitSet and encountered a weird case.
> The following does not seem to work as it is supposed to work
> (intersection of a set with the empty set produces a non-empty set).

Looks like all intersect, unite, and friends have serious flaws.
They have been posted on this list by some people, and I added them without
checking. Next time I will ;)
The functions themselves are not designed correctly, I would like to change
them from :

val intersect : t -> t -> unit

to :

val intersect : t -> t -> t

which will produce a new bitset. Sounds more logical to me in Ocaml world.
Any volunteer for implementation ?
Real Life takes quite a lot of my time too ;)

Nicolas Cannasse

[Ocaml-lib-devel] a bug in BitSet?

[Janne H. <ja...@hy...>]

I was writing a test for Extlib's BitSet and encountered a weird case. 
The following does not seem to work as it is supposed to work 
(intersection of a set with the empty set produces a non-empty set).

Run function test_rnd_creation for the buggy behaviour.  For some reason 
test_intersect does not exhibit the same behaviour.

A quick glance at the BitSet.intersect would suggest that it is reading 
past the second argument bit array (bget uses string_unsafe_get).

I incorporated this into my tester, but didn't enable it yet.

Apologies if this has already been fixed in CVS.  I'm using the 
released 1.3 version.

Here is the source for the test case:

<snip>
module B = BitSet

let bitset_of_int n =
   assert (n <= (1 lsl 29));
   let s = B.create 30 in
   for i = 0 to 29 do
     if (n land (1 lsl i)) <> 0 then
       B.set s i
   done;
   s

let int_of_bitset s =
   let n = ref 0 in
   for i = 0 to 29 do
     if B.is_set s i then
       n := !n lor (1 lsl i)
   done;
   !n

let test_rnd_creation () =
   for i = 0 to 255 do
     let r1 = Random.int (1 lsl 28) in
     let s = bitset_of_int r1 in
     let c = B.copy s in
     assert (int_of_bitset s = r1);
     assert (c = s);
     assert (B.compare c s = 0);
     B.unite c s;
     assert (c = s);
     B.intersect c (B.empty ());
     assert (B.count c = 0);
   done

let test_intersect () =
   for i = 0 to 2550 do
     let s = bitset_of_int (Random.int 1 lsl 28) in
     B.intersect s (B.empty ());
     assert (B.count s = 0)
   done
</snip>

ciao,
janne

Re: [Ocaml-lib-devel] Future of ExtLib

[Janne H. <ja...@hy...>]

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

Re: [Ocaml-lib-devel] Future of ExtLib

[Janne H. <ja...@hy...>]

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

Re: [Ocaml-lib-devel] Future of ExtLib

[Richard W.M. J. <ri...@me...>]

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

Re: [Ocaml-lib-devel] Future of ExtLib

[skaller <sk...@us...>]

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:sk...@us...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Ocaml-lib-devel] Future of ExtLib

[Janne H. <ja...@hy...>]

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

Re: [Ocaml-lib-devel] Future of ExtLib

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

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
<ba...@im...>
<ba...@sc...>

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

Re: [Ocaml-lib-devel] Future of ExtLib

[Janne H. <ja...@hy...>]

> 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

Re: [Ocaml-lib-devel] Future of ExtLib

[Richard J. <ri...@an...>]

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

Re: [Ocaml-lib-devel] Future of ExtLib

[Janne H. <ja...@hy...>]

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