compile vim71 on mac osx
由于更新了lookupfile.vim，需要7.1，自己重新编译了vim71
1. checkout source from svn:
svn co https://svn.sourceforge.net/svnroot/vim/vim7 .
2. run configure
cd src
CONF_OPT_PERL=’–enable-perlinterp’ \
CONF_OPT_MZSCHEME=’–enable-mzschemeinterp’ \
CONF_OPT_CSCOPE=’–enable-cscope’ \
CONF_OPT_MULTIBYTE=’–enable-multibyte’ \
CONF_OPT_OUTPUT=’–enable-fontset’ \
CONF_OPT_FEAT=’–with-features=huge’ \
CONF_OPT_COMPBY=’”–with-compiledby=nightsailer@chinavisual.com”‘ \
./configure
make
3.make install
That’s all.
Lighttpd1.5终于在osx上工作了
让lighttpd在mac osx上跑真是费劲。首先是编译，1.5需要使用gthread，因此需要glib2.6+，我使用fink来安装。很快遇到了些小麻烦，虽然glib2已经安装，但是configure始终无法找到。最后发现是因为mac自身的pkg-config优先/sw的
pkg-config，所以无法找到glib的包信息。重新调整下path,首先搜索/sw的fink的命令。编译通过了。
之后是安装php4,php5。
由于需要php4和php5同时工作，因此我使用了以下技巧：
使用2个spawn-fcgi 来spawn不同，为了方便脚本运行，将php4和php5的fastcgi程序rename为/usr/local/php4/bin/php4,/usr/local/php5/bin/php5.，这样可以分别start,stop不同的fastcgi daemon.
最有用的是，可以分别针对不同的host,将.php转发到
不同的fast-cgi server。比如blog.* 是php4, cms.*是php5等等。
不仅是这样，由于使用fastcgi，你可以将某个目录或者url直接转发到不同的php后端，这样可以将同一个php程序分别在php4,php5下面跑。在unix下面只要做个symbol link就搞定了，例如：app4,app5，
host['url'] =~ “app4.*” =>(
proxy….
)
host['url'] =~ “app5.*” =>(
proxy….
)
这点上，lighttpd比apache真是灵活很多，感觉非常方便。
说了好的，再说痛苦的， 在linux上面，lighttpd非常顺利。但是在我的mac上，很快
发现无法执行phpadmin，很奇怪的是简单的php程序可以，但是一跑phpadbmin，
lighttpd就crash了。
google半天，发现mac上用的太少了，都是1.4. 最后没办法，自己用ktrace 生成了lighttpd
的trace文件，使用kdump查看输出结果，很快，我就发现，是posix-aio出了问题。
我记得lighty的blog上说posix-aio不太稳定，实际上我在linux下面的libaio也曾经把kernel都弄死了。
而且作者在freebsd上默认编译是使用posix-aio，不幸的是，macosx属于freebsd系列。
立即验证,手动指定network-backend为gthread-aio,嗯，这下不死了，但是有些图片仍然无法显示。
看来aio还是实验性的东西。使用最传统的writev好了，果然，一切都正常了。
我提交了一个ticket，希望作者能够修正，至少默认不要用posix-aio。
gogle出游
最后一张有意思吧，是洪波逗gogle玩，呵呵
庆祝blog新的图片上传工具发布 看我家gogle的靓照 — (1162)
blog的图片上传更新啦，目前为止最方便的图片上传工具，欢迎批量传图。我做个示范，以下从上传图片到发布只用了20秒钟哦：
xcache导致php segfault
郁闷了n天的php segfault，今天终于让我抓到了元凶: xcache.
不论是s1还是s8,php的fastcgi始终会segfault。在blog上的频率最高。
今天查看xcahce的tickets,发现有xcache导致segault的例子。我突然想，
俺们是不是也一样呢。
关键是要重现segfault,嗯,如果是xcache的问题，那么在高负载下应该能够重现，
因为它就是用于缓冲opcode的。
用ab测试,很快segfault频频出现,又把xcache禁用,ab再次测试,没有segfault。
ok，原因找到了,这个错误在xcache的1.2dev中曾经被closed,但是最近又被reopen了，
看来要等作者修复完了再重新考虑xcache了。
现在的替代就是使用zend optimizer，测试了一下，没有什么问题。
今天早上不爽 投诉了那个出租车
今天有事要早到公司，于是6:50从西直门华堂上了一出租车，上车跟司机说去酒仙桥兆维大厦，走机场高速下大山子环岛。以为无事，就闭目养神。出来早，走的非常顺，都没踩几脚刹车。到了公司，一打表，51，靠，我8点半出来最堵最堵的时候不过是56，以前6点多都是39。我问司机，他问我是不是都是走同样的道，我说是阿，从二环上小街桥上高速，结果他回答，他走的是四环。我顿时气晕，我抽风阿，走四环还要绕回机场高速上大山子环岛？人家还振振有词：你又没告诉我怎么走。
我无语，难道我不说最近的路，你就应该给我绕道？ 想起来人家上海的出租车，都事先询问走什么路，大概有什么有缺点，会不会堵车，会不会绕道。 我是认道，那刚来北京咋办？
我也不想和他多说，吃完饭，立马打了投诉电话。好像是北京的出租车管理处的统一电话，都记录了。说是3个工作日内给我回复。
说起来马上就奥运了，这出租车可是窗口行业，咱不能让一小撮不争气的东西坏了咱首都的名声不是，所以。。。有事没事您就投诉吧，投诉多了，自然也能慢慢解决了。
lighty reloaded
blog的运行一直不太稳定。主要原因是wordpress大量依赖apache的url rewrite，此外部分plugin的相互兼容性存在问题。说到wordpress的不稳定，我的mac机器上甚至都跑不起来。最早我们使用的是lighttpd，不过很快发现很多错误，比如无法正确登录,最后发现可能是wp的部分代码无法兼容fast-cgi方式。修改了几次都不太理想。最后使用zend core的mod_fastcgi来替换apache本身的fast-cgi，似乎好一些。但是好景不长，很快就频繁出现页面空白等现象。重启apache就ok。是不是只有用mod_php方式最好呢？节前将php降级到redhat的官方64版本。情况更加糟糕，经常出现页面无法打开。我初步断定是代码问题。不过由此也看出，mod_php的确没有fast-cgi方式来的健壮。mod_php一旦有问题会危机httpd本身，而之前用Lighttpd15,尽管php-cgi频繁seg fault,但是lighttpd处理静态文件仍然很好。到了51节后，blog的出错让我忍无可忍，下决心重新使用lighttpd。 但是首先要解决url-rewrite的问题。之前使用lighttpd的url rewrite，由于缺乏条件重写，因此性能比较差，需要将所有静态文件手工补上规则，这也是以前页面侧栏无法工作的主要原因。不过还好，这次发现lighttpd的mod_magnet可以完成。
事情并非如此顺利，首先是如何编译mod_magnet, 这需要安装Lua这个语言，首先尝试自己编译，lua的安装简单，直接make linux就完了，但是在配置lighttpd的时候出现问题，虽然使用了 –with-lua=lua51，但是死活找不到lua的lib库。后来我手动加上-I/usr/loca/lib/lua 虽然config通过了，但是link阶段发现仍然有问题。在僵持了快1个小时后，我最终放弃，不过很快发现有rpm包可以用。从rpmfind.net找到 lua-5.1.2-1.fc7.src.rpm，为了避免最终link出问题，我使用icc rebuild了这个rpm。最后安装了lua,lua-devel 这2个rpm。lighttpd终于顺利的编译成功。通过查阅mod_magnet的例子，写了一个blog.lua:
if (not lighty.stat(lighty.env["physical.path"])) then
if (string.match(lighty.env["uri.path"], “^(/?[^/]*/)files/$”)) then
lighty.env["physical.rel-path"] = “index.php”
lighty.env["uri.path"] = “index.php”
else
n, a = string.match(lighty.env["uri.path"], “^(/?[^/]*/)files/(.+)”)
if a then
lighty.env["physical.rel-path"] = “wp-content/blogs.php”
lighty.env["uri.path"] = “wp-content/blogs.php”
lighty.env["uri.query"] = “file=” .. a
else
n, a = string.match(lighty.env["uri.path"], “^(/?[^/]*/)(wp-.*)”)
if a then
f = lighty.env["physical.doc-root"] .. a
if lighty.stat(f) then
lighty.env["physical.rel-path"] = a
lighty.env["uri.path"] = a
else
print(”missing ” .. f)
lighty.env["physical.rel-path"] = “index.php”
lighty.env["uri.path"] = “index.php”
end
else
n, a = string.match(lighty.env["uri.path"], “^(/?[^/]*/)(.*\.php)$”)
if a then
lighty.env["physical.rel-path"] = a
lighty.env["uri.path"] = a
else
lighty.env["physical.rel-path"] = “index.php”
lighty.env["uri.path"] = “index.php”
end
end
end
end
lighty.env["physical.path"] = lighty.env["physical.doc-root"] .. lighty.env["physical.rel-path"]
print(”physical.path ” .. lighty.env["physical.path"])
print(”uri.path ” .. lighty.env["uri.path"])
end
这里看起来简单，但是非常让人恼火的是，如果没有uri.path，那么会显示403 错误。这是在反复测试了3个小时候换来的血的教训。 也许问题不是出在lighty本身而是wordpress自己。
终于能跑起来了，但是很快发现rss不能用，尤其是全站。 这又花费了相当长的时间才搞定。
最后，删除了几个不稳定的plugin。
不良的代码竟然导致web server crash，这是我以前很少遇到的。
使用ab测试了一下，在高负载下还是有seg fault，不过还算能抗过去了。
不管怎么说，apache先休息一下吧
换一个mac派的主题
作为一个mac的粉丝，看到这样亲切的mac的主题，真的太棒了。
没的说，换。
Thanks , [iTheme](http://www.ndesign-studio.com/resources/wp-themes/itheme/)
关于UE的几个站点
http://ucdchina.com/blog/
http://blog.rexsong.com/
http://ucdchina.com/angela/
http://www.moond.com/lab/