依云's Blog

自打知道 FUSE 以来都觉得亲手写一个 FUSE 文件系统是很好玩的事情，但是因为没好的自己能够很快实现的点子所以一直没动手。前段时间需要从 Android xrecovery 备份中取得一旧版本的应用，才决定动手的，顺便也练习一下很久没怎么用到的 C 语言。至于为什么不用 Python，好像那个 Python 绑定不太稳定的样子，Python 3 版更是如此。而且我也不希望效率太差。

首先介绍一下，所谓的「dedupefs」，就是把 Android xrecovery 的「dedupe」备份格式的数据挂载成文件系统来查看。其实仅仅只是想查看的话，把那个 dedupe 目录下的东东 gcc 一下就可以创建和解开 dedupe 的备份了，只是占用很多磁盘空间而已。

dedupe 的格式很简单，一个文本文件描述文件信息（时间、路径、大小、类型等），一个目录里全是 sha256 命名的文件来存储文件的数据，以便在备份时不同的备份中的相同文件只保存一次。

FUSE 嘛，我好像从来没看到过完整一点的文档，就是官方 API 文档也经常语焉不详。dedupefs 是参考 rofs 写的。dedupefs 也是只读的。

挂载之前，先得把 dedupe 的纯文本格式处理一下。纯文本适合存储和人阅读，但是查询效率低下。我决定用更适合处理纯文本的 Python，把数据存储到 GNU dbm 键值对数据库中，然后 dedupefs 直接读取数据库就好了。（于是顺便学会了在 C 中使用 GNU dbm :-)）数据的组织方式如下：

• d + 文件路径：该目录下的文件名列表
• f + 文件路径：该文件的信息

这样要读取一个目录下的文件列表就查 d 开头的项，要取得一个文件的信息（stat）或者打开文件，就读 f 开头的。

下边是编码和调试过程中的经验与收获：

• GNU dbm 没说它是线程安全的，所以它不是线程安全的。但是 FUSE 又是多线程的（调试用的单线程模式我就不玩的），所以读取数据库时要加锁。
• GNU dbm 查询结果数据是要调用者来 free 的。
• 因为涉及到二进制数据交换（Python <-> C），所以要注意在结构体声明时围上#pragma pack(push, 1)和#pragma pack(pop)，以免对齐不一致造成数据错误。
• valgrind 用来诊断内存访问错误效果非常棒！
• FUSE 的struct fuse_file_info里有个fh域可以用来存文件描述符，这样就不用像 rofs 那样每次读取都要打开一遍文件了。
• FUSE 读取用的回调函数传的offset一定要用，要首先lseek(finfo->fh, offset, SEEK_SET);一下，不然指不定读取到什么地方的数据了。
• FUSE 文件系统可以忽略文件权限，所以自己不在open和access里判断的话，就可以访问到明明看上去不能访问的文件（这正在我想要的）。
• du 命令读取文件占用磁盘空间时使用了struct stat的st_blocks域。如果在 FUSE 程序里不管它的话，那么 du 将总是报告占用了 0 字节的空间……这里的块大小总是 512 字节。

第一次写 FUSE 程序，虽然文档差了一点，但用起来还是挺方便 =w=

哦对了，android-dedupefs 的仓库链接。

所谓「相见恨晚」，说的就是我第一次看到 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 也不错。复杂的逻辑还是交给专业点的语言吧。

经常地，程序在开始执行某项任务需要从文件读取数据。在任务完成后数据得到更新，新的数据会覆写到之前读取的文件中。怎么将数据写回到文件呢？一个直觉的方案是：

with open(datafile, 'w') as f:
  f.write(data)

在通常情况下，它能够正确地完成写回数据的任务。如果出于某种原因文件打开失败，通常也不会有人忘记处理。但是，当写入操作失败了呢？

时不时地编译程序看到 gcc 大把地警告：

警告：忽略声明有 warn_unused_result 属性的‘write’的返回值 [-Wunused-result]

在 Python 中，写文件时如果失败会抛出异常，上层的异常处理机制似乎能够作出相应的应对。但是，真的尽力了吗？

我也曾以为这样不会出问题。直到有一天，本地信箱里出现了这样的错误信息：

OSError: [Errno 28] No space left on device

可能是由于内核的某个 bug，我本来就所剩无几的 /home 分区没空闲空间了。一个 cronjob 在写回数据时发生异常。于是，新的数据没能写入文件。那旧数据呢？因为是以「写」方式打开文件，所以它也没了……

在那次事件之后，那段写回数据的代码变成了这个样子：

with open(datafile + '.tmp', 'w') as f:
  f.write(t)
# if the above write failed (because disk is full), the old data should be kept
os.rename(datafile + '.tmp', datafile)

注意：测试表明不使用with或者显式地关闭文件的做法是有问题的，即使在 CPython 中。

try:
  open('/dev/full', 'w').write('abc')
except:
  print('fine.')

在 Python 2.7 中会打印错误信息，Python 3.3.0 中无任何信息。都没有预料中的异常被捕获。

>>> python t.py
>>> python2 t.py
close failed in file object destructor:
IOError: [Errno 28] No space left on device

今天之所以写这个，是因为 Arch Linux CN 的群服务器遇到磁盘配额用尽的问题。XMPP 服务器 Prosody 在写入联系人信息时只写了一小部分，大部分数据丢失。这里有 bug 报告。

2013年7月21日更新：Sublime Text 2 作为商业软件，竟然不仅不采用「新建+重命名」的方式写入文件，而且连写入是否成功都不检查。难怪 Linux 版中文输入法的问题迟迟不修复，原来连造成用户数据丢失的问题都无所谓。

看到别人的 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');
}

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 中使用。

用于显示时，经常会遇到显示的文本太长需要截短的情况。如果是如 ASCII 这样的定长编码，截短到指定长度自然不成问题。可如果源字符串是 UTF-8 编码的呢？ANSI C 里只管字节不管编码，所以如果想只用 ANSI C 提供的功能的话，就只能自己写了。因为需求仅仅是截短字符串而已，也不要求多么精确，所以没有去做编解码，只是丢弃按字节截短后的字符串最后的无效编码而已。而且目标语种是 Lua，也不方便搞位操作。

查维基百科可知，UTF-8 多字节字符第一字节的最高两位为11，而其它字节的最高两位均为10。所以就把后面那些10xxxxxx连同最开始的11xxxxxx去掉好了。这样会多截掉一个多字节字符，但无所谓了。

function truncateUTF8String(s, n)
  local r = string.sub(s, 1, n)
  local last = string.byte(r, n)
  if not last then return r end
  while last >= 128 and last <= 192 do
    n = n - 1
    r = string.sub(r, 1, n)
    last = string.byte(r, n)
  end
  if last >= 128 then
    r = string.sub(r, 1, n-1)
  end
  return r
end

2012年9月27日更新：感谢Fermat618提供的思路，更新了更简洁、准确的代码如下：

function truncateUTF8String(s, n)
  local dropping = string.byte(s, n+1)
  if not dropping then return s end
  if dropping >= 128 and dropping < 192 then
    return truncateUTF8String(s, n-1)
  end
  return string.sub(s, 1, n)
end

今天看 Matz 的《Ruby编程指南》，遇到一个被称为「flip-flop」的奇特表达式：

在一个由条件式或循环所构成的上下文中，一个 flip-flop 由两个通过..操作符相连的布尔表达式构成。除非其左侧表达式为 true，否则一个 flip-flop 表达式就是 false，而且在左侧表达式为 true 之前，它的值都会是 false。一旦该表达式为 true ，那么它就会“flips”到一个持久的 true 状态。它会保持该状态，而且对其后续的求值也返回 true，直到其右侧表达式成为 true 为止。如果其右侧表达式为 true 了，那么该 flip-flop 就会“flops”回一个持久的false状态，对其后续的求值也返回false，直到其左侧表达式再次成为 true 为止。

[...]

Flip-flop 是一个非常晦涩的 Ruby 特性，因此最好不要在你的代码中使用它。但是它们并不是 Ruby 所独有的，Ruby 从 Perl 那里继承了这个特性，而 Perl 则从 Unix 的文本处理工具 sed 和 awk 那里继承了这个特性（注4）。Flip-flop 的初衷是在一个开始模式和一个结束模式之间匹配一个文本文件的行，而且这仍然是使用它们的有效方式。下面的这个简单的 Ruby 程序展示了一个 flip-flop，它逐行地从一个文本文件中读取内容，打印出含有“TODO”的行。它会不断地打印文本行，直到读入一个空行为止：

ARGF.each do |line|  # For each line of standard in or of named files
  print line if line=~/TODO/..line=~/^$/ # Print lines when flip-flop is true
end

作者还说很难正式地描述一个 flip-flop 的精确行为。但我不这么认为。

我想到了学习数字电路时遇到的各种触发器，于是乎，反复读了几次以上描述确定了 flip-flop 的行为到底如何后，列出了它的真值表，其中 A、B 为点两边的表达式的值（输入），Q 为其内部状态，Qn 就是 Q_next。

A   B   Q   Qn
0   0   0   0
0   0   1   1
0   1   0   0
0   1   1   0
1   0   0   1
1   0   1   1
1   1   0   1
1   1   1   0

然后和那些触发器的真值表对照，赫然发现它就是JK 触发器——

J   K   Q   Qn
0   0   0   0
0   0   1   1
0   1   X   0
1   0   X   1
1   1   0   1
1   1   1   0

看来 Matz 没学过数字电路 ;-)

PS: flip-flop 在电子电路中就是「触发器」的意思。。。