论我遇见的像是那种只活在自己世界里一样的…

好久好久没有更新过 blog 了…非要说的话,还是时代变了,自己也变了。但偶尔实际上还是会有想说点什么的想法。今天的话,其实是憋在心里很久想说的,当然其实也是想说给某些人听的,但是因为很久以前有段时间发觉自己讲话越来越难听,时常和别人起争吵。自从意识到这个事情之后…我有时候就想尝试不要那么激烈的讲。

那么这个标题……和选择发在这个文章分类到底算是有什么关系呢?

首先我得说,我在上大学的时候,是真的见过民科的。详情已经记不得了,但是那会还真的是年轻,只是走在三角地附近,突然被一个大叔搭讪,问能不能帮他输入一些东西。我本来以为也就是帮忙打字,所以就答应了他。但是带他到实验室的工位之后,却意外发现他让我打的是什么什么数学定理的证明。内容大概只有一页纸,已经不记得是什么定理了,但是反正是个有名的未证明的定理,只要看过科普的话就应该能见过的那种,也许是歌德巴赫吧。然后我这会儿,内心是尴尬的,可是又不想弄得非常麻烦还要讨论是否正确,毕竟我内心觉得和他争论这个事情可能很难能说服他,所以就干脆想赶快打完完事。结果输入的过程中还能发现非常低级的错误(等式左右算错那种)……因为影响输入所以还问他怎么办。结果还被他赞同了一下……最后总之赶快输入完打印了完事,结果他还塞给我50块钱说很有启发就跑走了,连我拒绝收钱的机会都没有给我。

非要说的话,十几年过去了…我是没有想到现在还能看见类似民科气质的人。

我一直有订阅着某论坛的某个版面的RSS,曾经还经常去帮他们回答一些 Fcitx 的配置问题,但是这么多年没见了,突然某天开始这个版面就开始有几个活跃的人。让我想起了那个我曾经遇见过的民科。

那么说到底我这里说的是什么…就是那种觉得自己就是正确的,有点完全活在自己的世界里的那种。当然,这里有几个不同的人,真的要说让我感到尴尬的点也不一样。我们只是说其中的某个提出了一个输入法方案的人。

我觉得他提出的那个方案可以说是有用的,但是他自己在推广的时候……实在是吹的太过头了。为什么我要说是像那个民科一样的感觉呢,就是总是一种“我真的是怀才不遇,四处碰壁”,但是“对的是我,错的是这个世界”。

可惜没人相信这种输入法的便利性、好处、以及潜在的市场优势。

我不太想过于直白的说明是谁但…光看他的回帖有多少个叹号……就知道大概是个什么感觉了。

但有的事情,让我不吐不快的就是,开源世界并不是这样的啊…开源世界的开始都是孤独的。这么长时间以来我自己很赞同 Linus 曾经在某个采访中说过的:

In many ways, I actually think the real idea of open source is for it to allow everybody to be “selfish”, not about trying to get everybody to contribute to some common good.

In other words, I do not see open source as some big goody-goody “let’s all sing kumbaya around the campfire and make the world a better place”. No, open source only really works if everybody is contributing for their own selfish reasons.

现实是,我其实觉得实现一下这个输入法是一件很有意思的事情,但是提出这个的人…讲起话来就让人感到一种被道德绑架的难受的感觉。

但正因为我已经开始写了,所以就实在是有点难以抑制的想把这些话说出来。

Posted in fcitx development | Tagged , | Leave a comment

Job DSL vs Pipeline in Jenkins

我自己的 CI 长久以来都是手动配置 Free-Style Project,有很多重复的部分很不方便统一修改。所以就打算搞得比较自动化一点方便批量修改任务,一开始是想用什么 Template 之类,但是后来就发现了 Job DSL 和 Pipeline。

姑且来说,这两个解决的问题有重合的部分,但是也有不一样的地方。Pipeline 基本就是用一个 Groovy 的子集(还是相似的东西?),来描述一个 Job,支持的功能比较多。而 Job DSL 是用 Groovy 的一个脚本来生成 Job。实践当中你可以两个都用。

Pipeline 最基本的用法就是在代码库里面放一个 Jenkinsfile,里面描述 pipeline。当然这么做是有缺点的,因为你还是没有自动化多个不同的项目的任务生成。总之是一个类似把 Jenkins 当作 travis 的用法。

我踩的第一个坑就是没有意识到这两个东西虽然都是 Groovy,但是使用的是两套 API。需要分别查看各自的文档。我犯的一个错误就是把 Pipeline 里面的用法放到 Job DSL 里面用……结果当然是没法通过了,而且我还一直没有意识到这个问题折腾了好久。

总之,最后总算是搞清了这个问题,然后我发现我一开始写的 Job DSL 还是生成了 Free Style Job,所以开始思考我到底要不要用 Pipeline。有这么几个问题,例如,我用的一个 Jenkins Plugin CMake 还不支持 Pipeline,所以就有些纠结到底要不要用这个。

