All Stories
买硬盘有一段时间了，当时的想法是可能要做Linux平台的开发，所有自己家里的机器上也得正儿八经地装个Linux某个发行版，于是纠结了很久，终于在京东上花了总共780块大洋买了个WD的绿盘2T。结果把硬盘装入机器后，只是分了十几个分区，就再也没动静了。
后来过了大概2、3周吧，实在对自己鄙视得受不了了，翻出两个8G的U盘来，一个是花了20块大洋从淘宝买的，谁料想过了没多久公司（已经是前公司了）又因为十周年纪念每人发了一个8G的U盘。于是从网上找资料看了一下，在Windows系统下用一个叫Win32Image Writer的程序把Linux发行版的ISO镜像写到U盘里，就可以从U盘启动安装了。
先是装了个Debian 6，用的GNOME，装好后发现屏幕闪得厉害，估摸着是显卡驱动的问题，据说ATI的显卡Linux就是支持不怎么好，我的是Radeon HD 4540，从网上找了一圈各种解决方案，试了各种配置和开源闭源驱动，都没效果，很失落。本来对Debian的印象很好的，就是一种运行速度快，而且稳定的发行版，因为曾经在公司用VirtualBox装了LinuxMint和Debian同时编译clang，发现在Debian下要快不少。可是现在的闪屏问题使得这个系统处于基本不可用的状态。后来我还试了换GNOME为KDE，果然没用。于是知彻底绝望了。
因为Debian的闪屏问题搞不定，于是只好试着装装Ubuntu12.04这种小白发行版，它果然一装上就所有驱动都搞定了，不光是我那块显卡，连在10.04时需要自己找相同芯片其他牌子无线网卡的驱动源代码来自己编译安装才能使用的Fast无线网卡都直接驱动了。真是让人感叹果然是个适合我等小白使用的发行版。本以为问题就这样搞定了，于是下载了qt呀，qt creator呀，clang呀之类的源代码，都编译了使用。可是好景不长，不到两个星期，就出现各种问题。比如启动特别慢，在红黑屏要停留很久，一开始都以为是启动不了了，后来才发现是因为需要时间很长。再后来，各种已有的分区不能自动挂载了。虽然可以自己敲命令挂载，但终归让人心里极其不爽。到现在，居然不能关机了，一直停在关机logo界面里了。失望透顶，Ubuntu是从7.x以来，各个版本都装过的，窃以为最不稳定的Linux发行版，没有之一。
今天实在对Debian和Ubuntu失望之极，打算再换个发行版试试。之前在VirtualBox中用过不短时间的Arch，Fedora，openSUSE和Mandriva，对于Arch和Gentoo，我就担心显卡问题搞不定。对于后三者，不是很喜欢它们的包管理机制。于是最后打算看看Mint吧。以前在VirtualBox中也装过Mint，现在公司里还装着用呢，它默认不使用GNOME或KDE，而是使用Mate或Cinnamon，感觉挺精致的。在装Mint还是LMDE之间犹豫了一会儿，后来看LMDE用的是Debian的testing源，在我看来相当于放弃了Debian的稳定性这一大优势，所以还是用Mint吧。安装过程仍然一样，写入U盘可以当Live盘启动，然后安装，很快很傻瓜。而且我之前装Debian和Ubuntu把它们的/home都放到同一个分区，而且两个系统中都用相同的用户名，在Mint中也这样做，就可以直接使用以前做好的一些把配置写到/home目录的软件的配置了。
Mint用了近一天了，感觉不错，就看它能用多久吧。
又好久没写blog了。上上周从推友处入了个二手的Kindle4,这是个很划算的事。350元顺丰到付，成色很新，还有个山寨的皮套。拿到手后，我就爱不释手了。
首先，Kindle4很小很轻，只有6寸，而且没有键盘，一只手就可以竖握整个机器，拿起来很方便，随身携带比带书轻便多了。
其次，E-ink屏真的很赞，真的只有自己实际把玩过，才会体会到它的好。之前很多次都冲动想买个Kindle，都被自己以“我不是个爱看书的人”为理由扼杀了这冲动。这次之前是橙子拿她刚到手的Kindle4来让我玩了一下下，于是就冲动了，刚好推上求二手也便宜，就入了。E-ink的屏幕观感上很接近纸版印刷，让人看起来相比电脑，手机，平板等等觉得更类似书本，另外个好处是，我早上上班路上会拿出来看点东西，如果露天有大太阳的情况下，用Nexus S手机看小说时得把屏幕调到最亮才能看清，E-ink则不在乎这个问题，但同样的，晚上回来如果天黑光线不足，E-ink就不行了，据说可以通过配备小照明灯解决。
再次，Kindle4有很方便的推送功能，只要把指定格式的电子书作为附件发送到Amazon给分配的邮箱里，Kindle在连上WIFI后就会后台自动把书下载来。这样一来，可以实现很不错的功能。比如定时推送RSS等内容，虽然网上已经有一些免费或付费的推送Google Reader或RSS的服务，但我还是打算自己写一个。有几个原因，一是这些服务免费的一般都有比较大限制，比如Google Reader推送时间只能一天一次，顶多一天两次，推送RSS则往往对订阅数有限制。二是我想增加多一些推送的类型，比如小说更新，漫画更新，还有从SNS消息中提取的链接内容。三是推送过来的字体、排版以及插入广告之类，终归不是很舒服。因此要写这样一个程序，打算设计成一个C/S架构的应用，客户端和服务器都具有内容下载生成的功能，但服务器端可以实现定时推送的功能，客户端可以把定时推送的请求发送给服务器端。
最后想说下遗憾的事，6寸屏对于看扫描版16开或22开大小的PDF还是不够理想，我在考虑是不是再入个DXG。
在新公司上班一周了，过上了坐地铁上下班的日子。以前每天自己开车上下班时，还有点向往那种坐公交地铁上下班的人，觉得可以在路上看到各种各样的人，还可以拿个手机或平板在路上看书。现在这样过了没几天就厌烦了，地铁太挤了，每天上下班一路会挤得浑身大汗，根本没心情看什么书，除了网络小说。
第一周干不了什么活，连产品的源代码都还没看到，说要我先写个小程序，写完了才给我看，原因是之前有个人去干了两天就跑了，他们担心源代码泄露。好吧，这次要在Linux下用socket写个C/S的小程序，但我今天突然发现他们现在的想法是不是有点问题，还是我没有彻底理解他们的需求。好吧，小公司确实是小公司的样子，感觉做事就是没条理，有点乱糟糟的，也许是以前呆的公司不是跟IBM学了IPD流程，就是跟着Microsoft的Workflow走，淡定点。
要在自己机器上至少装个Linux发行版，好好学习下Linux下的socket程序编写。是不是该去买个VPS，然后可以反向连接到公司里的Linux虚拟机上去。囧，这么大强度做Linux上的开发，居然还是只用虚拟机。
这两天在Windows下折腾clang。这东东前端是支持C/C++/Objective-C/Objective-C++，后端一般是用LLVM的。在Mac OS X上貌似用得很好，可以生成OSX和iOS的app，貌似在Linux或FreeBSD上也支持得不错的样子，不过在Windows上就纠结了。
首先，clang还是依赖gcc的crt和headers的。于是在Windows上基本上是用MinGW套件的。但是同样是MinGW，不同的人都能编译出不同的东西来，版本众多，质量也不同，貌似还是MinGW官方编译的版本最为稳定，MinGW-w64的x64版本貌似就压根编译不了clang。
众多32位版本的MinGW都可以编译clang，但是，编译出来的clang貌似就是能自举了，真是遗憾，也不知道是不是我哪里弄错了，4.4.0版本是报BFD模块中有个内部错误，4.6.3版本是在链接时报错，4.7.x版本则是编译第一个文件就报命令行参数错误。
我是在msys中编译的，值得提一下的是，它每次都要做rebuild all才行，incremental build貌似是不行的。还有就是perl中的pod2html.bat在msys中是用不了的，所以在make install时都会报错的。
最后要注意，编译clang前，需要修改下llvm\tools\clang\lib\Frontend\InitHeaderSearch.cpp中MinGW的头文件搜索路径。最简单的办法是硬编码增加搜索路径，但是这样你的MinGW和clang就只能存放在固定的位置了。我看了一下clang dev去年4月的maillist中一个thread，其他他们就是没找到一个高效低成本的方案来解决这个问题。于是我就自己用了一种quick & dirty的方案。先查找clang所在目录是否有gcc.exe，没有就找PATH环境变量中有没有，再没有就试试各个分区根目录下有没有mingw目录，如果能找到gcc.exe，就运行gcc.exe -v命令，得到target和version，这样就可能得到搜索路径了。自己写了大约200行代码，粘贴到这里了。
今天是在Wicresoft上班的最后一天，中午请share team的所有人去食堂吃了一顿饭，其实食堂也不便宜，原本我打算在华师大的秋实阁请的，但是暑假了华师大食堂都关门了。于是在紫竹一食堂吃了，16个人542块钱。
这次跳槽是出于两个原因，一是经济方面的考虑，对于目前的我来说，跳槽是涨工资最快的方式，另一方面是工作内容，在Wicresoft做Dynamics AX的SE工作，我的生产力极其低下，查了一下过去一年的成绩，我的产出大概连Michelle的一半都不到，这让我很忧伤，这样的状况让我连向领导提出加薪的勇气都没有。新的工作我的要求是要多做些编码，SE工作可能一个月都写不到一行代码，我觉得我写代码的能力这样下去会退化干净的。而且我一直以前都只能说会C++，熟悉Windows平台桌面应用开发，却没有一个真正熟悉、精通的领域，这次新的工作会涉及到多媒体视频、网络传输方面的内容，这样我也就有机会拥有一两个领域的专业技能和知识了。
办离职手续其实总共花了不到2个小时时间，但跑来跑去还是挺累人的。
最近Ainesmile的进展几乎停下来了，因为想到要让它支持像TextMate那样的bundles机制，但又为了避开版权问题而不能直接使用TextMate的bundles，所以就想把那些bundle的格式转换一下用就行了，于是就要写个小程序进行文件格式的转换。为了这个转换小程序更具有通用性和实用性，我就很是贪心地想让它支持在JSON、Apple PList、Windows INI、Java Properties和plain XML任意二者间进行相互转换。本来想想觉得只是个很小的任务，可实际做的时间还是有很多事情要做的，而且想来这样一个具有通用性和实用性的工具应该可以发布给别人使用，于是在包装上也做了更多点的工作，比如画图标，而且为了能在Windows和Mac OS X上都能使用，同时以为以前用过的一个Rapid XML封装更容易使用，结果陷入了无尽的跨平台的fixing中。
昨天发现一个新语言，Rust，据说是Mozilla开发来为了替代C++重写Firefox用的，现在才0.3版本，语言特性也还在快速变化中。看了半天的tutorial，发现语法上给我的感觉是很像Ruby，又有Erlang的一点点元素，而它自称是一种系统编程语言，所以从一开始就很注重与C的交互。它是一种编译型语言，有个叫rustc的编译器，现在还只能通过自己下载编译源代码来使用它。看tutorial的时候突然有个念头，这些年不断冒出来的声称解决了一大堆问题的编程语言，实际上也就是它声称的那些个领域上表现较好而已啊，C语言才是王道啊，哈哈。
在编译Rust的时候，发现它自动下载了最新的LLVM和Clang的源代码并编译好了，于是我就想再试下Mac OS X下用Clang编译下Qt，以前曾经尝试过但失败了。这次也遇到两个错误，就是返回值类型要去const修饰，gitorious上已经有patch的，但在4.8.2上没有合入，自己改一下整个Qt 4.8.2就能用Clang编译通过了。Clang在Mac OS X上基于上处于产品级的质量了，但不知道在Windows上什么时候才能达到近似的水平啊，叹气。貌似Clang对unix-like的系统都支持得挺不错的，甚至能用来编译FreeBSD内核。
最近正在编写一个文本编辑器，取名为Ainesmile。按照惯例，这个名字同样是一个妹汁的id。
这个文本编辑器的目标是成为超越Coda、Sublime Text和TextMate的存在，所以基本的定位是一个代码编辑器，也可以做为一个通用的纯文本编辑器。它使用Qt开发，所以目前可以确认的是它将可以在Windows和Mac上运行，如果移植代价不大，将也会在Linux或FreeBSD等其他Qt支持的桌面环境中运行。
写这么一个文本编辑器的出发点，首先，我觉得Mac OS X上的几个编辑器的功能都很炫目，很有现代感，而Windows平台上除了e，就没有其他类似产品了，而e的功能也似乎只是TextMate的一个子集。其次，我觉得Mac用户真是人傻钱多的存在啊。
功能方面，我觉得实现起来没有特别大的技术难点，只不过工作量有点大。当前一个主要的问题是，美工方面，缺少一套用于菜单、工具栏的图标，以及程序图标。求帮助。
这个月总的说来过得很开心，进展很大，当然前些天也一度出现很灭世的事，甚至为之放声大哭。
一个人的日子果然非常无趣，于是马上回到了用物质享受来麻痹精神的状态，买了一个BlackBerry的PlayBook，一个HP的TouchPad，总共花掉2600块钱，这个月就开销就这变大了。
之后一段时间最主要的两件事，一是找工作，二是写程序。有很多程序要写，现在由于Qt的lighthouse在4.8版本的比较成熟的运用，使得它在QNX，Android，iOS平台上都能进行可以发布级别的移植了，甚至webOS上都可以用了，除了据说虚拟键盘会弹不出来，这样在Pre2/3上应该是没问题吧，虽然我最想的是在TouchPad上用。不过iOS上那个Qt4iOS是要付费的，而且不卖license给个人用户，估计是因为太贵，作者觉得个人用户承受不起，郁闷！
昨天下班后去浦东机场接了小咪，感觉她跟中学时的长相差别好大，看照片中学时要清纯漂亮很多。回到小区是21:39，然后去对面的接头暗号吃肉，不过好像有点吃坏肚子了，晚上2点多起来拉肚子。后来醒来很多次，7:15时醒来打电话喊人起床，再一直迷迷糊糊睡到10点多，发现小咪已经起床了，再起来两人收拾收拾，去老街吃东西。每当有人来这里，我都是带人去老街吃东西，哈哈。不过小咪没像其他人一样吃汤圆，而是去吃了小笼包。吃完就把她送到虹桥高铁站送走啦！
从高铁站回来，又把别人托小咪带回来的东西送到人家手上了。
哈，好像没什么可以写的了。
上周基本解决了一个dump文件分析的问题。
一开始，问题没有弄复杂，只是从最后异常看到call stack，大体得出某个类的指针为NULL，却被继续使用，然后fix的话只要在被使用前判断一下是否不为NULL就行了。
不过这个fix有一点没有考虑到，是该方法一开始就有一个分支对该指针进行了判断。所以如果该分支确实成立的话，我的fix就说明有问题了。于是新的问题就成了验证该分支的条件是否成立。
分支的条件是判断另一个对象的每个成员是否为空。本来，这个对象一开始是new出来的，指针是某个方法的局部变量，一般说来是放在栈上的。不过通过call stack切换到那个方法的context后，发现查看局部变量并没有那个指针。通过查看反汇编的代码，才发现原来该指针被优化了，并不存储在栈上，而是存储在寄存器r13上了。于是我就开始想着如何可以查看某一级call stack时的寄存器，一开始我以为每次call指令时，会自动把所有寄存器的值都压栈的，后来发现不是，还特地去找了Intel的指令手册看了一下说明，反正没说有压栈寄存器，大概是我记错了。问了一下那个老外同事，他说没什么办法，只有想办法从栈里找。
这样没头绪了几天，后来灵光一闪，偶尔发现在call stack中使用r13存储指针的方法的下一级被调用方法的反汇编代码中，把r13压栈了！于是只要在栈中就肯定能找到那个指针的值了。至于怎么找那个栈中的位置，从函数的返回地址找！从最后的esp值开始大地址（栈的生长方向是往小地址方向生长）开始搜索那一个方法的返回地址，找到后再往小地址找压入的栈的寄存器值，果然找到一个值，可以通过dt来查看，还可以通过dds该地址的vf-table来查看它的虚表包含的虚函数名称，这样就可以验证是否是要找的那个对象。果然没错！
