This document proposes an annotation-based approach to recording finer-grained software evolution using an IDE. Developers can classify their edit operations according to different modes, and the system structures the edits to generate source code deltas for each intentional change. A prototype implementation as an Eclipse plug-in automates reordering edits based on the modes. This approach aims to avoid mixed changesets and better capture the relationships between changes.
Java 8 is one of the largest upgrades to the popular language and framework in over a decade. This talk will detail several new key features of Java 8 that can help make programs easier to read, write, and maintain. Java 8 comes with many features, especially related to collection libraries. We will cover such new features as Lambda Expressions, the Stream API, enhanced interfaces, and more.
Open Problems in Automatically Refactoring Legacy Java Software to use New Fe...Raffi Khatchadourian
Java 8 is one of the largest upgrades to the popular language and framework in over a decade. In this talk, I will first overview several new, key features of Java 8 that can help make programs easier to read, write, and maintain, especially in regards to collections. These features include Lambda Expressions, the Stream API, and enhanced interfaces, many of which help bridge the gap between functional and imperative programming paradigms and allow for succinct concurrency implementations. Next, I will discuss several open issues related to automatically migrating (refactoring) legacy Java software to use such features correctly, efficiently, and as completely as possible. Solving these problems will help developers to maximally understand and adopt these new features thus improving their software.
A Logic Meta-Programming Foundation for Example-Driven Pattern Detection in O...Coen De Roover
Presentation at the Postdoctoral symposium of the 2011 International Conference on Software Maintenance, accompanying the paper
http://soft.vub.ac.be/Publications/2011/vub-soft-tr-11-11.pdf
Multi-dimensional exploration of API usage - ICPC13 - 21-05-13Coen De Roover
Presented at the 21st IEEE International Conference on Program Comprehension (ICPC 2013), San Francisco (USA). Website of the paper: http://softlang.uni-koblenz.de/explore-API-usage/
Specifying function specializations over an arbitrary set of type constraints is a daunting task in C++ as soon as those constraints become more and more complex and/or grow in number. Various idioms are traditionally used to solve this problem: SFINAE or Tag Dispatching for example.
This talk introduces Boost.Dispatch, an infrastructure library that make Tag Dispatching easier to use and maintain by providing a protocol to define Tags and relationship between them, to map an arbitrary set of tags to a given function implementation and to extend said list of specialization in an open, modular way. The main new asset of Boost.Dispatch is the ability to use categorization of function properties and/or architectural information to guide the dispatch in addition to the more traditional use of type properties.
The talk will quickly brushes a picture of what SFINAE, overloading and Tag Dispatching mean in C++ and what are their limitations. We’ll introduce Boost.Dispatch over some examples ranging from simple library design to actual high performance computing code using the library to select best implementation of a function based on non-trivial architecture dependent information. Then we’ll dive into the implementation of the library and try to sketches the upcoming challenges yet to be solved.
Faults and Regression testing - Localizing Failure-Inducing Program Edits Bas...ICSM 2011
Paper: Localizing Failure-Inducing Program Edits Based on Spectrum Information.
Authors: Lingming Zhang, Miryung Kim, Sarfraz Khurshid.
Session: Research Track Session 1: Faults and Regression Testing
HDR Defence - Software Abstractions for Parallel ArchitecturesJoel Falcou
Performing large, intensive or non-trivial computing on array like data
structures is one of the most common task in scientific computing, video game
development and other fields. This matter of fact is backed up by the large number
of tools, languages and libraries to perform such tasks. If we restrict ourselves to
C++ based solutions, more than a dozen such libraries exists from BLAS/LAPACK
C++ binding to template meta-programming based Blitz++ or Eigen.
If all of these libraries provide good performance or good abstraction, none of
them seems to fit the need of so many different user types. Moreover, as parallel
system complexity grows, the need to maintain all those components quickly
become unwieldy. This thesis explores various software design techniques - like
Generative Programming, MetaProgramming and Generic Programming - and their
application to the implementation of various parallel computing libraries in such a
way that abstraction and expressiveness are maximized while efficiency overhead is
minimized.
Java 8 is one of the largest upgrades to the popular language and framework in over a decade. This talk will detail several new key features of Java 8 that can help make programs easier to read, write, and maintain. Java 8 comes with many features, especially related to collection libraries. We will cover such new features as Lambda Expressions, the Stream API, enhanced interfaces, and more.
Open Problems in Automatically Refactoring Legacy Java Software to use New Fe...Raffi Khatchadourian
Java 8 is one of the largest upgrades to the popular language and framework in over a decade. In this talk, I will first overview several new, key features of Java 8 that can help make programs easier to read, write, and maintain, especially in regards to collections. These features include Lambda Expressions, the Stream API, and enhanced interfaces, many of which help bridge the gap between functional and imperative programming paradigms and allow for succinct concurrency implementations. Next, I will discuss several open issues related to automatically migrating (refactoring) legacy Java software to use such features correctly, efficiently, and as completely as possible. Solving these problems will help developers to maximally understand and adopt these new features thus improving their software.
A Logic Meta-Programming Foundation for Example-Driven Pattern Detection in O...Coen De Roover
Presentation at the Postdoctoral symposium of the 2011 International Conference on Software Maintenance, accompanying the paper
http://soft.vub.ac.be/Publications/2011/vub-soft-tr-11-11.pdf
Multi-dimensional exploration of API usage - ICPC13 - 21-05-13Coen De Roover
Presented at the 21st IEEE International Conference on Program Comprehension (ICPC 2013), San Francisco (USA). Website of the paper: http://softlang.uni-koblenz.de/explore-API-usage/
Specifying function specializations over an arbitrary set of type constraints is a daunting task in C++ as soon as those constraints become more and more complex and/or grow in number. Various idioms are traditionally used to solve this problem: SFINAE or Tag Dispatching for example.
This talk introduces Boost.Dispatch, an infrastructure library that make Tag Dispatching easier to use and maintain by providing a protocol to define Tags and relationship between them, to map an arbitrary set of tags to a given function implementation and to extend said list of specialization in an open, modular way. The main new asset of Boost.Dispatch is the ability to use categorization of function properties and/or architectural information to guide the dispatch in addition to the more traditional use of type properties.
The talk will quickly brushes a picture of what SFINAE, overloading and Tag Dispatching mean in C++ and what are their limitations. We’ll introduce Boost.Dispatch over some examples ranging from simple library design to actual high performance computing code using the library to select best implementation of a function based on non-trivial architecture dependent information. Then we’ll dive into the implementation of the library and try to sketches the upcoming challenges yet to be solved.
Faults and Regression testing - Localizing Failure-Inducing Program Edits Bas...ICSM 2011
Paper: Localizing Failure-Inducing Program Edits Based on Spectrum Information.
Authors: Lingming Zhang, Miryung Kim, Sarfraz Khurshid.
Session: Research Track Session 1: Faults and Regression Testing
HDR Defence - Software Abstractions for Parallel ArchitecturesJoel Falcou
Performing large, intensive or non-trivial computing on array like data
structures is one of the most common task in scientific computing, video game
development and other fields. This matter of fact is backed up by the large number
of tools, languages and libraries to perform such tasks. If we restrict ourselves to
C++ based solutions, more than a dozen such libraries exists from BLAS/LAPACK
C++ binding to template meta-programming based Blitz++ or Eigen.
If all of these libraries provide good performance or good abstraction, none of
them seems to fit the need of so many different user types. Moreover, as parallel
system complexity grows, the need to maintain all those components quickly
become unwieldy. This thesis explores various software design techniques - like
Generative Programming, MetaProgramming and Generic Programming - and their
application to the implementation of various parallel computing libraries in such a
way that abstraction and expressiveness are maximized while efficiency overhead is
minimized.
ServiceNow Knowledge11 Advanced Scripting & Debugging LabJohn Roberts
In this advanced hands-on workshop you will work with a variety of debugging tools to troubleshoot client and server scripting. You'll learn how to add error handling and debugging assistance to your scripts. We will review some advanced scripting techniques including server-side script includes extending base classes and AJAX client requests. As we will not be covering basic scripting concepts in this session participants will require some understanding of JavaScript and scripting within ServiceNow.
The presentation from SPbPython meetup about simple self-made just-in-time (JIT) compiler for Python code.
N-th Fibonacci sequence number returning function is JIT-ed in the example.
What makes a good commit message? What makes for good commit contents? I present on how to reword commits to provide context, and structure commit contents to be the most meaningful for posterity with git rebase.
Similar to Recording Finer-Grained Software Evolution with IDE: An Annotation-Based Approach (20)
Recording Finer-Grained Software Evolution with IDE: An Annotation-Based Approach
1. Recording Finer-Grained
Software Evolution
with IDE:
An Annotation-Based Approach
Shinpei Hayashi and
Motoshi Saeki
Dept. of Computer Science,
Tokyo Institute of Technology
Japan
IWPSE-EVOL 2010
2. Abstract
Recording Finer-Grained SE
− Avoiding to commit mixed changesets
Annotation-Based Approach
− Developers perform edit operations of source
code together with classifying them
− Restructuring source code delta
Results: It works well!
− Defined algorithms for automation
− Implemented a prototyping tool
2
4. Background
Task Level Commit [SCM Patterns]
− We should avoid to commit mixed changesets
Why?
− Reuse (e.g. backport): separation required if we
apply a part of a changeset to another branch
− Reverting: extraction needed if we revert a part
of a changeset
− Understanding: the relations are unclear if the
commit log of a changeset describes multiple
changes
4
5. Problems
Mixed changesets occur in practice
− Bug-fix + logging
− Large refactorings (via transitional state)
5
6. Example: bug-fix + logging
int foo() {
int state = ……;
……
state = bar(state, false);
……
}
6
7. Example: bug-fix + logging
int foo() {
int state = ……;
log.trace(”state = ” + state);
……
state = bar(state, false);
log.trace(”state = ” + state);
……
}
1. Insertion of logging function calls (LFCs) +
finding the bug by executing the program and
confirming outputs of LFCs
7
8. Example: bug-fix + logging
int foo() {
int state = ……; false
log.trace(”state = ” + state);
…… true
state = bar(state, true);
log.trace(”state = ” + state);
……
}
1. Insertion of LFCs + finding the bug
2. Fixing the bug
8
9. Example: bug-fix + logging
int foo() {
int state = ……;
log.trace(”state = ” + state);
……
state = bar(state, true);
log.trace(”state = ” + state);
……
}
1. Insertion of LFCs + finding the bug
2. Fixing the bug
3. Execution again for confirming correct output
4. Commit
9
10. Example: bug-fix + logging
int foo() {
int state = ……;
log.trace(”state = ” + state);
……
state = bar(state, true);
log.trace(”state = ” + state);
……
}
Depends
1. Insertion of LFCs + finding the bug each other
2. Fixing the bug
3. Execution again for confirming correct output
4. Commit
Difficult to commit each of them independently in advance 10
11. Example: large refactoring
Involved with basic refactorings
Reverting needed if we commit each of
basic refactorings
revert
commit commit commit
Refactoring 1 Refactoring 2 Refactoring 3
Large refactoring
commit
11
12. Our Solution
Mixed changesets exist in practice
− Bug-fix + logging
− Large refactorings (via transitional state)
Changes should be managed on IDE
− Hypothesis: developers can identify the
timing of switching their editing intentions
12
13. Proposed Approach
Edit + mode changes Modes
1: fixing bug #5
Structuring edits 2: correcting a typo
according to modes 3: Move Method refactoring
: mode changes
time
<<annotate>>
<<edit>>
Developer Structuring
r1: r2: r3:
"fixed bug #5 ..." "refactored ..." “typo ..." Version
Archive
IDE
13
14. Example: bug-fix + logging
int foo() {
int state = ……;
……
state = bar(state, false);
……
}
14
15. Example: bug-fix + logging
int foo() {
int state = ……; Editing
log.trace(”state = ” + state); by mode 1
……
state = bar(state, false);
log.trace(”state = ” + state);
……
}
1. Insertion of logging function calls (LFCs) +
finding the bug by executing the program and
confirming outputs of LFCs
15
16. Example: bug-fix + logging
int foo() {
int state = ……;
log.trace(”state = ” + state); Editing
……
state = bar(state, true);
by mode 2
log.trace(”state = ” + state);
……
}
1. Insertion of LFCs + finding the bug
2. Fixing the bug
16
17. Example: bug-fix + logging
int foo() {
int state = ……;
log.trace(”state = ” + state);
……
state = bar(state, true);
log.trace(”state = ” + state); Committing
…… as revisions
}
1 and 2
1. Insertion of LFCs + finding the bug
2. Fixing the bug
3. Execution again for confirming correct output
4. Commit
17
18. Example: large refactoring
Use individual mode for each refactoring
commit commit commit
By mode 2 By mode 3
Mode 1
Refactoring 1 Refactoring 2 Refactoring 3
Large refactoring
18
19. Automation
Ordering edit operations Modes
1: fixing bug #5
Deciding the group order 2: correcting a typo
3: Move Method refactoring
: mode changes
time
<<annotate>>
<<edit>>
Developer Structuring
r1: r2: r3:
"fixed bug #5 ..." "refactored ..." “typo ..." Version
Archive
IDE
19
20. Automation < <
< <
Ordering edit operations Modes
< < Which orders #5
1: fixing bug
Deciding the patch order
< < are feasible? a typo
2: correcting
3: Move Method refactoring
< <
: mode changes
< < time
<<annotate>>
<<edit>>
Developer Structuring
r1: r2: r3:
"fixed bug #5 ..." "refactored ..." “typo ..." Version
Archive
IDE
20
21. Proposed System
Inputs Outputs
Edit history
(Seq. of
edit operations) Source code
deltas for each
Mode switching intentional changes
information
• when
• which mode
21
22. Edit Operations (EOs)
int foo() {
int state = 1;
return state;
}
A code fragment is added
• to file f
pi = (add, f, 29, 20)
• begins with 29th character
int foo() {
int state = 1; • Its length is 20
log.trace(state);
return state;
}
pj = (add, f, 63, 2)
int foo() {
int state = 1;
log.trace(state);
return state+1;
}
22
23. Commutations of EOs
Modifying the offsets
int foo() {
int state = 1;
of EOs
return state;
}
pi = (add, f, 29, 20) pj' = (add, f, 43, 2)
int foo() { int foo() {
int state = 1; int state = 1;
log.trace(state); return state+1;
return state; }
}
pj = (add, f, 63, 2) pi' = (add, f, 29, 20)
int foo() { int foo() {
int state = 1; int state = 1;
log.trace(state); log.trace(state);
return state+1; return state+1;
} }
23
24. Ordering EOs
Bubble sort based time
on group orders
− E.g. < <
EOs are commutated
when they are swapped
sorting criteria needed
for achieving that
all commutations
succeed
24
25. When Commutations Fail
3 cases
pi pj pi pj pi pj
(a) add; remove (b) add; add (c) remove; remove
25
26. Deciding Group Order
Possible group order: |G|! cases
< < time
< < Impossible
< <
< <
< < Impossible
< < Impossible
Deciding candidates based
on commutability of EOs Impossible
26
27. Tann: Prototype Implementation
ModeManager: As an Eclipse plug-in
Automating the reordering mechanism
OperationRecorder Edit history commute.rb
[Omori 08] (XML)
• Reordering EOs
• Collecting EOs based on modes
ModeManager
• UI of mode switching
• Collecting switch info. Switching
Information
Eclipse
Outputs:
Deltas for each mode 27
32. Pros and Cons
Positive points
− Not depend on programming languages
− Fully-automated (except for classification)
− High affinity to traditional SCMs
(current) Negative points
− Not considering syntaxes/semantics of
programming languages
− Classifications have to be done correctly
32
33. Future Work
Improving maturity of implementation
− Collaborating with UI of underlying SCM
− Warning when the structuring fails
New UI for reclassifying EOs
− Changing the group of past EOs
Other applications
− Large (group-level) undo on IDE
33
34. Background Proposed Approach
Task Level Commit [SCM Patterns]
Edit + mode changes Modes
1: fixing bug #5
− We should avoid to commit mixed changesets Structuring edits 2: correcting a typo
according to modes 3: Move Method refactoring
: mode changes
+
+
- time
-
Revision: 1 <<annotate>>
+
Log: fixed bug #5 diff +
+
-
-
-
Revision: 1 <<edit>>
Revision: 2 +
+
+
-
+
Log: fixed bug #5, Developer Structuring
Log: refactored + refactored, and
diff diff corrected a typo
r1: r2: r3:
+ "fixed bug #5 ..." "refactored ..." “typo ..." Version
-
Archive
Revision: 3 +
- Mixed
Log: corrected a typo IDE
diff changeset
3 13
Deciding Group Order Tann: Prototype Implementation
Possible group order: |G|! cases ModeManager: As an Eclipse plug-in
< < time Automating the reordering mechanism
< < Impossible
OperationRecorder Edit history commute.rb
< < [Omori 08] (XML)
[Omori 08]
•Reordering EOs
< < •Collecting EOs based on modes
< < Impossible
ModeManager
< < Impossible ed
fail •UI of mode switching
Switching
Deciding candidates based •Collecting switch info.
Information
on commutability of EOs Impossible Eclipse
Outputs:
26
Deltas for each mode 27
35. Credits
Photo by tokyofoodcast
http://www.flickr.com/photos/tokyofoodcast/92537891/
35