Whiteのふりーとーく

2001年5月後半

About this Page |過去分一覧


原則匿名で公開・個人情報は送られません。必要に応じ御署名/非公開希望をお書き添え下さい。


_ 掲示板:YaPW 旧掲示板 SMIL Boston日本語訳(頓座)



5.16

@ものすごい発散。

久々のお便り紹介です。

何か面白げな話ししてますな > 写像

とりあえず議論の行方を生暖かく見続けて行きたいと思います。

んー。面白い議論ではあるんですけどねぇ。話の発散ぶりに、ちと困っている部分もあります。日記だと逆リファレンスしにくいとかいう事情があったりするので。

もしかするとWikiとか、あるいは自動で逆リファレンスの追加される掲示版とかの方が欲しくなってきます。

ちうことで、そーゆー掲示版のたぐいの情報求む。

@卒論

なんか毎日のように「SunRPC + セキュリティ」やらで検索がかかってくるので、卒論(PDF版)を上げておきます。院生の研究に乗っかってるので単体では意味なしですが。ちなみに研究室のページはこちら。

@検索反応

あれこれと検索語に反応してみるのこと。

_6本充電できる充電器

私のしる限り、秋月電子通商にそのようなキットがあります。完成品でも、東京だったら秋葉原界隈をめぐれば何店かは取り扱っている模様。

_C言語 文章 単語切り出し

使っている言語によりますが、アルファベット系の文章なら簡単です。ってことは、それが問題ではないわけですね(笑) 良くは知らんですが日本語でしたらKAKASIやら茶筌やらを調べてみて下さい。実は何げに手前味噌なシロモノのC言語版が存在していたりする(公開はしていない)のですが、アルゴリズムからして希望されるような結果が出せるものではないかと思います。

_perl 16進 10進

そのようなPerl/Tkスクリプトなぞ公開してたりします。参考までにどうぞ。

@ひらめき

仕事してて不意に思う。

前述のような自動で逆リファレンスされる掲示版って、ソフトウェアの状態遷移管理とかするのに便利かも。

@目標。

WEBアニメスタイルが熱い。黙って読め。

5.17

@

別に一段落、というわけではないんですが、さしあたり収束ぎみなのはそうですね。

以下、いくつか気になった点などを。

_リンク先について。"http://white.niu.ne.jp/Freetalk/" は、時間経過と共に変化していくページです。静的な参照としてリンクを張る場合、"http://white.niu.ne.jp/Freetalk/0105a.html#110204a"のように、対応するログファイル側に張るようにしてください。

_前提について。

私の言うところの「表現」は、ほぼ"expression"に相当する言葉です。「外に(ex)出されたもの」――すなわち、作者とは切り離されてしまった存在であると考えてください。

使い方として微妙なのは、そこから引き起こされる結果までも「表現」と称してしまうからだと思います。以上が私の文章を読むときの前提。

付け加えるなら、影王さん言うところの「表現」は"representation"に相当するのだと思います。あるいは、そこから引き起こされることは含まれていません。

――そりゃ話も食い違うような気もしますが、それはそれとして。どーしても不満なら、「表現」という語を全部「記述」とでも読み換えてください。それでだいたい意味は通りますから。

_存在意義について。

端的な話をします。表現に存在意義などありません。少なくとも、私は存在意義と言う観点ではこの議論を見ていません。私が知りたいのは、「作者と表現」あるいは「表現と読者」という関係において、何が起こるものなのか、ということだけです。

繰り返します。意味も理由も関係ありません。ただ、表現に読者が触れるということが、どういうことであるのか。その理解が欲しいだけです。

「完成した表現」というのは、そのような文脈で用いた言葉です。表現が読者に触れるとき、その由来は関係なく、それを構成する記号だけが意味を持ちうるのですから。

「完成」という語が悪いのなら「確立した」とでも読み変えてください。

_一般的には……拡大解釈。

まったく同じ話になりますが、一般的であろうがなかろうが、読者が表現に触れてそれが起こるなら、それは表現が起こすものです。あるいは、表現には意味も理由もなく、それゆえ主体を持つ必要もありません。あえて主体を求めるなら、「神の表現」「この時空連立体の表現」「世界の表現」etc. どうとでも言えると思いますが。

_自己同一性の話に関しては了解しました。少なくとも、そのような機能があることは推察できるところですから。

_作品内世界に、作品外世界の自然科学の扱う客観世界の法則が適用できるなんて、誰も言っていません。作者の主観世界が投影されていようといなかろうと、作品内世界は作品内世界であって、断固として作品外世界とは別物です。大前提です。

