All Stories
又看到José León新发的blog，再结合吃晚饭时，同事的抱怨，不禁羞愧难当，伟大的Borland，伟大的Delphi，哪怕是几经更名，哪怕是几经易主，曾经的IDE霸主，编辑器就是应该这样的做的。 今天花了点时间重构编辑器的auto completion、call tips模块，框架早已完成，剩下的是只让整个流程运作起来。中途发现几处笔误和遗漏，都不是大问题。清理了原来的代码，从原来的几百行的规模，拆分成现在几十个文件和类，本意是让设计更容易理解和维护，也尽量往容易进行单元测试的方向靠拢。不过等都完成后，回想起来，这样的设计仍然觉得不是很爽。类与类之前的关系略显得混乱，有些依赖关系感觉不是很符合OO的那些基本原则，但具体怎么做能更好，我却没什么头绪，大概也是因为理论理论和实践经验的两重不足引起的吧，只能靠不断修炼，逐步提升自己的exp了。 同事抱怨说自动提示功能很少能正常工作，我觉得很惭愧，当时刚做出个样子来时，心里还是比较自豪和骄傲的，不过现在事实摆在眼前，离真正可用，好用还差得很远。幸好现在已经有了思路，用lex和yacc来做，再好好设计一下，争取让这功能真正好用起来，计划花一周的时间完成。再花两天，把编辑器View的基类提取出来，以后所有需要代码编辑功能的View，只要从这个类继承，就可以得到功能基本完善的编辑特性集合。最后，花两周时间，把外部脚本扩展的框架实现。
今天又读了一点Scintilla的源代码，因为要达到现在比较流行的AutoCompletion的下拉列表，旁边还能显示一个tooltip描述选中项，那种效果，所以要先熟悉一下代码流程。 总结一下思路，要至少增加2个消息，用于显示或隐藏描述选中项的tooltip用。增加1个回送通知，用于告诉用户有机会对选中项进行额外操作，这里也就是显示这tooltip。修改listbox的显示方式，主要有效内容要加粗，其他的不加粗。修改选中项上屏函数，用于过滤出确实要上屏的内容。 总的说来，工作量似乎并不大，但实际上我却很懒得动手，而且为了以后发展的需要，最好这部分功能能合入官方源代码中，而确实Scintilla的原作者Neil Hudgson曾经说过，自己不会去做这个功能，并且并没有说，即使别人贡献了这样的代码，他一定会合入。 今天顺便看了一会儿notepad++的源代码，有几个小功能还值得学习，不过我个人认为这代码写得并不好，至少不如Scintilla的代码，但有些设计确实不错，而且它还能支持简单的插件。但我认为它最不好的是，似乎它使用自己修改的Scintilla，这样它的通用性就不好了。
偶然看到这篇文章，Delphi for PHP已经升级到2.0了，不愧为曾经最强大的IDE生产商，把PHP的开发工具都做得这么神！ Code insight，也就是auto completion、call tips等功能的集合，想当年，第一次用Borland C++ Builder 5.0的时候，就很诧异它的auto completion，不过那个版本并不稳定，后来没多久就出了6.0，发现稳定好多，不过以现在的眼光看来，它的速度就慢了点，还看到国内有个牛人自己写了个增强插件CodeFast，速度，内容上都有很大提升，但极其不稳定，几乎处于不可用状态。当时用得多开心的，而且以VCL出色的设计，开发GUI程序，尤其对于初学者，有极大的鼓励作用。由此，我也就以为，Borland出的IDE是世界上最好的IDE，这个原因，也一定程度上让我不再愿意去费力气转向其他工具，包括VC。 后来用上了装了Visual Assist.X的VC，发现VAX的能力太过惊人，再后来就是工作中，直接使用VC作为开发工具，就已经离不开VAX了，VAX的智能提示功能实在是太好用了。 工作中，负责的也是一个IDE的编辑模块，其中的auto completion和call tips则是重头戏，前段时间计划着增强该功能，但一直没有动手。曾经考察过几种当前甚为流行的IDE的这个功能，包括VC（其实是VAX）、C++Builder/Delphi、Netbeans、Eclipse、Visual SlickEdit，当时的比较结果看来，C++ Builder/Delphi的似乎是其中最弱的，Netbeans的则看起来比较炫，太显得啰嗦，VAX的比较适中（可能也是因为看习惯了）。但有一条明显的需求是，当光标在下拉候选列表项中移动时，旁边应该可以弹出一个tooltip来详细描述当前被选中的项。但是项目中使用的Scintilla控件似乎并不直接提供此类支持，因此需要修改控件的源代码，而这是我最不愿意做的事情，我希望这个支持应该由官方来做。 而今看到这篇blog，则提供了一个可以学习的范例，同样是脚本语言开发环境，别个是当前业界最先进的，当然应该取其所长，补我所短了。
今天突然有个想法，关于前段时间的用WTL写个围棋打谱程序的念头，是否可以把棋盘、棋子绘画动作也抽象出来，棋子的位置、走法规则都提取出来，有一组严谨的约束，而且这组约束可以通过配置文件，或者脚本来描述，最后，C/C++代码则只用来完成具体的绘画操作，对这些约束完全一无所知，比如它只知道在哪个坐标画一个什么样的图形，而为什么要画这个图形，这个图形有什么其他的含义，都不是它需要知道的。 如果确实能高度抽象地完成这个描述，那么带来的灵活性则是非常有用的。对于单纯是一个围棋打谱程序来说，也许带来的好处并不明显。但再换个角度考虑，在这一套架构下，很容易通过写少量脚本或配置文件，而不需要修改一行C++代码，一个围棋打谱程序立马摇身一变，成了一个象棋打谱程序，或者五子棋打谱程序了。这样的诱惑，对目前的我来说，实在是巨大呀！ 这个想法的灵感，源于Eclipse的编辑器，《Contributing to Eclipse》中有一小段描述可以贡献一个编辑器，当时看到这段描述，甚是激动，差点想把那个IDE项目中的编辑器模块也这样做了。这次又联想到打谱程序，同样是画棋盘棋子的，只要合理设计，理应也可以达到类似的效果。 不过随便想想，以在世界范围最流行的4种棋类（围棋、中国象棋、国际象棋、五子棋）为目标，要想尽可能简单且灵活地实现，还有点困难。如何表示棋子的类型、如何表示行棋规则、如何定义精确的棋子位置以便程序绘制等等，都是摆在眼前最大的障碍。五子棋最容易表示，只有2种棋子，直接落子，虽也有像五手两打，三手交换之类的奇怪规则，但这些似乎都是在棋谱解析部分的工作。围棋则略为复杂，一个明显的问题是，要能计算出死子，并提出棋盘，这个工作如果纯粹交给外部脚本做，怕是会有心无力，但照现在的设计思想又不能让C/C++代码来做。两种象棋就更复杂了，棋子的类型就相比多了很多，每种棋子的合理行棋方式又都不一样，虽然从纯粹打谱的角度讲，比围棋、五子棋也复杂不了多少，但是在棋谱录入时，则很让我头痛了，如何表示一个棋子从一个位置移动到另一个位置，是否可以移动，移动后是否棋子的属性有变化（中国象棋中兵过河可横行，国际象棋中兵到底线可变身），移动后是否影响了其他棋子（吃掉了）等等，关键是一套界面和逻辑的交互协议，不能设计得太偏向于是为某种任务而特意为之，但又得有足够的信息在两者之间传递！
其实学的是flex，从公司网上找的，大概也是gnuwin32中的某个版本。顺便在公司网上又找了些资料来学，纯粹只是看的话，是跨不过那道坎的，所以要自己写几行来玩。生成的C代码倒是能直接用MinGW中的gcc编译，这让人觉得很舒心。开始的时候不明白，为什么写的正则表达式好像不起作用，总是把该扫描分析的文本全都打印出来了，而我明明只是想让它打印被匹配上的那些内容就行了啊，经过仔细观察，最后发现，其实是flex生成的C代码中，自动把不匹配任何自定义正则表达的内容也输出到控制台上去了。所以有两个办法可以解决此问题，一是把匹配内容输出到文件中，另一是修改下flex生成的C代码，把默认输出的那个ECHO修改了。 让它分析一个3万行的rb文件，匹配几种常见的token，如常量、变量、数字等等，速度奇快无比，可能不到1秒吧，想想我原来用Greta写的全文匹配5种模式，不知道要多久，不过幸好在不是很晚的时候发现了这个解决方案。从中已经可以看到曙光，原来我的猜想、直觉应该是正确的。flex可以解析出token，因为我需要的是其中的子模式，所以光是flex还不够，需要借助yacc（现在用bison的比较正常吧）进行语法分析。我猜即使加上了bison生成的语法分析过程，扫描那个3万行的rb文件，得到需要的结果，应该也不会超过3秒钟吧。不过另外有个问题需要注意，flex和bison生成的代码里都有一些全局变量，如果在多线程环境中使用，需要非常小心地进行同步，不过也许，自己也是可以对生成的代码略作修改的吧，尽管这些代码的可读性在我看来真的十分糟糕。
因为我是一个半路出家的coder，除了会写几行C/C++代码外，所有其他计算机科班出身的人会做的事我都不会，这也是我的一大劣势。 其实前段时间就想过，要学一下lex和yacc的用法。有这个想法，主要还在于看到不少开源项目，比如doxygen、source highlight、swig等等，全都用到了相关的东西，而正是因为我对这方面一无所知，所以即使能获取到它们的源代码，我也不知道如何自己编译。 这两天在公司里，遇到一个问题。编辑器里需要auto completion，为了尽可能实现地进行联想，于是以project方式组织时，需要扫描单独文件的上级文件内容，把符合要求的几种模式都识别出来，其实也只有5种。于是我就用了一个比较简单，可以说是笨的方法，用正则表达式去全文匹配一下，5种模式就匹配了5次，当文件内容少的时候，问题不明显，可说是没有问题。当文件有几万行时，就不行了，CPU占用率一下就99%以上了，而且匹配一次就会持续十来秒，5次就可能要1分钟去了。而且这个动作是在打开文件的时候进行，所以如果连续打开多个文件，机器就假死了。这个问题一直在存在，存在大半年了，只不过没人提出来，我也没意识到其严重性。这次跟同事讨论起来，我才觉得不改不行了，但我又想不出好的办法，缺少必要的理论支持，绞尽脑汁也是无济于事的。我的直觉告诉我，用编译原理方面的知识可以解决这个问题，所以学习编译原理也将提上议程。 编译原理一直以来是我最怕学的东西之一，记得很久以前，高中时的某个假期吧，但毫无进展，不了了之。后来大学时考高程，其中有一部分就是编译原理的内容，全靠考前死记硬背，考时胡乱蒙猜。可能其他还欠缺些理论知识的支撑，也是一部分原因吧。 因为想做好编辑器，所以对代码编辑的支持是必不可少的，因此从现在开始，订个计划，学编译原理，lex、yacc使用。
今天上午连续接了两个奇怪的电话。已经有几次了，打到什么布吉五金商行的，结果打到我们这个座机上来了，不过有趣的是，这次这个家伙没有直接挂掉，而是跟我扯起来，说什么交个朋友，有没有兴趣出来干，呵呵，感觉像是个人贩子似的。好不容易挂掉电话，马上就有另外一个人打进来，听背景声音跟前面一个是同一处，但听口音，明显是两个不同的人。这次这个也比较有趣，问我们公司现在招不招人，有什么岗位，待遇如何等等，还说是不是研发的都是高学历的，水平很高的，呵呵。又是好不容易挂上电话，手机又响了，这次是当当网送货的了。蹭蹭跑出去，发现居然是在岗亭门口的一个小角落里，而且看货有好几箱，而送货的只是一辆小自行车，真不知道他怎么把这么多书载过来的，混口饭吃也不容易啊。 打开看了看，建筑类的几本书的纸张质量还真是不敢恭维。《Head First Design Pattern》外面有一张塑料纸包着，好厚一本，拿回家翻了翻，有点后悔，价格定那么高，里面的篇幅实在没多少，很多的插图，很多的空白，浪费啊，看来我还是习惯那种适合苦读的典型的中国教科书啊。《建筑模式语言》有上下两册，精装的外壳，很厚很厚，但里面的纸张远不如《Head First DP》，《建筑的永恒之道》不是很厚，而且不是很大开本，不过奇怪的是，想不到建筑类的书居然也定价那么高。
还是没干什么事，看了一阵书，话说昨天把《设计模式解析》第二版还掉了，其实旁边的同事又马上借回来了，于是乎我就拿来看看，看得囫囵吞枣的，不过也比直接看GoF的要省力得多。其实一直以来我都很少会认真仔细地从头到尾看完一本技术类书籍，很多书甚至是只看了前言、序，或者目录就直接丢到一边了。虽是这样，就算没完整看完一本书，像那种武侠小说中描述的那样，像我这样的小虾，向大师学习时，能领悟到个一招半式也是受用无穷的了。 到今天为止，大致了解了Adapter、Facade、Bridge、Strategy、Abstract Factory这几种模式。简单地说来，Adapter是为了转换接口，Facade则是为了封装并简化接口，Bridge说是把抽象和实现解耦，在我看来，实际是把几种不同类的概念分类，避免组合爆炸，Strategy是为了封装算法，Abstract Factory则是封装一系列相关的类的实例化过程。在阅读《设计模式解析》的过程中，我还发现一个比较明显的现象，有些模式，或者说有些解决问题的方案，其实都是通过将问题细化，将较细粒度的变化进行封装来实现的。比如书中讲述Strategy模式时，一开始例举的是直接继承，在论述了该例的缺点后，才抛出新的方法，其实就是把更小更精确粒度的变化提取出来并进行封装。在讲述Bridge模式时，也有类似的倾向和做法。再回想《重构》一书中，作者Martin Fowler则是更激进的做法，如果要给一段代码添加注释，则把这段代码提取出来，用有意义的函数名来阐述代码的作用。这从另一角度促使了小粒度代码段的生成。 《设计模式解析》一书的写作风格也是让人比较舒服的。作者会花一些章节进行理论或实际例子的讲述，再用一些章节描述模式，再讲述一些通用的理论，如此穿插的作法，反正我书看得少，正是第一次看到，感觉比较容易让人接受并领悟。
我就是缺乏定力，就是忍不住去做些无聊的打发时间的事情，就是不愿意去做些有实际意义的事情。早上起来就觉得很烦躁，也不知道是哪里出问题了，仔细想想好像也没有什么重要的事情，但总是静不下心来。 白天在公司里糊里糊涂地过了一天，看了一点书，《设计模式解析》，书写得还是比较合我的口味的，不过下午的时候去图书馆，把这书还了，因为快到期了，以前没怎么看，后来觉得有用的时候，却是借期快满了。虽然只看了前半本，但也觉得略有斩获。前半本有不少内容是通用性的概念，有些概念我一看就觉得就是这么回事，不过自己却肯定总结不出这么精辟的来。
