依云's Blog

之前我写过一篇文章，讲述我使用 EasyEffects 的均衡器来调整 Bose 音箱的音效。最近读者 RNE 留言说可以直接通过 PipeWire 实现，于是前几天我实现了一下。

先说一下换了之后的体验。相比于 EasyEffects，使用 PipeWire 实现此功能获得了以下好处：

• 少用一个软件（虽然并没有多大）。
• 不依赖图形界面。EasyEffects 没有图形界面是启动不了的。
• 占用内存少。EasyEffects 有时候会占用很多内存，不知道是什么问题。
• 自己实现的切换逻辑，更符合自己的需求。EasyEffects 只能针对指定设备加载指定的配置，不能指定未知设备加载什么配置。因此，当我的内置扬声器名称在「alsa_output.pci-0000_00_1f.3.analog-stereo」、「alsa_output.pci-0000_00_1f.3.7.analog-stereo」或者「alsa_output.pci-0000_00_1f.3.13.analog-stereo」等之间变化时，我需要一个个名称地指定要加载的配置。
• 只要打开 pavucontrol 就能确认均衡器是否被应用了。EasyEffects 需要按两下Shift-Tab和空格（或者找找鼠标）来切换界面。

缺点嘛，就是我偶尔使用的「自动增益」功能没啦。不过自动增益的效果并不太好，我都是手动按需开关的。没了就没了吧。

配置方法

首先要定义均衡器。创建「~/.config/pipewire/pipewire.conf.d/bose-eq.conf」文件，按《Linux好声音（干净的均衡器）》一文的方式把均衡器定义写进去就好了。我的文件见 GitHub。

然后需要在合适的时候使用这个均衡器。实际上上述配置加载之后，PipeWire 里就会多出来一对名叫「Bose Equalizer Sink」的设备，一个 source 一个 sink。把 source 接到音箱，播放声音的程序接到 sink，就用上了。别问我为什么 source 的名字也是「Sink」，我不会分开定义它们的名字……

自动化应用使用的是 WirePlumber 脚本。它应该放在「~/.local/share/wireplumber/scripts」里，但是我为了方便放到 dotconfig 仓库里管理，在这里放了个到「~/.config/wireplumber/scripts」的软链接。脚本干的事情很简单：在选择输出设备的时候，看看当前默认设备是不是 Bose 音箱；如果是，就选择之前定义的「Bose Equalizer Sink」作为输出目标。不过因为文档匮乏，为了干成这件事花了我不少精力，翻看了不少 WirePlumber 自带脚本和源码。最终的脚本也在 GitHub 上。

结语

PipeWire 挺强大的，就是文档太「瘦弱」啦。能用脚本配置的软件都很棒～

再次感谢读者 RNE 的留言～

序

swapview 起源于我很早之前看到的一个 shell 脚本。当时正在学习 Haskell，所以就拿 Haskell 给实现了一遍。为了对比，又拿 Python 给实现了一遍。而如今，我又在学习另一门新的语言——Rust，也拿 swapview 来练习了。相比仅仅输出字符串的「Hello World」程序，swapview 无疑更实际一些：

• 文件系统操作：包括列目录、读取文件内容
• 数据解析：包括简单的字符串处理和解析，还有格式化输出
• 数据处理：求和啊排序什么的
• 流程控制：循环啊判断啊分支什么的都有
• 错误处理：要忽略文件读取错误的

因此，swapview 成为了依云版的「Hello World」:-)

感谢所有给 swapview 提交代码的朋友们！

本文只是借 swapview 这个程序，一窥众编程语言的某些特征。很显然，编程语言们各有所长，在不同的任务下会有不同的表现。而且 swapview 各个版本出自不同的人之手，代码质量也会有所差异。

闪耀！那些令人眼前一亮的语言们

从运行效率上来看，C 如预期的一样是最快的。但令人惊讶的是，由我这个 Rust 初学者写的 Rust 程序竟然紧随其后，超越了 C++。

而原以为会跟在 Rust 之后的 C++，却输给了作为脚本语言存在的 Lua 语言的高效实现 LuaJIT（与 Rust 版本相当）。而且非 JIT 版本的 Lua 5.1 和 5.2 也都挺快的。Lua 这语言自带的功能非常少，语法也简单，但是效率确实高，让人又爱又恨的。

失望！那些没预期中的高效的语言们

没想到 Python 2 也挺快的，很接近 Go 了。PyPy 大概是因为启动比较慢的原因而排在了后面。Python 3 有使用两个版本的代码，Python3_bytes 把文件读取改为使用 bytes，仅在需要的时候才解码成 str。仅此之差，运行速度快了10%。可见 Python 的 Unicode 处理十分耗时，难怪 Python 3 在各种测试中都比 Python 2 要慢上一截。至于 PyPy3，怎么跑到那么靠后的地方去了呢……

