[m-dev.] New release?

[Julien Fischer]

On Wed, 21 Oct 2015, Paul Bone wrote:

> On Wed, Oct 21, 2015 at 10:25:57AM +1100, Julien Fischer wrote:
>>
>> Hi Paul,
>>
>> On Tue, 20 Oct 2015, Paul Bone wrote:
>>
>>> Simple question, difficult answer..
>>>
>>> Is now a good time for a new Mercury release?
>>
>> It's certainly time we had another one; the GC upgrade was the main block.
>>
>>> Last time Julien and I spoke about this, quite a while ago, I recall that we
>>> wanted to upgrade Boehm GC first.  Now that that is done is there any other
>>> planned changes that we'd like to wait for?
>>
>> Before we branch we need to finalise the break-up of the standard library's
>> 'term' module, as per the following thread
>> <http://www.mercurylang.org/list-archives/reviews/2015-February/017741.html>.
>> In particular, the type term.context/0 needs to be moved to its own module.
>>
>> Bug #357, "Parallel conjunction broken on OS X" is a showstopper.  The
>> actual situation is worse than described in that bug report, _none_ of the
>> .par grades currently work on OS X.  (They worked in 14.01.)
>
> I've also been having trouble with parallel conjunction lately.  I'm not
> sure what's changed as I haven't looked at this for a while.  Although very
> few people use this feature, I'd still prefer to avoid regressions from
> release-to-release.

When I say the situation is worse, I mean that hlc.par.gc *also* does
not currently work on OS X (i.e. you can't use threads in the C grades
on OS X at the moment.)

> These types of bugs can probably be fixed on a release branch and merged
> back into master.  That said it still makes sense to wait before branching
> for Zoltan's change, to avoid making that more difficult than it needs to
> be.
>
>>
>> In addition, the following bugs really ought to be resolved before
>> any release:
>>
>>    * Bug #278: Compiler crash from bad state variable use.
>>    * Bug #373: string.to_float imprecisely specified.
>>
>> (There's almost certainly some other bugs that we would ideally address as
>> well.)
>>
>> There's some more standard library issues that aren't currently in the bug
>> database, for example float.round_to_int/1 and friends have inconsistent
>> behaviours across different backends when their argument won't fit in an int.
>> (I'll add an entry to Mantis for this.)
>
> Hrm, I'd like to try making a "TODO list" of bugs to fix for the release.
> I suggest tagging bugs in Mantis with the release name then using the
> roadmap feature as a TODO list.  I've added #357 as a test:
>
> https://www.mercurylang.org/bugs/roadmap_page.php

It seems a trifle optimistic to assume that it's going to be 15.11 ;-)

>> There was a list of things we wanted to do to address the "too many grades"
>> problem.  Some of these have been done (e.g. hiding user facing documentation
>> for experimental grade components), others haven't yet (e.g. merging the 'tr'
>> and 'trseg' grade components and renaming the grade component options).  See
>> the following thread:
>> <http://www.mercurylang.org/list-archives/reviews/2014-September/017297.html>
>
> When this came up recently Micheal (despite how he raised the issue) made a
> good suggestion that we should document not just what the grade components
> mean (which mostly exists in the user guide) but which combinations make
> sense / are supported / are well tested.

There are have been various changes over the past year or so that
have improved this stituation:

* the user facing documentation for the experimental grades has been
   hidden -- the publicly document grade components should be the ones
   that are well tested.

* the compiler and mgnuc script now carry out checks of grade component
   compatibility, for example:

      $ mmc --grade hlc.gc.stseg foo

   will result in:

      mercury_compile: stack segments are incompatible with the high-level C backend

(Hmmm, the word "error" really ought to appear in that message ...)

* the usage message and user's guide were updated to say which
   combinations are allowed (where that wasn't already stated).

> This was one of the reasons I setup the wiki.  There were a bunch of reasons
> but this was the one that actually got me to do something.  It has has very
> few contributions but zero spam, so I think that there's still potential
> there.  Anyway, my point is that some of the "too many grades" solution is
> orthogonal to making a release.

The main thing that remains to be done is to add new grade component
options.  The reason we want to do that is so that we can deprecate the
existing options.  We want to do that so we can change, for example,
'--debug' to means "choose the best available installed debug grade" intead of
"add the debug grade component to the current grade".

Julien.