03 March 2005

Apocalypse: 启示录
block: 块
concatenation: 串联
context: 语境,上下文
context-sensitive: 上下文相关的
lexical scope: 词法作用域
interpolation: 内插
migration: 移植
multiple dispatch: 多重分派
namespace: 命名空间
overloading: 重载
verview: 概述
routine: 例程
statement: 语句
synopsis: 纲要
scope: 作用域

在 Win32 下安装 Bugzilla

03 March 2005

Bugzilla 是由 Perl 编写的 bug tracing 系统。
我一向对大型 Perl Script 非常着迷,认为读懂它们会让人受益匪浅。所以下了寒假出的版本试着安装了下。
sf.net 那有 Bugzilla 的汉化版,因为我只是想看源代码所以就下了原版。
Env: Win2000(SP4)+Apache/2.0.50+Perl/v5.8.4+MySQL/4.1.7
Bugzilla version: 2.18

Step by Step

  1. http://www.bugzilla.org/download/ 下载 Stable Release.
  2. 解压缩到安装目录( eg, E:\Fayland\bugzilla ),阅读 QUICKSTART
  3. 运行 cmd 或用 phpMyAdmin, 来建造数据库 bugs 和用户 bugs/bugs
    C:\mysql\bin>mysql -u root
    mysql>create database bugs;
  4. 运行 cmd
    E:\Fayland\bugzilla>perl checksetup.pl
    • 此脚本第一件要做的是检查依存模块是否存在,版本号是否够新。如果不存在或不够新就需要安装新的。像我就安装了 Date::Format, Chart::Base, PatchReader. 其中 cpan Date::Format 还提示找不到,只好到 http://search.cpan.org 搜索来安装了下。
    • 第一次运行后安装目录下会生成 localconfig 文件,可用记事本打开。我设置了如下东西:
      $db_pass = 'bugs';
    • 再一次运行checksetup.pl, 脚本将检测是否可以连接数据库。如果连接成功将建立一些数据表,不成功的话重新改 localconfig 或调试 mysql.
    • 数据表建立后会让你设置 admin account, 输入 email 和 password, OK.
  5. perl checksetup.pl 完全成功后,配制 Apache 的 httpd.conf
    # bugzilla
    Alias /bugzilla "E:/Fayland/bugzilla/"
    <Directory "E:/Fayland/bugzilla/">
    	Options +ExecCGI
    	AllowOverride Limit 
    	DirectoryIndex index.cgi
    	AddHandler cgi-script .cgi
  6. 打开 Firefox 或 IE, http://localhost/bugzilla/. 出现界面后,Log in, 然后设置参数/Parameters
    urlbase = http://localhost/bugzilla/
    cookiepath = /bugzilla/
    sendmailnow = off
    因为我没 sendmail, 所以把 sendmailnow 设置为 off.
    参数设置的左边都有个 Reset, 是恢复到默认设置的意思。



XML-PRC Client 客户端编写

02 March 2005

暑假里看了些XML的书,fund.perlchina 又出了个 xml-rpc 接口,便想着用 perl 做个客户端试试。

xml-rpc Server 结构介绍

因为 hoowa 在忙着编写 fund.perl 的 xml-rpc 的第二版, 而当我连接 http://fund.perlchina.org/archive/poda.php 并调用 archive.index 时总返回“404 Not Found”。想着当 hoowa 完成时再写连接 fund.perl 的代码。

http://www.xml-rpc.com 找了个 XML-RPC interface. 地址为:http://xmlrpc.scripting.com/discuss/msgReader$2014

是 Weblogs.Com 的 XML-RPC 接口。大致的结构如下:

url: http://rpc.weblogs.com/RPC2
method: weblogUpdates.ping (weblogname, weblogurl, changesurl=weblogurl, categoryname="none") returns struct
我们的例子为调用 weblogUpdates.ping, 'Scripting News', 'http://www.scripting.com/'
返回值取其中的 message = 'Thanks for the ping.' or 'Thanks for the ping, however we can only accept one ping every half-hour.'


use Frontier::Client;

my $url = 'http://rpc.weblogs.com/RPC2';

