Journal of Computer Languages最新文献

Fault localization aims to automatically identify the cause of an error in a program by localizing the error to a relatively small part of the program. In this paper, we present a novel technique for automated fault localization via error invariants inferred by abstract interpretation. An error invariant for a location in an error program over-approximates the reachable states at the given location that may produce the error, if the execution of the program is continued from that location. Error invariants can be used for statement-wise semantic slicing of error programs and for obtaining concise error explanations. We use an iterative refinement sequence of backward–forward static analyses by abstract interpretation to compute error invariants, which are designed to explain why an error program violates a particular assertion.

Furthermore, we present a practical application of the fault localization technique for automatic repair of programs. Given an erroneous program, we first use the fault localization to automatically identify statements relevant for the error, and then repeatedly mutate the expressions in those relevant statements until a correct program that satisfies all assertions is found. All other statements classified by the fault localization as irrelevant for the error are not mutated in the program repair process. This way, we significantly reduce the search space of mutated programs without losing any potentially correct program, and so locate a repaired program much faster than a program repair without fault localization.

We have developed a prototype tool for automatic fault localization and repair of C programs. We demonstrate the effectiveness of our approach to localize errors in realistic C programs, and to subsequently repair them. Moreover, we show that our approach based on combining fault localization and code mutations is significantly faster that the previous program repair approach without fault localization.

Systematic reviews (SRs) provide valuable evidence for guiding new research directions. However, the manual effort involved in selecting articles for inclusion in an SR is error-prone and time-consuming. While screening articles has traditionally been considered challenging to automate, the advent of large language models offers new possibilities. In this paper, we discuss the effect of using ChatGPT on the SR process. In particular, we investigate the effectiveness of different prompt strategies for automating the article screening process using five real SR datasets. Our results show that ChatGPT can reach up to 82% accuracy. The best performing prompts specify exclusion criteria and avoid negative shots. However, prompts should be adapted to different corpus characteristics.

Systems engineering is fundamental to the performance, functionality, and value of modern systems and products. Systems model development and the usage of modeling tools in systems engineering can be complex. Systems engineering is concerned not only with the modeling process but many other aspects of development, such as hardware, data, and modeling tools. Because systems modeling practitioners are versatile and have expertise in specifying, building, maintaining, and supporting technical infrastructure, the modeling practices and challenges vary. We conducted an empirical study from a systems modeler’s perspective to better understand the challenges posed to systems engineers in the LabVIEW community. Our inspection consists of two investigations. First, with the help of machine learning techniques, we mined online discussion forum posts to identify what questions engineers ask regarding modeling challenges. The result shows that the most challenging part is related to coding practice in the development. Inspired by this discovery, we conducted another empirical study. We surveyed systems engineers in the LabVIEW community using an online questionnaire to recognize what system engineers tell regarding coding challenges in their development practice. Our paper also provided some observations and concrete suggestions to both systems engineers and tool developers on how to improve system model quality and facilitate the modeling process when using LabVIEW.

At Thales Defense Mission Systems (DMS), software products first go through an industrial prototyping phase. Prototypes are serious applications that we evaluate with our end-users during demonstrations. End-users have a central role in the design process of our products. They often ask for software modifications during demonstrations to experiment new ideas or to focus the existing design on their needs.

In this paper, we present how we combined Smalltalk’s live-programming capabilities with software component models to obtain flexible and modular software designs in our context of live prototyping. We present Molecule, an open-source implementation of the Lightweight CORBA Component Model in Pharo. We use Molecule to build HMI systems prototypes, and we benefit from the dynamic run-time modification capabilities of Pharo during demonstrations with our end-users where we explore software designs in a lively way.

Molecule is an industrial contribution to Smalltalk, as it capitalizes 20 years of usage and maturation in our prototyping activity. The Molecule framework and tools are now mature, and we started building end-user software used in production at Thales DMS. We present two such end-user software and analyze their component architecture, that are representative of how we (learnt to) build HMI prototypes. Finally, we analyze our technological decisions with regards to the benefits we sought for our industrial activity.

Object-centric breakpoints aim to facilitate the debugging of object-oriented programs by focusing on specific objects. However, their practical application faces limitations. They often produce false positives and require developers to identify objects to debug in a running program, which is sometimes not possible due to non-determinism. Additionally, object-centric breakpoints are difficult to build because, to the best of our knowledge, their implementations have never been abstracted from low-level concerns. The literature describes complex reflective architectures necessary for implementing these breakpoints, and their rare available implementations are language-specific.

In this paper, we introduce Time-Traveling Object-Centric Breakpoints (TTOCBs), a new definition and implementation of object-centric breakpoints based on Time-Traveling Queries (TTQs). TTQs are an extensible time-traveling debugging system that allows developers to explore their program executions back and forth by executing debugging queries. We argue that our query-based implementation helps to overcome the limitations of traditional object-centric breakpoints. We describe how TTOCBs assist developers in searching for objects to debug within their program executions, even in the presence of non-determinism. We illustrate how existing object-centric breakpoints from the literature can be implemented and how new ones can be created in a few steps using the TTQ abstractions and scripting API. To build breakpoints, developers need to familiarize themselves with a short API instead of learning language reflection techniques and libraries. This makes our TTOCBs independent of the underlying TTQs and debugger implementations.

