2009.12

テキストエディタ mi を中心とした LaTeX の統合環境を提供するアプリケーションとスクリプトのセットです。

高橋さんのおかげで多くのバグ修正/機能改善を行えました。

• include/input されているファイルから、PictPrinter で foward search できない不具合を修正（高橋さん、ありがとうございました）。
• 最初のタイプセットを include/input されているファイルから行うとエラーが発生する不具合を修正（高橋さんありがとうございました）。
• TeXBridge が起動してにない状態で、ツール「リファレンスパレットを表示」を実行すると、リファレンスパレットが表示されない不具合を修正。
• その他、リファレンスパレットを開いている時にエラーが発生することがある不具合を修正。
• xdvi のデフォルトコマンドを pxdvi に変更。
• xdvi コマンドのデフォルトオプションから -nofork を削除。
• xdvi で forward search する場合は、コマンドオプションから -unique を強制的に削除するようにした。

しかし、依然としてバグが残っているようで、リファレンスパレットを表示しておくと、何らかのタイミングで「&1 を取り出すことができません。」もしくは「スタックオーバーフローです。」というエラーが表示されることがあります。再現条件を発見できず、修正できずにいます。もし、エラーの再現できる手順がわかりましたらご連絡いただけると助かります。

1日早いクリスマスプレゼントを頂いたと思うと、いくらか幸せを感じます。

56人目。

ライブラリ/モジュールとしての AppleScript のリファレンスマニュアルを生成するアプリケーションです。

ソースコードにかかれたコメントから、スクリプトのリファレンスマニュアルを HTML として出力します。バンドル形式のスクリプトの場合、バンドル内に(ヘルブビューアに表示する) Help Book としてリファレンスマニュアルをセットアップできます。

Mac OS X 10.6 との互換性を改善しました。

2008 年度の5月頃に購入した Time Capsule が、昨日、ぶっ壊れました。

電源がいっさい入らなくなるという症状です。Apple のサポートディスカッションで同様の事例が報告されていますね。自分も地雷を踏んでしまったようです。

サポートに電話したところ既に保障期間が切れているにもかかわらず、無償交換となるようです。修理ではなく交換となるのが誠に腹立たしい。たぶん、ハードディスクは壊れていなくて電源が壊れているだけなのに、データが失われてしまいます。無くしてもいいデータしか置いていなかったのだけど、プライベートな情報が流出するのは嫌な感じ。Mac 本体と同じように修理してほしい物です。

Time Capsule を使うのはもうやめようかと思ったけど、コストパフォーマンスは Time Capsule が一番高い。それでも、無償交換してくれなかったら、別の物を考えていたでしょうね。

知らんかった。これまで、わざわざ name property を定義したりしていたよ。デバッグに使えそうだ。

テキストエディタ mi を中心とした LaTeX の統合環境を提供するアプリケーションとスクリプトのセットです。

修正点は、

• log ファイルが使用中だとエラーが発生する不具合を修正（高橋さんありがとうございました）。
• DVI プレビューアのモードが「Finder で開く」が設定されており、その DVI ファイルのデフォルトアプリケーションが TeXBridge の時、無限ループになる不具合を修正。
• その他、バグ修正。

今回も、高橋さんのおかげでいろいろ問題点を見つけることができました。誠にありがとうございました。

このサイトの構築には、XSLT と Mac OS X にもれなくついてくる XSLT プロセッサ xsltproc を、かなり広範囲に用いています。xsltproc を使っての処理に昔から、二つの悩みがあった。

• 遅い
• XHTML から HTML への変換の際に、タグに xml:space="preserve" とか shape="rect" というよけいな属性が勝手に付け加えられる。

--nodtdaddr というオプションで、xml:space="preserve" とか shape="rect" を抑制できるような記述を見たけど、自分の試した限りでは効果無し。何の役に立っているのか分からん。--nonet つけると、処理も早くなるしよけいな属性がタグにつくことも無いけど、dtd が読み込めない旨の warning が表示される。--novalid というオプションも試したけど、何の効果があるのかわからん。

結局、問題を解決するにはローカルに XHTML の dtd を置くことだった。僕の場合は、fink のパッケージ xhtml-dtd をインストールした。すると、/sw/etc/xml/catalog.d 以下に、XHTML の dtd がインストールされる。環境変数 XML_CATALOG_FILES に /sw/etc/xml/catalog が設定されていれば、何のオプションも無くても、速いしよけいな属性がついてくることも無くなった。

同じ悩みを持つ人のお役に立てることを願っています。

TerminalControl.osax は Mac OS X 10.5 の ターミナル.app の 足りない AppleScript に関する機能を補うスクリプティング機能追加です。通常の ターミナル.app と AppleScript ではできない、以下のことを可能にします。

