I am a beginner learning to program in scala-akka and I have had no problems running my scripts on IntelliJ IDE / and 'sbt run'. However, I can't seem to find any resources that teaches me how to manually use scalac and the akka jar dependency to compile and run just from the command-line. Can anyone point me in the right direction?
Let's assume you have Scala and Akka installed somewhere under /home/leo/apps/ and Scala binaries are searchable (e.g. export PATH=$PATH:home/leo/apps/scala-2.11.8/bin)
Next, let's say you have a Scala main app Tweets.scala along with a few supplementary classes packaged in akkastreams under /home/leo/myproject/:
akkastreams/
Tweets.scala
Author.scala
HashTag.scala
Message.scala
...
Here's how you'll compile and run the app:
cd /home/leo/myproject/
# Compile all files in package akkastreams:
scalac -cp "/home/leo/apps/akka-2.4.9/lib/akka/*" akkastreams/*.scala
# Run the main app Tweets (object Tweets extends App):
# Note that classpath includes also current subdir '.'
scala -cp "/home/leo/apps/akka-2.4.9/lib/akka/*:." akkastreams.Tweets
A few notes:
You could include only specific Akka jars instead of all of them.
Without dependencies and versioning being managed by sbt, you'll need to manually maintain version consistency between Scala's bundled Akka libraries versus Akka's own ones.
While it's a good exercise to see how things are done in a crude way, it's obviously unproductive to do this on a regular basis.
In my opinion You should perform scalac and scala with classpath parameter and selected library jar file.
By the way it's still more convenient to use sbt.
Related
https://docs.scala-lang.org/overviews/compiler-options/index.html says
Scala compiler scalac offers various compiler options, also referred to as compiler flags, to change how to compile your program.
Nowadays, most people are not running scalac from the command line. Instead, they use sbt, an IDE, and other tools as their interface to the compiler. Therefore they may not even have scalac installed, and won’t think to do man scalac.
Does "the compiler" refer to scalac?
If yes, is "they use sbt, an IDE, and other tools as their interface to the compiler" contrary to "therefore they may not even have scalac installed"?
Does sbt rely on scalac?
Thanks.
Scala compiler can be accessed programmatically via an API packaged by scala-compiler.jar dependency, hence tools such as IDEs and SBT can implement their own client frontends over this API to drive compiler functionality. scalac is just a bash script that executes scala.tools.nsc.MainClass class from scala-compiler.jar.
Does sbt rely on scalac?
No, sbt uses compiler API directly. One of the key concepts to understand regarding sbt is that the build definition is itself Scala code, either vanilla or DSL, but Scala nevertheless. The version of Scala used to compile the build definition is separate from the version of Scala used to compile project proper. The build definition source code in build.sbt and project/*.scala will be compiled using Scala version specified indirectly via sbt.version=1.2.8 setting in project/build.properties, whilst project source code proper in src/main/scala/* will be compiled using Scala version specified directly via scalaVersion := "2.13.1" setting in build.sbt. Note how they can indeed differ. Think of the build definition as simply another Scala app which uses sbt API for its implementation.
I have been using sbt on windows and a custom build.sbt script in conjunction with an import Chisel._ in the top-level file in order to generate Verilog from my Chisel source successfully.
I'm trying to get an IDE working on Windows to expedite Chisel development. I've gone with the Eclipse based SCALA IDE http://scala-ide.org/download/sdk.html/
I want to compile the Chisel library so that the import Chisel._ can be resolved locally, without having to go off and download the source from the repository each timeand recompile the source. When I download the Chisel-master repo from Git and include the src\main folder in my SCALA project in the SCALA IDE, I get lots of syntax errors in the Chisel SCALA files that prevent me from building the project.
Has anyone done anything like this before on Windows or have any knowledge of working with the SCALA IDE as it may just be a case of undefined symbols in the project configuration?
Not sure exactly what you did with build.sbt respect to recompile (I think it download it only the first time, then it caches it for the future). But I'm using ScalaIDE for Chisel on linux, using the default build.sbt files, maybe you can try to get it working out of the box first to help narrow down the issue.
Here are the steps I took in order to get ScalaIDE work with Chisel:
the latest Scala IDE uses 2.11.8, the current Chisel repository defaults to 2.11.7. So I had to change all the build.sbt reference to scalaVersion from 2.11.7 to 2.11.8
I used sbteclipse
https://github.com/typesafehub/sbteclipse
To create importable the workspace to setup the compilation dependencies.
Except for chiselFrontEnd. For some reason, this package is not added to the dependency. I have to Add chiselFrontEnd as a javabuildpath dependency manually (Properties/JavaBuildPath, under Projects) for my own projects.
To resolve undefined symbols, you can also add a JAR onto the project build path using Project Properties > Java Build Path > Libraries > Add External JARs...
If you are getting your JARs through Maven / SBT, they should be in:
C:\Users\<name>\.ivy2\local\edu.berkeley.cs\chisel3_2.11\jars
If you are using publish-local with chisel3, your JARs should be in
C:\Users\<name>\.ivy2\cache\edu.berkeley.cs\chisel3_2.11\jars
Note that chisel3 is compiled into one JAR, including coreMacros and chiselFrontend sub-projects
Of course, this is a more quick-and-dirty solution compared to something that can parse SBT files.
Suppose I have a Scala compile-time macro that I find useful and would like to share it (I do). How do I create a JAR file that when loaded into another project would execute the macro when compiling the new project?
Specifically, I've made a StaticAnnotation that rewrites the AST of the class that it wraps before compile time. This works in my Maven build (macro defined in the main directory, runs on test cases in the test directory) because I have
<compilerPlugins>
<compilerPlugin>
<groupId>org.scalamacros</groupId>
<artifactId>paradise_2.10.5</artifactId>
<version>2.1.0-M5</version>
</compilerPlugin>
</compilerPlugins>
in my scala-maven-plugin. (I'm starting with a Scala 2.10 project and if it works, will provide both 2.10 and 2.11.)
But if I put the resulting JAR on a Scala console classpath, in a Scala script, or into another Maven project (without special compiler plugins), it simply ignores the macro: the AST does not get overwritten and my compile-time println statements don't execute. If I use the #compileTimeOnly annotation on my macro (new in Scala 2.11), then it complains with the #compileTimeOnly error message.
Do I really need to tell my users to add compiler plugins in their pom.xml files, as well as alternate instructions for SBT and other build tools? Other packages containing macros (MacWire, Log4s) don't come with complicated build instructions: they just say, "point to this dependency in Maven Central." I couldn't find the magic in their build process that makes this work. What am I missing?
If you're relying on a macro-paradise-only feature then yes, you do need to tell your users to add compiler plugins. See http://docs.scala-lang.org/overviews/macros/annotations.html . The projects you mention are only using the scala compiler's built-in (non-paradise) macro features, not macro annotations.
I have recently begun exploring Scala, and have started by installing the Scala IDE in my copy of Eclipse (Indigo). I initially installed the Scala IDE for Scala 2.9, but then noticed that there was a newer release available for Scala 2.10. Installing the newer plug-in over the older one seems to have worked, but...
Scala 2.10 has deprecated the older Scala Actors in favor of Akka Actors. Thus I'm trying to add an import to my toy Scala project:
import akka.actor.Actor
This is flagged in the IDE with the error
not found: object akka
When I look at my Scala project's properties, I indeed do not see any of the akka-* jar files that are mentioned in the Akka documentation.
Do they need to be downloaded and installed separately, even though the Scala IDE plug-in installed the rest of Scala 2.10? Or have package names changed as part of integrating Akka actors in place of the older Scala Actors? (The documentation doesn't say so, but the Scala 2.10 release is fairly recent...)
No, they aren't packaged together.
The easiest way to make sure the Eclipse IDE can see your dependencies (Akka, and anything else referenced in your build.sbt file) is to let sbt do it using the sbteclipse plugin. Here's the instructions I wrote up for co-workers:
Install the "sbteclipse" plugin
This plugin will allow sbt to add the files/references that Eclipse needs to find all the dependencies that you specify in your build.sbt. Otherwise, you will be able to use the IDE, but you will seek all kinds of "object not found" errors.
Just make sure the plugin is being added in your global plugins.sbt file. This file (and it's path) may not exist so you may need to create it at the following location:
~/.sbt $ cd ~/.sbt/0.13/
~/.sbt/0.13 $ mkdir plugins
Edit/create the plugins.sbt file:
~/.sbt/0.13 $ vi plugins/plugins.sbt
then add this line (it may be the only line in the file):
addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0")
Running sbteclipse
To use this, you just navigate to a scala project on the commandline and run the following. If you already had Eclipse open, go ahead and restart it.
/sites/ewuser (master)$ sbt eclipse
References:
How to initialize a new Scala project in sbt, Eclipse and github
Official sbteclipse plugin
The Akka artifacts are not bundled with the Scala IDE (yet), you will have to add “akka-actor_2.10” and friends to your project’s dependencies.
Download the akka for eclipse from below location
http://downloads.typesafe.com/akka/akka_2.11-2.4.1.zip?_ga=1.167921254.618585520.1450199987
extract the zip
add dependencies from the lib folder into project
I'm currently using sbt to build and run my scala programs. I'm trying to use sbt.Process to execute system commands. I must be missing something because when I try to import sbt.Process in one of my files in src/ I get this error.
not found: value sbt
[error] import sbt.Process._
So it looks like I can't access the sbt package inside my src/ files. What do I need to do to access it? Thanks.
SBT's environment (v 0.7.x) is only available in your build file or a Plugin.
The easiest way to use sbt.Process library (until 0.9.x which will have Process as an independent library) is to copy (BSD License) Process.scala and ProcessImpl.scala into your project
There are different classpaths for running sbt and compiling your source files.
One classpath is for compilation of files in directory project/build (that one contains sbt jars and usually scala library 2.7.7) and the other one is for building source files of your project (that one contains your dependencies from lib and lib_managed and usually scala library 2.8.*). If you'd like to use sbt.Process in your source files you can do two things:
add sbt jar to lib or lib_managed for it to be available on your project's classpath
use snapshot version of scala 2.9, it would have sbt Process built-in as sys.process package
Wait for Scala 2.9, and then just use it out of scala.sys.process.
sbt package has became an integral part of the Scala standard library since version 2.9
...this API has been included in the Scala standard library for version 2.9.
quoted from sbt wiki
Here's the link (scroll down)
well, in order to use it, all you have to do (assuming you are using sbt for build), is to add in build.sbt file the following line of code: sbtPlugin := true it will add the needed dependencies to your project.
of course, this solution is only to get your imports with sbt package to work. you should refactor your code to use the new package scala.sys.process like Daniel C. Sobral suggested.