tDiary-2.1.4からは section_enter_procと section_leave_procが用意されてるので、現在 body_leave_procを使って一日毎に行ってることを、section_leave_procでセクション毎に行うだけ。
気が付いたらファイルサイズが 3.8GBを超えてるのにまだダウンロードしてる。32bit版は約 3.5GBのはずなのに。
ダウンロード済みのサイズがマイナスMBになってるし。進捗グラフがマイナス%になってる。MSのサーバーに「Range: bytes=-123456789-」みたいにマイナスから始まる変な要求を送ってる。
構わないと思うのですよ、リロードの度にプラグインを評価しなくても。
--- index.rb~ 2005-06-13 14:05:11.000000000 +0900 +++ index.rb 2006-06-11 00:52:18.203125000 +0900 @@ -60,11 +60,15 @@ body = '' head['Last-Modified'] = CGI::rfc1123_date( tdiary.last_modified ) + require 'time' + ims = ENV['HTTP_IF_MODIFIED_SINCE']; ims = ims ? Time.httpdate(ims) : Time.at(0); # ENV? + diary_changed = (tdiary.last_modified - ims) > 30; # 30? + # ETag testing code #require 'md5' #head['ETag'] = MD5::md5( body ) - if /HEAD/i !~ @cgi.request_method then + if /HEAD/i !~ @cgi.request_method and diary_changed then if @cgi.mobile_agent? then body = conf.to_mobile( tdiary.eval_rhtml( 'i.' ) ) head['charset'] = conf.mobile_encoding @@ -73,15 +77,15 @@ body = tdiary.eval_rhtml head['charset'] = conf.encoding head['Content-Length'] = body.size.to_s - head['Pragma'] = 'no-cache' - head['Cache-Control'] = 'no-cache' +# head['Pragma'] = 'no-cache' +# head['Cache-Control'] = 'no-cache' end head['cookie'] = tdiary.cookies if tdiary.cookies.size > 0 print @cgi.header( head ) print body else - head['Pragma'] = 'no-cache' - head['Cache-Control'] = 'no-cache' +# head['Pragma'] = 'no-cache' +# head['Cache-Control'] = 'no-cache' print @cgi.header( head ) end rescue TDiary::ForceRedirect
Segmentation faultが起こったり起こらなかったり、起こったとしても(特定のパターンはあるにせよ)違う場所だったりとはっきりしないエラーに困らされた。
原因が create_aggregateで独自に定義した集約関数を使ってるからだということはわかってる。RubyForgeに関連のありそうな投稿を見つけた。
原因はリファレンスが切れて GCに回収されてしまったオブジェクトを参照しようとしてることにある、ということで良いか? 何ともヘタレな回避策は↓。
GC.disable; db.execute(sql); GC.enable
sqlite3-rubyはもうメンテされないのかね。名前付きプレースホルダの問題も解決されないし。
sql = 'SELECT * FROM Books WHERE Title = :title;' db.execute(sql, {'title'=>'惑星をつぐ者'}) #=> no such bind parameter 'title' とかなんとか db.execute(sql, {':title'=>'星を継ぐもの'}) #=>(゜Д゜ )ウマー
bind_parameterのキーに普通はコロンを付けたりしないよね、多分。
WINDOWSが起動しなくなってから、復旧した後でイベントビューアを見てみると大量のエラーが記録されていてびっくりすることがある。こんなの。
ページング操作中にデバイス \Device\Harddisk1\D 上でエラーが検出されました。
ドライバは \Device\Harddisk1\D でコントローラ エラーを検出しました。
アプリケーション ポップアップ: Windows - 遅延書き込みデータの紛失 : ファイル C:\Temp\$Mft のためのデータを一部保存できませんでした。データを損失しました。 このエラーは、コンピュータのハードウェアまたはネットワーク接続の障害によって発生した可能性があります。このファイルをどこか別の所に保存してください。
最初のエラーが出た時点で気づいていれば WINDOWSが起動しなくなる前に何とかできたかもしれない。でも WINDOWSはエラーログを吐き続けるだけで何の警告もしてくれない。それをしてくれるのが eventtriggers.exe。特定のイベントの発生をトリガーにして特定のコマンドを実行してくれるプログラム。\WINDOWS\system32の中にあるはず。但し Windows XP Professional限定。少なくともこの PCには入っていない。
まただよ。また Home Editionの制限にやられた。こんなにも制限事項に引っかかるのが事前にわかってたら価格差を考えても Proを買ってたのに。
読んでみたくなる表紙カバー。
以上を読んで、俺ルールを述べる。
「モーニング娘。」は「。」まで含めて初めて「モーニング娘。」。* 外国語表記のアーティスト名を勝手にカタカナにして夕刊のヒットチャートに掲載していた読売新聞が嫌いです。
小学校で書写とかいう苦行を散々やらされたがそんなルールはなかった。教科書は「〜〜。」というように書かれてたし、これをノートに写すときは句点と閉じ括弧を同じマスに入れるというルールがあったことまで覚えてる。(間違えると間違えた箇所から書き直し。手書きのノートに「コピペ」「挿入」なんてないから延々書き直し(´Д⊂)
教科書至上主義の俺には活字媒体で幅をきかせてる送りがなの規則も不自然に映る。ATOKは送り仮名の送り方として「本則」「省く」「送る」「すべて」の 4つから選べるようになっているが、ATOKのヘルプから送り方の例を抜き出してみる。
本則 終わる 表す 省く 終る 表す 送る 終わる 表わす すべて 終る・終わる 表す・表わす
俺の時代の俺の小学校の教科書と漢字ドリルの送り仮名は全て本則で書かれていた。ATOKの設定は当然「本則」にしている。新聞・雑誌など活字メディアで一番目につくのが「表わす」。俺にしてみれば「短かい」('か'は不要)と同列の誤りに見えてしまう。
逆に日本語でなければ部分的にカンマも使う。
私は pearl, python, rubyを触ったことがありません。
公文書や新聞では表記を統一しなければいけないとかで読点やカンマを混在させたりはできないかもしれないがね。二重母音の「エイ」を全て「ー」と書くというのもそう。個人の文章や著作なら「ゲーム」「メイン」「メール」「プレイヤー」みたいに俺基準に沿って、より自然に感じる表記を選べるけれども、表記を統一する必要がある場合はどちらかを選ばなければいけないわけで、その結果不自然に見える部分が出てくるのは仕方ないと思ってる。
花岡っちは自分の業界を絶対視しすぎ。句読点然り、遷移然り。とはいえ、みずほ銀行のサイトに一般人への配慮が欠けてるのも事実。みずほ銀行のページに行ってみても確認できなかったので想像で書くけど、「宝くじに遷移します」というメッセージを見るに、これってリダイレクトのみを目的として一時的に表示されるページに書かれたメッセージじゃないの? 一瞬意味がわからなくてもすぐにページが切り替わるのを見れば「ああ、そういう意味だったんだな」ってわかると思うんだけど。意味がわからなくても困らないし。(みずほ銀行に同情してみたけど不親切なメッセージってことは変わらんね)
初めはトランジションという単語を、HTMLを触り始めてすぐの頃に目にした。Internet Explorerではページを表示するときと去るときに色々と用意されたビジュアル効果を適用することができて、これがトランジションと呼ばれていた⁑。遷移という単語はこれの訳語として後で知った。以後、遷移は自分の中で一般化した。4月7日の日記で「遷移」が 4回使われている。(他にネットを通して初めて自分の中で一般化した言葉といえば「萌え」。初めて目にしたときは「萌える」=「芽が出る」だったので全く意味不明だった。)
以前から横にだらだら延びた段落は醜いと思っていた。
このようなページを見つけた。C O U L D:固定か可変かそれが問題だ
早速 cssに下記の一行を追加した。
body { max-width: 50em }
emってな曖昧な単位に少し不安があるが Firefox1.5と IE7.0で同じように見えるので良しとする。
UTF-8な文字列を環境変数に設定して読み出すと尻切れ。
C:\Documents and Settings\ds14050\デスクトップ>irb irb(main):001:0> sjis = '高殿 円\' # 『銃姫』を読んでる。 => "\215\202\223a \211~" irb(main):002:0> ENV['hoge'] = sjis => "\215\202\223a \211~" irb(main):003:0> ENV['hoge'] == sjis => true irb(main):004:0> require 'nkf' => true irb(main):005:0> utf8 = NKF::nkf('-w', sjis) => "\351\253\230\346\256\277 \345\206\206" irb(main):006:0> ENV['hoge'] = utf8 => "\351\253\230\346\256\277 \345\206\206" irb(main):007:0> ENV['hoge'] == utf8 => false irb(main):008:0> ENV['hoge'] => "\351\253\230\346\256\277 \345\206"
日本語の PATH_INFOが文字化けするのに閉口してて、Apacheだとか mod_rewriteが悪さをしてるのかと思ってたけど環境変数を経由してたところに問題があったのかも。
文句を言ってても解決しないので REQUEST_URIから SCRIPT_NAME相当部分を取り除いてから URLデコードして自分で PATH_INFOを手に入れる。
ところで URLエンコードされたスラッシュ(%2F)が含まれてた場合、PATH_INFOを参照するだけではその存在がわからないと思うんだけど。やっぱり PATH_INFOって使えない?(<< いやいや PATHと名の付くものにスラッシュやバックスラッシュを含めるのが間違い)
<pre>の中だからってタグが書けないわけじゃなし。インライン要素なら OKのはず。
C:\Documents and Settings\ds14050\デスクトップ>diff -u hikidoc.rb~ hikidoc.rb --- hikidoc.rb~ 2005-10-06 16:42:35.000000000 +0900 +++ hikidoc.rb 2006-05-30 06:34:32.265625000 +0900 @@ -142,8 +142,9 @@ end def restore_pre( text ) - ret = unescape_meta_char( text, true ) - ret = restore_plugin_block( ret, true ) + text = inline_parser( text ) +# ret = unescape_meta_char( text, true ) +# ret = restore_plugin_block( ret, true ) end ######################################################################
''test'' ''test'' ''test&'test\''' ''test&'test\'''
<p><em>test</em></p> <pre> <em>test</em> </pre> <p><em>test&'test'</em></p> <pre> <em>test&'test'</em> </pre>
結果: ×111、△23、○25、◎41
結果はさておき、この↓「かんざきしゅんみ」さん。ヤングアニマルで『ああ探偵事務所』を連載中だというのにこの認知度の低さ。現役だよ?コミックスを欠かさず買ってる人間として嘆かわしい。立ち読みでいいから読んで欲しい。カバー絵からの予想は絶対裏切られるから。そして、アレな探偵と常識人で助手の涼子さんのコンビに魅せられたらしめたもの。6/29には 10巻が発売です。探偵ものを期待してナンセンスだと思われたらさようなら。
50 関崎俊三 (a g h) × (156) *********************************************** ◎21 ○27 △11 ×156 ○ (27) ******** ◎ (21) ****** △ (11) ***