The reviewed record of science sign in
Pith

arxiv: 2607.00623 · v1 · pith:VZD3ZN6L · submitted 2026-07-01 · cs.SE

SchedCheck: Schedule-Robustness Analysis for Event-Driven Block Programs

Yuan Si , Jialu Zhang This is my paper

Reviewed by Pith T0 review T1 audit T2 compute T3 formal T4 kernel 2026-07-02 08:49 UTCgrok-4.3pith:VZD3ZN6Lrecord.jsonopen to challenge →

classification cs.SE
keywords schedule robustnessblock-based programmingScratchconcurrencyevent-driven executionpartial-order reductiondependence analysisstudent projects
0
0 comments X

The pith

Over one-fifth of real Scratch student projects produce different observable results under different script execution orders that the language leaves open.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper shows that block-based programs assembled from sprites and scripts run as concurrent threads whose relative order is not fixed by the source, so the same blocks can yield different outcomes when the virtual machine permutes the initial executable-target list. It formalizes the schedule space as those permutations and defines schedule-robustness relative to a lattice of observation lenses over a fixed horizon. A dependence model collapses the factorial space into equivalence classes so that one representative schedule per class suffices; an oracle on small projects confirms the reduction recovers every realizable outcome. SchedCheck implements the method on the production Scratch VM and reports that at least 21 percent of 224 concurrent student projects are schedule-sensitive at the grading lens, with the rate replicated at 17.6 percent on a random public-project sample.

Core claim

Schedule-robustness analysis for event-driven block programs reduces to checking one schedule per dependence-equivalence class of the initial executable-target order; the dependence model is validated by an independent oracle on enumerable projects, and the resulting tool detects every injected schedule fault on hand-built pairs and a 32-fault benchmark while reporting clean on logic-fault controls.

What carries the argument

Dependence-equivalence class reduction over permutations of the initial executable-target order, which partitions the schedule space so one representative stands in for each class.

If this is right

  • Editing, saving, or remixing a project can silently alter its observable behavior by changing layer order without touching any blocks.
  • The same parametric method applies unchanged to any cooperative event-loop execution model.
  • All 32 spec-defined schedule faults across four classes are detected and localized; logic faults produce no false schedule alarms.
  • At least 17.6 percent of public projects exhibit schedule sensitivity at the grading lens.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Remix-based development can turn a robust animation into a non-robust one without any block changes, creating a hidden source of student confusion.
  • The same dependence model could be used to warn authors at edit time when a broadcast or clone addition introduces new schedule classes.
  • Grading rubrics that treat observable output as definitive would systematically penalize schedule-sensitive submissions even when the blocks are correct.

Load-bearing premise

The dependence model records every pair of scripts whose relative ordering can change observable state, with no missed cross-sprite or broadcast edges that would separate two schedules into different classes.

What would settle it

A concrete project in which two schedules placed in the same dependence class by the model nevertheless produce different observable outputs under the grading lens.

Figures

Figures reproduced from arXiv: 2607.00623 by Jialu Zhang, Yuan Si.

Figure 1
Figure 1. Figure 1: The ball-and-paddle project. Under (Ball, Paddle) the ball moves before the test and caught becomes yes; under (Paddle, Ball) the test runs first and it becomes no. The orders differ only by sprite layout, which a remix changes. II. BACKGROUND A. The Scratch execution model A Scratch project [6], [7] is a set of targets, one stage and a number of sprites. Each target owns scripts, and each script begins wi… view at source ↗
read the original abstract

