昔の最近の出来事(2013.03)

2013/03/31

AM中に起床。

もそもそと作文。「プロ遊」の下に「Emacsの雑記」という文書を置いてみました。 ご参考まで。

MinGW対応のgdcがgcc-4.8.0をベースにビルドできているようです。 今の所、アルファ品質、64bitターゲットはまだ、細かいバグ修正のパッチは未取り込み という感じのようですが、4.8.0をベースに作業されている事が判ったので リリースが楽しみです。因みにバイナリは bitbucketに置かれて いるようですが、ソースの方はgithubにまだコミットされてはいない模様。

昼頃起床。

もそもそと作文。

飲み会。日付越え前に帰着。

あまりの眠さに急速停止。

早めに帰着。

ちょろり調べ事。

気持ち遅めに帰着。

Web巡回して終了。

早くも無く遅くも無く。

ちょろり調べごと。

早めに帰着。

gcc-4.8.0対応されたgdcをFedoraでビルドしてみたり。 エラー無くビルド完了。簡単なソースのコンパイルは-m32も-m64も特に問題無さげ。

あ、そういや本日で本へっぽこページは13周年を迎えました。 毎度見てくだすっている方々には感謝致しますm(_'_)m ふにゃふにゃしているのは変わらずですが、これからもよろしくお願いします。

昼頃起床。

先日購入した「Land of Lisp」という本。O'REILLYの本ですが表紙に謎の 生き物のイラストが描かれている事が一部で話題になっています。 初版1刷が2013/2/22 なのに 既に2刷となっていたので思いのほか売れている のかも知れません。まだ最初の方しか読めていませんが、かなり自由に 書かれていて面白いです。

gdc。trunkは4.9向けにするようで、早速4.9のパッチがコミットされてます。

AM中に起床。

ちょろりお出かけ。色々散在。

gcc-4.8.0がリリースされた模様。gdcも4.8.0用のブランチが作られたようです。 trunkは4.9向けにメンテされるのでしょうか。それよりもMinGW向けが 追従できていないのが困るかも。

そういえば、Emacsで「C-x C-b」と言えば list-buffersが割りあたって いたのですが、これはカレントバッファを二分割するか、既に二分割以上 されていればフォーカスの無いバッファにバッファ一覧を表示します。 ただ、フォーカスの無いバッファに表示するものですから、 リストを使ってバッファの切り替えを行うのには「C-x C-o」でリスト バッファにフォーカスを移動してから操作するという流れになります。 で、確かMeadow2.xくらいからこのような感じになったと記憶している のですが、如何せんバッファ分割されるか否かが良くわからない ので思った場所に選択したバッファを表示したくても、思い通りに ならない場合がありました。
で、似たものに buffer-menu というのがあるのを知りました。 これは現在のバッファにバッファ一覧を表示を表示するので、 「C-x C-o」による移動も必要なければ、選択されたバッファは現在の バッファを切り替えるので、画面を分割表示していても思い通りの 位置にバッファを表示できます。 そんな訳でバインドを変えたのですが、list-buffersの「C-x C-o」が 必要なのに体が馴れてしまっていて、どうにも「C-x C-b C-x C-o」を セットで入力してしまいます(^^;
因みに buffer-menu はずっと前から存在していたものですが、 知ったのはつい数日前です(^^;;;; 毎回言ってる気がしますが、 長いこと使っているテキストエディタなのに未だに全容を知る事は できていません。多分これから先も知る事は無理だと思ってます(笑

ちょろりコーディング。

そういや、今日も東京スカイツリーからの電波試験が行われていて、 特に問題無い感じだったのですが一つ疑問があったり。 最近、東京MXは電波状態が悪くて映る方が少ない感じなのですが、 東京MXは既にスカイツリー発信に切り替わっています。 同じ電波塔からの電波を受信しているにもかかわらず、東京MX以外の局は 問題無く映って東京MXだけ電波状態が悪いのはなんで？と思ったり。

早めに帰着。

あまりの眠さに急速停止。

早めに帰着。

なにやらここ数日、gdcのtrunkが盛大に更新されていたり。 ちょっとしたファイルの整理レベルかと思っていたら、 かなり大胆な変更が加えられている模様。

ちょろりコーディング。

AM中に起床。

先日のemacs-w32でターミナル表示が遅い件の実験。

1. emacs-w32上でterm+でshellを起動し、更にscreenコマンドを実行。
2. 別途TeraTerm+Cygwinのshellを起動。1.で起動しているscreenに対して 「screen -x ????」(いわゆるマルチディスプレイモード)で アタッチする。
3. TeraTerm+Cygwinの方で emacs -nwを起動して操作する。emacs-w32の方は その操作をライブ表示という状態になります。

    ┌ emacs-w32──────────┐ | ┌ TeraTerm+Cygwin───────┐
    │┌ term+  ─────────┐│ | │　　　　　　　　　　　　　　　│
    ││┌ screen ───────┐││ | │　┌ screen -x  ─────┐　│
    │││┌ emacs -nw────┐│││ | │　│┌ emacs -nw────┐│　│
    ││││表示色々          ││││ | │　││表示色々          ││　│
    ││││(ライブ表示)      ││││ | │　││(こちらで操作)    ││　│
    ││││                  ││││ | │　││                  ││　│
    │││└─────────┘│││ | │　│└─────────┘│　│
    ││└───────────┘││ | │　└───────────┘　│
    │└─────────────┘│ | │　　　　　　　　　　　　　　　│
    └───────────────┘ | └───────────────┘

早めに帰着。

gccページが昨日からアクセスできなかったり。サーバが落ちているのか？

そういえばemacs-w32のtermというか表示全般。term+とか使っていると 表示が遅いのが非常に気になります。

早めに帰着。

ここ数日gdcのtrunkの更新頻度が上がっていたり。 不要なファイルを削除したり、色々と書き換えを行っている模様。 そういやgccもそろそろ4.8.0が出る感じなので、そこにはうまく合わせて 更新を終わらせて欲しいなぁと思ったりも。 それよりも、MinGWビルドの方が置き去りになっているのがいかんとも し難い感じです。バイナリ提供向けに4.6.xをメンテするのと同時に 4.8.xの方も野良ビルドはできるようにメンテしてもらえないかなぁ？ というのを期待しています。

昼過ぎ起床。

org-modeのLaTeX数式インライン画像生成で「プロ遊」の プログラミングリソース、「3D覚え書き(基礎)」と「3D覚え書き(応用)」 を再生成してみました。内容に変化は無いのでマイナーアップデートですが御参考まで。

アルファ付のPNG画像で文字色とバックグラウンド共に黒です。 透過表示ができないと真っ黒になるのですが、一応Emacs+w3mのインライン画像 表示で見ても大丈夫な感じに表示された(アルファの扱いが若干雑な気は しますが)ので多分大丈夫という事で。



画面左がorgソース。右がw3mでのインライン表示。org-modeでの数式インライン 表示は、何故か全ての式を一度にインライン表示できないようです。 上の画像では、ベクトルの長さを求める式はインライン表示できていますが、 ベクトルのスカラー倍の部分は元のLaTeX式のままになってます。 エクスポートにも少し時間がかかるので、LaTeXで式を書いてどんな 具合かちょっと確認するという程度の使い方しか想定していないの かも知れません。

トランスフォーマーリベンジ。どこまで実写でどこからCGか全然判りません。 ただ、カメラがグルグル回るシーンが多くて目が回りそうになったのは 歳のせいでしょうか(^^;

昼過ぎ起床。寝すぎ。

スカイツリーからの電波送信試験。今回は1時間ほど行うみたい。 ひとまず問題は無さげ。それにしても、どの局もデータ放送の方には 「現在スカイツリーから電波発信中」といった情報が乗っていないのは 残念な感じかも。

何気にorgモードでLaTeXの数式記述をインライン画像に変換する事が できるのですが、Meadowで使っていた時はそれがうまくいかなくて、 式だけのTeXファイルを用意して手で画像を切り出すという面倒臭い事を していました。で、何気にemacs-w32で試してみたところうまく使えそう だったので試しに使ってみたり。ちょっとハマり所があったり、 複雑な事はできないようですが概ね思い通りに書けたり。 org-modeで書いた文書本体とTeXで書いた式だけのファイルを管理 しなくてはならなかったのがorg-modeの文書本体だけで済むように なったのが良い感じです。

早めに帰着。

emacs-w32。なんとなくImageMagickを使うと 「... *** fatal error in forked process - failed to create new win32 semaphore, Win32 error 87」 が出るような気がしたり。ImageMagickを使わないようにすると ちょっと触ったくらいではエラー再現しなかったり。

ImageMagickの新しいのを野良ビルドしてリンクしてみたのですが、 なぜかtemacs.exeの段階で.elファイルを読み込んでいる最中にSegfaultで さっぱり動かなかったり。画像のロードライブラリでこんなに面倒臭い事 になるのか？因みに libsvgの方はリンクしても問題無く表示できるので、 やっぱりImageMagickに何かあるのかも。

そんな訳で、常用するemacs-w32はImageMagickサポートを外しておくこと にしたり。

あまりの眠さに急速停止。

早めに帰着。

Cygwinの emacs-w32が 24.3.1になり、テストリリースから正式サポートに 昇格したみたい。テストリリース版はインストールしてあっても、 うっかりするとインストーラーが古いバージョンを上書きしてしまう為、 定期的にパッケージをアップデートしている時に気を付けなくては ならなかったのですが、これで当面は気を緩めても大丈夫そう。

で、バイナリをインストールする前にソースをダウンロードしてこれまでに 加えた自前の変更などを取り込んでビルド。ひとまず使えそうな状態 になってからバイナリをインストールして、野良ビルドしたバイナリに 置き換えるという面倒臭い作業を行って無事乗り換え完了。

オリジナルではアプリアイコンがロードされるように修正されていた のですが、パッチに気づかずビルドしてしまったのでやり直し。 このとき、configure.acにパッチが当たっていたので autoconf とかからやり直したのですが、生成されたconfigureがエラーしまくり で困った事に。結局手でパッチを取り込んでビルドし直したりして 時間がかかってしまいました。

「... *** fatal error in forked process - failed to create new win32 semaphore, Win32 error 87」 の件は、オリジナルのバイナリでは直っている気が。でもパッチを あてた野良ビルドバイナリではやっぱり再現したり。 しかしながら、emacs-w32を使い始めてから、 エラー再現目的以外の操作でずっこけた事がなかったので、 普通に使っている分には地雷を踏む事は無いようです。

早めに帰着。

text-translatorのkill-ringの改行を変換する件。 改行を空白に置き換える仕組みは既に入っていて、 「(setq text-translator-do-fill-region t)」を.emacsに足せば良かったです。 「やっぱ使っているとこういうのも必要って思うだろうな」という開発者様の 気遣いがあったのでしょう。 そんな訳で、以下のようなテキストをkill-ringに入れた後、

   GDB command names may always be truncated if that abbreviation is
unambiguous.  Other possible command abbreviations are listed in the
documentation for individual commands.  In some cases, even ambiguous
abbreviations are allowed; for example, `s' is specially defined as
equivalent to `step' even though there are other commands whose names
start with `s'.  You can test abbreviations by using them as arguments
to the `help' command.

その略語があいまいであれば、GDBのコマンド名は常に切り捨てられる場合があ
ります。他の可能なコマンドの省略形は、個々のコマンドのマニュアルに記載
されています。いくつかのケースでも、あいまいな略語が許可されている、例
えば、 `sは名前の` s 'で始まる他のコマンドが存在するにも関わらず'特別
'ステップに相当するものとして定義されている'。に、 `help 'コマンドの引
数としてそれらを使用することによって略語をテストすることができます。

早めに帰着。

そういえば以前、text-translatorなる emacsから直接翻訳Webサイトにアクセスできるステキモードを知りました。しかし、 その後Googleの翻訳サイトへのアクセス方法が変わった為か使えなくなって しまってた時期があったのと、Chromeの「日本語に翻訳」を使うようになった事 もありしばらく忘れてました。で、久しぶりに何気に使ってみたところ、また使える ようになっていました。
でも、これは翻訳サイトの仕様なのでしょうけど、翻訳元の文章に改行が入っている とそこで文が切れた翻訳結果が得られてしまうのがイマイチだなぁと思ったり。 そこで、kill-ring(emacsのいわゆるクリップボード)から翻訳サイトに渡す前に 改行を空白文字に置き換えれば良好な結果が得られるんじゃね？と思い、 いじり所を探してみるのですが、どうやってkill-ringから文字列を取り出している のかよく判らなかったり。修行が足りません。

その後コードを眺めていると、なんとなく改行を空白に置き換えているような コードが存在しているのですが、どこに効いているのかイマイチよく判らなかったり。

早めに帰着。

ONEPIECE(69)。そういやチョッパーに「なにもするな」と泳がせたのは モネなのかな？と思っていたのですが、そのネタ回収をしてない 気がしたままモネは倒されちゃったので、あれ？と思ったりも。

AM中に起床。

本へっぽこのコンテンツである「MinGWでのGDCビルド手順」の TANEの作成したパッチファイルがアップロードされていないのに今頃気づきました(^^;;;;;; long定数の代入が化ける件(参考)の パッチも足してページをアップデートしました。役に立たないページになってて すんませんでしたm(_'_)m

よくページを見てみると、ビルドに使用するGDCへのgithubリンクも切れてしまってますorz。 うーむ、枝自体が無くなるとは思わなかった。そんな訳で、新しいのでビルドテストを してみたり。 新しいのでも本体ソース自体に変更は無いようだったので、パッチは1点だけリジェクト されたのを除けば基本的には前のままでOKそう。 そんな訳で明日付けになってますが「MinGWでのGDCビルド手順」アップデートしてみました。 御参考まで。

「ONEPIECE(69)」。ネタ振りとネタ回収でてんこ盛り。次巻で 何かしらカタが付くという感じでしょうか。

AM中に起床。

emacs-w32というかcygwin。 「... *** fatal error in forked process - failed to create new win32 semaphore, Win32 error 87」 の件で結局gdbでうまくブレークポイントを設定できないもんですから、 printf()デバッグしてみたり。といってもprintf()を直接使う事は できませんのでdebug_printf()なる関数を使用します。 この関数を使った場合、straceを使わないと仕込んだデバッグ文字を 表示する事ができません。しかし、straceを使用すると プログラム自体の実行が死ぬほど遅くなる為、エラーが再現する直前 までは普通に実行して、エラー再現をさせる直前でstrace --pid=xxx で アタッチしなくてはならないなどとにかく面倒臭いです。
で、やっぱり失敗しているのは確からしいのですが、その原因はやっぱり 判らず。なんとなくCygwinを介して管理しているものを、Win32API直接 実行で勝手に状態を変えてしまって、セマフォ管理が壊れていたりするのかなぁ？

そういや先日、アイコンがロードされないなぁ？ と思っていたのですが、ウインドの左上のアイコンはロードされてない のですが、エクスプローラやタスクバーには表示されてたり。 リソースとしては一応リンクできているみたい。

NTEmacsのパッチを元にIME対応してみたのですが、 C-s後にIMEを起動すると文字列入力がキャンセルされたり。うーむ。 予め検索したい文字列をRegionにコピーしておき、C-s後にESC-y でペーストすればサーチ自体はできたり。 元になったNTEmacsの方もダメなので対応がイマイチなのかも。
もう一度よく動作を見てみると、サーチ起動前に予めIMEで日本語入力 可能にしておくと「I-search []:」みたいな表示になるので、 ここでおもむろに文字入力をすると元のバッファにインライン表示 されるのですが、実はミニバッファを編集していて気にせず 入力すれば日本語文字列をサーチできます。NTEmacsも同じ。 でもこれでは日本語文字とASCIIが混在した文字列は検索できません。 まぁいずれにしてもMeadowのそれに比べればバグっていると言っていいレベル。

multi-term.elのバックバッファ編集機能がイマイチだという件で、 他に良いのが無いか検索していたところ、 term+.el なる存在を知ったり。特に「term+mux」を使うとscreenライクに タブによるシェルウインド切り替えが出来たりとかなり便利です。 勿論、バックバッファのコピーもマウス無しで出来たりとかなり 良い感じ。微妙にscreenコマンドとバインドが違っているので、 ちょいちょい混乱気味になるのは贅沢な悩みでしょうか。

気持ち早めに帰着。

あまりの眠さに急速停止。

早めに帰着。

emacs-w32。というかcygwinか？ 「... *** fatal error in forked process - failed to create new win32 semaphore, Win32 error 87」 をデバッグプリントを仕込んで調べたり。確かに失敗しているようなのですが、 なぜ失敗するのかはイマイチよくわからず。
失敗したときのエラーコードが87なのですが、これは ERROR_INVALID_PARAMETERで「パラメータが間違っています」という事らしい。 でも、CreateSemaphore()の失敗原因の中には前述コードを返す例が無くて、 このエラーコードが正しいのかも怪しい感じに思ったり。

早めに帰着。

あまりの眠さに急速停止。

早めに帰着。

emacs-w32。普通にCygwinのshellが使えるようになり、 ターミナルもemacs上で使いたくなってみたのでmulti-term.elを使ってみたり。 以前、Meadow3の新しいバイナリを 入れた時にansi-termを使うようにしたのですが、grepモードと共存できなかった為 ansi-termの方を封印してしまいました。現在はgrepモードの代わりに moccur-grepやmoccur-grep-findを使うようになったので、shellのLANGは ja_JP.UTF-8でも困らない感じになってます。

そんな訳で、普通にshellを使っているとちょっとファイルの中身を見たいとき ついlessとか実行する訳ですが特に問題無し。ちょっと1文字直したい時とかに ついvimを起動したりする訳ですが特に問題無し(笑。 ただ、折角広大なバックバッファを持ったターミナルになったのにも関わらず、 バックバッファに対する操作が弱いです。screenコマンドで言うところの 「Copy mode」的なものが必要なんじゃないか？と思ったりも。

早めに帰着。

そういや、スゲー4kデモとして有名な 「elevated」 ですが、我が家のPCでは何故か実行できなくて実際に動く様を見られませんでした。 どうやら、Win7用に動作可能なバイナリ(非公式バージョンみたいですが) じゃなくてはダメらしい事が判ったり。 因みにzipアーカイブのリスト表示は以下のような感じ。

$ unzip -l elevated_win7_test.zip
Archive:  elevated_win7_test.zip


 ___               __                  __                    ____  Scene.org!
/  //_____    _ __/ //_____.  _____ __/ //_____.     _____ _\\_ /___ ___
\__      /_ _____.  _/     |_\\_   \_   _/     |   _\\_   \_ _/    // _//_____
 _/     / _/     |  \      |   /    /   \      |  /   /    / \     \_ \_     /
 \______\ \      |___\_____|  /     \ ___\_____| /        /___\_____/  /    /
- ---_ ____\_____|-diP-_ _____\______\-bM--------\________\-----_ __________\-

                    ftp.scene.org - 'elektronik free art' since 11 March 1996

 [scene.org] upload to scene.org and get a free beer!
.                                                    .
  Length      Date    Time    Name
---------  ---------- -----   ----
     3451  04-10-2009 19:15   elevated.txt
     4079  09-02-2009 09:40   elevated_1024x768.exe
     4073  09-02-2009 09:40   elevated_1280x1024.exe
     4064  09-02-2009 09:40   elevated_1280x720.exe
     4074  09-02-2009 09:41   elevated_1440x900.exe
     4073  09-02-2009 09:41   elevated_1920x1080.exe
     4070  09-02-2009 09:39   elevated_1920x1080_hq.exe
     3190  11-03-2011 05:19   scene.org.txt
       59  11-03-2011 05:20   file_id.diz
---------                     -------
    31133                     9 files

AM中に起床。

デバッグ用にビルドしたCygwinを入れてみたのですが、なぜか 思った位置にブレークポイントを設定できず、どうにもエラーする瞬間を 捕らえる事ができなかったり。うーむ。

再現状況を見てみると、PDFファイルを表示した後に変になる感じで、 普通に画像を表示したりdiredを使っている分には特に問題無い感じ だったり。子プロセス起動で画像処理する(例えばフレームサイズにフィットする ように縮小表示するとか)ようなのがダメそうな予感。

そんな訳で、ここから野良ビルドしたemacs-w32で編集してみます。

そういえば、以前、「Tokyo Demo Fest 2013」が 開催されましたが、その時のデモが Pouetにアップロードされてました。 combined demoで1位になった「Artifacts」 を実行してみたり。ひとまず我が家のPCでは実行できました。 OpenCLを使用しているようなので恐らくNVIDIAのGPUでなくては 実行できないかも知れません(OpenCL.dllをベンダー提供のものに差し替えれば AMDでもいけるのか？)。特に圧縮している訳ではないようで、 OpenGLのシェーダーソースなどを見る事もできて参考になります。 フルスクリーンでしか実行できないので、どのシーンにどれだけの CPU/GPU負荷がかかっているのかはよくわかりませんが、 GPU負荷は50%(6角形のポリゴンが大量に飛ぶところ)以上 90%(最後の粒子)以下 という感じみたいでした。

粒子と言えば、「Breakpoint 2010」というデモパーティーで1位になった 「Agenda Circling Forth」 というデモが全編粒子で描かれているという強力なもので、 我が家のPCでは解像度を一番下げてもフレーム落ちせずに描けない 感じでした(ムービーも用意されているので正解はそちらを観るのが良いと 思います)。このデモもほぼGPUのみで描かれているようです。 GPUの使いこなし方で出せる絵の質が大きく変わるという感じです。

リアルタイムレンダリングのデモと言えば、最近だとスクウェア・エニックスの 「AGNI'S PHILOSOPHY」という テクニカルデモが凄いと思います。 因みに「Tokyo Demo Fest 2013」で 若干 DEMO違いな感じはあるものの、 AGNI'S PHILOSOPHYのスライド紹介やリアルタイムに爺さんの髭をエディット できる様の実演をしてました。このデモもCPUは殆ど使っていなくて、 GPUの使いこなして絵を出している様です。これくらいの絵が実際に ゲーム画面で操作できると驚くだろうなぁとは思います。
そういやPS4発表時に 本デモをPS4の実機で動かしたムービーが披露されたようですが、 もしPCと同程度の絵が出ているのならば、メモリ容量もそこそこあるので性能的に 当面は困る事にならないと言えるかも知れません。

emacs-w32。スクロールバーが古臭いのをどうにかできないかとMeadowの変更 ログを探ってみたところ、単に リソースをリンクすれば良さそうなだけと 言うことで手で足してみたり。一応新しい感じになってみたり。 リソースをリンクしたついでにウインドアイコンも追加されるかな？と 思ったらこっちはうまくロードできなかったり。こちらはCygwinのMailingListでも どうにかできそう という感じだったのでアップデートを待つ方向で。

昼前起床。

emacs-w32で「fatal error in forked process ....」が発生する件。 これってどうやらCygwinのメッセージらしい。子プロセスの生成に失敗 していてstackdumpが出ていたので、それからどこでずっこけているか 見てみたところ、src/process.c:create_process()の中のどこかで ずっこけているようですが良くわからず。

現在、CygwinのMailingListではemacs-w32を含んだemacsパッケージの テスト版についてスレッドがそれなりに立っているので、急速に安定する 事を期待したりも。

もう少しだけ調べてみたり。 「... *** fatal error in forked process - failed to create new win32 semaphore, Win32 error 87」 メッセージを出しているのはCygwinの winsup/cygwin/thread.cc:semaphore::_fixup_after_fork() 内 でした。

   3516 void
   3517 semaphore::_fixup_after_fork ()
   3518 {
   3519   if (shared == PTHREAD_PROCESS_PRIVATE)
   3520     {
   3521       pthread_printf ("sem %x", this);
   3522       /* FIXME: duplicate code here and in the constructor. */
   3523       this->win32_obj_id = ::CreateSemaphore (&sec_none_nih, currentvalue,
   3524                                               LONG_MAX, NULL);
   3525       if (!win32_obj_id)
   3526         api_fatal ("failed to create new win32 semaphore, %E");
   3527     }
   3528 }

早めに帰着。

emacs-w32に emacs-24.2-ime-2012-09-02.patch.tar.gzを当ててCygwinビルドしてみたり。 色々リジェクトされるので手で直す箇所が沢山あったのですが、なんとなく 動くようになってみたり。ついでにRSVG表示を活かしてみたり。こちらも いくつか修正が必要でしたが、なんとなく表示できるようになったり。
基本的にCygwinビルドなので、リモートアクセスにsshやscpをそのまま使えるし、 shell-modeもbashのままいけます。Meadow3.xではダメなtar.xzのdired閲覧や PDF表示もできるしで良い感じです。

なのですが、ちょいちょい 「... *** fatal error in forked process - failed to create new win32 semaphore, Win32 error 87」 てなエラーが出て、以降ディレクトリ読み込みや画像表示が全くできなく なる事があります。あとちょっとって感じなんだけどなぁ。 そう考えるとMeadowの安定度は抜群に高いと言わざるを得ません。

あ、そういやCygwinでビルドすると32bitアプリにしかならないのだけは イマイチかも。

あまりの眠さに急速停止。