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.
Related
I am using TreeHugger to generate code at runtime. I could not find many documents related to it. My question is, if I generate classes using treehugger, will I be able to access those classes in future?
To be precise: I want to read data coming from files like CSV and create classes at runtime . Can I use that class in future, say in the next class generated at runtime.
I am really new to scala, please forgive if I am not clear in explaining.
Thanks a lot!
I've done something similar, so I'll share what I've learned:
Treehugger ultimately generates code (strings) at runtime to be used in a subsequent, separate run (or I suppose to be eval'd at runtime, but I never got that to work).
So the course of action depends on what you mean by "runtime":
Are your .csv files only available at runtime? If you have access to the files at compile time (as is often the case), then are examples of your two options: experimental (scala macros) or traditional (sbt plugin) -- both approaches are similar but have subtle pros and cons.
If you only have access to the files at runtime, but still need to generate and "type" the classes and make the compiler expect them, then it seems to me that somebody has made a bad design mistake! But if you find yourself stuck in this circumstance, then it is possible to define and load classes at runtime with a bytecode-engineering library and some type-checker black magic (runtime type provider).
When I use scalac to compile file.scala, I end up with 2 outputs, file.class and file$.class. What is the difference between these files and which is the appropriate one to then run? I get distinctly different error messages between executing "scala file" vs "scala file$".
Scala objects get compiled to classes ending in "$" because you're allowed to have an "ordinary" class with the same name. But the object's methods are also exposed as static methods on the "ordinary" class, so that they can be called under the names you would expect. This is an artifact of trying to represent the scala semantics in a way that make sense to Java / the JVM, and I would encourage you to regard it as an implementation detail rather than something important.
(#MattPutnam's answer is correct that anonymous classes, including closures, are compiled to class files with $es in their name, but that's not what's causing your file$.class in this particular instance)
Use scala file. If you're interested in the implementation details you might also want to try java -cp /path/to/scala-library.jar file.
file$.class is some inner anonymous class. In Java they're very explicit, but they can be easy to miss in Scala. If you use any method that takes a function, there's an implicit anonymous class there. Post the code and I'll point it out.
I would like to write some pieces of code in Scala . It is important for me that this code can be called from matlab. AFAIK java code can easily be integrated with matlab. http://www.mathworks.co.uk/help/matlab/ref/javamethod.html
Is this valid also for scala code?
It is also valid for Scala code. Just pretend that you're doing Java interop (e.g. a method called + would actually be $plus) and make sure scala-library.jar is in Matlab's classpath (e.g. using javaaddpath).
Incidentally, I've done Java/Matlab interop before, and it's not as "easily integrated" as one might hope. Passing data is kind of awkward and you tend to trip on classloader and/or classpath issues every now and then.
I'd be wary of planning a big project with lots of tightly-connected interop. In my experience it usually works better using the Unix mindset: make independent tools that do their own thing well, and chain them together to get what you want. For instance, I routinely have Scala write Matlab code and call Matlab to run it, or have Matlab use system to fire up a Scala program to process a subset of the data.
So--calling Scala from Matlab is completely possible, and for simple interfaces looks just like Java. Just try to keep the interface simple.
You could encapsulate your Scala code in another language that's easily called by Matlab, such as Java of C. Since you seem to know about Java, you could use these examples to learn to encapsulate your Scala methods inside Jave methods that you can call from Matlab. A number of other methods are available to you with different languages (MEX-files, loadlibrary, etc...)
I have some class file inside a jar. Now I am searching for a way to optimize that class file using some components(most notably the Inliners) of the scala compiler.
My idea is to :
use the ICodeReader to emit ICode from class file
use an instance of the Inliner class in order to achieve the desired optimization
I am not know if that´s the right way to go
The problem is that
How to use the ICodeReader in order to read a class file and produce the needed ICode. ICodeReader inherits from ClassfileParser. The sole method that is for me more probable to use is parse(file: AbstractFile, root: Symbol) but the problem the root argument.
Any help is welcome
The Scala compiler acts on the source code and on the results of the intermediate step to produce bytecode, and will try to apply, if enabled, several optimisation.
In your case, if I understood right, you do not have the sources but the compiled classes, and I would not expect you being able to use a feature of Scala compiler on compiled classes.
What you should be looking to, in my understanding, is a bytecode optimizer , such as ProGuard, which is able to take existing bytecode and optimize it without having access to the source code
http://proguard.sourceforge.net/#FAQ.html
I have just finished the first version of a Java 6 compiler plugin, that automatically generates wrappers (proxy, adapter, delegate, call it what you like) based on an annotation.
Since I am doing mixed Java/Scala projects, I would like to be able to use the same annotation inside my Scala code, and get the same generated code (except of course in Scala). That basically means starting from scratch.
What I would like to do, and for which I haven't found an example yet, is how do I generate the code inside a Scala compiler plugin in the same way as in the Java compiler plugin. That is, I match/find where my annotation is used, get the AST for the annotated interface, and then ask the API to give me a Stream/Writer in which I output the generated Scala source code, using String manipulation.
That last part is what I could not find. So how do I tell the API to create a new Scala source file, and give me a Stream/Writer/File/Handle, so I can just write in it, and when I'm done, the Scala compiler compiles it, within the same run in which the plugin was invoked?
Why would I want to do that? Firstly, because than both plugins have the same structure, so maintenance is easy. Secondly, I want to open source it, and there is just no way to support every option that anyone would want, so I expect potential users to want to extend the generation with their own code. This will be a lot easier for them if they just have to do some printf(), instead of learning the AST API (this also applies to me).
Short answer:
It can't be done
Long answer:
You could conceivably generate your source file and push that through a parser instance within your plugin. But not in any way that's likely to be of any use to you, because you'd now have a bigger problem to contend with:
In order to grab all the type/name information for generating the delagate/proxy, you'll have to pick up the annotated type's AST after it has run through both the namer and typer phases (which are inseperable). The catch is that any attempts to call your generated code will already have failed typechecking, the compiler will have thrown an error, and any further bets are off.
Method synthesis is possible in limited cases, so long as you can somehow fool the typechecker for just long enough to get your code generated, which is the trick I pulled with my Autoproxy 'lite' plugin. Even then, you're far better off working with TreeDSL to generate code instead of pumping out raw source.
Kevin is entirely correct, but just for completeness it's worth mentioning that there is another alternative - write a compiler plugin that generates source. This is the approach that I've adopted in Borachio. It's not a very satisfactory solution, but it can be made to work.
Edit - I just reread your question and realised that you're actually asking about generating source anyway
So there is no support for this directly, but it's basically just a question of opening a file and writing the relevant "print" statements. There's no way to invoke the compiler "inside" a plugin AFAIK, but I've written an sbt plugin which hides most of the complexity of invoking the compiler twice.