[devel][c#] フォームとスレッド
vs2008のc#で。
デフォルトの状態のまんまのFormにLabelを一つ貼り付けて、Dockはfill。これに適当に文字を入れただけのもの。
これを、ThreadPool.QueueUserWorkItemで表示すると、Labelの部分が欠けて、あるいは透明になって、裏が透ける状態になる。
マウスポインタをもっていっても、時計状態。
どういうこと？
using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;
using System.Threading;
namespace FormInThread
{
static class Program
{
/// <summary>
/// アプリケーションのメイン エントリ ポイントです。
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
var f1 = new Form1();
ThreadPool.QueueUserWorkItem(new WaitCallback((Object obj) => f1.Show()));
Application.Run();
}
}
}アラートソフトなんかで、アラートフォームを表示してるのはスレッドじゃないんだろうか。
それにしても、久しぶりにC#を触ったらほとんど忘れてた。
0からじゃないものの、1.5くらいから勉強し直し。
まったくの入門からやるのはだるい感じだし、中級編にはまだ歯が立たない、という中途半端さ。
[cygwin] w3m 0.5.3-2のコンパイル
cygwinでw3mのバージョン 0.5.3-2をソースからビルド。
色々トラブったのでメモ。
cygportsというツールを使ってビルドするらしい。
cygport 入門 - BOOLEANLABEL
cygport w3m-0.5.3-2.cygport all
全部用意が出来てれば、/usr/src、つまりw3m-0.5.3-2.cygportがあるディレクトリで、これでいけるらしい。
が、色々エラーが出た。
autopointがなんたら、はgettext-develをインストール。
syntax error near unexpected token `SSL,' w3m AC_MSG_CHECKING if this token and others are legitimate, please use m4_pattern_allow.
この辺のエラーについては、ちょっと混乱。
pkg-configをインストール
ディレクトリw3m-0.5.2-2に降りて、
aclocal -I .
次に
autoconf
を実行。
エラーが出るので、もう一回やる。
するとなぜか通る。
ここで自分で、configureしてみる。
エラーが出る。
ひょっとしたらと思って、上のディレクトリに戻って、上述のcygportを実行。
automakeの実行 - hippos-lab::net
Dovecot - Secure IMAP server
cannot find "-lX11"
これは、libx11-develのインストール
もう一回cygport。
これで成功。
w3m-0.5.2という兄弟ディレクトリが作られてて、そこに実行ファイルなどが入ってる。
[Firefox][userscript] Google Reader Full Feed Modとcookieと
ないと困るものの一つのGoogle Reader Full Feed Mod.user.js(GFM)で、2件ほど。
autopagerのパラメータ、Loading next pageの値が保存されない。
813行目辺りの関数定義を、
var notN = function(a) { var r = Number(a); return (r == NaN) ? true : false; };
こんな感じに。
これで保存されるようになった。
もう一つ。
なぜか何かのタイミングで設定がごっそりと消えることがよく起ってた。
で、よくよく調べてみたら、どうやらCookieSwapでプロファイルを切り替えたタイミングらしい。
で、GFMは設定をlocalstorageに保存してる。
ブラウザ別、localStorage の削除に関わる所作 :WEB 職人によると、Fxではcookieとlocalstorageは、セットで管理されてるらしい。
だから、cookieを消すと、localstorageも消えるらしい。
多分、cookieswapの動作はcookieを消すことに相当するってことなんだろう。
以上をふまえて、GFMの"localStorage.setItem"、"localStorage.getItem"を、greasemonkeyというか、UserScriptLoaderの"GM_getValue"と"GM_setValue"に置換。
これでデータがprefs.jsに保存されることになる。
速度的にはちょっと不利なのかもしれないけど、とりあえず普通に動いてる感じ。
[devel][python] buildoutを使い始めるためのメモ
いくつかgaeのアプリケーションをpython2.5で作ってきた。
2.7も試したけど、個人的な用途ではあんまり旨味がなかったので、スルーしてきた。
でも、2.7でしか使えないライブラリなんかも追加されてきて、ちょっと触手を伸ばしてみようかと。
vertualenvで切り替えるのもいいけど、せっかくなので、同じような文脈でよく目にしたbuildoutを試してみることに。
参考にしたのは以下の二つのサイト
以下そのメモ。
疑問点、わからないところなども含む。
イントロ
buildoutはだいたい、cのmakeやjavaのantに当たるPythonのツール。
どっちかって言うとantに近いような。
Makefieleやbuild.xmlに相当するものは、buildout.cfgというコンフィグファイルで、これにやりたいことを書く。
ユースケースとしては、
などなど
ありがたいことに、そういったケースについて、buildout.cfgを公開してくれてるサイトがある。
だから、それをもらってきて使えば、詳細を知ることなく、その恩恵にあずかれる。
例えば、Google App Engine (GAE/py) の開発環境をつくる - 清水川Webなど。
ここで、mynewgaeappをプロジェクトルートとする。
上記のようなサイトのbuildout.cfgをコピペして、その上のディレクトリに保存してあるとする。
mkdir mynewgaeapp cp buildout.cfg mynewgaeapp cd mynewgaeapp buildout
これだけで、サブディレクトリを作って、必要なライブラリをダウンロードして、開発環境を作ってくれる。
インストール
makeやantoと大きく違うのは、buildoutは、基本的には、プロジェクトごとにインストールして使う物らしい。
では、そのbuildout自体を、どうやってインストールするか。
これには三つの方法があるらしい。
- bootstrap.py
- zc.buildout.eggをシステムのpython（以下、system python）にインストールして、そのbuildoutを使う。
- 最初だけ他のプロジェクトのbuildoutを使う
いろいろ見たページで一番多いのはbootstrap.pyを使うものだった。
これは、その名の通り、bootstrapを行う。つまり、buildout自体、その最新版をダウンロードしてきて、使える状態にしてくれる。
三番目のは、使い始めの段階ではパス。
で、厳密には一番目がいいんだろうと思う。けど、面倒なので僕は2番目の方法で。
pip install zc.buildout
これで、system pythonのScriptsディレクトリにbuildoutコマンドがインストールされる。
そこにパスが通っていれば、冒頭の通りに使える。
実行方法
インストール後は、基本的には、プロジェクトにある"bin/buildout"を実行。
partsを個別に実行する時は、"/bin/buildout install parts名"らしい。
なんでinstallなのかはよく分からない。
ルート直下の"install.cfg"に実行ログが書かれる。
自分で一から始めるには
mkdir newproj cd newproj buildout init
これで、必要なディレクトリが作られ、プロジェクトルート直下のbinディレクトリにbuildoutがインストールされ、プロジェクトルートに、buildout.cfgの雛形が作られる。
プロジェクトのソースファイルの置き場所は、基本的にはプロジェクトルート。
ディレクトリ構造はネストするより浅く広くがこのツールのポリシーらしい。
そうは言っても、ルート直下に"src"ディレクトリを掘ってその下に置く例もある。
その他の構造はDirectory Structure of a Buildout ― Buildout v1.2.1 documentation
buildout.cfgの書き方
個人的に一番多いユースケースは、サンドボックスでライブラリを試すこと。
だから、このケースに沿ってメモ。
概要
makeのルール、あるいはターゲットとコマンド行、antのターゲットとタスクに相当する物は、それぞれ、partsとrecipe。
recipeは、例えば何かのフレームワークのダウンロード、インストールを行って開発環境を設定する、などという一つのまとまったことを丸ごと行ってくれるものが多い。
partsは実質、このrecipeのオプション設定を行うもので、各partsにrecipe一つという形式。
antなどのように、一つのターゲットに、タスクを複数、ということはない。
そしてrecipeはたいていpypiにあるけど、名前さえ指定すれば、buildoutがダウンロードしてきてくれる。
至れり尽くせり。
文法
書き方は、PythonのConfigParserのフォーマットプラスα。
つまり、基本は
[ヘッダ]（ヘッダ） name=value（オプション）
で構成されるセクション、という構造で書いていく。
αの部分は、
- makeなんかにもある変数の置き換えマクロ
- 大文字小文字の区別。
- コンフィグファイルの継承に伴ったオプションの付け替え
この最後のやつはここでは省く。
基本モジュールを作っておいて、あとでそれをインクルードして変数設定して使うとかそんな感じかと。
基本型
buildoutセクションのpatrsオプションにpartsの名前を並べる。宣言か。
parts名は任意。
そしてそれに応じたpartsセクションを作って、partsの中身を定義する、という形。
各partsには、それぞれ一つのrecipeを置き、そのrecipeのオプションを設定していく。
逆に、recipeとそのオプションを設定するのがpartsセクションだと考えたほうがいいのかも。
[buildout]
parts= foo bar
[foo]
recipe=baz.quxw
quxwopt1=value1
quxwopt2=value2
[bar]
recipe=baz.quux
quuxopt=${hoge:fuga}
[hoge]
fuga=piyobuildoutセクションで、"foo"と"bar"という二つのpartsの使用を宣言。
パーツ"foo"セクションのrecipeオプションでrecipe"baz.quxw"の使用を設定。
その"baz.quxw"が要求するquxwopt1とquxwopt2に値を設定、という形。
ここでhogeセクションはpartsセクションじゃない。recipeがないので。
なにかrecipiがオプション設定にそういう書き方を要求するとか、置き換えマクロで使うような変数を書いたりする時に、こういうセクションが使われる。
パーツbarのセクションのquuxoptが変数置き換えの例。
${セクション名:オプション名}の形で参照できる。
ここでは、hugeセクションのfugaオプションの値を参照している。
buildout.cgの例
実際に動く形で。
適切かどうかは分からない。
ライブラリsimplejsonをサンドボックスで試すケース。
僕は、普段python25を使っているので、python2.7のサンドボックスを作ってみる。
[buildout] parts = tryjson python=python27 unzip=true include-site-packages=false [tryjson] recipe=z3c.recipe.scripts eggs=simplejson interpreter=myp [python27] executable=C:\lang\Python27\python.exe
という感じになる。
ここでは、z3c.recipe.scriptというレシピを使っている。
これは、こういう用途に使うものらしい。
そして、その設定をするためのpartsセクションをtryjsonという名前で作っている。
buildoutセクションのオプションのリストはzc.buildout Predefined buildout options
その下のほうにも、散発的にオプションが出てくる。
ここでは、buildoutセクションのpythonオプションでターゲットとなる処理系をしている。
include-site-packagesオプションで、site-packageを切り離し、あとは、site-customizeをオフにする設定を加えるだけ。ほぼ完全にvertualenv代替という感じか。
partsであるtryjsonセクションの"interpreter"オプションは、recipeである"z3c.recipe.scripts"のもので、要は"sys.path"を適切に設定したpythonの起動スクリプトをこの名前で作ってくれる、というものっぽい。
だから、このプロジェクトで使うpythonは、"bin/myp"で起動することになる。
じゃあ、shebangとかもそう書けってことか。
じゃあ、emacsのpython-modeとかから利用するのはどうするんだろう。
一時的にsetq？
実際の利用方法
recipeを探す
recipeのリストを見て、自分の要求に合う物を選び、組み合わせてbuildout.cfgを書く。
recipeの所在は、
- Buildout Recipes ― Buildout v1.2.1 documentation
- Index of Packages Matching 'buildout recipe' : Python Package Index
とかなんだろうか。
PyPI以外のところにあるrecipeを使う時は、buildoutセクションのオプションに、それを設定する項目がある。
parts間の依存関係
例えば、antのタスクの実行のためのフラグプロパティみたいなものはないみたい。
recipeはそれ自体で一通りのことをするので、たいていはparts間の依存性は気にしなくてもいい感じ。
だけど、例えば、他のpartsセクションで設定したoption値とかを参照する時は、依存性が生じる。
無理矢理作った例
[buildout]
parts = p1 p2 p3
[p1]
dummy = 1
[p2]
recipe = collective.recipe.template
input = inline:
#!/bin/bash
echo ${p3:foo}
output = out.sh
[p3]
recipe = mr.scripty
foo = return "from p3"
[parameter]
foo = 10
bar = 20partsセクションのp3で設定したオプションfooの値をpartsセクションのp2で参照している。
p2で使ってるrecipeは、テンプレートからファイルを作ってくれるもの。
こういうのはいくつかあるみたいだけど、ここではbuildout.cfg自体にテンプレートを書けるものを使った。
p3で使ってるrecipeは、オプションの値の設定にpythonのスクリプトを書けるようにするもの。
実はセクションをクラスにして、そのオプション名のインスタンスメソッドを作ってるらしい。
だから、returnで値を設定、ということになる。
で、p3で設定したオプションfooの値を、p2のテンプレート中で使ってる。
p2のインストールだけをした場合、どうなるか。
ともあれ、これを実行する
>buildout install p2 Getting distribution for 'mr.scripty'. Got mr.scripty 1.0b3. Getting distribution for 'collective.recipe.template'. Got collective.recipe.template 1.9. Installing p2. >cat out.sh #!/bin/bash echo from p3
p2のインストールを指定しただけだけど、きちんとp3が実行されて、それを反映したファイルができてる。
オプションの値の参照関係なんかは、きちんと拾ってくれるみたい。
ローカルなrecipeの使い方 :search:
マニュアルでやってること
pythonの対話モードでwrite()でbuildout.cfg書いたり、cat()でその中身を確認したりしてる。
なんだろうと思ったら、zc.buildout.testingをimportすると使えるみたい。
[Firefox] firefox17とminibufferとldrizeとUserScriptLoaderとtombloo
Firefox17にアップデートした。
使ってるアドオンはだいたい動いた。
Easy DragToGo+は、拖拽 展：Easy DragToGo+ 1.1.7 BETA10（2012.7.23更新） Mozilla Firefox中文社区にある1.1.7にしたら動いた。
スクリプト関係でいくつか動かないのが出た。
minibufferとldrize
まず、e4xがobsoleteだかdeprecatedだかで使えないのでその部分を修正。
minibuffer.user.jsの819行目付近
GM_addStyle("#FLASH_MESSAGE{ \ position : fixed; \ (中略) } \ ");
こんな感じに。
うじゃうじゃっとしたカッコを取り去ってダブルクォートで囲って、"\"で行をつなげただけ
もう一ヶ所925行目付近のGM_addStyleも同じようにする。
あと、minibufferオブジェクトが他から見えない状態になってるようなので、unsafeWindowに付け替えてみた。
minibuffer.user.jsの1741行目付近の最後の"}"の直前
window.dispatchEvent(ev); unsafeWindow.dispatchEvent(ev); unsafeWindow.Minibuffer = window.Minibuffer; }
次にldrize.user.js
150行目辺りの"// !!! END OF SETTINGS !!!"の下くらいに、
window.Minibuffer = unsafeWindow.Minibuffer;
という行を追加。
これでとりあえず動いたけど、副作用やらなにやら、これでいいのかは不明。
しばらく試す。
追記
// ==UserScript== // @name delMinibuffer // @namespace http://hatena.jp/serian // @description delete Minibuffer obj from unsafeWindow // @include * // ==/UserScript== unsafeWindow.Minibuffer = null;
こんな感じのを、"ZZZZZ-delMinibuffer.user.js"とかいう名前で作っておく。
"ZZZZZ"は、一番最後に実行されるように。
すると、スクラッチパッドなんかでMinibufferを取得しようとしてもできないけど、LDRizeは動いてる感じ。
多少はセキュリティー的にいいのかも?
tomblooとUserScriptLoader
UserScriptLoaderの中でtomblooのオブジェクトを取得してサンドボックスに入れてuserscriptから使うということをしてた。
greasemonkeyや、scriptish用には、tombloo自身がやってくれてること。
sandbox.Tombloo = Cc['@brasil.to/tombloo-service;1'].getService().wrappedJSObject;
930行目くらいにこんなのを入れて、
GoogleReader + Tomblooみたいなスクリプトの中で
var tombloo = Tombloo.Tombloo.Service;
みたいにして、使っていた。
これが、Firefox17にしたら、動かなくなった。
Tombloo.Tomblooが未定義になる。
ためしにTombloo.Serviceだけで参照してみたら、なんかユーザー定義の属性の無いオブジェクトになってる？
なんかセキュリティー関連の変更が合ったんだろうか。
どうしたものか。
追記
コメントで教えてもらいました。
Tombloo.Service.__exposedProps__ = {check: "r", share: "r"};TomblooService.patch.js
こんな感じのパッチを入れて、使えるようになりました。
参考 Nightlyで今すぐGoogle Reader Full Feed Modを動かす方法 - Firefox更新情報Wikiブログ
[firefox][emacs] cookieswap補助、gist.el、ちょっとtombloo
cookieswap
Firefoxの拡張で、クッキーをごっそりと入れ換えて、各種ログイン状態の切り替え管理ができるもの。
非常に便利なんだけど、つい、どのアカウント状態になってるか忘れてしまう。
デフォルトでは、ステータスバー、アドオンバーにプロファイル名が出るんだけど。
というわけで、選んだプロファイルごとに、Firefoxのどこかの色を変えて、注意を促そうというもの。
userChromeJS用のスクリプト。
連想配列に、プロファイル名と色の対応。
ここではnav-barの色を変えてる。
gist.el
emacs24に変えて色々調子いいんだけど、ここでつまった。
gnupackのものを、自分でインストールしたcygwin環境で使ってる。
まずは、
gnutls.el: (err=[-64] Error while reading file.) boot:
というエラー。
これは、emacs24がgnuTLSに対応したようなんだけど、cygwinのcertファイルを見に行ってて、それが読めないことから来るものだった。
gnutls.elの変数を更新
(eval-after-load "gnutls" '(setq gnutls-trustfiles "c:/cygwin/usr/ssl/certs/ca-bundle.crt")
みたいな感じ。
その次にまたエラー
Wrong type argument: stringp, 99
どうも、"url.el"の"url-retrieve-inner"が出してる。
(if asynch (let ((url-current-object url)) (setq buffer (funcall loader url callback cbargs))) (setq buffer (funcall loader url))
ここの"loader"が文字列になってるとかそんなふう。
http通信は普通にできて、httpsになるとおかしくなる。
gnupack純正のinit.elでやっても同じ。
逆に、gnupackの環境に、普段のinit.elを持ち込んでも同じ。
もちろん、gnupackの中にあるemacsではちゃんとうまく動く。
大元のwindowsの環境(変数)に問題があって、普段のinit.elの中でもそれを再びなぞるようなことをしてるってことか？
いっそのこと、gnupackの中に住んだほうがいいような気もしてきた。
