レス数が1スレッドの最大レス数(1000件)を超えています。残念ながら投稿することができません。
ひらno. on 29ch #5
-
前スレ
ttp://h.gdgd.biz/
-
若干だが納付が必要なようだ。マンドク
-
久々に Windows のお世話になった。e-Tax 専用 OS である。
来年 Windows 2000 のサポートが打ち切られたら、紙で申告に戻るか。
-
>>48
done.
-
うぎゃああああ
しまったな
-
今週も実は危うかった
cron タスクに格上げ
-
朝飯兼昼飯兼夕飯を食ってきた
-
うげ、あるプロセスが、
1) ファイルAをロック (flock でも lockf でも可)
2) ファイルBの内容を変更
3) ファイルAをアンロック
って安全なんだっけ。
OS が 1) と 2) あるいは、 2) と 3) のIO命令の順序を変更しないことは保証されているんだっけか。
-
よく考えると、入れ替わるわけねーな。
-
もちろん 3) の段階でファイルBがディスクに書き込まれていることは保証されていないけど
それは排他制御とは別の問題である。
-
ファイルのロックは今でも big kernel lock を取るんですな。
-
>>56
ファイルを書き換えるときにファイルが壊れる要因としては
1) 他のプロセスと競合
2) 自プロセスが SIGKILL
3) マシン電プチ
ぐらいか。それぞれ万毒である。
まあDB使えばそのへんは普通考えなくていいはずだけれど。。。
-
2) を防ぐ一番楽な方法は、別の名前のファイルに一旦書き込んでから、
元のファイルに対して上書きリネームじゃないかな？
でもこれ、書き込み -> リネームがこの順序でディスクに書き込まれなければ、
3) の問題が発生する。この書き込み順序は保証されているのか？
-
>>59
ファイルシステム依存らしい。
ext3 は 2.6.30 以降デフォルトでは保証されなくなったとのこと。
https://ext4.wiki.kernel.org/index.php/Ext3_data_mode_tradeoffs
-
fsync or fdatasync 呼べよ、って話になるんだが、
俺はディスク書き込み順序を保証して欲しいだけであって、
ディスク書き込みをここで待ちたくは無いんだが、、、
-
http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/ の
The atomicity not durability argument ってとこで同様の議論があった。
ブログの著者は fsync しても多少レイテンシ増えるけど気にしなくていいとか言ってるけど、信じられない。
lock -> write -> fsync -> close -> rename -> unlock とかやった場合、
fsync のレイテンシで他のプロセスまで影響するじゃねーか。
ちなみにこの議論のあと、このパッチによってまた挙動が変わってるっぽいので注意。
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e7c8f5079ed9ec9e6eb1abe3defc5fb4ebfdf1cb
-
ttp://sankei.jp.msn.com/affairs/crime/100325/crm1003252327026-n1.htm
「連れが車上狙いに行ったまま帰らない」などと１１０番があったという。
-
ttp://www.willcom-inc.com/ja/cp/course_change/index.html
これは安くなるのか？でも3年縛りは無いなあ。
-
ちなみに今は月3k強である
-
3k下回る月も多いから3k前後というのが適切か。
-
パケット使用量は月によって全然違うが平均すると3万パケット/月くらい。
したがって>>64のプランに乗り換えると、パケット料金込みでは、逆に高くなる。
引き続き現状維持しよう。
-
それよりはしもすみたく新規解約すると2万くらい差がつくらしいので、ありかもしれんが。
-
本人限定受取郵便物の受け取りマンドク
-
受け取りed.
-
住信SBIネット銀行面に落ちた。
-
gmail のパスワードが漏れると結構やばいなということでパスワードを久々に更新。
ついでに銀行系のパスワードも更新。
-
何も考えず長期の定期預金にぶち込むのがいいんだろうか。
日本経済にインフレする元気は無さそうだし、俺が近い将来まとまった支出をするとは考えづらいが。
-
全額ＦＸ２００倍だろ
-
うわあ、desireいいなあ
-
昨日はなかなか良かった
-
と思うがどうだろ
-
まだ酒が若干残っている気がする
-
今日も飲みk
-
うどんが素晴らしかった。
-
あーあ
自己嫌悪すなあ
-
胸が苦しい＞＜
恋だなこれは。
-
どうしようもねえ。
-
ｍ９
-
>>84
fsck you
-
ksk氏がモテモテである。
-
kernel.orgも4月馬鹿やってたのか
ttp://ankyo.blog.so-net.ne.jp/2010-04-01-1
-
ここに影響無いよな？
ttp://www.bloomberg.co.jp/apps/news?pid=90900001&sid=alyPnrnNfwzA
-
朝飯兼昼飯兼夕飯
-
食い過ぎた
超おなかいっぱい
-
エクスぺリアのキーボード、HT-03Aよりは圧倒的につかいやすいとおもうがハードウェアキーボード厨としてはやはり厳しいと言っておく。この文章を打つだけで5ふん以上かっかっている。いくら他がよくても思った通りに入力ができないと超イライラする。
-
というわけでやはりadvanced esから。快適。
慣れると多少良くなるかもしれないが、その慣れるプロセスが耐えられない。
-
俺が携帯使う主な用途がメールと掲示板への書き込みだからne-
入力はとても大事です。
-
あと実は日本語変換の性能にも有意な差があるんじゃないかな？
adesのATOKのほうがAndroidのWnnより良い気がするが。
-
エクスペリアはWnnじゃなくてpobox touchというものらしい。
-
規制されててLinux板に書き込めない。。。
-
今回の規制はまた長引きそうな予感
-
prin のほうもまだ規制中だしな。
でもこっちのほうが解除見込みはあり。
-
と思ったがログ読むと最近はちゃんと処理されてるっぽいので意外と早いかも
-
飲みながら数カ所とメールでやりとりしていると混信しそうだ
-
信号強度が弱いのはアンテナケーブルのせいだったらしい。
-
アンテナケーブルじゃなくてコネクタかも
-
そういや 1年たったが pccluster.org のメールが届き続けているな。
自分で購読解除できるけど無害なので放置しており
-
てかこれに関係あったのは1年どころか2年半前か
-
On2 Technologies買収してたのか
-
某スレより
ttp://akashi.ci.i.u-tokyo.ac.jp/lab/misc.html
-
相変わらず寝すぎである
-
そしてまた寝るか
-
ようつべは動画をお気に入りに入れると自分のチャンネルで公開されるんだな。
まあ別に問題は無いけど。。。
-
gcc 4.5.0 が出てたらしい
-
xperiaのブラウザ、<input type="file">に対応してないじゃん
死ぬべき
-
全くいつの時代のブラウザだよ
初代京ぽんにすら負けている
-
operaは対応していた。
でもopera はopera でまた色々と挙動が変だな。。。
-
画像の解像度落とす簡単なアプリが欲しいんだがいいのあるかしら
-
にゃー
-
昨日飲み屋でtkd氏と遭った気がする
-
>>111
2.1 の次の Froyo からサポートされるとのこと。
-
やる気なし。
-
DEOS廃止になったの？
-
今日は金曜日なのに比較的電車がすいている気がした。
首都圏からの民族大移動がもう始まっているからかな？
-
11連休であるが
-
> 「高速増殖炉もんじゅ」 ←これ言えないよね。「こうしょくぞうしょくりょもんじゅ」になっちゃう
確かに
-
なんぞ
-
マルチタッチは Javascript では ontouchstart とか ontouchmove とかいうイベントをハンドリングしてあげれば
いいっぽいが
-
ましかしマルチタッチ対応端末を持っていないのでテストできねえ
-
DBI 直で叩くべきか DBIx::Class 使うべきか
-
DBIx::Class はさくら鯖にはインストールされてないな。
s2.xrea.com にはインストールされてるっぽいが、何か変？
-
システムにインストールされてないモジュールはホームディレクトリにインストールすることになるが
xrea はローカルの Debian woody i386 の chroot 環境でビルドして転送すれば動く。
さくらは FreeBSD なのでビルド用 FreeBSD 環境まず作んないとだめだな。
-
と思ったが DBIx::Class モジュール自体は Pure Perl だったので依存関係が問題なければ
ビルドせずにそのまま転送して動く、かも。
-
DBIx::Class はバージョン 0.08117 で perl 5.6 サポート打ち切りとなっているので s2.xrea.com では
0.08115を使う必要があるな
-
DBIx::Class キモいっすなあ。こういうキモさは嫌いです。
おとなしく DBIx::Class::Schema::Loader だけを使ってる分には悪くないと思うけどね。
メソッドオーバライドとかやりだすと魔界に足を踏み入れる気がする。
やりたいことは、テーブルに列を追加するときに、
あるカラムの値に基づいて別のカラムにインデックス用の値をセットすることなんだけど、
ラッパークラス書くのがマシか？だったらDBI直叩きでもあんま変わらんような。
-
あと DBI で sqlite3 を使うときには重大な欠陥がある。これだけで使う気萎えるよな。
http://search.cpan.org/~adamk/DBD-SQLite/lib/DBD/SQLite.pm#Functions_And_Bind_Parameters
-
>>132 # 付きのリンクはうまく機能しないのでコピペで飛ぶこと。
-
なお DBIx::Class 使えば bind 時に型を指定してくれるので >>132 の罠は回避されるっぽい。
-
自分のラッパークラス => DBIx::Class (generated by DBIx::Class::Schema::Loader) => DBI => DBD::Sqlite という仮想化の連鎖がキモすぎるが
まあ仕方ないか。
-
あれ >>132 は特に問題なく動いた、、、
-
いややっぱ動かない。そして DBI でも DBIx::Class でも動かないのは同じだった。
-
WHERE a > ?
は動くが
WHERE a + b > ?
とか
HAVING count(*) > ?
とかは期待通り動かないわけだ。
DBD::Sqlite の問題というより sqlite3 の仕様が変な気もするけど。
>>132にある回避方法のほかにも
CAST(a + b AS INTEGER) > ?
CAST(count(*) AS INTEGER) > ?
とかやれば動く。
注意して使えば問題はない、、、のか？
-
sqlite3のドキュメントにバグを発見した
-
ベンチ
DBIC_Runtime: 16 wallclock secs (14.93 usr + 0.21 sys = 15.14 CPU) @ 66.05/s (n=1000)
DBIC_Pregenerated: 1 wallclock secs ( 1.23 usr + 0.04 sys = 1.27 CPU) @ 787.40/s (n=1000)
DBI: 0 wallclock secs ( 0.34 usr + 0.02 sys = 0.36 CPU) @ 2777.78/s (n=1000)
ランタイムは遅すぎ。まあ Pregenerated なら十分速いな。
-
>>128
xrea は動いた。
さくらはやっぱ FreeBSD 環境を手元に作らないと 無理っぽいな。
DBI でいい気がしてきた。
-
昼から飲んでおり
-
躁
-
ゃぁ
-
ぉぅぃぇ
-
ローカルにFreeBSD7環境作った。
これでさくら鯖ライトプランで任意のプログラムを動かせるようになった。
たとえば、CPU情報をダンプするプログラムとか。
ttp://zngl.sakura.ne.jp/cpuid.cgi
-
ライトプランはPHP無効化されてるけどコンパイルしてうｐすれば動くはずだ。
|
|
掲示板管理者へ連絡
無料レンタル掲示板
