IT牛人博客聚合

最近几天优化了一下 pbc 。

这是一个大改动，所以写 blog 记录一下。

首先，我为 rmessage 定制了一个 heap alloc ，在使用 rmessage 解包的时候不再调用系统的 malloc 。而是从一个连续内存 heap 上取用内存。这样在删除 rmessage 对象时也会更快。因为只需要把 heap 回收即可。

当然这样会导致 rmessage 解包时用到的内存增加。对于内存紧张，性能关键部分，我还是推荐 pattern 模式。虽然比较难用，但可以保证时间和空间性能。

另外，我增加了 upb 的 Event-based parsing 模式，见新增接口 pbc_decode 。

不过我认为这个 ap

查看全文: http://www.udpwork.com/item/7185.html

如果你在同一个进程里有多个 lua state , 它们需要共享大量的只读数据, 那么可能就不希望在每个 state 启动的时候都加载和解析一遍这些数据.

所以我们需要一个共享只读数据的方法。

前段时间，我实现了一个 共享内存服务 ，这个可以保证共享内存的安全读写。不过，如果数据是只读的，那么就不需要这么复杂了。

我们只需要把数据加载到一个 lua state 中，其它的同一进程内的 state 通过 C 接口去读数据就可以了。

今天，我做了简单的实现，放在了 github 上。

目前可以支持 nil number boolean function table 的数据交换。

function 交换有一些限制，不可以绑定

查看全文: http://www.udpwork.com/item/7138.html

最近入手了一台惹人争议的手机，一款在3月26号刚刚发布的手机–国虹水滴，这个内存是256，实在是太低了，而且一开机内存就占用了不少。 

最近一直在折腾这个水滴。。。 

本来是安装了个虚拟内存软件，可是这个软件时常发生意外终止的情况，所以就另想办法了。 

凭着对Linux的了解和使用经验，完全用超级终端手动给水滴添加swap 虚拟内存，并且不需要给SD卡重新分区。在linux中，谁都知道有个swap交换分区。 

所以我采用创建一个块设备文件的方式，在文件中启用swap交换分区，给水滴手机分配了虚拟内存（水滴的系统是Android 2.3.6）。当然，首先必须确保手机拥有ro

查看全文: http://www.udpwork.com/item/7168.html

虽然今天发了 twitter ，以及向 lua mailling list 里投递了消息，不过想想还是写一篇 blog 记录一下。

Lua 只支持一种 number ，默认是 double 类型。虽然你可以通过修改 luaconf.h 里的定义，把 lua number 改成 int64 。但是为了 int64 类型而放弃浮点数，恐怕不是大多数人想要的。

int64 通常用在 uuid 上，也就是说不需要对其数学运算，只需要可以比较就好了。我以前最喜欢的做法是用 8 bytes 长的 string 来表示一个 int64 。这样，即可以做唯一的 key 用，又不用做复杂的扩展。

在 pbc 的 lua binding 库 中，

查看全文: http://www.udpwork.com/item/7108.html

我们用 lua 做主要的项目开发语言，一直有同学希望可以在 IDE 里单步跟踪调试 lua 代码。我总觉得这个坏习惯是被 Windows 带坏的。当然，很多年前，我也尝试过编写一个图形界面的 debugger 。后来这玩意半途而废了。因为我觉得没啥实用价值，需要这样去调试 lua 程序的程序员反正也写不好 lua 程序。宁可不要这种工具让 lua 程序员的代码质量能提高一点。

后来过了两年，还在网易时，又有同学要求有一个方便点的调试器。我又写过一个远程调试器，gdb like 的界面，用 C/S 方式调试，并用 GTK 配了一个 GUI 的 client 。主要就是远程设置断点，观察变量等。有兴趣的同学可以看这一篇。

这套东西

查看全文: http://www.udpwork.com/item/6857.html

今天花了将近 3 个小时帮同事看一个崩在 lua VM 中的 bug 结果打乱了进度，没有在年前把预想的东西做完。其实说起来这不是个大问题，以前也碰到过。我检讨自己没有在看到出错时的调用栈时去看一眼 lua 相关的代码。如果是那样，因为以前遇到过同样的问题，所以就可以条件反射出问题原因，而不用荒废宝贵了数小时时间了。

唉，这下整合的进度没接上，过年不能自己一个人接着做下面的活了。

下面记录一下这个 bug ，提醒自己第三次遇到时不用再花时间找问题：

问题的缘由是因为的不同的 lua 扩展库链接的时候多链接了一份 lua 库，导致进程内有超过一份 lua 库。这是在写 Makefile 时不小心造成的。知道原因后自然很容易解决。

查看全文: http://www.udpwork.com/item/6725.html

lua 5.2 正式发布了，对于 lua 语言本身的修改，重中之重就是对 environment 这个概念的修改。

可以说， 5.1 以前的 environment 已经没有了。environment 对于制造一个安全的沙盒（或是实现 DSL）是一个很重要的语言特性，我以前很喜欢使用，但也很容易用错。这次的修改我认为是一个谨慎的决定，并使得 lua 语言更为精简和严谨了。

我这样理解 5.2 中的 environment 。本质上，lua 取消了原有意义上的 environment 。所以我们可以看到 C Function 不再有环境了。function 、在 lua 中称为 closure ，仅仅只是函数体和 upvalue

查看全文: http://www.udpwork.com/item/6598.html

前几天写的 pbc 初衷就是想可以方便的 binding 到动态语言中去用的。所以今天花了整整一天自己写了个简单的 lua binding 库，就是很自然的工作了。

写完了之后，我很好奇性能怎样，就写了一个非常简单的测试程序测了一下。当然这个测试不说明很多问题，因为测试用的数据实在是太简单了，等明天有空再弄个复杂点的来跑一下吧。我很奇怪，为什么 google 官方的 C++ 版性能这么差。

我的 lua 测试代码大约是这样的：

local protobuf = require "protobuf"

addr = io.open("../../build/addressbook.pb","rb")
buffer = addr:

查看全文: http://www.udpwork.com/item/6526.html

几个月以前，在我在 blog 上曾谈及 Lua 5.2 的改进。它可以用来实现抢占式多线程 。

周末休息，我把这桩事挖出来娱乐一下，花了一整个晚上做了实现。把 lua 的每个线程锁定在独立的 lua state 中，强迫线程之间通过消息管道的方式通讯。经过测试，Lua 5.2 每个独立的 state 占用的内存很小。通过自定义 alloc 函数可以测算出，一个干净的 32bit state ，不含任何库函数时，占用内存量在 2K 以下(1726 bytes)。如果加载基本库，也仅仅占用不到 4K (3265 bytes)。若把所有 lua 官方标准库加载进来，才会上升到 10K 以上(12456 bytes)。

对于 luaji

查看全文: http://www.udpwork.com/item/6264.html

在我看过的为数不多的电影中，对我影响最大的，是《黑客帝国》三部曲；而这个系列电影对我影响最大的场景，并非是人类和机器的战争，而是人类的叛徒在接受机器人杀手史密斯引诱时的那一段。这位自觉苦不堪言又前途渺茫的男士，用叉子叉起一块牛肉时说：我知道这块牛排不是真的，但我嘴里那种感觉却是真的（大意如此）。

这句台词的震撼之处在于：牛肉是虚拟的，但感觉却是真实的。那么，究竟什么才是真实的呢？究竟是客体存在是一种真实，还是主体感觉才是一种真实？

这是在描绘某种未来么？倒不见得。如果这是未来的话，事实上，我们就生活在这样一个未来中：我们用我们真实的感觉在体验某种程度上一种虚拟的现实。这，就是高度发达的数字媒介。

其实对于媒体，有这么一句比方：

查看全文: http://www.udpwork.com/item/6181.html

最近看了很多虚拟名片的交换应用，例如国外的Bump，国内的名片碰碰，还有基于LBS的在这儿，应用模式都基本一致，通过GPS、WIFI、移动基站甚至近场通讯等方式确定你的位置，然后查找周围也使用同款应用的用户，大家可以很快速地交换信息。

毫无疑问名片交换存在着巨大的市场，每跑一场活动都能收到一堆名片，假设这些名片都能无纸化对环保也是功德一件。虚拟名片能够提供的价值包括：毋须经过纸质中转直接进入设备，基于移动终端与数据网络可以便捷使用，电子化名片方便管理使用，例如可以直接拨打电话或发送邮件，还可以实现一对多的名片交换，这在人比较多的活动很有用。

