Does SBT make use of fsc?
For test purposes I am compiling a 500-line program on a fairly slow Ubuntu machine (Atom N270). Three successive compile times were 77s, 66s, and 66s.
I then compiled the file with fsc from the command line. Now my times were 80s, 25s, 18s. Better! That implies to me sbt is not using fsc. Am I right? If so, why doesn't it use it?
I may try getting sbt to explicitly use fsc to compile, though I am not sure I will figure out the config. Has anyone done this?
This discussion made me realize I have been using sbt the wrong way.
Instead of (from the command line):
$ sbt compile
$ sbt test
..one should keep sbt running and treat it as the command prompt.
$ sbt
> compile
...
> test
It has the command history and even ability to dive back into OS command line. I wrote this 'answer' for others like me (coming from a Makefile mindset) that might not realize we're taking the pill all wrong. :)
(It's still slow, though.)
SBT cannot benefit from the Fast Scala Compiler when you run it interactively (with or without using its continuous build mode) because the Scala compiler classes are loaded and get "warmed up" and JIT-ed, which is the entirety of fsc's advantage.
At least for SBT 0.7.x the authors explain that it is not as fast as fsc, which caches the compiler instance (including the loaded libraries), rather than just the JITted compiler classes:
http://code.google.com/p/simple-build-tool/wiki/ChangeDetectionAndTesting
My experience also confirms that fsc is faster for full compiles, but does not automatically select what to recompile.
For SBT 0.10, I can find no docs whatsoever on this issue.
You don't need to do it anymore. Sbt has its own way now:
https://github.com/sbt/sbt/wiki/Client-server-split
Related
I installed OpenJDK and then SBT on my Fedora 28 system.
SBT 1.2 comes from the bintray--sbt-rpm repository (the official one).
Both seem to work fine, and I can do basic scala projects.
Then I cloned the chisel-tutorial from the github chisel-tutorial site.
But when I go into the chisel-tutorial directory, SBT refuses to run at all, getting what appears to be an error about the scala version (which is well-nigh incomprehensible to me, but zillions of posts imply that scala version mismatch causes this message):
java.lang.NoSuchMethodError: scala.Predef$.$conforms()Lscala/Predef$$less$colon$less;
My understanding is that sbt is supposed to find the right scala version, but in my case it clearly does NOT.
I have tried dozens of things, some hinted at by posts that refer to the above error message. But they never say exactly what to do, just say something like "your problem is scala version, and that should fix it".
Surely there are chisel users who know the answer, or sbt aficionadoes who do.
Any help would be appreciated!
As per the Scala tutorials, we need to compile the Scala code using scalac filename.scala before executing it using scala filename. But when I tried like scala filename.scala, it runs and got the output.
Why is it so? So compiling using scalac is not required to run the code? Could someone please explain this.
Thanks.
scala -help was really helpful. It says
A file argument will be run as a scala script unless it contains only
self-contained compilation units (classes and objects) and exactly one
runnable main method. In that case the file will be compiled and the
main method invoked. This provides a bridge between scripts and standard
scala source.
Thanks Dennis for the pointer.
running the scala command actually compiles it first behind the scenes, then runs the resulting program.
This behavior is explained in the help for the scala command.
You can get the help by executing the scala -help command.
It's Typesafe Activator 1.2.10 on Windows 7, Scala 2.11.4, sbt 0.13.7. All packages installed using .msi.
When I run activator ui I get error:
Error: Could not find or load main class ui
and nothing happens then.
It appears that you're facing permission-related problems.
I can't give you the exact steps to sort it out (as I'm on Mac OS), but you should be able to work it around by running cmd as Administrator and then executing activator ui again.
There's also the version 1.2.12 so you may have more success with it. You don't need separate installations of Scala and sbt, either, as activator is going to take care of them (that's one of the many reasons to use the tool after all).
I'm a newbie with Clojure and Counterclockwise and I succeeded adding a Leiningen 2 project with "Poor man's integration" (External tools, linked from question Using Clojure and Leiningen with IDEs).
My alternatives for running tests so far:
From command line : lein test
Running "lein test" with "Poor man's integration" (External tool)
These work pretty fine but I'm wondering whether there's some smoother alternative, for example showing the tests run like with JUnit etc?
Or with more general formulation, how to have fluent TDD flow with Counterclockwise?
Another alternative I found (with clojure.test API) was loading the test file in REPL (Alt+Cmd+S) and calling run-tests:
(run-tests)
With some trying, I can re-run the tests with my modifications by loading the modified file to REPL and calling run-tests again. (Works but isn't probably the final solution)
Midje with autotest in REPL seems to be worth checking out.
One way to do this is to use cljunit as an interface between the JUNit runner in Eclipse and your Clojure tests.
I have downloaded a project which uses sbt as its build system and I want to build it. You'd think it would be as simple as typing "sbt" or something, but no.
I thought I'd add a question for this because it can take literally hours to figure this out on your own. I'm not joking.
tl;dr:
sbt compile
If you want to run it:
sbt run
To see what other targets are available:
sbt tasks
To get some (other) help, but mostly targeted at commands typed from the sbt console (ie, running sbt without parameters):
sbt help
This all assumes sbt version >= 0.10.0. To see what version of sbt is in use, do:
grep sbt.version project/build.properties
If there's no such file, and there's a file with extension ".sbt" on the base directory (not the project directory), then it's >= 0.10.0. Of course, if the grep works, it should tell you the version.
First, you'll want to use sbt-extras, because that automatically downloads and uses the right version of sbt. Trying to use the wrong version of sbt (newer or older than what the project you're trying to build says it requires) won't necessarily work, and may cause strange errors.
Run it:
~/path/to/sbt-extras/sbt
Wait for it to start up and download everything. If you need to use an authenticated proxy, you'll need to edit the script to specify the username and password for the proxy.
Check the version of Scala that sbt thinks it needs to build against (at the end of the output, if everything worked). If this is OK, fine, you don't need to do anything. If it isn't, you can temporarily specify a version explicitly with ++, e.g.:
++2.8.1
(If you want to make this permanent, you can edit the build definition files, but as that involves making a change to files under version control, that might not be what you want to do.)
Now, if you are using an older version of sbt, don't skip the next step! You could get strange errors if you do.
update
Now you can build and test what you've built:
test
If you get an error "Filename too long", this is not an sbt-specific problem, it's a scala problem, which most frequently affects Ubuntu users (technically, for Unbuntu users it's generally related to home directories encrypted with encfs). If you are using Scala >= 2.9, edit the build to use the scalac command-line option that allows you to specify a maximum filename length. Otherwise, if you are on Linux, you can redirect the build to /dev/shm or /tmp, by running these commands in a shell prompt (don't background sbt with CTRL+Z on Unix, because it may appear to stop working properly):
rm -rf target
ln -s /dev/shm target
(you may have to execute these commands in project/build instead or as well.)
Actually, it's probably better, and may even be more secure, to create a subdirectory of /dev/shm or /tmp and use that instead.
The compilation result should appear in target. You might then want to run it, if it's something you can run:
run
If everything looks OK, you can optionally publish the result locally so that the result can then be picked up automatically by other sbt builds:
publish-local
I don't think I could explain it better that the Getting Started Guide could. Please read the first 6 parts of it, which shouldn't too long time, to get it up and running.