Go 很快。至少比 Python 快。但也仅此而已了，不仅比 C++ 慢，甚至连 Lua（非 JIT 版）都不如。Go 语言版本虽然不是我写的，但我看过代码，感觉很原始。至少比 Lua 原始。看起来 Go 只不过是带接口和并发支持的 C 而已。而且，作为静态类型的编译型语言，却我却有一种很不放心的感觉。大约是因为我改动时发现传给 fmt.Printf 的参数类型和数目错了都不会得到警告或者错误的原因。而且我从来没见过 Go 编译时出现警告，对于还没入门的初学者写的、改过的程序，这样子不科学啊。早期我倒是见过 Go 报错了，但那只不过是编译器还不完善的表现而已。

传闻 NodeJS 很快。但至少它在 swapview 这种脚本中没能体现出来。正常版本比 Python 3 还要慢一点。而使用异步啊并行什么的版本还要慢上差不多三分之一，不知道怎么搞的。

编译型的 Chicken、OCaml、Haskell 都排在了一众脚本语言后边，虽然很可能是对语言本身不熟导致写出来的程序比较慢，但还是挺令人失望的。经过高手优化的 Haskell2 版本效率接近于 Python 3，但也到此为止了（因为不想使用 cabal 安装依赖，所以 Haskell2 没有参与这场对决）。我曾见过有人把 Haskell 代码优化到比 C 还快，但我宁愿去看汇编也不要去读那种代码……

Lisp 系（Chicken、Racket、SBCL（标注为 CommonLisp 的项）、Guile）也都挺慢的。不知道 LispWorks 之类的会不会快一大截呢。

预料之中的以及结果截图

Ruby 比 Python 略慢一点。

Java、Elixir 比较靠后。没办法，它们启动慢。也许以后我会出不考虑启动时间的版本。

以下是本文发表前的测试结果截图。其中 Erlang 版本因为有问题被信号所杀所以被扔在了最后。

测试使用的是benchmark子目录中的 Rust 程序，使用cargo build --release命令即可构建。另外也可以使用 farseerfc 的 Python 脚本。

代码量

Elixir 代码量挺少的。Python、Ruby 也挺不错。Java 版本竟然跟 Haskell 一样。不管是 JavaScript 还是 CoffeeScript 都比较长，比 Java 还长。Rust 比 Python 长不少，但也比 Go 短不少。而 Go 比起 C、C++ 要短一些。最长的，除了我不了解的 Pascal，竟然还有因为程序出错还没有测试的 Erlang！如果不算按行读取的 line_server.erl 的放大，只有不到一百行，倒还不算多。

                  Elixir:   50
                   Julia:   51
           Python3_bytes:   53
                  Python:   56
                    Ruby:   56
                  Racket:   58
                    Bash:   63
                   OCaml:   65
          CommonLisp_old:   67
          CommonLisp_opt:   67
           Bash_parallel:   69
             C++14_boost:   69
                   Guile:   70
                 Haskell:   73
                 Chicken:   75
                    Java:   75
                  NodeJS:   76
                    Vala:   78
                Haskell2:   81
                       D:   86
                    Rust:   88
                   C++14:   89
                  CSharp:   91
                     Lua:   91
            NodeJS_async:   93
            CoffeeScript:   93
   CoffeeScript_parallel:   95
                     PHP:   97
           Rust_parallel:   98
                      Go:  103
                   C++11:  128
                   C++98:  141
                       C:  149
              FreePascal:  185
                  Erlang:  232

编译速度

这个比较非常粗糙，比如联网下载依赖也被算进去了。不过可以肯定，不算下载依赖部分的话，Rust 是最慢的！其次是 Haskell。标榜编译速度非常快的 Go 并不是最快的，和 C++ 不相上下（当然不知道代码复杂之后会如何了）。

0.36 C
0.60 FreePascal
0.80 OCaml
0.83 CoffeeScript_parallel
1.48 CSharp
1.67 Vala
1.68 Erlang
2.13 NodeJS_async
2.27 C++14
2.49 Go
2.53 CoffeeScript
2.90 C++11
3.01 C++98
3.23 Java
3.52 Racket
3.98 NodeJS
6.05 CommonLisp_opt
7.07 D
9.01 C++14_boost
10.41 Haskell
13.07 Rust
14.74 Chicken
15.37 Rust_parallel

结语

这个项目最初只是练习而已。后来不同语言的版本有点多，于是才演变成众编程语言的竞技。也就随意地测试了一下在给定需求下不同语言的表现而已。其实比较有意思的部分，一是使用正在学习的编程语言写作程序的新奇感、新知、新的领悟（这也是我的测试程序使用 Rust 编写的原因），二是对比不同编程语言的风格和对同样需求的处理方式。

