During the next fee days I will be enjoying FSE in Atlanta, where for some weird reason everything is called Peachtree <whatever>. I guess that must be an American thing. In Canada they don’t do that: if you search for a “Maple Road” in Montreal, where do you land? Wisconsin! Point proven 🙂
At FSE, I’ll be presenting our latest breed on static verification using tracematches. Who knows – maybe I’ll see you there?
Yes, I guess it’s time to put my suit on… As I am planning to graduate (with Ph.D.) in summer 2009, I am currently looking out for interesting jobs, both in academia and industry. So if you have an interesting opening in some German or English speaking part of Europe, please let me know. All my application material (Resume, CV, Research and Teaching Statement) are available on my hiring website. To find out more about my research have a look here or browse my research block.
After my last tutorials on using Soot on the command line, and using the Soot Eclipse plugin, this is the third of a series of blog posts about frequently asked questions with using Soot. Today’s topic will be on extending Soot with your own intra-procedural data-flow analysis.
After my last tutorial on using Soot on the command line, this is the second of a series of blog posts about frequently asked questions with using Soot. Today’s topic will be on Soot’s eclipse plugin.
This is the first of what will be a series of blog posts about frequently asked questions with using Soot. I will try to cover different topics like using Soot from the command line, as a framework and in form of its Eclipse plug-in. This is basically a user-friendly digested version of all the fabulous Soot tutorials that we have online already. Today’s topic will be on Soot’s command line and phase options.
Update: Submission is now closed. Thank you very much for your contributions.
Planning to attend OOPSLA? You have still two days to submit to the affiliated Workshop on Virtual Machines and Intermediate Languages for emerging modularization mechanisms. We are looking forward to your contributions!
Did you ever have to program? Did you ever suffer from having to program in a programming language that you did not like? Why not make your own language? Sign up for COMP 520 and we will show you how.
This is a small recap of ISSTA 2008. It’s a little belated but I thought better late than never.
On Sunday I attended Defects’08 which was the first (!) International Workshop on Defects in Large Software Systems. The group of people was kind of interesting in the sense that I knew nobody in person when I got there. The primary may have been that there is a subtle difference between detecting software “defects” (which they focus on) and “API violations” (which I focus on): When looking for program points where API specifications are violated then your are given a specification. Therefore any usage of the API that does not conform with that specification is –by definition– an error, even if nothing bad actually happens.
And yes, we have yet another publication. This one has been accepted at BCS 2008. The conference promises to be an interesting event, as the British Computer Society managed to line up seven Turing Award winners to give keynote talks. Laurie Hendren, my supervisor, will be an invited speaker. Very unfortunately, I don’t think that I will be able to attend. So in case you go there, good for you and please try to speak with Patrick Lam instead, who will presenting the paper.
Anyway, so what are Object Representatives all about? Object Representatives are a sometimes very useful, uniform static abstraction of runtime objects that we came up with when evaluating tracematches ahead-of-time. At compile time, an Object Representative (OR) is just a plain old Java object that implements the interface below.
I am happy to announce the final version of our new FSE paper (joint work with Patrick Lam and my supervisor Laurie Hendren). You can grab the paper here. The idea of the paper is that runtime monitoring is nice because it manages to show you only actual errors, but nevertheless one should make a best effort to evaluate a runtime monitor ahead-of-time, i.e. at compile-time, as well as possible, so that programmers can find errors in the programs earlier in the development process.
