dataesr/scientific-paragraphs-categorization huggingface dataset:
For each occurrence of such an annotation, the check method is called with as parameter an object that contains contextual information (such as the program element AST node on which the annotation was found). The validator reports violations on the has default constructor constraint (see line 16 in Listing 18). We have used AVal as a means to describe and enforce the usage rules of annotations defined by three large frameworks  [32] : Hibernate's Java Persistence API implementation  [30] , Fractal's component model implementation for Java Fraclet  [37]  and the JSR181 for Web Services. We were able to use AVal to specify 23 annotations from these frameworks. Implementing AVal on top of Spoon provides benefits at two levels: On the implementation side, Spoon's abstractions allow AVal to rely on metaannotations to specify annotation constraints in a modular manner.
Obviously ducks can both fly and swim. However, single inheritance cannot appropriately capture on its own such a specialization scheme since it would be cumbersome to have a single line of specialization where Flying and Swimming would be artificially related to each other. Mixins can help to deal with such an issue. We illustrate in the remainder of this section how a simple annotation-based language for Java mixins can be defined with Spoon. We are aware that defining a full-fledged mixin language would require many more features than the ones we introduce. This is why, for the sake of clarity, we limit ourselves to the very first steps of such a project. Our purpose is to illustrate the capabilities of Spoon for defining simple annotation-based domain specific languages. Listing 19 introduces the annotation-based concept of mixin to define the Duck class (line 5).
Discussion To sum up, we have shown that Spoon can be used in a number of different analysis and transformation scenarios. As the examples show, the Spoon API enables the developer to write a transformation that is intuitive to write and easy to maintain. Spoon is deeply founded on AST analysis and consequently, all comments and layout are discarded when transforming code. In the case of large scale § In this paper, we have not discussed the usage of Spoon for standard generic static analyses such as building a control-flow graph, a program dependence graph, a single static assignment form, etc. This is on purpose: as the title suggests Spoon is meant to be used "by the masses" for writing their own domain-specific analysis (such as the one related to web services). However, based on our experience, Spoon can also be used for such tasks, for instance to perform a dead code elimination in a Java project.
Ichisugy and Roudier  [19]  devised a preprocessor for Java. A preprocessor enables one to only write transformations specified with intrusive specific preprocessor directives. On the contrary, Spoon allows one to transform any Java program in a non-intrusive manner. Chiba introduced the notion of compile-time meta-architecture  [9]. Spoon has the same kind of architecture for the Java language. Also, it uses Java generics for well-typing program analyses and transformations. Tatsubori et al. described a macro system for Java called OpenJava  [44]. OpenJava contains introspection and intercession methods that are similar to Spoon. The Javadoc system  [25]  enables to write "doclets", pieces of code that analyze the structure of a Java programs (classes, field, methods). Beyond the structural part, Spoon enables to analyze every single program element.
Spoon allows full intercession up to the statements and expressions of the language. Compile-time meta-architecture and aspects à la AspectJ  [22]  are closely related concepts. Spoon can be seen a a compile-time aspect weaver, where the AST node type and isToBeProcessed method act as the pointcut and the process method as the advice. The main difference between AspectJ and Spoon is that Spoon enables any kind of pointcut and advice to be written: any arbitrary code patterns can be encoded in isToBeProcessed as well as any transformation up to code elements. AspectJ is simpler to use but to the price of having a more limited scope of aspects. Van Deursen and Visser  [45]  introduced the idea of combining AST visitors to perform a wide range of analysis tasks. The main difference with Spoon is that Spoon provides not only visiting mechanisms but also a powerful transformation API.
However, Van Deursen and Visser's visitor combinators might be plug on top of Spoon transformations to create higher-order transformations. There are many bytecode analysis and transformation libraries (e. g. [10, 8] ). Spoon does not work on bytecode but on source code. This enables developers to reason and transform language structures and constructs that disappear during the compilation process (e. g. try/catch blocks, anonymous classes, etc. ). Also, the transformations are more intuitive to write since they refer to the syntactic programming concepts. Klint et al. presented Rascal [23]. Rascal is a domain-specific language for source code analysis and manipulation. It enables one to implement refactoring algorithms that are independent of the one particular programming language. While a domain-specific language allows conciseness and expressiveness, it has a steep learning curve.
On the contrary, any good Java developer is able to write a Spoon transformation of Java programs within a relatively short time. Visser invented Stratego, a language for program transformations using rewriting rules  [46]. Schordan and Quinlan described a source-to-source transformation framework dedicated to optimization  [39]. MetaJ is a metaprogramming environment for Java  [12]. It provides a template mechanism that is similar to ours described in Section 3. 3. Cordy presented the TXL source transformation language. The TXL language is based on rules to specify the transformations. Balland et al. summarized their research efforts on Tom, a term-rewriting platform that is able to deal with Java code  [4]. For all those approaches, the analysis and transformation developers are required to master a new abstract formalism.
On the contrary, using Spoon, only the concept of abstract syntax tree is required to start writing productive transformations in plain Java. Ludwig and Heuzeroth designed the COMPOST system  [29]  and some program transformations. Our goal and architecture are similar, but the Spoon mechanisms for transforming programs are more powerful. For instance, Compost has no way for specifying templates. Strein et al. [42]  proposed an extensible metamodel for program analysis. They only focus on program analysis while Spoon enables users to specify analyses and transformations using the same framework. Kuipers and Visser  [26]  presented a meta-approach to analysis: given a grammar definition, JJForester generates the classes implementing the meta-model and the traversal helper classes. Contrary to Spoon, this is one meta-level further.
Acknowledgments We would like thank all contributors of Spoon over the years:  Olivier Barais ;  David Bernard ;  Benoit Cornu ;  Didier Donsez ;  Favio DeMarco ;  Christophe Dufour ;  Sebastian Lamelas Marcote ;  Matias Martinez ;  Nicolas Pessemier ;  Phillip Schichtel ;  Stefan Wolf. Gerard Paligot  did the heavy lifting of Section 4. 1 and 4. 2.
a set of states, which represents our current estimate of the likely invariant at that program point, 2. a set of good states, which are concrete states such that executions starting from those states do not cause any assertion violations, and 3. a set of bad states, which are concrete states such that executions starting from those states cause an assertion violation. None of these sets is necessarily a strict over-or under-approximation of the reachable set at that program point. We use abstract interpretation to initialize the first set, but later update it with likely invariants learnt using machine learning or crowdsourcing. The set of good and bad states are collected using testing and symbolic execution, and they form the inputs for the machine learning and crowdsourced games. In particular, Chekofv complements machine learning pro-cedures by using two games, Xylem  [14]  and Binary Fission 4.
A secondary goal is to increase the visibility of our games and get feedback from the community. We hope to collect enough data this way to perform a statistically significant study that compares the quality of crowdsourced invariants with the quality of machine learned ones. The idea of learning likely invariants from program states goes back to Daikon  [5]. Daikon learns likely invariants from a given set of (good) program states by working with a fixed set of grammar patterns. Numerous approaches have used Daikon; for example, iDiscovery  [18]  uses symbolic execution to improve on Daikon's invariants. Similar to our approach, it inserts the learned invariants back in the code under analysis and then uses symbolic execution to confirm or break these candidate invariants. This process generates new states that can be fed to Daikon and can be iterated until either an inductive invariant is found, or symbolic execution fails to generate new states.
Crowdsourcing games To crowdsource the problem of finding likely invariants, we have developed two games, Xylem  [14]  and Binary Fission. Both games are available online at verigames. com. Xylem. The goal of Xylem is to generate new predicates that can be used for invariant construction. Players are presented with a sequence of (good or bad) program states and are asked to find a non-linear inequality that is satisfied by these states. In that sense, Xylem can be seen as a crowdsourced version of Daikon. To cap the cognitive load on players, Xylem splits the predicate construction problem into several game levels, with each level being composed of a limited number of states and a subset of variables. To ensure that we obtain a diverse set of solutions, Xylem gives different subsets of states and variables to different players.
Currently we seed this set using Daikon. If the available predicates are not sufficient to separate the good from the bad states within a given treedepth, some leaf nodes will contain both good and bad states. These states are then taken aside and reentered as input into Xylem and/or Daikon. Since these sets are smaller than the initial set, Xylem and Daikon are allowed to search for more complex likely invariants (which would otherwise be computationally expensive and lead to many useless candidates). Implementation Notes. The Chekofv system provides both games with sets of states and collects the predicates and candidate invariants provided by the players. Chekofv uses Frama-C for abstract interpretation and extends it by several plugins to extract the abstract state at particular program points, and to insert likely invariants.
This implements the steps Initialize and Update1 from our abstract algorithm in Section 4. Note that Chekofv only samples states at entry points of procedures and before procedure calls that precede Frama-C warnings. As shown in Section 3 this is sufficient to find real bugs. For practical reasons, we use the bounded model checker CBMC  [13]  instead of symbolic execution to implement step Update2 from Section 4. We perform minor program transformations (e. g. , insert assumptions and non-determinism) to make the result resemble a symbolic execution. The collected good and bad states are stored in a database and serve as input to both games. For testing, we also seed or database the sets of good and bad states from the experiments in  [12]  and  [18]  to our database. The sets of good and bad states differ greatly between the benchmarks.
For example, the TCAS benchmark in  [18]  comes with hundreds of states collected from dynamic execution, while other benchmarks come with less than a dozen states obtained by symbolic execution. Step Update3 from Section 4 is realized by the two games; each game has its own web server that pulls program states from the database and presents them to the game client. Predicates produced by the players are sent back to the server and stored in a database. Likely invariants generated from game play are post-processed and then used by Frama-C, thus closing the loop in Figure  3.
Acknowledgement This work was supported in part by the National Science Foundation under grant contracts CCF 1423296 and CNS 1423298, and DARPA under agreement number FA8750-12-C-0225. We gratefully acknowledge the contributions of our collaborators at UCSC especially Kate Compton, Heather Logas, Joseph Osborn, Zhongpeng Lin, Dylan Lederle-Ensign, Joe Mazeika, Afshin Mobrabraein, Chandranil Chakrabortii, Johnathan Pagnutti, Kelsey Coffman, Richard Vallejos, Lauren Scott, John Thomas Murray, Orlando Salvatore, Huascar Sanchez, Michael Shavlovsky, Daniel Cetina, Shayne Clementi, Chris Lewis, Dan Shapiro, Michael Mateas, E. James Whitehead Jr. , at SRI John Murray, Min Yin, Natarajan Shankar, Sam Owre, and at CEA Florent Kirchner, Boris Yakobowski.
Implementation and Experiments The method has been implemented in the RTD-Finder tool designed to check safety properties for real-time component-based systems modelled in the RT-BIP language  [1]. The tool and the examples are available at http://www-verimag. imag. fr/RTD-Finder. In RT-BIP, components are modelled as timed automata and synchronise by means of n-ary multi-party interactions. The tool takes as input a real-time BIP model and a file containing the safety property. It subsequently generates a Yices  [20]  output file where the invariants are expressed together with the property. RTD-Finder proceeds by the following steps. It extends the components with history clocks and computes their local invariants. The computation of those invariants requires the implementation of several operations on zones.
For this purpose, we developed a DBM (Difference Bound Matrices) library. RTD-Finder subsequently computes the history clocks constraints and the interaction invariant. It writes all these invariants to a file and calls Yices to check the satisfiabilty of GI ∧ ¬Ψ. If GI ∧ ¬Ψ is unsatisfiable, the property is valid. Otherwise, Yices generates a counter-example. We note that, at present, the tool cannot conclude if it is a valid counter-example, however, a guided backward analysis module is currently under development. The benchmarks we used in our experiments with RTD-Finder are described in what follows.
The difference between the history clocks relative to those two events is longer than the required time elapse: (h V P ≤ h V S ∧ h V S ≤ h 0 ) → h V S -h V P ≥ TURI 5. 6. Results. We ran our experiments on a Linux machine with Intel Core 3. 20 GHz ×4 and 15. 6 GiB memory. The results, synthesised in Table  1 , show the potential of our method in terms of accuracy and scalability. In Table  1 , n is the number of components, q is the total number of control locations, c (resp. h) is the number of system clocks (resp. history clocks), i is the number of interactions, while t shows the total verification time and t yices is the timed taken by Yices for satisfiability checking of GI ∧ ¬Ψ. To the best of our knowledge, there are no tools to compositionally verify safety properties of timed systems.
Conclusions We presented a fully automated compositional method to generate global invariants for timed systems described as parallel compositions of timed automata components using multi-party interactions. The soundness of the method proposed has been proven. In addition, it has been successfully tested on several benchmarks. This method has been implemented in the RTD-Finder tool. The results show that it may outperform the existing exhaustive exploration-based techniques for large systems, thanks to the use of compositionality and over-approximations. Nonetheless, the generated invariant is an over-approximation of the reachable states set and false-positives may raise. To remedy this, we are working on a guided backward analysis module to decide upon their validity. In order to achieve a better integration, we are working on handling richer classes of systems, including systems with data variables and urgencies  [7]  on transitions.
Previous DMD data were compiled together and, for each oligonucleotide, some 60 descriptors were considered. Statistical modelling approaches were applied to derive algorithms that predict exon skipping for a given target site. We confirmed (1) the binding energetics of the oligonucleotide to the RNA, and (2) the distance in bases of the target site from the splice acceptor site, as the two most predictive parameters, and we included these and several other parameters (while discounting many) into an in silico screening process, based on their capacity to predict high or low efficacy in either phosphorodiamidate morpholino oligomers (89% correctly predicted) and/or 2'O Methyl RNA oligonucleotides (76% correctly predicted). Predictions correlated strongly with in vitro testing for sixteen de novo PMO sequences targeting various positions on DMD exons 44 (R 2 0.
Aartsma-Rus et al. furthermore  [28]  used linear discriminant analysis to identify four parameters capable to classify a high proportion of 2'O-Methyl oligos into effective and non-effective categories (defined by those authors as >5% or <5% of transcript skipped). The strongest of these was the difference in free energy (dG) between the bound and unbound states of the oligo and the entire sequence of the exon. The remaining three parameters related to the binding of splice regulatory proteins to the target sequence within the exonic pre-mRNA: the number of hexameric exon splicing enhancer sites predicted by RESCUE-ESE  [33] , and the strength of sequence motifs for the binding of Tra2β and SC35 splicing factor proteins as predicted by Human Splicing Finder  [34]. Popplewell et al. [29] , carrying out a similar analysis but using PMO oligos, likewise identified (1) dG of the oligo to its target exon, but otherwise determined (2) oligo length, (3) the proximity of the target sequence to the exon acceptor site, (4) their experimental assay of target site accessibility, and (5) the predicted strength of ASF/SF2 splice factor binding, to be the other distinguishing parameters.
A purely in silico analysis of RNA accessibility identified parameters based on the computation of co-transcriptional folding dynamics  [35]. Their algorithm computed the free folding of a moving window of 1500 bases of the pre-mRNA, beginning with the exon at the 3' end of the window then shifting one base per iteration until the exon was at its 5' end. The number of times that bases of the target sequence were unbound throughout the iterations was computed, and was found to correlate with previously described skipping efficacy. A prospective study was later carried out using, as its oligo design criteria, a parameter ('L3') that was based on these RNA accessibility computations, together with two other parameters: the presence of exon splice enhancer motifs and the oligo length  [30]. These previous studies involving retrospective identification of design parameters were limited to single-study datasets and did not set specific criteria or thresholds  [28, 29] , whereas the prospective study  [30]  considered only several design criteria from among those parameters that had previously been identified to correlate with efficacy.
Importantly, no reports have moved beyond the identification of design criteria, to provide quantitative predictions of skipping efficacy. Furthermore, the retrospective analyses may, in the absence of checking against other datasets, have yielded potentially spurious study-specific biases in correlation, especially considering the large numbers of parameters involved. In addition, there are two contexts in which consideration of RNA folding and binding energetics have been based on assumptions that do not necessarily reflect as closely as possible the dynamics of the system: (1) because binding of the oligo occurs during the definition of the exon, it may make more sense to consider binding to a target region within which the target sequence is at the center (including where necessary some intronic sequence) rather than binding to the entire exon, which could be particularly inaccurate for oligo binding near the ends of the exon; (2) the pre-mRNA may have strong limitations on its freedom of movement over a window as long as 1500 bases, so computations of RNA accessibility over shorter lengths may give greater accuracy.
Here, we present a novel approach for screening across an exon to predict regions of high exon skipping efficacy. We collate previously published data on the efficacy of exon skipping oligos and their reported descriptive parameters. For each previously published oligo we then use computational tools to calculate additional parameters, usually with several variations of each (such as varying the length of flanking sequence in computations of binding energy). We identify parameters that have robust predictive power and, based on these, derive predictive algorithms and apply them to screen across all target positions within selected exons of the dystrophin pre-mRNA. Predictions are then tested by in vitro assays of exon skipping for oligos at eight positions each of dystrophin exons 44 and 53, and a strong correlation is found with the predicted profile across the exon.
Somewhat surprisingly, although several parameters were additive to predictive power in the PMO and 2'O-Methyl datasets, none were shared by both datasets except for (1) the binding energy of the oligonucleotide to the RNA, which was found to have the strongest influence on efficacy, and (2) the distance (in bases) of the target site from the splice acceptor. An in silico screening tool facilitating the application of these algorithms across any exon sequence of interest is provided as a Perl script with instructions for use.
For neighborhood inference scores, a Perl program was written to screen across all target exons and, for each hexamer sequence, retrieve the NI score published by  [37]. The cumulative NI score was defined as the sum of the hexamers scores for each target site. We also divided this cumulated score by target length to give a normalized cumulative NI score. GC content of the exon, the upstream flanking region, and our various secondary parameters based on those, were calculated using Perl and BioPerl. Data exploration and modelling were done using JMP software (SAS Institute Inc. , NC, USA). Further details relating to parameter calculations and predictive modelling can be found in supplemental materials and methods.
Screening of predictive algorithm across target exons Human DMD exon coordinates were taken from the Consensus CDS project reference CCDS14233. 1 and sequences were downloaded from NCBI nucleotide reference NC_000023. A fasta file was generated for target exons and 200 base intronic flanks (S1 Sequences). We include a Perl script (S1 Script) which takes the fasta file as input and generates two output files: (1) a list of oligo and target sequences (with flanking regions) for every position of the target exon(s), numbered according to the distance of the target sequence from the splice acceptor site, and (2) energy calculations for each of these oligo to target pairs. The script uses BioPerl's sequence input/output object to manipulate the fasta file, and the text interface version of RNAstructure software  [41]  to generate energy calculations.
The script has a path to RNAstructure thermodynamic parameter tables that must be set correctly and RNAstructure must be correctly installed on the system. The length of the oligo sequence can be specified in the script, along with several other parameters. The predictive formulae (PMO or 2'O-Methyl) presented here can then be applied to each target position, using Microsoft Excel to incorporate the dG and distance from acceptor values output by RNAstructure and Perl into the formula.