I just ran some statistics on all 242 projects that make up the complete source code of the Android 2.2 platform. In this experiment I used the CLOC ultility in connection with R64 and GGPlot2. You can find detailed plots for each project here.

Overall, the whole Android platform consists of a little more than 73 Million Lines of Code (73,517,272 to be precise). Here are the Top 242 largest projects:

GemX user interface on Ubuntu 10.04

Instructions

The instructions for compiling the command-line tool are the same as for Ubuntu 9.x, which you can find in this post.

Due to popular demand, I ported the GemX user interface of CCFinder to the latest version of Ubuntu 10.04.

Step 1

Download a copy of the source code and the binary package from MY DROPBOX and unpack it. This will create a folder ccfx-ubuntu.

Step 2

Compile the ccfx-ubuntu/src/GemXLinux project using Eclipse version 3.5 or later.

Step 3

Build the ccfxlib.jar library by running the ccfx-ubuntu/src/GemXLinux/buildGemXjar.sh script.
This will package the .class files and graphic resources created in Step 2 into a java archive and copy it to the correct place.

Step 4

Compile the JNI library ccfx-ubuntu/src/ccfx/CCFinderXLib using the provided Makefile. The makefile will also copy it to the correct place for you.

Step 5

Copy the Eclipse SWT archives form your Eclipse installation: use find /usr -name "*.jar" -print | grep swt to locate and copy org.eclipse.swt.gtk.linux.x86_VERSION.jar to ccfx-ubuntu/bin/jars/swt-gtk.jar and org.eclipse.swt_VERSION.jar to ccfx-ubuntu/bin/jars/swt.jar.

Step 6

Run the CCFinderX User Interface cd ccfx-ubuntu/bin && ./gemx.sh.

Update: “Studying the Impact of Social Structures on Software Quality” wins the Best Paper Award at ICPC’10!

Abstract – Correcting software defects accounts for a significant amount of resources such as time, money and personnel. To be able to focus testing efforts where needed the most, researchers have studied statistical models to predict in which parts of a software future defects are likely to occur. By studying the mathematical relations between predictor variables used in these models, researchers can form an increased understanding of the important connections between development activities and software quality. Predictor variables used in past top-performing models are largely based on file-oriented measures, such as source code and churn metrics. However, source code is the end product of numerous interlaced and collaborative activities carried out by developers. Traces of such activities can be found in the repositories used to manage development efforts. In this paper, we investigate statistical models, to study the impact of social structures between developers and end-users on software quality. These models use predictor variables based on social information mined from the issue tracking and version control repositories of a large open-source software project. The results of our case study are promising and indicate that statistical models based on social information have a similar degree of explanatory power as traditional models. Furthermore, our findings suggest that social information does not substitute, but rather augments traditional product and process-based metrics used in defect prediction models.

Download:

Publisher: IEEE.
Copyright © by IEEE. This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author’s copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

[I AGREE - DOWNLOAD PDF]

Reference:

