Opera 10.5 for Linux/FreeBSD、Gtk対応 | エンタープライズ | マイコミジャーナルむむむー。まだ残念。
Opera Softwareは2009年12月22日(ノルウェー時間)、新しいJavaScriptエンジンやレンダリングエンジン、ベクターグラフィックライブラリを搭載したOpera 10.5 pre-alphaを公開した。Betanewsの計測によればOpera 10.5 pre-alphaの速度はChromeを陵駕しており、アルファ版ながらも大幅な性能改善をアピールしている。 2009年12月22日に公開された段階ではWindows版とMac OS X版が公開されていた。2009年12月31日(ノルウェー時間)、Unix版も公開。FreeBSD/i386版、FreeBSD/amd64版、Linux/i368版、Linux/x86_64版が用意されている。
http://journal.mycom.co.jp/news/2010/01/05/040/index.html
2010/01/06
opera-10.50-6177.linux.i386
期待出来そうだったので動かしてみた。
2010/01/01
あけましておめでとうございます。
昨年は自分で思っていた程にはアウトプット出来なかった気がします。が...本年も気を張りすぎずに、笑って貰えてちょっぴりタメになる技術をブログにして行きたいと思います。
本年も宜しくお願い致します。
本年も宜しくお願い致します。
2009/12/31
非同期UI
最近、GoのGTKバインディングを作ってるのだけど、先日ようやく簡易twitterクライアントを作れるまでに至ったのだが、そのtwitterクライアントの「タイムライン更新」ボタンを押した時に画面をブロックさせずに画面を更新する方法を考えてた。
Perl-GTKならばCoroを使ってこうするだろうか。
平たく言うと、スレッドを使う予定の無かったUI処理を、スレッド対応にするには多少のコード修正が必要になるという事です。
今回、goで作った簡易twitterクライアントの「タイムライン更新」ボタンを非同期対応するのに費やしたコードはたった2行。元のコード
そう、goroutineはスレッドじゃない。
故に上記の様な 「
UIの開発に有利な言語にはある程度、共通する物があると思う。
goにおいては上記3点あてはまるが、デストラクタが無いのが一番の難点。
これからのUIはどんどん非同期な物になって行くんだろうな。
10年程前のUIと言えば、非同期なUIはあまり見られなかった。VB6においても定期的に「
Perl-GTKならばCoroを使ってこうするだろうか。
use strict;
use warnings;
use Gtk2 '-init', '-threads-init';
use AnyEvent;
use Coro;
use Coro::Timer;
my $window = Gtk2::Window->new('toplevel');
$window->signal_connect(
destroy => sub {
exit;
}
);
my $vbox = Gtk2::VBox->new;
my $button = Gtk2::Button->new('click me');
$button->signal_connect(
clicked => sub {
$button->set_sensitive(0);
async {
Coro::Timer::sleep 3;
Gtk2::Gdk::Threads->enter;
$button->set_sensitive(1);
Gtk2::Gdk::Threads->leave;
};
}
);
$vbox->add($button);
$window->add($vbox);
$window->show_all;
Gtk2->main;
ここでCoro::Timer::sleep
しているのは、生のsleep
を使うとCoroがスケジュール割り当てとして介入出来なくなるのを回避する為。非同期で動作はするものの、スレッド動作になるので「Gtk2::Threads->enter
」と「Gtk2::Threads->leave
」でUIに関連する処理をブロックしなければなりません。つまり例えばボタン押下時の処理が5段階あり、その都度UIの何かしらを変更しなければならない場合、「Gtk2::Threads->enter
」と「Gtk2::Threads->leave
」でそれぞれブロックしなければならない事になります。平たく言うと、スレッドを使う予定の無かったUI処理を、スレッド対応にするには多少のコード修正が必要になるという事です。
今回、goで作った簡易twitterクライアントの「タイムライン更新」ボタンを非同期対応するのに費やしたコードはたった2行。元のコード
button.Clicked(func(w *gtk.GtkWidget, args []unsafe.Pointer) {
button.SetSensitive(false);
if r, _, err := http.Get("http://twitter.com/statuses/public_timeline.json"); err == nil {
// タイムライン取得、表示処理
}
button.SetSensitive(true);
}, nil);
となっていたコードに「go」で実行されるブロックを追加しただけ。
button.Clicked(func(w *gtk.GtkWidget, args []unsafe.Pointer) {
button.SetSensitive(false);
go func() {
if r, _, err := http.Get("http://twitter.com/statuses/public_timeline.json"); err == nil {
// タイムライン取得、表示処理
}
button.SetSensitive(true);
}();
}, nil);
何が言いたいのかというと、groutineはgo組み込みであって、Coroがsleepやhttp_getを置き換えようとしている(CORE::GLOBAL上書きもあるけど)物とは違い、言語として非同期をサポートしているという事。もちろんgoにおいてもボタンクリック時にsleepを呼ぶとUIはブロックされるのだけど、実際sleepなんて使わないし、そもそもgoroutineはスレッドじゃない。そう、goroutineはスレッドじゃない。
A Tutorial for the Go Programming Language実際にはgoが内部でscheduleを行って実行する処理連鎖で実現している。なのでgtkを呼び出す場合においてもgdk_threads_enter/gdk_threads_leaveを呼び出す必要もない。なぜなら並行とは言えど同時実行ではないのでコンテキストスイッチも意識しなくて良い。
Go has its own model of process/threads/light-weight processes/coroutines, so to avoid notational confusion we call concurrently executing computations in Go goroutines.
http://golang.org/doc/go_tutorial.html
故に上記の様な 「
go func(){}()
」ブロックだけで非同期処理が書けるという訳。例えばcursesでCUIアプリを書いても画面が崩れる事は無いだろう(未確認)。UIの開発に有利な言語にはある程度、共通する物があると思う。
- 匿名関数をコールバックとして扱える
- サードパーティでも良いので非同期処理の仕組みがある
- GCが効く
sub {}
」で匿名関数が使えるがので優秀だが非同期となるとスレッドに頼らざるを得ないのが難点。rubyも同様。pythonは匿名関数が使えないのが少し悲しい(でもpygtkは好きだ)。結局の所、メインループと非同期処理をどう扱うかがネックになっている。例えば各言語でCOMを扱う場合、STA(Single Thread Apartment)しか対応していないCOMは、言語側でメインループをグルグル回すしかない。まぁ言語として用途が違うんだ(JavascriptはそもそもUI記述言語だろ...とか)から、比べちゃならんだろ...とも言えるし。goにおいては上記3点あてはまるが、デストラクタが無いのが一番の難点。
これからのUIはどんどん非同期な物になって行くんだろうな。
10年程前のUIと言えば、非同期なUIはあまり見られなかった。VB6においても定期的に「
DoEvents
」を実行してプログレスバーを更新するという、なんちゃって非同期処理が横行していた頃だ。最近はVB.NETでコンポーネント自身がスレッドサポート(実際にはデリゲート)しているので簡単に非同期処理が書ける様になったが、これら全てにおいてもやはり非同期対応するつもりの無かったUI処理を、非同期対応にするには多少のコード修正が必要になるには違い無いし、その点でgoには期待している。