各位读者对 swapview 有任何补充和改进，欢迎贡献代码哦～项目地址：https://github.com/lilydjwg/swapview。

更新区

2015年1月9日更新：又收到了不少版本和改进，以下是最新的测试结果。很不幸地，现在已经跑得很快的 Erlang 在测试中又没反应被杀掉了。并行版的 Rust 的结果很不稳定，这次跑得好快！C++ 的除了 C++98 版的之外都到 Rust 前边去了。PHP 竟然比 LuaJIT 还要快！D 怎么到 PyPy 后边去了。

2015年1月10日更新：C++ 版本继续改进，好多都超越 C 了，Rust 1.0.0alpha 的并列版本又快又稳定，Erlang 版本终于跑完了全部测试而没有出事，LLVM 版 D 快了好多。

2015年1月18日更新：继续更新。又添加了若干语言，不过期待中的 Nim、Zimbu 以及传统脚本语言 Perl、Tcl 依旧缺席中。另外，正文也进行了更新，重新计算了代码量，添加了编译速度的粗略比较。

稍微了解一点类 UNIX 系统的进程管理的都知道，当一个进程的父进程死亡之后，它就变成了孤儿进程，会由进程号 1 的 init 进程收养，并且在它死亡时由 init 来收尸。但是，自从使用 systemd 来管理用户级服务进程之后，我发现 systemd --user 管理的进程总是在它之下，即使进程已经 fork 了好几次。systemd 是怎么做到的呢？

对一个软件的实现有不懂的想了解当然是读它的源码了。这种东西可没有另外的文档，因为源码本身即文档。当然之前我也 Google 过，没有得到结果。在又一个全新的源码树里寻寻觅觅一两天之后，终于找到了这个：

        if (arg_running_as == SYSTEMD_USER) {
                /* Become reaper of our children */
                if (prctl(PR_SET_CHILD_SUBREAPER, 1) < 0) {
                        log_warning("Failed to make us a subreaper: %m");
                        if (errno == EINVAL)
                                log_info("Perhaps the kernel version is too old (< 3.4?)");
                }
        }

原来是通过prctl系统调用实现的。于是去翻 prctl 的 man 手册，得知PR_SET_CHILD_SUBREAPER是 Linux 3.4 加入的新特性。把它设置为非零值，当前进程就会变成 subreaper，会像 1 号进程那样收养孤儿进程了。

当然用 C 写不好玩，于是先用 python-cffi 玩了会儿，最后还是写了个 Python 模块，也是抓住机会练习一下 C 啦。有个 python-prctl 模块，但是它没有包含这个调用。

#include<sys/prctl.h>
#include<Python.h>

static PyObject* subreap(PyObject *self, PyObject *args){
  PyObject* pyreaping;
  int reaping;
  int result;

  if (!PyArg_ParseTuple(args, "O!", &PyBool_Type, &pyreaping))
    return NULL;
  reaping = pyreaping == Py_True;

  Py_BEGIN_ALLOW_THREADS
  result = prctl(PR_SET_CHILD_SUBREAPER, reaping);
  Py_END_ALLOW_THREADS

  if(result != 0){
    return PyErr_SetFromErrno(PyExc_OSError);
  }else{
    Py_RETURN_NONE;
  }
}

static PyMethodDef mysysutil_methods[] = {
  {"subreap", subreap, METH_VARARGS},
  {NULL, NULL}    /* Sentinel */
};

static PyModuleDef mysysutil = {
  PyModuleDef_HEAD_INIT,
  "mysysutil",
  "My system utils",
  -1,
  mysysutil_methods,
  NULL, NULL, NULL, NULL
};

PyMODINIT_FUNC PyInit_mysysutil(void){
  PyObject* m;

  m = PyModule_Create(&mysysutil);
  if(m == NULL)
    return NULL;
  return m;
}

编译之后，

>>> import mysysutil
>>> mysysutil.subreap(True)

然后开子进程，不管它 fork 多少次，都依然会在这个 Python 进程之下啦。

但是，这样子不太好玩呢。如果我登陆之后所有启动的子进程都在一个进程之下不是更有意思么？于是我打上了 Awesome 的主意，因为它支持运行任意的 Lua 代码嘛。于是我又给这个 prctl 调用弄了个 Lua 绑定。最终的版本如下：

#include<lua.h>
#include<lualib.h>
#include<lauxlib.h>

#include<sys/prctl.h>
#include<sys/wait.h>
#include<errno.h>
#include<string.h>
#include<signal.h>

