　電子辞書ときたら、入力した直後には検索が完了しているのだ。初めての出会いはザウルス内の機能としての辞書で、それはそれは語数も貧弱なモノであったが、それでもこの時点で辞書を引くのを楽しく感じたものだ。決定的な出会いはオヤジからデータディスクマンをもらった時で、それはもう持ち歩いて引きまくったモノである。

　その後も紆余曲折あって、現在はPC上でDDWINというアプリを使って数十冊の辞書をズガーンと串刺し検索しまくっている。串刺し検索というのは、存在するすべての辞書から単語を検索するというもので、一発で複数の辞書の記述を得るコトができるのだ。あぁ、文明開化バンザイである。

　しかしながら串刺し検索をデフォルトとしていても、DDWINの串刺し検索では検索結果が辞書の登録順に表示されるために、先頭に登録しておく辞書の選択は重要だ。私の場合、国語系、英語系と辞書グループを分けているが、国語系の筆頭は「広辞苑」、英語系の筆頭は「リーダーズ＋プラス」である。

　広辞苑はココでオイラが紹介するまでもないが、リーダーズ＋プラスの破壊力の凄まじさは体験しておいて損はないぞ。例えばスコッチ名がゾロゾロと出てきてしまうのである。

Talisker n. 【商標】 タリスカー 《スコットランド Skye 島唯一の蒸留所 Talisker Distillery 製の 12 年熟成のモルトウイスキー》.
Glenmorangie n. 【商標】 グレンモランジー 《スコットランド高地地方産の 10 年熟成のモルトウイスキー; モルトにしては驚くほど軽く香りがよい; Glenmorangie Distillery 製》.
Glenfiddich n. 【商標】 グレンフィディック 《スコットランド高地地方産の 10 年熟成の高級モルトウイスキー; Glenfiddich Distillery 製で William Grant & Sons (⇒→GRANT'S_) 社が販売; 1887 年より製造; ゲール語で「鹿のいる谷」の意》.

　このリーダーズ＋プラス、元は2冊の辞書から構成されているために一部重複する項目もあり、Glenfiddichに関しては片方はHighlandモルト、他方はSpeysideモルトと記述にバラつきがあったりするのを発見してしまったが、それよりなによりスコッチ名がゾロゾロ出てくるっていう時点で尋常ではないのである。さすが、プロ翻訳家が手元に置く辞書という触れ込みはダテではないのである。

　そんでもって「MC68」なんて引いてみたらこうであるッ!!

MC6800 n. 【電算】 MC6800 《米国 Motorola, Inc. の 8 ビットマイクロプロセッサー》.
MC6809 n. 【電算】 MC6809 《Motorola, Inc. の 8 ビットマイクロプロセッサー; 6800 シリーズの最上位機種で, 俗に 6800 GT ともいう》.
MC68000 n. 【電算】 MC68000 《Motorola, Inc. の 16 ビットマイクロプロセッサー; レジスターは 32 ビット構成》.
MC68010 n. 【電算】 MC68010《Motorola, Inc. の 16 ビットマイクロプロセッサー; バスレジスターの構成は MC68000 と同様だが命令セットが拡張されている》.
MC68020 n. 【電算】 MC68020 《Motorola, Inc. の 32 ビットマイクロプロセッサー》.
MC68030 n. 【電算】 MC68030 《Motorola, Inc. の 32 ビットマイクロプロセッサー; メモリー管理ユニット (MMU) を内蔵する》.
MC68040 n. 【電算】 MC68040 《Motorola, Inc. の 32 ビットマイクロプロセッサー; 浮動小数点演算ユニット・メモリー管理ユニット (MMU) を内蔵する》.
MC68881 n. 【電算】 MC68881 《Motorola, Inc. の MC680x0 マイクロプロセッサー用の数値演算コプロセッサー》.
MC68882 n. 【電算】 MC68882 《Motorola, Inc. の MC680x0 マイクロプロセッサー用の数値演算コプロセッサー》.

　 ……MC68000の「16ビットだがレジスタは32ビット」とかMC68030の「MMU内蔵」とか、どーしてまー、そこまで書くかねぇ、という状況である。「Z8」って検索すれば、

Z80 n. 【電算】 Z80 《米国 Zilog 社の 8 ビットマイクロプロセッサー; Intel 社の 8080 に対して上位互換性を有する》.
Z8000 n. 【電算】 Z8000 《米国 Zilog 社の 16 ビットマイクロプロセッサー》.

　これも必要十分な項目が出てくる。欲をいえば「Z80A/B」、「Z8」や「Z80000」なんて項目があってもいいと思うが。こんな調子だから「INTEL」なんて検索したら言わずもがなである。

　まー、そんなコトをしつつ、スコッチを舐めつつ、今日もEAGLEをイジるのである。とりあえず、発注したい基板のデザインは完了したのだが、あくまで全体の作業構成を確かめるために試しただけという状態である。というのも、本格的にOLIMEXに発注するには、最初からOLIMEXルールともいえる設計ルールに則って作業するのが近道だからだ。で、ここでもやっぱり問題はライブラリなのである。ライブラリ内にはドリルの穴も、シルク印刷の文字の太さも、既に定義されてしまっているため、それを載っけて作ってしまったら、後で修正するのは大変なのである。

　というトコロで発見したのが、このEinstein's electronic lab内のEAGLE for OLIMEXというページにあるスクリプト「libconv.ulp」だ。ライブラリのパーツ単位でバシッとドリル穴のサイズやシルク印刷の文字の太さを変更してくれるスグれモノである。……しかしながら、試しに基本的な抵抗パーツを変換したところ、シルクの太さは変わるのだが、どーにもドリルのサイズが変わっているとは思えない……というか事実、変わってない。結局、マニュアルを読まずに、スクリプトを解析するハメに。文法は概ねCライクなのだが、よくわからん制御構造があるし、イジっては様子を見るを繰り返す……まるで、意味もわからず、あちこちイジり回して謎を解くゲームMYSTをやっているようだ。

　結局、ulp(User Language Programs)ファイルというのは、単純なバッチファイルであるscr(SCRipt)ファイルを作り出すマクロ言語だというコトがわかり、パーツの修正はコマンド＋座標指定にて行われるコトがわかり、ドリルサイズが変わらないのは、ドリルの位置がシルクの位置と重なっている場合に、シルクに対してドリルのサイズ変更コマンドが作用しているためとわかった……つかれた。修正版のlibconv.ulpを置いておく。

　で、ココいらでヤメておけばいいのだが、ふとライブラリをパーツ単位で変換するのが面倒に思えてしまった。思えてしまったら止まらない。あろうコトかライブラリを一括変換するプログラムの開発を始めてしまう。試行錯誤でやっていると……イカン、スクリプトを変数に溜め込む現状のままのつくりだとEAGLEがメモリを食いつぶして固まってしまう。あー、イライライライライライライライラ。

　毎度のコトだが、どーにもオイラは環境にコダワって、本筋の作業を先に進めない性格のようだ。例の232メモリの開発を差し置いて、それを補助するオシロのアプリを書き始めてしまうし……。すべてのプロジェクトが発散しつつあるなぁ。とほほほ。

[ツッコミを入れる]

2006-02-07(Tue) メモリに安心させられる

　注文していたメモリが届いた。まぁ、しかし……なんだこのパッケージは。コンドームじゃあるまいし。そんなに思い切りデカデカと「安心」なんて表示をしなくても……そりゃ確かに、オイラもそれを一番大事な要素と考えて購入したんだけどさぁ……。

　しかし、例によって箱を開けると内容物は小さい。下手に大きいとノートPCの中に入らなくて困るので、そりゃ通常サイズであってほしいが、1万円も出したのにかかわらずこの大きさ……金を出した甲斐がないったらありゃしない。今は亡き、ハイウェイカードを5万円分買った時の約20%にあたる落胆ぶりである。

　 PCを裏返しにして、ネジを3箇所外し、表に返し、キーボードを持ち上げると、メモリ増設スロットが現れた。で、ちょっと緊張しながら、挿し込む……前に、流しで蛇口に触れておく。これは、静電気でメモリが破壊する恐れがあるので、必要とされている儀式であるが、静電気でメモリを破壊してしまったという人の話を聞いた事がないのはナゼだろう？　ここは一発、電子ライターのパッチンで、要らないメモリにプチサンダーを落とし、動作確認をしてみたいところである。意外と平気なんじゃないの？

　余談であるが、似たような儀式に「車のヘッドライトの交換時、電球には手を触れない」というものがある。なんでも、点灯時に付着した手の油脂が蒸発して、電球が割れることがあるらしい。しかし、私は以前に雑誌の特集で、コッテリとバターを塗りつけて点灯させてみた実験記事を読んだことがある。別に、電球は割れなかったという話だ。ちゅーわけで、そーゆーわけである。

　さて、増設して好きなだけウィンドウを開いて作業をしてみた。んが、コミットチャージは750MBを超えない。そりゃ、そうだよな。事前に確認してみた時でも700MBを越えるあたりがやっとだったんだから。せっかく増設したが、増設分の75%が遊んでしまっている状態である。

　しかし、だからといって1GBの増設が無駄で、512MBの増設で十分だったというわけではない。昨日書いたように、近年のOSは搭載メモリの遊んでいる部分をすべてディスクキャッシュに利用し、パフォーマンスの改善に役立てるからである……Linuxだけでなく、Windowsでもそうなんだよね……？　まぁ、試してみりゃいいのである。

　 cygwinから大き目のファイルのハッシュ値を求めてみよう。ハッシュ値を求めるのは、ファイルの内容をすべてナメ、全領域にアクセスさせたいだけで、今回の場合はそれ以上の意味はない。ちなみに、ファイルは30分のmpeg1ビデオファイルで1つ300MBだ。

SUZAKU:/MyDocuments/My Videos/megaten $ ls
合計 612920
-rwx------+ 1 mitsu 筏 313814368 Feb 20  2005 0220megaten1.vcd.mpg*
-rwx------+ 1 mitsu 筏 313814368 Apr 10  2005 0410megaten1.vcd.mpg*

　まずは、1回目。ハードディスクのランプは点きっぱなしになり、17秒弱を要した。

SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0220megaten1.vcd.mpg
f1b51c53ee2ebd5bb97bf6dc9abdbee3 *0220megaten1.vcd.mpg
　
real    0m16.929s
user    0m4.806s
sys     0m1.301s

　そして、2回目。ハードディスクのランプは点灯せず。前回の半分以下の7秒強で終了。

SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0220megaten1.vcd.mpg
f1b51c53ee2ebd5bb97bf6dc9abdbee3 *0220megaten1.vcd.mpg
　
real    0m7.092s
user    0m5.027s
sys     0m1.181s

　念のため、3回目。ハードディスクのランプは一瞬点灯。しかし7秒強で終了。

SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0220megaten1.vcd.mpg
f1b51c53ee2ebd5bb97bf6dc9abdbee3 *0220megaten1.vcd.mpg
　
real    0m7.253s
user    0m4.876s
sys     0m1.361s

　今度は別のファイルを試す。ハードディスクのランプは点きっぱなしになり、20秒強を要した。

SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0410megaten1.vcd.mpg
65c2d0261cd90151f1bd06fc63c3c5df *0410megaten1.vcd.mpg
　
real    0m20.343s
user    0m4.566s
sys     0m1.141s

　別ファイルの、2回目。ハードディスクのランプは一瞬点灯。前回の半分以下の7秒弱で終了。

SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0410megaten1.vcd.mpg
65c2d0261cd90151f1bd06fc63c3c5df *0410megaten1.vcd.mpg
　
real    0m6.897s
user    0m5.117s
sys     0m1.111s

　念のため、もう一度。7秒弱で終了。

SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0410megaten1.vcd.mpg
65c2d0261cd90151f1bd06fc63c3c5df *0410megaten1.vcd.mpg
　
real    0m6.966s
user    0m4.917s
sys     0m1.321s

　最初のファイルを再度やってみる。7秒弱。

SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0220megaten1.vcd.mpg
f1b51c53ee2ebd5bb97bf6dc9abdbee3 *0220megaten1.vcd.mpg
　
real    0m6.876s
user    0m4.917s
sys     0m1.311s

　どうやら、Windowsでも搭載メモリの遊んでいる部分は、すべてディスクキャッシュとして利用されるようである。この実験をやった時のコミットチャージは約740MB。利用可能メモリは約870MB。上記のファイルは2個で合計600MBであるが、ディスクアクセスはなかった。つまり、600MBがスッポリとキャッシュされているということである。一方で、もしメモリを1Gしか搭載してない場合は、利用可能メモリは約360MBになるだろうから、上記を交互に実行すれば、毎回ディスクアクセスが発生するはずである。

　それはそうと、メモリを大量に積んだので、アプリ立ち上げ放題なのはよいのだが、問題はタスクバーである。幅が足りずに切り替えボタンが出てきてしまうのである。これはどうにかしないと、不便で仕方ない。まっとーな案としては2段に増やすのがよいのだろうが、それももったいない……なんか名案はないものか、トホホ……。

[ツッコミを入れる]

2009-02-07(Sat) Fedora9、電子工作チューン外伝

　今日は、昨日に用意したパーツを利用して、RS232Cの簡易ラインモニタ装置を作るのである。

　余談ではあるが、先日、ガッツリとした棚を購入して、部品の取り出し効率を極端にアップすることに成功した。しかしながら、どうしても必要な部品の選定にはそれなりに時間がかかってしまう。そこで、ハンダ付けは「常に『遊んでぇ!!』とプレッシャをかけてくるイッペイ(3)」が寝ている時に進めるとして、彼が起きている間は、LEDをピコピコさせたりして気を引きつつ、一緒になって部品の選定をし、作業時間を稼ぐのであった。

　イッペイ(3)が寝た後、小一時間でLEDの取り付け以外は完了。今回のコンセプトはカスタマイズ。ピンヘッダの設定により、RXまたはTX、あるいは両方を選択的にモニタできるほか、左右のケーブルをピンヘッダ経由とすることで、容易にクロスケーブルバージョンに変更可能である。

　しかし、当初「ラインモニタ」でググったら、高そうな機器がゾロゾロ出てきて思わずアワてたぞい。えぇ!? 単にRXかTXをフツーのPCのシリアルポートにぶっ込むだけじゃダメなのッ!?　安易に考えすぎてたか……と思ったが、別に安易に考えすぎてて正しかった。この機器によって、予定通り、RXかTXをフツーのPCのシリアルポートにぶっ込み、特別なAPなしに、フツーの端末APでモニタできたし。

　モニタの目的は、秋月のPICライタAPのリバースエンジニアリング。実際、Linux用にPICライタ(ハードウェア)を作るのと、どっちが手間かはわからんが、高価なゼロプレッシャーソケットと、パッと開いてスグ始められる自作のEX-USB-CPシステムを有効活用しない手はない。とりあえず、Linux用のライタAPの作成に向け、少しバンガってみるのである。

　久々にWindowsPCを立ち上げる。見ないうちに、また秋月のPICライタAPのバージョンが上がっている。せっかくだからライタのファームを最新に上げてからモニタすることにしよう。

　と、ちょっとモニタしたところで、昨日コンパイルしたQt-BSch3Vの使い勝手がオイラ的にはかなりイマイチだということに気づいた。

　 XPortでちょっとした工作をしたいだけなのだが、次々に周辺環境の構築に手を出しているオイラである。そのうち工房付きの家まで建てかねないな。では。

[ツッコミを入れる]

2018-02-07(Wed) 卓上カレンダ継続

　気がつくと「卓上カレンダにムキーッ!!」としてから、1年半も経っているが、その後も、自宅でも職場でも楽しく便利に自作のカレンダを継続利用している。

　今回は、対象月の前後の小さな日付表示を追加しつつ、懐シューティング特集として、ワンポイントのイラストとフォントを揃えてみた。どれも熱中してプレイした名作ばかりだが……うぉっ、1作品だけコンティニュークリアだったような気も……リベンジしたくなってしまった。

　生成されたPDFを置いておく。

[ツッコミを入れる]

2024-02-07(Wed) 原作のとおりという難しさ

　「姫様"拷問"の時間です」って、なんなんだ？「暗殺教室」に負けない不穏なタイトルだな……と思って、期間限定公開されている原作のマンガを読んだら……そんなアプローチがあったとは。こういうナンセンスギャグ、好きなんだよなぁ。すっかり気に入ってアニメを観たら、コレがまた恐ろしくデキがいい。声優さんが熱演すぎるし、1話の最初と最後にソレをそう持ってくるとは。

　一方で「BASTARD!!」だ。2期がテレビでオンエアされると聞いて、初めて1期の後半をスルーしてしまっていたことに気づいたわ。原作がメチャクチャ好きなのに、デキが微妙であまり乗れなかったんだよな。で、2期の第1話を観たら……寝かけたよッ!! なんでだよッ!! 1期の1話の感想と全く同じだよ。原作の漫画を読み返すと、原作の方が圧倒的にグッとくるトコロまでッ!!

　軽く「原作のとおりに映像化」っていうけれど「BASTARD!!」は特段の改変もなく「原作のとおりに映像化」されている。でも、何だかわからないが全然ダメだ。一方で「姫様"拷問"の時間です」は、映像化で何倍も輝きを増しているのだ。この差はなんなんだ？

　考えてみれば簡単なことだ。うまく「翻案」するかどうかだ。いま「脚本家」が渦中にあるが(以下、この文章では原作の映像化に関するあらゆる関係者をまとめて「翻案家」と呼ぶ)、映像化で作品が輝くかどうかは「翻案家」の手腕がほぼすべてなのだ。まさに、上記の例で自分が実感したことだ。「翻案家」は実にスゴい仕事なのだ。「原作のとおりに映像化」なんて簡単に言うけれど、視聴者に「原作のとおりに映像化」だと感じさせるためには、恐ろしくスキルや工夫が必要なのだ。それはきっと並大抵のことではないのである。

　例の事件に関連して「ただ原作を脚本化する仕事は楽しくない。自分のオリジナリティを発揮するために原作を改変したくなるのだ」という発言を見かけたが、本当にそんなことを思っている翻案家がいるのだろうか？上記の例のように、改変なんてしなくたって、オリジナリティを発揮する場所なんていくらでもあるように思えるのだ。例えが適切かはわからないが、ヴォーカリストはオリジナリティを発揮したいからといってメロディや歌詞を改変して歌ったりはしないだろう？歌い方ひとつで、オリジナリティを発揮する場所なんていくらでもあるからだ。

　今回の事件では「原作の改変」に起因して原作者が自殺に至ってしまったとされているが、詳しい経緯について知りもせずに、脚本家の「9,10話を書いたのは私でなく原作者」というコメントが直接の引き金であるかのように語られている。自分はそれに強烈な違和感を感じるのだ。

　そこに至るまでにはいろいろあったのだろうけど、脚本家が言いたいのは「9,10話のデキが悪いのは私のせいではない」ということだろう？ 9,10話のデキついて少なくない批判を受けたからで、それは脚本家から仕事をムリヤリに奪い取った原作者側が招いた結果だ。改めて考えれば原作者が脚本家にダメ出しして脚本を書くって、前代未聞ではないのか？脚本家は猛烈に不快だっただろうことは想像に堅くない。それはやっていいことだったのだろうか？そこに至るまでにはいろいろあったのだろう。に、してもだ。

　「ハンロンの剃刀」という言葉がある。「無能で説明できることに悪意を見出すな」という意味だが、それは「悪い結果は悪意の結果と思いがちだ」という傾向の裏返しでもある。原作者としてドラマの出来に不満があったのはわかるが、もしかしたらそこに必要以上の悪意を見出したりしてはいなかったのだろうか。

　というのも、いくら他人の仕事がマズくても、それが自殺の引き金になるとは思えないんだよね。脚本家から仕事をムリヤリに奪い取ってまで書いた脚本だけど、それでも思ったような結果を残せなかったことの方が、はるかに大きなダメージを受けそうに思える。そりゃ、脚本家に任せていてもよい結果にはならなかったのかもしれないが、餅は餅屋。そこは立ち入るべきではない領域だったのではないだろうか。各々の領域のプロとして、リスペクトが不足していたのはお互い様だったのではないだろうか。

　自分は自宅を注文住宅として建てたが、刻一刻と進んでいく建築現場で「そこ違う！」ということが何度もあった。しかし、そう思った時点でそう仕上がってしまっているわけで、よほどでなければその修正は言い出せない。複数の人がスケジュールに従って動いていて、その成果物をどうこうするのは半端なく難しいのだ。今回、その結末から、原作者側に立った意見ばかりが溢れていて、そのほとんどは至極もっともな意見なのだけれど、翻案側の価値や立場をまったく考えないのも違うだろうと。

　つうか、それはそれとして、現在も進行形で松本ワールドをぶっ壊し続けている福井晴敏を誰か糾弾してくれッ!! アイツこそ、なんなんだよッ!! ……ほら、そこッ!! 無関係だと思っているガンダマーッ!! 彼奴がファーストのリメイクの脚本家になってから泣いてもしらんぞッ!!

　追記。なんだか出版社に問題があったという話になってきている。あー、そっちなのか。そっちもよくない話を漏れ聞くよなぁ。作家ファーストでない出版社なんて存在できないと思っていたが、なんか存在してそうな話だなぁ。まぁ、エンジニアファーストでない企業なんて普通に存在してるからなぁ。

[ツッコミを入れる]