- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: Scala scripting
Mon, 2009-07-13, 03:18
There is! -savecompiled.
-------------------------------------
Baldur Norddahl wrote:
Hi,
I am experimenting with using Scala instead of gawk or perl for simple
commandline scripting. Currently I have this simple script:
find . -name '*.class' | xargs -n 1000 scala -e "argv.toList.map{ x =>
x.replace('/','.').substring(2,x.lastIndexOf(\".\"))}.foreach(println _)"
This finds all classes in an unpacked jar file and prints them in standard
java form. For example
"./com/sun/org/apache/xpath/internal/axes/FilterExprWalker.class" becomes
"com.sun.org.apache.xpath.internal.axes.FilterExprWalker".
While this worked perfectly, there are two issues I am not 100% satisfied
with.
1) change xargs -n1000 to xargs -n1 and this never completes (for rt.jar).
Startup is order of magnitutes too slow. Perhabs there are no easy
solutions, but I could wish for a simple command line parameter that would
make scala cache the compiled script. When used together with -e it could
hash the script into a temp filename for caching.
2) I want to get rid of the xargs. Maybe there already is a way but I can't
find it. I want to do something like this:
find . -name '*.class' | scala -e "in.toStream.map{ x =>
x.replace('/','.').substring(2,x.lastIndexOf(\".\"))}.foreach(println _)"
There is readline but it will only read one line at a time. It requires far
too much boilerplate to create a stream of input lines to be useable
together with the -e option. Any ideas on how to do this?
In general I feel Scala needs a larger toolset to be a better scripting
option.
Thanks,
Baldur
Mon, 2009-07-13, 03:57
#2
Re: Scala scripting
I see.
Maybe in a way you could look at this problem being caused by combining bash with scala. Maybe you could write a scala version of the find command, and publish it. It shouldn't be too hard. You have to recurse on File.list or listFiles. With function literals that could be very powerful.
-------------------------------------
Baldur Norddahl wrote:
On Mon, Jul 13, 2009 at 4:18 AM, Naftoli Gugenhem wrote:
> There is! -savecompiled.
The -savecompiled option has no effect on my script when run together with
the -e option.
Mon, 2009-07-13, 19:37
#3
Re: Scala scripting
JVM load time is really more a matter of class load time, I think. So if you think about how many classes need to get loaded to run your script vs. to compile it, it's not so surprising.
I've read discussion about caching verified classes, don't remember outcome though.
-------------------------------------
Baldur Norddahl wrote:
On Mon, Jul 13, 2009 at 4:53 PM, Daniel Sobral wrote:
> Scala will never be competitive on startup-time. Maybe on .Net, but, even
> then, I doubt it.
>
Start time without -savecompiled or with -e is about 2.6 seconds on my
computer. With -savecompiled it is only about 0.4 seconds. This is still
slow but much much better than almost 3 seconds. So I will put up that
-savecompiled together with -e should be fixed.
The generated jar file does not seem to be a valid jar. But unzipping it and
running this command works:
java -cp /usr/share/java/scala-library.jar:. Main
Now start time is only 0.3 seconds.
I tried to compiled it with gcj but with no success. That is too bad since
it would have solved the start time issue.
Never the less - if JVM start time is only responsible for 0.3 seconds, why
does it spend 2.3 seconds to compile a simple one line script?
Mon, 2009-07-13, 19:47
#4
Re: Scala scripting
But the FSC compile daemon is supposed to fix that. Running with -nocompdaemon makes it even worse.
On Mon, Jul 13, 2009 at 8:17 PM, Naftoli Gugenhem <naftoligug@gmail.com> wrote:
On Mon, Jul 13, 2009 at 8:17 PM, Naftoli Gugenhem <naftoligug@gmail.com> wrote:
JVM load time is really more a matter of class load time, I think. So if you think about how many classes need to get loaded to run your script vs. to compile it, it's not so surprising.
I've read discussion about caching verified classes, don't remember outcome though.
Mon, 2009-07-13, 19:57
#5
Re: Scala scripting
I mean loading .class files, not referenced source files. Think about how many classes the compiler code references and causes the JVM to load and verify. That's of course besides the actual computing the the compiler does, which includes loading classes referenced by the source code.
-------------------------------------
Baldur Norddahl wrote:
But the FSC compile daemon is supposed to fix that. Running with
-nocompdaemon makes it even worse.
On Mon, Jul 13, 2009 at 8:17 PM, Naftoli Gugenhem wrote:
> JVM load time is really more a matter of class load time, I think. So if
> you think about how many classes need to get loaded to run your script vs.
> to compile it, it's not so surprising.
> I've read discussion about caching verified classes, don't remember outcome
> though.
>
>
Mon, 2009-07-13, 20:07
#6
Re: Scala scripting
The FSC compiler daemon is already loaded. It must be fully ready having done JIT on all necessary classes and so on, since it just compiled exactly the same script just a few seconds ago.
It does not seem to work as well as it could.
On Mon, Jul 13, 2009 at 8:41 PM, Naftoli Gugenhem <naftoligug@gmail.com> wrote:
It does not seem to work as well as it could.
On Mon, Jul 13, 2009 at 8:41 PM, Naftoli Gugenhem <naftoligug@gmail.com> wrote:
I mean loading .class files, not referenced source files. Think about how many classes the compiler code references and causes the JVM to load and verify. That's of course besides the actual computing the the compiler does, which includes loading classes referenced by the source code.
Mon, 2009-07-13, 21:17
#7
Re: Scala scripting
True.
-------------------------------------
Baldur Norddahl wrote:
The FSC compiler daemon is already loaded. It must be fully ready having
done JIT on all necessary classes and so on, since it just compiled exactly
the same script just a few seconds ago.
It does not seem to work as well as it could.
On Mon, Jul 13, 2009 at 8:41 PM, Naftoli Gugenhem wrote:
> I mean loading .class files, not referenced source files. Think about how
> many classes the compiler code references and causes the JVM to load and
> verify. That's of course besides the actual computing the the compiler does,
> which includes loading classes referenced by the source code.
>
>
The -savecompiled option has no effect on my script when run together with the -e option.