Category: Culture

Adium 一些工作与开源软件相关的思考

更新: 原来 MSN 群中使用 /showname 命令也可以控制这一点。

另外 Adium 其实是个非常好的开发群体，非常 active & helpful，只是项目庞大到了这样，bug tracker 里的 ticket 一多，开发者自己也很难保证代码结构足够好了。

因为最近开始使用 MSN 群 (1, 2)，但我使用的 MSN 客户端 Adium 并不能将群内发言人的身份显示出来，只能全部统一显示为群本身的名称。

其实这是 Adium 所使用的 IM 协议支持库 libpurple 在支持 MSN 协议上固有的缺陷 — 不过也不算特别严重的缺陷，因为 Windows 版本的 MSN 也只在 Windows Live Messenger 8 以上才支持，而 Mac OS X 下的 Microsoft Messenger 干脆到现在也不支持。

所以，要修复这个问题，必须从 libpurple 上打主意，然而，因为 libpurple 编译不便 (后面我会解释为什么这么说)，Adium 本身的代码仓库中只提供了编译好的 libpurple framework，编译这个 framework 的步骤则是分离出来的，要单独用 Utilities/dep-build-scripts 下面的脚本来完成。

可是问题变得越来越 tricky 了：为了编译 libpurple 的代码，必须下载整个 pidgin 的代码，但 pidgin 的代码又是用臭名卓著的 Monotone 来管理的，这直接导致下载当前代码的步骤就变得复杂无比，更不用说后面的编译了。

这还没有完，崩溃的是，Adium 虽然其他协议的支持都是直接从 libpurple 来的，但偏偏 MSN 协议最近改用了从 libpurple 中 fork 出来的 msn-pecan 项目，而 msn-pecan 又是用 git 来管理代码的……

这么一来，为了修改 MSN 协议支持并编译出 Adium，我们必须至少涉及三套版本管理系统 (Subversion, Monotone 和 git)，把 Adium 提供的一堆错综复杂的脚本找出来，让它先给 libpurple 打上 Adium 自己的 patch，然后分 ARCH 来生成 configure 并分别配置编译，最后合并成 Universal Binary 再 copy 回 Adium 的 Frameworks 目录去… 到这里我还没开始改一行代码呢！

虽然这个问题最终得到了解决，我提交的 patch 也将合并到 msn-pecan 官方的代码中去，可是这个经历仍然让我觉得颇有体会：

从 F/OSS 项目的贡献者来讲，要成功的参与项目，就必须掌握好常用的版本管理工具并了解基本的编译手段，才有机会参与到真正的代码修改中去。

而从 F/OSS 项目的发起和维护者来讲，要创造一个成功的项目，应该：

  1. 避免使用怪异的版本管理工具
  2. 编译步骤简单再简单，尽可能分解为可以单独执行调试的步骤，尽可能减少会在编译时出现的问题

随手翻译了一个 Colophon

Cover

