missdeer之程序的野望

　　Lua跟众多其他开源的脚本语言一样，都没有一个官方的或绝对统治地位的IDE。而与诸如Python和Ruby这些大红大紫的脚本语言相比，Lua算不上一个流行的语言，也就是当年WoW的推出，带动了Lua的发展，相应的，Lua的开发工具也就显得更加落后，不但缺少一个比较正统或权威的库集合，还缺少好用的编辑器。之前我已经介绍过LuaPack，一个与Lua For Windows定位类似的开源项目，提供了几十个常用功能的第三方库打包。这回就介绍一个目前看来最好用的Lua IDE，叫DForD LuaCoding，它在LuaPack中也集成了，但它是个共享软件，在LuaPack中集成的那个版本只有在每次启动时弹出个要求输入注册码的对话框，只要点击“试用”按钮就可以继续使用了，除此之外没有任何其他的时间或功能上的限制。但是在DForD LuaCoding的官方网站上下载的版本，除了弹nag窗口，还有试用30天的时间限制，之后就只能花99美元购买了，当然网上也有0day。
　　DForD LuaCoding采用解决方案、工程组织方式来管理文件，任一时刻最多可以打开一个解决方案，而每个解决方案中可以有任意多个工程，这种组织方式与Visual Studio类似。另外，DForD LuaCoding还有通过文件名快速定位并打开文件的功能，这在Visual Studio没有直接的支持，需要装像Visual Assist X之类的第三方插件才行。这个功能对于一个解决方案中包含了大量文件的情况下特别有用。
　　DForD LuaCoding使用Tab浏览多个打开的文档，得益于Scintilla控件，语法着色，代码折叠等现代代码编辑器常有的功能几乎都有。不过由于DForD LuaCoding的定位是一个专业的IDE，而不是一个通用的代码编辑器，所以跟SciTE、Notepad++这种编辑器相比，就少了一些平常不太用的功能，比如复制行，交换行等等。不过总的说来，作为一个IDE内嵌的编辑器，当前已有的功能足以满足99%的编辑需求。
　　DForD LuaCoding提供了一个有点模仿TextMate的Code Snippet功能，不过TextMate中叫Tab triggers，该功能全部通过Tab键完成，而DForD LuaCoding中使用了三个不同的快捷键分别用于缩写展开和编辑热点前后跳转。这两种方式可以说各有优缺点吧，总的说来，我个人不太喜欢TextMate中一个Tab具有不同含义的作法，而且DForD LuaCoding中的三个快捷键分布得还算方便。
　　DForD LuaCoding提供了一定程序的Auto Completion，即自动完成。对Lua标准库的支持比较完善，不过也是因为Lua标准库很小很简单吧，呵呵，还支持几个其他的第三方库。但要说的是，该Auto Completion功能的准确性不高，有时把当前文档中的单词都列出来了，有时把所有库的表名列出来了，有时把所有函数名列出来了。不过实话说，有了这个Auto Completion，只要记住前几个字母，后面可能的候选字都列出来了，仍然可以减轻记忆负担，减少击键次数和拼写错误。另外，DForD LuaCoding对标准库中的函数，还提供了简单的call tips说明，只要鼠标光标停留在函数名上几秒钟，就会弹出一个tooltip，显示出该函数的简单说明，了胜于无吧。
　　最后值得一说的是DForD LuaCoding提供了Lua脚本调试功能，包括断点、单步等，操作快捷键与Visual Studio中的一样。只不过对第三方嵌入Lua解释器的程序进行调试的支持就不怎么样了，这方面要向Decoda学习，尽管Decoda做得也不好，不但速度暴降而且稳定性也略差，在这点上可以算是一大竞争点，但Decoda的其它方面在DForD LuaCoding面前就一无是处了。
　　总而言之，DForD LuaCoding可算是目前能找到的最好的Lua IDE了，但在Auto Completion和调试方面还有很大的提升空间。

