虚構人形廃棄場

エアコンの排水がバルコニーの溝(排水目地と呼ぶらしい)からあふれていたので、直接排水溝に届くようドレンホースを延長したのですが、先端の収まりが悪い。

工事業者はVVFケーブルを巻いて対処するようですが、わざわざ買うのもバカらしいし、切断面だけとはいえ銅が露出していますから緑青が吹いてしまうでしょう。

アマチュアの一点もの工事はコストなんか大雑把でいいので、ステンレスか石が良かろうなあ、片サドルでも使おうか、とホームセンターを徘徊するうち、M20ナットに目が留まりました。

M20のネジ山を切る際の下穴は17.7mm、14mmドレンホースの外径は19mmです。これをキリキリとねじ込んで解決しました。

TH-WR700の送信機はあまり電池が持ちません。

電源OFF状態での待機電力が多く、たまにしか使わないと、次に使おうとした時には電池が空になっていること請け合い。

電池を抜いておけばいいのですが、ヘッドフォン側と4本着脱は面倒ですし、そもそも電池を外しにくくなっています。とりあえずリボンを接着して外しやすくしましたが、送信機を接続するのがもう一つの面倒です。

ちなみにリボンは末端からほどけてくるので、炙るなどして処理しておかないと悲惨なことになります。

できればヘッドフォン側の用意だけで後は勝手に動いてほしいところ。幸い、KDL-22EX300の音声はOlasonic TW-D7OPTとの光接続がメインのため、テレビ本体のヘッドフォン端子は接続したままで問題ありません。

というわけで、ダミー電池を製作してACアダプタ給電にしてみました。これが単3なら単4→単3変換スペーサが流用できますが、元が単4では作るしかないのです。

ryuchi氏のレシピを参考に、使った材料は以下の通り。

• 丸パイプ(ABS樹脂) Φ10×37mm
• 銅平リベットΦ5×10mm
• ナベ小ねじM2.6×8mm
• ローゼットワッシャM3
• ラグ端子M2.6
• ビニールコード適量
• DC3V ACアダプタ
• DC中継ジャック

作り始めて気付きましたが、両側から挟まれますから、必ずしも電極を接着する必要はないのでした。

この種の電池専用送信機は数多いですが、EIAJ#1でも付けてくれればいいのに、と思います。また可能ならラインレベルへの切り替えができると嬉しいな。

三日連続の40度超えにより四万十が41.0度を記録、遂に熊谷・多治見の40.9度が破られてしまいました...(涙)。

まあ関東圏では熊谷や甲府のブランドイメージは記録以前からでしたから、致命的ではありませんが、その点では単年最高記録持ちの牛久や上里見、特に上位ランカー館林が実力(何)の割に影が薄くて不憫だったりします。

さてネットラピュタ退会後、しばらくメールはGmailでしたが、プライバシーポリシー騒動の後、MACアドレス収集騒動があって足を洗いました。

そこでHotmailに来ましたが、IMAPが使えません。サポートしようかなあ、という話もあるようですが、1年経って音沙汰なしですからリップサービスなのでしょう。

でもそれ以外は悪くないサービスです。spamもほとんど来ませんし、モバイル限定ならActiveSyncでIMAP以上のものが使えます。IMAPさえあったなら...。

Hotmailを選んだ時はMacの利用頻度が上がっていなかったこともあり、IMAPを使ったことが全くありませんでした。しかし勤務先がOffice 365を導入したことでIMAPを使い始め、一挙に最重要機能になってしまったのです。

そこでHotmailの転送機能で別のアカウントに受信メールを飛ばし、そちらのIMAPを使って受信、送信はHotmailのSMTPを使い、保存はIMAPの送信済みフォルダにすることで、擬似的にIMAPの恩恵が受けられます。あとは転送先の選定だけです。

最初はYahoo! JAPANにしてみましたが、spamが酷くて半年でギブアップ。でもこのアカウントはオークションで長年使っているものですから、メールの使用開始前からspamに晒されていた可能性があるため、spamに関する公平な判断はつきません。

