〜2003年1月中旬〜
1/7に入手したccacheをインストール。 symlink経由でしかも-cだとSEGVになる。-oまでつければok。
% cp ccache gcc
% echo 'main(){}' >x.c
% ./gcc -c x.c
zsh: segmentation fault ./gcc -c x.c
% ./gcc -c x.c -o x.o
%
あ、ccache経由でも同じか。
% ./ccache gcc -c x.c
zsh: segmentation fault ./ccache gcc -c x.c
% gdb ccache
...
(gdb) run gcc -c x.c
Program received signal SIGSEGV, Segmentation fault.
0x0804a0a8 in process_args (argc=3, argv=0xbffff8a8) at ccache.c:741
741 if (strcmp(output_file, "-") == 0) {
(gdb) p output_file
$1 = 0x0
というわけで原因が判明。この部分が2.0で追加されたからだな。
if (outputfile && strcmp(output_file, "-") == 0) {
としとこう。 てゆか、こんな単純なバグはすでに直ってる気がするから見に行ってみると、 もうとっくに2.1.1になっていた。ぐはぁ。
vrubyのtests/sample.rbを使って Win32API.rbをテストしてみると、いきなり
./Win32API.rb:10:in `initialize': dlsym: Win32 error 127 (RuntimeError)
from ./Win32API.rb:10:in `new'
from ./Win32API.rb:10:in `initialize'
from /usr/local/lib/ruby/site_ruby/1.8/vr/sysmod.rb:150:in `new'
from /usr/local/lib/ruby/site_ruby/1.8/vr/sysmod.rb:150
from /usr/local/lib/ruby/site_ruby/1.8/vr/vrcontrol.rb:14:in `require'
from /usr/local/lib/ruby/site_ruby/1.8/vr/vrcontrol.rb:14
from sample.rb:2:in `require'
from sample.rb:2
を喰らう。どうもCygwinのdlsymがなんかまずいらしい。 127は
% /c/winnt/system32/net helpmsg 127 The specified procedure could not be found.
だからやはりdlsym()だよね。でもWin32API.rbの10行目は
handle = DLL[dllname] ||= DL::Handle.new(dllname)
だからまだdlsym()に辿りついてないはずだ。 ということはdlerror()自体なにか変だ。 ext/dl/handle.cでは
ptr = dlopen(clib, cflag);
#if defined(HAVE_DLERROR)
if( (err = dlerror()) ){
rb_raise(rb_eRuntimeError, err);
}
#else
if( !ptr ){
err = dlerror();
rb_raise(rb_eRuntimeError, err);
}
#endif
となっていて、HAVE_DLERRORは存在するので定義されている。 ということはdlopen()が成功してもその状態をクリアしていない可能性がある。 dlsym()は"A"のあるなしで失敗することもあるから、 以前に一度でも失敗するとまずそうだ。 試しに#else側を活かしてみる。うまくいった。
dlsym()が0を返したらdlerror()を見る必要はあるが、 dlopen()が0を返したら絶対に失敗だからdlerror()を見る必要はない。 表示するときは必要だけど。
handle.cを見てたら"A"の処理も入ってたのか。 Win32API.rbでやる必要はないな。
なぜuconv 0.4.11に上げないかというと この理由によりアップデート不要だからです。実際 uconv 0.4.10は--enable-win32apiつきでextconf.rbを実行してます。
ruby-talkの流量が急に増えた。news gatewayが3日ほど止まっていたようだ。
更新。
更新。
User Modeを試すがまだだめだ。
arch/um/kernel/ptrace.c:12: linux/proc_mm.h: No such file or directory
2.5では一度もmakeに成功したためしがない。途中で気になるメッセージがあった。
arch/um/include/uml-config.h:58: warning: `CONFIG_UNIX98_PTY_COUNT' redefined /usr/include/linux/autoconf.h:534: warning: this is the location of the previous definition
なぜ/usr/include/linuxを見てるんだろう？
更新。version番号のつけかたがBisonだけ独特なのがちょっと気になる。
うむ。かなり恥ずかしいバグだ。
更新。
更新。あ、適当にMakefileを作ったが、dpklibがないのか。消しとこう。
これだけgotoだらけになるなら、 not_found, load_dyna, load_rbあたりを関数にしたほうがよさそうだ。
更新。
というわけで更新。
27KBあるけど通ってるねえ。 これを通さないってわけにはいかないとは思うけど、 そんな柔軟な判断ができるとは思えないし。 それとも32KBになったんだろうか？
ってあまり乗り気じゃないんだけど、でもあったら使うかなあ。 やはりruby mode次第かも。
といいつつもこんなのを考えてみたり。
class String
def heredoc(bar = nil)
case bar
when String
reg = /^\s*#{Regexp.quote(bar)}/
when Integer
reg = /^\s{#{bar}}/
else
reg = /^\s{#{self.index(/[\S\n]/)}}/
end
gsub(reg, '')
end
end
if __FILE__ == $0
print <<-EOS.heredoc('|')
|Hello
| Hello
| Hello
EOS
print <<-EOS.heredoc(4)
Hello
Hello
Hello
EOS
print <<-EOS.heredoc
Hello
Hello
Hello
EOS
end
man bashして<<-を検索してみると
リダイレクション演算子が <<- ならば、行頭にあるタブ文字 は 全 て入力行および delimiter を含む行から取り除かれます。こ れにより、シェルスクリプト中のヒアドキュメントを自然な形で インデントさせることができます。
とある。使えるのはタブだけなんだよね。
% printf "cat <<-EOS\n\tHello\n\tEOS\n" |bash Hello % printf "cat <<-EOS\n Hello\n EOS\n" |bash Hello EOS
しまったなあ。確認が全然足りなかった。考えなおそう。
print <<'EOS'
hoge
EOS
while line = DATA.gets
print "%s = %s\n" % line.chomp.split(',')
end
__END__
foo,2
bar,1
のようなスクリプトをERBで書き直してみたら、 erbも erubyも__END__をサポートしてないことに気づいた。 ま、それも当然か。
unless defined? DATA
DATA = open($0)
DATA.gets("__END__\n")
end
でお茶を濁そうと思ったが、 __END__以降も普通の文字として処理されることには変わりなし。 それ以前に$0には"/usr/local/bin/erb"が入ってた。 erubyも"eruby"が入ってる。 スクリプト名にして欲しいな。あ、でもそうするにはerbのほうは $0問題が浮上するか。実は設定するだけなら
% irb irb(main):001:0> $0 => "irb" irb(main):002:0> $0 = "012345" => "012345" irb(main):003:0> $0 => "0123" irb(main):004:0> $0.replace "012345" => "012345" irb(main):005:0> $0 => "012345"
のようにString#replaceを使うという方法もないこともないんだけど。
<%# __END__ foo,2 bar,1 %>
として%>を無視するようにすればだいたい期待通りだが、 そこまでして__END__を使いたいわけでもない。
なぜかerubyよりもerbのほうが速い。ldd =erubyしてみると1.7.3がリンクされてた。 1.8と1.7の起動時間を計ってみよう。
% time ruby -v ruby 1.8.0 (2003-01-18) [i386-linux] ruby -v 0.12s user 0.02s system 115% cpu 0.121 total % time ruby-1.7.3 -v ruby 1.7.3 (2002-12-20) [i386-linux] ruby-1.7.3 -v 0.46s user 0.03s system 101% cpu 0.483 total
やはり最近速くなったようだ。
% time ruby-1.6.8 -v ruby 1.6.8 (2003-01-17) [i586-linux] ruby-1.6.8 -v 0.41s user 0.03s system 104% cpu 0.421 total
なので、1.8だけだ。 ま、このくらいの違いは非常に遅いマシンでないと体感できないと思うけど。
一体どの変更が効いたのか調べてみよう。 まずは2003-01-10あたりから。
% cvs -d /src co -D2003-01-10 -dtmp ruby % cd tmp % autoconf-2.57 % cp ../linux/config.cache . % ./configure --enable-shared --cache=config.cache % make miniruby % time ./miniruby -v
まだ2003-01-10は遅かった。 本当にここ一週間ぐらいの変更ということになる。 ChangeLogを見ると
Mon Jan 13 20:45:19 2003 Guy Decoux <ts@moulon.inra.fr>
* parse.y (list_append): avoid O(n) search using node->nd_next->nd_end.
* parse.y (list_append): ditto.
* eval.c (rb_eval): NODE_ARRY nd_end adoption.
これしかない。このchange setを戻してみると確かに遅くなる。 でもlist_append()って-vには何も関係ないよね？ これが速くなった原因とは思えない。 とするとeval.cのほうか？ eval.cを見てみるとruby_runningという変数が増えてる。 ruby_runningが0のときはcacheをいじらなくなったようだ。これか。 試しにruby_runningを常に1にしてみたら、やはり遅くなった。なるほど。
気づいてみるとbig@boss.comから8個来てる。 見た感じ添付ファイルを実行しない限り動かないタイプだけど、 だからなぜサルのようにクリックする？
EVECTRAというホストからは2個来てる。 その間2日空いている。感染にまだ気づいてないのか？
田中麗奈ってやっぱ田中麗奈にちょっと似てるあたりが田中麗奈なんだなと思ったり。 てゆか藤本美貴は別人だ。
いつのまにかgcc -sharedですべてのsymbolをexportしてることに気づいた。
% echo 'foo(){}' >foo.c
% i686-pc-cygwin-gcc -shared foo.c -o foo.dll
% ruby impgen.rb foo.dll
EXPORTS
foo