dataesr/scientific-paragraphs-categorization huggingface dataset:
The file indicates the node number, the debugging phase to consider (Steps 1, 5 or 6 on Figure  1 ), as well as the identifiers of the suspected nodes. The host machine is supposed to run a Linux-based system and have GDB for debugging. The MPSoC runs a MPSoC kernel characterized by a MPSoC API. The MPSoC API is inspired by the the POSIX standard and includes basic functions for execution flow management, synchronization, network communications and I/O. Our trace collection tool is deployed on each node of the MPSoC platform. As its purpose is to intercept the calls to the defined MPSoC API, it provides a simple interface including a trace function used for generating trace entries. The tool for deterministic replay implements the algorithms presented in Section III using as basis the MPSoC API.
A. Debugging a Tetris Application on an MPSoC Platform For this use case, we have used a Stagecoach expansion board having two OveroFE COM nodes (computer-on-module)  1. Each node has an ARM Cortex-A8 600MHz processor with 256MB of DDR RAM, 256MB of NAND flash memory and a microSD port. The two nodes occupy the first and the third slot of the board. They are connected through a 100Mb/s Ethernet link and have distinct IP addresses. The RJ45 slot of the board is used to connect to an external network card which gives IP access to both nodes. We have implemented our MPSoC API using the POSIX and the libc interfaces. We have installed the platform from scratch by creating a bootable microSD with the needed Linux distribution. The system image includes the 2. 6 Linux kernel, libc6, a file system and the ssh service.
B. Debugging a Video Decoding Application on a NUMA Platform To validate the scalability of our approach and given the unavailability of a large scale MPSoC platform at the time of the experience, we have developed the use case on a NUMA platform. The considered MPSoC software is the FFMPEG video decoder  [8] ,  [9]. The NUMA architecture used in our experiments has four nodes, each having eight dual core 2. 2 GHz AMD Opteron processors and 32GB of main memory. In the final experimental setup, one node is considered to be the master one, and as such can access the file system, as well as the peripherals. The master node is also responsible for communicating input peripheral data to the other nodes. It occupies four of the NUMA processors, the other four being reserved for GDB. The other three nodes are MPSoC slave nodes.
The implementation of our MPSoC API uses the Linux2. 6 interface, as well as the libSDL 3 and libc libraries. The task management and synchronization functions are based on the POSIX interface and use the system call sched_setaffinity. The I/O functions encapsulate the accesses to the file system, the screen, the keyboard, the audio card and the system clock. The file system is accessed using the libc functions. The audio and video peripherals are accessed through libSDL calls. Finally, the system clock is accessed using a dedicated Linux register. The network communication primitives are based on the inter-process socket-based communication of Linux. From the FFMPEG suite, we have used the FFPLAY  [10]  and FFSERVER  [11]  components. FFSERVER is a video server, receiving video flows through different protocols (e.
g. , RTP or RTSP) and creating multiple output flows having different formats (H. 264, DIVX, MPEG-4, etc). FFPLAY is a video decoder, receiving synchronizing audio and video frames. Using these components, we have created a video mosaic application (cf. Figure  12 ). We have re-engineered the code to redirect all Linux function calls to calls to our MPSoC API. The video mosaic application exhibited a non deterministic bug. During some executions, one or more videos were not visible. By tracing one of these executions, we captured the situation showed on Figure  13. The trace of Node0 (FFSERVER) shows the non blocking receptions of messages coming from FFPLAY components. The other three traces (FFPLAY components) show, in the beginning of their execution, receptions of messages from FFSERVER, followed by synchronization operations related to the work with memory buffers containing the audio/video data.
C. Performances To evaluate the performances of our implementation, we have considered three criteria, namely the intrusion during normal execution, the trace volume and the execution speed during debugging. To evaluate the intrusion of ReDSoC during the recording phase, we have considered both the embedded and the NUMA platforms and have used the the native execution time and the reference execution time. The native execution time reflects the execution duration of the software without ReDSoC. The measure is obtained as a mean value of thirty executions. The reference execution time is the mean execution time of the same software with the same inputs but running under the control of ReDSoC. This execution is logically slower due to the interception of function calls and the tracing mechanism.
VII. CONCLUSION In this paper we argue that with the increasing scale and complexity of embedded systems, classic debugging techniques cannot be applied "as is". Non deterministic systems with numerous components need our debugging methodology which applies space and time reduction criteria to the error search space. For human comprehension, debugging should indeed be able to focus on a specific part of the target software and consider a limited time interval. We have shown the usefulness of this approach in our experiences with two multimedia applications on two different platforms. The debugging experiences have proven successful and our system has performed with minimal intrusion. The selection of the suspected software parts and the time interval to debug is a delicate issue which for now relies on the developer experience.
These results are obtained by implementing our model into the publicly available package SARAH, which enables us to create a spectrum generator in order to perform the RGE evolution of all model parameters at two loops, from the messenger scale M down to the TeV scale, with GMSB boundary conditions. We have implemented five gauge groups at full one-and two-loop running, plus oneloop self energies, from the GUT or messenger scale, Higgsing and breaking to the diagonal subgroup of 4 gauge groups, while finite shifts and threshold corrections are carefully applied for each degree of freedom. We finally stress that we have implemented a conservative (precise) formulation of GMSB with full two loop equations for soft masses in the hidden sector. Still at this level of specification a reasonably natural spectrum is obtained, which demonstrates the ease with which much lighter spectra would be obtainable if these high standards were relaxed or some more phenomenological parameterisation adopted.
Implementing a quiver framework for phenomenological studies In order to perform the RGE evolution of the models' parameters and masses and compute the resulting low-energy particle spectra, we implemented the two model variants into the publicly available Mathematica package SARAH 3. 3  [17] [18] [19]. SARAH is a "spectrum generator generator", which includes a library of models that may communicate with HEP tools that are widely used in most phenomenological studies  [30, 33, [45] [46] [47] [48] [49] [50] [51] [52] [53] [54]. In particular, SARAH performs the task of generating Fortran routines compatible with the SPheno spectrum generator  [18]. In order to implement our model, we have used the possiblity offered by the package to implement and link two different "regimes". These regimes correspond to those introduced in section 3.
As the LHC exclusions are presented in terms of specific models, we are therefore keen to reinterpret these in order to understand how these bounds translate in the case of our model. There are a number of ways in which this work may be extended. A first step, as mentioned earlier, would be to determine whether larger ∆'s can be realized without making m L a free parameter by including U (1) kinetic mixing or, more ambitiously, an additional SU (3). This could be achieved by means of the tools we have developed with the help of the publicly available package SARAH. It would further be of interest to study related models of flavour, or models with chiral non-decoupled D-terms at the same level of precision. By moving Higgs fields or generations onto different quiver sites, such models are relatively straightforward to implement in our setup.
Acknowledgments We would all like to thank  Florian Staub  for numerous communications on SARAH and Werner Porod on SPheno. M. M. would like to thank  Martin Winkler ,  Jan Hajer ,  Kazuki Sakurai ,  Lisa Zeune ,  Florian Domingo ,  Kai Schmidt-Hoberg ,  Felix Brümmer  and  Jörg Jäckel  for very useful discussions. A. G. would like to acknowledge enlightening discussions.
For years, Integrated Development Environments have demonstrated their usefulness in order to ease the development of software. High-level security or safety systems require proofs of compliance to standards, based on analyses such as code review and, increasingly nowadays, formal proofs of conformance to specifications. This implies mixing computational and logical aspects all along the development, which naturally raises the need for a notion of Formal IDE. This paper examines the FoCaLiZe environment and explores the implementation issues raised by the decision to provide a single language to express specification properties, source code and machine-checked proofs while allowing incremental development and code reusability. Such features create strong dependencies between functions, properties and proofs, and impose an particular compilation scheme, which is described here.
This assessment process takes a lot of time and is expensive. The Foc environment was created ten years ago (  [6] ) by T. Hardin and R. Rioboo as a laboratory language to study "how to provide comprehensive facilities" to developers of critical systems, complying to high-level rates of standards like  [15, 14, 7]. At this moment, only B, Z and some tools based on algebraic data types were used in such developments. The idea was to couple the programming facilities of OCaml with the capabilities of the theorem prover Coq while avoiding the use of some complex features of these languages. The help provided to developers by object-oriented features like inheritance and late-binding, by abstraction features like modules, by parametrisation features like functors was already widely recognized in the software development world.
Such features were required in the Foc specification to manage not only source code but also requirements and proofs. Their possible codings in Coq were studied  [5]  and some possibilities of logical inconsistencies brought by mixing these features were identified. Some of them were avoided by using a dedicated concrete syntax. The remaining ones require a dedicated static analysis to be eliminated. This was the first version of the "dependency calculus", studied by V. Prevosto  [10] , who also designed the first compiler of the language (which name evolved in FoCaLiZe). At that time, the programming language was a pure functional strongly typed kernel, proofs were done directly in Coq. Then, a language for proofs was introduced to enable the use of the automated theorem prover Zenon[1] and automatically translate them into proof terms of Coq.
FoCaLiZe is the current version of Foc. It provides a logical language to express requirements as first-order formulas depending on identifiers present in the context, powerful data-types and patternmatching, object-oriented and modular features, a language of proofs done by Zenon, which may use unfolding of functions defined by pattern-matching. From the whole development, the compiler issues a source file written in OCaml and a proof term submitted to Coq. The two files are kept close to the FoCaLiZe source to ease traceability and the compiler guarantees that, if the FoCaLiZe source can be compiled, then its OCaml translation will be runnable and its Coq translation will be checkable. This is a way to avoid returning errors from target languages, which would be unacceptable for the user.
In this paper, we present the main features of the compiler, trying to explain why they permit to improve the adaptability of FoCaLiZe to the needs of formal developments. More returns on user experience using FoCaLiZe and help provided by this environment can been found in  [4, 3, 12]. The first specificity of FoCaLiZe is the mixing of logical and computational aspects which create a lot of dependencies between elements of a development. Definitions are considered as terms of the logical language, properties can embed names of functions being unfolded in proofs. Late-binding allows to change definitions thus altering proofs done with the old version. The second specificity of the current version of FoCaLiZe is the maximizing of sharing between computational and logical codes, at the source level, through the use of inheritance, late-binding and modularity which also adds dependencies.
Semantical Framework Specification requirements and implementations should be together expressible in any FIDE, the first one by logical language, the second one by a programming language. If these two languages can be related through a single semantical framework, then the demonstration of the conformance of developments to requirements can be facilitated. Choosing an imperative style related to a Hoare logical language leads to some difficulties when composing specifications and unfolding function bodies, due to the lack of referential transparency. So FoCaLiZe is built upon a pure functional language. Then, whatever is the logic, functions can be consistently unfolded in proofs and thus, can be used without restriction to express requirements (called here properties) and proofs. Side-effects are however possible but they have to be confined into dedicated modules, separated from the rest of the development.
Properties of functions making side-effects can be separately demonstrated and rendered as contracts. Static strong typing, rich data-types and pattern-matching ease source coding and error detection. This is why the FoCaLiZe programming (sub-)language is very close to a functional kernel of the OCaml language. The logical sub-language offers first-order quantifiers and the ability to use identifiers present in the context in formulas. So formulas can contain free variables, which however are bound in the development context. These formulas are indeed formulas of a dependent type theory and are translated as such in Coq, relying on the Curry-Howard isomorphism : data types are translated onto types, properties onto types and functions on terms. Having our own logical syntax instead of the one of a dependent theory like Coq allows (not only) to restrict formation rules of terms.
Incremental Specification and Development through a Running Example To support further discussions, this section will gradually introduce a running example. It represents a "monitor" which inputs a value and outputs a validity flag indicating the position of the value with regards to two thresholds, and this value or a default one in case of problem. A fleshed-out version of this example was used to develop a generic voter used in critical software  [4]. Object-oriented features are often offered by IDE as they have the reputation to help software development. Here, assessment also should be helped and some of these features like complex rules of visibility (tags private, friend, etc. ) and possibilities of runtime late-binding can weight down this process. FoCaLiZe proposes two object-oriented features: inheritance and late-binding.
We call here inheritance the ability of introducing, at any stage of the development, properties, functions and proofs (called methods in FoCaLiZe) that these new items contribute to fulfill previously stated requirements. As usual, late-binding is the possibility of introducing the name, and here the type, of a function while deferring its definition. This allows to adapt definitions along the inheritance tree and enhances reusability. species Data = let id = "default" ; signature fromInt : int -> Self ; end ;; species OrdData = inherit Data ; signature lt : Self -> Self -> bool ; signature eq : Self -> Self -> bool ; let gt (x, y) = ˜˜(lt (x, y)) && ˜˜(eq (x, y)) ; property ltNotGt : all x y : Self, lt (x, y) -> ˜gt (x, y) ; end ;; The component (species) Data simply says that the input is coded by an integer, converted by from int to a value of the internal representation, which is denoted by Self.
The species OrdData inherits from Data, it declares two functions (lt and eq), defines a derived function gt and states a property ltNotGt using both declared and defined methods. As function types are parts of specifications, late-binding cannot change them. But late-binding can invalidate proofs done with an "old" definition and the compiler must manage this point. Late-binding also allows stating properties and delay their proofs, while the former are already usable to write other proofs. Restricting the access to some elements is needed and handled at the component level. A FoCaLiZe component collects not only types, declarations and definitions but also related properties and proofs. Inside a component, the manipulated data-types have a double role: a programming one used in type verification, a logical one when translated to Coq (this double view has to be managed by the compiler and it is not always straightforward as seen further).
To simplify the FoCaLiZe model, all data-types introduced in a component are grouped (by the way of product and union types) into a single data-type called representation). It gives to this notion of component a flavor of Algebraic Data Type, a notion which has proven its usefulness in several IDE (e. g. [2]). The representation can be just a type variable (i. e. be not yet given an effective implementation), whose name serves in declarations. It can be instantiated by inheritance (but not redefined) to allow typing of definitions. The species TheInt defines the representation (int) and functions already declared, then proves the property by unfolding gt and using a property found in the file basics of the standard library (this proof, which could be done in OrdData, will be used later). Functors allow parametrisation by components.
On the contrary parametrisation asks for its abstraction. Indeed, a component seeing the data representation of its parameters can manipulate this data without using the provided functions, hence breaking invariants and structural assumptions made by parameters and invalidating the theorems they provide. Abstract definitions of types is not sufficient as properties can still reveal the exact definition of a type (a bad point when security properties are considered). Thus FoCaLiZe has two notions of components. Species which expose their representation are only used along inheritance and late-binding during design and refinement. Collections which encapsulate the representation are used as species parameters during the integration process. To avoid link-time errors, any call of an effective species parameter must be ensured that all functions exported by this parameter are really defined.
Properties and Proofs A proof, intended to be mechanically checked, must be decomposed into small enough steps to be checkable by the prover. Our first try (Foc) to directly use the script language of Coq, revealed several drawbacks. First, it required the user to have a deep knowledge of Coq to powerfully use it and to understand error messages. Second, the user had to be aware of the compilation of FoCaLiZe elements to Coq. Third, the proofs too deeply depended on Coq. In FoCaLiZe an intermediate step to do proofs has been introduced. It is based on natural deduction which, being reminiscent of mathematical reasoning, is accessible to a non-specialist without too much effort. It uses the automated theorem prover Zenon. A proof is a hierarchical decomposition into intermediate steps  [9]  unfolding definitions, introducing subgoals and assumptions in the context until reaching a leaf, that is, a subgoal which can be automatically handled by Zenon.
Dependencies Computation To support generation of well-formed code, the notion of dependencies must be reinforced and formally studied. The theorem ltNotGt syntactically decl-depends on gt, lt, rep and def-depends on gt. Thus, its proof is ultimately compiled to a Coq term, where gt is unfolded, making arising the identifier eq. The type of eq is needed to Coq-typecheck gt and must be provided through the λ -lift abst eq of eq. Only λ -lifting syntactic def-and decl-dependencies would lead to a generated code looking like: Theorem ltNotGt (abst_T : Set) (abst_lt := lt) (abst_gt := OrdData. gt abst_T abst_eq abst_lt) : forall x y : abst_T, Is_true ((abst_lt x y)) -> ˜Is_true ((abst_gt x y)). apply "Large Coq term generated by Zenon". where the := construct binds def-dependencies, and where abst eq is unbound ! Moreover, raising eq also exhibits a def-dependency on the carrier through the one of eq.
Code generation of In 5 10 and In 1 8 use the last definition of methods of IsIn but they do not share their bodies. Some possible sharing of the methods of the parameter IntC are also lost. Not only code size increases but assessment takes longer since any collection should be checked in extenso. Thus, code has to be generated for all species. Method Generators In the following example, the species IsInE redefines filter. species IsInE (X is OrdData, low in X, high in X) = inherit IsIn (X, low, high) ; let filter =. end ;; collection ExtIn_3_8 = implement IsInE (. ) ; end ;; lowMin def-depends on filter. Its body, that is, the proof of lowMin in IsIn, can be shared by all species inheriting IsIn, if they do not redefine filter. But it cannot be shared with IsInE as the proof must be re-done.
Thus, redefinitions cancel sharing of def-dependencies. Assume that a method IsIn!m decl-depends on filter. Then all species inheriting IsIn!m and not redefining m can share its body, up to the calls of filter. Similarly the collections In 5 10, In 1 8 and ExtIn 1 8 can share the methods of IntC, up to the calls of methods on which IntC decl-depends. Thus, the body of a definition m (function or proof) of a species S can be shared along inheritance, up to the calls to methods of S and of its parameters upon which m decl-depends (thanks to the absence of cycles in decl-dependencies). The sharing is done by abstracting, in m's body, the names of these decl-dependencies, using the standard technique of λ -lifting  [8]. The result of this λlifting is called the method generator of m. To obtain the final code of m, this generator will have to be applied to the most recent values of its decl-dependencies, provided by the species (or its descendants) (spec-arguments) or by the effective parameters (param-arguments).
Module Data. Definition id : basics. string__t := "default". End Data. Generating code for species OrdData: The body of gt decl-depends on eq, lt and the representation as its inferred type is Self → Self → bool. Note that this body remains close to the source one. Inherited and only declared methods induce no code. Generating code for species TheInt: This species redefines id and defines eq, fromInt and lt. id has no dependencies whereas eq, from int and lt only have a def-dependency on the representation, whose value (the built-in type int) is bound (:= construct) to abst T in the corresponding method generators. The proof of ltNotGt decl-depends on the representation. It def-depends on gt because it unfolds its definition. Note that lt and eq do not appear in this proof : unfolding of gt does not unfold them recursively.