Block-based languages such as Scratch let beginners assemble interactive programs from sprites and scripts. These programs are concurrent in practice: green-flag scripts, broadcasts, and clones run as cooperatively scheduled threads over shared sprite and stage state, and their authors never write a thread. We show that such programs contain schedule-sensitive behaviors whose observable result depends on an execution order the language leaves open. Editing, saving, or remixing a project can produce a copy with the same blocks but a different layer order, changing the order the virtual machine starts scripts. We formalize the schedule space a Scratch virtual machine can realize as the permutations of the initial executable-target order, and define schedule-robustness against a lattice of observation lenses over a fixed horizon. A partial-order exploration runs one schedule per dependence-equivalence class, and on projects small enough to enumerate, an independent oracle confirms it recovers every realizable outcome. On larger projects, representatives stand in for the factorial under the validated dependence model. SchedCheck implements this on the production Scratch VM. Across 224 real student projects, at least 21% of the concurrent ones are schedule-sensitive at the grading lens, and a uniform random sample of public projects replicates the rate at 17.6%, with two real remixes of a deployed animation arranging its letters differently. On hand-built fault pairs and a generated benchmark of 32 spec-defined faults across four classes, the tool detects and localizes every schedule fault, with a logic-fault control reporting clean. The oracle exposed four unsoundness gaps in the dependence model, all repaired. The method is parametric in the execution model, instantiating unchanged on a second cooperative event loop.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper introduces SchedCheck for analyzing schedule-robustness in Scratch block programs. It formalizes the realizable schedule space as permutations of the initial executable-target order under the VM's cooperative scheduling, defines robustness relative to observation lenses over a fixed horizon, and reduces the space via a dependence model that groups schedules into equivalence classes. A partial-order exploration is implemented on the production Scratch VM; on small projects an independent oracle confirms that one representative per class recovers all observable outcomes. On 224 student projects the tool reports that at least 21% of concurrent programs are schedule-sensitive at the grading lens; a uniform random sample of public projects yields 17.6%. The approach detects and localizes all injected schedule faults on hand-built and generated benchmarks while reporting clean on a logic-fault control set. The method is parametric and is shown to instantiate on a second cooperative event loop.

Significance. If the dependence model is sound for the evaluated corpus, the work establishes that schedule sensitivity is a measurable and non-negligible phenomenon in real beginner programs (17–21% rates), with direct implications for grading, remixing, and teaching concurrent thinking in block-based languages. Strengths include the independent oracle validation that found and led to repair of four unsoundness gaps, the clean separation from logic faults, the parametric formulation, and the use of external student and public corpora rather than synthetic examples.

major comments (2)
  1. [Evaluation] Evaluation (student and public project samples): the 21% and 17.6% schedule-sensitivity rates rest on the claim that the dependence-equivalence classes produced by the partial-order reduction exactly preserve observable outcomes under the grading lens. The only soundness evidence cited is the oracle check on small projects; no independent verification (e.g., exhaustive enumeration or second oracle) is described for any of the medium-sized projects in the 224-project or public samples. A missed cross-sprite, broadcast, or clone dependence would collapse distinct classes and could alter the sensitive/non-sensitive classification.
  2. [Section 3] Dependence model definition (Section 3 / partial-order exploration): the model is stated to have been repaired after the oracle exposed four gaps on small projects, yet the paper provides no argument or additional test that the repaired rules are complete for the larger projects whose rates are reported. Because the central empirical claim is obtained by running one schedule per class under this model, any residual incompleteness directly affects the reported percentages.
minor comments (2)
  1. [Abstract / Evaluation] The abstract and evaluation sections should explicitly state the size range (number of scripts/sprites) of the “small enough to enumerate” projects used for oracle validation versus the sizes of the 224 student projects.
  2. [Formalization] Notation for the lattice of observation lenses and the fixed horizon should be introduced with a small concrete example early in the formalization section to aid readability.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the careful and constructive review. The comments correctly identify a limitation in the validation of the dependence model. We respond point by point below and will make corresponding revisions.

