[m-dev.] New release?
jfischer at opturion.com
Mon Nov 2 11:32:48 AEDT 2015
On Thu, 29 Oct 2015, Paul Bone wrote:
> On Tue, Oct 20, 2015 at 05:52:21PM +1100, Paul Bone wrote:
>> Is now a good time for a new Mercury release?
> I've re-read through this list and made a list of the changes that people
> want before we make a release. Only three directly referenced issues are
> files as bugs is mantis.
I've added some more, all of which are things that cause the compiler
to abort or generated executables to behave incorrectly. (And that
don't require the implementation of a new mode checker to fix!)
A few of the existing bugs have actually been fixed, I've marked them
as resolved and added regression tests where necessary.
I'm still going through the bug database, I'll post a more complete list
of things that (ideally) should be addressed before the release later.
> The others are here:
> Zoltan's type status change
> Zoltan's invalid data in the .d file bug
> 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
> Zoltan's Grade selection proposal, if accepted.
Ideally, yes. The changes to the grade component command line options
certainly need to happen, since we want to deprecate the meanings of
the existing options.
> Julien's Installation profiles (seems like this is accepted).
> Duplicate output in .par grades on linux - pbone
What's this one?
> Stack segments as default.
> Anything else?
Trail segments as default.
Installation of extra grades. In one of the recent threads, I proposed
we write a new tool to manage this -- I don't know whether this will be
done in time, but provided the changes to the configure script pass
review I see no reason not to commit them now.
There's a change from Mark, "variable bindings for interactive queries",
that I think also ought to go in.
There's bunch of issues where program behaviour differs between
backends, for example, whether finalisers are run if main/2 terminates
with an uncaught exception.
More information about the developers