プログラミングGIMP

投稿者 akira 2010-08-15 13:22:00 GMT

自由研究にGIMPプログラミングをやってみた(2.6.10を使用)。夏休みはないけど。

GIMPを使って、複数の操作を順番に実行する必要のある、ある程度手間のかかる画像処理をしたいのだけど、手作業で繰り返すのはちょっと辛い。また、できればバッチ的にたくさんのファイルを処理したい。というわけで、ごく具体的な目的があってのチャレンジである。参考にしたのは以下。

GIMPでのプログラミングはScript-Fuと呼ばれていて、Schemeで書く。かっこを多用しなければならないのでついつい腰がひけてしまう。ただ、ここでやりたいのは操作手順を書き起こすことなので、webサービスを作るような場面でのプログラミングよりはずっと単純な内容で済む。「;」のかわりに「)」を書く、という程度の気持ちでもなんとかなる。はずだ。

Continue reading...

Railsで本当にやった○○な話

投稿者 akira 2010-03-01 02:57:00 GMT

そのいち。テストを書き加えるファイルを間違えたのに気付かず悩む。関係ないコントローラをテストしていたよ。

そのに。distinctを付け忘れる。やはり悩む。

C-0.06の15分間パッケージング

投稿者 akira 2009-11-12 13:06:00 GMT

C言語のワンライナーを書くためのCというツールがある、というのをついさっき知った。

普段C言語を何かを作るということはあまりなくて、C言語といえばどちらかというと読むもの。しかも部分的に。だから「あれ、どうだったかな?」なんていうのは――「;」忘れも欠かさない私にとってはよくあること。意外と使えるかもしれない。

こういうツールで迷うのはどこにインストールするか。ちょっと使ってみるだけになるかも、と思うと/usr/localを使うのは…… という気分になる。かといってホームディレクトリにポンと置いておくだけというのも。

まあ、本当のところは迷ってはいない。ちょこちょこっとパッケージングしてしまえばいいのだ。特にこういう小さくて、サーバ的でもないツールならパッケージ化の手間もたいしたことはない。

具体的な手順はこんなところ。

$ tar xf C-0.06.tar.gz
$ cd C-0.06
$ dh_make -c gpl2 -b -s -p large-c -f ../C-0.06.tar.gz
$ cd debian
$ rm README.* cron.d.ex emacsen-* init.d.* large-c.* manpage.* menu.ex post* pre*
$ vim copyright
$ vim control
$ mv watch.ex watch
$ vim watch
$ cd ..
$ debuild -uc -us

debian/copyrightやdebian/controlはREADMEなどからのコピー&ペーストで、debian/watchもURLを調整する程度。C-0.06のような構成ならdebian/rulesに手をいれる必要もない。

実際にはlintianエラーをつぶすためにdebuildをあと二回くらいは実行したものの、全工程で15分ほど。できたlarge-c_0.06-1_i386.debをインストールして作業を終えた。

$ C -cWall -cO2 -e 'printf("hello world\n")'
hello world

Typo 5.3がメモリを使い過ぎる

投稿者 akira 2009-06-28 09:28:00 GMT

二、三日前から時々oom-killerが出るようになった。なんでかなと見てみたらずいぶんと太ったTypoのプロセスサイズがいくつか。一つあたり500MBとか……。

今までなんともなかったのになと思ったものの、それほど考えてみれば気にしていなかっただけで、実はけっこう前からこういう状態だったのかもしれないということに気付いた。おおむね自分が困るだけとはいえ、ちょっとほったらかしすぎた。動きを見てみると、プロセスが生成されて少しして数秒かけてプロセスサイズが大きくなっていくことがわかった。どうやら何かを読み込んでいるように見える。

実はこのことに気付くほんの少し前のタイミングでPassengerのバージョンを変えたり、他のアプリケーションの配置を変えたり、GEM_HOMEを変えたりということをしている。そのため、まず疑ってしまったのはそのあたりだった。その次に疑ったのは自家製コードのいくつか。といってもTypoのためには数十行のコードを書いた程度で、特別に問題になりそうなものは見付からない。

動いているプロセスにコードをつっこんでオブジェクトの様子を見てみるかとも思い始めていたのだが、ここでscript/consoleでも同じ現象が出ていることに気付いた(遅い!)。そしてconfig/environment.rbを読み込み終えるまでにプロセスサイズが育っていることがわかった。printfデバッグで絞り込みをかけたところ、以下のコードにいたった。

if RAILS_ENV != 'test'
  begin
    ActiveRecord::Base.connection.select_all("select * from sessions")
  rescue
    begin
      ActiveRecord::Base.connection.current_database
      Migrator.migrate
    rescue
      # if there are no database, migrator doesn't no start
      # use case : rake db:create in rails tasks
    end
  end
end

このコードが加えられたのはこのあたり。これなら、とりあえずはlimit 1でも付けておけばよいだろうか。もっとやりようがありそうなものではあるが。

結局、問題が顕在化したのは保存しているセッションの数が多くなってきたからであった。実に602,788レコードもある。セッションデータの掃除は今でも(Typo 5.3ではRails 2.2を使っているが)手作業でやるのかな? (セッションだからdelete_allで十分かしら?)

$ script/runner -e production 'CGI::Session::ActiveRecordStore::Session.destroy_all(["updated_at

追記

問題として報告しておいたところgithub上のリポジトリでは引用したブロックはコメントアウトされたようだ。5.3.1では直っているのかな。なんだか他のチケットも動き出したので、ちょうどそんなタイミングだったらしい。