# Mining on Students' Execution Logs and Repairing Compilation Errors Based on Deep Learning
## 3 Mining on Students' Execution Logs
code while preserving the differing parts, the resulting code retains the differential aspects of the error code and incorporates the correct code to cover the other parts. This approach ensures that the differences between the sample pairs are concentrated. Strategy 3, as shown in Algorithm 1, involves traversing the execution log \(L\) to find the program \(p\) that passes all test cases. Then, we iterate backward through the execution log, identifying all previously encountered code that failed to compile. For each such code, we calculate the difference with the correct sample, considering only one differing code block, with a span of no more than three lines. Any code meeting these conditions is identified as an error sample. The temporary variables \(pl\) and \(pt\) are used to store the programs encountered during the traversal process. The function \(GetPreProg(L,pl)\) retrieves the previous code record for program pl from the execution log L and assigns it to pt. Similarly, \(GetDiffBlock()\) and \(GetDiffLine()\) return the number of differing code blocks and the span of differing lines between the two programs. The line \(s=Match(pt,p)\) represents pairing the error program \(pt\) with the correct program \(p\), creating a repair example program pair \(s\). Finally, these program pairs are collected as the set of all program pairs, denoted as \(S\). The program pairs obtained through three different strategies are further screened by restricting the Levenshtein distance [21] between program pairs. This filtering process aims to remove examples with excessively large modifications, such as deleting an entire line. Finally, the program pairs undergo manual review to exclude any unreasonable repair examples. ``` Input: program execution logs \(L=\{P_{1}\),\(P_{2}\),...,\(P_{n}\) } Output: program pair set \(S=\{S_{1}\),\(S_{2}\),...,\(S_{n}\) }
1 for\(p\) in \(L\)do
2 ifPassAllTests(\(p\)) then
3\(pl=p\)
4 while\(pl\) is not \(P_{1}\)do
5\(pt=GetPreProg(L,pl)\)
6 ifnot Compiled(\(pt\)) then
7 ifGetDiffBlock(\(pt\),\(p\)) = 1 and GetDiffLine(\(pt\),\(p\)) \(\leq\) 3 then
8\(s=Match(pt,p)\)
9 add \(s\) to the set \(S\)
10 endif
11\(pl=pt\)
12 continue
13 else
14\(p=pt\)
15



across different programming tasks, with a higher number of errors and a certain level of repair complexity. ## 4 Error Program Generating

### Code Tokenization

The type names, delimiters, library functions, keywords, and special symbols in the C language are universal, so they were preserved as individual tokens. Specifically, the identifiers within the code were retained, including variable names, function names, and other symbols, as they played a significant role in shaping the semantics of the code. The newline characters were abstracted and represented as the token <newline> to preserve the line information of the program. The various constants in the code do not alter the code syntax, and the exact values of constants are not important for the model's learning task. Therefore, the numerical constants in the code were abstracted as a token <number>, the string constants were abstracted as a token <string>, and the character constants were abstracted as a token <char>. We considered all the code in a program as a token sequence, and we used a dictionary to map all the constants that appeared in the program code. This allowed us to restore the abstracted code by replacing the mapped tokens with their original constants. ### Rookie Simulator

The main workflow of the RS for program pairs generation is illustrated in Figure 2. Transformer models [22] have shown remarkable performance in natural language processing tasks, such as machine translation and speech recognition. The research conducted by [PERSON] et al. [23] demonstrates that trained neural machine translation models can acquire a significant number of distinct bug patterns and generate patches for bug fixes.