All Stories

进展不错

  这两天整调试器,经过不怎样的努力,到现在为止,功能上基本算是具备了,不过就是剩下些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处理方式。   算了,不说了,先搞定调试器,再来看这个吧!

Windows下编译器内存分配释放性能对比(续)

  今天搞到了C++Builder2010,里面的bcc是6.21版本,相比bcc5.5,也是经过4个版本升级了,隐约记得在某个版本中,把CRT中的内存管理部分改用FastMM了,所以它的表现应该有所不同。   经过与前一次基本相同的测试,得到结果。从该数据中可以看到,6.21版本提升了多线程情况下的小块内存操作的性能,在1024字节以下的malloc测试中,表现优于所有其他的编译器!但在1M字节以上的测试中,还不如bcc5.5版本。而且,它的new操作耗时比malloc操作耗时多很多,大约是半倍到一倍的样子。在单线程小块内存的操作中,表现可以用技惊四座来形容,直逼OpenWatcom,甚至偶尔略有超越。但是在大块内存操作中,反而都不如原来BCC5.5。   详细测试用可执行程序与测试结果可以点击这里下载。

Windows下编译器内存分配释放性能对比

  前些天有人在群里说起测试malloc和HeapAlloc的效率,后来又在豆瓣上有人讨论起大块内存的策略问题,于是我决心再稍微仔细地测试一下各个编译器在这方面的表现。   首先,我选取了OpenWatcom 1.8、Digital Mars 8.51、Borland 5.5、MinGW GCC 4.4.0、MSVC 2008、Intel 11.0.061一共6种编译器,除了Intel C++,其他的编译器都可以在网上下载并免费使用。   然后写了一个非常简单的小程序,分别对1字节,1000字节,1024字节,1M字节,10M字节和50M字节进行重复的分配和释放,前三种大小重复15000000次,后三种大小重复150000次。为什么前三种的重复次数是后三种的100倍呢?因为测试过程中我发现,后三种的耗时在某些编译器中太长了,等不及了!   接着,使用所有这些编译器编译出4种不同CRT配置的可执行程序。分别是单线程静态链接,单线程动态链接,多线程静态链接和多线程动态链接。我都是使用bjam的默认参数编译的,其中Intel编译器不能生成单线程静态链接的可执行程序,但我想影响很小,也就不再追究。   最后就是运行每个程序,我的机器配置是Thinkpad T43,1.86GHz的P4m,1.5G内存,Windows XP SP3。每种跑10次,计平均时间,可以得到一些有趣的结果。从不同的维度观察这些数据,可以得到不同的结论。   先比较不同编译器间的差别。从实际上看,MinGW和Intel都是使用了msvcrt,只不过默认情况下MinGW使用的是6.0版本,Intel则使用当前安装的VC的最高版本的CRT库,我的机器上是9.0,所以总的说来这三者的差别应该不大。   在1字节的大小时,Digital Mars表现平稳而出色都在2s出头,而VC、MinGW和Intel都超过3s,OpenWatcom跟VC类似,但在单线程静态链接时就爆发了,只需要1s出头,而Borland在单线程中都只用1s多。   1000字节的测试基本与1字节的情况相同,但Digital Mars的耗时却飚升了近1倍!   而1024字节时,VC、MinGW和Intel的耗时又比1000字节时多了近1倍,看来这1000和1024之间有个阀值影响msvcrt使用不同的分配策略。   在1M、10M和50M字节的测试中,三个测试的数据差别不大,但与前三者的测试数据比较可以看出,OpenWatcom和DigitalMars的表现平稳,变化不大,但使用msvcrt的三者则耗时飚升,大约是前二者的400~500倍,是1024字节的200~250倍,这个差别比较大!   总的说来,Borland C++只有在单线程,小块内存分配时的表现还不错,这在DOS时代是好的,但进入了Windows时代,程序开发纷纷往多线程,大内存占用的方向发展时,它几乎没有进步。Open Watcom是受分配内存块大小影响最小的,几乎没有变化,而且总体上它在各个横向比较中性能是最好的。Digital Mars略次于Open Watcom,但它在单线程或多线程,静态或动态链接中几乎没有差别,估计最终使用的是同一个CRT库。VC、MinGW和Intel的表现基本相同,除了单线程静态链接小块内存分配外,其他情况都略好于Borland C++,所以可以看到Intel编译器的优化是集中在指令流的调整上,而对内存这块是忽略了。...

不错的励志歌曲——Trouble Is A Friend

  澳洲甜美歌声,我听了Lenka的12首歌,最后的结论是,只要听这一首就够了!歌词如下: trouble will find you no matter where you go oh oh 麻烦会找到你 不管你往哪里走 哦哦…… no matter if you're fast no matter if you're slow oh oh 不管你是赶路 不管你想停留 哦哦……...

买了个豆浆机

  因为前些天小师妹在网上跟我说,喝豆浆养肠胃。嗯,我肠胃不好已经很久了,我爸妈的肠胃也不好,所以我觉得买个豆浆机很有必要。   今天去4S店拿行驶证和发票什么的,昨晚聊天太晚了,今天老是走神,真危险呀。看来开车是个很耗体能和精力的事情,以后在前夜一定要保证精、气、神的良好状态!   吃过中饭去一百,先看到美的,看了一会儿,抬头看到九阳的柜台,于是直奔过去,买了个很便宜的,不能打冷饮的,呃,反正现在只是想喝豆浆而已!