All Stories

T43与N73蓝牙连接

T43与N73蓝牙连接

  下午正在睡觉,小妞打电话来把我吵醒了。打完电话,穷极无聊,想想怎么弄一下我的T43让它可以和我的N73通过蓝牙连接。一直都知道T43可以用蓝牙,但一直没用成功过。上网找了一下相关的资料,原来只要Fn+F5打开蓝牙功能就可以了。这样用N73就能搜索到了,但在连接的时候提示需要什么通讯码,就像识别标识一样。还以为是固定的,所以上网搜索了一下,没什么实际有用的信息。后来偶然发现,在T43上搜索蓝牙设备,可以找到N73,这里设一下PIN码,然后在N73里连接时要求通讯码输入那个自己设的PIN码就可以了,呵呵。这样就基本解决了T43与N73蓝牙通信的问题。不过试了一下,连接很不稳定,经常马上就断了,而且传输速率只有8Kbps左右。

关于程序运行效率后续

关于程序运行效率后续

  话说同事那任务把他整得精疲力竭,昨天加班又是继续攻关这个遗留问题。老大的看法是RichEdit在显示的时候占用太多时间是主要原因,于是同事把RichEdit换成用Scintilla控件来进行显示,结果效率并不比RichEdit好,估计因为Scintilla是一个通用的文本编辑器,为了进行着色、词法分析等任务,在这种特殊场合下,并不是最优的方案。还是换回RichEdit,只好从提高字符串操作效率着手。把其中一部分操作原本使用CString的,全部改换成用C运行时库重写了一遍,尽量减少字符串复制操作,用原始的指针,同时也避免了原本非常频繁的CString对象的创建和销毁,再加上一点点从CPU优化的角度的编码技巧。最后发现似乎效果还是挺明显的,不过RichEdit内的数据如果一多,显示速度也会降下来,这个问题照我的看法,如果坚持要使用RichEdit的话,只能开个定时器,每一个固定的时间周期,把RichEdit中的数据减少一点,保证RichEdit中最多只存储一定数量,该数量应该还不至于明显影响显示速度的内容,否则就完全摒弃使用RichEdit,采用自己画的方案,因为每次只是画出显示的那一部分内容,速度应该很快,而难点是,要把所有内容缓冲到文件中,如何能在文件不断增长的情况下,快速准确地定位到需要进行显示的那部分内容。  这个事件,让我对现成库的效率都产生了怀疑的心理,MFC库的慢是为众人诟病的,但不知我更习惯使用的STL效率如果,它的string类,它的各种算法不知道应用到这种场合会是什么样的效果。必要的时候还是得靠自己手动解决,看了《软件优化技术》中的一点内容,编译器优化会帮我们做不少事情,但很多时候还得程序员帮助编译器创建更优化的条件和机会。

今天去加班了

今天去加班了

  今天去加班了,难得哦,突然一下子变得很忙,这星期连续三天晚上加班,对我来说几乎是难以想像的啊。加班回来就先给妈妈打电话,然后给阿姨发短信。  给小丫头打电话,没人接,于是放下,看网页。过了一会儿小丫头发短信来说,9点以后她就接听免费了。于是安安份份地等到9点,再给小丫头打。这次小丫头似乎心情不错呢,还好像比以前会搞笑了,真是有点意外,倒是换过来我唉声叹气了好几次。记得刚来公司的那一年,经常心情不好的时候就会给小丫头打电话,那时她还在学校里,而且几乎每次她都是很固定的活动,也是我们学校的人最平常的活动,上BBS、看碟、打游戏,以前我在学校的时候也是这么过的,所以总是给我一种很怀念的感觉。以前每次跟小丫头打电话都会把糟糕的心情变好,真的很奇怪,现在却好像不行了,可能是跟我的心态有关系吧,现在的心态跟以前不一样了。  所以,人千万不能随便动感情啊,不然像陷入了泥潭,难以自拔啊!

关于程序运行效率