我作为参考的 KDE 是选择都用的,但是和编译工具链的胶水层是通过自己写的 Python 脚本来实现(当然我相信他们是有正当的理由)。反过来说我使用那个 CMake 插件也并没有特别实现什么…所以我其实并不需要 Pipeline 提供的复杂功能。Job DSL 的支持疑似比较全,所以我的一个结论就是,如果从前你就用 Free-Style Job 并且你也没有特别的需要新的功能,用 Job DSL 生成 Free-Style Job 就好。Pipeline 才能解决你的问题的时候,或者想要在源码库里面放个 Jenkinsfile 的方式来定义编译过程,你可以考虑 Pipeline。

Posted in Linux | Tagged , , | Leave a comment

纯粹不吐不快

更新:好吧原文作者说是 “gnome control center”。

后文可以略过了。

http://forum.ubuntu.org.cn/viewtopic.php?t=486270&p=3200398#p3200398

下面是原文

其余内容不论,我们单说第一句:「前一阵子 Ubuntu 的预设输入系统从 IBus 改为 Fcitx,但因后者不支持 gcc,搞得天下大乱,于是 Ubuntu 17.10 又换回 Ibus 了。 LZ 建议把 ibus 删除掉换成 fcitx,并不见得问题就消失了。」

不支持 gcc???黑人问号???

其一、世界上绝大多数发行版,包括 ubuntu 都是默认 gcc 编译器。debian 的迁移到 clang 的进程虽然一直有提但是绝对还没有完成,而且也只是测试是否「可以编译」,作为 debian 下游的 ubuntu 也显然还没有迁移到非 gcc 编译器。打包 fcitx 的人我都基本认识大半,从来没人和我说 fcitx 有什么不能在 gcc 上编译的问题。

突然来这么一发指责,你得给我拿出证据来。

其二、ubuntu 作为一个二进制发行版,原本就不需要用户从代码编译,你是从哪发现不支持 gcc 的?

Posted in fcitx development | Tagged | Leave a comment

The Road to Fcitx 5: 5. Good news for people who use multiple display server

A big refactor in fcitx 5 is to enable it to support for multiple display server. This is not limited to X11 + wayland, but it means you can use fcitx with multiple X11 server. While such functionality may have limitation about your layout settings, but still it will work for most of cases.

qdbus-qt5 org.fcitx.Fcitx5 /controller org.fcitx.Fcitx.Controller1.OpenX11Connection :1

The support for multiple X connection exists in the code for long time but it didn’t expose to the world till the commit today.

With a simple dbus call above, you can open an new X11 connection to display server :1. The classicui window, XIM, or client that uses dbus protocol in it will be able to use the “right” window in the display server. Though, kimpanel will not be able to enjoy this.

To test this funtionality, try it with some simply client:

Xephyr :1
qdbus-qt5 org.fcitx.Fcitx5 /controller org.fcitx.Fcitx.Controller1.OpenX11Connection :1
DISPLAY=:1 openbox
DISPLAy=:1 xterm

And you’ll find out that you can type in the xterm :P.

Posted in fcitx development | Tagged , , | Leave a comment

当你 Debug 一门过气语言生成的代码里面产生的 memory leak 时会发生什么 (a.k.a. 不要修改 vala 返回的 strv 的 length)

(会被写成 blog 发出来。)

直接上一段代码。

var array = elements.to_array ();
array.length = -1;
return "(" + string.joinv (" ", array) + ")";

提问,这段代码有什么问题?

它会生成这样的代码。

_tmp32_ = gee_collection_to_array ((GeeCollection*) _tmp30_, &_tmp31_);
array = _tmp32_;
array_length1 = _tmp31_;
_array_size_ = array_length1;
array_length1 = -1;
_tmp33_ = array_length1;
_tmp34_ = array;
_tmp34__length1 = array_length1;
_tmp35_ = _vala_g_strjoinv (" ", _tmp34_, _tmp34__length1);
_tmp36_ = _tmp35_;
_tmp37_ = g_strconcat ("(", _tmp36_, NULL);
_tmp38_ = _tmp37_;
_tmp39_ = g_strconcat (_tmp38_, ")", NULL);
_tmp40_ = _tmp39_;
_g_free0 (_tmp38_);
_g_free0 (_tmp36_);
result = _tmp40_;
array = (_vala_array_free (array, array_length1, (GDestroyNotify) g_free), NULL);
_g_object_unref0 (elements);
_g_free0 (_base);
_g_free0 (_tmp0_);
return result;

那么你再猜猜?给你点提示。

static void _vala_array_destroy (gpointer array, gint array_length, GDestroyNotify destroy_func) {
    if ((array != NULL) && (destroy_func != NULL)) {
        int i;
        for (i = 0; i < array_length; i = i + 1) {
            if (((gpointer*) array)[i] != NULL) {
                destroy_func (((gpointer*) array)[i]);
            }
        }
    }
}


static void _vala_array_free (gpointer array, gint array_length, GDestroyNotify destroy_func) {
    _vala_array_destroy (array, array_length, destroy_func);
    g_free (array);
}

´_>` strv 是一个不能改变大小的 array ……那么你改了它的大小……free 它的函数没法正常工作……然后就会造成 leak ……

Posted in Linux | Tagged , | 1 Comment