dataesr/scientific-paragraphs-categorization huggingface dataset:
A. Overall Framework As shown in Figure  2 , our approach is divided into three phases: 1) error inducing change (EIC) search, 2) code transformation extraction, and 3) recommendation ranking. We define an error-inducing change as a patch between two consecutive commits in which compiling a target backport file in the older commit version leads to a compile error. In the first phase, our approach gives as input a driver file that needs to be backported (input driver file), the Linux version to which we want to backport the driver file (target Linux version), and the git repository containing the change history between the target Linux version and the Linux version where the input driver file currently exists (version control system). The EIC search phase searches for two consecutive commits such that compiling the input driver file results in a compilation error in the older commit version, and no error in the newer commit version.
The goals of this phase are then two-fold: (1) Find the relevant change in the Linux kernel implementation that results in the input driver file not compiling in the target Linux version, (2) Find the changes that have been performed to existing Linux driver files to adapt them to this Linux kernel change. These adaptations are often committed at the same time as the relevant change to the underlying Linux kernel to prevent compilation errors. By reversing these adaptations, we can obtain hints on how to backport the input driver file. The EIC search phase has one processing component, namely the EIC Search Engine, which uses a binary search, starting with the target version, to jump through the change  The change between this commit version and the previous commit version is the EIC. For example, an EIC may include the removal of a function definition on which the driver relies.
Note that, in a more general case, there would be many EICs, however, we consider only cases where there is only one EIC. This one EIC may consist of many code changes between two consecutive commits that together render the code uncompilable. This EIC is output to the next phase. In the second phase, our approach takes as input the EIC obtained in the previous phase and the input driver file. This phase searches for changes in the EIC that are relevant to the line in the input driver file that the compiler has marked as erroneous (which we refer to as the error line), and generates candidate transformations to backport the input driver file. This phase has one processing component, namely the Code Transformation Extractor, which matches the error line with each deleted line in the EIC. It then generates candidate transformations based on how the deleted lines are changed to the corresponding added lines.
B. Error Inducing Change Search To find the EIC, an approach could be to linearize the git commit history and perform a binary search on it. However, linearizing the history in any way would break the parentchild relationship between two consecutive commits, which represent the actual change made when a developer commits to its local repository. For example, linearizing commit history by date would result in a series of commits that is ordered by date. However, two consecutive commits in this case may not represent the actual change since the two commits might be made by two developers in their own local repository and just accidentally happen at around the same time. Instead, we follow the approach presented in Algorithm 1. This algorithm takes as input the driver file DF to backport, the original Linux version origRev for which the driver file has been implemented and the target Linux version targetRev to which we want to backport the driver file.
The algorithm starts by retrieving the list revList of all the commit hashes that lie in the main trunk ranging from the original version to the target version (Line 2). To achieve this, we use the command: git log -pretty=%H -first-parent target version. original version. The option pretty=%H causes the result to be a list of commit hashes and the option -first-parent causes the log to follow only the first parent commit after a merge. Next, at Line 3, the algorithm passes this list to the function EIC Search, defined just below. EIC Search first performs a binary search of the commit hashes in revList to find a pair of consecutive commits, child and errP arent, such that the driver file does compile in the code resulting from child but does not compile in the code resulting from errP arent.
Next, if child is a merge commit (Line 6), then it must have some other parent in which the driver file does compile, because a merge commit does not itself change any code. In Line 7, EIC Search checks each parent commit other than errP arent until it finds one in which the driver file compiles, which is named okP arent. Based on our assumption that there is a single main developer from whom all code is initially obtained, errP arent and okP arent have a common ancestor, which is named ancestor in Line 8. This ancestor is obtained using the command: git mergebase errP arent okP arent. EIC Search then obtains the sequence of commit hashes from ancestor to okP arent. To achieve this, we use the command: git log -pretty=%Hfirst-parent ancestor. okP arent. On the other hand, if the binary search in Line 5 yields a node that commits a Alternatively to Algorithm 1, we could potentially have used git bisect  [9].
C. Code Transformation Extraction The Code Transformation Extractor processes the input driver file and the error inducing change (EIC) obtained by the previous phase. First, we compile the driver file in the target Linux version. By the definition of the backporting problem, we know that this will result in a compilation error. We then record the contents of the line containing the error. The goal is to find a change in the EIC that can be applied to the error line to remove the compiler error. The EIC can be viewed as a code difference (diff) composed of hunks, each of which is a contiguous sequence of lines corresponding to a sequence of line deletions, line additions, or both. Since we consider a backporting setting (changing code that works on a newer version to adapt it to an older version), to view a transformation in a natural way, we reverse the direction of a normal patch and thus a deleted line is a line in the newer code whereas an added line is a line in the older code.
A hunk containing only line additions or deletions does not correspond to a code change from which we can infer a transformation. Thus, we exclude such hunks from our analysis. We also ignore hunks that appear in non source-code files. The Code Transformation Extractor constructs an Abstract Syntax Tree (AST) for the error line and for each deleted line and each corresponding added line in the EIC. In general, a line in the source file might not represent a complete term in the C language. Since the complete source files are available, via git, our approach constructs an AST for the function containing each line, and then extracts from that the smallest sub-AST that contains all of the tokens of the considered line. The Code Transformation Extractor then tries to map the nodes of the AST of the error line to nodes of the AST of every deleted line, and the nodes of the AST of a deleted line to the nodes of the AST of every added line in the same hunk.
For each combination of error line, deleted line, and added line, the Code Transformation Extractor identifies a subtree in the error line's AST that matches a subtree in the deleted line's AST, which in turn matches a subtree in the added line's AST. For each matching, we transplant the matching subtree in the added line's AST to the error line's AST and adapt it with any necessary substitutions of identifier names. The adapted transplantation amounts to a transformation. A set of such possible transformations is output to the next phase. For each combination of error line, deleted line, and added line, Code Transformation Extractor follows Algorithm 2 to produce zero or one candidate transformations. This process involves three main steps: node mapping, extraction of matching subtrees, and subtree transplantation and subterm replacement.
A. Dataset Our dataset consists of 100 device driver files from Linux 2. 6. x versions. Using this dataset, we intend to simulate a backporting scenario. Since general automatic backporting is a new and hard problem, we limit the problem to make it more feasible to solve. Specifically, we select driver files and starting and target versions according to the following criteria. 1) The driver file should have only one changed line of source code between two consecutive Linux versions, e. g. , Linux versions 2. 6. 1 and 2. 6. 2. We focus on oneline changes to limit the difficulty of making the new code work in the older version. We consider that one-line changes represents a reasonable difficulty for an initial attempt at automatic backporting. 2) Following the first criteria, the driver file will be present in two versions: the old and new versions.
We should be able to compile the old and new versions of the driver file in their corresponding Linux kernel versions. 3) When we compile the new version of the driver file within the old version of the Linux kernel, a compilation error should occur. Our goal is to modify the a copy of the new driver to fix this compilation error. Table  I  shows the distribution of the 100 Linux driver files selected according to the above criteria. The error inducing change search phase is intended to find a change that contains an example from which we can learn how to backport the code. However, as noted above, all such examples may occur in earlier commits. To address this issue, we would need to extend our search to relevant commits that occurred prior to the error inducing change. The error transformation extraction phase is intended to learn a potential candidate transformation from a change between a pair of added and deleted lines.
And even if test cases existed for the new driver, they might not be directly usable in the older version. Thus, we would need to to backport the test cases and check whether their backport is correct, repeating the same problem. Regarding the transformation results, although some may look simple, it is not trivial for developers to perform them. Many people have contributed to the Linux kernel, and around 70,000 commits were made on the Linux kernel in 2015 alone. A developer is unlikely to be knowledgable about the large number of diverse changes made by others. Moreover, stateof-the-art works in automated bug fixing also can only fix a small number of bugs that span one or a few lines of code  [16] ,  [19] , showing the level of difficulty of automatically inferring correct fix for even one line of code.
Although bug fixing and backporting are two different problems, both involve transforming a broken piece of code to another that works. Last but not least, our approach currently targets backports that require only a one-line change. We have evaluated it on a simulation where we backport a driver file across two consecutive Linux versions. Analyzing a diff of two consecutive Linux versions, for all versions between 2. 6. 11 to 3. 13. 3, we found 944 driver files having a one line change that affects the driver functionality, meaning that using the newer version of the driver in the previous version of Linux will not work. Thus, even though one-line change is very limited, it still covers quite a number of potential backporting situations. Another limitation in our evaluation is that we assume that syntactic correctness equals semantic correctness.
J. Threats to Validity Possible threats to validity include threats to construct validity, to internal validity, and to external validity. Threats to Construct Validity. These threats refer to the suitability of our evaluation measures. We make use of accuracy and Hit@N as the effectiveness measures of our approach. These measures have been used in past studies and thus we believe the threats are minimal. Threats to Internal Validity. These threats correspond to experiment errors. To reduce the likelihood of this threat, we have checked the implementation of our approach multiple times. Still, there may be errors that we missed. Threats to External Validity. These threats refer to the generalizability of our experimental results. We have only investigated 100 Linux device driver files and backporting cases that involve two successive Linux versions.
V. RELATED WORK We now present related work on identifying and analyzing changes, mining change rules, and automatic program repair. Due to page limitations, our survey is by no means complete. Identifying and Analyzing Changes. Many studies focus on identifying and analyzing changes between two code versions. For example, Neamtiu et al. [23]  use partial abstract syntax tree matching to compare the source code of different C program versions. Horwitz et al. [10]  focus on identifying semantic changes in programs. Fluri et al. [5]  track the coevolution of comments and source code over multiple program versions, leveraging Evolizer  [7]  and ChangeDistiller  [6]  for extracting fine-grained source code changes between program versions. Marinescu et al. [20]  present Covrig, an infrastructure that collects static and dynamic software metrics when running different program versions, to study the coevolution of source code and test cases.
Zaidman et al. [30]  examine the co-evolution of source code and tests, inferring the development style employed by a number of Java projects. Our work differs from those above in that, rather than just identifying and analyzing differences, we automatically suggest transformations that can change code in a newer version to be compatible with an older version. We thus need to identify which changes can help us to learn the correct transformation, as implemented by our error inducing change search phase, and to learn and rank these candidate transformations, as implemented by our code transformation extraction and recommendation ranking phases. Mining Change Rules. Wu et al. [29]  propose an approach to mine method call change rules between two versions of a Java program. They combine call dependency and text similarity analyses to extract method change rules.
Similarly, Meng et al. [22]  extract method change rules between two versions of a Java program. However, rather that considering only one big change between two versions of a program, they consider all changes between two consecutive commits that are located in the change history between the two versions of the program. This allows them to analyze changes in a finer detail and enables them to mine chains of method changes. These works deal with a forward porting problem, which involves porting function calls to use a newer version of a library in Java programming language. We address a backporting problem, which is the task of porting a new version of some code (in our case, drivers) to work with an older version of a system (in our case, the Linux kernel). Thus, backporting can be seen as reverse forward porting.
Le Goues et al. propose GenProg, the first search-based automated patch generator  [17] ,  [18]. GenProg uses genetic programming to generate a large number of possible patch candidates. A valid patch candidate can be found by iterating through a pool of generated candidates and searching for the one that passes all the test cases of a given regression test suite. On a suite of 105 real-world bugs GenProg was able to create plausible fixes (i. e. , fixes that pass all test cases) for 55 of them  [17]. However, recently Qi et al. have shown that out of the 55 plausible fixes, only 2 are correct fixes  [26]. Kim et al. propose Pattern-based Automatic program Repair (PAR), that applies patterns learned from existing humanwritten patches to fix bugs  [11]. Ten fix templates learned from more than 60,000 human-written patches were created and applied to generate patches for buggy programs.
The results of their experiment show that PAR can automatically generate patches that are comparable to human-written patches. Weimer et al. [28]  propose an adaptive search strategy that uses a cost model for search-based automated program repair, to reduce the cost of validating candidate patches. The cost estimation allows the model to suggest an appropriate strategy for evaluating repair candidates, e. g. , which candidates should be evaluated first and how the test cases should be prioritized to allow an invalid candidate to be recognized as soon as possible. Their experimental results show that adaptive search finds repairs more quickly than GenProg. Most recently, Long and Rinard and Le et al. propose approaches that learn from historical bug fixes to guide a GenProg-style automated program repair technique to correctly fix bugs with a higher success rate  [16] ,  [19].
Mechtaev et al. propose Angelix that can fix bugs using semantics analysis and program synthesis  [21]. Subsequently,  Le et al. propose to use syntax-guided synthesis  [15]  and deductive verification  [13]  for program repair. However, even state-ofthe-art approaches can only fix a small number of bugs whose fixes span one or a few lines of code. Automatic program repair deals with the problem of fixing general bugs, where a bug is usually considered fixed when a program passes all test cases. Our backporting problem is related to automatic program repair in that we need to fix the error line when we compile a driver in the older Linux version. However, we do not have test cases to evaluate whether the fix is correct. Thus, we cast the problem as fix recommendation (i. e. , code change recommendation) rather than a fully automatic fix.
VI. CONCLUSION AND FUTURE WORK In this paper, we have presented a recommendation system that generates a ranked list of candidate transformations for (semi-)automatic backporting of Linux device drivers. Our approach consists of three phases. First, we search for a change that can give us a clue on how to fix the error when we backport a driver to an older Linux version. Then, we extract code transformation candidates that we may apply to fix the error. Finally, we rank the transformation candidates. Our simulated backporting experiment on 100 Linux device drivers shows that our approach can extract the correct transformation for 68% of the device drivers. Among the device drivers having a correct transformation in the recommendation list, our ranking approach ranks first 85. 3% of the correct transformations.
We then illustrate some successes and limitations of our approach. In future work, we plan to improve our search algorithm by extending our search beyond the error inducing change, especially to older changes involving the modified data structure or function in the error inducing change. We plan to extend our code transformation extraction algorithm to be able to learn from many deleted-added line pairs. We also plan to consider a more general backporting scenario, such as multi line and multi file backporting. We also plan to explore possibility of lightweight testing for improving the correctness of the backported device drivers. Finally, we plan to experiment on a bigger dataset to ensure the generalizability of our approach.
Since this paper involves the analysis of radio transients across a period of several years of initial detector data, multiple science runs of these interferometers are used. Data analyzed in this paper are drawn from summer 2007, coincident with LIGO's fifth and Virgo's first science run, as well as late 2009, coincident with LIGO's sixth and Virgo's third science run. FRB candidates discussed in this paper are coincident with GEO 600 Astrowatch data ranging from 2011 to 2013, and in some cases Virgo's fourth science run, which took place in summer 2011. See  [4]  for a comparison of sensitivities for these instruments from 2007 to 2014. The LIGO-Virgo network has undergone extensive upgrades to second-generation instruments, and during the first Advanced LIGO observation run made the first direct detection of a gravitational-wave transient  [16].
A. Green Bank single pulse analysis data The Robert C. Byrd Green Bank Telescope is the world's largest fully steerable single-dish radio telescope. In the summer of 2007 a drift-scan pulsar survey was conducted in a band of 350±25 MHz  [22]. This time frame was during Initial LIGO's fifth science run and Initial Virgo's first science run. In addition to the identification of continuously observable pulsars, a "single-pulse" archival search was performed to look for transient emission of millisecond-scale duration radio pulses. The drift-scan team provided LIGO/Virgo with 33 of these observed single-pulse triggers, ten of which were confirmed to originate from sources with repeated emission through followup observations, thus most likely originating from a pulsar or RRAT. Some of the triggers exhibited only a single radio pulse, while others show several pulses within a 2 min window, but in order to be considered a viable astrophysical signal, all pulses were required to exhibit the 1/f 2 dispersion behavior expected as a result of dispersion in the interstellar medium.
The FRBs of interest for a gravitational-wave search (i. e. omitting bursts from 2001, prior to the construction of sensitive GW interferometers) have observed fluences ranging from 0. 55 to 7. 3 Jy ms, observed width from 0. 64 to 15. 6 ms, and dispersion measures suggesting cosmological origin, ranging from 563 to 1629 pc cm -3  [48]. While most of these FRBs did not occur during LIGO/Virgo science runs, we performed a check in the Virgo science run data and GEO 600 Astrowatch data when available. Given the difference in the dispersion measure and other properties, the FRBs are most likely primarily a distinct class of sources compared to the RRAT-like observations in the previous section. Current evidence points to an astrophysical origin, especially as known perytons exhibit properties distinct from FRBs  [51].
A. Procedure The search for gravitational waves in coincidence with short radio transients was conducted using the X-PIPELINE analysis package  [63]. This software has been used for a number of GW searches in coincidence with astrophysical triggers. The analysis procedure for this search was modeled directly after conceptually similar searches for GWs in coincidence with gamma-ray bursts  [6, 11] , but the parameters were modified to account for the particular types of GW sources under consideration. Similar adjustments between GRB and radio transient searches can be used to design radio transient searches in advanced interferometers. For each radio trigger analyzed, we use X-PIPELINE to conduct a coherent search for a GW signal consistent with the location and time of the radio signal. The physical locations of the individual GW interferometers in the network and the antenna patterns based on their orientations are used to reject potential GW signals that are not consistent with the radio signal's sky location and only signals within ±2 minutes of the radio trigger are considered.
B. Parkes Telescope FRBs We examined a list of 14 FRBs  [48]  from Parkes, occurring as early as 2001 but primarily concentrated within the last five years. While none of the event times corresponded to science runs for Hanford or Livingston, eight of the FRBs corresponded to times when GEO 600 Astrowatch data were available and two of these also corresponded to data from Initial Virgo's fourth science run. After omitting two of these FRBs for which GEO data were too nonstationary to yield a quality GW analysis, we searched for GWs in coincidence with a total of six Parkes FRBs. Analysis parameters were kept as similar as feasible to the Green Bank drift-scan analysis described previously. However, the upper end of the frequency range was lowered to 1764 Hz due to the range over which GEO data are calibrated  [4]  and the higher frequency damped sinusoids were left out of the set of GW morphologies simulated.