经过四年的努力，最近终于拿到了计算机专业的学士学位和毕业证书……不容易啊，特别是对于像我这样的“差生”来说，呵呵。大家鼓励我一下吧！;)

这样一来，我的个人简历里就不用再写“expected to graduate in June, 2007”这样的话了，Yay!

今天晚上找到了Ubuntu下的一款极好的音频转换工具，叫做 Perl Audio Converter:

http://viiron.googlepages.com/screenshots

我已经成功地将 .ram 文件转换为了 .mp3 格式。它支持的格式实在太多，甚至可以将 .rm 视频文件转为 .mp3 音频。

不过安装不是那么直截了当。

wget http://linuxappfinder.com/debian/pool/main/p/pacpl/pacpl_3.3.1-1_i386.deb
sudo dpkg -i pacpl_3.3.1-1_i386.deb
sudo apt-get install libaudio-flac-header-perl
sudo apt-get -f install
sudo cpan MP4::Info Audio::APETags Audio::WMA MP3::Info

安装完毕之后，转换 .ram 至 .mp3 则通过下面这个命令：

pacpl --convertto mp3 *.ram

其他格式与之类似 ;)

YAPC::Beijing 2007 大会上拍的相片集:

http://yapc.org.cn/album-bin/index.pl

穿深绿色上衣正在做演讲的就是我啦，呵呵。

这是我和小林的合照:

http://yapc.org.cn/album-bin/index.pl?mode=view&photo=/dsc_0336.nef_01.jpg

可惜我那天胡子没刮，头发也没理……狼狈哦，呵呵

还有 Yahoo China 的朋友们以及 nomas：

http://www.yapc.org.cn/album-bin/index.pl?mode=view&photo=/dsc_0292.nef_01.jpg

2007-06-24

连夜用 Perl 6 的 Pod 赶好了我的 GNU make 类库的毕业论文，15 日下午便登上了前往北京的火车去参加 YAPC::Beijing 2007 大会－－带着 0 张幻灯片却申请了 2 场演讲！

第一次一个人出这么远的门，刚上火车的时候还真有些神经质，呵呵；脑袋里浮现出电影《天下无贼》中的画面……还好，我这一路上运气不好，没遇上那样的贼中高人。没过多久，我就被困倦打倒了，睡了一路。

16 日早上路过天津的时候确实有些伤感，但很快在杉哥的帮助下挺过去了，呵呵。

到了北京站，见着了 cnhackTNT（王晖）, hoowa（孙冰）, 和另一个叫做张建军的大连的朋友。一道打车去了东三环附近的百子湾路上的如家国贸店安顿了下来。这一路上，hoowa 说的都是他的 Asterisk 技术。可以通过 Perl 脚本向任何一部手机和任何一部固定电话打电话，并且能给接听方播放 mp3 文件。的确很酷哦！

我和 TNT 住一间，他们俩住一间。TNT 真是极好的人哪，得知我还是 0 张幻灯片以后，主动提出将他随身带过来的笔记本电脑借我使用。由于如家酒店提供了网线，再加上 TNT 的笔记本又是 ubuntu，幻灯片的制做过程非常地顺利……但却仍然用了一下午加上一晚上的时间……这是真正意义上的向唐凤学习－－JIT slide-making!

16 日在开始做幻灯之前，我和 TNT 去雅虎中国见了 nomas 和 yuting，并一起用了午餐。nomas 有些富态，非常和蔼可亲的人哦；而 yuting 则是不修边幅、踩着拖鞋啪哒啪哒的大男孩。

YAPC::Beijing 大会是在第二天，即 17 日在雅虎中国举行。早上过去就觉得身体很虚那种，因为前一晚上为做幻灯片的事情折腾到凌晨 4 点才睡下，然后早上 6 点多又起来了。TNT 也陪着我不睡觉，真是太对不起他了。

值 得一提的是，大会开始之前，我终于见到了孙磊(laye)。他专门为这次大会从上海赶过来。这一回算是我们的第一次见面，但我们在网上交流已经很久了。想 来也有趣，我和他最终是在一个叫做 xptop 的 C/C++ 论坛里认识的，后来一问才晓得，原来大家都是一个学校一个专业的！哈哈！另外，在会场上我还有幸遇见了 #perl6 频道里的 dolmans 并和他聊了不少。此前我一直以为他是德国人，呵呵，失误啊！dolmans 一直给我的是一种世外高人的感觉哦。