　　在Lua神作《PIL》中操作XML的示例是用expat库的，众所周知expat是用类似SAX的接口的，这里介绍一下使用其他的库来实现DOM接口操作XML。
　　可以使用的库有几个选择，包括ltxml，xerces，rapidxml等等。ltxml使用TinyXML和TinyXPath提供的服务，xerces使用Xerces-C++提供的服务，而rapidxml则是使用RapidXML。这三个库我都有过一段时间的使用，不过都没怎么深入过。总的说来三个库各有特色，呃，其实是它们依赖的C/C++库的特点，ltxml我不是很喜欢，当初用的时候发现不知道为什么，同样一段代码执行多次后，打开并读取XML文档就会出错。于是后来转用xerces，它倒是基本让人满意，不过得附带一个Xerces-C++的DLL，感觉有点不爽，而且Xerces-C++应该说是比较完整的实现了XML的几个接口标准，但xerces只是封装了其中DOM读写的很小一部分接口。而rapidxml胜在运行速度飞快，从RapidXML的项目主页上可以看到一个简单的横向评测结果。xerces和rapidxml的Lua接口非常相似，除了几个节点类型常量的名称和载入的表的名称不同外，其他的读写接口名称和签名几乎一模一样，它们的源代码可以在它们的项目主页上通过svn下载得到，但需要用户自己编译，当然也可以下载安装LuaPack，LuaPack提供已经编译好的xerces和rapidxml文件，但要注意的是由于使用VC2010进行编译，只能在Windows XP SP3或更高版本的Windows系统上运行。
　　下面以rapidxml为例，简单演示一下如何操作XML文档。
　　新建一个XML文档，并保存：

　　require “rapidxml”
　　local doc = rapidxml.parse( “” ) — assign root node xml text
　　local root = doc:root()
　　for i = 1, 10 do
　　　　local new_child = root:append( string.format( “test_node_%d”, i ) ) — create new child node
　　　　new_child:set_attr( “index”, tostring( i * 10 ) ) — append new attribute named index with value i *10
　　　　new_child:set_text( tostring( i [...]

　　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更值得推荐使用。

　　俗话说，磨刀不误砍柴功。对于这句话，我一直都自认为是辩证地看待的，在某些工作前，先做些准备工作可以极大地提高之后的效率，好比Kunth老爹的TeX。不过很多时候，磨刀也是件很费时费力的事情，好比Kunth老爹的TeX。
　　这几天一直在考虑实现ZenHTML，这是一种极大提高hard coding效率的code snippet方法。其中有一种可以认为是一种“小语言”，呃，这是《UNIX程序设计艺术》中的说法，用GoF的《设计模式》中的说法应该算是interpreter模式。不管怎么说，反正就是有一项任务是要解释字符串，根据字符串的不同表达式来作出不同的响应。
　　刚开始的时候我是觉得这个解析工作似乎非常简单，没有必要把它提高到“语言”这种层面对待，只要识别出两三个操作符就可以了。不过后来马上发现，实现起来并不轻松。我意识到，用Lua实现的话，用LPeg将是最合适的解决方案。今天又翻出LPeg的manual来看，还是看得有点糊里糊涂。明天继续。
　　所以说，磨刀也费时啊！

　　其实这个问题老早就有了，当时还在Lua的maillist上提过，不过当时我只是发现LuaJIT2在执行Lua脚本时，如果Lua脚本调用了不存在的C函数时会使宿主崩溃，Mike Pall同学（LuaJIT的作者）倒是很爽快地解决了这个问题。后来发现，Mike Pall解决的只是一部分，我这里因为用到了Luabind，通过Luabind来调用执行Lua函数，如果Lua脚本又调用到不存在的C++函数，进程就会无声无息地退出，而如果是官方Lua的话，则是会老老实实地打印那些出错信息出来。
　　昨天忍无可忍了，就又向Lua maillist发了封邮件，今天发现Mike Pall和Daniel Wallin（Luabind的作者）争起来了，呵呵。Mike Pall说问题在Linux上和Windows/x64上都没能重现，不知道Windows/x86出了什么问题，可能是Luabind重复抛出异常了，Daniel Wallin则说Luabind只是简单地调用了lua_error，他倒是能在虚拟机的Windows环境下重现问题，最后他又给出了一段简化后的代码，只要lua_error调用后面有C++对象的析构，LuaJIT就会出问题。
　　我倒是偶然看到今年1月份的Lua maillist上的邮件，Mike Pall曾经说过Windows/x86上MSVC实现try/catch是用SEH实现的，这个LuaJIT处理可能有点问题。但他后来的邮件中好像又说在新代码中已经解决这个问题了。我于是用MinGW试了试，GCC 4.4.0编译出来的，确实是没问题的呢！
　　不过最后，又看到Mike Pall好大一篇解释，最终结论是建议所有用户都升级使用x64，囧！