Big Sky

この時をずっとまってた。

Google製の新しいコンパイル型言語Go上で動くGTK GUIライブラリ、go-gtkが今日、windowsで動いた。
Xming上で動いている様にも見えますが、ちゃんとwin32 nativeなGTKで動いてます。
まずは一般的なGUIのサンプル。

そしてgoroutineで非同期にtwitter public timeline(非streaming API)を読み込むサンプル。

だいたい動きました。ここ数日、cgoのwin32対応に関するsubmitが多くなってたので、そろそろ動くかなと思って着手しました。win32向けに対応した部分としては実はそんなに多くないです。go-gtkはイベントポーリングを自前でやっていて、その排他制御にpthreadを使っているんですが、win32だとpthread_mutex_lock/pthread_mutex_unlockでうまく排他制御出来なかった(gdkのスレッドと相性が良くないのか落ちる)ので、win32ではクリティカルセクションを使う様にお得意の#ifdefで修正しました。
gtksourceviewの一部で落ちるのを1件確認してますが、その他はほぼ動きました。

GUIが扱えるスクリプト言語は数ありますが、nativeにコンパイル出来てオブジェクト思考で、非同期(goroutine)が使えるGoでGUIライブラリがwindows上で動いたのは、正直大きいと個人的には思っています。

Goの高速なコンパイルと、Duck Typingによる自由度の高い型変換により脳内で設計した物が思考停止する事なくアウトプット出来るのです。
同じコードで比べないと比較になりませんが、C言語でcurlとgtkを使ってtwitterのpublic timelineをGUI表示(アイコン表示あり)というコードがあったとして、僕のノートPC(Intel Core i5)ではコンパイル/リンクがだいたい5秒程度くらいかかりますが、go-gtkの同等サンプルexample/twitterだと2秒くらいでビルド出来ます。

これからGoでGUIを使ったアプリケーションを作りたいという方にはぜひ試して欲しいと思います。

Goがwindowsで動き出してまだホヤホヤですが、これから普及していく事を望んでます。

「Go言語？もうピーク過ぎたよね？」とか言ってる人達こんばんわ。
Go言語、終わってません。いまdev-listではすごい量のメールが飛び交っていて、毎日かなりの量の議論が行われています。
僕としては、ようやく始まったと言えます。もうすぐWindowsでcgoも実行出来る様になります。現在dev-listには既にパッチが投稿されていて、レビュー中です。そろそろ出るんじゃないかと思います。
ただし現状cgoが無いWindowsでもダイナミックローディングが出来ない訳ではありません。syscall.LoadLibraryとsyscall.GetProcAddressを使ってライブラリ関数を取得し、syscall.Syscallで呼び出す事も出来ます。cgo待ってられない！って人でも今すぐDLLを呼び出す拡張モジュールが書けるのです。
今日はその方法を使って、GoからCOM(Component Object Model)を扱えるライブラリを書きました。名前は「go-ole」としました。

mattn/go-ole - GitHub

win32 ole implementation for golang

https://github.com/mattn/go-ole/

GO言語のstructを使って、vtblを作成しています。まぁ先頭ポインタからオフセットでメンバにアクセス出来る言語であれば大体実現出来ますね。
今のところ、プリミティブな型でしか操作出来ません。配列もSAFEARRAYで扱ってません。これからという所です。皆さんのパッチお待ちしています。
サンプルとしてMSAgentでおしゃべりする物が動きました。

go-oleだと以下の様なソースになります。簡単ですね。

package main

import "ole"
import "ole/oleutil"
import "syscall"

func main() {
        ole.CoInitialize(0)
        agent, _ := oleutil.CreateDispatch("Agent.Control.1")
        oleutil.PutProperty(agent, "Connected", true)
        result, _ := oleutil.GetProperty(agent, "Characters")
        characters := result.ToIDispatch()
        oleutil.CallMethod(characters, "Load", "Merlin", "c:\\windows\\msagent\\chars\\Merlin.acs")
        result, _ = oleutil.CallMethod(characters, "Character", "Merlin")
        character := result.ToIDispatch()
        oleutil.CallMethod(character, "Show")
        oleutil.CallMethod(character, "Speak", "こんにちわ世界")

        syscall.Sleep(4000000000)
}

