Soul Orbit

这两天重新下了个最新的Chrome的源代码，想编译一下，结果发现怎么都编译不过，在编译webcore的工程时，报了一大堆与如下类似的错误：

error C1083: Cannot open include file: ‘EventInterfaces.h’: No such file or directory
error C1083: Cannot open include file: ‘CSSValueKeywords.h’: No such file or directory

1. 问题原因

找了很久终于找到了问题的原因：

EventInterface.h和CSSValueKeywords.h这些文件本身是不存在在代码中的，而是根据对应的idl文件的描述，系统在对应的平台下动态生成的。大家可以在src/third_party/WebKit/Source下搜索到这些idl文件。

而在windows下，由于没有自带的perl环境，所以chromium会在third_party下加入cygwin的目录，并利用cygwin来执行perl和相关的脚本。

由于chromium运行cygwin的方式是将其bin目录设置到PATH环境变量中，从而运行其脚本，所以其中一些目录环境就没有配置，比如/usr/lib文件夹是对应的windows的哪个文件夹。而chromium编译时依赖的perl就在这个文件夹内。

所以总的来说，就是在现在的代码在编译的时候无法找到当前需要的perl脚本，所以就无法正常编译。

2. 解决方法

既然已经找到问题的原因了，那么问题也就很好解决了。

在src/third_party/cygwin目录下，有一个setup_mount.bat的文件，运行这个文件，他会将cygwin相关的目录配置全部导入注册表内。这样perl就可以被正常执行了，那些文件也就可以被生成出来了，这个问题就算是初步解决了。

当然这只是一个临时的解决方案，因为这个修改是无法提交回chromium的，在原来的chromium的代码中，是存在一个叫做cygwin的工程来帮我们在每次编译前都自动运行setup_mount.bat的脚本的，但是现在这个工程消失了。

所以最好的方法其实应该是修改其gyp文件，修复windows下的工程信息，然后提交回chromium，但是我暂时还没有太看懂gyp文件，不知道怎么完全还原cygwin工程的配置，所以这个想法就暂时这么搁浅了。

chromium的网站上也有一个关于这个问题的issue，不知道什么时候才能有结果。现在看来只能静待佳音了。

Spotlight是一个让人又爱又恨的东西，一方面他确实相当好用，但是另外一方面，他也确实占用了不少系统资源，在进行大量文件操作的时候，经常将CPU占满，可以将我可怜的macbook pro烧到80度左右，所以不能不好好的折腾他一下了，这里总结一些这两天摸索出来的Spotlight调优的方法，希望能对大家也有些帮助。

本人使用Mac现在总时间还不超过一周，所以很多东西理解的可能是不对的（什么可能啊，是应该吧），有不正确的地方，还请大家多多指正。

以下优化是在Mac OS X Lion 10.7.2 的系统上实践出来的，其他版本的系统可能有一些不一样，大家可以Google一下具体的方法，但是基本步骤应该是差不多的。

如果没有大量的文件操作，Spotlight对系统的影响还是不大的，占用CPU一般是3% - 5%左右，没有太大必要进行优化。但是如果发现最近电脑温度很高，或者电池消耗很快，就可以检查一下Spotlight，参照这篇文章进行优化了。

我们用VS编译出来的QT程序，经常会遇见中文乱码，其实解决方法很简单：

在main函数所在文件的包含如下文件：

1
2

##include <QtCore/QTextCodec>

然后，在main函数的开头加入这么一句话就可以了。

1

QTextCodec::setCodecForTr(QTextCodec::codecForName("GB2312"));

之后在调用的时候，所有的字符串记得使用tr()函数包裹起来。比如：

1

QMessageBox::warning(this, tr("出错啦！"), errorInfo, tr("OK"));

这个是因为VS默认的编码是GB2312，而函数tr的作用，是将默认的字符串转换成QT内部的编码：Unicode，所以我们这里只需要设置好编码即可。

如果碰到一些2312里面没有的生僻字，我们也可以尝试使用Windows默认的多字符编码GB18030来解决。

