scalaが実行できない

[mizo]

皆様

　溝口@初心者です。

　コップ本を教科書に Scala を勉強しています。
　さて、コップ本に従いコードを書いて実行したら、
　次のような Java の Exception を拾ってしまっています。

C:\Documents and Settings\mizo\デスクトップ\Scala>scala widthOfLength.scala
Could not connect to compilation daemon.
Exception in thread "main" java.lang.Exception: fsc failure
at scala.tools.nsc.CompileSocket.fatal(CompileSocket.scala:53)
at scala.tools.nsc.CompileSocket.getPort(CompileSocket.scala:
175)
at scala.tools.nsc.CompileSocket.getsock$1(CompileSocket.scala:
206)
at scala.tools.nsc.CompileSocket.getsock$1(CompileSocket.scala:
224)
at scala.tools.nsc.CompileSocket.getsock$1(CompileSocket.scala:
224)
at scala.tools.nsc.CompileSocket.getOrCreateSocket
(CompileSocket.scala:227)
at scala.tools.nsc.CompileSocket.getOrCreateSocket
(CompileSocket.scala:232)
at scala.tools.nsc.ScriptRunner$.compileWithDaemon
(ScriptRunner.scala:237)
at scala.tools.nsc.ScriptRunner$.compile$1(ScriptRunner.scala:
315)
at scala.tools.nsc.ScriptRunner$.withCompiledScript
(ScriptRunner.scala:350)
at scala.tools.nsc.ScriptRunner$.runScript(ScriptRunner.scala:
413)
at scala.tools.nsc.MainGenericRunner$.main
(MainGenericRunner.scala:168)
at scala.tools.nsc.MainGenericRunner.main
(MainGenericRunner.scala)

　何と無く実行環境が整っていないためのような気がしますが
　何が悪いのでしょうか？

　正常な反応なのか良くわかりませんが、
　この Exception の意味がわかる人がいたら教えて下さい。

　宜しく御願いします。

以上

溝口

[Kota Mizushima]

溝口さん：

こんにちは。水島です。
scalaが実行できない問題ですが、エラーメッセージを見ると、どうやら
fsc(プロセスとして常駐して、２回目以降のコンパイル時間を削減する
ためのデーモン)が何かエラーを吐いているようです。たぶん、既に
起動済みのfscのプロセスがあるはずなので、それをkillするなり
(Linuxなど)、タスクマネージャから強制終了するなり(Windows)して
からもう一度実行してみてはどうでしょうか(fscのプロセスは実体
はJVMなので、タスクマネージャ等からはjavaとして見えていると
思います)。

2009年12月12日7:34 mizo <mizo....@gmail.com>:

> --
>
> このメールは Google グループのグループ「scala-be」の登録者に送られています。
> このグループに投稿するには、scal...@googlegroups.com にメールを送信してください。
> このグループから退会するには、scala-be+u...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/scala-be?hl=ja からこのグループにアクセスしてください。
>
>
>

--
Kota Mizushima
e-mail: hau5...@tree.odn.ne.jp,mizu...@gmail.com

[関隆]

溝口さんへ

こんばんは、関です。

連続してもう一回実行すれば、
おそらく、それ以降はうまく行くかと・・・
で、またしばらくすると同じエラーが出る場合もあります。
確認してませんが、
一定時間でFSCが勝手に終了してしますのかもしれませんね。
（わたしもWindowsの場合は同じ症状です。）

2009年12月12日7:34 mizo <mizo....@gmail.com>:

> --
>
> このメールは Google グループのグループ「scala-be」の登録者に送られています。
> このグループに投稿するには、scal...@googlegroups.com にメールを送信してください。
> このグループから退会するには、scala-be+u...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/scala-be?hl=ja からこのグループにアクセスしてください。
>
>
>



--

関　隆（SEKI Takashi）
hawk...@nifty.com
hawk...@gmail.com

[mizo]

関さん

　回答ありがとうございます。
　溝口です。

　今回の問題は、
　Windows をリブートしてたらOKに成りました。
　しかし、何が問題なのかハッキリしないのは気持ち悪いですね。

　ちなみに、同じコードを少しだけ大きいファイルに適用すると
　次のようなエラーがでました。

C:\Documents and Settings\mizo\デスクトップ\Scala>scala widthOfLength.scala