よかったら遊んでみて下さい。

VCだとビルド出来るらしいけど、strawberry perlとかだとコンパイル出来ない。
まずCoro側のpatch。

diff -ur Coro-5.132.orig/Coro/libcoro/coro.c Coro-5.132/Coro/libcoro/coro.c
--- Coro-5.132.orig/Coro/libcoro/coro.c 2008-11-19 11:50:13.000000000 +0900
+++ Coro-5.132/Coro/libcoro/coro.c  2009-06-19 15:01:16.140625000 +0900
@@ -228,6 +228,9 @@
   #if __CYGWIN__
     ctx->env[7] = (long)((char *)sptr + ssize) - sizeof (long);
     ctx->env[8] = (long)coro_init;
+  #elif defined(__MINGW32__)
+    ctx->env[4] = (int)((unsigned char *)sptr + ssize);
+    ctx->env[5] = (long)coro_init;
   #elif defined(_M_IX86)
     ((_JUMP_BUFFER *)&ctx->env)->Eip   = (long)coro_init;
     ((_JUMP_BUFFER *)&ctx->env)->Esp   = (long)STACK_ADJUST_PTR (sptr, ssize) - sizeof (long);

mingw32のjumpbufは4番目がEipで5番目がEspだったはず。
一応手元で動いてます。
あとこのままでも駄目で、ExtUtils::MakeMakerがgccの時に付けてしまう--image-baseオプションがまずい。
アドレスの作り方が Coro::Event であれば Event という文字列に対して上位4バイト、下位4バイトで分けてunpackとかやってござる。

    if ($GCC) {
        my $dllname = $self->{BASEEXT} . "." . $self->{DLEXT};
        $dllname =~ /(....)(.{0,4})/;
        my $baseaddr = unpack("n", $1 ^ $2);
        $otherldflags .= sprintf("-Wl,--image-base,0x%x0000 ", $baseaddr);
    }

なので、Coro::Event が使っている Event というモジュールと --image-base がバッティングして起動時にメモリロケーション不正参照のエラーが起きる。
こちらについては、ExtUtils::MakeMakerに含まれる MM_Win32.pm を修正する。最近の gcc は勝手に --image-base 作ってくれるので、そちらに任せる。

--- MM_Win32.pm.orig    2009-06-22 17:48:43.906250000 +0900
+++ MM_Win32.pm 2009-06-22 17:49:05.703125000 +0900
@@ -307,12 +307,12 @@
 # we try to overcome non-relocateable-DLL problems by generating
 #    a (hopefully unique) image-base from the dll's name
 # -- BKS, 10-19-1999
-    if ($GCC) {
-       my $dllname = $self->{BASEEXT} . "." . $self->{DLEXT};
-       $dllname =~ /(....)(.{0,4})/;
-       my $baseaddr = unpack("n", $1 ^ $2);
-       $otherldflags .= sprintf("-Wl,--image-base,0x%x0000 ", $baseaddr);
-    }
+#    if ($GCC) {
+#      my $dllname = $self->{BASEEXT} . "." . $self->{DLEXT};
+#      $dllname =~ /(....)(.{0,4})/;
+#      my $baseaddr = unpack("n", $1 ^ $2);
+#      $otherldflags .= sprintf("-Wl,--image-base,0x%x0000 ", $baseaddr);
+#    }
 
     push(@m,'
 # This section creates the dynamically loadable $(INST_DYNAMIC)

SYNOPSISの例でもちゃんと動きます。

あとはバグ報告から上手く修正されれば...

以前書いた、「ブラウザを全く使わずにustream.tvを楽しむ方法」という記事、なかなか好評だったのですが、 IRCチャットはともかくスタンドアロンFLASHプレーヤがLinuxしかないので、Windowsの方にはそれ程ありがたい記事では無かったかもしれません。

※Linux版スタンドアロンFLASHプレーヤ

って事でWindows版のUstreamプレーヤを作りました。

• GUIツールキットはFLTK2
• FLASHはブラウザが使用しているActiveXだけを表示
• 入力エリアにチャネル名を入力するだけで再生

名前はFLTK2アプリケーションには必ずと言っていい程、先頭に「FL」が付くので、「flUstPlayer」としました。
実行画面はこんな感じです。

続きを読む...