[Soot-list] [Soot] Your organization application has been rejected.
Bodden, Eric
eric.bodden at sit.fraunhofer.de
Fri Apr 19 05:50:38 EDT 2013
Hi all.
Thanks for raising the discussion; I am just seeing this thread now. I think some support by industry would be great but this is hard to find. I have recently joined Fraunhofer SIT, which will hopefully allow me to develop Soot and Heros further such that they can be used in an industrial context. That way, while there will be no direct funding for Soot through this channel (in terms of money) I expect there to be some improvements in terms of manpower (and industry would be funding the development indirectly through projects). Nevertheless, if someone could come up with additional ideas that would be great!
Eric
On 14.04.2013, at 06:39, Richard Xiao <richardxx at cse.ust.hk> wrote:
> Hi Marc:
>
> I also agree to your following up suggestions for soot improvement. The abstract IR in my mention does not include Coffi and Baf, because most of the optimizations operate on Jimple and Shimple. I don't know any tool that can easily support IR research, i.e. analysis and optimizations can be shared and specialized between IRs. Therefore, I wonder if soot can be the first to become a ideal IR experimental field.
>
> For the industry endeavor, I agree to Patrick, it's really hard to be funded by commercial company or find students to work solely on the engineering without research benefits. My primary aim to propose these ideas because I think the architecture, performance and interface problems are getting serious and they are really big issues for Soot right now. Hopefully, our active soot users can contribute to Soot, i.e. each of us takes charge of one part.
>
> Cheers,
> Xiao
>
>
> On Sun, Apr 14, 2013 at 2:45 AM, Patrick Lam <plam at sable.mcgill.ca> wrote:
> 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
>
> _______________________________________________
> Soot-list mailing list
> 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
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
--
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 Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
More information about the Soot-list
mailing list