You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Related to issue #895, GAP.evalstr also seems to hide error messages in some cases. It works if the error is reported by one of the evaluated expressions:
julia> GAP.evalstr("1/0")
ERROR: Error thrown by GAP: Error, Rational operations: <divisor> must not be zero
not in any function at stream:1
But now put 1/0; into a file, say foo.g, and let GAP's Read read that:
julia> GAP.evalstr("Read(\"foo.g\");")
julia>
Then no error is reported. Because our error handler eats up the error message; and the hack in evalstr to print the error anyway is not triggered in this case, because Read itself here look as if it "succeeded" based on the information available to evalstr.
One way to address this might be to remove the if any(x->x[1] == false, res) check from evalstr. But I am not sure if this might not have other, undesired consequences? In any case, it seems we should add more tests for evalstr to lock down the desired behavior...
BTW the above issue can be completely avoided by using GAP.Globals.Read(g"foo.g").
The text was updated successfully, but these errors were encountered:
Oh of course my hack doesn't work in general because it always calls error, which I guess is not what we want 😂. But my point more was that the error is there, we just need to detect it properly and print it.
When I put the command 1/0; into the file foo.g and call GAP.evalstr_ex("Read(\"foo.g\");") then I get GAP: [ [ true,, false,, "" ] ]. The true means that the statement was successful.
If I understand this right then the problem is that libgap's GAP_EvalString does not notice the error.
fingolfin
changed the title
GAP.evalstr hides indirect error messages of GAP.evalstr hides indirect error messages
Jun 19, 2023
Here's what I would suggest we try (even if it is not perfect): modify the check in evalstr which currently does if any(x->x[1] == false, res) and instead just check if the error output buffer is non-empty.
Related to issue #895,
GAP.evalstr
also seems to hide error messages in some cases. It works if the error is reported by one of the evaluated expressions:But now put
1/0;
into a file, sayfoo.g
, and let GAP'sRead
read that:Then no error is reported. Because our error handler eats up the error message; and the hack in
evalstr
to print the error anyway is not triggered in this case, becauseRead
itself here look as if it "succeeded" based on the information available toevalstr
.One way to address this might be to remove the
if any(x->x[1] == false, res)
check fromevalstr
. But I am not sure if this might not have other, undesired consequences? In any case, it seems we should add more tests forevalstr
to lock down the desired behavior...BTW the above issue can be completely avoided by using
GAP.Globals.Read(g"foo.g")
.The text was updated successfully, but these errors were encountered: