All Stories
今天遇到了骗子，只差一点点，有惊无险，记之以作警示。
全程经过是这样的。今天刚好去市区，到了目的地，就接到一个电话，号码是13201792864（疑点一），接听后是一个说普通话的女人，自称车管所的，我大惊，以为哪次闯红灯被逮到了？结果是问我是否xx（我妈的名字，因为后面提到的买车时登记的车主是她），是否在两个多月前买了车。都确认后，她就问我，难道没有接收到车管所发去的通知，根据xxx号文件的指示，小车购置税可以退3%（疑点二）。我说没收到啊，她就问，不是浙江省xx市xx地方吗（确实跟登记的地址一模一样，我已经开始相信是真的），我很抱歉地告诉她，我们搬家了，不住在那里了。她就说，这个通知被退回来了，现在把这部分钱转移到国税局去处理了，你赶紧联系一下国税局，今天是最后一天了，然后告诉我一个电话号码，是4006811987，还有个6位数的退税编码。我看到是400，觉得好像是正规的哈（完全相信），于是打过去，又是一个说普通话的女人（后来回忆了下，似乎跟前面的那个人的声音一样？），我说了一下事情，她就说，把退税编码报过来，我就说了，然后她就说，是不是名叫xx，xx车啊，我说是的，她就问我车身价多少（疑点三），我说10w零多少吧，我不在家，没有发票，说不出具体数字。她也没追究，直接说你可以退三千几百几十几元（后面的我忘了），我很开心啊，这钱相当于白来的嘛，就问她要走什么手续，她说中行建行农行邮政的都可以。我问了一下我身旁的我阿姨，她有个农行的卡（我还真没有这些银行的卡），那女人说，你找到就近的自动柜员机，我们会指导你进行相关操作，把钱转给你（疑点四），我问一定只能转账吗，她说是的（疑点五），此时的我正沉浸在天上掉馅饼的巨大喜悦之中，就硬是让我阿姨放下生意，带我去找农行。找到农行的柜员机后，我让阿姨跟那个女人通话，因为银行卡是她的嘛，要她输密码什么的总不好我来。结果就出很大的漏子了，阿姨跟那女人说上话后，插卡，然后就报了下自己的卡里的余额，我就迷惑了，是你要给我钱，我告诉你这个干吗。这时我阿姨也反应过来了，问我该不会是骗子吧，我心有点慌，支吾了。阿姨就问她，你是哪里的。她说，国税局的。阿姨说，国税局就在这里xx路上啊，我们直接去办理行不行。那女人说，不是你们那里的国税局，是绍兴的。阿姨就说，你绍兴的，就说绍兴话好了，那种话我听不懂，然后那边就没声音了，也没挂断……这时基本可以确认是骗子了，我又打了个电话到买车的4S店里问了一下，店里人马上就说，这是骗人的，我们这里已经有人被骗2w多块了。我说那他们怎么会有我这些资料的，店里的人说，可能是从车管所买来的吧。我郁闷，我现在还在猜是你们店里卖出去的呢！我草，我说你们也有责任通知一下你们每个客户，提醒一下他们注意啊，我今天就差点栽了！
马后炮分析：其实事后回忆整个过程疑点非常多，但我一直被他们说出的完全正确的个人信息和购车资料给迷惑了。后来我又反查了一下最开始那个手机号码，所在地竟然是陕西西安！郁闷，如果当时我的手机上的来电通是正常工作的，我估计不会跟着她这么去折腾吧！现在想起来还是有点心有余悸，羞愧难当啊！
打击诈骗，人人有责！
今天主要搞定了源代码断点，之前遇到的如果有断点，debuggee启动就会崩溃的问题，其实是通过socket发送命令过去后，debuggee在接收时会把不完整的信息压入到队列中，跟昨天遇到的回应消息不完整是一个道理。
最后我仍然是采用了完全使用debug库的功能实现的方式，这种方式的缺点是调试执行的效率很低，因为每次debug库回调时，都要判断一下是否在当前行有断点。至于之前我想过的那种快速断点的方案，就留到以后版本中实现吧！
今天可算是最近两个月来状态最好一天了，修正了一堆问题，以至于调试器工作得像样起来了，剩下只要完成源代码断点的功能，就接近可发布的状态了！
这里简单记一下这些已解决的问题。
一开始，是有各种奇怪的问题的，比如在Lua扩展中解析XML格式的回应信息时，会报invalid node，有时候又会报call stack节点不存在，有时候在VS的调试器中运行时，会在分配内存的时候异常。这些问题，最终的原因可能是相同的。我的设计是另有一个工作线程通过socket在与debuggee进程通信，它会接收debuggee进程发回来的回应消息，并把这些回应消息压入一个队列中。而界面线程，会在应用程序消息空闲时，从该队列中撮回应消息，并转发给Lua扩展进行处理。这时我犯了一个错误，我会把一个可能不完整的消息结构体压入队列中，而界面线程取出处理时，并不能检测出是否内容完整。而且，我还是通过动态堆分配来存储这些额外信息，在界面线程中又会去释放这块内存，于是工作线程很可能去读写一块已经无效的内存。
另一个问题是，debuggee有时候会启动即崩溃，通过打印的调试信息显示，是boost::shared_ptr的使用有问题。我仔细检查了代码，发现只有两个boost::shared_ptr，还发现，其中有一个是不必要的，那是一个放在线程函数中的临时对象，生命周期只在该线程函数中有效，所以换成栈上创建就可以了。这样一来，后来经过几次测试，也确实没再出现崩溃。
还有问题是，只能调试一次，再启动debuggee就自动退出了，还有调试的时候用户手动停止调试，debugger会崩溃。其实这是没有仔细划分好各模块的职责，没有仔细设计各模块交互的协议。后来总结发现，如果debuggee要退出，分两种情况，即自动运行完退出和手动强制退出，无论哪种退出，都给Lua扩展发送一个通知，然后Lua扩展把调试端口（socket通信）停掉，而这个通知如果debuggee有能力发（手动强制退出），就让debuggee发，如果没能力（自动运行完），就让debugger发。而手动强制退出，则是只要向debuggee发送个退出命令就可以了。
今天心情真舒畅啊！
这两天整调试器，经过不怎样的努力，到现在为止，功能上基本算是具备了，不过就是剩下些bug，主要有：
从debuggee发送过来的信息有时候经过XML解析会出错。
从debuggee发送过来的信息，有时候没有调用栈信息。
断点工作不正常。
有时候刚启动debuggee，debuggee就崩溃。
明后天就集中精力修改这些问题了，哈哈！
前次说到，我觉得我把wxScintilla的代码合得有问题了，我的程序中使用了wxScintilla不能多选。其实是我毛躁了，没认真看Scintilla的文档。其实当时我也是浏览了一遍代码的，发现在wxScintilla中处理用户输入后，就直接转发到Scintilla的平台无关的代码中去了，而这部分平台无关代码我基本是严格复制了官方Scintilla的代码，所以照理是应该没问题的。昨天在整理《Free Software Collection》一文时，考虑到用什么软件来替代UltraEdit，结果发现SciTE的列编辑模式已经可以做得跟UltraEdit很接近了，看了看修改版的SciTE-Ru，也同样如此。当时我还有点怀疑是不是需要在容器应用程序中做单独的处理，想想又有点不太可能。看了一下SciTE-Ru的配置文件，发现是有这么个选项的，后来就去看Scintilla的文档了，看到在Multiple Selection & Virtual Space一节里，确实有相应的设置选项。
土了啊，代码合得没问题，哈哈！
我是突然发现，原来我患的是这个病：成功恐惧症！在《反模式》中看到，原来我这样的病症并不唯一，很多人都会有，以至于他们都把它写到书中去了！
说到底，还是出于不够自信，以及毅力缺乏。古时候有句话，叫“行百里者半九十”，其中有一层含义就是最后那10%的工作是最难完成的，不光是因为可能工作内容的难度增加，还有执行者心理上的障碍，就像我这样。
一直以来，我都是一个缺乏毅力的人，很少会从头到尾认认真真地完成一件事情。不论是工作，还是其他生活中的琐碎的小事，比如看书，总是会把最后一部分丢掉。以前有领导说我，做事情总是喜欢只做到90分，而不去追求那完美的100，我不以为然，我是有点小骄傲的，有点自以为是的，这种关键部分有技术难度的部分完成了么，剩下的修修补补让别人去做好了！
现在不行了，所有的事情都得亲历亲为了，这个毛病带来的隐患就爆发了，将将引起严重后果了。记得类似的严重情况在公司时有过一次，那是我第一次独立负责一个特性，不但要完成自己的功能，还得提供接口给其他人使用，到了最后那段时间，心里非常焦虑，极度没信心，到后来都是只敢埋头写代码，不敢调试运行，生怕调试不过，把自己打击得再无法拾起从头来过的勇气了。最后运气很不错，因为本来也只是简单地调用别人的接口，我自己的特性完成后，提供给别人的接口基本功能也是能保障的。
眼下我那个调试器部分，已经持续2个月了吧，一直没有正常的进展，实在是挑战我的心理承受能力。我只能强行扭转自己的心理喜好习惯，自我灌输些心理暗示，希望能顺利度过这一关吧！
我有经常看一下Google Analytic的习惯，差不多每天上网的话都会去瞧一下。发现有好些访问，从从搜索引擎（Google）那里通过关键字“星座”、“双鱼座”等等过来的，今天还发现有个“双鱼座今年会和喜欢的人在一起吗 ”，让我觉得比较好笑。
我是个有点迷信星座的人，但只迷信它的大概的说法，对于每日/每月/每年的运程，我就不太信了。已经不记得在什么时候了，看过一段有点“伪”科学的解释，星座按出生月份划分，正好当时母亲在怀胎十月以及分娩时分受天气变化的影响，由此可能影响了胎儿的大脑等，就会影响到人的性格，而性格决定命运，所以我觉得似乎是有些道理的。
跟小师妹聊天时，偶尔会提及到我的缺点短处，我常会说“双鱼座就这样的啊”，小师妹就说我太宿命化了。以前确实没想到这层面上去，但被小师妹这么一说，我虽然表面上还说什么扬长避短之类的来狡辩一下，实际上心里有点惊悚的。照理说，我一直以为自己是一个不甘于受命运摆布的人，怎么这事上，就这么懦弱了呢？我一直认为人的出身已经注定，但通过后天努力是可以在一定程度上修改自己的命运的，可是现在想想，对于那些已有的缺点，我或无视之或逃避之，对于它们可能造成的不良影响完全无动于衷，这不是掩耳盗铃儿响叮当嘛！是该好好反省下了。
话说，昨晚居然梦见跟小妞一起看一本围棋书，醒来后真是心有余悸而力不足，不过好像在周公解梦中，男人梦见读书好像是好事呢！
用了wxScintilla，我一直试图让其中用到的Scintilla代码保持跟官方CVS中的同步。现在发现，还是合得有问题了，功能没合进来，但是光是看代码，我也不知道到底哪里出错了。具体的现象是，现在官方的Scintilla是已经能直接支持多块选择了，昨天试了试我的程序是不行的。不过这个问题暂时倒不要紧，可以放到以后去修改。
看到SciTE开始有实验性的支持使用Lua脚本实现lexer了，不过接口还没有稳定下来。不过我猜这个特性可能不会合到Scintilla里面去，而且即使合进去了，我暂时也没有这个需求。
自从前些天看到TextMate的Bundles的介绍，以及Zen Coding的介绍，心里一直蠢蠢欲动！VS在有VA强大的智能提示的帮助下，或许可以不用这种方式的支持。但对于已经习惯于UNIX使用文化的人来说，这种自动代码生成方式是很符合他们的使用习惯的，而且同时又能极大地提升编码效率。我就开始琢磨着能不能也实现一下。
Zen Coding的效果看来，主要适用于HTML这种从SGML衍生而来的标识语言，这主要是它的语法，以及它的生成代码上的限制，所以如果不是这方面的应用，可以暂时不管它。
而TextMate的Bundles看起来就很让人心动了，以前只是听说过却没有直观地体验过，所以感触不深，前些天看了一些评论和操作视频以及manual，冲击太大了。当然这种机制在Windows平台上命令行工具并不流行，脚本解释器又不默认安装的环境下，可能不如Linux/Unix/Mac上那么突出，但如果能做成对少数几种工具、脚本语言的支持，也是很有诱惑力的。
大概想了下，如果要实现这套机制，要修改一下Scintilla中对Tab和Back Tab的实现。目前Scintilla中的Tab有两种不同的行为，如果选中整行或多行了，则会对选中行进行缩进，其他情况则是插入空格或制表符。在Bundles中或者说Tab Triggers中，Tab又多了两种行为，一个是缩写扩展，如果同时有多个扩展使用相同的缩写，则要显示AutoCompletion下拉框，另一个是缩写扩展后光标自动跳转。所以我的想法是，要在Scintilla原来的两种行为中增加缩写扩展的行为，并在内部保存一个状态，表示缩写扩展后，所有的Tab操作不再进行默认的缩进或插入空格（制表符），而是在这些时候都给个通知，让宿主程序自己处理这个操作。而宿主程序在适合的时候再发个消息给Scintilla重置那个状态，以便Scintilla又退回原来的Tab处理方式。
算了，不说了，先搞定调试器，再来看这个吧！
今天搞到了C++Builder2010，里面的bcc是6.21版本，相比bcc5.5，也是经过4个版本升级了，隐约记得在某个版本中，把CRT中的内存管理部分改用FastMM了，所以它的表现应该有所不同。
经过与前一次基本相同的测试，得到结果。从该数据中可以看到，6.21版本提升了多线程情况下的小块内存操作的性能，在1024字节以下的malloc测试中，表现优于所有其他的编译器！但在1M字节以上的测试中，还不如bcc5.5版本。而且，它的new操作耗时比malloc操作耗时多很多，大约是半倍到一倍的样子。在单线程小块内存的操作中，表现可以用技惊四座来形容，直逼OpenWatcom，甚至偶尔略有超越。但是在大块内存操作中，反而都不如原来BCC5.5。
详细测试用可执行程序与测试结果可以点击这里下载。
