dataesr/scientific-paragraphs-categorization huggingface dataset:
Waveguide coupling 4. 1 2D approximation for the effective index A transverse view of the structure is shown in Figure  8. The two waveguides are separated by 300 nm of Al 0. 3 Ga 0. 7 As. Figure  9  presents a simulation of light propagation along the structure by a beam propagation method (BPM), which has been carried out with the commercial software RSoft. To reduce calculation time and quickly converge on an intuitive model, we first make a 2D effective-index approximation, whose validity will be checked in the next section. The injected mode, visible on the right-end side of Figure  9a , is the eigenmode presenting the highest overlap with the active region. As is visible from Figure  9b , 90% of the guided power is contained in the laser core layer at Z = 0, that is, before the taper.
Thermal behavior As mentioned earlier, thermal behavior is a critical point for the operation of the DOPO source. Given a maximal ridge width for single-mode operation, an epi-up geometry, and a target optical power, we can estimate the temperature rise in the laser. The laser ridge width is taken to be 5 μm, as this size provides single-mode operation for an index contrast of 0. 005  [12]. Assuming a target optical power of 100 mW and a wall-plug efficiency of 16%, the emitted power in the form of heat is 500 mW. We simulate a crude model of the temperature rise with the software COMSOL. The heat is assumed to escape fully from the junction of size 5 μm × 0. 1 μm × L (1, 2, or 3 mm) (Figure  14 ). The latter is set inside 10 μm of Al 0. 3 Ga 0. 7 As, and the underlying material is GaAs. Figure  15  shows the junction temperature calculated as a function of the substrate thickness for three different lengths (L = 1, 2, or 3 mm).
Docker is becoming a popular tool used by developers and end-users to deploy and run software applications. Dockerfiles are now found alongside projects' source code. Several projects are even starting to maintain families of Dockerfiles, like the Python project that maintains a family of 43 Dockerfiles, each for a specific Python version on a specific Linux distribution. In some situations, Dockerfiles family maintainers have to propagate a change to several, if not all, Dockerfiles of the family (for instance a bugfix applying on all Dockerfiles targeting Python 2. 7). This need to propagate changes is usually due to the presence of duplicates between several Dockerfiles of the family. In this paper, our goal is to provide practitioners a clear explanation for why Dockerfile duplicates arise in projects, and what are the different means to handle duplicates with their pros and cons.
I. INTRODUCTION Docker simplifies the deployment of software applications by enabling developers to package their applications with all their required dependencies in a single binary unit, called a Docker image 1. To build an image, developers have to write a Dockerfile, that will be executed by Docker. Such a Dockerfile is written in a Domain Specific Language (DSL) that can be compared to a very limited shell scripting language. Software projects using Docker manage their Dockerfiles in their Software Configuration Management tool (e. g. GitHub), as any other software artefacts. Some projects even have to manage a family of Dockerfiles (DF for short), especially when they have to support and maintain several versions in parallel with several sets of dependencies. For instance, the Python project 2  provides a family of 43 Dockerfiles, each one targeting a specific version of python (e.
g. 2. 7, 3. 8-rc) with a specific set of distributions (e. g. Debian, Alpine, Windows). Looking at such projects, it appears that sometimes a patch targeting a Dockerfile has to be propagated to some (if not all) Dockerfiles of the family. As an example, Listing 1 shows a patch encountered in the official Python project  3. This patch fixes an unexpected segmentation fault that appears only on Dockerfiles using the Alpine Linux distribution. This bug is due to a too small stack size and is resolved by adding a new flag in a make command as shown in Listing 1 (line 5). This bugfix was propagated to the 7 Dockerfiles of the family that are based on the Alpine distribution. Listing 1. A bugfix of a same duplicate across the Alpine family of Dockerfiles in the official Python project 1 RUN. 2 && apk add --no -cache --virtual.
build -deps \ 3 bzip2 -dev \ 4. 5 && make -j " $( nproc ) " EXTRA CFLAGS="-DTHREAD STACK SIZE=0x100000" 6 &&. As another example, every image of the official Python project come with a python package management tool called pip. When a new version of pip is available, all the family's Dockerfiles have to be patched. We observed such situation when an update was done from pip version 19. 0. 2 to 19. 0. 3  4 as shown in Listing 2. The two previous examples highlight a case of patch propagation among a family of Dockerfiles. Such situations arise because the impacted Dockerfiles share duplicated instructions. In the first example, all the Dockerfiles that are based on the Alpine distribution share the same make command with the same arguments (see Listing 1 (line 5)). In the second example, all the Dockerfiles mention the pip version they depend on.
As a consequence, for a patch to be safely propagated, all the impacted duplicates have hence to be identified and then equally modified, which is time consuming and may be errorprone. For example, this patch applied in 2015  5  has required another commit the same day to propagate the modification to other Dockerfiles  6. The main questions are then: are duplicates abundant in Dockerfiles families? and if yes, is their handling a source of concerns? Such questions are relevant to any maintainers of Software projects that rely on Docker, and that come to manage several Dockerfiles. In this paper, we answer the question of duplicates handling in Dockerfiles families by providing a grounded study based on the analysis of the Official Docker Projects. This choice is driven by the fact that these projects are real-world popular projects that manage medium to large families of Dockerfiles, but most importantly because as it is written in the Docker documentation, these projects promote the best practices to maintain Dockerfiles 7 and may be considered as a reference for any Dockerfile maintainer.
Our hypothesis is that these projects are the best to highlight the duplicates in Dockerfiles families problem, and the best to define the cutting-edge practices that exist for handling them. In our study, we then follow a mixed research method (quantitative and qualitative) and more precisely answer the following research questions: 1) Do official projects maintain families of Dockerfiles, and why? 2) Do duplicates arise in Dockerfiles families and why? 3) What are the tools used by official Docker projects for managing duplicates? What are their pros and cons? Through our study, we show that official Docker projects frequently maintain families of Dockerfiles. We observe that the most common reasons are: supporting multiple versions/base-images and versions/flavours. We then show that duplicates in Dockerfiles are abundant, and find the underlying reasons behind them: Software installation and configuration, dependency management and runtime configuration.
II. DOCKERFILES IN A NUTSHELL A Docker container is a "lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings"  8. A Docker container is ran from a Docker image, which is built from a Dockerfile. Using Docker is therefore a two steps process (1) Build a Docker image from a Dockerfile (docker build -f Dockerfile -t my image), (2) Run the Docker container from the Docker image (docker run my image). In our study, we focus on the first step, and more specifically on Dockerfiles, which are scripts composed of a sequence of instructions. Listing 3 shows a sample Dockerfile for a web application written in Python. This Dockerfile starts with a FROM instruction stating that the image to be built will be based on the existing python:2.
A. Repositories As presented in Section I, we choose to look at official Docker projects only. The list of these official projects is available on GitHub, with 138 official projects, as of March 2019. 10  Some of these projects share a same Github repository. For example, InfluxDB and Chronograf are maintained in the same GitHub repository. We therefore remove these 9 projects from our corpus to preserve a dataset uniformity. We also discard the hello world project as it is only intended to provide examples for beginners. At this stage, our corpus includes 128 projects with their associated GitHub repositories. We then count the number of files named Dockerfile in each of these 128 projects, as it is the most common name for Dockerfiles (see Section VII for potential threats). We identify 1300 Dockerfiles.
IV. RQ1: DO OFFICIAL PROJECTS MAINTAIN FAMILIES OF DOCKERFILES, AND WHY? To answer our first research question, we perform a manual inspection of all Dockerfiles contained in a project. We then identify the reasons behind the existence of multiple Dockerfiles in a project. 1) Methodology: While looking at Dockerfiles when building our dataset, we note that the location path of a Dockerfile contains information about its purpose. For instance, the rabbitmq project has a Dockerfile located in 3. 6/alpine/Dockerfile. Based on this path, we can easily understand that this Dockerfile targets the version 3. 6 of rabbitmq and is based upon Alpine Linux, a lightweight Linux distribution. Therefore, by analysing all Dockerfiles' paths, we see that rabbitmq maintains Dockerfiles for various versions and with various base images.
The most represented category is version that contains several versions of the project, similarly to the rabbitmq example. The second category by order of importance is base image that contains the different base images used to produce the project images (e. g. Alpine Linux and Debian Linux). The third category is flavour that contains different variants of the project (e. g. normal or multi-threaded flavour for the Perl project  12  ). The most seldom category is platform, that contains the different Docker platforms supported by the project (e. g. ARM, x86). Figure  6  is an UpSet plot  [2]  showing the relationships between versions, flavours, base images and platforms across the projects in our repositories. We first notice that the majority of projects (41) are actually maintaining images for multiple base images and versions at the same time.
The process can be composed of different steps going from downloading the software and installing it, to checking its signature, etc. Once a software is installed, the next step in this process is to configure the software before running it. Listing 4 is an extract of a whole duplicate (11 lines) that we manually analysed This duplicate involves two files from the XWiki project. It first starts by defining some environment variables (lines 1 to 4), then cleans a folder, and creates other ones that are mandatory for running XWiki (5 to 7). It then downloads the software and puts it in the right folder, validates it, unzip it and deletes the downloaded file. 50% of duplicates we analysed were due to software installation and configuration. b) Dependency management: Dependencies also follow an installation process.
In this extract, the package manager starts by updating its list of packages (line 1). Then, it downloads a bunch of dependencies, and finally, it cleans the package list it previously downloaded in order to reduce the final image size. It involves 2 files of the the bonita project 14. It is common to see the underlying shell commands combined in a single RUN instruction as we explained in Section II. We encountered this reason for 40% of duplicates we analysed. Listing 6. Duplicate due to dependency manager installation 1 RUN apt -get update 2 RUN apt -get install -y mysql -client -core -5. 7 openjdk -8 -jre -headless postgresql -client unzip curl zip 3 RUN rm -rf / var / lib / apt / lists /* c) Runtime configuration: These duplicates arise because developers set-up a same way of running the container in several images.
B. Dockerfile Management Tools We find that 66 projects in our repositories use tools to manage their DF (66% of our corpus). We notice that there is no on-the-shelf tool for this purpose: all developers maintain their own tool. However, all management tools have an update script file (located in the root of the repository) that is usually named update. sh, which is responsible for updating the whole DF. The update script needs some input parameters to generate the Dockerfiles, such as the version number or the target base image. 75% of them receive the parameters from the command-line while 25% automatically fetch parameters from a website. Finally some of the latter projects even automate the execution of the update. sh script at regular intervals via a dedicated bot. We notice that 88% of these scripts are written in Bash, the remaining 12% are written in different languages such as Go, PHP, Makefile, Python, Perl and Groovy.
This listing presents an extract of the template used to generate the Dockerfiles of the python project. We first notice that the base image is defined by a text replacement and a variable (line 1). The GPG key and python version that needs to be installed use the same features (text replacement and a variable (lines 2 and 3)). Only a few projects use more advanced template technologies supporting advanced features such as inclusion of subtemplates, loops and conditional statements: only 2 projects implement sub-templates, and only one project supports conditional statements. For instance, the XWiki project uses the most advanced template language we observed. Listing 9 shows an extract of this project's template. Among the list of XWiki's dependencies, developers must install either mysql or postgres according to the desired image flavour In the example, we see that a conditional statement is used (coming from Groovy's templating language) to handle this case (lines 7 and 8).
Regardless of the template language, projects using templates all perform the template rendering inside the update. sh script. rm -rf / var / lib / apt / lists /* b) Find and replace: Find and replace tools are also a fairly common Dockerfile management tools, and are used by 36% of the projects in our corpus and by 2 out of 11 maintainers in our survey. These tools proceed to update all Dockerfiles present in the repository by directly updating some of their content using the input data. Therefore, previous Dockerfiles present in the repository are overwritten by the updated ones. Such Dockerfile management tools mainly use regular expressions or dedicated Unix tools such as sed, located directly in the update. sh script. For instance, Listing 10 depicts a real extract from Kibana project's update script.
We see that the values at the right of KIBANA MAJOR, KIBANA VERSION and KIBANA SHA1 are replaced by the value contained in the variables passed as input parameters to the update script. Listing 10. An extract of the Kibana update script 1 sed -ri ' 2 s /ˆ( ENV KIBANA_MAJOR ). */\1 '" $version " '/; 3 s /ˆ( ENV KIBANA_VERSION ). */\1 '" $fullVersion " '/; 4 s /ˆ( ENV KIBANA_SHA1 ). */\1 '" $sha1 " '/; 5 ' " $version / Dockerfile " c) Generator: Generators are the least frequent Dockerfile management tool, only used by 10% of the projects in our corpus. However, they are used by 8 out of 11 DFM in our survey. They consist of a single update script that generates all Dockerfiles with their content using a shell language (bash for 4 out of 5 projects) or a general-purpose language (perl for one project).
These tools leverage on features offered by their host language and therefore provide many features (variables, loops, conditional evaluation, functions,. ). Listing 11 is an extract from the OpenJDK project's update script (written in bash). In this example, we see that a loop is used to generate the Dockerfiles for all versions of OpenJDK. Additionally, a conditional evaluation is used to add some extra dependencies if they are available for the target base image. Tools using generators place all the generator's code directly the update. sh script. Many projects use tools to handle duplicates. They fall into three categories: find and replace, template processors and generators. Several DFM stated that such tools can be too much time consuming or difficult to implement, and thus are not using them.
We use these two categories of propagated changes to discuss the pros and cons of each category of tools in the remainder of this section. a) Find and replace: Pros. Find and replace tools handle very well version updates propagation. Since the location of changes is known in advance, it's easy to build a regular expression or a sed command that automates them. In addition, it's very easy to set-up a find and replace tool, since it only requires to write a script that does nothing more than applying the sed command or the regular expression when called. Cons. On the other hand, find and replace tools are not adapted to other changes than version updates. Indeed, these changes are usually only applied once on the code base, therefore there is no use for defining and storing a regular expression or a sed command to perform it.
VIII. RELATED WORK In this section we discuss some research related to Docker and infrastructure as code. We also discuss different techniques used to detect duplicates in source code and other artefacts. Cito et al. [9]  conduct an empirical study on over 70,000 Dockerfiles assessing their quality and identify types of changes between consecutive versions of Dockerfiles. They show that common Dockerfiles are not changed often, while they indicate that popular Dockerfiles (like the ones in our corpus) happen to be more actively updated. They also indicate that the RUN instruction is the most commonly used instruction in Dockerfiles which can be linked to our results in Section V-A where we indicate that RUN instructions are the most frequently duplicated. Zerouali et al. [10]  perform an empirical analysis on 7,380 official and community Docker images that are based on the Debian Linux distribution.
They also analyse the correlation between their code smells, and show that design smells happen to co-occur more frequently which indicates the importance of design choices taken by developers. Hummer et al. [13]  propose a for testing Infrastructure as code automations for idempotence by following a model-based testing approach. They evaluate their tool on over 300 Chef scripts and determine that almost the third of them where actually idempotent. Their tool even let them to actually detect and report a bug in Chef implementation itself. Existing research on duplicates detection can be divided in two categories as follow: (a) in source code: CCFinder  [3]  proposes a token-based detection technique to identify duplicate code. Their tool is well-known and used by researchers. White et al. [14]  used a learning-based detection technique which relies on deep learning to detect code duplicates.
They found that their approach detected duplicates that weren't or where sub-optimally detected by traditional techniques. Ducasse et al. [15]  developed a language independent technique for detecting duplicated code without using any parser. Their technique relied on line-based string matching. There are also other duplicate detection techniques such as AST-based techniques  [16] -  [19]  and Graph-based techniques  [20] ,  [21]. Dhavleesh et al. [22]  did a systematic review of all software clone detection tools, that regroups other duplicates detection techniques we didn't present here. (b) in other artefacts: Liu et al. [23]  propose a suffixtree based approach to detect duplicates in UML sequence diagram. Störrle  [24]  also explores duplicates in UML and implement algorithms and heuristics for detecting duplicates with the MQlone tool.
IX. CONCLUSION Docker is becoming a popular tool used by developers and end-users to deploy and run software applications. Dockerfiles are now found alongside projects' source code. Several projects are even starting to maintain families of Dockerfiles. In some situations, Dockerfiles family maintainers have to propagate a change to several, if not all, Dockerfiles of the family. This need to propagate changes is usually due to the presence of duplicates between several family's Dockerfiles. In our study, we answer the question of duplicates handling in Dockerfiles families by providing a grounded study based on the analysis of the Official Docker Projects. We show that official Docker projects frequently maintain families of Dockerfiles and find the underlying reasons: supporting multiple versions/base-images and versions/flavours.
Agents range from simple fine-grained automata to complex coarse-grained knowledge-based systems. The environments are most usually spatial but there is no constraint about them. Interaction structures and languages range from physics-based interactions to speech acts. Organizations range from static to dynamic ones, and follow any kind of structure from hierarchies to markets. Vowels is guided by three principles for 'gluing the bricks'. The first principle (declarative) says that a MAS is composed of several agents, an environment, a set of possible interactions, and possibly at least one organization. The second principle (functional/computational) says that the functions that are performed by the MAS are those of the agents enriched by the ones resulting from the added value generated by the MAS itself, usually known as collective intelligence.
Finally, the third principle (recursion) says that a MAS could be potentially considered as agent entities at higher-level MAS. A key point of the approach is to see the A, E, I, O bricks as not atomic components, but as elements that can be composed of several parts, and these parts are distributed across the MAS when it is deployed. An architecture definition language called Madel (Multi-Agent DEscription Language) is used to describe the main parts of the system under construction, in the transition between development and deployment  (Ricordel & Demazeau, 2002). Vowels and Volcano were among the first developments showing the advantages of a methodology and a platform for adding, mixing, and reusing models of different aspects of MAS (Agent, Environment, Interaction, Organization), in terms of a high level of reuse, and the high abstraction level of the manipulated concepts  (Demazeau, 1995).
Dimensions in programming multi-agent systems Besides Vowels and Volcano, many specific agent programming languages and platforms have been developed in the last two decades 18. Our work is related in particular to BDI-based platforms that are explicitly oriented to practical development and in particular including an explicit support not only for the agent level, but also for the other dimensions, environment, and organization in particular. In fact, to the best of our knowledge, JaCaMo is the first fully fledged platform based on programming languages for the MAS dimensions that allow programmers to explore the synergies between those dimensions of concepts and programming constructs. Other existing approaches consider either the agent-organization dimensions or the agent-environment dimensions only, or do not have fully functional development platforms.