Powered by twtr2src
前回 OSC Tokyo 2010 Spring(だったけ?)に参加した時に思ったのは、「コミュニティの展示ブースのレイアウトがひどい」だった。
確かに場所の確保が大変なのは分かるし、主催者の方も工夫してくれているんだろうけど、それにしても来場者に背中を向けてる展示ってのはいかがなものかと。
んで、今度来週末にあるOSC 2010 Tokyo Fall（だったけ?)の出展ブースのレイアウト案というのを見せてもらったんだけど、レイアウトについては変更できない、ということになっているらしい。
ちなみにもらったレイアウト案だとこんな感じ。(*自分でOOoで書いた絵)
(長机が水色と灰色で、オレンジの椅子は参考に書いてみた)
確かに通路を確保しようとするとこうなるんだろうし、コミュニティの展示ブースでも机より中側に人を入れようすると背中合わせの部分にスペースが余計に必要になるから、通路が確保できなくなるのは分かる。
でもそれではなんら改善できていないので、それじゃあこんなのはどうかと思って書いてみた。
展示ブースの中側はぎりぎりの幅を取って、人の出入りように縦方向3列並びの机のどこか1箇所に人が通れるだけの隙間をあける＝通路が最初と同じだけ確保できる、という感じ。
まあこっちの方が机が通路に近くなるので圧迫感がでてくる感じがあるけど、展示としては多少は好ましいんじゃないかなとも思う。
あと、いっそのこと展示ブースの内側のイスは無くしちゃって、基本は立って展示する、休憩するときは外の休憩ブースに行く、というスタンスもありかも知れない。
とは言え、実は過去に試してみた結果、やっぱり良くなかったから今のレイアウトに落ち着いている、なんて話かも知れないので正直悩ましいんだろうけど、でもなんとかしてもらえないもんかなぁ……。
Powered by twtr2src
Debianのバグレポート(Bug#588125)によると、こんな具合いになることがわかった。
$ gem1.9.1 list /usr/lib/ruby/1.9.1/rubygems/source_index.rb:68:in `installed_spec_directories': undefined method `path' for Gem:Module (NoMethodError)
Ruby 1.9.2とRubyGems 1.3.7の組み合わせで、どちらもパッケージを利用している。RubyGemsのコードは、この場合、Ruby 1.9.2に含まれているものではなく、RubyGems 1.3.7からのものが使われている。Gem.pathがないっていうのはなかなか興味深いことだなあとちょっと調べてみた。
$ ruby1.$ ruby1.9.1 -ve 'p Gem.path' ruby 1.9.2dev (2010-07-30) [i486-linux] ["/home/akira/.gem/ruby/1.9.1", "/usr/lib/ruby/gems/1.9.1"]
特に問題ない。次。
$ ruby1.9.1 -e 'require "rubygems"; p Gem.path' /usr/lib/ruby/1.9.1/rubygems/source_index.rb:68:in `installed_spec_directories': undefined method `path' for Gem:Module (NoMethodError) [...]
おや。
$ ruby1.9.1 -e 'require "rubygems"' /usr/lib/ruby/1.9.1/rubygems/source_index.rb:68:in `installed_spec_directories': undefined method `path' for Gem:Module (NoMethodError) [...] from /usr/lib/ruby/1.9.1/rubygems.rb:839:in `searcher' from /usr/lib/ruby/1.9.1/rubygems.rb:478:in `find_files' from /usr/lib/ruby/1.9.1/rubygems.rb:982:in `load_plugins' from /usr/lib/ruby/1.9.1/rubygems.rb:1138:in `<top>' from <internal:lib/rubygems/custom_require>:29:in `require' from <internal:lib/rubygems/custom_require>:29:in `require' from -e:1:in `<main>'
おやおや。
$ ruby1.9.1 -e 'p Gem.path; begin; require "not exist"; rescue LoadError; end; require "rubygems"; p Gem.path' ["/home/akira/.gem/ruby/1.9.1", "/usr/lib/ruby/gems/1.9.1"] ["/home/akira/.gem/ruby/1.9.1", "/var/lib/gems/1.9.1"]
おやおやおや。
ある状況でGem.pathが消えてしまうらしいことがわかった。このあたりでRuby 1.9.2に入っているRubyGemsと単体で配布されているものとのdiffをとったりもして、どうやらこういうことらしいとわかった。
$ ruby1.9.1 -e 'p Gem.path; Gem::QuickLoader.remove; require "rubygems"; p Gem.path' ["/home/akira/.gem/ruby/1.9.1", "/usr/lib/ruby/gems/1.9.1"] ["/home/akira/.gem/ruby/1.9.1", "/var/lib/gems/1.9.1"]
回避策としてはとりあえずはこれでいい。ただ、どうしてこういう結果になるのかを把握するまでには、ここからさらにけっこうな時間がかかった。-d付きで実行したりデバッガ使ったり。printfデバッグしているつもりが表示内容がまずかったせいで別の例外を起こしているのにしばらく気付かなかったり。
ようやくわかったところによると、こういう流れがあるようだ。
まず「require 'rubygems'」がどこかで(たとえばgemコマンドの中で)行われてrubygems.rbが読み込まれる。このrubygems.rbはRubyGems 1.3.7由来のものである。
rubygems.rbは内部で「require 'rubygems/defaults/operating_system'」としているのだが、このoperating_systemというのはシステム上にない(*)。ここでRuby 1.9.2の「require」はRubyGemsが置き換えた後のものであることを思い出す。したがってrubygems/defaults/operating_system.rb(や.so)がなければ、RubyGemsの機構を使ってこれを救済できないか試みられる。
ところで、今問題にしている環境では、RubyGemsはRubyGems 1.3.7由来であり、Ruby 1.9.2に含まれるものではなかった。しかしながら、この時点で動作している「require」はRuby 1.9.2に含まれるRubyGemsに由来するものなのである。これはRubyインタプリタが内部に持っているgem_preludeの中にあって、$LOAD_PATH上にあるrubygems/custom_require.rb(=RubyGems 1.3.7由来)のそれとは動作が異なる。
ではそれによって何が起こるのかというとGem.try_activateが呼び出される。その実体はGem::QuickLoader.try_activateであり、これもRuby 1.9.2に由来する。このコードはGem::QuickLoader.load_full_rubygems_libraryを呼び出し、その先でGem::QuickLoader.removeが呼び出される。そうしてgem_preludeに由来するGem関係の何もかもを忘れ去ろうとする。
module QuickLoader
@loaded_full_rubygems_library = false
def self.remove
return if @loaded_full_rubygems_library
@loaded_full_rubygems_library = true
class << Gem
undef_method(*Gem::GEM_PRELUDE_METHODS)
end
remove_method :const_missing
remove_method :method_missing
Kernel.module_eval do
undef_method :gem if method_defined? :gem
end
end
[...]
end
さて、このremove、そもそもどうして呼び出されたのかというと「require "rubygems"」がきっかけとなって内部的に行われた「require "rubygems"」による。removeは、本来のRubyGemsがロードされるべき場面で使用されるはずのものであるが、この状況ではすでにrubygems.rb(RubyGems 1.3.7由来)が読み込まれてしまっている。したがって、removeした後で行われるに違いないと思われていたGem以下の再定義はなされない。
そうしてGem.pathがなくなってしまう。
この問題はRuby 1.9.2だけで構成されていれば起きることはない。というのも、Ruby 1.9.2に含まれるrubygems.rbは、その先頭で次のようなことをしている。
gem_disabled = !defined? Gem unless gem_disabled # Nuke the Quickloader stuff Gem::QuickLoader.remove end
この記述はRubyGems 1.3.7に含まれるrubygems.rbにはない。
Ruby 1.9.2だけから構成されていれば、上のストーリーの最初の「require 'rubygems'」の時点でgem_preludeに由来するコードは消し去さられ、フルセットのRubyGemsが読み込まれことになる。また、RubyGems 1.3.7に由来するrubygems.rbの先頭に同じ記述を加えた場合、同じように最初の「require 'rubygems'」の時点でgem_preludeに由来するコードは消し去られる。
いずれのケースでも、問題の発端となる「require 'rubygems/defaults/operating_system'」の時点で動作するのはgem_preludeに由来する「require」であるのに変わりはないが、removeの効果は一度だけしか現れない(@loaded_full_rubygems_library)ためGem.path消失問題が起きることはない。
(*) なお、operating_systemがシステム上にないのは特に問題ない。以下のようにLoadErrorをrescueしていて、そのファイルがなければなくても構わないというコードになっている。
begin # Defaults the operating system (or packager) wants to provide for RubyGems. require 'rubygems/defaults/operating_system' rescue LoadError end
この話とは直接的には関係ないけれど、今回の調査をしている中でRuby 1.9.2の-dオプションが地味に便利になっていることに気付いた。
$ ruby1.9.1 -d -e 'require "rubygems"' [...] /usr/lib/ruby/1.9.1/rubygems.rb:630: warning: method redefined; discarding old path <internal:gem_prelude>:43: warning: previous definition of path was here [...] <internal:lib/rubygems/custom_require>:29: warning: loading in progress, circular require considered harmful - /usr/lib/ruby/1.9.1/rubygems.rb [...]
大変ありがたいことに今年もRuby会議の動画配信があったのでこの三日間はそれなりに時間をとって見るようにした。以下は雑他なメモなど。主に自分向け。
前田さんの。[録画]
オープンクラスの後から定義をいじれる(メソッドを再定義できるなど)という点に、その影響の範囲を限定する仕組みを加える提案。面白いというかほしい。クラスボックス――と呼ばれていたが、実はクラスボックスとは違うものだったらしいという話がキーノートでちらっと出ていた。何て呼べば? で、たとえばこういう例。
class X def foo; puts "X"; end end module A def foo; print "A -> "; super; end end module B def foo; print "B -> "; super; end end module C overlay_module X, A overlay_module X, B X.new.foo # 「B -> A -> X」と表示される end
このようなoverlay_moduleを実装し、それを使って(ここでいうところの)classboxを実装している。わずか47行だとか。(必要となるcaller bindingも別に実装。)ネストしたメソッド定義の仕組みについて、定義されるメソッドの有効範囲をネストの内側だけに限定するよう改良。test-allにパス!
stdioまわりの話。知識としては持っているはずなのに、へー、ほーと思ってしまう。話をきくと一つのメソッドが配慮のかたまりだということがよく分かる。まあ、こうして、いつの間にかダメになっていくんだなあと。後半急ぎ足になったけどそちらも興味深そうであった。結局、というのもなんだが、デザインの話になっていく。重要なんだ。
Unix使っていると、こういったstdioだとか、あと端末だとか、そういうところに何度か戻ってくることがあるように思う。だんだん理解の深さが変わっていったり、あるいは角度が変わっていたりする。がっちりきっちり理解していないと困る、といわけでも実際にはない。「こういうものだから」という態度でなんとかやりくりすることも少なくなくて、その辺はコストのかけ方のバランスではあるのだけど。まあ、ちょっと離れているとかんどころを忘れちゃってたりするし。
まつもとさん。[録画]
メソッドをコピーするmixの提案。あれば欲しそうなな。難しい点、要検討が必要な点もあるようだけど。
でもこれが入るとincludeと混ぜるなキケンっぽい。あるいは単に混ぜられないか。(質疑のやり取りかすると後者っぽいかな。)で、そうなると移行期にはinclude用とmix用、それぞれにライブラリができてしまってそれらは混ぜるなキケン、てなことにならないのかな? と思った。どうもmix導入するなら移行をすすめたい感じだったのだけど、ホントにincludeはいらなくなるのだろうか。質疑では定数用名前空間としてmoduleを用いるケースについてmixだけではめんどうなんじゃないか、という点が指摘されていたが、それだけってこともないような気がする。
名前空間といえば、今のRubyでmoduleが名前空間のように使われているがあれがイヤだという意見もあった。高井さん? かな。時間がかかりそうなので後でどこかで、ってなっていたけど、普段気にしたこともないようなところだったのでどういう話だったのかが気になる。こういうのは現場にいないとなかなか興味を満たすことができないんだな。っていうか、気になったらことはその日のうちにつかまえるくらいの気持ちで行かないとってことか。
黒魔法の話。[録画]
かと思ったけど、そうでもなかったみたい。このあたりで作業しながらだったので後半あまり見られていないのだけど。
見てた範囲でいうと、メタプログラミングをやったことないよっていう人や、Railsのコードを読んでみようかなっていう人によさそうな内容。助走にちょうどよい感じ。基本的なところから丁寧に説明があるようだった。そのまま雑誌記事とかになるとうれしそうな。と思ったが、本が出てるんだった。本の中ではどこから始まって、どういうつっこみ方をしているのだろうか。というわけで
メタプログラミングRuby[amazon]は近いうちに買おう。(すでに品薄みたいだ。)
messagepack/messagepack-rpc @frsyuki - 単純に面白い。便利そう。気にはなっていたんだけど〜というプロダクトの一つで、だけどもついこのあいだkumofs経由で触れたくらいで、という感じだった。標準添付にできれば! という話も出ていて、たしかにそうなるとうれしそう。でもリリース間隔が短い感じがするので、標準添付になるとそのあたりのスピード感の違いがどうなるか。 [プレゼン資料]
babushka @ben_h - 早口でちょっとわからなかったけどキーワードだけでも気になる。test-driven sysadmin for rubyists。後で調べてみたところ、システムの状態を調査しながら定められた管理作業を行ようなツールのようだった。test-drivenというのは状態の調査結果に応じてっていうあたりなのだろうか。まだ読み切れていないのだけど、バラツキのある状態でのセットアップなんかには便利なのかも。変な例だけどハンズオンでセットアップ〜な場面とか。なかなか面白そうなので後で少し動かしてみようかと。babushka.meにデモビデオがある。コードはgithub。
ReVIEW @takahashim - ReVIEW自体には興味があることはあるが手を出すところまでは。LT本題のほうにも関心をもちかけたのだが、会社の業務としてやってくっていう話だそうなので、まあ、品質とかそういった面で恩恵?を受けられるのかな? というところ。とちぎで森田さんとしゃべったあたりのことが今でも欲しいなあと思ってはいるんだよな。
Lingo @KazkiMatz - デモに期待してたのだけど時間切れで残念。 開発者さんのblogに発表資料やデモビデオがあるので後でそれを見た。ビデオがあるので後でそれを見た。やっぱり自分で使って試してみたい。が、これサービスとして提供されるんだろうかしら。もしそうなら情報の取り扱いがどうなるが気になる。lingo-proj.com
VIMのほうで発表していた人がyokohama.vimを開催するのだとか。これ→Yokohama.vim #0。VIM使いではぜんぜんないのだけどちょっと行ってみようかしら。見てるだけになりそうだけど。
VIMのためのスーパー補完システムってことでいいのかな? 資料とコード。なんかすごそう。Ruby向けで機能が不十分なところがあるそうで、なんとかなんないかなあという話も。これも試してみないとな。
RICOHの方による発表。[録画] @suzumura_ss
quanpで使っている分散ストレージシステムCastoroの紹介。事前にコードをながめた人によるとNFSで何かやってるっぽいね? という話があったのだけど、要するにAPI的なものの他にファイルシステムからのアクセスが可能になっているということのようだった。これはこれでうれしい場面はたしかにありそう。(もちろんquanpには必要な機能だったわけだし。)遅延レプリケーションをするために最初のpeerにはRAIDが必要になる。この遅延具合いを調整することはできるのかしら。できるのならアプリケーション側で待つとかも可能なのかなと。まあ、それはそれでどうなんだってことかも。
Castoroがあきらめたものの一つにidの一意性というようなのが挙げられていたけど、ちょっとよくわからなかった。ストレージ上でidが重複するってどういう状況なのかな? アプリケーションが正しいidを知っていれば大丈夫っていう話だったが。
あとpeerからgatewayにmulticastしてたのはgatewayが複数いるからなのかな? オンエアではプロセス構造を再確認できなかったのでちょっとわからなかった。……ので確認したところ、複数いるようだ。clientはgateway〇ちの中からどうやって自分のgatewayを選ぶのだろう(ここはmulticastじゃなかったような…… どうだっけ?)。という意味では設定関係がどうなっているのか気になってくる。peer追加とか。
資料を見返すなり、コードを見るなり、かな。
いやおもしろかった。全文検索で使った自前のストーレージシステムというのが、OODBを昇華させたものということで、かなり気になる。すでに出てるやつ、ではないのだよね? きっと。
ささださんのところの学生さん。[録画]
リアルタイムに計測結果を見られるのはすごくわかりやすい。ただ動かすためにはRuby本体にパッチが必要ということで、すぐにどうこうということではなさそう。1.9.3に入るといいなーという感じのようなので期待。とりあえず今の段階でのコードをgithubに上げてくれという意見。コードが出てきたら試してみたいかな。
三日目の日曜はさすがに動画を見るのに目が疲れてきてしまって後で見るモードに。ぐるんがー[録画]は見ておかなきゃ。試しておきたいものもいくつか。忘れないうちに。いきおいがなくならないうちに。
中継のなかった部屋がいくつもある。まあ全部は無理だろうし、一部でもあるだけありがたい。ただまあそうなるとやはり現場へって感じだが、うーん、チケットを買う時点でどれくらい内容がわかってるんだっけ? COOKPADのんとか盛り上がっていたようだなあ。
Powered by twtr2src
Powered by twtr2src
http://mail.gnome.gr.jp/ml/gnome-translation/201008/msg00031.htmlそんなんできるんですか。$ msgunfmt --help使用法: msgunfmt [オプション] [ファイル]...バイナリメッセージカタログを Uniforum 形式の .po ファイルに変換....$ msgcat --help使用法: msgcat [オプション] [入力ファイル]...指定された PO ファイルを連結し、マージします.2..
仕事にケリがついていないのに強引に休んで今日だけRubyKaigi2010に参加してきた。
準備万端整えたつもりだったが途中で糊を持ってくるのを忘れたことに気づいた。せっかく名札ジェネレータで印刷して切って準備した名札が使えないじゃないか、というわけで、北千住の駅にあったファミリーマートでスティックのりをゲット。
つくばエキスプレスはJRじゃないということを今日はじめて知った。
つくば駅についたのは11:15。時間が余り過ぎなので、駅の近くのショッピングモールに入ってフードコートでとんこつラーメンを食べた。
つくば駅から結構歩いて（暑かった）国際会議場でチェックイン。受付でチケットを見せたらスポンサーは別の担当者のところへ回されて青い名札をもらった。ええー、赤がよかったなあ、Rubyなんだから…
早速作業台へ行き、紙を貼り付けて名札を作成。糊は寄付した。みんな使ってくれただろうか。
フォントはもちろんVLゴシック。裏はみかちゃんだけど。
他にもノベルティをいただきました。
なぜか手ぬぐい。後ほど角谷さんがこれをカッコよく頭に巻いている姿を目撃することになる。
トートバッグ。一澤信三郎帆布のトートバッグで馳せ参じたオレ涙目（わら
そしてiPhoneで無線LANに接続。準備完了。さて充電でもしておくかと思ってユニバーサルドックのケーブルを取り出したら、先端にコンセントが付いていなかったのであった…充電できないじゃん…大失敗…
あとで電器店を探すことにしてとりあえず大ホールへ移動。
実行委員長の高橋さんの開会宣言に続いて角谷さんの注意事項説明。全部日本語だったが@lchinさんが頑張って翻訳していた。@lchinさんはその後も大ホールの翻訳担当として頑張っておられました。
ゴミは全部持ち帰りましょう。
Jeremy Kemperさんは来れなかったがその代わりに別のRailsコミッタ2人とまつもとゆきひろさんと松田さんと実行委員長の高橋さんと@lchinさんとのRails3の開発秘話的なセッション。たこ焼き仮面ことAaron PattersonさんはRubyとRails両方のコミット権を持っている。パッチとテストを大量に投稿し続けたら面倒臭がってコミット権をくれたらしい。どれだけ投稿したんだ。
AaronさんはRubyの開発は日本語メインなので英語が母国語の人にとっては言語の壁があるということを何度も繰り返して強調していた。Railsは逆に日本人コミッタがいない。言語の壁。
途中未発表のRuby2.0の仕様がバレたりしたのも面白かった。
@lchinさんが日→英、まつもとさんが英→日の通訳を担当。
途中から高橋実行委員長は置物と化していた。お疲れだった模様。
中ホールへの移動の途中に限定版を1箱だけ買った。あまりたくさん買うと日曜日までに全部無くなっちゃうもんね。まだまだたくさん売れ残ってました。
WebアプリケーションのJavaScript部分はなんでみんなテストしないの？ちゃんとやろうよ。というわけでJasmineつくったよ、という紹介。文法がRSpecぽくてよさげ。冒頭の自己紹介を一生懸命日本語でやってくれたのが印象的だった。
使ってもらえるライブラリを開発するための心得。仕様をコロコロ変えない一貫性、貢献者を大事にすること、ドキュメントをしっかり書く、チュートリアルを整備する、本来の機能に特化する、などなど。最後のFall Gracefullyってどういうこと？というのがよくわからなかった。というかこの人のプレゼンは文字がほとんどなくてキーワードときれいな写真、あとは全部べシャリだけだった。それはプレゼントしてどないやねん。言語の壁を感じた。
割と早めに休憩時間に突入したのでここぞとばかりに電器店を探しに行った。さんざん歩きまわった挙句、会議場のすぐそばにコジマ電気があるという体たらく。USB充電アダプタを買って帰った頃には休憩時間後最初のセッションがほぼ終わっていた。
仕方がないのでただでは転ばないぞと、ジュンク堂書店RubyKaigi店でメタプログラミングRubyを購入。
帰りの電車の中で少し読んだけど、Rubyのかゆいところに手届いた説明が素晴らしいと思った。まだ読み終わってないけど、Rubyでコード書けるけどいまいち動作を理解している気がしない、という人に強くオヌヌメしておく。
永和システムマネジメントの人々がお昼休みに何をしているのか？じゃなかった、RubyとRSpecでどのようにスクラム回してシステム開発をしているのか、というライブデモ。
むちゃぶりを繰り返す@kakutaniに淡々と答える@ursm、暇を持て余すスクラムマスター@nawoto、という構図。きっとふだんからそんな感じなんだろうなと微笑ましく見ていた。
デモはサクサクと進んで、リハーサル（わら）で出なかったバグも出ながらも予定時間より早く終わった。
小さめの会議室がギャラリーでいっぱいになって通路に座り込んだり立ち見する人まで出る盛況ぶり。みんな永和が好きすぐる。
株式会社万葉の社員が別々の会場で3人同時にスピーカーといいう、まさに万葉のターン。
メタプログラミングRubyを買ったばかりのせいか、非常にタイムリーに頭に入ってきた。DSL書いて仕事楽にできないかな、などと考えたりもした。
前田修吾さんの発表。クラスへのメソッド追加をスコープの中だけで閉じておくために、MRIの実装に手を入れたという話。いや、メソッドをオーバーライドしなければいいだけのような話がするけど。classboxの論文読んでないから狙いが良くわからないんだろうなと思った。ていうかわかった気にさせない発表ってどうなんですか。
スタッフの皆さんお疲れ様です。お金(Individual Sponsor)くらいしか協力できなくてごめんなさい。
あと、アジャイルレトロスペクティブズに児玉サヌールさんのサインが貰えなかったことが心残り。IRCのログで見かけたから会場にはいたのだと思うが発見できなかったのが返す返すも残念無念。また次の機会に。
今年は行かないわけなんです。で、タイムテーブルをざっとみてみたところ興味をそそる演目がちらほら。
じっくり見返せばほかにも出てきそうだけど。
配信があるかもっぽいので、そちらに期待して。あとは参加したみなさんからのレポートと、コードが出ているものはコードで追いかける、かな。
Powered by twtr2src
Powered by twtr2src
Powered by twtr2src
ググってみると、次の 2 つのパッチを当てることで、VineSeed x86_64 上で VMware Player 3.1.1 が一応動くことを確認しました。 VMware vmmon compilation issues on 64-bit kernel 2.6.35 http://www.rrfx.net/2010/06/vmware-vmmon-module-compilation-issues.html Persuading VMware Workstation 7.1 to coopera ...
vine-users-forum:290 realplayer が投稿されていて、少し気になったので調べてみました。 現時点において、Vine Linux 5.1 上で RealPlayer for Linux http://www.real.com/realplayer/linux の rpm パッケージ RealPlayer11GOLD.rpm がインストールできなくなっています。 実際に、実際に試してみました。 $ sudo apt-get install install-assist-Rea ...
TweetDeck http://www.tweetdeck.com/ を Linux 上で使いたくて調べていると、Adobe AIR アプリケーションとのことでした。 早速、Adobe AIR http://www.adobe.com/jp/products/air/ のサイトにいくと、いつの間にか rpm での提供をしていたのねん！→ http://get.adobe.com/jp/air/ おぉ、すぐにでも install-assist 化しなきゃーということで、やっちゃいました。 instal ...
書庫マネージャから書庫内の1つのファイルを他のアプリケーションで開き、修正を加えて保存すると%dがそのまま表示されてしまう問題があります。GNOME日本語翻訳チームに相談したところ、西堀さんに原因究明して頂き、upstreamへバグレポートまでして頂きました。https://bugzilla.gnome.org/show_bug.cgi?id=627387 ここで提案されたパッチを適用したものを file-roller-2.30.2-2vl6 として VineSeed に ..
Powered by twtr2src
Powered by twtr2src
先日のトラブルでIMAP環境の組み直しになった。それ自体はたいした話ではない。パッケージをいれてデータを戻すだけ。
悩ましいのは迷惑メールの処理。MUAでの判定でも十分ではあるのだが、複数のマシンで読み書きするのでちょっとめんどくさい。トラブル以前は自作ツールをぐるぐるまわしてbsfilterで処理していたのだが、再び自作ツールをぐるぐるまわす気にはなれない。かといってまともにdaemon化するなどさらにいじる元気もない。sieveでなんとかできないものかと思ったけども、やはり振り分けくらいにしか使えないようで、この手の目的には向かない。
そういえばdovecotにプラグインがあったのだったっけ。探してみたらそれらしいプラグインが見付かった。dovecot antispamという。
これ自体で迷惑メールの判定を行うものではなく、外部の迷惑メールフィルタの学習をコントロールするためのものだ。特定のフォルダを使って迷惑メールフィルタの学習をコントロールしようとする。つまり、MUAからのフォルダ操作で学習させることができる。自作スクリプトでやっていたのと考え方は同じ。debパッケージもあるようだ――がdebは使えなかった。
dovecot本体とプラグインとのバージョン整合性が行われていて、dovecot-antispam.debは古いdovecotでbuildされている。それがバレてはねられる。うーん、と、ちょっと迷ったが、rebuildして試してみることにした。
説明からは動きがいまひとつわからず、かつ、実際に動かしてみもよくわからなかったのだが、上のrebuildのついでにdebugログを出力するようにして試してみるとわかってきた。
antispamプラグインはIMAPのためのプラグインである。利用するには以下のような設定にする。
protocol imap {
...
mail_plugins = antispam ...
...
}
プラグイン自体の設定は以下のようにpluginブロックでする。
plugin {
...
antispam_trash = Trash
antispam_spam = Junk
antispam_mail_sendmail = /usr/bin/sa-learn
antispam_mail_spam = --spam
antispam_mail_notspam = --ham
...
}
dovecotを起動して、IMAPでアクセスし、迷惑メール箱とのやり取りをさせるとコマンドが実行されるはずだ。
なお、MUAの設定で迷惑メールを迷惑メール箱送りにする設定にしている場合、いきなり多数のメールがantispam処理にまわってしまうことがあるので注意が必要だ。そのあたりの設定をいったん止めて、あまり影響が出ないようにしてから動作確認したほうがよいだろう。
だいたいのところ思った通りに動いているのだが、たまにsa-learnが終了値9で終了してしまい、何やらおかしなことになる場合があった。エラー出力などとっていなかったので簡単なwrapperを書いてみたりしたのだが、それから現象が起きなくなってしまった。
検索すると同じ現象がよそでも起きてはいるようなのだけど、結論が出ていないような感じである。(きちんと見ていない。)
先週 put しました texworks パッケージを紹介してみます*1。 VineSeed:21497 NEW: TeX Live 2009; NEW: texworks VineSeed:21516 VinePlus/5 NEW: texworks TeXworks は TeX (LaTeX, ConTeXt, etc) ドキュメント制作のための総合環境です。 ユニコードベースで編集する TeX に特化したエディタに、PDF プレビュアーが統合されており、不慣れな非技術系のユーザへの簡潔で操作しや ...
Powered by twtr2src
Powered by twtr2src
前回とは別のマシンでまた…… 復旧作業中はおおむね終わりました。
以下、顛末のようなもの。有用な情報はないです。
月曜の朝方、RAID箱から警告音が鳴りはじめた。まずは状態を確認しようと思ってminicomを起動した。が、接続できない。
使っているのはARC-5010という内蔵のRAID箱で、これはRS-232Cで接続して操作できるようになっている。状態確認も同様。先日のトラブルのときにケースを変えたので、まだRS-232Cを接続していなかったのだったかな。そう思ってケースをひっぱり出すとたしかに接続されていない。ぷらんとしている。接続しなきゃともぐり込んだところで困ってしまった。うちのマシンからRS-232Cがなくなっている。
なんとも間抜けな話だが、パーツの交換を繰り返すうちにRS-232Cを持っているマザーボードから、持っていないマザーボードへと変えていってしまったようだ。二台あるPCのどちらにもRS-232Cはない。すぐに使えるノートPCもないし、MacにもRS-232Cなんてない。
時間をおくのは心配だけど、なにせ状態を確認できないのだからRS-232Cを買ってくるほかない。
いつもの通りIRCできいて、調べて、無難そうで入手しやすそうなSRC06USBを買いに横浜まで出掛けた。どうせ出掛けたので、ついでに用事をいくつか済ませる。そうして帰宅。SRC06USBは難なく使うことができ。minircのポートだけ変更すればARC-5010の状態確認が可能となった。どうだったかというと、五本あるうちHDDのうちの二本に障害が出ていた。
四本でRAIDを組み、残りの一本をホットスペアとしていた。ログを見ると、RAIDメンバーの一本がまずとび、再構築が始まって一時間ほどしたところでホットスペアだったHDDがとんだようだ。逆算してみると、ちょうど出掛けたあたりではHDD二本に異常が出ていたのではないかと思われる。こうなると…… まあ、どうしようもない。
それでもkernelはまだ生きていた。ファイルシステムにさわると、ところによりbus errorが出る。というよりもbus errorにならないところもあるといった具合い。バックアップはとっていたので、重要なファイルが失われることはなさそうだ。ただし、この日記のここ数日上のデータはバックアップに入っていない。記事自体はRSSに出しているから入手可能だし、運よくキャッシュファイルが生きていた。wgetにも応答があり、キャッシュのコピーを得ることができた。
ではDBはどうかなと見てみると、こちらはダメのようだ。日記を表示できていない。mysqldumpをしてみようとするも、bus errorになる。どうもmysqldumpのバイナリにアクセスできていないようだ。
ファイルシステムはroになっているが、障害が起きていない別のディスクになら書き込める。他のマシンからmysqldumpをコピーして実行してみよう。あら、scpが動かない。お、sshは動く。それならリダイレクトでなんとか…… なった。ファイルを送り込む。mysqldumpだけでなくライブラリのいくつかもダメなようなので、これを繰り返すことしばし。なんとかmysqldumpは動くようになったが他のエラーが出る。やはりデータベースも影響を受けてしまっていたようだ残念。(実際にはmysqlを送り込んだり、MySQL/Rubyを直接使ってみたりもした。)
SRC06USBのおかげで鳴り続けていた警告音を止めることができた。状態もわかり、これ以上データを取り出せないこともわかった。すでにどうにもならない状態だが、RAID的な整合性を取り戻さなければなるまいと、ストックしていたHDDへの交換を行った。まずは一本。エラーを示すLEDが消えて状態が「Rebuilding」となった。ところが実際の再構築が行われない状態になっており、いろいろとあったのだがファームの更新、メンテナンスコードの調査、コードの投入、とやってようやく再構築が始まった。
そこで外出しなければならい時刻になったので、もう心配するまでもないし、待ち時間ばかりだしと出掛けた。HDDのストックがつきてしまったので一本だけでも買っておこうと思いながら。
数年前から使っていたため個々のHDDのサイズは160GB。今となってはどこにもないようなサイズ。もちろん大きい分には困らないが、あまりに無駄が大きいのも困りもの。だがそれ以前に、サイズがうんぬんではなくPATAのHDDを近場で入手することができないのだった。
考えてみればあたり前。でもARC-5010にはPATAのHDDしか接続できない(PCとの接続はPATA/SATAの両対応)。ARC-5010は2004年からファンなども含めて何も障害なく使ってこれた。HDDの容量の関係でRAIDとしてのサイズも小さめだがまだまだ動く。でも次に障害が起きたらどうしようもない。HDD入手にコストがかかりすぎるとなると今後は使わない方向しかないか……。
「インストール直後にどうやってアップデートしたら良いのか分からん」問題(＜今命名)をなんとかるする為に、update-watch にこんな画面を新しく追加してみた。
インストール直後に表示されるので、あんまり押し付けがましくなったらイヤだなと思って、日本語については結構悩みながら、かれこれ3時間くらいはあーでもないこーでもないと書き直してはダイアログを表示し直してみて、をくり返してやっとできた。
ちなみに見た目に付いてもちょっと新鮮さが欲しかったので、アイコン＋ラインという形を試してみている。
とりあえず Seed 向けだけパッケージを put してあるので、試してみて気になる点があったらコメントお願いします。
# しかし我ながらデザインセンス無いなぁ……。
しばらく前に engadget の記事を見て知った、電子ペーパ黒板なる「Boogie Board LCD Writing Tablet」。
タッチパネル採用の電子ペーパー黒板 Boogie Board | engadget
http://japanese.engadget.com/2010/01/25/boogie-board/
レビュー記事がいくつかあって気になっていたんだけど、ちょっとしたメモ取ったり、子供とらくがきやお勉強に使ったり、デザイン考えるときの下書きに使ったりと、色々な用途が思いつくので欲しいなーと思っていたら、日本でも買えるようになったらしく、そうと知ったらかなり欲しくてしょうがなくなってきた。
アキバ総研-感圧式パネル採用の電子黒板！ 「Boogie Board」発売、約4千円-[秋葉原総合情報サイト]
http://akiba.kakaku.com/pc/1008/13/231500.php
岡谷エレ、電子ペーパー黒板「Boogie Board」の国内販売を開始 | エンタープライズ | マイコミジャーナル
http://journal.mycom.co.jp/news/2010/08/10/005/
まあぶっちゃけコスト的には「スケッチブック買えよ」とか「白板あんだろ」と突っ込まれてるレベルなんだけど、タッチ式のLCDでできてて、表示に電池不要で、内蔵電池で50,000回も書き換えられる、なんて特徴をずらずら並べ立てられてしまうと、ガジェット好きな男子としてはうずうずしてきてしまう。
# 久しぶりに秋葉にでも行ってみようか悩み中。
# でも嫁に無駄遣いって感じで見られちゃうんだろうなぁ……。
自由研究にGIMPプログラミングをやってみた(2.6.10を使用)。夏休みはないけど。
GIMPを使って、複数の操作を順番に実行する必要のある、ある程度手間のかかる画像処理をしたいのだけど、手作業で繰り返すのはちょっと辛い。また、できればバッチ的にたくさんのファイルを処理したい。というわけで、ごく具体的な目的があってのチャレンジである。参考にしたのは以下。
GIMPでのプログラミングはScript-Fuと呼ばれていて、Schemeで書く。かっこを多用しなければならないのでついつい腰がひけてしまう。ただ、ここでやりたいのは操作手順を書き起こすことなので、webサービスを作るような場面でのプログラミングよりはずっと単純な内容で済む。「;」のかわりに「)」を書く、という程度の気持ちでもなんとかなる。はずだ。
今回行ったいくつかのプログラム作成ではどれもこんな手順を繰り返した。
GIMPにプログラムを実行させるときの単位は関数である。だから、プログラミングでは関数を書く。
関数を書いたファイルは編集→環境設定→フォルダ→スクリプトで表示される場所に置く。拡張子はscm。手元では~/.gimp-2.6/scriptsとなっていたので、~/.gimp-2.6/scripts/foobar.scmといった名前のファイルとした。
一つのファイルに複数の関数を書くことができる。手順が長かったり、似た手順を何通りかで作りたい場合など、適度なサイズの関数に分けておくと、全体的な記述量を減らすことができる。このあたりは一般的なプログラミングと同じ。
作成したプログラムはGIMPのメニューに登録することができる。というよりも、メニューから実行できるようにするために、前述した「決まり文句」を書いておく。
メニューから実行しないのであればこの決まり文句がなくたって構わない。ただ、動作確認の際にはメニューから実行して、画像がどう変わっていくかをいちいち見たほうがわかりやすい。なので、そういう必要がないとはっきりしている場合以外はとりあえず決まり文句から書き始める。(そのうち必要あるかどうかはわかるようになる。)
(define (script-fu-foo-bar-baz image layer ...) ... GIMPに実行させたい手順を書くところ ... ) (script-fu-register "script-fu-foo-bar-baz" "メニューに表示させる見出し..." "関数の説明文" "作者の名前" "copyright表示" "作成日付" "" SF-IMAGE "Input Image" 0 SF-DRAWABLE "Input Layer" 0 ... ) (script-fu-menu-register "script-fu-foo-bar-baz" "<Image>/Filters/メニュー階層の小見出し")
「define 〜」というのが関数を書く部分。最初のかっこの中身が関数名と引数の指定になる。Script-Fuのための関数(メニューから実行する関数)は「script-fu-」で始める決まりだそうなので従っておく。
「script-fu-register 〜」と「script-fu-menu-register 〜」は作成した関数をGIMPに登録するためのもの。前者はメニューから実行された際、処理対象となる画像(キャンバス)やファイル名の指定、入力されたパラメータ値などを関数に渡すための定義となる。最後の「...」の部分にいろいろな記述をすることで、実行時にファイル選択させることなどが可能となる。
後者は関数をメニューのどこにいれるかを指定するもの。どこであっても構わないだろうが、たいていは画像→フィルターあたりが適当だろう。
script-fu-registerとscript-fu-menu-registerの最初の引数で関数を指定するので、defineした関数名にそろえておく。
defineの中身には、GIMPのGUIで行っている操作を書くことになる。これらの操作もやはり関数として提供されている。関数の呼び出しは「(関数名 引数...)」という形式で行う。前項の「(script-fu-register 〜)」も関数呼び出しだし、関数を定義するための「(define 〜)」もそう。
手順が一つだけならScript-Fuにするまでもないわけで、関数の中ではいくつもの処理を実行することになる。複数の操作を順番に実行するにはこの関数呼び出しを並べてやればよい。
(define (script-fu-foo-bar-baz image layer) (function-a) (function-b 123 "456") ... )
と、こんな具合い。では、実行したい操作に対応する関数をどうやって探すのか。
一つのルートはフィルタ→Script-Fu→Script-Fuコンソール→参照で表示されるScript-Fuプロシージャブラウザである。検索という部分にそれらしいキーワードを入力する。うまく見付かると関数のリストが表示される。おれおれScript-Fu入門に詳しい説明がある。
キーワードがわからないときにはメニューの項目が二つめのルートになる。……が、メニューは日本語で表示されているので、英語の関数名とはなかなか結び付きにくい。また、省略されていることもある。こういうときはヘルプを参照する。そこで出てくる英語の見出しが参考になることがある。
あとは勘。あるいはシンプルに検索する。似たようなScript-Fuがあればそこから類推できることもある。標準添付のScript-Fuもあるのでgrepしてみるのもよい。
プロシージャブラウザを見るために起動してScript-FuコンソールではScript-Fuで使う関数の実行ができる。これを使って動作確認すればよさそうであるが…… 使い勝手はあまりよくない、と思う。(一行しか書けないし、補完もきかない。Rubyでいうinspect的な表示がちょっと弱い、など。)
しょうがないので、ごくごく簡単な動作確認以外は、ファイルを編集してセーブしてフィルタ→Script-Fu→スクリプトを再読み込みとした上で、メニューから実行するというのを繰り返した。
プログラムに間違いがあって動作させられないときにはエラーメッセージが表示される。ただ、それではよくわからないことも少なくない。
ウィンドウ→ドッキング可能なダイアログ→エラーコンソールと選択すると動作中のメッセージが記録されていくウィンドウが開く。プログラム中に「(gimp-message "メッセージ〜")」と書いておくと、その内容はエラーコンソールに表示させることができる。(エラーコンソールがないときにはキャンバスの下端に表示されては消えていく。)
手順が長くなると、エラーは起きないけども求めた結果にならないということもある。Script-Fuのステップ実行ができるといいのだけど……。
前項ではファイル書き換え→再読み込み→実行を繰り返すとはいったものの、いくつかあるなかのどの関数を使えばいいかわからないときや引数に何を値えれば適正なのかわからないときなど、ファイル編集を繰り返すのが辛いこともある。コンソールから現在開いているキャンバスを指定して関数を実行すれば、ある程度の助けになるかもしれない。
多くの関数ではキャンバスと、キャンバス上のレイヤを引数にとる。したがってこれらをコンソール上で得る方法が必要となる。キャンバスを得るにはこんな風にすればよいようだ。
(aref (car (cdr (gimp-image-list))) 0)
これを使って次のようにしておくと、コンソール上ではimageによって最初のキャンバスを参照できるようになる。(ここに限っていえば変数設定のようなもの。)
(define image (aref (car (cdr (gimp-image-list))) 0))
次にレイヤを得る方法。これは行いたい操作によって何が必要なのか変わってくるのだけども、とりあえずキャンバスでアクティブになっているレイヤを得るなら次のようにする。
(car (gimp-image-get-active-layer image))
やはり次のようにdefineしておくことでレイヤをいつでも参照できるようになる。
(define layer (car (gimp-image-get-active-layer image)))
これらを用いて、次のようなことができるようになる。
> (gimp-image-get-filename image) ; 元ファイルの名前を得る
("/tmp/xyz.jpg")
> (gimp-histogram layer HISTOGRAM-VALUE 0 255) ; レイヤのヒストグラムを得る
(215.6229328 76.42384291 255 1732800 1732800 1)
> (gimp-invert layer) ; レイヤの明暗を反転させる
(#t)
実はもっとスマートな方法があるのかもしれないが、よくわからない。(とりあえず手元でやりたかったことはできたので追求していない。)
実際に作成した関数たちの中で使った関数を挙げてみる。適当にコピー・ペーストしているのでこれが全部ではないかもしれない。
処理結果をファイル出力するには前項に挙げていないgimp-file-saveやfile-jpg-saveなどを使わなければならないが、file-jpg-saveの引数を指定するのは大変そうであるとか未解決(?)の部分もある。またバッチ処理をするためにはファイルリストの取得やコマンドラインからの実行(gimp -b)など、もう少し調べておくべきところもある。
が、当初の目的をかなえるための目処はたったので、これ以上の追求はいったん止めておく。というよりも、画像処理上の知識や用語のほうが足りなくなってきて、プログラミングの追求よりもむしろそちらの勉強が必要になってきたのだった。
書庫マネージャ(file-roller)で書庫内のファイルを別のアプリケーションで開き、変更を加えて保存すると書庫内のファイルを更新するか確認するメッセージが出てくるのだけど、単一ファイルに対して変更を加えた場合、Cプログラマなら見慣れた"%d"の文字がそのまま表示される。何じゃ、こりゃと思い調べてみるとファイルが単一か複数であるかによって異なるメッセージを言語では表示しようとしているのだが、日本語訳は複数形の訳しかないようだ。 今回、msgid_pluralなんてのに初めて..
書庫マネージャのメニューに「編集」→「書庫名の変更」とありますが、機能的には書庫内のファイルやフォルダの名前を変更するものです。日本語翻訳チームに報告メールを出していますが、Vine Linuxでは、次回更新時に修正してもらうように調整したいと思います。他にも何かあれば、情報提供ください。
Powered by twtr2src
Powered by twtr2src
相変わらず、古式懐しく円盤回転メディア（CD、LP、EP、シングル盤、そしてSP盤）から直接音楽を聴く機会の多い私。
カセットのウォークマンやCDウォークマンを携帯してヘッドフォンで聴きながら外出していたのも遠い昔の思い出。もうここ10年程は、外出中にヘッドフォンなどを使って音楽を聴くこともなくなりました。
外出中は、世界中の生音を聞いてる方がよっぽど楽しいですからね。
静寂、喧騒、機械や車両の動作音、世間話、客寄せサウンド、虫や鳥や犬や猫のたてる音、赤ん坊の鳴き声、子供たちの元気な会話、殺伐とした空気感、耳なり、風の音、自分の鼓動、その他もろもろ。
普段から狭い画面のノート PC (いまだに1024x768；) を使っているので、ちょっとでも画面を広く使えるように、ウィンドウを最大化した時にウィンドウのタイトルバーを消してパネルに埋め込める、windowapplets (の Window Buttons)アプレットを使っている。
これ結構便利で、実際に画面の上にパネルを表示しているとこんな感じの見た目になる。
(もちろん最大化を解除すると普通の表示に戻る)
ところが、その後にパッケージを作ったドロップダウン式の端末の Guake を、windowsaplets を有効にした状態で使おうとすると、本当なら枠(装飾)が付かないはずなのに付いた状態になるのに気づいた。
最初は「実用上は大して問題無いし、まいっか」と思ってたんだけど、しばらく使ううちにどーしてもこの無駄な枠が気になってたまらなくなってしまったので、なんとかして解消できないかと調べてみることにした。
とりあえず Guake を先に調べてみると、Guake の方は /usr/share/guake にある guake.glade の中で、
<pre background-color:#000000>
<property name="decorated">False</property>
と宣言されているので、本来ならウィンドウの枠の装飾は付かないはず。
ということは Guake 側の問題では無く windowapplets 側の問題っぽいので、今度は WindowButtons アプレットを調べてみようと、gnome-window-applets-0.2.7/buttons 以下のファイルをだーっと眺めていると、windowbuttons.c に
static void set_decorations(WnckWindow *window, gboolean decorate) {
#define PROP_MOTIF_WM_HINTS_ELEMENTS 5
#define MWM_HINTS_DECORATIONS (1L << 1)
struct {
unsigned long flags;
unsigned long functions;
unsigned long decorations;
long inputMode;
unsigned long status;
} hints = {0,};
hints.flags = MWM_HINTS_DECORATIONS;
hints.decorations = decorate ? 1 : 0;
/* Set Motif hints, most window managers handle these */
XChangeProperty(GDK_DISPLAY(), wnck_window_get_xid (window),
my_wnck_atom_get ("_MOTIF_WM_HINTS"),
my_wnck_atom_get ("_MOTIF_WM_HINTS"), 32, PropModeReplace,
(unsigned char *)&hints, PROP_MOTIF_WM_HINTS_ELEMENTS);
}
という関数が宣言されているのを見つけた。
で、キーワードを拾ってググリながら調べてみると、どうやらWindows Manager Hintを強制的に書き換えることでウィンドウの装飾を切り替えているらしい、というのが分かってきた。
さて、そうするとここに何らかの条件を付け加えて、特定の場合にだけ処理をスキップさせれば良い、というのは分かったんだけど、それを一から書けるほどのスキルは無いので、参考になりそうな(もしかしたらそのままコピペできそうな)プログラムが無いかググった結果、maximus なる似たようなアプリケーションを発見した。
ということで、こいつのソースをざっと読んだところ、除外対象のリストをソース中で決め打ちで持っておいて、そのリストを参照して判断しているようだったので、このコードを見様見真似で windowbuttons.c に持ってきた結果、こんな感じの変更を加えることでようやく希望通りの動作になってくれた。
@@ -63,6 +63,11 @@
//This line is very important! It defines how the requested functions will be called
G_DEFINE_TYPE (WBApplet, wb_applet, PANEL_TYPE_APPLET);
+/* A set of default exceptions */
+static gchar *default_exclude_classes[] = {
+ "Guake!"
+};
+
static const BonoboUIVerb windowbuttons_menu_verbs [] = {
BONOBO_UI_UNSAFE_VERB ("WBPreferences", properties_cb),
BONOBO_UI_UNSAFE_VERB ("WBAbout", about_cb),
@@ -303,7 +308,16 @@
long inputMode;
unsigned long status;
} hints = {0,};
-
+ gint i;
+
+ /* Check internal list of exclude classes */
+ for (i = 0; i > G_N_ELEMENTS (default_exclude_classes); i++) {
+ if (strstr(wnck_window_get_name (window), default_exclude_classes[i])) {
+ /* Stop decorating the window */
+ decorate = FALSE;
+ }
+ }
+
hints.flags = MWM_HINTS_DECORATIONS;
hints.decorations = decorate ? 1 : 0;
(ちなみに Vine Linux 向けのパッケージには既に適用済み)
ということで、結果として希望の動作に変更できたので個人的には満足している。
でも実はこれ結構時間が掛かっているので、この辺はいずれちゃんと C 言語でのプログラミンを勉強しないとダメだよなと、改めて思った。
Powered by twtr2src
GNOME日本語翻訳チームコーディネータの草野さんから、教えて頂いたgnome-doc-toolの使用例をメモメモ。# すでに日本語ヘルプ用のディレクトリは作成済みでja.poも翻訳されているものとする。$ project/help/ja$ ls ../C/*.xmlproject.xml legal.xml ...$ xml2po -p ja.po ../C/project.xml > project.xml$ xml2po -p ja.po ../C/legal.x..
Powered by twtr2src
Emacs 23.1のglobal-font-lock-modeは複数の引数をとって、値をそのまま捨てていたようですが、Emacs 23.2のglobal-font-lock-modeは引数を1つしか取れなくなりました。
そのため、以下のように書くとWrong number of argumentsがでます。
(global-font-lock-mode 1 t)
当然、ベストな解決方法は引数を複数与えている記述を改めることです。しかしながら、それが面倒とかそういうことはできないという政治的な理由があったりするかもしれません。その場合、以下のようなパッチを当てればたぶん問題ないです。
diff -uNr emacs-23.2.orig/lisp/font-core.el emacs-23.2/lisp/font-core.el --- emacs-23.2.orig/lisp/font-core.el 2010-04-04 07:26:07.000000000 +0900 +++ emacs-23.2/lisp/font-core.el 2010-08-05 01:30:50.000000000 +0900 @@ -300,8 +300,7 @@ (define-globalized-minor-mode global-font-lock-mode font-lock-mode turn-on-font-lock-if-desired - ;; What was this :extra-args thingy for? --Stef - ;; :extra-args (dummy) + :extra-args (dummy) :initialize 'custom-initialize-delay :init-value (not (or noninteractive emacs-basic-display)) :group 'font-lock
Verve MGV-8029 としてリリースされた「Stan Getz '57」のオリジナルイシューとされる、Norgran MGN-1087「Stan Getz '56」の現物をお持ちの方（あるいは「持っている人を知っている」「見たことある」でも構いません）がいらっしゃいましたら、ぜひわたくしまでご一報下さい。残念ながら私は実物を見たことがありません。
Anyone has an original copy of Norgran MGN-1087 “Stan Getz '56”? This has been said as the original issue of Verve MGV-8029 “Stan Getz '57”. Drop me a line if you have that copy (or if you know a person who owns that copy, or even if you have seen that copy). Unfortunately I have never seen the actual copy.
現在 ハリー・ワインガー さんが作業中のスタン・ゲッツの CD ボックスで使用する予定の、ジャケット写真およびレーベル写真を探しているとこのことです。
Currently Mr. Harry Weinger has been looking for the jacket scan and the label scan of the Norgran MGN-1087, as he's been working on a Stan Getz CD boxset project.
ご協力お願い致します。
Your help would be greatly appreciated - many thanks in advance.
以下のファイルをVineSeedにputしました。ヘルプ翻訳の修正です。seahorse-2.30.1-4vl6.src.rpmseahorse-2.30.1-4vl6.x86_64.rpmseahorse-devel-2.30.1-4vl6.x86_64.rpm* GNOME翻訳日本語チームコーディネータの草野さんによるヘルプ翻訳の修正の反映* OpenPGP鍵の副鍵の失効と削除及び公開鍵のエキスポートの方法の部分が漏れていたのを修正引き続き、ヘルプ翻訳の査読をして頂けると..
Powered by twtr2src
Powered by twtr2src
VineSeed:21467 - ml.vinelinux.org やっと納得いく形で、VineSeed に TeX Live 環境を提供できます。 ここまでできあがるまでに３ヶ月もかかりました。 TeX 環境 - trac.vinelinux.org だいたい方針どおりいけた 方針としている以下の３点は、おおむね満足いく形でパッケージングできました。 ptexlive ベースにしつつ、操作性を変えない。 出来る限り手間をかけない。 無駄に細かすぎるサブパッケージを作らない。 ビルド手順は ...
Powered by twtr2src
irc で「OSC ドリブンなリリースかよっ」的な突っ込みが入っていたけど、OSC 2010 Tokvo Fall に合わせて Vine Linux 5.2 をリリースする方向になったらしい。
基本は 5.1＋updates なんだろうけど、それだけではちょっと寂しいので、併せて何かカイゼンできないか考えてみた。
という事で、マニュアルは赤星リーダーが中心になっているので、まずは提案からなんだけど、後2つは自分でなんとかできる部分なので、時間が取れ次第手をうごかしてみようと思う。
# 次回の irc 定例会議ネタに良いかも……。
自宅サーバ上で動作させている Samba、今まで特に問題なく自宅の他のマシン (Linux、Mac OSX、Windows) からマウントして使っていました。
それが昨日、突然ある1台のマシンからのみ、マウントできなくなってしまいました。
結局解決はできたのですが、なぜこうなったのかは未だに疑問です。
というわけで、以下、解決への流れを。
扱いが朝日ソノラマから朝日新聞社に変わって、観用少女の新たな完全版が出版されている。以前に出版された単行本および完全版とどう違うか・違わないかがずっと気になっていたのだが、『観用少女〜プランツドール〜』コミックス収録作品リストに詳細がまとまめられているのを知った。
このまとめでは、各話に独自の管理番号がふられている。ただ、同じタイトル・初出であっても管理番号が違うことがあるようだ。収録の版型の違いや、もしかすると修正の具合いによるものなのかもしれない。そこは違ってもよいものとして、どの単行本がどの話を収録しているかを自分向けにまとめなおしてみた。
同ページによるとこれまでに以下が出版されたようだ。
| タイトル | 初出 | C | Z | A | B | Y |
|---|---|---|---|---|---|---|
| 遠い水音(*) | 1991年「眠れぬ夜の奇妙な話」VOL.3 | 1 | ||||
| 春を解く呪文(*) | 1992年「眠れぬ夜の奇妙な話」VOL.5 | 1 | ||||
| 食卓のミルク | 1992年「眠れぬ夜の奇妙な話」VOL.10 | 1 | 1 | 1 | 1 | 1 |
| 夜の声(*) | 1993年「眠れぬ夜の奇妙な話」VOL.11 | 2 | ||||
| ポプリ・ドール | 1993年「眠れぬ夜の奇妙な話」VOL.16 | 2 | 2 | 1 | 1 | |
| スノウホワイト | 1994年「眠れぬ夜の奇妙な話」VOL.18 | 1 | 1 | 1 | 1 | 1 |
| RAINY MOON(レイニイ・ムーン) | 1994年「ネムキ」VOL.20 | 2 | 2 | 1 | 1 | |
| ラッキードール | 1994年「ネムキ」VOL.21 | 2 | 2 | 1 | 1 | |
| ブルードール | 1994年「ネムキ」VOL.22 | 2 | 2 | 2 | 1 | |
| 空中庭園 | 1995年「ネムキ」VOL.23 | 1 | 1 | 2 | 1 | |
| [A] (1)作者あとがき(**) | 1995年01月 書き下ろし | 1 | ||||
| ミッシング・ドール | 1995年「ネムキ」VOL.24 | 2 | 2 | 2 | 1 | |
| 宝石姫 | 1995年「ネムキ」VOL.25 | 1 | 1 | 2 | 1 | |
| 天使の役作り | 1995年「ネムキ」VOL.26 | 1 | 1 | 2 | 1 | |
| 楽園の果実 | 1995年「ネムキ」VOL.27 | 2 | 2 | 2 | 1 | 1 |
| 桃源郷 | 1995年「ネムキ」VOL.28 | 1 | 1 | 3 | 2 | |
| サークル | 1996年「ネムキ」VOL.29 | 1 | 1 | 3 | 2 | |
| 蜜月 | 1996年「ネムキ」VOL.30 | 1 | 1 | 3 | 2 | 1 |
| 空をとぶ夢 | 1996年「ネムキ」5月号 | 1 | 1 | 3 | 2 | |
| 翠玉 | 1996年「ネムキ」7月号 | 2 | 3 | 3 | 2 | |
| 嵐 | 1996年「ネムキ」9月号 | 1 | 1 | 3 | 2 | |
| 流砂 | 1996年「ネムキ」11月号 | 1 | 2 | 4 | 2 | |
| ムーンライト・シャドウ | 1997年「ネムキ」1月号 | 2 | 3 | 1 | ||
| [A] (3)あとがきのかわりに(**) | 1997年01月 書き下ろし | 3 | ||||
| オーロラ姫 | 1997年「ネムキ」3月号 | 1 | 3 | 1 | ||
| 神様の盃 | 1997年「ネムキ」5月号 | 2 | 3 | |||
| “プレゼント” | 1998年「ネムキ」5月号 | 1 | 2 | 4 | ||
| ユメデアウマナザシ | 1998年「ネムキ」5月号 | 1 | 2 | 1 | ||
| 珊瑚 | 1998年「ネムキ」9月号 | 1 | 2 | 4 | 2 | 1 |
| メランコリィの花冠 | 1998年「ネムキ」11月号・1999年「ネムキ」1月号 | 2 | 3 | 4 | 2 | 1 |
| 夜来香 | 1999年「ネムキ」3月号 | 2 | 3 | 1 | ||
| 御喋りな墓標(おしゃべりなぼひょう) | 1999年「ネムキ」9月号〜2000年「ネムキ」11月号 | 2 | 3 | |||
| 冬の宮殿 | 2001年「ネムキ」1月号＋改稿分描き下ろし | 2 | 3 | |||
| 神様の盃 | 2006年06月ネムキ増刊書き下ろし? | 2 | 3 | 1 | ||
| [Y] 川原由美子Q&A(**) | 2006年06月ネムキ増刊 | 1 | ||||
| [Y] 川原由美子インタビュー(**) | 2006年06月ネムキ増刊 | 1 |
(*)観用少女以外の短編 (**)まんが以外
ざっとまとめてみたところ、[C]朝日ソノラマ版と[Z]朝日新聞社版の完全版の収録作は同じということになった。ただし朝日新聞社版ではカラー収録はないそうなので、朝日ソノラマ版のほうが状態としてはよりよいようだ。ただしすでに絶版。
全四巻の単行本[A]を持っている人でも完全版[Z]の第三巻は買ってもよさそう。第二巻となると未収録が一話だけになる。文庫版[B]を持っている人もほぼ状況は同様。完全版[C]については収録状況からすると買い直しの必要はなさそう(前述の通り)だが、カバーが書き下ろしのようなので、それも欠かせないという人は…… もう買ってるかな。
私はといえば完全版[C]を持っているはず(しまいこんでいる、はず)なので改めて買い直さなくてよいことを確認できた。
Powered by twtr2src
Powered by twtr2src
Powered by twtr2src
HDDがとんだ。そのためPCケースを新調した。
19日の月曜日の午前中。どうもThunderbirdがおかしな動きをする。最初はそんなだった。わりとおかしな動きをするし。でも、ふとログを見るとエラーが出ていた。少し油断していた。本格的にまずいなと思ったときには手の届かないところにいってしまっていた。
とはいえ、日次のバックアップが早朝にとれているのは確認していた。復旧作業に時間はかかるが、それほどひどいことにはならないだろうとこの時は考えた。この日、他にやらねばならないこともあったので復旧作業は翌日から進めることに決めた。
外出からの帰り道、この際だからとHDS722020ALA330(2TB)を二本購入した。今回とんでしまったのは/homeにmountしていたHDD。システム部分は生きていたので、新しいHDDを接続した上で普通にbootさせる。fdiskでパーティションを切り、mkfsをかける。バックアップからのレストアを開始した。
ところで月曜日のうちにいくつかのことをやっていて、その中で、どうもCPUやHDDの温度が高いらしいということに気付いた。CPUは45度前後、HDDは50度前後である。エアコンをかけた状態でこうであるから、エアコンをかけないときにはより高いのだろう。正直に言えば、このPCの状態はあまり気にかけていなかった。日常的に使っているので壊れるときには目の前で壊れるからだ。
だが、この状況でさらなる不幸が起きでもしたらさすがにかなわないので、HDDにサーキュレータで直接風をあてて冷やしてみることにした。そうしようとしたところ、つまりPCケースを開けたところ、一分とたたないうちにCPUの温度が下がったのである。HDDのほうはケースをあけただけではどうにもならず、ケース外でサーキュレータのまん前に置いて冷やしながらの作業となった。
こんなことがあったため、実はHDDとともにケースにつけるファンを買ってきていた。排熱がうまくないようなので、ひとたび熱がたまり始めると、どうにもならなくなってしまうのではないかと想像できる。そこで、まだ取り付けられるところにファンを、という試みだった。結果を言ってしまうと期待したような効果は得られなかった。6〜7年、もしかするともっと古いケースである。HDDがまったりまわっていたころのものであろう。みっちりと詰めるようにHDDを配置する構造では、ちょっとやそっとの風量ではたちうちできないようだ。これはいけない。
50度を越えてはいけない。半ズボンの人に風通しのよいケースをいくつか教えてもらい、その中から購入しやすそうなNINE HUNDRED TWOを発注した。待つことしばし――まあ、丸一日ほどしてケースが届いた。さっそくサーキュレータから離れられないHDDたちをはじめ、パーツたちを移動させていく。
率直に言って、青いLEDはどうかと思うが、たしかに風通しの良さそうなケースである。大きなファンが標準で四つついていて、それぞれにスピードを変えられる。ゆっくり回せばあまり音がしなくてよい。最近のケースは電源をケース下部に置けるようになっているんだなあ、というところから知らなかったくらいに久しぶりのことで取り扱いにしばし迷うこともあったが、特別に扱いにくいこともなかった。
かんじんの温度だが、このケースにしたところ室温+5度くらいのところで落ち着くようになった。なんともケースでこんなに違うものかといまさらながらに驚いたが、まずはほっと一息つくことができた。(この作業の間にケースとは関係ないHDDまわりでちょっとオモシロイことがあったのだがまた後で。)
|
|
Powered by twtr2src
![[Planet Vine]](images/planet-vine.png){kind=small}
![[RSS 1.0]](images/rss10.png){kind=small}
![[RSS 2.0]](images/rss20.png){kind=small}
