Expanding Fix Patterns to Enable Automatic Program Repair

Automatic Program Repair (APR) has been proposed to help developers and reduce the time spent repairing programs. Recent APR tools have applied learned templates (fix patterns) to fix code using knowledge from fixes successfully applied in the past. However, there is still no general agreement on the representation of fix patterns, making their application and comparison with a baseline difficult. As a consequence, it is also difficult to expand fix patterns and further enable APR. We automatically generate fix patterns from similar fixes and compare the generated fix patterns against a state-of-the-art taxonomy. Our automated approach splits fixes into smaller, method-level chunks and calculates their similarity. A threshold-based clustering algorithm groups similar chunks and finds matches with state-of-the-art fix patterns. In our evaluation, we present 33 clusters whose fix patterns were generated from the fixes of 835 Defects4J bugs. Of those 33 clusters, 22 matched a state-of-the-art taxonomy with good agreement. The remaining 11 clusters were thematically analysed and generated new fix patterns that expanded the taxonomy. Our new fix patterns should enable APR researchers and practitioners to expand their tools to fix a greater range of bugs in the future

Towards Developer-Centered Automatic Program Repair:Findings from Bloomberg

This paper reports on qualitative research into automatic program repair (APR) at Bloomberg. Six focus groups were conducted with a total of seventeen participants (including both developers of the APR tool and developers using the tool) to consider: the development at Bloomberg of a prototype APR tool (Fixie); developers' early experiences using the tool; and developers' perspectives on how they would like to interact with the tool in future. APR is developing rapidly and it is important to understand in greater detail developers' experiences using this emerging technology. In this paper, we provide in-depth, qualitative data from an industrial setting. We found that the development of APR at Bloomberg had become increasingly user-centered, emphasising how fixes were presented to developers, as well as particular features, such as cus-tomisability. From the focus groups with developers who had used Fixie, we found particular concern with the pragmatic aspects of APR, such as how and when fixes were presented to them. Based on our findings, we make a series of recommendations to inform future APR development, highlighting how APR tools should 'start small', be customisable, and fit with developers' workflows. We also suggest that APR tools should capitalise on the promise of repair bots and draw on advances in explainable AI

Towards Developer-Centered Automatic Program Repair: Findings from Bloomberg

This paper reports on qualitative research into automatic program repair (APR) at Bloomberg. Six focus groups were conducted with a total of seventeen participants (including both developers of the APR tool and developers using the tool) to consider: the development at Bloomberg of a prototype APR tool (Fixie); developers' early experiences using the tool; and developers' perspectives on how they would like to interact with the tool in future. APR is developing rapidly and it is important to understand in greater detail developers' experiences using this emerging technology. In this paper, we provide in-depth, qualitative data from an industrial setting. We found that the development of APR at Bloomberg had become increasingly user-centered, emphasising how fixes were presented to developers, as well as particular features, such as cus-tomisability. From the focus groups with developers who had used Fixie, we found particular concern with the pragmatic aspects of APR, such as how and when fixes were presented to them. Based on our findings, we make a series of recommendations to inform future APR development, highlighting how APR tools should 'start small', be customisable, and fit with developers' workflows. We also suggest that APR tools should capitalise on the promise of repair bots and draw on advances in explainable AI.Output Status: Forthcomin

Towards Developer-Centered Automatic Program Repair: Findings from Bloomberg

This paper reports on qualitative research into automatic program repair (APR) at Bloomberg. Six focus groups were conducted with a total of seventeen participants (including both developers of the APR tool and developers using the tool) to consider: the development at Bloomberg of a prototype APR tool (Fixie); developers' early experiences using the tool; and developers' perspectives on how they would like to interact with the tool in future. APR is developing rapidly and it is important to understand in greater detail developers' experiences using this emerging technology. In this paper, we provide in-depth, qualitative data from an industrial setting. We found that the development of APR at Bloomberg had become increasingly user-centered, emphasising how fixes were presented to developers, as well as particular features, such as cus-tomisability. From the focus groups with developers who had used Fixie, we found particular concern with the pragmatic aspects of APR, such as how and when fixes were presented to them. Based on our findings, we make a series of recommendations to inform future APR development, highlighting how APR tools should 'start small', be customisable, and fit with developers' workflows. We also suggest that APR tools should capitalise on the promise of repair bots and draw on advances in explainable AI

LEGaTO: towards energy-efficient, secure, fault-tolerant toolset for heterogeneous computing

