劇場版Star trekでのタイムマシン

先日公開された劇場版Star trekでは時間をさかのぼり、未然に災いを防ごうという行為(今回の場合それがトンでもない方向に出ましたが)がありました。タイムマシンと言えば過去にさかのぼっても結果は変わらないのではないかLink の議論。元々Star trekの世界は似非物理なのですが、光子魚雷や遮蔽装置の仕組みなど、似非は似非なりに理屈を通さないと方々から突っ込むのがStar trekファンだったりしますw

今回はブラックホールに飲み込まれることにより時間を遡ったのですが、たどり着いたのは元とは別の平行世界の昔だという説明にしたいようです。つまり元の世界で起きてしまった災いは取り消せないけれど別の世界の昔なら話は別、結果を変えることができるはず、またはそもそも他の世界から来た者によって変えられてしまう予定の世界とも考えられます。

別の考え方をすれば、ある時点で世界が枝分かれする。そしてブラックホールを通じて、片側の世界からもう一方の世界の昔に干渉が入る。

これだと未来の結果は変えられないという問題には説明付きますが、一度枝分かれした世界が時間を経てまた同じ状態になる可能性はほぼ皆無。こんな世界の枝分かれが頻繁に起きていたら、いったいいくつの平行世界が必要か分かったもんじゃないという別の突込みが来そうです。

あ~、ややこしい。でもこれ、プログラムで言えばforkでブラックホールがスレッド間通信と置き換えれば、分かりやすい気がしませんかw > プログラマ様

— posted by mu at 06:08 pm   commentComment [0]  pingTrackBack [0]

 

劇場版Star trek

blog20090607-StarTrekPosterInSJ

私の好きな映像作品で最上位に来るのが、おそらくStar trekシリーズと初代トップをねらえ!です。自分でもなんだその組み合わせはと思いますが、似非宇宙物理と理屈じゃない精神物の詰め合わせが好きなんでしょう、たぶん。

つい先日、Star trek劇場版最新作の日本語字幕版が公開となりました。誘われたんじゃなくて、自分で観たい映画を観に行ったのは2年振りでしょうか。観客少な! 日曜日のレイトショーとはいえ、公開して初めての週末でこうですから、あまり長く上映されなさそう。早めに行って良かった。

シリコンバレー出張時にアメリカ人に聞いた限りでは、アメリカでStar trekはStar warsと並ぶ両雄、別格扱いみたいなのですが、ここ日本では両者の人気の差は歴然のようで。でも私はStar wars観ても「ふ~ん」位にしか感じないのよぉ・・・

Star trekシリーズには宇宙大冒険という邦題の付いた初代から、一番有名であろう2代目Next generationなど舞台の異なるいくつかのシーズンがあるのですが、今回は初代の番外編とでも言いましょうか、カークやスポックなど初代のメンバーが若い頃どうやって知り合ったのかという内容です。

実は私Star trekが好きではあるんですが、生粋のファンから見ればにわかファンでして、初代を観たことありませんw 一番観たのがVoyager、次がDS9ですがどちらも半分も観てない。Next generationに至っては劇場版しか観た事ないという有様 ^^;

なにせ1シーズンがどれも半端じゃない量の上、レンタルビデオでもなかなか見つからない。そして初代は作成された時期からして映像技術が古いことが容易に予想され、なんか興ざめしそうで避けてたんです。古いというのは日本で言うと昔のウルトラマンなどいわゆる特撮物、ワイアーで模型の飛行機を吊るして撮影とかそんな感じ。初代を観た事ないのであくまで想像でしかないのですが、アメリカでも「愛すべきしょぼさ」みたいな表現があるようなので、まぁあまり外れてはいないでしょう。

そんな初代知らずの私ですが、今回の劇場版はちゃんと楽しめました。CG使ってますし、ロミュラン宇宙船は相変わらず馬鹿でかい。ただ間違いなく、「あ、あそこにあの人物が!」みたいなシーンを見逃しているはず。知らないんだもんw

しかしStar trekの世界を知らない人にはお勧めできないです。ワープやエンタープライズ号くらいは前知識であるかもしれませんが、転送・ワープコア・バルカンとロミュランとかストーリー上重要な用語が何の説明もなく使われています。数秒で大爆発といったピンチを転送で救い出し敵さんだけさようならというのはStar trekではお約束の展開。今回も終盤に使われているのですが、知らない人は「なんだ、そのやり方は!?」と思ってしまうでしょう。

[2009/6/8 追記] 出張先サンノゼ市繁華街の映画館にあったパネルの写真を追加。Star Trek知らない人には、何の絵だか分からないんじゃないだろうかw

— posted by mu at 12:13 am   commentComment [0]  pingTrackBack [0]

Vostro 1500破損

blog20090531-Vostro1500Damaged

空港で床に落としました・・・・