一年一度的公司旅游，结果去的地方我已经去过了，于是抓住机会请了三天年假，想在家里好好休息休息。当然MM还要上课，所以去不了什么远的地方，于是，打算这几天在北京逛逛，然后听听音乐会就这么休息过去吧。
中央音乐学院真是一个好地方，时不时就有演出可以看，有时候还是大师来演出，质量也是相当的高，最后外加一个双休，五天听了五场，很爽很震撼。

第一天是一场几米的漫画主题音乐会，开场比较搞，为了和几米的漫画造成反差，居然用了德国战车的Engel当开头，不过后面真的很感人，期间有一首德彪西的音乐，基本上改变了我极度不喜欢他的看法，后面在看《蓝石头》+ 《空顶之光》的时候，居然被感动到流泪了，没有办法，那样干净的旋律，配上蓝石头这么煽情的剧情，再加上一个杯具的北漂程序猿，怎么不感动。当然最后被MM狂笑了一顿。。。。。一个爷们，感情神马的，哪来这么丰富。。。。。

C++多重继承一直是一个让人搞不太清楚的一个问题，但是有时候为了实现多个接口，多重继承是基本不可避免，当然在Windows下我们有强大的COM来帮我们搞定这个事情，不过如果你想自己实现一套类似于COM的东西出来的时候，麻烦事情就来了。

在COM里面，有两个很基础的，而且我们都会用到的特性：

1. 纯虚接口：一般使用一个只有纯虚函数的类来作为接口
2. 引用计数：在C++中一般都使用引用计数来管理对象的生命周期

这两个功能在一般设计C++接口的时候也经常用到。其实说到底，上面这两个特性牵扯到的是多重继承的二个表现：

1. 多重继承中的数据存储
2. 多重继承中的虚函数

在COM中，纯虚接口是使用的interface来定义的，引用计数是通过IUnknown接口来实现的，所有的接口都是从IUnknown这种接口中派生出来的。当我们需要某一个类实现多个接口的时候，就经常会遇见这样的多重继承：

哦？！是不是很眼熟，ios，istream，ostream，iostream。。各种C++书籍最喜欢用的一个示例。好吧，现在我们先自己实现一个吧，看看到底要怎么使用多重继承。

看Chrome已经有一段时间了，但是一直都没有沉淀些内容下来，是该写写笔记什么的了，免得自己忘记了。看的都是Windows平台下的代码，所以记录也都是记录的。。。废话。。

那么首先，先从最基础的东西记录起吧：Chrome的线程模型和消息循环。

1. 多线程的麻烦

多线程编程一直是一件麻烦的事情，线程执行的不确定性，资源的并发访问，一直困扰着众多程序员们。为了解决多线程编程的麻烦，大家想出了很多经典的方案：如：对资源直接加锁，角色模型，CSP，FP等等。他们的思想基本分为两类：一类是对存在并发访问资源直接加锁，第二类是避免资源被并发访问。前者存在许多问题，如死锁，优先级反转等等，而相对来说，后者会好很多，角色模型，CSP和FP就都属于后者，Chrome也是使用后者的思想来实现多线程的。

快四月份了，传说中的樱花终于盛开了，于是和MM一起跑到玉渊潭，准备来一场浪漫的樱花之旅。结果。。。

这是我幻想中的樱花节：
河河路花花路路路花花路河河
河河路花花路路路花花路河河
河河路花花路人人花花路河河
河河路花花路路路花花人河河
河河路花花路路路花花路河河
河河人花花路路路花花路河河
河河路花花路路路花花路河河
河河路花花路路路花花人河河
河河路花花路路人花花路河河
河河路花花路路人花花路河河

结果现实中的樱花节是这样的：
土土土土土土土土人土土土土
人土树土土树树土土土土人土
土人树土土土土土土树土土土
土土土土土树树人人土人土土
土土树树土人土人人人人人土
人土土土土土人树树人树人土
土土土土树土人人人花人人土
土人树土土土土人人树人人土
土土人土土人土人人人人土土
土土土树土土树土树土树土土
土土人土土土土土土土土土土

