8 posts tagged “development”
SharpDevelop 3.0 Beta 1でF#がサポートされた。F# Interactiveがついてる。
IronPythonのサポートは、Alphaの時から追加されてたけど、F#までサポートするとは。素晴らしい。
tracもpythonで書いてあるんだから、psyco使ったら速くなるかな?とふと思ったので試してみた。
私の所では、mod_pythonを使っているので、trac/web/modpython_frontend.pyに以下を追加して試した。
abで負荷かけてみたら、平均だと20msecぐらい速くなった。
import psyco
psyco.profile()
min 154→130
mean 161→137
median 159→136
max 810→531
1000リクエストにかかった時間が、160sec→138secで22秒差だから大体あってるかな。
coLinux(ubuntu)にemacsをいれた。
とりあえず既存のパッケージをいれてみた。
ちゃんとputtyでxterm-256colorにしておいたので、たくさん色が出せる。
(emacs-version)
"GNU Emacs 22.1.1 (i486-pc-linux-gnu)
of 2007-11-07 on terranova, modified by Ubuntu"
meadowから乗り換えたいので、howmはいれた。ちゃんとgrepが使える。cmigemoとmigemo.elもいれた。
ついでにdisplay-time-string-formsを見直してみた。
今までは、検索して見つけたやつ(dayname-j-alistで英語表記の曜日と日本語表記の曜日の対応をつけてるやつ)をコピペして使っていた。
ただ、なにも指定しなければ曜日が漢字で出ているので、自前の連想リストが無駄な感じがして気になっていた。
ちょっとtime.elをみたら簡単だった。
(setq display-time-string-forms '((format-time-string "%Y/%m/%d(%a) %H:%M" now) load))
要するに、RoundRobinLoadBalanceとfailOverReadOnly=trueの問題でした。
- JDBC URLのホスト部にホストを複数書いたときに、先頭以外のホストが選ばれると、そのコネクションはfailover状態に設定される。
- failover状態になると、
failOverReadOnlyがtrueなら当然そのコネクションはReadOnlyなコネクションになる。 - この状態(failover&
failoverReadOnly=true)になると、setReadOnly(false)しても書き込み可能にならないので書き込もうとすると例外が発生する。 - そんなコネクションがc3p0やらdbcpでプールされるが、書き込みたいときに書き込み可能コネクションがとれるとは限らない。
解決策の案
プールを別にする
Solaris上でコンパイルするので、Sun studio 12をつかってみた。
Sun studioのコンパイラでは、ctypes用のlibffiが、そのままだとコンパイルできません。
Sun studioのコンパイラが、__i386__を定義していないのが原因なので、__i386__から__i386にすると通ります。
参考
- Predefined Names Sun Studio 12のマニュアル
- Pre-defined Architecture Macros 一般的なものが網羅されていて素晴らしい
Windows SDKに入っているコンパイラと、mecab-win32でビルドできた。
バイナリ配布のlib/dllを使うので、MeCab_wrap.cxxへのパッチが必要。
manifest(python.exe.manifest, pythonw.exe.manifest)を修正しないと、MSVCR80.DLLがロードできないので、
manifestに、以下のエントリを追加した。
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
idleでも問題なくなったけど、pyscripterはだめだな。manifestを内部で持ってるのかな?
ほとんど使わないからいいか。
mingwでコンパイルした、mecabとmecab-pythonが、うまくロードできないことがある。
だめなときは、ImportError: DLL load failed: メモリ ロケーションへのアクセスが無効です。とか言われる。
idle、PyScripter, IPythonからだと確実にロードできない。
MeCabLibでもだめだったから、libmecab-1.dllが原因かな。何が悪いんだろう。
バイナリ配布のmecab-win32だと、g++で作ったのとリンクできないし、VC++で試すしかないのかな。
ついでに、mingwだと、mecabをコンパイルするときに、mecab.hをいじっておくか、
MeCab_wrap.cxxをいじらないと、リンクに失敗した。
mecab.hをいじるなら、以下のdiff。
MeCab_wrap.cxxはこっち--- mecab.h 2007-03-11 23:19:42 +0900
+++ mecab-0.96/src/mecab.h 2007-07-10 09:58:10 +0900
@@ -217,11 +217,11 @@
virtual ~Tagger() {}
#ifndef SIWG
- static Tagger* create(int argc, char **argv);
- static Tagger* create(const char *arg);
+ MECAB_DLL_EXTERN static Tagger* create(int argc, char **argv);
+ MECAB_DLL_EXTERN static Tagger* create(const char *arg);
#endif
- static const char *version();
+ MECAB_DLL_EXTERN static const char *version();
};
/* factory method */
--- MeCab_wrap.cxx 2007-06-10 23:32:44 +0900
+++ mecab-python-0.96/MeCab_wrap.cxx 2007-07-10 12:44:27 +0900
@@ -4450,7 +4450,7 @@
arg2 = reinterpret_cast< char ** >(argp2);
{
try {
- result = (MeCab::Tagger *)MeCab::Tagger::create(arg1,arg2);
+ result = (MeCab::Tagger *)MeCab::createTagger(arg1,arg2);
}
catch (char *e) {
SWIG_exception (SWIG_RuntimeError, e);
@@ -4483,7 +4483,7 @@
arg1 = reinterpret_cast< char * >(buf1);
{
try {
- result = (MeCab::Tagger *)MeCab::Tagger::create((char const *)arg1);
+ result = (MeCab::Tagger *)MeCab::createTagger((char const *)arg1);
}
catch (char *e) {
SWIG_exception (SWIG_RuntimeError, e);
@@ -4548,7 +4548,7 @@
if (!PyArg_ParseTuple(args,(char *)":Tagger_version")) SWIG_fail;
{
try {
- result = (char *)MeCab::Tagger::version();
+ result = (char *)mecab_version();
}
catch (char *e) {
SWIG_exception (SWIG_RuntimeError, e);
IE Developer Toolbarの正式版がでてた。beta3はひどかった…beta2を消してしまって、我慢しながらbeta3を使ってたから、やっとイライラから解放される。
IE6はやっぱりランタイムエラーがでるっぽい。。