missdeer之程序的野望

　　今天看到推友@liancheng说Mozilla/WPF/QT/GNOME3都同质化了，大体的意思是指这几种方案都把表现层和逻辑层分离得很独立，复杂的，高度重用的，平台相关的部分，用C/C++之类的语言实现成组件，表现层用XML描述界面，用CSS之类的样式描述skin，再用如JS之类的脚本语言描述运算逻辑粘合组件和界面。
　　我最早了解到这种架构是几年前Firefox开始大肆流行，网上这类技术文章也大量涌现。当时也是很惊叹于Firefox的扩展机制如此灵活，却对它的开发环境很是鄙视，而且用于表述逻辑的脚本语言是用JS这个我完全没了解过的东西，所以看过介绍后，就丢到一边了。后来也偶尔听说WPF、XAML之类的东西，但对.NET一直没啥好感，于是也没研究。最近几个月跟个网友讨论，提到QT的界面方案，大体上也是知道QT也采用这种架构了，而且也确实一直计划着做完眼前的这组东西后，以后全面转向QT了，但仍一直没抽出时间来研究。
　　今天看到@liancheng的讨论后，让我有点儿沮丧。我现在用C++/wxWidgets做主框架，好不容易设计并实现了一个并不精巧的插件机制，用Lua来编写逻辑，还总是有这样那样的限制，这不就是典型的重新发明轮子么，而且发明的是个不咋样的轮子。唉！

　　前几天，把所有的插件以插件为单位打包成zip了。不过不知道wxWidgets中的zip虚拟文件系统如何支持密码，至少是没找到相关的选项。现在的情况是验证了方案可行性，可以确认功能上的不缺失以及性能上的损耗在可接受的范围内，但真正实用是一定要有密码的，也就是为了保护插件中的源代码。以前还以为带了密码就不方便第三方开发插件了，现在想通了，其实只要我提供一个插件开发环境，其中自带插件打包功能，这样就可以用同一个密码了。既然wxWidgets没有简单方便的接口来支持密码zip，那就只好自己写一个这样的功能了，好在zip实在是一个很大众化的格式，源代码很容易找到。

　　宿主程序提供了界面国际化，那么插件不能提供国际化就说不过去了，至少得有这样的机制以供支撑该种需求嘛。　　得益于wxWidgets对国际化的良好支持，要让嵌入的Lua解释执行的Lua脚本也能根据宿主程序的本地化信息进行正确的处理非常简单。wxWidgets中对要进行国际化的字符串用_()进行包裹，其实这是一个宏，用于调用真正的翻译功能，比如wxGetTranslation。所以在嵌入的Lua中将wxGetTranslation函数注册到Lua中即可，然后在Lua脚本的最开始处将该函数换个更简单的名字，比如_，这是最好的名字了，哈哈。这样就可以在Lua脚本中对需要进行国际化的字符串也用_()进行包裹，它会调用wxGetTranslation函数。　　GNU的国际化方案套餐中，提供一个叫xgettext的工具，可以从众多编程语言的源代码文件中提取出字符串，生成po文件以供翻译生成mo文件。比较不幸的是，xgettext不能支持Lua语言，同时由于我这个项目中使用的插件描述信息中有一部分界面信息是在xml文件中的，这也是一种自定义的格式，所在很不幸地xgettext更是不能处理啊！所以我在想，我是否要先写个可以支持Lua和我这种xml格式的类似xgettext的工具呢？Poedit太扯蛋了，居然只能认它自己生成的那种po格式的文件，稍微改一点就报错了！

　　到昨天为止，基本完成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时发现它只能从源代码中提取出需要翻译的字符串，不能全新的创建一个，这太土了，以后一定要自己写个好用的。　　最后的一个问题是，现在的插件扩展机制，容易出现重复代码，比如相同的功能会在菜单中写一遍，在工具栏中也写一遍，这该怎么修改一下呢，呃，得仔细考虑考虑

　　昨天偶然发现一个超级严重的问题，程序运行一小会儿就会自动退出，什么提示都没有。至于没提示，这已经有一段时间了，照理说，内部状态、逻辑不正常么，可以给个Windows的崩溃报告嘛，可是它偏偏没有，弄得我要跟着崩溃了。　　后来在代码中加入一些跟踪语句，发现出错的原因跟我的猜测一致，内嵌的Lua解释器栈溢出了。这是个很头痛的问题，以前听人说过，如果没有sandbox，插件运行环境是不可靠的，呃，最出名的是chrome的架构，经典的sandbox。但是我这个程序跟它的情况有点不同，在主窗口和子窗口上都有大量的用户交互操作，以及主窗口和子窗口之间大量的交互，子进程间的通信会很复杂。而且现在引起崩溃的，都是主窗口中的逻辑，所以还是会导致整个程序的不可用。　　昨天晚上调试了好久，发现只要更新工具栏按钮或主菜单项的界面状态的响应函数打开后，过一会儿就会退出。所以最后可以把范围缩小在C++调用Lua函数的那一块代码上。我不怀疑Lua的代码有问题，凭我现在对Lua的了解，即使真有问题，估计我也是束手无策的。既然是栈溢出，而且时间不长就可以重现。我仔细地看了那块代码，又看了Lua manual和PIL，以及Luabind Documentation，发现我一直忽略的一个问题，在调用Lua的C API出错后，Lua经常会把出错信息压入栈中，而Luabind可能会直接将其封装为luabind::error类型的异常抛出，然后我就只是看一下那个字符串内容，却没其他处理了。这是一处错误，应该在提取字符串后，将其弹出。另一处错误是，我这里调用Lua中的函数，都是存放在一个表中的，所以中间无论哪个步骤出错，都应该把先前压入栈中的东西弹出。还有一处错误是，最后我从Lua栈中获取到函数后，用luabind::object封装了一把，然后luabind::call_function来调用，这时我又直接返回了，却没把这个放在栈中的函数弹出。　　昨晚解决了这三个问题后，还以为所有问题都已经修正了。今天又测试了一遍，发现过了约半个小时后，程序还是自动退出了，而且连那exe文件都没了！我要疯了！　　唉，这什么都是从零开始的，风险实在太大了。使用wxWidgets是第一次，复杂的内嵌Lua扩展框架是第一次，使用Luabind是第一次，使用wxLua是第一次，把所有东西混在一起用更是第一次！而且很不爽的是，已经用惯了MS的解决方案的我，没有像MSDN这样的大而全的文档极不适应，那些说使用开源的东西成本低的人，不知是真的短视，还是别有用心呢。