static int l_setsubreap(lua_State * L){
  int reap;
  if(lua_isboolean(L, 1)){
    reap = lua_toboolean(L, 1);
  }else{
    return luaL_argerror(L, 1, "not a boolean");
  }
  if(prctl(PR_SET_CHILD_SUBREAPER, reap) != 0){
    return luaL_error(L, "prctl failed: %s", strerror(errno));
  }
  return 0;
}

static int l_ignore_SIGCHLD(lua_State * L){
  signal(SIGCHLD, SIG_IGN);
  return 0;
}

static int l_reap(lua_State * L){
  int pid, st;
  pid = waitpid(-1, &st, WNOHANG);
  lua_pushinteger(L, st);
  lua_pushinteger(L, pid);
  return 2;
}

static const struct luaL_Reg l_lib[] = {
  {"setsubreap", l_setsubreap},
  {"reap", l_reap},
  {"ignore_SIGCHLD", l_ignore_SIGCHLD},
  {NULL, NULL}
};

int luaopen_clua(lua_State * L){
  lua_newtable(L);
  luaL_setfuncs(L, l_lib, 0);
  return 1;
}

除了调用 prctl 外，还增加了显式忽略 SIGCHLD 信号，以及非阻塞地调用 waitpid 收割单个僵尸进程的函数，因为 Awesome 本身没处理子进程退出，我一不小心弄出了好几个僵尸进程……对了，那个 waitpid 要注意给弄成非阻塞的，不然一不小心就会出问题。

用的时候就是这样子，可以写到rc.lua里，也可以在 awesome-client 里调用：

package.cpath = package.cpath .. ';/home/lilydjwg/scripts/lua/cmod/?.so'
clua = require('clua')
clua.setsubreap(true)
clua.ignore_SIGCHLD()

最终，我的进程树成了这样子：

可以看到，由 Awesome 启动的进程已经全部待在 Awesome 进程树之下了。systemd --user 是由 PAM 启动的，所以不在 Awesome 树下。但是，那些 dbus 的东西和 gconfd-2、at-spi 之类的是怎么回事呀……

所谓「相见恨晚」，说的就是我第一次看到 inspect.lua 的感觉啊！Lua 这个超小型主打嵌入的语言，连 Readline 都要第三方库来支持，自然是没 Python 那样的补全功能了。不仅如此，连一个展示其数据结构的函数都没有。包括自己在内，不少人零零散散写过各种打印 Lua 表的函数，但像 inspect.lua 这样子优秀的还是第一次见到。

基本用法啊示例什么的不说了，直接在对象上调用 inspect 函数就可以得到一个（可能是巨大的但一定不会是无限的）字符串表示，递归的结构会依据其类型和一个序号来辨识。

既得此神器，自然要用来看看我那自从升级到 3.5 版本之后就一直在慢慢泄漏内存的 Awesome 了：

>>> awesome-client
awesome#inspect = dofile('tmpfs/inspect.lua')
awesome#f = io.open('tmpfs/output.lua', 'w')
awesome#f:write(inspect(_G))
awesome#f:close()
awesome#f = nil

然后就是慢慢察看了。我注意到了这么一个变量：

  raise_on_click = {
    [<client 13>] = true,
    [<client 12>] = true,
    [<client 14>] = true,
    [<client 15>] = true,
    [<client 16>] = true,
    [<client 17>] = true,
    [<client 18>] = true,
    [<client 19>] = true,
    [<client 20>] = true,
    [<client 21>] = true,
    ...
  }

这个变量由来已久，好像现在已经偏离了当初的设计目的了……不管它，反正呢，它里边保留了所有 Awesome 正管理的客户端对象，有 100 多个呢。可是，我怎么会同时有那么多窗口呢，明明才十几个啊？

检查一下配置文件，终于知道问题在哪里了：

diff --git a/rc.lua b/rc.lua
index ad06296..c1422bd 100644
--- a/rc.lua
+++ b/rc.lua
@@ -991,7 +991,7 @@ end)
 client.connect_signal("focus", function(c) c.border_color = beautiful.border_focus end)
 client.connect_signal("unfocus", function(c) c.border_color = beautiful.border_normal end)

-client.add_signal("unmanage", function(c)
+client.connect_signal("unmanage", function(c)
     raise_on_click[c] = nil
 end)
 -- }}}

add_signal是 Awesome 3.4 的用法，3.5 应该用connect_signal才对。这里的client.add_signal是 Awesome 自己用的另外一个意思的函数……

用上 Awesome 3.5 后，我发现 Awesome 占用的内存有点多。后来又发现，运行的时间越长，其占用的内存也就越多：

这不是典型的内存泄漏吗！

然后我发现我只要按下Win+Ctrl+R重新载入 Awesome 配置，内存使用就会回去。看来是我的配置文件有问题。不过由于时间关系一直使用重新载入的方式应付着。今天终于有点时间和兴致，于是专心对付它了。

