|
．i386-netbsdpe な egcs 環境を commit してみた。やっぱり GNU のアプリ、 それもビルドプロセス(つまり autoconf)にかかわる部分は触りたくない…。 ．-mwindows を付けないと -D__NetBSD__ -D__PECOFF__ で libc のみリンク、 -mwindows を付けると -D_WIN32 -DWINNT な状態で kernel32.dll とか たくさんリンク、と切替えるようにしたのであった。 |
|
．気づくと長い間音楽やってきたが、Am7b5b9 なんてコードが割合と まともな響きであったことに初めて気づく。理論的には、 Am7b5 に b9th なんてテンションは無いし、 やっぱり avoid note だけに、音の重ね方はシビアな気がするが。 ．解説：コードを実際に演奏する場面では、3 つないし 4 つのコード音に、 スケール上にあるコード音以外の音を混ぜて使うのが 普通(俺はそう思ってるけど、本当に普通かどうかは知らん)です。 こういう付加的な音をテンションというのですが、 こいつはどんな音でもいいわけじゃない。 いっちばん単純明解なルールは、 「テンションはコード音の b9 度上の音であってはならない」でござんす。 つまり、たとえば普通の Cmaj7 の和音だったら、9 や 13 は平気だけど、 11 は 3 の b9 度上の音だからダメってことね。 もちろん、スケール以外の音、たとえば b9 とか #9 とかは最初っからダメ。 これ以外の決まりもいくつかあるのだけど、一番大きい制約はこれ。 これはすごく理にかなった規則。ためしに、真ん中の C と、 そのオクターブが一つ上の C# を弾いてごらんなさい。 こういう使えない音を avoid note といいます。 これさえ憶えておけば、好きなコードに好きなだけテンションが入れられる。 ．で、上の Am7b5b9 は、テンション b9 があからさまに avoid note なのですな。 しかしながら、この規則はもともとインチキでして、 ドミナントコードといわれてるものでは何故かほとんど無視できてしまって、 C major なキーで平気で G7 b9 b13 なんてコードがまかり通るし、 実際響きも良い。というか、ジャズの響きはまさにこの響きなのだが。 ．で、話を Am7b5 に戻すと、私は普段は無難に 11th に頼ることが多い。 マイナー系コードでは、11th はほぼ絶対に avoid note ではないし、 一般的に響きもやわらかい。 エキゾチックな響きが欲しい時は Am7b5 9 とか G△/Am7b5 (つまり Am7b5 9 11)なんかも使うのだけど、 こいつは音がきついし、スケールも人工的なものになっちゃうので、 使えない場面も多い。つーか、ボローン、と G△/Am7b5 のコードを一発弾いて、 これがまともな響きに聞こえたら、それはかなりの変態です :-) ．って、Am7b5 なんてもともと特殊なコードで延々と何考えてんだか＞俺 |
|
．勤怠管理ツールが Web ベースになって、格段に使いにくくなった。 前のツールは curses ベースで、hjkl でカーソルが移動できて、 まとめ入力が格段に便利だったのだが… ←勤怠は、まとめ入力してはいけません :D ．そうえば、いいところを一つだけ発見。 一ヵ月の勤怠を一画面で眺められる。これは便利。 いままでのは、画面幅の都合で一週間ごとだった。 |
|
．そういう employer の認識は、半分正しくて半分間違ってますな 。 われわれ employee (苦笑)の世界では、 「てきとーな規模の会社の管理者にもぐり込んで、のうのうと暮らすと楽」 という隠居の仕方はよく話題になる。 一方で、「片手間でできるだろうからお前やれ」 ってことになってる会社も多い。 で、何でそういう状況になるかといえば結局の所、今の employer は、 この職種に対する調査が足りないし、 よって適切なコスト感覚がないのだと思う。 ．私は、ネットワーク管理者ってのは、 ある意味ビルとかの管理人と同じで、 「雑用ばっかりだけど片手間ではできない仕事」 っていう認識かな。 ビルの管理人さんと違うのは、 ネットワーク管理者は専門知識を要求するから高給だってことかのう。 いまどきの世の中、ビルの管理人さんだって、 電話工事の専門知識と免許くらいは持ってるものらしいのだが、 何か、ネットワーク管理者の方は掃除機の使い方も知らないようなのが 多いような気がするんだけど。 ．うちの会社は、「危ないから社外にはまかせない」というポリシーで、 それこそ 100 ピンの不燃ケーブルのコネクタ圧着からして 社内の人間で全部やってる。私もコネクタ圧着やった(笑)。 また、全体の管理のために事実上一人はりついてるけど、 基本的には各分社で分担して管理をやることになってる。 …はずなのだけど、そういう意識のない(以下略) |
|
．某 users 。 いっつも思うんだけど、何で本の一冊も買わずにサーバ管理やろうとするかなぁ。 簡単な vhost の設定くらい、まあ、そらで答えられるようになれ、 とは言わないから、せめて、人に聞かないでも調べられるような 状況を作ってからサーバ立ててくださいな。 |
|
．あう、 表面積小さいからあったまりやすい はちょいと変です。 一般的に、表面積の小さい方が熱抵抗が大きいので、 あったまりにくいし冷えにくい、ということですな。 もちろん、「氷枕全体」として見た場合には、枕の袋と氷の触れている面が 小さく、効率的に枕に熱が伝わらないので 「氷枕の袋はあったまりやすい」のは確かですけれども。 ．元ネタの場合 、 氷は 0 ℃の仮想的な定温度源なので、 それが氷である限り無尽蔵に負の熱を発生する、と見なせますから (周囲が 0 ℃以上であると仮定)、 氷とどれだけ直に接しているか (=いかに熱抵抗が小さいか)が冷えやすさの目安です。 冷やしたい面のほとんどに氷を接することのできる氷の量を超えれば、 冷え方は変わらなくなるし、それ以上の氷は、 どれだけの間冷えている時間が持続するか、という意味になりますね。 それ以下の氷の量だったら、 氷が少なくなるとそれだけ接している面が小さくなるので冷えにくくなる。 したがって、氷が少ない場合には氷が多いほど冷えやすいけど、 氷がある程度多くなれば冷えやすさは変わらなくなる、というのが正解かな。 ．…茄子さんには興味ないが(以下略) |
|
．水木しげるな ToHeart には心あたりが… 。 「おい鬼太郎」「お、お父さんっ」「この金でかまぼこを買い占めるんじゃ」 ←一部で意味明瞭。 |
|
．Mike Smith があっと言う間に Intel の ACPI CA / OSPM の sample implementation を FreeBSD に port してしまったのであった。 いやー、fulltime job な人は仕事が早い。 ここだけの話、先週あたりから私も ACPI CA ベースで 作り直すべきだと思いはじめていたところであったが、 その手間が省けたというものだ。 というわけで、これの NetBSD への port を画策中。 |
|
．ちょびっツ。それにしても、これヤンマガの読者層に受けてるんかのう。 表紙の「カワイさあまってシゲキ 100 倍! 話題ソー然!」って キャッチが如何にも「ヤング〜」系っぽくて、全てをブチ壊してる気もする :-)。 主人公君はいろいろエッチな想像をしてるし、エッチな小細工は出て来るけど、 せいぜい中学生だまし程度のエッチさだし、たぶんこの路線のまま変わらないで 連載進んで行きそうな気がするので、「シゲキ」はないだろう、「シゲキ」は。 |
|
．「冷たさ」と言ったら冷えるスピードなので 、 熱容量で説明するのは「2 万ボルトの電流」並の気持ち悪さを感じるのう。 もっとも、氷の多い少ないがどう影響するのか、 という対素人説明としては適切な気はしますが。 |
|
．ちなみに Wine (WineLib) は 、 peace の実装とは違って ELF-pecoff ブローカーとして動くので、 ELF なバイナリから WineLib を通して DLL を呼べちゃうんですな。 ．もっとも、peace では pecoff がネイティブなオブジェクトフォーマットなので、 わざわざ ELF から呼ぶ必要がないんですが :-)。実際、 負通の NetBSD/x86 環境とは、ほとんどソース互換なので、 NetBSD で動くプログラムは多くの場合それなりに簡単に peace 環境でも動く。 |
|
．こがさん情報。TDU 附属中学/高校 。 タントンタターンタントンタン(←もろ DDR マルチ風) |
|
．うーん 、 私は根が電子屋だからか、過渡特性でモノを見てるのだけど、 どうも課長は定常状態でモノを見てるような。 ．まあ、私も厳密な話はできないので、以下半ばインチキですが、 「冷える速度(not 吸熱量)」というので考察。 ．単純に考えれば、次の 3 つの状態が考えられます：
．1 の場合には、水はほとんど介在しないので、 単純に氷枕をはさんで頭と氷が接している面積に比例して速く冷えるでしょう。 この状態では、氷の量は冷える速度と関係ありません。昨日わたしは、 「一定以上の氷」としてこういう状態を考えてたんですが、 よく考えるとこれじゃ氷が ごっつくて寝れませんな (^^;; ．2 の場合。だいたい半分くらいの氷は直接氷枕の壁面に接していて、 そのすき間に水が入ってるとします。このくらいになると、 水と氷の熱交換が、頭を冷やす速度を支配するようになってくるので、 いかに氷が水を早く冷やせるか、という状況になります。 ．で、頭の冷える速度は、かなり大雑把に言って氷の表面積に比例し、 氷の面と冷やされる面との間の距離 *1に反比例するでしょう。 多分、この辺、言葉で書いてもよく分んないので、図か数式がいいのかのう。 数式だと、やっぱり大雑把にいえば、 冷える速度は面積分「∬∬dSdR/L(s,r)」に比例する。 積分する面は S が氷の全表面、R が冷やされる面の全体、 で、L(s,r) は氷の面 dS と冷やされる面 dR との間の距離。 ちなみに、L も経路積分になる *2。 う、やっぱりよくわからんかも (^^;; ．ここで、氷の質量とか氷の熱容量は直接的には関係ない *3。 確かに質量が大きい方が表面積が大きくなるし、 質量が大きくなれば熱容量も大きくなる。 だから、熱容量が大きい方が冷えやすい、とも言えなくは無いけど、 それは単に氷の熱容量が氷の表面積に対して従属してるからというだけであって、 熱容量の大小は本質的な理由ではない。 ．そうは言っても、氷の量を入れれば入れるほど全体の表面積は大きくなるので、 冷える速度が増加するのも確かでしょう。 でも、氷を増やすと冷やしたい面から距離が離れた氷の面の割合も大きくなる。 よって、トータルの氷の量が増えてくると、 いくら氷を増やしても、冷える速度はあまり増えなくなってくるでしょう。 ．逆に、同じ量の氷でも、真四角の大きな塊より、 クラッシアイスにした方が、特に冷やす面に近い所にある氷の 表面積が大きくなるので冷えやすくなる。この点において、比表面積ってやつは 少なくとも局所的な熱交換の善し悪しの目安にはなる、と考えられますな。 ．3 は単純な水と頭の熱交換に近似されちゃうんで省略。 ．まとめと加筆。
．それにしても、 化学の知識も物理の知識も数学の知識も全部抜けてしまってるので、 知ってる言葉をつないで手探りで考察するしかない状態。 基礎勉強が、いかに「思考をするうえのアクセラレーション」になるかを 思い知ったよ… |
|
|
．この辺もねぇ… 。 WM_PALETTECHANGED 飛んで来たときに、うっかり自分が RealizePalette してしまったらどうなるのかを考えると、 夜もねむれない。一方、ウィンドウごとに我が道を行っちゃう X のパレットは、たまに画面がファンタスティックなことになるしのう。 ．…この後は当然、color mixing なんて鬼門が出て来るのだけど、 この辺はどうしたもんかな。 どこで描画をやるのか、とも密接に関係してくるのだが。 X サーバではできることとできないことがあるので、 X サーバができないことを真面目に処理するなら、 1)X サーバで描いて、クライアントに持ってきて、処理してもう一度戻す、 2)クライアントで全部描く、の 2 つしかないわけだけども。 1 をやるくらいなら 2 のほうが無駄が少ないようにも見えるけど、 実際には X サーバのみで全部できちゃうことの方が多そうな気がするし、 そういう場合には無駄になる。 これに絡んで「フォントをどうするか」というのも大きな問題。 X のフォントを使うのなら、クライアント側で描画するのはちと面倒だ。 やっぱり X サーバで描いて持ってくるか、自分で libfont をリンクするか、 あるいは大差ないけど xfs と通信するか。 …なんとなく、もはや全部 FreeType に頼っちまうのが無難なのかな、 という気がして来たぞ←ヨワヨワ。 ．… Wine の X ドライバは color mixing に関しては、 完全に手を抜いて、描画は全部サーバにやらせてるように見えるな…。 だったらええか、手抜いて(ぉ。 |
|
．うーむ、昨日のタイ料理のせいで、痛いぞ(謎)。 どうも辛いものを食べると、お腹が緩くなるのう。 週末もタイ料理なのだが。 ．電車内ハック。 ．全体会議のため早く出社。 うへー、利益計画、うちが×億円とか言ってる所に、 あっちは×百万円で許されるんですか…。 某分社の増員計画のところでうっかり、「延べ人数は何人なんだろう」 とか本音をつぶやいてしまい、周囲を変な人化させてしまったり。 |
|
．電車内ハックの成果を commit。ついでに free し忘れでコケてたのを直す。 XPutPixel を使わないで自前で blt するようにしたら格段に速くなった。 ．…ふと、一見 8bit 以上の DIB に対応した錯覚に陥ったのだけど、 よく考えてみたら全然ダメだった(^^;; 。 致命的なのは 16bit DIB の時で、ちゃんとビットオペレーションするか、 表索きにせんといかんのう。128k くらいだったら、 表にしちゃってもええんかのう。 あと、今のままだと packed 24bit はちと辛い。まあ簡単に直るけど。 ．…う、誰だ、「簡単に直るけど」とか言った奴は(お前です＞俺)。 いろいろとややこしいぞよ… ．超絶マクロで実装。 |
|
．ううむ、ペンチさん 800MHz ってこんなに速かったんかい。 痕の 8bit DIB を 24bit DIB に一度コンバートさせてから、 これをもう一度 16bit XImage に落して SHM なしで X サーバに投げても、 痕のイントロの背景の波ラスタースクロールが余裕シャクシャクで動くぞ。 ．それにしても、カイコ本を見ると、「sigaction は process grobal」とか 書いてあるのだが、unproven-pthread の実装を見ると sigaction も sigprocmask もスレッド毎にハンドルしてる。どっちが正しいんだろ。 いずれにしろ、スレッドが起動する前にどっかで SIGINT とかはハンドラを 設定して、ほげってやる必要がありそう。 ．それにしても、この関数だけでバイナリでも 32KByte くらいあるな… 帰って来たら分離しよう。 kotori だと、wingdi.c のコンパイルだけで 5 分くらいかかるし。 |
|
．起動せず。 とらハはどうもエラーチェックが弱いことを何故か私は知っているのだが、 そういうわけなので CreateFile に失敗して返って来た -1 をいろんなもんに 渡してる。とりあえず、CloseHandle に -1 が渡った時の挙動が 致命的だったので、ロボに CloseHandle に手を入れてもらう。 ．さて、それだけじゃ動かなかったので、いろいろ検証してみると、 まず、RegOpenKey にバグがあった。 subkey に NULL が渡されると strcat で NULL ポインタ参照してしまうのだが、 何故か落ちずにゴミを regkey->path にくっつけてくれるので、 一見落ちずに変なレジストリキーを返す、というのが一つ。 もう一つは、RegQueryValue の valname に NULL が渡されると以下同様。 こっちは、とりあえず「valname が NULL だったら "/" にする」という ad hoc な対応をしてみたが、どでせうかねぇ。 ．さて、ついでに regkey を書くプログラムを書いて、 とらハのレジストリを書き込んで起動。やっぱり起動せず。 見ると、ファイル名の大文字小文字問題。 しょうがないので kernel32.dll に path の大文字小文字無視パスサーチを 組み込んだ。 ．…これでなんか動いてるようには見えるんだけど、ウィンドウは真っ白。 ログ見ると、StretchDIBits 使ってやがる。 ．…寝ます。 ．…と思ったが、1 分ほどかけて StretchDIBits から 単に SetDIBitsToDevice を呼ぶようにする quick hack 。 すげーインチキだが、一応ゲームできるぞ(笑)。 何故か左クリックだとメッセージが進まないんだけども、 スキップボタンで進ませることはできる。 まだメニューの実装が無いので、セーブも、終了すらもできんけど(笑)。 ．…あー、xtoraha のモチベーションが急降下…。 |
|
．各地で Crusoe な VAIO C1 の話で盛り上がってたりするので、 私もちんまいマシンが欲しくなったぞ。 しかしながら、VAIO C1 はとりあえず却下なので、 いいマシンがないのよねぇ…。条件：
．と、いうわけで、 ふと、irc で言われたことを思いだし、 なんとなく kotori 用の BIOS アップデートでもやってみるかのう、 と思って古巣を漁るが、 いつのまにか 121ware.com なる変なサイトに変わってて、 なれ親しんだ 98 infomation ではなくなってしまってるし。 それだけならいいのだが、困ったことに古い製品の製品情報がないのね。 ．気をとりなおして、BIOS アップデートのページをあさるのだが、 MB12C には UV と UD があって、どっちだかよくわからん。 kotori 裏の銘盤は削れて文字が完全に消えてしまってるし。 いろいろ kotori の体をまさぐってみたが、 MB12C であること以上の情報は得られず。 一瞬ロボにメールだそうかと思ったが、 ただ、どー考えてもこの視野角の狭さが STN 液晶であることと、 いろいろ漁ってるうちに、ロボの 初代の mobioNX の記述、 購入時期 と 古巣のプレスリリース(UD, UV) から、こいつは MB12C/UD D1 であると同定。 ．さて、帰ってから BIOS アップデートでもしてみるかなん。 …というか、kotori は BIOS アップデート処女(←…)なのだろうか。 帰ったらロボに聞いてみようかな。 ．…処女ではなかったらしい 。 がっくし(←……)。 |
|
．なんとなくコードをいじる気の起こらない日なので、 方法だけ考えてみる。 ．DDA で実装。(おわり) ．…って終ってしまった(笑)。いや、実際拡大縮小回転ネタなんてのは、 私としてももう 10 年近く前に一度やったネタなのだ。 当時はアセンブラで自己書き換えとか平気でやってたものだけども、 今や C とマクロの組合せでガーっと展開…するまでもなく、 うちの P!!!-800/133 ならベタで書いても速度出そうだから、つまらん(←…)。 つまらなかったので、SetDIBitsToDevice ではマクロ展開使ったけども(ぉ。 ．というか、どうやって SetDIBitsToDevice の _BLT マクロを StretchXXX に 拡張するか、という純粋に実装上の問題なんだな、実は。 まあ、当面はまた XPutPixel で組んでもいいとして、 最終的には全部の BLT は一つに統合したいのう。 ．さて、この辺一段落したら、どうしようかのう。 そのままフォントに走ってもいいし、 あるいは一度秘密から離れて ACPI に行ってもいいし、 Citrus を真面目にやるのもいいのう。 順序としては、なんとなく、「StretchXXX 暫定版」か「ACPI CA 暫定版」の どっちかが最初になるでしょうな。 |
|
．つーわけで、BIOS を UPDATE しようとしたのだが、 「The BIOS ROM file may not be used with this system」 と出る。ダメぢゃん。 どうも GORRY さんも MB20C でダメだったようなので、 根本的に何かがダメな模様。 |
|
．うーん 、 既にうちの NetBSD では「本物が NetBSD ネイティブ(not emu)で(笑)」 動いてしまってる*1し、 自前で書いても簡単に実現できることも実はわかってる *2ので、モチベーションは低かったり。 ホントにさくっと移植するので良いのなら、 既に tty ではゲームできるし、ほぼ完全に調査も終ってるので、 きっと一週間弱ほげれば、 ちゃんとグラフィカルな画面でゲームができるくらいにはなるでせう。 ．…ホントに需要があれば考えます。きっと、portability を考えて SDL で作るでせう。うちだと thread が動かんのだけど、 もともとのとらハも thread 使ってないし(笑)。 |
|
