All Stories

DForD SourceCoding介绍

DForD SourceCoding介绍

  我一直在寻找,甚至试图自己编写一个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...

Lua中使用DOM读写XML

Lua中使用DOM读写XML

  在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...

LuaPack

LuaPack

  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了,只好自己写代码转换了。

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

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

  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号线上去了,哈哈,真是木耳的风格呢!