看到虚拟名片能够为大家创造的价值，似乎你已经准备开始欢呼雀跃了，但事情似乎总不会那么简单

查看全文: http://www.udpwork.com/item/5737.html

国内IT舆论其实有一个不太好的倾向，就是如果国内数字公司和国外数字公司起纷争，就是国内的不好；如果官方媒体和数字媒体起纷争，那就是官方媒体不好。比如百度就是个例子。只要百度和谷歌有点什么矛盾，必定是百度的不是，而央视一批起百度来，那就是央视的不是了。这在我看来，纯属情绪说话。

这两日央视又开始狠批百度，说百度推广有大量不实广告信息，隔天又聚焦到百度贴吧上。我注意到，网上有一种说法是：央视你自己不照照自己，现在批百度，不是五十步笑百步么？（大意如此）。另外一种说法则是：央视推了一个搜索，所以要批一批百度，为自家搜索清道。这两种说法，我以为，都是很有问题的。

我基本上完整地看了央视批百度推广的那档节目，也学到了不少百度的新招术，比如

查看全文: http://www.udpwork.com/item/5686.html

Lua 5.2 的开发进度可以回溯到 2010 年 1 月。漫长的流程到今天已经快两年过去，终于等到了 beta 版。我十分期待它可以在 2011 年内正式发布。在这几经折腾的两年里，许多新特性企图挤进 5.2 版，又最终被否决。

当我们审视改进列表，似乎看不到太多耳目一新的东西。但如果仔细阅读一下源代码，就会发现，大部分地方都重新实现过了，以配合这些表面上看起来不大的修改。如果你对 Lua 有足够理解，会发现，这次最激动人心的改进是 "yieldable pcall and metamethods" 。官方也把之列为 Main changes 第一条。语言上的重大新特性 goto 却被列在末尾。

当然，这只是我粗浅的理解而已。

查看全文: http://www.udpwork.com/item/5616.html

最近 Lua 社区非常活跃。6 月 22 日发布了 Lua 5.2.0 (beta-rc2) 。今天(6 月 24 日) 发布了 LuaJIT-2.0.0-beta8 。

虽然 luajit 和 lua 5.2 还有点小矛盾，luajit 没有完全支持 lua 5.2 的迹象。不过，这些对 Lua 社区都是好消息啦。可能对于 lua 用户会有点小纠结，到底是追随官方的 5.2 版呢，还是去用性能更好的 luajit2 。我比较在意性能，暂时先投靠 luajit 了。反正和 5.2 区别也不大。更重要的是，luajit2 提供的 ffi 库相当之好用，极大的减少了我们写 C 库的 lua binding 的负担。从某种角度可以看到另

查看全文: http://www.udpwork.com/item/5347.html

我这里说的程序员搞投资，不是说投资自己的精力去写文档、写程序甚至做产品，而是投资Bitcoin。更理性点说，他们是在非理性的炒作Bitcoin。
是的，很多程序员都投资Bitcoin去了，生怕哪天世界是Bitcoin一统天下，自己也会像没有抢到地一样必须卑躬屈膝的向地产商们送钱一样。
他们靠在圈内的影响力以及诡辩能力，去说服自己和他人，去抢BTC。然而，事情并没有那么简单：
Bitcoin生产BTC的速度受时间限制，总量受控，永远也不会超过2100万个BTC，就意味着它稳定吗？不会通货膨胀就意味着它能够解决现有货币系统的缺陷吗？我今天买一个面包，要1BTC，每天可能就是0.00001个BTC了。我不知道这是膨胀还是紧缩，但我知道这个

查看全文: http://www.udpwork.com/item/5191.html

前几天分析了 lua gc 的实现细节。这里先汇总一下：

Lua GC 的源码剖析 (1)

Lua GC 的源码剖析 (2)

Lua GC 的源码剖析 (3)

Lua GC 的源码剖析 (4)

Lua GC 的源码剖析 (5)

Lua GC 的源码剖析 (6)

btw, 阅读 lua 的代码是段很有趣的经历。但如果是重头读 lua 的源码，建议从简单的部分读起。gc 恰巧是最难的一段。LuaJIT 的作者 Mike 在这方面很有发言权，他在回答 Which OSS codebases out there are so well designed that you would consider them 'must re

查看全文: http://www.udpwork.com/item/4719.html