"C:\Document
s and Settings\mizo\デスクトップ\UML_Exercise.txt"
java.nio.BufferUnderflowException
at java.nio.Buffer.nextGetIndex(Unknown Source)
at java.nio.HeapCharBuffer.get(Unknown Source)
at scala.io.BufferedSource$$anon$2.<init>(BufferedSource.scala:77)
at scala.io.BufferedSource.<init>(BufferedSource.scala:74)
at scala.io.BufferedSource$$anon$1.<init>(BufferedSource.scala:34)
at scala.io.BufferedSource$.fromInputStream(BufferedSource.scala:32)
at scala.io.BufferedSource$.fromInputStream(BufferedSource.scala:27)
at scala.io.BufferedSource$.fromInputStream(BufferedSource.scala:23)
at scala.io.Source$.fromFile(Source.scala:132)
at scala.io.Source$.fromFile(Source.scala:122)
at scala.io.Source$.fromFile(Source.scala:101)
at scala.io.Source$.fromFile(Source.scala:95)
at Main$$anon$1.<init>((virtual file):10)
at Main$.main((virtual file):4)
at Main.main((virtual file))
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at scala.tools.nsc.ObjectRunner$$anonfun$run$1.apply(ObjectRunner.scala:75)
at scala.tools.nsc.ObjectRunner$.withContextClassLoader(ObjectRunner.scala:49)
at scala.tools.nsc.ObjectRunner$.run(ObjectRunner.scala:74)
at
scala.tools.nsc.ScriptRunner$.scala$tools$nsc$ScriptRunner$$runCompiled(Scrip
tRunner.scala:381)
at
scala.tools.nsc.ScriptRunner$$anonfun$runScript$1.apply(ScriptRunner.scala:41
4)
at
scala.tools.nsc.ScriptRunner$$anonfun$runScript$1.apply(ScriptRunner.scala:41
3)
at scala.tools.nsc.ScriptRunner$.withCompiledScript(ScriptRunner.scala:351)
at scala.tools.nsc.ScriptRunner$.runScript(ScriptRunner.scala:413)
at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:168)
at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)


　さて、この状態から、どこに問題があると推論すれば良いのでしょうか？
　JVM ダイナミック言語のランタイムエラーの状況って
　こう言う感じですか?

以上

溝口


関隆 さんは書きました:

[Kota Mizushima]

溝口さん：

水島です。JVMのダイナミック言語に限った話ではなく(そもそもScalaは静的な言語ですし)、Javaでも
基本的には同じですが、原因を究明するには、エラーが出ているユーザコード(widthOfLength.scala)と
ライブラリコードの境界がどこかを見つけることだと思います。今回のケースでは、

> at scala.io.Source$.fromFile(Source.scala:95)
> at Main$$anon$1.<init>((virtual file):10)

となっていますので、widthOfLength.scalaの10行目でSource.fromFileの呼び出しがあり、そこで例外
が発生しているようです。ということは、(Source.fromFileの呼び出し方を間違っていなければ)問題が
あるのはSource.fromFile、つまりライブラリコードにある可能性が高いと思います。widthOfLength.scala
のソース(全文)と問題を再現する入力があれば、こちらでも確かめることもできるかと思いますが…。

2009年12月16日1:40 mizo <mizo...@jcom.home.ne.jp>:

--
Kota Mizushima
e-mail: hau5...@tree.odn.ne.jp,mizu...@gmail.com

[関隆]

溝口さんへ

こんにちは、関隆です。

問題の切り分け方は、すでに水島さんが回答してくださってますので、、
私は、参考情報をば・・・
入力ファイルも文字コードがもしUTF-8でなかったら、
fromFile("input.txt", "shift-jis")のように明示してあげるとうまく行くかもしれません。