关于程序运行效率

  同事为了能快速地打印输出格式化的字符串,已经被弄得精疲力竭了,呵呵。这些字符串来源于Ruby解释器的输出,包括各种复杂的信息,所以需要在显示前进行相关的处理,比如提取出放在行首的颜色信息,把字符串断行等等。目前的问题是,输出显示很慢,要么就是闪烁,要么就是脚本执行已经被中断了,它还在那里慢吞吞地输出,其实确实字符串已经送到了,但进行字符串处理的过程太慢,导致脚本执行中断时,还堆积了很多没处理的字符串。  看一下我们这个项目的代码,一般都是只求功能的实现,几乎从来不关心代码运行效率的问题。我一直也是这样的毛病,以前也没怎么想过特意去怎么优化。现在这个事情突然让我对这方面很是关注。  一般说来,以这个例子来说,要解决,首先就是要使用更高效的算法,看到同事写的那一段代码,确实是很低效的,大量的字符串重复拷贝、对象创建和销毁、字符串匹配等等都是很耗费时间的操作,又不注意稍微节省点用,照老大的说法,一个CString被复制了几次,用个引用效率也能高一些啊!然后可以考虑从CPU层面的优化,当然当前都是调试版本处理,也许效果还不是很明显。  我想了一下,如果是我来做那部分东西,我会怎么办。首先,我可能会把所有的CString都用C++标准库里的string/wstring来代替。其次,我应该尽量会避免每次收到一个字符串时就new一个结构体,里面还有个CString成员,这样的分配内存和创建对象操作在这种场合都太费时间了。然后是,开一个合适大小的内存池,这样一边可以追加,一边可以取出处理。再就是尽量提高匹配的效率,选择一些比较高效的算法以及好好改写程序逻辑和代码结构。最后是,RichEdit似乎也有一部分问题,可以考虑自己画,把所有接收到的内容先写入一个文件,或某块内存,每次自己处理滚动条消息,然后计算比例,画出相应的部分内容,如果用双缓冲画几行字,即使用GDI应该也还可以吧。不过这样纯粹是我的空想,基本没有实践支持,所以具体效果如何,以及复杂度如何,我也不得而知。

被吞噬ing

被吞噬ing

  随便翻了下阿菲和小思宇的blog看看,想起自己的blog,都已经被工作和程序吞噬了,几乎没有生活了。不知道这是好事还是坏事。  打到我那里的问题堆积得高居榜首,结果被人说了,说这周晚上应该要加点班,于是今晚就很听话地在那里加班,改问题、写文档。难得又加班一回,就给小丫头发邮件,结果好像还被鄙视了,呼呼。  又多了个任务,不过估计那个任务不会花多少时间的,呵呵。  很矛盾啊,又想赚钱又想玩啊!

问题数又长了

问题数又长了

  今天搞了一天,也没把配置的内容整好,不熟悉是一方面,另一方面是内容太多,很多是体力活。未解决的问题数于是又增长上去了。  快下班的时候,老大又把我叫去跟另一个老大讨论那个需求去了,结果还是要在本地加个小程序,呼呼,这个自由度大了好多,而且可以做得再花哨一点,可以像Google桌面搜索一样,加个Band在右下角,用IE来做界面。还说要有可扩展性,这样如果设计得好,还可以做成一个远程控制客户端,既然都这样了,就像一个木马了,亦或是可以即时通讯,哈哈,这个真是太危险了。不过老大还是有点舍不得SharePoint啊,本来SharePoint对于现在这个项目来说,有一项非常强的优势,是内容管理,还可以全文搜索,如果不需要全文搜索,随便一个C/S的东西就行了,要是需要对.doc、.xls、.ppt等文件进行管理,SharePoint是很强悍的。  昨天上网搜了一些中文分词的资料下来,突然觉得要是通过很好的中文分词,或许拼音输入法就能做得比较好用呢,说不定能提高整句输入的精确度呢。

过去这两年

