papers: publish recent preprints and biblio info
authorStefano Zacchiroli <zack@upsilon.cc>
Fri, 27 Dec 2019 10:28:47 +0000 (11:28 +0100)
committerStefano Zacchiroli <zack@upsilon.cc>
Fri, 27 Dec 2019 10:28:47 +0000 (11:28 +0100)
research/publications.mdwn
research/publications/cise-2020-doi.bib [new file with mode: 0644]
research/publications/cise-2020-doi.pdf [new file with mode: 0644]
research/publications/cudf-ocaml-2014.bib
research/publications/debsources-ese-2016.bib
research/publications/distcheck-msr-2015.bib
research/publications/saner-2020-deps.bib [new file with mode: 0644]

index 91fee21..633429e 100644 (file)
@@ -13,6 +13,14 @@ You might also be interested in my author profiles on
 
 # <span title="international, peer-reviewed journals">international, peer-reviewed journal articles</span>
 
+ 1. <a class="paper-download" href="cise-2020-doi.pdf" title="download paper in PDF format">[.pdf]</a> <a class="bibtex-download" href="cise-2020-doi.bib" title="download bibliographic entry in BibTeX format">[.bib]</a> <a href="http://www.dicosmo.org">Roberto Di Cosmo</a>, <a href="https://moranegg.github.io/">Morane Gruenpeter</a>, <a href="http://upsilon.cc/~zack">Stefano Zacchiroli</a>. **Referencing Source Code Artifacts: a Separate Concern in Software Citation**.  <em>
+       To appear in <a href="https://www.computer.org/csdl/magazines/cs">Computing in Science
+       &amp; Engineering</a>.
+       ISSN 1521-9615, IEEE. 2020.
+      </em>
+    [[!toggle id=id78 text="Abstract..."]] [[!toggleable id=id78 text="""
+    *Abstract:* Among the entities involved in software citation, software source code requires special attention, due to the role it plays in ensuring scientific reproducibility. To reference source code we need identifiers that are not only unique and persistent, but also support integrity checking intrinsically. Suitable iden- tifiers must guarantee that denoted objects will always stay the same, without relying on external third parties and administrative processes. We analyze the role of identifiers for digital objects (IDOs), whose properties are different from, and complementary to, those of the various digital identifiers of objects (DIOs) that are today popular building blocks of software and data citation toolchains. We argue that both kinds of identifiers are needed and detail the syntax, semantics, and practical implementation of the persistent identifiers (PIDs) adopted by the Software Heritage project to reference billions of software source code artifacts such as source code files, directories, and commits.
+    """]]
  1. <a class="paper-download" href="cscw-2018-rtce.pdf" title="download paper in PDF format">[.pdf]</a> <a class="bibtex-download" href="cscw-2018-rtce.bib" title="download bibliographic entry in BibTeX format">[.bib]</a> <span class="doi_logo"><a href="http://dx.doi.org/10.1145/3274310" title="Document Object Identifier">doi&gt;</a></span> <a href="http://www.cs.unibo.it/~gdangelo/">Gabriele D'Angelo</a>, <a href="http://diiorio.web.cs.unibo.it/">Angelo Di Iorio</a>, <a href="http://upsilon.cc/~zack">Stefano Zacchiroli</a>. **Spacetime Characterization of Real-Time Collaborative Editing**.  <em>
        In <a href="https://pacmhci.acm.org/">Proceedings of
        the ACM on Human-Computer Interaction</a>,
@@ -175,15 +183,24 @@ You might also be interested in my author profiles on
 
 # <span title="international, peer-reviewed conferences">international, peer-reviewed conference proceedings</span>
 