ここで言うspamはYahoo!デリバーを含みません。無料でネットのリソースを使わせてもらうのですから、あれは必要にして正当なサービスであり、私も同意して使い始めました。それ以外の純粋なspamが多かったのです。

無料版spamフィルタはあまり機能せず、ThunderbirdはともかくiOSにspamフィルタがないため、サーバー側に頼るべきところ、そもそもHotmailアドレス自体にはspamが来ていないので、乗り換えるべしという結論になりました。

乗り換え先を調べてみると...まあGmailが現実的に筆頭候補にならざるを得ないのはわかっていますが、他に無料IMAPはあるかというと...AOLがありました。現在順調に移行を完了したところです。

Yahoo!メールはフォルダを受信箱と同階層にしか作れませんが、AOLは自由に作れます。これも嬉しい違いでした。

身の危険を感じる気温になりました。さいたま市37.4度。皮膚が焼けるような感覚でした。

甲府と四万十で40.7度と、熊谷と多治見の日本最高記録40.9度に迫る勢いでした。猛暑はまだ2週間近く続く見込みということで...。

ところで記録を破られるとですね、埼玉県の数少ない観光資源が一つ消えるわけですよ、ええ。2007年に獲得したばかりの地位ではありますが。

観光資源と言っても話の種程度の意味ですが、地域振興にはそれがあるのとないので大違い。宇都宮が静岡と餃子の消費量を競っているのも同じでしょう。

しかし歴代記録の40度超えを見てみると、今日の前はもちろん40.9度を記録した2007年、その前が2004年(甲府40.4)、2001年(牛久40.2)、1998年(上里見40.3)、1994年(かつらぎと天竜が別の日に40.6)...。

それより前は、1978年(酒田40.1)、1933年(前回最高の山形40.8)、1927年(宇和島40.2度)です。

1978年は最低気温でも上位に複数が陣取る異常な年ですが、傾向としてやはり最近の頻度が高いとは言えるでしょう。米所で品種の鞍替えを視野に入れ始めていると聞いたこともあります。

地球の温暖化が人間のせいかどうか、言い換えれば人間が防げるかどうか、そこには議論が多いようですが、ともかく気候がおかしいと感じるのは自然なことでしょう。

いきなりIndex 0EEhでString Descriptorを取得に来ることで悪名高いMicrosoft OS Descriptorですが、xHCIだと読みに来るものが限られるようです。

どうもUSBスタック(正確にはハブクラスドライバ?)が主体的に行なうものらしく、Windows 8以降のMicrosoftスタックだと読みに来ますが、少なくともルネサスのスタックだとOSに関わらず、Extended Propertiesを読みません。Extended Compat IDは読みます。

他のメーカーは不明ですが、基本的にルネサスはEHCIスタックをベースに開発したのでしょうから、Windows XP初期に実装されたものだけが引き継がれ、結果として制限事項になったと推測しています。

ということは、例えば.inf無しでWinUSBを読み込ませる企ては、限定的にしか実現されないことになります。DeviceInterfaceGUIDが書き込まれないためWinUSBのAPIから接続できません。

ただしWinUSB.sys/.dllの読み込みまではできるので、Device ParametersにDeviceInterfaceGUIDを書き込めば(通常の管理者権限で可能)何とかなります。個人使用ならこれで充分でしょう。

まとめると、回避法は以下になります。

• Windows 8以降でMicrosoftスタックを使用
• xHCIポートを使わない
• HCKにinfを申請し署名入り.catファイル発行(有償)
• DeviceInterfaceGUIDを手動で書き込み
• 自己署名とテストモード
• 32ビット版WindowsやXP x64

OleLoadPictureが失敗するWindowsビットマップ形式ファイルがありました。

Photoshop Elements 7で作成した16bpp/RGB565のもので、プレビューはできていますが、フリーソフトのGVでも失敗。

どうやらBITMAPINFOHEADERのbiSizeが間違っているためと判明。40でなく56になっていました。

BI_BITFIELDSのマスクはbiSizeに含まれませんから、これはバグでしょう。biSizeを40に修正すると、色も含めて正常に読み込むことができました。果たして最新はCS6とかCCとかはどうなのか。

