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

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

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