航海日誌 Starlog

gnumericをアップデートするために、

sudo port upgrade gnumeric

を実行。librsvgのconfigureでエラー。

ログを見るとlibreadline.6.dylibがロードされていないと出る。あるはずのでディレクトリ/opt/local/libにはlibreadline.7.dylibがあるが6は無い。

ググると似たような事例が見つかった。libreadline.dylibへのシンボリックリンクをlibreadline.6.dylibとして作成して解決しているようだ。libreadline.dylibはlibreadline.7.dylibへのシンボリックリンク。

真似してシンボリックリンクを作成したら、librsvgのconfigureが終わって、ちゃんとビルドできた。現在、gnumericのアップデート中。

最近のExcelで気になること。最近と言ってもここ10年ぐらいだが。

Excel 2007や2010でグラフを作り、軸ラベルの数値書式を指数にする。軸を対数にした時に、軸ラベルを指数形式にしたくなる。
数値軸の範囲がやたら大きな数だったり小さな数の時は自動で指数形式になるのだけど、自動で指数形式にならない時は自分で書式を指数に指定する。この時に、指数の書式を指定して、小数点以下の桁数を0とすると"0.E+00"という書式が指定されてしまう。これはExcel 2003から実装されたバグだと思う。

これを回避するには"0E+00"という書式をユーザー指定で追加しなくてはならない。

2000までは小数点以下の桁数を0にすると小数点は自動で消えていたのだけど、2003になって間抜けになってしまった。2013ではどうなんだろう。

もちろんLibreOffice Calcやgnumericやgnuplotではこんなにマヌケな事にはならない。ま、gnumericやgnuplotを使うときは"0E+00"のような形式ではなくて、指数部分を10の方に乗せた書式にするけど。

なぜか職場ではこのことを気にしている人はあまりいない。ネットで検索してもこのことを論じているページを見つけられなかった。誰も気にしていないのか・・・。

Macportsでgnumeric 1.12.22.2をビルドしようとしたら、ghostscript 9.16のビルド中に次のエラーが出て失敗した。

Error: org.macports.checksum for port ghostscript returned: ghostscript-fonts-std-8.11.tar.gz does not exist in /opt/local/var/macports/distfiles/ghostscript/9.16_1

書かれているフォルダを見に行くと、確かに無いと言われているファイルがない。

ghostscript-fonts-std-8.11.tar.gzはsourceforgeからダウンロードできたので、これを指定のフォルダに移動してsudo upgrade gnumericとしたら今度は無事にgnumericのビルドが完了した。

MacPortsでGnumeric 1.12.4をインストールできるようになっていたのでさっそくMacBook Proにインストールした。

sudo port selfupdate

でMacPortsを更新して、

sudo port upgrade gnumeric

でgnumericを更新。Mountain LionのMacBook Proでは特に問題なく1.12.4に更新された。

1ヶ月くらい前にPowerMac G3/Tigerの方でselfupdateしたらMacPorts 2.2.0が入ってきた。この時はまだgnumeric 1.10.17が提供されていて、インストールしてあったのは1.10.4だったのだが、試しにupgradeをかけたらllvmのビルドでエラーになって失敗した。1.10.4のときはllvmは依存関係に入っていなかったし、MacBook Proの方でも入っていないのだけど。

MacPortsのllvmを検索してみると、PowerPCではビルドに失敗するという礼がいくつも見つかった。これ以上は自力で何とかできそうにないので、gnumericのアップグレード前にとっておいたディスクイメージのバックアップを復元して元の環境に戻した。

x値, y値のセットで30万点のデータのグラフを書くことになった。使える道具は、Windows XP上のExcel 2003。こいつは残念ながら、ワークシートに65536行までしか入らないし、グラフも1系列あたり32000点が限界（これは2007でも同じ）。もっと古いExcelだと、グラフの一系列あたりのデータ数が4000点という制限もあったけど。

Excel 2007やExcel 2010が入ったPCはかなり遠いところにあったので（２つ隣の建物 ^^;)、フリーで使えるLibreOffice Calc 3.4.1 とgnumeric 1.10.14とgnuplot 4.4.3を使ってみた。

