Closed codykenb closed 7 years ago
BubbleDouble, BubbleLoops, Heap, Quick, Merge, Radix have been run without exception. Cocktail throws exception.
HuffmanCodeBook.java
doesn't parse:
Exception in thread “main” com.github.javaparser.ParseProblemException: (line 83,col 1) private is not allowed here.
(line 98,col 1) ‘private’ is not allowed here.
at com.github.javaparser.JavaParser.simplifiedParse(JavaParser.java:390)
at com.github.javaparser.JavaParser.parse(JavaParser.java:261)
at gin.SourceFile.<init>(SourceFile.java:23)
at gin.LocalSearch.<init>(LocalSearch.java:47)
at gin.LocalSearch.main(LocalSearch.java:33)'
Sure, I've yet to write a test case for it also, might be best to leave it out of master branch until it's ready?
OK, removed HuffmanCodeBook from the branch.
We still have two issues to resolve:
Regarding the exception, I have recreated and am investigating. I can't see why this is happening yet.
Could you expand on the out-of-bounds comments please? e.g. could you give an example of it failing?
Minimal example to recreate exception:
java gin.PatchAnalyser examples/locoGP/SortCocktail.java "| MOVE 16 -> 2:0 |"
Question about out-of-bounds is, should we check
parent.getChildNodes().size() > copy.destinationChildInBlock
when applying a patch (happens when only one child node, index is 1), or should we investigate why a patch is referencing an out of bounds index?
On 27 June 2017 at 14:15, drdrwhite notifications@github.com wrote:
We still have two issues to resolve:
- the exception from JavaParser when optimising SortCocktail.
- // TODO why are we going out-of-bounds here? <--- these comments
Regarding the exception, I have recreated and am investigating. I can't see why this is happening yet.
Could you expand on the out-of-bounds comments please? e.g. could you give an example of it failing?
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/drdrwhite/gin/pull/1#issuecomment-311354428, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0t4wBdYK6eW8NJgNbRdSyFwC7xzdrAks5sIQBigaJpZM4OFYtU .
A patch should never reference an out-of-bounds index, so there's a bug if that's happening. Perhaps that could explain the Exception problem, which is mystifying me so far.
DEL X = Delete statement X (you can see the way the statements are numbered by viewing the .statements output of PatchAnalyser)
MOVE or COPY X -> B:P = place X at Block B (you can see the block numbering via .blocks output from PatchAnalyser) and point P within the block.
"Point P" means "before statement P". There are special conditions to handle where there are no statements, i.e. the insertion is going into an empty block.
So I can confirm that the bug is actually caused by the delete operation and not the insertion.
I suspect some sort of issue with the cloning of the original statement here.
I think I've identified the problem. The .remove method in JavaParser's Node doesn't fully remove a node, and the AST becomes garbled.
Looking at a ModifierVisitor instead. This makes things much more complex that they should be from our POV. Not good.
I was hoping javaparser would give us a simple way to modify ast's, strange...
New minimal example: "DEL 16" is enough to cause the problem
New absolutely minimal example:
public class SortCocktail {
public static void example() {
boolean swapped;
swapped=false;
swapped=false;
}
}
with | DEL 3 |
Bug is clearly related to the sample expression statement appear twice in a block.
Example sort algorithms and tests added.