过去这两年

  今天在网上闲逛看别人的blog,在csdn上看到一个blog,博主写了篇《过去这两年》的文字,博主82年人,应该是和我同届的,文中他画了张图,总结了自己的工作学习的情况。  再回头看看我的情况。我2005年7月1日直接从重庆学校飞到这边,算是7月4日入职的,到现在也十足两年了。两年中,做SDH设备的软件测试不计节假日共约21个月(2005年7月中~2007年3月底)。当时得知自己去做测试,心中也不免诸多怨忿和失望,完全全新的领域,加上并不感兴趣,而且劳动态度不端正,以及自身先天(?)的素质影响下,成绩如何可想而知。不过到后来便有点麻木了,觉得干什么都一样,而且男人选择自己感兴趣的行业作为职业似乎是种很不成熟的表现,呵呵。  两年来,几乎什么都没学到,什么荣誉都没得到,什么好处都没捞到。真是失败啊,对比那位博主,只能感叹人与人之间的差异很多时候是没法填补的。  只能说,在以后的日子里,在自己力所能及的范围内,尽量努力,不为什么,只为能赚更多的钱,这是最直接最首要的目的。

输入法变大好多

输入法变大好多

  昨天今天翻看五笔爱好者论坛几年前讨论大熊猫输入法的老帖子,发现一些有趣的想法,比如词库用数据库来实现。  今天就动手把SQLite3.4版的代码下下来,并加入输入法的工程一起编译,看起来好像编译是没问题,不知道实际用的时候怎么样。  另外想到的是,要让输入法能直接使用sogou拼音输入法的皮肤,也就是ssf格式的文件,其实也是zip文件,只是后缀名改了,于是要加入unzip的代码,而既然加了zip格式的解压功能,索性把rar格式的解压也加进去算了。这两块的代码因为直接就测试使用了,还真出现了一些问题。首先是unrar的代码都是.hpp和.cpp后缀的,而整个输入法的工程原来一直只用C,所以要用extern "C"来修饰一下。然后发现unrar的文件包含关系还真是奇怪,它会直接include那些cpp文件,但如果直接把那些cpp文件加到工程里来编译是会出错的,这从它的makefile中也可以看出来,并不直接编译其中几个cpp文件,但也不能把它们直接删掉,真是奇怪啊!再后来的问题是,因为我想反正输入法最后生成的就是一个动态链接库嘛,让它多导出几个函数可以让辅助工具使用,所以加入RARDLL预定义宏,指示把rar代码编译成DLL,再把几个函数名写到def中去,这样就可以导出这些函数了。但还会有问题,再加个预定义宏SILENT,就能正常运行通过了。之后出问题的是unzip的代码,首先unzip的代码并不能自动覆盖已有的同名文件,所以只好在调用前先把目标文件夹内的文件都删掉。后来看起来好像运行得还算正常,但突然发现,release模式下,不能直接激活输入法,在激活时会调用unzip来解压文件,这时就直接崩溃了。但如果是先用rar或7z格式的皮肤,就不会崩溃,再切换到zip格式的文件,用unzip也不会崩溃,比较怪异。最怪异的是,这只有在release模式下直接运行会出错,如果是通过VC下的调试器,或OllyDbg这样的调试器里运行,就算是release也不会出错。这就导致问题很难定位了,本来就没有多少调试方面的措施在输入法里,而这又是第三方库的代码。想到debug模式的是没这问题的,于是又想到编译链接选项里动脑筋,经过少量的试验,最后发现,只要加上了缓冲区检查编译选项,release模式的也不会崩溃了。唉,VC的这些选项还真是大有学问啊!  今天一下加入了3个开源库,于是趁机把版权声明也整理了一下,呵呵,一个小小的输入法还用到了不少东西呢,现在就有7z、unzip、unrar、lua,还有从网上找来的一小段一小段的代码,以后辅助工具里估计还会加入Boost的东西。最后用debug模式生成的ime文件有1.9MB,用release模式生成的有1.04MB,用upx的--best选项压缩一下,最小也有近500KB,一个五笔输入法做到这种程度不容易啊,哈哈。而且还不是最终成品,成品应该还会再大点点。

忙得昏天黑地

忙得昏天黑地

  自从老大一声令下要仔细认真测试,短短两三天时间内,挂到我下面的问题就有近70个,这两天奋力迎战,到今天下班前,还剩下30多个未解决的,其实是暂时不容易解决的。  昨天下午,疯丫头还发邮件问我去不去拿MP3,结果这邮件我都是到下班的时候才看到。大概今天她自己都觉得我可怜了,自己送过来了,哈哈。