[m-rev.] the grade library is ready for review

[Paul Bone]

On Tue, Apr 05, 2016 at 02:00:24PM +1000, Zoltan Somogyi wrote:
> 
> 
> On Tue, 5 Apr 2016 12:26:57 +1000, Paul Bone <paul at bone.id.au> wrote:
> > Cool.  Can (should?) the grade library distinguish between sensible grades
> > (for users) / grades that work / grades that do not work?
> 
> The grade library must handle all valid grades, since it will be used by
> developers as well as users.
> 
> As for distinguishing the developer-only and intended-for-users grades:
> what distinction did you have in mind? If you intend to protect users from
> grades that e.g. combine debugging and deep profiling, there is no need.
> Since the defaults are no debugging and no deep profiling, the only time
> the solver will generate a grade that combines debugging and deep profiling
> is when the user has *asked* for both.

Yeah, in the case of debugging and profiling this is not a concern.  What I
was thinking (and I didn't think very far) Was something like weak
constraints that the system would be willing to break in order to find a
solution.

A simpler solution might be that if backend=llds and thread_safe=thread_safe
get selected, then the preferences for stack segments get re-arranged to
make a segmented stack preferred.

Since stack segments will become the default anyway disregard this, unless
someone has a more relevant motivating example.  In any case, this is only a
nice-to-have thing.  I would generally prefer not to over-engineering the
constraint solver/grade library.

> > These preferences make sense, including the version parameter.  We may want to
> > tweak the order of the variables if constraints between them are added or other
> > preferences change.  If we decide to make thread safety the default then it
> > needs to be moved ahead of stack segments, so that we don't commit to a fixed
> > size stack before labeling thread safety.
> 
> Since we agreed that we will make stack segments the default, the above
> scenario won't happen. I think we should make that switch soon after
> we switch over to the compiler using the grade library.
>
> > Hrm, this is a form of weak constraint: thread safety in the llds backend
> > weakly implies a segmented stack.  It's still okay to use fixed size stacks,
> > but a segmented one improves performance.
> 
> True, but since (due to robustness concerns) we already prefer a segmented stack,
> it is not a *conditional* constraint.

Ah cool.  In that case disregard my weak constraints idea.

> > I don't see
> > > any situation whatever in which printing them all would help the user, and
> > > without that, I don't see why the grade library should ever compute them all.
> > 
> > Depends how the grade library is used to choose a grade relative to the
> > installed grades.  If the installed grades are used to setup the constraint
> > problem (need only first solution) or filter the results of the problem (may
> > need all solutions).
> 
> I don't understand the second sentence, since it is incomplete.

If the constraint problem is setup with information about the installed
grades, then the first solution is fine and the solver only needs to return
one solution.  If instead the solver does not know about the installed
grades, its first solution may not be one of the installed grades.  It may
need to return all the solutions.

The first option seems simpler.

> > While writing this e-mail I thought of other instances of this kind of
> > thing:
> > 
> >     The user wants "debugging", but doesn't care which debugger is used.
> >     This relieves the user from needing to know that different debuggers are
> >     available (to some extent).
> > 
> >         debugging -> debug=debug \/ debug=decldebug \/ debug=ssdebug
> 
> Yes, we discussed that a few months ago. I agree that the above is a
> good idea *if* the source-to-source debugger is ready for users. I don't use it
> myself, but the last time the question came up, the answer was that it wasn't
> ready.

Okay.

> >     Of course the user still needs to know which debugger or profiler they
> >     got so that they can invoke it.
> 
> Yep. The question is: *when* should we tell them? Telling them every time
> the grade library chooses for them will get old *really* fast. I don't think we
> can make a good decision on this without trying out some algorithms and seeing
> how we like them.

mmm..  This is difficult, if we tried to hide the differences between the
various debuggers or profilers too much.  Those differences would eventually
become important, the abstraction would leak, surprising the user at a more
irritating time.


-- 
Paul Bone