[Soot-list] Fwd: [Soot] Your organization application has been rejected.
Patrick Lam
plam at sable.mcgill.ca
Fri Apr 12 21:49:30 EDT 2013
So the problem is one of incentives. I had this discussion recently
about research infrastructure. It is not usually helpful for graduate
students to work on Soot unless there is some research benefit to them.
Now, if there was some company that was involved in funding work on
Soot, we could leverage that by getting lots of Canadian government
money. Do you know of any companies that could help?
pat
On 12/04/13 09:11 PM, Marc-André Laverdière-Papineau wrote:
> Hello,
>
> Thanks for being open and direct. Personally, I think that one of the
> things we need to consider is 'industrializing' the project.
>
> You can tell that I am an industry guy :)
>
> Of course, we need to keep Soot as a fun place for people to do their
> research projects. So keeping things easy to extend and prototype is
> essential.
>
> Adding to what you said:
> 1. I agree. We should modularize and ideally mavenize the components.
> People who want to use the whole thing could still fetch all the
> dependencies at once. And once we have modules, it is easy to mention
> which ones are deprecated, which ones are unmaintained, etc.
> I think it could help people get involved as maintainers.
> Right now, Eric is the super-maintainer - sort of a big role. We could
> end up with maintainers for various modules.
>
> 2. I am not sure I am 'getting' this point. Is it to do something like
> the InterproceduralCFG for both Jimple and Shimple that you have in
> mind? What about Coffi? Are there other IRs we need to deal with?
>
> 3. I had the same idea. I have discussed with Bernhard who is doing some
> measurements for his very very big projects.
>
> 4. The PTA information is not very easy to use, I agree. Some serious
> thinking about what requirements we have as a community should be the
> first step. Maybe we could put that on the schedule for SOAP?
>
> And my opinion:
> 1. I think that better support for parallelization and thread-safety is
> very important. I am writing some code in Scala and sometimes I have to
> downgrade to sequential because some data structures don't accommodate
> concurrent access. I think we could get some speedups for the body
> transformers. Parallelizing Spark is sort of a holy grail though.
>
> 2. Switching to real logging. Personally, I'd like to trash all the
> G.v().out and migrate to SLF4J. Probably the easiest project in the list.
>
> 3. Deprecating plenty of the interfaces. There is a lot of getNumXYZ and
> getXYZ(i) and the collections API should be used instead.
>
> 4. This one would be a very invasive change: should we migrate from
> singletons to another design?
>
> 5. Scala rocks. Lets port as much as we can to Scala and use immutable
> data structures, monads, lamdas, etc.
>
> /me ducks for cover for the upcoming flame war
>
> Finally, I'd like it if we, as a community, were to organize ourselves
> more along the lines of other FLOSS projects and adopt a roadmap.
>
>
>
> Marc-André Laverdière-Papineau
> Doctorant - PhD Candidate
>
> On 13-04-10 04:23 AM, Richard Xiao wrote:
>> Hi, Eric and Elena:
>>
>> After my recent experience on soot, I think adding more functions to
>> soot is not the first priority. I feel that it's time to check and
>> refactor the current code base:
>>
>> 1. More and more people report problems for components that are
>> untouched for a long time, such as the recent reported InfoFlows. For
>> those components working improperly, we should fix them or move it out
>> of soot to be an optional package, just like and paddle and heros does.
>>
>> 2. Most analysis and optimization algorithms written for jimple, shimple
>> is lacking of support for a long time and it is unknown the existing
>> analysis and optimization algorithms can work correctly on shimple. To
>> attract more users doing experiments with soot, I think it is useful to
>> refactor the code to add an abstract layer to model different program
>> representations. Then, we let the analysis and optimization algorithms
>> work on the abstract layer to serve all supported IRs.
>>
>> 3. Improve the performance of soot. Analyzing software with higher JDK
>> (1.5 or above) consumes significant time and memory, especially for the
>> points-to packages spark and paddle (even we use BDD). In my memory,
>> there are many inefficient use of data structures. For example, the
>> bit-vector for points-to information is not sparse bit-vector. Although
>> it is expanded on demand, we still waste lots of space for empty bits.
>> Moreover, it also wastes lot of memory if we use it for storing
>> side-effect information.
>>
>> 4. New query interfaces should be added to give users more ways to
>> access information. The typical example is the points-to information.
>> Using the "forAll" function to visit the points-to vector is not
>> efficient because first, we have to create a visitor object and pass it
>> to "forAll". Second, sometimes we only search for particular object, the
>> "forAll" function forces us to visit all objects and it is not easy to
>> terminate the visit process earlier. Therefore, it is more convenient to
>> provide a "iterator" way to access the points-to vector. Another problem
>> is that the "is alias" query is not defined in the standard query
>> interface. Therefore, users have to write different code for
>> experimenting with different points-to packages, which increases the
>> burden for users to study the internal design of these packages.
>>
>> These are only my personal opinions for the GSOC project. Hopefully we
>> can have a discussion on these issues.
>>
>>
>> Best Regards,
>> Xiao
>>
>>
>> On Wed, Apr 10, 2013 at 7:13 AM, Elena Sherman
>> <elenasherman at boisestate.edu<mailto:elenasherman at boisestate.edu>> wrote:
>>
>> Yeah, but it is very competitive. Can try next year again,
>> hopefully, with more preparation and feedback.
>> I will try to participate in the IRC if I figure out how to use it
>> and correctly translate 16:00 UTC to my time zone.
>>
>> Elena
>>
>>
>> On Tue, Apr 9, 2013 at 12:48 AM, Eric Bodden
>> <eric.bodden at sit.fraunhofer.de
>> <mailto:eric.bodden at sit.fraunhofer.de>> wrote:
>>
>> Hi all.
>>
>> I am afraid that GSOC rejected our application for this year.
>> Too bad.
>> Is anyone interested in participating in the IRC chat mentioned
>> below?
>>
>> Eric
>>
>>
>> ---------- Forwarded message ----------
>> From:<no-reply at google-melange.appspotmail.com
>> <mailto:no-reply at google-melange.appspotmail.com>>
>> Date: 8 April 2013 20:42
>> Subject: [Soot] Your organization application has been rejected.
>> To: eric.bodden at gmail.com<mailto:eric.bodden at gmail.com>
>>
>>
>> Thank you for submitting "Soot" organization application to Google
>> Summer of Code 2013. Unfortunately, we were unable to accept your
>> organization's application at this time. Every year we receive many
>> more applications than we are able to accommodate, and we would
>> encourage you to reapply for future instances of the program.
>>
>> If you would like some general feedback on why your organization was
>> not accepted, please consider attending the IRC meeting in #gsoc on
>> Freenode on Friday, April 19, 2013 at 16:00 UTC.
>>
>> Best regards,
>>
>> Google Open Source Programs
>>
>>
>> --
>> Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
>> Head of Secure Software Engineering Group at EC SPRIDE
>> Tel: +49 6151 16-75422<tel:%2B49%206151%2016-75422> Fax: +49
>> 6151 16-72051<tel:%2B49%206151%2016-72051>
>> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca<mailto:Soot-list at sable.mcgill.ca>
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
>>
>>
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca<mailto:Soot-list at sable.mcgill.ca>
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
>>
>>
>>
>> --
>> Richard Xiao Xiao
>> PhD Student @ CSE @ Hong Kong University of Science and Technology
>> www.cse.ust.hk/~richardxx<http://www.cse.ust.hk/~richardxx>
>>
>>
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
More information about the Soot-list
mailing list