[Soot-list] summary of 2013 SOAP workshop discussions

[Patrick Lam]

Whoops, was in Vancouver at a judo tournament, so my reply is delayed.

On 07/04/2013 12:31 PM, Bodden, Eric wrote:
>> (A) I looked at the webpage and it is showing its age.
>> There was some discussion at the workshop about hosting
>> the main Soot webpage on github. Thoughts?
>
> I would very much support this move. In fact I already though of hiring a student assistant to take care of this and to also help polish the build and release process and its documentation. Does that sound like a good plan?

Sounds great to me.

>> (B) With Soot's use of github, it is now easier to maintain separate
>> Soot branches and to push contributions to the main branch (we merge
>> patches quickly!)
>>   * Soot extensions, though, are still hard to list; we should
>>     at least keep a page with links to extension project pages
>>     and descriptions thereof.
>
> Right. Github does show forks of Soot but they come without any deeper semantics. I think a list would be great. Maybe we should have a brief intro on how to extend Soot, and how to contribute back and/or list extensions on this page.

Indeed. It probably makes sense to do this once we have a new webpage.

>> (C) Documentation is always difficult. There are some resources,
>> but they can be overwhelming to the new user. There was discussion
>> of wiki-style documentation, but I'm not convinced that it would help;
>> wikis are no panacea. Making it easy to submit documentation patches
>> could help.
>
> One could use the Markdown language that Github supports (the one that also makes up the README). That would allow users to easily update it through pull requests.

Markdown is pretty popular these days. But there are at least two levels 
of answers to this question: 1) Javadoc-style doc comments (which would 
be good to encourage patches to! perhaps we can have Soot Doc Hack Day 
or something) and 2) longer-form tutorial-style documents, which could 
well be in Markdown. It would be good for these documents to be easily 
maintainable.

>> Some specific points:
>>   * A list of Soot features/nonfeatures would be useful to those who
>>     are trying to figure out whether Soot would work for them or not.
>>   * IdentityStmt is confusing to many new Soot users, and a blog
>>     post would help a lot.
>>   * New users are sometimes confused about how to send questions
>>     to the Soot community, so there should be an explicit statement
>>     about that somewhere.
>
> I like all of those points. Any volunteers?

Anyone?

Can we also have issues opened for these? That would be a good first step.

>> ** Soot development requests **
>>   * Update links to PLDI03 tutorial: done
>>   * Probably overdue for a minor release.
>
> I would volunteer for that some time this summer, assuming that others help fixing open bugs.

Thanks!

>>   * Write a Jimple verification pass that checks that
>>      IdentityStmts are the first things in a method.
>
> I thought we had done that!?

Yes, JimpleBody.validateIdentityStatements() does this. Not sure why 
people aren't tripping it.

>>   * Write a Jimple verification pass that checks for
>>      accesses to uninitialized fields in constructors.
>>   * Jimple/source code links are popular as always;
>>      we should use the scope attribute with use-original-names.
>
> What do you mean with "scope attribute"?

I don't know about this firsthand, but it seems like Java bytecode says 
something about scopes in the Java source code, and we could leverage 
that to assign more accurate names.

> I was wondering whether we should add a simple getLine() method or so to Unit, which would automatically find he right tags etc. Does that sound like a good idea?

Yes, that seems like it would help a lot, as long as we can get it to 
work well by default.

>>   * Java 7 question: at the bytecode level, the only change was
>>     invokedynamic, which Soot supports; at the source code level,
>>     there are a couple of new constructs, which would be a good
>>     student project.
>
> Right. We would only need to bind to the new JastAdd version, which already supports those features in general but does not yet convert them to Jimple AFAIK. It might be simpler than we think.

Should be easy, if someone has time.

>> ** Discussion topics that we didn't get to **
>>
>>   * how to do instrumentation and monitoring using Soot;
>
> We will have an RV tutorial on that! Please attend! (There will be a paper version, too.)

Sounds good!

>>   * BDDs and sets
>
> ?

Phil Pratt-Szeliga was wondering about how to use BDDs to represent sets.

pat