arXiv subjects

Giovanni Rosa

Publications and source records attributed to Giovanni Rosa.

7 recordsLinked to original sources

arXiv2026

Not Only for Developers: Exploring Plugin Maintenance for Knowledge-Centric Communities

The adoption of third-party libraries has become integral to modern software development, leading to large ecosystems such as PyPI, NPM, and Maven, where contributors typically share the technical expertise to sustain extensions. In communities that are not exclusively composed of developers, however, maintaining plugin ecosystems can present different challenges. In this early results paper, we study Obsidian, a knowledge--centric platform whose community is focused on writing, organization, and creativity--has built a substantial plugin ecosystem despite not being developer--centric. We investigate what kinds of plugins exist within this hybrid ecosystem and establish a foundation for understanding how they are maintained. Using repository mining and LLM-based topic modeling on a representative sample of 396 plugins, we identify six topics related to knowledge management and tooling, which is (i) dynamic editing and organization, (ii) interface and layouts, (iii) creative writing and productivity, (iv) knowledge sync solutions, (v) linking and script tools, and (vi) workflow enhancements tools. Furthermore, analysis of the Pull Requests from these plugins show that much software evolution has been performed on these ecosystem. These findings suggest that even in mixed communities, plugin ecosystems can develop recognizable engineering structures, motivating future work that highlight three different research directions with six research questions related to the health and sustainability of these non-developer ecosystems.

cs.SE↗

arXiv2026

Understanding Specification-Driven Code Generation with LLMs: An Empirical Study Design

Large Language Models (LLMs) are increasingly integrated into software development workflows, yet their behavior in structured, specification-driven processes remains poorly understood. This paper presents an empirical study design using CURRANTE, a Visual Studio Code extension that enables a human-in-the-loop workflow for LLM-assisted code generation. The tool guides developers through three sequential stages--Specification, Tests, and Function--allowing them to define requirements, generate and refine test suites, and produce functions that satisfy those tests. Participants will solve medium-difficulty problems from the LiveCodeBench dataset, while the tool records fine-grained interaction logs, effectiveness metrics (e.g., pass rate, all-pass completion), efficiency indicators (e.g., time-to-pass), and iteration behaviors. The study aims to analyze how human intervention in specification and test refinement influences the quality and dynamics of LLM-generated code. The results will provide empirical insights into the design of next-generation development environments that align human reasoning with model-driven code generation.

cs.SE↗

arXiv2025

An empirical analysis of vulnerability detection tools for solidity smart contracts

The rapid adoption of blockchain technology highlighted the importance of ensuring the security of smart contracts due to their critical role in automated business logic execution on blockchain platforms. This paper provides an empirical evaluation of automated vulnerability analysis tools specifically designed for Solidity smart contracts. Leveraging the extensive SmartBugs 2.0 framework, which includes 20 analysis tools, we conducted a comprehensive assessment using an annotated dataset of 2,182 instances we manually annotated with line-level vulnerability labels. Our evaluation highlights the detection effectiveness of these tools in detecting various types of vulnerabilities, as categorized by the DASP TOP 10 taxonomy. We evaluated the effectiveness of a Large Language Model-based detection method on two popular datasets. In this case, we obtained inconsistent results with the two datasets, showing unreliable detection when analyzing real-world smart contracts. Our study identifies significant variations in the accuracy and reliability of different tools and demonstrates the advantages of combining multiple detection methods to improve vulnerability identification. We identified a set of 3 tools that, combined, achieve up to 76.78\% found vulnerabilities taking less than one minute to run, on average. This study contributes to the field by releasing the largest dataset of manually analyzed smart contracts with line-level vulnerability annotations and the empirical evaluation of the greatest number of tools to date.

cs.SE↗

arXiv2024

First direction sensitive search for dark matter with a nuclear emulsion detector at a surface site

Fine-grained nuclear emulsion films have been developed as a tracking detector with nanometric spatial resolution to be used in direction-sensitive dark matter searches, thanks to novel readout technologies capable of exploiting this unprecedented resolution. Emulsion detectors are time insensitive. Therefore, a directional dark matter search with such detector requires the use of an equatorial telescope to absorb the Earth rotation effect. We have conducted for the first time a directional dark matter search in an unshielded location, at the sea level, by keeping an emulsion detector exposed for 39 days on an equatorial telescope mount. The observed angular distribution of the data collected during an exposure equivalent to 0.59 g days agrees with the background model and an exclusion plot was then derived in the dark matter mass and cross-section plane: cross-sections higher than $1.3 \times 10^{-28}$ cm$^{2}$ and $1.7 \times 10^{-31}$ cm$^2$ were excluded for a dark matter mass of $10$ GeV$/c^2$ and $100$ GeV$/c^2$, respectively. This is the first direction sensitive search for dark matter with a solid-state, particle tracking detector.

