Closed f4z3r closed 5 years ago
DeepCode analyzed this pull request. There are no new issues.
Just so you have an idea of the change, I ran the docker from current master on this project. This ran for 2m46s. I then ran the docker from this branch with precompiled Datalog binaries, and it ran for only 49s. Both were run without the truffle flag.
There seems to be a lot of boilerplate code that can be removed, such as the instruction count computation, the logging of the thresholds, the Soufflé installation check (souffle
is not actually required at runtime anymore), etc. Should I take care of this?
There seems to be a lot of boilerplate code that can be removed, such as the instruction count computation, the logging of the thresholds, the Soufflé installation check (
souffle
is not actually required at runtime anymore), etc. Should I take care of this?
In a follow-up PR if you want, sure!
@jakobbeckmann can you look at the last commit, and see whether that's good enough for you? I quickly tested, it seems to work.
The main drawback is that now, running java -jar build/libs/securify.jar
won't work without build/mayImplicit
etc.
@hiqua Well technically you will build build/mayImplicit
etc. in order to get the .jar
file. So as soon as you can launch the .jar
file, the Datalog binaries should exist, unless you actually copy paste the .jar
file somewhere or manually compile the Java code. Is that really a problem/do you expect people to do this in real life?
Other than that, everything seems fine and works.
There seems to be a lot of boilerplate code that can be removed, such as the instruction count computation, the logging of the thresholds, the Soufflé installation check (
souffle
is not actually required at runtime anymore), etc. Should I take care of this?In a follow-up PR if you want, sure!
I'll work on it at some point towards the end of this week.
@hiqua Well technically you will build
build/mayImplicit
etc. in order to get the.jar
file. So as soon as you can launch the.jar
file, the Datalog binaries should exist, unless you actually copy paste the.jar
file somewhere or manually compile the Java code. Is that really a problem/do you expect people to do this in real life?
Yes this is what I meant, being able to copy-paste the .jar around is nice, and we actually do that on the webserver, although we can obviously adapt and also copy the compilation output / build and use the docker image instead.
Builds Soufflé executables at build time of the docker image. Fixes #46