Coding my life

Go – 把gvim打造成go的IDE

Allen Dang — Sat, 19 Mar 2011 22:30:43 +0800

为了在windows下面写go的时候舒服点，我对gvim做了一些改造，主要是写了个ctags的生成小工具，然后改了改taglist的代码，让它可以支持显示go文件的结构。先看看截图。然后还写了个小脚本把F5绑定到编译当前文件并在quickfix里面显示错误信息，F6执行并反馈结果，<leader>f调用gofmt格式化当前代码。这里放出几个关键的文件，用gvim的同好们也许用得着。 gomake.vim 放到vimfiles的plugin目录 taglist.vim 放到vimfiles的plugin目录 gotags.zip 解压出来的gotags.exe放到vimfiles的plugin目录 go.vim 放到vimfiles的ftplugin目录

Go – 使用cgo包装windows api。

Allen Dang — Sat, 19 Mar 2011 22:11:43 +0800

自从无法忍受C#的性能之后，我就从没停止过寻找好的桌面程序解决方案。在windows平台上找到一个设计符合我的美学的全编译语言并不容易，选择貌似很多，但其实只有C++。我曾经用“这是唯一的选择”这个理由强迫自己去学习它，使用它，一度咬牙开始啃MFC，一度开始用它写一些手边的小工具。但对语言的感觉如同性格一样，不是咬牙就能改变的。我内心真的很不喜欢C++过度复杂的设计，和那怎么用都不舒服的字符串。我想要的很简单，全编译，语法简洁，符合我的审美。好吧，又开始漫长的寻觅。不经意间，Google的Go语言进入我的视线。上一次听到这个家伙是一年半以前它的生日。自那以后似乎甚少听到它的新闻。一时兴起，拿起来耍了几天。语法很好，简洁明了。全编译，且编译速度很快。天然支持unicode和测试，有GC，有包管理。行了，我要的全了。玩了一个月，越发的喜爱了。一门全编译的语言竟然写起来感觉像脚本语言，真不可思议。唯一的问题是它基本每个星期都在变化，代码可能存在经常要重写的风险。但我已经不在乎了。余下的事情就是用它开始写桌面应用了。于是乎我找了下，发现已经有人写了个桌面库叫“walk（windows application library framework）”，下来看了几天，发现还非常不成熟，且封装的风格不是我喜欢的那种。于是我萌生了自己封装一套的念想，是啊，疯狂的念想对吧？一步一步来吧，首先，要搞清楚如何用Go调用C/C++的代码。研究了一段时间，发现了三种方法，syscall，cgo，swig。 syscall这个包提供了很多Syscall方法，可以用来调用Dll里面的方法。walk的作者就是这样封装了常用的windows api。但我总觉得这有点隔靴搔痒的意思，且需要重新定义一遍用到的结构，甚麻烦。 swig则是一个可以沟通多种语言与c/c++的神奇东西，最新版本已经可以支持go了。我尝试了一下，确实生成了接口文件，但我在windows下面从来没有真正编译成功过。而且接口很像syscall。 cgo则是随go提供的一个工具，专门用来沟通c/c++的。恩，看起来这就是我需要的东西。于是抓来文档看了看，动手用GetCurrentDirectory来开刀，下面就是cgo的代码，文件叫做w32api.go。 package cgotest /* #include <windows.h> */ import "C" import "syscall" func GetCurrentDirectory() string { var buflen C.DWORD = 0 buflen = C.GetCurrentDirectoryW(0, nil) buf := make([]C.WCHAR, buflen) [...]

小工具 – 兼容C++ 0x标准的正则表达式测试器

Allen Dang — Sat, 20 Nov 2010 11:31:44 +0800

这几天开始学习C++，在更新我的一个小工具天涯帖子抓取器的时候正好需要用到0x标准库里面的正则库，看了下，语法细节上似乎与C#不同。导致以前常用的正则测试器不能很好的使用了，索性正在学习MFC，顺手写了个测试器，顺便感受下MFC。界面很简单，正则的一系列选项也没有加上去，就是很简单的测试一些匹配结果。界面如下点击下载

记录一个由ServiceController的缺陷引发的bug。

Allen Dang — Tue, 12 Oct 2010 16:34:23 +0800

