All Stories
看了两天小说，呃，又堕落了。由于已经看完了，今天就比较认真地折腾起flex和bison。其实之前已经把lex和yacc脚本写完大部分了，至少可以从控制台打印结果出来了。今天就修改一下yacc脚本，把原来打印到控制台的内容保存在内存中，到时候转储成xml格式。因为只是要显示在界面的树视图中，我想了想，也就只有函数定义值得这么显示一下，所以也就只处理了这部分。 总的说来，感觉yacc有点土，它只能接受一种输入接口，而我用flex时发现可以生成C++代码，所以要给bison用的话，仍然需要把这个C++类的接口再适配成bison可用的C接口。 这种任务果然是实践性非常强的工作，本来看过一些资料，当然，能找到的资料也基本内容一样，翻来覆去那么几句话几个例子，等到自己要做时，不时地有些迷惑，只得慢慢尝试，倒也捣鼓出来了。 在yacc中可以为每个token或type指定一个union中的某个成员，其实这个成员的指定只在规则描述段中的action中有用，就我看来各种资料、教程中说的那一堆实在是扰乱视线。对于一个C/C++程序员来说，这种用法只是万千技巧中的一种，实在没必要说得那么严肃仔细，好像不那么用就不行了似的。 再说个我觉得yacc土的地方，由于这种格式上的限制，在action中只能访问一些全局的变量、对象等，至少在思维逻辑上很不连贯，其实lex也有这个问题。要我说，比较让现代化的做法是它应该生成一个类，每组action触发时，应该调用该类中的某个回调函数或虚函数，这里形式有好几种，都可以考虑，不知道boost.spirit是不是这种形式的，也许ANTLR等其他类似的工具就是这么做的。 最后抱怨一下，Lua Reference Manual中附录的complete syntax不能直接用的，至少不能直接用于yacc，有好些地方似乎没写全。
昨天偶尔发现，在笔记本上编译的工程在台式机上启动即崩溃。一开始的时候我认为是因为lua装入的一些第三方库dll没有设置好依赖的dll路径和正确的manifest配置，后来发现问题不是那么简单。 首先是我用了LuaJIT的dll，而之后发现LuaJIT要求CPU支持SSE2指令集的，我那台式机是2002年的配置，当然没有。换成官方Lua后，问题仍然存在。 接着发现，安装程序没有把配置文件复制到正确的文件夹下。看了一下安装程序的脚本，果然没写对。但是当把配置文件的路径修改正确后，问题仍然存在。 因为台式机上装了Win2000ProSP4，WinXPProSP2和Win2003，所以当XP上仍然不能运行时，我切换到Win2000和Win2003上进行测试，发现问题同样存在。我考虑了一下两台机器软硬件的区别，猜想是不是仍然是软件配置的问题。于是我在笔记本上用VirtualBox建了个干净的XP系统，第一次运行时，居然报了个错，说ltxml加载不成功。幸好我前天已经自己写了个Xerces C++的绑定，而且用于的地方现在还不多，立马全都把使用ltxml的地方改成用xerces的。之后虚拟机上可以正常运行了。 到了这一点，说明可以排除安装部署的问题。再想想两台机器的区别，台式机上的3个系统都是原生的中文版系统，而笔记本上和虚拟机上的都是英文版的，其中笔记本上的打了个可以处理中文的多国语言包。我有点怀疑会不会是因为这个缘故，但又觉得可能性不大，如果真是这个原因的话就不好处理了。我试着把安装后的那些mo文件都删掉，结果仍然没用。 最后我没有办法了，只好修改源代码，从程序开始处依次加入日志，看到底在哪一步引起崩溃的。经过逐步排查，最后定位到使用Crypto++的初始化RSA公钥的对象构造时崩溃了，连异常都没有抛出。这时我想到了LuaJIT对CPU的要求，猜想会不会Crypto++编译时也受CPU的影响。用CPU-Z看了一下虚拟机的CPU，是跟宿主的CPU几乎相同的。不再继续猜想，直接在台式机上编译了一遍Crypto++，拿到笔记本上可以链接上，再把exe复制到台式机上，程序也可以正常运行了。 至此，问题解决！这时我不禁有些担心，我这样一直用笔记本写的程序会不会都有这种问题，一遇到老机器，就会罢工呢！
本来是有ltxml这个库的，这个库使用TinyXML和TinyXPath，本来用着，也勉强，可以读取xml文件，但也不时地出点小问题，不过都让我规避掉了。这回是想写xml文件了，结果发现ltxml的接口我很不习惯，嗯，不喜欢，于是想自己重新写一个新的绑定。 我首先看了一下libxml2，发现它的文档和例子都不是很清晰，不想继续投入精力去研究了。剩下两个选择，MSXML和Xerces C++。这两个库我都用C++的类做了一层简单的封装，可以适配应用STL中的算法。后来想想，MSXML的那个封装因为当初只考虑配合MFC/WTL使用，所有的字符串都用CString了，而且另外一点是MSXML是只在Windows上可用，Xerces C++是跨平台的，特别是可以用gcc编译，于是最后就选择了Xerces C++。 本来我的那个封装是只针对DOM接口的，同时有4个类，分别对应DOM文档、DOM节点、DOM节点列表，以及DOM节点列表的迭代器。绑定的过程参考了ltxml的实现，但只给DOM文档和DOM节点定义了userdata，因为Lua有table，所以可以用来表示DOM节点列表。 绑定完成后，简单试用了一下，读取，写入都基本满足当前的需求，除了不知道怎么让它写入的时候进行format pretty print，老是多加个换行符，中间有空行可一点都不pretty。
宿主程序提供了界面国际化，那么插件不能提供国际化就说不过去了，至少得有这样的机制以供支撑该种需求嘛。 得益于wxWidgets对国际化的良好支持，要让嵌入的Lua解释执行的Lua脚本也能根据宿主程序的本地化信息进行正确的处理非常简单。wxWidgets中对要进行国际化的字符串用_()进行包裹，其实这是一个宏，用于调用真正的翻译功能，比如wxGetTranslation。所以在嵌入的Lua中将wxGetTranslation函数注册到Lua中即可，然后在Lua脚本的最开始处将该函数换个更简单的名字，比如_，这是最好的名字了，哈哈。这样就可以在Lua脚本中对需要进行国际化的字符串也用_()进行包裹，它会调用wxGetTranslation函数。 GNU的国际化方案套餐中，提供一个叫xgettext的工具，可以从众多编程语言的源代码文件中提取出字符串，生成po文件以供翻译生成mo文件。比较不幸的是，xgettext不能支持Lua语言，同时由于我这个项目中使用的插件描述信息中有一部分界面信息是在xml文件中的，这也是一种自定义的格式，所在很不幸地xgettext更是不能处理啊！所以我在想，我是否要先写个可以支持Lua和我这种xml格式的类似xgettext的工具呢？Poedit太扯蛋了，居然只能认它自己生成的那种po格式的文件，稍微改一点就报错了！
上午花了几个小时修改了Auto Completion功能后，用起来的感觉已经超过LuaForWindows中带的SciTE了。于是又开始寻找起可以分析Lua代码并生成AST的东西，google了大半天，发现了几个Lua项目，一个ANTLR的文本，最后都可耻地放弃了！因为那些Lua项目全都由于这样那样原因而不可用，而ANTLR，呃，我试了下，它是用LL分析的，语法元素的分析顺序不能直接为我所用，而且我在之前一点都不了解ANTLR这个东西，我甚至翻遍网络，找不到怎么让它在需要的时候记录下行号！后来又翻了一下Lua的源代码，呃，说实话真没习惯它几乎每次函数调用都有一个回调函数的用法，嗯，我真的只会一点C++了，放弃！ 真是个头痛的问题啊！我觉得我还是退回去，老老实实地再温习一下编译原理，用flex和bison自己写一个分析模块吧，毕竟Lua的语言核心真的很小很小！
昨天晚上，突然发现又有内存泄漏了，我真的要疯掉了。一段代码一段代码地注释掉，来查看到底是哪段代码引起泄漏的，中间又偶然发现有些情况下又没有泄漏，真是太容易迷惑人了。最后发现还是原来那段扫描文件目录并分析xml文件那个函数引起的泄漏，费了老大的劲儿。这是一种比较奇怪的现象，我到现在也没有想明白怎么会有这种情况。本来以字符串作为key插入到std::map中时，如果有重复的key，我会用clock()生成一个数字添加到key的末尾，作为一个新key，以为这样就可以保证都插入进去了。现在发现似乎还是有漏网之鱼，真是太奇怪了。不过我也不想深究这个问题了，索性遇到这种重复的情况，直接在原来的key后面添加一串比较随机的字符，并再添加一个递增的编号，这样再要有重复，我就去买彩票了。 昨天在实现Auto Completion功能，呃，只是Lua编辑时可用。后来发现LuaForWindows中带的SciTE的一个做法可以学一下，就是可以分析出当前编辑器内的所有单词，以这些单词作为Auto Completion的列表源。于是今天想了想，这部分提取出单词的功能应该由C/C++来实现，Boost中有个Tokenizer库，刚好用来作这个事情。看了一下文档，用它自带的一个示例修改了一下测试一番，提取一个828KB的cpp文件中的所有单词，然后用STL的sort算法排序，再unique和erase一把，把重复项去除，最后再用STL中的copy算法复制到另一个vector中，总共这些操作，在VC2008中进行测试。最后发现，在Debug模式中大约在10700ms左右，Release模式则在500ms左右，近20倍的性能差异！我不知道这个比例是线性的，还是指数级的，反正证明一件事，那就是Release的确实比Debug的快很多！
到昨天为止，基本完成Code Snippet的框架，剩下的都是些体力活。该特性要求在点击菜单项时，根据当前光标所在位置的字符串，替换成对应的代码片段。由于菜单项是通过插件添加实现的，而且Code Snippet又根据当前编辑的源代码对应的编程语言不同，也会有不同的处理，所以也是通过不同的插件实现的，这就要求插件可以再次调用插件。好在当初设计插件扩展框架时，已经考虑到这一点，所以虽然有实现过程中有需要慢慢调试的地方，但没有特别大的障碍。 完成Code Snippet后，应该开始Auto Completion特性的开发。该特性是本项目中可算是难度最高的特性之一，同时又有比较高的准确性和运行效率等要求。还有点比较头痛的是，针对不同的编程语言，可复用的东西不多。 此外，还有个功能应该尽早加入，就是处理文件的不同编码。比如通常，尤其是早期的代码，都是直接使用ANSI编码保存。而现在已经比较常用的是保存成UTF-8等编码方式，特别是像LaTeX的一些处理器直接要求输入文件是UTF-8编码。所以应该能在文件的装入和保存时，可以自动处理文件的编码问题，这可以通过iconv或ICU实现，不过问题就在于有了选择，才是苦恼啊！目前我倾向于使用iconv，因为相比之下更轻量，而且够用。 这些天发现，Lua的字符串连接符..效率还真低，怪不得Lua要提供*all和table.concat等设施。 本来Lua中操作XML有几种不同的选择，这跟在C++中情况差不多，我选择的是比较轻量的ltxml。而昨天在Code Snippet特性的开发过程中发现，我把所有的信息都保存在xml中，而每次完成snippet时都从xml中读取，开始几次还是正常的，但只要过一会儿，在调用xml.open时就会报什么试图index一个function值中一个number值，还真是诡异，但调试发现这时无论xml.open还是传入的参数都是正确的，很是纳闷啊。于是只好规避一下，只在开始时读一次，全部都装入到内存中，以后就直接读内存了。 一直以来，都是通过print来进行Lua脚本调试，真是应了那句“一夜回到解放前”。前两天才在界面上加了一个专门的输出窗口用于从Lua脚本打印字符串过来。好比是当年写Windows GUI程序时，用MessageBox调试进化到用OutputDebugStrng进行调试。昨天记起来有LuaLogging这么个第三方库，于是仔细看了看，很简单的功能，只有几个lua文件，可以记录日志到文件、控制台、socket、email或数据库中。于是我参照这些appender的实现，加了一个新的appender，用于将日志打印到宿主的插件输出窗口中，感觉不错。 接着是使用luabind的问题。在网上看到有人说luabind的各个版本都存在指针的double deleting问题，这让我有点惶恐。好在今天看邮件列表时，看到luabind的作者说，这种问题只出现在使用智能指针或类继承时切片的情况，而且要求是Lua的state先于这些对象被销毁，现在没有好的办法来修正这个问题。我想了想，这几种情况我现在都不会遇到，我只有最最简单的嵌入和扩展交互。之后，又发现有人在邮件列表中写了一个luabind和SWIG的性能比较，SWIG的封装比luabind的快一倍。看到这个结果，我觉得是意料之中，SWIG的封装方式比较底层，调用快也是正常的。不过luabind的作者说，他写了些benchmark的测试，在未发布的luabind 0.9中已经有不小的改进，虽然仍然不比SWIG快，但相比0.8.1版本，差距缩小了约一半，期待0.9的发布。 昨天无意中看到云风blog上一篇老文章提到有Lua Ring这么个库，可以在Lua代码中再创建个新的Lua state，让某些代码在这个新的state中运行，从而保护比较重要的核心state。我潜意识中认为，像我现在这个项目使用嵌入Lua来作为插件扩展的运行环境，确实要用一个比较安全的环境，即所谓的沙盒，但这个Lua Ring怎么应用上去，以及能有多少效果，仍然有待考察。 前些天，从SVN上更新的了wxPropertyGrid的代码后，发现用GCC编译不过了，直到昨天仍然不行，实在忍无可忍，真要骂娘了。上它的sf项目见面看了一下，自11月25日更新代码后，估计作者就压根没发现这个问题，于是在上面提了个单。今天发现作者已经回复那个单，并在svn trunk中已经修正了该问题，总算松了口气。 今天仔细学了一下如何让wxWidgets支持国际化，发现非常简单。只要在程序初始化时，自己创建一个wxLocale对象，把mo文件的搜索路径加进去，设置好当前要使用的语言。其他想要被翻译的字符串用_()宏替换wxT()和_T()，如果是个wxString对象，就用wxGetTranslation()，这样在这些字符串会自动从mo文件中读出相应的翻译后的文本，感觉比ini等配置文件，或是国际化资源dll的方案方便很多。不过为了让插件支持国际化，也可以使用类似的方案，但是我有poEdit时发现它只能从源代码中提取出需要翻译的字符串，不能全新的创建一个，这太土了，以后一定要自己写个好用的。 最后的一个问题是，现在的插件扩展机制，容易出现重复代码，比如相同的功能会在菜单中写一遍，在工具栏中也写一遍，这该怎么修改一下呢，呃，得仔细考虑考虑
突然想研究一下软件注册机制中使用比较强的加密算法，能带来什么效果。说到比较强的加密算法，用非对称的算法应该是公认的比较好的选择。流行的大概有RSA、ElGamal和ECC了。翻出几本买了好久，都没仔细看过的书，最后发现我的数学基础实在很差，这方面的思维分析能力也很差，最终大致能看懂原理的只有RSA算法。RSA算法的强度建立在大素数因子分解的基础上，只要选择足够大的两个大素数，当然还要受制到当前主流硬件运算能力，就能保证一定意义上的安全。 目前有很多开源的加密算法库和大数运算库，可以提供RSA算法的实现，比如MIRACL、Crypto++、LibTomCrypt等等。结果发现MIRACL只能免费用于非商业用途，而LibTomCrypt的接口让我比较迷惑而不会用，剩下的Crypto++倒是可以正常使用，接口设计得也非常方便易用，缺点是体积大了点，而且很早以前在网上看到过有人说它有些算法可能涉及到一些版权、专利的问题。 最后是使用RSA实现软件注册算法的问题，从书上看到，注册机使用RSA私钥对用户名进行解密，解密的结果则作为注册码，用户拿到该注册码，输入到软件注册界面后，软件使用RSA公钥对注册码加密，能得到用户名？不过我发现，在用Crypto++进行计算时发现，随便取的一个字符串作为密文用私钥根本解密不了啊，会抛异常说无效的密文，其次，使用公钥进行加密时，也有限制，对明文的长度有限制，根本不能对很长的，可能是密文的字符串进行加密呀！倒是用RSA进行签名是可以的，这种签名方式就与MD5、SHA之类的单向散列算法效果类似了，只能确认明文是否被修改过。 不过我到PEDIY的论坛上问了问，其实采用多强的加密算法没多少区别，只要破解者能找到最后判断的语句，找到关键的那条跳转语句，就可以爆破了，前面的那些复杂的加密解密运算全做无用功了。汗！
上午整了一两个小时，在wxWidgets程序中使用第三方库wxPropGrid，结果发现在VC2008中链接时有几个warning，虽然看起来刺眼，但似乎是可以正常运行的，也没有很在意。然后用MinGW编译链接，最后链接不通过，报未定义的符号，而这些符号是之前用VC2008时报warning的那几个，这就说明不是库编译得有问题，就是本身程序编译得有问题。 我先把焦点放在库上，wxPropGrid是编译成静态库的，这不但编译链接选项不同，连有个宏定义（静态库是WXMAKINGLIB_PROPGRID，动态库是WXMAKINGDLL_PROPGRID）都不同。我仔细观察了该宏定义对源代码的影响，并参考了wxScintilla的做法，发现区别很小，基本可以忽略。于是我琢磨着如果实在不行了，把wxPropGrid编译成动态库试试。正在这么打算的时候，突然想起来，这个宏定义在主程序中没定义啊！一定是这个原因！于是修改了主程序的配置，加上了这个宏定义，重新编译，发现果然有效，VC中也不报warning了，MinGW中也可以链接通过了！ 其实这是个老问题了，只是平时很少遇到这种情形，一时没想起来。
