http://rubycocoa.sourceforge.net/EmbedRubyCocoa の

require 'pathname'
exec = File.join(ENV['TARGET_BUILD_DIR'], ENV['EXECUTABLE_PATH'])
old = Pathname.new('/usr/lib/libruby.1.dylib').realpath
new = '@executable_path/../Resources/libruby.1.dylib'
system("install_name_tool -change '#{old}' '#{new}' '#{exec}'") or exit 1

ってうまくいかないようなきがする。Contents/MacOS/APPNAME は otool -L すると libruby にリンクしてなくて、@executable_path/../Frameworks/RubyCocoa.framework/Versions/A/RubyCocoa にリンクしてるし、実際 libruby にリンクしてるのはこっちのほう。install_name_tool の挙動を勘違いしていなければ、たんにこれは指定されたファイルの Mach-O dylib のパスを書きかえるだけだろうから、これだと意図したこと (バンドル内の libruby よむ) ようにならない?

Chemr とかでは結局 standalonefy してあつめられる .bundle とかの libruby.1.dylib へのリンクも一緒に書きかえるようにしてみた。

# in 'package' task
	# copy libruby.1.dylib
	sh %{rubycocoa standaloneify "build/#{DEFAULT_CONFIGURATION}/#{APPNAME}.app" "image/#{APPNAME}.app"}
	system_libruby = Pathname.new("/usr/lib/libruby.1.dylib").realpath
	bundle_libruby = "image/#{APPNAME}.app/Contents/Resources/libruby.1.dylib"
	linked_binary  = "image/#{APPNAME}.app/Contents/Frameworks/RubyCocoa.framework/Versions/A/RubyCocoa"
	(Pathname.glob("image/**/*.{bundle,dylib}") + [linked_binary]).each do |l|
		sh %{install_name_tool -change '#{system_libruby}' '@executable_path/../Resources/libruby.1.dylib' '#{l}'}
	end
	cp system_libruby, bundle_libruby

sudo mv /usr/lib/libruby.1.dylib /usr/lib/libruby.1.dylib_  

して起動することを確認してみた。

(たぶん) 完全にスタンドアロンな Chemr と Amalgam

• http://lab.lowreal.net/test/amalgam/Amalgam.2007-11-04.dmg
• http://lab.lowreal.net/test/chemr/Chemr.2007-11-04.dmg

使わないときにも実行されるのが嫌

GM で書いたほうがはやく書けるけど、日常的におもくなってストレスたまるほうがいやだな。

GranParadiso はそれでなくても重いし!!!!! というか Safari の UI を RubyCocoa で InputManager とかつかって変更できるなら乗りかえちゃうなとか思った。

>

CPU つかいすぎだなぁ……あとなんかフォアグラウンドにいるときはより CPU を食う。ActivityMonitor のグラフがやたらのびてるなぁとおもってそっちにスイッチすると隠れようとする。

関係ないけど pmTool も CPU 食いまくるよなぁ。そのせいでバッテリ持たないっていうのはどうなの。

Firebug1.1.0b7 を入れた。うごいている。しかしいままで以上に重い。GranParadiso の重さと相乗効果

はてなのマルチログイン uc.js がないと激しく不便なのでデバッグして Fx3 向けに修正した。tumblr のやつも同じ修正が必要だけど、あんま使ってないのでそのうちでいいや。

http://coderepos.org/share/changeset/1051

とりあえず module/pluggable を使っていたものの、別にリロードとかできなくていい (CGI なので使い捨て) ので、もっと簡単なプラグインシステムにした。ついでに rubygems への依存もなくなったので、純粋に Ruby がインストールされていればレポジトリからチェックアウトしてすぐ動くようになった。

# プラグインファイルをロードして
# インスタンスの配列を実行すべき順にソートして返す
def load_plugins
	Pathname.glob(@opts[:plugin_dir] + "/**/*.rb") do |f|
		load f
	end
	pm = self.class.const_get(:Plugin)
	pm.constants.inject([]) {|r,i|
		r << pm.const_get(i).new(self)
	}.sort_by {|i|
		i.priority
	}
end

みたいにして Ekfloras::Plugin::* をプラグインとみなし、メソッドをよぶ。かなり簡単だけど普通は十分なプラグイン機構だと思う。(ファイル名とクラス名間の名前の制約がなくなるので、てきとーにプラグインんが書けるようになる。逆にこれのせいでリロードとかが実装できない) こんだけ単純だと特にライブラリする必要もないので欲しくなったときに書きなぐればいいのがいい。

