Concepts, Operations, and Feasibility of a Projection-Based Variation Control System

S, tefan Stanciulescu˘ Thorsten Berger Eric Walkingshaw Andrzej W ˛asowski IT University of Copenhagen Chalmers | University of Gothenburg Oregon State University IT University of Copenhagen Denmark Sweden USA Denmark [email protected] [email protected] [email protected] [email protected]

Abstract—Highly configurable software often uses preproces- // LCD selection sor annotations to handle variability. However, understanding, #ifdef U8GLIB_ST7920 maintaining, and evolving code with such annotations is difficult, //U8GLIB_ST7920_128X64_RRD u8g(0,0,0); mainly because a developer has to work with all variants at a U8GLIB_ST7920_128X64_RRD u8g(0); time. Dedicated methods and tools that allow working on a subset #elif defined(MAKRPANEL) of all variants could ease the engineering of highly configurable // The MaKrPanel display, software. We investigate the potential of one kind of such tools: // ST7565 controller as well projection-based variation control systems integrated with projec- U8GLIB_NHD_C12864 u8g(DOGLCD_CS, DOGLCD_A0); tional editors. For such systems we aim to understand: (i) what #elif defined(VIKI2) || defined(miniVIKI) end-user operations they need to support, and (ii) whether they // Mini Viki and Viki 2.0 LCD, can realize the actual evolution of real-world, highly configurable // ST7565 controller as well software. We conduct an experiment that investigates variability- U8GLIB_NHD_C12864 u8g(DOGLCD_CS, DOGLCD_A0); related evolution patterns and that evaluates the feasibility of a #elif defined(ELB_FULL_GRAPHIC_CONTROLLER) projection-based variation control system by replaying parts of // Based on the Adafruit ST7565 the history of a real-world 3D printer firmware project. Among // (http://www.adafruit.com/products/250) others, we show that the prototype variation control system does U8GLIB_LM6059 u8g(DOGLCD_CS, DOGLCD_A0); indeed support the evolution of a highly configurable system and #else that in general, it does not degrade the code. // for regular DOGM128 display with HW-SPI // HW-SPI Com: CS, A0 U8GLIB_DOGM128 u8g(DOGLCD_CS, DOGLCD_A0); #endif