大会开始以后，第一 个 talk 就是我的"Contribute to Pugs"。当然又是一场激情四射的讲演了啊，呵呵。也算是代表唐凤和 Pugs 团队吧。听众的反响相当热烈。末后，fkiori（陈正伟），TNT，和传说中的小林当场向我提了几个很不错的问题。由于对 S12 的无知，fkiori 问的 Perl 6 中 protected 类型成员的声明记法我没有答上。TNT 问的有关 Pugs 与 parrot 等其他 Perl 6 相关项目的关系问题我早有准备。小林问的有关如何处理我的学业与 Pugs 团队开发之前的关系，回答起来也是颇有意趣的。演讲结束后，又有不少与会者私下问了我许多有关 Perl 6 和 Pugs 的问题，其中不乏"Perl 6 何时问世"这样的经典问题。我听到了有关 Perl 6 本身的唯一不满是，新的面向对象的记法"太像 Java 了"。这是真正的 Perl 5 程序员的反应，哈哈！

下午又听了 Joe, fkiori, 小林, hoowa 等高手的演讲。Joe 的演讲中提及的不少 DBI 相关的有趣模块我还是第一回听说，感觉很有收获。fkiori 的 P3P 也很有新意。小林提及的通用 Web 后台系统让我有一种想介绍 Jifty 的冲动，呵呵。hoowa 的演讲是最有个性的，现场演示用它的客户端程序拨通观众的手机－－一个字:帅！他的 Asterisk 模块看上去妙趣横生哦。 临近结束时我又作了一个有关 UML::Class::Simple 模块的闪电演讲。

最后大家一起合了影，开心哦，呵呵。我记得还见到了一个女性程序员，她说他们部门从主管到普通员工，很多都是女孩子－－实在是太强了！

晚上又和 PerlChina 的不少朋友在百子湾路上的一家小饭馆一起用了晚餐。认识了好几个新朋友。饭后回到如家，又听了三明治介绍他的精彩历史，听他讲"长发怪物"和"赤脚怪物"的离奇故事……

18 日起来，一个人逛了北京永安里、天安门和王府井等地方。觉得最有趣的还是永安里 LG 大厦附近的居民小区。在那里见着了北京的鸽子和猫咪哦。

19 日我就坐火车回来了。

感觉像记流水帐哦……没办法，想记录的事情太多，而我的汉语又有所退步……

P.S. 如果下一届 Audrey 能来，那可就更帅了哦，呵呵。

2007 年 6 月 13 日

Quoted from http://en.wikipedia.org/wiki/Parser_Grammar_Engine :

References

1. Michaud, Patrick R. (2004-11-22). Parrot Grammar Engine (PGE).
2. ^ Michaud, Patrick R. (2004-11-08). First public release of grammar engine.
3. ^ "Agent Zhang" (2006-09-17). PCR replaces PGE in Pugs.

Huh, I posted the article "PCR replaces PGE in Pugs" to Audrey's blog site about one year ago:

http://pugs.blogs.com/pugs/2006/09/pcr_replaces_pg.html

Hey, it's really exciting. Yay!

2007 年 6 月 13 日

今天填了一些表格，需要写自我鉴定和个人小结之类的东西。想想把我写的发给大家看看也蛮有趣的，呵呵。全文如下：

经过四年的学习，终于顺利完成了大学里那些数量众多同时难度颇深的课程的学习，并自学了许多课外的知识和技能。

对 我来说，学校能教给我的东西是极为有限的。更多地，学校扮演着这样的一个角色：她为我提供一个学习、思考和实践的平台，是我大量地积累知识和技术的主要推 动力之一，她为我创造了许多软件项目和科学研究的原始需求和灵感源泉，同时也为我提供了极为丰富的图书资源。说实话，四年来，学校的课程对我的不间断的巨 大压力迫使着我不断地攀登技术高峰，不断地补充自己在众多不同领域的基础知识，不断地完成越来越复杂、越来越重要的项目和课题。

相信与 否？我大学中最重要的时光是在英特网上度过的。和身边许多同学在网络游戏中沉沦不同的是，我积极地参与到了国际 Perl 编程社区的活动中，投身到了包括 Pugs 和 Jifty 在内的开源软件项目的开发工作中，与包括 Audrey Tang , Larry Wall, Adam Kennedy, Luke Palmer 在内的许多世界知名的程序员进行过比较深入的交流，并建立起良好的关系。

