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).
Related
I've been working on a small set of command line programs in Scala. While
developing I used SBT, and tested the program with run within the console. At
this point the programs had a fast startup time (when re-run after initial compilation); nearly instant, even
with additional dependencies.
Now that I'm trying to actually utilize them on my system outside of sbt, the speeds have noticeable lag. I'm looking for ways to
reduce this, since the nature of these utilities requires little to no delay.
The best speeds I've achieved so far has been through utilizing Drip. I include all dependencies in a lib directory by utilizing Pack and then run by executing a shell script like this:
#!/bin/sh
SCRIPT=$(readlink -f "$0")
SCRIPT_PATH=$(dirname "$SCRIPT")
PROG_HOME=`cd "$SCRIPT_PATH/../" && pwd`
CLASSPATH_SUFFIX=""
# Path separator used in EXTRA_CLASSPATH
PSEP=":"
exec drip \
-cp "${PROG_HOME}/lib/*${CLASSPATH_SUFFIX}" \ # Add lib directory to classpath
TagWorkspace "$#" # TagWorkspace is the main class
This is still noticeably slower then invoking run from within SBT.
I'm curious as to why SBT is able to startup the application so much faster, and if there is someway for me to levarage its strategy, or SBT itself, even if that means keeping a long living process around to actually run a command through.
Unless you have forking turned on for your run task, this is likely due to VM startup time. When you run from inside an active SBT session, you have an already initialized VM pointing at your classes - all SBT needs to do is create a new ClassLoader and point it at your build output directory. This bypasses all of the other (not insignificant) stuff that happens when you fire up a new VM.
Have you tried using the client VM to start your utility from the command line? Sadly, this isn't an option with 64-bit Java, since Oracle apparently doesn't want to support it, but if you're using a 32-bit VM, try adding the -client argument to the list that you give the VM from the command line.
If you are using a 64-bit VM, some googling will find you some unofficial forks of OpenJDK that have the client VM re-enabled. It's really just a #define in the JVM build itself - it works fine once it's been compiled in.
The only slowness I have is launching SBT. Running a hello-word Scala app with java (no Drip) version 1.8 on a 7381 bogomips CPU takes only 0.2 seconds.
If you're not in that magnitude, I suspect your application startup requires loading thousands of classes, and creating instances of them.
I'm running some tests for Django, and some other tests for the website using Selenium.
My choice of Testing framework is amazing Pytest.
for testing Django I've currently installed pytest-django plugin and tests for Django run as expected, however now I'm back to my previous tests that don't need Django plugin.
I start tests and the Django plugin is picked up automatically.
I've checked the documentation and found the article where it is explained how to disable\deactivate plugins, however when I run this command:
py.test -p no:django
I get an error that my "DJANGO_SETTINGS_MODULE" is not on sys.path.
Also
commands like:
py.test --traceconfig
or
py.test --version
throw me the same error.
Looks like Django plugin is getting to deep? Why is it called when I'm just checking the version or the 'installed plugins'?
QUESTION: Is there any way to temporary deactivate this plugin without uninstalling it?
This should work. When i install pytest-2.3.4 and run py.test -p no:django --version i don't get the DJANGO_SETTINGS issues. I get it when i leave away the -p no:django disabling.
If it doesn't work, please link to a full trace on a pastebin.
IIRC this is because of a combination of things:
On startup py.test looks for the setuptool entrypoint "pytest11"
Entrypoints get imported before they get activated or deactivated
pytest-django (as released, currently 1.4) does a load of Django imports upfront
A lot of Django needs the settings module configured even at import time
Unfortunately this is unavoidable in the released version of pytest-django. And the answer originally was: no, run the pytest-django and other tests in different virtualenvs.
However it is also the reason we started work on a version of the plugin which avoids these problems. What I consider the best version right now is the pytest23 branch at https://github.com/flub/pytest_django This version is pretty feature complete, certainly compared to the released version, it just needs a little more polishing mainly on the tests and documentation.
I believe/hope that within the next few weeks this branch will be merged and released, I just need to get Andreas to have a look through and agree. I consider it certainly stable enough to start using.
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.
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
How do YOU debug a Scala program?
I mean YOU as in the person posting the Answer :) Please answer only from personal experience, not from stuff you've heard or read on the Internet. You should not believe everything you read on the Internet, especially tales of complex open-source software configurations that actually work :-)
The are many Java tools which claim to support Scala in some way or another, but I have so far struck out in trying to get any one of them to actually let me set a breakpoint in Scala code and step through it. These are big, major open-source IDEs I'm talking about here.
The main problem in getting a debugger to work seems to be the "version hell" with fast-changing IDEs, Plug-Ins, JDKs, and the Scala language itself.
Hence, the more detailed re-statement of the question is appropriate: What is the exact version number of the IDE, Plug-In, JDK, Scala, and even Operating System, that you are successfully using?
My question is related to this one, but wider in scope:
How To: debug Scala code when outside of an IDE
Thanks
In our development we use IntelliJ IDEA 9.0.1 which is available by the link below:
http://www.jetbrains.com/idea/download/
with Scala plugin installed:
http://confluence.jetbrains.net/display/SCA/Getting+Started+with+IntelliJ+IDEA+Scala+Plugin
All you need is to have project with Scala sources (probably, mixed with Java or other JVM-based languages) opened. You can compile it and run as Java application, maven goal etc. or connect to the remote application if it has been run in debug mode.
See IntelliJ help for details of adjusting debug configuration.
Cheers!
Ilya
I've worked with Eclipse and the Scala plugin for it. It works somewhat ok, if you can overlook the fact that it doesn't remember the configuration for your Scala application on the next run.
I debug my Scala programs by running relevant parts of it on the REPL, as to verify what it is really doing. Other than that, the good old println or logs.
Digressing here a bit, it has been a rare thing in my life a situation where step-in debuggers were actually required -- and, then, mostly for assembler code, though languages where testing snippets of code is difficult for some reason were more likely to require it than others which weren't.
OS: xUbuntu(GNU/Linux) 9.10
JDK:
java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)
(which is the Java-6-sun-version, used by the xUbuntu-installer).
Eclipse: 3.5.1 Build id: 20090920-1017
Scala-Plugin 2.7.7final
Scala 2.7.7
If possible: println-Statements, because eclipse is often tricky to invoke (does not find the main class, even after complete rebuild, closing/opening project, deleting old class-Files). The latest search for a problem ended when I 'deleted all bookmarks' - suddenly I was allowed to run the program.
Curious observation: class Bruch was what I tried to run, but eclipse allways mentioned 'Bruc' and named the runtime-configuration like this. Adding and removing characters reflected in the generated name accordingly (Bruc => Bru).