Listing 1. Source code with annotations Consider the example from Listing1. 1 The code represents I.INTRODUCTION several variants related to the printer display that can be used. Understanding the code and what impact would a change have is more difficult because of the many variants. The projectional editing model [35] proposes a mechanism that allows to edit only the variants we are interested in. For example, selecting Tailoring systems to specific needs of users—such as hardware the MARKPANEL feature will give us the following code. environments, runtime platforms or various combinations of features—is becoming increasingly important. Such systems are // The MaKrPanel display, // ST7565 controller as well typically highly configurable by containing massive amounts U8GLIB_NHD_C12864 u8g(DOGLCD_CS, DOGLCD_A0); of variability, which is often realized using static variability annotations, such as conditional compilation directives, e.g. Now the developer can make a change on this variant, that #ifdef in C code [17]. While such annotations are among the contains less code and it is easier to understand than the source most frequently used and most simple variability mechanisms, code in Listing1, and should be able to update the repository their use is known to complicate writing, maintaining (e.g., bug- with the new code. fixing), and evolving (e.g., adding a cross cutting feature) source Various methods and tools that allow working on a dedicated code [10]. Variability annotations obscure the structure and flow subset of all variants have been proposed in the literature [35], of the underlying code [29], since much of the conditionally [21], [3], [18], [16]. These can ease to some degree the included code is often irrelevant for a particular code-editing engineering of highly configurable software, though none of task. In fact, working on all possible variants of the system them has found widespread adoption. In fact, no empirical at once is known to negatively impact the comprehension of data is available that shows how exactly they can be used to source code [24]. Beyond syntax-highlighting and code-folding, 1Source code from Marlin: https://github.com/MarlinFirmware/Marlin/ none of the major IDEs supports editing variant subsets while blob/a83bf18ee1063798e75ad6324b033752e0b1f66f/Marlin/dogm_lcd_ ensuring the consistency of the whole system. implementation.h engineer real-world systems, and what their specific benefits tems [18], [25] that provide editable views based on projections and challenges are. Another kind of tools that provide views specified by developers, and the projectional editing model [35]. on programs, but that are actually adopted in practice [32], All rely on variability realized using annotations embedded in are projectional editors, such as Jetbrains’ Meta Programming code, similar to C’s conditional-compilation directives (e.g., #if System [1] or Intentional’s Domain Workbench [27], [4]. Un- or #ifdef). These annotations carry a Boolean expression over fortunately, they lack dedicated operations related to editing features, called presence condition (PC) in the remainder. The source code with variability. first two systems do not exist anymore and there is hardly any In this paper, we conduct an empirical study to assess the evidence to their usefulness. The third has not been empirically feasibility of such methods and tools that allow working on evaluated and no publicly available tool exists. a dedicated subset of all variants, such as the projectional Kruskal [18], [19] presents an editor that realizes both editing model [35]. Towards building efficient, projection-based concurrent versioning (variability) and sequential versioning methods and tools for engineering highly configurable software, (deltas) relying on variability annotations. Similar to conditional we need to understand what operations users need and how they compilation, code lines are mapped to Boolean PCs, represent- could deal with such operations. To investigate if projection- ing both the variant and the version that specific lines belong based methods and tools can be used to engineer real world to. The editor creates views based on a partial configuration systems, we realize a variation control system that supports the (a conjunction of features) called mask, supporting workflows following workflow: (1) checkout the source code according where developers start with a relatively broad mask (e.g., to a given condition, (2) edit the code, and (3) checkin the projecting on just one feature), potentially restricting the mask edited code. by conjoining other features (i.e., “push” more masks on a Our system combines and extends concepts from prior work, stack), editing code in the views belong to the more restricted such as a projectional editing model [35] and change-oriented masks, and then returning to more broad masks (i.e., “pop” versioning [22]. We describe it using the choice calculus [8], masks from a stack). Code lines with PCs that do not contradict [33], [34], a concise and formal notation that avoids dealing the mask are visible for editing. Several convenience commands with intricate C preprocessor semantics and allows reasoning are available to the user for iterating through variants and for about highly configurable systems. manipulating PCs. Unfortunately, the editor is not available To identify end-user edit operations the system should anymore, and no empirical data on its use exists. support, we analyze the history of a highly configurable open- Lie et al. [22], Munch [25], and Westfechtel et al. [36] present source software system: the 3D printer firmware Marlin. We and evaluate an alternative versioning model based on logical aim at understanding the kinds of changes (patterns) related to changes: change-oriented versioning (CoV). It also unifies variability done by developers. We cross-validate the patterns versioning and variability, by attaching Boolean PCs to file using Busybox, an open-source project implementing shell fragments. It follows a classical checkin/checkout cycle, where tools for embedded systems. Based on the patterns we show a configuration (conjunction of features) determines both how the edit operations for the variation control system can the version and the variant available in the view (i.e., the be implemented. We then conduct an experiment where we workspace), which can be edited. It decouples the projection use our variation control system to replay parts of Marlin’s (called “choice”) from the expression used to checkin the edited history—by applying randomly selected patches to study how view (called “ambition”) to denote to which variants a change the edit operations can be realized using the variation control applies to. In an empirical study the authors translate existing system. In summary, we contribute: C/C++ source code files of gcc into CoV representation in • A projection-based variation control system relying on a a database (EPOSDB-II [12]), and compare the performance checkout/checkin workflow and automatically handling against RCS [30] when checkin version 2.4.0 of gcc. The variability annotations; experiment investigates only performance. It does not show how • End-user edit operations that show the use of the variation feasible it is to actually engineer a real-world system, and how control system, based on identified variability-related code exactly the checkin/checkout cycles with which expressions evolution patterns; for choices and ambitions can be used by developers. • Empirical data (metrics) that shows feasibility, benefits, Walkingshaw et al. present a model for a variation control and challenges of using the system, specifically showing system called projectional editing [35].3 They present a formal that the resulting code is not significantly degraded by specification of the model with the get (create a view using using the variation control system; a projection) and put (update the underlying program with 2 • A replication package in an online appendix, showing changes done within the view) functions at its core. Examples the use of the system (i.e., the code before projection, the are provided that show how to create the view and how an projection and its resulting view, the code changes, and update executes the changes done to the view. However, in the code after checking the view back in). contrast to CoV, the definition of put is founded on an edit II.MOTIVATION isolation principle that ensures that the only variants that change We briefly introduce two previous variation control sys- 3Not to be confused with projectional editing used in the Meta Programming 2http://bitbucket.org/modelsteam/2016-vcs-marlin System [1] or the Intentional Domain Workbench [4] B ::= true | false r derived edit r0 F ::= B | ¬F | F ∨ F | F ∧ F e ::= F he, ei Choice (1) get(p, r) put(p, p, r, w) (3) put(p, a, r, w0) | e · e Append get(p ∧ a, r0) w w0 | a Token (2) actual edit | ι Identity Fig. 2. Projection-based variational editing workflow and relationships. Symbol Fig. 1. Choice calculus syntax r represents the source code, p is the projection that specifies how to obtain the view w from r using the get function. The ambition a specifies how in the underlying program are those that can be reached from should the changes from the edited view w0 be applied to the repository using the put function. Both p and a are Boolean expressions over features. the view. In other words, when we put, the edits made on the view are guaranteed not to affect code that was hidden by the variability than afforded by #ifdef since it is not constrained get. Given this limitation, and since it was not evaluated on to varying lines. a real-world system, it is not clear whether this model can handle the engineering of such a system. B. Workflow To study the concepts and the use of a projection-based Figure2 shows the intended workflow of our system. Symbols variation control system, we create one that takes concepts from r and r0 refer to the highly configurable software source code previous work, while avoiding some limitations. For instance, stored in the repository, and w and w0 refer to working copies we allow partial configurations and use the ambition concept of the source code that are viewable and editable by the from CoV [25]. Our prototype’s design and implementation is developer. The source code (r, r0, w, w0) is represented by a mostly based on the projectional editing model [35]. choice calculus expression (e in Fig.1). The operation get is used to checkout a particular working copy from the repository, III.VARIATION CONTROL SYSTEM CONCEPTS and put is used to checkin any changes back to the repository. Our variation control system can be seen as a generalization In step (1) the developer obtains a simplified view w from of the one described before [35], but we borrow the concept the initial repository r. The parameter p, the projection, defines of ambition from CoV [25], which is used when updating the how w is obtained from r. More specifically, p describes a repository to specify which variants should be affected by the partial configuration of r, eliminating all of the variability that change. We allow partial configurations, whose consistency is irrelevant to the current code-editing task. In step (2) the with PCs is checked using a SAT solver. developer edits w into w0 using whatever standard tools they prefer. In step (3) an additional parameter a, the ambition, is A. Choice Calculus introduced, which specifies how the developer’s changes should We use the choice calculus [8], [33], [34], a formal and concise be integrated into the repository. Note that the put operation notation for variational software, to describe our projection- takes into account the initial repository, the updated working based variation control system and for expressing examples in copy, the projection, and the ambition when producing the a language independent manner. Figure1 describes its syntax. updated repository r0. Unlike previous applications of the choice calculus [9], we The two dashed edges in the diagram describe some basic do not embed choices within abstract syntax trees. Instead, we consistency principles that get and put should satisfy. These use a generic monoid structure. This better models the use of are derived from the lens laws developed in research on #ifdef directives in existing code repositories, since #ifdef bidirectional transformations [11] and constrain the potential directives are line-based and need not respect the syntactic definitions of get and put. structure of the underlying object language. The left dashed line requires that a get followed by a put The metavariable e denotes a choice calculus expression (i.e., is idempotent. Specifically, if we retrieve a simplified version code). An expression can consist of a choice, the concatenation w with some projection p and then immediately check it back of one expression to another using the monoid append operation in with the same ambition a = p, then the repository should (·), an arbitrary token, or the monoid identity element (ι). A remain unchanged. This enforces that the get operation is not choice represents a variation point in-place as a choice between effectful from the perspective of the repository. alternatives, written F he1, e2i. The associated condition F is The right dashed edge requires that a put followed by a the choice’s PC—a Boolean expression over features. When get (with an appropriately structured projection) is idempotent. configuring a choice calculus expression, each feature is set to Specifically, immediately after applying put function to checkin true or false, then each choice is replaced by either alternative changes from the edited view w0, we can obtain that same e1 if F evaluates to true, or alternative e2 otherwise. For working copy by doing a checkout using the conjunction of p example, given the choice (A ∧ B)h2, 3i, if both features A and a as the projection. This enforces that the effects of the and B are set to true, the choice will resolve to 2 during put operation are always reversible. configuration, but will resolve to 3 if A or B is false. We consider tokens to be arbitrary strings, the append operation to C. Get and Put Function be string and line concatenation, and the identity element to Specifying and implementing get is straightforward (e.g. via be the empty string. This allows for a finer representation of partial preprocessing). For the put operation it is difficult to IV. METHODOLOGY FACTORING F he1, e2i · F he3, e4i F he1 · e3, e2 · e4i In our study we investigate two research questions: F he1, e2i · ¬F he3, e4i F he1 · e4, e2 · e3i RQ1: What edit operations should a variation control system CHOICE-DOMINATION support? We analyze the history of an open-source project CHOICE-IDEMPOTENCY 0 0 belcF = el berc¬F = er repository at the source code level to identify variability-related F he, ei e 0 0 F hel, eri F hel, eri editing patterns. We show how edit operations for the variation JOIN-OR control system can realize the patterns found. 0 0 F hel,F hel, erii (F ∨ F )hel, eri RQ2: Can a variation control system be used to maintain and JOIN-AND evolve a highly configurable system? In an experiment we 0 0 F hF hel, eri, eri (F ∧ F )hel, eri replay parts of the history of our subject system using the JOIN-OR-NOT variation control system, and check how many cases we can 0 0 F hel,F her, elii (F ∨ ¬F )hel, eri support and which are not trivial to support. Using metrics we JOIN-AND-NOT 0 0 study characteristics of the code before checkout, of the view F hF her, eli, eri (F ∧ ¬F )hel, eri itself, and of the code after checkin. Specifically, we check that there is no negative effect (e.g., deterioration) on the source Fig. 3. Choice calculus minimization rules code by our variation control system. identify a simple and rational definition that is consistent with Our investigation of both research questions is followed by a the above requirements by analyzing examples alone. Recall discussion of the challenges we encountered (e.g., for choosing that our previous work [35] relied on an edit isolation principle: projection and ambition) during the experiment, and of the edit When doing a put in (3), the edits made in (2) cannot affect operations we identified. code hidden by get in (1). Although this principle is somewhat A. Subject System restrictive, it leads naturally to a definition that satisfies the requirements derived from the lens laws. Generalizing the edit We study Marlin, a highly configurable firmware for 3D isolation principle, we can obtain a put operation that is less printers written in C++, that uses conditional compilation to restrictive than in the previous work, while still retaining the implement variability. Marlin emerged in 2011 as a mixture properties. of the existing projects, Grbl (firmware for CNC machines) and Sprinter (firmware for 3D printers), and original code. We This generalized edit isolation principle can be defined as chose Marlin as it is large and complex enough for our purpose follows. Let C be the set of all configurations of r and r0, (40KLOC and over 140 features) and we have prior experience and r0 = put(p, a, r, w0) as defined in Fig.2. The get function with understanding the system [31], which reduces the chance obtains all choices whose PC does not contradict the projection: of misinterpretations of mistakes. We use the development get(c, w0) if SAT(c ∧ p) branch of Marlin’s Git repository4 on Github. We cloned the ∀c ∈ C. get(c, r0) = get(c, r) otherwise “MarlinDev” repository with the HEAD pointing to commit 3cfe1dce1. This version of Marlin consists of 187 source files The put update function consists of constructing a new (excluding additional library files supporting Arduino boards). choice with the updated view w0 in the left branch, and the original source r in the right branch: B. RQ1: Identification of Edit Operations To identify edit operations we analyze patches and extract put(p, a, r, w0) = minimize(F hw0, ri) variability-related edit patterns. We retrieve all 3747 commits F = (p ∧ a) (without merge commits) from Marlin’s history and split each commit into a patch per changed file, excluding those files We minimize the choice expressions to a more compact that were added, removed or renamed, resulting in 5640 per representation, which reduces redundancy, using rules shown changed file patches. in Fig.3. Note that they can change the syntax of a choice, but We classify the patches into patterns in three steps. First, preserve its semantics. For an in-depth description of choice- we randomly extract 50 commits that add or remove #ifdef idempotency, choice-domination and join rules, please refer to directives in code using grep, and manually inspect the patch previous work [35]. The FACTORING rules join two consecutive to understand the change and recognize patterns. Second, to choices that have compatible PCs into a single choice. automatically classify to which edit pattern a patch belongs to, D. Implementation we create several regular expressions to represent each pattern defined previously, and apply them on the patches. We analyze We implement the variation control system prototype, com- the results of this step by verifying if all the patches have been prising parser, get and put function, minimization rules, and classified. Third, for patches that remain unclassified, we add pretty printer, in Scala. The prototype is programming-language- the respective regular expressions and re-run the classification. independent, but the parser and pretty printer recognize and We repeat these steps until every patch is classified with at least write variability annotations in C preprocessor syntax (e.g., #if, #ifdef, #endif). Internally, the choice calculus [33] is used. 4https://github.com/MarlinFirmware/MarlinDev one update pattern (note that a patch can belong to multiple TABLE I patterns). CODE-ADDING PATTERNS To cross-validate the patterns we run our classifier on the Name #Multi #Only Example Busybox5 project, a larger project with 175K LOC. We cloned the project’s repository at commit a83e3ae, containing 13,700 P1 AddIfdef 969 129 ι → F he, ιi P2 AddIfdef∗ 424 32 (ι → F he, ιi)∗ commits excluding merge commits, and again split them into P3 AddIfdefElse 271 4 ι → F he1, e2i a patch per file, which yielded 34,018 patches. P4 AddIfdefWrapElse 43 17 e2 → F he1, e2i P5 AddIfdefWrapThen 13 3 e1 → F he1, e2i C. RQ2: Replaying a Sample of Marlin’s History P6 AddNormalCode 4683 871 ι → e P7 AddAnnotation 293 12 not applicable We replay randomly selected patches from Marlin (RQ2). We filter the 5640 Marlin patches down to 2322 by considering only those patches that modify files containing only Boolean V. EDIT OPERATIONS presence conditions. This is justified as we are not interested in analyzing the complexity of Marlin’s PCs. Other kind of PCs We now explain each identified pattern and how it can be turned could be handled using an SMT or CSP solver, without affecting into an edit operation (RQ1) on top of the variation control the variation control system’s main design features. From the system. We use a stripped notation of the unified diff program to 2322 patches we randomly selected three for each identified represent the changes. A plus (+) in front of a line indicates that edit pattern. Some patterns did not have any purely Boolean the line is to be added, a minus (-) that the line is to be removed. representative in the selection. For these we randomly picked A line without plus or minus remains unmodified. We remove missing patches from the whole pool of 5640 (Boolean and non- meta information (e.g., header, hunks range information), as it Boolean) patches, and transform non-Boolean expressions into is not particularly useful for representing the pattern. Running Boolean ones by introducing new variables for non-Boolean the pattern classifier, we identified 14 types of edit patterns. sub-expressions (a simple form of predicate abstraction). We split these into three categories: Code-Adding Patterns, 1) Experiment Setup: For each randomly selected patch, Code-Removing Patterns, and Other Patterns. we manually conceive the projection and ambition required These patterns represent edit operations that projection-based to replay it. Recall that the projection represents a set of variation control systems need to support. We show for each configurations for which the code is changed. To conceive it pattern how the workflow described in Sec. III-B can be applied we localize the change in the file using line numbers from the to realize the particular edit. patch’s meta-data and then check if those lines exist under any A. Code-Adding Patterns PC. The projection is then a conjunction of all the PCs. The ambition is conceived using only the patch information. We Table 1 shows patterns where new code is added, together with replay each change in three steps, where S1 and S3 are done the number of patches belonging to each pattern. The #Multi by our prototype, and S2 is done manually in a text editor: column indicates the number of patches that match the given S1 Checkout the original source code file using a projection. pattern and also one or more other patterns, while the #Only S2 Edit the view to apply changes from the patch. column indicates the number of patches that match only that S3 Checkin changes using the projection and ambition. pattern. The last column provides a brief illustration of the 2) Metrics: We compute metrics for the stages in our pattern using the choice calculus. workflow (cf. Fig.2): original source code (r), projected source P1 AddIfdef. In this pattern a simple #ifdef with no #else code (w), and updated source code by our system (r’). To branch is added in the code, as shown below. compare the latter to the updated original source code, we also + #ifdef ULTRA_LCD compute the metrics for the original update (r’) from Marlin’s + lcd_setalertstatuspgm(lcd_msg); Git repository. We use the following metrics: + #endif • LOC: lines of code in a file, including comments and This pattern can be achieved in the variation control system by excluding blank lines. doing a checkout with the trivial projection true, adding the _ • NVAR: number of variation points; more precisely: second line, then checkin changes with the ambition ULTRA LCD. choices (represented by #if, #ifdef, #ifndef, etc.) in In Fig.4 we illustrate this workflow using the choice calculus. a file. A high NVAR challenges code comprehension. For simplicity of presentation, in this and following examples We compute the reduction factor for LOC and NVAR we assume starting with an empty file or with just a few lines _ by dividing their values after checkout (view) to the values of code. We use U as shorthand for the ULTRA LCD feature and before checkout, which would show any positive or negative lcd for the code on second line. We will use these abbreviations throughout the section. impact of creating views. Finally, we consider the number of ∗ checkin/checkout cycles per executed change. In some cases, P2 AddIfdef . In this pattern two or more simple #ifdef with we need to apply different projections and ambitions to realize no #else branches are added to the code. We distinguish a change. We count this number of steps. this pattern from the previous one, since adding multiple #ifdef blocks at once may require multiple checkout/checkin 5http://busybox.net sequences if the PCs are different. If multiple #ifdef blocks r = ι r0 = Uhlcd, ιi P5 AddIfdefWrapThen. This pattern is dual to the previous get(true, r) put(true, U, r, w0) pattern. In this pattern, the original code becomes the then- branch of a new #ifdef block, as illustrated below. w = ι w0 = lcd actual edit + #ifdef ULTRA_LCD lcd_setalertstatuspgm(lcd_msg); Fig. 4. P1 AddIfdef editing workflow. + #else + alertstatuspgm(msg); are added that have the same presence condition, then the edit + #endif can be executed in the same way as the P1 AddIfdef pattern. The workflow to support this pattern is as the one from P4 P3 AddIfdefElse. In this pattern, presented below, an #ifdef AddIfdefWrapElse, except that we checkin with ambition ¬U. with an #else branch is added in the code. P6 AddNormalCode. This pattern represents changes that do + #ifdef ULTRA_LCD not affect the variability of the code base. That is, the modified + lcd_setalertstatuspgm(lcd_msg); code is either (1) non-variational, or (2) exists under a specific #else + presence condition. This is the most common of the operations + alertstatuspgm(msg); + #endif performed during system evolution [23]. In case 1, we just checkout and checkin with p = a = true. In case 2, we This pattern is supported by the projection-based variation checkout with a p equal to the presence condition of the control system in two ways. The first is to do a checkout modified code, then checkin with a = true. In case 2, if with trivial projection (e.g., p = true), add the full #ifdef– the presence condition eliminates a significant amount of #else–#endif block directly, and then checkin with a trivial surrounding code, then we expect our editing workflow to ambition. However, it is also supported by a sequence of two convey significant usability benefits since this code is irrelevant edits, one that edits the configurations where ULTRA_LCD feature to the edit being performed. This is confirmed in a case in our is enabled, and one that edits the configurations where it is experiment, where more than half of the code is eliminated in disabled. the view. In Fig.5, we illustrate this edit using our workflow. We use P7 AddAnnotation. This pattern captures cases where preproces- lcd and alert as shorthand for the code on lines two and four, sor annotations are added to the code. This usually corresponds respectively. to adding a new #ifdef line or a new #endif line to the code to fix a previous mistake. We do not exclude whitespace changes, ι Uhlcd, ιi get(¬U,r2) Uhlcd, alerti get(true,r) thus this pattern happens also when there are changes in the 0 0 line that contains the annotations (e.g., adding a comment to put(true, U, r1, w1) put(¬U, ¬U, r2, w2) ι lcd ι alert the line). Our editing model does not support such cases since actual edit actual edit we permit only well-formed variability annotations and the Fig. 5. P3 AddIfdefElse editing workflow. prototype handles the annotations.