astro-ph.CO↗

arXiv2023

Automatically Generating Dockerfiles via Deep Learning: Challenges and Promises

Containerization allows developers to define the execution environment in which their software needs to be installed. Docker is the leading platform in this field, and developers that use it are required to write a Dockerfile for their software. Writing Dockerfiles is far from trivial, especially when the system has unusual requirements for its execution environment. Despite several tools exist to support developers in writing Dockerfiles, none of them is able to generate entire Dockerfiles from scratch given a high-level specification of the requirements of the execution environment. In this paper, we present a study in which we aim at understanding to what extent Deep Learning (DL), which has been proven successful for other coding tasks, can be used for this specific coding task. We preliminarily defined a structured natural language specification for Dockerfile requirements and a methodology that we use to automatically infer the requirements from the largest dataset of Dockerfiles currently available. We used the obtained dataset, with 670,982 instances, to train and test a Text-to-Text Transfer Transformer (T5) model, following the current state-of-the-art procedure for coding tasks, to automatically generate Dockerfiles from the structured specifications. The results of our evaluation show that T5 performs similarly to the more trivial IR-based baselines we considered. We also report the open challenges associated with the application of deep learning in the context of Dockerfile generation.

cs.SE↗

arXiv2022

Fixing Dockerfile Smells: An Empirical Study

Background. Containerization technologies are widely adopted in the DevOps workflow. The most commonly used one is Docker, which requires developers to define a specification file (Dockerfile) to build the image used for creating containers. There are several best practice rules for writing Dockerfiles, but the developers do not always follow them. Violations of such practices, known as Dockerfile smells, can negatively impact the reliability and the performance of Docker images. Previous studies showed that Dockerfile smells are widely diffused, and there is a lack of automatic tools that support developers in fixing them. However, it is still unclear what Dockerfile smells get fixed by developers and to what extent developers would be willing to fix smells in the first place. Objective. The aim of our exploratory study is twofold. First, we want to understand what Dockerfiles smells receive more attention from developers, i.e., are fixed more frequently in the history of open-source projects. Second, we want to check if developers are willing to accept changes aimed at fixing Dockerfile smells (e.g., generated by an automated tool), to understand if they care about them. Method. In the first part of the study, we will evaluate the survivability of Dockerfile smells on a state-of-the-art dataset composed of 9.4M unique Dockerfiles. We rely on a state-of-the-art tool (hadolint) for detecting which Dockerfile smells disappear during the evolution of Dockerfiles, and we will manually analyze a large sample of such cases to understand if developers fixed them and if they were aware of the smell. In the second part, we will detect smelly Dockerfiles on a set of GitHub projects, and we will use a rule-based tool to automatically fix them. Finally, we will open pull requests proposing the modifications to developers, and we will quantitatively and qualitatively evaluate their outcome.

cs.SE↗

arXiv2021

Evaluating SZZ Implementations Through a Developer-informed Oracle

The SZZ algorithm for identifying bug-inducing changes has been widely used to evaluate defect prediction techniques and to empirically investigate when, how, and by whom bugs are introduced. Over the years, researchers have proposed several heuristics to improve the SZZ accuracy, providing various implementations of SZZ. However, fairly evaluating those implementations on a reliable oracle is an open problem: SZZ evaluations usually rely on (i) the manual analysis of the SZZ output to classify the identified bug-inducing commits as true or false positives; or (ii) a golden set linking bug-fixing and bug-inducing commits. In both cases, these manual evaluations are performed by researchers with limited knowledge of the studied subject systems. Ideally, there should be a golden set created by the original developers of the studied systems. We propose a methodology to build a "developer-informed" oracle for the evaluation of SZZ variants. We use Natural Language Processing (NLP) to identify bug-fixing commits in which developers explicitly reference the commit(s) that introduced a fixed bug. This was followed by a manual filtering step aimed at ensuring the quality and accuracy of the oracle. Once built, we used the oracle to evaluate several variants of the SZZ algorithm in terms of their accuracy. Our evaluation helped us to distill a set of lessons learned to further improve the SZZ algorithm.

cs.SE↗