今天帮同事fix了一个由ServiceController的缺陷引发的bug。现象很简单，调用ServiceController.Start启动服务之后，调用ServiceController.WaitForStatus等待服务的状态变成Running。代码如下 ServiceController m_SC = new ServiceController(“service name”); m_SC.Start(); m_SC.WaitForStatus(ServiceControllerStatus.Running); 代码很简单，我相信很多人都会这么写。但问题也很明显，当服务线程在启动过程中意外退出了，那么此时ServiceController.WaitForStatus这个方法并不会退出，这样就造成了程序一直在等待。有的朋友可能会说，这个解决起来很容易，直接调用ServiceController.WaitForStatus的另外一个带有timeout的重载就好了。这确实是一个解决方案，但在这里不适用。因为该服务的启动时间不可预测，如果使用timeout就会造成服务启动失败。没看代码之前，我原本的想法是在启动服务之后不断检测它的状态，一旦变成Stopped就抛异常终止。可是一跟才发现，服务的状态从启动之后到启动完成之前竟然一直都是Stopped状态（我认为这里设计的不好，启动完成之前应该还有个中间状态叫做Starting）。好吧，换个方法。那就检测与该服务相关的进程是否还存在吧。下面的代码完成了这个功能。 ServiceController m_SC = new ServiceController(“service name”); m_SC.Start(); while (true) { // 如果服务启动成功，则退出。 if (m_SC.Status == ServiceControllerStatus.Running) break; try { //获取服务内部的所有进程ID. [...]

记录一个Control.Invoke引起的bug

Allen Dang — Sat, 25 Sep 2010 20:36:25 +0800

在时隔差不多一年之后，我终于又重新开始更新这个Blog了。罪孽啊，自己鄙视一个。 Blog还是要坚持写的，这次我又下了决心。技术的心得和一些体会可能不是经常都有的，但是一旦有了就需要记下来，我希望我能坚持下去。好了，闲话少说，先说一下今天的问题。同事说，这个问题他前前后后解决了很多次，最后一次他认为已经搞定了，也确实很久没再次发作，但今天竟然又出现了，他想了很久无解。遂发出来给大家看看，帮忙看看有没有答案。这段代码要解决的问题很简单，就是在主窗口关闭时，显示一个进度窗口以提醒用户关闭的进度。至于为什么要这样一个进度窗口不在本文讨论的范畴。同事使用的是一个很直观的解决方案，在主窗口的FormClosing事件里面打开一个新的线程，在新线程里创建一个ProgressForm，然后在主线程更新上面的进度条。 public class ProgressFormStandalone { private ProgressForm m_ProgressForm; private Thread m_Thread; private bool m_FormLoaded = false; private void ShowProgressForm() { m_ProgressForm = new ProgressForm(); [...]

MiniTwitter

Allen Dang — Sat, 12 Dec 2009 13:36:56 +0800

我喜欢用Twitter记录自己的一些想法，所以一个小巧的Twitter发送程序就成了我手边必须东西。目前的Twitter客户端大多功能太多，且发送消息的功能大多只是附属，所以自己写了一个。好了，秀一下界面吧。这段时间我的状态比较奇怪，也不知道为什么，对于用C#写东西开始失去了兴趣，一是觉得太过高层，很多细节都接触不到，二是随便一个小程序内存占用都是10MB以上。所以前段时间我学了Qt，觉得Qt的整体设计很不错，写出来的代码结构很好看，但有一个致命的缺点是我所不能忍受的，编译出来的程序体积太大了，就算用Upx压缩之后最小还是2MB。之后又动过念头去学习MFC，奈何这东西现在看实在太过繁琐，很多设计用几年前的眼光去看还不错，但现在就觉得落后了些。挑来挑去最后还是拿起了Delphi，5、6年以前它也曾是我手里的利器，很是写过不少的东西。之后因为种种原因再没碰过。这几年这个昔日有着王霸之气的IDE也随着Borland沉沉浮浮，Pascal这门语言也渐渐被世人冷落。我下载了最新版本的Delphi 2010，初用了下还行，深入用下去就发现自己真是被VS给惯坏了，相比下来Delphi的代码编辑器真是太低能了。智能提示窗口出来之后第一行竟然没有焦点，这让整个编码过程变得很痛苦，经常需要去按Ctrl+Space或者下箭头。我心说这种问题应该早就有人郁闷过了，上网一找果然，国人的cnpack就是解决方案。装上之后舒服了。之后就看了看语法，熟悉了下类库，写下了这个小程序。别看功能简单，我连学带写还是花了三个晚上才搞定。因为国内不能直接访问Twitter，所以加上了启用Twitter API代理的功能。用法简单，配置好账号信息，设定一个热键。呼出主窗口，输入文字，回车，搞定。最后还是忍不住要抱怨一下，本来的设想是，消息发送完成之后在TrayIcon上弹出一个气泡提示。很简单一个功能对吧，但是Delphi 2010自带的TrayIcon控件竟然因为有Bug而无法实现。我那个郁闷啊！随后换了Raize控件包的RzTrayIcon，发现该控件在XP下面工作良好，到Vista就不行了。好吧，果然是C#太过高级了，此类问题是永远不会碰到的，我也被惯坏了，现在一时间还真就解决不了，正在啃Vista的SDK，希望过几天能自己fix一下这个bug。这里是MiniTwitter的下载链接，喜欢的话就用用吧，如果你能给我留个言的话我会更开心:) 点击下载

小工具 – 天涯帖子抓取器

Allen Dang — Tue, 08 Sep 2009 10:00:05 +0800

老婆酷爱在天涯上看小说，莲蓬鬼话是她的最爱。这天她跟我抱怨，说帖子太长了，且里面回复太多，看起来很不方便。所以我就答应了帮她写一个抓取天涯帖子内容的小工具，以方便她的小说阅读大业。正好最近在学习Qt，便用它来练练手。Qt确实很方便，原以为代码量肯定要比C#多一倍以上，没想到竟然还少了，这样一个小东西只花了不到600行就搞定了。确实应了Qt的广告词，Code Less, Create More。下面就秀一下截图：很简单，应该不需要教程就会用了。只要把帖子第一页的地址粘贴到“帖子地址”然后点击开始抓取就可以了，抓天涯会自动抓取所有页面的内容。现在还有个不完善的地方，很多帖子都还在继续更新，而每次都需要重新开始下载，太浪费时间。我会在将来加入类似断点续传的功能，从上次下载的位置开始抓取更新了的内容。已经完成了这个功能，下载链接也更新了。现在在下载帖子之前会查看保存目录，如果发现同名文件就会开始继续下载。 ————————————————————————————- 2010年11月20日更新 ————————————————————————————- 之前因为天涯的页面有调整，导致抓天涯不能正常工作了。这么长时间之后我终于更新了它，现在又可以工作了。由于始终不能接受QT程序过大的体积，这次用MFC重新写了。这里是下载链接：点击下载

使用Qt读取大文件最后一行

Allen Dang — Mon, 07 Sep 2009 16:30:29 +0800

正在写的一个小软件需要这样一个功能，在开始一个新的下载任务前，先尝试在本地寻找是否已经存在同名文件。如果有，那读取文件最后一行文本，这行文本里面记录了上次下载的一些信息，然后从断点开始继续下载。最后一行文本的格式很简单，就是[页码|行号]，例如[160|8]就代表160页第8行。读取的基本思路就是，先把文件指针移动到距离文件尾部20个字节的地方（这里留20个字节是因为我的最后一行信息很简单），然后循环读取每一行，最后一次读取到的就是最后一行文本。目标文本文件最后一行如下： [160|8] 具体代码如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 QFile file("C:\\test.txt"); if (file.open(QIODevice::ReadOnly | QIODevice::Text)) { qint64 len = file.size(); QTextStream reader(&file); QString lastLine; if (reader.seek(len-20)) { while (!reader.atEnd()) { lastLine = reader.readLine(); } } file.close(); QRegExp re("\\[(\\d+)\\|(\\d+)\\]"); if (re.indexIn(lastLine, 0) != -1) { QString page = re.cap(1); //page = 160 QString pos = re.cap(2); //pos = 8 } } 任务完成！

浅谈.NET Micro Framework的性能优化。

Allen Dang — Thu, 23 Apr 2009 14:27:26 +0800

(如有转载，请注明出处，谢谢) 由于工作原因，这几个月对.NET家族的新成员.NET Micro Framework做了一些研究和实践，对于这个可以直接运行在硬件上的小家伙还是很看好的。它的可剪裁性，高定制性，和天生对硬件高集成度都让它的前途一片光明。当然，它现在还很年轻，就发布的SDK v3.0来看，它还有很长的路要走。废话不说，就这几个月我用下来的经验谈谈在针对MF应用程序的性能优化吧。 1. 尽可能减少方法调用！方法调用过于频繁对于性能的影响非常大，所以所有的优化都是以这个为大前提的。 2. 尽可能避免使用属性，而用公共域来代替。因为编辑器会在编译的时候为每个属性的getter和setter添加访问方法，基于第一条，这是要避免地。当然也不是说完全避免使用属性了，毕竟有的时候属性是很方便且必要的。比如这个下面这个使用属性的例子： public class Test { public string Name { get; set; } } 需要把它改成这样： public class Test { public string Name; } 3. 只在构造函数里面初始化变量。这一条很容易明白，看下面的例子： public class Test { private string name = "Test String"; private DateTime date = DateTime.Now; private int score, counter; public Test() { score = 0; counter = 0; } } 初始化的工作其实进行了两次，一次是在声明变量的时候，另外一次是在调用构造函数的时候。遵循第一条原则，我们要尽可能减少方法调用，且构造函数的使用概率很高，所以我们在此需要把初始化的工作全部集中到构造函数里面来进行。 4. 只在必要的地方调用lock。对于MF这样一个半实时的系统来说，lock的成本远远高于我们的想象。在.NET里面可能感觉不出来，但到了MF这个小伙子手里感觉就非常明显了，也许这一条大家已经知道了，就当我老调重弹吧。看这个例子： public class Test { private ArrayList objs; public void SomeMethod(object o) { for(int i = 0; i < 100; i++) { if (objs.Contains(o)) { lock(objs.SyncRoot) { objs.Remove(o); } } } } } 在一个循环里面增删一个集合，由于是多线程访问，所以在操作之前加了锁。之所以在循环内部加锁，理由可能是想尽可能的减少lock的访问次数，只有满足那个if条件的时候才会被调用。实际上，这个想法错了，无论如何，这里的lock都会被调用很多次，这些开销加起来就会对性能造成很大的影响。把代码改成这样就会好很多： public class [...]

我的Visual Studio 2008颜色配置。

Allen Dang — Fri, 20 Mar 2009 10:54:52 +0800

花了好几天慢慢调出来的颜色，现在长时间看着眼睛也不会不舒服了。点击这里下载。