我 与世界各地的程序员保持着广泛的沟通与联系，甚至进行协同开发。从他们身上，我学到了太多太多。我学到的不仅仅是许多具体的技术和技巧，还包括他们的似火 般的热情，绅士般的风度，朋友般的友善、君子般的谦逊……更重要的是他们面对问题、处理问题和解决问题时的发散式、跳跃式的思维方法，以及一丝不苟、一切 务实的行事原则。当然，还有英语表达上的许多技巧。在这种场合下，我才发现原来熟悉英语是一件非常幸福的事情。和不同国家、不同肤色的志同道合的朋友无障 碍地交流，细细想来，还真是一件不可思议的事情，呵呵。

我这个人喜欢体验创新，喜欢冒险，喜欢不断尝试各种有趣而新奇的想法和事物。我也 喜欢一个人静静地坐在图书馆里潜心阅读计算、数学、物理、生物、化学和历史方面的英文原著，抑或是坐在风和日丽的山头，思索科学和人生中一些有趣而重要的 问题，或者和大学和中学里结交的好朋友们呆在一起，畅所欲言，天马行空，热烈地讨论技术和科学中已经发生的、正在发生的、和将要发生的那些不可思议的事 情……

2007 年 6 月 12 日

由于前面为实现 Makefile "脱糖" 程序 makesimple，我为我的 pgmake-db 程序添加了 --question (-q) 和 --always-make (-B) 选项，并在 Makefile::AST::Evaluator 中提供了相应的支持，与此同时还修复了隐式规则搜索算法的实现代码中的两处严重的 bug。这些改进最终使得我的 pgmake-db 对官方测试集的通过率首次超过了 50%. 万岁！

事实上，以目前 AST 和运行时的架构，完全足以通过 90% 以上的官方测试集，只不过不少小东西还需要花时间去打磨。只要给我满满一周的时间，我有信心让它达到 90% 以上。但目前条件并不具备。

从目前的实现出发，可以开发出许多很酷的应用。关键就看我们的想象力了。我的 makesimple 脚本已经掀开了从 GNU makefile 到其他格式的项目配置文件的序幕。事实上，makesimple 程序最终将演化为"传说"中的 Makefile::Compiler 模块中的一个部分。呵呵。

将当前 pgmake-db 借用的 GNU make 前端 Makefile::Parser::GmakeDB 模块替换为纯 Perl 实现（即未来的 Makefile::Parser::Gmake 模块）也可以推动 DOM parser 的开发工作，特别是提高我整个工具链的可移植性和整体可靠性。与此同时，纯 Perl 的 GNU make 工具链，有助于横向上开发其他种类的 makefile 的工具链，比如 MS nmake 的从 DOM 到 AST 再到 Evaluator 的工具链。届时，项目的可复用性、开放性和灵活性将超过我目前的想象能力，呵呵。

Alas, time is always a problem :(

.oO( 论文...论文...论文... )

2007 年 6 月 12 日

或许我真的应该开始写论文了，但我还是忍不住实现了一个 GNU makefile 的翻译程序makesimple：

http://svn.openfoundry.org/makefileparser/branches/gmake-db/script/makesimple

该程序能将非常复杂的 GNU makefile 转换成最最基本的形式，即所谓的"简单makefile"。

"简单makefile"中只有单目标的显式规则，没有变量赋值，没有变量引用，没有条件指令，没有模式规则，没有所有其他看上去"高级"的东西。因此它可以不加修改地为其他版本的 make 正确处理，比如 nmake 和 dmake.

而作为输入的 makefile 则可以使用GNU make手册中描述的绝大部分的高级特性，包括

• 多目标规则 (multi-target rules)
• 双冒号规则 (double-colon rules)
• 隐式规则 (implicit rules/pattern rules)
• 链式隐式规则 (chained implicit rules)
• 静态模式规则 (static pattern rules)
• 仅顺序依项目 (order-only prerequisites)
• 自动变量 (automatic variables)
• 目标局部变量 (target-specific variables)
• 由 define 指令定义的逐字句变量 (verbatim variables)
• 简单展开变量 (simply-expanded variables)
• 递归展开变量 (recursively-expanded variables)
• 命令序列束(canned sequence of commands)
• 命令修饰符 @, - 和 +
• 利用续行符 ("\\\n") 跨越多行的命令 (commands spanning multiple lines)
• 绝大多数内建函数引用 (built-in function references)
• 条件指令 ifdef/else/...

详情请见下面这个测试文件中的测试用例（只需看 __DATA__ 那行之后的内容就可以了）：

http://svn.openfoundry.org/makefileparser/branches/gmake-db/t/makesimple.t

另外 include 指令和其他词法/语法层面上的特性也应该工作得很好，因为那是前端提供的"免费功能"，呵呵。

这些特性都是我的 Makefile::AST 和 Makefile::AST::Evaluator 模块提供的实现。我的 makesimple 脚本只是利用了 Class::Trait 模块，在 Makefile::AST::Evaluator::make_by_rule 方法里定义的锚点位置上，把 Makefile::AST::Rule 对象和对应的 Makefile::AST::Command 对象全部记录下来。 Class::Trait 简直就是天赐之物，实在想不出能让我的 Evaluator 代码保持整洁，同时又提供给用户应用足够大的灵活性的更理想的解决方案了！难怪 Jesse 会在 Jifty 项目中大力推动该模块的应用呢。

目前 makesimple 脚本会自动轮询 makefile 中所有出现的目标，而且用户可以在命令行上指定额外的目标。额外的目标对于隐式规则的应用而言至关重要，毕竟 GNU make 中有太多的"魔法"。

Audrey 的 Module::Install 模块生成的庞大的 GNU makefile，经过 makesimple 转换后，仍然工作得很好。这是第一个现实世界中的测试用例啊。

makefilesimple 在翻译时会保持"默认目标" (default goal)，包括用 .DEFAULT_GOAL 显式指定的默认目标以及出现在输入 makefile 中的第一个非隐式规则的目标。默认目标如果对应一个双冒号规则集 (set of double-colon rules)，也能正确地处理 :)

makesimple 的 TODO:

• 对用户显式指定的某些变量不进行第二 次遍历 (the second pass) 中的展开操作，除非它是某个 GNU make 内建函数的参数，代之以变量赋值语句，从而提高“简单makefile”的灵活性，这样使用翻译版本的最终用户可以自己修改这些变量的值，比如 CC和CFLAGS 这样的变量就经常需要自己进行调整。但是，第一次遍历过程中的变量展开操作必须进行，否则解析器很可能无法继续。
• 对用户显式指定的某些变量的某些取值进行轮询，并将由此得到的不同版本的"简单makefile"作为一个一个的代码块，填进"目标 make"支持的条件语句中。（这让我想起"程序设计方法学"中结构化程序的正确性证明中用到的"分支展开"技术，呵呵）
• order-only 依赖项需要更理想的翻译方法，目前是直译。
• 提供 shell 命令翻译的解决方案。可以尝试类似 sh ==> cmd 这样的自动转换，以及类似国际化支持中的用户自定义翻译。（见 Locale::Maketext 模块。）

正如你可能已经猜到的，makesimple 脚本就是“传说中的” Makefile::Compiler 模块的一个原型实现！Come on!

与 makesimple 相似的另一个有趣的应用就是在全新的 makefile AST 和 Evaluator 的基础上改写我从前发布在 CPAN 上的 Makefile::GraphViz 模块。现在从任意复杂的 GNU makefile 生成依赖图的 PNG 图片已经是很容易很容易的一件事情了！

毕竟依赖关系示意图本质上只是"简单makefile"的另一种表示形式而已，技术上实现起来极为类似，呵呵。

但现在－－论文高于一切！

2007 年 6 月 12 日

Found today on Perl.com:

CPAN Module Review: Pod::POM::Web

For years, my schoolmates and I have been relying heavily on my "viewpod" script based on Catalyst (Yes, search.cpan.org is slow and way too scattered!). Now there is a better alternative.

I've given it a shot in my ubuntu box and it's *really* impressive. Not sure about its Win32 compatibility though. Reports welcome ;)

2007 年 6 月 11 日

昨天经过好几个小时的努力，终于完成了GNU make官方测试集到我的基于 Test::Base 的 测试台的自动转换程序p4_to_t.pl：

http://svn.openfoundry.org/mdom/branches/gmake/script/p4_to_t.pl

哇， 440 行Perl 5代码耶，比我想象得长多了，也比我想象得复杂多了……但它也比我想象得有用多了！该脚本已将官方测试集中所有的用Perl 4写成的测试脚本转换成了对应的 .t 文件，并且其中有 70% 以上的 .t 文件完全通过了GNU make程序的测试。

其基本原理如下：

1. 使用 PPI 模块解析Perl 4测试文件，提取出其中的 Perl 注释（不包括makefile注释！），并将之替换成函数调用形式。比如原文件中的

# Test #1: Test the order-only prerequisites

将被识别并替换成下面这一行：

comment("# Test #1: Test the order-only prerequisites");

其目的在于在翻译后的 .t 文件中也能保留原始文件中的这些注释。而一般情况下Perl注释是无法流过perl解释器的，除非使用source filter. 但source filter本质上也需要对这些注释进行识别和提取。

值得一提的是，由于 PPI 的当前版本不能处理下面这种形式的 Perl heredoc

print MAKEFILE <<\EOF;
all: ; @echo hello
EOF

所以在把Perl 4源代码喂给 PPI 之前需要用正则替换把上面这几行预处理为下面这种等价形式：

print MAKEFILE <<'EOF';
all: ; @echo hello
EOF

我昨天已经发了一封 email 给 PPI 的作者 Alias，报告了该问题。

2. 给经过注释转换的Perl 4文件加上一个文件头，在这个文件头中提供了GNU make测试驱动提供的那些工具函数的mocking版本，主要包括： rmfiles, utouch, touch, run_make_with_options, compare_output, 和 run_make_test. 同时还需要 mock 一下测试文件可能调用到的"Perl内建函数"和Perl标准模块，比如 unlink和Cwd. Mocking像Cwd这样的Perl模块，我用到了Test::MockClass模块。

这 些mocking版本的函数的功能主是让原始的Perl 4测试脚本"感觉"自己好像运行在了GNU make官方的测试平台上，但事实上，我的这些函数根本不执行任何测试动作，而是记录下所有的调用历史，特别是参数和上下文变量的值，然后生成一个与 Test::Base 块/段结构相应的数据结构。

另外，还需要定义一下测试文件所需的配置变量，比如$mkpath, $make_name, $makefile, $delete_command等等。

文件头中还包括了一个 END 块，用于在测试脚本退出时，从采集到的数据结构生成 Test::Base 格式的 .t 源代码。

3. 通过 IPC::Run3 模块将进行修改的Perl测试脚本喂给perl解释器执行之，并将它的 stdout 输出采集起来，写入到 .t 文件。

由于官方测试集的格式相当整齐（请参考GNU make团队成员所使用的 测试文件模板），所以绝大多数的的测试用例都可以完美地翻译过来，而且质量可以与我手工翻译的质量相媲美。但也有两方面的限制：

1. 原始测试用例都是上下文有关的，而我的基于 Test::Base 的测试用例都是上下文无关的，即前一个测试的结果和环境不会影响到下一个测试。虽然 p4_to_t.pl 脚本采用了许多技巧自动跟踪和隔离上下文信息，但难免会有一些特殊情况无法跟踪到。

2. 如果一个测试用例涉及多个 makefile，则无法正确翻译－－事实上此时手工翻译都需要动一翻脑筋的。

最后欣赏一下直接由p4_to_t.pl脚本生成的全新版的测试集吧（未经过任何手工编辑）：

http://svn.openfoundry.org/mdom/branches/gmake/mech_t/

呵呵 :)

2007 年 6 月 10 日

LOL. From the page "tools useful for A-A-P" :

          Ant

Java based build tool, like make, but uses classes and XML. Portable over systems, but requires Java.
Writing a build file in XML file is clumsy. XML is nice for computers to parse and produce, not for humans. Flow control is even more clumsy, XML is not a scripting language.
Can be used for ideas how recipes work.

Well, I must say I totally agree but I won't try to advocate make against Ant to those conservative Java programmers ;)

And...make *can* be evil, but not necessary, just like Perl. It depends on the monkeys who are using them, not on the language or the tool itself :)

So, take care...

2007 年 6 月 10 日

过 去的一周集中了几乎所有力量于 pgmake-db 的开发，修复了 DOM 解析器、GmakeDB AST 构建器，AST，和 AST 执行器(runtime) 中的许多 bugs，包括那个曾经让我非常头疼的 double-colon 测试（即 Savannah bug #14334），并且在各个组件中实现了许多重要的 GNU make 特性，包括：

* Pattern rules
* Target-specific rules
* Order-only prerequisites and normal prerequisites
* Phony targets

* Canned sequence of commands
* Command modifiers '@' and '-' and their various combinations
* Line-continuations ("\\\n") in commands

* Automatic variables $@, $<, $^, $*, $|, and $+
* Verbatim variables defined by the 'define' directive
* Simply-expanded variables and recursively expanded variables
* Most of the builtin function references

* -f --file --makefile command line option
* -n --just-print --dry-run --recon command line option
* -s --silent --quiet command line option
* -i --ignore-errors command line option

* Circular dependency checking

还有许多特性是我复用的 GNU make 前端"免费"提供给我的 pgmake-db 的：

* Syntax issues like variations of comments, line-continuations outside commands
* Variable overridding by the override directive
* Variable overridding by the command-line variables
* Conditional directives like ifdef/ifeq
* Global makefile variable assignment using '+=', '?=', and redefining

目前已知 GNU make 的数据库输出功能（）存在下列 bugs:

* Savannah bug #20067: Unescaped meta characters in makefile database outputs
* Savannah bug #20069: Request for unexport/export info in makefile database outputs
* Savannah bug #20133: 'make -p' always uses ':=' for pattern-specific variable assignments
* Continued commands' leading whitespaces are missing in the DB output

这 些 bugs 使得至少 export/unexport 和 Pattern-specific variable assignment 这两个特性无法实现，阻止了官方测试集中对应的那 2 个测试文件的通过（即 features/export 和 features/patspecific_vars)。

目前 GNU make 官方测试集已通过近一半的测试用例（约48%），其中完全通过的测试文件列表如下（共 36 个文件）：

features/comments
features/conditionals
features/default_names
features/double_colon
features/echoing
features/errors
features/escape
features/include
features/mult_rules
features/mult_targets
features/order_only
features/override
features/patternrules
features/quoting
features/varnesting
features/vpath2
features/vpathgpath
functions/abspath
functions/addprefix
functions/addsuffix
functions/basename
functions/dir
functions/filter-out
functions/findstring
functions/join
functions/notdir
functions/realpath
functions/substitution
functions/wildcard
targets/PHONY
targets/clean
variables/CURDIR
variables/MAKEFILES
variables/MFILE_LIST
variables/negative
variables/special

事 实上，functions/, variables/, 和 targets/ 目录下的不少失败的测试，稍加调整就可以通过，但目前那些测试尚未导入到我的基于 t::Gmake 的测试台中，故还需要先编写一个自动转换程序。（该程序昨天上午的时候已经在学校图书馆里打好草稿了，呵呵。）

我自己现有的基于 t::Gmake 的测试集的文件通过率已达到 90% 以上，只有 3 个测试文件失败了，而且其中有两个文件还是因为 GNU make 的 bugs，而不是我的问题 :)

现在剩下的时间真的不多了……必须得赶快开始写毕业论文了……我晕……今天打算把那个测试集升迁程序准备好，把官方测试集中余下的测试导入到我的测试台中，然后把那些本该通过却未通过的测试调通，这样不费多少气力，就可以进一步地提高测试通过率。

其 实现在从我的 Makefile::Parser::GmakeDB 构造的 AST 出发，结合 Makefile::AST::Evaluator 中的算法，已经可以开发出许多非常有趣的应用了，比如从任意复杂度的 GNU makefile 生成最最简单的只含简单规则的"基本 Makefile"，从而可以为所有其他版本的 make 正确处理，再比如利用类似的技术生成其他非 make 构建工具的配置文件，如 Ant 和 PBS。另一个例子就是全新版的 Makefile::GraphViz 了，从任意复杂度的 GNU makefile 生成拓朴树的示意图。

这些应用看起来好像很复杂，但其实从现有的 pgmake-db 各个环节的代码出发，只需要几十行代码就可以搞定！

可是……我现在缺的只有时间！

P.S. 毕业论文就用 Perl 6 的 POD 来制作吧！该是在我自己的工作中实用一下 Damian 的 Perl6::Perldoc 模块的时候了！耶！

2007年6月5日

今天在 CPANTS 的 Kwalitee 排名列表中看到自己的 CPAN ID AGENT 已是第 45 名了：

2007 年 6 月 5 日

昨 天我继续以测试驱动（TDD）方式完善我的基于 Makefile::Parser::GmakeDB 的 pgmake-db 程序，结果在调试 GNU make 官方测试集中的 features/escape.t 和 features/export.t 的时候遇到了 GNU make 的 database 输出支持上的两个 bug.

一是 gmake 在输出的 makefile 语法的数据库列表中没有对目标和依赖项中的元字符进行转义，比如 :, \, 和 #. 该 bug 已作为 Savannah bug #20067 报告给了 GNU make 团队。先前我还另外发了一封 email 到 bug-make 邮件组：

http://www.mail-archive.com/bug-make@gnu.org/msg04650.html

从 GNU make 的“看门人” Paul Smith 的回复中可以看到，没有多少人会将 `make -pq` 命令的输出喂给其他程序（包括 gmake 自己），因此其记法上的合法性并没有经过很好的测试。

该问题在 gmake 那边尚未修复，我已在本地通过预处理 db 输出的方法绕开了这个 bug.

二 是 gmake 生成的 db 输出中缺少 export/unexport 指令的信息，这使得 GmakeDB 模块构造的 AST 亦缺少这样的信息，从而使得 features/export।t 测试文件暂时无法通过。更糟糕的是没有简单的方法能绕开它。该问题我已经以 Savannah bug #20069 的形式报告给了 GNU make 团队，目前尚无回复。

除 了和 GNU make 的限制角力之外，我还修复了 pgmake-db 中的一些小问题，从而使 Makefile::DOM 的 gmake 分支中基于 t::Gmake 的测试集的（文件）通过率从 50% 提高到了 60% ~ 70%.余下的拦路虎是 features/order_only.t 所需的 order only prepreqs 支持和 features/override.t 所需的 Canned Command Sequences 和 Defining Variables Verbatim 支持。这些改动都比较大，所以最好还是放到学校图书馆去构思吧，呵呵。

另外，features/double_colon.t 中还有一个测试在前天跳过了，即 Savannah bug #14334，该行为实现起来相当有难度，但我已想到了一种解决的方法，即该 bug thread 中所说的"postponing this timestamp propagation until after all individual rules have been updated ".

昨 天晚上我还 checkout 了一下 GNU make 的 CVS 源代码仓库，并想办法让官方测试集能运行我的 pgmake-db. 经过一番努力，终于得到了 35% 的测试通过率。由于官方测试集使用的是 Perl 4 代码，根本未利用现代 Perl 5 基于 Test::More 的测试台技术，所以它并不适合我进行 TDD. 而且所有的测试脚本都运行在和测试台 Harness 相同的进程中，导致 ulimit 在杀死挂起的测试脚本的同时也杀死了测试台 Harness，从而得不到最后的测试报表。现在已知 features/patternrules.t 会限入死递归，并吃掉所有内存，另外 functions/sort.t 也很占用 CPU 时间。这些都有待于后续工作来修复。

目前官方测试集仅有不到一半的用例移植到了我的基于 t::Gmake 的测试平台上。这些还是从前我手工进行转换的。昨天晚上我终于想到了一种非常巧妙的自动转换方法，即利用 mocking 的方法运行那些用 Perl 4 写成的官方测试集脚本，从而采集到所有数据，并生成 Test::Base 的声明性的用例格式。该方法的优点是可靠、安全、快速，同时也非常容易实现。原先我考虑的转换方法是去解析那些 Perl 4 代码。显然即便是 Perl 4，其语法也是相当复杂的（使用 PPI 也需要许多代码），至于其语义分析那就更加困难了。

通 过 mocking 工具函数运行待解析代码，来提取所需信息的技术很像 Perl DSL(Domain Specific Language)，比如 CPAN 上的 Template::Declare 和 Object::Declare 模块就是"借用" Perl 语言来生成 HTML 或者其他东西。很有些"借尸还魂"的味道哦。借用现有的 Perl 语言或者 Perl 解释器可以大大减少对自定义编译器的需求。无论如何，编写一个解析器都不是轻而易举的事情。

所有这些有趣的东东都打算今天在图书馆里搞出来。祝我自己好运啦 :)

P.S. 发送 email 的同时亦能发表博客文章，实在太帅，呵呵。

2007年6月4日

