svn 服务器 ip地址切换

Eclipse 中重新定位SVN服務器地址

转自：http://renren.it/a/bianchengyuyan/ASP/20110424/83768.html

linux 下切换svn地址的命令是 svn switch --relocate FROM TO [PATH...]

公司SVN服務器換了IP地址。我用的是Eclipse的subversion，在SVN資源庫的透視圖中重新輸入新SVN的IP即可，過程如下圖。

不過重新定位SVN服務器的時間比較長，需要耐心等待。

這次在hosts中添加了別名，SVN地址使用了別名。以後SVN服務器換了IP，改host就可以了，無須漫長等待。

没有退路

近日看吴军的《浪潮之巅》，颇觉是IT近代史。和别的历史书籍不同，这本书看的激情澎湃，因为很多事情都觉得很贴近。书中讲述了很多大公司在一些很有前景的项目上畏首畏尾或者在当前业务中比重太小而不重视。反倒是一些小公司在这项目上不成功便成仁，拿出破釜沉舟的干劲，最后成功了。

读书时学过太极吴氏老架，当时顺便学了老师独创的太极健身八法。近日练习八法时，想像以往那样跟着视频打，因为总记不全。但手机里的太极视频不知何时弄丢了。重新弄了两次没有成功。一时没了后路。翻出以前打印的相关材料，总结成十个字后练习几次居然可以不再依赖视频独立完整练习了。

面对诸多待办事情时，人谷子里都有拖延的习惯。为什么？因为有退路，现在不做也可以。这种情形往往后果比较严重。因为当前拖延的事情稍候就会变得紧急，久而久之就会不断疲于应付很多紧急的琐事。反倒是那些不紧急但重要的事情没有太多的精力去处理了。长此以往，人就失去了核心优势。

C++下类似Perl正则表达式的支持库deelx.h存在严重的内存泄漏，用boost::regex取代deelx.h

经历一番折腾，我用deelx.h支持的正则表达式完成了我需要的全部功能，但测试程序的内存开销时，吓了一大跳。deelx.h存在严重的内存泄漏。经过内存泄漏工具的检测，原来是realloc函数的使用出现了问题。我花了一个小时也没能搞定deelx.h中的这个bug。万般无奈，换到了boost:regex库。结果经过简单的程序片段转换，我完成的新版程序功能和原先的完全一样，而且完全没有内存泄漏。

原先我还有一个Perl程序实现了同样的功能。对比Boost::regex的实现以及Perl的实现，Boost内存开销小一些，但Perl速度快很多，二者都没有内存泄漏。网上对deelx.h的好评很多，猜想他们都是在用match功能，一旦用上replace功能，deelx.h就会吃光内存了。其实deelx.h在CodeProject上也获得了很多好评，但同时也被人发现了内存泄漏问题，很奇怪的是这个问题09年10月就被人发现了，作者也知道这事儿，为什么就还没有被修正呢？有机会时我再试试。

C++下类似Perl正则表达式的支持库deelx.h中Bug的修正

今天要转换一段Perl中的正则表达式替换代码到C++中。以前积累下的deelx库可以方便的发挥作用了。

原始的deelx.h可以在这里找到 http://www.regexlab.com/zh/deelx/introidx.htm

但是在使用deelx的Replace功能时，总是遇到三处Bug，如下：

deelx.h:3626: error: cast from ‘const char*’ to ‘int’ loses precision

deelx.h:3637: error: cast from ‘const char*’ to ‘int’ loses precision

deelx.h:3644: error: cast from ‘const char*’ to ‘int’ loses precision

不管我怎么修正我的main.cpp总是会得到这样三个Bug，百思不得其解。最后在一个论坛上找到了解决方案 http://stackoverflow.com/questions/153065/converting-a-pointer-into-an-integer

原来是deelx.h在64位机器上编译时，原先的强制转换(int)都遇到了问题，需要修改为(size_t)来自适应64位的编译器。

三处bug都从（int）修改为（size_t）后就都解决掉了。现在的Replace功能就能正常使用了。

留在此处供遇到同样问题的朋友参考。

自然语言处理或者自然语言理解的终极之道：聊天机器人？！

网上看到下面这段文字，让我这样的自然语言处理小辈激动不已。找个时间好好学习一下这个Cleverbot的后台机制，特别是它的自动学习机制。曾经设想过这样的东西，但没有想明白学习机制。这次得好好学习咯。

----------------------------------------------------------------

智能机器人Cleverbot是怎样炼成的？

1988年，英国人罗洛卡彭特（Rollo Carpenter）开始着手这一人工智能研究项目，1997年将机器人Cleverbot接入互联网，使其不断地向访问者学习"知识"，增长自己的"才干"，直到今年9月才获得初步的成功。请见："Cleverbot: Artificial Intelligence of the Future, or Just a Jerk?"一文，此文发表于2011年7月18日。

由此可见，机器学习是构建网络智能机器人的基础，不会自动学习，谈何智能机器人？但是，怎么让机器"自动学习"？这就是一个实质性的问题。这个智能机器人研究项目一干就是二十几年，与我们某些"核高基"研究项目的"短视"相比，不可同日而语也。乌呼！