不过 Lua 脚本的内存泄漏要怎么查呢？我一开始想把_G打印出来。不过以前写的那个 Lua 对象转字符串函数似乎并不太喜欢 Awesome 加进去的那些对象，抛出了异常。瞪大双眼检查配置文件里的各种全局变量，特别是那里每隔几秒更新一次的指示器们，但也没发现什么。有些不知所措，随手又调出 htop 查看上图中那个占用了「巨量」内存的 Awesome 进程，右手无名指不自觉地按下，然后竟然发现了一个问题：

怎么开了那么多/proc/net/route和/proc/net/dev文件？这两个文件是我在网络指示工具中打开并读取了的，但是我不至于扔着打开的文件不管啊：

function update_netstat()
    local interval = netwidget_clock.timeout
    local netif, text
    for line in io.lines("/proc/net/route") do
        netif = line:match('^(%w+)%s+00000000%s')
        if netif then
            break
        end
    end
    if netif then
        local down, up
        for line in io.lines("/proc/net/dev") do
            -- Match wmaster0 as well as rt0 (multiple leading spaces)
            local name, recv, send = string.match(line, "^%s*(%w+):%s+(%d+)%s+%d+%s+%d+%s+%d+%s+%d+%s+%d+%s+%d+%s+%d+%s+(%d+)")
            if name == netif then
                if netdata[name] == nil then
                    -- Default values on the first run
                    netdata[name] = {}
                    down, up = 0, 0
                else
                    down = (recv - netdata[name][1]) / interval
                    up   = (send - netdata[name][2]) / interval
                end
                netdata[name][1] = recv
                netdata[name][2] = send
                break
            end
        end
        down = string.format('%.1f', down / 1024)
        up = string.format('%.1f', up / 1024)
        text = '↓<span color="#5798d9">'.. down ..'</span> ↑<span color="#c2ba62">'.. up ..'</span>'
    else
        netdata = {} -- clear as the interface may have been reset
        text = '(No network)'
    end

我是用io.lines函数打开文件的。印象中这家伙是会自动关闭文件的啊，我也没办法再手动关闭是不？不过既然是这地方的问题，那么再去仔细看看文档好了：

Opens the given file name in read mode and returns an iterator function that works like file:lines(···) over the opened file. When the iterator function detects the end of file, it returns nil (to finish the loop) and automatically closes the file.

什么？and automatically closes the file？也就是说如果文件没读完的话……

于是我立即打开 ilua 写下：

for i in io.lines('strprint.lua') do print(i) if i:sub(1,1) == '-' then break end end

执行完毕，再去 htop 里查看文件描述符，果然没关！

好吧，又一坑。于是改成像 C 语言中那样显式打开和关闭文件了（相关提交在此）。过几天再看看问题有没有完全解决。

2014年1月11日更新：后来还是依靠 inspect.lua 才完全解决我的 Awesome 配置中的内存泄漏。

假设myfunc已经在其它地方定义，你觉得以下两段代码作用一样吗？

local t = {}
local item = myfunc()
table.insert(t, item)
item = nil

local t = {}
table.insert(t, myfunc())

代码一把函数的结果存放在临时变量里再作为参数传给其它函数，代码二直接将函数返回值作为参数传给其它函数。看上去，代码二比代码一简短了一些，少用了个变量名。

可是，如果myfunc返回多个值的话，代码二将不能正确运行，因为myfunc的所有返回值均会传递给table.insert。和其它语言完全不一样。我想，这个应该是「真正的」多返回值吧？——它返回的不是像其它语言那样的是一种复合类型的值，而真真正正的是多个值，以一种超乎直觉的方式存在着。

所以，要么总是通过赋值来指定需要的返回值，要么不要给已有函数增加新的返回值。我倾向于前者，因为，你记得你所有用到的函数的返回值数目吗？

协程只能在 Lua 代码中使用

协程（coroutine）应该是 Lua 最大的卖点之一了。可是，它有一个在文档中根本没有提到过的弱点：只能在 Lua 代码中使用，不能跨越 C 函数调用界限。也就是说，从 C 代码中无法直接或者间接地挂起一个在进入这个 C 函数之前已经创建的协程。而 Lua 本身作为一种易于嵌入的语言，必然不时与 C 打交道。

比如以下程序：

c = require('c')

co = coroutine.create(function()
  print('coroutine yielding')
  c.callback(function()
    coroutine.yield()
  end)
  print('coroutine resumed')
end)

coroutine.resume(co)
coroutine.resume(co)

print('the end')

C 模块代码：

#include<stdio.h>
#include<stdlib.h>
#include<lua.h>
#include<lualib.h>
#include<lauxlib.h>

