missdeer之程序的野望

好用的Mac五笔输入法

missdeer — Sun, 05 Sep 2010 05:05:55 +0000

　　看到推友@davidx_me说有个叫WBIM的for Mac的五笔输入法，马上去下载了来试用一番。之前一直用系统自带的那个五笔型输入法，相当不好用，不但字符小，应该是GB2312的吧，而且连候选提示都没有，其他的常用选项更不用说了。试用了WBIM后，就爱不释手了，虽然跟小鸭、极点神马的在可配置选项上有所差距，但总体来说，已经可以说是鸟枪换炮了。
　　它有着大部分常用的输入需求的选项，比如繁简切换、中英文标点、全角半角、空格，还可以自定义翻页的快捷键，可以自定义用户词库，比较遗憾的是貌似不能自定义选择候选的第二三项的快捷键，不过好在五笔输入绝大多数是选择第一项的，所以也可以忍受。
　　再有一个还算满意的是上屏速度不慢，虽然偶尔还是有点呆滞，不过也在可以忍受的范围内。
　　最后要说一下，这个软件目前貌似是免费的，这对于混迹于人傻钱又多的Mac用户群中偶尔几个穷人来说，实在是个福音。

目前最好的Lua IDE

missdeer — Tue, 31 Aug 2010 05:27:10 +0000

　　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和调试方面还有很大的提升空间。

又系统还原，又丢失数据

missdeer — Mon, 30 Aug 2010 03:07:19 +0000

　　昨天鬼使神差地想下几部爱情动作片看看，结果果然不幸中招了，乱78糟地起了一堆的进程，然后装上QQ医生，删那些可疑文件，最后不幸地不能进入系统了，一登录进桌面就立即自动注销了。于是只好恢复到出厂状态了，郁闷的是那块硬盘上的其他东西都备份不下来了。说起来，有各种备份措施可以使用的，但我仍然杯具了，是有原因了。
　　首先，我的笔记本自带的光驱不能工作了，这是一大杯具。进入Access IBM的备份和还原界面后，虽然有备份选项，还能找到硬盘上的所有数据，但即使在USB口上接了下刻录机，也找不到那个可写媒介。IBM的软件果然糟糕哇！
　　其次是我使用硬盘的方式有问题。一直都是整块硬盘的使用，不分区，然后有一块外接硬盘通过USB口使用。实践证明，外接USB硬盘已经有好几次貌似都因为USB的问题把整个分区甚至全部分区都弄得不能访问了。
　　最后要说的是，网络备份只是小孩子过家家的玩意儿，当然，我只是使用那些免费的服务，不但空间容量小，而且传输速度慢，以及到目前为止并没有证明其可靠性有良好的保证。
　　所以最后的结论是，等手头开始宽裕了，就装个高配置的台式机，最好能配个RAID，这样应该算是比较可靠的了。

DForD SourceCoding介绍

missdeer — Sat, 28 Aug 2010 05:06:29 +0000

　　我一直在寻找，甚至试图自己编写一个Source Insight的替代品，主要看中它作为一个源代码阅读工具，并具有良好的通用代码编辑功能。如果一定要找出同类产品来，还真是比较难，也许Komodo IDE和SlickEdit在通用代码编辑器的范围上可以往上靠，但在代码阅读器的范围内，实在很少见，可能doxygen和understand for C++可以勉强算是一类，但实现方式差别很大。现在有了DForD SourceCoding，总的说来，它是最接近Source Insight定位的同类产品。
　　DForD SourceCoding具有良好的中文支持，这得益于Scintilla控件的完美实现和ICU的强大兼容性。Source Insight的中文支持一直是其软肋，多年来没有什么实质性的改进，无论是保存项目文件的路径字符，还是文件中的字符，凡是中文，都很有可能出现轻重不一的问题，DForD SourceCoding则完全没有这些问题。
　　DForD SourceCoding使用Tab栏多文档界面，很难想像如今还有一个拥有大量用户的多文档界面的软件，居然没有Tab栏，Source Insight就是那么一个独树一帜的软件，以至于有牛人通过逆向工程等手段，给Source Insight开发了外挂，通过外挂给Source Insight添加Tab浏览等功能，可谓用心良苦。
　　还有一个大问题是DForD SourceCoding的代码编辑器是支持代码折叠的，而Source Insight至今仍无任何迹象显示要在这方面有所改进。代码折叠也算是众多Source Insight用户特别期待的一个功能了，对于现在一个完整的代码编辑器，基本上可算是标准配置，可是比较遗憾的是，这个功能似乎连外挂也是不能指望上了。
　　当然DForD SourceCoding也有不少缺点，比较明显的是，速度比较慢，比起Source Insight不是差了一两个数量级。其次，DForD SourceCoding的代码分析功能相比Source Insight来说，不够精准。DForD SourceCoding直接使用了ctags和cscope来进行代码分析，而Source Insight应该是对cscope进行了一定的改进，而且跟编辑器结合得更紧密。另外，DForD SourceCoding虽然本身是基于一个Lua脚本语言扩展的架构实现，但它并不开放这个扩展构架以便用户进行二次开发，而Source Insight则是向用户开放了脚本扩展的能力。所以说，DForD SourceCoding还需要持续改进，才能彻底战胜Source Insight啊。
　　最后有一点值得说的是，Source Insight比较贵，DForD SourceCoding的定价才是它的一半多一点，当然这要看用户如何选择了，是否少花近100美元买80%功能的呢？