思えば購入Link から1年半、デスクトップを隠居に追い込み個人用ゲームPCとして国内・海外に大活躍でした。あとはもうちょっと軽くて、ポインティングデバイスがトラックポイントだったら文句なしだったのですが。いままで、ありがとう!

・・・・まだ使えるってw 欠けた部分を瞬間接着剤でくっつけておしまい。落下時はクッション地のバッグに入れてあったのに。ThinkPadなら裸でこの程度の落下でも表面の傷くらいで終わりなこと多いんだけどなぁ。

— posted by mu at 10:19 pm   commentComment [0]  pingTrackBack [0]

 

マニラからPSU

blog20090530-PSUDisconnected

シリコンバレーから帰国Link 後、遅めのGWを取ってまたマニラに来ていたのですが、今日で帰国。んで、またシリコンバレーの可能性大って、ぉぃw

今回もGeForce 8600M GT搭載Dell Vostro 1500を持ち込んでPSUやっていたのですが、かなりつらいというのが結論。原因はひとえにネットワーク回線の遅さにあり、
  • 日本時間23~25時くらいは、1時間に数回切断する
  • エリアの切り替えに時間がかかり、他のプレーヤーから後れを取る
  • こちらの操作(武器の持ち替え・回復薬などの使用)に対して実行がひどいときには30秒近く遅れ、攻撃できなかったり追加のダメージもらって戦闘不能になる
  • 敵が倒されたという情報が遅れて伝わるので、既にいない敵に対して攻撃を繰り返す
などなど。これらが経験値が手に入らないという結果につながり、かなり効率の悪いプレーに(T_T)

今年は後数回ここに来ないといけないんだよなぁ、なんかいい解決方法無いかなぁ(かなり絶望的w)

— posted by mu at 04:27 am   commentComment [0]  pingTrackBack [0]

Tclのイベント処理が止まる

Tclにはイベントドリブンで処理を行う方法が用意されています。
proc record1 { } {
  global s
  gets $s data
  set f [open "c:/temp/record.txt" a+]
  puts $f $data
  close $f
}

set s [socket 127.0.0.1 8097]
fconfigure $s -blocking 0 -buffering line -translation auto
fileevent $s readable record1
vwait a

こういうコードを書くと、サーバ(この場合localhost)のポート8097に接続しサーバから送られてくるデータをファイルに保存していきます。fileeventがTclのイベント処理に登録するコマンドで、読み取り可能なデータが入ってくると関数record1が呼び出されるようにしています。vwaitが変数aに値がセットされるまでイベント処理を続けるコマンドですが、このコードには変数aをセットするところがありませんので延々とイベント処理が続きます。

一方Tcl環境をC#等Managedな環境と一緒に使う場合Tcl/CSharpLinkEagleLink といった間を取り持つ層を用いますが、Tcl/CSharpを用いて以下のことをやるとします。

  1. C#側でソケット接続を受け付けるようにする
  2. C#側で同じプロセスの別スレッドからTcl interpreterを作成する
  3. 作成したTcl interpreterから先ほどのC#で作ったソケットサーバに接続する
  4. Tcl側で上のようなfileeventを使う方法で、C#側とソケット通信する

なぜこんな変なことをするのかは聞かないで(^^;) 実際には通信を開始する前にTcl interpreterにはコマンド追加などさまざまな操作をしており、それが今回の問題を引き起こしているかもしれないのですが、その内容はここには書けませんw

ここで問題が発生しまして、

  • Tcl側でデータを一切受信しない。上の例で言えばrecord1が呼ばれません。
  • ソケット接続は行われるのでTcl側が全く動いていないわけではない。
  • telnetや即席のソケット通信プログラムを使用する限りC#側のソケットサーバーはデータを送信しているので、C#側に問題はない模様。
  • ソケット通信TclスクリプトをC#とは別プロセス(別途起動したtclshやwish)から立ち上げるとちゃんと通信する。
これを解決するためTclスクリプト側に以下を追加しました。
proc EventKeepAlive { } {
  after 100 EventKeepAlive
}
after 100 EventKeepAlive
(ここまでvwaitより前に)
100msecごとにEventKeepAlive関数が延々と呼ばれると言うだけで全く仕事をしないこの部分、これを追加するとC#と同じプロセスで作られたTclインタープリタでもちゃんと通信するようになりました。

理由、分かりません。こうやってTclのイベントを絶えず使っておかないと止まってしまうようです。ここLink 書いてあるスレッドが止まると言うことと原因は同じなのかなぁ。

この解決を見つけるまで.NET Frameworkのマルチスレッド処理がおかしいのではないかとかいろいろ大変でした。ただあまりに特殊なことをやっているためここに書いても同じ状況にぶつかる人がいるのか疑問ですがw

— posted by mu at 12:35 pm   commentComment [0]  pingTrackBack [0]

T: Y: ALL: Online:
ThemeSwitch
  • Basic
Created in 0.0207 sec.
prev
2025.3
next
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31