read point-by-point responses

  1. Referee: [Evaluation] Evaluation (student and public project samples): the 21% and 17.6% schedule-sensitivity rates rest on the claim that the dependence-equivalence classes produced by the partial-order reduction exactly preserve observable outcomes under the grading lens. The only soundness evidence cited is the oracle check on small projects; no independent verification (e.g., exhaustive enumeration or second oracle) is described for any of the medium-sized projects in the 224-project or public samples. A missed cross-sprite, broadcast, or clone dependence would collapse distinct classes and could alter the sensitive/non-sensitive classification.

    Authors: We agree that the oracle provides exhaustive confirmation only on small projects. The dependence model is obtained by formalizing the Scratch VM cooperative scheduler (Section 3) and extracting the minimal set of ordering constraints that affect observable outcomes under the defined lenses. The four gaps found by the oracle were general semantic rules (broadcast delivery, clone initialization ordering, and cross-sprite variable visibility) rather than size-specific heuristics; once repaired, the same rules are applied uniformly. Because the model is parametric in the execution engine and the fault-injection experiments on generated benchmarks exercise the same dependence classes, we maintain that the reported rates are reliable. Nevertheless, we will add an explicit paragraph in the evaluation section stating that independent verification on medium-sized projects is infeasible due to state-space size and will therefore qualify the percentages as lower bounds under the validated model. revision: partial

  2. Referee: [Section 3] Dependence model definition (Section 3 / partial-order exploration): the model is stated to have been repaired after the oracle exposed four gaps on small projects, yet the paper provides no argument or additional test that the repaired rules are complete for the larger projects whose rates are reported. Because the central empirical claim is obtained by running one schedule per class under this model, any residual incompleteness directly affects the reported percentages.

    Authors: Section 3 derives the dependence rules directly from the VM's observable scheduling semantics (initial executable-target order, broadcast queues, clone creation, and sprite layering). The oracle was used precisely to detect and close gaps in that formalization; the repairs are therefore part of the model definition rather than ad-hoc patches. We do not claim a machine-checked proof of completeness for arbitrary programs, but the model is shown to be sound and complete on all programs small enough to enumerate and to correctly classify every injected schedule fault while remaining clean on the logic-fault control set. We will revise Section 3 to include a short soundness argument that ties each repaired rule back to the VM specification and to note that the same rules are used for the second cooperative event-loop instantiation. revision: partial

Circularity Check

0 steps flagged

No significant circularity; empirical rates measured on external projects under independently validated reduction

full rationale

The paper's central results are direct empirical counts (21% and 17.6% schedule-sensitive projects) obtained by running the implemented tool on 224 student projects and a random public sample. The partial-order reduction rests on a dependence model whose soundness was checked by an independent oracle on small projects (recovering every realizable outcome), after which four gaps were repaired; the final measurements are not obtained by fitting parameters to the target corpus or by renaming the inputs. No self-citations, self-definitional equations, or ansatzes imported via prior work appear as load-bearing steps in the derivation. The method is presented as parametric and instantiated on a second VM without circular reference to its own outputs.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 1 invented entities

The central claim rests on a dependence model of the Scratch VM whose completeness is only partially checked by the oracle. No numerical free parameters are fitted. The model itself is an invented abstraction whose independent evidence is the oracle validation on small projects.

axioms (2)
  • domain assumption The Scratch VM realizes exactly the permutations of the initial executable-target order as possible schedules.
    Stated when the schedule space is formalized.
  • domain assumption The dependence relation is sufficient to partition schedules into equivalence classes that preserve all observable outcomes under the chosen lenses.
    Invoked when partial-order exploration is defined and when the oracle is used to validate the model.
invented entities (1)
  • Dependence-equivalence class of schedules independent evidence
    purpose: To reduce the factorial schedule space to a tractable set of representatives while preserving observable behavior.
    New abstraction introduced to make exhaustive exploration feasible; independent evidence is the oracle check on small projects.

pith-pipeline@v0.9.1-grok · 5832 in / 1633 out tokens · 30864 ms · 2026-07-02T08:49:45.711251+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

