2009/07/09
AutoPagerize 対応
AutoPagerize に対応してみた。
AutoPagerize は検索エンジンの結果など複数ペイジにわたる Web ペイジを
スクロールするだけで自動的に読み込んで表示してくれるという、
非常に便利で素晴らしい Greasemonkey 用の拡張スクリプトで、
今やこれがないと Web ブラウジングが苦痛になる程便利な機能である。
paging プラグインも導入したので 右側にペイジ遷移ナビゲータが表示されているのだが、 AutoPagerize が組み込まれているブラウザで表示した場合は スクロールするだけで前後ペイジが表示できるので快適に閲覧できると思う。
AutoPagerize 対応といっても、繰り返したい要素を
"autopagerize_page_element" というクラスの div タグで
指定するだけ。
date.html の日付表示部の上から story.html の最下部までを
"autopagerize_page_element" という div で指定したので、
日付から記事部分が自動で読み込まれる様になる。
2009/07/05
type-P の解像度を任意の値に設定する
type-P は 1600x768 という変態的な解像度なので、
横幅が広く2画面で作業するときなどは非常に便利だ。
その反面文字が非常に小さいので細かい文字をみるのが苦痛な時もある。
そんな時に簡単に画面の解像度を変更したいのだが、
標準の状態では画面のプロパティから任意の解像度が選択できない。
そこで以下の作業をしてレジストリを修正すると
任意の解像度で表示できる様になり、
CrystalRes
という FreeSoft と併用する事で S ボタンで解像度が変更できて
非常に便利である。
ただしこの作業はレジストリを操作するので危険である。
場合によっては Windows が起動できなくなる危険性もあるので、
自己責任において十分注意しながら作業しなければならない。
基本的には
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Sevices\LPCO\CONFIG\SurfaceAdditionsLVDS\通番
というレジストリキーを作成して、
そのレジストリキーに横方向の解像度(Xres)、
縦方向の解像度(Yres)、色数(bpp)を
それぞれ16進数の dword で定義すれば良い。
例えば以下の設定を追加すると 1024x480、1252x600 が選択できるようになる。
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LPCO\CONFIG\SurfaceAdditionsLVDS] "NumSurfaceAdditions"=dword:00000004 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LPCO\CONFIG\SurfaceAdditionsLVDS\0] "Xres"=dword:00000400 "Yres"=dword:000001e0 "bpp"=dword:00000010 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LPCO\CONFIG\SurfaceAdditionsLVDS\1] "Xres"=dword:00000400 "Yres"=dword:000001e0 "bpp"=dword:00000020 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LPCO\CONFIG\SurfaceAdditionsLVDS\2] "Xres"=dword:000004e4 "Yres"=dword:00000258 "bpp"=dword:00000010 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LPCO\CONFIG\SurfaceAdditionsLVDS\3] "Xres"=dword:000004e4 "Yres"=dword:00000258 "bpp"=dword:00000020
これらの解像度を指定できるようになれば、
CrystalRes のコマンドライン引数による解像度変更の機能を利用して
S ボタンの外部コマンド実行から簡単に解像度の変更が可能となる。
せっかくなので S1 ボタンで高解像度と低解像度の変更を
トグル操作をさせたたかったので、
以下の bat ファイルを作成して s1 ボタンから実行する様にした。
これで s1 ボタンを押す度に解像度がトグル動作して非常に便利である。
1@echo off 2 3set index="c:\Program Files\CrystalRes\index.dat" 4 5if exist %index% goto LOWRES else goto HIRES 6 7:HIRES 8"c:\Program Files\CrystalRes\CrystalRes.exe" 1024x480x32x60 9echo LOWRES > %index% 10goto END 11 12:LOWRES 13"c:\Program Files\CrystalRes\CrystalRes.exe" 1600x768x32x60 14del %index% 15goto END 16 17:END
2009/07/04
2009/07/03
ファイルのオーバーライド
通常のパイプ動作するフィルタコマンドでは
元ファイルを直接オーバライドできない。
例えば sort (1) の -o オプションの様に
元ファイルのオーバライド指定ができる
(この動作をスポンジ動作というらしい)もの以外での処理について。
一番簡単で誰でも思いつくのが一時ファイルを利用するやりかた。
$ command < foo.dat > foo.new $ mv foo.new foo.datこの方法だと command の実行中に割込が発生したりすると 一時ファイルが残ってしまい美しくない。
$ cat foo.dat | ( sleep 1; command > foo.dat)この方法だと sleep (1) の時間がうっとおしく、 データ量や command の速度などによって失敗する場合もありうる。
$ (rm foo.dat; command > foo.dat) < foo.dat若干判りづらいのだがこれで確実に成功する。
先行する rm (1) は必須である。 rm (1) がない場合は外側のシェルが '<' により O_RDONLY で open (2) するファイルと 内側のシェルが '>' により O_RDONLY|O_TRUNC で open (2) するファイルの inode が等しいので OS は同一ファイルと見做し、 command の標準入力は O_TRUC により truncate されたファイルとなってしまう。
対して rm (1) がある場合は外側のシェルが O_RDONLY で open (2) するファイルと 内側のシェルが O_RDONLY|O_TRUNC で open (2) するファイルの inode が異なるので O_TRUNC による truncate は影響を受けない。
2009/07/02
2009/07/01
2009/06/30
EF 28-135mm F3.5-5.6 IS USM
オークションで EF 28-135mm の IS レンズを入手した。
フィルター径 72mm のレンズは Kiss に装着するとさすがに大きく、
本体よりもレンズの方が目立ってしまう感じ。
EF 50mm F1.4 USM と EF 28-135mm F3.5-5.6 IS USM
念願の IS ーIMAGE STABILIZERー は
スゴイの一言につきる。
シャッタースピード 3 段分程度の補正効果があるという IS は
確かに効果満点。
室内でストロボを発光させずに IS on / off で試し撮りを繰り返してみると、
カメラの小さなモニターで見てもはっきり判る程の手ぶれ補正効果に驚き。
しかも 28-135mm なので屋外での撮影は殆どこれ一本でまかなえるから、
少なめの荷物で出かける時など最適のレンズではないだろうか。
薄暗い室内や夕方の公園などの撮影に威力を発揮しそうで楽しみだ。
2009/06/29
2009/06/18
SIGPIPE
1#!/bin/sh 2 : 3if ${any_command} | grep -q "${word}" 4then 5 :
linux 上で実行しているこの様なシェルスクリプトの ${any_commnand} がたまに異常終了している事がある。
気になって調べてみると SIGPIPE を受信してエラー終了している様だ。
grep (1) のマニュアルを調べてみると
Exit immediately with zero status if any match is found, even if an error was detected.
man grep
と明記してあるので grep (1) が先に終了してしまったので、 ${any_command} に SIGPIPE が送信されているらしい。
スクリプト中で grep -q は割と多用すると思うが、
こんな落とし穴もあるので気をつけなくては。
そもそも grep (1) なんてよく使うコマンドだから
かえってマニュアルを熟読しないだろうし、
だからこの様な BUG が潜む原因にもなっていると思う。
というか実は常識的な話だったりする?