(priority メソッドの返り値でソートしているのは、プラグイン同士で実行順に気をつかうようにするため。blosxom だと名前順になっているから、各ユーザがプラグインの仕組みを理解してファイル名を書きかえたりしないといけなかったけど、これでだいたいてきとーにプラグインディレクトリにほうりこんでも動くようになるはず)

ちゃんとインスタンス化してメソッドをよぶようになるので、各プラグイン内のメソッドの名前がコンフリクトしたり、データが共有されることがなくていい。ちゃんとメソッド間ではデータ共有できるし (こんなのあたりまえなんだけど、Ruby 系のプラグイン機構ってこういうあたりまえのことができないのが多いイメージ)

あとは設定かな。設定はできるだけ書きたくないから (blosxom のプラグインのいいところは投げこめば動くことだと思う)、最小設定と、オプションをいくつかとかになるかな。

1. #<Ekfloras::Plugin::Meta:0xb7bcc03c>
2. #<Ekfloras::Plugin::Paging:0xb7bcbfec>
3. #<Ekfloras::Plugin::Comment:0xb7bcc014>

(EntriesCache なし)

ruby 1.8.4
1159 files, 1.212316 sec
1159 files, 1.722761 sec
1159 files, 1.390812 sec
1159 files, 1.353448 sec
1159 files, 1.423345 sec

ruby 1.9.0 (2007-09-24 patchlevel 0) [i686-linux]
1159 files, 1.025227 sec
1159 files, 1.075664 sec
1159 files, 1.202309 sec
1159 files, 1.300395 sec
1159 files, 1.284752 sec

1. #<Ekfloras::Plugin::EntriesCache:0xb7c08ae8>

ruby 1.8.4
1159 files, 0.733907 sec
1159 files, 1.166876 sec
1159 files, 1.437776 sec
1159 files, 0.857321 sec
1159 files, 0.906379 sec

ruby 1.9.0 (2007-09-24 patchlevel 0) [i686-linux]
1159 files, 0.315943 sec
1159 files, 0.301194 sec
1159 files, 0.446674 sec
1159 files, 0.254224 sec
1159 files, 0.45789 sec

EntriesCache (エントリをオブジェクト化した状態でマーシャライズしてキャッシュするプラグイン) 入れた ruby1.9 がかなりはやい。

http://coderepos.org/share/browser/lang/ruby/ekfloras

Ruby で blosxom クローンを書いてみた。他の言語と違って blosxom のプラグインの雰囲気をのこしたり、まじめに使うことをちょっと考えたりするように。

テンプレートエンジンに ERB と Erubis どっちもサポートしようとおもって書いていたけど、途中でテンプレートが Erubis 専用になってしまっていることに気付いてめんどくなったのでどっちもやめて (イミフ) 前書いた MiniERB をつかうようにした。(空白圧縮とかしないけど ERB の 2.5 倍ぐらいはやい)

いまどきブログ CGI なんて書いてもだれもつかわないんだけどなぁ。ふつうにどっかのサービスつかったほうがいい。でも blosxom 系のはブログつーるというより他の使いかたをしやすいからおもしろい。

最近の、であって、僕が書いた、じゃないですよ? (coderepos にあるもののみ)

• Ruby - ekfloras - http://coderepos.org/share/browser/lang/ruby/ekfloras
• Scheme - bloscheme - http://coderepos.org/share/browser/lang/scheme/bloscheme
• Io - IoBlosxom - http://coderepos.org/share/browser/lang/io/ioblosxom
• Zsh - blosxom.zsh - http://coderepos.org/share/browser/lang/shellscript/blosxom.zsh
• Vim - blosxom.vim.cgi - http://coderepos.org/share/browser/lang/vim/blosxom.vim.cgi

(使えそうな順にならんでます)

Lua は付属インタプリタでは実装できない。PHP と Python はやりたいと思わない。VBScript は Windows で CGI 環境つくるのがめんどうくさい。

Haskell と C# (on mono) あたりはやってみたいけど、ここで「やってみたい」とか書いている限りやらないだろう。本当にやってみたいなら既にやっているはずだ。