[Linux System Programming](http://www.oreilly.com/catalog/9780596009588/) 封面上的图是在一个正在飞行机器上的人。早在莱特兄弟于 1903 年实现他们第一台“重于空气”的可控飞行器以前，世界上的许多人就已经在用简单而精致的机器探寻飞行的奥秘了。在二世纪或三世纪时，就有中国的诸葛亮在孔明灯中飞行的记录，这是第一个热气球。而在六至七世纪，许多中国人尝试将自己绑在大型的风筝上以在空气中飞行。

此外，据说中国还创造了会转动的玩具，它是直升机的早期版本，这个设计可能在莱昂纳多达芬奇对人类飞行进行早期尝试时给予了他灵感，而在 1845 年，他设计了一台扑翼机，一台试图通过展动翅膀载人于空中飞行的机器。尽管他从未将这台机器建造出来，扑翼机的鸟状结构影响了后续几个世纪对飞行器的设计。

绘于本书封面的这台飞行机器要比 James Means 在 1893 的模型飞行器更为精细，多出了螺旋桨。Means 后来给他的飞行器印制了一份使用手册，其中提到“于 Willard 山巅，Crawford 屋畔，觅一良所”来试验这台机器。

不过这类试验通常是很危险的，在十九世纪后期，Otto Lilienthal 建造了一些单翼机、双翼机和滑翔机，他是第一个展示出飞行是在人类可控的范围内的人，也因此获得了“飞行测试之父”的称号：他曾参与超过 2000 次滑翔机飞行，有时单次飞行距离就超过了一千英尺。他在 1896 年死于一次降落事故，在那次事故中他折断了脊椎。

飞行器还被称作机器鸟或飞行船，也偶尔会叫成人造信天翁 (Artificial Albatross) 这样华美的名字。人们对飞行器的热情现在依然高涨，直到今天还有航空爱好者在建造早期的飞行器。

封面图和章节题图来自 Dover Pictorial Archive。封面的字体是 Adobe ITC Garamond。正文字体是 Linotype Birka，标题字体是 Adobe Myriad Condensed，代码字体则是 LucasFont 的 TheSans Mono Condensed。

注：孔明灯的传说里并没有提到诸葛亮借此飞行，当为老外附会。

文档标记语言的一点思考

近来在水木上讨论文档标记语言的优劣，想起前些天查资料时正好又碰到了一个熟悉的名字: Scribe，于是多花了一点时间查找，没想到找到的资料仍然非常稀少。

Scribe，是 Brian Reid 在 Carnegie Mellon 的 Ph.D Thesis，也是对文档格式研究中所绕不开的一个重要的名字 (另一个，当然是 Don Knuth 的 TeX)，这个项目大概在 1976 年开始，1980 年 Reid 发表这篇 [Scribe: A Document Specification Language and its Compiler](http://portal.acm.org/citation.cfm?id=909923) 以后，就甚少有什么改进了，尽管 Reid 的论文中也研究了 Knuth 的工作，但可以认为 Scribe 和 TeX 是同时代的作品。从对后续文档格式的影响说，Scribe 还更大一点，我们熟悉的 SGML (XML 的前身)，BibTeX 都受了 Scribe 的影响。在 1982 年，Reid 还因为这一贡献 (Ground-breaking text-formatting language.) 获得了 [Grace Hopper Medal](http://hopl.murdoch.edu.au/showlanguage.prx?exp=2481)。

可是 Scribe 在应用上的成就却远远地被 TeX 所抛离，TeX 的生命力，被证明持久至今，而 Scribe 现在却在网上连一个正式的文档格式规范都找不到，一篇超过两页的详细描述都找不到！这是为什么呢？从 wikipedia 的文章中我们或许可以猜到一些隐情。

与 Knuth 慷慨地将 TeX 放入 public domain 不一样，1979 年 Reid 就把 Scribe 卖给了一个叫做 Unilogic 的公司，后来这个公司还持续和 Carnegie Mellon 大学就 Scribe 的知识产权问题扯皮，直到 CMU 放弃。最愚蠢的还不在这里，Scribe 居然在免费提供的 Scribe 程序中安插了后来被称为“time bomb”的东西，也就是说，90 天后如果用户不购买，这个软件就会执行自毁程序。

从 Scribe 如此猥琐的历史看，这个软件、这套格式最终为大众所抛弃，实在一点也不奇怪。

Helvetica: The Film

helvetica.png

这个 blog 的长期读者也许读过我翻译的 [The Scourge of Arial](http://blog.jjgod.org/2004/10/06/arial-ooo/) 一文，其中介绍了 Helvetica 的由来。而今年年初，看到 [Helvetica: The Film](http://www.helveticafilm.com/) 的公开，忍不住将它称做“[年度最期待纪录片](http://www3.newsmth.org/bbscon.php?bid=460&id=250597)”。

目前它已经在[欧美各处](http://www.helveticafilm.com/screenings.html)公映，却没有看到在中国的任何一处上映的计划，如果你能提供帮助：

If you work with a film festival, museum, cinema, or arts group and would like to organize a screening, please contact us via email: helvetica (at) swissdots.com

因为，[我们想看 Helvetica](http://hlb.yichi.org/blog/2007/05/02/162)，[我们不能错过它](http://lukhnos.org/blog/zh/archives/494)。

恩，打算写个连载

这个东东首发在水木社区的 TeX 版，反响还不错，就贴来大家一同讨论吧 🙂

谈谈 TeX 系统的构建过程，不过这个其实挺没意思的，如果只是用 TeX，而不打算修改 TeX 的代码的人完全不需要了解这个，我也不会涉及什么 TeXBook 里的内容，不知道有人有兴趣不？先贴一小段，要是大家有兴趣我就继续贴。呵呵，也算是一个开发了几十年的软件如何演化的一点掌故。

偶尔，你可能会突发奇想：平时自己用的这些 tex, latex, pdftex 是怎么来的？——是怎么写出来的，又是怎么编译出来的？

愿意究根问底的话，可以先自己动手试一试，目前可以工作的最小的 TeX 系统是 web2c，我们常用的发行版中的二进制程序，都是根据 web2c 中提供的代码，基本不作修改，或者只作很小修改编译而来的，所以，你可以先从 http://www.tug.org/ftp/tex/web2c.tar.gz 下载一份 web2c 的代码，解压开来，听我一步步的讲。

众所周知，Knuth 最早是在一台 DEC PDP-11 上用一种叫做 SAIL 的语言编写的 TeX，尔后他和一些合作者，开始在 Stanford 大学实验一种叫做 literate programming (文学编程) 的新式编程方法，他们设计了一套叫做 WEB 的系统，用 Pascal 语言来编写程序，用 TeX 来编写文档，将两者交织为一张“网”。

经过几年的不断修改，WEB 系统和 TeX 系统相互的影响下逐渐成熟，到 1982 年的时候，两者都基本上稳定下来，此时的 TeX 系统，核心就是一个 tex.web 文件。OK, 看看你刚刚解压出来的 web2c 目录下是不是有这么一个文件？那就是 Knuth 亲手写的，原封不动。

WEB 系统中有两个独立运行的程序，一个叫做 tangle (扰乱？) 一个叫 weave (编织？)，运行 tangle tex.web 将生成一个叫做 tex.p 的 Pascal 程序，这个程序可以用任何现代的 Pascal 编译器编译；而运行 weave tex.web 将生成 tex.tex，你可以用自己系统里已经安装的 tex 来 tex tex.tex 得到这个程序的文档：tex.dvi。

我相信很多人看到这里就会觉得相当无聊，那不妨认为你现在用的 TeX 系统就是这么来的句号。如果你坚持到现在还在继续看，那就可以接下去看更完整一点的故事。

Knuth 当时写着写着，居然写了一个三万多行代码的文件出来 (灌水王啊~) 这已经很恐怖了，可是后来大家要接着在他后边修改就很累了，他自己也得做 bug fix 不是？所以就给 WEB 系统添加了一个功能：合并主程序和 change file 的功能。

其实这个 change file，和我们现在常用的 diff 出来的 patch 结构也差不多，无非是原来代码的上下文，和要修改成的代码。比如在 tex.ch 里，你可以看到:

@x
原代码
@y
新代码
@z

这就是一个完整的修改单元。tangle 和 weave 都同时接受主程序和 change file 两个参数，将两者归并起来再行生成 Pascal 程序和 tex 文档，也就是说，实际的编译过程是这样的:

tangle tex.web tex.ch 得到 tex.p
weave tex.web tex.ch 得到 tex.tex

可是后来，Knuth 又说，TeX 这个程序应该 freeze 下来，大家不要再改了啊，想改，就换个名字，不要再叫做 tex 了。所以后来陆陆续续就出现 etex, omega, pdftex 等等增强版本，可是大家做这些增强版本的时候，也不好意思直接在 Knuth 的代码上改啊 (恩，大牛写的代码只能拜)，就纷纷创建自己的 change file。渐渐的 change file 就多了起来，比如 XeTeX, 要归并的 change file 有四五个之多，可是 tangle
和 weave 都只支持一个 change file 啊，于是就有人写了一个叫做 tie 的程序，专门做这种归并工作 (和 Larry Wall 写的 patch 一样)，你可以指定一个主文件和 9 个以内的 change file，按顺序一个一个归并起来。

所以我们看 etex 的编译过程 (在 etexdir/etex.mk 这个 Makefile 里可以看到)，就是先:

tie -m etex.web tex.web etex.ch etex.fix

得到 etex.web，然后 tangle etex.web 得到 etex.p 的。

可是 Knuth 开发 TeX 的那个时代 C 还没有获得大众 (OK，如果计算机科学家也算作大众的话) 的欢迎，也许因为 Knuth 本人和 Nicklaus Wirth 关系也比较铁，WEB 就优先选用了 Pascal 语言来编写 TeX，然而到了 90 年代，Pascal 渐渐退出了大家的视野，尤其在 Unix 系统下，C 更是金科玉律一般没有任何其他语言能替代，考虑到普及的原因，也考虑到方便与其他 C 语言编写的模块一同链接的原因，一班人开始考虑把 TeX 的代码转换为 C 的可能性，这就产生了 web2c。(web2c 一位长期的维护者 Karl Berry 就是现任 TUG 主席，也是 TeXLive 的主要维护者之一。)

最直接的办法就是把 tangle 后的 Pascal 代码转换为 C 代码，web2c 也正是如此设计的，毕竟 Knuth 当时为了保证尽可能的方便移植，几乎没有用到只有 Pascal 语言才有的特性，所涵盖的功能现代的 C 编译器
都已具备。所以他们采取的方法就是用 lex 和 yacc 写出了一个把 tangle 输出转换为 C 代码的程序。

那么，究竟应该如何调用 web2c 来生成 C 代码呢？生成出来的代码又该如何编译呢？且听下回分解。