dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgments The authors would like to thank  Marc Boyron  and  Julien Diperi  for the robot and the testbench realization;  Nicolas Franceschini  for helping in the design of the robot,  Franck Ruffier  for the fruitful discussions and the help implementing the flying arena. We would like to thank the referees for carefully reading our manuscript and for giving constructive feedback which improved significantly the quality of the paper. We also acknowledge the financial support of the  Future and Emerging Technologies (FET) program  within the  Seventh Framework Programme for Research  of the  European Commission , under  FET-Open Grant   237940. This work was supported by  CNRS ,  Aix-Marseille University ,  Provence-Alpes-Cote d'Azur region , and the  French National Research Agency (ANR)  with the EVA,  IRIS , and  Equipex/Robotex  projects ( EVA  project and  IRIS  project under ANR grants' number  ANR608-CORD-007-04 , and  ANR-12-INSE-0009 , respectively).
We show how our model leverages both structural and computational reflection to meet the properties we have identified and present its implementation in the Pharo language [BDN + 09] discussing the trade-offs that remote debugging imposes on reflective facilities. Finally we validate our proposal by exemplifying remote debugging techniques supported by Mercury's properties, such as remote agile debugging and remote object instrumentation. The contributions of this paper are the following: • The identification of three desirable properties for remote debugging solutions. • The definition of a remote meta-level and infrastructure for remote debugging that can exhibit these properties. • A prototype implementation of our model and its validation. Our work is organized as follows: we begin by providing definitions and motivation for remote debugging in Section 2.
We then introduce the properties for remote debugging solutions (Section 3) that we have identified. Then in Section 4 -given these properties -we evaluate existing solutions. Section 5 presents our proposed model: Mercury. Section 6 details our prototype implementation of the Mercury model. Section 7 presents the experimental setting and validation of our proposal. Finally Section 8 concludes our work and presents future perspectives. We provide working definitions for debugging that depend loosely on those given by Zeller  [Zel05]  and Sommerville  [Som01]  respectively: Debugging is a two phases process via which a programmer: i) Relates a failure in the observational domain of a program to a defect  [Bei90a, Hum99]  in the program's code and ii) Subsequently validates the elimination of a defect by applying a fix in the program's code relating it to a success in the observational domain.
Evaluation of Existing Solutions We now study existing debugging solutions of major OO languages in current use today (Java and other OO JVM-based languages (JPDA)  [Ora13b, Ora13a] , C# (. NET Debugger)  [Mic12b] , C++ and Objective-C (through Gdb)  [RS03] ) and Javascript  [Mic12a]  as well as dynamic languages with live programming support (such as Smalltalk and its debugging model  [LP90] ) taking also into account bleeding-edge technological achievements [Zer12, WHV + 12, PTP07] and very recent research results [WWS10, BNVC + 11, RBN12].
Existing Solutions JPDA/JVM Java's debugging framework stack is JPDA  [Ora13b]  and it consists of a mirror interface (JDI)  [Ora13a, BU04] , a communications protocol (JDWP) and the debugging support on the target as part of the virtual-machine's infrastructure (JVM TI). The application on the target machine must be specifically run with debugging support from the VM (the JVM TI) for any interaction between the client and the target to take place. JPDA does not provide facilities to dynamically update the target other then the hot-swapping of pre-existing methods. The communication stress is handled by the low-level debugging communication protocol (JDWP), whose specification is statically defined. The debugging support for other JVM-based languages such as Scala  [MO06]  [Dra14], JRuby  [Gra14]  and Groovy  [Eis14]  rely on the debugging interfaces provided by JDI and provide all or a subset of the aforementioned facilities  [Bru12].
JS/Rivet In-browser debugging of client-side web-applications is out of scope of our current work. Nevertheless we surveyed the debugging tools of the following web-browsers: IE [Mic14], Mozilla  [Moz14]  and Chrome  [Goo14]  in terms of the features discussed in Section 3. These solutions apart from classic debugging facilities for execution control and breakpoints, offer event-driven debugging facilities for the DOM (Document Object Model [WAC + 98]) and some limited form of live-editing for slots and pre-existing methods. Our own work is more related to the debugging facilities of standalone javascript applications (like those of Node. js [Joy14]) which have nevertheless very rudimentary support for execution control and breakpoints. The experimental solution of Rivet from Microsoft  [Mic12a]  comes closer than other solutions for JS to what we have described in Section 3.
It supports run-time evolution through live-patching and has an easily extensible communication architecture build on top of HTTP. AmbientTalk AmbientTalk is an ambient-oriented programming language dedicated to mobile ad-hoc networks. AmbientTalk's reflective model supports mirages  [MCTT07]  which are an extension to the mirror model adding implicit reflection capabilities. Through implicit reflection AmbientTalk extends the contemporary API of mirrors with the following three methods: a doesNotUnderstand(selector) protocol for message sends and two implicit hooks for object marshalling (pass() and resolve()) [MVCT + 09]. These hooks can be used during a debugging session to support some of the object-oriented execution events we describe in Section 3, such as instantiation events, slot editing and interception  [Cut14].
Run-Time Evolution As seen in Table  3  debugging environments of mainstream OO languages (JPDA,. Net Debugger, Gdb) do not support run-time evolution with the exception of a save-and-continue facility for pre-existing methods. In the case of Gdb method hotswapping can lead to inconsistencies  [Zel05]  since it is supported through memory patching, which is a blind process that replaces execution instructions in memory, without knowledge of the underlying semantics of the language. In the Java world recent developments (through Jrebel and DCE) provide full support for this property as do more dynamic environments such as Smalltalk, Bifrost and Rivet.
Comparison Overview In Table  1  we present an overview of our comparison in terms of all properties that were described in Section 3: As we can see from Table  1  debugging solutions based on reflection (such as Smalltalk and Bifrost in the local scenario) offer the most complete solutions in terms of run-time evolution and semantic instrumentation, but lack support for adaptable distribution (as in the case of AmbientTalk). On the other hand solutions of mainstream OO languages (JPDA,. Net Debugger, Gdb) and their extensions (Jrebel, DCE) lack support for either run-time evolution or instrumentation (or in some cases both). Other solutions (Rivet, TOD, AmbientTalk, Maxine) have partial support for some but not all of our properties. There is no solution that meets all our criteria in a satisfactory way.
The Core Meta-Level The meta-level located on the development machine (left part of Figure  4 ) is a set of mirrors that reflect on objects (e. g. , instance of the class Point) on the target side (right part of Figure  4 ). The target machine also includes support for reflection and debugging. This is the role of the package RTSupport that includes the RunTimeDebuggingSupport class (our remote facade). On the left side of Figure  4 , we depict the 3 core classes of our meta-level. The root is the Mirror class, that declares the targetObject field. So, every mirror holds a remote reference to one object on the target. Nevertheless, an object on the target can be reflected by multiple mirrors on the development side. Both on the developer's end and on the target, a unique object is responsible to handle all communications to the other side.
For structural reflection, this means that the addition of a new package, a new class or method through mirrors, etc. in the development side results in a structural update of the running application on the other side. These 8 core classes depicted in Figure  7  define an API that supports run-time evolution. Instances of these classes reflect on remote objects on the target and all of their methods can be executed while the application is running. ObjectMirror. An ObjectMirror enables retrieving information from the object reflected such as its class, reading/setting its fields or sending new messages to it but also changing its class (setClass). EnvironmentMirror. It is the entry point mirror to the target application depicting the remote environment as a whole. Through the environment mirror globals are read/written, loaded packages are retrieved, interrupted processes and unhandled exceptions are accessed, code is evaluated (evaluate) and packages can be created, removed, or edited (newPackage, removePackage, etc.
). PackageMirror. A package mirror reflects on loaded packages on the target application. This mirror gives access to package's meta-information such as its name and the classes it contains. Classes can also be added or removed using the methods newClassNamed and removeClassNamed. ClassMirror. Through a class mirror the name, superclass, fields, methods and enclosing package of the reflected class can be retrieved. The superclass can be changed, new instance variables and methods can be added/removed or edited (setSuperClass, addInst-VarName, deleteInstVarName, addMethod, deleteMethod, etc. ). (  MethodMirror. Apart from retrieving the name, source or class membership of a Method, the developer can edit a method in place (recompileWithSource). ProcessMirror. It allows one to retrieve meta-information on a process such as its stack and manipulate the execution flow.
Limitations In contrast with the debugging solutions presented in Section 4 our solution has the following limitiations: Distributed Applications Mercury is a model for remote debugging and can thus seperately debug the connected parties of a distributed application, as is usually the case with debugging remote server or client applications. Special debugging facilities for distributed applications -such as asynchronous breakpoints supported by REME-D [BNVC + 11] -were outside the focus of our work. VM-Debugging Also our solution concerns itself exclusively with language-side debugging, in contrast for e. g. , with Maxine [WHV + 12]. Maxine targets a meta-circular language-vm system and can thus be used to debug both the Maxine virtual-machine as well as the java program running on top of it.
Discussion: Implementing Mercury in Java We take the Java language as an example to investigate the feasibility of implementing Mercury in other languages. We discuss the technological prerequisites for implementors for each part of our model as was discussed in Section 5. A causally connected dynamic meta-level for debugging that can support run-time evolution can be build for Java by combining the currently available debugging infrastructure found in JPDA  [Ora13b]  with the incremental updating facilities of the DCE VM project  [WWS10]  or those found in the JRebel vm-plugin  [Zer12]  (see also Section 4). Support for semantic instrumentation can be build on top of solutions for bytecode manipulation or reflective intercession for Java like those in Iguana/J [RC00], Reflex  [TBN01] , ASM  [BLC02]  or JavaAssist  [CN03].
The Droid and Cloud File Browsers Figure  17  shows the Droid-Browser application running on the phone and tablet devices (middle and right part of Figure  17  respectively). The Droid-Browser is a local file browsing application that presents the option to upload local files stored on the device to the cloud (i. e the remote server of our experimental setting). On the other hand the Cloud-Browser is a normal web-application that presents the option to download files that where previously uploaded on the server. The two applications share part of their code for file browsing and serving of web-pages as seen in Figure  12. The core logic of both applications resides in two subclasses of a common ancestor class named FileBrowser. FileBrowser is itself a subclass of WAComponent which is part of the Seaside  [DLR04]  web-framework.
Case Study I: Remote Agile Debugging Our starting point is the deployment of our target software in all three devices, and the subsequent launch of the applications. We then connect through the debugging front-end of Mercury to our remote targets. All our targets upon start-up raised the same error. From the exception name and the remote stack we can deduce that a NotFound error was triggered from inside the #detect: method of class Collection, as seen in Script 8. After navigating the stack through our context mirrors we come to the first context related with our application, which can be seen in Script 9. The method in Script 9 is an extension Our next step is shown in Figure  12. Since Mercury can dynamically evolve the target's code (run-time evolution) we can remotely introduce new classes and methods for testing to all of our targets while debugging.
In this case we introduce the test class FileBrowserTest (right part of Figure  12 ) as a subclass of the class TestCase which is part of the SUnit framework on the target. Getting a class mirror on FileBrowserTest will allows us to incrementally run tests on our remote machines and debug their results, without ever quitting our current debugging session. The code of our FileBrowserTest class is given on Script 11. Our first method #suffixOf: is a helper method that replicates the behavior of the String»#suffix method of Script 9. Our second method #testSuffixWithDot invokes our helper method on a simple dotted filename and makes an assertion about the return value of this invocation (this case is similar to our initial error on our tablet). Method #testSuffixWithoutDot makes an assertion for the case of a notdotted filename (similar to our initial error for the smart-phone).
Debugging Hypotheses and Fixes At this point having 12 different threads of execution at our disposal spanning 3 different devices, we can start debugging our hypotheses. Our expectation for the String»suffix method is to return an empty string for filenames without a dot. Since our second test fails with a NotFound error notification we can now device Figure  13  -Remotely Running and Debugging multiple Test-Cases while maintaining the initial error a possible fix. We need to introduce an error handler for this case which will return the empty string when the error is raised. We want of course to test this possible fix before applying it to the String»suffix method, especially because we are not expecting that the fix will solve the two other cases of the defect. In order to do so we remotely update the FileBrowserTest»suffixOf: method as seen in Script 12.
In line 5 of Script 12 we introduce an #on:do: exception handler that returns an empty string when the NotFound error is raised. Subsequently we re-run all tests. The results are shown in Figure  14. In Figure  14  on the left we can see that our #testSuffixWithoutDot test now runs successfully, ensuring the applicability of our fix for this case. For the two other cases though as we expected the tests fail. After the introduction of the error handler in FileBrowserTest»suffixOf: the defect manifests itself as failed assertions on our two remaining tests. Debugging these last two failed assertions will be the focus of our second case study.
The Hidden Path Hypothesis We continue where we left off in our first case-study (Figure  14 ) but now turn our attention to the hidden path failure on the server that we discussed on Section 7. 3. We would now like to examine the execution of the FileBrowserTest»suffixOf: method more closely. We restart the execution of the current context and then we step-into the suffixOf: method (Script 11). In order to get to our point of interest though we now have to follow the iteration seen on line 4 of Script 11 (inside the block closure argument to the #detect: method). Getting inside the loop requires in total 10 control-flow commands from our initial execution point and for each additional iteration 3 commands more. A breakpoint inside the loop can reduce the number of commands we need to issue from the ui (to 1 command per iteration), but still the placement of the dot is such that we would need 30 iterations to get there (the loop iterates the string starting from the end).
Combining Object and Stack Debugging in a Remote Setting Stack-based debugging got us this far, but it is becoming cumbersome. We need to narrow the domain of our examination. What is needed here is either a conditional break-point or a watch-point breaking exactly at the required iteration. A generalized object-oriented version of such facilities as we saw was proposed by Ressia  [Res12]. In a nutshell these facilities instead of using source-code locations (line numbers or method-names) as their point of reference for interrupting execution, use run-time objects of interest and their events. For instance, the programmer can put a breakpoint on the next message send that will be received by an object or the next read (or write) of one of its instance variable. We will now see how Mercury brings this object-centric debugging to a distributed setting through remote instrumentation.
We continue from our execution point inside the suffixOf: method (Script 11) but instead of trying to navigate through the loop or inside the #detect: method we now invoke the remote instrumentation interface of Mercury (seen in Figure  15 ). In the left part of Figure  15  we can see the failed assertion and its stack, the execution is currently suspended in the FileBrowserTest»suffixOf: method. In the right we can see the remote instrumentation ui. From the panel in Step 1 we can choose the semantical event which we wish to instrument (Object Interaction in our case). The text entry in Step 2 receives an expression whose result will be returned as a mirror in the developers machine. This mirror will serve as a target for the semantical event of Step 1. The text entry in Step 3 receives additional information related to the event which we wish to instrument.
While on lines 4 through 6 we instruct the reflectogram to perform the default action (for this semantical event) when execution resumes from the breakpoint of line 3. In a nutshell we have instructed Mercury through this process to halt execution the next time the dot inside the hidden filepath will interact in anyway with the dot object (representing the suffix separator defined by the FileSystem). This way through remote object instrumentation we have implemented a custom conditional watchpoint for our case with object-centric semantics. The results of this process are seen in Figure  16. In the left part of Figure  16  we can see that the assertion's execution continued up until the semantical event that we defined above and then halted (Step 1). Specifically (as seen in the code editor of Figure  16 ) execution halted when the two objects we were targeting (the dot inside the filepath and the dot of the FileSystem interacted).
We have validated the applicability of our proposal through a prototype implementation in the Pharo language. We have illustrated our approach through several working examples in an experimental setting of two case-studies. Future Work A future perspective for this work is to examine the prerequisites of supporting advanced debugging facilities such as delta-debugging  [Zel02]  in a remote setting. We also plan to explore more issues of mirror-based systems in a remote setting such as ontological correspondence  [BU04]. Finally we would like to extend our implementation to be completely independent from local reflection facilities on the target (such as the host compiler) as exemplified in our previous work with MetaTalk [PBD + 11].
Simulation results and Discussion The simulation has been carried out using Matlab Simulink package, under a wind speed profile whose mean value is (11. 5 m/s). The evaluation tests have been done with the wind speed input defined by Fig. 9 , got from a Matlab Simulation. The system parameters are given in the appendix A. The and the output power is shown in the following for each one of the presented algorithms. The studied and proposed algorithm MEPO based on VSAS approach is tested in simulation and compared with the different MPPT methods (OTC, P&O ) are shown in Figs  (10, 11 ,12 and 13) ; The simulation results are summarized in Table  I   [2]. The MPPT controller ensures the tracking of the optimum power points at variable wind speeds, by maintaining the power coefficient to its maximum value as shown in Fig.
Conclusion The PMSG is nowadays a popular choice for wind energy conversion systems. This popularity is mostly due to its ability for large variable speed drive. In this paper we present the models of the different parts of a WECS: the generator side and the grid side converters have been modeled in Simulink. The generator side controller has been used to track the maximum power generated from WT. In this part, OTC and classical P&O methods MPPT are reviewed and discussed, for wind turbine driving and we proposes a new MPPT algorithm (MEPO) deduced from the VSAS approach. We analyze a simulation and comparison of three selected control methods in terms of efficiency and speed of response. The verification of maximum power tracking control is illustrated in the presented figures show that the best MPPT algorithm is the MEPO.
R. leguminosarum has distinct symbiovars  [11] : symbiovar (sv. ) viciae forms nodules only on the roots of the legume tribe Vicieae, which includes vetches, peas and lentils (Vicia, Lathyrus, Pisum and Lens), while sv. trifolii is confined to clovers (Trifolium). The 'nodulation genes' that define these two distinct host specificities, together with genes responsible for the process of nitrogen fixation, are normally encoded on a plasmid in this species. There are complete published genome sequences of R. leguminosarum sv. viciae strain 3841 and sv. trifolii strains WSM1325 and WSM2304  [15 -17] , and unpublished genome sequences of other strains have recently become available in the public International Nucleotide Sequence Database Collaboration (INSDC) databases. The genome of R. leguminosarum is large and complex, consisting of a chromosome and a variable number of low-copy-number plasmids, including two that can be called chromids  [18]  because they are large and carry some core genes.
Assembly and mapping of the sequence reads Roche NEWBLER 2. 3 assembler was run using the command line (runAssembly) option with 90% sequence identity and 40-bp minimum overlap as parameters to perform de novo assembly of each of the Rhizobium genomes. Shell scripts were written to run runAssembly on multiple datasets. GSMAPPER 2. 3 with 90% sequence identity and 40-bp minimum overlap was used to perform reference-based assembly of each genome using 305 core genes from strain 3841 as the reference genes. These 305 genes were those shown to be common to all chromid-bearing bacteria analysed by Harrison et al. [18]. Shell scripts were written to run runMapper on multiple datasets. Nucleotide information of 305 core genes was extracted from every draft genome using a Perl script, and a shell script was used to merge this information with their respective genes present in fully sequenced Rhizobium genomes.