@inproceedings{bettenburg:icpc2010,
 author={Nicolas Bettenburg and Ahmed E. Hassan},
 booktitle={ICPC '10: Proceedings of the 17th IEEE International Conference on Program Comprehension},
 title={Studying the Impact of Social Structures on Software Quality},
 year={2010},
 pages={to appear},
 publisher={IEEE},
 location={Braga, Portugal}}

Today I accepted an invitation to the Program Committee of the Tool Demo Track for the 18th IEEE International Conference on Program Comprehension (ICPC’10) in Braga, Portugal.

[Visit ICPC 2010 Website to learn more]

Following up on my previous post on “How to compile CCFinder under Ubuntu Linux 9.10″ I worked through the CCFinder code, porting it to 64 bit Mac OS X Snow Leopard. So much fun having non-standard STLs, dynamic frameworks and all these fancy stuffs like python extensions and Java JNI code to get this thing running. However, in the end I managed to get CCFinder running. Mac OS X! 64 Bit! Let the clone detection begin! Here is a screenshot of CCFinder GemX running on its own sources

CCFinderX running on Mac OS X 10.6 Snow Leopard Screenshot

What is CCFinder?
CCFinderX is a code-clone detector, which detects code clones (duplicated code fragments) from source files written in Java, C/C++, COBOL, VB, C#. The new CCFinderX is a major version up of CCFinder, and it has been totally re-designed and re-implemented from scratch. Its new design and technologies aim at improving performance, enabling a user-side customization of a preprocessor, and providing an interactive analysis based on metrics.

Where can I get CCFinderX?
You can download CCFinderX sources and binaries from the official CCFinderX website. However, at the moment of this writing, there are no pre-compiled binaries available. Good new is that you can follow some simple steps to compile the sources yourself.

How to compile CCFinderX
In the following I will describe step-by-step how to compile the CCFinderX under Ubuntu 9.10 Karmic Koala.

Note: Even though the sources are supposed to be used under the 32bit version of Ubuntu, I was able to successfully compile the tool under Ubuntu 9.10 amd64 without modifications of the source files. Ok! Let’s get going!

Step 1: Download the sources
To compile CCFinderX under Ubuntu you need two separate sets of files.

The actual ccfinder sources that contain the clone detection tool, shared libraries and the GUI.
pinky@brain:/sandbox$ wget http://www.ccfinder.net/download/ccfx-src.zip

In addition, Toshihiro Kamiya, the maker of CCFinderX provides additional sources and makefiles for Linux in a second archive.
pinky@brain:/sandbox$ wget http://www.ccfinder.net/download/karmicmakefileetc.7z

Step 2: Install p7zip and unzip source archives
If you have not already install p7zip for Linux you need to do so now by issuing
sudo apt-get install p7zip
Afterwards, we first move the supporting files into a new directory and unpack them:
pinky@brain:/sandbox$ mkdir karmicmakefileetc
pinky@brain:/sandbox$ mv karmicmakefileetc.7z karmicmakefileetc
pinky@brain:/sandbox$ cd karmicmakefileetc
pinky@brain:/sandbox/karmicmakefileetc$ p7zip -d karmicmakefiles.7z

Step 3: Unzip ccfinder sources
The ccfinder sources will unpack into the current directory. We will keep things clean and create a directory first, which we move the source in and unpack them there.
pinky@brain:/sandbox$ mkdir ccfinder-src
pinky@brain:/sandbox$ mv ccfx-src.zip ccfinder-src
pinky@brain:/sandbox$ cd ccfinder-src
pinky@brain:/sandbox/ccfinder-src$ unzip ccfx-src.zip

Step 4: Copy the contents from the support files to the CCFinder source folder
pinky@brain:/sandbox$ for i in karmicmakefileetc/*; do cp -Ru $i ccfinder-src/; done

Step 5: Install development tools and required libraries
If you haven’t installed the glibc and C++ compiler yet, do so by issuing
pinky@brain:/sandbox$ sudo apt-get install build-essential
CCFinderX makes extensive use of the boost-libraries, so we need to install them first.
pinky@brain:/sandbox$ sudo apt-get install libboost-dev

Step 6: Compile the ccfx binary
pinky@brain:/sandbox$ cd ccfinder-src/ccfx
pinky@brain:/sandbox/ccfinder-src/ccfx$ mv karmic.mk Makefile
pinky@brain:/sandbox/ccfinder-src/ccfx$ make
This will produce numerous warnings that we ignore for now.

Step 7: Compile the picosel module
CCFinderX uses various modules and additional tools to work. The first one is the picosel module.
pinky@brain:/sandbox$ cd ccfinder-src/picosel
pinky@brain:/sandbox/ccfinder-src/picosel$ mv karmic.mk Makefile
pinky@brain:/sandbox/ccfinder-src/picosel$ make
Again we will ignore the warnings.

Step 8: Compile the pyeasytorq module
pinky@brain:/sandbox$ cd ccfinder-src/torq/pyeasytorq
pinky@brain:/sandbox/ccfinder-src/torq/pyeasytorq$ mv karmic.mk Makefile
pinky@brain:/sandbox/ccfinder-src/torq/pyeasytorq$ vim Makefile
There we need to append the -fPIC parameter to the gcc compiler opts to make this work. After adding this
parameter the OPTS line should now read:
OPTS = -O2 -fpermissive -fPIC -I/usr/include/python2.6/
Now we can compile the module (ignore the warnings):
pinky@brain:/sandbox/ccfinder-src/torq/pyeasytorq$ make

Step 9: Compile the picoselib module
We will first need to install the open java 6 jdk if it is not already installed:
pinky@brain:/sandbox$ sudo apt-get install openjdk-6-jdk
Then we prepare the makefile for picoselib.
pinky@brain:/sandbox$ cd ccfinder-src/utility/picoselib
pinky@brain:/sandbox/ccfinder-src/utility/picoselib$ mv karmic.mk Makefile
pinky@brain:/sandbox/ccfinder-src/utility/picoselib$ vim Makefile
Again we need to append the -fPIC parameter to the compiler flags, add it to
the OPTS line, which afterwards should read:
OPTS = -O2 -fpermissive -fPIC -I/usr/lib/jvm/java-6-openjdk/include/
Save the makefile and start compilation (ignore warnings):
pinky@brain:/sandbox/ccfinder-src/utility/picoselib$ make

Step 10: Compile the CCFinderXLib module
pinky@brain:/sandbox$ cd ccfinder-src/ccfx/CCFinderXLib
pinky@brain:/sandbox/ccfinder-src/ccfx/CCFinderXLib$ mv karmic.mk Makefile
pinky@brain:/sandbox/ccfinder-src/ccfx/CCFinderXLib$ vim Makefile
Again append the -fPIC parameter to the compiler flags similar to step 8 and step 9.
Then we compile the code
pinky@brain:/sandbox/ccfinder-src/ccfx/CCFinderXLib$ make

Step 11: Test the installation
If everything worked out without errors, you should find the ccfx binary and all required modules
in the ubuntu32 directory. We run a short test to see if CCFinderX works as expected.
pinky@brain:/sandbox/ubuntu32$ ./ccfx d cpp ../ccfinder-src/ccfx/rawclonepairdata.cpp
pinky@brain:/sandbox/ubuntu32$ ./ccfx p a.ccfxd

The console output should read:
version: ccfx 10.2.7
format: pair_diploid
option: -b 50
option: -s 2
option: -u +
option: -t 12
option: -w f+g+w+
option: -j +
option: -k 60m
option: -preprocessed_file_postfix .cpp.2_0_0_2.default.ccfxprep
option: -pp +
preprocess_script: cpp
source_files {
1 ../../ubuntu_9_10/ccfx/rawclonepairdata.cpp 249
}
source_file_remarks {
}
clone_pairs {
}
clone_set_remarks {
}

Congratulations! You successfully compiled CCFinderX for Ubuntu 9.10!

Abstract – A widely shared belief in the software engineering community is that stack traces are much sought after by developers to support them in debugging. But limited empirical evidence is available to confirm the value of stack traces to developers. In this paper, we seek to provide such evidence by conducting an empirical study on the usage of stack traces by developers from the ECLIPSE project. Our results provide strong evidence to this effect and also throws light on some of the patterns in bug fixing using stack traces. We expect the findings of our study to further emphasize the importance of adding stack traces to bug reports and that in the future, software vendors will provide more support in their products to help general users make such information available when filing bug reports.

Download:

Publisher: IEEE.
Copyright © by IEEE. This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author’s copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

[I AGREE - DOWNLOAD PDF]

Reference:

@inproceedings{schroeter:msr2010,
 author = {Adrian Schr\"{o}ter and Nicolas Bettenburg and Rahul Premraj},
 title = {Do Stacktraces help Developers Fix Bugs?},
 booktitle = {MSR '10: Proceedings of the 2010 International Working Conference on Mining Software Repositories},
 year = {2010},
 pages = {118--122},
 location = {Cape Town, South Africa},
 publisher = {IEEE}}

Abstract – Development mailing lists play a central role in facilitating communication in open source projects. Since these lists frequently host design and project discussions, knowledgeable contribution to these discussion threads is essential to avoid mis- communication that might slow down the progress of a project. However, given the sheer volume of emails on these lists, it is easy to miss important discussions. To find out how developers are able to deal with mailing list discussions, we study the main factors that encourage developers to contribute to the development mailing lists. We develop personalized models to automatically identify discussion threads that a developer would contribute to based on his previous contribution behavior. Case studies on development mailing lists of three open source projects (Apache, PostgreSQL and Python) show that the average accuracy of our models is 85–89% and that the models vary significantly between different developers.

Download:

Publisher: IEEE.
Copyright © by IEEE. This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author’s copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

[I AGREE - DOWNLOAD PDF]

Reference:

@inproceedings{ibrahim:msr2010,
 author = {Walid M. Ibrahim and Nicolas Bettenburg and Emad Shihab and Bram Adams and Ahmed E. Hassan},
 title = {Should I contribute to this discussion?},
 booktitle = {MSR '10: Proceedings of the 2010 International Working Conference on Mining Software Repositories},
 year = {2010},
 pages = {181--191},
 location = {Cape Town, South Africa},
 publisher = {IEEE}}

Not strictly research-related, but in case you didn’t already know: the 2010 Olympic Winter Games are hosted by Canada! Here is an overview of the current medal count to keep you up to date while working on one of the many paper deadlines this winter.