To evaluate our solution, we conducted an initial anecdotal user study on four example scenarios, providing evidence that debugging with TTOCBs requires fewer actions than with traditional object-centric breakpoints. We then discuss the comparison between object-centric breakpoints and TTOCBs in terms of applicability and performance.

Delta-Oriented Programming is a modular, and flexible paradigm for implementing a Software Product Line. Delta-Oriented Programming involves implementing a core software product alongside a collection of Delta Modules, which encapsulate modifications that can be applied to the core software to obtain the desired product. The applicable Delta modules are activated through product configuration. The core product in Delta-Oriented Programming is mainly an object-oriented program. While Delta-Oriented Programming has the potential to enhance productivity by reusing modifications, its limited availability of tools poses a challenge in managing large-scale software systems, making it difficult for non-experts to use. Model-based engineering offers a viable solution to this problem by utilizing model artifacts instead of code snippets, simplifying product line management based on Delta-Oriented Programming. This paper presents PhaDOP, a framework for implementing Delta-Oriented Programming at the model level in the Pharo environment. The framework provides the necessary structures to construct Software Product Line architecture, organize reusable artifacts, and prepare the Delta Module through a graphical user interface. PhaDOP was evaluated through a case study.

Refactorings are behavior-preserving code transformations. They are a recommended software development practice and are now a standard feature in modern IDEs. There are however many situations where developers need to perform mere transformations (non-behavior-preserving) or to mix refactorings and transformations. Little work exists on the analysis of transformations implementation, how refactorings could be composed of smaller, reusable, parts (simple transformations or other refactorings), and, conversely, how transformations could be reused in isolation or to compose new refactorings. In a previous article, we started to analyze the seminal implementation of refactorings as proposed in the Ph.D. of D. Roberts, and whose evolution is available in the Pharo IDE. We identified a dichotomy between the class hierarchy of refactorings (56 classes) and that of transformations (70 classes). We also noted that there are different kinds of preconditions for different purposes (applicability preconditions or behavior-preserving preconditions). In this article, we go further by proposing a new architecture that: (i) supports two important scenarios (interactive use or scripting, i.e., batch use); (ii) defines a clear API unifying refactorings and transformations; (iii) expresses refactorings as decorators over transformations, and; (iv) formalizes the uses of the different kinds of preconditions, thus supporting better user feedback. We are in the process of migrating the existing Pharo refactorings to this new architecture. Current results show that elementary transformations such as the Add Method transformation is reused in 24 refactorings and 11 other transformations; and the Remove Method transformation is reused in 11 refactorings and 7 other transformations.

We present Smalltalk-25, a scientific Programm of research towards the synthesis of Smalltalk VMs by formal methods. We approach this through a Dynabook-style implementation of Hilbert’s “manipulating proofs as mathematical objects”. We begin by implementing an automated-reasoning engine based on refinement types. Having that foundation laid, we build a program logics for a simple “model” language; a framework for reasoning about a real intermediate language by translating into the model language; an ahead-of-time bootstrapper; and a framework for debugging thus-constructed VMs.

Our Programm is an ongoing research effort; this paper provides a report of its current status. Every part of our system is implemented in Smalltalk and available from GitHub under the MIT license.

Reflective operations are powerful APIs (Application Programming Interface) that let developers build advanced tools and architectures. Reflective operations are used for implementing tools and development environments (e.g., compilers, debuggers, inspectors) or language features (e.g., distributed systems, exceptions, proxies, aspect-oriented programming). In addition, languages are evolving, introducing better concepts, and revising practices and APIs. Since 2008 Pharo has evolved from Squeak and its reflective API has evolved accordingly, diverging consequently from the original Smalltalk reflective API. With more than 500 reflective methods identified, Pharo has one of the largest reflective feature sets ranging from structural reflection to on-demand stack reification. Those operations are often built on top of the other, creating different layers of reflective operations, from low-level to high-level ones.

There is a need to understand the current reflective APIs to understand their underlying use, potential dependencies, and whether some reflective features can be scoped and optional. Such an analysis is challenged by new metaobjects organically introduced in the system, such as first-class instance variables, and their mixture with the base-level API of objects and classes.

In this article, we analyze the reflective operations used in Pharo 12 and their interdependencies. We propose a classification based on their semantics and we identify a set of issues of the current implementation. Such an analysis of reflective operations in Pharo is important to support the revision of the reflective layer and its potential redesign.

We introduce a representation for generating explanations for the outcomes of combinatorial optimization algorithms. The two key ideas are (A) to maintain fine-grained representations of the values manipulated by these algorithms and (B) to derive explanations from these representations through merge, filter, and aggregation operations. An explanation in our model presents essentially a high-level comparison of the solution to a problem with a hypothesized alternative, illuminating why the solution is better than the alternative. Our value representation results in explanations smaller than other dynamic program representations, such as traces. Based on a measure for the conciseness of explanations we demonstrate through a number of experiments that the explanations produced by our approach are small and scale well with problem size across a number of different applications.