[m-dev.] promoted ROTDs

[Julien Fischer]

Hi Peter,

On Tue, 24 Jul 2018, Peter Wang wrote:

> Continuing on from
> https://github.com/Mercury-Language/mercury/issues/38#issuecomment-405848166
>
> The master branch seems to be in a good state right now (as it usually
> is), and the start of a month is as good a time as any, so:

No objection from me.

> Next week, can we start promoting a recent ROTD as a version of choice
> for users who can't or don't want to use the "Stable" release, but are
> wary of simply picking the latest ROTD in case they happen to hit a
> recently-introduced bug (however rare they may be)?
>
> A "preferred ROTD" should also be a useful target for packagers who need
> some guidance as to the version to package.
>
> Is there anything known to be wrong with rotd-2018-07-23?

The C# and Java backends don't bootcheck at the moment because they
generate code that goes into a loop (or goes really slowly).
(I think the minimum criterion for stable should be that all the
non-Erlang backends bootcheck.)

I started looking at this the other week, but haven't really had time
to continue; according to jdb the problem is occurring in
lexer.string_get_quoted_name; the last working rotd was 2018-05-29,
so presumably it was broken by one of the commits between that
and rotd-2018-06-03.

> I can do some more testing with that snapshot this week.
> I did some testing with a similar version on MinGW-w64 for the snprintf
> change. The only test that fails on Linux/x86_64 currently is
> tabled_typeclass in debug grades, but AFAIK it should not be blocking.

The failure of tabled_typeclass is not a block.

FWIW, I looked into this a bit and there are a few things going on with
that test case:

1. the number of tabled I/O actions exceeds the default limit for
printing them out.  (The declarative debugger has a way of changing this
limit, I couldn't find one for the procedural debugger, is there?)  [We
can workaround this by telling it to print out a known range of tabled
I/O actions but that's not very resiliant to future library changes.]

2. Various I/O primitives now contain memory addresses that need to be
filtered.

3. In debug grades, the final bit of of the output (after the last retry
command) is no longer printed; in decldebug grades (according to the
second expected output) it was never printed?

Julien.