原則匿名で公開・個人情報は送られません。必要に応じ御署名/非公開希望をお書き添え下さい。
_ 掲示板:YaPW 旧掲示板 SMIL Boston日本語訳(頓座)
久々のお便り紹介です。
何か面白げな話ししてますな > 写像
とりあえず議論の行方を生暖かく見続けて行きたいと思います。
んー。面白い議論ではあるんですけどねぇ。話の発散ぶりに、ちと困っている部分もあります。日記だと逆リファレンスしにくいとかいう事情があったりするので。
もしかするとWikiとか、あるいは自動で逆リファレンスの追加される掲示版とかの方が欲しくなってきます。
ちうことで、そーゆー掲示版のたぐいの情報求む。
あれこれと検索語に反応してみるのこと。
_6本充電できる充電器
私のしる限り、秋月電子通商にそのようなキットがあります。完成品でも、東京だったら秋葉原界隈をめぐれば何店かは取り扱っている模様。
_C言語 文章 単語切り出し
使っている言語によりますが、アルファベット系の文章なら簡単です。ってことは、それが問題ではないわけですね(笑) 良くは知らんですが日本語でしたらKAKASIやら茶筌やらを調べてみて下さい。実は何げに手前味噌なシロモノのC言語版が存在していたりする(公開はしていない)のですが、アルゴリズムからして希望されるような結果が出せるものではないかと思います。
_perl 16進 10進
そのようなPerl/Tkスクリプトなぞ公開してたりします。参考までにどうぞ。別に一段落、というわけではないんですが、さしあたり収束ぎみなのはそうですね。
以下、いくつか気になった点などを。
_リンク先について。"http://white.niu.ne.jp/Freetalk/" は、時間経過と共に変化していくページです。静的な参照としてリンクを張る場合、"http://white.niu.ne.jp/Freetalk/0105a.html#110204a"のように、対応するログファイル側に張るようにしてください。
_前提について。
私の言うところの「表現」は、ほぼ"expression"に相当する言葉です。「外に(ex)出されたもの」――すなわち、作者とは切り離されてしまった存在であると考えてください。
使い方として微妙なのは、そこから引き起こされる結果までも「表現」と称してしまうからだと思います。以上が私の文章を読むときの前提。
付け加えるなら、影王さん言うところの「表現」は"representation"に相当するのだと思います。あるいは、そこから引き起こされることは含まれていません。
――そりゃ話も食い違うような気もしますが、それはそれとして。どーしても不満なら、「表現」という語を全部「記述」とでも読み換えてください。それでだいたい意味は通りますから。
_存在意義について。
端的な話をします。表現に存在意義などありません。少なくとも、私は存在意義と言う観点ではこの議論を見ていません。私が知りたいのは、「作者と表現」あるいは「表現と読者」という関係において、何が起こるものなのか、ということだけです。
繰り返します。意味も理由も関係ありません。ただ、表現に読者が触れるということが、どういうことであるのか。その理解が欲しいだけです。
「完成した表現」というのは、そのような文脈で用いた言葉です。表現が読者に触れるとき、その由来は関係なく、それを構成する記号だけが意味を持ちうるのですから。
「完成」という語が悪いのなら「確立した」とでも読み変えてください。
_一般的には……拡大解釈。
まったく同じ話になりますが、一般的であろうがなかろうが、読者が表現に触れてそれが起こるなら、それは表現が起こすものです。あるいは、表現には意味も理由もなく、それゆえ主体を持つ必要もありません。あえて主体を求めるなら、「神の表現」「この時空連立体の表現」「世界の表現」etc. どうとでも言えると思いますが。
_自己同一性の話に関しては了解しました。少なくとも、そのような機能があることは推察できるところですから。
_作品内世界に、作品外世界の自然科学の扱う客観世界の法則が適用できるなんて、誰も言っていません。作者の主観世界が投影されていようといなかろうと、作品内世界は作品内世界であって、断固として作品外世界とは別物です。大前提です。
そんなの当然です。ちなみにこの場合の作品外世界とは、作者や読者や私や影王さんが存在する、と思われる世界のことですが。
閑話休題。
作品内世界があるとしましょう。その作品内世界が作者から出てきたものであったとしても、作者がそれを作品内世界と認識した瞬間から、作者もまた作品内世界から影響を受けることを免れ得ません。
ここに至って、作品内世界が未だ作者の意図である、という前提は崩れています。それは確かに脳の刻印により汚染されたものではあるかもしれませんが、それが作者とは(完全でないにせよ)別のものであると認識できる点で、決定的な独立性を持っているものであるとも思うのです。
確かに作者の手元にある限り、その世界からは作者の意図ばかりが引き出されるかもしれません。このとき、作者と作品の間に、不確定性はないのでしょう。しかし、それが作品に組み込まれた形で作者の手から離れて読者の手に渡ったとき、そこから何を読み取るかは読者の自由です。汚染されてはいても、その独立性のゆえに、作品と読者の間に不確定性は発生します。
とかなんとか書きましたが、そもそもこの話自体が私の側の前提が通ってないからでてきたようなもんなので、さしあたりこのへんで中断しときましょう。いろいろ突っ込むと、面白そうな話ではあるのですが。
メーラにはmewを使用していたりするわけだが、日本語の添付ファイルが読めない。これが仕事で非常に困る、ちうわけで検索。
ちうことで、もっといいアルゴリズム知ってる識者を求めて話題を広げてみるテスト。
表題通り。
スクリプトの先頭に、こんな感じのコードを置いておく。
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
ということで、先日言ってたような掲示版作ってます。同一システム内の題名に全部リンク張って、逆リンクも張って、っていうやつ。
一応メイン部分は動くようになって、あとはHTMLレベルの見た目をきれいにするとか、負荷軽減のためのあれこれだとか、せめてロック機構ぐらい導入しろだとか、そういうところなわけですが。
週末までにはお見せできる程度のものにする予定。
自分用メモ。あれこれとやること・やりたいこと。
当然ながらデバッグモード時のコードをそのまま残しておくと、プログラムの実行が若干遅くなる。そういうときに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。
あるいは単に「動作原理知りたい」から作るような場合もありますけどね。
有志で資金を出し合ってサーバをハウジング、なんてことをしてたりするのですが、そこの下位ユーザ用のログインシェル(パスワード変更のみ可能)なんてものを作るために、検索。
半ば予想はしていたけど、一番使えたのは元指導教官様のページでございましたとさ(^^;
データの配置とかそういうこと以前に、ガンパレの場合はメモリとの戦いが厳しいんだと思います。ひょっとすると、「他の部分をぎりぎり載せられるメモリ量」から人数が逆算されてるんでないのかと思うぐらい。通常画面とメニュー画面のそれぞれのコードを両方載せてる余裕はないのでしょう。
というか、AI部分を守るために、他のすべてが犠牲になってるという印象。主メモリはAI+キャッシュで、CDを半ばメモリのように使い……というどう考えてもイカれたことをやってるような感も。それを成立させるために、PSにしてはえらく強力なCDエラー回復機能もついてたり。
ちなみにPS2でやると、違いがわかるぐらいには快適になります。
誰がなんと言おうと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は最初からネットワーク越しを前提にした構成をしているからだ。
ということで、この項続く、かもしれない。