[logseq-plugin-git:commit] 2025-07-02T09:50:30.863Z
This commit is contained in:
Binary file not shown.
|
After Width: | Height: | Size: 627 KiB |
@@ -2980,7 +2980,7 @@ This paper investigates the conceptual and technical feasibility of a new softwa
|
|||||||
\par
|
\par
|
||||||
9F5F2G9D\{"readingTime":\{"page":8,"data":\{"0":760,"1":680,"2":850,"3":120,"4":50,"5":50,"6":70,"7":70\}\}\}
|
9F5F2G9D\{"readingTime":\{"page":8,"data":\{"0":760,"1":680,"2":850,"3":120,"4":50,"5":50,"6":70,"7":70\}\}\}
|
||||||
\par
|
\par
|
||||||
9G4B4RYG\{"readingTime":\{"page":477,"data":\{"0":30,"2":10,"3":20,"4":10,"7":20,"14":10,"17":140,"18":40,"19":10,"20":40,"21":30,"22":10,"25":220,"26":180,"27":140,"28":110,"29":40,"30":40,"31":340,"32":250,"33":90,"34":300,"35":340,"36":490,"37":220,"38":410,"39":230,"40":80,"399":10,"400":20\}\}\}
|
9G4B4RYG\{"readingTime":\{"page":477,"data":\{"0":30,"2":10,"3":20,"4":10,"7":20,"14":10,"17":140,"18":40,"19":10,"20":40,"21":30,"22":10,"25":220,"26":180,"27":140,"28":110,"29":40,"30":40,"31":340,"32":250,"33":90,"34":300,"35":340,"36":490,"37":220,"38":410,"39":230,"40":110,"41":10,"399":10,"400":20\}\}\}
|
||||||
\par
|
\par
|
||||||
9QF9CWEH\{"readingTime":\{"page":44,"data":\{"0":30\}\}\}
|
9QF9CWEH\{"readingTime":\{"page":44,"data":\{"0":30\}\}\}
|
||||||
\par
|
\par
|
||||||
@@ -2998,7 +2998,7 @@ A922CEM7\{"readingTime":\{"page":6,"data":\{"0":70,"1":10\}\}\}
|
|||||||
\par
|
\par
|
||||||
AB7CRAXD\{"readingTime":\{"page":30,"data":\{"0":140,"1":50,"2":110,"3":190,"4":310,"5":170,"6":230,"7":140,"8":240,"9":220,"10":70,"11":120,"12":180,"13":560,"14":340,"15":230,"16":160,"17":330,"18":190,"19":140,"22":20,"23":10,"26":40,"28":80,"29":20\}\}\}
|
AB7CRAXD\{"readingTime":\{"page":30,"data":\{"0":140,"1":50,"2":110,"3":190,"4":310,"5":170,"6":230,"7":140,"8":240,"9":220,"10":70,"11":120,"12":180,"13":560,"14":340,"15":230,"16":160,"17":330,"18":190,"19":140,"22":20,"23":10,"26":40,"28":80,"29":20\}\}\}
|
||||||
\par
|
\par
|
||||||
AI3NY5EV\{"readingTime":\{"page":17,"data":\{"5":90,"6":10\}\}\}
|
AI3NY5EV\{"readingTime":\{"page":17,"data":\{"5":100,"6":10\}\}\}
|
||||||
\par
|
\par
|
||||||
AT23QI2D\{"readingTime":\{"page":17,"data":\{"0":20\}\}\}
|
AT23QI2D\{"readingTime":\{"page":17,"data":\{"0":20\}\}\}
|
||||||
\par
|
\par
|
||||||
@@ -3010,9 +3010,13 @@ BD6CUQXU\{"readingTime":\{"page":298,"data":\{"3":10,"9":10,"109":10,"115":10,"1
|
|||||||
\par
|
\par
|
||||||
C6XDG4BZ\{"readingTime":\{"page":23,"data":\{"0":90,"1":60,"2":10,"4":10,"7":10,"8":160\}\}\}
|
C6XDG4BZ\{"readingTime":\{"page":23,"data":\{"0":90,"1":60,"2":10,"4":10,"7":10,"8":160\}\}\}
|
||||||
\par
|
\par
|
||||||
|
C7RUHIEZ\{"readingTime":\{"page":7,"data":\{"0":660,"1":760,"2":380,"3":760,"4":170,"5":150\}\}\}
|
||||||
|
\par
|
||||||
|
CFCTHT5R\{"readingTime":\{"page":17,"data":\{"0":10,"2":10,"3":20\}\}\}
|
||||||
|
\par
|
||||||
D7IJSMGJ\{"readingTime":\{"page":288,"data":\{"0":10,"6":20,"10":10,"63":10,"66":10,"115":10,"116":10,"118":10\}\}\}
|
D7IJSMGJ\{"readingTime":\{"page":288,"data":\{"0":10,"6":20,"10":10,"63":10,"66":10,"115":10,"116":10,"118":10\}\}\}
|
||||||
\par
|
\par
|
||||||
DMQKA893\{"readingTime":\{"page":7,"data":\{"0":20,"1":10,"2":10\}\}\}
|
DMQKA893\{"readingTime":\{"page":7,"data":\{"0":900,"1":1050,"2":700,"3":380,"4":340,"5":380\}\}\}
|
||||||
\par
|
\par
|
||||||
G8G3WY38\{"readingTime":\{"page":12,"data":\{"0":550,"1":790,"2":940,"3":980,"4":760,"5":720,"6":400,"7":130,"8":60,"9":30\}\}\}
|
G8G3WY38\{"readingTime":\{"page":12,"data":\{"0":550,"1":790,"2":940,"3":980,"4":760,"5":720,"6":400,"7":130,"8":60,"9":30\}\}\}
|
||||||
\par
|
\par
|
||||||
@@ -7124,6 +7128,19 @@ The authors discuss challenges to and recommendations for implementing such inst
|
|||||||
keywords = {⛔ No INSPIRE recid found}
|
keywords = {⛔ No INSPIRE recid found}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@online{belcakSmallLanguageModels2025,
|
||||||
|
title = {Small {{Language Models}} Are the {{Future}} of {{Agentic AI}}},
|
||||||
|
author = {Belcak, Peter and Heinrich, Greg and Diao, Shizhe and Fu, Yonggan and Dong, Xin and Muralidharan, Saurav and Lin, Yingyan Celine and Molchanov, Pavlo},
|
||||||
|
date = {2025-06-02},
|
||||||
|
eprint = {2506.02153},
|
||||||
|
eprinttype = {arXiv},
|
||||||
|
eprintclass = {cs},
|
||||||
|
doi = {10.48550/arXiv.2506.02153},
|
||||||
|
abstract = {Large language models (LLMs) are often praised for exhibiting near-human performance on a wide range of tasks and valued for their ability to hold a general conversation. The rise of agentic AI systems is, however, ushering in a mass of applications in which language models perform a small number of specialized tasks repetitively and with little variation. Here we lay out the position that small language models (SLMs) are sufficiently powerful, inherently more suitable, and necessarily more economical for many invocations in agentic systems, and are therefore the future of agentic AI. Our argumentation is grounded in the current level of capabilities exhibited by SLMs, the common architectures of agentic systems, and the economy of LM deployment. We further argue that in situations where general-purpose conversational abilities are essential, heterogeneous agentic systems (i.e., agents invoking multiple different models) are the natural choice. We discuss the potential barriers for the adoption of SLMs in agentic systems and outline a general LLM-to-SLM agent conversion algorithm. Our position, formulated as a value statement, highlights the significance of the operational and economic impact even a partial shift from LLMs to SLMs is to have on the AI agent industry. We aim to stimulate the discussion on the effective use of AI resources and hope to advance the efforts to lower the costs of AI of the present day. Calling for both contributions to and critique of our position, we commit to publishing all such correspondence at https://research.nvidia.com/labs/lpr/slm-agents.},
|
||||||
|
pubstate = {prepublished},
|
||||||
|
keywords = {Computer Science - Artificial Intelligence}
|
||||||
|
}
|
||||||
|
|
||||||
@article{belgacemAutomatedAnomalyDetection2024,
|
@article{belgacemAutomatedAnomalyDetection2024,
|
||||||
title = {Automated Anomaly Detection for Categorical Data by Repurposing a Form Filling Recommender System},
|
title = {Automated Anomaly Detection for Categorical Data by Repurposing a Form Filling Recommender System},
|
||||||
author = {Belgacem, Hichem and Li, Xiaochen and Bianculli, Domenico and Briand, Lionel},
|
author = {Belgacem, Hichem and Li, Xiaochen and Bianculli, Domenico and Briand, Lionel},
|
||||||
@@ -18655,11 +18672,372 @@ This work proposes a novel approach, which overcomes limitations by using semant
|
|||||||
}
|
}
|
||||||
|
|
||||||
@misc{ESEM25_paper_239,
|
@misc{ESEM25_paper_239,
|
||||||
title = {{{ESEM25}}\_paper\_239}
|
title = {{{ESEM25}}\_paper\_239},
|
||||||
|
keywords = {LOGSEQ},
|
||||||
|
note = {\section{Annotazioni\\
|
||||||
|
(26/6/2025, 09:15:21)}
|
||||||
|
|
||||||
|
\par
|
||||||
|
- “Code Retrieval” (“ESEM25\_paper\_239”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Commit Message Generation” (“ESEM25\_paper\_239”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “A commit message describes the main code changes in a commit and plays a crucial role in software maintenance” (“ESEM25\_paper\_239”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Existing commit message generation (CMG) approaches typically frame it as a direct mapping that takes a code diff as input and produces a brief descriptive sentence as output.” (“ESEM25\_paper\_239”, p. 1) \#a28ae5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “argue” (“ESEM25\_paper\_239”, p. 1) \#f19837\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “relying solely on the code diff is insufficient,” (“ESEM25\_paper\_239”, p. 1) \#a28ae5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “C3Gen to enhance CMG” (“ESEM25\_paper\_239”, p. 1) \#a28ae5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “richer contextual information at the repository scope.” (“ESEM25\_paper\_239”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “conduct a human evaluation” (“ESEM25\_paper\_239”, p. 1) \#e56eee\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “commits serve as the fundamental unit for recording the evolution of code” (“ESEM25\_paper\_239”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “The commit message is intended to describe the nature, motivation, and potential impact of the corresponding code changes” (“ESEM25\_paper\_239”, p. 1) \#a28ae5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “facilitate effective collaboration within development teams” (“ESEM25\_paper\_239”, p. 1) \#f19837\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “composing informative commit messages can be both timeconsuming and labor-intensive for developers” (“ESEM25\_paper\_239”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “As a result, in real-world development settings, the overall quality of commit messages is often suboptimal” (“ESEM25\_paper\_239”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “CMG has emerged as a prominent topic in automated software engineering, attracting growing attention from the research community” (“ESEM25\_paper\_239”, p. 1) \#ffd400\\
|
||||||
|
\mkbibemph{Necessary a reference to support this statement. }
|
||||||
|
\par
|
||||||
|
- “f that maps a code diff to a message, i.e., f (diff) → message.” (“ESEM25\_paper\_239”, p. 1) \#e56eee\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “the .diff file in Git only contains a limited window of code around the chang” (“ESEM25\_paper\_239”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “enhancing the input context, such that the model can generate semantically rich commit messages that better capture the global development intent” (“ESEM25\_paper\_239”, p. 1) \#a28ae5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “we propose C3Gen, a retrieval-augmented framework designed to enhance commit message generation by incorporating relevant contextual code snippets alongside the code diff” (“ESEM25\_paper\_239”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “C3Gen enables models to effectively leverage additional contextual information, thereby improving the completeness of the generated commit message” (“ESEM25\_paper\_239”, p. 1) \#e56eee\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “predefined rules or templates” (“ESEM25\_paper\_239”, p. 2) \#e56eee\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Retrieval-based approaches leverage information retrieval (IR) techniques to suggest commit messages from similar code diff.” (“ESEM25\_paper\_239”, p. 2) \#e56eee\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “These methods leverage large-scale diff-message datasets to train deep neural networks capable of learning how to generate commit messages.” (“ESEM25\_paper\_239”, p. 2) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “However, none of these approaches incorporate commit-relevant code snippets to provide the model with repository-level code context, which we argue is important for capturing the global scope of changes and the underlying development intent.” (“ESEM25\_paper\_239”, p. 2) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Contextual Code-aware Commit Message Generation” (“ESEM25\_paper\_239”, p. 2) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “identifying program entities t” (“ESEM25\_paper\_239”, p. 2) \#ffd400\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “incorporating richer contextual information into the generation process” (“ESEM25\_paper\_239”, p. 2) \#ffd400\\
|
||||||
|
\mkbibemph{why locating and considering program entities that invoke or instantiate the motified functions should imply having a better commit message? Commit messages should describe the changes being committed and not the code related to them. }
|
||||||
|
\par
|
||||||
|
- “(1) constructing Code Structure Graphs (CSGs)” (“ESEM25\_paper\_239”, p. 2) \#2ea8e5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “(2) enriching the CSG with diff-related modifications” (“ESEM25\_paper\_239”, p. 2) \#2ea8e5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “(3) extracting contextually relevant code snippets for the later commit message generation” (“ESEM25\_paper\_239”, p. 2) \#2ea8e5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “CSGs” (“ESEM25\_paper\_239”, p. 2) \#ffd400\\
|
||||||
|
\mkbibemph{Code Structure Graphs: is it like abstract syntax trees or something different? }
|
||||||
|
\par
|
||||||
|
- “extract the names of classes or functions, their file paths, as well as the start and end lines of the class or function definitions.” (“ESEM25\_paper\_239”, p. 2) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “These elements extracted from each sourcecode file are serialized and stored in one JSON file, and the JSON files of all sourcecode files in the codebase are referred to DefinitionIndex” (“ESEM25\_paper\_239”, p. 2) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “CSG of each source code file in the codebases is constructed based on the corresponding JSON file in DefinitionIndex” (“ESEM25\_paper\_239”, p. 2) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “The edges between S-node and F-node/C-node denote that the functions and/or classes are defined in this source code file.” (“ESEM25\_paper\_239”, p. 2) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “augmented with information related to code changes, which point to the specified code diff.” (“ESEM25\_paper\_239”, p. 2) \#a28ae5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “removing duplicates” (“ESEM25\_paper\_239”, p. 3) \#ffd400\\
|
||||||
|
\mkbibemph{why duplicates? The example shown in Fig. 1 should be referred during the discussion to make the sentence easy to understand. }
|
||||||
|
\par
|
||||||
|
- “identify the source code files that are invoked by the functions or instantiate the classes defined in this source code file” (“ESEM25\_paper\_239”, p. 3) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “the corresponding C-nodes or Fnodes in the CSG of this source code file will be augmented with code diff information.” (“ESEM25\_paper\_239”, p. 3) \#ffd400\\
|
||||||
|
\mkbibemph{how is this augmentation is done? What does it mean? What does the augmentation consist of? }
|
||||||
|
\par
|
||||||
|
- “D-nodes to cover the names and paths of the invoked source code files as well as the line number referring to the locations of instantiation, invocation, etc.” (“ESEM25\_paper\_239”, p. 3) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “For each entity in ModifiedEntityList, we locate its corresponding information nodes in the CSG to retrieve all the recorded invocations or instantiations. If the invocation occurs within the definition of one function or class, the entire body of the enclosing function or class will be extracted by using the elements from DefinitionIndex.” (“ESEM25\_paper\_239”, p. 3) \#ffd400\\
|
||||||
|
\mkbibemph{here we need an examples. It's difficult to grasp the details of what you are doing here }
|
||||||
|
\par
|
||||||
|
- “If the invocation is located in a global scope or unstructured block, 25 lines before and after the invocation will be selected to as a heuristic for contextual relevance of the specified code diff.” (“ESEM25\_paper\_239”, p. 3) \#ffd400\\
|
||||||
|
\mkbibemph{Is this number defined empirically, or how? }
|
||||||
|
\par
|
||||||
|
- “extracted segments is treated as the Relevant Code Context corresponding to the commit message, and will be used to enrich the input to the commit message generation model.” (“ESEM25\_paper\_239”, p. 3) \#ffd400\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “context,C3Gen” (“ESEM25\_paper\_239”, p. 3) \#ff6666\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “only by the immediate code changes but also by their usage, dependencies, and interactions across the broader codebase. This contributes to more semantically accurate and contextaware natural language summaries of code commits.” (“ESEM25\_paper\_239”, p. 3) \#ffd400\\
|
||||||
|
\mkbibemph{Can you give an example of what is supposed to be the right commit message compare to one that is generated by currently available CMG approaches?
|
||||||
|
|
||||||
|
Can you define the quality of commit messages? What is it expected to be a good commit message? How have you driven the work towards the achievement of such quality factors? }
|
||||||
|
\par
|
||||||
|
- “Furthermore, persistent issues with respect to data quality and construction methodologies continue to plague existing datasets” (“ESEM25\_paper\_239”, p. 3) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Zhang et al. have revealed that specific datasets did not implement rigorous quality filtering on source repositories, resulting in commit messages that exhibit marked inconsistent clarity and adherence to conventions [3].” (“ESEM25\_paper\_239”, p. 3) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “incomplete data fields” (“ESEM25\_paper\_239”, p. 3) \#ffd400\\
|
||||||
|
\mkbibemph{which one, can you give some examples? }
|
||||||
|
\par
|
||||||
|
- “A. Data Selection and Collection” (“ESEM25\_paper\_239”, p. 3) \#2ea8e5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “GitHub Specifically” (“ESEM25\_paper\_239”, p. 3) \#ff6666\\
|
||||||
|
\mkbibemph{missing "." }
|
||||||
|
\par
|
||||||
|
- “et.” (“ESEM25\_paper\_239”, p. 3) \#ff6666\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “the diff and its associated retrieved code snippets as input,” (“ESEM25\_paper\_239”, p. 4) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “In our experiments, four representative LLMs, i.e., GPT4o, GPT-4.1, DeepSeek V3, and DeepSeek R1, are selected to perform generation” (“ESEM25\_paper\_239”, p. 4) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “We access all models via their official APIs and uniformly set the temperature parameter to 0.0, which minimizes randomness.” (“ESEM25\_paper\_239”, p. 4) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “quantitatively measure the similarity between the commit messages automatically generated by LLMs and those written by human developers.” (“ESEM25\_paper\_239”, p. 4) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “a) BLEU” (“ESEM25\_paper\_239”, p. 4) \#2ea8e5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “b) ROUGE-L” (“ESEM25\_paper\_239”, p. 4) \#2ea8e5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “c) METEOR” (“ESEM25\_paper\_239”, p. 4) \#2ea8e5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Clarity, Completness, and Correctness.” (“ESEM25\_paper\_239”, p. 4) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Clarity is defined to evaluate how easily the commit message can be understood, considering its wording, structure, and grammar. Completeness assesses how thoroughly the commit message captures all changes in the code diff, including important and relevant contextual details. Correctness assesses how accurately the commit message reflects the actual code changes, ensuring it avoids hallucinations or misinterpretations.” (“ESEM25\_paper\_239”, p. 4) \#ffd400\\
|
||||||
|
\mkbibemph{Who assessed such metrics? Who and how measured them? }
|
||||||
|
\par
|
||||||
|
- “retrieve code segments relevant to the diff as additional information to enrich the input context” (“ESEM25\_paper\_239”, p. 4) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “assumption that providing more contextual information will help the LLM generate semantically richer commit messages, enabling it to better articulate why the change was made and what was changed.” (“ESEM25\_paper\_239”, p. 4) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “the one enhanced with our proposed C3Gen input context augmentation.” (“ESEM25\_paper\_239”, p. 4) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “These mixed results suggest that different metrics emphasize distinct aspects of similarity. It is important to note that all of these metrics approximate quality based on heuristic similarity to the ground truth.” (“ESEM25\_paper\_239”, p. 5) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “This highlights the limitations of relying solely on automatic metrics to assess semantic adequacy and human preference in the context of CMG tasks.” (“ESEM25\_paper\_239”, p. 5) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “We identified several cases that shed light on the potential reasons behind this observation. One possible reason lies in the complexity of the code diff.” (“ESEM25\_paper\_239”, p. 5) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “In many cases, the original commit message primarily describes changes to a key function, whereas the retrieval module might retrieve relevant code based on other, less central modifications.” (“ESEM25\_paper\_239”, p. 5) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “This mismatch between the source of the retrieved code and the focus of the commit message can negatively impact the evaluation metrics.” (“ESEM25\_paper\_239”, p. 5) \#ffd400\\
|
||||||
|
\mkbibemph{Yes, but this can be a sign that maybe including context information is not beneficial, because commits might not have nothing to do directly with the code that is not the subject of the code, but that uses functions or classes that have been changed! }
|
||||||
|
\par
|
||||||
|
- “This additional context may shift the generation toward a more detailed and implementationoriented style, resulting in lower similarity scores due to a mismatch in writing style rather than semantic quality.” (“ESEM25\_paper\_239”, p. 5) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “due to the inherent randomness in the output of large language models, different generations of commit messages may vary slightly in word choice.” (“ESEM25\_paper\_239”, p. 5) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “we argue that existing similarity-based objective metrics only provide heuristic approximations of generation quality. This calls for complementary human evaluation to gain deeper insights into the actual quality and semantic improvements of the generated commit messages.” (“ESEM25\_paper\_239”, p. 5) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Further analysis reveals that these objective metrics provide only heuristic approximations and fail to effectively capture the semantic improvements introduced by additional contextual code.” (“ESEM25\_paper\_239”, p. 6) \#ffd400\\
|
||||||
|
\mkbibemph{I think that's the point. The first thing to investigate is define what's a good commit message, whatever is the values of objective metrics. Once defined, then it is necessary to conceive metrics accordingly and then you can assess the quality of the proposed tool. At the current state, what can we conclude? what's the takeaway message? Is your approaching accurate? Since the metric scores for the considered balisenes do not change singnificantly, does it mean that existing tools are alrady good at the task of commit message generation? }
|
||||||
|
\par
|
||||||
|
- “C3Gen-generated commit messages” (“ESEM25\_paper\_239”, p. 6) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “For each commit instance, participants were provided with the code diff and a set of nine commit message candidates generated by different methods including the developer-written reference message” (“ESEM25\_paper\_239”, p. 6) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Key Finding 2” (“ESEM25\_paper\_239”, p. 6) \#ffd400\\
|
||||||
|
\mkbibemph{To be unbiased and valid it is necessary to do the same quality assessment also with the baseline. }
|
||||||
|
\par
|
||||||
|
- “particular,cular,” (“ESEM25\_paper\_239”, p. 6) \#ff6666\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Our experimental results demonstrate that the proposed approach significantly improves performance on the CMG task” (“ESEM25\_paper\_239”, p. 6) \#ffd400\\
|
||||||
|
\mkbibemph{This statement is not supported by the experiments that instead for some aspects represent negative results, which are ok but need to be presented as such. }
|
||||||
|
\par
|
||||||
|
- “ApacheCM, a high-quality and context-rich dataset tailored for commit message generation research.” (“ESEM25\_paper\_239”, p. 6) \#ffd400\\
|
||||||
|
\mkbibemph{This is the main contribution of the paper. C3Gen still needs improvements by following the process that I mentioned before by starting with the definition of what's a good commit message? }}
|
||||||
}
|
}
|
||||||
|
|
||||||
@misc{ESEM25_paper_260,
|
@misc{ESEM25_paper_260,
|
||||||
title = {{{ESEM25}}\_paper\_260}
|
title = {{{ESEM25}}\_paper\_260},
|
||||||
|
keywords = {LOGSEQ},
|
||||||
|
note = {\section{Annotazioni\\
|
||||||
|
(26/6/2025, 14:47:40)}
|
||||||
|
|
||||||
|
\par
|
||||||
|
- “existing comments and then synthesize a new comment, yet retrieval and generation are typically optimized in isolation, allowing irrelevant neighbors to propagate noise downstrea” (“ESEM25\_paper\_260”, p. 1) \#ffd400\\
|
||||||
|
\mkbibemph{not very clear }
|
||||||
|
\par
|
||||||
|
- “RAGSum with the aim of both effectiveness and efficiency in recommendations. RAGSum is built on top of fuse retrieval and generation using a single CodeT5 backbone” (“ESEM25\_paper\_260”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Template systems extract salient tokens and stitch them into fixed linguistic patterns [3], [4]; IR systems locate code fragments similar to a query and reuse their comments [5], [6]. Although lightweight, these methods often misalign with the precise semantics of the target snipp” (“ESEM25\_paper\_260”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Such models learned richer representations, but even the best variants struggled to bridge the modality gap between programming languages and English, leading to generic or inaccurate summaries” (“ESEM25\_paper\_260”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “train retrieval and generation components separately” (“ESEM25\_paper\_260”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “refines retrieved comments to better align with the semantics of the input code query.” (“ESEM25\_paper\_260”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “While EditSum captures essential keywords from the input code snippet during comment generation through its self-editing pipeline, the presence of irrelevant retrieved code can still degrade performance” (“ESEM25\_paper\_260”, p. 1) \#a28ae5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “MR-Sum proposed an extractor that integrates generated and retrieved comments within a unified framework, aiming to align them using an attention mechanism.” (“ESEM25\_paper\_260”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “We argue that though these approaches outperform earlier methods based on separate training paradigms, treating the retriever and generator as distinct tasks may still hinder the overall performance of comment generation.” (“ESEM25\_paper\_260”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Figure 1 we show the results of using JOINTCOM and CMR-Sum to generate comments for a given input code query. It is evident that compared to the ground-truth comment and the input code, the results generated by both JOINTCOM and CMR-Sum exhibit significant semantic inaccuracies.” (“ESEM25\_paper\_260”, p. 1) \#a28ae5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “fuse retrieval and generation within a single CodeT5” (“ESEM25\_paper\_260”, p. 1) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “RAGSum gains significant improvements with respect to the baselines.” (“ESEM25\_paper\_260”, p. 2) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “These early findings indicate that tightly coupling retrieval and generation can raise the ceiling for comment automation and motivate forthcoming industrial replications and qualitative developer studies.” (“ESEM25\_paper\_260”, p. 2) \#a28ae5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “to code” (“ESEM25\_paper\_260”, p. 2) \#ffd400\\
|
||||||
|
\mkbibemph{to code? }
|
||||||
|
\par
|
||||||
|
- “deep learning-based methods for code summarization” (“ESEM25\_paper\_260”, p. 2) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “generation models often struggle with issues such as hallucination and limited access to external knowledge, which can hinder the accuracy and completeness of the generated summaries” (“ESEM25\_paper\_260”, p. 2) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Another framework for comment generation – DECOM [23] with the multistage deliberation process which use the keywords from source code and the comment of retrieved sample to enhance the performance” (“ESEM25\_paper\_260”, p. 2) \#ffd400\\
|
||||||
|
\mkbibemph{It does not parse, please revise. }
|
||||||
|
\par
|
||||||
|
- “Recent research has concentrated on exploring various prompting techniques to better harness the potential of LLMs in this task [24] but the summaries produced by LLMs often differ significantly in expression from reference and tend to include more detailed information than those generated by traditional models [25]” (“ESEM25\_paper\_260”, p. 2) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Self-Supervised Training of Retriever;” (“ESEM25\_paper\_260”, p. 2) \#2ea8e5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “RetrieverGenerator Joint Fine-tuning” (“ESEM25\_paper\_260”, p. 2) \#2ea8e5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Self-Refinement Process” (“ESEM25\_paper\_260”, p. 2) \#2ea8e5\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “Given a code query qi and its corresponding comment ci, the CodeT5 encoder first produces two representation vectors, which, for simplicity, are also denoted as qi and ci, respectively” (“ESEM25\_paper\_260”, p. 2) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “q+ i” (“ESEM25\_paper\_260”, p. 2) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “this objective helps the model more effectively distinguish between relevant and irrelevant pairs, thereby enhancing its understanding of the semantic relationship between code and comments.” (“ESEM25\_paper\_260”, p. 3) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “RQ1: How effective is the Retriever component of RAGSum in retrieving relevant results compared to the baselines?” (“ESEM25\_paper\_260”, p. 4) \#f19837\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “RAGSum, JOINTCOM, and CMR-Sum–by comparing them to the reference comment of the input code.” (“ESEM25\_paper\_260”, p. 4) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “RQ2: How effective is RAGSum compared to the baselines?” (“ESEM25\_paper\_260”, p. 4) \#f19837\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “CMR-Sum [14] introduced a joint retriever-generator framework for code summarization, where the retriever and generator are finetuned independently.” (“ESEM25\_paper\_260”, p. 4) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “JOINTCOM [13] also employed a joint retriever-generator paradigm for comment generation,” (“ESEM25\_paper\_260”, p. 4) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “LLama-3.1-8B [16] is a Large Language Model (LLM) developed by Meta AI. Due to resource constraints, we use the 8B-parameter version for inference. In our experiments, the LLM serves as the generator in the RAG framework, with one-shot and few-shot exemplars retrieved using CodeT5 embeddings.” (“ESEM25\_paper\_260”, p. 4) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “RQ3: How does each component of RAGSum contribute to its overall performance?” (“ESEM25\_paper\_260”, p. 4) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “to each input code in the test set, and then calculated the ROUGE-L score between the retrieved comment and the ground truth comment.” (“ESEM25\_paper\_260”, p. 4) \#ffd400\\
|
||||||
|
\mkbibemph{Something that needs to be clarified is the process that generates comments by retrieving those of source code, which is similar to that under analysis. Having similar code does it always mean similar descriptive text? }
|
||||||
|
\par
|
||||||
|
- “The retriever of RAGSum is more effective and robust than the baseline methods in fetching relevant information.” (“ESEM25\_paper\_260”, p. 5) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “B. RQ2: How effective is RAGSum compared to the baselines?” (“ESEM25\_paper\_260”, p. 5) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “RAGSum increases 4.1\%, 5.31\%, 2.63\%, 3.13\% and 4.68\% in terms of C-BLEU, S-BLEU, ROUGE-L, METEOR, and CIDEr, respectively.” (“ESEM25\_paper\_260”, p. 5) \#ffd400\\
|
||||||
|
\mkbibemph{are this increase values significant? Can you discuss them from a qualitative point of view? }
|
||||||
|
\par
|
||||||
|
- “Notably, RAGSum leverages relevant knowledge to generate more context-aware comments.” (“ESEM25\_paper\_260”, p. 5) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “C. RQ3: How does each component of RAGSum contribute to its overall performance?” (“ESEM25\_paper\_260”, p. 5) \#5fb236\\
|
||||||
|
\mkbibemph{ }
|
||||||
|
\par
|
||||||
|
- “may not fully capture semantic equivalence, potentially underestimating the quality” (“ESEM25\_paper\_260”, p. 6) \#ffd400\\
|
||||||
|
\mkbibemph{This is a very tricky point, which deserves further investigation. }
|
||||||
|
\par
|
||||||
|
- “In this paper, we proposed RAGSum for automated code comment generation that effectively leverages the existing joint fine-tuning retriever and generator. Empirical evaluation of benchmark datasets showed that RAGSum significantly improved baselines in code summarization. For future work, we plan to explore more dynamic retrieval mechanisms, investigate the scalability of RAGSum to large-scale codebases, and extend our approach to support multilingual codebases and more diverse programming paradigms.” (“ESEM25\_paper\_260”, p. 6) \#5fb236\\
|
||||||
|
\mkbibemph{ }}
|
||||||
}
|
}
|
||||||
|
|
||||||
@online{EserciziDiMemoria,
|
@online{EserciziDiMemoria,
|
||||||
@@ -34317,6 +34695,7 @@ And then add a Detailed Comments section to report the notets that contain issue
|
|||||||
author = {Muctadir, Hossain Muhammad and Liao, Yanyifan and Cleophas, Loek},
|
author = {Muctadir, Hossain Muhammad and Liao, Yanyifan and Cleophas, Loek},
|
||||||
abstract = {Digital Twins (DTs) are often defined as a pairing of a physical entity (PE) and one or more virtual entities (VEs) where the latter mimics certain behaviors of the former to provide specific services. VEs are typically model-based software systems that incorporate a variety of multi-domain, multi-tool models that are essential throughout the DT’s lifecycle. Any inconsistency among these models directly affects the performance, reliability, and effectiveness of a DT. In this paper, we present a case study on consistency management of VE models contained within a DT of a microbrewery, which encapsulates the fermentation process to optimize beer production.},
|
abstract = {Digital Twins (DTs) are often defined as a pairing of a physical entity (PE) and one or more virtual entities (VEs) where the latter mimics certain behaviors of the former to provide specific services. VEs are typically model-based software systems that incorporate a variety of multi-domain, multi-tool models that are essential throughout the DT’s lifecycle. Any inconsistency among these models directly affects the performance, reliability, and effectiveness of a DT. In this paper, we present a case study on consistency management of VE models contained within a DT of a microbrewery, which encapsulates the fermentation process to optimize beer production.},
|
||||||
langid = {english},
|
langid = {english},
|
||||||
|
keywords = {LOGSEQ},
|
||||||
note = {I'm reviewing a research paper and I took the following notes:
|
note = {I'm reviewing a research paper and I took the following notes:
|
||||||
\par
|
\par
|
||||||
\section{Annotazioni\\
|
\section{Annotazioni\\
|
||||||
@@ -38098,6 +38477,7 @@ Google's monolithic repository provides a common source of truth for tens of tho
|
|||||||
author = {Pretel, Elena and Navarro, Elena and López-Jaquero, Víctor and González, Pascual and Dustdar, Schahram},
|
author = {Pretel, Elena and Navarro, Elena and López-Jaquero, Víctor and González, Pascual and Dustdar, Schahram},
|
||||||
abstract = {The entanglement property is an essential property of Digital Twins (DTs), enabling seamless interaction between the physical twin and its DT. Despite the increasing adoption of MultiAgent Systems (MAS) in DT development, there is a lack of structured guidance on how agent design can support different levels of entanglement. This paper addresses this gap by proposing a catalogue of agent design patterns tailored to support weak, simple, and strong entanglement in DTs. Each pattern is aligned with established design patterns in MAS literature. A decision model is also introduced to guide practitioners in selecting appropriate patterns based on the essential aspects of entanglement: connectivity, promptness, and association. The proposed patterns and model were applied in a real-world case study involving the design of a DT to manage study sessions for children with ADHD, demonstrating their effectiveness and practical value. The results support the feasibility and utility of our catalogue of design patterns for the entanglement of the DT.},
|
abstract = {The entanglement property is an essential property of Digital Twins (DTs), enabling seamless interaction between the physical twin and its DT. Despite the increasing adoption of MultiAgent Systems (MAS) in DT development, there is a lack of structured guidance on how agent design can support different levels of entanglement. This paper addresses this gap by proposing a catalogue of agent design patterns tailored to support weak, simple, and strong entanglement in DTs. Each pattern is aligned with established design patterns in MAS literature. A decision model is also introduced to guide practitioners in selecting appropriate patterns based on the essential aspects of entanglement: connectivity, promptness, and association. The proposed patterns and model were applied in a real-world case study involving the design of a DT to manage study sessions for children with ADHD, demonstrating their effectiveness and practical value. The results support the feasibility and utility of our catalogue of design patterns for the entanglement of the DT.},
|
||||||
langid = {english},
|
langid = {english},
|
||||||
|
keywords = {LOGSEQ},
|
||||||
note = {I'm reviewing a research paper and I took the following notes:
|
note = {I'm reviewing a research paper and I took the following notes:
|
||||||
\par
|
\par
|
||||||
\section{Annotazioni\\
|
\section{Annotazioni\\
|
||||||
@@ -52708,7 +53088,7 @@ A Cache-bAsed compoSitE algorithm, short formed as CASE, to automatically catego
|
|||||||
doi = {10.1145/3696630.3728542},
|
doi = {10.1145/3696630.3728542},
|
||||||
abstract = {Developers often evolve an existing software system by making internal changes, called migration. Moving to a new framework, changing implementation to improve efficiency, and upgrading a dependency to its latest version are examples of migrations. Migration is a common and typically continuous maintenance task undertaken either manually or through tooling. Certain migrations are labor intensive and costly, developers do not find the required work rewarding, and they may take years to complete. Hence, automation is preferred for such migrations. In this paper, we discuss a large-scale, costly and traditionally manual migration project at Google, propose a novel automated algorithm that uses change location discovery and a Large Language Model (LLM) to aid developers conduct the migration, report the results of a large case study, and discuss lessons learned. Our case study on 39 distinct migrations undertaken by three developers over twelve months shows that a total of 595 code changes with 93,574 edits have been submitted, where 74.45\% of the code changes and 69.46\% of the edits were generated by the LLM. The developers reported high satisfaction with the automated tooling, and estimated a 50\% reduction on the total time spent on the migration compared to earlier manual migrations. Our results suggest that our automated, LLM-assisted workflow can serve as a model for similar initiatives.},
|
abstract = {Developers often evolve an existing software system by making internal changes, called migration. Moving to a new framework, changing implementation to improve efficiency, and upgrading a dependency to its latest version are examples of migrations. Migration is a common and typically continuous maintenance task undertaken either manually or through tooling. Certain migrations are labor intensive and costly, developers do not find the required work rewarding, and they may take years to complete. Hence, automation is preferred for such migrations. In this paper, we discuss a large-scale, costly and traditionally manual migration project at Google, propose a novel automated algorithm that uses change location discovery and a Large Language Model (LLM) to aid developers conduct the migration, report the results of a large case study, and discuss lessons learned. Our case study on 39 distinct migrations undertaken by three developers over twelve months shows that a total of 595 code changes with 93,574 edits have been submitted, where 74.45\% of the code changes and 69.46\% of the edits were generated by the LLM. The developers reported high satisfaction with the automated tooling, and estimated a 50\% reduction on the total time spent on the migration compared to earlier manual migrations. Our results suggest that our automated, LLM-assisted workflow can serve as a model for similar initiatives.},
|
||||||
pubstate = {prepublished},
|
pubstate = {prepublished},
|
||||||
keywords = {Computer Science - Artificial Intelligence,Computer Science - Software Engineering}
|
keywords = {Computer Science - Artificial Intelligence,Computer Science - Software Engineering,LOGSEQ}
|
||||||
}
|
}
|
||||||
|
|
||||||
@article{zolotasRESTsecLowcodePlatform2018,
|
@article{zolotasRESTsecLowcodePlatform2018,
|
||||||
|
|||||||
@@ -192,7 +192,8 @@ progress:: {{renderer :todomaster}}
|
|||||||
- 
|
- 
|
||||||
- 
|
- 
|
||||||
- 
|
- 
|
||||||
- 
|
- {:height 549, :width 980}
|
||||||
|
- 
|
||||||
-
|
-
|
||||||
- ### WP5 Presentation
|
- ### WP5 Presentation
|
||||||
-
|
-
|
||||||
|
|||||||
Reference in New Issue
Block a user