[m-rev.] for post-commit review: fix mantis bug 361

Julien Fischer jfischer at opturion.com
Tue Sep 16 14:57:18 AEST 2014

Hi Zoltan,

On Tue, 16 Sep 2014, Zoltan Somogyi wrote:

> On Tue, 16 Sep 2014 13:33:31 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
>> That looks ok otherwise.  Thanks for looking into that so promptly.
> You are welcome.
> About 360: the feature is not compatible with our current
> implementation.

I'd worked that out based on the error message ;-)

> The attached DIFF is a proposal for documenting the restriction.
> However, it seems that many grade components are currently quite
> underdocumented, especially in their requirements. I saw no mention of
> the fact that e.g. debugging is only available in llds grades, so I
> saw no slot into which I could put that same restriction for .mm
> grades. (Internally, the system uses mmsc or mmos, but users can use
> plain mm as the grade component for minimal model.)
> We could put an explanation of our current rules for which
> grade components are incompatible with which other grade
> components into the affected section of the user manual.
> It could be useful for users, or it could could overwhelm them
> with too much detail.

It's likely to do both for different sets of users, I don't think
there is any avoiding that.  What we can try to do is ensure that
users only need to deal with all the details when they actually
have to.

> Any opinions?

These things need to be documented *somewhere*.

More generally, I think the are quite a few problems with grade
components.  Of the top of my head:

(1) Too many experimental or not-useful grade components are currently
documented at the user-level, for example agc, hl, il, hgc, jump, fast.

(2) The compiler currently does not do a good job of reporting
incompatible grade components in many cases.  For example, I accidently
tried to compile a program in the grade hlc.gc.mm recently and while I
did get a runtime error from the program, the compiler probably
shouldn't have ever let met get that far.

(3) The grade component options, --debug, --trailing, --parallism, etc,
seem to be a great source of confusion for users.  They seem to expect
that, for example, --debug will prepare their program for debugging;
what it in fact does is add the .debug component to the current grade.
On systems where the default grade is hlc.gc, this results in
compilation errors when the user does 'mmc --debug foo.m'.

I think we should consider renaming all the existing grade component
options and have options like --debug mean something like "choose the
best available grade that supports debugging".


More information about the reviews mailing list