Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
2
datasets available to search
ShareScore release 0.9.0
Dataset results
2 results for “Haskell”
Data: What about Haskell Bugs?
<div> <div><span># Data Package for: "What about Haskell Bugs?"</span></div> <br> <div><span>## General Introduction</span></div> <br> <div><span>The goal of the paper is to identify the extent to which existing bug taxonomies can classify bugs in Haskell, and how they could be adapted to better accommodate the unique features of Haskell. The specific research questions that were studied are:</span></div> <div><span>RQ1 What are the most common types of Haskell bugs?</span></div> <div><span>RQ2 What are the limitations of existing bug taxonomies in capturing the unique features of Haskell bugs?</span></div> <div><span>RQ3 How do Haskell developers classify bugs and how is it different from the previously discussed taxonomies?</span></div> <br> <div><span>The data collected for the creation of the paper includes:</span></div> <div><span>• A bug dataset of 142 bugs from 10 Haskell FOSS (free open-source software) projects;</span></div> <div><span>• A qualitative codebook created after 4 interviews performed with Haskell developers about their perspectives on bugs.</span></div> <br> <div><span>## BugDB</span></div> <br> <div><span>The bug dataset contains 142 bugs, collected from 10 Haskell FOSS repositories. The repositories have been chosen from Github, to be as diverse as possible, to avoid bias towards any defect type. From each repository a number of 20 bugs were collected, or the maximum available.</span></div> <br> <div><span>The bugs have been taken based on the most recent closed issues with tags that contain the term </span><span>**bug**</span><span>. The issues were ensured to relate to commits or pull requests, which have been merged into the main branch. The code in the commits and pull requests was checked to include bug fixes for the specified bug report. They were ensured to contain true bugs in the code, and all duplicates were removed. Also, the fix of the bug needed to include a change in at least one </span><span>*.hs*</span><span> file to ensure that they are bugs related to Haskell. Note that they can modify other types of files alongside the Haskell ones.</span></div> <br> <div><span>The bug dataset has been fully classified manually, based on the two chosen taxonomies. The chosen taxonomies can be found in the </span><span>*Bug_taxonomies*</span><span> PDF file. The most relevant category from each of the taxonomies was the one chosen, but complex bugs, where a clear distinction was hard to make, have been documented. </span></div> <br> <div><span>## Codebook</span></div> <br> <div><span>Four open-source Haskell developers took part in a semi-structured interview. The interviews took approximately 30 minutes and were done online. They were audio recorded and transcribed. The participants were asked about how they identify, understand, classify, and fix bugs in practice, as well as what their opinion was on the proposed taxonomies. The participants agreed to the storage, usage and publication of data by signing an informed consent form. The data gathered during the interviews was used to construct a qualitative codebook, using a bottom-up approach.</span></div> <br> <div><span>## Description of the data in this data set</span></div> <br> <div><span>| File Name | File Format | Description |</span></div> <div><span>| --------- | ----------- | ----------- |</span></div> <div><span>| Bug_taxonomies | PDF | This file includes the 2 taxonomies used in the study. It provides the citation and an explicit description of each of the types of bugs as proposed by each respective taxonomy. |</span></div> <div><span>| Codebook | PDF | This file is the qualitative codebook produced from the 4 interviews with Haskell developers. It is split into 5 columns: Theme, Code, Explanation, Examples, and Partial-fit Examples. The last two columns include examples, relating to the specific code and theme, taken from the interview transcripts. |</span></div> <div><span>| bug_db | CSV | This file represents the bugs collected from Github issues and classified according to the 2 taxonomies. The columns are </span><span>**1.Repository**</span><span>: name of the repository from which the bug was taken; </span><span>**2.Bug Name**</span><span>: name of the issue as it appears on the GitHub page; </span><span>**3.Link to bug**</span><span>: link to the Github issue of the respective bug; </span><span>**4.Taxonomy Catolino**</span><span>: categorization according to the taxonomy proposed by Catolino et al. (See </span><span>*Bug_taxonomies*</span><span> for more information) This can only include one of the types of bugs from this taxonomy; </span><span>**5.Taxonomy Seaman**</span><span>: categorization according to the taxonomy proposed by Seaman et al. (See </span><span>*Bug_taxonomies*</span><span> for more information) This can only include one of the types of bugs from this taxonomy; </span><span>**6.Notes**</span><span>: This includes details explaining the decisions made when choosing the types for each of the bugs. When the text includes the term </span><span>*COMPLEX*</span><span>, the bug is considered a complex bug, meaning it might also fit as other types of bugs within the same taxonomy. In this case, the types are specifically mentioned after the phrase </span><span>*Might also be considered*</span><span>. | </span></div> <div><span>| bug_db_result_counts | CSV | This file contains 3 tables. The first one is the count and percentages per type of bug for the taxonomy proposed by Catolino et al. The second one is the count and percentages per type of bug for the taxonomy proposed by Seaman et al. The third one is a representation of the Complex bugs. It has 4 columns: </span><span>**Chosen type**</span><span>: the type as chosen in the taxonomy column of the complex bugs. </span><span>**Other type**</span><span>: the types as mentioned in the Notes column of the complex bugs. </span><span>**Count**</span><span>: the number of bugs that have the respective chosen type in the taxonomy column and the other type in the notes. </span><span>**Reverse count**</span><span> the number of bugs that have the chosen type in the notes column and the other type in the taxonomy column. The one bug that has 2 other types has been split into separate instances with Logic as the chosen type, one with Algorithm/Method as the other type, and one with Checking as the other type.| </span></div> <br><br> <div><span>## Interview Transcipts</span></div> <br> <div><span>The interview transcripts are not shared due to data protection. </span></div> <div><span>We have further explicitly ensured participants to not share their transcripts, but only the anonymized codebook. </span></div> </div>
Data: HasBugs - Handpicked Haskell Bugs
<p><strong>HasBugs - Handpicked Haskell Bugs</strong></p> <p>We try to provide a fresh dataset in the fashion of [Defects4J](https://github.com/rjust/defects4j) to evaluate tasks such as fault localization, program repair and test generation.</p> <p>Instead of just providing the commits, we learned from some of the datasets out there, which we address in the following: </p> <ol> <li>A failing CI does not mean a bug - atleast not certainly from the code. Hence, our bug-points are aknowledged by the projects through PRs and Issues. This also means that the *buggy version* of the datapoints usually compiles. </li> <li>Similarly, the Fix is what the maintainers consider fixed (even if that is removal of a feature).</li> <li>As research by [Martin Monperrus](https://link.springer.com/article/10.1007/s10664-016-9470-4) showed, not all found patches in program repair actually help despite passing the test-suite. To help with inspection of potential tasks, we look into the material provided (code, issues, project readme/architecture) to give a estimate of "what is buggy". We hope this helps to easier distinguish actually good result from e.g. overfitting.</li> <li>We express multiple bug and fix locations in the datapoint</li> </ol> <p>The aim of these changes is to provide a (small) dataset with bugs from real-world problems of which all steps are aknowledged by their maintainers (the bug, the test & the fix).<br> We do not try to provide a dataset in the size that you can run deep learning on it - but we want to have a quality gold standard to benchmark modern tools against.</p> <p><strong>Datapoint </strong></p> <p>For every project, we provide </p> <ul> <li>The buggy version</li> <li>The fixed version</li> <li>The separated Test-Patch, tested Version</li> <li>A datapoint for analysis (see below)</li> </ul> <p>A single datapoint can contain the following attributes (required attributes are marked with *, but these stars are not in the actual json!): </p> <pre><code class="language-javascript">{ "*id":42, "*repositoryurl": "https://github.com/ciselab/HasBugs", "*repository":"Ciselab/HasBugs", "*licence":"MIT", "*faultcommit":"xxx", "*fixcommit":"yyy", "ghc-version":"9.2.4", "buildframework":"Cabal", "testframeworks" : ["QuickCheck","Tasty"], "testpatch":true, "description": "Input Sanitazion missing - divides by zero", "categories" : ["Sanitazion", "DivideByZero"], "relatedissues" : ["https:www.github.com/ciselab/HasBugs/issues/1"], "relatedprs" : ["https:www.github.com/ciselab/HasBugs/issues/2"], "*faultlocations" : [ { "*startline": 5, "*endline": 15, "*file" : "./project/.../program.hs", "module" : "Math.Divison", "method": "divide" },{ "*startline": 25, "*endline": 35, "*file" : "./project/.../program.hs", "module" : "Math.Divison", "method": "divide" } ], "*fixlocations" : [ { "*startline": 5, "*endline": 20, "*file" : "./project/.../program.hs", "module" : "Math.Divison", "method": "divide" } ] }</code></pre> <p><strong>Inclusion Criteria </strong></p> <ol> <li>Compatible with GHC >=8.10</li> <li>Projects run with a single `make test`, `cabal test` or `stack test` </li> <li>buggy version newer than 2018</li> <li>bug and fix aknowledged as such by the maintainer(s) through Github Issues / PRs <br> </li> </ol>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.