実はちょうど今、同じようなBufferUnderflowException問題に遭遇してたのでした・・・(^^;

2009年12月16日1:40 mizo <mizo...@jcom.home.ne.jp>:

[Mizoken001]

水島さん，関さん

　溝口です。
　回答ありがとうございました。

　私の素朴な疑問です。

> > at scala.io.Source$.fromFile(Source.scala:95)
> > at Main$$anon$1.<init>((virtual file):10)
>

　上記のスタックダンプから、
　どうすれば「widthOfLength.scala10行目のSource.fromFile呼び出し」と判断
できるのでしょうか？
　私が、問題だなと思うのは、そのまま、Javaに翻訳されたスタックフレームが
出ていて、
　所見では完全にハナモゲラ状態だといくことです。

　水島さんの解説だとMain$$anon$1.<init>がwidthOfLength.scalaに相当するの
だと思うのですが、
　私に、あのスタックダンプから、その情報が読取れませんでした。

　スタックダンプは、デバッグや問題解決の一番大事な情報です。
　それが、あのような状態では、少し、ガッカリしています。
　前の、java.lang.Exception: fsc failure　の異常終了もそうですが、
　ScalaのRun Timeは、結構、弱そうな感じがしています。

　プログラムは、コップ本の文中にあったサンプル・プログラムですが添付します。
　コップ本からは、Source.fromFileの正しい呼び出し方が分からないので、
　リファレンスなどを探したいと思います。

> 水島です。JVMのダイナミック言語に限った話ではなく(そもそもScalaは静的な言語ですし)

　済みません、JVM ダイナミック言語と使ったのは、言語仕様がダイナミック言語と言う意味ではなく
　JRuby, Tython, Groovy のようにJVM上に構築した言語が、JVM ダイナミック言語と呼ぶのかと
　思っていました（しかし、上記例の言語は、ダイナミック言語に分類されますね…）
　あるセミナで聞いた言葉を鵜呑みにして使ったのですが、あまり普及して無いようですね onz
　しかし、Scalaは、ダイナミック言語？　スタティック言語？　どちらなのでしょうか？

以上

溝口


Kota Mizushima さんは書きました:

[Mizoken001]

水島さん，関さん

　溝口です。
　回答ありがとうございました。

　私の素朴な疑問です。

>> > > at scala.io.Source$.fromFile(Source.scala:95)
>> > > at Main$$anon$1.<init>((virtual file):10)
>>
> >
>

　上記のスタックダンプから、
　どうすれば「widthOfLength.scala10行目のSource.fromFile呼び出し」と判断
できるのでしょうか？
　私が、問題だなと思うのは、そのまま、Javaに翻訳されたスタックフレームが
出ていて、
　所見では完全にハナモゲラ状態だといくことです。

　水島さんの解説だとMain$$anon$1.<init>がwidthOfLength.scalaに相当するの
だと思うのですが、
　私に、あのスタックダンプから、その情報が読取れませんでした。

　スタックダンプは、デバッグや問題解決の一番大事な情報です。
　それが、あのような状態では、少し、ガッカリしています。
　前の、java.lang.Exception: fsc failure　の異常終了もそうですが、
　ScalaのRun Timeは、結構、弱そうな感じがしています。

　プログラムは、コップ本の文中にあったサンプル・プログラムですが添付します。
　コップ本からは、Source.fromFileの正しい呼び出し方が分からないので、
　リファレンスなどを探したいと思います。


> > 水島です。JVMのダイナミック言語に限った話ではなく(そもそもScalaは静的な言語ですし)
>

　済みません、JVM ダイナミック言語と使ったのは、言語仕様がダイナミック言語と言う意味ではなく
　JRuby, Tython, Groovy のようにJVM上に構築した言語が、JVM ダイナミック言語と呼ぶのかと
　思っていました（しかし、上記例の言語は、ダイナミック言語に分類されますね…）
　あるセミナで聞いた言葉を鵜呑みにして使ったのですが、あまり普及して無いようですね onz
　しかし、Scalaは、ダイナミック言語？　スタティック言語？　どちらなのでしょうか？

[Kota Mizushima]

溝口さん：

水島です。

2009年12月16日19:40 Mizoken001 <mizo....@gmail.com>:

> 水島さん，関さん
>
> 溝口です。
> 回答ありがとうございました。
>
> 私の素朴な疑問です。
>
>> >        at scala.io.Source$.fromFile(Source.scala:95)
>> >        at Main$$anon$1.<init>((virtual file):10)
>>
> 　上記のスタックダンプから、
> どうすれば「widthOfLength.scala10行目のSource.fromFile呼び出し」と判断
> できるのでしょうか？
> 私が、問題だなと思うのは、そのまま、Javaに翻訳されたスタックフレームが
> 出ていて、
> 所見では完全にハナモゲラ状態だといくことです。
>
> 水島さんの解説だとMain$$anon$1.<init>がwidthOfLength.scalaに相当するの
> だと思うのですが、
> 私に、あのスタックダンプから、その情報が読取れませんでした。

初見ではよくわからないスタックダンプであり、不親切だというのはその通りだと思いますし、
改善の余地があると思います。ただ、読み方の基本みたいなものはあって、それさえ抑えて
れば大体読み取ることができます。

まず、基本知識なのですが、scalaはscalacでコンパイルするのが基本の言語であって、
scala [ファイル名]コマンドはscalacのラッパのような形で提供されているということです。
具体的には、ファイル名で与えられたスクリプトの前後に、scalacでコンパイルするのに
必要なコードをちょこちょこっとくっつけて、scalacに流し込むような感じです(厳密には
ちょっと違いますが)。このとき、最終的にscalacに渡されるのは元のファイル(たとえば
widthOfLength.scala)そのものではなく、その前後に色々くっつけたバイト列であるため、
ファイル名の情報が失われて、(virutal file):10のようになります(実は、前後に色々くっつける
際に行番号もずれるため、先ほど10行目と書いたのは実は正確ではないです)。

また、スクリプトとして直接実行する際のエントリポイントは、Main$$anon$1.<init>のように
なります(他の環境で確認したわけではないですが、おそらく同じだと思います)。

あと、(virtual file):行番号と表示されている箇所より下の部分はscalaコマンドがプログラムの
実行のために呼び出しているリフレクションAPI関連のスタックトレースですので全部無視して
良いです。

とにかく、scalaコマンドで直接スクリプトを実行する際のスタックトレースを読み取るときには、

･下の方のトレースは関係無いので無視する
･(virtual file):行番号がついている箇所に注目する

ことで必要な情報は大体読み取れるようになります。

>
> スタックダンプは、デバッグや問題解決の一番大事な情報です。
> それが、あのような状態では、少し、ガッカリしています。

scalaコマンドによるスクリプト実行の際のスタックダンプには問題があって読みづらいのは
先ほど述べたように事実ですが、scalacでコンパイルしたプログラム実行の際には
javaと同程度かそれに近いくらいには読みやすいスタックトレースが出るようになっています
(scalacで一度コンパイルして試してみてください)。

> 前の、java.lang.Exception: fsc failure　の異常終了もそうですが、
> ScalaのRun Timeは、結構、弱そうな感じがしています。

これは明確に間違っています。ランタイムに関してはほぼJavaそのままなので、Javaと同程度には
頑健です。fsc failureに関しては、fsc(のおそらくは通信関係の部分)の実装の問題であり、この部分の
実装がまだこなれていないという事ではあるのですが、これはランタイムとは直接関係無いです。

とりあえず自分が言えることとしては、

･コンパイラは割と安定している(ただし、時々コンパイラが落ちるようなバグが見つかるが)
･コンパイラは遅い(おそらくコンパイラのアーキテクチャが原因)
･fsc(Fast Scala Compiler。デーモンとして常駐して、２回目以降のコンパイル時間を削減するプログラム)
は環境によって不安定だったりする
･scalaコマンドによるスクリプト実行の際のスタックトレースは不親切。改善の余地あり
･ランタイムは(Javaそのものなので)安定している

辺りでしょうか。

>
> プログラムは、コップ本の文中にあったサンプル・プログラムですが添付します。
> コップ本からは、Source.fromFileの正しい呼び出し方が分からないので、
> リファレンスなどを探したいと思います。
>
>> 水島です。JVMのダイナミック言語に限った話ではなく(そもそもScalaは静的な言語ですし)
>
> 済みません、JVM ダイナミック言語と使ったのは、言語仕様がダイナミック言語と言う意味ではなく
> JRuby, Tython, Groovy のようにJVM上に構築した言語が、JVM ダイナミック言語と呼ぶのかと
> 思っていました（しかし、上記例の言語は、ダイナミック言語に分類されますね…）
> あるセミナで聞いた言葉を鵜呑みにして使ったのですが、あまり普及して無いようですね onz
> しかし、Scalaは、ダイナミック言語？　スタティック言語？　どちらなのでしょうか？

ダイナミック/スタティック(動的/静的)言語というのは、基本的に言語の分類に当たって使われる言葉で、
JVMの上であろうとそうでなかろうと変わりません。JRuby, Jython, Groovyなどは、変数や式に
静的な型が無い(=動的に変わり得る)ので、動的型付けや動的言語と呼ばれます。一方、JavaやScalaは
変数や式に静的な型があるので、静的型付けや静的言語などと呼ばれます。
# 個人的には、静的言語や動的言語という言い方よりも、静的型付けや動的型付け言語
# と呼ぶ方が好きですが。

--
Kota Mizushima
e-mail: hau5...@tree.odn.ne.jp,mizu...@gmail.com

[Mizoken001]

溝口です

水島さん回答ありがとうございます。
水島さんの回答には納得します。
とりあえずコンパイルしてから、スタックトレースを取ってみます。

> ・コンパイラは割と安定している(ただし、時々コンパイラが落ちるようなバグが見つかるが)

> ・コンパイラは遅い(おそらくコンパイラのアーキテクチャが原因)
> ・fsc(Fast Scala Compiler。デーモンとして常駐して、２回目以降のコンパイル時間を削減するプログラム)
> は環境によって不安定だったりする
> ・scalaコマンドによるスクリプト実行の際のスタックトレースは不親切。改善の余地あり
> ・ランタイムは(Javaそのものなので)安定している

> 初見ではよくわからないスタックダンプであり、不親切だというのはその通りだと思いますし、
> 改善の余地があると思います。ただ、読み方の基本みたいなものはあって、それさえ抑えて
> れば大体読み取ることができます。

多分、これは、私のような一般人には難しいと思います。
が、解読方法は、じっくり鑑賞させてもらっています。

> > 前の、java.lang.Exception: fsc failure　の異常終了もそうですが、
> > ScalaのRun Timeは、結構、弱そうな感じがしています。
>

> これは明確に間違っています。ランタイムに関してはほぼJavaそのままなの
で、Javaと同程度には

> 頑健です。fsc failureに関しては、fsc(のおそらくは通信関係の部分)の実装の問題であり、この部分の
> 実装がまだこなれていないという事ではあるのですが、これはランタイムとは直接関係無いです。

ここは、完全に主観の領域で、ランタイムに一抹の不安を感じただけですね。
コンパイルした実行ではないので、コンパイルしてから物申せは正しいと思います。
ただ、コップ本に書いてあった通りに実行しただけなモノで、
何が違うか良く割らないですね。

ただ、私は、Scalaには、好感を持っているので、
すぐ投げ出すつもりは無いので、
これからも御鞭撻を御願いします。

> ダイナミック/スタティック(動的/静的)言語というのは、基本的に言語の分類に当たって使われる言葉で、
> JVMの上であろうとそうでなかろうと変わりません。

そうですね。
この時点で、自分の用語の使い方の不用意さは謝罪してます。

> JRuby, Jython, Groovyなどは、変数や式に
> 静的な型が無い(=動的に変わり得る)ので、動的型付けや動的言語と呼ばれます。一方、JavaやScalaは
> 変数や式に静的な型があるので、静的型付けや静的言語などと呼ばれます。
> # 個人的には、静的言語や動的言語という言い方よりも、静的型付けや動的型付け言語
> # と呼ぶ方が好きですが。

　個人的に、「動的型付け＝動的言語」なのか？　の疑問符があり、

> > しかし、Scalaは、ダイナミック言語？　スタティック言語？　どちらなのでしょうか？

　の発言になりました。
　ダイナミック言語の本来の意味は、動的型付けではなく、動的にプログラムの制御構造が
　プログラミングされていく言語だと認識しています。
　つまり、フォイノンマン型で命令部を書換えながら実行していくプログラムが書ける言語
　と言う認識です（間違っていたら済みません）。
　つまり、動的言語で「動的型付け＝動的言語」は、
　あくまで短絡的な解釈ではないかと思ったわけです？
　関数型では、型付けが仕様の緒言なので同義語と言われれば、そおままですが…
　色々、奥が深い話な感じがしてきました
　一寸、初学者の私としては、この位で白旗を上げたいのですが、
　更なる、御鞭撻があれば、御願いします。

[Mizoken001]

溝口です。

　「JVM ダイナミック言語」の用語を使ったのは、
　ダイナミック/スタティック(動的/静的)型言語や、
　動的にプログラムを生成していく言語（マクロやクロージャ）とは別に
　JVM上に躍動的に展開されている言語環境と言う
　ほとんど意味の無いシンボルのような気がします。

　曖昧な用語を鵜呑みにして使用して
　少々、議論に混乱が生じてすみませんでした。
　反省しますので、以降、スレッドが生じないことを願います。

以上

溝内