- 1. <a class="paper-download" href="saner-2020-swh-graph.pdf" title="download paper in PDF format">[.pdf]</a> <a class="bibtex-download" href="saner-2020-swh-graph.bib" title="download bibliographic entry in BibTeX format">[.bib]</a> Paolo Boldi, <a href="https://koin.fr/">Antoine Pietri</a>, Sebastiano Vigna, <a href="http://upsilon.cc/~zack">Stefano Zacchiroli</a>. **Ultra-Large-Scale Repository Analysis via Graph Compression**.  <em>
+ 1. <a class="paper-download" href="saner-2020-swh-graph.pdf" title="download paper in PDF format">[.pdf]</a> <a class="bibtex-download" href="saner-2020-swh-graph.bib" title="download bibliographic entry in BibTeX format">[.bib]</a> <a href="http://boldi.di.unimi.it/">Paolo Boldi</a>, <a href="https://koin.fr/">Antoine Pietri</a>, <a href="http://vigna.di.unimi.it/">Sebastiano Vigna</a>, <a href="http://upsilon.cc/~zack">Stefano Zacchiroli</a>. **Ultra-Large-Scale Repository Analysis via Graph Compression**.  <em>
        To appear in proceedings of <a href="https://saner2020.csd.uwo.ca/">SANER 2020</a>: The 27th IEEE
        International Conference on Software Analysis, Evolution and
        Reengineering, February 18-21, 2020, London, Ontario,
        Canada. IEEE 2020.
       </em>
