600 research outputs found
rieder/amuse-masc: Binaries
No full textAdds support for binaries
Full Changelog: https://github.com/rieder/amuse-masc/compare/0.7.0...0.8.
FEVER: Extracting Feature-oriented Changes from Commits
No full textThe study of the evolution of highly configurable systems requires a thorough understanding of thee core ingredients of such systems: (1) the underlying variability model; (2) the assets that together implement the configurable features; and (3) the mapping from variable features to actual assets. Unfortunately, to date no systematic way to obtain such information at a sufficiently fine grained level exists. To remedy this problem we propose FEVER and its instantiation for the Linux kernel. FEVER extracts detailed information on changes in variability models (KConfig files), assets (preprocessor based C code), and mappings (Make- files). We describe how FEVER works, and apply it to several releases of the Linux kernel. Our evaluation on 300 randomly selected commits, from two different releases, shows our results are accurate in 82.6% of the commits. Fur- thermore, we illustrate how the populated FEVER graph database thus obtained can be used in typical Linux engineering tasks.Software TechnologyElectrical Engineering, Mathematics and Computer Scienc
Detecting PII in Git commits
No full textWith the advancement of technology, organizations are experiencing more trouble with keeping their data private with it often leaked to the public via their code-repositories or databases. There are methods to counter the leakage of data while pushing code to a repository however, these are heavily reliant on regular expressions. Personal names, locations and other Personally Identifiable Information (PII) do not follow a reoccurring pattern and can thus only be prevented by manual code reviews, which are also prone to errors. A tool to detect these PII should be designed as an initial measure to counteract the leakage. In this paper, we propose a heavily modifiable tool in which we combine the strength of regular expressions with a state-of-the-art machine learning model to detect a variety of important PII within the code changes of Python software projects. We use CodeBERT, a RoBERTa-like Transformer model, as our PII recognizer. This recognizer is fine-tuned using the Scikit-learn library of which we injected the git commits with fake sensitive data. To test and improve the quality of the model and the entire tool, we design an experimental methodology to find the optimal value for the hyper parameters of the model, compare it against another Transformer model and run the fine-tuned model against several other code-bases with different programming languages. The outcome of these experiments benefit the quality of the model in a positive way and allows us to design a robust tool with a well-performing machine learning model to detect a variety of entities. This tool can be personalized to any business and mitigate a significant part of the potential data leaks.Computer Science | Software Technolog
Curated dataset of bug fix commits from "An Empirical Study on Real Bug Fixes"
No full text<p>To cite it:</p>
<p><code>@misc{bfdataset,<br>
author = {Martin Monperrus},<br>
title = {Curated dataset of bug fix commits from "An Empirical Study on Real Bug Fixes"},<br>
year = 2017,<br>
doi = {10.5281/zenodo.1004734},<br>
url = {https://doi.org/10.5281/zenodo.1004734}<br>
}</code></p>
<pre>
</pre>
<p> </p>
1151 commits with software maintenance activity labels (corrective,perfective,adaptive)
No full text<p>Data format: CSV</p>
<p>Separator character: '#'</p>
<p><strong>This dataset contains 1151 commits manually labeled with maintenance activities ("c" for corrective, "p" for perfective, "a" for adaptive)</strong> according to the definition by Mockus et al. in <em>"Mockus, A. and Votta, L.G., 2000, October. Identifying Reasons for Software Changes using Historic Databases. In icsm (pp. 120-130)"</em>.</p>
<p>In addition, this dataset also contains <strong>further information (features) extracted from the commits</strong>:</p>
<ol>
<li>The <strong>source code changes</strong> performed by the commit author as part of a given commit (statement added, statement removed, etc.)
<ul>
<li>The source code change taxonomy is detailed in <em>"Fluri, B. and Gall, H.C., 2006, June. Classifying change types for qualifying change couplings. In Program Comprehension, 2006. ICPC 2006. 14th IEEE International Conference on (pp. 35-45). IEEE."</em></li>
</ul>
</li>
<li>A binary indication (1/0) whether a given commit contains any of the <strong>keywords from a pre-computed </strong>(according to a word frequency analysis)<strong> set of keywords</strong> <strong>indicative of each maintenance activity</strong>.</li>
</ol>
<p>The dataset consists of commits sampled from the following open source projects:</p>
<ol>
<li>RxJava</li>
<li>hbase</li>
<li>elasticsearch</li>
<li>intellij-community</li>
<li>hadoop</li>
<li>drools</li>
<li>kotlin</li>
<li>restlet-framework-java</li>
<li>orientdb</li>
<li>camel</li>
<li>spring-framework </li>
</ol>
<p>This dataset is a supporting material for the paper <strong>"Boosting Automatic Commit Classification Into Maintenance Activities By Utilizing Source Code Changes", to appear in PROMISE 2017.</strong></p>
359,569 commits with source code density; 1149 commits of which have software maintenance activity labels (adaptive, corrective, perfective)
No full text<p>This dataset comes as SQL-importable file and is compatible with the widely available MariaDB- and MySQL-databases.</p>
<p>It is based on (and incorporates/extends) the dataset "<em>1151 commits with software maintenance activity labels (corrective,perfective,adaptive)</em>" by Levin and Yehudai (<a href="https://doi.org/10.5281/zenodo.835534">https://doi.org/10.5281/zenodo.835534</a>).</p>
<p>The extensions to this dataset were obtained using <em>Git-Tools</em>, a tool that is included in the <strong>Git-Density</strong> (<a href="https://doi.org/10.5281/zenodo.2565238">https://doi.org/10.5281/zenodo.2565238</a>) suite. For each of the projects in the original dataset, Git-Tools was run in <em>extended</em> mode.</p>
<p>The dataset contains these tables:</p>
<ul>
<li><strong>x1151</strong>: The original dataset from Levin and Yehudai.
<ul>
<li>despite its name, this dataset has only 1,149 commits, as two commits were duplicates in the original dataset.</li>
<li>This dataset spanned 11 projects, each of which had between 99 and 114 commits</li>
<li>This dataset has <strong>71</strong> features and spans the projects <em>RxJava, hbase, elasticsearch, intellij-community, hadoop, drools, Kotlin, restlet-framework-java, orientdb, camel</em> and <em>spring-framework</em>.</li>
</ul>
</li>
<li><strong>gtools_ex</strong> (short for <em>Git-Tools, extended</em>)
<ul>
<li>Contains <strong>359,569</strong> commits, analyzed using Git-Tools in extended mode</li>
<li>It spans all commits and projects from the x1151 dataset as well.</li>
<li>All 11 projects were analyzed, from the initial commit until the end of January 2019. For the projects <em>Intellij</em> and <em>Kotlin</em>, the first 35,000 resp. 30,000 commits were analyzed.</li>
<li>This dataset introduces <strong>35 new</strong> features (see list below), 22 of which are <em><strong>size</strong></em>- or <em><strong>density</strong></em>-related.</li>
</ul>
</li>
</ul>
<p>The dataset contains these views:</p>
<ul>
<li><strong>geX_L</strong> (short for Git-<em>tools, extended, with labels</em>)
<ul>
<li>Joins the commits' labels from <em>x1151</em> with the extended attributes from <em>gtools_ex</em>, using the commits' hashes.</li>
</ul>
</li>
<li><strong>jeX_L</strong> (short for <em>joined, extended, with labels</em>)
<ul>
<li>Joins the datasets <em>x1151</em> and <em>gtools_ex</em> entirely, based on the commits' hashes.</li>
</ul>
</li>
</ul>
<p> </p>
<p>Features of the <strong>gtools_ex</strong> dataset:</p>
<ul>
<li><strong>SHA1</strong></li>
<li><strong>RepoPathOrUrl</strong></li>
<li><strong>AuthorName</strong></li>
<li><strong>CommitterName</strong></li>
<li><strong>AuthorTime </strong>(UTC)</li>
<li><strong>CommitterTime </strong>(UTC)</li>
<li><strong>MinutesSincePreviousCommit</strong>: Double, describing the amount of minutes that passed since the previous commit. Previous refers to the <strong>parent</strong> commit, not the previous in time.</li>
<li><strong>Message</strong>: The commit's message/comment</li>
<li><strong>AuthorEmail</strong></li>
<li><strong>CommitterEmail</strong></li>
<li><strong>AuthorNominalLabel</strong>: All authors of a repository are analyzed and merged by Git-Density using some heuristic, even if they do not always use the same email address or name. This label is a unique string that helps identifying the same author across commits, even if the author did not always use the exact same identity.</li>
<li><strong>CommitterNominalLabel</strong>: The same as <em>AuthorNominalLabel</em>, but for the committer this time.</li>
<li><strong>IsInitialCommit</strong>: A boolean indicating, whether a commit is preceded by a parent or not.</li>
<li><strong>IsMergeCommit</strong>: A boolean indicating whether a commit has more than one parent.</li>
<li><strong>NumberOfParentCommits</strong></li>
<li><strong>ParentCommitSHA1s</strong>: A comma-concatenated string of the parents' SHA1 IDs</li>
<li><strong>NumberOfFilesAdded</strong></li>
<li><strong>NumberOfFilesAddedNet</strong>: Like the previous property, but if the net-size of all changes of an added file is zero (i.e. when adding a file that is empty/whitespace or does not contain code), then this property does not count the file.</li>
<li><strong>NumberOfLinesAddedByAddedFiles</strong></li>
<li><strong>NumberOfLinesAddedByAddedFilesNet</strong>: Like the previous property, but counts the net-lines</li>
<li><strong>NumberOfFilesDeleted</strong></li>
<li><strong>NumberOfFilesDeletedNet</strong>: Like the previous property, but considers only files that had net-changes</li>
<li><strong>NumberOfLinesDeletedByDeletedFiles</strong></li>
<li><strong>NumberOfLinesDeletedByDeletedFilesNet</strong>: Like the previous property, but counts the net-lines</li>
<li><strong>NumberOfFilesModified</strong></li>
<li><strong>NumberOfFilesModifiedNet</strong>: Like the previous property, but considers only files that had net-changes</li>
<li><strong>NumberOfFilesRenamed</strong></li>
<li><strong>NumberOfFilesRenamedNet</strong>: Like the previous property, but considers only files that had net-changes</li>
<li><strong>NumberOfLinesAddedByModifiedFiles</strong></li>
<li><strong>NumberOfLinesAddedByModifiedFilesNet</strong>: Like the previous property, but counts the net-lines</li>
<li><strong>NumberOfLinesDeletedByModifiedFiles</strong></li>
<li><strong>NumberOfLinesDeletedByModifiedFilesNet</strong>: Like the previous property, but counts the net-lines</li>
<li><strong>NumberOfLinesAddedByRenamedFiles</strong></li>
<li><strong>NumberOfLinesAddedByRenamedFilesNet</strong>: Like the previous property, but counts the net-lines</li>
<li><strong>NumberOfLinesDeletedByRenamedFiles</strong></li>
<li><strong>NumberOfLinesDeletedByRenamedFilesNet</strong>: Like the previous property, but counts the net-lines</li>
<li><strong>Density</strong>: The ratio between the two sums of all lines added+deleted+modified+renamed and their resp. gross-version. A density of zero means that the sum of net-lines is zero (i.e. all lines changes were just whitespace, comments etc.). A density of of 1 means that all changed net-lines contribute to the gross-size of the commit (i.e. no useless lines with e.g. only comments or whitespace).</li>
<li><strong>AffectedFilesRatioNet</strong>: The ratio between the sums of <em>NumberOfFilesXXX</em> and <em>NumberOfFilesXXXNet</em></li>
</ul>
<p> </p>
<p>This dataset is supporting the paper <strong>"<em>Importance and Aptitude of Source code Density for Commit Classification into Maintenance Activities</em></strong><strong>"</strong>, as submitted to the <em>QRS2019</em> conference (The 19th IEEE International Conference on Software Quality, Reliability, and Security). Citation: Hönel, S., Ericsson, M., Löwe, W. and Wingkvist, A., 2019. Importance and Aptitude of Source code Density for Commit Classification into Maintenance Activities. In <em>The 19th IEEE International Conference on Software Quality, Reliability, and Security</em>.</p>The dataset was compressed using 7z and the PPMd algorithm
Commits Analysis for Author Expertise
No full textEmpirical Analysis on CI/CD Pipeline Evolution in Machine Learning Projects</p
Dataset of Grouped Commit Author IDs after Identity Resolution
No full textThis Dataset contains the SHA1 values of IDs for 5,427,024 commit authors who have created commits in git version control system, and have more than 1 ID in git. It is a compressed CSV file (separated by ; ) with 14,861,538 author IDs, where the first column is the group ID, which is same as the first (randomly selected) author ID of the group, and the second column is the author ID that is part of the group. If an author was found to have 2 different IDs: I1, I2, then it is recorded in the file in 2 separate lines, with the lines being I1;I1 and I1;I2, i.e. the first column is the group identifier, which is one of the IDs in a group, and the second column contains the different author IDs in separate lines. Author IDs consist of the Author's name and email address in the format: Name .</p
Dataset of Grouped Commit Author IDs after Identity Resolution
No full textThis Dataset contains the IDs of 5,427,024 commit authors who have created commits in git version control system, and have more than 1 ID in git. It is a compressed CSV file (separated by ; ) with 14,861,538 author IDs, where the first column is the group ID, which is same as the first (randomly selected) author ID of the group, and the second column is the author ID that is part of the group. If an author was found to have 2 different IDs: I1, I2, then it is recorded in the file in 2 separate lines, with the lines being I1;I1 and I1;I2, i.e. the first column is the group identifier, which is one of the IDs in a group, and the second column contains the different author IDs in separate lines.</p
Everybody Commits Crimes (Analysis of Legal Culpability and Human Behavior)
No full textabstract: Realistically, everyone should either be in jail or in court for crimes that everybody
commits. Outside of the house, there are people speeding, jaywalking, littering, sharing
medication, and driving without seat belts. Inside the house, people are downloading
music/movies, drinking while underage, using (and abusing) social media while under the age of
18, and reading another person’s mail. With so much of a focus on serious crimes, or felonies,
people tend to forget about the everyday actions in America that are also illegal. For example, a
police officer may not do anything if several cars are going well over the speed limit on the
highway, because it is normalized. This paper explores two sides of this issue: the psychological
side and the legal side. The goal is to find out how culpable people really are for their actions
when they do not have the mental intent that the they are determined to have in court. All human
behavior will be divided into two sections (people with non-extreme mental disorders and people
who have total control over their behavior). First, I dive into the complexity of anxiety,
depression, and ADHD, and explain how these disorders will subtly change someone’s behavior.
Next, I examine how actions like speeding and jaywalking and explain how certain illegal
actions have become so normalized that people may not be very guilty, even when they are
knowingly committing these crimes. I use different misdemeanors as examples for each of these
types of behaviors to argue why people should be more culpable (aggravating factors) or less
culpable (mitigating factors) because of their respective predispositions. Finally, I discuss issues
of fixing the criminal justice system such as: how to make all punishments fair/accurate, how to
fix the public’s distrust towards the law, and how to stop these normalized illegal behaviors for
all people, regardless of mental health or intent
- …
