RSS

日々のメモ書き

Debian Developerが綴るメモ

U-17 ブラジル戦

ハポンコールに日本の選手を慰めるブラジルの監督。つらいな。

荒れたピッチは同条件だけどきれいなピッチでどこまでブラジルとやれたのか見たかった。さすがに日本の技術では同等のブラジルでは簡単にかわせない。そこでブラジルとのフィジカルの差が出てしまったというところか。体は飛ばされるしドリブルは置いつけないし。肝心なところでの残念守備というのもあったが。やっぱり出たつまらないミスとか。

ブラジルはペース無視で中盤を潰しにきて見事に点を取ったというところか。60分過ぎたあたりからきちんと体力切れになっていたのだからちゃんと守り切っていられたらと思う。それにしても恥ずかしげもなく中東戦法を使うブラジルというのもなかなか…。GKにはイエロー出たのかな。高木のスライディングが最大のチャンスだったか。あそこの位置取りがわかっている人ならもう一歩前に出られたはずで…。

あともうちょっと。日本のサッカーの形ができつつありその形は世界に通用するなというのがわかった大会だった。

JavaでGTK+

すでに書いたようにメモリリークの問題があるので正常に動作しないのではあるが…。ロジックとしては正しくできた。さて、いくつかの感想。

  • 4.0.15はGTK+2.16に対応。色々使えない…。Widget.Drawは使えない…。Java-Gnome-4.1でGTK+3に対応なのか?
  • Windowに直接描画できない。DrawingAreaを追加して描画する必要がある。GTK+の対応が古いため。
  • g_timeout_addではなくて java.util.Timerを使う。無形クラスやらいろいろ楽しいな。
  • 範囲付きのdoubleの乱数も返せないの?自分で実装?
  • Cairoで直接文字が直接書けない。Pangoを使ってやる必要がある。
  • JavaもJavaで変なところあるよなあ。
  • java at master from takaki/gsvolley - GitHub

Java-Gnomeでメモリリーク

GTK+で書いたプログラムをJavaに移植してみた。移植作業自体は順調に進んで、同じような動作をするところまでこぎつけた…と思ったら問題発生。メモリを食い潰していく。はぁ?Javaだぞ、なんでだと思った。どうも画面の書き直しあたりでおかしいところまではわかった。JNIを使っているから変なことになってんのかなと思ったりもしつつ…。

ここでメモリリークを調べるツールを導入だとEclipse TPTPを導入した。しかし、なぜか、モニターが起動しない。そこでごにょごにょ探すとlibstdc++5が必要だと。そんなのどこで調べたらわかるんだか。

なんとかTPTPをインストールしてメモリのプロファイルを取る。あれ?とてもリークしているように見えない。

ふとtopを見るとjavaではなくてXorgがメモリを使っていた? Xサーバーのメモリですか。どういう加減かいまいちわからない。最小再現コードがきちんとできたので置いておく。new Context(widget.getWindow())かw.setSizeRequest(640,400)のどちらかがなければメモリリークの現象は起こらない。どういう状況なのかいまいちわからない…。

ちなみにJava-Gnomeのバージョンは4.0.15。4.1でGTK+3に対応するように見えるので、そうなると描画周りが変更になるのであまり深く追求する気にもならない。

import java.util.Timer;
import java.util.TimerTask;

import org.freedesktop.cairo.Context;
import org.gnome.gdk.Event;
import org.gnome.gdk.EventExpose;
import org.gnome.gtk.Gtk;
import org.gnome.gtk.Widget;
import org.gnome.gtk.Window;

public class LeakMemGTK {
	public static void main(String[] args) {
		Gtk.init(args);
		class EventLoop extends TimerTask {
			final Window w;
			EventLoop(Window w) {
				this.w = w;
			}
			public void run() {
				w.queueDraw();
			}
		}
		final Window w = new Window();
		Timer timer = new Timer(true);
		w.connect(new Widget.ExposeEvent() {
			public boolean onExposeEvent(Widget widget, EventExpose event) {
				new Context(widget.getWindow());
				return false;
			}
		});
		w.connect(new Window.DeleteEvent() {
			public boolean onDeleteEvent(Widget arg0, Event arg1) {
				Gtk.mainQuit();
				return false;
			}
		});
		EventLoop task = new EventLoop(w);
		timer.scheduleAtFixedRate(task, 0, 10);

		w.setSizeRequest(640, 480);
		w.setResizable(false);
		w.showAll();
		Gtk.main();
	}
}

U-17 ニュージーランド戦

録画中継しか見れないので結果が目に入らないように逃げ回っていた。

なんでこんなに差がついてるんだ?ニュージーランドが弱すぎるだけなのか?監督は勝って兜の緒を締めよなのかまだまだ課題が多いと言っているが…。

非常に状況判断が上手いな。相手がプレッシャーかけてきても慌てず、むしろそのせいで崩れたバランスを利用して相手をかわしていた。相手はどこでしかけたらいいのかわからない状況になっていた。真ん中入れて戻してサイドに出してというのがうまく機能していた。前半は特に右サイドの崩しがきれいに決まっていた。バルサに似ているとかなんとかってのもだんだん納得しそうになる。

秋野のボールの散らしが効果的。武蔵は空回りというか…右サイドに張っていてではちょっと難しい面があっただろうか。一人だけ違うリズムでプレーのは良いところだと思う。

次はブラジル戦か。ここでどのような戦いができるかで本当の評価ができると思う。楽しみな試合である。

C++でGTK+