P4 AddIfdefWrapElse. This pattern represents cases where some B. Code-Removing Patterns existing code becomes the else-branch of a new #ifdef block. TableII lists patterns that relate to removing code. The pattern is presented below. P9 RemNormalCode. This pattern captures cases where code is + #ifdef ULTRA_LCD removed, regardless of whether it is under a presence condition + lcd_setalertstatuspgm(lcd_msg); or not. The pattern is presented below. + #else #ifdef ULTRA_LCD alertstatuspgm(msg); - lcd_setalertstatuspgm(lcd_msg); + #endif alertstatuspgm(msg); This pattern is well-supported by our workflow, as illustrated #endif in Fig.6, where we checkout with a trivial projection, edit the The update in this case is simply to checkout the source original code, and then checkin with the ambition ULTRA_LCD. code with projection ULTRA_LCD, delete line two, and checkin with ambition ULTRA_LCD as shown in Fig.7. r = alert r0 = Uhlcd, alerti For cases where an #else branch exists in the #ifdef block, get(true, r) put(true, U, r, w0) the workflow is the same but the projection is the negation

w = alert w0 = lcd actual edit TABLE II Fig. 6. P4 AddIfdefWrapElse editing workflow. CODE-REMOVING PATTERNS

Note that checking out with projection U in step (1) would Name #Multi #Only Example yield the same result, but the advantage of the given workflow P9 RemNormalCode 3932 209 e → ι is that we can decide after making the edits how they should P8 RemIfdef 534 24 F he1, e2i → ι be applied to the repository. P10 RemAnnotation 228 2 r = Uhlcd · alert, ιi r0 = Uhalert, ιi r = lcd r0 = Uhlcd, ιi get(U, r) put(U, U, r, w0) get(true, r) put(true, ¬U, r, w0) w = lcd · alert w0 = alert actual edit w = lcd w0 = ι actual edit Fig. 7. P7 editing workflow. Fig. 9. P11 editing workflow. of the PC. All the numbers corresponding to P9 in TableII ambition that describes the configurations in which the code include any removed code from an #ifdef block. should no longer appear (e.g., ¬ULTRA_LCD). P8 RemIfdef. This pattern captures cases where code blocks P12 UnwrapCode. guarded by presence conditions are removed. This pattern This pattern describes the opposite case where an existing piece of variational code is made non- covers the remove of both simple #ifdef blocks, and those containing an else-branch. The pattern is presented below. variational, that is, the surrounding #ifdef and #endif an- notations are removed, as shown below. - #ifdef ULTRA_LCD _ - lcd_setalertstatuspgm(lcd_msg); - #ifdef ULTRA LCD _ _ - #else lcd setalertstatuspgm(lcd msg); - alertstatuspgm(msg); - #endif - #endif This pattern is not very amenable to the projectional editing This edit is dual to the P3 AddIfdefElse and can be similarly model. The workflow for this pattern is shown in Fig. 10. supported either by a trivial projection, or by a sequence of Essentially, it requires to obtain the variants that do not include two edits, as illustrated in Fig.8. the code, re-adding the same code, and checkin with the same ambition as the projection. Uhlcd, alerti Uhι, alerti ι Note that before minimization, the put will produce a choice get(¬U,r2) get(U,r1) Uhlcd, lcdi, where both alternatives are the same. This can 0 0 put(U, U, r1, w1) put(¬U, ¬U, r2, w2) be simplified to simply lcd using the choice idempotency lcd ι alert ι actual edit actual edit minimization rule, resulting in r0. Observe that the manual edit to transform w into w0 requires Fig. 8. P8 RemIfdef editing workflow. reproducing the code that was projected away in step (1). Although this can be accomplished for a single #ifdef with P10 RemAnnotation. This pattern represents cases where copy–paste, clearly this is not ideal. Therefore, this scenario is annotations are removed from code. This can happen when a better supported by a non-projectional edit, doing a checkout #ifdef or #endif line was previously removed, resulting in an the trivial true, removing the #ifdef and #endif annotations, ill-formed variation. As with the P7 AddAnnotation pattern, and use ambition true for checkin. this pattern cannot be reproduced (and would not occur) when P13 ChangePC. This pattern describes cases where the PC using our editing model since we do not support ill-formed associated with an #ifdef is changed, as shown below. variation annotations. - #ifdef ULTRA_LCD C. Other Patterns + #if ULTRALCD && ULTIPANEL lcd_setalertstatuspgm(lcd_msg); The remaining editing patterns are listed in Table III. #endif P11 WrapCode. This pattern describes cases where an existing In this example two changes have occurred: the ULTRA_LCD piece of code is made variational, as shown next. option has been renamed ULTRALCD, and an additional constraint + #ifdef ULTRA_LCD ULTIPANEL has also been added. lcd_setalertstatuspgm(lcd_msg); This pattern is best supported without a projectional edit + #endif because it would require to remove all code under the old We show how to support this pattern in Fig.9. We checkout with PC and then add the same code that was removed under the a trivial projection, delete the code that should be conditionally new PC. In future work, we plan to explore operations for wrapped, in this case line two, and then checkin with an explicitly supporting such edits, including feature renaming and systematic modifications to presence conditions.