そもそも16bppのカラーマスクはRGBの3つ分なので、56でなくせめて52だろうとか、他にもツッコミどころがありますが...。

バージョンの付け方が不揃いすぎるというのは置いておき。

DeltaEndの0.61を公開しました。通知領域から昨日の変更ができていなかった酷いバグの修正と、内部動作の改良。DLL開放でメッセージ専用ウィンドウを、列挙とWM_NULLのポストによる通常の方法で対処できるようになりました。


gnyaclockも2.0.2になりました。機能的にはGDI描画とGDI+描画の切り替えができるようになったぐらいですが、内部は別物です。PostScriptベースのOpenTypeフォントをGDI+で描画するためのQGraphicsText.dllが含まれています。

リスタートマーカーがどの程度実用になっているかと試してみました。

0FFDxhの下位3ビットが番号を表してRST0～RST7の8種類ですから、7連続で破損しても回復できるはずです。つまり例えばRST2の次が同じRST2の場合。

8連続以上を判別できないのは桁数の問題ですからどうにもなりません。MPEG-2 TSのcontinuity_counter(4ビット)も16連続以上は無理です。

そのJPEGですが、3連続の破損でずれました。ずれるつまり想定されるMCUの位置に進めなかったことを意味します。

私の実装だと回復できるのですが...IJGの実装のようですね。djpeg.exeでも確認しました。WindowsプレビューやFirefox等々。

jdmarker.cのjpeg_resync_to_restart()の中で再同期を処理していて、なるほど確かに2連続までしか復帰処理をしないようです。

そんなに派手に吹っ飛んだら表示し続けることの意味も薄いでしょうが、なぜ制限しているのでしょうね。

今の仕事に関係あるものの要求仕様にないところで、JPEG(ベースラインのみ)の実装をしてみました。

JPEG...夢でした。学生時代、まあ躁の気の迷いですから結局手つかずでしたが、「わかりやすいJPEG・MPEG2の実現法」なんて本を買ったりもしました。

ホストから短いパケット単位で送られてくるデータをその都度展開するという、能動的に読みに行く通常の動作と逆のものです。

マルチスレッドや割り込み優先度の差によって、データが必要サイズ揃うまで受信コールバックをブロックすればlibjpegの動作すら可能でしょうが、ちょっと作ってみたのです。必要RAMは3KB弱となりました。

以前Zlib展開の実装をしたことがありハフマン符号の理解があったこと、難関である逆離散コサイン変換に既存の(ライセンス的にOKな)関数を使ったことから、1週間程度で実用レベルのものができてしまいました。

ちなみに量子化テーブルやハフマンテーブルが一つのマーカーになっているもの、Y/C、DC/ACそれぞれ別々のマーカーになっているもの、と個性があるようでした。YCrCb 4:2:2のサンプルはImageMagickで作りましたが、出力できるソフトはあるのでしょうかね。

わかってしまえば至ってシンプルだなあ、というのが感想です。「非可逆」という割り切り、劇的な圧縮率。20年を越えて現役であり続けるのは凄いものです。

(追記2013/7/24)
YCrCb 4:2:2対応ソフトは少なくないようですが、GIFアニメ大学校様のこちらによると、Paint Shop Pro 8が色々設定できたようです。最新X5は不明ですが、さすがに4x2:2x2:2x2みたいなのは異常と言わざるを得ないような...。

出かけた帰り、浦和を歩いていると参院選候補者のビラが大量に路上に捨ててありました。ほとんど束になっている状態で、もらった人が捨てたものとは思えませんでした。

場所はイトーヨーカドー隣の薬局跡の角、線路沿いから一本入った道ですが、不自然きわまりない。

普通、選挙活動のビラ配りは駅前で行なうものでしょう。ビラを配る人があそこにいたとは考えにくいのですが、一体何がどうなってあそこに捨てたのか。

ともあれ都議会選で大負けした上にこの体たらく。下っ端の仕業にしても、ゴミの始末ぐらいしてもらいたいもんです。

月曜になってもまだあったので撮影しておきましたが、輪ゴムまでかかってますね。