今儿搞定了俩bug，系统能正常通过test suite了，备忘一下。
1. 拷贝构造器漏拷了某field
这个的确很弱智…… 但是拷贝构造器在每次增减field的时候都要手动改，这个真麻烦……
就不能提供一个只要我没动的都自动拷一遍的拷贝构造器么……
2. 拷贝构造器中，成员变量中的父指针没有指向新对象
简单来说，就是
class A; class B { A *parent; }; class A { B b; } |
A在拷贝的时候，应该吧b这个成员的parent指针指向新的A……
A::A(const A& other) : b(other.b) ... { ... b.setParent(this); ... } |
不过实际上好像父指针不是一个好的模式？但是不用这个用啥呢…… 或者就注意点吧……
ibus 1.4.0在gvim里有些问题。具体来说，启动gvim之后数秒内无法输入，之后控制台输出
(gvim:77687): IBUS-WARNING **: Process Key Event failed: Timeout was reached
这句话，之后在gvim里可以输入，但是用不了输入法。
根据研究貌似是gvim的问题，FreeBSD的vim还停留在7.3.121，而新的vim，例如7.3.315就没有问题。
这个问题的报告：
http://code.google.com/p/ibus/issues/detail?id=1249
https://bugzilla.redhat.com/show_bug.cgi?id=673438
有个workaround是gvim -f，但是毕竟麻烦。
于是手工改了个vim 7.3.315的port，用着挺好…… 除了切输入法的时候会输入一个空格以外……
FreeBSD的vim留在7.3.121是有原因的。首先是7.3.122这个补丁打完之后无法编译。
其实7.3.122是说，不附带src/auto/config.mk，在顶级目录Makefile里加上自动复制src/config.mk.dist为这个文件……
但是可能是BSD这边编译方法的问题，没有直接跑顶级Makefile，于是缺文件…… 其实自己复制过去就好了。
之后是7.3.225这个补丁打不上。貌似原因是patch数错行数了…… 或许是^M这些东西的关系。
解决方法是在test79.in和test79.ok最后加些只有”+”的行。加到正好数量对为止…… 反正这俩文件也没啥关系
于是现在用着vim 7.3.315，感觉很好…… ibus也没有问题……
其实早就该更新的…… 不过之前尝试了一下，觉得1.4.0不咋的，还有些问题，于是没管……
结果终于有好心人搞了个1.4.0的patch，还群发邮件说各位基于ibus的ports的maintainer们，快更新吧！
他顺便还加上了GTK3支持的选项，看来大家都要渐渐向GTK3迁移了么……
在那个patch的基础上，提了些修改，现在在等待commit……
具体来说：
* 貌似其实ibus不依赖Qt？为啥从前加上去了呢…… 于是去掉了
* 没有post-deinstall这个target的，应该在pkg-plist里用@unexec来执行卸载命令的……
所以从前的ibus port删除之后，是不会更新gtk2的immodules列表的…… 这么多时间了也没人发现……
为了这个，ibus-pinyin也更新到1.4.0。但是ibus-pinyin 1.4.0居然要编译器支持c++0x…… BSD的古老的gcc 4.2怎么行……
于是就让port依赖gcc 4.4+，没办法…… 其实ibus-pinyin还有个替代选项是用boost，但是开了之后没法编译。虽说打个补丁应该可以，但是太麻烦…… 另一个好处是，现在就不依赖boost了……
其他更改：
* 不知道为啥，ibus-pinyin有个${DBTAR}在DISTFILES里，而这个东西没定义过…… 删了删了
* 去掉boost支持，反正依赖gcc 4.4+了……
* RUN_DEPENDS单独定义。这个是portlint说的，说BUILD_DEPENDS其实还有别的东西，不能直接赋给RUN_DEPENDS
* 目前禁用lua扩展。反正也没人用……
* 加了俩选项，选择是否编译Android DB和OpenPhrase DB。貌似是俩词库，OpenPhrase 那个挺大……
* 加了选项是否依赖opencc进行简繁转换
ibus 1.4.0在gvim里有些问题，换篇文讲吧……
于是就等待commit了～
Happy New Year!
之前发生了好几次，在FreeBSD下往NTFS分区拷东西，结果之后去win下一看，不见了……
关于这个问题，找到过一个原因：如果先启动BSD，然后卸载某个NTFS分区，开一个直接使用那个NTFS分区的Win虚拟机，Suspend那个虚拟机，挂上那个分区，写东西，卸载，再Resume并正常关闭那个虚拟机，文件就会丢……
这个问题挺好理解的，就是Win虚拟机自己保存了一些数据结构，你在Suspend期间对那个分区写的内容，Win虚拟机不知道。等他把数据结构flush回去，自然中间的改动就丢了……
之后还是出这个问题，最近又找到一个原因：如果往NTFS分区复制文件，之后用reboot命令重启，文件也会丢……
这个原因貌似是reboot是个很彪悍的命令，它不运行rc.d里那些脚本来停止服务，直接对所有进程发SIGTERM…… 于是cache里的数据没flush出去，那些文件就丢了……
不过貌似这样文件是丢了，可用空间却会变少…… 如果在Win下检查NTFS分区，会说已使用位图不正确……
以后不用reboot了…… 要不要直接alias掉呢……
说起来init 6倒是没有问题…… shutdown -r自然也没有问题…… 这些都是好好地先停掉服务的……