Stefano Ferri wrote:
> Error messages associated to some commands are clearly understandable, but
> often aren't very useful, in the sense they don't make possible to rapidly find
> where error is located.
> In example, matrix_size say this:
>
> The first argument of the function matrix_size must be a matrix
> -- an error. To debug this try debugmode(true);
>
> that is perfectly clear if an user is typing commands in the shell, but
> imagine you are working with a 1000 lines .mac file containing 20 or 30
> matrix_size commands (that's my situation). When such an error is displayed,
> it is hard to find to which matrix_size command it is referred.
> It could be useful if also line number was displayed, in example:
>
> Error at line 35 of file.mac
> The first argument of the function matrix_size must be a matrix
> -- an error. To debug this try debugmode(true);
>
> Some commands already do this, while matrix_size, addow, and others do not.
> What do you think?
>
>
There are certainly many ways of improving error messages. A possibly
useful model is one used by Mathematica.
Some ideas: the error messages have identifiers and are registered in a
grand list of all possible error messages.
Also, a message may be abbreviated on display with a <<more>> indication.
If the same warning message is
repeated too many times, just keep count and don't write it all out
(Mathematica does a lot of this).
Some Macsyma/Maxima error messages were set up when it was much harder
to do a good job, and
people felt more protective of memory. They could be revised to
mention the data causing the error. e.g. "the first argument of the
function matrix_size is XXXX, which is
not a matrix but an object of type YYYY."
> Stefano
>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>