dataesr/scientific-paragraphs-categorization huggingface dataset:
Static approaches take profit from the technology developed for compilers and language-based tools to be able to gather information about the source code without executing it. The improvement of dynamic testing mechanism with static techniques (like metrics or style analysis), led to a new generation of hybrid systems such as CourseMaker, Web-CAT, eGrader, Au-toLEP or BOSS that combine the best of both approaches. This symbiosis keeps providing immediate feedback to the users, but enriched by a quality analysis -which is obviously a relevant extra-value. In the past few years, with the spreading of Agile Methodologies  (Beck, 2001) , some experiments  (Hazzan and Dubinsky, 2003; Jovanovic et al. , 2002)  were conducted aimed at combining two topics: Agile Development and Education. In this context, the implementation of Continuos Integration (CI)  (Kim et al.
iQUIMERA iQuimera is an improved version of our AGS first approach -the Quimera system  (Fonte et al. , 2012)  developed to support the features announced in Sec-tion 3. This system is a web-based application to assess and grade students' programming exercises written in the C programming language, either in learning or programming contest environments. It offers a complete management system, allowing to set up and manage contests; register students and associate them in groups; and follow up and monitor the different activities involved. With iQuimera extension, we aim at improving our original approach in two important directions: • Flexibilization of the Grading process -on the one hand, being able to accept as correct answers semantically similar to the expected one, independently of their syntactic differences 1  ; on the other hand, allowing the definition of a set of partially correct answers that should also be accepted and graded 2.
Quimera initial functionalities Quimera is a system capable of evaluating and automatically ranking programming exercises in learning or programming contest environments, by combining a very complete static source code analysis with dynamic analysis. Thus, Quimera is able to ensure the grading of the submitted solution based not only on its capability of producing the expected output, but also considering the source code quality and accuracy. Our system guarantees that different programming styles will receive different grades even if they produce the correct output and satisfy all the requirements; this can be an advantage on learning environments, because the student is stimulated to find different correct solutions. Teachers will not waste time searching for problems that have only one solution; the approach adopted allows problems that can be solved in different manners.
Dynamic Analysis Quimera Dynamic Analyzer module follows the traditional strict approach: the submitted (source) code is compiled and then executed with a set of predefined tests. Each test is composed of an input data vector and the correspondent output vector. Running the compiled code (submitted by the student) with one input data vector, the output produced is saved as a vector and is compared with the expected output. The student's submission passes that test if both output vectors are strictly equal (the difference between them is null). In this way, the submission under assessment is correct if and only if all the tests succeed. After the assessment (running the submitted code with all the test vectors), the user can consult the percentage of tests successfully passed. However, he does not know how many tests there are and only has access to the tests included in the problem statement.
Static Analysis Quimera Source Code Analyzer module produces a complete report about the quality of the source code submitted through a set of predefined metrics (currently 56 metrics), grouped by five classes, namely: Size, Consistence, Legibility, Complexity and Originality (as detailed in  (Fonte et al. , 2012) , here ommited for the sake of space). The different values computed automatically by this module using classic compiler technologies, when combined with the dynamic evaluation (as discussed in subsection 4. 1. 1), provide a fine grain assessment that is uttermost relevant for the student learning process. However to be useful in the grading process, the numerical values obtained along the metrics evaluation must be appropriately transformed. For the sake of simplicity and space we do not discuss here those transformations.
At present we are using the following combination of weights: Execution (75% + 5%), Size (2%), Consistence (5%), Legibility (2%), Complexity (6%) and Cloning (5%). In this way, we enhance the dynamic analysis: the actual program ability to produce the correct output corresponds to 80%; the source code quality influences the final grading with just a factor of 20%. The report issued by Quimera after the Grading phase, contains not only the final grade but all details concerned with the two previous marking phases, as depicted on both sides of Figure  1. On the left side of Figure  1 , we can see a report for an answer that only passes in 22% of the tests. This is a well documented answer (it has 15 commented lines in 50 lines of code) and its Legibility has a final score of 93%. The Complexity score is owed to the number of used variables and data structures.
6%. In the Consistency category, its weak weight of 22% is also owed to the use of several returns through the code. Finally, it is possible to see that both solutions have not been plagiarized (100% original) and students follow the good practice of not repeating their own code (0% of duplicated code). These assessments led to a final grade of 29% on the first case and a significant 89% on the second case. Quimera also completes this evaluation with radial charts to a quicker and easier comparison of the solution performance in the different grading categories.
Architecture iQuimera architecture is organized in four levels, as depicted in Figure  2. • The Data level represents the data abstraction layer. It is composed of the modules related with the storage of the data concerned with contests, users, and problems in a relational Database. This level also includes the Code Repository, where all the students' submissions are stored. • The Main Engine level works as the system core, linking and controlling the communication between the several components of the system. This level includes: the Course/Problem and the Group/User managers which are responsible for the interaction with the data associated with the problem and user management tasks; The Continuous Integration Engine that is responsible for keeping the Code Repository integrity, managing the tasks associated with Code Repository update and with the continuous assessment process; and  • The Pluggable level encloses all the plugins currently available in the system.
, 2013). To implement this model, we perform a semantic comparison between both outputs based on a Domain Specific Language (DSL), specially designed to specify the output structure and semantics -the Output Semantic-Similarity Language (OSSL). The OSSL design also supports the mark of partially correct answers. For this, we are extending the grading module of Quimera with a Flexible Dynamic Analyzer (FDA). Figure  3  depicts the architecture of that extension, which is composed of three modules: the OSSL Processor, the Flexible Evaluator and the Grader. The OSSL Processor is responsible for producing the set of resources required to execute, validate and grade the submission under assessment. It receives an Extended Learning Object containing the problem description, the associated metadata and the OSSL specification, and generates the set of Inputs, the set of the Expected Outputs (through an intermediate representation, IR) and the Grading Instructions.
A valuable coproduct is the generation of success statistics and reports for every team member who performs an integration  (Miller, 2008). We are enriching Quimera evaluation process by taking advantage of the techniques used in CI, to improve students' effectiveness  (Vilas Boas et al. , 2013). To the best of our knowledge, CI methodology was never attempted as assessment tool within the educational environment, more specifically, in teaching programming languages to beginners. Figure  5  depicts the Quimera system extension to include the CI methodology. This process requires the implementation of a Code Integration Engine (CIE) with capability to work with some of the common Version Control Systems. New code integration will be automated as much as possible, using the automerge mode of those tools to minimize collisions.
After a successful Integration, CIE builds the code, with the tools already available in the AGS. Along this process, the warnings and errors found are reported. Then, some metrics are evaluated directly from the source code to enrich the final report. As Recurring to the AGS, the executable code produced is deployed to a sandbox running on protected environment, in order to be tested. This allows to emulate the real environment where the code should be tested and prevents system failure that can come from the execution of malicious code. After deployment, the set of test units is run and a report about the code correctness is generated. This report is the main result of the integration. Finally, another report is generated with details about the status of each step of the process described.
CONCLUSION We discussed the difficulties inbred in teaching and learning Programming Languages and proposed iQuimera, a system developed in the scope of computer aided education to help making this process more successful through problem-solving paradigm. iQuimera extends Quimera, an hybrid (static and dynamic) Automatic Grading System (AGS) in what concerns students evaluation approaches. Our contribution is two fold. On one hand, we propose a more flexible assessment model accepting answers that have syntactic differences (although semantically correct), and also partially correct answers. On the other hand, we propose to apply Continuous Integration (CI) principles for a continuous assessment of group elements. Although iQuimera requires more configuration effort from the three actors enrolled than the traditional AGS-more time to specify the problem, test vectors, and grading mechanisms (teacher), to manage all the participants and processes (admin), and to use the system in collaborative mode (students), as well as, more sensibility to tune appropriately the system (teacher)-, it is not an effort necessary each time someone wants to use the system, but it shall be done only once per course or exercise.
Thus, we believe that this configuration effort is surpassed by the advantages iQuimera provides with CI and Flexible Dynamic Analysis adoption. We plan (1) to finish the implementation of the Flexible Dynamic Analyser and the CI engine; (2) to develop new front ends in order for iQuimera to accept other programming languages than C; (3) to extend iQuimera such that it performs with minimal students intervention. Afterwards, we plan to test iQuimera with real users by means of a carefully sketched real case study, in order to verify its usefulness and benefits.
Molecular dynamics study Model structures for wild type (usual BChE) and p. Val204Asp mutant were prepared from the X-ray coordinates of PDB ID 1P0I  [17]  as described in our previous studies  [18, 19]. For p. Val204Asp mutant of BChE, the Val204 side chain was manually converted to aspartic acid and its side chain was minimized with other protein atoms fixed. Minimization and MD simulations were performed with the NAMD 2. 9 program  [20]  and the CHARMM36 force field  [21]  on the Lomonosov Moscow State University supercomputer  [22]. After solvation and addition of ions, protein structures were saturated with water molecules and water box equilibrating runs were performed as described in  [18]. This was followed by a full dynamic simulation of each system performed for 100 ns under periodic boundary conditions at a constant temperature of 298 K and constant pressure 1 atm.
1699G. A, p. Ala539Thr). The last one, which was not previously described nor was included in any mutation databases, introduced a mis-sense mutation at amino acid residue 204 (c. 695T. A, p. Val204Asp, GenBank Accession #KJ513459) (Fig. 2 ). It involves a residue highly conserved across species (Table  2 ). In silico predictions identified this mutation as potentially deleterious: i. e. PolyPhen-2 score of 1. 0 (sensitivity: 0. 00, specificity: 1. 00), and Mutation Taster score of 152. This mutation was observed in the patient's father (patient I-1) at heterozygous state, whereas the mother (patient I-2) was compound heterozygote for the atypical variant and the Kalow variant. Mutations near residue Val204 have previously been described: p. Ala199Val  [25] , p. Ala201Thr  [26]  and p. Ser203Pro  [27].
Acknowledgements. GCGC is grateful to the  Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP, Brazil)  project  2010/03537-7  and to the  Coordenação de Aperfeiçoamento Pessoal de Nível Superior (CAPES, Brazil)  project  419011-4  for the granting of PhD scholarships. We are indebted to  Jean-Luc Bouchez ,  Loïc Labrousse  and  Djordje Grujic  and one anonymous reviewer for their criticisms that helped substantially to improve this manuscript. Additional assistance by  Bénédicte Cenki-Tok ,  Lucelene Martins ,  Fleurice Parat  and  Carlos Eduardo  is greatly appreciated. Doriane Delmas  and  Christophe Nevado  are acknowledged for the preparation of high-quality polished thin sections. Edited by:  F. Rossetti.
Coordination problems in ECA rules Event-Condition-Action (ECA) rules are defined  [13]  as a set of rules where each of them 'autonomously reacts to actively or passively detected simple or complex events by evaluating a condition or a set of conditions and by executing a reaction whenever the event happens and the condition is true'. The form of the rule is: ON Event IF Condition DO Action. Some characteristics are that: a rule is activated only by events; its execution is autonomous and independent of other rules in the system; it implements a reaction to the incoming event; it contains a guarding condition to execute such actions. Research on ECA rules is often related to active database management systems (ADBMS)  [3, 14] , where events represent modifications produced in the database, and ECA rules are used to control the integrity.
But they have also been used in different control environments  [8]  or adaptation frameworks  [10] , and there are many different implementations of ECA rule-based systems. ECA rules are a language derived from practice, and not constructed from a formal definition in the beginning. This is comparable to other cases like StateCharts and its multiple variants and implementations (e. g. in UML, or in the StateMate tools of iLogix  [1] , or in Stateflow/Simulink), or like works on the verification of implementation languages like Java or C. Therefore, there is no unique reference or formal semantics, and they can not be submitted to formal analysis as such. Coordination problems The nature of ECA rule-based systems shows different problems in their execution, the most extended  [18]  being as follows.
ECA rule systems are validated, detecting the described issues. Our proposal constitutes a formal semantics of ECA rules, covering variants of rule engines, and defined concretely by translation into a formally defined language, for which formal tools are available. Rules execution is also controlled and coordinated to avoid the described problems at run-time. We will concentrate on small or home environment as target systems, although our results are generic enough to be applied in any ECA rule-based system. The Heptagon/BZR programming language  [2]  is used here because of its capability to express behavioral invariants in the system in the form of contracts, which allows verifying the application by model checking as well as controlling or coordinating the execution according to the described invariants.
g. , by controller synthesis) of programs. Heptagon/BZR  [2]  is a synchronous dataflow programming language with support for equations and automata. This language also provides a contract mechanism allowing the use of discrete controller synthesis (DCS) within the compilation, using the Sigali synthesis tool  [12]. The discrete controller synthesis method is based in partitioning input variables into controllable and uncontrollable ones. For a given objective, such as staying in a subset of states, its DCS algorithm will automatically compute, by symbolic exploration of the state space, the constraint on controllable variables, so that the behavior satisfies the objective, whatever be the values of the inputs from the environment. Figure  1 (a) represents the control loop. The automata-based program is in charge of controlling the environment.
The behavior of the automata is constrained by the synthesized controller, which is in charge of maintaining the system in the desired subset of states. The main elements of a Heptagon/BZR program are: -Nodes: blocks of equations or automata with input and output signals -Equations: determining the value of node outputs. A set of equations in parallel are separated by semicolons. -Automata: mode automata using states, input and output signals. -Contracts: describing invariants to be enforced by control at execution. The compiler generates executable code in C or Java. Figure  1 (b) shows an example of Heptagon/BZR code. It contains a delay node, with an automaton which makes use of a controlled variable to delay the emission of a received signal. A main node makes use of this automaton. It includes a contract to enforce that both signals are not emitted at the same time.
This allows emitting the desired value in the same execution step. Heptagon/BZR has been used by some work in smart home / environment context, to design safe control systems. In  [19] , Heptagon/BZR is proposed for the autonomic management of small environments. The behavior of devices is represented using automata and control objectives are described as contracts. For instance, it can avoid the request to turn on a device if it can generate an energy consumption higher than the specified. In  [7] , a similar approach is proposed   to provide safe environment for disabled people. However, none of these works featured ECA rules as a high-level description language. In another domain, the coordination of multiple autonomic loops in adaptive computing systems has been approached with a discrete control approach  [6].
We propose a transformation to Heptagon/BZR code from the described ECA rule-based system. As shown in Figure  4 , the generated Heptagon/BZR program will be defined in the body of a main node. This node is structured into three sub-nodes named events, rules and devices. The main node will receive all the sensor signals from the devices. The events node will use them to determine if events occur according to their definition. Events and devices signals are then passed to the rules node, where rules are activated according to their firing event and condition. Actions corresponding to activated rules are then used in the devices node, to be processed before being sent to devices, according to the corresponding device policy. The Rule Engine contains the execution policy to be simulated, determining the behavior of the rule-based system.
Code transformations Figure  5  shows the skeleton for the code generated from a textual representation of an ECA rule-based system according to the grammar of Figure  2 , with terms that are defined in the following. The order of the program is that nodes are defined before being used as sub-nodes in later nodes. The main node (e) invokes the sub-nodes events (defined in (a)), rules (c) and devices (d) nodes. The rules node (c) invokes the sub-node rule_engine (b), which models the execution policy, as described in 4. 2. Event detectors, rules and devices are translated as lists of equations inside of the indicated nodes. The developed tool implements several transformation schemes to translate events, rules and devices descriptions into Heptagon/BZR code, which are described for every element.
We consider an ECA system S = (R, E, D). The function name is used to define Heptagon/BZR variable names from the set  N of rules, events and devices names. We consider for the sake of clarity and simplicity that Boolean expressions in the ECA language corresponds to the Heptagon/BZR ones, and thus they can be used as they are. Figure  6  gives transformations to Heptagon/BZR for several terms. The <de-vice_outputs> list is generated over all the devices and their corresponding outputs. Similarly, we can generate <device_inputs>. The <final_event_names> list is build similarly to <event_names>, but adding the "final_" prefix, to differentiate inputs and outputs of the rule_engine node. Other lists are created similarly, <request_devices_inputs> and <temp_event_names>, but adding "req_" or "temp_" prefixes respectively to the names in their counterpart lists.
Execution models As said before, the transformation is designed to support different execution policies in ECA rule-based systems. We currently support transformations for parallel and delayed execution. The code generation for the rule_engine node will differ for every case. For the delaying of events, as shown in Figure  9 , the delay automaton is used as for the device node code generation. Only one event will be sent to the rules node for every execution of the controller. For the parallel execution model, as shown in Figure  10 , all the events are allowed to be activated in the same execution step without restrictions. Other execution policies can be added in this node to simulate any ECA execution model.
Here is a simple example of redundancy: The Sigali tool is used to solve this problem. The redundancy can be better checked using this tool. The capability of working with equations  [12]  in Sigali is used to detect the situation where the condition of one rule is included in the condition of another rule, thus making them redundant. For Sigali this means that the solutions for the equation c 1 = true is a subset of the solutions of c 2 = true. Sigali code performing this check is generated for every couple of rules that fulfills the following conditions: -Rules are activated by the same event -The set of actions of one rule is a subset of actions of the other one. -The set of variables used in the conditions of both rules are not disjoint. This filtering also helps reducing the quantity of operations in Sigali.
The Sigali tool will detect inconsistencies failing to generate the controller, indicating that the program it not executable regarding the contracts. Circularity generated by internal events can be detected by Heptagon/BZR, for the case of the parallel execution model, as a causality error at compilation time. The following code generates a circularity problem: ON internal1 IF true DO internal2 ON internal2 IF true DO internal3 ON internal3 IF true DO internal1 A dependency cycle occurs in the definition of rules in a way that these rules are always activating themselves. The circularity is detected independently of the number of involved events. The generated code is as follows: rule0 = (internal3) & (true); rule1 = (internal2) & (true); rule2 = (internal1) & (true); internal2 = rule2; internal1 = rule0; internal3 = rule1; The dependency cycle will be detected by Heptagon/BZR as a causality error.