[TOP][電波…とどいた? TOP]

電波…とどいた? 199810上旬/中旬/下旬

[←前のページ]
[次のページ→]

1998年10月21日の電波状況

今日は何の日?

ふふにや。たまにはいいよね…

(22:30)新型あかりちゃんに差し換えてみたり。……むぅ、謎だ。謎すぎる。なんか浩之に後ろからスリッパでぱこーんとかされそうだ。

j.v.l に投稿したダメ劇場をここにも記録(^^;

あ: ねえねえ、浩之ちゃん。
ひ: ん、なんだ、あかり。
あ: えへへ、今日は何の日だか知ってる?
ひ: 今日? ...駅前のスーパーが特売でもしてるのか?
あ: ちがうよ〜。あのね、今日はね、「あかりの日」なんだ。
ひ: (ぽん)ああ、そういやそんな日もあったなぁ
あ: そう。私のことを世界中の人が記念してくれてるんだね♪ あ、国民の祝日にはならないのかなぁ

ぺしっ!

あ: きゃっ! ううっ。浩之ちゃん、ひどいよぉ。
ひ: バーカ。なに寝惚けたこといってんだよ。今日はエジソンが白熱電球を発明した日だろーが。
あ: あ、浩之ちゃん知ってたんだ。
ひ: まあな。一応これでも自称「神岸あかり研究家」だからな(やや赤面)。
あかりに関することならなんだってどんとこいだ。
あ: なんでもわかるの?
ひ: まあ、たいていのことはオレに聞けば OK だ。
あ: ……それじゃあ、質問してもいい?
ひ: お、おう。
あ: えっと、神岸さんちのあかりちゃんがずーっと前から大好きな人の名前教えてほしいな♪
ひ: う゛……そ、それは
あ: (わくわく)
ひ: ほら、わかるだろ、だから、
あ: (にこにこ)
ひ: えーい、フ・ジ・タ・ヒ・ロ・ユ・キ 、そう、オレのことだ(完全に赤面)
あ: ふふふぅ。正解〜♪ (ぎゅ)

ダメダメっすねヽ(´ー`)ノ

無題

RFC2468を読む。合掌。

SORAMIMI

ふふふ、雅史ソング(大汗)。「だれかの涙とひきかえにした記憶がおもすぎて…」ダレカッテあかりナノダロウカ…いやぁぁぁぁ。

wcahr_t

塩崎さんがいそがしいそうなのでメールできたのを勝手に転載。

ふみ? EUC は始めから iso-2022 ですよね。実装ですか? itojunさんの 拡張 rune lib も XMulti wchar_t もどちらも EUC は One of iso-2022 ですよ。
最初、あの箇条書きを書いたときは、iso-2022 の方に括弧書きで入ってました。
# だって、初期状態があらかじめ決められてる ISO-2022 ですからね>EUC

なぜ別にしたか、というと、たとえば、itojun さんの ISO-2022 rune のエンコーディング規則に沿わせるためには、最上位ビットを落したりとか、ロケールに合わせて付加情報を付けたりとかしなきゃいけないけど、 wchar_t ってロケールに即したエンコーディングだけで十分なのだから、そこまでせず、EUC 生で扱えば十分、という考え方もあると思うのです。一方で、ISO-2022 へ統一すると、あそこで書いたようなメリットが生ずるわけです。どっちがいいんだろ…

# 意欲的な実装、という点では後者ですが。

@ EUCのエンジンを専用でつくるつもりなのかなーともおもいつつ問い返してみたのでした。個人的には統一化が好みです。そうむずかしくないし。

Shift_JIS は GB と同様完全に独自なエンコーディングですから、独自の処理エンジンが必要ですね。あと、このエンコーディングは jisx0208 からはみでちゃう部分をもってますから (95区〜120区。 115〜120区にはIBM外字がはいってることが多い) iso-2022 の枠組みに安易につっこむのはアレかもしれず。

う、知らんかった…。これは別にしないと駄目ですね。

> 参考資料: OSF での推奨規定。

しかし、MS/IBM はつくづく困った人たちだ。
# 時代背景を考えると、そうとは言えないのかな…

そうそう、あと fj のどっか (どこか失念。あとで気がむいたらさがしまふ)で見た話。エンコードとしての Shift_JIS と Windows-31J

SJIS 系は明確に分離ですね。

@ はい。各種 SJIS 体系を網羅できたら良いかなぁと思います。すくなくとも iconv には、単純なよく行われている SJIS から他のエンコーディングへの置換のみではなく、外字までも含めた対応の指定が欲しいです。

MS-UNICODE 問題はこれまた既にOSFの案があるんで、それにしたがって、テーブルを複数準備するなり、ラッパかけるなりで良いのではないでしょうか。ちなみに3方式あって、それぞれ iconv にあたえる名称で区別できますです。

わたしは modifier 使おうと思ってたんですけど、規格の不備に泣かされるとわ (T_T)。
# あれは LANG 書き忘れただけでしょ、きっと。
# あるいは、互換性の問題なのかなぁ

でも、XPG5 で変わってる可能性が無きにしもあらず、なので、調べる必要はありますね。
# Alias を用意する、という手が良いような気がしないでもない。

wchar_t は iso-2022 系のものなら iso-2022 系と対応がとりやすいもの、 unicode 系なら unicode と対応がとりやすいコード、ということで問題ないでしょう。

はい。本当にいろんなエンコーディングが混在しているようなダーティなマルチスクリプトを扱うのでなければ、wchar_t は生のエンコーディングを直接反映させた形がベストだと思いますです。

※「ダーティな〜」というのは、わたしが最初提案した、ああいう すべてのロケールを統合するような無茶なマルチスクリプト、 という意味で、決して ISO-2022 でのマルチスクリプトを wchar_t で 扱うべきでない、という意味ではありません。ISO-2022 に対しては、 たとえば itojun さんのような内部フォーマットで格納するのが ベストなのでしょう。

@ iso系のエンジンとその wchar_t、 unicode系のエンジンとその wchar_t、他独自系のエンジンとその wchar_t に加えて、その「ダーティな」ものもあっても良い、というか、私はそれはそれで欲しいです、ということで、私はつくるでしょうね。そういう独自な体系を、ユーザが独自に追加するための枠組みとしての機構そのものが必要なのです。現行の glibc のように差し換えが効かない構造はこまるのです。

その追加のための API (でなくても、追加のためのコマンド体系でも良いとは思いますが)を ISO-C からはずれた枠組みでつくってしまうことは全く問題ないと思います。

特に現在の rune lib にこだわる必要は無いと思います。

これは、単に後方互換性維持のためだけに用意する必要はあるでしょう。

@ うーん、これに関する後方互換性って必要な場面あるのかしらん.. rune_t を直接さわっているようなものって存在しますか? ……って、あ゛そうか、FreeBSD の ctype 関連がこれで実装されてるから、関数呼び出しでなく、マクロ経由で直接 rune 関連よびだしてたらはまるかもしれず。

[略] modifier についての規格

ですって(T_T)。でも、だからといって modifier 使っちゃいけない理由にはならないような。結局、

LANG=ja
LC_CHARSET=ja.UCS2@MSKK
LC_TIME=ja_JP@Gengou

という仕様にするのは自由、という気はする。
# でも互換性を維持するために、やっぱ Alias は必要だな…

P.S. Locale Value をちゃんとパーズするような実装にすべきですね。いまの FreeBSD ロケールって、単純に対応する名前のディレクトリみてるだけだし。

@ X のように Locale 名称のデータベースをひいて、少々の誤差は吸収するようなものが欲しいかもしれません。

実装のたたきだいになる、もすこしまとまった試案がほしいですね。 FreeBSD-tech での ML 設立の話はどこにいっちゃったのかな... って試案をつくってからでいいか。


1998年10月22日の電波状況

シフトJIS

10/20 の シフトJISエンコーディングに関する話。 fj.net.www.authoring に村田さんが投稿された、 <702lcu$6kk$1@tpost1.netspace.or.jp> の記事でした。

現在、IANAでShift_JISとWindows-31Jの明確化提案をしているところです。今の案が通れば、Shift_JISはJIS X 0208の付属書通り、Windows-31Jは JIS X 0201 + JIS X 0208 + NEC/IBM拡張になります。そうなれば、 XMLパーサではencoding="shift_JIS"と書いてあって、丸付き数字が現れたら致命的エラーを報告してくたばるのが正しい実装ということになります。

情報ありがとうございます>内田さん

ぐる

昨日の「あかりの日」記念絵。それなりに うけた模様(^^;

@ ダメ劇場、最近は 『To Heart』 については、「あかりと浩之」がセットなのがしっくりくる気がしてるので、自分にはしませんでした(^^; 『痕』の場合も同様。あ、対R子さんなら「ごうちゃん」で通します。はい。しかし、私が書くとみんなお笑い系のキャラになるような気がするのは気のせいなのだろーか。

@ そうですね〜、DPS は表示から印刷までがシームレスなのは良いですよね。 X Window System の通常の機構では、表示と印刷を一致させる機能を提供していないので、結局印刷関連のソフトは表示と印刷の制御を全部自前でもつことになるってのはやっぱしくしくです。特にフォントの扱いが問題。Tgif のフォント問題は顕著ですね。 X11R6.3 からの Xprt サーバが一応このあたりを考えたもので、 XPRINT Extention というのが存在するのですが、使ったことが無いので詳しいことはわかりません(^^;

GNOME に関連したところでは GYVE が gtkDPS つかってて、X Window System + DPS 前提でくまれているみたいですね。

@ はやりもの。2.08。 Hos さんと同じか...。設問6 は両方それなりにそれなり(謎)なのでどうすべかと思ったのですが、一応 2のほうにしてみた結果。3その他にすると 2.16 なのでした。

Visual Novel

@ クリックの話。『雫』の「瑠璃子、るりこ、ルリコ」のシーンは、当初は一語一語クリックを必要として、かちかちかちかち連打させますが、最後の部分はクリックなしで連続でざーっと表示されて画面全部をうめつくしてしまう、というようになっていたと記憶しています。 (むぅ、CD-ROM ドライブを家においてきたから確認できないぞっと) これはクリック効果による演出のうまい例といえるのではないでしょうか。あと LVNS は文字の表示速度そのものが細かく調整かかってますよね。文字表現を利用した演出としてあと追加できそうなものとしてはフォント(family/size/style/weight)の変更ぐらいでしょうか。あれ? 絵文字表現は LVNS つかってたかな? 汗マークはあったような気がする。

@ ログについて。選択肢の時に、これどうだっけ? と思い出すのに参照することが多いと思います。まあたいていの場合は覚えているので特に参照することはないのですが... 個人的には、Novel タイプのゲームは、ゲーム完了後に、その一連の流れを選択肢もすっきりととりこんだ形で通してよませてくれるようなモードがあると嬉しいなと思ったりします。画像の「アルバム」があるんだから、それの文書版があってもええやん、といったところでしょうか。ついでに全画面ビジュアルとかは挿絵として挿入されてて、章とかのサブタイトルもついて目次がついたりするともっとなお良し。ゲーム中の Visual Novel としての演出はなくなって普通の小説になってしまうわけですが、あとから反芻するときにはそれのが良いかなと思うのです。


1998年10月23日の電波状況

予定

秋から冬にかけての予定とか。

10/31(土)〜11/1(日)
Leaf IRC 豊橋オフミ 鍋大会 at ひふみ荘
11/26(木)〜28(土)
第4回 ITRC 総会・研究会 at 別府温泉
あう、申し込み〆切が今日だ。書かないとね
12/5(土)
谷山浩子コンサート「幻想図書館」 at 新宿スペースゼロ
一年に一回ぐらいはコンサート♪。Hos さんと行く予定。
12/15(火)〜12/18(金)
Internet Week '98 at 国立京都国際会館
Linux Conference (12/18)にて X-TT 関連の発表。あと FreeBSD BOF。 学生は席空いてたらチュートリアルは無料で参加できるらしいので 全日程行くかも。
12/29(火)〜30(水)
コミックマーケット55 at 東京国際展示場
物はつくるけど、私自身は行かないかも。

うーむ、12月はぎっちりだなぁ

ぐる

お、痕してるですね:D 楓ちゃんいいですよね〜。ふきふきだし(爆)。柳川シナリオは、私は楓ちゃんシナリオの裏ストーリと位置付けてます。事件の総まとめになるシナリオですね。痕のシナリオ構成の妙が一番良くでてる部分かと思います。

@ IW98 参加ですか。どこぞでお会いできるかもですね :D


1998年10月25日の電波状況

昨日

寝たのは 6:00 ごろ。起きたのも 6:00 ごろ... 一瞬何がおきているのかわからなかった秘密※ぼけて「今日」ってかいててので修正

ぐる

xwd は TrueColor では(だったか 16bpp でだったか)ではうまくうごかない ですね。xv を使っているのなら、xv の grab で切り出しするのがナイスかと。あと gimp も切り出し機能もってます。

@ お、 無事『痕』マスターになられたようですね〜(^^)。痕の世界はやっぱその広がりが魅力です。一応それで話は終わっているのですが、初音ちゃんハッピー(?)エンドとか、柳川シナリオとか、「その後」がすごく気になってしまう部分がけっこうあって、それを想像させるだけの材料、世界観、キャラクターみんないきいきしてるので、いろいろと同人誌とか二次創作とかができてるんだと思います。そもそもおまけシナリオ部分自体二次創作と言えますよね。キノコものというか、数ある『痕』お料理ネタの根元です(笑)。あ、そうそう。『さおりんといっしょ』に短いおまけシナリオがありますよ〜。あとこの調子で『雫』の世界もご堪能下さいませ。こちらのがぐさぐさ度は高いでしょう。某シナリオとか(大汗)。

@ めったに会わない年の近い異性の従姉妹っすか... そのまま『痕』っすねヽ(´ー`)ノ。塩崎さんも遊ぶしか!!!

@ MB_CUR_MAX はそれなりにでかくとっておくっつーのが常套手段な予感。

@ ふふふ、あかりの日トラップにはまった人がここにも一人...

@ Leaf のシステム。(リンク先がまだないみたい...) WA はまあ横においておくとして、To Heart については、 Visual Novel のシステムがキャラクター主軸のゲームの表現にけっこうナイスに使えるというのを示してるのではないかと思います。小説と漫画や映画などの中間点というか、挿絵が全ページにあって、表情変化がわかる小説というか。小説は文字を連ねることで、心情の細かい変化などを表現しているわけですが、 Visual Novel が示した画像による表情の微妙な変化などの表現は、それに対するイメージ喚起の補助として非常に有効だなあと思うわけです。 Leaf じゃないけど、ONE の澪の立ち絵の枚数。あれはすごかったと思います。

@ 全画面でのイメージや動画などをはさみこむことも表現の幅をひろげますね。そうそう、音楽の効果は絶対わすれてはいけません。LVNS がすごいのは、あの音楽と効果音による部分も相当あると思います。痕のように、分岐によるからみあったシナリオ構造、といった部分が特に存在しなくて、単にストーリーをただ読むだけであっても、こういう部分的な 『Visual 化』による効果は確かにあると思うのでした。

@ ストーリー分岐の要素は文字による表現を全部アニメーションに置換してもまあ通用するのですが、個人的にはあくまで文字主体がいいですね〜。秀逸な文書による表現(+ちょっとした画像 + BGM + SE)ってのが、私にはほかのどんなメディアよりも想像力を喚起してくれて物語への没入度やらキャラへの萌え度が高くなってる気がします:D

@ 浩之の話。 j.v.l でも書いたのですが、やっぱ私の「あかり萌え」ってのは、浩之とセットになってこそのあかりなんだよなぁと思う今日このごろなのでした。他でも、To Heart の SS とかで、作品の質としては高いと思っても、「なんかこの浩之、浩之じゃない。」ということであまり評価高くないものがあったりしますです。なんか「弱い」のね>そういう浩之

@ 3X 翻訳完了おつかれさまです。ちまちまですけど査読しますね〜♪次はとりあえずパッケージ化ですな。

らくがき

この数日の逃避落描きをあげておきませう。

あさ

とりあえずたまった洗濯物。で、ポポロクロイスをみてみる。けっこういいかも。ガサラキは前回見逃してるのでとりあえず録画。だれか見せて>前回のぶん

ぐる

悪いのは xwd ではありませんでした。 xwd は単に取得した XImage の内容を素直に保存かけるだけで、きちんと保存かかってます。 xwud で表示させるときちんとでます。xv が変です。どこかフォーマットがきめうちになっているのではないかと想像。 (xwd は非常にフォーマットのバリエーションが豊富(エンディアン(byte/bit)、アラインメント、マスク、depth、その他もろもろ)で、ヘッダにそのこまかい情報がはいっているのです)

あ、 私も『痕』のが上と思ってますです(^^)。 Visual Novel の表現の魅力ってのはまあシナリオ構成以外にもあるよんってことが示したかっただけなのでした。

完成度については同感です。結局のところ、システムの可能性はあくまで可能性であって、それをうまく生かしたシナリオと、そしてそれを際立てる演出があってこその作品ですよね。

マルチは肩にのせないと、ってのは昨日塩崎さんにもいわれました(^^; それらしく描くのめんどくさかったもので… ←いいわけ。ぷにぷにって感じはけっこうでてるかと思います :D 一人欲しい(笑)。あかりちゃん、おさげバージョンも気がむいたら描くかも。

さて、ちと買い物にでもいってこよう。

さんざいさんざい♪

今日3回目の学校でし。ということで散財一覧。

JIS ハンドブックの 「言語」のやつ(13000yen) と「コード」のやつ(8500yen だったかな) を買っとこうかとも一瞬思ったけど、いらない部分が多いのと高いのでやっぱヤメ。

しかし FreeBSD/Linux の本って確実に増えてますねぇ。あと X Window System の環境設定関連の本も2冊ほど発見。一冊はなんかこないだ塩崎さんもいってた X-TT にもふれられてるやつ(書名失念) ぱらぱらと見てみただけ。特に内容はよくみなかったので評価せず。

他の散財物の感想とかはまた明日にでも。

今日は...

なんか今日(10/25)の誕生花は「楓」で、花言葉は「遠慮」らしい。くぅ〜。……ところで、楓の花ってどんなんだっけ(^^;;;


1998年10月27日の電波状況

昨日

あやや、日記書いてないやん。

@ とりあえず一昨日の査収物について。 ONE小説版。基本的にゲームの流れ、内容ほんとそのまんまですね。脳内画像あんどBGM(+音声(笑))つきモードで読んだので泣いてしまったのは秘密だ(^^; ゲームではなかった「えいえんのせかい」での出来事が書かれています。個人的には○。ということで、あまり芸はないのですが、ゲーム世界の復習用 + αとしてはナイスかと思います。

@ 続いて原画集。表紙は長森と、まえ小さい写真みたときは七瀬かと思ったけど郁美なのね。長森おそわれてるみたい(笑)。 MOON. はまだ結局あそんでないのでさくっととばして、ONE の部分をざっと眺めたり。まあこんなもんでしょう。巻末の顔と体のパーツ群はけっこうおもしろいかも。インタービューは例の引き抜き後におこなったのね。プロデューサさんも大変っすな。さてさて、次作はどうなるか。プロデューサの手腕がいかほどのものか楽しみです。

「いちょう〜」はまださわりしか遊んでないので感想保留。音楽はたしかにけっこういいかんじ。ちとインパクトにはかけるかも。日常の繰り返しはたしかにちと退屈風味な予感。

ぐる

1990 っすか。substitute の部分は primary が無いときにつかうやつのはずなので、そのままで良いはずなのですが.... あ、fs2 あたりに substitute が無い部分があったりしません? 確かそいつのパーサにびみょーにバグがあったような記憶が。そのあたりと関連してとちくるってたのかもしれませぬ。ちなみに 1990年版の jiskan16 は 安岡さんが作って配布してるっす。 78,83,90 とそろってるのでこだわりの人は全部いれておくのもナイスかも。 k14用差分は高田さんがつくってますね それぞれG0領域へのデジグネータは 1978:[ESC $ @], 1983:[ESC $ B], 1990:[ESC & @ ESC $ B] だったりするのですが、1990 は 1983 に二文字追加なだけなので (このための エスケープシーケンスが ESC & @)、実用上は 1983 と同一視されてます。iso-2022-jp では ESC & @ はつけないことになってます。なお、コンパウンドテキストに登録かかってるのは jisx0208:1983 です。←ミスしてたので修正

作業

もじらを 4.07 にしてみたり。ん? ちょっと重くなった? 気のせいかな。

らくがき

昨日のらくがき。

こーいう瑠璃子さん描くのはたぶん私ぐらいだろう。はっはっは。あかりちゃん、なんか、ろり度高いかも。

がさらき

神野君が録ってあったので借りることができた。さんくす。でもっておとといの録りそこねたそうなので、もちつ持たれつ♪

ふと思って「能」の話をしてみたところ、さすがは神野君。知ってました。で、そのNHKの道成寺のやつの回の録画があるかもしれないので探してみてくれるそうだ。らっきー。見つかるといいな。

X-Jdoc Project

X Japanese Documentation Project、藤原さんの精力的な翻訳作業によって、X3 セクションの仮翻訳が完了したので、暫定アルファ版を公開してあります。翻訳に対するつっこみとか歓迎。


1998年10月28日の電波状況

そらりす・せぶん

Solaris 7 という名前になったらしい。 64bit 環境への対応とか、システムたちあげたままでの部品交換とか。ちゃんとUNIX98 になってますね Unicode ベースの locale もサポートした模様。この文脈からして、Unicode フォントも持っている予感。ということは日本語きちんとでますな。ちゃんとした UNIX ですから、localedef(1)があるので、 EUC-JP つかいたければ自分で定義できるはずだから問題無し。

フリー版 もちゃんと Solaris 7 になってますね♪。もうすぐ(カードができしだい) 発注するつもりだったので丁度よい〜♪ みんなも買う(送料 + メディア代)しか!!

にゅ、docs.sun.com、言語が ja だとバケラッタ…。しかたないので en を一時的に優先に。編集/設定/Navigator/言語から設定できるのでし。

らくがき

TF さんにお誕生日絵をおくったり。いいんちょっす。けっこう可愛くしあがった予感。やっぱろり傾向だけど(^^;

でもって落書き。

脚がむずかしかったっす。うみゅ、首の位置と左右の肩が変だにゃ(汗)。落書きだから直さないヽ(´ー`)ノ

ぐる

件のページの言語の切り替えはクッキーでなくて、 HTTP1.1 の Accept-Language による自動切り替えです。ちなみに、 イソターネットの I19N 部会のページ でも同様の処理が行われてたりします。 apache の場合、AddLanguageでこれを処理できるのでした。 IE だと表示/インターネット/オプションから言語の優先順を指定できますね。

ふふふ、 『雫』をはじめられたですね :D。くすくすくす。才能あるかな? はさみ〜(T_T)。ええわたしゃこれを二回目に見た(初回は仰げばとおとし)のですが、もうぐさぐさ度では雫中最大かもしれずです。そのあとショックでしばし呆然としたものです。さおり〜ん(T_T)。む、瑠璃子さん怒らせましたね(謎)。 (『雫』と『痕』は全シナリオの基本的な流れとポイントを覚えてるのでした(^^;)

『雫』は『痕』と異なり、シナリオの順序制御が一つの例外(とおまけシナリオ)を除いて存在しないので、初回から(トゥルーエンドを含む)全員のエンディングにたどりつくことができます。個人的には 沙織→瑞穂→瑠璃子 のシナリオの順に順次進めることをおすすめしておきます。この順に核心へのふれかたが深くなるので、理解度と感動が高いかと思います。

GOME、私もいれようかと思いつつも結局まだいれてません(^^; 日本の GNOME ML (最近できた)にははいってて、国際化関連技術についてコメントつけてたりします(^^; gtk そのものはまだつっこんだ部分はみていません。

Gtk は Font と FontSet を両方同様にあつかえるように既になっており、普通にとある locale でのマルチバイト文字が描画可能なのが強みです。TextWidget がまだ本家のほうでは対応しきれてないのですが、パッチが存在し、統合してもらうべく動いている模様です。私としてはやはり KDE よりもこちらのほうを押しますね。 Mozilla の新しい roadmap がでていますが、X のインターフェースは Motif から Gtk ベースに移行することになったみたいです。


1998年10月29日の電波状況

戦利品

ボスの手伝いをして謎の戦利品をもらう。ふふふ。しかしもらったのはいいが当分使い道がないらしー

ぐる

NULL 嫌い... if (!(fp = fopen("hoge", "r"))) とか書くのかなと想像。私の場合 NULL 使う場合と使わない場合がけっこうまざってる気がする。使うときは素直に後ろに来ます。…とか書いてたら違ってた模様(^^;

私はずっと gcc つかってまして、開発中は -Wall を常時つけているので if (a = NULL) は warning でるから気づくから問題になったことないです。 warning 出なくするには if ((a = NULL)) と書けば良いですからね。でもって最終チェックするときは HP-UX とか OSF とかにもっていって、それにはいってる cc でコンパイルします。gcc -ansi よりチェックきびしいっす(^^;

インデントスタイルは最初からほぼ BSD のスタイルですね。 1年ぐらい前から関数定義の返り値の後ろに改行いれるようになったので、ほとんど同じになってるのはず。インデント量が 4 ってのが標準と違うぐらいですね。あ、あと関数定義は ANSI のプロトタイプ宣言をちゃんと使います。このスタイルの利点は、BSD のソースはみんなこれだということ。あと X もほぼ同じですね。違和感なく読めるのです。全然スタイルが違う人のソースを読むときは、さくっと indent(1) 通して自分のスタイルにしてから読んだりします。

スタイルのアンケート、空白のいれ方なのですが、私は () の内側には空白をいれませんが、演算子の両端にはいれます。だからそこの例のどれもあてはまりません(^^; あ、沖さんと同じですね。あと、関数の定義、上にもちょろいと書きましたが、返り値の部分で改行いれてます。

C(93)...ちぇっくちぇっく..えっと、ISO/IEC 9899:1990 Amendment 1:1995 ですね。93 ってのはミスかと思います。 ISO/IEC 9899:1990 は、いわゆる ISO-C です。日本では JIS X 3010-1993 「プログラミング言語 C」がこれに相当します(これと年号混同してる予感)。 ISO-C には 1995 年に Amendment として、Wide Character 操作関数と、restartable な mb <-> wc 相互変換関数群 (Multibyte Support Extetion) が多数追加になっているのです。そして JIS-C にもこれにあわせて追捕 (JIS X 3010:1996 プログラミング言語C (追補1))がでています。

規格の構造ですが、 ISO-C (追補除く)に加えて LC_MESSAGES などの追加 (POSIX.1) と localedef などの周辺コマンドの規定(POSIX.2) をしたのが POSIX、 ISO-C と POSIX を加えてさらにメッセージカタログ(catopen)の機能や ISO-C 追捕のワイド文字関連部分を追加、さらに独自拡張を施してあるのが XPG4、それにさらに ISO-C 追補の残りの部分も追加したものが XPG5 です。なお、UNIX98 では XPG5 のサポートが必須です。 API および関連コマンドの仕様が知りたければ、上記 UNIX98 のページから Single Unix Specification Version 2 の HTML 版をダウンロードできます。

日本語で ISO-C の全 API について細かく仕様を解説したものは私は規格書 (JIS X 3010) 以外知りません。JIS ハンドブックの「プログラミング言語」を入手すると、POSIX.1 (JIS X 3030-1994) とかと一緒にはいってます。 (そこだけうってくれるといいのに...)


1998年10月30日の電波状況

昨日

やっぱ 改造版 rune による locale ライブラリにしてから、アプリが segmentation fault でおちる(- -#) 特に X の国際化アプリ。gimp も。つーことで原因追求モードに遷移。-g つけてコンパイルした Xlib を追跡する。……謎の場所でおちる。しかもこのデータって前回の参照時には正しい値がはいってるぞっと。どっか別の場所からデータ破壊がおこってるんだな、というわけで追跡続行のため gtk も -g つけて再コンパイルして問題発生直前から徹底にトレース.... setlocale 読んで帰ってきた時点でこわれてるやん... つーことでさらにその内部もトレース... locale 用のデータ領域の格納サイズ計算ミス。ふう予想以上に時間かかったっすヽ(´ー`)ノ。とりあえずバグレポート書いてメール。

で、gimp が落ちなくなったので、ついでに gtk と gimp をバージョンアップ。gimp は Text Tool の日本語化も行う。うむ、ばっちり kinput2 で入力できるようになったぞっと。 Input Method に渡す文字のサイズ情報は毎回変更してくれるほうが良いなぁ。気がむいたらハックしてみることにしよう。もしくは要望だしですな。

iso-2022-jp な locale、まあ、正しく動いてるんだけど、なんか X側が変なのでし。はて? 前実験したときはうまく言ったと思ったのだが...まあチェックはまた今度にしよう

ふう

授業料納めにいったりする。

本吉君がぴあきゃろの ToyBox を買ってきた。Go!Go! 木下祐介を遊ぶのを後ろから眺めたりする。どうやら失敗したらしい(^^; さらに Dora キャロットしてたら途中でハングって、結局そのあと内部のぞきもーどに。ファイルは全部展開状態の模様。ディスクくいますなしかし文書もなにもかも全部一枚絵なのかぁ。まあそうしておくほうが簡単ではありますな。そのまま全画像みてたり(^^;; やっぱオリジナルスタッフの描きおろしがナイスな模様。右2かわいい.

そのあと本吉君は共用マシンの壁紙を蛙をもったかおるちゃん(謎)にしてから去っていった。はたしてこのトラップにかかる人はいるのか!?

いったん家に物をおきにいって、ついでにカレカノみて、家賃大家さんちにもっていって、それから学校にまた来たら途中どしゃぶりでぬれねずみ。しくしく。カレカノ、頭みそこねる。結局主題歌はあったのだろーか。内容はなんとなくいまいちな気がした。

さて

明日は来客あるっつーことで、早めに帰って掃除とかでもしようかにゃ

[←前のページ]
[次のページ→]