• ウインドウ/タブのカスタムタイトルを個別に変更
• ウインドウの背景色の透明度を設定

Open in Terminal、SmartTitle、TeX Tools for mi、UnixScriptsTools for mi などで必要です。

修正点は、

• インストーラーを追加。
• Mac OS X 10.5 用とMac OS X 10.6 用を同じバージョン番号にした。
• メモリーリークを修正。

Instruments を使うと簡単に memory leak を発見できることを知った。今まで知らんかったのが悔やまれます。

TeX Tools for mi 3.3.4 に含まれているスクリプティング機能追加 TerminalControl.osax が Mac OS X 10.6 用の物しか含まれていませんでした。ごめんなさい。Mac OS X 10.5 用の TerminalControl.osax も追加しました。

もし、Mac OS X 10.5 に TeX Tools for mi 3.3.4 に含まれる TerminalControl.osax をインストールしてしまったら、再度ダウンロードして TerminalControl.osax を再インストールしてください。

あと、TeX Tools for mi 3.3.4 には、ログファイルが他のアプリケーションで使われているとき（もしくはファイルシステムがそう思っている時）、「missing value は posix_path メッセージを認識できません。」というエラーが表示されます。ログファイルがアプリケーションで開かれているなら閉じるか、一度消去してください。修正版を近日中に公開します。

bug fix にご協力いただいた高橋さん、誠にありがとうございました。

テキストエディタ mi を中心とした LaTeX の統合環境を提供するアプリケーションとスクリプトのセットです。

高橋さんのおかげで多くのバグを修正することができました。

• DVI プレビューアの設定が xdvi のとき、source specials 付きでタイプセットした DVI を表示しようとするとエラーが発生する不具合を修正（高橋さん、ありがとうございました）。
• ターミナルウインドウが複数表示されることがある不具合を修正（高橋さん、ありがとうございました）。
• ParentFile の設定が正しくないファイルが前面にある状態でリファレンスパレットを表示すると、エラーが発生する不具合を修正。
  • 適切な警告を表示するようにしました。

FileClipper をご使用いただけているとのこと。久しぶりの寄付で（久しぶりでないことはほとんど無いのですが）嬉しい限りです。

問題/ご要望がありましたら、お気軽にお声をかけていただければ幸いです。

55 人目。

ModueLoader 2.1 では新しいモジュールロードの構文を導入します。記述を劇的に簡素化することに成功しました。ModuleLoader 2.1 を紹介できることに興奮しています。他のスクリプト言語では当たり前かもしれないけど、AppleScript にとっては革命的だと思う。

マニュアルを書き上げられるのはもう少し時間がかかりそうなので（どう書くのも悩ましい）、とりあえずバイナリだけβ版として先行公開します。

使い方は次のように超簡単。まず、読み込みたいスクリプトを ~/Library/Scripts/Modules もしくは /Library/Scripts/Modules に置く。これをモジュールとする。トップレベルのスクリプトではモジュールと同じ名前の property を用意し、module コマンドをその定義としておく。こんな感じで。

そして、その後 "boot (module loader) for me" という一文を実行させるようにする。どうです。簡単でしょう。詳細は以下の通り。

• module コマンドは property の初期値として与えなければいけません。
• moduel コマンドが実行されただけでは、モジュールは読み込まれません。
• module コマンドはその property にモジュールを読み込むことを予約します。
• property の名前の同じ名前のモジュールが読み込まれます。上の例だと ModuleA.scptd や ModuleA.scpt などがロードされます。
• property 名と違う名前のモジュールを読み込みたいときは、module "ModuleName" というぐあいに、module コマンドの引数で指定します。
• boot (module loader) for me が実行された段階で、モジュールの読み込みが行われます。
• module loader コマンドは、version 2.0 の make loader コマンドと同じです。名前を変更しました。

モジュールの方で依存しているモジュールの記述は、同じように property の定義部で module コマンドを実行するようにします。

こんだけだ。すごく簡単でしょう。version 2.0 で紹介したやり方も合わせて使えるよ。

否定的な意見でもいいからフィードバックが欲しい。

現在、ModuleLoader の大幅なアップデータを開発中です。新しいモジュールの読み込み構文を導入します。これまで紹介した ModuleLoader のやり方ができなくなる訳じゃないけど、もっといいやり方を思いついてしまった。

