[Soot-list] Fwd: [Soot] Your organization application has been rejected.

Patrick Lam plam at sable.mcgill.ca
Sat Apr 13 14:45:33 EDT 2013 

It's also a question of who we'd be more likely to get usable work out 
of. Coordination cost is high, and often exceeds what you can actually 
get out of a undergrad project, in my experience.

Undergrads around Waterloo are also expensive, because they can make a 
large amount of money on their co-op terms. The usual NSERC undergrad 
project requires $1200 of faculty money and NSERC throws in $4500. But 
that really doesn't compare well to what undergrads make in industry. I 
think it's like a third of what they make.

More specifically, there are a bunch of Canadian grants which require 
some company to sign on eventually, but to start, just some 
collaborative project is sufficient: it is possible to get NSERC money 
without an industry monetary contribution (through the Engage program), 
only time. So the first thing to do would be to talk to someone at a 
company and get interest. It's not so useful to name companies in 
general, usually it helps to have a specific connection. After getting 
an Engage grant, future monetary contributions might work too, and they 
can be leveraged. In fact, I don't see any reason to wait for you to 
finish your PhD---what's the status of this company?

Probably in terms of Soot the best thing to do would be to propose some 
research and have infrastructure as a side effect. I think that's more 
likely to produce good results than hiring people specifically to work 
on Soot.

pat

On 04/13/13 10:43, Marc-André Laverdière-Papineau wrote:
> Hi Patrick,
>
> Good point. We who have theses to write are measured by the yardstick of
> publications, and most maintenance activity won't give any.
>
> So we're left with non-theses folks: industry/govt, interns, and
> possibly Bachelors' final projects or honors projects (did I get the
> terminology right?)
>
> Lets get brainstorming!!!
>
> 1) Industry/govt
> The #1 supporter I can think of is IBM. Too bad that they're the only
> real competitor around. :(
>
> I hope that, once the PhD is over, my company will see a vested interest
> in developing Soot further, but that's not helping in the short term, as
> I got 2+ years to go... That being said, if we can put together an
> interesting proposal, maybe I can get this process accelerated.
>
> Some players working on privacy could see an interest in this. I can
> think of Nortel (now tanked), Zeroknowledge's enterprise division. Maybe
> SAP too.
>
> I can think of Defense R&D Canada as a potential partner. They funded my
> masters' project on code analysis.
>
> 2) Interns
> I know that, at my college, we hire summer interns with NSERC funding
> most of their salaries. The Canadian government also has a program for
> funding interns that presumably wouldn't fall in the NSERC category. But
> we still need a bit of cash to give them.
>
> So we can keep on applying for GSoC, but maybe we can try to pull the
> strings we have in our geographies?
>
> 3) Final projects
> Maybe the only option that doesn't require us to have funding, but it
> sort of 'requires' soot users to be teaching, so that they can connect
> with the students.
>
> Anybody else wants to join the brainstorm?
>
> Regards,
>
>
> Marc-André Laverdière-Papineau
> Doctorant - PhD Candidate
>
> On 13-04-12 09:49 PM, Patrick Lam wrote:
>> 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
>>
>> _______________________________________________
>> 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