サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
macks.hatenadiary.org
FD_SETSIZE 問題とは、1 つのプロセスで大量のファイルを同時に open するなどしてファイルデスクリプタの値が FD_SETSIZE *1の値を超える(fd >= FD_SETSIZE になる)と標準の fd_set 型で取り扱えなくなり、select(2) が正しく実行できなくなる、という問題。有名でわりと古典的な問題だが、今でもいろんなところに埋まっている。 たとえば、同時に大量のネットワークコネクションを取り扱いたい大規模サーバではこれが問題になる。実際にこれを踏むと、範囲外アクセスを起こして Segmentation fault で落ちることが多い。 なお、select(2) そのものの実装は(現代的な OS のカーネルであれば) FD_SETSIZE には依存しておらず、呼び出し側(ユーザランド)の問題である。 また、一般的な解決方法として、子プロセスを作ってそちらに
KVM の仮想マシンのディスクイメージを raw format で作成して運用していたんだけど、容量が不足してきたので拡張しようとしたら色々と厄介だったので備忘録代わりに手順をメモっておく。 前提 ディスクイメージは raw format。 ディスクは /boot + LVM という構成。 大まかな手順 ファイルサイズを増やす パーティションを切り直す LVM の Physical Volume をリサイズ LVM の Logical Volume をリサイズ ファイルシステムをリサイズ 後始末 手順 ファイルサイズを増やす 増やしたいサイズの分(今回は 10GB)のゼロデータを後ろに追加する。(dd の seek= を使わなかったのは、sparse ファイルにしたくなかったから) # dd if=/dev/zero bs=1M count=$((10 * 1024)) >> disk.i
TokyuRuby会議01へ行ってきました。 真っ昼間から酒と食べ物をつまみつつ Ruby に関係したりしなかったりする内容を語る、たいへん楽しいイベントでした。プログラムの前半も終わっていないのに「会場が酒臭い」とか「カオス」とか言われてしまうような勉強会は初めてです。Tokyu.rb のイベントは初参加なのですが、普段からこんな感じなんでしょうか。 以下、LT の内容メモ(と感想)です。 No.1 たのしいRuby (MH35) Ruby のプログラミングは楽しい No.2 ROMA Client Server (@sato_ryu) HTTP Client から ROMA へのアクセスを可能にするための Proxy Server を Sinatra で実装した話。 「ROMA の Client」として動作する「HTTP Server」なので「ROMA Client Server」。
glibc の wcwidth() の動作を自分の手できちんと検証したことがなかったので実験してみた。対象バージョンは Debian lenny に含まれていた 2.7-18。 実験に使ったのは以下のプログラム。 #define _XOPEN_SOURCE #include <stdio.h> #include <locale.h> #include <wchar.h> void print_wcwidth(wchar_t c) { printf("wcwidth('%lc') == %d\n", c, wcwidth(c)); } int main() { setlocale(LC_CTYPE, ""); print_wcwidth(0x41); print_wcwidth(0x3b1); print_wcwidth(0x3042); return 0; } これをコンパイルして、UTF
「ソケットを直に触るプログラムを書くのは初めてなんですが、何かアドバイスないですか?」みたいなことを聞かれたので、入門書には載ってなさそうな注意点をまとめてみる。 とは言っても、私自身、直にソケットを叩いて C や C++ でプログラムを書いていたのは遠い過去のことだし、その道の専門家でもないので、誤りや抜けてる項目に気づいた方や、よりベターな方法を知ってる方は指摘していただければありがたい。 前提 対象読者は最低限の知識(TCP/IP, socket, シグナル等)を持っていることが前提。 Linux + GNU libc だけの環境を仮定。その他のライブラリは無い。 TCP, IPv4 でクライアントを実装する。 注意点まとめ あらゆるシステムコール/ライブラリ関数が失敗する可能性を考慮する。 入門書や解説本ではエラー処理を省略している場合がある。 fdopen() を使ってソケットか
glibc の wcwidth() の「曖昧な文字幅」についての動作の話の続き。 やっぱり、UTF-8 の charmap を全部書き換えてしまうのは良くないと思い、以下のようにしてみた。 まず、/usr/share/i18n/charmaps/UTF-8.gz を改造して ambiguous width な文字の幅を 2 にしたものを /usr/share/i18n/charmaps/UTF8-8-CJK.gz として設置。*1 次に UTF-8-CJK を使って locale を再作成 $ sudo localedef -i ja_JP -c -f UTF-8-CJK ja_JP.UTF-8あるいは、/etc/locale.gen を以下のように書き換えて locale-gen コマンドを実行しても同じ。(Debian 特有?) en_US.UTF-8 UTF-8 ja_JP.EUC-
以前書いた記事(Ruby 1.9 の新機能を調べてみた)の m17n がらみの箇所についてコメントやらトラックバックやらをいただいたので、もう少し調べてまとめてみた。 なお、1.9.0 リリース版ではなく、開発版(trunk r14835)で動作を確認している。 コマンドラインオプション -E --encoding "ruby -E エンコーディング名" または "ruby --encoding=エンコーディング名" のように使う。 Encoding.default_external を指定したエンコーディングに変更する。 コマンドラインで指定したスクリプトファイル(または -e で指定したスクリプト)のエンコーディングを変更する。(スクリプト内でマジックコメントによるエンコーディング指定を行なったのと同じ効果だが、マジックコメントで指定がある場合はそちらが優先) -K ruby 1.8
1.9.0 のリリースも近いということで、Changes in Ruby 1.9 を参考にしながら Ruby 1.9 trunk (r14828) で遊んでみた。 まあ、ほとんどは上のサイトに書いてあるとおりなんだけど、「おっ」と思った点やその他で気付いた点を以下に列挙。(既に書かれている内容はほぼ省略) Changes in Ruby 1.9 のページに書いてあるけど現状に即していない点。 Object#__send__ は、けっきょく可視性に関わらず全てのメソッドを呼べるようになった。(__send や __send! は廃止) NameError は、けっきょく StandardError のサブクラスに戻った。 Hash#each と Hash#each_pair は同じ動作になった。 他にもあるかもしれないけど、とりあえず気付いたのは以上。 RubyGems が標準で組み込まれる
プログラマブルな DNS サーバが欲しくなったので、スクリプト系言語で DNS が実装できるかどうか調べてみた。 Perl であれば、CPAN に Net::DNS::Server というモジュールがあるので、これを使えば簡単に DNS サーバが実装できるようだ。 また、既存の実装では DNS Balance が「Ruby で実装された DNS サーバ」だということが分かったが、コードを見たところあまり流用したくなるような内容ではなかった。 そこで、RFC 1034, RFC 1035 を読みつつ*1、Ruby で自作してみることにした。 で、初版として作ったのが以下のプログラム。 require 'rubygems' require 'Net/DNS' require 'socket' sock = UDPSocket.new sock.bind('localhost', 10053)
9月30日の続き。 UTF-8 環境で w3m のメニュー表示が崩れる原因が分かった。俺は GNU screen を常用してるんだが、実はそちらが原因だった。(使っていることを忘れるくらいに使いまくってるため、screen 以外の環境でテストすることを思いつかなかった。間抜け過ぎる) 調べてみたところ、UTF-8 の East Asian Ambiguous Character Width に関してパッチ付きのバグ報告がされていた*1。このパッチを適用してみたところメニューの表示が崩れなくなり、とりあえず問題が解決したらしい。 ついでなので、Unicode の曖昧な文字幅問題に関して、各ソフトウェアでの対処法のまとめ。 w3m w3m-dev 4049 に投稿されている ambwidth パッチを使い、オプションで "Use double width for some Unicode ch
ふと思いついて、作業環境(Debian sarge)の文字コードを EUC-JP から UTF-8 へ移行することにした。Debian の次期 stable (etch) では UTF-8 が標準になるそうだし。 ほとんどのソフトウェアは locale の設定を変えるだけで問題なく移行できたんだが*1、PuTTY 上で起動した w3m で、罫線などの表示が崩れるという問題に遭遇した。 最初は PuTTY の問題かと思ったんだが、いろいろと調べた結果、問題の原因は、Unicode の Eastern Asian Ambiguous Character Width*2にあることが分かった。つまり、Unicode では罫線や一部の記号(☆とか□とか)の文字幅が曖昧であり、文脈に応じて半角(half-width)になったり全角(full-width)になったりするんだが、どうやら w3m ではこれ
このページを最初にブックマークしてみませんか?
『diary of a madman』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く