VI下DoxygenToolkit生成注释非常方便

曾几何时，我在Eclipse下进行Java编程时，对于生成Javadoc有过一个非常棒的插件。将光标放置到函数内部或者文件头部，按下快捷键就可以得到相关的符合Javadoc或者Doxygen标准的相关注释。当时对程序编写注释是一件非常舒服的事情，而且最终生成的文档也非常的漂亮。

从去年2月开始完全转入Linux环境后，我开始纯粹的C++编程，不管采用哪种编程IDE，都没有找回那种编写注释的感觉了。今天，这种感觉重新回来了。那就是VI下的DoxygenToolkit。在文件头输入DoxAuthor命令就能自动插入作者信息，输入DoxLic就能自动插入版权信息，更为强大的是在类或者函数的头部输入Dox命令就能得到标准的注释模板，而且一些域已经很好的自动补全了。

配合Doxygen生成的html网页或者latex pdf文档看起来都是相当的专业。

参考链接：

Vim自动文档插件--DoxygenToolkit http://hi.baidu.com/david_jlu/blog/item/44c1413340121f45ad4b5f90.html

vim中两个实用插件doxygen和projects的安装与使用  http://yaronspace.cn/blog/archives/682

doxygen+VIM文档实用指南for C/C-liked Programmers http://blog.csdn.net/clarkZHUO/article/details/1471573

看来以后在VI下的编程时间会不断增加，还得熟悉一些相关插件，争取实现手指在键盘上飞的感觉。标记于此。

我的机器翻译学习经历以及即将开启的词对齐学习

统计机器翻译的第一步就是词对齐，随后抽取短语表，然后根据短语表进行翻译解码，中间会根据语言模型来选取最优的翻译结果。整个统计机器翻译的各个步骤都有很多人在不断的深入研究，从mt-archieve这个网页（http://www.mt-archive.info/subjects.htm）可以见识到相关论文的增长速度。面对如此海量的论文，对于一个统计机器翻译的新手，究竟该何去何从呢？这个问题长时间的困扰了我。

去年年初博士毕业后开始接触统计机器翻译。好友张慧一开始就建议我仔仔细细从零开始实现一个机器翻译的系统，可以完全从词对齐开始实现全部的步骤，也可以针对解码器从零开始实现解码功能，经过这个阶段后才能真正领悟统计机器翻译的魅力以及其中的症结。由于项目的压力，我只能抽出业余时间来完成这个计划。起初是想从零开始实现解码器，经过一个多月的业余开发，我的解码器可以得到和moses的最基本stack解码一模一样的各种概率输出。当时我小小的兴奋了一下，感觉对机器翻译总算有了一点点感觉。但是随着翻译句子长度的增加，我的解码器速度变得非常的慢，比起moses的速度差远了，内存开销方面我的解码器也比moses差很多。后续我开始研究moses的各种加速技术以及节省内存开销的方法。在网上四处转悠后发现了kenlm这个比srilm好很多的语言模型工具包。熟练使用后，我把kenlm的代码改装替换掉了我的解码器的语言模型，也同时替换掉了我的项目里使用的语言模型，当时我项目使用的decoder在内存开销方面节省了很多。随着更进一步的优化，我对stack解码器相关的技术了解了更多。当我开始尝试编写cube pruning解码方法时，开始被项目项目相关的其他事宜占用全部的时间，随后我的解码器业余时间研发计划就被搁置下来。仔细算来，我的这个事项居然被耽搁了半年多了。

随着对统计机器翻译的认识不断深入，我越发觉得如果想深入研究机器翻译或者从事相关的开发工作，词对齐方面的研究必不可少。给我造成这种直觉的直接原因，是我原本想准备完成一项短语表过滤的研究任务。但是随着调研和各种对比实验的深入，我发现单纯从已有的低质短语表出发，很难找到更加有效的过滤方法。更加fundamental的方法是进行更好的词对齐以及后续的短语抽取。这个路子可能才是解决问题的思路。

后续我阅读了近两年来的关于词对齐的论文，最近在reading group上主讲的《An Unsupervised Model for Joint Phrase Alignment and Extraction 》、《Feature-Rich Language-Independent Syntax-Based Alignment for Statistical Machine Translation 》、《Bayesian Word Alignment for Statistical Machine Translation》让我对词对齐任务有了进一步深入的认识。词对齐的根本目的是为了抽取短语，好的短语可以产生好的翻译。有人也在绕过词对齐，而直接作短语对齐。细数mt-archieve上的词对齐论文，几百篇的数量让人惊讶。

我想深入的学习词对齐这个点，力争在词对齐上有所突破后再向短语对齐方向努力，进而再结合解码过程中的特点来实现一种新型的短语抽取和解码过程直接相关的翻译系统。这个计划需要好好执行。

接下来的词对齐学习，我想就从Jorg Tiedemann今年5月刚出版的《Bitext Alignment》开始吧。153页的薄册子，希望能在半个月内能看完。给自己加油 :)