static int c_callback(lua_State *L){
  int ret = lua_pcall(L, 0, 0, 0);
  if(ret){
    fprintf(stderr, "Error: %s\n", lua_tostring(L, -1));
    lua_pop(L, 1);
    exit(1);
  }
  return 0;
}

static const luaL_Reg c[] = {
  {"callback", c_callback},
  {NULL, NULL}
};

LUALIB_API int luaopen_c (lua_State *L) {
  luaL_register(L, "c", c);
  return 1;
}

在官方版 Lua 以及 LuaJIT 中会出现「attempt to yield across metamethod/C-call boundary」错误。只有打过 Coco 补丁的版本才能正常执行。

>>> lua5.1 co.lua
coroutine yielding
Error: attempt to yield across metamethod/C-call boundary
>>> luacoco co.lua
coroutine yielding
coroutine resumed
the end
>>> luajit co.lua
coroutine yielding
Error: co.lua:6: attempt to yield across C-call boundary

据说 LuaJIT 已经解决了这个问题，不过我想他们说的是内建函数支持 yield 而已。

在 Lua 5.2 中，提供了新的 API 来支持在 C 中 yield。不过，既然是 C API，当然得改代码，而且看上去比异步回调更复杂。

幽灵一般的 nil

nil 相当于 Python 中的 None 或者 C 中的 NULL，表示「没有这个值」的意思。但是，一个神奇的地方在于，所有未定义的变量的值均为 nil。所以，在 Lua 中有空值 nil，但是有时它又不存在：当你尝试把 nil 值存到表里时，它会消失掉。

另外，当 nil 被传入接受可变参数的函数时，官方版 Lua 只能通过select('#', ...)获取参数个数。至于 LuaJIT，很遗憾，没有办法。

LuaJIT 中还有这样一个值，它等于 nil。但是根据 Lua 语言标准，只有 false 和 nil 的值为假。于是，在 LuaJIT 中，两个相等的量，却有着不同的真值。它就是 ffi 中的 NULL 指针。

在另外一些地方，也会有其它各种库定义的 null 值，比如ngx.null、cjson.null。这些空值之间哪些相等哪些不等就难说了。

没有 continue

Lua 一直不肯添加 continue 关键字。作者声称不添加不必要的特性。请问有谁认为「repeat ... until」结构比「continue」关键字更有必要？于是，凡是本来应当使用 continue 的地方，都不得不弄一个大大的 if 语句：

for line in configfile:
  if line.startswith('#'):
    contine

  parse_config(line)

在 Lua 中只能这么写：

for line in configfile do
  if string.sub(line, 1, 1) == '#' then
  else
    parse_config(line)
  end
end

所以，Lua 代码的左边空白的形状都是些 45° 或者 135° 的斜线。

错误信息的表达

Lua 中，习惯的错误表达为，返回两个值，第一个为 nil 表示发生了错误，第二个为字符串，是错误信息。字符串形式的错误信息显示给用户挺不错的（想想微软喜欢的长长的错误号）。可是，程序里只好用模式匹配去判断是否发生了指定类型的错误。这多么像 VimScript 中的错误处理啊。journald 取代 syslog 的重要原因之一就是它存储的是结构化文本。Lua 错误处理最伟大的一点则是我们又回到了字符串匹配。别以为你可以返回一个 table 或者 userdata 来表达错误。很多库可不这么认为。当你的结构化错误被..连接时你就会发现这厮没救了。

下标

别的编程语言下标都从 0 开始。Lua 为了更「人性化」，其下标从 1 开始。其实写多了也能习惯，除了当通过 ffi 获得一个 C 数组的时候……

提前返回

return 语句之后必须跟着一个end。于是，很多提前返回的时候只能写do return end。有意义么？

方法调用

访问表或者 userdata 的域使用一个点.，连接字符串使用两个点..。而方法定义和调用时，你需要垂直放置的两个点——冒号:。它与域访问的一个点相比，也就多了四个像素，显示器不干净或者精神不佳的时候就得小心了！

面向对象

Lua 是不支持面向对象的。很多人用尽各种招术利用元表来模拟。可是，Lua 的发明者似乎不想看到这样的情形，因为他们把取长度的__len方法以及析构函数__gc留给了 C API。纯 Lua 只能望洋兴叹。

结论

Lua 只适合写写配置。做纯计算用用 LuaJIT 也不错。复杂的逻辑还是交给专业点的语言吧。

看到别人的 Racket 版，心里痒痒，写了个 Haskell 版。只用了尾递归，没用什么高级特性。题目地址。

calc3xp1 :: Int -> Int
calc3xp1 n | even n = n `div` 2
           | otherwise = 3 * n + 1

countlen :: Int -> Int
countlen = countlen_tail 0

countlen_tail :: Int -> Int -> Int
countlen_tail c n | n == 1 = c
                  | otherwise = countlen_tail (c+1) $ calc3xp1 n