現在の ModuleLoader で不満なのはモジュール側で module loaded ハンドラを用意して、明示的にモジュールの読み込みを記述しなければならないこと。宣言するだけでモジュールを勝手に読み込んでくれるようにはできない物かとずーっと考えていて、ほとんどあきらめていた。でも、この話を書き終わってから、ほとんど理想に近いやり方を思いついちゃいました。実装もほとんど済みました。今のところ、思惑通りうまくいっているようです。

新しい ModuleLoader の公開はまだ先になるし、書いちゃったので現在の ModuleLoader の仕組みを紹介します。

まず、前回の復習です。

• 他のスクリプトにロードされて、使い回されるスクリプトファイルをモジュールと呼びましょう。
• 文字列処理用のモジュール StringHandlers を作りました。
• テキストエディット操作用モジュール TextEditHandlers から、StringHandlers をロードするようにしました。
  • load script コマンドは、StringHandlers が更新されても、TextEditHandlers の中の StringHandlers を個苦心してくれません。
• トップレベルスクリプトでも ScriptHandlers をロードします。
  • load script コマンドだと、TextEditHandlers の中の StringHandlers と別物になります。
• ModuleLoader を使うと、TextEditHandlers の StringHandlers を自動的に更新してくれるし、トップレベルのStringHandlers と同じ物にしてくれます。同じモジュールの複製は作られません。

さて、今回は ModuleLoader がモジュールを読み込む仕組みについて解説しましょう。

まず、前回のサンプルのモジュール読み込み部分を見てみましょう。

TextEditHandlers

Top level スクリプト

ポイントは以下の二つ

• TextEditHandlers で module loaded ハンドラを実装し、その中で、load module "StringHandlers" を実行していること。
• トップレベルスクリプトで parent に make loader コマンドで生成される loader script を設定し、loader scirpt に対して、load module コマンドを実行すること。

トップレベルスクリプトのコンパイルが行われたときに起こることをの絵を描いてみました。

処理の流れを説明してみます。

1. make loader コマンドで loader script を生成します
2. loader script をトップレベルスクリプトの parent に設定します。
3. load module コマンドを実行して、"TextEditHandlers" をロードを開始します。
   • load module コマンドはスクリプティング機能追加ではなく、 parent の loader script に送られます。
4. loader script はキャッシュの中から、"TextEditHandlers" を探します。最初の load module ですから、当然見つかりません。
5. loader script は ModuleLoader.oasx にモジュール "TextEditHandlers" へのパスを教えてもらいます（find module コマンドを使う）。
6. パスをキー値にして、もう一度キャッシュの中を探します。やっぱり見つかりません。
7. load script で、"TextEditHandlers" を読み込んで、キャッシュに登録します。
8. TextEditHandlers の module loaded ハンドラを実行します。
9. TextEditHandlers の module loaded ハンドラの中で、"StringHandlers" を読み込む為に 3～10 までの処理が実行され、返り値が property StringHandlers に設定されます。
10. load module ハンドラからロードした TextEditHandlers が返され、property にセットされます
11. トップレベルスクリプトで、load module "StringHandlers" が loader script で実行されます。
12. loader script のキャッシュにヒットして、キャッシュの中の "StringHandlers" が返されます。

これで、めでたくモジュールの読み込みは完了します

ちなみに、loader script のキャッシュの中のスリプトオブジェクトと load module コマンドの返り値は別物になるんじゃないかと思われるかと思いますが、スクリプトオブジェクトは copy コマンドや重複した load script を行わない限り、複製は作られません。変数に set したりハンドラの引数に渡したりしても、参照をやり取りしていて、実体は共有されます。スクリプトオブジェクトだけでなくリストやレコードにも同じ性質が有ります。

ちなみに、このような仕組みは僕が考えた訳ではなくて、appleMods というライブラリで使われている仕組みをパクりました。appleMods でいろいろ気に入らないことがあったのでので自分で作ったのですが、不満が無い訳ではありません。モジュール側で module loaded ハンドラのように依存しているモジュールを読み込むコードを書かなければいけないのは気に入らないところです。ついこの間まで、言語のサポートがない限りはどうにもしようがない、現状ではこれがベスト、と思っていたけど、次の ModuleLoader では、module loaded ハンドラがいらなくなります。しかし、ロード時の動的な振る舞いの為に、module loaded ハンドラは残ります。

次は、新しい ModuleLoader を公開してから、新機能を紹介します。

スクリプトオブジェクトの細かい解説より ModuleLoader の解説を先にしたのは、オブジェクト指向云々よりスクリプトオブジェクトを共有する為のインフラを知る方が先だろうと思ったからです。ハンドラを共有する為だけのスクリプトオブジェクトだって十分役に立ちますから。

次の次からは、役に立つモジュールを作る為のスクリプトオブジェクトのオブジェクト指向の側面について解説したいと思っています。