アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
Waba (スコア:2, 興味深い)
スレッドとかサポートしてなかった気がします。
しかし、OSASKにWabaっていうのは結構良い取り合わせだと思いました。
あくまで1FDで動くことに対するこだわりを感じます。
Re:Waba (スコア:3, 参考になる)
言わないですね。WabaSoft自身が否定しています。
> スレッドとかサポートしてなかった気がします。
確かに初期のWabaはかなり制限されたサブセットでしたが、
sf.net版は、longも浮動小数もスレッドもサポートしています。
初期のWabaスレッドは、周期コールバックとでもいうようなもの
でしたが、現在はOSのスレッドを使うようなコード(の、かけら)も
あります。
たぶん、最後の壁はathrowです。これが実装されれば、Javaコンパイラ
が吐くバイトコードを解釈するVMとしては、とりあえずの機能を満たせる
のではないでしょうか。
# 最近、コードにタッチしていないけどID
from もなか
Re:Waba (スコア:1)
＃今動いてないみたいですが多分このURLで合ってる。
Wabaがいいのは、その小ささ素朴さもさることながら、
最初から移植性を意識して機種依存部分そ非依存部分をきちんと分けたかたちで
ソースが提供されてる、って点かなーと個人的には思っています。
そのへんの事情は、Waba乗りラピュータのページに詳しいです。
で、ならばと探してみたら、上記リンク集(?)にあるように、移植した奴が有るわ有るわ…
>言わないですね。WabaSoft自身が否定しています。
んですね。Wabaは(Kaffeのとってる立場ともまた一味違って)「サブセット」と呼ぶべきものかと。
>sf.net版は、longも浮動小数もスレッドもサポートしています。
本家はもう止まってるですね。sf版がどんどん進んでる。
なので、システムを大きくしたくないときや、沢山ソースを読み書きしたくないとき(笑)は、今でも本家版かなー。
新しい奴だと俺の古いPalmに載せるのが辛いっす。
＃ただ本家版は、Hash系のクラスやhashCode()メソッドが死んでるのが悲しい。
＃「データの照合」のコストは、wabaが対象とするような弱い処理系では特に、気にする必要があると思うんで、
＃当初から(Nativeで)実装されてりゃ良かったのになーと思う次第。
さて。今回の奴ですが、Waba乗りラピュータのページを参考にした
(中見てないけど、文面から察するにソースもそのまま流用してる？)
ということは、ベースはsf版じゃなく古典本家版なわけですね。
うん。可愛い移植だという意味では「わーい」ですが、
PCのような「大きな」環境(このOSの技術的事情は知らないんでアレですが)をターゲットとする場合、
本家版wabaだと、微妙に寂しいかなと…と、つい思ってしまいます。
まあきまぐれまぎちゃん [geocities.co.jp]などの市販ソフト(違うぞ)が
そのまま動いてくれるのは少しだけ嬉しいけど。
>たぶん、最後の壁はathrowです。これが実装されれば、Javaコンパイラ
>が吐くバイトコードを解釈するVMとしては、とりあえずの機能を満たせる
>のではないでしょうか。
JavaByteCodeは知らないんですが、athrowってのは例外投げのことですか？
＃自作言語では、whileループより例外のほうが先に実装された(=作るのが「楽」だった)ので、意外な気分のG7
＃一緒になるとは限らないんだろうけど、まあ…
Re:Waba (オフトピ) (スコア:1)
Wabaに対する謎の一つですね。そんなに難しくなかっただろうし、
コストもかからなかったであろうはずなのですが。
// 仮にsf.net版の実装に間違いがないと仮定して、の話。
> JavaByteCodeは知らないんですが、athrowってのは例外投げのことですか？
cf. http://mrl.nyu.edu/~meyer/jvmref/ref-athrow.html
実装の難易度より、catchにかかる演算コストを嫌ったということではと
思っています。無くても致命的ではないですし。著しく不便ですが。
from もなか
Re:Waba (オフトピ) (スコア:1)
> 思っています。無くても致命的ではないですし。著しく不便ですが。
例外なんだから、遅くてもいいじゃん、と思いました/思ってます。出来ない、よりマシだと思うのですが。
Re:Waba (オフトピ) (スコア:1)
肥大傾向のsf.net版を議論の叩き台にするならおっしゃる通りかもしれませんが、オリジナルのWabaSoft版についていえば、コードを読んで、むしろ正しい割切りと感動しましたがねぇ、私は。
WabaVMはJavaVMではなく、JavaVMと同じ機能を載せればJavaVM並に大きくなるのは理。
from もなか
Re:Waba (オフトピ) (スコア:1)
個人的には、例外→遅い→あまり使わないようにしよう、という一部の(特にC++勢の:-P)論調は、どうも好きになれません。
例外を使うべきかどうかはプログラムのデザインの問題であって、
遅いから避けるなんていう前近代的なことは、あんまりすべきじゃないと思う。
＃Javaがシンドいのはthrowsを書かないとならないからであって、throwが悪いわけじゃない、と思っているのでG7。
＃DelphiはJavaとほぼ同じモデルのExceptoinがあるけど、throwsに相当するものは無い。
＃Javaのthrowsって一見便利かなと思ったんだけど、実際やってみるとどうにもメンテナンスがしんどい。
で、例外の需要が増せば、最適化屋さんも頑張ってくれるかなーと、期待してみたり(^^;
それにしても、そんなにコストかかるものなんでしょうか。
まあ言語の構造(に引きずられての各処理系実装の構造)に拠るんだろうけど。
Re:Waba (オフトピ) (スコア:1)
>コストもかからなかったであろうはずなのですが。
逆に言えば、NativeでなくPureJavaでhashCode()を実装しろ…しかも低コストで…なんて命じられたら
俺なら泣いて詫び入れるかも知れません。
Cなら、ポインタを数字にゼロコストで読み替えできるCならではの芸当を使えばいい一方で、
PureJavaだとObject自体の識別子(謎)を数値に置き換えるリーズナブルな方法が無い(よね)…
そういや、同じことを考えたのか、Newton用実装ではhashCode()を追加してあるんでしたよね。
余談：
PascalつーかDelphiの「順序型」が順序型であるのが、痛烈に悲しい。
デジタルに識別可能な型であっても順序が定義(?)できない型は、
たとえばcase文(Cのswitchみたいな奴)に使えない。
おかげで、「Object参照をcase文に使う」ということが出来ない。
これは凄く残念。たかだか数個のオブジェクトのうちの「どれか」が来るのを判別するという場面で
うだうだif文を書かないとならないわけで…
caseが取れるのが「順序型」であるという決まりって、もしかしてDelphiより昔の古典Pascal、つまり
オブジェクトとか同一性同値性云々とかいう概念に世間が注目するよりも「前」に考えられた決まりなんだろうね。
ここも今っぽくリファインしてくれたらよかったのに＞Delphi
Re:Waba (オフトピ) (スコア:1)
sf.net版では、Newton用を参考にしてhashCode()を実装しました。
from もなか
Re:Waba (スコア:1, 興味深い)
PCで動かすことを前提にするなら、1CD位がちょうど良いと思うのですが。今なら、FDドライブもCDドライブも調達する具合は変わらないと思うし。
組み込みを目指しているなら、わかるのですが。
Re:Waba (スコア:0)
FDに入る大きさにすることで、とにかく小さくするという目的も達成できるし。
Re:Waba (スコア:0)
Re:Waba (スコア:0)
Re:Waba (スコア:1)
>スレッドとかサポートしてなかった気がします。
２年ほど前に WinCE 上にて Waba を遊んだ際は、java.lang.String がなくて、文字列の取り扱いが独自実装だったのがかなりの痛恨でした……
下位互換でもいいから java.lang.String 的にして欲しかった、というのが Waba に対する最も強い印象でした。そーすれば通常の JSE 用とロジックまわりくらいは共通で書けたのにー。
今ではそのあたり変わっているのでしょうか。