dataesr/scientific-paragraphs-categorization huggingface dataset:
80% F1 score for 80% threshold), Ebola (100% F1 score for thresholds greater than 80%), Germanwings (64. 96% F1 score for 90% threshold), Ferguson (approx 39% F1 score for thresholds greater than 75%), and Sydney Siege (51. 90% F1 score for 90% threshold). This effect was obtained thanks to the huge number of topics with which the model was trained, returning topics that are related. We are currently working on extending this model by considering retweets, likes, and other attributes to measure the social impact of a tweet, which in turn could improve the measure of credibility, and applying it to other languages, such as Spanish and French. Moreover, we are planning to use a larger dataset to have a greater variety of topics and keywords that can be used for analysis, as well as to evaluate other topic detection algorithms such as neural language models and community detection.
The Sheep Herding Task The task used here is an adaptation of the sheep herding task  [7, 15] , and is largely inspired by the experimental design in a previous work by Bennett et al. [21]. We created our own version of the task using Unity software (Unity Technologies, San Francisco, CA, USA). The participant needs to move a "dog" object (the cursor) to keep three moving "sheep" objects as close as possible to the center of the screen (for scoring), thereby preventing the sheep from going outside the circular pen (Figure  1 ). Each sheep moved permanently according to three forces: (1) Repulsion force: the sheep is repelled by the dog. The closer the dog is to the sheep, the faster the sheep moves in the opposite direction; (2) Pack force: the sheep moves towards the barycenter of the sheep positions; and (3) Random force: a Perlin noise was used to move the sheep randomly over time.
1). The overall difficulty perceived by each participant is expected to be maintained during successive repetitions, which is addressed a posteriori by comparing scores. The task used here is an adaptation of the sheep herding task  [7, 15]. We created our own version of the task using Unity software (Unity Technologies, San Francisco, CA, USA). The participant needs to move a "dog" object (the cursor) to keep three moving "sheep" objects as close as possible to the center of the screen (for scoring), thereby preventing the sheep from going outside the circular pen (Figure  1 ).
Hand as a Tool In hand condition, the dog on the screen was moved in perfect synchronization with the hand displacement on the table. For that, three markers were fixed on the back of the hand (wearing a glove) and tracked by an Optitrack motion capture system (V120: Trio, OptiTrack; NaturalPoint, Inc. , Corvallis, OR, USA), consisting of three infrared cameras following reflective markers. The position of the rigid body was streamed at 90 Hz to the Sheep Herding task in the Unity software to act as a guide for the dog's movements. No latency was perceptible by the participant. The gain between hand and cursor displacement was adjusted to offer a sensitivity similar to that of the computer mouse in mouse condition.
Statistical Analysis The statistical analysis was performed using Matlab (Matlab 2021b, Matworks, Natick, MA, USA). Outliers were identified by using the matlab 'isoutlier' function, which is based on three scaled median absolute deviations (MAD) away from the median. Each set of computed variables was tested for normality with the Shapiro-Wilk test using significant level p = 0. 05. A large majority of samples showed normal distribution. When this was not the case, log-transformed data were used for further statistical analyses. A two-way ANOVA with tool (mouse, hand) and repetition (1-5) as independent variables was used to detect possible interactions. When no interaction effect was found, a subsequent one-way ANOVA with repeated measures was performed.
The implementation of DEPREWRITER is based on dynamic program transformation: when a deprecated method is executed, a program transformation engine rewrites and recompiles the caller's code before continuing the execution. The approach presented in this article has been developed by the Pharo consortium. Since 2016, DEPREWRITER is used in production in multiple distributions of the Pharo programming language: Pharo 6, 7, 8, and 9 alpha. This article presents and validates this approach. The validation is done in two steps: first with an analysis of deprecations available in Pharo 8 and second with an open survey of software developers about DEPREWRITER. We studied 367 Pharo 8 deprecations, among which we analyzed the 218 rewriting deprecations that use transformation rules. We identified the validity conditions and reported defects to the community.
We also proposed 33 transformation rules to be added to the non-rewriting deprecations. Both contributions were accepted into Pharo 9 alpha. We classified the rules and identified possible points of improvement. In addition, we performed a user survey and collected information from 46 software developers: some of them used existing DEPREWRITER' rules and executed them on their code, others used DEPREWRITER to create rewriting deprecations, and finally, some were not aware of DEPREWRITER. 28 of 46 developers (60%) reported that the rewriting deprecations helped them, while 10 stated the inverse and 8 were uncertain. After discussing the current implementation, we sketch possible implementations for other languages than Pharo, showing that the approach is general enough to be applied to other languages.
Before going any further, we define the vocabulary for the rest of this article. We call -Client developers: the developers of an application or library that is using another library whose API is changing and subject to deprecation practices. -Library developers: the developers of an application or library that is changing and may use DEPREWRITER to help client developers adapt their application to changes. -Transformation rule: a rule that describes the transformation of the source code in the form antecedent → consequent. Antecedent is the expression that matches the code that should be replaced. Consequent defines the replacement. -Rewriting deprecation: a deprecation that contains a transformation rule and can automatically rewrite the call sites. -Non-rewriting deprecation: a deprecation that does not contain a transformation rule.
Runtime information helps to distinguish the real deprecated method callers from other method calls with the same name. Using DEPREWRITER (which stand for DEPrecation REWRITER): 1. Library developers annotate the deprecated methods with transformation rules. 2. Then, when clients of the deprecated API execute their program, DEPREWRITER dynamically rewrites the source code of the methods that have called the deprecated APIs. The implementation of DEPREWRITER is based on call-stack reification and navigation  (Rivard 1996) , dynamic program update, and tree matching rewriting (D. Roberts et al. 1996 Roberts et al. , 1997)) , however the approach is generic enough to be implemented using different mechanisms as explained in Section 8. When a deprecated method is executed, DEPREWRITER walks the stack to find the caller method and the call site from which the deprecated method is ivoked.
Then it uses a program transformation engine to rewrite the call site's source code. Finally, the execution of the deprecated method continues. All changes are done automatically. These changes are editable in the IDE, just like any other change performed interactively by the programmer. Developers review such automatic changes, modify them and commit a potentially further adapted version of their updated code. As DEPREWRITER is integrated into the IDE, its usage does not impose the need for new abilities on client developers. In recent years, many studies have shown how the migration rules can be extracted from source code  (Kim et al. 2007; Xing 2007; Schäfer et al. 2008; Wu et al. 2010; Nguyen et al. 2010; Pandita et al. 2015)  and the commit history  (Dagenais & Robillard 2008 ; S. Meng et al.
2012; Teyton et al. 2013; Hora et al. 2014; Alrubaye & Mkaouer 2019). These approaches support the developers of client applications and help them update their systems to the latest versions of the external libraries without relying on the library developers to provide a set of migration rules. The DEPREWRITER approach, which we present in this paper, focuses on supporting library and client developers in the process of library evolution. DEPREWRITER allows library developers to annotate deprecated methods with transformation rules that are used to update client systems either fully automatically or semi-automatically. Our approach is related to the one of Chow and Notkin  (Chow & Notkin 1996) , who designed a language for expressing code transformations in C. They implemented a semi-automatic tool that allows library developers to annotate changed functions with transformation rules which later are applied statically to update the client code.
The DE-PREWRITER approach is better suited for highly polymorphic object-oriented languages because it dynamically identifies call sites that need to be updated. Since 2016, DEPREWRITER is used in production in the Pharo distributions: Pharo 6, 7, 8, and 9 alpha. Pharo 1  is an open-source dynamically-typed reflective, object-oriented language inspired by Smalltalk  (Black et al. 2009). Its latest stable release, 8, includes 667 packages. Pharo has more than 3000 external projects, 220 forks on GitHub, and 121 committers, among which there are 12 core contributors. It is managed by an industrial consortium. 2 n the context of Pharo industrial consortium, we implemented the DEPREWRITER approach to ease software evolution within the Pharo ecosystem using rewriting deprecations. After describing the approach, we answer two categories of research questions: the first category is about the use and flexibility of the rewriting deprecations as used by library providers (e.
Problem: the Limits of Static Analysis for Dynamically-Typed Languages Static analyzers are useful to precisely identify and transform callers of deprecated methods in the context of programming languages with static type information. However, the same techniques do not yield precise results in dynamically-typed languages such as Python, Ruby, Javascript, or Pharo  (Suzuki 1981; Milner 1978 ). Such languages do not have static type information that can be used to drive the static analyses, so static analyzers need to speculate. For example, consider Figure  1  showing the log: methods coming from two different libraries: a logging library and a math library, and a user of them. The maintainers of the logging library decide to deprecate their log: method in favor of a version with an extra argument for the logging level.
Library Client Perspective From the perspective of a user of a deprecated method, the process is simple. Developers execute their application, for example, by invoking the main program or by running its tests. At runtime, calls to deprecated methods are rewritten using the transformation rules, and then the application continues its execution. In all cases, the deprecated method is invoked and executed normally. Code transformation of the client method happens as a side effect of its execution. At runtime, when the deprecated method is executed, the following steps occur: 1. DEPREWRITER is called before the actual body of the method is executed. 2. It accesses the caller method and the exact call site (i. e. , the exact location in the text of the method call) where this method was called from -Our implementation introspects the call stack, but alternate approaches such as AOP are possible.
In the Logger example (see Figure  2 ), as soon as the client system calls method Logger >> log:, three things happen: (1) the deprecation warning is signaled (warnings can be disabled); (2) the transformation rule rewrites the client code at the call site and replaces the method call to log: with a call to log: level :, then the method is recompiled; (3) execution of the log: method is resumed, and the last line ^self log: aMessage level: #info is executed, thus calling the correct method. All automatic code transformations are applied to the original source code. Finally, developers review the changes and decide which ones to keep and version them using traditional tools. By default, transformations are applied to client code automatically. However, DEPREWRITER is configurable to only show a warning instead.
General Architecture in a Nutshell Our approach works as follows (See Figure  3 ): 1. The deprecated method is marked with deprecation and its runtime transformation as shown by (1) in Figure  2. 2. During program execution, the execution of the deprecated method raises an exception (2) in Figure  2. 3. DEPREWRITER captures the exception (3) in Figure  2. 4. When configured to rewrite on the fly, DEPREWRITER identifies the exact call site in the calling method; and it rewrites the method using the deprecation transformation rules ((4) in Figure  2 ). 5. The execution of the deprecated (halted by exception) method is resumed. The body of the deprecated method is executed ((5) in Figure  2 ): in most cases, the execution simply calls the new API. 6. From then on, the next execution of the rewritten method will execute the transformed code, and as such, the deprecated method will not be invoked from that call site anymore.
] One particular aspect of ParseTreeRewriter is that it cleverly extends the syntax of the language. Programmers can simply take their code and annotate it with the specific characters, and they obtain a transformation rule. The Pharo consortium decided to use this aspect to ease the adoption by practitioners so that they do not have to learn another language or framework to deprecate their code  (Rizun et al. 2015). Alternate extensible solutions have been proposed to support programmers during the definition of transformation patterns  (Rizun et al. 2016 ), but they require the use of a tool to help generating the rule.
Deprecate class -when the class is deprecated, all of its methods can be deprecated as well. In this case, the transformation rule can not be introduced because it is not only the method call that must be replaced but also the code that instantiates the receiver. Complex replacement -in addition to the scenarios described above, there are also more complex situations when a method deprecation would require client developers to introduce changes into multiple locations in their code (can not be handled with the current implementation of DE-PREWRITER) or to replace a method call with a more complex expression that may include block closures, streams, etc. (can be handled if all the variables are known). It is also possible that a complex replacement requires client developers to make extra decisions and introduce different fixes depending on the specific situation.
6 The source code of Pharo v8. 0 was loaded from an open source repository https://github. com/pharo-project/pharo at commit bbcdf97 7 Pharo is a programming language and an IDE written entirely in itself. This can be a source of confusion. In this section, we analyse how rewriting deprecations, introduced into Pharo (an open-source project with over 140 contributors), were used by its developers to deprecate methods in other parts of the same project. In other words, we study how Pharo developers use the rewriting functionality of Pharo to deprecate methods in Pharo. Cleaning the Data. Before analysing the deprecated methods, we performed several data cleaning steps to only retain those deprecations that are relevant. First, we have removed 8 deprecated methods that were used only for testing (e.
User Survey Making a sound evaluation of DEPREWRITER is difficult because it is often applied to the private code of developers using Pharo. In addition, developers can have different development processes. To understand how DEPREWRITER is used and perceived by developers in the Pharo ecosystem, we performed an open survey. The participants of the survey are developers programming in Pharo. We did not select the participants based on their practices or use of DEPREWRITER. From that perspective, they can either know or not the existence of DEPREWRITER, and be either client or library developers as defined at the start of this article. With this survey, we set the following research questions: RQ4 How is DEPREWRITER used by client developers who are affected by deprecation rewriting? RQ5 How is it used by the developers who introduced the rewriting deprecations into their systems? RQ6 What are the configurations of DEPREWRITER that are preferred by users? The list of survey questions is available in Appendix B.
Such numbers are not surprising; because library developers are sensitive to deprecations and the impact of their changes. So, it is normal that they got a stronger incentive to participate in the survey. Then we asked how often they migrate their software. A release cycle of Pharo is one to one and a half years. And, this is a main source of migration. The data in Table  5  show that 58% of developers (27 out of 46) are often migrating their code to newer versions of Pharo. A couple of developers mentioned in the optional comments that they always migrate to bleedingedge versions.
The rewriting happens as a side effect, as we do not perform the on-stack replacement. The rewritten method will be used for the next execution. 1 O b j e c t >> deprecated : a n E x p l a n a t i o n S t r i n g Listing 1 The method deprecated: transformWith: Rewriting steps. The transform method does the following (Listing 2): -Lines 3-4, it checks if it has been configured to transform the caller or not. If the user wants a deprecation exception to be managed normally, the transformation does not happen. The exception is signaled. -Line 5, the caller method is an identifier. The method contextOfSender is just doing context sender, it means that given the method that invoked the deprecated:transformWith :, it will find the stack element representing the caller call. -Line 6, some internal usage of the code evaluator are ignored (code snippet executions are mapped to anonymous methods and we do not want to rewrite snippets therefore the implementation has to check that a caller is not a snippet execution).
-Line 7 grabs the program node of the AST representing the caller of the deprecated method. -Line 8 the transformation rule (called a rewrite rule) is created based on the specifications of the deprecation. Deprewriter: On the fly rewriting method deprecations -Lines 9-10 once we have the node and the rule, the method asks if the rule can be applied to the node. This is what is done in the message executeTree:. When the node cannot be rewritten, the default exception is raised. -Lines 11-12, when the node can be rewritten, it is replaced by the corresponding expression and the method is recompiled. At this point, the currently executed method is still on the stack, and it continues its execution. This means that the rewritten code will only be executed on the next execution. Note that if we have two calls to the same deprecated method in one method, we will execute this method twice to replace both cases.
23 Even i f t h e i n f o r m a t i o n i s p r e s e n t 24 as a s t r i n g , c a l l e r i d e n t i f i c a t i o n Dynamic Software Support in Tools. In the scenario we are using a language that does not natively support DSU, we still are able to use existing DSU tools for these languages. These tools manage the update of executing code allowing us to modify the caller method. Such tools exist in numerous languages and environments ranging from low-level languages as C (e. g. , Kitsune  (Hayden et al. 2012) , Ginseng  (Neamtiu et al. 2006 )) to object-oriented languages running in a VM like Java (e. g. , JRebel (ZeroTurnAround 2012), Rubah  (Pina & Hicks 2013) ). Original Source Code Rewriting. If there is no support for dynamic update of the running application, our approach is still applicable: A possible implementation is one that updates the source code of the application and recompiles it to be executed during the next execution of the application.
Discussing Survey Results In this section, we discuss the factors that might have affected the result of the survey. We have identified a number of characteristics of the Pharo community and the way the survey has been done. We consider that these elements do not affect the validity of the presented survey nor the validity of the proposed solution. However, these should be taken in account. As the application of a tool and its perception by the community is affected by the culture and nature of the community, language, and platform; the presented result might not produce the same results when extrapolated to other languages and communities. Integration with other Tools. The presented approach is integrated with the other tools existing in Pharo. Even though DEPREWRITER is not exposed with a tool, its effects are visible through all other tools in the IDE.
For example, the versioning system tool is able to correctly identify the changes performed by DEPREWRITER and show them to the user to commit them. This natural integration with the tools may minimize the negative impact of the users seeing their code rewritten by its execution. Integration in Different Versions. The tool has been integrated in Pharo 6, 7, 8, and 9 alpha. This might have minimized the impact of self-changing code to the users. The users are not surprised by the error messages or the modification appearing in the code, as they have internalized that this is normal behavior of Pharo. This might explain the high percentage of positive answers and the lack of answers describing it as surprising.
This would explain some high percentage of positive answers. Lack of Tool and Knowledge. The usability of the rewrite engine may be a concern because there is no up to date documentation nor a dedicated tool to support the definition of rewriting deprecations. Developers proceed often by copy and paste existing deprecations and limit themselves to simple rewriting. It is our future plan to evaluate the impact of such tooling on the rule expressions. Openness and Discoverability. Pharo users are used to discover tools, how they should be used, and their inner-workings by exploring the implementation, existing uses, and tests. This is a product of the open nature of Pharo, as all the code of the system and libraries is accessible from the IDE. This culture may have limited the fact that the tool did not have any proper documentation and that such absence of documentation hampered its use by unfamiliar developers.
Rubah is a Dynamic Software Updater for Java, but it cannot update core libraries  (Pina et al. 2014). Espell is an infrastructure that supports dynamic software update even for core libraries  (Polito et al. 2015). Tesone et al. (Tesone et al. 2018)  propose gDSU, dynamic software update that works for both live programming and production environments. The solution implements safe update point detection using call stack manipulation and a reusable instance migration mechanism to minimize manual intervention in patch generation. Moreover, it also offers updates of core language libraries and the update mechanism itself. This is achieved by the incremental copy of the modified objects and an atomic commit operation. Library Migration and Update. Our research is closely related to the problems of library update (updating a client system to depend on a new version of the external library) and library migration (replacing the dependency on one library with that on a different library).