findmax :: Int -> Int
findmax = findmax_tail 1 1 1

findmax_tail max maxn n final | n >= final = maxn
                              | otherwise = if new_len > max
                                               then findmax_tail new_len n n' final
                                               else findmax_tail max maxn n' final
                                             where new_len = countlen n
                                                   n' = n + 1

main = print $ findmax 1000000

>>> time ./3xp1
./3xp1  14.92s user 0.02s system 99% cpu 14.955 total

Erlang 版本直接照抄 Haskell 版：

-module(e3xp1).
-export([main/1]).

calc3xp1(N) when N rem 2 == 0 ->
  N div 2;
calc3xp1(N) ->
  3 * N + 1.

countlen(N) -> countlen_tail(0, N).

countlen_tail(C, 1) ->
  C;
countlen_tail(C, N) ->
  countlen_tail(C+1, calc3xp1(N)).

findmax(N) ->
  findmax_tail(1, 1, 1, N).

findmax_tail(_, Maxn, N, Final) when N >= Final ->
  Maxn;
findmax_tail(Max, Maxn, N, Final) ->
  Newlen = countlen(N),
  if Newlen > Max -> findmax_tail(Newlen, N, N+1, Final);
    true -> findmax_tail(Max, Maxn, N+1, Final)
  end.

main(_) ->
  io:format("~B~n", [findmax(1000000)]).

它在六分钟后还没能输出结果……

>>> time escript e3xp1.erl
^C
escript e3xp1.erl  374.55s user 0.94s system 99% cpu 6:15.76 total

Racket 版在同一机器上用时：

>>> time racket 3xp1.racket
racket 3xp1.racket  3.22s user 0.22s system 99% cpu 3.448 total

这是为什么呢？

PS: C 更快，不到半秒就搞定了……

更新：又试了试 Lua 版本的，和 Haskell 版速度相当。但是——LuaJIT 竟然只 2.4s 出结果，因为换了机器，所以实际上它应该比 Racket 版快一倍以上。

再次更新：Erlang 版编译后还是挺快的：

>>> erlc e3xp1.erl
>>> time erl -noshell -s e3xp1 main -s init stop
erl -noshell -s e3xp1 main -s init stop  5.59s user 0.01s system 84% cpu 6.608 total

不过，它什么事都不干启动后立即停止也花了一秒多，比 Java 更厉害：

>>> time erl -noshell -s init stop
erl -noshell -s init stop  0.06s user 0.01s system 6% cpu 1.077 total

2014年12月24日更新：Rust 版也非常快，而且写起来舒服：

fn calc3xpi(n: uint) -> uint {
    if n % 2 == 0 {
        n / 2
    } else {
        3 * n + 1
    }
}

fn countlen(&n: &uint) -> uint {
    let mut c = 0;
    let mut x = n;
    while x != 1 {
        c += 1;
        x = calc3xpi(x);
    }
    c
}

fn findmax(n: uint) -> uint {
    range(1, n).max_by(countlen).unwrap()
}

fn main(){
    let mut stdout = std::io::stdout();
    stdout.write_uint(findmax(1000000));
    stdout.write_char('\n');
}

GTK 右键的输入法菜单中有一项「IPA」，用于输入国际音标的。不过为了输入几个国际音标去够鼠标点菜单太麻烦了。既然是输入，交给我最爱的 fcitx 输入法去处理就好了嘛。

GTK 的国际音标输入很简单，每一两个字符对应一个音标字符。不过，因为通常是连续输入好几个国际音标，因此简单地使用 fcitx 的「快速输入」模块的话，每输入一个得打一次前缀，太痛苦了。于是我用 fcitx 的 Lua 模块来做。

要注意的是，fcitx 的 Lua 支持默认没有开启，编译时需要在 cmake 参数中加上-DENABLE_LUA=On。Arch 用户可以从 archlinuxcn 源安装 fcitx-lilydjwg-git。其它发行版可能有单独的fcitx-lua包，也可能需要自行编译。

安装方法很简单，把ipa.lua放到~/.config/fcitx/lua目录下即可。然后按Ctrl-5（默认）重新加载 fcitx 配置即可。

使用方法是，使用预定义的快速输入快捷键（默认是;）进入「快速输入」模式后，输入命令前缀yb，然后按 GTK 那个 IPA 输入法的方式输入即可，按空格提交输入。不知道对应关系的可查看脚本源码。

[ˌðæts ˈɔːl ˈθænks].

Suǒwèide 「pīnyīn shēngdiào shùzì zhuǎn zìfú」 jiùshì bǎ 「pīnyīn+shùzìdiàbiǎo de shēngdiào」 zhuǎnchén Unicode zìfú biǎoshì.

