Misleading red error arrow in Workbench

Bugs
1

Expected behavior

If my script fails, the red arrow should point to the offending line. Specifically, if I call a function included from a module, and that throws an exception as a result of a bad parameter I gave it, the arrow should point to where I called the library function.

Actual behavior

Workbench finds another line number somewhere in the traceback and points the red arrow at an entirely innocent line in my script.

Steps to reproduce the behavior

Try the following pair of scripts:
mylib.py:

def myfunc(x):
    if(x<0):
        raise ValueError("x should be positive")
    else:
        return x*2.0

mylib_user.py:

import mylib

print ("this line is innocent")

# the one below calls the library
z=mylib.myfunc(-2.0)
print (z)

Platforms affected

Mantid 4.1 (Workbench), demonstrated on Windows

2

There’s a related problem. The line numbers in the traceback which refer to the module are wrong. In the simple example above, it gives line 5 (actually the “return” statement) although in this case correctly extracts the “raise” statment for printing. In other cases I’ve seen line numbers far in excess of the size of the module file which makes debugging impossible! On investigation it might be as if the module file was imported double-spaced, an error on line N being reported as (approximately) 2N-1.
Running the module script directly, with a simple test call appended to the end, gives correct traceback line numbers for the same lines but incorrectly undoes the double spacing and prints the text of the wrong line.

3

Thank you for your useful test to demonstrate this error. Part of me wonders is the red arrow stopping on the number-th line that is readable (not blank or commented out) so while it should stop on the 6th line (3rd readable line) it stops on the 3rd incorrectly.

An issue has been created for this: Progress arrow fails on wrong line · Issue #27245 · mantidproject/mantid · GitHub

4

Thanks for raising this as an issue. I did try adding/replacing lines above the “raise” one with comments, blank lines, executable statements, loops with indented lines or continuation lines of the statement above, but it seems that the 2N+1 holds for short scripts. In the longer one where I originally saw the error, this “estimate” was off by about 10 lines.

5

A related feature. If I create a script in the Workbench editor and then open it in Notepad or Notepad++ it appears double spaced! If I take an existing script (developed in Mantid Plot) and add to it in Workbench, all the new parts I’ve typed are double spaced in Notepad. On inspection, the new lines end with “CR CR LF”! The standard block of import statements put at the top of a new tab have ordinary “CR LF” line endings and appear single spaced in Notepad. So maybe the Python interpreter, like Notepad, really does see the file as double spaced?