my $client = Frontier::Client->new(
    url => $url,
    debug => 1,
# Call the remote server and get our result.
my $result = $client->call('weblogUpdates.ping', 'Scripting News', 'http://www.scripting.com/');

print $result->{'message'};
http://www-900.ibm.com/developerWorks/cn/webservices/ws-xpc1/index.shtml (中文)
perldoc Frontier::Client


my $cli = RPC::XML::Client->new('http://rpc.weblogs.com/RPC2');

my $request = RPC::XML::request->new('weblogUpdates.ping', 'Scripting News', 'http://www.scripting.com/');

my $response = $cli->simple_request($request);

if (!$response) {
    print "$RPC::XML::ERROR \n"; # No response
else {
    print $response->{'message'};


use XMLRPC::Lite;

my $result =  XMLRPC::Lite
      -> proxy('http://rpc.weblogs.com/RPC2')
      -> call('weblogUpdates.ping', 'Scripting News', 'http://www.scripting.com/')
      -> result;

print $result->{'message'};
perldoc XMLPRC::Lite

Further References

Add @ 2005/3/3

问了问 hoowa fund.perlchina 的 xml-rpc 接口,他给了我一段样例。原来是地址错了,挂不得总是回 404 Not Found.
use XMLRPC::Lite;

my $rpc = 'http://fund.perlchina.org/archive/poa.php';

my $client=XMLRPC::Lite->new();
my $archive= $client->call('archive.getindex'=>{order=>'1',limit=>'11'})->result;

foreach (@{$archive}) {
    my %result = %{$_};
    print $result{'title'}, "\n";

Apocalypse RFC 005

02 March 2005

    RFC  PSA  Title
    ---  ---  -----
    005  cdr  Multiline Comments for Perl(为 Perl 增加多行注释)

RFC 005 : 为 Perl 增加多行注释 / Multiline Comments for Perl

I admit to being prejudiced on this one -- I was unduly influenced at a tender age by the rationale for the design of Ada, which made a good case, I thought, for leaving multiline comments out of the language.

我承认我对此怀有偏见——在幼年时 Ada 设计的基本原理过度地影响了我,不过我认为这是件好事,语言中就不该有多行注释。

But even if I weren't blindly prejudiced, I suspect I'd look at the psychology of the thing, and notice that much of the time, even in languages that have multiline comments, people nevertheless tend to use them like this:


     *  Natter, natter, natter.
     *  Gromish, gromish, gromish.
The counterargument to that is, of course, that people don't always do that in C, so why should they have to do it in Perl? And if there were no other way to do multiline comments in Perl, they'd have a stronger case. But there already is another way, albeit one rejected by this RFC as "a workaround."

当然,相反的意见认为人们在 C 中并非总是这么做的,为何在 Perl 里必须得这么做? 如果 Perl 中没有其他方式进行多行注释,那这是个问题。但是我们已经有一个了,虽然有人在这个 RFC 中以它是个“工作区/a workaround”而抵制它。

But it seems to me that, rather than adding another kind of comment or trying to make something that looks like code behave like a comment, the solution is simply to fix whatever is wrong with POD so that its use for commenting can no longer be considered a workaround. Actual design of POD can be put off till Apocalypse 26, but we can speculate at this point that the rules for switching back and forth between POD and Perl are suboptimal for use in comments. If so, then it's likely that in Perl 6 we'll have a rule like this: If a =begin MUMBLE transitions from Perl to POD mode then the corresponding =end MUMBLE should transition back (without a =cut directive).

但是我个人以为,与其加入另一种注释方式或是搞些表现得象注释的代码,还不如修复 POD 的任何错误,让它可以注释且又不会被人认为是个工作区。对 POD 的真正设计将知道启示录 26 时才会出现,但我们可以在此推测出,在 POD 和 Perl 中换来换去对于注释并不是很理想。假如这样的话,在 Perl 6 中我们或许会这么做:=begin MUMBLE 表示 Perl 转为 POD 模式,而相对应的 =end MUMBLE 则转回来。(不使用指令符 =cut )

Note that we haven't defined our MUMBLEs yet, but they can be set up to let our program have any sort of programmatic access to the data that we desire. For instance, it is likely that comments of this kind could be tied in with some sort of literate (or at least, semiliterate) programming framework.

注意,我们还没有定义 MUMBLE ,但是它们应当设置成允许我们的程序毫无困难地使用我们想要的数据。例如,这种注释也或许能够和某种文字(至少半文盲)程序框架结合。

Goodbye, CET 6

01 March 2005

Thank God, I passed the CET 6(College English Test 6).
I'll celebrate this with beer and foods this evening together with my schoolmates, and it's a pity that most of them failed. What's more pity, I'm still coughing badly (more than a month now) and cann't have any beer.

To some extent, I should owe my success to perl. The perl infomation is almost wrote in English, I surf the English site, read articles, and translate them into Chinese. These helps me a lot.

Several days ago, I decided to have further education -- be a graduate student. My dear sister told me that the graduate English exam is more difficult than CET 6, so I need more efforts.
Writing some essays somtimes, just like what I'm doing now, is a step. Translating more perl works is another.

Thank God, everyday has surprise.

Apocalypse 1 / 启示录一

28 February 2005





启示录 1 :丑陋的,坏的和好的


Larry Wall


维护者: Larry Wall 
日期: 2 Apr 2001
最后修改: 27 Sep 2004
编号: 1
版本: 2

在以下的专栏中,我所要揭示的将是关于 Perl6 的设计思路。或者,更确切地说,是设计的开始,因为,在我最初的发言之后,设计过程必然会继续进行。我并非无所不知,尽管有些谣言会这么认为。显然我太渺小,同上帝游戏的工作并不适合我。但无论如何,总有人必须去做,所以,我只好硬着头皮,竭尽全力。我期望你们能够帮助我一起创造历史。在自愿的基础上,我们都得尽自己的一份力量。

如果你着眼于 Perl6 的历史,你就能发现为什么这篇文章的幅标题是“丑陋的,坏的和好的”了,从某种意义上来说,去年的RFC过程甚是丑陋。它是一个自由讨论的过程,这就意味着它的丑陋——并不是指粗野,因为 RFC 过程实际上是相当文明的——而是指在RFC中各种意见大都是些毫无联系的构思。坦白的说,RFC完全偏离了原来的计划。有的 RFC 是矛盾的,而有的 RFC 迷失了。很多的 RFC 本来着眼于现实的问题但却用好笑的角度试着提出解决方案。很多 RFC 修补了些小毛病却忘了最基础最底层的问题。

我也发现了 Larry 的重新设计语言的第一法则:Everyone wants the colon.

刚才讲的是丑陋的部分。而坏的部分是有些人指望我用这些 RFC 在两个星期内建立起一个一致的设计方案。开始的时候,我打算将那些RFC分成好的,坏的和丑陋的三类,而最终,他们中的大多数被归为了丑陋的,因为好的那些通常存在一些错误,而即使坏的那些通常指出了一个问题,其思想还是不错的,即使这个解决方案完全就是杜撰的。

现在,五个月过去了,我一直都在思考如何才能获得一致。很多人知道当你的 Perl 程序超过了你的物理内存的时候什么会发生——你开始抓狂了。我也会这样。我无法很好的在头脑里面一次处理很多的问题,而且我不是一个善于分析问题的人。我的长处在于综合,而非分析。我无法忍受生活中有许多让我分心的事情,有一些是我自己造成的,有一些不是。我不会更多的谈这些,都留在我的还未发表的自传里面吧。

但是现在,我们来谈谈好的部分(我希望是的)。经过考虑了许许多多单个的 RFC ,而且不知道如何开始将他们作为一个整体来思考的时期之后,我终于发现了用来思考这些问题的恰当的顺序,或多或少,就是骆驼书章节的顺序。更确切的说,骆驼书的章节就是为了在解释 Perl 时减少他们之间的直接引用而设计的。所以用大概同样的顺序来思考 Perl 6 ,将减少在我做出决定之前必须去决定的那些事情。

所以,我已经非常乐意的将所有的 RFC 按照章节顺序进行了分类,现在,他们看起来更容易管理了。(我还重新组织了我的 email ,这样不管消息位于邮件列表的哪个位置,我都能在所有消息中看到那些谈到特定 RFC 的消息。这对我帮助很大。)我打算为每一章写一个“启示录”,所以,启示录 1 将对应着第一章:Perl 概述(An Overview of Perl)。(当然,在这本书中,“概述”更象一个短小的教程,而非真正完整的对 Perl 进行分析的哲学基础。尽管如此,将那些总体谈到 Perl 6 的 RFC 分类到此倒是很方便。)


    RFC  PSA  Title
    ---  ---  -----
     16  bdb  保持Perl的缺省状态不受warning和strict等的限制。
      26  ccb  命名操作符还是函数
      28  acc  Perl 应该保持本色。
      73  adb  所有 Perl 的核心函数应该返回对象。
     141  abr  这是最后的主要修订。
PSA 代表着“Problem(问题), Solution(解答), Acceptance(接受)”.问题(problem)和解答(solution)的等级为a-f, 通常,你将发现我对问题(problem)的评级高于解答(solution)。接受(acceptance)评级是以下之一:

a 完全接受
b 基本接受
c 勉强接受
r 拒绝

RFC 141: 这是最后的主要修订

最初,我倾向于接受这个RFC,但是最终,在神学的立场上(on theological grouds),我决定否决它。在关于启示录的文学作品中,7 是一个代表完美的数字,而6则代表着瑕疵。实际上,就像RFC暗示的,我们可能不会结束向2*PI这样一个版本号的收敛,不过 6.6.6 看上去更不幸。

所以,Perl 7 将是最后一个主要的修订版本。实际上,Perl 7 将会非常完美,它将不会再需要任何修改。perl 6 仅仅是 Perl 7 的原型。:-)

实际上,我同意这个 RFC 的潜在的情感——我否定它,只是为了娱乐的价值。我想让 Perl 继续演变,能够更好的解决问题。以至于,如果你细读 RFC ,你会发现我的一些设计目标刻意表现的比较模糊。

首先,Perl将会支持映射于( mapping onto )单语义模型( single semantic model )的多重语法( multiple syntaxes )。其次,单语义模型将会反过来映射到多平台。

多重语法听起来象一个邪恶之物,但是他们对于语言的演化是非常需要的。某种程度上来说,我们已经有了多重语法模型;每次你使用一个 pragma 或者 module ,你就在扭曲你正在使用的语言。只要在 module 的开头清晰地说明了你是使用哪个版本的语言,那就没啥大问题。

对多重语法的支持是如何允许( Perl )不断进化,有个特殊而强有力的例子就是从 Perl 5 移植到 Perl 6 本身。详见下面关于 RFC 16 的讨论。

多后端(multiple backends)对于我们如今居住的世界很重要。Perl 6 绝对不能限制在那些要能进行 C 编程的平台上运行。它必须能够在其他的虚拟机上运行,比如说那些由 Java 和 C# 支持的。

RFC 28: Perl应该保持本色。

我由衷的希望那些钟情 Perl 5 的人们会更钟情于 Perl 6 。也可以这样说,我由衷的希望 Perl 将继续满足人们的一切需要,因为那也是Perl的希望。

我原则上接受这个 RFC (我不想胡言乱语),但仍然有些不同意见,因为我认为没有必要害怕任何一些编程范例“接管”设计工作。这将不会发生。Perl 的组成本来就是多范例的(multi-paradigmatic)。Perl 让你能够遵循任何范例,且不用特意遵循。

Perl的实质是真正的上下文敏感(context sensitivity),不是指语法上下文(syntactic context),而是语义的(semantic),实在的(pragmatic)以及文化的(cultral)上下文。这整套哲学在 Perl 6 中不会改变,虽然一些特定的上下文敏感会被修改。目前的一些上下文敏感阻碍的我们在某些领域做的更好。通过有目的摆脱一些束缚,我们能够使 Perl 比现在更好的理解我们的意愿。

一个特别的例子,如果我们鼓起勇气打破 @foo 和 $foo[] 之间的奇怪的关系,那么很多的事情都能够得到改进。是的,我们失去了目前的切片符号(slice notation)(我期待一些更好的东西能代替它)。但是,如果我们一致的将 @foo 看作在标量上下文中返回一个数组引用,我们可以让下标(subscript)带数组引用,这样我们就不用象在 Perl 5 中那样需要区别 $foo[] 和 $foo->[] 。在启示录 2 中,当我们仔细研究如 RFC 9: 高地数据类型的时候等的时候,会有更多的讨论。

RFC 16: 保持 Perl 的缺省状态不受 warning 和 strict 等的限制。

关于这个讨论我感到非常为难,两方的论据都非常充分。如果读一遍讨论,所有的那些意见都是被反复的而有力的提出。讨论主要集中在关于 strictness 的主题,因为这个 RFC 主题显得更具哲学意味,所以在该启示录中我们就应该给出一个结论。

我会同时谈谈 strictness 和 warnings ,再大体上谈谈限制(constraints),不过我会首先绕开一些深奥的设计主题。我认为,这个 RFC (以及与其相对的),代表了一个例子,那就是为什么象我这样的一些程序员必须对其做出一个判断,因为它既是对的,同时又是错的。很多 RFC 旗帜鲜明,错过了折中的机会。一个 RFC 的确只应该关注于一个领域而非全部。但是,因为所有的这些 RFC 是依照 Perl 5 的思想来撰写的,所以,他们不能进行妥协,即使在那些 Perl 6 的设计要求那么做的地方。

对于我来说,一个最重要的主题就是是否能将 Perl 5 的代码转换为 Perl 6 的代码。一个大家非常关注的地方就是 shell 脚本,在 shell 脚本中,到处都有俏皮的内嵌代码。我们确实没有好的办法来转化这些“符咒”,所以用一个新的命令行来转到“no strict”是不切实际的。

另一个与之密切相关的问题是 Perl 如何识别那些偶然碰到的 Perl 5 代码。不可能立即赋予工作代码一套新的语义集。所以,我认为,不可能通过定义(definition)来使 Perl 6 处理 Perl 5 的代码。运行过程的情况应该是,在新的东西出现之前,假定 Perl 6 本来在处理 Perl 5 的代码。这就意味着,我们必须有一些声明(declaration),这些声明清晰的将代码声明为 Perl 6 。

目前,面对以上问题,存在一些正确的,和错误的解决方法。我对 DEC 升级 BASIC/PLUS 来处理长变量名所采取的方法非常气愤。他们的解决方案是要求所有使用长变量名的程序在最开始加上 EXTEND 命令。所以,从此以后,所有的 BASIC/PLUS 程序在最开始都有 EXTEND 。我不知道是不是应该称其为坏或者丑陋,但绝非好。

一个好一些的方法是修改那些本来存在的东西。如果你看看 CPAN 的那些模块,在最开始你看到了什么?答案:" package "声明。我们来打破它。

所以,我声明,在文件开始的 package 声明指出了你正在分析 Perl 5 代码。如果你想要写 Perl 6 模块或者类,那么关键字会是 module 或者 class 。我不清楚确切的模块和类的声明的语法,但是我清楚的是,我们将如同 package 声明那样设定目前的全局名字域(global namespace)。

现在,通过将模块和类默认值设为 strict 和 warnings 能够处理很多编程的问题。但是要注意,在主程序(the main programs)中默认值是 Perl 5 ,其被定义为 non-strict 。我们仍然必须解决, Perl 6 的主程序应该如何区别于 Perl 5 (或许是加上一个" use 6.0 "?),以及是否 Perl 6 主程序应该将默认值设为 strict (我想不会),不过你已经看到了,老师可以对学生以不及格相威胁,只要他没有在程序开始加上“ module Main ”,而且从不告诉他的学生,那样做的原因是因为要开启 strict 和 warnings 。

其他的一些方法也是可行的,不过将我们带入一个更深的主题,关于工程方针和站点方针(the issue of project policy and site policy)。人们总是渴望各种文件能够自动的从各个位置读入,我已经坚决反对这么做,因为这在暗中(implicityly)使脚本变得笨重。与之相反,外在的(explicit)的不轻便性(non-portablity)是可以接受的,所以我们的假象的老师没有理由不会坚持在程序的开头加上"use Policy;"之类的东西。

现在让我们看看,以上的方法怎么会引起一个更深的程序设计主题。真正的问题是,很难在 Perl 5 中写这样一个 Policy 模块,因为它不是一个普通的模块,而是一个超模块( meta-module )。它想要完成" use strict "和" use warnings ",但它自己却不能。所以,我们在 Perl 6 中必须实现的一个东西就是 meta-use 声明,它看起来很像从前的 use 声明,但却可以代表用户声明其他的东西,为了用户,为了工程,或者为了站点。(或是其他任何东西。我不是一个 policy 书呆子。)

所以,是否我同意该 RFC 完全依赖于“默认值(defualt)”的含义。就像又矮又胖的人那样,我会为我认为的最方便的的形式赋予含义。那就是工作时的上下文敏感性。

我同意该 RFC 也是因为我的人生哲学,道德绝不可强求。不过,总有些时候,道德会被强烈的提出,所以我认为可以写个模块和类来解决。

[ 更新:现在当我们知道它是 Perl 6 而不是 Perl 5 时,主程序默认将开启 strict. 如果我们首先看到了类如“ use 6.0 ”等东西,那我们知道这是 Perl 6 ,从而我们知道它的格式是严格的。(同样的 #!/usr/bin/perl6 将默认开启 strict 。)我想我们可以认可一个更短而非正规的不带 use 的形式来默认不开启 strict :

    $x = 1; # global is legal
(没有 v6 将默认为 Perl 5 。)由 -e 运行的脚本也将默认不开启 strict 。也许我们能允许无争议的 -e 作为最终的行,用以在以下行中抑制 strict 的使用。当然,“ no strict ”也是可以行的。 ]

RFC 73: 所有 Perl 的核心函数应该返回对象

我不知道该 RFC 是否应该属于概要。原则上,我同意该 RFC 。当然,如果所有的 Perl 变量都是对象,这个 RFC 肯定正确。但是,真正的问题在于,对于未知的性能水平,你对能返回对象的兴趣有多少。 Perl 5 的对象相对的笨重,如果所有的 Perl 6 的对象都是这样,事情就糟了。

我正在考虑该解决方案应该是对数值(data values)的更好的抽象类型支持,就像在 C structs 中在内部所呈现的那样。当我们试着将 C struct tm 转换成哈希值得时候,我们往往会陷入困境。相反,struct tm 之间的互相转换却十分的高效,因为这是一个 no-op 。我们可以使这样一个 struct 看起来像一个 Perl 对象,然后通过属性方法(attribute methods)高效的访问它,就像一个真正的对象一样。我们可以只通过强加一个抽象的系统开销(overhead)。最大的系统开销将很可能会是 struct 的内存管理而非 int ,然后,通过某些上下文相关的优化,系统开销能够被大大节省。

无论如何,我想指出,当我们谈论以不同以往的方式返回对象的时候,我们不必惊惶。记住任何对象能够定义 stringify 和 numify 来重载那些类要做的事情,所以,过去的代码看起来是这样:

print scalar localtime;

RFC 26: 命名操作符还是函数

我不晓得在什么地方放置这个 RFC 好。

我发现这个RFC容易让人弄胡涂,因为其表达的理论的内容,比其描述的要激进的多。如果忽略理论的内容,我会非常同意它。在 Perl 5 中我们主要通过其调用的方式来区分操作符和函数。这个 RFC 可以澄清的一个地方是 Perl 5 区分了两种类型的有名操作符(named operators): 有名一元操作符(named unary operators)和列表操作符(list operators)。因为他们含有不同的优先级(precedence)所以他们可以被区分开来。我们将在启示录 3 中讨论优先级的改革,但是我怀疑我们会将两种有名操作符联合起来。(我的确知道简化 Perl 优先级表的方式,从 24 层简化到 18 层,虽然,这样做让一些不常用的操作符对 C 的兼容性造成破坏。这个以后再说。)

你现在开始明白为什么我的工作不仅仅是对各个 RFC 进行投票。我们会面临很多不能被 RFC 所包含的重大主题。我们必须决定在多大程度上我们的文化应该保留或者进行修改。我们必须使 Perl 5 向 Perl 6 平滑过渡,使人们很容易的适应 Perl 6 。我们必须关注那些深刻的主题直到我们从中发现更深刻的部分。我们必须使所有的人都能够随时方便的使用 Perl 来工作。


Perl 6 Apocalypse

28 February 2005

最近 Autrijus Tang (唐宗汉先生)在编写个 Perl 6 的解释器/interpreter —— Pugs. 我订阅了他在 use.perl journal RSS.
其中牵涉到一些 Perl 6 的语法,觉得挺陌生的。便想看看 Perl 6 的语法文档。在dev.perl6 上翻了翻,也只有找到 Larry Wall 的 Apocalypse 比较适合。
在我的印象中,DanceDanceDance 好像翻译过部分,找 y6cmE 要了那部分翻译文稿。他只翻译了 Apocalypse 1, 用 MSN 联系了他(gongwuming_At_hotmail_Dot_com),他说早以不做这事了。
他翻译的是2 Apr 2001的第一稿,而现在是27 Sep 2004的第二稿,我打算对照着翻译修改一点,过几天将 Apocalypse 1 放到网上来。

Apocalypse 的结构

Apocalypse 里最常见的结构如下:
     RFC  PSA  Title
     ---  ---  -----
     141  abr  This Is The Last Major Revision
RFC 141: This Is The Last Major Revision
I was initially inclined to accept this RFC. ....
RFC, RFC 是英文 Request For Comments|Change 的缩写,翻译成中文就是请求注解,另种意思为 Internet 标准。RFC下的141为数字记号。
PSA, PSA 是 Problem(问题), Solution(解答), Acceptance(接受度)的缩写。下面的abr分别对应三者,其中 PS 以 a-f 划分问题和解答是好是差,A/Acceptance 划分为
a Accepted wholeheartedly 完全接受
b Accepted with a few "buts" 基本接受
c Accepted with some major caveats 勉强接受
r Rejected 拒绝
d Deferred 延期
如此,上面的 abr 就为好的问题,较好的解答,拒绝接受此请求。

这就是一篇 Apocalypse 的基本结构。而所有的 RFC 按照“操作符,语法,子程序等”划分为八篇 Apocalypse.
这些内容将在 Apocalypse 1 中讲到。

Apocalypse 的这种结构对翻译来说是很适合的,有时间翻译一个 RFC ,可以多人协作。我打算在 wiki.perlchina 上发起这个翻译协作。

God bless me.


15 January 2005

原因可能是创建rss时我是提取mysql数据库里的资料(utf8编码的), 而更新的时候是直接使用表单里的数据,不是utf8编码的。
我试了use Encode qw/encode decode/;可没结果,将表单数据转换后,在网页编码为utf8时正确显示,写入的时候却成了乱码。

Google了一下,下过来的都不是encmap文件,虽然名字也是gb2312.enc, 而很多Blog所提起的http://atzone.fatb.org却失效了。
看看Google搜索来的东西,里面有个post在ASPN提起如何制作gb2312.enc, http://aspn.activestate.com/ASPN/Mail/Message/perl-xml/1341040

1. Download GB2312.TXT from ftp.unicode.org
2. Download the XML::Encoding 1.01 and get two binaries:
   make_encmap and compile_encoding
3. run make_encmap as follows:
   make_encmap GB2312 GB2312.TXT >  GB2312.encmap
4. Add expat='yes' to the first line of GB2312.encmap
5. run compile_encoding:
   compile_encoding -o GB2312.enc GB2312.encmap
6. copy GB2312.enc to
cpan XML::Encoding后,却在unicode.org上找不到GB2312.txt, 有这连接,又是失效了。Google "GB2312.txt"找到的都是错的。我faint!
后来换Baidu搜索了好一阵子才在 http://eaa13.dns0755.net/~atzone/source/gb2312.enc 找到。
Have fun!

记于 2005/01/15


14 January 2005


pod(Plain Old Documentation), 它是一种简单而易用的标记型语言(置标语言),用于perl程序和模块中的文档书写。
pod中用段分可以分为三种,普通段落,字面段落(Verbatim Paragraph)和命令段落。


此四个指示字生产指定级别的标题。pod2html时用其对应的<h1> .. </h4>包围此段落,并且自动生成a的命名/name和索引/index.


=head1 NAME

pod2html - convert .pod files to .html files

pod2html后NAME的标签为h1, 而后面的那段为p。

=pod 只告诉编译器pod文档开始了,而=cut则是pod文档的结束。




Here we start our pod


sub _ {

=over NUMBER
=item SYMBOL
当SYMBOL为数字时使用ol, SYBMOL为*时使用ul, 其余的使用dl.
=item 能自动生成a的命名,但不参加索引/index(与head不同)。


=over 4

=item L<http://www.perl.com/>

Perl 的首页 (由欧莱礼公司维护)

=item L<http://www.cpan.org/>

Perl 综合典藏网 (Comprehensive Perl Archive Network)

=item L<http://lists.perl.org/>

Perl 邮递论坛一览



=for format text
=begin format
=end format
此指示字的作用是对此段落使用特殊的格式/format(如html, text等)。


=begin html

<hr> <img src="thang.png">
<p> This is a raw HTML paragraph </p>

=end html



  • I<text>
    用斜体表示text, 效果如text
  • B<text>
    用粗体表示text, 效果如text
  • C<code>
  • L<text|name/sec>
    其中text为连接所显示的内容,若没有text,name为模块名时显示 the module::name manpage, name为网址时不允许存在text。pod2html时转化为<a>和</a>之间的东西。
    L<Net::Ping> - <a href="/Net/Ping.html">the Net::Ping manpage</a>
    L<http://www.1313s.com> - <a href='http://www.1313s.com'>http://www.1313s.com/</a>
    L<Perl Error Messages|perldiag> - <a href='perldiag.html'>Perl Error Message</a>
    L<perlsyn/"For Loops"> - <a href='perlsyn.html#for_loops'>the perlsyn manpage</a>
    L<fayland|http://www.1313s.com> - name为网址时不允许存在text
  • E<escape>
    • E<lt> - <
    • E<gt> - >
    • E<verbar> - |
    • E<sol> - /
    • 更多的请参考perldoc perlpod
  • 更多的如F<filename>, S<text>等请参考perldoc perlpod




=head1 Examples

it's just a examples for pod newcomer.

=head1 how to write a pod?

=over 4

=item 1

know all pod command's meanings such as "head1, over, item, begin".

=item 2

try to write a example by yourself.

=item 3

use 'pod2html' utility convert pod to html format.

=item 4

modify and pod2html again until u a satisfied.


=head1 FAQ

=head2 want to add a B<img>?

use code as follows:

 =begin html
 <img src='http://www.1313s.com/f/fayland_gmail.png' />
 =end html

=head2 how to add E<lt>bE<gt> etc.


=head1 link I<this> page



perldoc & pod2html



你可以通过pod2html --help来查看pod2html的所有参数。因为所有的参数都是很容易看懂的,也就不多加解释了。
将上面的例子保存为examples.pod, 然后进入控制台/console:
pod2html <examples.pod >examples.html -css=Active.css
All is Done.


=over 4

=item *

perldoc L<perlpod>

=item *

perldoc L<perlpodspec>

=item *

<Programming Perl> Chapter 26 大骆驼书第26章


:) have fun.


12 January 2005


RSS 的好处和用途不用多说,简而言之就是方便有用。详细的请Google it.


创建需要填写Channel,而更新时不需要。对于image, textinput暂时略过。


Channel里有很多参数,如dc, syn, taxo等。很多我都不太懂。不过不懂就暂时先别加上,等懂了再加也不迟。

use XML::RSS;
my $RSS_file = "$Cfg{'htmldir'}/index.rdf";
my $rss = XML::RSS->new(version => '1.0');

print 'Create a new RSS file<br>';
    title        => "Fayland's",
    link         => 'http://www.1313s.com/f/',
    description  => 'What Fayland says',
    language     => 'zh-cn',
    copyright    => '(c)2005, all rights reserved',
    syn => {
        updatePeriod     => 'daily',
        updateFrequency  => '1',
        updateBase       => '2005-01-12T00:00+00:00',
# get 20 data from database, u can get more by set LIMIT
my $sth = $dbh->prepare(
    qq{SELECT * FROM cms ORDER BY cms_id DESC LIMIT 0, 20}
my $cats = $sth->fetchall_arrayref({});

foreach my $cat (@$cats) {
        title       => "$cat->{'cms_title'}",
        link        => "http://www.1313s.com/f/$cat->{'cms_file'}.html",
        description => "$cat->{'cms_describe'}",
    print "Add $cat->{'cms_title'}<br>";

print 'all DOne!<br>';


更新比创建还简单。就要先读取,然后再add_item, 再save就OK了。

use XML::RSS;
my $RSS_file = "$Cfg{'htmldir'}/index.rdf";
my $rss = XML::RSS->new(version => '1.0');


    title       => "$tilte",
    link        => "http://www.1313s.com/f/$file.html",
    description => "$describe",