All Stories
Lua官方只提供了一个解释器和一个编译器，不像Python、Ruby那样有一个大而全的标准库。但是Lua仍然有众多的第三方库，像Luaforge上就托管了一大批Lua相关的项目。
为了方便用户使用，也有第三方贡献者将一些常用的第三方库编译并打包在一起提供，比较著名的是Lua For Windows（简称LfW），而这里要介绍的是另一个刚开始没多久的项目，叫LuaPack。LuaPack受LfW的启发而创建，而且比LfW走得更远。LuaPack不但已经完成了对Windows系统的良好支持，从其SVN仓库中可以看出，现在正着手努力使其支持（Ubuntu） Linux和MacOSX，这是LuaPack与LfW最大的区别，而LfW从项目名称上就可以知道是只支持Windows系统的。另外，LuaPack打包了一个专业的Lua IDE，叫DForD LuaCoding，这是一个由DForD Software提供的针对Lua语言开发的IDE环境，勿庸质疑DForD LuaCoding的功能比LfW中附带的基于SciTE的编辑器要强大得多，但DForD LuaCoding是个共享软件，未注册版将会在每次启动时弹出一个要求输入注册码的对话框，除此之外没有任何功能或使用时间上的限制。最后一点小区别是，可能是基于创建者自身的价值理念，LuaPack和LfW打包的第三方库有些许不同，有的库只在LuaPack中存在，而另一些库只在LfW中存在，而且LfW是使用VC2005编译，所以可以在Windows 2000及更高版本中运行，而LuaPack使用VC2010编译那些Lua扩展库，所以只能在Windows XP SP3或更高版本中运行。
就我个人而言，LuaPack更值得推荐使用。
昨天算是发布出去了，这次花了3个月时间。修正了一些bug，添加了一些新特性，修改了一些功能。总之，现在回头看来，不那么令人满意。
没有UT是最大的问题，根本不能保证某次修改会影响到什么。这不能再忽视了，test case要开始补起来。
其次是编译器差异和编译模式差异之大，出乎我的意料。好几次都是VC编译出来的正常，用GCC编译的就不正常。或者debug编译的正常，release的不正常。这是因为我离不开Visual Assist，也有点离不开VC的调试器。这点实在不好解决。
再次是Lua开发环境还是不够好用。Auto Completion不准确就不说了，有时Auto Completion出来过后，整个程序就会很卡，不知道为什么。以后要能做到Auto Completion分库，可以让用户随意通过增删文件来增删符号库。
最后一点是对架构的不满意。经过如今大半年的迭代发现，插件扩展架构的可扩展性和可裁剪性不够灵活。这点现在还没有具体的思路，或者说一直觉得实现上也许有点麻烦。
除了这些外，还有许多特性要增加，比如增加几种常见的SCM工具支持，开放二次开发接口，增加插件扩展的开发环境等等。
这是个很简单的功能，但却很有用。SciTE和Notepad++都有一套自己的实现，感觉Notepad++的效果比较好。从它们的配置文件中提取出众多编程语言的注释符号即可。注释分为两类，一类是行注释，另一类块注释。不是每种编程语言都支持这两类注释方式，甚至有的编程语言都不支持可以有注释。当然这个不是很重要，反正所有的信息可以写在配置文件中。
昨天还意外地发现，用boost.lambda对std::basic_string和wxString对象进行==比较时，用VC编译的运行正常，用GCC则一直不正确。一开始还以为是两个编译器对两种字符串对象的内存布局不一样引起不同的结果。最后发现，其实是我自己写的迭代器在std::find/std::find_if中不正常，在GCC编译的程序中，比较谓词根本没有被调用。回想起来当时看到GCC的std::find/std::find_if对于随机迭代器是特化实现的，想想其实我那个迭代器不需要随机迭代器，用双向迭代器就可以了，改了后，一切都正常了！
昨天完成了自定义快捷键的特性。该特性在配置对话框中实现与用户交互。
首先，在程序启动时，装载所有菜单项时，把所有菜单项的ID、标题、快捷键信息记录下来，作为缺省的配置。将缺省配置保存到文件中，然后查看是否存在保存了修改后配置的文件，如果存在该文件，则装载该文件的配置，应用到程序中。应用过程分两步，刷新菜单显示和设置快捷键表。
接着，处理在配置对话框中的用户交互响应。在对话框初始化时，加载当前正在使用的快捷键配置。用户可以修改其中任意一项的配置，当用户选择应用修改后的配置时，就将当前配置保存到文件中，以便下次程序启动时可以装载这个修改后的配置。
基本处理流程就是这样。用wxWidgets实现时，也是比较容易的。wxWidgets提供了快捷键相关的几个类和方法，相当方便，包括wxAcceleratorEntry、wxAcceleratorTable、SetAcceleratorTable等等。
这里不得不抱怨一下，wxWidgets对于一些明明日常需要使用的类和方法，竟然没有文档进行说明。另外还发现个问题，wxAcceleratorEntry有个ToString方法，当其中的Key Code是除了字母、数字外的其他的可打印字符时，会断言失败，太Orz了，只好自己写代码转换了。
Relation视图可以算是完成了，至少是处于可用的状态了。基本原理就是调用cscope这个程序，本来这个程序是开源的，而且是用BSD许可的，比较干净的做法是把代码拿来编译进自己的工程里。不过我懒得研究那个代码怎么编译了，直接调用现成的可执行程序，通过管道获取其输出，然后自己解析一遍输出内容，显示在relation视图上。这样看来这该是个很容易实现的功能，但是实际上我却花了不少时间。原因是我一开始考虑得过于简单，把所有工作都放在一个singleton中完成。既要生成新进程，又要获取管道输出，同时还要兼顾老进程没有结果又有新进程的请求到来。于是总是在同时有多个进程时崩溃。后来把新老进程调试和获取管道输出分别放在两个类中实现，就都好了。
另外还有个问题是用gcc编译。现在这个版本基本上也到了收尾的阶段，我也买了个Mac Mini，希望能把它移植到Mac OS X上。Mac OS X上可以用gcc，于是我就先尝试在Windows XP上用gcc编译这个工程。这些天一直在折腾这事，总是由于这样那样的原因失败。到今天为止，终于可算是正常通过了，有几点需要记一下。我一直用boost svn trunk中的代码，绝大多数时候，用VC编译链接都是没问题的，可是这次用MinGW中的gcc 4.4.0把boost.thread链接到工程中时，仍然会报有几个符号找不到，如果是用正式发布的1.43.0版本的Boost，是可以正常链接通过的。gcc不支持在函数体内定义结构体（类），VC9是可以的。gcc在用boost.lambda时有些情况会编译不通过，就是几个结构体内的成员被lambda bind后再进行比较的情况，但是VC9是能编译通过的，而且也不是所有这种bind并比较都不能编译过，具体的还得继续研究一下。总的说来，gcc对类型检测比较严格，呃，说难听点，是比较死板，不如VC那么智能。还有种情况是gcc编译wxString::Format时，如果第二个参数开始传入的是wxString，运行时会出错，但它又报不上来，基本上就是直接崩溃，VC在这方面又做得好得多，不过这点我估计是受不同编译器对对象内存布局不同引起的，所以也许gcc真是无能为力，VC那样可以用算是歪打正着吧。
好吧，总之最头痛的两件事算是解决了。
好多天前，木耳就说要来上虞搞社会实践，崧厦那边有个阳伞市场，嗯嗯，这点是可以理解的。前些天我在魔都，木耳11号傍晚就来了，而我是昨天下午才回来的。
本来木耳说的是要持续10天的样子，结果昨天突然说马上可以完成回去了，晕。今天刚好去了百官，我就问木耳在哪里，她说在沃尔玛。呃，我不认识路呀，问了下阿姨怎么走。然后我就跟木耳说，我去找她。嗯，还是比较近的，她跟几个同学在沃尔玛门口的快餐亭或坐或站。然后我就自告奋勇送他们几个去火车站，呃，果然走错路了，不过上虞这块确实小，而且他们的火车也还要一个小时才来，所以我是不慌不忙了。
另外还有个女生，木耳说她叫鲜，是个重庆mm，呃，以前在网上看到木耳提起过，还以为是个GG呢。
原来以为木耳会多呆些日子，我还想可以带他们到处转转呢。现在我又决定短期内不去魔都了，木耳还说我欠她一顿饭，不知道会是什么时候了，哈哈！
昨天下午木耳（@ainesmile）突然给我打电话，问我晚上有没有空一起出去玩，我当然有空啦。木耳的声音比我想象的要成熟一点，哈哈，其实再想想也是快大三的人了，这样的声音也正常。大概是像小妞，疯丫头那种腻腻，软软的声音听多，下意识的以为所有女的都应该那样了。不过后来发现木耳说话的语气还是有点点小女孩的那种感觉。
出门的时候刚好遇上下班人流高峰时段，地铁上好多人，前几个站一直是只上不下。到了人民广场站后，又绕来绕去，问了几个人，才找到来福士广场。木耳在KFC门口等我，我正要给她打招呼，她就一下认出我来了，让我觉得有点惊讶。找到坐在那里的猫猫（@maovivi），猫猫是个很开朗外向的人，总是逗木耳玩，我连话都插不上，只好在旁边坐着看她们玩。没多久后，可可（@zkaip）也来了，挺有速度的嘛！本来我以为可可是个小正太形象呢，囧！
四人出了KFC闲逛，找吃的地方，大家都对那块不熟，还打电话问了人，结果还是没结论，于是继续瞎逛，到了南京路步行街。之后经过小杨生煎，我之前只听人说过小杨生煎有机会一定要吃吃，于是心里暗喜。钱是可可出的，哇哈哈，蹭了一顿！不过最后那些汤浪费了，生煎倒是味道不错，就是大个了点，出乎我的意料，于是吃完生煎就没胃口继续喝汤了。
吃饱喝足继续逛街，猫猫好像是想买几个世博会的吉祥物海宝回去，不过最后都没挑到满意的。木耳一直说要在8点钟回去，又逛了一会儿就准备各自回家了。我们都是坐2号线，我跟木耳是一个方向，可可跟猫猫是一个方向。木耳比我先下，她在中山公园站转3号线，没几分钟她在推上说，坐错了，坐到4号线上去了，哈哈，真是木耳的风格呢！
周六之后，一直在看小说和动画片。越来越觉得没有好看的小说了，于是试图把自己的注意力转移回动画片上去。看完了13集的《Working!!》和12集的《江户盗贼团五叶》，还看了没有完结的36集《妖精的尾巴》。最合我口味的是《妖精的尾巴》，差不多一直是高潮，没什么铺垫和伏笔之类的，所以很轻松，没用费脑子。画面也是最合我口味的那类传统大眼睛好身材的人物造型，还算细致的物品和景观。《Working!!》的结局不是很喜欢，感觉不像结局，中间的情节倒是还行。《江户盗贼团五叶》有很浓重的日风，但人物造型实在不习惯，那个面部轮廓、五官都不习惯，我好像是第一次看到这种类型的，但其他方面都画得很精细，音乐也好，情节么，还行吧，总共12集我直到第10集才大致明白整个的来龙去脉，但我仍然觉得这没什么特别的，好像这种讲述方法的动画片也不少。不过我觉得吧，这三部里最赞的还是《江户盗贼团五叶》，从另一个角度讲，如果中国动画片在遥远的未来能有所发展的话，可能《江户盗贼团五叶》这样的是最后被模仿达到的。
把ctags封装了一把，其实是CodeLite中的codelite_indexer，因为它已经把ctags提取出来了，不过是5.6版本，又对C++部分做了些修改，不过我不清楚这些修改有什么作用。有点奇怪的是，如果在Lua中用的话，只能提取一次tags，再试图提取tags的话会出错，就我现在猜测可能是里面有些全局状态，用过后没有恢复。于是我只好用Rings了，这是个在Lua的state里再创建一个state来执行代码，master state和slave state之间基本可以互不影响，但也可以传递些数据。这样我就每次都是在一个新new出来的Rings的slave state里调用一次ctags。在封装ctags的时候发现codelite_indexer没有把gnu regex编译进去，这需要指定几个宏定义，看makefile就知道了。
现在已经可以将所有文件都提取一遍tags，并存入数据库中了。而context视图都是在数据库中查找可能匹配的符号信息的。但这需要保证当前数据库中的符号是正确的最新的，所以一个合适的自动更新符号数据库的机制就很有必要，现在还没想好要怎么弄，既要有及时性，又要求不能影响用户的操作体验。
之后还剩下一个大特性是relative视图了，这个目前有些困难，无论是数据上还是界面上，都没有比较方便的现成解决方案。
