今儿搞定了俩bug，系统能正常通过test suite了，备忘一下。 1. 拷贝构造器漏拷了某field 这个的确很弱智…… 但是拷贝构造器在每次增减field的时候都要手动改，这个真麻烦…… 就不能提供一个只要我没动的都自动拷一遍的拷贝构造器么…… 2. 拷贝构造器中，成员变量中的父指针没有指向新对象 简单来说，就是 class A; class B { A *parent; }; class A { B b; }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); … }A::A(const A& other) : b(other.b) … { …
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了～
之前发生了好几次，在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自然也没有问题…… 这些都是好好地先停掉服务的……
首先，如果某个test.h里有如下内容： class A { public: int x(); } int A::x() { }class A { public: int x(); } int A::x() { } 那如果只有一个test.cpp引用了它： #include "test.h" int main() { A a; a.x(); }#include "test.h" int main() { A a; a.x(); } 那还好。但如果还有一个test2.cpp引用了它： #include "test.h" int foo() { A a; a.x(); }#include "test.h" int …