有限会社明日夢。浦和で進学塾を経営していた戸原さんが立ち上げたソフトハウスだ。当初HyperCardの学習ソフト及び便利なライブラリ集みたいなものを作成して売っていたと思う。前回出した家入さんを経由して、ここに服部宗弘さんや僕がかかわることになる。
LCやPerformaが出てMacが普及し始めた頃、Macオタクの僕らは「Macにエロゲーがない」事に心を痛めていた。
正確に言うと、海外輸入のヌード写真集もどきとか、MacPlaymateみたいなアメリカンエロソフトは存在したのだ。まだMacのソフトが輸入に頼っていた時代でもあり、税関のチェックがソフトウェアに及んでいなかったこともあり、秋葉原では直輸入のアンダーヘア丸出し洋物エロソフトが存在してはいた。しかしそれらはあくまでアングラ臭漂うグレー領域のものだったし、日本の若者に向けたアニメ、漫画風のエロは皆無だった。
アンチエイリアスのアルゴリズムというのはどっかに定番があるのだろうか。フォントだろうが図形だろうが、輪郭がギザギザにならないように、境界部分に中間色を配して滑らかに見せるテクニックは普通に用いられているが、ネットで検索してもなかなかその方法を解説した文書は見つからない。
そもそも多角形の内部を塗りつぶす方法は一般に走査線方式が用いられる。上から下まで水平線を走査し、多角形の辺とぶつかったら塗りつぶし開始、もう一度辺とぶつかったら塗りつぶし停止。要するに横に走査していって奇数番目の辺と交差したらピクセルを塗り、偶数版目の線と交差したらやめるというのが用いられる。このため、線が交差するような複雑な図形の場合、内部に塗られない島ができる。
問題となるのは、多角形の辺がピクセルを切断する場合だ。斜めの直線と水平の走査線の交点を整数に丸めてしまうと、１か０にきっちり分かれ、特定のピクセルを完全に塗りつぶすか、全く塗りつぶさないかの二通りになる。
アンチエイリアスを実現するためには、線が切断しているピクセルを、その切断部の大きさに応じた濃さのグレーで塗りつぶす必要がある。その方法として僕が考えたのは次の二通り。
前回の続き
さて、nekoDAの非独占的使用権を獲得しに来たIBMPacificの副社長だが、この人との会合はなぜだか覚えていないが、西川口の焼肉屋「安楽亭」で行った。Part1で書いたが、僕が初めてMZ-80に触れたのがハムショップであるつまり僕はハム（アマチュア無線家)だったのだ。そしてこの副社長氏もハムだった。nekoの契約の話は15分で済む物であったので、あとはハム談義に花が咲いた。僕は中学時代に免許を取り、アマチュア無線局を運営していたが、その後パソコンにはまったこともあって無線局免許を更新しないで失効させていた。当時のコールサインはJR7NKVである。アマチュア無線局のコールサインはJAから始まって、その後に地域を表す数字一文字、そして三桁のアルファベットが付くものだった。JAで表せるコードがいっぱいになって、JH、JRと追加されていった。東北は7エリアで、JR7NKVというコールサインは結構ベテランっぽいのだ。しかし僕はそのコールを失効させてしまった。無線局のコールサインは以前は使いまわさず、新しい物を割り当てていたが、この頃には、空きが少なくなって、失効したコールサインを新規の局に割り当てることになっていた。そんなわけで僕は自分の無線局を昔のコールサインで復活させることなど不可能と思っていたのだが、この副社長氏はJARL(日本のアマチュア無線家の総元締め)にも顔が利く大物らしく、
「いや、なんとかなると思いますよ、こちらからなんとかしましょうか」と簡単におっしゃるのだ。まあ、なんとかするといっても、もう住民票も7エリアにないのだし、実際には無理なのだが、大物振りを存分に発揮した人だったのである。IBMの管理職やる人はやっぱでかいぜ
前回の続き…
以前も書いたが、僕はLisaやMacが発表されたとき、あまり興味を持たなかった。カラーはないし高いし。要するにビジネス向けのコンピューターなんだという印象を持った。雑誌の写真ではない、実物のMacを見たのは、確か大学時代に友人と行った平和島のマイコンショーだったかなあ。CanonのDynaMac(当時Appleの代理店だったCanonが、本社の日本語対応の遅れに業を煮やして自前で漢字ROMを半田付けして発売したモデル）の画面に高層ビルが描かれていたのを記憶している。なにしろ一枚絵をただ表示していたので、GUIもへったくれもないのだが、なんか不思議に惹かれるものを感じた。
その後秋葉原でMacを置いている店を色々見て回ることになる。当時九十九電器とかではいつもチェック柄のボールが画面を高速で跳ね回るデモを流していた。ビジネスマシンっぽいけど、こんなに速いアニメーションができるのかと感心した。実はあれはアンディ・ハーツフェルドだか誰だかが、Amigaのデモをまねして「Macだってこれくらいできるぞ」とばかりに作った物らしい。よく考えるとあれはループアニメーションであり、当時のmacの画面はわずか20KBかそこらしかないので、全部のフレームをあらかじめメモリ上につくっちゃって、連続表示すればできることだったんだな。別にフレームごとに座標計算して書いては消ししていたわけではないのだ。ちくしょう、だまされたぜ。
前回の続き…
NAPLPS規格の特徴は、極力デバイスの物理解像度に依存しない仕組みを作っていたことであり、ピクセルにあたる単位をペルという抽象化された矩形にしたうえで、直線、曲線、多角形などを描画するものだった。ビットマップも描画できたが、伝送量の少なくなるベクトルデータを使用することが基本だったと思う。
newapのオーバーレイモジュールというのは、プログラム本体から呼び出される画面表示のための小さなプログラムである。いまならPhotoshopのプラグインに近い概念だと思う。これが行うべき処理はただひとつ。画面に塗りつぶした矩形を描くことなのだ。直線、曲線、多角形などは、この矩形を使ってnewnap本体が描画するのである。
この仕組みは描画速度という点では不利だと思うが、モジュールの作成は非常に簡単なのである。なにしろ四角形を描くだけなのだから。これはアセンブラで書いても全然面倒くさくないレベルの作業だ。
ついでに、モジュールには、コマンドラインオプションも渡される事になっていたので、これを利用してプログラム起動時にオプションを指定して画面モードやカラーの使い方を指示する事が出来た。MSX2の、高解像度で16色のモードを使うか、低解像度で256色のモードを使うか、さらにインターレースモードを使うかといったスイッチを仕込むことが容易に出来たのだ。
これはびっくりするほどの効果を得られた。Ｒｏｙさんの本体プログラムが偉いのだが、きわめて短いプログラムでさまざまなモードを駆使し、同じ画像を高解像度で表示したり、多色で表示したりできたのだ。僕にとって、MZ-80でのパックマン以来の面白いプログラムだった。
このころも僕は絵描きだったので、絵を表示するのではなく作成するプログラムにも興味はあった。NAPLPSデータを作成するお絵かきツールをBASICで書いたりしていた。名づけてNGM=Naplps Generator for MSX2。ただ、これはマウスを使って絵を描くだけではデータは完成せず、色々手動でデータを完成させる必要があったし、UIも洗練されていないものだった。
そんな時、僕はMacintoshに興味を抱く。秋葉原で見かけるMac Plus。店頭デモ機には大概MacPaintやSuperPaintがインストールされていた。いじっていると面白い。画面上端のメニューバーと、描画ツールを選ぶツールボックス、自在にスクロールできるウインドウといったものに惹かれていた。だが、いかんせんＭａｃ Ｐｌｕsが398000円の時代である。僕はMSX2でMacみたいなお絵かきツールを実装しようと思い立つ。
前回の続き…
僕が大学に入った頃、秋葉原はまさにパソコンの黄金期に入りつつあった。まだ8bit機も多い時代で、ショップにはNEC、シャープ、富士通、東芝、日立などなど、さまざまなメーカーのさまざまな機種が展示されていた。おおむねホビーには8bit、ビジネスには16bitという時代だ。8bitはやはり全体としてNECのPC88シリーズが強かったとはいえ、他社の機種にもファンが多く、群雄割拠の様相を呈していた。富士通はFM-7,77と出し続け、シャープはX1シリーズがホビー層に人気だったし、アスキーの提唱で各社が製造したMSXは、安価なゲーム機とパソコンの中間的な存在として若年層に使われていた。16bit機は早々にNECのPC98シリーズが主流になり、富士通のFM16βがしばらく頑張ってはいたが、やがて衰退していく。
貧乏学生の僕は、しばらくFM-8を使い続けていたが、とっくに古臭くなった機種であることが、逆に面白い状況を生んでいた。秋葉原のはずれのビルの二階にあった小さな店で、OS-9 for FM-8のパッケージを見つけた。覚えていないが、小遣いで買えるほど安くなっていた。8bit機で走る、本格的なマルチタスクOSをいじるのはわくわくしたものだ。とはいっても、結局「いじってみた」の範囲を出ることはなく、使いこなすにはいたらなかった。
以前2chに書き込んだパソコン遍歴を発掘した記事を書いたが、僕とパソコンについてもうちょっと書いてみたい。
最初にパソコンを見たのは、確か高校に入った頃ではなかったかと思う。
岩手県水沢市（現奥州市）、水沢駅の東側にあった、ハムショップJALCという、アマチュア無線関係のお店に、シャープのMZ-80Cが入っていたのだ。僕は中学時代にアマチュア無線（電話級）の免許を取っていたので、JALCという店は知っていたのだが、あるときいってみたらなんと、「コンピューター」が売っていたのである。
とはいえ、当時のMZ-80Cは268,000円。高校入ったばかりの少年に手が出る代物ではない。僕はJALCの親父に「これ、ちょっといじってもいいですか？」と聞いて、店先でいじっていたのだ。
googleで検索していて、2hに昔書いたレスを発見した。
9 名前： 後藤寿庵 投稿日： 2001/03/31(土) 08:03 ID:9tehTcQU
高校の時、ハムショップに入ったMZ-80Cをいじり倒してた。
そこで知り合った大人の人がAppleII持ってて、ハイレゾ画面で擬似的に
カナテキストを表示するのに感動した。ROMにアセンブラが内蔵
されてるのもすごかったし、キータッチの重厚さにも憧れた。
しかし、AppleIIは当時のくそ高いMZ-80Cよりなお高かった。
Macが出た時、ASCIIの記事で見て思ったのは、GUIのすばらしさでも
マウスのカッコよさでもなく、「なんでカラーマイコンの元祖
たるAppleがモノクロの事務機を出すんだ」という事だった。
実物を始めてみたのは、マイコンショーで展示されていたCanonの
DynaMac。スクリーンに高層ビルが描き出されていた。
その後だんだん憧れが膨らみ、MSX2でMacPaintっぽいインターフェイス
のドローソフトを開発しようと企むが、Mac起動時の「Welcome」のまねと、
メニューバーの実装まででメモリが足りなくなり、断念。そいでもメニュー
ピコピコ出して喜んでた。
初めて買ったMacはPlus、MacIIとSEが出た直後で、メモリも2MBに増え、
漢字Talkも2.0になって、以前より使えるようになっていたが、
あまりに高いのでハードディスクは買えず、内蔵フロッピーのみで
使用。メモリのうち800KBをシェアウエアのRamDiskに割り当て、そこに
起動ディスクを読み込んでRamDiskから使用するというわざを使って
いた。1年後に我慢できなくなってNovaの40MBハードディスクを購入。
これが寒くなるとグリースが固まってスピンアップしなくなるという
不良品(当時結構話題になった)。回らない時はディスク叩いたり
振ったりして起動させていた。
その後、Plus用アクセラレータのBrainStormを購入、これは
68000のクロックを倍に上げてくれるのだが、CPUの足に直にハンダ付け
したり、チップの足をニッパで切ったりして装着する、アクセラレータ
というよりMac改造キットといった代物。加えてあのPlusの構造で
CPU速度をあげれば、当然熱が篭って不安定になるので、秋葉原で
ジャンクのファンを購入(AC100Vで駆動するでっかいやつ)。取っ手のくぼみに
ガムテープで括りつけて使っていた。
$mysqldump -uuser -ppass --default-charaster-set=latin1 -Q --opt dbname >backup.sqlどうも海外サーバのデータベース使うと難儀だな。データベースのcharacter-serをutf8にしておいても、なぜかphpMyadminでエクスポートすると壊れている。blogなりcmsの上ではまともに日本語見えて使えているのだけど… とりあえず上のようにするとまともなデータで落ちてくるようだ。バイナリデータを16進にするには--hex-blob追加すればいいんだっけ？
現在のところIE(5.5以降)限定だが、Web上で縦書きを可能にするwriting-modeを使用すると、このような入力フォームでも縦書きができる。他のブラウザでは普通に横書きになっちゃうけどね。
すると、VB.NETとかでIEコンポーネント使って、なんちゃって縦書きエディタなんかも簡単にできてしまうのかな？
これといった利点はないが、漫画の台詞部分を縦書きHTMLで表現してみる実験。
CSS3(予定)のwriting-modeを使用しているので、IE5.5以降でないと縦書きにならない。
まあ台詞を画像ではなくテキストにすることで、翻訳版が作りやすくなったりするかも…でも
いい感じの編集ツールがないとブロック要素の位置あわせやらなにやらでかえって面倒になりそうだな。
僕は公式サイトを海外のレンタルサーバに置いているのだが、そこがMySQLを4.1.15にアップグレードし、データをバックアップ→レストアしたらしい。ある日突然blogがえらい文字化けだらけになってしまった。
最初は事情がつかめないまま、サポートに連絡し、状況を伝えたのだが、データベースとクライアントプログラムの文字コードを合わせてみてという類のアドバイスしかもらえない。ネットで色々調べて、MySQL4.0と4.1以降での文字コードの扱いが原因で色々トラブルが起こっていることを知ったので、Movable Typeのスクリプトをいじってみたりしたのだが、文字化けは解消しない。データベースの設定をphpMyAdminからいじって、参照順をLatin1からutf8に変えても解消しない。というか、部分的には日本語が残っていたものがすべてラテン文字に変換されて表示されるようになってしまった。
らちがあかないので、ダンプした古いデータベースのバックアップをくれるように交渉し、入手できたのだが、どうやらダンプした段階で化け化けになっているようだ。Latin1の設定のデータベースにutf8を突っ込んだものをダンプする際は、
sqldump --default-character-set=latin1
のようにオプションを指定してやることで、コード変換されずにデータを得ることが出来るということが検索でわかったので、これをサポートに伝え、あらためてダンプデータを送ってもらう。
結果、正常にutf8で日本語の記事が含まれたデータが入手できたので、データ内で Latin1と指定されている部分をutf8に置換。phpMyAdminから読み込ませて、やっとのことで復旧できた。
こういうとき、海外の会社との交渉は大変だなあ。
BIOSでCPU smart fan Tempを60℃、CPU Temp toleranceを2にしてみたら、CPU温度がすぐに７０℃を超えてしまう。うっかりすると72℃なんてこともある。ところが、CPU smart Fan TempをDisableにすると50℃台で安定。
どうもDisableにすると常にCPUファン3000～3500回転位で回っているようだが、これを60度に設定すると、すぐ回転数ゼロになり、相当温度上がってからゆるゆる動き出す。普段静かなのは言いのだが、Pen4 3.0EGzの基準を超えて温度が上がるのは問題だ。
最初の設定では、CPU温度60℃、＋2℃まで許容という意味だと思うのだが、実際にその範囲に収まるわけではなく、かなり余裕を持って設定しないとまずいっぽい。
温度設定をもっと低めにすればいいのかなあ。55℃にしてみるか。
ずいぶん長い間ソニーのトリニトロンモニターCPD-17FS9を使っていたが、最近ヘンな補色のゴーストが右に流れるように出るようになってきた。で、ほっといたら、昨日マンションの停電後、画面の色が完全におかしくなってしまった。ひどく緑がかって、目が痛い感じだ。しょうがないので、町田のヨドバシにモニターを買いに行くと、もはやCRTのモニターはほとんど姿を消し、パソコン売り場には液晶ばかり。というわけで、EIZOのFlexScan M170というやつを購入。いままで、CRTモニタの上にテーブルを乗せて、その上にスキャナなどを置いていたので、液晶にするとスキャナ置き場がなくなる。しょうがないので、テーブルの上に設置するパソコンスタンドを一緒に購入したのだが、いざ合わせてみると、机を縦に使っているという変則的なレイアウト、スピーカーが左右に内蔵されているタイプのモニタを買ったために、CRTのときより幅が広くなったしまったという条件が重なり、パソコンスタンドにうまく納まらなくなってしまった。しょうながいので、写真のように、
スタンドを縦置きにして、パソコン本体を右に配置、モニタは前に張り出すようなヘンなレイアウトになっていしまった。やたらと奥行きのある、旧型トリニトロンから、液晶にした意味が薄いなあ。まあいいか。
前に書いたようにB4出力可能で、リアル1200dpi のプリンタを探していたのだが、結局ヤフオクでA3レーザープリンタを入手することにした。
で、1200dpi出せるモノクロレーザーで定評あるCanonのLBPシリーズを狙って、LBP-910を入手することができた。ところで、このあたりの機種はオプションでLANなどのインターフェイスを追加することができるのだけど、ちょうどやはりヤフオクでLBP-1810から抜いたLANボードなるものが出品されているのを見つけた。これはぱっと見LBP-910などのLIO-V2用のカードに見える。なにしろ910と1810はほとんど同じプリンタといってもいいようなスペックで、最初からLANが内蔵されているかいないかの違いといってもよさそうなシロモノである。というわけで、イケルんじゃないかと思い、これも落札。今日すべてそろったのでセットアップに挑戦してみた。
漫画やイラストの仕事は、もはやほぼデジタルオンリーで問題ない状態になっているのだが、たまに紙に出したものが必要になる場合がある。
漫画の場合、B4出力可能なものが欲しいのだが、このクラスのプリンタは結構高いか、選択肢が少ない。A3出力可能なレーザープリンタというのが、モノクロの場合には最高の選択なのだが、これはやはり高いのだ。もっとも、リース落ちの中古品などなら、十分なスペックのものが安価に入手可能ではある。ただし、設置面積、体積の問題で、やはりちと苦しい。
この前書いたデジメモの件。
本体に付属の用紙もまだまだ残っているのだが、互換性のあるレポート用紙を近所の文房具屋で購入して試してみることにする。
写真でセットしているのは、エトランジェ・ディ・コスタリカという会社のA5版レポート用紙。横罫ではなく、方眼になっているので、絵描きにはこちらのほうが使いやすい。なかなかきれいにセットできるな。
こんな絵を描いて取り込んでみる。JPEGで書き出したものが
こんな感じ。漫画のネームくらいには使えるかも。ファミレスでネーム切って帰宅して繋げばすぐ取り込み。スキャナ使うより早いし、いいかもしれない。専用アプリケーションからメールで送ることもできるとか。まだ試してないけど。
ところで、CFカードだが、フォーマットはFATである必要があるようだ(FAT32はダメっぽい)。以前ニコンのデジカメ用に使っていたTDK製の64MBカードはPCで直接フォーマットしても使えず、デジメモに挿入した状態でのフォーマットも不可能だった。IO-DATA製のものはOK。SanDiskは説明書でも推奨しているので大丈夫だろう。512MBまでは使えるらしい。そんなでっかいのは持っていないので、未確認。
町田のドスパラで8980円で売っていたので買ってきた。
要するに一種のタブレットみたなものだが、パソコンにつないで描くのではなく、単独で描いて、後で画像を転送するというもの。描画エリアはポケットになっていて、レポート用紙のような、上で綴じているパッド形式のノートの台紙部分を差込んで使用する。付属のクリップを装着すればペラの紙を挟んで使用することもできる。だけどこのクリップなくしそうだな。
使い方は、装着した紙に付属のボールペンでなんでも好きなものを書く。本体のキーでページを進め、パッドのページをめくって新しい絵なり文章なりを描いていく。するとデータが本体のメモリにどんどんたまっていくので、あとはUSBケーブルでパソコンに繋げば画像データを取り出すことができる。ただし、画像は独自のフォーマットなので、専用のアプリケーションが必要。
本体には8MBのメモリが内蔵されているが、CFカードを使うこともできるので、容量は気にしなくてもいいようだ。
A5のパッド用紙が必要なのはちょっと使い勝手が悪いかも。B5が使えればそこいらのコンビニで売っているレポート用紙が使えるのだが。
先月、DVD-R上の壊れたデータをなんとかしようと、BadCopy Proをオンラインで購入したのだが、最初クレジット決済がうまくいかなかったのでもう一度申し込んだら、二本買ったことになってしまった。$39.5のソフト、二本で8600円になってしまい、ちょっとブルーだったのだが、こっちのミスもあるし、英語で交渉するのも大変なのでまあいいや、と思っていたのだ。ちなみに、決済画面では日本円に換算して、一本4300円との表示があった。
ところが、クレジットカードの明細を見て驚いた。4300ドル、 452,087円の請求が二本表示されているのである。あわせて約90万円なり!!
いばれた話ではないが、銀行口座にはそんなに入っていない。っていうかおい。これはドルと円まちがっとるがな。
あわてて決済会社とソフトハウス両方につたない英語で問い合わせのメールを送ったところだが、いったいどうなることやら。あとでカード会社の方にも連絡しよう。忙しいのにもう!!
ちなみに、決済会社はRegSoft.comというところである。みんなも気をつけような。
ためしにRegSoftで検索してみたら、灰羽連盟の安倍吉俊さんも同じトラブルにあっている模様…
(追記)
NICOSに連絡して調査してもらった。RegSoftの件では他にも同様の問題がおきているとのことで、話がスムーズに進んでいる。どうにか今月末の引き落としはストップしてもらって、この件を引いた額を来月14日に引き落とし、ということでまとまった。
まずは一安心。
僕のサイト
http://www.juangotoh.com/
http://www.sendouya.com/
ともに現在アクセスできません。これらのサーバにDoSアタックがあったらしく、一時停止し、マシンが復帰した後も
「アカウント停止」状態が続いています。問い合わせたところ、僕のサイトについて、エラーログが大量に生成されたため、止めているとの事です。前に書いたように、メールマガジンだかspamだかによる、大量の画像アクセスがあり、リファラではじくようにしていました。その結果403エラーが大量に発生していたと思われます。より詳しい情報をすぐによこすとの事でしたが、12時間たってもいまだ届いておらず、僕自身ftpにもアクセスできないので何もできない状態です。
juangotoh.com,sendouya.comのメールサーバも止まっているので、僕にメールを出したい方はこのblogのプロフィールから送信してください。こちらのメールアドレスはまだ使用可能です。
前の記事で、サンプル画像へのアクセスが極端に多いので、自宅サーバに移したと書いたが、よく調べたら、僕の利用しているプロバイダ(JCOM)はサーバ設置禁止なのだった。
ああもう。色々設定したのが水の泡。以前サーバOKになったと思ったんだけど、気のせいだったか……
結局、外部からのリンクを禁止する設定にして、もとのサーバにもどした。あと、メニューに表示されるサンプル画像の数を、最近の100枚から、20枚に変更。この辺の設定は様子を見て考えよう。
有料サイトを運営しているのだが、アクセスログをチェックしたところ、リファラに
by18fd.bay18.hotmail.msn.com/cgi-bin/getmsg
が記録されたアクセスが大量に発生していた。
リクエストの内容は、有料登録しなくても見られるサンプル画像。
これをあるだけごっそりもっていっている。しかも同時多発的に多数のホストから。
これによる転送量は一日約3GB!!
月間転送量40GBのサーバを借りているが、これではたまったものじゃない。
このリファラはなにかというと、hotomailのreadページなんである。
ここから飛んできて画像だけ持っていくということは、つまりメールに画像が貼られているということだと思うのだが、この大量同時アクセスは一体何事？？
考えられるのはどこかのspam業者がうちのサイトの画像を勝手に貼り付けたメールを大量にばらまいている、ということか。どんなspamなんだろう。残念ならが、僕のところには、僕の絵を貼り付けたspamは来ていない。
なんにしろ、この業者は、うちのサンプル画像を大量に貼っているわけで、なんか自分のところのコンテンツを偽っている可能性がある。というわけで、サンプル全てに僕のCopyright表示と、僕のサイトのURLをつけることにした。これが貼られれば、それらの画像が件のspam業者のものとは違うと言うことがわかると思うのだが、それでもアクセスは増えこそすれ、減る気配がない。
このままではやばいので、サンプル画像フォルダをローカルサーバに移した。もともとこちらの上り帯域は狭く、さらにmod_bandwidthで帯域制限しているので、重くなったと思うけど、背に腹は変えられない。
細線化アルゴリズム実験中
いまいちかなあ。
どうしても、線の接続点がなまってしまうので、繰り返しコピーをかけたようになっている。まあ、600dpi程度の解像度があれば、実際に印刷した状態ではこの程度の「なまり」は気にならないっちゃ気にならないけど。
これはよく知られたHilditchのThinningアルゴリズムをそのまま実装したもの。ただし、細線化の余地がなくなるまで繰り返す作業を省いているので、最初に１ドット削った段階で終了する。フィルターを繰り返しかければ、どんどん細くなるが、線が途切れたり、消えてしまうことはない。
以下は細線化の余地がなくなるまで繰り返しフィルターをかけたもの。
Photoshop用フィルタで、このての処理を行ってくれるものとして、Chris Cox氏制作のChris' Filtersに含まれるSkeletonフィルタがあったのだが、Mac版だけだったし、今では入手困難である。あと、昔ThunderScanに付属していた画像加工ソフトで同様の処理ができるものがあったと記憶しているが、定かでない。たしかBill Atkinson氏のソフトじゃなかったかしらん？
まあ、これ、あまり普通の人は使う機会のないものだが、マンガをデジタル処理する場合、スキャナで取り込んだ線画が「太る」という問題があるので、こういうのがほしいのだ。細い線はどうしても飛んでしまうか、太ってしまうかなので、飛ばないようにした上で、取り込んだ後でやせさせようというわけだ。
問題は、とにかく処理が重いことだな。グレースケールA4で取り込んだ、B5原寸サイズの線画全体にフィルタをかけて、終了するのに40秒余りかかっている(Celeron 1GHz)。
くまりんが 見てた !・ 結局は思考の欠如の問題かと OpenDocネタに反応してくれた方々へ
ちと古い記事だけど、なんか懐かしいなあ、OpenDoc。
デベロッパにとっては、簡単に安価なパーツを作って商売しても旨みが無さすぎだし、ユーザーにとってはそもそも意味がわからんシステムだったわけで、失敗は当然の帰結だったのかもね。
OpenDocとはなんぞや、っていうと、要するに書類を作成する環境と言える。従来の環境は、何らかのアプリケーションが上位にあって、書類がそれに従属する。Photoshopを立ち上げて絵を描き、保存する。OpenDocでは、書類の雛形をデスクトップから開くと、書類が開き、そのなかに自由に絵だろうが文章だろうが配置して編集できる。そのためのパーツがパレットに並んでいるというもの。概念としてはアプリケーション指向から書類指向への大きな転換を促すものであったといえる。書類指向という概念自体はLisaにあったんだけどね。
でもこれって、使ってみると、「指向」の転換には程遠いんだわ。要するにOpenDocアプリケーションが起動して、OpenDoc書類を開くというように感じてしまう。その中で操作する各パーツエディタはOpenDocというアプリケーションのプラグインだと考えればいい。現在なら、Webブラウザのプラグインみたいなものだね。Webページ上にムービーやらFLASHやらのコンテンツが表示されるさまはOpenDocの概念とほとんど一緒。
OS環境としてのOpenDocを成功させるなら、Finder自体をOpenDoc向きに書き換えなきゃいけなかった。Finderのファイルメニューから「新規」を選ぶとOpenDocコンテナが作成されるとかね。
ユーザーから見て、従来のアプリケーションとの違いが明確ではなく、かつ、微妙に操作感が異なるってのがOpenDocだった。これはなんつーかMac上で他の環境をエミュレートして動かすみたいな、隔靴掻痒の感覚を抱かせる。
で、リンクした記事で、思考の欠如ということが言われていたけど、結局のところMac(に限らず現代のパソコンというもの)は文房具であって、それは最低限の使い方を知っていればいいものなんだよね。たとえば100個のファイルの名前に連番をつけなければいけなくなったとして、「コンピューター」なんだから、便利な方法があるだろう、と考え、AppleScriptなりシェルスクリプトなりで自動化するというのは、文房具の一般的な使い方じゃない。
スクリプトを勉強して試行錯誤するより、Finder上で一個一個リネームするほうが速い。
OpenDocにしても、他のテクノロジにしても、従来の方法に比べて、明らかに便利になると示されない限り、多くの人は使わない。OpenDocについては、あいまいな将来像ばかりで、具体的な便利さがさっぱり伝わらなかった。PhotoshopでPainterのブラシが使えるようになるみたいなのは、たしかに実現すれば便利だろう。しかし、自分のアプリケーションにユーザーを囲い込みたいメーカーがやりたくないことの筆頭じゃなかろうか。ユーザーから見てそれは信用できない将来像だった。
それでもユーザーに使わせたければ、これはもう強制するしかない。ジョブズがかつてマウスを使わせるために最初のMacからカーソルキーを取り除いたように、MacOS Xを使わせるためにMacOS 9を棺おけに放り込んだように。極端な形、従来のアプリケーションを廃止して、OpenDocパーツだけを認めるという方法も考えられる。ただしこれは大きな賭けになるけどね。
MacOS X 10.3のファースト・ユーザースイッチに対応したドライバ(英語版)がリリースされている。今のところ日本語版は出ていないので、FUSで困ってる人意外はインストールする必要ないと思うけど、欲しい人はWACOM USAでどうぞ。
で、このバージョンでは、各ユーザーごとに設定を保存するようになっている。ユーザーが自分のアカウントで使用するときは、その設定が利用されるわけだ、ところが、ログインパネルが出ている状態では、誰のアカウントでもないということになる。ここでタブレットが使えないのでは使いにくいことこの上ないのだが、ちゃんとタブレットを使用できるよう、ログインパネル用の設定ファイルが/Library以下に置かれている。
さて、WACOMのタブレットは、ペンやマウスを使い分けられるようになっており、それぞれのデバイスごとの設定を保存できるようになっている。そのため、今まで使っていないデバイスでタブレットに触れると、デバイスを設定するよう促すダイアログが表示される。ユーザーは最初にペンを使うときや、最初に4Dマウスを使うときに、このダイアログを見て、タブレット設定用アプリケーションを起動する。すると、設定ファイルにユーザーの設定が書き込まれ、以後警告ダイアログが出なくなる。
ところが、これらの設定は各個人用の設定ファイルに記録されるため、ログインパネル用の設定は更新されない。したがって、ログインパネルが表示されるたびに警告ダイアログが表示され、これを出さないようにする標準的な方法が存在しないという困ったことになっている。
毎回ボタンをクリックすればいいのだが面倒だ。ログインパネルではデフォルト設定きめうちで設定を促さないようにするか、そもそも警告ダイアログを出した後、その段階のアカウントで設定アプリケーションを自動起動し、しかるべき設定ファイルを更新すべきじゃないかなあ。
試していないけど、すべてのデバイスを設定した個人用の設定ファイルをコピーして、共有設定に上書きすれば警告は出なくなるかもしれない。
従来のInterfaceLibではなく、CarbonLibをリンクする。
標準ライブラリなどもCarbon対応のものにする。
PiPLリソースのデスクリプタプロパティを変更する。内容は従来のppcプラグインのもの'pwpc'とそっくり同じでよいが、プロパティタグが'pwpc'ではなく、'ppcb'である。SDKに含まれるPIPL.rを編集してやるか、普通にビルドした後でResEditのHexエディタで直接リソースを書きかえてもよい。
プログラムをCarbon対応にするため、古いToolBoxコールなどは変更する必要がある。QDGlobalsなんかを使ってたり、WIndowPtrとDialogPtrとGrafPortを同じものとみなしたたりするものは書き換えが必要。
こうしてCarbon対応にしたプラグインをプラグインフォルダに入れれば問題なく使える。ただし、Classic環境でPhotoshopを起動した場合、プラグインは読み込まれない。Photoshop7以降のプラグインは、実はパッケージであり、内部にCarbon用とClassic用の二つのプラグインが入っている。これにあわせるには、
プラグイン本体フォルダ
--プラグイン(Classic)へのエイリアス
--Contents
----PkgInfo
----MacOS
------プラグイン(Carbon)
----MacOSClassic
------プラグイン(Classic)
ってな構造のフォルダを作ってやる。PkgInfoは、内容が'8BFM8BIM'というテキストファイル(フィルタプラグインの場合)。
これだけだと、ただのフォルダなので、パッケージとして表示させるために、プラグイン本体フォルダのBundleビットを立ててやる必要がある(使用上はただのフォルダでも問題は無い)。面倒なら、適当な既存のプラグインをコピーして、「パッケージの内容を表示」して、中身を自分のプラグインに置き換えてしまえばいい。
ちなみにPhotoshopはパッケージの構造とは無関係にフォルダの中をとにかく検索して、プラグインファイルがあれば、PiPLリソースをチェックして読み込むかどうか決めているらしい。まちがってClassicプラグインのPiPLをCarbon用の物にしたところ、フィルタメニューの下に同じプラグインが二つ並んでしまった。で、Classicの方をCarbonで動いているPhotoshopから起動しようとすると、エラーになって実行できない。
色んな裏技使って、Photoshop7 SDK使わず、とりあえずコンパイル通って、動くところまでこぎ着けました。
しかし、予想された事とはいえ、Aquaなコントロールがちぐはぐだあ。どうしたらいいでしょうねえ。倍率ボタンなんて、なんか変なモノになってるし……
ちなみに、もとはCodeWarriorで開発していましたが、OSX用に開発するにはバージョンが古くなってしまったので、もはや誰も覚えていないMPWに移行してみました。低レベル開発環境だけに、工夫次第ではなんでもできるっぽいなあ、これディスコンにするのもったいないよ、Appleさん。っつーか、XcodeでCFMバイナリ作れるようにしてくれ。
とはいえ、集中線と流線はいいとして、線つなぎとゴミ取りはC++でSTLとか使ってるんだよなあ。STLPortでコンパイルすれば動くかしらん。ちなみに線つなぎとゴミ取りはもともとModeでパワトン作ってた人のコードだから、美しさは逸品です。問題は僕がC++さっぱりわかんないのに移植作業やってることだけど……
まあ、こんなわけで、とりあえず集中線プラグインをコンパイルする事ができましたが、実際に公式のものになるのはまだまだ先だと思います。期待しないで待っていてください。
秋葉原のヤマギワソフト館で火事が合ったらしい。価格.comに写真が載っていたが、こりゃすごい。幸い死者がでることもなかったが、まじでやばい状況だったようだ。
まあ、今回は関係ないと思うけど、近年の状況から、つい「テロ」という単語が頭をよぎってしまう。こないだもモスクワの地下鉄で自爆テロがあったばかりだし。しかし、たとえばアメリカに対するテロにおいて、アメリカ経済の象徴たるマンハッタンが狙われたのと同じ理屈で、日本経済の象徴は秋葉原だ、とかテロ組織が考えていたら、ちと恥ずかしい(笑)。
備忘録--MacOS X
ディスクユーティリティで「エクステント アロケーション重複 XXXXd」、またはfsckで
Overwrapped extent allocation XXXXd
みたいになると、修復しても重複は解決されていなかったりする。
リストアップされたinode番号をメモ
find / -inum XXXX
(XXXX)はinode番号
で該当ファイルを見つけて削除。
でとりあえず解決。
このあと、ボリュームビットマップが不正になっていたりする事もあるみたいなので、もういちど修復をかけておく。
ただし、間違って重大なファイルを消さないように注意。ホントはDiskWarriorなどを使った方がいい。
ふと思い立って、jrogueにアイテム一覧ウィンドウ(引き出し)を表示する機能を組み込みました。
スクリーンショット
リストからアイテムを選んで使う(読む、飲む、装備するなど)事ができます。
jrogue for Mac 2.2を公開しました。
今回のバージョンから、MacOS X専用になります。それも、10.2.8以降でないと動かないと思います。
また、旧バージョンのセーブファイルは使えません。
jrogueでは、セーブファイルは読み込んだら消える仕様のため、常に一つしか使えません。従来のMac版では、コピーしたセーブファイルが使えましたが、今回ＵＮＩＸ版と同様にファイルＩＤをチェックするようにしたので、コピーしたファイルでは遊べません。また、リンクカウントをチェックしているので、ハードリンクしたセーブファイルも使えません。
旧Carbon版では、MacOS Xのログイン名が取得されず、プレイヤー名が「戦士」になっていましたが、今回のバージョンでは、ただしいアカウント名が使われます。それも「長い名前」が使われるので、日本語のアカウントを使っている場合は日本語の名前で表示されます。
旧Carbon版では、移動中のキャラクタ表示が行われませんでしたが、この問題は解決しました。
等幅以外のフォントを使っても等幅で表示されます。ただ、フォントやサイズによっては、メッセージ行に少しゴミが残ることがあります。ヒラギノも使えますが、このフォントではちと行間が空きすぎて、見た目はいまいちかもしれません。
日本語フォントの場合、半角部分は日本語文字の半分の幅に圧縮して表示します。もともと日本語文字の半分におさまる文字はそのまま表示されます。つまり、普通のフォントであれば'I'はそのまま、'W'は圧縮されるということです。
昔のQuickDrawだったら、Windowに何かを描画すれば、ただちに画面に反映される。しかし、MacOS Xでは、Windowへの描画は常にバッファリングされており、OSが適切に画面にその内容をフラッシュする。つまりいつでも勝手にオフスクリーンに描かれているような物だ。このため、Windowが他のWindowの陰になったり、スクリーンからはみ出しても、欠けた部分の内容は保持されており、旧来の意味でのアップデート処理は必要ない。
ところで、実際にバッファから画面に書き出されるのはいつか。通常適当に描画を行って、放っておけば、確かにきちんと描画される。しかし、一つの関数の中でループを回し、連続的に描画した場合、その過程は画面に反映されず、最後に描いた内容が表示される事になる。
Carbon版jrogueで、キャラクターの連続移動が描画されない理由はこのあたりにあるらしい。最初、理由がわからず、描画の度にQDFlushPortBuffer()を呼び出していたが、連続移動のアニメーション処理は、キャラクターの移動だけではなく、飛び道具を使うとか、ドラゴンが炎を吐くとか、バラバラな場所で様々に使われているため、いちいちそれらの関数を探してループに手を加えるのも巧くない。というわけで、cursesの画面リフレッシュ関数の中で、メインイベントループ呼び出してやる事にした。前に書いたように、今回のjrogueでは、もともとのjrogueのメインプログラムと、GUIに関わるメインイベントループを切り離して、それぞれ別スレッドにしてあるため、YieldToAnyThread()を挟むだけで済んだ。従来型のプログラムだったら、WaitNextEvent()なり、EventAvail()なりを入れてやれば描画のアップデートはそのときに行われるのではないかしらん。
jrogueの移植で、従来Mac独自の処理を行っていた機種依存関数の多くを、UNIXの場合と同様の処理に変更してみたのだけど。なぜか getlogin() が間違ったアカウント名を返す。これは家族用に複数のアカウントを作っているので発覚したのだけど、複数の人間がログインして、ユーザーを切り替えて使っている場合、他人のアカウント名が帰ってくる場合があるのだ。というか、僕の場合ほぼかならず妻のlogin名が帰ってくる。
環境変数USERは正しい名前を返すようだ。なんだろう。ファスト・ユーザースイッチのバグだろうか？？
環境変数を読むようにしてもいいのだけど、どうせならということで、このあたりの処理は独自仕様ということで、CSCopyUserName()を使って長いユーザー名を取得するようにした。これだと、日本語のアカウント名を得ることができる……っていうか、ひょっとして日本語アカウントとの相性問題か？子供が使うことも考えて、うちの家族全員日本語アカウント作っちゃったしなあ。
jrogueのMach-O Carbonへの移植をちまちま行っている。
リソースをnibに置き換えてビルドしてみたが、それだけだとメニューのハンドリングがうまくいかず、結局Carebon Eventモデルに変更することに。しかし、本来独立したメインループで動いているjrogueを、完全なイベントドリブンに書き換えるのは大事、というか、別物になってしまう。いままでの構造は
main(); ↓ Mac用のToolbox初期化ルーチン ↓ roguemain(); ←もともとのmain() ↓ キー入力待ち ↓↑ WaitNextEvent(); イベント取得とcpuタイムの振り分け
ってな構造だったのだけど、RunApplicationEventLoop()を使う形に変更するにはどうするか。
と考え、 結局roguemain()を、メニューやウインドウ操作から分離し、別スレッドにして、タイマーでYieldすることにした。結局大きく構造が変わってしまうことになる。いままでのCFM形式でもまあちゃんと動くし、Mach-Oにしても、WaitNextEvent()使う形は残せるはずだけど、ついついおかしな方向に進めてしまった。まだ動作に問題点があるので公開はしないけど、そのうち出します。
同人誌のデータは、おおむね1ファイル/1ページのPhotoshopデータで作成している。これをPDFにして、ページを追って読めるようにするにはどうするか。
まあ簡単な方法としては、ワープロに貼付けて、Acrobatで出力。MacOS Xなら印刷ダイアログにもれなく「PDFで保存」というボタンがあるので、それを使えばいい。
問題は、Acrobatは結構高いということ。それ以外の選択肢でとなると、なにかと不便だ。まず、マンガは縦書き右綴じである。普通にページ単位で出力したPDFは、横書き左綴じという前提になっている。Adbe Readerで見開き表示にすると、ページ方向が逆になってしまい、とても読みにくい。
色々考えるうちに、TeXで画像をページに貼り込んで、dvipdfmでpdfにすればいいのではないかという構想になった。TeXは遠い昔にちょっとだけ手を出したことがあるが、さっぱり身に付かなかったし、身に付いた部分もそっくり忘れているのでネットでお勉強してみた……が、日本語のTeX関連情報は、ほとんどが日本語の表示や組版についてのことばかり。ページいっぱいいっぱいに画像を貼り込み、右綴じで出力する方法がストレートにわかるようなものはなかった。
それでも調べているうちにいろいろなことがわかったのでコーディング、画像をおさめたディレクトリを指定してやればその中の画像ファイルをインクルードした.texファイルを出力するスクリプトを書いてみる。こいつで書き出した.texファイルはこんな感じ
¥documentclass[b5paper]{jbook}
¥AtBeginDvi{¥special{pdf:tounicode 90ms-RKSJ-UCS2}}
¥special{pdf: docinfo << /Author (後藤寿庵)
/Title (民主帝国6)
/Subject (オーバーマン・キングゲイナー) >>}
¥special{pdf: docview << /ViewerPreferences << /PageDirection /R2L >> >> }
¥pagestyle{empty}
¥topmargin=-1in
¥headheight=0mm
¥headsep=0mm
¥oddsidemargin=-1.1in
¥evensidemargin=-1.1in
¥textwidth=¥paperwidth
¥textheight=¥paperheight
¥marginparwidth=0mm
¥marginparsep=0mm
¥footskip=0mm
¥linewidth=¥paperwidth
¥columnseprule=0mm
¥usepackage{graphicx}
¥begin{document}
¥includegraphics[bb=0mm 0mm ¥paperwidth+0mm ¥paperheight+0mm]{img/01.jpg}
¥newpage
:
:
¥end{document}
画像ファイルは、あらかじめB5/150dpiに変換し、jpeg形式で保存してある。文書の幅や、画像のバウンディングボッックスはすべて¥paperwidthと¥paperheightにあわせてしまう。あと、右綴じの設定が必要なので、¥specialで埋め込み。
とりあえずうまくいったみたい。40pの同人誌が9.1MBのPDFファイルになった。
ローカルなcgiであれ、レンタルであれ、日記を新しくした場合、以前のデータをどうするかというのは難しい問題だ。
多くの場合、新しい日記の画面に、以前のものへのリンクを張るという方法で済ませることになると思う。
ところで、このblogには、データを書き出したり読み込んだりする機能があるので、データのフォーマットさえ合わせれば、以前のデータを引き継ぐことが出来る。
というわけで、以前自分のページにおいていた日記cgiのデータを変換することにする。
perlで一晩かかって変換スクリプトを書き、以前のデータを食わせる。が、スクリプトのバグでおかしな結果になってしまった。30以上の記事を何度か削除しては登録しなおすという羽目になる。もっと小さなデータでまず試すべきだったなあ。
ともかくうまくいって、ココログ開始のはるか以前の記事まで読み込むことが出来た。これからしばらくこれでいこう。
とはいえ、さらにもうひとつ古い日記(cgi)があり、そこからリンクされたさらに古い日記(HTML)もあるのである。全部変換するのはとても大変なので、上のほうにリンク貼っておこう。
嫁さん用のiBookが、CDの蓋は壊れるわ、画面は暗くなるわ、そろそろやばくなってきたので、買い替えを検討。画面も狭いので、最近のwebページは表示しきれないものが増えてきたしね。で、eMacを検討したのだが、そうすると、今まで食事用のテーブルに上げたり下ろしたりという使い方をしていたiBookと違い、どうしても設置するための机が必要、ということで、写真のパソコンデスクをケーヨーD2で買ってきた。
で、このてのスリムデスクの場合、引き出し式のキーボードテーブルから、さらに横にマウステーブルをスライドするものが一般的だ。写真のように幅がぎりぎりなのでどうしよう、と悩んでいたら、
「大丈夫、あたしマウス使わないし」
……iBookならな。
まあ、マウステーブルについては、パソコンデスクを少し前に出せばスライドさせることもできる(右の棚の扉が開かなくなるが)し、eMacをテーブル上で左に寄せれば、右に20cm近く空きスペースも出来る計算なので、そこで使ってもよかろう。
というわけで、あとはeMacの到着を待つだけ。
10/21に日本語版ダウンロード開始のはずが、なぜか延期のお知らせ。なんじゃそれ。
うちあたりiPodがあるわけでもなく、別にiTunes使う積極的な意味はないのだが、踊らされやすい男としては踊らされずにはおられない。
しょうがないので英語版をダウンロードして手持ちのアルバムを読ませてみる。
って最近CD買ってないから、えらく古いのばっかりだな。
*******このようなメールに注意************
通知人：（株）Ｊ.Ｃ.Ｐ
顧客管理課 料金徴収係
担当 田中
＜＜ 最 終 通 告 ＞＞前略、先日発送させて頂きました債権譲渡に関しての通知書はすでにご覧頂けたものと存じます。
同通知書の書面でもお知らせしました通り、弊社は各サイトのインターネットコンテンツ事業者様
より利用料金等の回収を委託されているものです。弊社が回収受任しました今回の貴殿の債務についてこれまで何度かのご連絡をさせて頂きましたが
未だ貴殿からのご入金が確認出来ておりません（３/０５現在）。
この度、弊社顧問法律事務所との協議の結果、以下の通りの事案を決定とし本メールを
最後の通知とさせて頂きます。【入金期限】平成１５年０３月１１日（火）午後３時
【振込先】（代表口座）
新生銀行 本店（店番４００）
普通口座 ＊＊＊＊＊＊＊＊
＊＊＊＊＊＊＊＊
【入金額】５３，３７８円（以下内訳）
アダルトコンテンツ利用料 ３０，０００円
延滞金 １３，３７８円
督促費用 １０，０００円
合計 ５３，３７８円これまで貴殿の利用料につきましてはコンテンツ事業者様及び弊社共々、再三のご連絡を試みて
来ましたが未だご入金がなくまた誠意ある回答も頂いておりません。
今回の通告にも関わらず万が一にもご入金のほうの確認が取れない場合は弊社関連調査会社のほうで
貴殿のご自宅、勤務先等をメールアドレス、アクセスログ、電話番号等から調査、解析し回収員が
貴殿のご自宅、勤務先等へ直接、回収に伺う事となりますのでご了承下さい。
またその際に掛かります費用、調査費用、交通費等の雑費、別途回収手数料も合わせてご請求させて頂きます。
また場合によっては裁判所を通じた法的手段にて対応させて頂く事となります。本状は「最終通告」です。これ以上の猶予はないものとお考え下さい。
尚、もし本状と行き違いにお支払いの場合はご容赦願います。
以上、何卒宜しくお願い申し上げます。
（株）Ｊ.Ｃ.Ｐ
※ 本メールは送信専用アドレスより配信されています。このメールに返信されてもお返事は届きません。
弊社は債権回収業者であり本件に関してのお問い合わせ等は直接コンテンツ事業者様へお問い合わせ下さい。
とにかくこのようなメールにあわてて、お金を振り込んではいけません。また、このような手口を見て、軽い気持で真似してはいけません。言うまでもなくこれは犯罪です。
もし、あなたが実際アダルトサイトなどにアクセスした上、そのことも忘れ、「最終通告」以前に何度も来ているはずの連絡があったかどうかすら分らないほどにルーズな生活を送っているとしても、まずは警察や消費者センターなどに相談しましょう。この文面に限って言えば、「前略」はふさわしくない。講座名義が個人名（文面から削除しましたが、個人名でした）なのが変だなど、ちょっと考えれば変なことがたくさんあります。そもそもこの種のお知らせが電子メールで来る事自体通常考えられず、書留、内容証明などの手段のある通常の郵便が使われるでしょう。
えーと、とある漫画のとある回に萌えまして、そのエロパロ絵を描いてとある有名掲示板に貼ったりしたわけです。まあ、そのためだけに描いたわけじゃなくて、冬コミ用CG集に入れるついでなんですけど。
でまあ、結構褒められていい気になっていたんですが、いろいろ考えさせられるレスもありました。まず、原作をトレスしていると思われたこと。見て描きましたがトレスはしていません。しかし、あきらかなぎこちなさがあって、それがトレスと思われたのでしょう。また、後藤寿庵の絵と見破った上で(まあ、Juanという例のサインを入れてありますが)、後藤寿庵本人ならもっと顔を自分流にいじるだろう、これは後藤寿庵の絵の顔の部分だけ挿げ替えたものだという疑惑。さらに、首から下の絵に関して、前に見た記憶があるとまで書かれています。
これは二重に僕の絵の欠点を突いています。実際の所、僕は相当意識しない限り、見たものをできるだけ忠実に写してしまう傾向があります。実は自分流に上手くアレンジすることのほうが少ないのです。「これが自分の個性」という強いものを持っていないのですね。
また、首から上以外は同じ物を見たことがあるというのは、ようするにしょっちゅう似たような絵を描いているという事です。反省しなきゃいけないなあ。
*******
#!/bin/shwhile test 1
do
cdrecord -v dev=2,0,0 speed=24 driveropts=burnfree -dao -eject $1
echo 'Hit Any Key'
read xx
done
Windows XPには最初からCD-R作成機能がありますが、同じ内容で何十枚も作成するような用途には全くむいていませんね。
結局デジコミツールズのWindowsへの移植は僕がやる事になった。自慢じゃないが、僕はWindowsマシンをまともに使った事がないのだけど、まあいいか。
開発機材もデジターボから提供してもらったが、ツクモのショップブランドで、Micro-ATX、オンボードVGAの安いやつ。本体キーボード、マウス、スピーカー付きで7万切っている。でもセレロン1GHzだ。周波数と値段を考えると、やっと1GHzが出たMacとの差に愕然とするなあ。
ちなみに、とりあえず集中線プラグインを動かす所まで漕ぎ着けている。600dpi、26cm四方の画像に高密度の集中線を引いてみたが、今まで使っていたMacよりかなり速い。といっても、うちのMacが今の基準でMacとしてもむちゃくちゃ遅い(CPUは400MHz,バスは45MHz、メモリはFP-DIMM、ビデオ回路はオンボードでアクセラレータ無し)のだが。
ちなみにこのプログラムはAltiVecなどは使っていないので、純粋にどれだけ高速に通常の浮動小数点演算をこなすかで速さが決まる。同クロックの最新モデル同士で比較したらどっちが速いか興味深い所だ。なにしろコアの部分はWin版もMac版も全く同じソースを使っている。
現在のスクリーンショット。
(http://www.hotwired.co.jp/nwt/011226/maillist.html)
授賞式に併せて行われた出席者スピーチに立った堺屋太一内閣特別顧問は、インパクのおかげで「インターネットカフェのブームが起こり、ブロードバンド技術の進化がももたらされ、ADSLの普及に繋がった。インパクは予想以上の成果を納めた」と評価した。
凄い事言うなあ、堺屋太一。インパクを当て込んでインターネットカフェを作ったオーナー、どっかにいるのか？知らなかったやつの方が多そうだぞ。ISDNや56kモデムじゃインパクが快適に見られないからBBにしたやつなんているのか？
想像も付かんぞ。
夏コミのときはCG集の作成にMacCDRを使ったのだけど、これで何十枚も焼くのは結構大変だった。ドライブにメディアを入れて、ドライブの準備が整うのを「目で」確認(ランプが緑になるのを待つ)してからボタンをクリックするという迂遠な方法なので、とても難儀だった。それに、今ではMacOS Xをメインに使っているので、できるだけMacOS 9で再起動をするのは避けたいのだ。ちなみにうちで使っているMacCDRとCD-R/RWドライブの組み合わせはMacOS XのClassic環境では使えない。
思えばフロッピーでCG集を作っていたときは楽だった。Apple Disk Copyはもともとフロッピーの大量複製のためのツールで、一旦ディスクイメージを作成してそれを指定してやれば、延々複製を作ってはディスクを自動的に吐き出し(これは昔からのMacの利点だよね)、新しいディスクを差し込むだけで次のコピーを作ってくれた。
MacOS Xの地道なバージョンアップに伴い、これまで使えなかったSCSI接続のCD-Rも使えるようになった。そして、MacOS X版のDisk CopyでCDを焼く事も可能だ。ということは再びあの気楽なコピー環境が復活しているのか？………しかし、現実は甘くはなかった。
まずCDのディスクイメージを作るために一枚CDを作る作業、これは非常に手軽だ。生のCD-Rを入れてやれば、Finderが作成するフォーマットを聞いてきて、それに答えるとCD-Rがデスクトップにマウントされる。あとは焼きたいファイル/フォルダをそのCD-Rにドラッグするだけ。最後にCD-Rをイジェクトしようとすると作成するかどうか聞いてくる。実際にはこの段階でCDに焼かれるようだ。しばらく待っていればCD-Rの出来上がり。Disc Copyを使って、装置からイメージを作成する。/dev/disk3などのUNIX風デバイス名で表示されるので分かりにくいが、三角マークをクリックしてパーティションマップを出せばその装置がCD-Rかどうかわかるので問題はない。
問題はこの後。「イメージをCDに作成」を選ぶと、CD-Rのトレイが開いて新規メディアの挿入を促され、挿入すると自動的にCDが作成される。だが、終了後続けて次のCD作成にならないのだ。あくまで一度に一枚である。しかも毎回イメージファイルをファイル選択パネルで選択しなければいけない。これではMacCDRより面倒である。
ということで、色々調べてみた所、コマンドラインツールのhdiutilでもCDの作成ができる事が分かった。%hdiutil burn myImage.dmg
でイメージファイルをCDに焼く事ができる。大量に焼く場合はデータの検証をスキップしたいが、それも
%hdiutil burn myImage.dmg -noverufyburn
でOKだ。詳しくはman hdiutil を見れ。
コマンドラインでできると言う事は、シェルスクリプトでループさせてやればいくらでも連続焼きができるということだ。こいつはいけるぜ。
ちなみに、FinderでCD-Rを焼くときのフォーマットだけど、「標準(HFS+/ISO9660)」はMac/Win共通で読める。どうもISO9660 Level2にHFS+のための情報を追加した形式のようだ。以前のApple/ISOフォーマットともちょっと違うようだが、詳しくは分からない。Macの場合はMacOS 9以降でないと正しく読み込めないみたいだが。
ヘンテナの話は、Mac用の有名なアウトラインプロセッサ、Acta7を検索して見つけたものだ。かのヘンテナ氏はActa7の日本語化を行った人でもあったのだ。Acte7日本語版はどうしてできたか、などを読むとなかなか興味深い。しかし、姉妹、叔母も兄弟、叔父もどっちも分かりにくいよなあ。アウトラインプロセッサの階層をあらわす表現ってやっぱ変。
というわけで、有名どころのアウトラインプロセッサであるActa、現在Acta ClassicがA#のサイトからダウンロードできる。日本語化パッチは飯森さんのサイトからダウンロードできる。
Macintosh~今さら試してみもしないが、ワイヤーが出てる地球のマーク、ウインドウぎりぎりではなく、少し内側に配置されたスクロールバーといったデザインセンスは後のNetscapeより上だったと思う。
のフリーバージョン~Nisus CompactとNisus Writer 4.1.6のフルバージョンが無料でダウンロードできる。これらもかつてれっきとした商品で、通好みのワープロだったものだ。日本語どころか各国語をまぜて編集できるすぐれものワープロ。しかも動作は速い。ただし日本語ワープロ特有のルビや縦書きはなかったと思う。ひところはテキストエディタ代わりにmac関連ライター達に愛用されていた。
Session~Sessionはリアルに動くカセットテレコ風UIで一世を風靡した作曲、再生ソフト。当時普通にプログラムしたのでは不可能なトラック数を同時にドライブする事で話題を読んだ。ダウンロードできるのはカセットテレコ画面を廃止した後のSuper Studio Sessionだが、みてくれを考えなければ十分使える。かつて僕はこれをちゃんと購入して使っていた。マニュアルなどの箔押しを使ったキラキラした印刷が目に痛かった。ぺあぺあどんどんだったかぺあぺあどんどんIIの中で使った音楽はこいつで作曲したもの。
Sessionはなんつーか説明が難しいソフト。ダウンロードして試してみれ。と思ったけど、MacOS XのClassicモードじゃうまく動作しないなこれ。
Perlなりシェルスクリプトなりでファイルをコピーしたり新規ファイルを作ったり、そういう場合MacOS 9から使う事を考えるとファイルタイプなどをきちんと扱いたい事がある。ファイルコピーの際、cpを使うとファイルタイプやリソースフォークが無視されるので具合が悪いが、/Developer/Tools/CpMacを使えばOK。同様に、移動にはmvの代わりに/Developer/Tools/MvMacを使えばいい。Perlなどから直接ファイルを作った場合、任意のクリエータとファイルタイプを設定するには
`/Developer/Tools/SetFile -c MSIE -t TEXT "$filename"`
などとすればOK。ふうむ、結構考えてるじゃんApple。SetFileコマンドでは、他に作成、修正日付け、Finderフラグの設定なども行える。引数無しで起動すると簡単なusageが出るので詳しくはそれ見れ。
Juan's Hentai Art shop用に、画像をディレクトリに追加するだけでサムネール一覧とクリックによる画像本体表示を実現するPHPスクリプトを作ってるのだが、ディレクトリの中のサムネール一覧を取得するところで、なぜかドットファイルを拾ってしまう。正確には、'.'と'..'はよけてくれるのだけど、'.DS Store'を画像と一緒にリストアップしてしまうのだ。あ、.DS Stroeってのは、MacOS XのFinderがファイル情報を納めるために使う隠しファイル(らしい)で、適当にFinderで作業しているといつのまにかディレクトリの中に作られているという代物。sitecopyでこいつを送らないように設定しているので、サイトに送る段階では問題にならないのだけど、ローカルで動作チェックをしていると引っ掛かる。なんでだろう、と思って良く見ると。
while($file=readdir($dir)){
if (!ereg($file,"^\.")){
$flist[]=$file;
}
}
驚いたことに
while($file=readdir($dir)){
if (ereg("^[^\.]",$file)){
$flist[]=$file;
}
}
に書き換えて解決。ついでにifの直下で!使うのではなく、正規表現の中で除外の[^]を使う方がスマートかな。
配列の要素全部について何かをするとき、Cなら
for ( i=0; i < array_count ; i++ ){
if (array[i] == hogehoge ){
...
}
}
int max = [array count];
int i;
for ( i = 0; i< max; i++){
if( [[array objectAtIndex:i] isEqualTo:hogehoge]){
...
}
}
NSEnumerator *enumerator = [array objectEnumerator];
id theObject;
while( theObject = [ enumerator nextObject] ){
...
}
を返すということ。これはMacOS Xのgccにおけるintで、正の値になっている。見つからなかったら負の値を返すものとまるで根拠なく思っていて、
enum {
NSNotFound = 0x7fffffff
};
if (result >=0){
...
}
みたいな判断をしてはまった。ちゃんとドキュメント読めよ。天気: 晴れ
観測場所: 相模原
Cocoa アプリケーション全般に言えるのだが、バックスラッシュと円記号が一つの書類に同居するようになっている。キーボードメニューでことえりを有効にしていると円記号が、U.S.モードにしているとバックスラッシュが入力される。TextEditの場合これを欧米(MacOS Roman)形式で保存するとバックスラッシュの部分が0x5cとして保存され、円記号は0xb4になっている。日本語(Mac OS)形式で保存すると、バックスラッシュが0x80、円記号が0x5cになる。これは、もともと昔からのMacのフォント配列を反映した素直な変換だ。ちなみにUTF-8で保存すると、円記号は0xc2a5、バックスラッシュは0x5cである。
ところで、Cなどでプログラムを組む際。円記号やバックスラッシュがどういうコードで扱われるかは重要である。\nとかが気軽に使えないとなにかとやっかいだ。日本では歴史的にASCIIコードとJIS X 0201-1976 の前半をあまり区別しないで使っていた。そのため、0x5Cが日本では円記号として扱われ、C言語の入門書などでもこのコードを円記号として印刷しているものが多い。
Interface Builderの組み込みエディタでは、欧米(MacOS Roman)でも日本語(MacOS)でも、円記号とバックスラッシュをいっさい区別せず、0x5cとして保存するようだ。入力時は別々に表示されるが、一旦保存して開き直すと、すべてバックスラッシュになる。ただし、UTF-8ではコードが別々に保存される。この場合、円記号はエスケープ記号としての意味を失うので注意が必要だ。
とりあえず、エスケープ記号を入力したい場合、U.S.モードにしてバックスラッシュを入力するのが確実のようだ。
macosx-dev-jp-mlで話題に出てたけど、CocoaとCarbonの位置付け、Classic MacOSとの互換APIであるCarbon、NeXT由来のCocoa、位置付けとしては横並びで、好きな方使ってねって感じなんだけど、メニューのハイライトからなにから自分でやらなきゃ行けないCarbonと、巨大なアプリケーションフレームワークであるCocoaじゃあ月とスッポン、アセンブラとBASIC、新規のMacOS X用プロジェクトだったら、フレームワークと言語そのものを勉強してでもCocoa使った方が楽だと思う。Objective-Cは覚えにくい言語じゃないしね。
ただ、件のMLでも出ていたのだけど、Cocoaは良くも悪しくもUNIXの上にのっかっている。飯森さんが力説していたけど、パス名を使ってファイルアクセスするのはMacOS的には邪道中の邪道なんだよね。MacOSでは、ファイルの位置を指定するのにフルパスは極力使うなと言う事が昔から言われていた。実際、ファイルをアプリケーションから開くのに通常パスを意識する必要はない。設定ファイルを置いておくべき場所はOSに問い合わせて取得するし、開いたファイルの履歴をとっておく必要があればAliasレコードを作って保存する。Aliasは内部的にはファイル名、ファイルID、相対パス。親ディレクトリのID、ボリューム番号など、ファイルを指定するための情報をいくつも保存しておく仕組み。これがあれば、ターゲットのファイルが移動してしまっても追跡可能な、優れたシステムだ。まあ、MacOSはもともとPascalのためのAPIで構成されていて、文字列の長さが255bytesしかなく、そのうえファイル名が31bytesまで使えたので、フルパス主体にファイルマネージャを作ったら、すぐに限界を超えてしまうと言う問題もあったと思うけど。
さて、Cocoaではなにかとパス名を使う。NSStringクラスにはパス文字列を操作する便利なメソッドがてんこもりだ。確かにMacOSのノリだと気持ち悪いけど、便利だからつい使っちゃう。世の中Mac以外が90%で、それらがパス主体のファイル操作で困ってると言う話も聞かない。ならいいんじゃないか、と思うのだけど、意外な所に問題が潜んでいるのだった。
MacOS Xでの、パス文字列の長さは、最大1024bytesと決まっている。一方、HFS+ファイルシステムはUnicode文字で255文字までのファイル名を許している。ファイルシステム上ではUCS2かなにかで保存されており、原則的には一文字あたり2byteになっている。MacOS XのPOSIX APIではこのファイル名をUTF-8に変換して使っているようだ。UTF-8は欧米系の文字はほぼ1文字=1byteで表現されている。つまりファイル名は最大255byte程度と考えられる。限界までの長ーい名前を付けたフォルダを4つ入れ子にすれば、もう5階層以下は参照不能となってしまう。プログラムによってはバッファオーバーランでクラッシュするだろう。現実には、長い名前はあまりフォルダにはつけないと思うので、そうそう限界に達する事はないが、UTF-8で日本語などはだいたい文字あたり3byte以上になってしまうため、見た目以上にパス文字列にしたときのバイト長はのびている可能性がある。
飯森さんなどは、MacOS XのアプリケーションはFSRefを中心につかえと言う忠告をしている。確かにCarbon呼び出しをラップしてうまくカテゴリなどでクラスを拡張してやるやり方を取れば、さほど苦労しなくてもいけるかもと思うけど、それはそれでなんか納得行かないものがあるのも確かだ。
そういえばApple的にはCocoaでのファイル特定にパスにかわってNSURLを使わせようとしているきらいがあるな。NSURLでの指定にはパス長は関係しないのだろうか。"file://localhome"を削って下位APIに渡しているだけだったら同じ事になっちゃうけど。
MacOS X Cocoaプログラムの悩み。
NSImageViewはイメージファイルのドロップを受け付けるのだけど、JPEGだけ受け付けるようにしたいと思い、サブクラス作ってメソッドをオーバーライドすることにした。
- (unsigned int) draggingEntered : (id<NSDraggingInfo>) sender;
{
NSPasteboard *pb = [ sender draggingPasteboard ];
NSArray *ar = [ pb propertyListForType : NSFilenamesPboardType ];
NSString *filePath = [ ar objectAtIndex : 0 ];
if ( [JCutility isJPEG:filePath] || [JCutility isDirectory:filePath] ) {
NSColor *col = [NSColor controlHighlightColor];
[self lockFocus];
[[col colorWithAlphaComponent:0.2]set];
NSRectFillUsingOperation([self visibleRect],NSCompositePlusDarker);
[self displayIfNeeded];
[self unlockFocus];
return( NSDragOperationGeneric );
}
return NO;
}.
PowerMac 7300～9600でOS X を動かすための手順が(http://homepage.mac.com/RyanRempel/OldWorld/Instructions.html)にある。うちでもこの手順で動かすことができたのだが、L2キャッシュが動作していないためひっじょーに重たい。この手順と必要な追加ファイルを用意してくれた、Ryan Rampel氏は、PublicBetaの時に、非サポート機種でL2キャッシュを有効にするL2ChacheConfigを作ってくれた偉い人なのだが、正式版用のアップデートでちょっと問題があって遅れているらしい。そこで、とりあえず自分専用にカーネルに直にパッチを当てることにした。 cvsでDarwinのカーネルソースを取ってきて、一部手を加えmakeする。ただし、現在のカーネルソースは、そのままではMac OS Xでコンパイルできないので、かなり面倒な作業になる。カーネルビルドの手順については説明しないので、やってみたい方はhttp://www.darwinfo.orgあたりで、Darwin-Devメーリングリストのアーカイブを読んで勉強して下さい あ、それから、このパッチはG4カード用です。G3カードの場合はパッチを当てる場所が違います。
xnu/osfmk/ppc/start.s
from line 462
init7400: bf firstBoot,i7400nb ; Do different if not initial boot....
mfspr r13,l2cr ; Get the L2CR.
oris r13,r13,0xB908 ; ----Juan set dummy L2CR data.
rlwinm. r0,r13,0,l2e,l2e ; Any L2?.
bne+ i7400hl2 ; Yes....
rlwinm r17,r17,0,pfL2b+1,pfL2b-1 ; No L2, turn off feature.
三行目のorisで始まる行が追加したもの。最初からG3以降を搭載しているMacでは、ROMが起動時にL2CRレジスタを設定するが、アップグレードカードの場合、多くはそういう事をしていないので、最初L2CRの値は0になっている。そこで、L2CRの値を読み込んだ直後に、その読み込み先のレジスタに手動でL2CRの「こうあるべき」値をセットしてやる。ここでセットしている値は、L2キャッシュ有効、L2サイズ1MB、キャッシュ/CPUスピード比1:2、ライトスルーモード、というところ。
この変更を加えたカーネルをコンパイルして、入れ替えたところ、驚く程速くなった。これなら十分実用的と言える。
「あいきこジャパン」なるエロサイトを見つけたんだけど、なにこれ？？
やっとアメリカに出てきた！！ や！私の名前はあいきこです。ようこそ！この唯のプレビューを お楽しみなさい。このサイトは好きな変態味のコレクションがたくさんは 入っています。一番の変なフェティシズムから一番の普通のまでこのサイト が全部持っていて、あなたの要るものを絶対満足させます。 いつもこのサイト が切り替えまて、一番速いサーバーは凄いOC-3コネクションを使って、何人か の客たちは満足で、このサイトは一番と伝えてくれます。
あいきこ？？
触手エーリアンやデーモンや触手などあります。
Ｈのコンプリートアーカイブには諸々変な触手ある動物といしょの
セックス の画像があります。私たちは、インターネットでベスト
インターアクティブ変態 モンスターアーカイブ持っています！
こんなメンバーシップの為に死ね！！！
同じ古い物に疲れた？では、あいきこジャパンはベストオリジナル
触手のアーカイブ 等々を差し上げますから！
面白い………
僕が作った集中線/流線フィルタを含む、デジコミツールズVOL.1が(株)デジターボより発売された。もともとは冬コミの原稿作成に間に合う時期に出すはずだったのだが、予想通り遅れてしまった。遅れている間、プログラマ当人がベータ版を使って冬コミ新刊を作っていたのは内緒だ(笑)。
まさに表題通りのコラムがあった。
前々から僕はスケッチブックみたいなグラフィックコンピューターが欲しいと思っていた。できればA4程度のサイズで全面がタッチスクリーンというのが欲しい、タブレットのペン先に直に絵が描かれないといやだ。上のコラムで紹介されてるVAIO LX80のTVCMを見て、「これはいい」と思った。あくまでデスクトップマシンだし、スケッチブック程自由にスクリーンの位置や角度を変えられるわけでは無いが、欲しいと思っていた物にかなり近い。ちなみに僕はまごうかたなきマッカーであり、単に慣れてるという以上にMac好きである。でもこれはかなりそそられる(そういえば2chで「VAIOみたいなダメパソコン買うのはマッカー位のもの」という悪口を見かけたのだが、そうすると僕が気に入るのは別に普通の事なのかもなあ)。Windowsマシンとしてはちょっと高いけど、Macと比較すればそれほどでもない。金が無いので買えないけどね。
MacOS XのベースはDarwinである。従って、MacOS XのカーネルのソースはDarwinのそれと基本的に同じである。ただし、MacOS Xでは、AppleがBTOでつけたいくつかのSCSIカード等を使用するためのドライバが追加されており、これらはカードベンダーのライセンスとの兼ね合いで、Darwinでは公開されていない。しかし、それらのカードを使わないのであれば、DarwinのカーネルはMacOS Xに持って来てもきちんと動作する。MacOS X用のDev-toolsをインストールすれば、自前でカーネルハックも可能だ。
MacOS X Public beta だが、G4アップグレードカードを使用したPCI Macでは全く起動しない。これはカーネルがCPUの初期化をする段階で、旧機種+G4という環境を想定していないためである。この件に関して、L2Chashe Configを作ったRyan Rempel氏がDarwin-Dev MLで詳細な分析をしている。
以下Rampel氏のmailからの一部翻訳。
L2CR プロセッサレジスタは、起動時にデフォルトで0になっている。一般にL2CRレジスターを正しい値に設定するのはROMの仕事である。しかし、7600のROMはL2CRレジスタの事を知らない。従って、このルーチンが現在のL2CRの値を得ようとした時、この値は0になる。これはL2キャッシュを無効にするべき正しい値である。しかしこれはもちろん最適な値ではない。
興味深い事に、G3プロセッサでは、キャッシュ無効状態ではあるものの、カーネルはブートし、per_proc_infoの値を手動でセットして、後でcacheInit()を呼ぶ事でL2キャッシュを有効にできる(これは私のL2CasheConfigユーティリティが行なっている事である)。なぜG3とG4でこのような違いが生じるのか。
start.s内のG3とG4のコードを見比べてみると、G3コードはL2CRの値が正しいRAMサイズかどうかチェックしているのに気づくだろう。(RAMサイズはL2CR内の2ビットの値であらわされる)。G3では、0x00のRAMサイズはリザーブされており、従って、アップグレードされた7600で、L2CRが0である場合、コードはそれが間違った値であると判断し、故に、per_proc_infoに、L2キャッシュがあるという設定をしない。
G4では、これに対して、0x00のRAMサイズは有効であり、それは2MBのRAMが存在する事を示している。従って、コードはL2キャッシュがあるとper_proc_infoに記録し、かつ、L2CRの値は0である。しかし、もちろんこれは矛盾した状態である。後に、cacheInit()ルーチンはL2CRの値0でL2キャッシュを有効にしようとする。これは、もしcacheInit()が値0を文字どおり0として扱うならば、そう悪くはない。しかしそうはしない。ルーチンはL2キャッシュが存在すると仮定し、キャッシュを有効にしようとする。結果的に、このルーチンは有効ビットをセットし、L2CRレジスターを0ではなく0x80000000にする。この結果、正しくない値をセットした事によって、コンピューターは即座にフリーズする。
ところで、僕はアセンブラについてはZ80しかやったことなかったので、もとのソースはチンプンカンプンでした。でもまあざっとソースを眺めるとbがブランチの意味らしい位はわかるし、bgeやbltもまあなんとか。というところ。こういう場合、コメントが充実してると実際助かるな。上記のG4カードで起動しないなんてのは、ある程度経験のあるプログラマならすぐに原因と対処法を発見できるレベルの問題だと思うけど、PublicBeta登場後、今までなかなか出てこなかったあたりは、Apple社内のOS Xチームは旧機種のサポートには興味がないだろうし、Opensourceとして取り組んでいる外部のプログラマは人数が不足しているんだろうな。こういうのは自分のマシンで動かないのを何とかしたいという人間が解決する傾向がある。
ところで、CPUアクセラレータを作っている会社こそが、Darwinに参加してこういう所を調べるべきだと思うのだけど、どうだろう。いや多分やってると思うけどさ。他の周辺機器や拡張カードメーカーはAppleと一緒に、最新機種にフォーカス絞っていけるだろうけど、CPUアクセラレータの場合、旧機種でこそ有り難みがあるわけで、新OSのコアを直接触れるDarwinはチェックしておくべきだと思うのだけどどうだろう。まあ、言わなくても実際やってるかなあ。
なんか、MacOS X PBで、弊社のG3/G4アクセラレータは起動しますが、L2キャッシュが有効になりません、なんてことをWebページに載せてる会社は自分とこのG4カードでの確認すら行なっていないんじゃないかと思うのよ。
jrogueをCarbon化してみた。以前からソースにはCarbon化のための処理を入れてあるし、実際コンパイルし直すだけで理論上Carbon対応が可能なはずなのだが、少々難儀な問題がある。もともとrogueはUNIX生まれで、僕が元にしたソースはそれをDOSに対応させたものだ、というわけで、当然ながらCの標準ライブラリを大量に使用している。MacOS X Carbon対応のために一番問題になるのは実はこの標準ライブラリ絡みの部分なのだ。
従来のMacアプリケーション用APIはCarbonがうまくやってくれるが、標準CライブラリはCarbonには含まれていない。現在のMacOS 9では、標準ライブラリがOSに含まれており (もともと、すべてのPowerMacのROM内に標準ライブラリが含まれている。OSのバージョンが上がって、標準ライブラリも改良されて来ているので、最近はROMではなくSystemファイルに含まれているものが起動時にロードされて使われる)、これへのインターフェイスはStdCLibというstubを通して行うのだが、Carbon porting guideではこれを使うなと言う事になっている。最終的には使えるようになるようだが、現在のパブリックベータでは、Carbonアプリ用のStdCLib(CFMアプリケーションからUNIXレイヤーの該当機能にアクセスするバイパスのようなものらしい)はまだ完全ではなく、OS 9用にMPWで作成したStdCLib使用アプリケーションは使えないようだ。
意外に思われるかも知れないが、この事はあまりMacデベロッパの間で問題にはなっていない。もともとMacのAPIはPascalベースだし、Cっぽい作法を嫌う所が多い。コンソールの概念がないので、文字列表示も基本的にグラフィックだし、文字列操作もC文字列とか使ってしまうと、どっかでPascal文字列に変換しなければならなかったりしてめんどくさい。メモリ操作については、最近はそうでもないが、もともとメモリが少なかったのでリロケータブルブロックを二重ポインタで操作する専用のAPIがガンガンつかわれていた。ファイル操作にいたっては独自の属性やデュアルフォークシステムを標準ライブラリの機能ではまるでサポートできない。というわけで、Macのソフトではmalloc()もprintf()もstrcat()もfopen()もほとんど使われてこなかったのだ。
で、MPWからCodeWarriorにソースを写し、StdCLibの代わりにMSLを使うようにしてみた。CWのMSL実装は、OS内蔵の関数を使うのではなく、独自に標準関数をインプリメントしているので、OSの対応を待たなくても使えるのだ。しかし、CWのCarbon対応も、間もなく出るCW6(米国ではすでに発売されている)で正式に使えるようになるもので、うちにあるCW5ではプレリリース版のCarbon版MSLがあるだけだ。このプレリリース版が出た後も、AppleのCarbon仕様や、ヘッダファイルの仕様が変わっており、現在のCarbon1.0.4SDKの環境ではMSL自体がコンパイルエラーを出してしまう。幸い機械的に2,3箇所ソースをいじるだけでOKだったのでとりあえずMacOS 9のCarbonLib上で動くものがコンパイルできた。
さて、問題はうちにはMacOS X パブリックベータがないことだ。まだ日本で発売されていないので、年間500$のデベロッパ契約をしている人、米国に知人がいる人など以外はなかなか入手できないのである(英語版のMacOS X PBはアップルストア直販のみで、日本からは買えない)。というわけで、自分では動作チェックが出来ない。ついでに言うと、以前のDeveloper Preview版と違い、PB版は未サポート機種へのインストールオプションが無くなっているらしく、うちのPowerMac7600にはインストールすら出来ない可能性がある。こうなると、そもそも自作アプリのCarbon化も意味がない気がしてくるね。ともかくだれか試してみて下さい(一部、動作したという報告がありました)。
(http://www.win.ne.jp/~juan/misc/roguelike.html)
今回の方法は、標準ライブラリの機能をアプリケーション自体に持たせたわけで、BSDレイヤーを持つOS Xにこの方法を用いるのはかなり無駄っぽい。あきらかに容量増えてるしな。まあ、容量増えた原因はそれだけじゃなくて、OS X用の巨大なアイコンデータを持たせたという事もあるのだけど(なにしろ32bitカラーで128*128ピクセルなんだもん、昔ならnetでやり取りするのもはばかられるサイズだよな)。
OS X用のアイコン、Cocoaなどで.icnsファイルにするのはわかるけど、従来のCFMアプリであるCarbonで、どういうフォーマットで持たせるのかっていう説明が見つからなかったのだけど、どうやるのが正しいのでしょうね。BNDL,FREFと関連づけたicnsリソースを用意すればいいっぽいのだけど、なにしろきちんとしたドキュメントがみつかならいんで、巷に出回りつつあるcarbon対応のシェア/フリーウエアを解析してみた、ところが、ほとんどの場合、OS X用のサムネールアイコン(そう、あの特大サイズのアイコンはサムネールというのだ)は内蔵していないのだった。もちろん、OS 9 以前の32ピクセルサイズのアイコン(ちなみにこれは伝統的にラージアイコンと呼ばれる。16ピクセルのがスモールアイコン)だけでも動作に支障はないのだけど、あれが「ぐわっ」とドックなどで拡大されるとみっともないような気がする。
OS Xのアイコンは、精密で写真っぽい質感が要求される。Appleの出して来た標準のアイコンと違和感がないようにデザインしようとすると、かなり面倒な事になるだろう。従来ResEditのICONエディタでポチポチドット打っていた段階でも、プログラマはともすればコードが仕上がっているのに、アイコンでザインで四苦八苦し、「これに一番時間がかかる」などと冗談まじりにぼやいたものだが、今後はおそらく3DソフトやPhotoshopを駆使したアイコンデザインが主流になるだろう。アイコン制作受注と言う仕事がより注目を浴びるのではないだろうか。
以前、集中線描画アルゴリズムについてちょっと書いたが、これをJavaでやってみた。浮動小数点演算の固まりだけど、今どきのマシンで動かすと結構速いね。ライブでパラメータ変更、再描画をくり返しても結構追随してくれる。遅いのは主に最初に読み込んで起動するまでだな。
ちなみに、Mac用のNetscape Communicator 4.7.1では動作しません。Macの場合、IE5で、最新のMRJを動かすようにして下さい。WidnowsやLinuxの環境でちゃんと動作するかどうかは未確認。
G3カードとの相性が悪いと言うので外していたマザーボードキャッシュを戻す事で安定したかに見えたSTFだが、果たしてそれでよかったのか？というわけで、その後の話
上記の環境で、自作のPhotoshopプラグインがフリーズしやすい事に気づいた。当然普通ならバグだと思うのだが、徹底的に見直してもバグらしきものは発見できない。フリーズする条件は、MacOSの仮想記憶をONにした上で、馬鹿でかい画像データにフィルタをかける事。仮想記憶OFFだとフリーズしない。デバッガでヒープをチェックすると、ヒープが壊れているどころではなく、ヒープをチェックしようとしたデバッガが特定の変なアドレスにアクセスしようとしてエラーになっている事が多い。これが仮想記憶空間の最後のアドレスなのだ。こりゃページング処理が転けてるよなあ。ポインタに書き込むコード等で、NULLや-1にアクセスしている部分はないし。いろいろトラップかけてみたら、Photoshopのホストコールバックである、AdvanceState()関数の中で落ちている。この関数は、メモリが足りない場合、画像の一部をメモリに読み込み、今まで読み込んでいた部分をディスクにスワップする物なのだ。OSの仮想記憶がONになっていると、この時にまあ大概OSの方のスワッピングも起こってしまう。下手をすると、メモリ上にあるとPhotoshopが思っているデータが実際にはファイル上にあり、それをPhotoshopがディスクに書き出すためにわざわざディスクから読み込むなんてことが凄い勢いで起こる。というわけで、通常Photoshopを使う場合OSの仮想記憶は切るのが鉄則になっている。まあ、そこをあえてPhotoshopには酷な条件でやっているわけだが、本来こういう事をやっても、激烈に遅くなる事はあっても、クラッシュすることはないはずなのだ。
いろいろ調べてみると、仮想記憶を切る他に、起動後にマザーボードのキャッシュを無効にする事でもクラッシュをさける事ができるようだ。そもそも、CPUに1MBものバックサイドキャッシュがついているのだから、本来ボード上の256KBしかないキャッシュは足を引張るだけなのだ。もともとこいつはオリジナルのPowerPC 604/132と一緒に動作するように作られていて、スピードの速いアクセラレータの類いと同時使用すると不安定要因になると言われている。しかし、起動時にはこのキャッシュがONになっていないと、ほぼ確実に起動途中でクラッシュする。
PowerLogixが配布しているG3/G4 Cache Profilerを使用すると、起動した後でCPUのバックサイドキャッシュや、マザーボードキャッシュの設定を変えられる。しかもこいつはAppleScriptで制御可能なのだ(なんでこんなものがって感じではある)。そこで、Chache Profilerを起動して、マザーボードキャッシュを無効にし、終了するスクリプトを書いて、起動項目フォルダに放り込んでみた。これによって、起動時はキャッシュONで、起動した後で自動的にOFFになる。
どうやらなんとかなりそうかな。ちなみに、使用したスクリプトは以下の通り。
tell application "G3/G4 Cache Profiler 1.3"
set enabled of Motherboard Cache 1 to false
quit
end tell
来週と言っていたStorage Fighter だが、今日届いた。ファームウエアはちゃんと復旧している。STFからの起動テストを行い、正常に起動する事を確認したと書いてある。しかし、相変わらず家の環境では起動しない。CPUを、Booster750/266から、以前使っていた604e/233に変えてみた所、全く問題なく起動する。しかし、G3と604eの速度差は、やはりかなりの物で、今さら戻る気になれない。これは困った。どうもメモリアクセスのタイミングやら何やらの、よくわからんシビアな問題があるようだ。海外メーカーのCPUカードだと、ドーターボード上にディップスイッチがついていたりして、気軽にバスクロックを変えられるものもあるのだが、Boosterにはそんなものないので、とりあえずバスクロックを下げて様子を見るって事も出来ない。
ところで、7500/7600あたりのマシンだと、メモリを二枚組みで増設すれば、インターリーブが効いてメモリアクセスが速くなるようになっているが、STFはこれに未対応だと書いてある。うちでは、8*2,16*2,32*2,64*1という構成になっていて、最後の64MBが一枚しかささっていないので、インターリーブ効いてないと思うのだけど、ひょっとしてスロット組ごとにインターリーブって効いたりするのかしらん。とりあえずメモリをバラバラに差し換えてみる。また、7600/132には、最初マザーボード上に256KBの二次キャッシュがついていたのだが、G3カードを挿す際に、もともとの二次キャッシュは足を引張ったり、不安定要因になるので外すように書いてあったので外していた。なんとなくこれも戻してみる。また、BoosterG3機能拡張ファイルを外し、より細かい設定のできる、PowerLogix G3/G4 Chache Controlerを入れて、安全方向にCPUの設定を変えてみる。(スペキュレイティブアクセスOFF,ライトスルーモードON、バックサイドキャッシュのスピードを少し落す)
その結果。なんとかSTFからの起動に成功した。まだ多少不安定だが、まあ使えない事はない程度か。よしよし。コミケで儲けてSTFと相性の言いG3カードを買うのだ(いまさらか？？)。
加賀電子から電話。「お客さまの症状ですと、即日修理が可能なので、来週の早い時期には届けられると思うとのことです。」うむ、なるほど。ついでに修理は海外の製造元で行うのかどうか聞いてみた所、「はい…あ、いえ、加賀電子内部で修理を行う所がありまして、そちらで行っています」あ、そーなんだ。すると、加賀電子の社内で修理部門まで届くのに数日かかるんだなあ。まあ、そういうものか。いや別に文句言ってるんじゃないです。「そうなんだ」と思っただけ。修理出したら、一ヶ月くらいかかっても、とりたててひどいとは思わないし。でもはやく来ないかな−。戻って来てもうまく動作するかどうかわからないが、動けば、3GBのハードディスクが一気に24GBだもんね。しかもいままでのSCSI2にくらべれば格段に速い(はず)。動かなかったら……どうしよう………。
2000年 6月 23日 金曜日 11:32:43 AM~
修理のため、加賀電子に先週送ったStorageFighterだが、いつごろ戻るのか気になったので、電話してみた。すると、「本日メーカーに届いたようですので、そちらに問い合わせてみて結果を連絡差し上げます」とのこと。むむ、詳しい事は聞かなかったが、この場合のメーカーって、OEM元のACARDの事かしらん。加賀電子の社内で修理とかするのだったら、もう少し違う言い方になる気がする。そういう事情だと、まあちょっと時間かかっちゃうかもなあ。ACARDって、結構Webページ繋がりにくかったりするのだが、台湾のメーカーなのね。ふむふむ、台湾で唯一独自にSCSIチップをデザインできる会社だと書いてあるな。あと、ファームウエアは、どのバージョンでどんな問題が解決されたかも書いておいてくれるとうれしいぞ、ACARD。
HNSの日記を書きはじめる時の手間を省くAppleScript。ミミカキエディット使用。
set fontName to "Osaka" -- フォントを変えたい場合、ここを変更
set fontSize to 12 -- 文字サイズを変えたい場合、ここを変更
on curMonth(n)
repeat with i from 1 to 12
if n = item i of ﾂ
{January, February, March, April, May, June, July, August, September, October, November, December} then ﾂ
return addZero(i)
end repeat
end curMonthon addZero(n)
return (text -2 thru -1 of ("00" & n))
end addZeroset curDate to current date
set curDate to "d" & (year of curDate as string) & (curMonth(month of curDate) as string) & ﾂ
addZero(day of curDate) & ".hnf"tell application "ミミカキエディット"
activate
make new document with properties {font:fontName, size:fontSize, mode:ﾂ
"HNS", name:curDate, character code:EUC, return code:LF, content:"OK" & return & return}
end tell
天気: 晴れ
観測場所: 相模原
前々から調子悪かったMOドライブが本格的にいかれてきた。書き込みエラーの頻発、マウントできない。コピーが異様に遅い。問題をメディアのせいにする(いやこれはこちらの感じ方か)。しょうがないので分解掃除に挑戦してみるも、MOドライブというものは、ハードディスクの次くらいに分解できないように作ってあるのだな。一晩かかってピックアップの所まで辿り着くも、掃除して調子よくなるわけでもない。MOドライブの場合、防塵構造になっていて、フロッピーのように内部に汚れやほこりがたまる事は少ないので、もともとそれが原因ではなかったかも知れない。疲れ果てた上に効果がないので、新しいMOを買いに行く。2万円以下の捨て値で売っているCD-Rにも非常に心が引かれたが、今まで取ったバックアップのMOが読める環境が優先なので、230Mの安いMOを探す。値段を見ると、もはや230Mは数が少なく、値段的にもお得感はあまりない。しかし、640MB以上のMOを買うのもCD-Rの値段を考えるとちとナニだ。結局ソフマップで中古の230MBが￥18,000で出ていたので、これにする。ついでにきつきつのハードディスク(現在3GB)も増設しようと思ったが、今さらSCSI2の内蔵バスに繋ぐのももったいない。最近話題のTurboMax(PCIバスに挿すUltraATAカード、MacからはSCSIバスに見える)を探してみるが、町田では売っていなかった。同じOEMもとのカードである、加賀電子のStorageFighter(以下STF)を見つけたので、これと、24GBのQuantum製HDを買う。
帰って来て、とりあえず本体を開け、STFをセットする。実はすでに内蔵ハードディスクが二つ入っているので(PowerMac 7600の匡体には2台までしか積めない)。一つを外し、新しいディスクをセットして、もう一つのディスクの中身をコピーしてから、今外した方のディスクを戻し、コピーを取ったディスクを外す、という難儀な作業をすることになる。
まあともかくセッティングして、起動後、純正のドライブ設定で初期化が可能だったので、それで初期化するが、どうも不安定である。STFのうたい文句で、起動ディスクにもなるということだったので、システムフォルダをコピーして再起動するが、起動中に爆弾やフリーズが頻発して使い物にならない。さて、作業手順を振り返ってみよう。今、新しいディスクにはコピーしたシステムが入っている。つまり、バックアップを取って外した方のディスクにシステムが入っていたわけで、今、MacのSCSIに繋がっているディスクにはシステムが入っていない。というわけで、インストールCDから起動し、SCSIのディスクにシステムをインストールする。結構疲れる。
で、とりあえずインターネットにつなげるように設定し、参考になる情報がないかと加賀電子のページを見てみる。STF用ファームウエアのアップデータがあったので、「これか？」と思い、ダウンロード。アップデートをかます。アップデートが済んだ旨のメッセージが出たので再起動。……起動しない。灰色の画面にマウスポインタが表示されたところでフリーズしている。実は、アップデータの注意書きに、STFにディスクが繋がっていない状態でアップデートしてくれと書いてあったのを見落としていたのだ。っていうか、見なかった事にしていたのだ。だって、17インチトリニトロンモニターが本体に直接乗ってるんだよ。できるだけ開け閉めしたくないんだよ。腰いためるんだよ。と言い訳してもしょうがない。簡単に考えていたが、これは容易ならざる事態だ。腰はさておき、しょうがないので蓋を空け、STFからケーブルを外し、カード単体でPCIスロットに挿さっている状態にして再起動。やはりダメ。マザーボード上のリセットスイッチを押し、さらにCommand+option+P+RでPRAMクリアもしてみるがダメ。どうやらファームのアップデートに失敗し、起動時のPCIバスチェックの時に凍り付いているようだ。この段階でこけられると、手も足もでない。アップデータを再度かける事もできない。なにしろ挿さっていると起動しないのだから。「もしかして」と思い、カードを外した状態で電源を入れ、ディスクを読みはじめてからカードを挿したりしてみる(絶対まねしちゃだめだよ、壊れるかもしんないから)。そうやって起動してから、アップデータをかけようとするが、この場合は、起動時にデバイスツリーに登録されないので、アップデータが対象になるカードを見つけられず、失敗。
万策尽きたので、加賀電子のサポートに電話する。事情が事情だけに、保証は受けられないかと思ったのだが、修理してくれるとのお返事をいただいた。ソフマップで、保証書に判子ついてくれなかったのだが、それも言ったら、レシートのコピーを添付すればいいとのこと。早速宅急便で送る。たのんます。
さて、まだ動いているうちに、何度か二つのSCSIディスクを付け替え、データを新しいディスクにコピーしていたので、これは消してもいいや、と、片方のディスクを初期化してしまった。データは新しい方に入っているのだが、カードが戻ってくるまでは失われているのと同じ。ちと困ったが、とりあえずしばらくはプログラム開発環境は無しでもいいし。PhotoshopとPainterはCDから再インストールできたので、コミケまではこれでよしとしよう。この日記をはじめとする、自分のWebページデータも消えてしまったが、これはサーバー上にあるので問題ない。適当な時期にもう一度ローカルに落してもいいし。
で、新しいMOは快調に動作している。MOってこんなに速かったんだ(笑)。しかし、今回MOを買い替えた理由の半分は、ディスクの空きを作るために、当面使わないファイルをバックアップして消してしまおうというものだったので、さっぱりディスク一つ初期化してしまったという時点で目的を達成してしまった。もう一つの理由は同人誌のデータ入稿のためにMOが必要というものだが、共信印刷がオンライン入稿をはじめたので、ひょっとするとこれも不要かも。まあ、同人誌一冊分のデータをWeb上のフォームから送信するのは無謀だと思うので、多分MOで送る事になると思うけどね。
観測場所: 相模原
天気: 雨
上の方にある、「御意見、御感想をどうぞ」という部分、設定ミスでForbiddenになっていた。以前は使えていたので、日記スクリプトのバージョンアップの時にミスったのだろうなあ。文句書こうしてできなかった人がいたらすいません。使えるようになったのでどんどん書いて下さい。
Macの調子悪いな−と思っていたら、クラッシュ後起動ディスクを認識しなくなった。「初期化しますか」とか言ってくる。CD-ROMで立ち上げ、Disk First AIDをかけてみたところ、修復不能。こういう時って、頭ぐるぐる回るよね。Nortonはずいぶん前に買った後、HFS+対応のアップデートをさぼってたから使えないし、起動ディスクの中身あきらめるしかないかなーと思ったのだ。画像等の作品データは他のボリュームに保存してたし、PhotoshopとかPainterも同様。重大な被害はないような気がしたが、よくよく考えると、mailデータ、WWWのブックマークといったインターネット絡みのデータが全部消える事に気づいた。これは結構大変だ。それに、PhotoshopやPainterも、レジスト入れ直さないと使えない。Macじゃこの手のデータは起動ディスクの初期設定ファイルに記録されるのだから。で、レジスト書かれたマニュアルやら封筒やらペラやらはどっかに埋もれていて、見つからないかも知れない。あらためて頭ぐるぐる。
落ち着け俺。速攻でショップ行ってNorton買ってくるか、でも結局復活できなかったら無駄金じゃん(無駄じゃなくて、今後の事を考えれば用意しておいていいわけだが、なんかNorton for Macはトラブルメーカーという印象が強くてさあ)。そういえば、DiskWarrierっていうのがいいと聞いた気がする。依然ちらりと発売元のページ見てみたら、ダウンロード型式で買えるようになっていた記憶がある。とにかく空きディスクにシステムインストールして、そこから起動し、インターネットの設定をした上で、ネスケでアクセスしてみる。といっても、ブックマークも全滅なので、適当な検索エンジンなど駆使してなんとか行けたのだが。
安い。ダウンロードオンリーなら$69だ!!。これなら復活できなかった時もまあ、あきらめがつくような気がする。ええいままよとクレジットカード番号を入れダウンロード。さっそく動かしてみる。選択肢もほとんどない、Rebuildボタンを押すしかないウインドウが表示される。ちょっとびっくり。こういうディスク修復ツールって、障害の分析やら段階的な修復やら、色々設定する必要あったりするような気がするのだが、大丈夫なのだろうか、これ。ええいままよ、とRebuildボタンを押す。修復段階は10段階、とはいっても、ほとんどの段階は非常に高速でパカパカと進む、ディレクトリ構造の再構築で、安全に行うだけのスペースがないので、強行するかどうか聞いて来た。要するに、ディスクに空きが十分在れば、問題の在る構造をそのまま残した上で、新しいディレクトリを構築し、うまくいかなかったら戻すとか言う事ができるのかな、このダイアログには、詳細表示及び、プレビューを行うボタンがある。プレビューすると、とりあえずマウントしてファイルを表示してくれる。よくわからないが大丈夫そうだ。というか、デスクトップから消え失せた旧起動ディスクの中身が何もなかったように表示される事に感動する。なんにしろキャンセルしたってしょうがないので強行する。ディレクトリ再構築が終わり、完全にディスクは修復されたようだ。ひょっとすると消えたファイルや壊れたファイルもあるかも知れないが、とりあえず今の所問題は起きていない。作業に要した時間は1分程度だったと思う。驚く程簡単で、しかも速い。ありがとうDiskWarrier!! お礼にこの場で宣伝してあげよう。なんてったって、クラッシュしてからその場で手配でき、すぐに使えるというのがいい。みんなにお勧めだ。おっと、URLを忘れる所だった。(http://www.alsoft.com/DiskWarrior/)日本語版の情報は(http://www.senko-corp.co.jp/html.file/ALSOFT.www/html/Alsoft_main_page.htm)にある。ただし日本語版はダウンロード販売を行っていない模様。とはいえ、壊れたディスクの他に使えるディスクがない場合、あっても空き容量が少なく、あらたに作業用のシステムをインストールできない場合、また、システムインストールの時間が惜しい場合等に便利。できればパッケージ版を買っておいた方がいいと思う。
WINのメールサーバーがIMAP4対応になるらしい。というわけで4/5に案内のメールが届いたのだが、
なお、これにともない、現在ご利用いただいているメールアドレス（ド
メイン部分）、および送受信用メールサーバが変更となります。皆さま
には長らくご愛用いただいているメールアドレスを変更していただくこ
ととなり、大変ご負担をおかけいたしますが、何とぞご理解をいただき
ますと共に、ご協力賜わりますようお願い申し上げます。
＜中略＞
■ご利用のメールアドレスが変更となります現在： ○○@super.win.ne.jp
または ○○@first.win.ne.jpサーバ切替完了後： ○○@pop.win.ne.jp
にて、メールサーバ切替によりお客様が現在ご使用のメールアドレスの
ホスト名部分が変更になる旨の記載がございましたが、この点についい
て訂正させていただきます。メールサーバ切替に伴うメールアドレスの変更はございません。
お客様には、メールサーバが切り替えられる５月１０日以降も、現在ご
利用のメールアドレスを継続してご利用いただけます。先のご案内により、メールアドレスが変更される点について、お客様の
中より現在のメールアドレスから変えないで欲しいとのご要望を多くい
ただきました。弊社へのご意見に心より感謝いたしますとともに、この
度のメールサーバ切替がお客様にご負担を強いる方式になり兼ねません
でしたことをお詫びいたします。
4.5だとIEをバックに回して、他の作業をやった後でフロントに戻すと、しばらくマウスカーソルが「読み込み中」のアニメーションを続けて、その後でウインドウが描画される形になっていたが、5.0ではこのアニメーションがなくなり、こういう場合の表示は速くなったようだ。ただし、IE上で複数のウインドウを開いて切り替える時等、微妙に重たい感じがする。それと、4.5に比べて、フリーズする度合いが上がったし、フリーズするとcommand+option+escで強制終了する事もできない。とはいえ、Mozilla5よりはまだ安定しており、動作も速い。今時のWebページは、Communicator4.7ではCSSがらみで文字化けする事が多いし、IE4.5ではFlashの動作に問題があったりする。iCabはまだCSSに非対応だし、現在のMac用ブラウザは非常に厳しい状況だと言える。
スクウェアの野村哲也氏の悪口ネタ。最初は普通の悪口だが、例によって途中から暴走。どんどん架空の「野村」が作られていく様はかなり面白い。野村氏本人が見たとしたら多分最初は怒るだろうけど、わらわら出てくる架空「野村」の言動には笑うんじゃないだろうか。もはやほとんど独自のキャラとして成立してしまっているのだから。
ちなみに、僕自信は野村氏が下手くそだとは思わない。まず基本的に僕よりずっと上手いし、少なくともFF7のキャラクターには華がある。パライブ、FF8あたりだとリアル指向になった分、漫画的な華は薄れた気がするが、FF7の「ポリゴンにすると気色悪い」部分を解消する方向としてのFF8のキャラ作りというのはアリだと思う。まあ、一方によりマンガチックなポリゴン作りという方向もあって、必ずしもリアル指向がベストではないのだけどね(デュープリズムは埋もれさせるには惜しいゲームだ)。それはそうと、野村氏のキャラ絵をポリゴンに起こして、元の絵と同じ角度でレンダリングした画像をよく見るが、スクウェアのモデラーの技術には本当に感心する。ここまでビタリと一致するように作るって、なかなかできる事ではないと思うのだ、そういえばクロノクロスのムービー等では、結城氏の濃いキャラをきっちりテイスト失わずに起こしているのに感心したっけ。
ちなみに、
509 名前： 野村 投稿日： 2000/03/15(水) 04:25てゆーかホントは僕チョコボ描いてれば幸せなんだ。あと乳な。
半裸デカから全裸デカに昇進したパライブのAyaな、あれホントはチョコボなんだ。
羽むしったやつな。
だいぶ前なんだけど、この日記のアクセスログを見たら、2chからの参照があったのね。探しに行ってみたけど、ここにリンクしてる記事は見つからなくて、なんか気になるんだけど。「イタイ厨房がドキュンだぜ(ワラ」とか言われてた？言われてた？気になる〜〜〜。
どうういわけかdi.cgiが、1974年1月1日を返す。つまり時刻取得に思いきり失敗しているらしい。不思議な事にコマンドラインから実行すれば正しい更新時刻を返す。普通ならディレクトリのパーミッション違いだと思うのだが、di.cgiが読もうとしているディレクトリは第三者読み込み及び実行/検索パーミッションがついている。何が悪いんだ。
細かく動作を追ってみると
@a= <$diarydir/$year/d*.hnf>みたいな行で、@aに何も入っていない事が判明する。ファイル名のワイルドカード展開がこけてるのか？これってperlの普通の使い方だよなあ。コマンドラインから実行するとちゃんと動くんだし。これを試しに、
ううむ。どうかな
my $file;
my @a = ();
opendir(DIR, "$diarydir/$year");
while ($file = readdir(DIR)) {
push (@a, "$diarydir/$year/$file") if $file =~ /\.hnf$/;
}
closedir DIR;
などとすると、ちゃんと動作する。不思議だ。何が起こってるんだ？どうやらclear_cache.cgiでキャッシュクリアされないのもこの辺があやしそう。あ、はい、すいません。MLに入ります。ふむふむ、nobodyがデフォルトですか。ところで、うちの環境、cgiの実行オーナーはよく見たら'www'でした。ううむ、インストール後に手動で行わなければならかった事はううむ、この問題、考え出すときりがないですね。すると結局GIFなんぞ使わずPNGってのも態度としては正しいか。hns作って配付してるチームからしたら、このへんでぶつぶつ「pngなんてつかえねーもんにしやがって、抗議運動様かい？けっ」(いやそんなにヤな言い方はしてないつもりだけど)とか書かれたら怒るかもなあ。僕が配布元だったらやっぱりPNGにしちゃうかもだなあ。
このページでは、ライセンシー全部が載っているわけではないので、よくわからないが、Appleはどうなんだ？これが大問題かも。
問題になったMicrosoftのライセンスだが、あれは要するに企業単位でどんと一括のライセンス料払って、IEなど個々のプロダクトの配布ごとにライセンス料かからないようになっているのだろうな。で、プロダクトそのものに限定されるライセンスではないので、適用範囲を明確にしないとまずいという事情があって、配布プログラムやAPIを使ったサードパーティまで拡大されないという事を表明したのだろう。それは分かる。Microsoftとしてはそこで責任範囲を決めてるわけで。サードパーティは個別にライセンスを取る。これは別に間違ってはいない。ただ、フリーソフトウエアはなんであれ、LZWを使ったGIFを生成する事も表示する事も一切不可能だと言う事だ。ここから、フリーソフトウエアのPNGへの流れが必然的に起こる。いいも悪いもなくGIFは使えないのだから。
してみると、NetscapeがMozillaベースのブラウザを無料で配付する場合は、おそらくMicrosoftのような一括ライセンスの元で行うから問題はないだろうな。ただ、Mozillaそのものの配布と使用という問題は残る。現在もM13/M14を試験的に使う事はライセンス違反になるのか。オープンソースである以上、誰でも自由にダウンロードして試す事ができる。
それはさておき、リーガルなツールで作成した画像そのものを配付する行為は問題ないはず。なぜならUNISYSの特許はLZWの圧縮と展開にかかるものだから。Webサイトライセンスは、オンデマンドで画像を生成するような状況を考えて作られたものであって、対象はやはり画像生成のためのソフトウエアであると思う。
ライセンスは、企業製のブラウザではあまり問題にならないので、GIFを追放する動機にはならない。バックワード・コンパチビリティを考えれば、サポートを急に外すわけにはいかないのだし。ましてや、PNGは単にデータを圧縮するものではなく、リッチな規格であるため、きちんとサポートしようとすれば開発コストが相対的に大きくなるだろう。
GIFは、256色以内であれば劣化無しで利用できる事、アニメーションができること、透過をサポートしているといった特徴がある。一方PNGは、GIFのできることはおおむねできて、その上フルカラー、半透明マスク、デバイス非依存で正確な色再現が可能といった特徴がある。ただし、GIFの最大の弱点であり、それゆえにJPEGがGIFと同じくらいメジャーになった原因であるフルカラーのサポートはまた、ファイルサイズの肥大という効果をもたらす。もちろん、同じ色数ではPNGの方がGIFより圧縮率が高いと言われており、この場合は問題にならないが、24bitカラーなどの画像を可逆圧縮すると、あからさまに大きくなってしまい、JPEGのような非可逆圧縮の圧倒的有利が目立ってしまう。要するにフルカラーではJPEG、256色以下ではGIFで十分、積極的に新しいフォーマットを採用する理由はないわけだ。
ただし、時代の流れとして、PNGが表示可能な環境はゆっくりと増えている。Netscape Communicatorも不完全ではあるが表示できないわけではない。NetscapeがIEに破れて、開発が大幅にスピードダウンした事が不幸の元であると思う。本来ならとっくにPNGの透過もサポートされていたはずではないだろうか。ブラウザがサポートすれば、便利なフォーマットはあっという間に広がる。初期のMosaicではGIFしかインライン表示できなかったが、NetscapeがJPEGをサポートして、一気にフルカラーでかつ軽い、このフォーマットは広まった。おそらく、あと一年もすれば、PNGを表示する上での不具合はおおむね解消されると思う。
もう飽きたと思うが、rogueの話。
rogueとの初めての出会いは、今はなきASCII-NETであった。ちなみに当時のASCII-NETでの僕のIDはASC08452である。それはさておき、初期のASCII-NETでは、login後のプロンプトからrogueと打てばrogueが遊べたのだ。ついでに、なにかとホームディレクトリにcoreを吐いていた(^^;。
ASCII-NETはVAX上の4.2BSDで動いていたと思う。おそらくあれはオリジナル版のrogueではないかと思うのだ。暗い部屋もあった気がするし。で、当時の感想としては、正直言って、「なんだこりゃ」って感じであった。ただ、通信ソフトの画面上で座標を操作してキャラクタが動くと言う事に感心したのは覚えている。当時の事だから、300〜1200bpsの速度で、かなりのたくた動いていたはずだ。
さて、現在フリーで出回っているrogueは、ほとんどTim Stoehrによる「Rogue Clone II」をベースにした物だ。Tim Stoehrは、BSD版のRogue 5.3のソースコードを入手する事ができず、自分でほぼ同じ動作をするゲームを作ってしまったらしい。オリジナルのソースは紛失したとも言われているが、現在その開発史をWeb上で読む事ができる。興味深い事に、初期のMacにRogueを移植したと書かれている。これは「Dungeon of Doom」の事だろうか。オリジナルの開発者達は会社を作り、各種パソコン版のRogueを販売するも、あまり当たらなかったらしい。そして、ここからリンクされているDoom では、PC Rogue のソースを(GIF画像で)見る事ができる(太田さん、ここにありますぜ)。BSD版関係者が作った会社のもので、オリジナル版の直系と言っていいだろう。
もうひとつ、Rogueバリエーションの一つで、UltraRogueというのがある。Rogueをもとに、AT&T/ベル研で開発されたAdvanced Rogue(これは最初のroguelikeゲームだそうな)をもとにして開発されたもの。現在SCOのサイトからソースがダウンロードできる。キャラクターのクラスがあったり、店(ノミの市)があったり、アーティファクトがあったり、このへんで現代のroguelikeゲームの要素が出来上がりつつあるようだ。なかなか興味深い。
ところで、今時のインターネットプロバイダの多くは、telnetによるshellの利用を許してはいないが、winではこれができるし、nethackが遊べたりする。ちょっとASCII-NETを思い出すな。
まあ、winでシェルアカウントを持っていれば、ccやgccが使えるので、自分のホームディレクトリでrogueとか適当にコンパイルして遊ぶ事は可能なのだが、システム側で用意して遊ばせるところがちょっと微笑ましいような気がする。そもそも、電話回線繋いだままnethackふつうやらないよなあ。自分のパソコンでできるし、rogueやnethackをオンラインでやるってのは、スコアを他人と競えると言う楽しみはあるのだが………
そろそろなんか発表されてるころだろうか。ううむ、1月のSFで新機種発表がなかったから、今回どーんと発表されると言う噂がたちまくってるけど、世界的な発表があるんだったら、基調講演を生中継しないはずはないと思うのだがどうだろうか。日本発の大規模ストリーミング中継は色々難しいかもしんないけど。
ま、とりあえずこの日記は結果が出てからサーバーに送ろう。
と書いてひと休みしたら、発表されてたみたい。ハードウエアは、まあ順当な所、PowerBookはAirMac対応、FireWire搭載など、iBookはメモリ/HD増量で値段据え置き+グラファイトのスペシャルエディション登場。G4は400〜500にスピードアップ、というか、当初のスペックに戻るって感じ。興味深いのはむしろMacOS Xに添付されるヒラギノ6書体かしらん。OpenType、17000文字搭載で、明朝、ゴシックそれなりに使えそうなバリエーションで揃っている。
どうもrogueの動作が遅い。自動移動などで、時々いらつく程度に遅い。これではPPCネイティブ化した意味がない。実際68k版と動作速度が変わらない気がする。PPCProfかましてみたら、かなりの部分DrawTextに食われている。API呼び出しがCPUタイムのほとんどをくっているわけで、これでは68k版(エミュレーション)との差も出ないはずだ。つまりこちらの責任ではなく、MacOSのAPIが遅いのだ。と言いたい所だが、アンチエイリアステキストの描画なんて、どうやったって遅いのは当たり前。無駄にDrawTextを呼ばないようにするべきなわけで、MacCursesのコードを調べると、wrefreshの度に全画面描きなおしてる。まあ動作として間違ってはいないが、無駄だ。特にrogueだけに使うなら、あまりいろんな状況を考えなくても良いので、表示行数分の真偽値フラグ配列を用意し、文字追加などのたびに「この行はアップデートが必要だよ」という印をつけ、wrefreshの時には、その印がついてる行だけ描画するようにする。
真に無駄を省くなら、文字単位でダーティかどうか判断し、最小限の描画で済ませるという方法も考えられるが、DrawTextは小数点幅の文字を制御するため、一文字ずつ描画する場合と、一行描画する場合で幅が若干異なってしまう。行単位のフラグで十分速くなったので、これでよしとするか。
というか、すでにちと速すぎる。これでは移動途中を表示しない設定とあまり変わらない。移動中のキャラクターがジャンプ移動しているように飛び飛びに見える事を考えると、どうやらモニターのリフレッシュレート以上の速度で画面を描き換えているようだ。うちはPowerMac 7600にG3/266を挿しているが、おそらく今どきのマシンはCPUクロックのみならず、バススピードもビデオカードも高速化しているから、どれもこれの倍速いだろう。そうなると、移動途中の表示を切った状態と変わらない事になる。一般的なモニターとビデオカードの組み合わせなら、どれでも60Hz以上のリフレッシュレートだから、60fpsにしておけば、移動中のキャラクターは完全に表示されるはずだ。前回表示してから1/60程度経たないうちは次の描画を行わないようにした方がいいような気がする。60fpsだと、横一杯移動するのに約1.3秒かかる計算になるか、うーん、悩ましい。ま、いいか。ウエイト入れとこう。ここに置いておくので、Macユーザーでrogueやりたいひとはもって行って下さい。
ソースをメッセージ分離版rogueに変更。これでMacでもLeafRogueができたりするわけさ。ところで、メッセージ分離版は起動時にコマンドラインでデータファイルを指定する事になっているが、当然Macにはコマンドラインがないので、他の方法を取らなければならない。最初はrogue本体と同じディレクトリにデフォルトのメッセージファイルを置いておいて、とりあえずそれを読ませ、初期設定ダイアログで変更可能にするというインターフェースで作ってみたが、これだと、もしアプリケーションだけを別の場所に移動したりすると起動すらできないことになる。また、初期設定ファイルにメッセージファイルのエイリアスを保存させるようにしたので、間違って関係ないテキストファイルを指定してしまった場合、エラーで落ちて、初期設定ファイルを削除しないと二度と動かないということになる。色々悩んだ挙げ句、デフォルトのメッセージファイルをアプリケーションのリソースフォークに格納して、指定したメッセージファイルに問題があったらデフォルトメッセージを読み込んで起動するように改造。
前に書いたセーブファイルのIDの件、Macの機能で実現は可能なのだが、問題はボリュームを超えての「ファイルの移動」ができないこと、およびHFS系のファイルシステムでないとファイルIDが有効でないということ。最初に保存したディスクと別のボリュームにセーブファイルを動かすと、コピーを作った事になり、そのファイルから起動できなくなってしまう(同じボリューム内での移動はOK)。セーブファイルの厳しさをそこまでつくりこまなくてもいいと思い、やはりやめることにする。ところで、UNIXでは例えばmvコマンドでボリューム跨いでもきちんと移動になるが、この際、rogueのセーブファイルはきちんと同一のファイルとして扱われるのだろうか。確かUNIX用の処理では、inode番号を使っていたが。
調子にのって、rogueをCarbonアプリケーションにしてみる。いろいろ書き換えなければならない所も多いが、なんとか動作する。しかし、どうも根本的な問題がある。
CarbonはMacOS APIをMacOS Xで使えるようにするものだ。これに添ってアプリケーションを作れば、MacOS Xのメモリ保護、プリエンプティブマルチタスクなどの恩恵を受ける事ができる。おまけに、MacOSでもMacOS Xでも一つのバイナリで動作するアプリケーションができる。ただし、CarbonがサポートするのはMacOS APIのみであり、ANSI Cの標準ライブラリなどは含まれない。もともとMacOS X にはBSD互換レイヤーがあり、ネイティブに標準ライブラリが使用できる。MacOSの場合には、OSにStdCLibという標準ライブラリが組み込まれていて、これに動的にリンクすることで、不完全ながら標準関数が使える。当然、rogueみたいな移植モノではStdCLibに依存した移植を行うわけで、アプリケーションからStdCLibへのリンクは外せない。
MacOSでCarbonアプリケーションを開発する時は、CarbonLibを動的にリンクする。この共有ライブラリは、MacOS上でCarbonアプリケーションを動かすためのモノだが、これを使う場合、クラシックなMacOS アプリケーションを作る時にリンクする基本的な共有ライブラリ(InterfaceLibなど)の機能をCarbonLibが内蔵しているので、それらはリンクせずCarbonLibだけをリンクする事になる。この段階で、MacOS XのBSD/POSIX互換レイヤーを呼び出すライブラリをリンクする事はできない。もし、そのためのstubファイルが用意されていても、それではMacOS上では実行できないOS X専用バイナリになってしまうだろう。可能なのはStdCLibをリンクする事だが、これはMacOS組み込みなので、MacOS Xでは使用できない。おそらく起動しようとすれば共有ライブラリのロードに失敗してエラーを出すだろう。
バイナリ互換を保ちながらMacOS/MacOS Xでの標準ライブラリを使用するには、共有ライブラリそのものであるStdCLibをアプリケーションと同じフォルダに入れて、一緒に配付するという方法が考えられる。現在、静的ライブラリのStdCLibは配付されておらず、共有ライブラリ版のみであるため、通常のPPCLinkでアプリケーションに直接組み込む事はできないが、Carbon環境がClassicと同様、アプリケーション直下などの共有ライブラリを自動的にサーチして使用する仕組みであるなら、これは動作する可能性が高い。アプリケーションとライブラリという、分割ファイルになるのが気に入らないが、これはOS X御得意のパッケージにしてしまうという手もある。
もっとも、このStdCLib共有ライブラリについては、Carbon互換ではないので使うなとドキュメントされているという凄い問題があるのだが………
Mac版jrogueのPPCネイティブ & カラー化に取り組んでいる。
これこれ、この色、昔PC98版をやったときの色だよ。うふふ。ついでにMacOS 9のマルチユーザーに対応して、ログイン名をきちんと取り出すようにする。他のユーザーのセーブファイルではプレイできないようにするのだ。Rogueって、セーブファイルの扱い厳しいよね。セーブから再開したら、そのファイルは自動的に消えてしまうし、他人のファイルでは遊べない、さらに、ファイルをバックアップするとダメ。データに改造加えてもダメ。ただ、今回は、昔使っていたThink C付属のUNIX互換ライブラリが使えないので、ファイルIDを判断する部分を無効にしてしまった。というわけで、今の状態ではセーブファイルをコピーして、何度でもやりなおしができてしまう。これ、どうしようかなあ。きちんと自分でそのへん判断する関数作るべきか？
しかし、これやりだすと、セーブファイルを置く場所も問題になるなあ。制限付ユーザーでは、アプリケーションのあるフォルダでは保存できないかもしれないから、デフォルトでユーザーの書類フォルダにリダイレクトするようにすべきか？fopen系の関数にこれやらすのは結構面倒。MacOS 9に含まれるStdClLibではFSSpec使う代替関数が用意されてるけど、MacOS 9限定にするとか、StdCLibのshLibつけるとかはしたくないし……
さて、フォントメニューは前からあるけど、簡単にやっているので、インストールされてるフォント全部表示してしまう。本来等幅フォントのみにすべきだと思うけど、FONDリソースのフラグで等幅かどうかチェックすると、通常の日本語等幅フォントはほぼすべて等幅でないというフラグになっている。1Byte部分と2Byte部分の幅が違うからかしらん。で、CharWidthで' 'と'W'の幅をチェックして同じだったら等幅とみなすという処理を加えたら、フォントメニュー構築にむちゃくちゃ時間かかっちゃうので断念。
あと、ゲームのオプション設定をMacっぽくGUIで行って、初期設定フォルダに置くようにしないとなあ。この部分はあきらかに面倒なので前にやったときも放置していた部分。
ところで、カラーの黒地白文字で12Pt程度だと、モニター解像度が高い場合、非常にみにくい。しかし、24Pt位にして、アピアランスコントロールパネルで、なめらかな文字で表示する設定にすると、なかなかいいかんじである。小さいサイズの時と、大きいサイズの時では、きれいに見えるフォントも変わってくる。昔の画面の雰囲気を味わうためにはビットマップのASLFont+を拡大して使うのもわるくないが、20ポイントあたりからきちんとアウトラインをきれいにラスタライズするようになった「等幅ゴシック」も捨てがたい。W7位の等幅明朝体があれば、それもいいと思うが、うちにあるフォントでは、等幅明朝とリュウミンライト−KL−等幅といった、細い書体しかないので、ちと見づらい。ただし、これらの書体を使う場合、ゲームオーバー時の墓石表示が化ける(\をバックスラッシュとして表示できないため)。もちろん\が円記号なのはJISのコードでは正しいので、ASLFont+eのように、コードの左半分をASCII互換にしてあるフォントを使うというのはいかにも対処療法っぽくて気持ちが悪い。このゲームの中では、基本的にバックスラッシュが表示される事を期待して使われているので、表示部分にフックして、書体を一時的に、勝手に切り替えるべきか……っつーか、それ、まともにやったら表示遅くなって多分だめ。QuickDrawの低レベルフックを使う手はあるけど、そこまでやると複雑になるしなあ。
と思ったら、実はMacOS用の日本語フォントでは、0x80にバックスラッシュが割り当てられている事を発見!、これならもとのメッセージの文字列リテラルを書き換えるだけでOK、スピードは一切犠牲にならない。0x5Cにバックスラッシュを割り当ててるASLFont+eの場合、0x80に円記号を置いているのでこれを使われるとやはり化けてしまうが、この場合は、eなしのASLFontが使えるので問題は少ないと思う。
天気: 晴れ
観測場所: 相模原
hnsの日記をmailで更新するmail2nikkiだが、添付した画像を自動的に切り出して、設定した画像ディレクトリに入れてくれたりするとうれしいな〜。
というわけで、mail2nikkiの前にかますフィルタを作ってみる。本文中に出てくるマルチパートのヘッダの、Content-Type: image/を見て、取り出すかどうか決めようと思ったら、僕が使っているmailerがAppleDoubleで添付する画像って、application/octet-streamなのな。ううむ、
しょうがないから、'Content-Type: 'があり、かつ'name='がついてるヘッダを見つけて、ファイル名を取り出す。なんていいかげんな………
Content-Disposition:を見た方がいいのかな？name=じゃなくてfiilename=がついてるし。でもこれって必須だっけ？MIMEのRFCってすげーでかいから参照するのいやだし
multipartってのも、むちゃくちゃ自由度高くて、バウンダリが入れ子になってたり、かなりいやーんな感じ。
しかし、考えてみたらmailer立ち上げるのもfetch立ち上げるのも、手間としちゃ変わらん。すくなくとも、うちの今の環境で、mailで日記更新する積極的な理由が何もない事に気づく。アホか僕？
というわけで、急遽計画取り消し。今まで通りftpで更新する事にする。根本的に、hns系の日記スクリプトが本当に便利なのは、サーバーに直でloginして、emacsなどでつらつら文章書く人であろうと思う。これだと「日記ディレクトリに文書置くだけ」という感覚で使えるよね。この差は本当に微妙なんだけど、ローカルな感覚とリモート感覚には結構壁がある気がする。誤解されると困るけど、物理的なネットワークの事を言ってるんじゃないよ。違うOSでの平行作業と、その摺り合わせ部分がちょっとだけかったるいという話。たとえば、hnsがすこしの改造でMacOSで動作する事はわかったので、自分でMacOSのWebサーバーを立ち上げて公開すれば、これはこれでとても楽だろう。まあ、諸処の事情でそこまではできないが。できるだけ操作感覚を変えない工夫をすれば、かなりローカル感覚に近付いていくと思う。ミミカキエディットで直にftpサーバーに保存できるようにするとか、いっそftp先のディレクトリをMacOSのデスクトップにマウントしてしまうとか(Finder感覚のFTPソフトと言うやつも色々出ているが、やはりFidnerとは別のアプリケーションであり、シームレスに使える感じはしない。アプリケーションの保存ダイアログから使えるわけでもないし。)。apple.comのiDiskが、実際外部ファイルシステムとしてマウントできる仕組みを提供しているが、ああいう感じで、任意のftpサーバーにアクセスできる仕組みを誰か作ってくれないか。余談だが、iDiskはISDN 64kでも遅すぎてちと苦しい、ああいう仕組みを本当に生かすには、Mbpsクラスのネットワークが必須だと思う。ああ、インフラ………うちのマンションの住人、誰かタイタスに加入してくれないか。*1
というわけで、Mozzila M13が出た。以前のバージョンよりは大分安定しているようだ。とはいえ、異常に処理が重くなったり、フリーズしたりする事もあるので、実用的というにはまだちょっと足りない。
全体に重たいのだけど、画面の表示自体はわりと速いし、今のMac版Communicatorみたいに、ウインドウのリサイズでいちいち画面をクリアしてゆっくり書き直すということもない。おもしろいのは、メニューに最初から組み込まれている、各種翻訳サービスだ。英語→日本語、も可能だが、翻訳能力は一昔前のコンシューマ向け翻訳ソフトなみ。原文より意味がわからなくなる。ちなみにこのスクリーンショットはRumorsのページを翻訳してみたもの。クリックすると全体図が表示されるが、ざっと350KBぼどあるので、覚悟して見るように。
見て分かるように、Mozillaでは、スクロールバーや、ボタンといったGUI部品を、完全に独自な方法で実装している。この方法はおそらく全プラットホームでGUIを統一するのに役立つだろうが、Macユーザーには違和感が強いし、なにしろおそらく内部的にはOSのサービスを使えば済む部分をわざわざ二重に実装しているわけだから、遅くなるし、プラットホーム内の他のソフトとの統一性はなくなる。ただ、このGUI部品は、それ自体入れ換え可能なものみたいなので、まあ、実際にモノが出来上がってくれば、MacOS風とか、Aqua風とかのカスタマイズは可能であると思われる。また、ソースを見ていないのではっきりした事はわからないが、GUI部品まで独自に実装するという事は、プラットホーム依存部分を減らして、ソースを共通化するという部分でも役にたっているのではないかと思う。なお、M13は初のα版だそうだ。β版にむけて、バグレポートをたくさん送ろう。英語できたらね(^^;。
Namazuが動かない原因はやっぱりパーミッションだった。nobodyで動くcgiがnamazuのindexを読めないという問題。ちょっと手を入れて動くようにする。
しかし、詳細指定/ヘルプのページ、検索式の例が文字化けしてる。スタイルシートでモノスペースフォントを指定しているのがいかんらしい。これはネスケのCSS実装がタコなのだとしておこう。どうやら、lang="ja"になっていようがいまいが、サンセリフ、セリフ、モノスペースといった指定はすべてローマンフォントになってしまうようだ。おかげで最近は読めないページが多い。Appleのページでも、たとえば8.6のテクニカルノートなど、ネスケでは見出しが化けて読めなかったりする。なお、9のテクニカルノートはネスケでも正常に見る事が出来る。
Mozilla M13では、日本語でもこれらのフォント属性ごとにフォントを割り当てられるようになっている(そういうインターフェースはできているが、まだ設定が実際に有効にはならないようだ)ので、いずれはきちんと見られるようになると思うけど。
天気: 晴れ
観測場所: 相模原
サーバーの/usr/local/binにkakasiが入っている模様。しかし不完全なようで辞書がないといって動かない。ローカルディレクトリにインストールする。なんかmknmzが単に名前で呼び出してる所があるらしく、ローカルの方を呼んでくれない。それっぽいところを書き換える。hns-index2が実行できるようになった。namazu2.cgiをコマンドラインから実行するとそれなりに検索結果をテキストで返す。コマンドラインから-hオプションを付けて検索するとHTMLで返す。しかしブラウザから実行するとInternal Server Error………またパーミッションの不整合かしらん？？それとも別の原因が？？まあいいや。とりあえずほっとこう。
とりあえずこのへん参考にさせてもらってます。
この日記CGIには、管理者がアクセス記録を見る機能があるのだが、今日の午前9:00頃から大量のアクセスがあった。ロボットだろうか、.frドメインからなのだが、ブラウザ種別がLSLってのも聞いた事がない。なんか登録されている日付けの日記をすべて読み、それから1999年、2001年、1998年、2002年という具合に、過去と未来を交互にリクエストし続けてどんどん振幅が広がっていき、過去は1984年、未来は2039年まで行っている。ううむ。なんか火の鳥みたいだ。
天気: 晴れ
観測場所: 相模原
BGM: スパロボ
その後の進展。
カテゴリアイコンを収めたディレクトリを":cat"みたくHFS表記であらわすのは色々問題が多い。これはThemeファイルにも出てくるので、こういう風にThemeファイルをいじってしまうと、日記のデザインそのものをローカルでチェックしてからプロバイダの方に送ると問題が起こる。それに、問題はあくまで画像サイズ取得に絡む部分であり、本来ブラウザで見る時には"/"表記でいいのだから、デフォルトを"/"表記にしておいて、Size.pmだけを書き換えるようにした方が合理的。というわけで、Size.pmの42行付近に追加
my ($file, $width_maxsize) = @_;
### Add by juan for mac
if ($file =~ /^\//) {
$file =~ s/^\///;
$file =~ s/\//:/g;
} else {
$file =~ s/\//:/g;
$file = ":" . $file;
}
### End mac addition.
天気: 晴れ
観測場所: 相模原
おお？こんなとこ見つけちゃった。みんな考える事は一緒だなあ。おお、流線も描けるのか、ああ、僕のは未公開版でしかそれ実現してない。アルゴリズムは三角形(or ひし形)描画方式かしらん。このサンプルでは解像度が低くてよく分からないけど。次回のコミケで襲撃しようかな。いやうちはWindowsマシンないから、プログラムは使えないけどさ。おもしろそうな同人誌作ってるし。
天気: 雨
観測場所: 相模原
睡眠時間: 0
BGM: ダイガード
hnsをMacにインストールする事に一応成功。と言っても、なにしろshもmakeもないので、プロバイダのユーザーディレクトリにインストールしたものを、ディレクトリ構造ごとftpでローカルのMacにもって来た上、config.phをMac上のディレクトリ構成に会うよう編集、さらに、MacPerlがパス区切りに「/」ではなく「:」を使っているので、あちこち修正。で、おおむね動くようになったんだけど、どうにもカテゴリのアイコン表示がうまくいかない。これがまたMacのパス区切りに由来する問題だというのははっきりしている。
hnfは、偉い事にアイコンイメージ等の画像を表示する際、自動的に縦横のドット数を取得して、IMGタグのWIDTH,HEIGHTを生成する。このルーチンはURI型式でファイルを得る事ができないため、ローカルのパスを指定する必要がある。この部分のために、画像の入ったディレクトリを「:cat」という具合に、HFSの部分パス表記で与えてやる。これは機械的にソースのパス記号を書き換えると言う作業の一環で対処可能である。ところが、hnsがIMGタグのSRCパラメータを生成する際、画像ファイルの縦横比を決定する時に使った部分パス名をそのまま使ってしまうのだ。従って、このままではタグは
<IMG SRC=":cat:foo.gif"...>という形になる。これは当然URIとしては通らない。対処法としては、タグを生成する所で、
$src =~ s/^:/.\//;
$src =~ s/:/\//g;
などとしてやればいいわけだが、ちょっとソースの解析も疲れたのでひと休み。こんな特殊な事情を繁栄させてもあまりいいことない気がするし。カテゴリアイコン出なくても、ローカルでの日記のチェックにはあまり差し障りないし。なにより僕Perlってよくわかんないのだ。しかし、こういう時って、Macのパス表記が憎くなるね。なにしろMacでも当然ながらURI表記はあくまで「/」なのだ。Macのパス表記が「:」であることには利点もあって、ShiftJISを使っているにも関わらず、外国製のソフトを使っても日本語の２バイト目がパス区切りと判断されてやっかいなことになったりしないのだが、もはやMacのファイルシステムも内部ではUnicode化されているので、あまり関係ない。いっそMacPerlも「/」区切りにしちゃってくれないものか。確かにMacではファイル名として「/」が使える事になっているので、場合によってはひどい事になるかも知れないが、それを言うならWWWブラウザでローカルボリュームを表示する場合も同じ事ではないかなあ。全体にMacPerlはうまく移植されていて、パス表記を書き変えればたいがいのスクリプトは動いてしまう。それだけに惜しい。
天気: 晴れ
観測場所: 相模原
BGM: おかあさんといっしょ
漫画によくある集中線をコンピューターで描画する方法。
はじめに単純化した集中線を考える。中心から距離rまでは空白である。この、距離rの点をr1とする。中心からr1を通って外側に向かう直線を考え、その先の、中心からの距離r2の点を考える。線は、この描画開始位置r1から、r2まで引かれる。この線分をlとする。
lとX軸が作る角度をθとし、θを0から2π(ラジアン) まで変化させながら、その角度に応じた線分lを引けば、半径r1から半径r2までの直線がぐるりとウニの刺のように描かれた図形が出来上がる。任意のθにおける、r1とr1の位置(x1,y1), (x2, y2)は次のようになる。
x1 = r1 cosθ
y1 = r1 sinθx2 = r2 cosθ
y2 = r2 sin θ
dim x1, y1, x2, y2, r1,r2 as integer // 座標
dim dig as double // 角度dig = 0
r1 = 50
r2 = 100
while dig < 2* 3.141592 // 角度が2π(一回転分)になるまでくり返す
x1 = r1 * cos(dig)
y1 = r1 * sin(dig)
x2 = r2 * cos(dig)
y2 = r2 * cos(dig)
me.graphics.DrawLine x1,y1,x2,y2 // (x1,y1)から(x2,y2)まで線を引く
dig = dig + 0.05 // この数値が小さい程線の密度が上がる
wend
この方法で描かれる集中線は、まるで太陽柄のスクリーントーンのように規則的で、とても集中線とは言えない。漫画の一般的な集中線に近付けるためにはどうしたらいいかを考える。
線の開始位置をランダムにずらす必要がある。以下のrnd関数は0から1の実数乱数を生成するとして、
r1 = 50 + rnd *10
r2 = r1+ 50
これでも実際の漫画に使えるような集中線は描けない。ペンで描かれた集中線は、外側は太く、中心近くで細くなっている。これを実現するためには、単純にr1からr2に直線を引く方法では対処できない。そこで、集中線ジェネレーターでは、中心から外側に向けて広がる二等辺三角形を描画する事にした。しかし、この方法では、実際にペンで描かれた物に比べ、直線的に太さが変わるため、機械的な印象が否めない。また、描画する距離が長くなると、必要以上に外側が太くなり、あきらかにペンのそれとは異なる様相を示す。これに改良を加えたバージョンでは、円弧の一部を切り取った図形を二つ張り合わせた多角形(筆の穂先のような形になる)*1を作り、これを回転させながらコピーする方法を取った。この方法は多少複雑だが、線の最大の太さが長さで決定できるため、どこまでのばしても、最大の太さが設定をこえる亊はない。このアルゴリズムを応用して、カーブした集中線も描けるようになった。
ある事情で、このバージョンは公開できなくなったが、近いうちに最低限これと同じ機能を持つソフトウエアが登場するはずである*2。
天気: 曇り
観測場所: 相模原
ミミカキエディットでhnfを書くためのマクロやAppleScriptをがしがし書く。メニュー上のレイアウトがどうあるべきか、ショートカットは？そもそもツールとして実装する意味のあるコマンドはどれか、等考えると結構大変。そういえば、どうもAppleScriptから
set selection of dcument 1 to hogehoge
aaa
bbb
ccc
OL
LI aaa
LI bbb
LI ccc
LI
/OL
tell application "ミミカキエディット"
deactivate
copy selection of document 1 to targetStr
set CurDelim to AppleScript's text item delimiters
set AppleScript's text item delimiters to return
set targetStr to text items of targetStr
set AppleScript's text item delimiters to CurDelim
set endStr to "OL"
repeat with i in targetStr
set endStr to endStr & return & "LI " & (i as string)
end repeat
set endStr to endStr & return & "/OL" & return
set selection of document 1 to endStr
end tell
global a
set a to "ftp:****/diary/2000/"
tell application "ミミカキエディット"
deactivate
text returned of (display dialog "日記をアップロードします" default answer a) returning btry
copy file of document 1 to f
tell application "URL Access Scripting"
activate
upload f to b replacing yes with progress and authentication
quit
end tell
on error
display dialog "アップロードできません。ファイルが保存されていない可能性があります。"
quit
end try
end tell
Yahooの株価が一億円を突破!! それにしても売り出し時200万前後で、その後の値動きも緩やかだったのに、この一年でいきなり50倍はすごいよなあ。サラ金から金借りてでも買うべきだったって感じ？でも上がり過ぎにびびったか、どっと売られて急落、あらあら。頂点で売った人は儲かったんだろうなあ。
さて、Yahooだが、確かに最近やけに元気だ。なんでかなあ。検索エンジンとしては、なにしろ手動登録なので、最新の情報は少ないし、ヒット率もそんなに高くない。とにかくなにか特定の単語をキーに情報を探すというなら、ロボット使った他のエンジンの方が多くのデータが得られるはずだ。もちろん、単に該当単語を探す方式だと、およそ無関係なノイズ情報が多すぎて、結局検索の意味がなかったりするので、クオリティの高い情報を得ると言う点では、Yahooの方式が正しいとは思う。Yahooでヒットしなかった時、他の検索エンジンで探す事ができるようになっているとはいえ、なんかハイテクっぽくないよねえ。サイトのデザインも、あえてブラウザの基本色をそのまま使う設定になっているので、大概の環境では灰色の地味な画面になる。一般ユーザーへのアピール度は低い気がするのだが………
どうも、人気の秘密はいろんなサービスを組み合わせるやり方のうまさにあるのかもしれない。Yahoo ページャーとかってみんな使ってるのかな？まあ、どこも似たようなサービスを行っているわけだが、検索エンジンと掲示板、各種ニュース、ダウンロードサービスなどがうまく組み合わされて、一昔前のNIFTY-Serveみたくなっているような感じかも。僕も最近は、なんか大きな事件があったりすると、Yahooのニュースと掲示板を覗く事が多い。大きな事件があると、トップページに登録され、関連情報にアクセスしやすくなっているし、他の人の意見が知りたい時は、そこから直接関連した話題が交わされている掲示板のトピックにリンクされていたりする。各サービスの連係がうまく取れていて、結構利用しやすいのだ。あの地味なページ設計も、必要な情報を探す時には軽くていい。考えてみれば、世の中ネットで辞書を引くように検索しなければならない事はそう多くはない。どちらかといえば、今世間で話題になっている情報が整理されて提供されている方が、多くの人には有り難いだろうと思う。他のサイトが、情報を収集するだけして、「さあどれでも持っていけ」という形であるのに対し、Yahooは積極的に情報を選択し、加工し、提供するという姿勢である、という感じかしらん。
Yahoo掲示板の内容については、なんつーかアレな事も多く、ナニなのだが、またいずれネタにするかも……
天気: 晴れ
観測場所: 相模原
この日記の見栄えをよくしようと、色々設定いじっているのだが、スタイルシートって、いまだに動作があやしいなあ。読みやすいようにと思って、line-height: 1.5emとかしてみたら、!!←こういう顔アイコン入った行が、次の行と重なっちゃって読めないでやんの(NN4.7)(T_T)それとも、これはCSSの仕様なのかなあ。よくわからん。というわけで、結局行間の設定はデフォルトのままになってます。読みにくいが我慢してくれ。
MacOS 9 の、ほとんど知られていない機能にMLTEというのがある。32KBオーバーのテキストを編集できるエディタエンジンなのだが、これ、実はWindows型式のTrueTypeフォント、OCF,CIDを含むPS type1フォントをATMなしで使えるのだ。未だAppleからSDKもサンプルコードも出ておらず、ドキュメントもひどく簡単なPDFファイルが提供されているだけなのが災いしてか、これを使ったソフトがさっぱり出てこないのだが。結構すごいと思う。エディタとして必要なほとんどの機能はAPIの呼び出しだけで済んでしまうし、その機能の豊富さはちょっとしたワープロ並みだ。画像やムービー、サウンドも張り込めるし、データの保存、メニューのハンドリング、コード変換、文字スタイル、タブ機能、インライン入力となんでもござれ。
でもATSUIを使うようにすると、フォントメニューの構築に数秒かかるようだ。また、フォントメニューがすべて英語で表示されるのはつらい。QuickDrawを使うようにすると、Type1フォントが使えない。ううむ………微妙にまだ作り込みが甘いような気がするなあ。
右の画像は、とりあえずMLTEを使ったプログラムをでっちあげたもの。保存もなにもできない、ほんとのサンプルなので、プログラムそのものは公開しません。
ちょっと僕もよくわからないけど、もしMLTE試してみて、ATSUIを使うモードでうまく行かない場合。
TXNFocus(oTXNObject, true)；
してみるといいかも。とにかくウインドウがアクティブになった時には、これ入れないとまるで文字が入力されないか、デタラメな文字が入るみたい。あと、nullEventだけじゃなく、mouseDownなどのときも
TXNTSMCheck(oTXNObject, &gEvent);
しないと、マウスクリックによる変換操作が効かない。
天気: 曇り
観測場所: 相模原
体重: 50
体温: 36.5
睡眠時間: 0
日記の書き方を変えた。以前のやりかたでは、日記本文のHTMLを書き、さらに、タイトル一覧のHTMLを書き、リンクを正しく張ってftpしなければならなかったので、なにかと面倒になってしまったのだ。こういう作業はできるだけ自動化して楽をしたい。いっそ掲示板の入力フォームを隠して日記にしてしまえばいいのではないかと思ったが、これはこれでいろいろ問題もある。日記は掲示板と違って、一定件数たまったからといって機械的に消していいものでもない。レイアウトなどの自由度でも掲示板は少し寂しい物がある。で、なんかそれ系のCGIがないかと探してみた所、いろいろな物が見つかった。それこそ管理者しか書き込めない掲示板、という形態のものが多かったが、あくまで日記テキストをサーバに置くところは書き手に任せ、表示と検索に力を入れた方向性のものがあった。これもよく似た型式の物がいくつかあったが、とりあえずHNS(Hyper 日記 システム)というものをインストールしてみた。それがつまり、この日記である。話題をカテゴリにわける事もできるし、カレンダーから適当に読む事もできる。なかなかすぐれものだと思う。さらに、全文検索エンジンNamazuと連動させて、日記の全文検索もできるらしいが、Namazuをインストールしていないので、とりあえずその機能は使えない(あれって、管理者権限なくてもインストールできるのかな？よく調べてないけど)。あと、mailで日記を更新したりもできるらしいが、日記更新用にmailアカウントを作らなければいけないので、これも使えない。特定の日記ディレクトリにファイル置くだけだから、別にmail使わない形でフォームから書き込むようにもできそうだなあ。まあそのへんはおいおい考えよう。
ええと、昨日の日記でHTMLエディタの話をしているけど、実はあれ書いたのはもう少し前で、HNSほど機能満載ではないが、似たような発想の日記CGI(サーバーに置かれたHTMLをカレンダーから自動的にリンクして表示するタイプ)を試してみた時に書いた物なのだ。そのプログラムは文字修飾や見出しの自動生成まではやらず、そういうことがやりたければ、HTMLタグを直接使うという方法だったため、ああいう事になっていた。このプログラムに乗り換える際、HTMLタグを削除して、hnsのコマンドに書き換えたのだ。
さて、今的にMac界の話題はOS X のGUI、Aquaだと思うがどうだろうか。少々やり過ぎの感もあるピカピカデザインは、あれはあれで結構楽しそう。基本的にウチあたりの旧機種はサポート外の筈だが、無理矢理インストールすれば動くかも。どうかな。しかし、現状ハードディスクが全然足らない。どうしよう。(安いんだから買えって)
アニメ・コミック | ウェブログ・ココログ関連 | グルメ・クッキング | ゲーム | パソコン・インターネット | ファッション・アクセサリ | 同人・コミケ | 携帯・デジカメ | 旅行・地域 | 日記・コラム・つぶやき | 映画・テレビ | 趣味 | 音楽
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 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 |
Recent Comments