LEGaTO is a three-year EU H2020 project which started in December 2017. The LEGaTO project will leverage task-based programming models to provide a software ecosystem for Made-in-Europe heterogeneous hardware composed of CPUs, GPUs, FPGAs and dataflow engines. The aim is to attain one order of magnitude energy savings from the edge to the converged cloud/HPC.Peer ReviewedPostprint (author's final draft

Discutindo a educação ambiental no cotidiano escolar: desenvolvimento de projetos na escola formação inicial e continuada de professores

A presente pesquisa buscou discutir como a Educação Ambiental (EA) vem sendo trabalhada, no Ensino Fundamental e como os docentes desta escola compreendem e vem inserindo a EA no cotidiano escolar., em uma escola estadual do município de Tangará da Serra/MT, Brasil. Para tanto, realizou-se entrevistas com os professores que fazem parte de um projeto interdisciplinar de EA na escola pesquisada. Verificou-se que o projeto da escola não vem conseguindo alcançar os objetivos propostos por: desconhecimento do mesmo, pelos professores; formação deficiente dos professores, não entendimento da EA como processo de ensino-aprendizagem, falta de recursos didáticos, planejamento inadequado das atividades. A partir dessa constatação, procurou-se debater a impossibilidade de tratar do tema fora do trabalho interdisciplinar, bem como, e principalmente, a importância de um estudo mais aprofundado de EA, vinculando teoria e prática, tanto na formação docente, como em projetos escolares, a fim de fugir do tradicional vínculo “EA e ecologia, lixo e horta”.Facultad de Humanidades y Ciencias de la Educació

Extending the applicability of deterministic multithreading

With the increased number of cores on a single processor chip, an application can achieve good performance if it splits the execution into multiple threads that run on multiple cores at the same time. To synchronize threads, Transactional Memory (TM) allows them to concurrently execute sections of code (transactions) with accesses to shared memory, and requires reexecution of one of the transactions in case of a conflicting access. Even though parallel programming with TM is simpler and less error-prone than with the traditional locking mechanism, concurrent programming errors are hard to avoid in general. The reason is that threads run in parallel and might interleave in a nondeterministic order. As a consequence, an error can occur in one execution but be hidden in another (which makes debugging hard), and the application output might vary (which makes testing and replica-based fault tolerance hard). To help programmers in testing, debugging and providing fault tolerance, researchers have proposed deterministic multithreading, which guarantees that application threads access shared memory in the same order and the application gives the same output whenever it runs with the same input parameters. In this thesis we present DeTrans, a system for deterministic multithreading in transactional applications. DeTrans ensures determinism even in the presence of data races, by executing non-transactional code serially and transactions in parallel. We compare DeTrans with Dthreads, a widely-used deterministic system for lock-based applications, and analyse sources of the overhead caused by deterministic execution. Instead of using memory protection hardware and operating system facilities, DeTrans exploits properties of TM implemented in software and outperforms Dthreads. To allow transactions to invoke standard library functions while running deterministically and to increase parallelism, this thesis proposes TM-dietlibc, a TM-aware standard library. Our experience in modifying a lock-based standard library in order to integrate it in a TM system is applicable for any TM-aware software. TM-dietlibc provides concurrent execution of standard library functions and only in a few cases the execution switches to serial. In comparison to completely serialized execution, TM-dietlibc shows high scalability and performance improvement for benchmarks with short transactions and low contention. Serialization of transactions - which is still required for transactions in TM-dietlibc with non-reversible side effects - might enforce an order of threads execution different from the one enforced by a deterministic system, causing a deadlock. By porting deterministic system DeTrans in TM-dietlibc, we ensure deterministic multithreading at application and standardlibrary level, and avoid deadlocks by serializing transactions in deterministic order. In this thesis we also discuss a common limitation of deterministic systems - ad hoc synchronization. Ad hoc synchronization is in general widely used, but similarly to transaction serialization, it might be prone to deadlocks during deterministic execution. We use hardware performance counters to identify synchronization loops at runtime and to avoid deadlocks by dynamically (but deterministically) changing the order of threads execution.Con el aumento del número de núcleos en un solo procesador, una aplicación puede lograr un buen rendimiento si se divide la ejecución en múltiples hilos que se ejecutan en múltiples núcleos al mismo tiempo. Para sincronizar estos hilos, memoria transaccional (TM) permite ejecutar simultáneamente secciones de código (transacciones) con accesos a memoria compartida, y requiere re-ejecución de una de las transacciones en caso de un acceso a memoria que causa un conflicto. A pesar de que la programación paralela con TM es más simple y menos propensa a errores que con mecanismos de cerrojos tradicionales, los errores de programación concurrentes son difíciles de evitar en general. La razón es que los hilos se ejecutan en paralelo y pueden intercalar en ordenes no deterministas. Como consecuencia, un error puede ocurrir en una ejecución, pero se oculta en otro (lo que hace que la depuración difícil), y el resultado de la aplicación puede variar (lo que hace el testeo y la tolerancia a fallos basada en réplica difícil). Para ayudar a los programadores en el testeo, depuración y proporcionar tolerancia a fallos, los investigadores han propuesto sistemas multihilos deterministas, que garantizan que los diferentes hilos de las aplicaciones accedan a la memoria compartida en el mismo orden y la aplicación da el mismo resultado cada vez que se ejecuta con los mismos parámetros de entrada. En esta tesis presentamos DeTrans, un sistema determinista para las aplicaciones transaccionales. DeTrans asegura el determinismo incluso en presencia de condiciones de carrera de datos, mediante la ejecución de código no transaccional en serie y las transacciones en paralelo. Comparamos DeTrans con Dthreads, un sistema determinista ampliamente utilizado para aplicaciones basadas en cerrojos, y analizamos las fuentes de coste adicional causadas por la ejecución determinista. En lugar de utilizar hardware de protección de memoria y las funcionalidades del sistema operativo, DeTrans explota las propiedades de TM implementadas en software y rinde mejor que Dthreads. Para permitir que las transacciones puedan invocar funciones de la librería estándar durante la ejecución determinista y aumentar el paralelismo, esta tesis propone TM-dietlibc, una librería estándar consciente de TM. Nuestra experiencia en la modificación de una librería estándar basada en locks con el fin de integrarlo en un sistema de TM es aplicable a cualquier software consciente de TM. TM-dietlibc proporciona ejecución simultánea de funciones de la librería estándar y sólo en unos pocos casos la ejecución pasa a ser en serie. En comparación con la ejecución totalmente serial, TM-dietlibc muestra una alta escalabilidad y una mejora del rendimiento para aplicaciones con transacciones cortas y contención baja. Serialización de transacciones - que todavía se requieren para las transacciones en TM-dietlibc con efectos secundarios no reversibles - podría forzar un orden de ejecución de los hilos distinta de la aplicada por un sistema determinista, causando un deadlock. Portando el sistema determinista DeTrans a TM-dietlibc, aseguramos ejecuciones multihilo deterministas tanto a nivel de la aplicación como de la librería estándar, y evitamos deadlocks serializando transacciones en orden determinista. En esta tesis también discutimos una limitación común de los sistemas deterministas - la sincronización ad-hoc. La sincronización ad-hoc es en general ampliamente utilizada, pero de manera similar a la serialización transacción, puede ser propensa a deadlocks durante la ejecución determinista. Utilizamos contadores de rendimiento hardware para identificar bucles de sincronización durante la ejecución y así evitar deadlocks de forma dinámica (pero determinista) cambiando el orden de ejecución de los hilos

Let's Talk With Developers, Not About Developers:A Review of Automatic Program Repair Research

Automatic program repair (APR) offers significant potential for automating some coding tasks. Using APR could reduce the high costs historically associated with fixing code faults and deliver significant benefits to software engineering. Adopting APR could also have profound implications for software developers daily activities, transforming their work practices. To realise the benefits of APR it is vital that we consider how developers feel about APR and the impact APR may have on developers' work. Developing APR tools without consideration of the developer is likely to undermine the success of APR deployment. In this paper, we critically review how developers are considered in APR research by analysing how human factors are treated in 260 studies from Monperrus's Living Review of APR. Over half of the 260 studies in our review were motivated by a problem faced by developers (e.g., the difficulty associated with fixing faults). Despite these human-oriented motivations, fewer than 7% of the 260 studies included a human study. We looked in detail at these human studies and found their quality mixed (for example, one human study was based on input from only one developer). Our results suggest that software developers are often talked about in APR studies, but are rarely talked with. A more comprehensive and reliable understanding of developer human factors in relation to APR is needed. Without this understanding, it will be difficult to develop APR tools and techniques which integrate effectively into developers' workflows. We recommend a future research agenda to advance the study of human factors in APR

How do developers really feel about bug fixing?:Directions for automatic program repair

Automatic program repair (APR) is a rapidly advancing field of software engineering that aims to supplement or replace manual bug fixing with an automated tool. For APR to be successfully adopted in industry, it is vital that APR tools respond to developer needs and preferences. However, very little research has considered developers' general attitudes to APR or developers' current bug fixing practices (the activity APR aims to replace). This paper responds to this gap by reporting on a survey of 386 software developers about their bug finding and fixing practices and experiences, and their instinctive attitudes towards APR. We find that bug finding and fixing is not necessarily as onerous for developers as has often been suggested, being rated as more satisfying than developers' general work. The fact that developers derive satisfaction and benefit from bug fixing indicates that APR adoption is not as simple as APR replacing an unwanted activity. When it comes to potential APR approaches, we find a strong preference for developers being kept in the loop (for example, choosing between different fixes or validating fixes) as opposed to a fully automated process. This suggests that advances in APR should be careful to consider the agency of the developer, as well as what information is presented to developers alongside fixes. It also indicates that there are key barriers related to trust that would need to be overcome for full scale APR adoption, supported by the fact that even those developers who stated that they were positive about APR listed several caveats and concerns. We find very few statistically significant relationships between particular demographic variables (for example, developer experience, age, education) and key attitudinal variables, suggesting that developers' instinctive attitudes towards APR are little influenced by experience level but are held widely across the developer community