昨日書いたんだけどあげるのわすれてたにょ。
XDMCP の件、 細かいことは塩崎さんが解説されてますのでパスして… xdm 立ち上げのとこをもすこし端的に。クライアント側が Vine Linux なマシンということですが、XFree86 のデフォルトの設定のままなら、 xdm は立ち上げるだけで外部からの XDMCP 接続をうけつけます。ということで、rc.d のどこかに xdm を立ち上げる設定が存在すると思いますので、それをたちあげさせて、クライアント側からは単純に XDMCP 接続にして接続先を指定すれば良いでしょう。もし無ければ、起動後 root で /usr/X11R6/bin/xdm を起動すればそれだけで OK (場所はちょと違うかも)。ただし、xdm はデフォルトでは、遠隔のみならず、コンソールの X サーバも制御対象にして、勝手に立ち上げてしまいます。「俺は startx じゃなきゃいやなんだー」ということでしたら、/usr/X11R6/lib/X11/xdm/Xservers の中に xdm がデフォルトで自動起動させる Xserver 一覧がありますので、:0 ではじまる行をコメントアウトすれば良いでしょう。
余談。XDMCP を使うと簡単に X端末化ができます。 HostA で xdm が立ち上がっているとします。HostB はコンソール起動で X は startx で立ち上げるような状態だとします。このとき、HostB で次のような操作をすると…
HostB% X -query HostA -once
HostA に xdm 経由で直接 login できます。なお、-once をつけないと、logout したあとも連続で接続がかかります。
HostB% X -indirect HostA -once
と、indirect 指定を行うと、HostA が chooser という接続先選択クライアントをたちあげてくれるので、LAN 上にある任意の xdm に接続できるようになります。
さらに余談ですが、Solaris の xdm 接続したときの login クライアントは賢くて、(HP-UX とかもだけど)、ここで locale と OpenWindow/CDE環境、を選択してからログインできるようになっていて、さらに別の Host への接続切り替えも自力で可能です。
@ とりあえず封印ということですが、また機会がありましたら全体をぜひプレイしていただきたいです。はい。あ、最後のおまけは楽しいです :)
@ 私も人にすすめるときはとりあえず痕が先ですね(^^;。ちなみに私は TH→雫→痕です。雫と痕はあの Leaf 初出展のコミケの帰りに買ったはずだから、TH が出た年の 8月だったと思う。私はトゥルーで感動しつつも、ちょっとさみしかったのを Happy でむちゃくちゃよろこんだ人です(^^)。おまけはおもしろいですね。あのシュールなところがナイスです。でも 雫の価値では無いと思うよ(^^;;。ちなみにさおりん BAD、たぶん Happy 方面からの単純な想像より (精神的に)酷い演出をすこーんとかましてくれます(汗)。必見(ぉぃ)
@ みゅ、 ONE Diary はおもいっきり未完なんで封印中でし(汗)。東鳩日記もなんだけど…。とりあえず画像は復活させておきました。
@ つーわけで、瑠璃子さんは、私のことをしっかり理解したうえで「ダメ」っていってますから、全くもって問題ないです(ぉ。なんせ電波でも交わりあった仲ですから。
@ あ、そうそう、「悔しい」というのとは違います(-_-)。いちおーほこりをもって(ほこりだらけになってかもしれんが)ダメ人間になっているつもりですから。ちょっと気持悪いだけです。もっとも、こっちから心理的な壁を作っているだけのような気もする。それを乗り越えてくるか(おお、まい、えたーなるふれんど)、全然来ないか(これはこれで良し)、ちらちらのぞいているだけか、 (これがちょいイヤ。どうせならどーんといきませう。どーんと。どこまで落ちていくかは才能によります(笑))で、オレ内部対人間関係ランクづけしちゃってることは否みません。
@ だいじょうぶです、 はちさんが言われた場合は、200% 誉め言葉だと認識しておりますので。とりあえず、従来は単純に「同志」的認識だったのですが、「成長する可能性があるからダメ」とのお言葉を拝聴して以来、尊敬の対象にさせていただいております(ぉぃ
@ たぶんそうなんではないですかね。そちらにもたぶん話は飛んでいるかと思いますので。 A は本だしてますよね。あのあたりからみで話がうごいてます。
@ lex は lexical analyzer でしか無いですからちょっと これだけでなんでも処理してしまおうというのは酷ですね(^^; ちなみに私はこの 日記処理の最終フィルタ としてつかってたりします。主に改行の削除が目的。 (m4 つかってると大量に改行が残るので…) 他にもいろいろ謎なことしてます。ちなみに XMulti も lex と yacc のお世話になってるところが多かったり。
@ もじら、がんばってるんですなぁ。私はおいかけている時間も体力もありまへん。それはサテオキ、gtk が国際化されているのはだいぶ以前からの話ですが、これはあくまで UI であって、Motif と同じで、メニューなどに日本語(localeでサポートされた言語)がつかえる、といったレベルでのお話です。 Web Browser 本体の表示部分を真面目につくるなら、M17N の技法が必要になりかなり高度なものを自前で組む必要があります。もじらくんのそのあたりの対応がどの程度進んでいるのかは知りませんが、とりあえずできてないみたいですね。
@ 某BのためのMLが動作開始。こないだの会議の様子は今日にはまとめて流してくれるそうな。
@ X JDOC Project のドキュメント群の CVS 移行完了。ああ、登録依頼がきてたにゃ。あとで処理しておかねば…。
@ 立ち絵がようやくコンプリート。気に入らないの部分も大量にあるが、直してる余裕はないのでしょうがあるまい(T_T)。一括して同一パレット指定で OPTPiX にてふにふに減色処理。ちなみに GIMP だと(減色の精度はおちますが)レイヤごとに絵をつっこんでいって、一括で index 化処理すると一応同様のことができます。
@ ファイル形式変換作業。ううっ、gimp って --no-interface --batch でバッチ処理できるはずなんだけど、制御方法知らないので全部手作業。さすがに 40 もあるとけっこう大変。
@ で、立ち絵は大丈夫だったのですが、一枚絵を保存すると Seg. Fault でおちる(汗)。むーーーー。プラグインのデバッグなんてどうするんだ? 結局必殺 fprintf アタックで場所を特定。どうも最後の瞬間になんかひっかかってるらしい。判定の順番がアルゴリズムとしてなんか変なんだろうと思ったが、なにも考えずに 作業領域の mallc してるサイズを 1増やしたらおちなくなって、あと画像もきちんと保存されていたので良しとする(ぉ。はにゃ? 画像が真っ黒(?_?)…この画像形式のこのローダは 256色だと 0 と誤認するのか(汗)。255色にすることにして頭から作業やりなおし(T_T)。
「ワタシノココロ」、ぱーむに入れたまではいのですが、そのあといろいろ忙しいこともあり、頭のほんのちょっとしか読んでなかったのでした。で、ふと、本日の作業も一段落ついたし、ちょっとだけ読もうとおもって読みだしてみる。…数分後、私は後悔するのであった。
しまった、ひきこまれて、読むの、とまらん(汗)
読了。現在 6:00 a.m.ちょい前。あああ、睡眠時間ががが…。いまさらながら、とりあえず一言。「みんな読め」。さわりごときで先入観もっちゃダメですね…。勧めてくださった sugich さんの審美眼に乾杯。
さすがにちょっと寝ます。…起きれるかしら…
あるるん生きてたのね。よかったよかった。
@ 「痕」の続編、は期待はしてますけど実際にはけっこうむずかしいかにゃ、とか思ってたり。某新聞記事では「ライフワーク」とかおっしゃってましたね。鬼の設定とかだけもってきて、4姉妹たちは出すとしても脇役に徹したりするのが良いのかも。
@ それはサテオキ、某 j.v.l からの情報をもとに、「巨乳家族 スペシャル」(みずきひとし:週間漫画サンデー増刊)ゲット(ぉ。書き下しで「巨乳サスペンス劇場 〜真夏の温泉湯けむり旅情〜 美人巨乳姉妹に忍び寄る黒い影」があるのですが、「つるぎ屋女将 千歳」とその姉妹2人がどーみても以下略(笑)。梓はなんか仲間はずれらしい(苦笑)。オレ的にはいろんな点でこずえちゃんが好みだ(謎)
@ iso-2022-jp のような JIS7 系のコード体系は 7bit なので、 (単純に「JIS」というと、実はかなり種類がある … 8bit な jis8 もあります) ASCII と完全に衝突してかなり不幸なことになります、CGI とかの内部コードでは使わないのが吉です。これはあくまで 7bitの経路が主流だった時代からの「通信用のコード」ですからね。 SJIS も 2byte 目が 0x40〜0x7e と 0x80〜0xFC で、一部 ASCII と重なるために、不都合がおこります。代表的なのが 0x5c の "\"。printf がらみでよくトラブルの原因になります。ということで、単純に処理をする場合には、CGI 内部では EUC-JP を使うのが一番無難です。追記: '\' のコードを 0x92 ってまちがえてかいてたっす。修正。92 で 0x5c です。はい。
「あかりの日記」ベータ版作成作業。Hos さんがくんだものを補正して、画像は再 Pack。苺内 + 外部αでの チェック用配付物。現在のサイズ、3.6M。けっこうなサイズだにゃ。当初 FD で配付とかいってたのはさっくり不可能になっている(苦笑)
某に某をいれるべく、とりあえず使ってないものをけずって、 1.4M を空ける。8M な人がうらやましい(謎)。ふにふにコンバートして転送。すげーーーーー。ちゃんと動いてるよ〜。合成かかってるよ〜。まだαってことなので詳細は書けない(^^;; 知りたい人は tech-ml に Go!
あう、けしちまってる。「某の某」は「痕 for PalmIII」ナノデス。
@ 昨日。某所で真鍋さんと某氏と某氏と密談。ふむ、X のメジャー化というかもっとクローズアップするというか…でも、どこかがそれなりに組織だったところが音頭とりしてくれないと、個人ベースのレベルではねぇ…。
@ かつてつくったパッチが使われる日がきてしまったらしい。というわけで、Leaf IRC 網 (実は 6サーバもあったりする)から夢鋳物なクライアントが遮断されましたとさ。motd参照。チャンネル数が激減したみたい。
@ みゅみゅ、 Linux Magazine (ASCII) の3号が積んであるにょ。たしか ASCII さんのほうからくれるっていってたような気がするので立ち読み(ぉ。ぱらぱら。ふむ、フリーソフトウェア100本ですか。なんか、FD とかがつきだしたころの DOS/Windows 系の雑誌みたいだね(苦笑)。ほー、いろいろあるもんですなぁ。カラー記事だからなんかかっこいいぞ(笑)。つーことで、XMascot と XMultiも紹介されてたりします。 XMascot、タイトルバーの消し方わからなったのかしらん。 vi の入門記事か。やっぱモードな概念よりコマンドな概念で教えるほうが分かりやすいと思うのココロ。
空き容量が洒落にならんっつーことで、結局 Flash PRO 導入承認(^^;。注文してダウンロード。やっぱカードは便利やね。これで 820k ほどが余分に使えることになるので問題なっしんぐ。 Flash Memory の管理が全部 Palm 上で行えて便利便利〜。さくさくとJOS III関連を Flash ROM に移動。あとで辞書もでかいのにさしかえておこう。ついでに標準 Large の代りに ナガ10 をいれる。さて、一時的に消えてもらったアプリケーション達も順次復旧。ついでにグレイスケールもとれる daSCRshot もいれてみて画像サンプルとってみて勝手に掲載。痕 for PalmIII 動作画面 その1 その2『痕』(c)Leaf 。うむ、ばっちりだにょ。
IP直接でメール出す場合は、[]でくくれば良いはずです。なお、nslookup ででてくるアドレスはメールの配送先と同じ場合もあるでしょうが、そうで無い場合もよくありますのでご注意。 nslookup -type=MX some.domain.org として出力されるアドレスが実際のそのドメインへのメールの配送先(MX)ということになります。
@ いろいろたぐってて見かけた(つーかどうたどったかわからんなった(汗)) 「 漢字コードの変換について」非常に良いことを書いておられる(コード変換がいろいろあるのは無駄ってところとか、あと、全体的にサイトの傾向とノリが好みだ(笑)) のですが、ミスがかなり目立つ(^^; のでせっかくだからいろいろコメントしてみるる。かなり長い上にうるさいかもしれませんが、この問題はこのぐらい難しいということで…。この手のプログラムをする人にとってはそれなりに知っておくべきことだったりします。API の整備がすすんでいれば知らなくても使えるはずなんですけどねぇ…
@ MB ←→ WC の変換、というか C 言語における wchar_t は、単純に「固定幅」での処理を行うためのものであって、コード Unify のためのものではありません。 WC は locale の数だけありえます。たまたまどの locale でも WC が同じになっている実装はありますが(Windows とか glibc とか)、一般的な商用 UNIX でそうなっているものはありません。 効率が悪いからです。ということで、MB と MB の相互変換に mbstowcs と wcstombs を利用することはできません。 locale を切り替えた時点で WC の定義もまた変わりうるのです。 locale がプログラム中でかちゃかちゃ切り替えることを想定していない、というのはその通りです。ちなみに、以前は私もできると誤解していました(^^; 仕様書をきちんとよむと、そう期待できないのがわかりますし、実際の実装もそうなのです。
@ iconv(3) が各種コード変換のための「標準 UNIX ライブラリ」です。 (XPG の関数の一つ)。これを持たない OS はOpenGroup 的な「UNIX」を名乗ることができません。固まった規格ですから、相当のことがないかぎり、名前が変わったり、仕様がかわったりすることは無いでしょう。 PC-UNIX での実装が不十分なことによる問題はおっしゃる通りです。なお、iconv の情報が得たい場合は、まともな 商用 UNIX で man iconv するか、 Single Unix Specification Version 2 を参照 されるとよろしいでしょう。
@ iconv でMB文字列のエンコード変換する場合に利用する識別子は、処理系依存ですが、locale の LC_CTYPE のエンコーディング部分から得る場合には標準関数としては nl_langinfo(3) があります。さらにエンコードのバリエーションに応じてモディファイヤをいろいろ指定可能ですが、日本語 locale については OSF のほうで 合意が存在します。「コード判定」については、Java のでは「自動判定」が存在しますね。同様の処理で一応可能でしょう。
@ 厳密に言うと、iso-2022-jp と EUC-JP と Shift_JIS は採用している文字集合がすこしづつ違います。たとえば iso-2022-jp は JIS X 0208:1978(旧 JIS) と JIS X 0208:1983(新 JIS) を両方利用できますが、 JIS X 0201 kana(いわゆる半角カナ)は使えません。EUC-JP は JIS X 0201 kana も JIS X 0212(補助漢字)も使えます。「外字」問題も考慮にいれるとさらにややこしいことになりますが、まあ、本質的にはおおむね同じとみてよいでしょう(苦笑) ちなみに上の OSF の定義では、外字もふくめて真面目に論じてありますので参照されるとよろしいでしょう。実際問題、ここまでサポートしないかぎり、「商用」では つかいものにならないのです。
@ ISO 2022 自体は非常に単純なすっきりとした原理です。規格書のページ数も少ないです。ちなみに JIS X 0202 が ISO 2022 と全く同じものです。 (国際規格 ISO の内容ははすみやかに JIS に反映されます) ISO 2022 はあらゆる種類のコードをカバーできるようにつくられているため、理論上登録されたあらゆる国の文字コードを表現できるため、全体として複雑なのです。JIS X 0208 は、そもそもはじめから ISO 2022 に適合するように設計されているのです。ちなみに JIS X 0201 も ISO 646 を日本用にしたものです。次期 JIS漢字コード である JIS X 0213(仮) も、 ISO 2022 にあてはめるようにつくる必要がありますから、コードとしては 「94x94 が2面」になり、エスケープシーケンス用には新たな終端文字がわりあてられることになります。
@ iso-2022-jp (RFC1468) は、ISO 2022 の機能のうち、junet で 日本語を扱うために必要な部分だけとってきてつくられたものです。「改行の時 ASCII に自動的に復帰する」という機能を追加しているのと「JIS X 0208:1983 と JIS X 0208:1990の違いを無視している」ため、正確には ISO 2022 には適合しません。
@ 「漢字イン」「漢字アウト」という言い方が誤用なのはその通りです。名称のでどころはもしかしたら、ISO 2022 での「呼び出し(invoke)」機能の一つである、「ロッキングシフト」にわりあてられたコード、「シフトアウト(SO/LS0)」「シフトイン(SI/LS1)」あたりかもしれません。ちなみに JIS X 0208 にでてくる「JIS7 encoding」では、この SO/SI で 「半角カナ」に相当するコードを呼び出します。エスケープシーケンスによる切り替えのことは正確には「指示(designate)」と言います。
@ ISO 2022 系のコード(7bit系)はあくまで「通信用」のものであって、エディタなどの処理につかうもんじゃありません。ASCII と完全にぶつかりますので、 SHIFT_JIS よりたちが悪いです。(ISO 8859 のような 1byte のものと、制限をもうけて処理を簡略化した EUC はのぞく) 私、これを内部コードに採用しろといわれたら泣きます(^^; まともなベンダ系 UNIX で、 state を保持しないといけない種類の ISO 2022 系のコード をlocale のためのコードとして採用しているような、もの好きなところはあんまりないでしょう。もちろん iconv(3) ではきちんとつかえますが。
@ 通常の EUC(可変長版) は実は 8bit の iso-2022 の一種です。(固定長EUCは UNIXベンダ間での完全な独自規格です)。8bit目をたてているだけではありません。シングルシフト (SS2,SS3)←修正(7/26) とよばれる機能により、全部で4つまでの文字集合をよびだして利用でき、最短で1byte、最長で 3byte になります。一つ目の文字集合部分(= 8bit目が0。普通 ASCII)が他の3つの文字集合(EUC-JP の場合は JIS X 0208, JIS X 0201kana, JIS X 0212) と絶対に重ならないという特性があるのと、シングルシフトしかつかわないので、状態変化は続かない(state 保持不用)という特徴があります。
@ つーことで、SJIS だけが仲間はずれなのでした。
@
ちなみに、JIS X 0208 の 英数字部分と、JIS X 0201 の カナ部分、それから Unicode の 「full-width」な英数字と「half-width」なカナは、過去互換のためのものなので、新規文章ではつかわないようにと、それぞれの規格で言及されています。おそろしいことに、英語で説明できちゃうんですね。これが(苦笑)。
Windows は Unicode 移行の方向ですすんでますから、「半角カナ」を捨てるのは自明の理。
ついでに、JIS X 0213(仮) では、SJIS の「半角カナ」領域をつぶして漢字をいれることになってたりします。
ううっ、修正(6/27)。JIS X 0213 の案では、「半角カナ」のところはよけて、
5000字程度の増強にとどまっております。どこでどう勘違いしたのだろう…
@ このあたりの話は、実のところ、たまたま今の PC-UNIX がまともに処理できないだけで、UNIX 全体としては、既にほとんど(少なくとも日本語を扱う範囲では) 完成された状態なのでした。「多言語」とか、複雑な表示系とかの話になってくると話はまた別ですけどね。
せっかくなんで、書いちゃえ。苦言です。たわごとかも。
@ 現在の Linux を中心にしたもりあがり、ホントに本気で展開するつもりがあるのなら、Linux 協会でもどこでもいいけど、金だして人集めて、「規格を満たす日本語 locale の実装」とかそういった足回りをちゃっちゃとつくらせないとダメですね。「そのうちだれかがつくるだろう」なボランティアにたよりまくった発想だとなかなかまともに使えるものはでてこないですよん。
@ 「無くても一応なんとかなる」な現状がいちばんまずいでしょう。私みたいな以前からつかってて、なぜ動かないか理由もわかってて、でもって、それで特に困ってなくて、その回避方法とかが体にしみついてる人はそもそもあまり気にしてないけど、それなりに筋が通った Windows 環境になれている一般人はごまかせないよん。
OpenBSD の起動画面をほえーとながめてて、あることに気付く。ほえ? midi デバイスが 3つ? ………がびーん。 /dev/rmidi*, /dev/music, /dev/sequencer あるやん(苦笑)。いったいいつのまに(ぉ。 /usr/bin/midiplay コマンドもあるのか。ごそごそ SC-55 をとりだしてきてつなぐ。midiplay SZ_GS08.MID 。 しっかり鳴るやん(^^)。 /dev/rmidi* が raw デバイスでインターフェースとの直接の入出力。 /dev/music がシーケンサ仮想デバイスで、再生タイミングはカーネルがとってくれるのね。NetBSD 1.4 からもってきた模様。さすがに OPL デバイスや、システムスピーカーではきちんとならんか (笑)。単音ならなるみたい。
「痕 for Palm III」ちょびっと詳細な情報。
ちょっと秋葉にでもでてくるかにゃ。
うー、どうやっても建設的な話にもっていけそうにないので、塩崎さんの記述に対してのコメントはほとんどカット。あ、一つだけ。私はいわゆる「全角英数字」をつかってる人をみると、 (そのかかれている文書の場合によっては←26日追記) 「ださださー」と思って、そして、その程度の技量だと判断します。いじょ。
さてさて、Linux 方面の動きとして、「Linux研究会 NLS部会 というものをご教授いただきました。ありがとうございます ＞ ペンギンくん@GEOCITIES 様。すくなくとも citurs よりは順調そうだ(ぉ。うまく実装と調整が進んで良い結果になると良いですね。Linux を商用方面で進めようと思われている方面は、積極的に支援するのが吉でしょう。
ひらがなで名乗る理由、ですか。んー、「ごう」のほうが書きやすいのと、「つよし」とまちがわれないのと、やわらかい雰囲気がでるからかな。
トラブルの嵐。Windows のバカヤロー。しくしく。変になったデバイスドライバを忘れさせようとして上書きインストールしてもうまくいかず、結局再インストール中に CD-ROM ドライブがいかれてて破綻。ぎゃー。おもわぬ出費だ。しくぽん。で、壊れてないのつないでも途中で見えなくなる(大汗)……犯人はこいつカー。
ううっ、結局 IDE の 大容量HDD (某件にからんで借りた) がバス道連れで認識しやがらねぇ。DOS からは見えるのにー(T_T)。OpenBSD からもしっかり見えるのにー(最高性能はだせんけど)。だんだんだん。 HDD はその DOS のエンジン経由でいちおーみえる(パフォーマンスは全然でない)んだけど、同じラインにのっかってる ATAPI の CDがまったく見えん。どうやら該当する症状を MS本家サポートの FAQ で確認するも、「対処方法: Win98 SP2 にすれ」。がふぅ。どないっせーちゅーんやー。日本語版ないやん。ケーブルかってきて ATAPI のラインわけよ…。しくぽん。
はい、 原稿用紙用といった、「そういう状態の実装がある」ことを想定した利用が行われることがあるのはもちろんわかってます。ということで、24日のぶんには「場合によっては」を追記(^^;。でも、状況に応じた使い分けがうまくできていない場合は、やはり、リテラシーの有無と言って良いのではないでしょうか? 文書を書く道具としてのコンピュータは原稿用紙とイコールでは無いのですから。
@ おさまりが良いのは固定幅のフォントを利用されてるからですね :)。私の場合も 慣習としてプレーンテキストで「半角文字」の前後には空白文字をいれることは多いですね。「1桁」とかは意味的に切れるので空白はいれませんけど。非常に目立つ実例としては、E-mail/NetNews の名乗りなどの場面での「だれそれ＠ばしょ」がありますね。半角だと違和感感じる人が多いのでしょうな。
結論。MS P ゴシック/明朝は、そうと気付かせた点で偉大だが、そうと気付かせない点で困ったちゃんであり、IME の不徹底がそれに拍車をかけている。 ←話がかなり飛躍している。
春風亭工房にて、南風センセの「Kanon 食い逃げシール」の画像が公開されてるので、みそこねた人はいくべし(笑)。そーかー秋子さんもだったのカー。栞のタバスコも想定外だった。他は予想通りだったかな。上級編が楽しみなり。
作者の吉川さんとの調整の結果、Pilot-Tech-ML にはあまりそぐわない場合もあるだろう & 敷居が高いかもということで、「痕 for PalmIII」のαテスタ用の ML を別途たちあげました。αテスト(バグ出し)に参加されたい方は、 To: pvns-ml-ctl@dsl.gr.jpに、
subscribe 自分の名前 例: subscribe Go Watanabeという内容のメールを出して下さい。折り返し登録確認の返信がきますので、それに返信すると登録されます(システムは fmlです)。なお、ML 本体のアドレスは pvns-ml@dsl.gr.jp になります。
24日の記述、SJIS の半角カナ領域についての記述、間違い発覚についき修正。 JIS X 0213 では「半角カナ」は保存されております。どこでどう勘違いしたのだろう(T_T)
昨日の文は 断定してて、かつ情報量不足なので反省。それぐらいならかかないほうが良かったかもしれない。
@ いくつか捕捉。塩崎さんのかかれていた「某氏」とは、mohta さんこと、太田昌孝氏のことです、iso-2022-jp の RFC1468 をまとめられた方、 Unicode 反対の先鋒の一人、と言えばわかりやすいでしょう。「JIS X 0208」に統一して使うことを主張し、かつ実際実践されておられたはずです (私はリアルタイム世代ではないので、そのあたりの補強話を聞かせていただけると幸です)。氏の書かれた RFC1468 の日本語訳は 日本語としての文書の部分は JIS X 0208 で統一されており、また比較的最近みたある ML でのメールでも技術的に ASCII でないといけない部分以外は JIS X 0208 で書かれていたように記憶しております。
@ もう一つ。「統合」の規格的な根拠として、ISO-2022 (JIS X 0202) のほうで、 1byte 系の文字と 2byte 系の文字を G0〜G4 領域にわりあてて混在して利用する場合に、「同じ文字」がある場合には、領域の番号が小さいほうのものを利用する旨が決まってたはずです。 (つまり、ASCII vs JIS X 0208 の場合は、ASCII が勝つ) JIS X 0208 の 7章あたりの符号化方式の解説部分でもたしかこれについての言及があったかと。正確な文面は明日までまってね。
@ ついでなので昨日書いてけっきょく消したことも書いておく。基本的にこのあたりの話は、「HTMLの要素タグのまちがえた使い方」といった話と近いものがあると思います。 CSS もそうですね
@ なにはともあれ、断定して決めた調子でいくのはトラブルの要因であることは合意。ただ望ましいと思うことを主張し、啓蒙していくのはやはり重要なことだとは思います。そうしないといつまでたっても状況がかわらないわけですからね。まともな実装も啓蒙としては重要。いろいろ肝に命じておかないといけないですね。
「痕」for PalmIII ML のメンバーは増加中。なーんか知人の名前がちらほら(^^;。新バージョンとフラグ制御ツールの登場で検証がしやすくなってたり。ひさしぶりに「柏木家の食卓」を見た。おお、ノリツッコミ楓ちゃん(笑)。
はい、 データをひっぺがすために Win 版「痕」が必要になりますです。うーん…ここはさくっと新パッケージ版を買ってしまうとか…(ぉぃ
@ ちょっとアイス/氷菓子の話になって、「ガツンとみかん」ってたしか赤城乳業だったよなと思ってみにいくとのってないようなので、検索してみる。…???? これってどうみても「みかん」の検索結果だよな……どうやら infoseek は「ガツン」なる単語をインデックスとして保持してないらしい。なんでやねん。それはさておき、goo で検索すると、本吉君のページがトップで, 次に引っ掛かるのが宇井君のページってのが苦笑(^^; 赤城乳業で正解でした。
@ 苺電波部、トップ絵 by あずみん追加。今後交代でいろいろ更新できたらいいな…。
@ IVNS1、デモ版「ダメダメあかりちゃん」公開。1.5M ほどあります(^^;。本編の部分は全然無し。DNML でまあ、このぐらいはできるよんってところです。なお、DNML/二次創作セット/東鳩CD が別途必要です。詳細は README参照。とりあえず、あかり、ダメすぎ(苦笑)。 PAK をのぞいてはいけません(謎)
ちりちりちり。次の本家は魔女っ子らしいぞっ(謎)。赤毛のショート、体操着にブルマで、マントとつばの広い帽子で、ヒザ下までのハイソックス＆上履き。んで右手に魔導書なロリキャラらC。という映像情報がはいってるが、未確認なので信用しないよーに(ぉ。追記。関連したより正確な情報が 30日、および31日にあり。参照のこと。
いちにち夏休みとった。どうせ修羅場るけど。
だれか、なか卯の券3枚あまってません?、いや、あと3枚あったらくまのマグカップもらえるので(苦笑)
BootEasy とかを FreeBSD のパーティションの先頭にいれるようにしておけば、 MBR さわんなくてよくて幸せだとおもいますがどうでせう? (標準 MBR は、アクティブなパーティションのPBRを読み出して実行するはず)。ちょっと話はそれるけど、たしか今の OpenBSD/i386 は全 disk を OpenBSD に使う場合も、 OpenBSD の biosboot (first-stage system bootstrap)をMBR におくことは避けて、fdisk でDOSパーティション切って、標準 MBRおいて、 1トラック目をよけて、disklabel もそれを参照して領域を決定して、 installboot も、A6 なパーティションをさがして、そこの先頭に biosboot をいれるようになってるはずです。
えと、 「痕forPalm」の URL はおおっぴらには公開されてません。αテスタ ML にご参加下さいませ。 参加方法。
そのでじこは、すでに昨日ぐらいにチェックずみだにょ(苦笑)。日記にかくの忘れてたにょ。あいかわらずのりがダークだにょ＞でじこ←そこがステキ。
ああ、もう、のぞいちゃだめだっていってるのに、みんなのぞいてるし(謎)。で、お気付きの通り、LF2 + LEAFPAK(旧)形式です。キーは東鳩と同じ。どうやってつくったかはないしょ♪(ぉ。
ASCII から秋から季刊ででる、 BSD Magazine(仮称:99%確定)(説明的)の bsd-hackers/bsd-writers ML が活発にうごいてる模様。 writers は著者のみなんだけど、hackers は特に制限があるわけでないので、紙面形成になんらかの形で意見をだしたい人はいろいろつてをたぐって参加すべし。
Leaf から暑中みまい。彩ちゃんと千沙ちゃん♪。木陰でねむねむ〜。
散髪にいってすっきりさっぱり
昨日もちらっと書きましたが、Leaf 大阪開発室(伊丹からは引っ越したんだったかな)
のほうの新作。電撃姫にちらっとだけ記事あり。ただし本当にちらっと。特に買う価値は無しとみなして買わず。ジャンル不明、内容不明。唯一公開されたキーワードは「魔女っ子」(笑)、つーことで、昨日の話はあながちまちがいじゃなさそう。なんかキャラクターショーでそういう絵がでてたらしい。あ、でも、
ロングツインテールだったぞな＞公開された絵。謎。追記: 整理した情報が31日にあり。参照のこと。
(たぶん)ヒロインキャラの立ち絵数点など。 触角ははやりらしい。あれぇ? これ、水無月キャラ…? なんか雰囲気違うが…すくなくとも河田さんの絵では無いが、はて…。あ、今これ書いてて思いついた。なんか、 萩谷さんの絵のよーな気がする。しまった、買ってこなかったから確認できん(苦笑)。だれか買った人いたら確認して(笑)。…で、結局買ってきた(^^;。うーん、目の描き方、体のラインのとりかた、線の強弱のつけかた、たぶん合ってる…と思う。 PS TH から絵師で参加。スタッフロールでは「はぎやまさかげ」。こみパ! official book では P.7 で千沙ちゃんと瑞希描いてます。裸えぷろんを描かせたら天下一品な方(ぉ
他の新しい情報。
さて、錯綜した情報の整理。(thanks to 井之上さん)まず、 7/29 にふれている謎のブルマな魔女っ娘について。これは、 『VENUS IN PARADISE '99 SUMMER』という未来蜂歌留多商会が夏コミで販売するトレーディングカードで水無月徹さんが描かれている絵とのこと。なるほど。「魔女っ娘」をキーに話がまざちゃったのね。
つづいて 7/30 の Leaf新作の原画について、ですが、某チャネル on 某チャットにて曰く「ノーコメント」、だそうです(^^; ま、そういうことで。
ふみ、 子プロセスからの出力ですか。fork した瞬間に子プロセスは親プロセスの開いているファイルディスクリプタを全てうけつぎますから、子プロセスが標準出力に出したものがそのまま親の標準出力と同じところにでているだけのことですね。標準入出力を準備するのは、libc ではありません。
@ 最初に必要な tty(4) をにぎって(openして) それを標準入出力につなぎなおす(dup(2)) のは、init(8) からよばれる getty(8)で、それがそのまま exec(3) によって login(8) になって、さらに exec(3) によってシェルになります。これにより tty(4) への標準入出力の接続がずっとうけつがれています。シェルから fork(2) + exec(3) によって 起動されるコマンドは、通常は親の標準入出力の口をそのまま自分の標準入出力の口として使うわけです。パイプやリダイレクトをする場合は、親のシェルが必要なだけ fork(2) して、適当に標準入出力をファイルなりパイプなりにつなぎなおしてから、 exec(3) で子を呼び出すわけで、子は何がおこってるのか、標準入出力の先に何がつながっているのか、なんてのは普通気にする必要はないのです。 (コマンドによっては接続先が「端末装置か否か」をチェックするものももちろんありますが)
@ pty(4) の場合は、kterm(1x) とか script(1)とかの仮想端末ソフトウェアが 空いてる pty(4) を探して開き、そのプロセス側の口と自分の表示系などを接続してから、fork(2) し、その子側が、もう一方の tty(4) 側の 口を標準入出力に接続しなおしてからさらに exec(3) して、シェルなどになり、このシェルから起動されるものはみんなその標準入出力につながった tty-pty を使うわけです。
@ 余談。daemon は一般的には、この標準入出力を全部切ってしまって端末からの制御をカットし、さらに親子関係も絶縁してしまいます。 (2回 fork して、親、子、孫、となり、子の部分が自殺することで、孫の親を init(8) にしてしまう)
@ exec のセクション番号をどうするか一瞬考えたけど、たぶんライブラリになってバリエーションがあって、exec(3) で代表でマニュアルがひけると思うので 3 にしてみまひた。だらだら文かいてるだけであまり説明になってないような…。
@ みゅ、日が変わってるけど流れでそのまま。 pty の取得、SVR4 の場合は、ストリームな実装で、 /dev/ptmx を開くと、自動的に対応するスレーブ装置がロックされるんでそれをごにょごにょいじって、ptsname でスレーブの名前取得して、そいつを開いて 「端末エミュレーションモジュール」をつっこんで、で、つかえるようになります。BSD のほうは、それであってます。 /dev/ptyp0 から順番にOpen できるものをさがして、マスターの名前(ptyAB)が決まったらスレーブはその名前に対応した名前(ttyAB) なんで、それ開いてちょっとごにょごにょ。
