<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Automatic Software Repair: a Bibliography · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/1807.00515/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/1807.00515/feed.xml" rel="self" type="application/rss+xml" /><item><title>Automatic Software Repair: a Bibliography — mentioned by sitkack</title><link>https://news.ycombinator.com/item?id=24401830</link><guid isPermaLink="false">urn:hackerpapers:mention:1807.00515:24401830</guid><pubDate>Mon, 07 Sep 2020 19:13:15 GMT</pubDate><description>&lt;p&gt;Mutation Testing [1] is a generalized form of fuzzing. It is also analogous to Sensitivity Analysis [2]. As part of closing the feedback loop between the code and the tests, if one had a repeatable way to break the code and measure the selectivity in the test result, one could ensure that they are testing the same thing as the code evolves. Automatic program repair [3] tries to find patches to broken code, maybe goal directed program breaking (possibly using DNNs) could be used to infer properties for code so that better invariants could be discovered. [1]…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1807.00515/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.SE</category></item></channel></rss>
