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

Addressing a variable that does not exist causes confusion during a debug session #1855

Open
brandy125 opened this issue Jul 12, 2024 · 5 comments

Comments

@brandy125
Copy link

When addressing any not existing variable during debugging of a program causes confusion.
The only way to continue is to create that variable with any contents.
Any way to resolve this?

pro var
	stop
	print,'ok'
end
GDL> var
% Compiled module: VAR.
% Stop encountered: VAR                  3 var.pro
GDL> print,variablethatdoesnotexist
% PRINT: Variable is undefined: VARIABLETHATDOESNOTEXIST
% Execution halted at: VAR                  3 var.pro
%                      $MAIN$          
GDL> .c
% PRINT: Variable is undefined: VARIABLETHATDOESNOTEXIST
% Execution halted at: VAR                  3 var.pro
%                      $MAIN$          
GDL> 
@ChunkyPanda03
Copy link
Contributor

I just tested this on idl 6.3 and I can confirm that this is supposed to continue

IDL> var
% Stop encountered: VAR                 2  var.pro
IDL> print,variablethatdoesnotexist
% PRINT: Variable is undefined: VARIABLETHATDOESNOTEXIST.
% Execution halted at: VAR                 2  var.pro
%                      $MAIN$          
IDL> .c
ok

interesting idl states that it stopped on line 2 but GDL reports stopping on line 3 is this related?
note .c = .continue I didn't know this before

@GillesDuvert
Copy link
Contributor

Yes gdl is always "at the next line" . Dunno if this is unavoidable or if it could be patched. I think when trapped in an unvoluntary error loop as you report, one can do a stepover .so and then continue as usual.

@GillesDuvert
Copy link
Contributor

Btw thanks for reporting, even if this issue will likely be not worked on soon.

@brandy125
Copy link
Author

Today I saw that there is another problem related to this when the procedure name was misspelled like "prin" instead of "print":
Screenshot_2024-07-20 12 36 44_ugCoRs

This can be overcome by a ".skip" but it is boring. Imagine a long debug session where a "wrong" ".skip" could cause confusion in the debug session

@brandy125
Copy link
Author

Any updates here?
I am having problems every day when I misspell a variable. Sometimes very deep in a debugging session. It is confusing if I need to write .skip to a not existing command line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants