TimothyQiu's Blog

keep it simple stupid

定位工具 Git Bisect

No Comments

经过 @Neuron Teckid 童鞋的提点,发现了 git bisect 这个非常有意思的工具。

话说,我第一眼把 bisect 看成了 biscuit,以为 Git 也开始学 Android 卖萌了呢……结果一查字典,这个词是「等分」的意思……

假设某天你发现你编译出的程序里有个 Bug,该如何找出它是从哪个版本开始引入的呢?在版本历史中找出有 Bug 和无 Bug 两个版本,用简单的二分查找法就可以定位啦。git bisect 正是用来帮助你完成这种二分查找法的自动化的。

基本用法

git bisect start         # 初始化二分查找
git bisect bad           # 标记当前版本存在问题
git bisect good 38a63d9  # 标记 38a63d9 版本没有问题

至少标记了一个没有问题的版本(Good)和一个有问题的版本(Bad)后,Git 就会开始二分查找的过程,不断检出 Good 和 Bad 中间的版本等待你检查后作出标记。每次检出后 Git 都会提示你还剩多少文件、大致还剩余多少次比较:

Bisecting: 441 revisions left to test after this (roughly 9 steps)

比如上面这三步后,Git 检出了中间版本 b17ff03。你编译运行后发现这个版本没有问题,就可以用 git bisect good 将当前版本标记为没有问题。此时 Git 就会再把 b17ff03 和最初版本之间的区域二分,检出中间版本等待你的检查。

等一切完成以后,就可以用 git bisect reset 返回开始前的版本。

自动查找

手动标记 Good / Bad 可以帮助人类从挑选下一个合适的版本的工作中解放出来。(似乎可以理解为 C++ 从 forstd::for_each 的抽象过程。)但这还是远远不够的,因为测试某个版本是否正常的重任依旧需要人类的介入。

所幸你可以指定一个检测用的程序,让 git bisect 自动完成整个定位的过程。这个程序必须在当前版本没有问题时返回 0,而 1 到 127 之间的值则表示有问题(特殊值 125 表示没法确定)。

git bisect run <cmd>...

例如,让你从一个陌生的代码库里找到能够编译和不能编译的临界提交,我们可以通过传入 make 来实现自动化查找:

git bisect start HEAD 38a63d9  # 简单写法:初始化二分查找,HEAD 有问题,而 38a63d9 没有
git bisect run make            # 利用 make 来检测某个版本是否能够通过编译

而后,Git 就会自己用二分查找法不断检出中间版本,每次检出后都会运行 make,根据 make 的返回值来确定当前版本是否存在问题(是否能够通过编译)。

以上。

被遗忘的 Git Stash

2 Comments

在介绍 Git 的时候,大多数文章都会提到它在 Working Copy 和 Repository 之间新增的 Staging Area,它使得你可以只提交 Working Copy 中的一小部分。作为一个半路出家的 Git 山寨用户,我之前知道的也就只是这三个地方了,不过这两天发现了第四个区域:Stashing Area。

假设你刚把代码改得乱七八糟,忽然想要从修改前的某个版本里做一个小改动,马上出一个紧急修正版。此时理论上,你只需先提交当前所有改动,然后就可以马上切换到以前的版本/分支开始工作了。但是作为「每次一提交都要能够通过编译」原则的忠实粉丝,这种思路所可能产生的垃圾提交是完全无法忍受的。

一种比较山寨的做法就是,手动把已修改的文件复制出去,然后 git checkout 回修改前的版本,最后切换版本/分支开始工作。做完以后再切换回来、把之前复制出去的文件复制回来。

Stashing Area 直接翻译过来是储藏间,是 Git 中用来暂存已作出的修改的地方,可以避免这种手动做法的繁琐。

  1. git stash save 将当前 Working Copy 中的修改保存为 Stash 中的一条新的记录,Working Copy 则变成了修改前的样子。
  2. 切换到别的版本/分支干活。
  3. 切换回原先的版本/分支。
  4. git stash pop 将 Stash 中最新的记录取出,并应用到 Working Copy 上。(从名字上可以看出,Stash 是一个栈式结构。)

Stash 的另一个方便之处是 git stash branch,它可以直接从 Stash 上创建一个分支。比如在你刚把代码改得乱七八糟,忽然想起来自己忘了新建分支的时候很有用。

相关信息

Windows 核心编程:字符串查漏补缺

No Comments

趁着双十一买了好几本想买的书,其中就有这本《Windows 核心编程》。首先需要吐槽的就是好好的《Windows via C/C++》这么高端大气上档次的名字怎么就被翻译成了这么个蛋疼样,而且中文版的封面也是扑面而来的一股浓郁的上个世纪气息,以至于在正文里看到 Vista 的字样都感觉各种穿越……

本文是关于这本书的第一篇读书笔记。天知道会不会有第二篇。

虽说之前已经写过好几篇关于字符编码的文章,都快写吐了,不过读了这本书的开篇还是感觉相见恨晚。这里对于前面这几篇里关于字符串的说明进行一下查漏补缺。

Unicode 和 UTF-16

前文书说到,Unicode 定义的是码位(Code Point),即为每一个字符赋一个唯一编号,记作 U+XXXX。Unicode 目前实际占用了 016 到 10FFFF16 的码位,有些已经分配了字符,有些还没有。

Unicode 中最初推出的 U+0000 到 U+FFFF 这 216 个码位称为基本多文种平面(Basic Multilingual Plane,BMP)。早年只有这一个平面的时候,Unicode 与 UTF-16 是等价的,因为可以做到一一对应。然而时过境迁,区区 16 位已经满足不了 U+10000 到 U+10FFFF 的码位了。

与 UTF-8 编码规则的爽快不同,UTF-16 在沦为实实在在的「编码」时,还需要考虑到向后兼容性问题。如何在维持 U+0000 到 U+FFFF 一一对应的同时,把剩余的 U+10000 到 U+10FFFF 编进来?

答案是:把 U+D800 到 U+DFFF 命名为 UTF-16 编码专用字符。即如果 UTF-16 数据流中出现了这一范围内的字符,意味着它本身不是一个字符,紧接着它的 16 位数据需要加上一定的偏移值才是真正的数据。

这一土豪做法让我目瞪口呆。至于 UTF-32,目前来说与它与 Unicode 码位一一对应起来绰绰有余。当然,如果哪天发现了外星文明,需要把他们的字符也编码进来,导致 Unicode 占用的码位暴增,说不定这一一对应的任务就只能交给未来的 UTF-64 了。这就是把问题留给子孙后代去解决的大智慧啊!

CHARLPSTR

前文书里吐槽过 Windows API 的丑陋不堪,也说过这也是历史遗留、不得已而为之。

没错的,CHARchar 在语义上并不等价,前者专指 8 位字符,后者则只是字符而已,说不定在哪个古董机器上就是 7 位了。(尽管我不认为你会在那上面跑 Windows……)

LPSTR 尽管被定义为 CHAR *,但它实际上还借助了编译器扩展实现了「以 NUL 结尾」的语义:

typedef __nullterminated CHAR *LPSTR;

Unicode 和 ANSI 版本

说实话我依旧不喜欢官方的这两个名字,我更喜欢「宽字符版本」和「多字节字符版本」这两个更拗口但更准确的名字。

由于现代 Windows 内部都是以 UTF-16 存储,实际提供的 API 本身也都是 Unicode 版本的,即以 W 结尾的版本。而相应的 A 结尾的 ANSI 版本则是在 W 版本基础上的封装。

于是可以想象,全局使用 ANSI 相比全局使用 Unicode 而言要占更多的内存,理论上也要更慢一些。

以上。

Direct Access

2 Comments

由于众所周知的原因,Google Search 是不稳定的。作为一个怕麻烦的小朋友,我几乎把所有 Google 相关的高危域名都列在 Proxy SwitchySharp 的切换规则里。

我这么做也算是牺牲速度带来省心吧,然而 Google Search 有一个蛋疼的地方,就是所有的搜索结果在你点击时都会先走 Google 自己的页面,重定向一下之后才会进入搜索结果对应的 URL。

生命在于折腾。忍了很久以后,今天突然兴起,囫囵吞枣地看了下 Chrome 官方的扩展开发文档,于是就有了这个 Chrome 扩展,代码和成品放在了 Github 上。尽管统计功能还存在已知的 Bug,但目前来说还是比较够用的,留待日后慢慢完善吧~

过段时间有空估计会折腾下放 Chrome Store 里去……

Ok 一段时间过去了,在同学的大力帮助下成功注册了 Chrome 开发者帐号,现在已经可以在 Chrome Store 里找到啦~(虽说估计应该没什么人会去用……)

p.s. 发现一个非常不错的生成简单图标的网站: iconmonstr

小试 Variadic Template

4 Comments

本文源自于今天对 neuront 童鞋的这篇文章的末尾的那段代码的 C++ 实现的思考。(好多「的」……)

尽管 std::accumulate() 和 Python 的 reduce() 类似,但因为 C艹 的 std::map<std::string, std::map<std::string, int>>std::map<std::string, int> 是不同的类型,所以似乎只能自己用可变参数模板写一个了。

简单起见,我们还是退一步,来解决一个更简单、更不通用、而且似乎和 reduce() 完全无关的问题吧:如何才能一次性取得任意层次的字典值?用更直白的代码表达,就是我们需要一个 GetMapValue() 函数,实现这样的功能:

// 用于缓解眼花缭乱感的宏
#define MAP_LITERAL(...) { __VA_ARGS__ }

// 简单映射
std::map<std::string, std::string>
simple_dict = MAP_LITERAL({"Hello", "World"});

// 「我勒个去居然这么麻烦」映射
std::map<std::string,
         std::map<std::string,
                  std::map<std::string,
                           int>>>
nested_dict = MAP_LITERAL( { "x", MAP_LITERAL( { "y", MAP_LITERAL( { "a", 10 } ) },
                                               { "z", MAP_LITERAL( { "b", 20 } ) } ) });

auto value1 = GetMapValue(simple_dict, "Hello");
std::cout << value1 << std::endl;

auto value2 = GetMapValue(nested_dict, "x", "y", "a");
std::cout << value2 << std::endl;

阅读剩余部分...