Is there any performance penalty when running a scala program with sbt run instead of using sbt assembly and creating an executable jar?
Yes, there is. In the worst case, sbt will have to compile your project before running it.
Regardless of compilation, sbt runs the program after forking. That incurs overhead as well.
Related
I'm tyring to find a better method to run my SBT project with continuous build (compile) and run, SBT can already do continuous compile and test but not with the run command unless I'm not aware how that is possible.
I tried using the ~ command on run but it does nothing
sbt clean compile ~run
I tried using the spray sbt plugin
addSbtPlugin("io.spray" % "sbt-revolver" % "0.9.1")
but it is so tempremental and hangs a lot while trying to kill the current process making it faster to just kill the app then run sbt clean compile run
Is there a way to achieve this?
sbt clean ~run should work fine and rerun main method every time you change the sources. But if you're running a web server which is supposed to run continuously, sbt won't interrupt it to rerun.
So you should use sbt-revolver for that and solve any problems with it by either asking another question or submitting a bug report for the plugin.
I was wondering if anyone could recommend best practise for SBT builds using Bamboo. I see that is a Bamboo plugin for SBT however it is a) unsupported and b) isn't compatible with later versions of Bamboo. This combination would almost certainly be a blocker for us as using it could lead to a position where we couldn't take a Bamboo update (potentially fixing a security issue) because it would break all of our SBT builds.
Presumably you can just set up Bamboo to build SBT projects as a script task but I'm a bit worried about the experience here as it's not clear to me how things like failing tests and code coverage will be represented.
Is it possible to have a reasonably slick SBT and Bamboo setup without using the plugin or is Bamboo not a suitable CI system to use with SBT?
We do heavily rely on bamboo in our sbt workflows. The plugin works fine but the only benefit over a short inline script is the parsing of tests which is also available as another task.
We love having some portable build scripts in the projects which can be also used by bamboo.
So here is the starter guide:
have a good portable build script in your project (presumably bash script)
call this script in an inline script in bamboo (so you can do some other stuff as well, e.g. checkout submodules, choosing docker host, ...)
I've cross compiled Qt and created SD card image and mounted using losetup. Compiation is much faster now compared to direct sshfs mount. Application runs OK. Now, I want to debug which is dead slow and it appears like it is copying the files back to the dev machine for debugging. I see this suggestion:
File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
I'm using gdb-multiarch and have got gdbserver (on target board).
I'm kind of lost here. Where to set this option? I've supplied --sysroot argument to the binary but no use. Any help is really appreciated.
Update: using Qt Creator for the development.
sysroot is a gdb setting. You can set it in gdb with the set sysroot command. For example:
(gdb) help set sysroot
Set an alternate system root.
The system root is used to load absolute shared library symbol files.
For other (relative) files, you can add directories using
`set solib-search-path'.
This setting controls how gdb tries to find various files it needs, and in particular the executable and shared libraries that you are debugging.
Recent versions of gdb default sysroot to target:, which means "fetch the files from the target". If you're debugging locally, this is just local filesystem access; but if you are debugging remotely and have a slow connection, this can be a bit painful. In order to make this faster, the idea is to keep a local copy of all the files you'll need, and then use set sysroot to point gdb at this local copy.
The main issue with this approach is that if your local copy is out of sync with the remote, you can end up confusing gdb and getting nonsense results. I am not certain but maybe enabling build-ids alleviates this problem somewhat (certainly in theory gdb can detect build-id mismatches and warn, I just don't recall whether it actually does).
As Tom Tromey suggested adding set sysroot {my sysroot local path} as a starting command in the debugger has worked for me.
I am using iarbuild in command line to build my projects on a 8-core PC. The build speed is quite slow and it smells the multicore PC's is not fully utilized. Is there a build option that can make the build running in parallel mode? (Like in GNU make, there is a -j option)
I had an email from IAR last week
New version of IAR Embedded Workbench for ARM
Version 7.40 is now available
• Parallel build
The compiler can now run in several parallel processes to better use the available processor cores in the PC. To control parallel build, choose Tools>Options>Project>Enable parallel build.
I believe that this is also becoming available for other targets as I have seen similar for the MSP430.
SBT keeps running out of memory on some of my bigger acceptance style tests using specs2 and spray-testkit. I have 10 gigs or RAM available and currently I start SBT (using the SBT extras script) with MaxPermSize at 512m, Xms at 1024m and Xmx at 2g.
The acceptance test runs through a client's entire business process in specific sequence, so it's not easy to split the acceptance test in to multiple smaller tests.
Any ideas how I can configure my environment better, or gotcha's that I should look out for will be appreciated.
For what it's worth, I'm using Oracle Java under Ubuntu, and the project uses Scala 2.10, sbt 0.12.2, spray 1.1-M7 with specs2 1.14.
When running the system outside of test, or when using smaller tests, everything runs like clockwork. It's only during larger tests that things go nutty.
One thing you can do is to fork your tests, you can set your memory settings in the build.sbt directly:
fork in Test := true
javaOptions in Test += "-Xmx2048m" // we need lots of heap space
This means that the tests don't depend on you running with the SBT extras script, and the settings don't affect sbt itself. You can also set various other options (see Forking), including changing the working directory, and even the JRE to use.
I suspect you're hitting the exponential problem with the specs2 immutable style. The solution is simply to add more memory or bust your tests up into smaller chunks. More info is here:
http://www.artima.com/articles/compile_time.html