単純な構造のXMLからエレメントを抜き出す 4月27日, 2012
GPXデータのtrkpt要素を抜き出し、time要素を読み取って処理することで遊ぶうち、その一部は幾分かでも汎用的なものにしておいて後日に備えようという気になった。XMLのうち、ごくシンプルな構造のものであればそれほど手もかからないという読みだ。
エレメントの名称と対象のXMLファイルを指定すると、そのエレメントの内容を表示する単純なperlのスクリプトだ。XMLでは、ツリー構造の各レベルに同一名称のエレメントが存在している場合がある。ここではそのレベルの違いを無視し、名称で全てを抜き出してくる。特徴は、XMLモジュールを用いず、正規表現でマッチさせている点にあるだろう。ただし、私の関心は身の回りにある ごく単純な構造のXMLファイル にあるので、それなりに複雑でサイズも大きい純然たるXMLには対応できないだろうと思う。また、XML宣言部分や全角のタグ名称についてはここでは考慮していない。
スクリプトでは、複数行マッチをさせる関係から予め全てを文字列に読み込んでしまう。サブルーチンでそこから該当エレメントを配列に抜き出させ、その配列を表示している。この表示部分を加工すれば、後日何かに適応できるのではないかという目算だ。でも何ができるかわからないけどね。サブルーチンで、マッチングをとるのにちょっと格好悪い’or’があるのは、<tag…/>を処理するためのもの。そこでは属性にデータがあり終了タグが省かれている。どうも私はXMLを充分に理解していないなあ。とにかくそれに対応している。見るからに効率も悪そうだしエレガントではないのだが、わが要求からすれば充分に機能を果たしてくれる(はず)。
$ ./extract_element.pl ElementName From.xml
ElementNameが抜き出すエレメント名、From.xmlが対象のXMLファイル名。
GPXデータをスリムにする 4月23日, 2012
GPSロガーないしは、サイコンの話です。gpxデータのポイント数が多い場合、例えばルートラボなどにインポートしようとすると8,000ポイントの制限を越えてしまって、保存することができませんよね。以下は、それを削ることに関して、自分ではこうするということを簡単にまとめたものです。Lionのシステム既存のrubyで処理しています。環境が変ればこのままではうまくいかないかもしれません。例によって、自分の目の前で必要な処理ができればよい、というスタンスで考えたものですが、同じような環境の方なら多分同じ動きをするはずです。
今、試しにgpxのファイルをエディターで開いてみると、それが単純なXMLファイルであることがわかります。各ポイントデータは<trkpt>と</trkpt>のタグで囲まれ、その下位の<time>タグにUTCで表現された時間データが記録されています。試しにのぞいたものは、4秒毎にデータを取得していて毎分15ポイント。走行時間が10時間の遠出ではデータが9,000ポイントにもなります。ここはひとつ思い切って毎分1ポイントにスリム化してしまいましょう。
スクリプトではREXMLライブラリを使用して、分毎の重複するエレメントを削除しています。ごく短い純朴なもので、かなり遅いのですが、ちゃんと処理してくれます。手元のデータをスリム化した例では、10,000ポイントを少し越えるものを1,000ポイント以下まで削ってくれました。ここまで削る必要はありませんが、まあ今時スリムにこしたことはないでしょう。遅さは驚く程です。3〜4分はかかるのを覚悟して動かします。そう頻繁に使うものではないし、短時間で簡単に書けるスクリプトの方がありがたいといういつもの発想です。
point_reducer.rbのfile_nameに編集対象ファイル名を指定した上で、
$ ./point_reducer.rb | sed '/^ *$/d' > OUT.gpx
delete_elementした結果の空白行をsedを通して削っています。簡単なのがなにより。結果はOUT.gpxにリダイレクトしています。
上記をまとめたあと、思いたってperlでも挑戦してみた。XMLモジュールは用いずに、高校生のように素朴にパターンマッチで処理した。別にperlに慣れているわけでもないのでね。上記と同様に毎分1ポイントにスリム化し、Rubyの動作確認に使用したのと同一の10,000ポイントを越えるデータを処理してみたところ、処理に要した時間は驚きのもの。timeコマンドの出力で0m0.093s。あまりに速いので、気づかない手抜かりでもしているのではないかと心配で、Rubyでやったものと比較してみると、Byte数・行数は同一。これで安心と思いつつも、念押しのdiff。無論同一となるとの予想に反し行数と同じくらいの数のズレを指摘された。いやあ、ミスしたかなとソースと目で比べてみると意外や意外。RubyのREXMLライブラリーを使用したものは、属性の配列順序がソースと異なるのだ。何か指定しなければいけなかったかなあ、ライブラリー内部ではハッシュが返す値を用いて再構成しているのかな、複雑なことをやっているのだろうなあなどと思いつつ、中心としていたtrkpt要素については全く影響がないことなのでいいことにした。今後はperlの方を使おう。
$ ./reduce_point.pl GPX.gpx > REDUCED.gpx
GPX.gpxがソースファイル名、REDUCED.gpxが出力先ファイル名。
Xcode-4.3.2のCommand Line Tools 4月19日, 2012
Xcodeをupdateして4.3.2となった。gemに必要なので、Command Line ToolsをXcodeのPreferences>Downloads>Componentsからインストールしようとしても、Checksum Errorで失敗する。これは僕の環境で起こるだけなのだろうか。ここで得るファイルにミスがあるせいではないのか。このエラーは、discussionsjapan.apple.comには何の情報も無いが、discussions.apple.comにはかなりの情報があるのだけど。とにかくそれに従って上の方法を捨て、直接Developer ConnectionからLate March 2012を手動でダウンロード。このファイルはOKだった。いったいどういうことなのだろうか。不思議だ。
FlushとSafari 4月17日, 2012
Lion になって起動できなくなったClassic・PowerPCのアプリケーションやフレームワークなどを一掃した。これまでのメジャーアップデートの時、まっさらインストールをしてこなかったのでね。それもあり、動作確認のためにConsole.appを動かし"すべてのメッセージ"をながめることが多くなって気づいた点を2つ。
最も気になる点は、Flush Playerプラグインに関連してkernelが吐くエラー。
kernel [0] : IOSurface: buffer allocation size is zero
このプラグインを外せば出なくなることで因果関係は確かめられるが、かなりログを消費している。この件は ここ に最新のまとめがある。Safariと同じくWebkitを使用するChromeでも同様の警告が出るが、GeckoのFirefoxでは出ない。どうやらWebkitとFlushとの連動にそもそもの原因があるようだ。これを開発に当たっている人たちは充分承知しているだろうに、なぜ解決しないのだろうか、不思議だ。対処方法は、プラグインを外す以外にない(だろう、多分)。
実は、さらにログを浪費しているのは、32bitアプリケーションが動く際に出る警告。試しにConsole.appを32bitモードで起動すると、
Console: Warning – conversion from 64 bit to 32 bit integral value requested within NSPortCoder, but the 64 bit value 9223372036854775807 cannot be represented by a 32 bit value
これはわがMacBookProが初期のもので(MA609J/A)、64bitのcpuを載せていながら、EFIが32bitであるため中途半端な状態で動いているためかもしれない。しかし、愛用のCotEditorなど、毎秒20行以上もこれが出力されたりするのだからひどい。syslogのレベルを変更して出力を押さえたりもしてはいるものの、警告を発して無駄に動いていること自身はどうしようもなく気分が良くない。元々が速くはないマシンなので、何とかならないものか。困った。こちらの対処方法は、見なかったことにして無視するか、グチを言う以外に無い。
[追記 2012-04-19]: CotEditorやMacJournalなどの常用アプリケーションでconversionの警告が大量に出る原因を勘違いしていた。このwarningの原因は、AquaSKKにあるようだ。性に合うので気に入って長らく使ってきていて、他のwindowsなマシンやことえりなMacに向かった時でも、反射的にスペースキーやqキーを押してしまうほど。Lionに上げた後も、これが無事に動くので喜んでいたのも束の間、警告の固まりとなってしまった。途方に暮れてしまうよ。
Finderのプレビュー欄の日本語文字列 4月12日, 2012
遅まきながら Lion にした。ほとんどの主要なアプリケーションに問題はなかったが、楽譜清書の Sibelius4 はやはり古かった。Updateせずに満足して使っていたのに Lion には非対応。結構な出費と相当なダウンロード時間で(サウンドデータが30GB以上もある)、何とか Sibelius7 に生まれ変わった。よしよし。
あれこれいじっている中で気づいたことを1点だけ。それは、ファインダー/ Finder をカラム表示にした時のプレビュー欄に関して。ファイルを選択すると、ファイルの名前・種類・サイズ・作成日・その他の情報とともにアイコンが表示されるのだけど、 Lion では、テキストファイルについては内容そのものが読み易いサイズのフォントで、しかもスクロールバー付きで表示されるようになった。内容を手軽に見ることができ、クイックルック/ QuickLook する必要もない。ちょっと大きなファイルでは表示可能量に制限があるようだが、必要なら"ちょん"とスペースキーを押せばテキストの全体が表示されるのだし問題ない。
Desktop にメモを散らしているので、それらをざっと見渡す場合などにとても便利。ただ、必要があって ruby のソースを開こうとして気づいた。ファイルに書き込んである日本語文字列が化ける。
スクリプトの多くには、作成時の意図や使用法の要点などをメモしているのでこれが読めれば更に便利なのに。UTI(Uniform Type Identifier)のpublic.plain-text(Text.qlgenerator)ではOKなのに、その下位のpublic.source-codeで文字が化けるわけだから、SourceCode.qlgeneratorが使用するEncodingに関連するように思える。解決にはちょと時間が必要かな。当面の逃げは単純にソースコードの表示加工を止めてしまえばいいか。
/Developer/Applications/Xcode.app/Contents/Library/
QuickLook/SourceCode.qlgeneratorの名前を変更し、
$ qlmanage -r
〜SourceCode.qlgeneratorBK にしておく。プログラム用のソースコードに相応したカラーリングが行なわれなくなるし、logにエラーが残るが、得られるものの方が大きい。カラーリングだけならQLColorCode.qlgeneratorもあるのだけれど…。まあ当面これで充分としよう。Xcodeなどで色を付けたくなったら上の " BK "を削るだけだし。
なお、日本語表示に使用されるフォントの種類やサイズを変更する簡単な方法については、 こちら に説明されています(別サイトに飛びます)。
[追記 2012-04-16]: syslogに次のエラーが数多く記録されるようになる。
quicklookd:
Can’t get plugin bundle info at file://localhost/Developer/Applications/Xcode.app/Contents/
Library/QuickLook/SourceCode.qlgenerator
これが気になる場合は、
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/ LaunchServices.framework/Versions/A/Support/lsregister -f /Developer/ Applications/Xcode.app
まるでおまじないだね( Source )。