今回はx軸の値を別の値に換算しなくてはならなかったので、gnuplotはそこまでの使い方がわからずパス (^^ゞ　ただグラフを書くのならgnuplotが一番早くできるかもしれないが。

gnumericは換算用の数式を一度にコピー＆ペーストあるいはFilldownしようとするとメモリ不足なのかエラーメッセージも出さずにいきなり落ちてしまうが、数万行ずつのfilldownを繰り返してx軸の換算が終了。グラフ作成も問題なくできた。

LibureOffice Calcでも同じような処理はできたのだけど、テキストファイルの読み込みがなんかどんくさいので、Calcでいくつもデータを開いて処理するのは面倒に思えてこれもパス。

結局grumericでグラフ作成。Pentium D 2.8GHzではグラフの書き直しはどのソフトを使っても処理にそこそこの時間がかかり、分単位で待たされてしまう。gnumericは割とレスポンスが早くて、その点では使いやすい。

もっとも、最速はgnuplotだったりするのだが。x軸の変換をしなければ、作業手順的にも、処理時間的にも、gnuplotが最速。GUIで操作できるcueplotを併用。

ExcelやLibreOffice Calcで2つ以上の系列を持つグラフを作成したときに、第2数値軸を設定することができる。互いに関係はあるが値が大きく異なるデータをひとつのグラフに表示したい時に第2数値軸は便利な機能である。

普段私は3Dタイプのグラフを使うことはないのだが、3Dタイプのグラフでは第2数値軸を設定できないことに気づいた。

手元のソフトで確認したら、Excel 2003/2007、LibreOffice 3.3.2では3Dタイプのグラフで第2数値軸(LibreOfficeでは第2 Y軸)を設定できなかった。

gnumericは3Dグラフという設定ができなかったけど (^_^;)

iWork'09のNumbersも3Dグラフだと第2数値軸の設定ができない。それ以前に、第2数値軸の設定のグラフが縦棒グラフと折れ線グラフの組み合わせで、他のグラフへの変更方法がよくわからなかった。Numbersはトライアル版を入れてあるだけで、普段は使っていないので使い方を分かっていないだけではあるのだが。

Gecko 1.9.2.9のFirefox 3.6.9とThunderbird 3.1.3がリリースされた。

Gecko 1.9.1.12のFirefox 3.5.12とThunderbird 3.0.7とSeaMonkey 2.0.7もリリース。

Thunderbird 2.0は2010年6月でサポートが終了しているが、Gecok 1.9.1系列は2010年12月でサポートが終了するとのこと。

ついでに最近のリリースとして、Safariが5.0.2に、Google Chromeの安定版がバージョン6に、開発版がバージョン7になった。Operaも10.62がリリース。大きく版が上がったのはChromeだけかな。

MacPortsでインストールしているgnumericが、1.8.4.1から1.10.9へ上がった。こいつのバージョンアップは久しぶり。1.8.4をインストールしたときのコンポーネントにバグがあったのか、gnumericを起動するときに毎回dbusのエラーが出ていたのだけど、今回から出なくなった。

ClamXavの2.0.7betaが出ている。スキャンエンジンはclamav 0.96.2。

2010/9/18 追記
9/15頃にFirefox 3.6.10とThunderbird 3.1.4, SeaMonkey 2.0.8がリリースされた。

OpenOffice.orgやGIMP、Inkscape、GnumericなどのUnixからWindowsへ移植されたソフトは、いずれも動作が遅い。これらのソフトは、いずれもUnixのライブラリ群をWindowsへ移植して動いている。それぞれのソフトのフォルダを見ると、同じ名前のdllが多数入っている。

これらのソフトからWindowsの機能の呼出しの際には、おそらくアプリケーション←→移植されたUnixライブラリ←→Windows APIという経路となるため、直接Windows APIを呼び出す普通のWindowsアプリケーションよりも呼出しのオーバーヘッドが多くなっているのだろうと思う。ひょっとすると関数呼出し時の引数の渡し方なんかもUnixとWindowsでは違うのかもしれないけど、調べたことがないからわからない (^^;)

体感だけど、PentiumD 2.8GHz(FSB 800MHz)/RAM 1GB(PC2-4200)/Windows XP SP2というマシンでOOo 3.1.1, GIMP 2.6.8, Inkscape 0.47, Gnumeric 1.9.16を動作させた場合、PowerPCG4 500Mz(システムバス66MHz)/RAM 768MB(PC-100)/MacOS X 10.3.9のX Window上でOOo 2.2.1, GIMP 2.2, Inkscape 0.46, Gnumeric 1.8.1よりも圧倒的に遅い。もちろんPenD上でOpenOffice.orgとMIcrosoft Officeの速度を比べると、起動も操作のレスポンスもOpenOffice.orgの方が遅い。

Cone2Duo 2.26GHz(FSB 1066MHz)/RAM 4GB(PC3-8500)/MacOS X 10.6.2の上で動くOpenOffice.org 3.1.1はMS Office 2008と同じ程度に軽快だし、X Window環境のGIMP 2.6.8やInkscape 0.47, Gnumeric 1.8.4などにいたっては動作速度に何の不満もない。MacOS Xネイティブでないというところが不満だけど (^^;)

WindowsをやめてPC上でLinuxを動かせば、OpenOffice.orgも軽快に動くのだろうけど。