Matches in reverse order when using basecode

[tsaglam]

From an email we received:

Some of the similar regions reported in my batch of 125 Python3 files are, for lack of a better word, backwards. For example, the first of the 3 in the report below, which was the 'worst' case, with 96% reported matching:

{"id1":"77.py",
 "id2":"1.py",
 "similarity":0.96,
 "matches":
   [{"file1":"77.py/77.py","file2":"1.py/1.py",
     "start1":292,"end1":241,"start2":287,"end2":237,"tokens":113},
    {"file1":"77.py/77.py","file2":"1.py/1.py",
     "start1":173,"end1":237,"start2":176,"end2":234,"tokens":62},
    {"file1":"77.py/77.py","file2":"1.py/1.py",
     "start1":436,"end1":436,"start2":413,"end2":413,"tokens":17}]
}

The resulting display in the viewer is, not surprisingly, confused:

  Submission 1	Submission 2
     File 1 	   File 2	Tokens

  77.py/77.py    1.py/1.py               | [Orange
  (292 - 241)   (287 - 237)  	 113     |  background]

  77.py/77.py    1.py/1.py               | [Green
  (173 - 237)   (176 - 234)	  62     |  background]
	
  77.py/77.py    1.py/1.py               | [Purple
  (436 - 436)   (413 - 413)	  17     |  background]

Clicking on the Green or Brown region entries scrolls to a correspondingly coloured region of code in the two file listing columns.

Clicking on the Orange region entry goes nowhere (on first attempt) or to the 'beginning' of the region, i.e. 292/287, but no lines are coloured Orange...

The user used a basecode submission, and the problem stems from the core, not the report viewer. However, whether it stems from the report generation or the comparison algorithm is unclear.

Contact @tsaglam if you want to reproduce this issue.

Sidenote: The symptoms are resolved by #971, but we should still find out where this comes from.

[TwoOfTwelve]

The error is cause by the python language module. The METHOD_END, ass well as CLASS_END, is reported with the line of the method (or class) begin. See JplagPython3Listener.java.

There is no direct connection to the base code feature, this happens if the last token of a match has an earlier line associated with it.

This problem should be fixed in: #280.

[tsaglam]

Addressed by #280.