Data.txt fields
Example:
ARTICLE:ANALYSIS_BY[name] studentX
ARTICLE:ANALYSIS_TIME[minutes] 4
ARTICLE:COMMENT[string]
ARTICLE:COMMERCIAL_EFFORT[none,part,full] none
ARTICLE:GRANT_SUPPORT[none or string] Supported by the National Science Foundation under grant CCF-0905509.
ARTICLE:IMPLEMENTATION_EXISTS[unknown,hardware,yes,no] yes
ARTICLE:LINK[url] http://doi.acm.org/10.1145/2400682.2400716
ARTICLE:NSF_SUPPORT[none or number] CCF-0905509.
ARTICLE:PAGE_COUNT[pages] 20
ARTICLE:STATUS[not_finished,finished] finished
ARTICLE:TYPE[conference,journal,poster,abstract] journal
AUTHOR:NAMES[list of first_last] Mehmet_E._Belviranli Laxmi_N._Bhuyan Rajiv_Gupta
BIBTEX:LABEL[string] BelviranliBG13
BIBTEX:LINK[url] http://dblp.uni-trier.de/rec/bibtex/conf/taco/BelviranliBG13
BUILD:ANALYSIS_BY[name]
BUILD:ANALYSIS_TIME[minutes]
BUILD:BENEFIT_OF_DOUBT[unknown,yes,no] unknown
BUILD:COMMENT[string]
BUILD:error-comment[none,not_needed,comment] not_needed
BUILD:STATUS[one of {unknown,needed,not_needed,started,finished} and list of {downloaded,compiles,runs}] unknown
BUILD:VERIFY_BY[name]
BUILD:VERIFY_COMMENT[string]
BUILD:VERIFY_STATUS[needed,not_needed,started,finished] not_needed
BUILD:VERIFY_TIME[minutes]
COMMENT:CORRECTION[string]
COMMENT:RESPONSE[string]
EMAIL1:CODE_AVAILABLE[yes,no,no_response] no_response
EMAIL1:REMARK[comment]
EMAIL:STATUS[unknown,not_needed,not_found or list of {needed,request_1,response_1,sent_thank_you}] needed request_1
PI:COMMENT_CC[string]
PI:COMMENT_TP[string]
TOOL:ARTICLE_LINK[unknown,none,url,broken and url] none
TOOL:DATA_LINK[unknown,none,url,broken and url]
TOOL:EMAIL_LINK[unknown,none,sent_no_url,url,broken and url]
TOOL:GOOGLE_LINK[unknown,none,url,broken and url] none
TOOL:NAME[string] HDSS
VERIFY:ANALYSIS_BY[name] studentY
VERIFY:COMMENT[string] author has tried scheduling and load balancing on different architectures, but probably they can provide their code
VERIFY:STATUS[unknown,needed,not_needed,started,finished] finished
Interpretation
ARTICLE
- ANALYSIS_BY: Original student to look at the article for code.
- ANALYSIS_TIME: How long the student took before finishing.
- COMMENT: any notes on the paper in general.
- COMMERCIAL_EFFORT: Values depending on if the paper was written with/by an industry research lab.
- GRANT_SUPPORT: Text copied from the paper regarding funding.
- IMPLEMENTATION_EXISTS: Does the paper depend on an code implementation.
- LINK: Link to where we retrieved the article.
- NSF_SUPPORT: If the work was supported by an NSF grant, this has the id.
- PAGE_COUNT: Number of pages in the pdf version we have.
- STATUS: Set to finished after the initial analysis to find code was done.
- TYPE: Indicates if poster or abstract from a conference. Or regular article.
AUTHOR
- NAMES: Names of the authors retrieved from the BibTeX.
BIBTEX
- LABEL: BibTeX label used as a key for our database.
- LINK: Link to the BibTeX file for the version we looked at.
BUILD
- ANALYSIS_BY: Who first attempted the build.
- ANALYSIS_TIME: How long was spent building the code. Goal was to spend 30 minutes or less.
- BENEFITOFDOUBT: If the paper was given the benefit of the doubt. (This was implemented after many builds were done and isn't fully used)
- COMMENT: A short description of the build results.
- ERROR_COMMENT: A tag representing categories of failed builds. Possible values are described below.
- STATUS: Status of the build, at the end all should be finished. With tags to represent the state of the build. Each build is expected to be downloaded (otherwise the code is unavailable). Compiles indicates that the code was compiled and runs if we were able to get it to start in the most rudimentary way. Some papers had online implementations and these are tagged "online runs" without the compiles tag.
- VERIFY_BY: If the code didn't build after the initial attempt a different student attempted the build.
- VERIFY_COMMENT: Any notes on the build during verification.
- VERIFY_STATUS: Recording if the verification was complete.
- VERIFY_TIME: Amount of time spent verifying the build.
COMMENT
Both of these fields use the abbreviations for paper classification that are used in the result web table and the paper's result table. The abbreviations are described below.
* CORRECTION: Comment on corrections between the first released version and the final version.
* RESPONSE: Response to what the authors have said in the survey.
EMAIL1
- CODE_AVAILABLE: If an email response showed us the code or sent it to use.
- REMARK: A tag representing the categories of different reasons for not making code available.
EMAIL
- STATUS: Representing the status of the email. Some papers were not sent emails because that would result in a single author receiving two emails by us for separate articles. (this was checked from the emails we had). We tagged these at "needed" but not "request1". "request2" was also used to indicate that a reminder was sent.
PI
- COMMENT_CC: Comment by Christian Collberg.
- COMMENT_TP: Comment by Todd Proebsting
TOOL
- ARTICLE_LINK: If a link was found in the article, it will be listed here. If the link didn't work it will also include the tag broken.
- DATA_LINK: If we found a link to data during our search it would be put here, however we didn't search for this intentionally it is often unused.
- EMAIL_LINK: If we received the link from an email request it may be here, some code was attached and others were not correctly entered here.
- GOOGLE_LINK: If the code wasn't found in the article, but was found from a Google search we put the link here.
- NAME: The name of the tool that is described in the paper.
VERIFY
- ANALYSIS_BY: The student who verified the original analysis, everything besides building and email results.
- COMMENT: Any comments on the original analysis
- STATUS: The status of the verification. Finished for all papers.
Error Categories
Possible values of the ERROR_COMMENT field.
- not_needed - Code was successfully compiled and run, was online or wasn't found.
- DISTRIBUTION_IS_MISSING_FILES - The author did not make available files that should be part of the build, such as a missing header file or a missing file with input data to run the code.
- INTERNAL_COMPILER_ERROR - Compilation terminated with the message 'Internal Compiler Error.'
- PREREQUISITE_FAILED_TO_BUILD - A pre-requisite for a tool could not be successfully built by the team.
- INCOMPLETE_DOCUMENTATION - Documentation necessary to build the software is incomplete or missing.
- MISSING_THIRD_PARTY_PACKAGE - A particular piece of software, package or tool required to run the build was not found.
- OTHER_ERRORS - The error could not be categorized.
- RUNTIME_ERROR - The code compiles and fails to run, due, for example, to a segmentation fault or a runtime exception.
The build template has space for two separate attempts to build and run the code. The name of the student is placed on one line, along with the environment. Dependencies are put between two tags and finally notes on the process are between two more tags. In some cases more than two students attempted a build.
Each attempt is marked with a number, e.g. 2:BUILD_BY is the second build attempt.
The template:
1:BUILD_BY[name]
1:BUILD_ENVIRONMENT[operating system 32 vs 64]
1:DEPENDENCIES[list of dependencies with where to get them]
1:END_DEPENDENCIES
1:NOTES[notes on attempted build]
1:END_NOTES
2:BUILD_BY[name]
2:BUILD_ENVIRONMENT[operating system 32 vs 64]
2:END_BUILD_ENVIRONMENT
2:DEPENDENCIES[list of dependencies with where to get them]
2:END_DEPENDENCIES
2:NOTES[notes on attempted build]
2:END_NOTES
Multiple authors could respond to the same survey so each survey.txt includes summary fields. These were set, either as a copy of the only author, or if conflicting author responses by a number of criteria. If the conflict had a more generous interpretation, this was taken or the conflict was resolved to match our question intention, if that was at issue.
There was confusion regarding CLASSIFICATION. We have reframed this as whether the paper is backed by code or not, rather than the loaded distinction between practical and theoretical papers.
The template:
ANONYMOUS_COMMENT[string]
BUILD_COMMENT[string]
BUILD_DIFFICULTY[not_applicable, reasonable_effort, code_problematic or string]
BUILD_DIFFICULTY_COMMENT[string]
CLASSIFICATION[practical,theoretical,hardware]
CLASSIFICATION_COMMENT[string]
CORRECT_CODE_LOCATION[string]
PUBLIC_COMMENT[string]
PUBLISHED_CODE[not_applicable, yes, no]
SAME_VERSION[not_applicable, yes, no_but_available, no_and_not_available]
SAME_VERSION_COMMENT[string]
STUDY_FOUND_CORRECT_CODE[not_applicable, yes, no]
- ANONYMOUS_COMMENT: Not included in table, but particular responses are found in the technical report.
- BUILD_DIFFICULTY: Authors opinion on the ease of building the code.
- BUILDDIFFICULTYCOMMENT: Free response on the above question.
- BUILD_COMMENT: Comment on our attempt to build the code.
- CLASSIFICATION: Whether code existed for evaluation, question caused confusion, see above.
- CLASSIFICATION_COMMENT: Any comment on the classification that we made or they made.
- CORRECTCODELOCATION: Location where the code could be found
- PUBLIC_COMMENT: Any general comment, included in the online table.
- PUBLISHED_CODE: If the code was published.
- SAME_VERSION: If the published code is the same version that was run to get the results in the paper.
- SAMEVERSIONCOMMENT: Comment on the version question.
- STUDYFOUNDCORRECT_CODE: Whether our study evaluated the correct code.
Classification Abbreviations
Classification
- BC - Paper where the results are backed by code.
- NC - Paper excluded due to results not being backed by code.
- HW - Paper excluded due to replication requiring special hardware.
- EX - Paper excluded due to overlapping author lists.
Code Location
- Article - Code is found from link in the article itself.
- Web - Code is found from a web search.
- EM_yes - Code is provided by author after email request.
- EM_no - Author responds that the code cannot be provided.
- EM_0 - Author does not respond to email request within 2 months.
Build Results
- OK_<30 - We succeed in building the system in ≤30 minutes.
- OK_>30 - We succeed in building the system in >30 minutes.
- OK_>Author - We fail to build, but the author says the code builds with reasonable effort.
- Fails - We fail to build, and the author doesn't respond to survey or says code may have problems building.