Lua中使用DOM读写XML

missdeer — Sun, 15 Aug 2010 00:18:26 +0000

　　在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 * 20 ) ) -- set node text 　　end 　　doc:save( "C:\\testxml\\testdata.xml" , true )
　　打开刚才创建并保存的XML文件，并读取：
　　require "rapidxml" 　　local doc = rapidxml.open( "C:\\testxml\\testdata.xml" ) 　　local root = doc:root() 　　local child_nodes = root:children() 　　for k, child_node in pairs( child_nodes ) do 　　　　if child_node:type() == rapidxml.node_element then 　　　　　　if child_node:exists_attr( "index" ) then 　　　　　　　　print( child_node:name(), child_node:attribute( "index" ) ) -- 打印该节点的名称和index属性值　　　　　　end 　　　　　　print( child_node:text() ) -- 打印该节点的文本内容　　　　end 　　end
　　比较方便的是，rapidxml把子节点集合用Lua table表示，所以可以方便地使用pairs等Lua的设施来进行操作。xerces的使用方法与上面的代码类似。

LuaPack

missdeer — Fri, 13 Aug 2010 00:53:51 +0000

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

阶段性小结

missdeer — Sat, 31 Jul 2010 01:50:39 +0000

　　昨天算是发布出去了，这次花了3个月时间。修正了一些bug，添加了一些新特性，修改了一些功能。总之，现在回头看来，不那么令人满意。
　　没有UT是最大的问题，根本不能保证某次修改会影响到什么。这不能再忽视了，test case要开始补起来。
　　其次是编译器差异和编译模式差异之大，出乎我的意料。好几次都是VC编译出来的正常，用GCC编译的就不正常。或者debug编译的正常，release的不正常。这是因为我离不开Visual Assist，也有点离不开VC的调试器。这点实在不好解决。
　　再次是Lua开发环境还是不够好用。Auto Completion不准确就不说了，有时Auto Completion出来过后，整个程序就会很卡，不知道为什么。以后要能做到Auto Completion分库，可以让用户随意通过增删文件来增删符号库。
　　最后一点是对架构的不满意。经过如今大半年的迭代发现，插件扩展架构的可扩展性和可裁剪性不够灵活。这点现在还没有具体的思路，或者说一直觉得实现上也许有点麻烦。
　　除了这些外，还有许多特性要增加，比如增加几种常见的SCM工具支持，开放二次开发接口，增加插件扩展的开发环境等等。

实现注释和取消注释

missdeer — Tue, 20 Jul 2010 03:30:11 +0000

　　这是个很简单的功能，但却很有用。SciTE和Notepad++都有一套自己的实现，感觉Notepad++的效果比较好。从它们的配置文件中提取出众多编程语言的注释符号即可。注释分为两类，一类是行注释，另一类块注释。不是每种编程语言都支持这两类注释方式，甚至有的编程语言都不支持可以有注释。当然这个不是很重要，反正所有的信息可以写在配置文件中。
　　昨天还意外地发现，用boost.lambda对std::basic_string和wxString对象进行==比较时，用VC编译的运行正常，用GCC则一直不正确。一开始还以为是两个编译器对两种字符串对象的内存布局不一样引起不同的结果。最后发现，其实是我自己写的迭代器在std::find/std::find_if中不正常，在GCC编译的程序中，比较谓词根本没有被调用。回想起来当时看到GCC的std::find/std::find_if对于随机迭代器是特化实现的，想想其实我那个迭代器不需要随机迭代器，用双向迭代器就可以了，改了后，一切都正常了！

自定义快捷键

missdeer — Sun, 18 Jul 2010 22:28:20 +0000

　　昨天完成了自定义快捷键的特性。该特性在配置对话框中实现与用户交互。
　　首先，在程序启动时，装载所有菜单项时，把所有菜单项的ID、标题、快捷键信息记录下来，作为缺省的配置。将缺省配置保存到文件中，然后查看是否存在保存了修改后配置的文件，如果存在该文件，则装载该文件的配置，应用到程序中。应用过程分两步，刷新菜单显示和设置快捷键表。
　　接着，处理在配置对话框中的用户交互响应。在对话框初始化时，加载当前正在使用的快捷键配置。用户可以修改其中任意一项的配置，当用户选择应用修改后的配置时，就将当前配置保存到文件中，以便下次程序启动时可以装载这个修改后的配置。
　　基本处理流程就是这样。用wxWidgets实现时，也是比较容易的。wxWidgets提供了快捷键相关的几个类和方法，相当方便，包括wxAcceleratorEntry、wxAcceleratorTable、SetAcceleratorTable等等。
　　这里不得不抱怨一下，wxWidgets对于一些明明日常需要使用的类和方法，竟然没有文档进行说明。另外还发现个问题，wxAcceleratorEntry有个ToString方法，当其中的Key Code是除了字母、数字外的其他的可打印字符时，会断言失败，太Orz了，只好自己写代码转换了。

实现关系视图，使用gcc编译

missdeer — Fri, 16 Jul 2010 14:05:01 +0000

　　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那样可以用算是歪打正着吧。
　　好吧，总之最头痛的两件事算是解决了。