TABLE III OTHER PATTERNS Fig. 10. P12 editing workflow. Name #Multi #Only Example r = Uhlcd, ιi r0 = lcd P11 WrapCode 77 29 e → F he, ιi put(¬U, ¬U, r, w0) P12 UnwrapCode 12 2 F he, ιi → e get(¬U, r) P13 ChangePC 225 74 F1he1, e2i → F2he1, e2i w = ι w0 = lcd P14 MoveElse 5 2 F he1, e2 · e3i → F he1 · e2, e3i actual edit TABLE IV

LOCANDNVARMETRICSWITHTHEMIN, MAX, AND MEDIAN VALUES FOR LOC ● ● ● ● ● THE 33 CHANGESFORTHEPUTFUNCTION.REPOSITORY UPDATE REPRESENTSTHECHANGEINTHEORIGINALGITREPOSITORYOFTHE PROJECT. NVAR ● ● ●

LOC NVAR 0.0 0.2 0.4 0.6 Reduction Factor Put function Repository update Put function Repository update MIN 65 72 1 1 Fig. 12. Reduction factors for LOC and NVAR for the view. MAX 2448 2368 193 147 MEDIAN 447 449 20 21 ill-formed variation and was excluded. In total we used the variation control system on 33 patches. All the selected patches were successfully applied using the P14 MoveElse. This pattern captures cases where an #else variation control system. The actual changes on the view were annotation is moved in order to move some code from one set performed with a simple text editor. Note that for all patches of configurations to another. This pattern is presented below. that add or remove #ifdef blocks, we only touched the code #ifdef ULTRA_LCD between the annotations to realize the edit; the annotations are _ _ lcd setalertstatuspgm(lcd msg); handled by the variation control system. - #else alertstatuspgm(msg); Observation 1: A projection-based variation control + #else cleanup(msg); system can support all the presented edit patterns when #endif no malformed variability annotations exist. This (infrequent) pattern is another that is perhaps best B. Complexity of Projections and Ambitions supported without projectional editing, but it can be achieved Since some patches required multiple steps to execute the by two edits as illustrated in Fig. 11. In this example we use change, we performed a total of 37 projections. Of these, 14 use the first letter of each line (two, four and six), due to space one feature and 11 the trivial condition true. The remaining 12 limitations, to indicate the respective line of code. projections use two, three or four features in their expressions. In three cases the projection is the conjunction of four features, Uhl, a · ci Uhl, ci Uhl · a, ci get(U,r2) making these projections more difficult to understand and use. get(¬U,r1) Yet, it is not uncommon that a developer needs to consider 0 0 put(¬U,¬U,r1,w ) put(U,U,r2,w2) a · c 1 c l l · a two or more features (i.e., ≥ 4 system variants) when fixing actual edit actual edit bugs. In fact, Abal et al. [2] identified 30 bugs that occur when there is a combination of at least two configuration options. In Fig. 11. P14 MoveElse such cases, using a projection-based editing tool could simplify As with the P12 UnwrapCode pattern, this requires reproducing focusing only on the variants in which the bug appears. (or copy–pasting) some part of the code between projectional In ambitions, the highest number of features is the same as edits (e.g., alert in this example). in projections, four. But we see a decrease of trivial ambitions, which is expected, as for example P11 WrapCode edits may VI.RESULTS be performed on trivial projections, but require an ambition We now present the results of applying the variation control different than true. In one case the expression used for both system. All evaluation data is available in the online appendix.6 projection and ambition is a conjunction of a feature and a Our objective in this experiment is to verify if the edit disjunction, p = A ∧ (B ∨ C). Finally, for 18 changes the patterns described in Sec.V are indeed supported, and what ambition equals the projection. kind of projections and ambitions are used. Moreover, we are C. Metrics and Reduction Factors interested to see if there is any negative effect on the source code when using the prototype variation control system. TableIV shows the aggregate values (min, max, and median) of our metrics on the source code resulted from the update A. Applying the Changes done by the prototype, and the original update from the Git Following the methodology from Sec. IV-C, we randomly repository. While our goal is not to improve code with regards selected patches that belong to only one edit pattern, covering to LOC or NVAR, TableIV shows that the prototype does not 12 edit patterns out of 14. Patches from the remaining two edit perform worse than the original update, in almost all cases. patterns (P7 AddAnnotation, P10 RemAnnotation) cannot be The boxplot in Fig. 12 shows the reduction factor for LOC executed with the prototype. We therefore ignore these two and NVAR after the projection. For the LOC reduction factor update patterns and obtain 34 patches. One patch belonging when doing projections, we would expect it to be zero, in the to P12 UnwrapCode contains merge conflicts leading to an case of using a trivial projection, or larger than zero when a non-trivial projection is used. TableIV and the boxplot confirm 6http://bitbucket.org/modelsteam/2016-vcs-marlin this hypothesis. The average number of LOC after projection is smaller than before projection. In one outlier case the LOC derive, where needed, the edit operations for a variation control in the view was reduced by half, compared to the original system. Most patterns can be used in a straightforward manner file. The reason is that the source code has a sequence of and do not require specialized operations. However, a variation #if-#elif-#else-#endif directives with many #elif branches, control system would require a specialized edit operation for which naturally contradicted the projection. In such cases, the allowing the renaming and changing a PC. We also need better benefit of projecting views can be high, especially for code support for P12 UnwrapCode and P14 MoveElse patterns, as an comprehension (e.g., to understand the control flow). extra copy-paste editing step is required. These would require As we would also expect, NVAR is reduced when projecting more specialized primitive operations, ideally in a text editor the code, although this reduction is minimal in most cases. In or IDE. In future work we plan to define and implement these our experiment, many changes are done on features that wrap edit operations, and experiment how well they can be used. an entire file’s source code or use the trivial projection true. Finally, we identified a limitation of the variation control Nevertheless, in three outlier cases there is a high decrease in system, which is not solved by any of the existing ones either. NVAR when many #ifdef blocks are projected away. The generalized edit isolation principle (cf. Sec. III-B) raises Finally, we investigate whether there is any degradation of the following problem: How to handle the cases when an code when using the variation control system. Comparing the ambition is weaker than the projection? An example scenario LOC between the update done by the variation control system could be fixing a bug in a particular variant, where the fix and the original update shows that the former has the same or might affect other variants as well. So instead of fixing the less LOC in most cases. The differences mostly occur when bug in all variants, we would like to have a specific projection, two consecutive choices (#ifdef blocks) with the same PC but then perform the change with a weaker ambition. Our are merged, or when one has the other one’s negated PC, as definition of the put function (which conjoins projection and formulated by the factoring rule shown in Fig.3. This merging ambition) cannot handle this case. Solving this problem in a also affects the number of variation points, generating a lower sound way is subject to future work. number in the case of the variation control system’s update. VIII.THREATS TO VALIDITY Observation 2: A projection-based variation control A. Internal Validity system can be used to engineer a highly configurable We consider our updates to be correct as the put function is system. Our prototype did not negatively impact the code correct by construction. To check for bugs in the prototype, in terms of LOC, NVAR. In some cases it even improved we used KDiff3 to compare the update result of the prototype the code. with the original update from the repository. We examined and VII.DISCUSSION compared the two updates visually. We double-checked the Let us now discuss challenges we encountered in the experiment two cases where our update performs worse, which showed (RQ2) and then get back to the editing operations (RQ1). that the update result is correct and preserves semantics. We developed a general parser for the C preprocessor A. Challenges of Using the Variation Control System language, as it is simpler and less error-prone than language- Most importantly, the editing workflow is different. This specific parsers. This allows to use the system with any source requires some mental effort in understanding what projection code that implements variability using preprocessor annotations. and ambition to use. However, in our experience, choosing a Our definition and implementation of the variation control projection and ambition was straightforward in most cases, system might be incorrect, and we might introduce bias when but more difficult for changes that required two or three identifying the edit operations or conducting the experiment. checkin/checkout cycles. To identify edit operations we followed a systematic ap- An interesting case to consider is choosing the ambition when proach: first studying samples, then iteratively creating regular making code optional, that is, wrapping existing code with a expressions to validate them on all 5640 Marlin patches. We PC. Both P11 WrapCode and P5 AddIfdefWrapThen require also cross-checked the identified operations on 34,018 patches the ambition to be the negated desired presence condition. from Busybox, another highly configurable software project The intuition is that the we have to choose an ambition that from a different domain. 99.27% of the patches in Busybox describes in which configurations should the code not appear. were classified in one or more patterns that we previously This may seem unintuitive at first, but it is easy to see why identified. this is necessary. In a text editor or IDE, the user could select In the experiment, we reduce bias of replaying changes with the code that should be under a PC and just enter that PC. the variation control system by randomly selecting patches spanning all twelve edit operations considered. B. Edit Operations for a Variation Control System Some of the identified edit patterns were difficult to replay B. External Validity using the projection-based editing workflow and the realization The identified edit patterns overlap with some extracted in of the get/put functions. However, the edit patterns should not previous work [15], [26], [6], which increases our confidence in be seen as the edit operations a developer would use when the method and completeness. While more patterns might exist, using a variation control system. We use the edit patterns to our collection was sufficient for executing complex changes. Composing edit operations can allow a user to execute the decomposed structure in terms of module units of the program. same change as in a normal editing model, modulo number of A classes view shows the decomposed structure of classes. steps. The edit operations are generic and also specific enough Changes applied to one view are reflected in the other view, to allow to execute any change. Using the trivial projection which is automatically modified and updated. The tool stores and ambition true, the proposed workflow behaves similarly the structure of the program internally, while the developer as the normal editing model. edits a so called virtual source file [5]. We did not consider systems that use a variability model and a dedicated variability-aware build system for implementing B. Evolution of Highly Configurable Software more complex variability, such as the Linux Kernel or Busybox. Several studies of changes performed to highly configurable However, the variation control system can still be used to software exist [6], [26], [23]. They usually also consider the directly manipulate the source code, as well as the variability variability model and the build system of such software, model and the build files. whereas we focus only on the code level. IX.RELATED WORK Dintzner et al. aggregate feature-evolution information by mining commits [6], including extensive information of what In addition to the three approaches discussed in Sec.II that our artifacts are affected. They mainly consider commits that touch variation control system is most similar to, other techniques #ifdef blocks. They create this data for the variability model, to realize views on configurable code are proposed in the build system, and source code. Their focus is not to detect literature. what exact type of changes are done, but to offer an overview A. Views on Source Code of the evolution of features. In contrast, our work identifies what kind of code edits occur in real systems and whether Atkins et al. develop a version editor that hides preprocessor these can be applied using a variation control system. directives, allowing to edit a particular variant of a source Passos et al. present a catalog of patterns on the co-evolution file [3]. Edits to the view are propagated back into the source of features in the variability model, build system, and code, file. Their study on a large telecommunication project shows a obtained from the Linux Kernel [26]. Several patterns use productivity increase of up to 40%. only the variability model and/or the build files to add or Hofer et al. argue that existing approaches to assist with remove features. Some of our patterns overlap with theirs: P3 handling the preprocessor are tied to IDEs—thus, their adoption AddIfdefElse corresponds to AVONMF (Add Visible Optional rate is low [13]. They introduce the filesystem LEVIATHAN Non Modular Feature), P5 AddIfdefWrapThen to FCUTVOF that mounts a view representing a variant. Heuristics are used (Featurize Compilation Unit to Visible Optional Feature), and to synchronize changes in the view with the source code in P8 RemIfdef to RVONMF (Remove Visible Optional Non the physical storage. However, it does not allow modifying the Modular Feature). The main difference between our work and structure of the conditional blocks when working on a view. theirs is that we do not want to understand how a system C-CLR is an Eclipse plugin that allows creating a view by evolves in all three spaces, but if source code changes can be selecting the respective preprocessor macros (features) [28]. The supported with a variation control system. tool offers support for generating views, but not for executing changes and updating the view. Similarly, folding is used as X.CONCLUSION a visualization technique by Kullbach et al. [20] to hide and unhide code in the GUPRO tool [7]. The idea is to fold parts of Maintaining and evolving highly configurable software is chal- code (including preprocessor directives) and possibly labeling lenging for many projects. Using a projection-based variation the fold to easily identify its purpose. control systems may overcome some of these challenges. So Kaestner et al. propose colors to show annotated code far, experience with variation control systems is limited. corresponding to a feature [16], and implement the Colored IDE In this paper, we have designed and formally described a (CIDE). The tool requires disciplined preprocessor annotations, variation control system that combines and extends concepts such that arbitrary code fragments cannot be annotated. A vari- of prior proposals in the literature. In a study, we identified ant view shows annotated code fragments using a background 14 variability-related edit patterns from a highly configurable color according to a feature selection. Markers are used to 3D printer firmware project. We used the patterns to derive show code that belongs to features that are not selected. what edit operations a projection-based variation control system A similar tool that uses colors (but lacks the ability to hide needs to support. We then conducted an experiment using a code) is developed by Le et al. [21]. Internally it uses choice prototype of the variation control system to replay real changes calculus. A controlled experiment with students shows that the from the subject system to show that indeed a variation control prototype increases code comprehension compared to the C system can be used to maintain and evolve a highly configurable preprocessor tool. Users were more successful and efficient in software system. completing their tasks and gave more correct answers, which We found that while the projection-based editing model can motivates the use of dedicated variation control systems. support most edit operations, some are difficult to realize with Janzen et al. propose to use crosscutting effective views this model and require extra effort. However, when executing to modularize concerns [14]. The modules view provides a changes with the prototype we found that in most cases the code does not degrade with respect to code size and number [22] A. Lie, R. Conradi, T. M. Didriksen, and E.-A. Karlsson. Change oriented of variation points, and it is fairly easy to use. versioning in a software engineering database. SIGSOFT Softw. Eng. Notes, 14(7):56–65, 1989. In future work, we need to allow developers to work in [23] R. Lotufo, S. She, T. Berger, K. Czarnecki, and A. Wasowski. Evolution parallel on a project, meaning we need to handle merge conflicts of the linux kernel variability model. In Proceedings of 14th International and possible integration aspects. We are currently developing Conference, (SPLC), 2010. [24] J. Melo, C. Brabrand, and A. W˛asowski. How Does the Degree of a user interface that is connected to the prototype, to allow us Variability Affect Bug-Finding? In International Conference on Software to implement and test the identified edit operations on highly Engineering (ICSE), 2016. configurable systems. [25] B. P. Munch. Versioning in a Software Engineering Database — the Change Oriented Way. PhD thesis, Norwegian Institute of Technology, Division of Computer Systems and Telematics, 1993. REFERENCES [26] L. Passos, L. Teixeira, D. Nicolas, S. Apel, A. W ˛asowski, K. Czarnecki, P. Borba, and J. Guo. Coevolution of variability models and related [1] Jetbrains MPS. http://www.jetbrains.com/mps. software artifacts: A fresh look at evolution patterns in the linux kernel. [2] I. Abal, C. Brabrand, and A. Wasowski. 42 variability bugs in the linux Empirical Software Engineering, Springer, 2015. kernel: a qualitative analysis. In ACM/IEEE International Conference [27] C. Simonyi, M. Christerson, and S. Clifford. Intentional Software. In on Automated Software Engineering, ASE, 2014, pages 421–432, 2014. Proceedings of OOPSLA, 2006. [3] D. L. Atkins, T. Ball, T. L. Graves, and A. Mockus. Using Version [28] N. Singh, C. Gibbs, and Y. Coady. C-clr: A tool for navigating highly Control Data to Evaluate the Impact of Software Tools: A Case Study of configurable system software. In Proceedings of the 6th Workshop on the Version Editor. IEEE Trans. on Software Engineering, 28(7):625–637, Aspects, Components, and Patterns for Infrastructure Software (ACP4IS), 2002. 2007. [4] M. Christerson and H. Kolk. Domain expert DSLs, 2009. talk at [29] H. Spencer and C. Geoff. #ifdef Considered Harmful, or Portability QCon London 2009, available at http://www.infoq.com/presentations/ Experience With C News. In USENIX Summer Technical Conference, DSL-Magnus-Christerson-Henk-Kolk. pages 185–198, 1992. [5] M. C. Chu-Carroll, J. Wright, and D. Shields. Supporting aggregation [30] W. F. Tichy. RCS — A System for Version Control. 7(July 1985):637– in fine grained software configuration management. ACM SIGSOFT 654, 1985. Software Engineering Notes, 27:99, 2002. [31]S , . Stanciulescu,˘ S. Schulze, and A. W˛asowski. Forked and Integrated [6] N. Dintzner, A. van Deursen, and M. Pinzger. Fever: Extracting feature- Variants in an Open-Source Firmware Project. In 31st International oriented changes from commits. In 13th International Conference on Conference on Software Maintenance and Evolution (ICSME), 2015. Mining Software Repositories (MSR), 2016. [32] M. Voelter, J. Siegmund, T. Berger, and B. Kolb. Towards user-friendly [7] J. Ebert, R. Gimnich, H. Stasch, and A. Winter. Gupro - generische projectional editors. In 7th International Conference on Software umgebung zum programmverstehen. Koblenzer Schriften zur Informatik. Language Engineering (SLE), 2014. Folbach, Koblenz, 1998. [33] E. Walkingshaw. The Choice Calculus: A Formal Language of Variation. [8] M. Erwig and E. Walkingshaw. The Choice Calculus: A Representation PhD thesis, Oregon State University, USA, 2013. for Software Variation. ACM Trans. on Software Engineering and [34] E. Walkingshaw and M. Erwig. A calculus for modeling and implement- Methodology (TOSEM), 21(1):6:1–6:27, 2011. ing variation. SIGPLAN Not., 48(3):132–140, Sept. 2012. [9] M. Erwig and E. Walkingshaw. Generative and Transformational [35] E. Walkingshaw and K. Ostermann. Projectional editing of variational Techniques in Software Engineering IV: International Summer School, software. In Generative Programming: Concepts and Experiences GTTSE 2011, chapter Variation Programming with the Choice Calculus, (GPCE), 2014. pages 55–100. Springer Berlin Heidelberg, Berlin, Heidelberg, 2013. [36] B. Westfechtel, B. P. Munch, and R. Conradi. A layered architecture for [10] J. Favre. Preprocessors from an abstract point of view. In International uniform version management. IEEE Trans. Softw. Eng., 27(12):1111– Conference on Software Maintenance (ICSM), 1996. 1133, Dec. 2001. [11] J. N. Foster, M. B. Greenwald, J. T. Moore, B. C. Pierce, and A. Schmitt. Combinators for Bidirectional Tree Transformations: A Linguistic Approach to the View-update Problem. ACM Trans. on Programming Languages and Systems, 29(3), 2007. [12] B. Gulla, E.-A. Karlsson, and D. Yeh. Change-oriented version descriptions in EPOS. Software Engineering Journal, 6(6):378–386, 1991. [13] W. Hofer, C. Elsner, F. Blendinger, W. Schröder-Preikschat, and D. Lohmann. Toolchain-independent variant management with the leviathan filesystem. In Proceedings of the 2nd International Workshop on Feature-Oriented Software Development (FOSD), 2010. [14] D. Janzen and K. De Volder. Programming with crosscutting effective views. In European Conference on Object-Oriented Programming (ECOOP). 2004. [15] W. Ji, T. Berger, M. Antkiewicz, and K. Czarnecki. Maintaining feature traceability with embedded annotations. In Proc. SPLC, 2015. [16] C. Kästner, S. Trujillo, and S. Apel. Visualizing software product line variabilities in source code. In ViSPLE, 2008. [17] B. W. Kernighan and D. M. Ritchie. The C programming language, volume 78. 1988. [18] V. Kruskal. Managing multi-version programs with an editor. IBM Journal of Research and Development, 28(1):74–81, Jan 1984. [19] V. Kruskal. A blast from the past: Using p-edit for multidimensional editing. In Workshop on Multi-Dimensional Separation of Concerns in Software Engineering, 2000. [20] B. Kullbach and V. Riediger. Folding: an approach to enable program understanding of preprocessed languages. In Proceedings of 8th Working Conference on Reverse Engineering (WCRE), 2001. [21] D. Le, E. Walkingshaw, and M. Erwig. #ifdef confirmed harmful: Pro- moting understandable software variation. In Proceedings of Symposium on Visual Languages and Human Centric Computing (VL/HCC), 2011.