Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error message <corrupted statement> when using [i,j] with invalid indices #2656

Closed
ssiccha opened this issue Jul 20, 2018 · 4 comments · Fixed by #2520
Closed

Error message <corrupted statement> when using [i,j] with invalid indices #2656

ssiccha opened this issue Jul 20, 2018 · 4 comments · Fixed by #2520
Assignees
Labels
kind: bug Issues describing general bugs, and PRs fixing them

Comments

@ssiccha
Copy link
Contributor

ssiccha commented Jul 20, 2018

In GAP 4.9.1 and in the current master branch I get:

gap> l := [[1]];
[ [ 1 ] ]
gap> f := {} -> l[2,1];
function(  ) ... end
gap> f();
Error, List Element: <list>[2] must have an assigned value in
  return m[i][j]; at /home/sergio/projects/gap-master/lib/matrix.gi:30 called from 
<corrupted statement>  called from
<function "f">( <arguments> )
 called from read-eval loop at *stdin*:3
you can 'return;' after assigning a value
brk> 

Is it worth the effort to let GAP show the line from where the offending l[2,1] was called?

@stevelinton
Copy link
Contributor

It's easy to fix this problem -- Just add SET_BRK_CALL_TO( expr) in EvalElm2List much as it appears in ElmList, and it seems to work correctly.

However, when I starting looking through related functions, though like EvalElmsList and EvalAss2List I become confused about where SET_BRK_CURR_STAT and SET_BRK_CALL_TO ought to appear and why. Does anyone understand the rules for these? If so, any chance of writing something about them (perhaps as comments vars.h where they are defined?

@ChrisJefferson
Copy link
Contributor

I did look at this at some point, and got confused. I think @fingolfin was looking too, not sure how confused he got. This might require a sit down at a gap days to decide what we want, once and for all :)

@stevelinton
Copy link
Contributor

It looks like PR #2520 is WIP on tackling this.

@fingolfin fingolfin added the kind: bug Issues describing general bugs, and PRs fixing them label Jul 30, 2018
@fingolfin fingolfin self-assigned this Jul 30, 2018
@fingolfin
Copy link
Member

I'll take care of this as part of PR #2520 (or some successor PR)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: bug Issues describing general bugs, and PRs fixing them
Projects
None yet
4 participants