所谓的「拼音声调数字转字符」就是把「拼音+数字表示的声调」转成 Unicode 字符表示，为了是做成 fcitx 的拼音输入插件，以方便输入上段的内容。

算法是参考别人的，把所有带声调的音节后缀穷举出来再转换，简单暴力好用。我改写的 Python 3 版在 github/winterpy 上，支持大写和「ü」。

为了在 fcitx 中使用，我又改写了一 Lua 版本，代码如下：

#!/usr/bin/env lua

-- http://www.robertyu.com/wikiperdido/Pinyin%20Parser%20for%20MoinMoin

-- definitions
-- For the pinyin tone rules (which vowel?), see
-- http://www.pinyin.info/rules/where.html

local strsub = string.gsub
local _strupper = string.upper

-- map (final) constanant+tone to tone+constanant
mapConstTone2ToneConst = {
  n1 = '1n',
  n2 = '2n',
  n3 = '3n',
  n4 = '4n',
  ng1 = '1ng',
  ng2 = '2ng',
  ng3 = '3ng',
  ng4 = '4ng',
  r1 = '1r',
  r2 = '2r',
  r3 = '3r',
  r4 = '4r',
}

-- map vowel+vowel+tone to vowel+tone+vowel
mapVowelVowelTone2VowelToneVowel = {
  ai1 = 'a1i',
  ai2 = 'a2i',
  ai3 = 'a3i',
  ai4 = 'a4i',
  ao1 = 'a1o',
  ao2 = 'a2o',
  ao3 = 'a3o',
  ao4 = 'a4o',
  ei1 = 'e1i',
  ei2 = 'e2i',
  ei3 = 'e3i',
  ei4 = 'e4i',
  ou1 = 'o1u',
  ou2 = 'o2u',
  ou3 = 'o3u',
  ou4 = 'o4u',
}

-- map vowel-number combination to unicode
mapVowelTone2Unicode = {
  a1 = 'ā',
  a2 = 'á',
  a3 = 'ǎ',
  a4 = 'à',
  e1 = 'ē',
  e2 = 'é',
  e3 = 'ě',
  e4 = 'è',
  i1 = 'ī',
  i2 = 'í',
  i3 = 'ǐ',
  i4 = 'ì',
  o1 = 'ō',
  o2 = 'ó',
  o3 = 'ǒ',
  o4 = 'ò',
  u1 = 'ū',
  u2 = 'ú',
  u3 = 'ǔ',
  u4 = 'ù',
  v1 = 'ǜ',
  v2 = 'ǘ',
  v3 = 'ǚ',
  v4 = 'ǜ',
}

function strupper(c)
  local specials = {
    ['ā'] = 'Ā',
    ['á'] = 'Á',
    ['ǎ'] = 'Ǎ',
    ['à'] = 'À',
    ['ē'] = 'Ē',
    ['é'] = 'É',
    ['ě'] = 'Ě',
    ['è'] = 'È',
    ['ī'] = 'Ī',
    ['í'] = 'Í',
    ['ǐ'] = 'Ǐ',
    ['ì'] = 'Ì',
    ['ō'] = 'Ō',
    ['ó'] = 'Ó',
    ['ǒ'] = 'Ǒ',
    ['ò'] = 'Ò',
    ['ū'] = 'Ū',
    ['ú'] = 'Ú',
    ['ǔ'] = 'Ǔ',
    ['ù'] = 'Ù',
    ['ǜ'] = 'Ǜ',
    ['ǘ'] = 'Ǘ',
    ['ǚ'] = 'Ǚ',
    ['ǜ'] = 'Ǜ',
  }
  if specials[c] then
    return specials[c]
  else
    return _strupper(c)
  end
end

function ConvertPinyinToneNumbers(lineIn)
  local lineOut = lineIn

  -- first transform
  for x, y in pairs(mapConstTone2ToneConst) do
    lineOut = strsub(strsub(lineOut, x, y), strupper(x), strupper(y))
  end

  -- second transform
  for x, y in pairs(mapVowelVowelTone2VowelToneVowel) do
    lineOut = strsub(strsub(lineOut, x, y), strupper(x), strupper(y))
  end

  -- third transform
  for x, y in pairs(mapVowelTone2Unicode) do
    lineOut = strsub(strsub(lineOut, x, y), strupper(x), strupper(y))
  end

  return strsub(strsub(lineOut, 'v', 'ü'), 'V', 'Ü')
end

local function main()
  local lineOut
  for lineIn in io.stdin:lines() do
    lineOut = ConvertPinyinToneNumbers(lineIn)
    print(lineOut)
  end
end

main()

很可惜的是，fcitx 的 Lua 模块目前不支持屏蔽数字键选字，所以暂无法在 fcitx 中使用。