そんなの当然です。ちなみにこの場合の作品外世界とは、作者や読者や私や影王さんが存在する、と思われる世界のことですが。

閑話休題。

作品内世界があるとしましょう。その作品内世界が作者から出てきたものであったとしても、作者がそれを作品内世界と認識した瞬間から、作者もまた作品内世界から影響を受けることを免れ得ません。

ここに至って、作品内世界が未だ作者の意図である、という前提は崩れています。それは確かに脳の刻印により汚染されたものではあるかもしれませんが、それが作者とは(完全でないにせよ)別のものであると認識できる点で、決定的な独立性を持っているものであるとも思うのです。

確かに作者の手元にある限り、その世界からは作者の意図ばかりが引き出されるかもしれません。このとき、作者と作品の間に、不確定性はないのでしょう。しかし、それが作品に組み込まれた形で作者の手から離れて読者の手に渡ったとき、そこから何を読み取るかは読者の自由です。汚染されてはいても、その独立性のゆえに、作品と読者の間に不確定性は発生します。

とかなんとか書きましたが、そもそもこの話自体が私の側の前提が通ってないからでてきたようなもんなので、さしあたりこのへんで中断しときましょう。いろいろ突っ込むと、面白そうな話ではあるのですが。

@悪貨は良貨を

メーラにはmewを使用していたりするわけだが、日本語の添付ファイルが読めない。これが仕事で非常に困る、ちうわけで検索。

_Kanji Filename Handling
とりあえずそのものずばりに、不正な日本語ファイル名エンコーディングを扱うためのMew拡張。当方Mew version 1.94.2にて動作を確認。
_なんでもかんでも添付しないの
添付ファイル全般に関する注意書き集。どちっかてーと初心者向けだけど、良くまとまった印象
_添付ファイルにおける日本語のファイル名に関して
RFCに基づいた現状についての技術面からの指的。

5.18

@最小値。

そういうときは一応GA(遺伝的アルゴリズム)とかの出番だと思うんですが、極値の多さがなんとも不向きな感じ。ただ、それこそ全検索できる世界ではないし、やっぱりそういう「許容しうる精度の近似解」を求めてから、必要があれば最適解を(範囲絞って)全検索、ということにはなるかと思うんですが。

ちうことで、もっといいアルゴリズム知ってる識者を求めて話題を広げてみるテスト。

@言ってみるもの

