dataesr/scientific-paragraphs-categorization huggingface dataset:
Front-end Shell parser. The syntax of the Posix shell language is unconventional in many aspects. For this reason, the implementation of a parser for Posix shell cannot simply reuse the standard techniques solely based on code generators. Most of the shell implementations falls back to manually written character-level parsers, which are dicult to maintain and to trust. morbig  [30]  is a parser that tries to use code generators as much as possible to keep the parser implementation at a high level of abstraction, simplifying maintenance and improving our ability to check if it complies with the Posix standard. The CoLiS language. It was rst presented in 2017  [23]. Its design aims to avoid some pitfalls of the shell, and to make explicit the dangerous constructions we cannot eliminate. It has a clear syntax and a formally dened semantics.
We provide an automated and direct translation from Posix shell. The correctness of the translation from shell to CoLiS cannot be proven formally but must be trusted based on manual review of translations and tests. For this case study, we improved the language proposed formerly  [23]  to increase the number of analysed Debian maintainer scripts. First, we added a number of constructs to the language. Second, we provide a formal semantics for the new constructs and we align the previous semantics  [23]  to the one of the Posix shell for a few other constructs. These changes and a complete description of the current CoLiS language are described in a technical report  [6]. Fig. 5  shows the CoLiS version of the preinst script of the rancid-cgi package, shown previously in Fig. 1. Notice the syntax for string arguments and for lists of arguments that requires mandatory usage of delimiters.
Generally speaking, the syntax of CoLiS is designed so as to remove potential ambiguities  [6]. The toolchain for analysing CoLiS scripts is designed with formal verication in mind: the syntax, semantics, and interpreters of CoLiS are implemented using the Why3 environment  [7]    The semantic rules cover the contents of variables and input/output buers used during the evaluation of a CoLiS script, but they do not specify the contents of the le system and the behaviour of Posix commands. The judgements and rules are parameterised by bounds on the number of loop iterations and the number of (recursively) nested function calls to allow for formalising the correctness of the symbolic interpreter. The bounds are either a non-negative integer, or ∞ for unbounded execution, and keep constant throughout the evaluation of a CoLiS instruction.
We refer to  [6]  for the details. A concrete interpreter for the CoLiS language is implemented in Why3. Its formal specications (preconditions and post-conditions) state the soundness of the interpreter, i. e. , that any result corresponds to the formal semantics with unbounded number of loop iterations and unbounded nested function calls. The specications are checked using automated theorem provers  [23]. Translation from shell to CoLiS. This is done automatically, but it is not formally proven. Indeed, a formal semantics of shell was missing until very recently  [21]. For the control ow constructs, the AST of the shell script is translated into the AST of CoLiS. For the strings (words in shell), the translation generates either a string CoLiS expression or a list of CoLiS expressions depending on the content of the shell string.
This translation makes explicit the string evaluation in shell, in particular the implicit string splitting. At the present time, the translator rejects 23% of shell scripts because it does not cover the full constructs of the shell, e. g. , usage of globs, variables with parameters, and advanced uses of redirections. The conformance of the CoLiS script with the original shell script is not proven formally but tested by manual review and some automatic tests. For the latter, we developed a tool that automatically compares the results of the CoLiS interpreter on the CoLiS script with the results of the Debian default shell (dash) on the original shell script. This tool uses a test suite of shell scripts built to cover the whole constructs of the CoLiS language. The test suite allowed us to x the translator and the formal semantics of CoLiS and, as an additional outcome, it revealed a lack of conformance between the Debian default shell and Posix 5.
Specications of UNIX commands The specication of the UNIX commands uses our feature tree logic to express their eect on the le system. The specication formalises the description given in natural language in the Posix standard  [22,  Chapter Utilities] and, for some commands, in GNU manual pages. We only specied (most of ) the UNIX commands called by the maintainer scripts. The full specication is available in a separate technical report  [24]. We present here its main ingredients. A UNIX command has the form: cmd options paths, where cmd is a command name, options is a list of options, and paths is one or more absolute or relative paths (i. e. , sequence of le names and symbols. and. ). For each combination of command name and option, we provide a list of formulas specifying the success and failure cases.
A success or failure case formula has two free variables r and r , which represent the root of the le system before and after the command execution. For some combinations of command names and options, the specication is not provided, but computed by the symbolic execution of a CoLiS script. This script captures the command behaviour by calling other (primitive) commands. Path resolution. An important ingredient in command specication is the constraint encoding the resolution of a path in the le system. For this, we dene a predicate resolve(r, cwd, p, z) stating that when the root of the le system is r and the current working directory is the sequence of features cwd, the path p resolves and goes to variable z. The constraint dening this predicate is a Σ 1 lg. conf? Fig. 10. Specication of error cases of rm /etc/rancid/lg.
Analysis by symbolic execution With a similar approach as for the concrete interpreter (Section 3. 1), we designed and implemented a symbolic interpreter for the CoLiS language in Why3. Guided by a proof-of-concept symbolic interpreter for a simple IMP language  [5] , the main design choices for the symbolic interpreter for CoLiS are: Variables are not interpreted abstractly: when executing an installation script, the concrete values of the variables are known. On the other hand, the state of the le system is not known precisely, and it is represented symbolically using a feature tree constraint. The symbolic engine is generic with respect to the utilities: their specications in terms of symbolic input/output relations are taken as parameters. The number of loop iterations and the number of (recursively) nested function calls  [6] ) is bounded a priori, the bound is given by a global parameter set at the interpreter call.
Scenarios So far, we have presented how we analyse individual maintainer scripts. In reality, the Debian policy species in natural language in which order and with which arguments these scripts are invoked during package installation, upgrade, or removal (see, for instance, Fig. 2 ). We have specied these scenarios in a loopfree custom language. These scenarios dene what happens after the success or the failure of a script execution. They also specify when the static content is unpacked. Furthermore, our toolchain allows to dene the assumptions that can be made on an initial lesystem before executing a scenario, for instance the File System Hierarchy Standard  [38]. Our toolchain reports on packages that may remain in an unexpected state after the execution of one of these scenarios. For instance, the installation scenario of the package rancid-cgi may leave that package in the state not-installed, which is reported by our toolchain using the diagram in Fig.
Results and impact 4. 1 Coverage of the case study The tools used and the datasets analyzed during the current study are available in the Zenodo repository  [36]. We execute the analysis on a machine equipped with 40 hyperthreaded Intel Xeon CPU @ 2. 20GHz, and 750GB of RAM. To obtain a reasonable execution time, we limit the processing of one script to 60 seconds and 8GB of RAM. The time limit might seem low, but the experience shows that the few scripts (in 30 packages) that exceed this limit actually require hours of processing because they make a heavy use of dpkg-maintscript-helper. On our corpus of 12 592 packages with 28 814 scripts, the analysis runs in about half an hour. All of those scripts that are syntactically correct with respect to the Posix standard (99. 9%) are parsed successfully by our parser.
The translation of the parsed scripts into our intermediary language CoLiS succeeds for 77% of them; the translation fails mainly because of the use of globs, variables with parameters and advanced uses of redirections. Our toolchain then attempts to run 113 328 scenarios (12 592 packages with scripts, 9 scenarios per package). Out of those, 45 456 scenarios (40%) are run completely and 13 149 (12%) partially. This is because scenarios have several branches and although a branch might encounter failure, we try to get some information on execution of other branches. For the same reason, one scenario might encounter several failures. In total, we encounter 67 873 failures. The origins of failures are multiple, but the two main ones are (i) trying to execute a scenario that includes a script that we cannot convert (28% of failures), or (ii) the scripts might use commands unsupported by our tools, or unsupported features of supported commands (71% of failures).
Corpus mining The latest version of the Debian sid distribution on which we ran our tools dates from October 6, 2019. It contains 60 000 packages, 12 592 of which contain at In the process of designing our tools, and in order to validate our hypotheses, we ran statistical analysis on this corpus of scripts. The construction of our tool for statistical analysis is described in a technical report  [25]  where we also detail a few of our ndings. To summarize, analysing the corpus revealed that: Most variables in scripts were used as constants: only 3 008 scripts contain variables whose value actually changes. There are no recursive functions in the whole corpus. There are 2 300 scripts that include a while loop. 93% of the while loops occur in a pipe reading the output of dpkg -L and are an idiosyncrasy that is proper to some shell languages.
Bugs found We ran our toolchain on several snapshots of the Debian sid distribution taken between 2016 and 2019, the latest one being October 6, 2019. We reported over this period a total of 152 bugs to the Debian Bug Tracking System  [37]. Some of them have immediately been conrmed by the package maintainer (for instance,  [16] ), and 96 of them have already been resolved. Table  1  summarizes the main categories of bugs we reported. Simple lexical analysis already detects 95 violations of the Debian Policy, for instance scripts that do not specify the interpreter to be used, or that do not use the -e mode  [9]. The shell parser (Section 3. 1) detects 3 scripts that use shell constructs not allowed by the Posix standard, or in a context where the Posix standard states that the behaviour is undened  [15].
Lessons learnt One basic problem when trying to analyse maintainer scripts is to understand precisely the meaning of the policy document. For instance, one of the more intriguing requirements is that maintainer scripts have to be idempotent (Section 6. 2 in  [4] ). While it is common knowledge that a mathematical function f is idempotent when f (f (x)) = f (x) for any x, the meaning is much less clear in the context of Debian maintainer scripts as the policy goes on to explain If the rst call failed, or aborted half way through for some reason, the second call should merely do the things that were left undone the rst time, if any, and exit with a success status if everything is OK. We suppose that this refers to causes of error external to the script itself (power failure, full disk, etc. ), and that there might be an intervention by the system administrator between the two invocations.
Since we cannot even explain in natural language what precisely that means, let alone formalise it, we decided to model at the moment only a rough under-approximation of that property that only compares executions by their exit code. This allowed us to detect a bug  [14]. We found that identifying bugs in maintainer scripts always requires human examination. Automated tools allow to point out potential problems in a large corpus, but deciding whether such a problem actually deserves a bug report, and of what severity level, requires some experience with the Debian processes. This is most visible with semantic bugs in scripts, since an error exit code does not imply that there is a bug. Indeed, if a script detects a situation it cannot handle then it must signal an error and produce a useful error message.
4 ). This study had several additional outcomes. The toolchain includes tools for parsing and light static analysis of shell scripts  [30] , an engine for the symbolic execution of imperative languages based on rst-order logics representation of program congurations  [5] , and an ecient decision procedure for feature tree logics. We also provide a formal specication of Posix commands used in Debian scripts in terms of a rst-order logic  [24]. We are not aware of a project dealing with this kind of problem or obtaining comparable results. To our knowledge, the only existing attempt to analyse a complete corpus of package maintainer scripts was done in the context of the Mancoosi project  [19]. In this work, the analysis, mainly syntactic, resulted in a set of building blocks used in maintainer scripts that may be used in a DSL.
In a series of papers  [20, 28, 29] , Ntzik et al. consider the formal reasoning on the Posix scripts manipulating the le system based on (concurrent) separation logic. Not only do they employ a dierent logic (a second-order logic), but they also focus on (manual) proof techniques for correctness and not on automatic techniques for nding bugs. Moreover, they consider general scripts and properties that are not relational (like idempotency). There have been few attempts to formalise the shell. Greenberg  [21]  recently oers an executable formal semantics of Posix shell that will serve as a foundation for shell analysis tools. Abash  [27]  contains a formalisation of parts of the bash language and an abstract interpretation tool for the analysis of arguments passed by scripts to Unix commands; this work focused on identifying security vulnerabilities.
The crystal-ball shape and tail parameters for the ψ(2S) were fixed with respect to the J/ψ parameters, using the PDG database value  [43]  for the energy difference and a width broadening factor taken from simulations. In cases where the statistical precision of the data led to poor definition of the J/ψ signal shape, the mass and width of the J/ψ peak were fixed and a systematic uncertainty was assigned to the yield based on tests made with higher statistics cases. The statistical uncertainties related to the extraction of the J/ψ yields were determined from a covariance matrix in the fitting procedure.
Acceptance and Reconstruction Efficiency The study of acceptance and reconstruction efficiency of dimuons from J/ψ decays has been performed using a geant4-based full detector simulation  [48]. In this simulation, the MuTr and MuID detector efficiencies are set to values determined from the data. An emulator of the dimuon trigger response is included in the simulation to account for the trigger efficiency. As these efficiencies depend on the instantaneous luminosity being sampled, each data set is divided into three groups with different beam interaction rates, and corrected yields with separate corrections are compared. A systematic uncertainty is assigned to the extracted J/ψ cross sections times branching fraction to µ + µ -to reflect the differences, see Sec. III G for details. The pythia8 event generator package  [49]  is utilized to generate J/ψ events used for the full Geant4 detector simulation.
IV. RESULTS In this section, we present invariant yield, nuclear modification factor, and p 2 T results at forward and backward rapidity. There have been significant changes to the muon arm configuration and to the simulation framework since the d+Au data set was recorded. Figure  4  shows the J/ψ invariant yield as a function of p T in p+p collisions at √ s = 200 GeV at forward and backward rapidity, where bars (boxes) represent point-to-point uncorrelated (correlated) uncertainties. The global systematic uncertainty is 10. 1%. The ratio of invariant yields between the forward and backward rapidity regions is presented in the bottom panel, where the systematic uncertainty due to the J/ψ polarization cancels in the ratio. The invariant yields at forward and backward rapidity are consistent within the systematic uncertainties, confirming that the detector efficiency is well understood in p+p collisions.
In the comparison between p+Au and d+Au, the two systems do not share the same p+p reference, therefore all systematic uncertainties are included in the ratio. Note the d+Au data set was recorded in 2008, while the p+Au data was recorded in 2015 with a new detector. Simulations for d+Au were also performed using methods that differ from those used for the new small systems study. For p+Au, d+Au and 3 He+Au comparisons, a mean value has been fitted to the ratios, and the result is shown on the plot together with the fit uncertainty and the uncertainty from the systematic errors. The systematic uncertainty was determined by repeating the fit with all points moved to the upper or lower limits of their systematic uncertainty. The comparison in Fig. 15  of 0%-20% p+Al with 0%-20% p+Au modifications contrasts the weak modification in central p+Al collisions with the strong modification, particularly at forward rapidity, in central p+Au collisions.
ACKNOWLEDGMENTS We thank the staff of the  Collider-Accelerator and Physics Departments at Brookhaven National Laboratory  and the staff of the other PHENIX participating institutions for their vital contributions. We also thank  H. -S. Shao  and  J. -P. Lansberg , et al. ,  R. Vogt ,  X. Du , and  R. Rapp  for useful discussions and providing unpublished predictions. We acknowledge support from the  Office of Nuclear Physics in the Office of Science of the Department of Energy , the  National Science Foundation ,  Abilene Christian University Research Council, Research Foundation of SUNY, and Dean of the College of Arts and Sciences, Vanderbilt University (U. S. A) ,  Ministry of Education, Culture, Sports, Science, and Technology  and the  Japan Society for the Promotion of Science (Japan) ,  Conselho Nacional de Desenvolvimento Científico e Tecnológico and Fundação de Amparo à Pesquisa do Estado de São Paulo (Brazil) ,  Natural Science Foundation of China (People's Republic of China) ,  Croatian Science Foundation and Ministry of Science and Education (Croatia) ,  Ministry of Education, Youth and Sports (Czech Republic) ,  Centre National de la Recherche Scientifique ,  Commissariat à l' Énergie Atomique , and  Institut National de Physique Nucléaire et de Physique des Particules (France) ,  Bundesministerium für Bildung und Forschung ,  Deutscher Akademischer Austausch Dienst , and  Alexander von Humboldt Stiftung (Germany) ,  J.
Therefore, we set up a semi-automated method using Image J software (Suppl Figure  1D ) to quantify the extent of regeneration without any bias. We measured CTB-555 intensity along the optic nerve at defined distances from the injury site. CTB-555 intensity was then normalized by the width of the optic nerve at each distance and by the maximal CTB-555 intensity in the regenerating region to account for experimental variability. Finally, we subtracted the background value. The resulting normalized integrated intensity at each distance allowed us to quantify the extent of axon regeneration accurately and without any bias. In parallel, after two weeks in culture, explants were fixed and stained with an anti-β Tubulin III (TUJ1) antibody. In control conditions, 38% of all explants did not grow any axon, compared to 19.
5% for PTEN -/-and less than 10% for PTEN -/-/SOCS3 -/-+c-myc conditions (Table  1 ). This observation reflects in vivo conditions as WT optic nerves show very little regeneration compared to PTEN -/-and PTEN -/-/SOCS3 -/-+c-myc conditions. For the explants that grew more than one axon, we measured axon number and length in WT, PTEN -/-and PTEN -/-/SOCS3 -/-+c-myc conditions (Figure  3G, H, I ; Suppl Figure  2A, B, C, D ). To do so, we used the Scholl analysis-based plug-in Neurite-J(18) on Image J software. An automated method defined the explant borders and filtered out noise in the background, with manual correction if necessary. Subsequently, we used the automated Scholl analysis to measure the number of intersections (outgrowing neurites) at defined distances of the explants (50µm step) (Suppl Figure  2E ).
Imaging For whole optic nerve imaging, we used the DragonFly spinning disc confocal from Andor. We took z stacks (2µm for each z step) to scan the entire width of the cleared optic nerves. Then we stitched images (with at least 10% of overlap) using a custom stitching module in Metamorph. We used the maximum z projection (performed with Metamorph) to visualize and quantify the extent of regeneration.
Live imaging and laser ablation All live imaging and laser ablation experiments were performed with PTEN -/-retina explant cultures or PTEN -/-/Thy1-YFP retina explant cultures. For fluorescence live imaging, culture medium was replaced with unsupplemented Hibernate-A with no phenol red (BrainBits). Axons or growth cones were imaged with the DragonFly spinning disc confocal microscope from Andor, with 1 image per second. For standard DIC imaging and laser ablation, retina explant cultures were left to equilibrate in the humidified chamber at 37°C and 5% CO2 for 15min. We chose axons that were isolated from their neighbors to avoid working with fasciculate axons and we checked axon health by observing and recording growth cone dynamics for 20min before starting the experiment. Laser ablation was performed with Micropoint (Andor Technologies) and controlled with Metamorph imaging software.
20/27 Explants were imaged with epifluorescence microscopy with automatic stitching (Axioscan slide scanner Scan. Z1, Zeiss). Explants with no or little axon outgrowth (0 or 1 axon) were removed and analyzed separately (Table  1 ). For the rest of the explants, axon outgrowth was quantified with a Scholl analysis using the ImageJ plug-in Neurite-J  (18). Definition of the explant and background noise filtering were automatically performed with manual correction if necessary, as described by the plug-in developer. The number of neurites intersects was determined by the Scholl analysis with a step of 50µm. Data were plotted as the number of neurite intersects as a function of the distance to the explant border.
Statistical analysis Statistical analysis was performed with GraphPad Prism (version 7. 00). For each dataset, the Shapiro-Wilk test was used to assess normal distribution (P-value >= 0. 01). Datasets normally distributed were analyzed with an unpaired Student's t-test (for comparison of two conditions) or an ANOVA test (for multiple comparisons). Datasets that were not normally distributed were analyzed      Data collected from two independent days of explant culture. 1 Explants with no axon growth were excluded from quantification. 2 Explants with overlap of axons from neighbouring explants were excluded from quantification. FIGURE LEGENDS.