53 extracted references · 53 canonical work pages · 3 internal anchors

  1. [1]

    Testing scratch programs automatically,

    A. Stahlbauer, M. Kreis, and G. Fraser, “Testing scratch programs automatically,” inACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). ACM, 2019, pp. 165–175

    work page 2019

  2. [2]

    LitterBox: A linter for scratch programs,

    G. Fraser, U. Heuer, N. K ¨orber, F. Oberm ¨uller, and E. Wasmeier, “LitterBox: A linter for scratch programs,” inIEEE/ACM International Conference on Software Engineering: Software Engineering Education and Training (ICSE-SEET). IEEE, 2021, pp. 183–188

    work page 2021

  3. [3]

    Dynamic partial-order reduction for model checking software,

    C. Flanagan and P. Godefroid, “Dynamic partial-order reduction for model checking software,” inACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL). ACM, 2005, pp. 110– 121

    work page 2005

  4. [4]

    Optimal dynamic partial order reduction,

    P. Abdulla, S. Aronis, B. Jonsson, and K. Sagonas, “Optimal dynamic partial order reduction,” inACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL). ACM, 2014, pp. 373– 384

    work page 2014

  5. [5]

    ScratchLens: Lens-Parametric Behavioral Equivalence for Scratch Programs

    Y . Si and J. Zhang, “ScratchLens: Lens-parametric behavioral equivalence for Scratch programs,” arXiv:2606.15817 [cs.PL], 2026

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  6. [6]

    The scratch programming language and environment,

    J. Maloney, M. Resnick, N. Rusk, B. Silverman, and E. Eastmond, “The scratch programming language and environment,”ACM Transactions on Computing Education, vol. 10, no. 4, pp. 16:1–16:15, 2010

    work page 2010

  7. [7]

    Scratch: Programming for all,

    M. Resnick, J. Maloney, A. Monroy-Hern ´andez, N. Rusk, E. Eastmond, K. Brennan, A. Millner, E. Rosenbaum, J. Silver, B. Silverman, and Y . Kafai, “Scratch: Programming for all,”Communications of the ACM, vol. 52, no. 11, pp. 60–67, 2009

    work page 2009

  8. [8]

    Scratch virtual machine (scratch-vm),

    Scratch Foundation, “Scratch virtual machine (scratch-vm),” https: //github.com/scratchfoundation/scratch-vm, 2024, npm package scratch- vm, version 5.0.300, pinned for the experiments

    work page 2024

  9. [9]

    Analysis of programs for parallel processing,

    A. J. Bernstein, “Analysis of programs for parallel processing,”IEEE Transactions on Electronic Computers, vol. EC-15, no. 5, pp. 757–763, 1966

    work page 1966

  10. [10]

    Trace theory,

    A. Mazurkiewicz, “Trace theory,” inPetri Nets: Applications and Relationships to Other Models of Concurrency. Springer, 1987, pp. 278–324

    work page 1987

  11. [11]

    Abstract interpretation: A unified lattice model for static analysis of programs by construction or approximation of fixpoints,

    P. Cousot and R. Cousot, “Abstract interpretation: A unified lattice model for static analysis of programs by construction or approximation of fixpoints,” inACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages (POPL). ACM, 1977, pp. 238–252

    work page 1977

  12. [12]

    Counterexample- guided abstraction refinement for symbolic model checking,

    E. Clarke, O. Grumberg, S. Jha, Y . Lu, and H. Veith, “Counterexample- guided abstraction refinement for symbolic model checking,”Journal of the ACM, vol. 50, no. 5, pp. 752–794, 2003

    work page 2003

  13. [13]

    Godefroid,Partial-Order Methods for the Verification of Concurrent Systems, ser

    P. Godefroid,Partial-Order Methods for the Verification of Concurrent Systems, ser. Lecture Notes in Computer Science. Springer, 1996, vol. 1032

    work page 1996

  14. [14]

    The state explosion problem,

    A. Valmari, “The state explosion problem,” inLectures on Petri Nets I: Basic Models. Springer, 1998, pp. 429–528

    work page 1998

  15. [15]

    Milner,Communication and Concurrency

    R. Milner,Communication and Concurrency. Prentice Hall, 1989

    work page 1989

  16. [16]

    An empirical analysis of flaky tests,

    Q. Luo, F. Hariri, L. Eloussi, and D. Marinov, “An empirical analysis of flaky tests,” inACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE). ACM, 2014, pp. 643–653

    work page 2014

  17. [17]

    Practical regression test selec- tion with dynamic file dependencies,

    M. Gligoric, L. Eloussi, and D. Marinov, “Practical regression test selec- tion with dynamic file dependencies,” inACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). ACM, 2015, pp. 211–222

    work page 2015

  18. [18]

    iDFlakies: A framework for detecting and partially classifying flaky tests,

    W. Lam, R. Oei, A. Shi, D. Marinov, and T. Xie, “iDFlakies: A framework for detecting and partially classifying flaky tests,” inIEEE Conference on Software Testing, Validation and Verification (ICST). IEEE, 2019, pp. 312–322

    work page 2019

  19. [19]

    Hints on test data selection: Help for the practicing programmer,

    R. A. DeMillo, R. J. Lipton, and F. G. Sayward, “Hints on test data selection: Help for the practicing programmer,”Computer, vol. 11, no. 4, pp. 34–41, 1978

    work page 1978

  20. [20]

    An analysis and survey of the development of mutation testing,

    Y . Jia and M. Harman, “An analysis and survey of the development of mutation testing,”IEEE Transactions on Software Engineering, vol. 37, no. 5, pp. 649–678, 2011

    work page 2011

  21. [21]

    Covering and uncovering equivalent mutants,

    D. Schuler and A. Zeller, “Covering and uncovering equivalent mutants,” Software Testing, Verification and Reliability, vol. 23, no. 5, pp. 353–374, 2013

    work page 2013

  22. [22]

    Systematic testing of asyn- chronous reactive systems,

    A. Desai, S. Qadeer, and S. A. Seshia, “Systematic testing of asyn- chronous reactive systems,” inACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). ACM, 2015, pp. 73–83

    work page 2015

  23. [23]

    How kids code and how we know: An exploratory study on the scratch repository,

    E. Aivaloglou and F. Hermans, “How kids code and how we know: An exploratory study on the scratch repository,” inACM Conference on International Computing Education Research (ICER). ACM, 2016, pp. 53–61

    work page 2016

  24. [24]

    Automated test generation for scratch programs,

    A. Deiner, P. Feldmeier, G. Fraser, S. Schweikl, and W. Wang, “Automated test generation for scratch programs,”Empirical Software Engineering, vol. 28, no. 3, p. 79, 2023

    work page 2023

  25. [25]

    Model-based testing of scratch programs,

    K. G ¨otz, P. Feldmeier, and G. Fraser, “Model-based testing of scratch programs,” inIEEE Conference on Software Testing, Verification and Validation (ICST). IEEE, 2022, pp. 411–421

    work page 2022

  26. [26]

    Hairball: Lint-inspired static analysis of scratch projects,

    B. Boe, C. Hill, M. Len, G. Dreschler, P. Conrad, and D. Franklin, “Hairball: Lint-inspired static analysis of scratch projects,” inACM Technical Symposium on Computer Science Education (SIGCSE). ACM, 2013, pp. 215–220

    work page 2013

  27. [27]

    Dr. scratch: Automatic analysis of scratch projects to assess and foster computational thinking,

    J. Moreno-Le ´on, G. Robles, and M. Rom ´an-Gonz´alez, “Dr. scratch: Automatic analysis of scratch projects to assess and foster computational thinking,”Revista de Educaci ´on a Distancia, no. 46, 2015

    work page 2015

  28. [28]

    Common bugs in scratch programs,

    C. Fr¨adrich, F. Oberm¨uller, N. K¨orber, U. Heuer, and G. Fraser, “Common bugs in scratch programs,” inInnovation and Technology in Computer Science Education (ITiCSE). ACM, 2020, pp. 89–95

    work page 2020

  29. [29]

    Verified from scratch: Program analysis for learners’ programs,

    A. Stahlbauer, C. Fr¨adrich, and G. Fraser, “Verified from scratch: Program analysis for learners’ programs,” inIEEE/ACM International Conference on Automated Software Engineering (ASE). ACM, 2020, pp. 150–162

    work page 2020

  30. [30]

    Guiding next-step hint generation using automated tests,

    F. Oberm¨uller, U. Heuer, and G. Fraser, “Guiding next-step hint generation using automated tests,” inInnovation and Technology in Computer Science Education (ITiCSE). ACM, 2021, pp. 220–226

    work page 2021

  31. [31]

    NuzzleBug: Debugging block-based programs in scratch,

    A. Deiner and G. Fraser, “NuzzleBug: Debugging block-based programs in scratch,” inIEEE/ACM International Conference on Software Engi- neering (ICSE). ACM, 2024, pp. 1–13

    work page 2024

  32. [32]

    ITCH: Individual testing of computer homework for scratch assignments,

    D. E. Johnson, “ITCH: Individual testing of computer homework for scratch assignments,” inACM Technical Symposium on Computing Science Education (SIGCSE). ACM, 2016, pp. 223–227

    work page 2016

  33. [33]

    arXiv preprint arXiv:2509.11065

    Y . Si, D. Li, H. Shi, and J. Zhang, “ViScratch: Using large language models and gameplay videos for automated feedback in Scratch,” arXiv:2509.11065 [cs.SE], 2025

    work page arXiv 2025

  34. [34]

    Stitch: Step-by-step LLM guided tutoring for Scratch,

    Y . Si, K. Qi, D. Li, H. Shi, and J. Zhang, “Stitch: Step-by-step LLM guided tutoring for Scratch,” arXiv:2510.26634 [cs.SE], 2025

    work page arXiv 2025

  35. [35]

    ScratchEval: A multi- modal evaluation framework for LLMs in block-based programming,

    Y . Si, S. Han, D. Li, H. Shi, and J. Zhang, “ScratchEval: A multi- modal evaluation framework for LLMs in block-based programming,” arXiv:2602.00757 [cs.SE], 2026

    work page arXiv 2026

  36. [36]

    EcoScratch: Cost- effective multimodal repair for Scratch using execution feedback,

    Y . Si, M. Wang, D. Li, H. Shi, and J. Zhang, “EcoScratch: Cost- effective multimodal repair for Scratch using execution feedback,” arXiv:2603.29624 [cs.SE], 2026

    work page arXiv 2026

  37. [37]

    Raven: Rethinking Automated Assessment for Scratch Programs via Video-Grounded Evaluation

    D. Li, D. Li, H. Shi, and J. Zhang, “Raven: Rethinking auto- mated assessment for Scratch programs via video-grounded evaluation,” arXiv:2604.17820 [cs.SE], 2026

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  38. [38]

    ScratchWorld: Evaluating If World Models Compute Executable Consequences

    Y . Lin and J. Zhang, “ScratchWorld: Evaluating if world models compute executable consequences,” arXiv:2606.31689 [cs.SE], 2026

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  39. [39]

    Automated feedback generation for competition-level code,

    J. Zhang, D. Li, J. C. Kolesar, H. Shi, and R. Piskac, “Automated feedback generation for competition-level code,” inProceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering, ser. ASE 2022. ACM, 2022, pp. 13:1–13:13

    work page 2022

  40. [40]

    PyDex: Repairing bugs in introductory python assignments using LLMs,

    J. Zhang, J. P. Cambronero, S. Gulwani, V . Le, R. Piskac, G. Soares, and G. Verbruggen, “PyDex: Repairing bugs in introductory python assignments using LLMs,”Proceedings of the ACM on Programming Languages, vol. 8, no. OOPSLA1, pp. 1100–1124, 2024

    work page 2024

  41. [41]

    A systematic study of time limit exceeded errors in online programming assignments,

    J. Zhang, J. Gu, W. Zhang, J. P. Cambronero, J. C. Kolesar, R. Piskac, D. Li, and H. Shi, “A systematic study of time limit exceeded errors in online programming assignments,” arXiv:2510.14339 [cs.SE], 2025

    work page arXiv 2025

  42. [42]

    Using pre-trained language models to resolve textual and semantic merge conflicts,

    J. Zhang, T. Mytkowicz, M. Kaufman, R. Piskac, and S. K. Lahiri, “Using pre-trained language models to resolve textual and semantic merge conflicts,” inProceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis, ser. ISSTA 2022. ACM, 2022, pp. 77–88

    work page 2022

  43. [43]

    Learning CI configuration correctness for early build feedback,

    M. Santolucito, J. Zhang, E. Zhai, J. Cito, and R. Piskac, “Learning CI configuration correctness for early build feedback,” inProceedings of the 2022 IEEE International Conference on Software Analysis, Evolution and Reengineering, ser. SANER 2022. IEEE, 2022, pp. 1006–1017

    work page 2022

  44. [44]

    Static detection of silent misconfigurations with deep interaction analysis,

    J. Zhang, R. Piskac, E. Zhai, and T. Xu, “Static detection of silent misconfigurations with deep interaction analysis,”Proceedings of the ACM on Programming Languages, vol. 5, no. OOPSLA, pp. 1–30, 2021

    work page 2021

  45. [45]

    Translation validation,

    A. Pnueli, M. Siegel, and E. Singerman, “Translation validation,” inTools and Algorithms for the Construction and Analysis of Systems (TACAS). Springer, 1998, pp. 151–166

    work page 1998

  46. [46]

    Regression verification: Proving the equivalence of similar programs,

    B. Godlin and O. Strichman, “Regression verification: Proving the equivalence of similar programs,”Software Testing, Verification and Reliability, vol. 23, no. 3, pp. 241–258, 2013

    work page 2013

  47. [47]

    Differential symbolic execution,

    S. Person, M. B. Dwyer, S. Elbaum, and C. S. P ˘as˘areanu, “Differential symbolic execution,” inACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE). ACM, 2008, pp. 226–237

    work page 2008

  48. [48]

    Semantic diff: A tool for summarizing the effects of modifications,

    D. Jackson and D. A. Ladd, “Semantic diff: A tool for summarizing the effects of modifications,” inInternational Conference on Software Maintenance (ICSM). IEEE, 1994, pp. 243–252

    work page 1994

  49. [49]

    SYMDIFF: A language-agnostic semantic diff tool for imperative programs,

    S. K. Lahiri, C. Hawblitzel, M. Kawaguchi, and H. Reb ˆelo, “SYMDIFF: A language-agnostic semantic diff tool for imperative programs,” in Computer Aided Verification (CAV). Springer, 2012, pp. 712–717

    work page 2012

  50. [50]

    Practical, low-effort equivalence verification of real code,

    D. A. Ramos and D. R. Engler, “Practical, low-effort equivalence verification of real code,” inComputer Aided Verification (CAV). Springer, 2011, pp. 669–685

    work page 2011

  51. [51]

    Fine-grained and accurate source code differencing,

    J.-R. Falleri, F. Morandat, X. Blanc, M. Martinez, and M. Monperrus, “Fine-grained and accurate source code differencing,” inACM/IEEE International Conference on Automated Software Engineering (ASE). ACM, 2014, pp. 313–324

    work page 2014

  52. [52]

    Change distilling: Tree differencing for fine-grained source code change extraction,

    B. Fluri, M. W ¨ursch, M. Pinzger, and H. Gall, “Change distilling: Tree differencing for fine-grained source code change extraction,”IEEE Transactions on Software Engineering, vol. 33, no. 11, pp. 725–743, 2007

    work page 2007

  53. [53]

    Comparison and evaluation of code clone detection techniques and tools: A qualitative approach,

    C. K. Roy, J. R. Cordy, and R. Koschke, “Comparison and evaluation of code clone detection techniques and tools: A qualitative approach,” Science of Computer Programming, vol. 74, no. 7, pp. 470–495, 2009

    work page 2009