GAは極値(局所最適)にとらわれないからいい手法なんだけど(^^;

シミュレーテッドアニーリング(SA)の脱出戦略をうまく設定して、並列に実行するか、GAを使うのが最近の主な探索手法です。

むむ。そういわれればそうだったような気も>GAの特性。いや、なにぶん漠然としか覚えてないので、そんなところまで記憶から引き出されるはずもないのです(弱) 

それはともかく、検索かけてみました。SA + Simulatedで出てきたのがこんなとこ。なるほど。

ちうことで、よろしければ参考になどしてみてください>ひらしょーさん。


5.21

@豆知識:PerlによるCGIスクリプトのデバッグ

表題通り。

スクリプトの先頭に、こんな感じのコードを置いておく。

  if($ARGV[0] eq '-debug'){
      $ENV{QUERY_STRING}   = "subject=test&body=入力テスト";
      $ENV{REQUEST_METHOD} = "GET";
      $CGIDebug = 1;
  }

CGIを実行し、エラーが出た場合には、

 % ./sample.cgi -debug

としてスクリプトを実行する。一応これでCGIエミュレーション的な動きをしてくれるはずである。QUERY_STRINGには正しい入力例を設定すること。

それから、お行儀のよろしくない手抜き(POST決め打ちとかだ)をしていた場合には当然動かないわけである。

_それからここでは、"$CGIDebug = 1;"によってデバッグモードを表すフラグを立てている。立てているので、以下のようなコードをスクリプトに埋め込むと、デバッグモード時にのみ出力が得られたりする。

  print "debug mode" if defined $main::CGIDebug;

やけに文芸的な書き方なのはそういうもんだと思いねぇ。perlスクリプトかくあるべし、なのだ。

_応用として、以下のようにしてperlデバッガで動かすのもなかなかよろしい。使い方は頑張って調べること。

  % perl -d ./sample.cgi -debug

5.22

@掲示版

ということで、先日言ってたような掲示版作ってます。同一システム内の題名に全部リンク張って、逆リンクも張って、っていうやつ。

一応メイン部分は動くようになって、あとはHTMLレベルの見た目をきれいにするとか、負荷軽減のためのあれこれだとか、せめてロック機構ぐらい導入しろだとか、そういうところなわけですが。

週末までにはお見せできる程度のものにする予定。


5.24

@やること。

自分用メモ。あれこれとやること・やりたいこと。

  • HL-1240をLinuxで動かしてみるの顛末。
  • 謎掲示版ことLLLL(仮称)のドキュメンテーション。
  • ここの生成に使ってるスクリプトの公開。激しいスパゲッティとの格闘の要アリ。
  • いーかげんに回してる自作日記更新チェッカの再構築。

@豆知識の捕捉。

こないだの豆知識の捕捉。ちうか今思いついたんだけどさ(^^;

当然ながらデバッグモード時のコードをそのまま残しておくと、プログラムの実行が若干遅くなる。そういうときにPerl人(とは限らないけど)としてはどうすべきか。

そりゃもう全部コメントアウトしちまえばよいわけだ。

open(FILE,"$ARGV[0]");
@file = <FILE>;
close(FILE);
map {$_ = '#'.$_ if(/if defined \$main::CGIDebug/);} @_;
open(FILE,"> $ARGV[0]");
print FILE join('',@_);
close(FILE);

こんな感じのスクリプトを実行すれば全部コメントアウトできるはず。逆変換も似たようなスクリプトを使えばOK。


5.25

@衝き動かすもの

「自分で作りたい」には、「動作のわからないものを使いたくない」という要素も大きいんじゃないかと思います。自分で作ったものでなければ、動作はよくわからない。よくわからなくて見通しが効かなければ、自分のプログラムの見通しが悪くなる。

あるいは単に「動作原理知りたい」から作るような場合もありますけどね。


5.27

@因果。

有志で資金を出し合ってサーバをハウジング、なんてことをしてたりするのですが、そこの下位ユーザ用のログインシェル(パスワード変更のみ可能)なんてものを作るために、検索。

半ば予想はしていたけど、一番使えたのは元指導教官様のページでございましたとさ(^^;

@Inferno

なにげに(現実逃避も兼ねて)Infernoに手をつけてみる。こちらこちらを参考にしながら。

Windows君にインストール。インストール元(アーカイブの解凍先)のパス名に日本語を含めたりすると、インストーラがそこでコケる模様。注意。

pathにコンフィギュレーションを書き込んで、起動。半信半疑だったのだけど、本当に軽い。これで日本語環境さえあれば、WindowsなんてInfernoの肥しに貶めて、と思うほどには。

@

データの配置とかそういうこと以前に、ガンパレの場合はメモリとの戦いが厳しいんだと思います。ひょっとすると、「他の部分をぎりぎり載せられるメモリ量」から人数が逆算されてるんでないのかと思うぐらい。通常画面とメニュー画面のそれぞれのコードを両方載せてる余裕はないのでしょう。

というか、AI部分を守るために、他のすべてが犠牲になってるという印象。主メモリはAI+キャッシュで、CDを半ばメモリのように使い……というどう考えてもイカれたことをやってるような感も。それを成立させるために、PSにしてはえらく強力なCDエラー回復機能もついてたり。

ちなみにPS2でやると、違いがわかるぐらいには快適になります。


5.30

@VNC + VMware

誰がなんと言おうとVMwareは便利だが、とかくその画面描画の速度は問題になる。現環境(RedHat Linux7.0上でWindows2000 on VMware)だと、フルスクリーンモードでないとストレス溜って使う気がしない。

ということで、ふと一計を案じてみた。別の方法で描画してみればどうだろう。

かくしてVNCの登場である。ホスト(=Linux)とゲスト(=Windows2000)の両方にVNCをインストール。とりあえずWindows2000の方でVNCサーバを動かし、Linux側でクライアントを動かす。ちなみにマシン環境はCeleron733MHz,メモリ256MB(128MBをVMwareに割り当て)。

感覚としては、VMwareをウィンドウモードで使っているのとそう変わらない使用感。ややVNCの方がもったりしているかもしれない。

VNCではときどき描画がおかしくなったりする。これは、VMwareが根性入れてすべての画面描画を再現しているのに対し、VNCでは諦めて適当に描画をさぼっているせいだろう。ウィンドウをクリックすればだいたいの場合は直る。

流石に両方ローカルだと、VMwareを直で使った方がいいように感じる。ただし、VNCの方がX-Windowとの親和性が高い(と私は思う)点は見逃せないかもしれない。そのへんは好みによるだろう。

ただ、ネットワーク越しに使うような場合には差が出てくるかもしれない。VMwareがX-Windowsの限界に挑んでいるような感じであるのに対して、VNCは最初からネットワーク越しを前提にした構成をしているからだ。

ということで、この項続く、かもしれない。


御意見・御感想の宛先white@niu.ne.jp