This may sound like a stupid question, but I've been searching all over the internet on how to comment a line in an sbt file. Does anyone know how to?
// creates the comment.
It is rather easy to find.
Edit: An sbt build file uses Scala syntax with some DSL on top of it. As per documentation:
Each Setting is defined with a Scala expression. The expressions in
settings are independent of one another, and they are expressions,
rather than complete Scala statements.
So if you wonder what for instance lazy val root means you should rather search Scala documentation (or SO) for the answer.
On the other hand many "operators" (like +=, :=) are the part of sbt's DSL - they simply methods explained to some degree in the settings section.
Related
I know a Scala file, as in Java, should better define only one class. But now I have someone else's code. The code defines two classes. I 'd like to compile one of them because the other one does not compile. Of course I could have commented out the other one, but I have a large number of such files and I am looking for an automated solution for doing so. Any idea?
The Scala compiler works on whole files. The only way I can imagine doing this is to write a script which comments out all classes you don't want, runs scalac and then removes the comment markers again (well, you could also use Scala compiler as a library to get equivalent results without doing this literally). Needless to say, I don't think it's actually a good idea, but it's possible.
I'm new to scala and struggling with the documentation a little bit. I was looking at a piece of code in the spark codebase (cosine similarity for RowMatrix) and saw that they use Iterator.tabulate. Not knowing what that function does I looked in the scala API docs, only to find out the function does not exist. Except that it does exist, because I can use it in the repl (hmm, maybe I'm looking at the wrong API docs version ... no, this this is the current version).
After a bit of searching I find out that tabulate is defined (at least) in scala.collection.generic.SeqFactory and scala.collection.generic.TraversableFactory. These two however appear not the be connected in the dependency graph. I can't find any path between the two, and hence no way of actually knowing - from looking at the API docs - that .tabulate even exists.
So the question is: how do you find .tabulate and it's documentation from looking at the API docs for the class (say Iterator or Seq). Do I just have to google my way around it, or is there some magic button in the scala docs that will make the thing appear?
This doesn't seem to be limited to just .tabulate but a more common issue (at least for me), looking at library code functions seem to exist that are never mentioned in the API. Another example is
org.apache.spark.mllib.linalg.distributed.RowMatrix.toBreeze
I still don't know if that function exists, some code seems to use it, but I can't find any documentation about it.
In Scala source code all logic of Iterator defined in one file Iterator.scala. Function tabulate that you're looking for is defined in object Iterator in Scala API you make search by trait Iterator so this is why you can't find it.
In right corner of doc you can switch to object iterator and here you will find Iterator$#tabulate util function.
I was doing some research of how to solve this question. However, I am wondering if I can start learning how the function works, or how they pass the argument into the local scope by reading the source code of scala.
I know the source code of scala is hosted in Github, my question is how to locate the definition of def.
Or more generally, how to locate the source code of certain built in functions, operators?
The source code for everything in the Scala standard library is under https://github.com/scala/scala/tree/2.11.x/src/library/scala.
Also, the Scaladoc for the standard library includes links to the source code. So e.g. if you're interested in scala.Option and you're looking at http://www.scala-lang.org/api/2.11.7/#scala.Option, notice that page has "Source: Option.scala" where "Option.scala" is hyperlinked to the source code.
For something like def, which is not part of the standard library, but part of the language, well... there is no single place where def itself is defined. The compiler has 25 phases (you can list them by running scalac -Xshow-phases) and basically every phase participates in the job of making def mean what it means.
If you want to understand def, you'd probably be better off reading the Scala Language Specification; it's highly technical, but still much more approachable than the source code for the compiler.
The part of the spec that addresses your question about named and default arguments is SLS 6.6.1.
The SBT documentation about Macro Projects starts with the following:
The current macro implementation in the compiler requires that macro implementations be compiled before they are used. The solution is typically to put the macros in a subproject or in their own configuration.
What does exactly mean to put the macros "in their own configuration"? Does it mean there is an alternative to putting macro source in a subproject? If so, what would that alternative be? I'm looking for an option where I'd not have to separate macro source from invocations, mainly because I don't want yet another subproject for common code.
I believe the author refers to the Configuration scop. In short: you already know that diffrent sources can reside under src/main/scala and src/test/scala, and that code in the test configuration can use code from the compile (main) configuration. so why not having a custom configuration, e.g. macro, and sources for it can reside under src/macro/scala?
there's a great answer on this matter, I suggest you take a look.
also, you could find useful examples here. it's an explanation on defining new configurations for tests. but you could exploit it for your needs.
I don't know what the author meant by own configuration.
An alternative is to use SBT's ability to generate sources (c.f. sourceGenerators) before they get compiled. "Generating" in fact allows you for instance to copy macro source files from elsewhere.
However that's convoluted, so I'd recommend to separate macros in a sub-project. Besides, separating macros still allows you to build even if you switch to an IDE that doesn't support SBT (then you have a macro-defining project and a macro-using project).
sbt maintains dependencies between tasks, and the resulting graph can be reasoned about fairly easily. On the other hand, skimming the source code, it seems like the incremental compilation logic is a lot more opaque. I'd like to be able to do the following things:
Say the equivalent of "if I modified this interface [in this way], what would get invalidated?"
Build a graph of how modifying different class interfaces affects the rest of the build. Graphing scala import dependencies isn't a particularly good approximation of this, given how complicated implicit dependencies can get in Scala. It seems like sbt must maintain this information in some form or another to do incremental compilation, so I "just" need to figure out how to access it and hope that it's in a form suitable for my use case.
Are either of these feasible? I'm not opposed to writing sbt plugins, but would appreciate hints about how to proceed.
Edit: it looks like Relation's usesInternalSrc(dep: File): Set[File] could be promising. Does that capture all of sbt's dependency knowledge?
Edit 2: even more promising, there's a DotGraph object inside the sbt source tree. It has no documentation and google doesn't have any human-readable text about it. If I can figure out how to use it I'll post an answer.
Sample console-project session:
> val (s, a) = runTask(compile in Compile, currentState)
> DotGraph.sources(a.relations, file("source-graph"), Nil)
source-graph is a directory that will contain two dot files, one with source dependencies and one with binary. You can alternatively directly interact with a.relations of type Relations, as suggested in the question, and which does capture all of sbt's dependency knowledge. In 0.13 there will also be information about which dependencies are due to inheriting from something in another source file.
In terms of how modifying a source file affects invalidation, it is very coarse grained. Any change to any non-private signature marks a source as changed. In 0.12 and earlier, this will at least invalidate direct dependencies and maybe more. In 0.13, this will invalidate direct dependencies only, except for inherited dependencies, which are transitively invalidated. There is currently no way to see what will be invalidated when a source file's non-private API is modified except by doing it.