[mercury-users] Mercury Anarchive proposal

Ondrej Bojar bojar at csse.unimelb.edu.au
Fri Feb 23 11:37:52 AEDT 2007


Dear all,

most of you have probably implemented lots of functions and predicates that 
"should" be in the Mercury standard library but still are not there. Some of 
you have even contributed your extensions either to the Mercury-extras, on 
your personal web site, or posted to this forum on someone else's request. I 
also have a collection of routines that could be useful to other people and I 
wish other people were spotting rare bugs in my code, because I use it every 
day and tend to rely on it.

Given the harsh committing policy of the Mercury team I thought of introducing 
some anarchy ;-) and start Mercury Anarchive. The name can be shortened to 
Manarchive or Mana (pronounced either like mana or manna [mannah], depending 
on your religious background).

Manarchive will be a repository for generally useful routines, like c?an's are 
for Perl, TeX, R-Project and others. I am not too ambitious at this point.

In this pre-announcement, I'd like learn from those of you who might wish to 
make use of the archive or who might want to contribute:

- has the Manarchive to adopt a specific copyright policy to be useful for
   you?
   I'm not good at picking one of the ready-made licences, all I want is
   that my credit is recognized and kept in comments. I do not mind if the code
   I'd contribute would be used in for-profit systems.

- has the Manarchive repository to live in a "public" place like sourceforge?
- or would sourceforge block you from contributing?
   I sort of prefer keeping the main repository on disks I have nearly physical
   access to, but regular 'svnadmin dump' can solve this.


As for the usage:

1. Using Manarchive should be as simple as possible, something like:
     svn checkout
     make  # to compile all the parts that have prerequisities satisfied
           # (some of the packages might depend on some libraries
           # installed; only users wanting such packages should be forced
           # to satisfy the prerequisities)
     mmc --make \
         `manarchive-config --print-mmc-flags --package X --package Y` \
         myproject
           # to link against packages X and Y (if they were successfully made)

     Manarchive must be usable both with libraries 'installed' (all grades
     generated) and with libraries 'non-installed' (just your favourite grade,
     for quick debugging of the library)

2. Contributing must be as simple as possible, something like:

     join sourceforge (or whatever we go for)
     svn add your-new-contribution # and all the files in it
     svn commit # with a pre-commit validation
          # ideally, the pre-commit validation would not allow committing if
          # any package fails some of the tests after your change that were
          # successful before your change

     It must be easy for a Manarchive package to depend on other Manarchive
     packages (at the current Manarchive revision; no version spaghetti,
     please)

I plan to enforce these rules:

1. Anything can be contributed, provided no name-clashes happen.

2. People are kindly asked to stick to coding style of the package they are 
modifying. Bringing your own package, you can bring your own style.

2. As soon as a contributor has time, the package should be upgraded to 
"partially_tested" status: Tested packages must contain a non-empty set of 
tests -- each consisting of a mercury program and expected output (or more 
outputs one of which must succeed).

3. As soon as a contributor has time, the package should be upgraded to
"has_example" status: Exemplified packages must contain a non-empty set of 
examples -- essentially like test programs with expected output, but intended 
for users to read.

4. If a contributor has abundance of free time, he/she might wish to upgrade a 
package to "fully_tested" status: Fully tested packages must contain a single 
mercury program (with a set of expected inputs and corresponding expected 
outputs) that actually checks every part of the package. 'mcov' will be used 
to check the fully_tested status.

The main make of the library will prepare a summary listing every package and 
it's status:
   - failed_to_compile
   - untested
   - partially_tested(passed)
   - partially_tested(failed)
   - fully_tested(passed)
   - fully_tested(failed)

Looking forward to your comments and suggestions,
   Ondrej.

-- 
Ondrej Bojar (mailto:obo at cuni.cz / bojar at ufal.mff.cuni.cz)
http://www.cuni.cz/~obo
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the users mailing list