dataesr/scientific-paragraphs-categorization huggingface dataset:
The general patterns of growth are similar for male and female baboons (see Figs  3  and 4 ). Therefore, it is possible to describe a general pattern of limb growth in baboons. Regarding NPP convergence, although the coupling between forelimb and hindlimb is always close during development (Fig. 8 ), the linear models show a trend towards a gradual increase in the forelimb NPP relatively to the hindlimb NPP [from the full dataset, slope (95% CI): 0. 90 (0. 86-0. 93) and 0. 90 (0. 88-0. 93) for females and males, respectively]. We split our sample into 1-year age-classes in order to highlight the period in which the convergence of the NPP decreases. The forelimb NPP is significantly greater than the hindlimb NPP from 3 years of age onwards in females and from 1 year of age onwards in males.
Software tends to be highly configurable, but most applications are hardly context aware. For example, a web browser provides many settings to configure printers and proxies, but nevertheless it is unable to dynamically adapt to a new workplace. In this paper we aim to empirically demonstrate that by dynamic and automatic reconfiguration of unmodified software we can systematically introduce context awareness. In 16 real-world applications comprising 50 million lines of code we empirically investigate which of the 2,683 run-time configuration accesses (1) already take context into account, or (2) can be manipulated at run-time to do so. The results show that context awareness can be exploited far beyond the developers' initial intentions. Our tool Elektra dynamically intercepts the run-time configuration accesses and replaces them with a context aware implementation.
Introduction Context-information about the environment in which software executes-strongly influences the behavior we expect from software, and most software is subject to context. As our running example, we describe a web browser with its local network settings as context: In different networks, web browsers may require different proxy settings for Internet access. The default printer might also have to be changed to a physically co-located one. If software (more) readily adapts its behavior automatically to its current context, we call it (more) context aware  (Alegre et al. , 2016). Context awareness fundamentally increases user experience  (Dey and Abowd, 2000). For example, if a web browser considers its network context, users will be able to display a web page regardless of which proxy is required by the network.
Context-oriented software engineering (COSE) puts context awareness in its focus. Previous COSE approaches required developers to consider every context already at design time  (Kamina et al. , 2014). Thus they were not applicable for already existing large software projects and in particular for legacy software. To improve on these issues, we propose to move COSE to deployment time. This way we delay decisions about supported contexts. Three classes of stakeholders participate: (1) the developers, who still focus on configurability without the need to explicitly implement context awareness; (2) the administrators, who enable context-awareness in applications with our novel COSE process during deployment; and (3) the end users, who enjoy more context-aware applications.
Research Questions We claim that it is possible and practical to take unmodified software, and by run-time reconfiguration, improve their context awareness. Our goal is to exploit already existing run-time configuration accesses (RCAs) in free and open source software (FLOSS). To validate our claim, we answer 3 research questions: First we need to show that enough RCAs are present in FLOSS to support run-time reconfiguration. To confirm that, in Section 4 we analyze the source code in a sample of 16 popular and large-scale FLOSS applications and count RCAs to answer RQ 1: How often are RCAs used in FLOSS? To find out whether RCAs occur sufficiently frequently during run time, a dynamic analysis is needed. In Section 5 we evaluate case studies with the same 16 applications and answer RQ 2: How many RCAs can be made context aware? In Section 6 we investigate if our proposed solution is efficient enough by answering RQ 3: What is the overhead of context-aware RCAs?.
Contributions This paper is (to the best of our knowledge) the first endeavor to empirically investigate context awareness in large-scale FLOSS applications: • We collected profound evidence that RCAs in FLOSS applications can be used to improve context awareness. • In case studies with 16 real-world applications we found out that COSE improves unmodified FLOSS applications. • No previous evaluation of context-aware applications was conducted using such large, complex, and popular applications. Contribution 1: In a source-code analysis of 16 FLOSS applications we observe that a particular kind of RCAs, namely invocation of the getenv function, is used pervasively (2,683 call sites). (Section 4) Contribution 2: We confirm that RCAs are used ubiquitously also at run time. We systematically investigated which RCAs can be used to improve context awareness in all 16 applications.
Preliminaries & Motivation An important aspect of software configuration is to specify run-time configuration accesses (RCAs). RCAs are the places within code that define different behavior based on configuration. Usually RCAs are calls to configuration application programming interfaces (APIs) such as getenv but can also be direct accesses to data structures. The getenv function is a low-level configuration RCA. It accesses the environment variables of the current process, which is set by the caller (e. g. , the user's shell) when a program is started. After the start of the process, its environment variables can no longer be changed externally, only from within the process using the setenv function. We chose it for most of our investigations because it is widely standardized and available in many programming languages.
For example, in web browsers we find code such as: getenv (" http_proxy "); In this example, the return value of getenv can contain an outdated proxy after network changes because environment variables are not updated for processes. Context-oriented programming (COP) allows developers to naturally separate multidimensional concerns  (Dey and Abowd, 2000; Salvaneschi et al. , 2012; Schippers et al. , 2010). COP is one way to specify programs that adapt their behavior to the context. Layers are the foundation of COP  (Appeltauer et al. , 2009; Costanza et al. , 2006; von Löwis et al. , 2007; Wasty et al. , 2010). Every layer constitutes one dimension of context that cuts across the software system. The (de)activation of layers occurs during program execution. All active layers together define the current context of the program.
Context sensors  (Dey and Abowd, 2000; Baldauf et al. , 2007)  are hardware and software with the main purpose of activating layers according to context changes. We will use them as separate processes that wait for context change events  (Raab, 2016c). Yin et al. (Yin et al. , 2011)  found out that in "a large portion (46. 3 % to 61. 9 %) of the parameter misconfigurations" the context was not considered. Our goal is to explicitly specify the contextual values that make the execution of the applications more contextaware. This specification leads to a better understanding of the context in teams maintaining the software. We are positive that the specification helps reduce external misconfiguration errors as a side effect. For newly written context-aware software, current COP and COSE approaches would be a viable choice  (Jong-yi et al.
Elektra Elektra is a library developed by one of the authors, which implements uniform, consistent and context-aware configuration access. In the present paper we describe an approach to use Elektra as a tool to integrate unmodified applications. The approach is to apply Elektra in COSE processes at deployment. Elektra  (Raab, 2016a)  works as follows: At application start, Elektra initializes itself by parsing configuration files. The configuration files contain both the specifications and configurations for contextual values. Elektra supports over 190 configuration file formats including the widely-used INI, XML and JSON formats. The support for these formats enables Elektra to directly manipulate configuration of applications. In its essence, Elektra provides a key-value database with unique keys and a specification for every configuration setting.
Interception To work with unmodified applications, Elektra intercepts important library calls, including the following: • Each getenv invocation to provide context-aware access for environment variables. • Each open invocation to return configuration files with configuration settings respecting the current context. Interceptions of library calls are platformdependent but are available for every major OS, e. g. , LD_PRELOAD and /etc/ld. so. preload for Linux. Instead of requiring developers to implement new behavior for context adoption, we rely on already existing behavioral adoptions that are guarded by RCAs.
Context Specification Elektra itself is configured via a configuration specification language. In this paper we will use a simple key-value syntax to illustrate the specification of the key-value database and its contents. For example, let us specify the contextual value getenv/http_proxy: [getenv / http_proxy ] context=http_proxy /%interface%/%network% The key within [] represents a unique identifier to a configuration setting. Entries in the database are organized hierarchically with / as the level separator. The getenv-interceptor reads its configuration from keys starting with getenv/. We configure it to handle getenv invocations with the parameter "http_proxy". In the example above, the only property for this key, i. e. , context, specifies that the value to be returned from such invocations should be context aware.
Using the %. % syntax we specify placeholders to be substituted by the values of layers. The getenv invocation returns the proxy configured for the currently active interface and network layers. This functionality allows us to modify configuration settings passed to applications: An application that requests a configuration setting from the environment transparently receives a setting from our key-value database instead. By honoring context in the lookup we introduce context awareness in the client software. The context-aware lookup makes sure that the returned value recursively respects context specifications. With changing context, i. e. , different values in layers, the same requested key has different values. We express the possible values using straight-forward pattern matching. E. g.
Context Changes and Sensors When the context changes, this information must be communicated to applications. For the present work, we use external context sensors: small programs running in separate processes that monitor the context of interest. When the sensor detects a change, it updates the corresponding layer's value in the key-value database. Future requests for contextual values via Elektra (through intercepted getenv or open invocations) will use these updated layer values in their lookups. Having context sensors running in their own process separates concerns between the application and the code detecting context changes. In the running example, users switch networks by changing their location or by connecting a network cable. A sensor detects this change and updates Elektra's database accordingly.
We used hooks in network interfaces to implement this use case. Assume that the interface changes to eth and the network to work. Then the next getenv("http_proxy") invocation will return proxy. example. com. This is an increase in context awareness: Normally getenv is not context-aware because the program's environment is initialized at startup and cannot be modified externally, only by the program itself using setenv. Thus the standard getenv function always returns the same value for a given argument. In contrast, Elektra's modified getenv returns different values if the underlying context changes. Elektra is not limited to pulling configuration settings while RCAs are executed. Instead Elektra can push information to applications by notifying them to reload their configuration, e. g. , via signals for daemons or socket communication for Firefox.
Methodology We count the total lines of code and occurrences of getenv in selected applications. Obvious wrapper functions (e. g. , LYGetEnv in Lynx) are treated identically to getenv itself. To improve external validity we carefully sampled 16 applications. We started by including large applications that have a thriving community. In addition we took care to have a broad range of diverse applications. We searched for further popular applications to reduce the familiarity heuristic. If Internet pages repeatedly mentioned some applications, we considered them for inclusion. Finally, we set a focus on browsers to have a better picture for a specific domain. The evaluation of the paper consistently uses the same applications with the same versions. We used Cloc 1. 60 to determine the code size of the applications in the versions as listed above.
Related Work Xu et al. investigated which configuration settings are actually used in practice  (Xu et al. , 2015). They argue that users get confused by too many settings. We fully agree and think that our approach helps here by automatically deducing most settings from context. Then developers can remove these settings from user guides. Advanced users, however, still can override context-aware configuration settings. Jin et al. describe different challenges in configuring real-world systems  (Jin et al. , 2014). Our approach addresses them by (1) working across language barriers, (2) having a holistic integration of different RCAs, and (3) making sure that RCAs do not return outdated values. The authors uncovered 1,957 settings for Firefox and assumed that only a "small part" of settings is missing.
Threats to Validity Internal: Both the code and run-time analysis have the danger of subjective classification and oversight. To minimize such errors we included second opinions and only report large differences. Additionally the combination of code and run-time analyses yields a more complete picture as proposed for mixed methods  (Ihantola and Kihn, 2011). External: An important concern is whether the evaluated applications and their developers are representative. We address it by studying a high number of diverse applications. We included both small and large applications. We took care that different domains, development teams and programming languages are represented. In particular the browsers are used heavily in mobile contexts. We have to acknowledge that most software we evaluated is written in C/C++.
Nevertheless, Java, JavaScript and Python were well represented with 4. 3, 3. 3, and 1. 1 million lines of code, respectively. Furthermore, we added Eclipse to also have a large project mainly implemented in Java. Since we found no context-aware application of reasonable size with an active community, we could not include such applications into the analysis. Hence our claims exclude applications developed with context-awareness as goal. An equally important concern is whether getenv, our main subject of study, represents every form of RCA. Based on many previous studies  (Jin et al. , 2014; Rabkin and Katz, 2011; Xu et al. , 2013) , run-time RCAs are in their essence simple key-value accesses. Higher-level RCAs, e. g. with type-safety, would only complicate the implementation. Because we did an in-depth source code analysis, we could not pick closed-source applications.
A significant portion of the evaluated software, however, has at least roots as closed-source applications. Also based on experience within companies, we are positive that our conclusions hold for closed-source applications. It is well known that in experimental analysis high standards are required  (Johnson, 2002) ; e. g. , to mitigate measurement issues we always used two different profiling tools. Overall we cannot draw any general conclusions applicable to every form of configuration. In particular we focus on observations how RCAs are used in FLOSS applications. Thus results should be interpreted and generalized with awareness of our focus. Nevertheless our study provides profound insights about connections between configuration and context awareness.
Conclusion and Future Work In this paper we claimed that unmodified applications can become more context aware. We demonstrated that such an approach exists and is practical. We evaluated the approach on 16 large, real-world FLOSS applications. By configuring a simple tool, context awareness was improved in case studies, often even flawlessly. We applied a straightforward contextoriented software engineering process which enables systematic applicability during deployment. Our work shows that it is realistic to deduce configuration settings from context. We are positive that doing so contributes to reduce one of the major source of configuration errors, i. e. , forgetting about context in configuration. We propose that environment variables should be specified and documented like other configuration settings.
Our approach shows that it is not necessary that developers foresee every possible context. Instead layers and configuration settings per context are introduced during deployment. Our approach is modular because context sensors are implemented separately from applications. Elektra is available as free software from http://www. libelektra. org and is more general than described in this paper: For example, it can be used for newly developed contextaware software by generating contextual values. This paper focuses on its use for unmodified software. The source code analysis suggest that dependency injection ('hijacking' existing getenv/open invocations or other APIs) makes it easy to introduce context awareness. Elektra is not limited to intercepting getenv and open. For example, we implemented the gsettings API which has the potential to make GNOME settings context-aware.
As future work Elektra can be extended to make even more forms of configuration context-aware (configuration for modules, plugins, dependency injections, rich mobile APIs etc. ). Although we did not find a single occurrence where existing context awareness conflicted with our approach, combining Elektra with already contextaware software is future work. Another research direction is to investigate how many applications allow reloading of configuration settings. Enabling Elektra to push configuration settings to more applications improves the user experience again.
Nevertheless, very few tools really help journalists in their verification routines. In practice, journalists and investigators need to switch back and forth among a multitude of online tools and services, each of which addresses only a small part of the journalistic verification process. Through design thinking methodology, observing and understanding of journalistic workflows and of the difficulties encountered by professionals when verifying information, we have released (on  July 3, 2017)  in "open beta" the first version of a browser plug-in, designed as a verification "Swiss army knife". The tool, which has been released as open source software 3 , provides a unified view over a number of third party services and novel technologies developed within the InVID 4 and REVEAL 5 research projects, through a single graphical user interface, aiming to help journalists to get additional related information about the content that they try to verify.
Verification systems and services A lot of tools are used in the journalistic verification process; these include search engines, online translators, video players and editing software, map services (e. g. Google maps, Street view, Bing maps, Open Street Map, Nokia Here, Yandex maps, Wikimapia. org) and other web services and applications (e. g. providing historical weather information). Journalists often rely on the YouTube DataViewer 6  of Amnesty International for performing reverse image search based on the video thumbnails, or simply take screenshots while watching the video and upload them on reverse image search services such as Google images. For still images, plug-ins like RevEye  7  or TinEye 8  (linked to the respective search engines) are also used. Yet, all those tools require experience and remain rudimentary and cumbersome to use (e.
In particular, different features have been considered: features related to the post (tweet) (including both general text features, e. g. n-grams, and twitter-specific ones, e. g. hashtag-and URL-based), the author/user, topic-based and network-or propagation-based features. Several works that follow a very similar approach  [5, 16]  confirmed on different datasets the potential and high accuracy of fake post detection when using post-and author-based features. Although such methods have shown great potential in automatically distinguishing between credible and fake tweets, in practice end users (journalists) are often reluctant to rely on algorithmic outcomes for deciding on the veracity of online content. To this end, the presented plug-in only computes some of the credibility features investigated by previous works and presents them to end users without providing any automatically produced score quantifying the veracity of an input video.
Several prototypes were made for different tools, such as Python scripts to trigger fast reverse image search on YouTube videos or to automate the advanced search on Twitter by time interval up to the minute. In the meantime, sophisticated multimedia analysis services such as video context analysis (Section 4. 1), video keyframe selection (Section 4. 3), and image forensics (Section 4. 5) were integrated in the tool. While the goal of InVID is to develop a full knowledge verification platform to detect emerging stories and assess the reliability of newsworthy video files and content spread via social media, we decided to share our work with the journalistic community 9 by designing a browser plug-in wrapping up several tools in a single interface, implemented in HTML, CSS and JavaScript. The browser plug-in appeared as the best solution to combine the available tools, to engage with the community of end users and to provide also some long lasting modules (Twitter advanced search, Metadata reader, Magnifier, YouTube Thumbnails reverse search), locally in the browser, always at the user's fingertips.
PLUG-IN VERIFICATION MODULES 4. 1 Video context analysis This module aims to assist analysts by providing contextual information about the video, which can often be exploited for verification. Although part of the information provided by this module can be accessed already by visiting the page where the video was published (e. g. YouTube), the module isolates and aggregates verification-relevant information and presents it to the investigator 9 Media studies and media education scholars have also shown great interest in using the plug-in. Video and channel metadata are collected from the YouTube and Facebook APIs 10  , and presented in a compact form to the investigator. Besides the video name and description, these include information such as the video and channel views count, video upload date and channel creation date (converted to GMT), plus any locations mentioned in the video description, extracted using the Named Entity Extraction functionalities of the Stanford CoreNLP library  11  (Figures  1  and 2 ).