つぎはC++でGTK+を使ってみる。つまりgtkmm。

Gtk::Windowを継承してアプリケーションのクラスを作るというところで設計が違ってきた。いろいろな初期化やシグナルの登録がコンストラクタでやることになった。アプリのインスタンス内でいろんな情報を保持してくれるので楽は楽。

signalの扱いが最初面倒。sigc++を使っているが最初は何をやっているのかわからなかった。直接関数が渡せないで関数を引数としたクラスのインスタンスを作って…という流れだった。そうするとシグナルコネクションのクラスが帰ってくるのでそれを操作…という流れ。なかなかややこしいが慣れるとわかりやすい。

C++で書いたのも久しぶりなのでわけのわからんことに。生ポインタを使わないんだよねーとauto_ptrもdeprecatedってそんな話も聞いたっけなーとか。constメンバ関数なんて忘却の彼方だよーはっはっは。だけど静的にエラーをチェックするという機能においてはC++はよく考えられているなーと思った。

非常にはまったのかsignal_key_pressの処理。なぜかカーソルを拾ってくれないなーと調べたらconnectの第二引数にfalseを渡して処理する順番を変えてもらう必要があった。先に別の何かがカーソルだけは拾ってしまうようだった。window managerかな?でもなんでgtkmmで起こったんだろう?

いろいろと設計の不具合や無駄な処理がわかってきたなと思っているのでこれをなんとかする作業が必要だろう。ただanjutaはリファクタリングがまだ弱い…。

cpp at master from takaki/gsvolley - GitHub

U-17 アルゼンチン戦

圧勝ですな。

個人技術・個人戦術・テーム戦術のどれを取っても圧勝。勝つべくして勝った試合だった。個人技術では最初のタッチで、特にトラップで、相手が取れない位置や次の展開ができる位置にきちんとボールを置くことができていた。

難点は焦ってミスしてボールを取られるということを何回も繰り返していたこと。ちょっと落ち着いてボールを扱えばさらに一方的な展開にできただろうにと残念だった。失点シーンはちょっとなあ…。気が抜けていたんだろうけど。

しかしアルゼンチンは大変残念なチームにだった。大泣きしていた選手もいたようだが…。3位抜けができたのだろう?

U-23 クウェート

無事に勝ち上がれたが課題は多い。

2戦とも失点シーンは崩されたというよりは軽率なプレーが原因が残念で仕方がない。セットプレーから放り込まれたボールを適当なマークでシュートを打たれる、本来余裕を持って対処できる状態なのに相手をひっかけてPKを与える。審判がまともだったからあの程度ですんだというべきだろう。

前半はいい加減なピッチを考慮していろいろすっとばしたつなぎでなかなかいい感じの攻めだったのいな。後半はなんであんなにぐだぐだになったのだろう?

後半25分ぐらいからさすがにクウェートも足が止まってきたのでさすがに崩されるということもなくなってきたが…。最終的にはいつもの面白中東サッカーに巻き込まれたのは反省すべき残念なことだった。

あと人間力は落ち着け。うっとうしくなってめずらしく地上波に切り替えてしまった。

PythonでGTK+

普通のGTK+で書いたプログラムをPythonに移植してみた。まあ、割と素直。ほぼ直感通りでgtk+の関数とPythonのインスタンスメソッドのマップがされていた。まだGTK+2版でしかないのでGTK+3のソースからGTK+2へのやり方に戻す必要があった。本当に必要なのはdrawからexpose-eventに変わったところぐらい。

CairoContextをひっぱりだすところがちょっとまよったがexpose_eventに渡されるwidgetからwindowを取り出してcairo_create()でよかった。その流れが最初わからなかった。あとKeyEventの処理。gtk.gdk.keyval_name()を使ったのだがそれでよかったのかな? GDK_KEY_a とかないよなあと思ったでの…。

クラスの備わった言語で書いてみましたという例。

python at master from takaki/gsvolley - GitHub

U-17 フランス

録画放送なので結果は知ってみていた。前半に先制したフランスが流し気味なのはわかるが後半同点に追いつかれてからは日本が押していたと見るべきだろう。ほんのちょっとシュートがまともだったら十分に逆転に成功していた。結果自体は引き分けで良しというところなんだろう。

後半は完全に試合を支配して調子のよいパス交換からの突破も何度も見られて期待が持てる。非常に高いレベルでチームが仕上がっているのがわかる。

さて、見ていてさらに思ったのは日本の選手の技術の高さ。ついに基礎的な個人技術、トラップ・ドリブル・パスあるいは1対1の守備、がヨーロッパのレベルを越えてしまったようだ。フランスはアフリカ系の選手ばかりなのだが、そのフランスのU-17はその身体能力で技術の低さなんとかカバーしていたように見えた。今まで若年層がアフリカ系の選手と当たるときにはどうしても技術だけでは補えない部分をチームプレーでなんとかカバーしていた。しかし見ていて、たしかに普段ではありえない足の伸ばされ方でボールを奪われる場面はあったにせよ、それを技術だけで対処する能力があり、必死さを感じない普通のプレーで相手をかわすようになってしまっていた。

今回のチームにはまだ天才と呼ばれるような選手はいないようだが全員が高いレベルでの個人技術と個人戦術が徹底されているようだ。このまま行けば結構なところまで行くだろう。

Plone 4.0.7更新

Plone更新。

  • Plone 4.0.7にupgrade
  • sc.social.like を導入。これで全部のページにlikeがついた。

しかしどことなく調子が悪い…。

< 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 >