=。=||| 真是坑爹啊！不过，凑近了看，看是有好看的景色的。。嗯。。凑近了看。。近了看。。了看。。看。。

前几天想在wordpress里面插入一小段ubb来生成一些链接，结果发现居然没有，于是自己写了一个很弱的小插件来管理自己的ubb代码。语言暂时只有英文，不过内容是中文也是可以用的。

Wordpress的用户信息真的不是很友好啊，找了半天也没有找到我自己的项目列表，寒。

现在代码总算是提交了，不过也不知道什么时候才能生效，姑且先这么放着，看看明天结果如何。

============= 我是欢乐的分隔线 =============

**插件名称：**ubb-master
插件地址：http://wordpress.org/extend/plugins/ubb-master/
插件用法：
一段典型的ubb代码，一般如下：

1

[search]put your keyword here[/search]

然后我们就可以这样替换这段ubb代码了：

• !{content}: 在[ubb]和[/ubb]标签之间的内容。
• !{encoded_content}: 经过urlencode之后的!{content}
• !{attr:attribute_name}: [ubb]标签中名为attribute_name的属性
• !{encoded_attr:attribute_name}: 经过urlencode之后的!{attr:attribute_name}

比如，如果我们将search的ubb格式定为如下这段代码：

1

<a target="blank" href="http://www.google.com/search?ie=UTF-8&q=!{encoded_content}">!{content}</a>

那么上面这段ubb在输出中将会被转变为如下的内容：

1

<a target="blank" href="http://www.google.com/search?ie=UTF-8&q=put+your+keyword+here%26%238230%3B">put your keyword here…</a>

这样，我们就可以自己定义自己的ubb代码，而不用四处找适合自己的wordpress插件了。

好，看完了如何使用breakpad，我们现在看看breakpad在Windows下到底是如何实现的呢？

1. 代码结构

在我们来看breakpad是如何实现其强大的功能之前，我们先来看一下他的代码结构吧。

• Google breakpad的源代码都在src的目录下，他分为如下几个文件夹：
• client：这下面包含了前台应用程序中捕捉dump的部分代码，里面按照平台分成各个子文件夹
• common：前台后台都会用到的部分基础代码，字符串转换，内存读写，md5神马的
• google_breakpad：breakpad中公共的头文件
• processor：用于在后台处理崩溃的核心代码
• testing：测试工程
• third_party：第三方库
• tools：一些小工具，用于处理dump文件和符号表

我们先来看Windows下前台实现的部分，也就是client文件夹下的代码。

Google breakpad是一个非常实用的跨平台的崩溃转储和分析模块，他支持Windows，Linux和Mac和Solaris。由于他本身跨平台，所以很大的减少我们在平台移植时的工作，毕竟崩溃转储，每个平台下都不同，使用起来很难统一，而Google breakpad就帮我们做到了这一点，不管是哪个平台下的崩溃，都能够进行统一的分析。现在很多工程都在使用他：最著名的几个如Chrome，Firefox，Picasa和Google Earth。另外他的License是BSD的，也就是说，我们即便是在商业软件中使用，也是合法的，哈哈，这么好的东西，我们能放过么？现在就让我们来看看这个神奇的软件吧。

1. 原理简介

breakpad抓取dump的方式和一般我们抓取dump的方式不一样。在breakpad的wiki上有一幅图可以很好的概括他的原理。

breakpad把应用程序分成三个部分，代码，breakpad客户端和调试信息。

1. 在build system中，通过symbol dumper用平台相关的调试信息生成平台无关的symbol文件。这样做的好处很明显，一旦平台无关了，所有平台的崩溃就可以做统一的分析了。
2. breakpad采取进程外转储和分析崩溃的方式，他使用C/S结构，客户端用来捕获当前进程中发生的崩溃，并通知服务端崩溃发生。服务端用来响应客户端，抓取dump文件。这样做的目的是为了减少崩溃进程对dump的影响。
3. Dump生成后转发到崩溃分析器中，这个部分可以在本地也可以在服务器上，他对Dump文件进行解析，生成可读的堆栈信息。

这就是breakpad处理dump大概的流程。