毕业论文交稿日期在即，而我还在努力奋斗，呵呵。

几天前刚刚发布了通用事情仿真引擎 Sim 到 CPAN：

http://search.cpan.org/dist/Sim

可惜与我的毕业设计并无直接关系。

这 两日我正工作在从 GNU make 生成的 makefile 数据库列表解析生成 makefile AST 的 Makefile::Parser::GmakeDB 以及 AST 库 Makefile::AST 和 makefile 运行时（即 AST 的执行器） Makefile::AST::Evaluator.

从最高的尺度上讲，它是一个 gmake 和我的 Makefile 库所组成的``混血儿''。后端借用了 GNU make 的 C 实现，完成绝大部分的词法分析和词法分析的任务，以及在那个阶段上完成的执行动作；后端从 AST 开始一直到运行时，都是我自己的 Perl 代码。中间的对接复用了我的那个``不怎么好的'' Makefile 解析器，即 Makefile::DOM，外加一些 AST 构造代码，这便构成了 Makefile::Parser::GmakeDB. 所有部分合在一起便是一个比较完整的 make 工具（我已将之命名为 pgmake-db）。

我现在正以测试驱动（TDD）方式不断完善 pgmake-db 脚本及相关组件，特别是 AST 的设计及 AST 以后的运行时实现。到写这封邮件的时候为止，我已让 pgmake-db 通过了 50% 以上的 gmake 测试集：

http://svn.openfoundry.org/mdom/branches/gmake/t/gmake/

Makefile::Parser::GmakeDB, Makefile::AST, 和 Makefile::AST::Evaluator 的源代码（gmake-db分支）都位于下面这个位置：

http://svn.openfoundry.org/makefileparser/branches/gmake-db/

Makefile::DOM （gmake分支）的源代码位于：

http://svn.openfoundry.org/mdom/branches/gmake/

短期目标

• 在未来几天中，让 pgmake-db 程序通过 GNU make 90% 以上的测试集（并将官方测试集中未移植到 Test::Base + IPC::Run3 测试台的部分移植过来）。这样就可以得到比较完美的 AST 及 Evaluator 部件了。

• 在 未来两周中对 Makefile::DOM 进行改写，并在之基础上开发 Makefile::Parser::Gmake（可借鉴 Makefile::Parser::GmakeDB 的一些代码和算法），从而能取代 Makefile::Parser::GmakeDB 而与 AST 及运行时后端实现对接。

长期目标

• 以全新的 AST 和 Evaluator 为基础改写 Makefile::GraphViz 模块，从而使之趋近``完美''

• 从全新的 AST 出发，发射 NMAKE, PerlBuildSystem 格式的配置代码。

• 从 DOM 出发，发射``地道而无损的'' NMAKE, PerlBuildSystem 格式的配置代码

• 为 Makefile::DOM, Makefile::Parser 以及其他后端部件添加对其他格式的 makefile 的支持（如 NMAKE, BSD make, 和 dmake）

• 尝试将 NMAKE 格式的 makefile 翻译到 GNU make 格式

短期目标希望能在答辩之前完成，并写进我的毕业论文。长期目标目前看来只能放到毕业之后继续了，呵呵。

唉……这学期大部分时间都放在考试复习、找工作和其他的事情上了……所以现在时间紧得不得了。

我心爱的 agentzh.blogspot.com 被 GFW 掉之后，无奈之下我又回来了。

人生就是这样充满了无奈……

今天 live.com 慢得直接就点不进去，一气之下，决定搬家 :)

如今我的博客已搬到了 Google 的 Blogger 上了：

http://agentzh.blogspot.com

呵呵，网址比原来用的那个 agentzh.spaces.live.com 还要短一些，耶，好棒！

而且 Blogger 响应很快，功能丰富，比如支持直接通过电子邮件发表文章，有人发表评论时会自动发送电子邮件提醒我，另外允许匿名访问者发表评论，模板也觉得很漂亮，呵呵。

我已经通过 email 将这个 live.com 博客中有点儿价值的文章都导入到那个新的主页上去了。欢迎继续关注和发表评论！谢谢！

大家可以通过 http://agentzh.blogspot.com/feeds/posts/default 在你最喜爱的 RSS 阅读器（比如 Google Reader中）订阅我的新博客 :)

（说实话，我不太理解为什么身边有这么多朋友使用 live.com……受不了……）