search

squaresLab / MultiEdit_Experiments

What are multiedit bugs?
2 stars 0 forks source link

Incompatibility of multi-module Bears bugs. #25

Open zhenyudg opened 4 years ago

zhenyudg commented 4 years ago

Some multi-module projects are removed because they are not compatible with the automation tools used in this paper. Which tools do you refer to?

zhenyudg commented 4 years ago

We had previously written internal software tools that operate on single-module Maven projects.

zhenyudg commented 4 years ago

For an ICSE resubmission, how difficult would it be to support multi-module projects? I believe that @lvyiwei1 made the decision to exclude multi-module bugs, so he may have some insights here.

lvyiwei1 commented 4 years ago

Um, I can only give some insight about the fitness experiment: the whole experiment pipeline is designed based on standard single-module maven project structure, so including multi-module bugs would require some serious re-working. Also, since I actually use Genprog4java's testing functionality combined with Fake-JUnit to do count passing test classes/methods/assertions, I have to figure out how to make GP4J work with multi-module projects too (the script I use to run GP4J on Bears was an adaptation of the GenProgScripts repo written by Mau years ago for D4j, which has no mult-module projects).

lvyiwei1 commented 4 years ago

To include the multi-module bugs, we have 2 options: 1. make the current code work for multi-module bugs (most likely that means). This will require some serious dev work and debugging, since the current experiment pipeline contains a LOT of code and scripts reused from older repos that fits to D4J-style single-module projects. 2. Maybe we can ditch the additional modules and only do experiment on the module that contains the bug? that will also require some engineering too since the bug info that comes with the Bears Dataset applies to the whole project instead of specific modules. Also, that's assuming modules are completely independent from each other -- which may not always be the case

zhenyudg commented 4 years ago

Okay, perhaps this language might work:

We reused code from genprog4java's text execution harness, which assumes a single-module project structure.