menucomplete.msのクラスメンバ補完を強化する

先ほどのctagsをWin32環境でビルドするで書いた「やりたかったこと」が一応できました。以下で順に解説したいと思います。

まずきっかけは、ctagsに「--extra=+q」というオプションがあることを発見したことでした。このオプションを付けてctags -eを実行すると、通常なら

class CApp : public CAppFrame {CApp
4,52
CFastPlaneFactory planeFactory_;planeFactory_
12,202

のように出力されるところが、

class CApp : public CAppFrame {CApp
4,52
CFastPlaneFactory planeFactory_;CApp::planeFactory_
12,202

のように表示されるのです。

何が違うの？と思われるかも知れないのですが、CAppクラスのメンバであるplaneFactoryのタグに、「CApp::」という修飾名が付いています。つまり、「--extra=+q」というオプションは、クラスメンバのタグの出力を、スコープ付きで行ってくれるというオプションなのです。

これはメンバ補完にとっては画期的なことで、あるクラスのメンバを探すには、「クラス名::」でgrepしてやればいいことになります。それで関数もメンバ変数もenumも全て取得できるのです。これを発見したときは、正直かなり興奮してしまいました。

ただ、実際に「--extra=+q」オプションを使ってみると、問題があることがわかりました。このオプションは、クラスのタグ出力をスコープ付きで行ってくれるのはよいのですが、スコープ付きでない出力も同時に行ってしまうのです。先ほどの例でいうと、

class CApp : public CAppFrame {CApp
4,52
CFastPlaneFactory planeFactory_;planeFactory_
12,202
CFastPlaneFactory planeFactory_;CApp::planeFactory_
12,202

のようになってしまいます。これではTAGSのサイズがほぼ2倍になってしまいますし、Peggyでタグジャンプするときに候補が二つ表示されてしまい、大変使いづらいです。

というわけで、Peggyで「--extra=+q」オプションをまともに使うには、スコープ付きタグを出力したときには通常のタグを出力しないという改造をctagsに施す必要がある、ということになります。このため、ctagsのビルド環境を整える必要があったわけです。

実際に行った改造はそれほど大きなものではなく、c.cというソースを以下のパッチの通りに変更すればOKです。なお、パッチはctags5.7J1に対してのものです。

1094a1095,1099
> static boolean isExtraTagEntryExist(vString *const scope)
> {
> return (Option.include.qualifiedTags && scope != NULL && vStringLength (scope) > 0);
> }
>
1098,1099c1103
< if (Option.include.qualifiedTags &&
< scope != NULL && vStringLength (scope) > 0)
---
> if (isExtraTagEntryExist(scope))
1157,1158c1161,1165
< makeTagEntry (&e);
< makeExtraTagEntry (type, &e, scope);
---
> if (isExtraTagEntryExist(scope)) {
> makeExtraTagEntry (type, &e, scope);
> } else {
> makeTagEntry (&e);
> }

目的の通り、「スコープ付きのタグを出力するときは通常のタグを出力しない」という改造です。

この改造版ctagsをPeggyが使うようにして、menucomplete.msも改造したところ、正しくクラスのメンバ補完が行えるようになりました。今までとは比較にならない精度でメンバを拾うことができます。また副作用として、namespaceにも補完が効くようになりました。namespace内で定義しているクラス名等が表示されます。

ただ、今回の改造版ctagsとmenucomplete.msの公開に関しては今まで通りはいかなそうです。スクリプトであれば、アンカーシステムズさんのMocaScriptライブラリでチェックしていただけるのですが、改造したctagsのバイナリとなると、動かしても大丈夫かチェックする方法がありません。パッチだけを公開して、自分でコンパイルしてもらうのは敷居が高すぎますし…。

ひとまずは、思いがけない問題が隠れている可能性もありますので、自分で使ってチェックしようと思います。公開の仕方はその後に考えたいと思います。

ctagsをWin32環境でビルドする

とある事情でctagsを改造したくなったのですが、Win32環境でビルドするまでがかなり大変でした。以下にやり方をメモしたいと思います。

まず前提として、ctagsのWin32用のソースは、書き方が古すぎて現行のVisual Studio 2005やVisual Studio2008ではコンパイルできないようです。古い書き方を許容するようなオプションがあるかもしれないのですが、一通り探しても見つからなかったので諦めました。

となると、コンパイルするには古いコンパイラが必要となってきます。幸いなことに、Visual Studio 2003のC++コンパイラ部分を抜き出したツールであるMicrosoft Visual C++ Toolkit 2003というものが無料で手に入ります。これに付属するコンパイラを使用すれば、ctagsをコンパイルすることができます。
ただし、残念ながらMicrosoftの公式サイトではこのツールは現在ダウンロードできないようです。非公式ではありますが、こちらのmsdnのフォーラムのリンクからダウンロードできます。

また、ctagsのコンパイルには、nmake等のビルドを行うためのツールやライブラリ等が含まれるPlatform SDKが必要になります。僕はこちらの246netさんのまとめページを参考にして設定しました。インストールした

C:\Program Files\Microsoft Visual C++ Toolkit 2003\vcvars32.bat

に、以下のような内容を書き加えます。

REM add for Platform SDK
set CPU=i386
set MSSdk=C:\Program Files\Microsoft Platform SDK
set LIB=%MSSdk%\Lib;%LIB%
set INCLUDE=%MSSdk%\Include;%INCLUDE%
set TARGETOS=WINNT
set PATH=%MSSdk%\Bin;%MSSdk%\Bin\winnt;%PATH%

あとはctags日本語版の配布ページに行ってソースをダウンロードし、適当な場所に展開して、先ほどのvcvars32.batを実行した状態で展開した場所に移動し、

nmake /f mk_mvc.mak

とします。（mk_mvc.makというのは、Win32環境用のメイクファイルです。）

ただ、残念ながらこれだけではうまく行きません。メイクするとソースが全部コンパイルされて、大丈夫なように思えるのですが、最後のリンクするところで

LINK : fatal error LNK1181: cannot open input file 'setargv.obj'
NMAKE : fatal error U1077: 'cl' : return code '0x2'

と怒られて終了してしまいます。どうやらsetargv.objがない、というエラーのようです。
Googleで調べてみたところ、setargv.objはワイルドカード展開を行うためのライブラリだそうで、使うには自分でPlatform SDKのソースをコンパイルする必要があるみたいです。こちらのtorutkの日記さんの記事を参考にして、

cd "C:\Program Files\Microsoft Platform SDK\src\crt"
cl /I. /c -D_CRTBLD setargv.c

でcrtフォルダにsetargv.objを作成することができました。このファイルをctagsを展開したフォルダに入れて再度メイクすれば、無事にctagsの実行ファイルを生成することができます。

実際に実行してみると、

% ctags --version
Exuberant Ctags 5.7J1, Copyright (C) 1996-2007 Darren Hiebert
Compiled: Jul 21 2008, 19:49:30

となり、今現在コンパイルしたものであることを確認できました。

ctagsを改造して何をしたかったかなのですが、例によってPeggy関連で、C++のクラスメンバ補完をより高度に行う方法を模索してみようと思っています。うまく成果が出ればよいのですが…。

EeePC901の初期設定

EeePC901は、Cドライブの4GBだけだった701と比較すると、Dドライブの8GBが増えて合計12GBとなり、容量の問題はいくらか緩和されています。ただ、システムドライブであるCドライブは依然4GBのままですので、注意して使わないと容量不足に陥ってしまいます。
今回はどのように設定を行ったのかをまとめておきたいと思います。

まず、MicrosoftUpdateを全て適用しました。この時点で残り容量が1GBを切ってしまい、少しあせりましたが、途中で止まるということはありませんでした。

次に、こちらのサイトにまとめられていることを実行しました。

http://www.4gamer.net/games/046/G004621/20080121031/
http://www.4gamer.net/games/046/G004621/20080123023/

EeePC701用の記事ですが、901でも問題なく適用可能です。dllcacheの削除だけは危険そうでしたので行いませんでした。
アプリの削除に関しては、この記事に書かれているものに加えて、901ではStarSuite 8というOffice互換のアプリが入っていて、これがかなりの容量を占めています。アプリ自体はDドライブにインストールされているものの、このアプリの実行に必要なJavaがCドライブに入っていて、これがかなりのサイズなのです。悩みどころなのですが、ばっさり削除することにしました。ただ、閲覧さえできないというのはさすがにまずいので、Microsoftが配布しているOfficeViewerをインストールすることにします。

http://www.microsoft.com/Downloads/details.aspx?familyid=95E24C87-8732-48D5-8689-AB826E7B8FDF&displaylang=ja
http://www.microsoft.com/downloads/details.aspx?FamilyID=c8378bf4-996c-4569-b547-75edbd03aaf0&displaylang=JA
http://www.microsoft.com/downloads/details.aspx?FamilyId=428D5727-43AB-4F24-90B7-A94784AF71A4&displaylang=ja

PowerPointViewerだけがCドライブ強制インストールなのが謎ですが、それほどサイズは消費しません。
また、盲点になりがちだと思うのがStarSuite 8に含まれるフォントです。StarSuite 8をアンインストールしても、フォントは消されないのです。C:\WINDOWS\FONTSフォルダから、「Sun」と名前の付いたフォントを消していくだけで、100MBは削減できます。

あとは、.NetFrameworkも使いたいアプリがなければ必要ないですね。

これでCドライブの残り容量は1.8GB程度になっているはずです。dllcacheを削除すれば2GBを超えそうですが、これだけあれば十分ですのでやめておくことにしました。

設定はいろいろ大変ですが、2chのEeePCスレなどを見ながらやっていると、みんなでやっている感じがして楽しいですね。それに愛着もわいてきます。これから大切に使っていこうと思います。

EeePC901を開封してみました

先週購入したEeePC901はとても快適に動作しています。一週間遅くなってしまいましたが、開封の様子をレポートしたいと思います。

続きを読む "EeePC901を開封してみました"

Netbookはこれからどうなるのか?

いつ出るのか、もしかしたら日本では発売されないんじゃないかとガジェットマニアたちをやきもきさせていたEeePC901が、先週の土曜日ついに発売されました。前々から欲しいと思っていたこともあり、僕もヨドバシ梅田で買ってきました。

日曜日からいろいろとセットアップしていて感じたのは、時代が変わったんだなあということです。あまりに普通に使えてしまうので、これが6万円で購入できるノートPCなのだということが、今までの感覚とは合わないのです。
もちろん、Cドライブが4GB、Dドライブが8GBしかないという制約上、様々な工夫は必要としますが、一度設定をしてしまえばあとはごく普通のWindowsPCとして使うことができます。

「性能は維持して値段と消費電力を下げる」というIntelの決断、WindowsXPという異例に長寿命で安定したOS、そしてメーカーの挑戦があって、Netbookという新しいカテゴリが生まれました。iPhoneが非PCからパソコンに近い体験をより使いやすい形で進めていくものだとすれば、Netbookは従来のパソコンの方向から一般に広げていくアプローチだと思います。様々な方向からのアプローチがあるのは、とても良いことですよね。

EeePC901に関するレポートはまた後ほどとして、今回はこのNetbookという分野がこれからどうなっていくのかを考えてみたいと思います。

まず、パソコンの変化を考えるには、デバイスの変化を考える必要があります。特に重要なのは、CPUとチップセットですね。
EeePC901はIntelのAtomという新しいCPUを搭載していますが、これはIntelが小型のノートPCやスマートフォンをターゲットとして開発した、全く新しいアーキテクチャのCPUです。その特徴は、性能よりも消費電力やコストを重視していることで、同じ性能ならCereronMの数分の一の電力しか消費しません。

現在のAtomはSilverthorneと呼ばれる第１世代ですが、2009年中には第２世代のLincroftが登場する予定です。Lincroftでは現在のAtomとCPUの性能自体は大きく変わらないものの、メモリコントローラやグラフィックプロセッサが統合され、さらに付随するチップセットも専用のものが開発されます。

現行のAtom搭載Netbookの問題点は、CPUこそ新規設計で新しいものの、チップセットが従来のままであるため、チップセットの消費電力がシステム全体の足を引っ張ってしまうことでした。チップセット全体が再設計され、しかも機能の統合が進むことで、消費電力がより小さくなります。具体的には、現行世代のさらに数分の１になるようです。当然実装面積も小さくなりますので、デバイス自体の小型化、もしくは設計の自由度向上に繋がります。

統合されるグラフィックプロセッサがどのようなものなのかがまだ公開されていないのが不安材料ですが、機能の統合によってアクセスレンテンシが小さくなり、性能の向上も望めそうです。資料では、トータルパフォーマンスで現行の１．３倍、ということになっていますね。

また、現状の最大の問題点であるSSDの容量はどうなるでしょうか。フラッシュメモリの大半を供給しているサムソンと東芝の計画を見ていくと、フラッシュメモリは大まかに言って、一年経つと同じ値段で倍の容量の製品を買えることがわかります。つまり、現行のEeePCがCドライブ4GB、Dドライブ8GBですので、同価格帯ならCドライブ8GB、Dドライブ16GBを搭載できることになります。Cドライブが8GBあれば、EeePC901のように色々な工夫をしてCドライブを空けなくても良さそうですね。

さらに、ソフトウェアについても考える必要があります。EeePC901はWindowsXPを搭載していますが、今後もWindowsXPを使い続けることはできるのでしょうか？Windows Vistaはインストールサイズが10GB近くになってしまうため、今後も（特にSSD搭載の）Netbookでの採用は難しそうです。
結論から言いますと、今後もWindowsXPを使い続けることは可能です。一般向けのWindowsXPの販売は今年の6月で終了してしまいましたが、マイクロソフトはNetbook向けにWindowsXP Homeの販売を、2010年6月30日、もしくは次バージョンのWindowsがリリースされて1年後まで続けると発表しているためです。つまり、少なくともあと２年は大丈夫ということですね。

以上のことをまとめると、２００９年中には以下のようなNetbookが発売される可能性がある、ということになります。

・処理性能は現行の1.3倍
・メインメモリはおそらく変わらない、1GB
・SSD搭載、容量は合計で24GB
・WindowsXP Home搭載
・消費電力は現行より小さくなる。（CPUとチップセットの消費電力はシステム全体からすると一部ですので、劇的な改善はないかもしれません。）それに伴う小型・軽量化

こう見ると、EeePC901と比べてさらに「普通に使える」PCになりそうな感じがしますね。もちろん、これはNetbookに求められる「インターネットをする」ということの定義が変わらなければ、という前提ではあります。例えばニコニコ動画が登場したことにより、インターネットをすることへの要求スペックはここ数年でかなり上昇しました。（一部ではニコニコの壁、と呼ばれています。）
現行Atomはこの壁をギリギリ越えられる能力を持っているのですが、今後さらに重いアプリケーションが流行ると、Netbookの性能とのバランスが崩れてしまうかもしれません。こればかりは読みようがないですね。

このような予想を立てた上で、ではもう一年待つのか？と考えてみましたが、結局は今EeePC901を買うことを選択しました。将来的な性能の向上による利益よりも、今欲しいという気持ちが大きかったからです。この選択が正しかったか否かは、時間が経たないとわからないですね。

iPod touch 2.0 ソフトウェアアップデートしてみました

iPhone3Gが無事発売されまして、iPhoneと基本的なハードウェア構成を共有しているiPod touchもiPod touch 2.0 ソフトウェアが配布開始されました。前回のアップデートと同様、今回も有償アップデートで、料金は1,200円です。

もしiPod touchが単体のプラットフォームであったら、これほど頻繁に大規模なアップデートが行われることはなかったのではないか、と思います。どちらかというと、iPhoneの進化に乗っけてもらっているという感じですね。とてもありがたいことです。

今回のアップデートの目玉は、もちろんユーザーが作成したアプリをダウンロードできるApp Storeなわけですが、個人的には電卓に関数電卓機能が追加されるというのがポイントでした。実際に使うかどうかは別として、何というか、面白そうじゃないですか!

というわけで早速iTunesを7.7にアップデートし、iTune Storeにアクセスしてみると、真ん中の目立つ部分にソフトウェアアップデートのバナーがあります。クリックして条件に同意するとなんともあっさりダウンロードが始まりました。サイズは222.6MBとあります。ネットワーク環境によっては少し時間がかかるかもしれません。

ダウンロードが始まるとPCに接続されたiPod touchの更新が始まるのですが、これがかなり長時間かかります。明らかに今までの更新とは異なる挙動です。どうやら一度本体をフォーマットして、まっさらにした上でiPod touch 2.0 ソフトウェアをインストールしているようです。さすがはメジャーバージョンアップ。
途中「工場出荷状態に戻しました」というような恐ろしいメッセージが表示され、発売当初の悪夢を思い出してしまいましが、なんとか無事にアップデートが終了しました。

使ってみた感じですが、まず関数電卓はなかなか良い感じです。基数変換機能がないのが少し残念ですが、それ以外の機能は一通り揃っています。特に乱数生成機能があるのは良いですね。これでとっさに乱数が欲しくなったときも大丈夫です。

App Storeには既にたくさんのソフトが登録されています。動かしてみた中で面白かったのは、加速度センサーを使ってライトセーバーごっこをするPhoneSaberですね。ブロックスピーカーがあれば、iPod touchでも十分に感じが出ます。
LifeGameというライフゲームを再現するためのアプリや、iTarotというタロット占いのアプリもすごくよくできてます。

サービスイン直後なのにここまでのクオリティを持ったアプリが出てくるというのは、開発環境の優秀さを物語っているなあと感じました。これからどんなアプリが出てくるか、今から楽しみです。

インクリメンタル行ジャンプスクリプトを公開しました

このほど、久しぶりにPeggyのスクリプトを作成してみました。今回のスクリプトはi-gotoline.msというもので、インクリメンタルな行ジャンプを行うスクリプトです。

スクリプトを起動するとエディットボックスだけのダイアログが出ますので、そこに行番号を入力すると、そのたびに入力した行へジャンプします。エンターキーかエスケープキーを押すとダイアログを閉じます。

i-search.msで作ったカスタムダイアログボックスを使った操作を別の用途でも使えないかなあとずっと思っていたのですが、ある日「行ジャンプがインクリメンタルになったら便利なんじゃないか？」と思いつき、勢いで作ってみました。

ただ、実際に作ってみると、行番号は入力するたびに桁が上がり、大きく数値が変わるため、あまりインクリメンタルになりませんでした。「リアルタイム行ジャンプ」と言った方が適切かもしれないです(^^;

それでもなかなか便利な物ではあると思いますので、使ってみていただけると幸いです。