[m-users.] mmc option parallel

[Paul Bone]

On Mon, Mar 16, 2015 at 06:21:09PM +1100, Peter Schachte wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 16/03/2015 10:23 am, Paul Bone wrote:
> > I believe that the long term solution is to make a clear separation between options and grade
> components. And possibly to abstract away grades altogether. A user
> should be able to say "I want parallelism" and get it, as you suggest,
> by the system choosing the best parallel grade available. Thanks.
> 
> Grades are something the Mercury implementors are interested in, and
> users are not.  The better you can hide them from users, the better.  If
  ^^^^^^^^^^^^^
  This,

    We think grades are cool because we like to test and compare them.  But
    users (who are the larger group making use of this software) do not.

> Mercury had a pragma to allow a file to specify that it needs some grade
> component, most users would not need to use it or even know about it. 
> Some libraries would specify that they need a trail, or threads, or
> stack segments, etc.  It would be up to the build system to piece
> together the grade components needed by the (recursive dependencies of)
> the application source files, and validate that they don't conflict.  It
> should also keep track of what grade the current object files were built
> with and rebuild if the grade changes (or perhaps generate each grade in
> a different subdirectory to keep them from interfering with one
> another).  There should also be some compiler switches for things like
> debugging, stack segments, or leaving out the garbage collector, but the
> user would not need to be aware they relate to grades.  This should
> allow all but the most advanced users to remain ignorant of grades.
> 
> Regarding the time taken to build the library in different grades, how
> about having the compiler create a directory somewhere under the user's
> home directory holding (caching) the library files built in the grades
> that have been needed in the past.  Then it would not be necessary to
> build any libraries at install time other than those used in the
> compiler itself.  This would waste space on a multiuser system where
> many people use Mercury, since some generated files would be stored
> under several people's home directories, but space is pretty cheap these
> days, and most people have single-user computers anyway.  There would
> also be space and time *savings* since only library files that have been
> used would be built, and only in the grades they've actually been used in.

I thought that the compiler should provide a script that will install a new
grade.  If the compiler finds that a library grade isn't installed then it
prompts the user to contact their administrator or run "sudo
mercury-install-another-grade"

Cheers.


-- 
Paul Bone