-    [[!toggle id=id76 text="Abstract..."]] [[!toggleable id=id76 text="""
+    [[!toggle id=id77 text="Abstract..."]] [[!toggleable id=id77 text="""
     *Abstract:* We consider the problem of mining the development history—as captured by modern version control systems—of ultra-large-scale software archives (e.g., tens of millions software repositories corresponding). We show that graph compression techniques can be applied to the problem, dramatically reducing the hardware resources needed to mine similarly-sized corpus. As a concrete use case we compress the full Software Heritage archive, consisting of 5 billion unique source code files and 1 billion unique commits, harvested from more than 80 million software projects—encompassing a full mirror of GitHub. The resulting compressed graph fits in less than 100 GB of RAM, corresponding to a hardware cost of less than 300 U.S. dollars. We show that the compressed in-memory representation of the full corpus can be accessed with excellent performances, with edge lookup times close to memory random access. As a sample exploitation experiment we show that the compressed graph can be used to conduct clone detection at this scale, benefiting from main memory access speed.
     """]]
+ 1. <a class="bibtex-download" href="saner-2020-deps.bib" title="download bibliographic entry in BibTeX format">[.bib]</a> <a href="http://mancoosi.org/~abate/about-me">Pietro Abate</a>, <a href="http://www.dicosmo.org">Roberto Di Cosmo</a>, <a href="http://www.gousios.gr/">Georgios Gousios</a>, <a href="http://upsilon.cc/~zack">Stefano Zacchiroli</a>. **Dependency Solving: Looking Back, Going Forward**.  <em>
+       To appear in proceedings of <a href="https://saner2020.csd.uwo.ca/">SANER 2020</a>: The 27th IEEE
+       International Conference on Software Analysis, Evolution and
+       Reengineering, February 18-21, 2020, London, Ontario,
+       Canada. IEEE 2020.
+      </em>
+    [[!toggle id=id76 text="Abstract..."]] [[!toggleable id=id76 text="""
+    *Abstract:* Dependency solving is a hard (NP-complete) problem in all non-trivial component models due to either mutually incompatible versions of the same packages or explicitly declared package conflicts. As such, software upgrade planning needs to rely on highly specialized dependency solvers, lest falling into pitfalls such as incompleteness—a combination of package versions that satisfy dependency constraints does exist, but the package manager is unable to find it. In this paper we look back at proposals from dependency solving research dating back a few years. Specifically, we review the idea of treating dependency solving as a separate concern in package manager implementations, relying on generic dependency solvers based on tried and tested techniques such as SAT solving, PBO, MILP, etc. By conducting a census of dependency solving capabilities in state-of-the-art package managers we conclude that some proposals are starting to take off (e.g., SAT-based dependency solving) while—with few exceptions—others have not (e.g., outsourcing dependency solving to reusable components). We reflect on why that has been the case and look at novel challenges for dependency solving that have emerged since.
+    """]]
  1. <a class="paper-download" href="msr-2020-challenge.pdf" title="download paper in PDF format">[.pdf]</a> <a class="bibtex-download" href="msr-2020-challenge.bib" title="download bibliographic entry in BibTeX format">[.bib]</a> <a href="https://koin.fr/">Antoine Pietri</a>, <a href="https://www.spinellis.gr">Diomidis Spinellis</a>, <a href="http://upsilon.cc/~zack">Stefano Zacchiroli</a>. **The Software Heritage Graph Dataset: Large-scale Analysis of Public Software Development History**.  <em>
        To appear in proceedings of <a href="http://2020.msrconf.org/">MSR 2020</a>: The 17th International
        Conference on Mining Software Repositories, May 2020,
diff --git a/research/publications/cise-2020-doi.bib b/research/publications/cise-2020-doi.bib
new file mode 100644 (file)
index 0000000..aba4d95
--- /dev/null
@@ -0,0 +1,9 @@
+@article{cise-2020-doi,
+  author = {Di Cosmo, Roberto and Gruenpeter, Morane and Stefano Zacchiroli},
+  title = {Referencing Source Code Artifacts: a Separate Concern in Software Citation},
+  abstract = {Among the entities involved in software citation, software source code requires special attention, due to the role it plays in ensuring scientific reproducibility. To reference source code we need identifiers that are not only unique and persistent, but also support integrity checking intrinsically. Suitable iden- tifiers must guarantee that denoted objects will always stay the same, without relying on external third parties and administrative processes. We analyze the role of identifiers for digital objects (IDOs), whose properties are different from, and complementary to, those of the various digital identifiers of objects (DIOs) that are today popular building blocks of software and data citation toolchains. We argue that both kinds of identifiers are needed and detail the syntax, semantics, and practical implementation of the persistent identifiers (PIDs) adopted by the Software Heritage project to reference billions of software source code artifacts such as source code files, directories, and commits.},
+  publisher = {IEEE},
+  year = {2020},
+  issn = {1521-9615},
+  journal = {Computing in Science &amp; Engineering},
+}
diff --git a/research/publications/cise-2020-doi.pdf b/research/publications/cise-2020-doi.pdf
new file mode 100644 (file)
index 0000000..88c2341
Binary files /dev/null and b/research/publications/cise-2020-doi.pdf differ
index 9872d8a..f4b4dda 100644 (file)
@@ -1,5 +1,5 @@
 @inproceedings{cudf-ocaml-2014,
-  author = {Pietro Abate and Di Cosmo, Roberto and Louis Gesbert and Fabrice Le Fessant and Stefano Zacchiroli},
+  author = {Pietro Abate and Di Cosmo, Roberto and Louis Gesbert and Le Fessant, Fabrice and Stefano Zacchiroli},
   title = {Using Preferences to Tame your Package Manager},
   abstract = {Determining whether some components can be installed on a system is a complex problem: not only it is NP-complete in the worst case, but there can also be exponentially many solutions to it. Ordinary package managers use ad-hoc heuristics to solve this installation problem and choose a particular solution, making extremely difficult to change or sidestep these heuristics when the result is not the one we expect. When software repositories become complex enough, one gets vastly superior results by delegating dependency handling to a specialised solver, and use optimisation functions (or preferences) to control the class of solutions that are found. The opam package manager relies on the CUDF pivot format, which allows OCaml users that have a CUDF-compliant solver on their machine to reap the benefits of preferences-based dependency resolution. Thanks to the solver farm provided by Irill, these benefits are now extended to the OCaml community at large. In this talk we will present the preferences language and explain how to use it.},
   year = {2014},
index d7af6c6..43a392b 100644 (file)
@@ -1,5 +1,5 @@
 @article{debsources-ese-2016,
-  author = {Caneill, Matthieu and Daniel M. Germán and Stefano Zacchiroli},
+  author = {Caneill, Matthieu and Germán, Daniel M. and Stefano Zacchiroli},
   title = {The Debsources Dataset: Two Decades of Free and Open Source Software},
   abstract = {We present the Debsources Dataset: source code and related metadata spanning two decades of Free and Open Source Software (FOSS) history, seen through the lens of the Debian distribution. The dataset spans more than 3 billion lines of source code as well as metadata about them such as: size metrics (lines of code, disk usage), developer-defined symbols (ctags), file-level checksums (SHA1, SHA256, TLSH), file media types (MIME), release information (which version of which package containing which source code files has been released when), and license information (GPL, BSD, etc). The Debsources Dataset comes as a set of tarballs containing deduplicated unique source code files organized by their SHA1 checksums (the source code), plus a portable PostgreSQL database dump (the metadata). A case study is run to show how the Debsources Dataset can be used to easily and efficiently instrument very long-term analyses of the evolution of Debian from various angles (size, granularity, licensing, etc.), getting a grasp of major FOSS trends of the past two decades. The Debsources Dataset is Open Data, released under the terms of the CC BY-SA 4.0 license, and available for download from Zenodo with DOI reference 10.5281/zenodo.61089.},
   publisher = {Springer},
index 5a49ed2..f3d2b64 100644 (file)
@@ -1,5 +1,5 @@
 @inproceedings{distcheck-msr-2015,
-  author = {Pietro Abate and Di Cosmo, Roberto and Louis Gesbert and Fabrice Le Fessant and Ralf Treinen and Stefano Zacchiroli},
+  author = {Pietro Abate and Di Cosmo, Roberto and Louis Gesbert and Le Fessant, Fabrice and Ralf Treinen and Stefano Zacchiroli},
   title = {Mining Component Repositories for Installability Issues},
   abstract = {Component repositories play an increasingly relevant role in software life-cycle management, from software distribution to end-user, to deployment and upgrade management. Software components shipped via such repositories are equipped with rich metadata that describe their relationship (e.g., dependencies and conflicts) with other components. In this practice paper we show how to use a tool, distcheck, that uses component metadata to identify all the components in a repository that cannot be installed (e.g., due to unsatisfiable dependencies), provides detailed information to help developers understanding the cause of the problem, and fix it in the repository. We report about detailed analyses of several repositories: the Debian distribution, the OPAM package collection, and Drupal modules. In each case, distcheck is able to efficiently identify not installable components and provide valuable explanations of the issues. Our experience provides solid ground for generalizing the use of distcheck to other component repositories.},
   publisher = {IEEE},
diff --git a/research/publications/saner-2020-deps.bib b/research/publications/saner-2020-deps.bib
new file mode 100644 (file)
index 0000000..775160f
--- /dev/null
@@ -0,0 +1,8 @@
+@inproceedings{saner-2020-deps,
+  author = {Pietro Abate and Di Cosmo, Roberto and Georgios Gousios and Stefano Zacchiroli},
+  title = {Dependency Solving: Looking Back, Going Forward},
+  abstract = {Dependency solving is a hard (NP-complete) problem in all non-trivial component models due to either mutually incompatible versions of the same packages or explicitly declared package conflicts. As such, software upgrade planning needs to rely on highly specialized dependency solvers, lest falling into pitfalls such as incompleteness—a combination of package versions that satisfy dependency constraints does exist, but the package manager is unable to find it. In this paper we look back at proposals from dependency solving research dating back a few years. Specifically, we review the idea of treating dependency solving as a separate concern in package manager implementations, relying on generic dependency solvers based on tried and tested techniques such as SAT solving, PBO, MILP, etc. By conducting a census of dependency solving capabilities in state-of-the-art package managers we conclude that some proposals are starting to take off (e.g., SAT-based dependency solving) while—with few exceptions—others have not (e.g., outsourcing dependency solving to reusable components). We reflect on why that has been the case and look at novel challenges for dependency solving that have emerged since.},
+  publisher = {IEEE},
+  year = {2020},
+  booktitle = {SANER 2020: The 27th IEEE International Conference on Software Analysis, Evolution and Reengineering},
+}