[#14185] ruby on Linux/m68k — akira yamada / やまだあきら <akira@...>
[#14196] fork() on MacOS — nobu.nakada@...
なかだです。
[#14206] undef_method :method_missing — Kenichi Komiya <kom@...1.accsnet.ne.jp>
なかだです。
なかだです。
金光です。
むらけんです.
金光です。
金光です。
金光です。
金光です。どもっ。
むらけんです.
なかだです。
金光です。どもっ。
金光です。
金光です。FOXとかもあるのかぁ。すげぇなぁ。
まつもと ゆきひろです
金光です。御大、待ってましたっ。
なかだです。
金光です。どもどもっ。
なかだです。
さくです。
まつもと ゆきひろです
金光です。どもっ。
まつもと ゆきひろです
金光です。どもどもっ。
まつもと ゆきひろです
岩月と申します。
金光です。どもっ。
岩月と申します。
むらけんです.
楠です
むらけんです.
有馬です。
金光です。
有馬です。
金光です。どもっ。
とみたです。
金光です。
とみたです。
金光です。
まつもと ゆきひろです
金光です。(^_^;
あづみです。
有馬です。
金光です。
有馬です。
金光です。どもっ。
有馬です。
むらけんです.
むらけんさん wrote:
むらけんです.
長沢です。
まつもと ゆきひろです
金光です。どもっ。
有馬です。
金光です。どもどもっ。
むらけんです.
金光です。いちおうフォローだけ
ふなばです。
一応フォローだけ、ほんとにちょっとだけっすよ
[#14229] [BUG] segv on [str].pack("p") — Koji Arai <JCA02266@...>
新井です。
なかだです。
新井です。
なかだです。
[#14338] setup.rb (Re: Common GUI framework) — Minero Aoki <aamine@...>
あおきです。
[#14382] [BUG] segv on regex matching with long string — TAKAHASHI Masayoshi <maki@...>
高橋征義です。
[#14390] [Patch] pp.rb and debug.rb — "NAKAMURA, Hiroshi" <nakahiro@...>
なひです。
In article <DJEGJLCFNEIMKDNMLFPHCEPJCAAA.nakahiro@sarion.co.jp>,
なひです。
まつもと ゆきひろです
In article <DJEGJLCFNEIMKDNMLFPHCEPJCAAA.nakahiro@sarion.co.jp>,
あおきです。
In article <20010809221751J.aamine@mx.edit.ne.jp>,
なひです。書き忘れ。
なかだです。
nobu.nakada@nifty.ne.jpさんの
なひです。
なかだです。
In article <DJEGJLCFNEIMKDNMLFPHMEAHCBAA.nakahiro@sarion.co.jp>,
なひです。
In article <DJEGJLCFNEIMKDNMLFPHEEAICBAA.nakahiro@sarion.co.jp>,
なひです。
まつもと ゆきひろです
In article <997774251.527258.14423.nullmailer@ev.netlab.jp>,
まつもと ゆきひろです
In article <997783083.657819.14685.nullmailer@ev.netlab.jp>,
なひです。
In article <DJEGJLCFNEIMKDNMLFPHEEALCBAA.nakahiro@sarion.co.jp>,
なひです。
In article <DJEGJLCFNEIMKDNMLFPHEEAPCBAA.nakahiro@sarion.co.jp>,
なひです。
In article <DJEGJLCFNEIMKDNMLFPHMEBACBAA.nakahiro@sarion.co.jp>,
なひです。
In article <DJEGJLCFNEIMKDNMLFPHIEBBCBAA.nakahiro@sarion.co.jp>,
うぅむ。ぼーっとしてたら意味もなく Subject を変えてしまった。
In article <20010817205051.UAZHC0A8274C.C78F0C8A@mail.biglobe.ne.jp>,
あづみです。
In article <hvo66bnxe4b.fsf_-_@flux.etl.go.jp>,
古い話題で恐縮ですが…
なかだです。
In article <200109290948.f8T9mbh12942@sharui.nakada.kanuma.tochigi.jp>,
なかだです。
まつもと ゆきひろです
In article <1001945748.240863.24023.nullmailer@ev.netlab.jp>,
なかだです。
In article <200110020334.f923YLb08299@sharui.nakada.kanuma.tochigi.jp>,
なかだです。
In article <200110021010.f92AAIb13474@sharui.nakada.kanuma.tochigi.jp>,
なかだです。
まつもと ゆきひろです
まつもと ゆきひろです
なかだです。
まつもと ゆきひろです
In article <1002080461.740444.11187.nullmailer@ev.netlab.jp>,
なかだです。
まつもと ゆきひろです
なかだです。
まつもと ゆきひろです
なかだです。
まつもと ゆきひろです
あづみです。
[#14406] typo in ruby 1.7 — Koji Arai <JCA02266@...>
新井です。
[#14413] 1.7.1 2001-08-06: if true && /match/ — WATANABE Tetsuya <tetsu@...>
渡辺哲也です。
[#14465] Ruby/Bsearch — akira yamada / やまだあきら <akira@...>
まつもと ゆきひろです
At Wed, 15 Aug 2001 18:01:50 +0900,
"Akinori MUSHA" <knu@iDaemons.org> wrote:
In article <20010816001456V.satoru@namazu.org>,
Tanaka Akira <akr@m17n.org> wrote:
In article <20010816130056C.satoru@namazu.org>,
[#14480] avoid compile warning of tcltklib with VC5 — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
なかだです。
こんにちは、なかむら(う)です。
[#14505] BUG: ruby 1.6.4 cannot use threads on Sparc (segv) — akira yamada / やまだあきら <akira@...>
[#14530] restore terminal mode even if readline interrupted. — Koji Arai <JCA02266@...>
新井です。
新井です。
新井です。
新井です。
At Wed, 5 Sep 2001 00:19:51 +0900,
まつもと ゆきひろです
[#14552] read in IO#eof? — nobu.nakada@...
なかだです。
[#14575] infinite loop on Dir.glob("*/**/*") — nobu.nakada@...
なかだです。
[#14577] option nodynamic — Daisuke Aoki <dai@...>
青木@横浜です。
[#14595] SEGV at `$0 = "long long string"' — nobu.nakada@...
なかだです。
なかだです。
まつもと ゆきひろです
[ruby-dev:14277] Re: Common GUI framework(Re: Virtual Machine)
まつもと ゆきひろです
ま、面白いのでもう少し静観しようかとも思ったのですが、私の意
見を聞きたい人もいるでしょうから。
まず第一に金光さんの考えていらっしゃるのはSmalltalk(より具体
的にはSqueak)なんでしょうが、Rubyはそれとは違う道を歩みます。
ですから、
VMにGUI機能(たとえbitbltでも)は追加しません
GUI機能はVMではなく、拡張ライブラリで提供されます。これは将
来とも絶対に変わりません。
さて、次に標準GUI(フレームワーク)についてですが、これもあら
かじめ断言しておくと
私がなにかを標準にすることはありません
それとこれもはっきりさせておきたいのですが、私が音頭をとって
Ruby独自のフレームワークを作ることもありません。
これらの理由はいくつかあります。
* まず第一に言語とGUI機能はある程度直交するものだからです。
特にRubyはJavaとは違いプラットフォーム独立な独自の世界を
作ろうというアプローチではなく、プラットフォームのやり方
をRuby流に取り込む方向性があるのでなおさらです。
また、GUI関係は言語に比べて寿命が短いのも問題になりえま
す。OpenLookって聞いたことありますか。SmalltalkのGUIって
流行遅れって思ったことはないですか?
* 第二に、私自身が正しい標準GUIプラットフォームの設計がで
きるほどGUIにこだわりがないことです。私は正しい言語設計
を行う知識と経験と自信がありますが、GUIに関しては知識は
あっても経験も自身もありません。
* 第三に、誰もRubyを「標準スクリプト言語」に選んだわけでは
ありませんが(あ、コンダラの人たちはそう呼んでるんだっけ)、
でも私たちの多くはスクリプト言語を使うときにはRubyを使う
ようになっていることと思います。GUIフレームワークもそれ
と同様に生存競争に勝ち残って登場すべきだと思います。
* 第四に、GUIに対するニーズも、バックグラウンドになるプラッ
トフォーム機能も実は多種多様でなので、すべての人が満足し、
かつ十分に移植性もあり、パフォーマンスも出るGUIプラット
フォームというのは現実的ではないのではないかと考えていま
す。追求するのは自由ですし、止めませんが。
* 最後にトレードオフについて考えたいと思います。仮にRuby独
自のGUIフレームワークを作りはじめたとして、それによって
得られるものは「RubyでGUIを作るならこれさえ覚えれば十分」
という安心感です。しかし、そのために「多大な開発コスト」、
「十分でないパフォーマンス」、「最大公約数的な(時として
不足する)機能」などのリスクが伴います。また、Ruby独自と
いうことは、自分であらゆる苦労を背負込むことでもあります。
ですから、「これが標準」というのではなく、結果的にデファクト
スタンダードを形成するのが望ましいと思います。また、最初に述
べたようにGUIと言語がある程度独立であることを考えると、Ruby
だけでそれに取り掛かることは賢明ではないと思います。
世の中にはプラットフォーム共通のGUIフレームワークの試みはFOX
であるとかWxWindowであるとかたくさんあるのですから、そういう
ものが欲しければ、そちらと共闘すべきと思います。そして、それ
に対する使いやすいRubyインタフェースを用意する、必要に応じて
それらフレームワークにコントリビュートする、そういうのがRuby
流のオープンなやり方ではないでしょうか。
で、みなさんの満足の行くGUIフレームワークが見つかるなり、完
成するなりした時点で、それを「(当面の)推奨GUIフレームワーク」
と呼ぶことはできるでしょう。
まつもと ゆきひろ /:|)