何事西风不待人

夏末秋初~乘着思念去找你~

2023-09-08T02:04:36.000Z

（本文有中度性描写）

大约一个月之前，我脑子里忽然冒出这样的想法：「如果再见不到纱夜猫，我要死掉了」。想来我和她已经半年多没有见过面了，上一次还是在寒假。本来以往2月底的 Reading Week，和暑假，理论上都是会去找她的，但由于种种原因都没有实现。于是直到我已经开始工作的时候，还是没有去找她。所以那一天，我立刻下定了九月 Labour Day 去 Boston 的机票，甚至咕掉了我一个月之前就买好票了的 Anime Toronto。

Day 0：忙碌的白天和安心的晚上

我定的票是周五晚上的，也就是说我一下班就得赶去飞机场。虽然在前一天晚上已经大抵收好了行李，但是有一些平常要用的东西，还是不得不走之前才能收起来。再加上还要稍微收拾一下家里，并且把垃圾扔掉，所以当天要做的事情也就多了起来。但很不巧的是，这天下午的会一个比一个长，于是只能在下班之后才开始收拾了，我中午点的打算下午吃的外卖甚至都没时间吃，那就带到机场吃吧。赶忙地收好东西之后准备出门，打开爪机发现飞机延迟了。我：好吧。把门锁好，带着东西往地铁站走。照着往常的路线，地铁转电车，晃晃悠悠到了湖畔，天和水都十分的澄澈，还有两只鸭子在游泳。

这时候已经没有去机场的轮渡了，只能走地下道，于是也就慢慢走了过去。然后发现飞机第二次延误了。这时候内心是很平静的。拿了票过了安检，便把食物拿出来慢慢地吃。接下来就是等了。好不容易上了飞机，第三次延误出现了，飞机上广播说要进行什么修理，然后我就看到右边有人在对机翼做什么，很暗，也看不清。但我的直觉就是很不妙，不会出什么问题了吧。

我：我草
我：它们在修飞机
我：呃
我：希望不要出什么问题

虽然理智告诉我，porter 从来没出过人命，但是我还是忍不住想，如果我死在飞机上了怎么办。我对我的女朋友们说：

我：看上去要飞了
我：动了
我：mua
我：爱你们

（后来鸟说她也很担心，害怕我出什么事情。我当时是抱着「我可能发完之后就死掉了」的这种想法给伊们发消息的。）幸好并没有发生什么 drama，最终还是平稳落地了。进了机场连上它的 wlan，收到纱夜猫和妹妹给我发的消息。妹妹说「希望姐姐能平稳降落w」，我回了一个「有哦w」。猫问我想吃什么，我说想吃 pocky（毕竟说好了要 pocky kiss 的），但是这样的零食很显然不能满足填饱肚子的需求，她提议吃麦当劳。过海关的时候甚至没有问我要去拜访的是何人。出来之后纱夜猫说她还在车上，我在机场门口等了一辆又一辆 shuttle bus，记不得是第三辆还是第四辆才是她坐的那一趟。透过车窗看到她的身影，然后看着车停下，她从上面下来，手插在兜里，然后又和我一起上车。一到车上就跟我抱在一起亲，感觉真的好开心。其实在下飞机之前，那种「再见不到就要死掉了」的感觉已经很淡了，甚至有一种「见到她真的会这么开心吗」的怀疑。但是一见面果然还是不一样啊。我看着她，对她说「猫猫好可爱啊，好喜欢猫猫」，她笑着问我「我们是第一次见面吗？」然后便被我索取一个吻。很快车就到站了，我问她「怎么感觉这么快呀」，她说「因为只有一站呀」，但是我想，是因为猫猫在，很开心，所以时间才会过得特别快吧。

下了车，穿过熟悉的公园（这条路我们已经走过无数遍了啊。），一起走到猫猫家里，她一只手拖着我的箱子，一只手牵着我。我说「猫猫今天穿得好好看」——她穿着一件黑色的大衣，下面是一条很短的裙子。

到了之后就很困了，躺在猫猫的床上就感觉很安心。洗了澡，等头发干的时候把我的笔记本拿出来，打开。跟她坐着随便扯皮，就不知不觉到了两三点多。

Day 1：约饭和闲逛

这一天周六，是和猫猫和另一个星友约了吃饭。因为前一天睡得很晚，第二天起来也就很困，猫猫一直躺在床上。她一边玩手机一边摸我的下面，我一被她摸就觉得发情（她摸得真的好舒服呜呜呜），是我自己自慰的时候从来没有过的体验。

吃的是牛角的烤肉。我和猫猫的第一次约会就是吃的这家（虽然不是同一个地方啦），我还记得当时是一个四人的桌子，猫猫问我坐对面还是坐一起，我想坐一起。然后拍了合照。

席间表演了一个现场烤寿司，因为 notfoundbot 说他不吃不是全熟的肉，我就把寿司上的牛肉片拿了下来，放在火上烤。这是我曾经做过的事情（记得就是在这家店里做的），当时猫猫大为震惊。没想到居然这个传统艺能能派上正经的用场（笑）。

吃完饭了我问 notfoundbot 要不要和我们一起逛街，去了一个文具店，闲逛之余问了一下有没有我想要的墨水，但是并没有（回来之后我还是在网上下单了），虽然是意料之中就是了。

然后逛了各种各样的店，之后去了哈佛~~游荡了一下~~，去了它的洗爪间，出来之后感叹了一句：「哈佛能举世称赞，是有原因的。它洗爪间的纸，质量是真的好，比我们学校的好多了。」毕竟敝校是被吐槽「厕纸是世界上最薄的东西」的地方。

在那边坐了好久，然后开始漫无目的地找寻下一个目标，猫猫把手机地图拿了出来，看到一家杂货店，里面居然有龙虾卷，便打定主意要去这里。结果猫猫看中了一个酒，就决定买回来试着喝一下。走出店门在外面坐着的时候，才想起来，龙虾卷呢？又回去问，还真的有。点了一个。吃起来并不好吃，觉得它还是别叫「the famous lobster roll」了吧。这个时候暮色正好降临，就拿起爪机拍了一张街景。

吃完并不好吃的龙虾卷之后，我们和 notfoundbot 分别，然后坐了地铁。以往都是猫猫给我刷卡，但是这次我自己刷卡进去了。转乘的时候，猫猫问我「你都记得怎么走了啊」，我说「这不是跟着猫猫的嘛」（虽然我确实知道该怎么走啦）。到了站拉着手出去，就连过闸机的时候也是牵着手的。

回去之后困得要死，然后稍微睡了一下爬起来参加 kazvconference。纱夜猫说试一下之前买的那一瓶酒。她从瓶子里面倒出来一点点，先喝了一点，然后给我试了一下。我是从来没喝过酒的，觉得味道很奇怪，很辣。感觉并不好喝（然后被妹妹说了「姐姐就不要喝酒啦！」）（跟鸟说喝了酒结果她以为我是难受才喝的，虽然并不是这样，只是猫想喝就跟她一起喝了）。之后纱夜猫给我泡了一杯茶，我直呼「这不比酒好喝多了？」（笑）

然后又到了两点多才睡。

Day 2：睡了一天，然后做了

因为出去了一天很困，所以这一天一直在趴。早上起来了一下，然后下午又睡过去了，醒来已经晚上了。我一直跟猫猫说着想要，想做爱（之前和不止一个人说了「我来见纱夜猫一定要做爱」）。

之前也不是不想做，但是我跟她很难亲密接触，从第一次见面开始，我和猫猫一贴贴就会想笑，然后停不下来，只能把她推开。这几天因为很想猫猫的原因，慢慢地能接受拉着手睡觉了，虽然抱着睡还是不太舒服，但是至少不会一抱就笑出声。

于是这天晚上，我记得也是过了凌晨了，猫猫骑在我的身上，用手指在我的下面游走着，不停地变换着摸的地方。我一边娇喘一边说着「猫猫怎么这么会啊？」

被吻住了。两条腿被猫猫分开，被压住，阴唇被分开，被猫猫揉了阴蒂，好舒服，好想要...但是，责怪我不敏感的身体，过了好久才到了一次边缘，接下来就是没感觉了，然后是再一波的亲吻，乳头贴贴，被玩弄下面...这样到了好几次边缘，我感觉猫猫已经很努力了，揉得我阴蒂都有点痛了，但是还是不够让我到高潮...

于是我就这样被猫猫操了一晚上。舒服是真的舒服，但是没高潮也是真的没高潮。鸟一直在听我们做爱。

Day 3：意料之外的事情，可能是上天想让我和她多呆一会儿

我来找猫猫之前想的是「逃离」，逃离现在糟糕的生活，再加上时间本来就很紧，所以订票是按着周五晚上去，周一晚上回来来定的，结果等猫猫和我走到机场的时候，发现 check-in 已经关了，甚至一个人都没有，很慌。之后回到猫猫家里，重新买了第二天一大早的机票。然后赶紧睡觉。虽然其实并不怎么能睡得着。只记得我和她在床上拉着手，亲了一下又一下，不停的对对面说着「我喜欢你」。

「以后也和我一起去创造美好的回忆吧？」我这么对她说着。她在我怀里「嗯」了一声。

凌晨的时候，她送我去机场，在安检队列前面亲亲抱抱，然后我走进去，照着惯例过了安检，过去了用机场的 wlan 给她发消息说我进去了，她可以回家了。

其实这篇文章周一我就想写了，但是这几天实在是太累，几乎每天都是巨大的困困喵，下了班就倒头睡一觉，所以就没时间写。肯定有好多东西我本来想写但是忘了的。

和笙的对谈

2023-08-30T02:11:01.000Z

今天笙给我发了她的日记。发来的时候我这里是凌晨，半夜醒来看到，迅速浏览了一下，但是太困了，中午才又拿出来仔细地读。

内容大抵是怀念小的时候，不需要思考未来的时候，以及「不想变成大人」。

我莫名地想到了 n-buna 的歌，《ヒッチコック》。印象深刻的是，今年前些时候回去听的时候，有这么一个评论，大意是说「这个歌反应了当代年轻人对现在社会的无所适从的迷茫感」一类的。但其实我并不觉得这样的表达是切中要害的。我自己的想法是，我并不会厌恶「长大」这个事情本身，甚至比起小的时候，现在的生活至少没有那么多让我感到拘束的地方。以前的话，做什么都会被管束着，不能自在地去自己想去的地方，和谁交往也是会被过问的，哭了也要忍住不被发现，不然会被问奇怪的问题，更不用说这么多年来遭受过的身体和心理上的暴力了。所以我讨厌那样的生活。

我所厌恶的并不是「长大」本身，而是「人必须要做某些工作，才能被允许活下去」这种事情。这种资本主义的规则。我是厌恶这样的想法的。一想到自己可能在能看见的未来，就必须做着自己可能并不热爱的东西才能活下去，就不禁感到很悲伤啊。为什么人必须要出卖自己的身体和灵魂，才能获得赖以生存的必需品呢？

所以我也厌恶着现在的生活，现在这样，不得不在自己并不热衷的东西上消耗时间，才能在这里生存下去。会觉得「看不见未来」。然后我想到了 David Revoy，以前我和笙提过，他可以靠着支持者的捐助来做他想做的事情，所以也不用担心他的作品会像 n-buna 那样商业化。她那时对我说，那样好棒啊。是啊，我也是这么觉得的。

我会因为这样简单的理由，讨厌这样的人类世界，讨厌资本主义。

以前的我大抵确然不会考虑什么未来的。不管喜欢上谁只会贪恋当下。但是我四年前喜欢上笙的时候不一样，那个时候我第一次想到了「未来」这种事情。第一次因为「觉得自己没有办法对她负起责任」而感到悲伤。

就这样我把自己漫杂的思绪全发给她了。想着她有没有睡觉，结果没睡。

她对我说「如果能安慰到当时的你就好了。」

「虽然那时候我完全就是个胆小鬼就是了。」「我不敢让你知道我喜欢你。」虽然按着我悲观的想法来看，如果我当时有告诉她，事情也并不会朝着好的方向发展就是了。「我害怕你知道了就会开始疏远我了。」我这么和她说。

想到了林奈¹的事情。粗略地说，林奈是一个被她的主人包养的人，而伊们之间的感情不过是（按照林奈自己的话说）「他只是需要我代替他死掉的前女友，但是他给我钱了，在我需要撒娇的时候让我撒娇了」，所以就维持着这样的关系。我当时问她「如果你主人不要你了怎么办」，她回答我「我可以做他的画师，只要有利益关系在，就不用担心没有饭吃。」

我当时和林奈说「我想打破这个世界的规则，但你想利用它。所以，我感觉总有一天我们会站到对立面上。」她开玩笑地说「我是邪恶轴心w」。我严肃地加了一句「但是我对林奈完全讨厌不起来诶。」当时的我是觉得这很奇怪的。四年之后这种奇怪的感觉逐渐地消散掉了，但今天我跟笙说出来了：「现在想来，因为 sex worker 也是父权和资本主义的受害者。她也不过只是想活下去而已。」就像是，如果没法打破这种制度的话，那就薅一薅羊毛吧。我不会去指责仅仅是利用这样压迫人的规则讨一点生活，而没有去谋害别的人的人。

她和我说「现在有了想法的转变，之前我是没有办法理解林奈这样的人的。但是现在不会了。」「看到你的信之后就有所思考了。之后也见到了很多例子。」

林奈曾经跟我说「你不适合风俗业啦。」因为我跟她说过，我绝对会陷进去的。笙说她的一个朋友去过百合风俗店，然后深陷其中。「听她的描述就像是恋爱一样。」我说了「曾经我看过一篇文章，就是关于作者自己去百合风俗店的经历。」（「被大姐姐关心了生活，感觉很温馨」那里面似乎有这样的话的。）她说「那好像就是她或者她的朋友写的。」

我当时会和林奈谈起这事，也就是因为看过那篇文章。那个时候我告诉自己，「除非到了非常绝望的地步，不然我是不会去的。」因为我知道自己绝对是会陷进去的，会被各种大姐姐榨干（各种意义上的）。但如果真的到了一无所有的程度了，那最后也没有什么好失去的了，对吧？

笙说「我觉得我也会陷进去，会分不清真实和虚假的。」我倒是没有这种想法啦。但是我会因为一句话一点小事而心动，我会很清醒地知道她们对我的爱意只是装出来的，但会渴望它是真实的。所以才会因此难过。

「但是我跟笙笙说的都是真的哦。」

「我也是。」

无厘头的对谈以我要开会而她要睡觉而收场了。

1.不希望有人打扰她，所以我就不照惯例放什么链接在这里了。更何况也并没有什么链接可言。↩

那些让我活下去的人

2023-07-23T19:54:30.000Z

依稀记得七年前的夏天。那时候我是个平凡的女子高生。像小说里那样，每天上课睡觉，偶尔逃一逃课闲逛。

当然如果只是这样的话，这个故事就结束了。

不同的地方是，这个小萝莉并没有什么可以一起玩闹的朋友。所以睡觉也好，逃课也好，写诗还是写随笔也好，都只是她一个人的事情。

「毕竟不会有人喜欢这种孤僻而又不会说话的女孩子的。」

她每天就看着身旁的人嬉笑打闹，谁和谁又在讨论中午要去吃什么，哪人和哪人又有着什么关系了，哪个老师又讲出什么段子了。但是一切和她无关，她曾笨拙地试图加入伊们的谈话，却发现自己一句话也插不上。

「哇小栗好轻诶，我能把小栗公主抱起来吗？」其中的一个女孩子对着另一个说。然后第二只便钻进了第一只怀里。真的抱起来了，旁边一阵惊呼声、以及此起彼伏的「我也要试试」。

「好无聊。」被欢快的说话声惊扰醒了的萝莉稍微抬了一下头，轻轻瞥了一眼伊们。然后她又把头趴在课桌上睡过去了。

在没有人看到的地方，她大概是轻轻地叹息了一下。

曾经在新年之前，她给几个人写了贺年卡，但是却并没有收到任何一张。

「那可真是遗憾呢。」她这么想着。明明给每个人都写了一段诗呢。

然后日子便也是这么过着。

只是这样的联结，就已经让人无比地心安了

也不知道是什么时候，萝莉在放学的时候发现路上有一家面包店。萝莉最喜欢夹着香肠的面包了。带着好奇的心情，她把单车停在路边锁好（锁车什么的真的是最麻烦了啊），然后走了进去。

嗯，果然有着好多好吃的面包呢。便稍微挑了几个买下来。它的味道究竟是什么样的，现在大抵已经忘却，但有一样事情我是知道的，当时那个小萝莉吃得很开心。

于是不出意外地，她每过几天就会顺道光顾一次。

不知又是从哪一日开始呢，好像有一个店员大姐姐记得她了。

——「今天怎么样呢？」

——「不错哦。」

然后看着大姐姐慢慢地把面包一个一个装进袋子里。

很有默契地没有多余的交流。但是每次都是这一个人，跟萝莉日常地走完日常的流程。然后看着她从门口出去。

对小说里的角色来说，这大约算不得什么吧。但只是这样的联结，对那个小萝莉来说，就已经让人无比地心安了。

然后日子便也是这么过着。

即使如此也还是谢谢你的陪伴

然后到了小萝莉高考的日子。考完了在家里吃西瓜。

这一天她并不顺路地特地来到这家面包店。

「嗯...我是来道谢的，谢谢你这么长时间的陪伴。」

在想什么呢，这种话怎么可能是那时候的她说得出口的呢？

——「嗯...我可能以后不能再经常来了。」

——「怎么了吗？」

——「因为我考上了大学，会很远，嗯...」

真实的对话大抵如此，我已经忘记大姐姐是怎么回答的了。

所以她终究还是没将那些感谢的话说出口。

一年之后的暑假再来的时候，那个大姐姐已经找不到了。

偶然的相遇和偶然的重逢

这一天萝莉在学校食堂，刚买完午餐，准备找个地方坐下来。她看见两个女孩子正对坐在一张四人的桌子上。

如果是平时的话，她总是会找一个人最少的地方。但那天不知道怎么地，她坐在其中的一个人的旁边。

邻座的两人像是完全忽视了她的存在一样，接着大声地说她们本来要说的话。

于是萝莉也就一边吃饭一边听着。

「嗯...？她们说的东西好像很二次元？」她这样想着。

要不要去搭话呢？

在扒拉了碗里的饭第50还是60次的时候，她终于开口了。

「你们说的那个什么『萝莉岛』，它好玩吗？」

那两个女孩止不住地大笑。

然后那个看上去很高的女孩对她说：「小孩子还是不要知道这些比较好哦？」

什么嘛，明明我才是学姐好吗。比我高一点就这么说话吗。萝莉这样想着。

那两个女孩子便走掉了。萝莉继续吃完了饭。

然后日子便也是这么过着。

那是第一个主动找她交往的人

到了运动会的时节。不可能会有人选一个脚上有伤的病弱萝莉去比赛的啦。况且这种事情她也完全不擅长嘛。

于是萝莉就在一旁呆坐着。然后，那个很高的女孩子出现了。

她面带笑容，远远地朝萝莉走过来，坐在了她的身边。

然后就是闲聊啦。我早已忘记那天她们究竟是怎么打开话题的，可能是死宅特有的什么方式吧。但总之，萝莉知道了这个人是高二的学妹（真是的，那还管我叫小孩子）。那个女孩知道了萝莉是个破画画的。然后萝莉拿出了自己画画的本子，那个女孩子在本子上写下了自己的联系方式。

再之后的事情也记不真切，大抵是偶尔会聊一会儿天的程度吧。在学校里也甚少碰面。但那是她身边第一个主动找她交往的人呢。

即使是痛苦的过去，也会有着如明星般闪耀的存在

现在的我回看起过去的那个小萝莉，果然是会心疼的吧？她从没感受到过爱，于是也特别容易满足。

如果是现在的我回到过去的话，大概会说一句「只是如此吗？」吧。

正是因为过去那个小萝莉承受了那么多她本不该承受的，我才站到现在的位置上来。

而在那样痛苦的过去里，我还是翻出了些许如明星般闪耀的存在。

她们大约就是让她活下去的人吧。

然后日子便也是这么过着。

现在的我拼命地记下当下的美好。

而那也终将成为闪耀的回忆。

日后谈

把这篇文章给我四年之前暗恋过的女孩子看了。

她说「能带入到你的心情呢。」

我说「是因为你也曾经历过类似的事情吗？」

她说「是这样的。」

我说「然后那个时候是因为有我在吗？」

她说「是这样的。」

啊啊，原来我也成为过那样闪耀的存在呢。

「之后也要陪你一起走下去啊。」当时的我这么对她说着。

「好哦。」现在的她回应了我这句穿越了四年的话。

Fediverse: the two years 联邦宇宙：这两年来

2023-07-13T18:19:25.000Z

It's more than two years I have been here, maybe almost three.

我呆这块儿两年有余了，可能几乎有三年了。

-1+y: hitorino

This is the actual beginning of me in the fediverse though I did not realize it then. Someone invited me to hitorino, a then-functioning Mastodon server. And they suggested an app to me, maybe it's Pawoo or something, but I cannot remember. No one told me anything about the fediverse, not even Mastodon. They just gave me a link, and that's it. So I just registered, and that's it.

这是我在联邦宇宙里的实际开始，虽然我那时没得意识到。有人邀请我去 hitorino，当时还在运作的一个 Mastodon 服务器。对面还推荐了一个 app 给我，可能是 Pawoo 或者什么玩意儿吧，但是我记不得了。没得人告诉我关于联邦宇宙的任何东西，甚至没得讲 Mastodon。伊就给了我一个链接，然后就没得了。所以我也就注册了，然后就没得了。

0: t.tusooa.xyz

It was the end of 2020 I remember. I was browsing through some old archives on #archlinux-cn. There were many interesting people, including those I've been known for a decade or so. Some got a blog, and they put their link to their Mastodon account on it. I followed that link, and got (re-)introduced to that little simple interface. "Oh, it's a microblog." I was like. I was already using Matrix for a long time, and my feeling was, "So I can self-host this as well?" So I did, and that was https://t.tusooa.xyz . I began posting poems, posting some daily life, and it turns out that I have already been interacting with those who later became my lovers.

我记得那是 2020 的末尾。我在浏览 #archlinux-cn 高头的一些老档案。那块有好多有意思的人，包括那些我晓得了有十年多了的人。有人有个博客，而把伊的 Mastodon 账号链接放在上面了。我追随了那个链接，被（重新）带到了那个小小的简单的界面高头。「哦，这是个微博啊。」我这么想到。我已经用了 Matrix 蛮长时间的了，我的感受就是，「所以我也能自己 host 这个玩意儿？」那我就干了，就成了 https://t.tusooa.xyz 。我开始发诗，发点儿日常生活，我还发觉在那个时候我就开始跟那些后来成为我的恋人的人们互动了。

Good life was short. I got burned out by my internship. Covid was there. I wasn't able to see my girlfriend. I tried to participate in discussions peacefully, there were always people who spread hatred, discrimination, and especially transphobia. Since the beginning, I tried to give constructive feedback, but those just won't listen and will just violently push you back against a rock. And the more I use Mastodon, the more I feel it was really uncustomizable. The text limit can't be changed without changing the code. The requirement for email upon registration is constantly bothering me because it is inherently unnecessary information collected against users' privacy, and Eugen refused to make it optional. I never actually opened up registration on the server.

美好生活是短暂的。我被实习搞得精疲力竭。Covid 在那块。我见不到女朋友。我试到和平地参与讨论，总有人散播仇恨，歧视，而尤其是恐跨。从最开始来讲，我试到给出建设性的反馈，但是伊们就不听，还粗暴地把你推到石头高头。而且啊，我越是用 Mastodon，就越觉得它真的不可定制。文字上限不改代码就改不了。要求注册时填邮箱真的是让我很苦恼，因为是原本不必要的信息被收集起来，损害用户的隐私，而 Eugen 拒绝让它变成可选的。我从来没得在那个服务器高头开过注册。

Watching for Pleroma注视到 Pleroma

It was no surprise I began searching for alternative microblogging software. And somehow I found out about Pleroma. It looks so nice, so customizable, and is so friendly towards those who do not register (Mastodon requires you to register to perform most read-only actions). Immediately I was amazed about that. Only one thing though: Mastodon allows you to take all ("conditions apply"!) your followers with you when you jump ships. Pleroma had no such feature. The good side was, I found out about one merge request on their GitLab, which allows you to move from Mastodon to Pleroma, by adding an alias referring the old account to the new account. I was never thinking of going back, so that was enough for me. I looked at it and that gave me hope of using some other software than Mastodon. But after a month or so, there was literally no progress on that MR, so I decided to shout out in the dev channel and ask what was going on. One of them, maybe rinpatch, told me that if no one cared about it then it was probably going to be ignored, and suggested that I comment on the MR. I ended up testing it and reported my results -- initially it did not work. It went the wrong way as the original method added it to the WebFinger profile, but Mastodon expects the alias in the Actor object. After the problem was fixed, I was able to open up a Pleroma server for my own use.

我开始搜索替代的微博软件就不值得惊讶了。然后我不知怎么的就找到了 Pleroma。它看上去很棒，很可定制，而且对不注册的人非常友好（Mastodon要你注册才能完成大部分的只读操作）。我立刻就为之惊叹了。但有一事：Mastodon允许你跳船的时候把所有的关注者带走（「要符合条件的才行」！）。 Pleroma 还没得这个功能。好的一面就是，我在伊们的 GitLab 高头找到了一个合并请求，能让你从 Mastodon 移动到 Pleroma。原理是在新账号上加一个指向旧账号的别名。我从来没得想过回去，所以那对我来讲就足够了。我看到它，就觉有希望能用 Mastodon 意外的什么软件了。但过了一个月吧，那个 MR 高头完全没得任何进度，所以我决定去开发者频道高头吼一嗓子问问到底怎么样了。其中一个，可能是 rinpatch 吧，告诉我如果没得人关心，那可能就会被忽略了，然后建议我去那个 MR 高头评论。我最终还是自己测试了，汇报了我的结果——一开始是不能用的。它走错了道路，之前的方法是把它加到 WebFinger profile 高头，但是 Mastodon 想要别名在 Actor 对象里头。这个问题修好了之后，我就能开一个自己用的 Pleroma 服务器了。

And that was the beginning of kazv.moe, somewhere April in 2021. It started out as a tiny little server. I invited my girlfriend and some friends there. Some people who I have known when I was on Mastodon registered alt accounts on it. Even though registration was completely open without any verification, there was not a lot of people.

而那便是 kazv.moe 的开端了，2021年4月的某日。它开始是一个微小的服务器。我把我的女朋友和一些朋友邀请了过来。一些我在 Mastodon 高头认识的人在上面注册了小号。尽管完全开放注册，没得任何验证机制，它也还是没得多少人。

Hacking Pleroma

As time goes, I feel that I want more features for Pleroma. First of all, I want account migration to fully work. A lot of people are posting really long images and I could not zoom in conveniently. I really liked Misskey's tree-style thread display and nice mention links. The emoji picker was a disaster to use because it was really slow to load, and everything was mixed together, there being only two groups: "custom" and "unicode," effectively making emoji packs useless.

时光流逝，我感觉我想要 Pleroma 有更多功能。首先，我想要账号迁移能完全工作。好多人在发巨长的图，我没得办法方便地放大。我真的很喜欢 Misskey 的树状线索显示和好看的艾特链接。表情选择器用起来简直是灾难，因为它加载起来真的真的慢，所有的东西都糊在一起，只有两个分组：「自定义」和「unicode」，让表情包完全无用。

So I started to write code, for the features I want, and deployed them to kazv.moe . At the beginning, I just touched the frontend. It was relatively easy. It's JavaScript, and I knew JavaScript since 2017, when I joined Rikumi's project and started writing server-side JavaScript. It took me some time to figure out how Vue works, but since I knew React, it wasn't that much of a problem. Then, suica asked me why search on Pleroma was broken. And debula found out the cause of it. To fix that took me a couple of hours -- that was the first time I touched Pleroma's backend code. I was never exposed to any Elixir or Erlang before, and all I read was Elixir's official tutorial. I did not get to read the OTP part -- it could have saved a huge part of my time if I did, because I did not know how to run individual test cases and wasted a lot of time on running the whole coveralls process.

所以我开始给我想要的特性写代码，然后把它部署到 kazv.moe 去。一开始，我只是动动前端。还是比较简单的。它是 JavaScript 的，而我从 2017年加入 Rikumi 的项目开始写服务端 JavaScript 的时候就懂得 JavaScript 了。弄清楚 Vue 怎么工作花了点时间，但是我懂 React，所以问题不大。然后，suica 问我为什么 Pleroma 的搜索是坏的。debula 找到了问题的原因。修它花了我几个小时—— 那是我第一次去动 Pleroma 的后端代码。我之前从来没得接触过任何 Elixir 或者 Erlang，我当时就读了 Elixir 的官方教程。没得读 OTP 的那部分——要是看了的话，那能节省我一大半的时间了，因为我不晓得怎么运行单个的测试案例，在运行整个 coveralls 过程里浪费了好多时间。

And so I continued adding new features: grouped emoji picker, remote interaction, misskeyish mention links, confirmation dialogs, account migration, translations for backend-rendered pages, server announcements, editing. Those are all things wanted by people, and they really love to see it. However, Pleroma at that time was on the verge of collapsing: AG was using his power to push all his changes into Pleroma in any way he could, while caring little if nothing about other people's work and especially Pleroma-FE, as Soapbox was the frontend of his legacy. There were not a lot of people who can review my code, so it got stuck in the process for a very long time. My very first MR took half a year to get merged.

然后我就继续加新功能：分组的表情选择器，远端互动， misskey 式的艾特链接，确认对话框，账号迁移，后端渲染的页面的翻译，服务器公告，编辑。这些都是人们想要的功能，伊们真的很想看到的。但是，Pleroma 在那个时候处在崩溃的边缘： AG 在用他的权力以任何可以的方法把他的修改推进 Pleroma 里头，但是对别人的工作，尤其是 Pleroma-FE （毕竟 Soapbox 是他的遗迹前端嘛）的关注微乎其微，如果不是完全没得的话。没得什么人能审阅我的代码，所以它卡在过程里就卡了好久。我第一个 MR 用了半年才被合并。

In the meantime, hj organized a meeting for Pleroma developers and users to reunionize the community and rethink about the next steps. AG was stripped off the maintainer title, and later got kicked out. He then became really abusive on the fediverse, calling names towards me and Hélène, the other girl at that time on our team. I wonder whether it is due to this that she ended up quitting developing Pleroma. I ended up banned both of his instance from kazv.moe . Reflecting on that, I would say, "A self-claimed feminist, and all he does is... harassing women? What a shame?" By the end of the year of 2022, I was named a new maintainer through the consensus of the current devs on the IRC channel. And we released 2.5.0, the one with many of the long-longed features I wrote. The Akkoma folks forked away from us and advertised their software with the features I wrote, claiming credits just because they released earlier than us. I really can't say I like how this works.

在同时，hj 给 Pleroma 的开发者和用户组织了一个会议，为了重组社群，再思考下一步怎么办。 AG 被削除了维护者的头衔，之后被开除出去了。他之后在联邦宇宙上面变得非常粗暴，咒骂我跟 Hélène，当时我们团队里头的另一个女孩。我不晓得是不是因为这个，她才从 Pleroma 的开发里退出的。我最后在 kazv.moe 高头把他的两个实例都给封得了。现在回想起来，我就要讲了：「一个自称的女权主义者，而他做的事情都是在...伤害女性？多么可耻啊？」 2022年底，IRC 频道高头的现任开发者们一致同意授予我新的维护者的职位。然后我们释出了 2.5.0，这个有很多我写的，大家都期盼已久的特性的版本。Akkoma 那一帮人从我们这边 fork 走了，拿着我写的那些特性来宣传伊们的软件，只因为伊们释出的早，便抢了名头。我真的没得办法讲我喜欢这事的。

My personal life我的个人生活

From here on there might be depiction of sex. You have been warned.

从这里开始可能有性描写。你已经被警告过了。

That's not as much dramatic as the Pleroma drama, no? I still posted my poems (2021 was the year when I wrote the most poems till then). I occasionally posted the food I cooked, and I posted my political viewpoints. Definitely a lot of people hate me for my views, but I do not care any more. I created an alt account for more intimate relationships, and I started to flirt with Reiki. We used paired avatars, expressed our feelings to each other, and maybe after half a year, I asked them to be my girlfriend. They agreed. Since that time I realized I was not a "pure lesbian" but rather can be attracted to non-binary people as well, which is a type of Bi+. I use the term yuri to represent my sexual orientation now. And later I got to be girlfriends with two other cute people.

那远不如 Pleroma 的戏剧那么戏剧化，不是吗？我仍然发诗（2021是我在以往年份里写过最多诗的一年）。我偶尔发点自己做的食物，我还发我的政治观点。肯定有很多人因为我的观点而恨我的，但我不再在意了。我创了一个小号给更加亲密的关系，并且开始和蕾姬调情。我们用一对的头像，向对方表达自己的感情，可能有半年之后吧，我让伊做我的女朋友。伊答应了。从那个时候起，我意识到我不是一个「纯女同」，我其实也可以对非二元的人产生吸引的，这是一种 Bi+。我现在用百合这个词来表达我的性取向。再之后我又和另外两个可爱的人成为了女朋友。

After covid I have been able to see Saya more often, but only during my school breaks. She masturbated me and I think that counts as sex. I hate it that I have to cross the border. At school it's still busy, and I have encountered a couple of small problems, but luckily they were resolved promptly.

covid 过后我能更频繁地见 Saya 了，但是也只有学校放假的时候。她给我自慰了，我觉得这算是性交。我讨厌必须穿越边境这事。在学校还是很忙，碰到了好多小问题，但还好能妥善解决。

Revealing my political views isn't necessarily a bad thing right? Someone came to kazv.moe because she love my views, and I ended up having a crush on her. Unfortunately she doesn't love me back so we are just being friends and sisters. I guess that's the bitterness of life, huh. (Oh have I told you that she now has a Pleroma instance with the exact same setup as mine?) I finally actually used my Funkwhale, and please, look forward to our new song, ok?

揭示我的政治观点不一定是坏事，对吧？有人就是因为喜欢我的观点才来到 kazv.moe，再后来我爱上了她。但不凑巧，她并不也爱我，所以我们只是在做朋友和姐妹啦。我想这就是人生的酸涩吧，嘛。（哦，我啊讲过啊，她现在有一个 Pleroma 实例了，用的是跟我一模一样的配置诶？）我终于把我的 Funkwhale 真的用起来了，请期待一下我们的新歌吧？

systemd -> openRC

2021-10-01T22:25:15.000Z

Recently I switched from systemd to openRC on my Gentoo laptop.

最近我把我践兔的笔记本高头的 systemd 换到了 openRC。

Why?为什么啊？

Contrast to what you might think, this article would not do a comparison between systemd and openRC. I switched purely for fun.

没得想到吧，这篇文章不搞 systemd 跟 openRC 的对比。我纯粹为了好玩。

Steps步骤

First update the whole system, as it is a good practice before doing any invasive change.

首先更新整个系统。在搞任何侵入性的修改之前，这么搞总是好的。

1 2	eix-sync emerge -av1uUD --with-bdeps=y world

Then switch to a non-systemd profile.

然后切到一个不是 systemd 的 profile。

1 2	eselect profile list eselect profile set X

Change USE="elogind -systemd" in make.conf.

在 make.conf 里头，改个 USE="elogind -systemd"。

I first tried to do the same as updating the system, but it still does not rid me of the systemd dependencies. So check now what packages still have a hard-dependency on systemd.

我先试到搞跟更新系统的时候一样的事情，但是它还是没得办法把我从 systemd 依赖里头解脱出来。所以现在检查一下哪些包还对 systemd 有硬依赖的。

] equery d systemd
 * These packages depend on systemd:
app-crypt/p11-kit-0.23.22 (systemd ? sys-apps/systemd)
app-editors/emacs-27.2-r5 (systemd ? sys-apps/systemd)
app-i18n/fcitx5-5.0.1 (sys-apps/systemd)
dev-db/mariadb-10.5.10-r2 (systemd ? sys-apps/systemd)
dev-db/postgresql-13.3 (systemd ? sys-apps/systemd)
dev-lang/erlang-24.0.2 (systemd ? sys-apps/systemd)
dev-libs/libratbag-0.16 (systemd ? sys-apps/systemd)
dev-libs/weston-9.0.0-r1 (systemd ? >=sys-apps/systemd-209[pam])
dev-qt/qtcore-5.15.2-r3 (systemd ? sys-apps/systemd)
gnome-base/gnome-desktop-40.3 (systemd ? sys-apps/systemd)
kde-plasma/plasma-meta-5.22.5 (systemd ? sys-apps/systemd[pam])
media-sound/pulseaudio-13.0-r1 (systemd ? sys-apps/systemd:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
net-libs/webkit-gtk-2.32.4 (systemd ? sys-apps/systemd)
net-misc/modemmanager-1.16.8 (systemd ? >=sys-apps/systemd-209)
net-misc/networkmanager-1.32.4-r1 (systemd ? >=sys-apps/systemd-209:0)
net-print/cups-2.3.3_p2-r2 (systemd ? sys-apps/systemd)
net-wireless/bluez-5.61 (systemd ? sys-apps/systemd)
sys-apps/accountsservice-0.6.55-r1 (systemd ? >=sys-apps/systemd-186:0)
sys-apps/dbus-1.12.20-r3 (systemd ? sys-apps/systemd:0)
sys-apps/gentoo-systemd-integration-8 (>=sys-apps/systemd-207)
sys-apps/hwids-20210613-r1 (systemd ? sys-apps/systemd[hwdb])
sys-apps/smartmontools-7.2 (systemd ? sys-apps/systemd)
sys-apps/util-linux-2.37.2-r1 (systemd ? sys-apps/systemd)
sys-auth/pambase-20210201.1 (homed ? sys-apps/systemd[homed])
                            (systemd ? sys-apps/systemd[pam])
sys-auth/polkit-0.119-r2 (systemd ? sys-apps/systemd:0[policykit])
sys-auth/rtkit-0.13-r1 (systemd ? sys-apps/systemd)
sys-fs/lvm2-2.02.188-r2 (systemd ? >=sys-apps/systemd-205:0)
sys-fs/udisks-2.9.3 (systemd ? >=sys-apps/systemd-209)
sys-kernel/dracut-053-r1 (sys-apps/systemd[sysv-utils])
sys-process/procps-3.3.17-r1 (systemd ? sys-apps/systemd[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
virtual/libudev-232-r5 (systemd ? >=sys-apps/systemd-232:0/2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
virtual/logger-0-r1 (>=sys-apps/systemd-38)
virtual/service-manager-1 (kernel_linux ? sys-apps/systemd)
virtual/tmpfiles-0-r1 (!prefix-guest ? sys-apps/systemd)
virtual/udev-217-r3 (>=sys-apps/systemd-217)
x11-base/xorg-server-1.20.13-r1 (systemd ? sys-apps/systemd)
x11-misc/sddm-0.18.1-r5 (systemd ? sys-apps/systemd)

It turns out that virtual/logger, virtual/service-manager, virtual/tmpfiles have dependencies on systemd, and they are not willing to switch to another provider. I had to pull them in manually. Here, I chose openrc for service-manager (obviously), systemd-tmpfiles for tmpfiles (only other sensible package to provide this), and syslog-ng for logger (this one has many choices).

看样子 virtual/logger、virtual/service-manager、virtual/tmpfiles 有 systemd 的依赖，而且这些都不愿意切换到另一个提供者的。我就得把这些手动拉进来了。在这块，我选了 openrc 来提供 service-manager（显然），systemd-tmpfiles 来提供 tmpfiles（唯一的别的提供这玩意儿的理智的包），然后是 syslog-ng 来提供 logger（这个就有蛮多选择的了）。

1	emerge -av1uUD --with-bdeps=y openrc systemd-tmpfiles sysvinit syslog-ng world

In the meantime, prepare other parts of the system for openRC. First backup the current kernel (bzImage, System.map and initramfs), and check the kernel config to make sure we supported openRC.

与此同时，把系统的别的地方给 openRC 准备一下子。首先备份一下当前的内核（bzImage、System.map 跟 initramfs），然后检查一下内核配置，确保支持了 openRC。

1
2
3

Gentoo Linux  --->
  Support for init systems, system and service managers  --->
    [*] OpenRC, runit and other script based systems and managers

Bid farewell to systemd and express gratitude:

跟 systemd 讲再见，表达一下感谢：

1
2
3

] systemd-analyze
Startup finished in 6.575s (firmware) + 2.132s (loader) + 2.835s (kernel) + 2.130s (userspace) = 13.674s
graphical.target reached after 2.087s in userspace

Always good to have some root ttys and sessions:

有几个 root 的 tty 跟会话总是好的：

sudo su -

Install a busybox in case of misfortune.

装个 busybox 以防不测。

1
2
3

euse -E static -p sys-apps/busybox
euse -D pam -p sys-apps/busybox
emerge -av busybox

After the emerge finished, I was prompted to run emerge @preserved-rebuild so just ran it.

emerge 结束之后，它提示我要运行 emerge @preserved-rebuild，那就运行吧。

Update the initramfs to pickup any changes. This may not be needed; I ran it just to be safe.

更新 initramfs 来捡起来任何更改。这个可能不需要，为了保险起见我还是执行了。

1	genkernel --no-clean initramfs

Configuration配置

Reference: https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base

参考： https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base

1
2
3

# cat /etc/timezone
# echo "......." > /etc/timezone
# emerge --config sys-libs/timezone-data

1 2	# cat /etc/locale.gen # eselect locale list

1	emerge -av app-admin/logrotate

1
2
3

# cat /etc/conf.d/hwclock
# cat /etc/conf.d/hostname
# cat /etc/hostname

NetworkManager

1	rc-update add NetworkManager default

Display manager显示管理器

1 2	rc-update add display-manager default nano -w /etc/conf.d/display-manager

keymaps (replacement for localectl)keymaps（localectl的替代）

Reference: https://wiki.gentoo.org/wiki/Keyboard_layout_switching

参考： https://wiki.gentoo.org/wiki/Keyboard_layout_switching

1 2	nano -w /etc/conf.d/keymaps rc-update add keymaps boot

1	# cat /etc/X11/xorg.conf.d/00-keyboard.conf

lvm

Reference: https://wiki.gentoo.org/wiki/LVM#openrc

参考： https://wiki.gentoo.org/wiki/LVM#openrc

1	rc-update add lvm boot

tmpfs on /tmp (systemd auto-mount)在 /tmp 高头的 tmpfs（systemd 自动挂载的）

1
2
3

# nano -w /etc/fstab

tmpfs /tmp tmpfs rw,nosuid,noatime,nodev,size=4G,mode=1777 0 0

backlight (replacement for systemd-backlight)backlight（systemd-backlight 的替代）

eselect repository enable beatussum-overlay
emaint sync --repo beatussum-overlay
echo '*/*::beatussum-overlay' |sudo tee /etc/portage/package.mask/beatussum-overlay
echo 'sys-apps/save-backlight::beatussum-overlay' |sudo tee /etc/portage/package.unmask/save-backlight
emerge -av save-backlight
rc-update add save-backlight default

alsa

Note that the alsasound service only saves and loads mixer state. You will still be able to use sound without this service.

注意 alsasound 服务只是保存跟读取混音器的状态。就算不用这个服务，也可以用声音的。

1 2	rc-update add alsasound default rc-update add alsasound nonetwork

cron

1	rc-update add cronie boot

time sync (replacement for systemd-timesync)时间同步（systemd-timesync 的替代）

1
2
3

emerge -av ntp
rc-update add ntp-client default
rc-update add ntpd default

https://wiki.gentoo.org/wiki/Ntp#Ntpd

ufw

1	rc-update add ufw default

bluetooth蓝牙

1	rc-update add bluetooth

Finalize完成

1 2	# emerge -avuUD world # reboot

But in fact after the reboot command it just hangs indefinitely. I ended up rebooting via sysrq.

但是实际上重启命令之后它就一直卡到那块了。我最后用 sysrq 重启的。

What's next?然后呢？

Nothing. What are you expecting?

没得唻。你在期待什么呢？

Notes on PinePhone and mobile GNU/Linux systems 关于 PinePhone 和移动端 GNU/Linux 系统的笔记

2021-03-28T23:07:52.000Z

At the end of last year, I bought the PinePhone KDE Community Edition; but due to me being too lazy, I had not tried it out until several months later. I used a few distributions, namely (1) the manjaro with Plasma Mobile it comes with, (2) Plasma Mobile development version, also based on Manjaro, and (3) openSUSE Tumbleweed with Plasma Mobile. The first two are not really usable, as I got blackscreens after a few reboots -((.

去年底，我买了 PinePhone KDE 社区版；然而因为我太懒，好几个月都没得好好试试。用了几个发行版，分别是 (1) PinePhone 自带的 Manjaro，(2) Plasma Mobile 的开发版本，也是基于 Manjaro 的，和 (3) 带了 Plasma Mobile 的 openSUSE Tumbleweed。前两个都用不起来，重启几次之后就黑屏了 -((。

Experience with openSUSEopenSUSE 的体验

What's working什么能用

Messaging and calls. Had a call with my girlfriend for about 30mins without interruption. Although she said my voice is a bit strange.

短信和通话。给女朋友打了三十分的电话，没得中断过的。虽然她说我的声音有一点奇怪。

NeoChat.

NeoChat。

Web browser.

网络浏览器。

Setting locales. I see some translations in Mandarin as Simplified Chinese are there already, but there are a lot of places without translations (namely those specific to Plasma Mobile).

设置 locale。我看到有的简体中文的官话翻译已经在那块了，但是还是有好多地方没得个翻译的（就那些只在 Plasma Mobile 里头有的）。

Problems问题

Data does not work. Plasma Mobile does not give me an option to change network settings either.

流量没得办法用。Plasma Mobile 也没得给我个改网络设置的地方哎。

Sometimes laggy.

有的时候卡。

Due to 2, pushing the power button does not always immediately wake up the phone.

因为 2，按电源键了，也不一定能立刻唤醒手机。

Input method does not work. At least for the openSUSE distribution, it (maliit) does not come with Chinese input. Even after I installed maliit-keyboard2-lang. The screen keyboard is implemented using IM modules. Setting QT_IM_MODULE=fcitx will just prevent the screen keyboard from showing up.

输入法没得办法用。至少在 openSUSE 发行版高头，丫 (maliit) 没得个中文输入的。就算我装了 maliit-keyboard2-lang，也不行。屏幕键盘用输入法模块实现的。设个 QT_IM_MODULE=fcitx，屏幕键盘就不能显示了。

With earphones there are electrical current sounds from time to time.

耳机有的时候会有电流声。

If I click an app, and switch to another app, or the desktop, before that app window shows up, the app window will pop up afterwards instead of being pushed to the background.

要是我按一个应用，再在那个应用的窗口显示之前，切到另一个应用，或者是桌面，那那个窗口会弹出来，而不是摁到后台去。

Privacytools search reports "Rate limit exceeded1" [sic] when I search in Angelfish.

我在 Angelfish 里搜索的时候，Privacytools 的搜索跟我讲「Rate limit exceeded1」[原文如此]。

The screen keyboard sometimes responds to key pressing with word suggestions, which can be never inputed to the input box desired.

屏幕键盘有的时候会把我的按键转成单词建议，但那玩意儿又从来没得办法输到输入框里去。

Other notes别的笔记

I have a nano sim card and it will need the adapter that comes with PinePhone to install it properly. I pushed it in without the adapter, and had to disassemble the phone to push it back out from the inside.

我有个 nano sim card，那玩意儿要用 PinePhone 自带的转接器才能好好装上。之前没得用转接器就摁进去了，结果只能把手机拆的了然后从里头给它推出来。

The Manjaro distribution the PinePhone comes with has Telegram installed by default. Telegram can only connect to a non-free server, and forces users to provide a phone number in order to use services that does not need one. This is a serious privacy concern. I strongly oppose to the use of Telegram in any cases, and suggest everyone uninstall it upon receiving your PinePhone.

PinePhone 自带的 Manjaro 发行版默认安装了 Telegram。Telegram 只能连接到一个不自由的服务器，而且强迫用户提供手机号以使用并不需要手机号的服务。这是一个严重的隐私隐患。我强烈反对任何情况下使用 Telegram，并推荐所有人收到 PinePhone 之后立刻卸载它。

The Manjaro distribution the PinePhone comes with cannot be waken up by an alarm clock. I have not yet tried with openSUSE.

PinePhone 自带的 Manjaro 发行版没得办法被闹钟唤醒。openSUSE 我还没得试过。

From a weird Dolphin bug 从一个奇怪的 Dolphin bug 说起

2021-02-05T00:38:47.000Z

One day when I opened Dolphin I found that it is reporting the file does not exist when I tried to open one with a Chinese file name. "Well, that's bad," I thought, and instead opened it in the terminal. Recently I went through the bug list for Dolphin and KIO and saw that encoding-related bugs are all mentioning that file cannot be trashed. Which is not the case for me. So I opened a new bug and started investigating it.

某日我打开 Dolphin，发觉它在我试图打开一个文件名带中文的文件的时候告诉我那文件不存在。「行吧，太差了。」我想着，然后在终端里打开了那个文件。最近我遍览了 Dolphin 和 KIO 的 bug 列表，看着编码相关的 bug 全在说文件不能被扔垃圾桶。而我这里却不然。所以我开了个新 bug 开始钻研它。

A note: if your Qt is not configured to use icu, then this does not apply to you.

提示：如果您的 Qt 没有被配置为使用 icu，那么这事对您便不适用。

From Dolphin to KIO从 Dolphin 到 KIO

So I checked Dolphin's code, found that the actual code for opening a file is with KIO. The implementation is in KFileItemActions. However, that seems not to be the real source of error. The KFileItemList there is already wrong, with all non-ascii characters turned into question marks. Further I looked into the logic of obtaining the content of a directory: KIO invokes a plugin called file.so, for local filesystem, and that, which is actually a kdeinit program, run as another process, does the real work. Then the data is transferred back to Dolphin using a QDataStream. And in file.so it seems that everything looks correct.

所以啊我就查了查 Dolphin 的代码，发觉真正打开文件的代码在 KIO 里。实现在 KFileItemActions 里。然而，那好像并不是真的错因。那里的 KFileItemList 已经错了，非 ascii 的字符全变问号了。再往下，我看了看获取目录内容的逻辑：对于本地文件系统，KIO 调用了一个唤作 file.so 的插件，而那插件实际上是个 kdeinit 程序，作为另一个进程，做了实事的了。然后数据通过一个 QDataStream 传到 Dolphin 里。在 file.so 里，一切看着都很对。

Why is that? Is it the QDataStream is bad? I looked into the code for how QDataStream transfers strings and, no, it cannot be. Also I noticed that the filename is displaying correctly in Dolphin, just I cannot open it. I got some support on the #kde-devel channel, and someone reminded me of the LegacyCodec in file.so. That is not the cause of the problem, of cource, as in there it is nothing wrong. But it reminded me of the QTextCodec problem. There is something Qt used to convert its UTF-16 representation into other encodings. And that is called QTextCodec::codecForLocale(). An observation is that in file.so, the codec name is called UTF-8; while in Dolphin, it is called US-ASCII, unless I set LC_ALL to a UTF-8 locale.

为啥啊？QDataStream 坏了吗？我看了下 QDataStream 是怎么传字串的，啊这，不可能错的。又注意到文件名在 Dolphin 里显示啥问题都没有，只是我打不开。在 #kde-devel 上得到了些帮助，有人提醒我 file.so 里有一 LegacyCodec。当然这不是真的错因，因为那边没啥问题啊。但是这教我注意到 QTextCodec 的问题了。有个玩意儿是 Qt 用来把它自己的 UTF-16 表示法转成别的编码的。那玩意儿叫 QTextCodec::codecForLocale()。观察到 file.so 里的 codec 名字叫 UTF-8；跑 Dolphin 里它变成 US-ASCII 了，除非我把 LC_ALL 设成一个 UTF-8 的 locale。

icu and Qt bugsicu 和 Qt 的 bug 们

I digged into the code for that, and it turns out that it ultimately uses ucnv_getDefaultName() to obtain the name of the encoding. That function is from icu. In their bug tracker, I found one that says:

You may need to call setlocale(LC_ALL, ""); from your own code before ICU.

我钻进代码里一看，它用了个叫 ucnv_getDefaultName() 的去获取编码的名字。这函数 icu 里的。在伊们的 bug 追踪器上，我看到一个说：

在 ICU 之前，您可能得从您自己的代码里调用 setlocale(LC_ALL, "");。

And that reminds me. Does Qt call it for us? I searched on Qt's bug tracker and got this:

When using ICU, Qt may call ucnv_getDefaultName() without calling setlocale(.., "") first, which is required before calling ucnv_getDefaultName(). One such possible path is: QString::fromLocal8Bit() -> QTextCodec::codecForLocale() -> QIcuCodec::defaultCodecUnlocked() -> ucnv_getDefaultName() setlocale() is called in QCoreApplicationPrivate::initLocale(), which may not have been called.

But unfortunately, it seems the Qt person does not want to fix it. Ok, I guess, then what is calling ucnv_getDefaultName()? At least, if they do not fix it, I must fix it.

这又给我提了个醒了。Qt 给咱们调用这玩意儿了吗？我搜搜 Qt 的 bug 追踪器，看到这：

用 ICU 时，Qt 可能会调用 ucnv_getDefaultName() 而先前却没有调用过 setlocale(.., "")。后者则是在调用 ucnv_getDefaultName() 之前必须得调用的. 一个可能的途径是： QString::fromLocal8Bit() -> QTextCodec::codecForLocale() -> QIcuCodec::defaultCodecUnlocked() -> ucnv_getDefaultName() setlocale() 是在 QCoreApplicationPrivate::initLocale() 里调用的。但这玩意儿可能还没被调用呢。

How to track down a function call怎么追踪一个函数调用

I did not know. First intuition was to search for fromLocal8Bit in the KIO source. Yields nothing useful. Then it occurred to me that I could use LD_PRELOAD trick. From proxychains to valgrind, they all use LD_PRELOAD to override an existing function. If I override ucnv_getDefaultName() to have it call std::terminate(), I could get a backtrace using gdb. So here it is:

我不知道啊。第一个直觉是在 KIO 源码里搜 fromLocal8Bit。并没有用。然后我突然想起来 LD_PRELOAD 的伎俩了。从 proxychains 到 valgrind，都用了 LD_PRELOAD 去覆盖一个已有的函数。如果我把 ucnv_getDefaultName() 覆盖了，让它调用 std::terminate()，我便能用 gdb 整个 backtrace 出来。所以就这样了：

#include <exception>

extern "C" const char *ucnv_getDefaultName(void)
{
    std::terminate();
    return "";
}

Compile that file with g++ ucnv-override.cpp -shared -fPIC -o ucnv-override.so and set LD_PRELOAD=/path/to/ucnv-override.so. Use gdb to invoke dolphin. Got a backtrace. And it's there:

用 g++ ucnv-override.cpp -shared -fPIC -o ucnv-override.so 编译那文件，设下 LD_PRELOAD=/path/to/ucnv-override.so。用 gdb 启动 dolphin。弄出一个 backtrace。搁这儿呢：

#26 0x00007ffff582370b in QLoggingCategory::init(char const*, QtMsgType) () from /usr/lib64/libQt5Core.so.5
#27 0x00007ffff772d29b in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
    at /home/tusooa/Code/kio/src/widgets/kdirmodel.cpp:39
#28 0x00007ffff772d2ce in _GLOBAL__sub_I_kdirmodel.cpp(void) ()
    at /home/tusooa/Code/kio/build/src/widgets/KF5KIOWidgets_autogen/include/moc_kdirmodel.cpp:155
#29 0x00007ffff7fe1c1e in ?? () from /lib64/ld-linux-x86-64.so.2

No statement from main, no statement from Dolphin. It is in the initialization of a global variable. And that is:

没有 main 的语句。没有 Dolphin 的语句。这玩意是在初始化全局变量的。呐看：

1	static QLoggingCategory category("kf.kio.widgets.kdirmodel", QtInfoMsg);

The QLoggingCategory. But Krita uses that for debug too, while I do not have any issues dealing with Chinese file names? It turns out that we have been using the Q_LOGGING_CATEGORY macro, and "The implicitly-defined QLoggingCategory object is created on first use, in a thread-safe manner." (from Qt doc) So in that case, the initialization is always run after entering main(), where setlocale() has been called already.

这 QLoggingCategory。但 Krita 也用它做调试啊，我也没发现处理中文文件名有啥问题啊？原来是我们用的是 Q_LOGGING_CATEGORY 宏，而「这隐式定义的 QLoggingCategory 对象在初次使用时给创建的，这过程还线程安全。」（来自 Qt 文档）所以那情况下，初始化肯定在进了 main()，setlocale() 被调用过了的时候才运行了的。

So, replace that with Q_LOGGING_CATEGORY(category, "kf.kio.widgets.kdirmodel", QtInfoMsg), and everything went back to normal. ~~200 IQ.~~

所以啊，把那换成 Q_LOGGING_CATEGORY(category, "kf.kio.widgets.kdirmodel", QtInfoMsg)，啥东西都正常了。~~智商 200。~~

Some multilingual hacks on Hexo 瞎折腾Hexo的多语言

2020-10-10T20:55:15.000Z

I do not know why exactly I am so stubborn to insist on making this site multilingual, and in a way that you may see multiple languages at the same time. But it is something.

我自己也不明白为什么我执拗得一定要把这网站做成多语言的，还是叫人能同时看到多种语言的那种。但聊胜于无吧。

A weird thing about HexoHexo 的诡异事件

The first weird thing I got, when I was trying to figure out hexo-theme-next: sometimes hexo server gives the perfect result, but when I hexo generate or hexo deploy, nothing will be correct. Everything is just malformed, and it does not change even if I hexo clean.

我在折腾 hexo-theme-next 的时候碰到的第一个诡异事件是：有时候 hexo server 给出了个无懈可击的结果，但只要一 hexo generate 或者 hexo deploy，全完蛋。整个网站看着都非常诡异，甚至我 hexo clean 了之后也没有丝毫变化。

After digging a lot into the source code, and enabling --debug, I finally found that there are some backup files that are also processed. And the content of those files does correspond to the wrong contents on the site. "Okay," hereby I say, "this behaviour is indeed ridiculous."

钻进源码里东张西望了好久，再合着 --debug 的加成，我终于看到了一些备份文件也被处理了。而其内容确然是应了网站上有问题的东西。「行吧，」如是我说，「是事直令人齿冷。」

And thus I added the ignore rules to ignore all such files, and everything is hopefully back in place.

所以我加了忽略规则来忽略这种文件，世界终于清净了，谢天谢地。

ignore:
  - "**/*~"
  - "**/#*"
  - "**/.#*"

NexT's language switcherNexT 的语言切换器

That is an even more terrible part that comes in. Yes, NexT comes with such a thing called a "language switcher," but it never takes you to a right place. I cannot even get Hexo generate pages for different languages, no matter how I change the language parameter in _config.yml. So whenever I click on the language switcher, I got a 404. And it is hidden at the very bottom of the page --- How should one expect their visitor to dig into the deepest hole before they can switch languages?

这玩意儿甚至更可怕了。是是是，NexT 有个叫「语言切换器」的东西，但是它总把人引入歧途。让 Hexo 给不同的语言分别生成页面，这我怎么改 _config.yml 里的 language 参数，也弄不成。所以呢，每次按下这语言切换器的时候，404 就浮现在我眼前了。而且这切换器给藏在了页面最底下——让访客钻进最深的洞里才许其切换语言，这能成吗？

So, well, since NexT's language switcher sucks, and multi-page style multi-language implementation is not feasible, why not just put everything all together? NexT at least provides a way to customize what texts are shown... in languages.yml.

啊啊，行吧，NexT 这语言切换器是糟透了，多页面显示多语言也办不到，那么把所有东西全放一起，这又如何呢？NexT 至少给了个用 languages.yml 来控制显示什么文字的方法呀......

The main idea is to merge NexT's default translations into one. I made a Perl script for this. The text for every language is a span, and they are next to each other. Use css to put a divider between every visible span. Whether a language is shown is controlled by a JavaScript program that adds or removes classes from the elements.

大意就是把 NexT 的默认翻译全整一起去。这事我写了个 Perl 脚本去做。每种语言的文字装在一个 span 里，并并排。用 css 在每个显示了的 span 之间，摆一个分割线。至于某种语言是显示呢是隐藏呢，这让 JavaScript 程序来控制，就从元素里加上或是减去些 class 就好。

As I am too lazy, the code is all on GitLab. Whether this is a viable implementation is left as an exercise for the reader.

因为我太懒了，代码都在 GitLab 上。这东西到底可行不，留给读者作练习。

Fix firefox address bar clickSelectsAll bug (Spoiler: no re-compilation required.)

2020-10-02T00:15:56.000Z

A couple of months ago, I opened my Firefox as usual, I found out that when I click on the address bar, it dared to select everything in it as if any creepy browser would do! The first thing I did is to check the clickSelectsAll pref -- what I always do first after getting a new install of Firefox on Windows is setting this pref to false, and setting doubleClickSelectsAll pref to true: that is the default behaviour for Firefox on GNU/Linux... that time at least...

Much to my disappointment, the pref are setting correctly, but nothing works. I tried to search for this, but without success, maybe since this bug was so new, or I was to silly to apply the right keywords (huh, maybe the latter one?). So I created an account on Mozilla's bugtracker just to open a bug. At the same time I switched back to the ESR version of Firefox, which rid me (till recently) of this stupid address bar but still granted me security updates. A few days ago, however, Firefox ESR was unfortunately eventually shipped with this bug, calling for a solution.

Some more background

Here I will add more background because I need to complain a lot (>w<). If you would like to see the solution directly, jump there.

Someone on bugzilla pointed out that the bug had been raised by someone else. Following that bug, I saw that the developer was being pretty toxic and just marked it as WONTFIX, despite many people criticized the buggy behaviour and regarded the original behaviour as signature of Firefox. I finally switched from Ubuntu to Gentoo after the new ESR, as I would like to have more control of my software.

Yesterday I talked to tiar about the freedom of users to make software behave the way they want, without necessarily being a developer. I complained that many free/libre software does not excel in this aspect, using Firefox >=75 as an example.

The thing Firefox developers does, by removing the clickSelectsAll prefs, is actually somewhat limiting users' freedom, as customization becomes harder and harder. This kind of freedom has been brought up by a KDE person as a goal called "freedom out of the box." In short, it aims to make changing the behaviour of a program as easy as just using it, probably unifying the interface where a program is used and where a program is customized.

And that is reasonable: no one should have to spend quite a long time reading an extraordinarily large code base just to make a tiny little change that would significantly improve their lives. We will simply not have that much time. I know tweaking system is fun... (should I say addictive?) but still, instant result is always a good-to-have.

The solution

For Firefox, we do have a solution without needing to recompile. That is, to change the omni.ja pack in the Firefox distribution. Based on that I managed to restore the old good urlbar behaviour.

For my firefox-bin on Gentoo, the relevant file is at /opt/firefox/browser/omni.ja.

First make a copy of that file:

1	cp -v /opt/firefox/browser/omni.ja omni.ja.orig

Then unzip the file:

1	mkdir omni && unzip -d omni /opt/firefox/browser/omni.ja

It may return 2, but does not matter.

Then edit the modules/UrlbarInput.jsm:

Change

1	this._preventClickSelectsAll = this.focused;

1	this._preventClickSelectsAll = true;

to get the clickSelectsAll behaviour.

Change
1
if (event.target.id == SEARCH_BUTTON_ID) {
to
1
2
3
4
if (event.detail == 2) {
this.select();
event.preventDefault();
} else if (event.target.id == SEARCH_BUTTON_ID) {
to get the doubleClickSelectsAll behaviour.

Note that this will not put the url into primary selection upon double click. This can be useful sometimes, if you just would like to replace the current url with the one currently in primary selection. If you would like to put the url into primary selection upon double click, which completely restores the original behaviour, change it to
1
2
3
4
if (event.detail == 2) {
this.inputField.select();
event.preventDefault();
} else if (event.target.id == SEARCH_BUTTON_ID) {
instead.

I have also made a patch:

] diff -Naur omni-old omni
diff -Naur omni-old/modules/UrlbarInput.jsm omni/modules/UrlbarInput.jsm
--- omni-old/modules/UrlbarInput.jsm    2010-01-01 00:00:00.000000000 -0500
+++ omni/modules/UrlbarInput.jsm        2020-10-01 19:50:41.925266392 -0400
@@ -2225,7 +2225,7 @@
         }

         this.focusedViaMousedown = !this.focused;
-        this._preventClickSelectsAll = this.focused;
+        this._preventClickSelectsAll = true;

         if (event.target != this.inputField) {
           this.focus();
@@ -2242,7 +2242,11 @@
           this.selectionStart = this.selectionEnd = 0;
         }

-        if (event.target.id == SEARCH_BUTTON_ID) {
+        // doubleClickSelectsAll
+        if (event.detail == 2) {
+          this.select();
+          event.preventDefault();
+        } else if (event.target.id == SEARCH_BUTTON_ID) {
           this._preventClickSelectsAll = true;
           this.search(UrlbarTokenizer.RESTRICT.SEARCH);
         } else {

There is also the search bar to change. The original Superuser answer suggests this, but as I do not use the search bar, I have not tried it out, nor do I know what the original behaviour of it was.

1	sed -i 's/this\._preventClickSelectsAll = this\._textbox\.focused;/this._preventClickSelectsAll = true;/' omni/chrome/browser/content/browser/search/searchbar.js

After editing, we need to re-pack the files:

1	cd omni && zip -0DXqr ../omni.ja * && cd -

And replace the original one:

1	cp -v omni.ja /opt/firefox/browser/omni.ja

You may need to change the ownership of the newly-created archive:

1	chown [U]:[G] /opt/firefox/browser/omni.ja

where [U] and [G] refers to the owner and group of the original file (we made a backup at omni.ja.orig).

To ensure everything takes effect, make a file called .purgecaches to make Firefox aware of the changes:

1	touch /opt/firefox/browser/.purgecaches

Okay, from now on, we shall no longer suffer from the clickSelectsAll bug.

Also, you may want to have additional configurations, such as disabling the pop-up list upon clicking address bar or gettind rid of the address bar expanding effect when clicked upon.

Pay another respect to kritacommand--which we are going beyond

2019-08-24T23:51:09.000Z

Your work is gonna make Krita significantly different. -- Wolthera, Krita developer and digital artist

Krita's undo system, namely kritacommand, was added 8 years ago to Calligra under the name of kundo2, as a fork of Qt's undo framework. The use of undo commands, however, might have an even longer history. Undo commands provide a way to revert individual actions. Up to now, most (though not all) undo commands do it by providing two sets of code that do and undo the actions, respectively. Drawbacks of this system includes (1) it is not very easy to manage; (2) it may introduce duplicated code; and (3) it makes it hard to access a previous document state without actually going back to that state. What I do is to start getting rid of such situation.

The plan for a new system is to use shallow copies to store documents at different states. Dmitry said "it was something we really want to do and allows us to make historical brushes (fetch content from earlier document states)." And according to him, he spent years to implement copy-on-write on paint layers. He suggested me to start from vector layers which he thought would be easier since it does not need to be very thread-safe.

I completely understood that was a challenge, but did not realize where the difficult part was until I come here. Copy-on-write is not the challenging part. We have QSharedDataPointer and almost all the work is to routinely replace the same code. Porting tools is more difficult. The old flake tools are running under the GUI thread, which makes no requirement on thread-safety. Technically we do not need to run it in a stroke / in image thread but with no multithreading the tools runs too slowly on some computers (read as "my Thinkpad laptop") so I am not unwilling to take this extra challenge. In previous posts I described how the strokes work and the problems I encountered. Besides that there are still some problems I need to face.

the HACK code in the stroke strategy

At the last of the strokes post, I proposed a fix to the crash when deleting KisNode, which is messy. After testing with Dmitry at the sprint, we discovered that the real problems lies in KoShapeManager's updateTreeCompressor. It is used to schedule updates of its R-tree. However, it is run at the beginning of every other operation so Dmitry says it is no longer needed. After the compressor was removed we are safe to delete the node normally so there would be no need for such hack code.

Path tool crashing when editing calligraphic shapes

Calligraphic shapes, coming from Karbon, is a shape created by hand-drawing. It has many path points and editing it using path tool usually leads to a crash. Dmitry tested it with ASan and discovered the problem occurs because the path points, which is fetched in the GUI thread to paint the canvas, could be deleted when editing the shape. He suggests to apply a lock to the canvas, not allowing the image and GUI threads to access the shapes concurrently.

Keeping selections after undo/redoing

This challenge is a smaller one. The shape selections were not kept, since they are not part of the layer. It was owned by the layer's shape manager, though, but a cloned layer would take a brand-new shape manager. In addition undo() and redo() will now replace the whole layer, so pointers to original shapes are no longer valid. This means merely keeping the selections from the shape manager would not work. The solution is to map the selected shapes to the cloned layer, which would be kept in the undo command. The strategy I use is similar to what we have done for layers: go through the whole heirarchy of the old layer and push everything into a queue; go through the heirarchy of the cloned layer in the same order and each time take the first shape in the queue; if the popped shape is in the selection, we add its counterpart in the cloned layer to our new selection.

For now the tools should be working and the merge request is prepared for final review. Hopefully it would make its way to master soon.

The Sprint

2019-08-22T03:16:54.000Z

Hi -)) haven't posted for some time, because I was busy travelling and coding for the first half of the month. From Aug 5 to Aug 9, I went to the Krita Sprint in Deventer, Netherlands.

According to Halla, I was the first person to arrive. My flight took a transit via Hong Kong where some flights were affected due to natural and social factors, but fortunately mine was not one of them. Upon arrival in Amsterdam I got a ticket for the Intercity to Deventer. Railway constructions made me take a transfer via Utrecht Centraal, but that was not a problem at all: the station has escalators going both up to the hall, and down to the platforms (in China you can only go to the hall by stairs or elevator (which is often crowded after you get off)). When I got out of Deventer Station, Halla immediately recognized me (how?!). It was early in the morning, and the street's quietness was broken by the sound of me dragging my suitcase. Halla led me through Deventer's crooked streets and alleys to his house.

For the next two days people gradually arrived. I met my main mentor Dmitry (magician!) and his tiger, Sagoskatt, which I (and many others) have mistaken for a giraffe. He was even the voice actor for Sago. He had got quite a lot of insights into the code base (according to Halla, "80%") and solved a number of bugs in Krita (but he said he introduced a lot of bugs, ha!). Also I met David Revoy (my favourite painter!), the author of Pepper and Carrot. And Tiar, our developer who started to work full-time on Krita this year; she had always been volunteering to support other Krita users and always on the IRC and Reddit. And two of other three GSoC students for the year: Blackbeard (just as his face) and Hellozee. Sh_zam could not come and lost communications due to political issues, which was really unfortunate (eh at least now he can be connected). It is feels so good to be able to see so many people in the community -- they are so nice! And it is such an experience to hack in a basement church.

On Aug 7 we went to the Open Air Museum. It displays a large extent of the history in the Netherlands, how their people lived. After a really delicious lunch we went out and started to do paintings. I was to paint on my Surface using Krita, but unfortunately it went out of battery so I had to gave up and painted on a postcard. The tram in the museum is my favourite one (I am always fond of transit) and they even have a carhouse where stood lots of old vehicles. Except for my head which hit the ceiling of the coach three times, everything that day was wonderful.

The next day was the main meeting. In the morning we discussed the development plans for Krita. Bugs. Stability. New features. David Revoy came up again with the docker size problem, which Halla simply called it "a Qt problem." He said, "Yes I do know what to do with that, but new users probably don't and thus we gotta address it and not solely blame Qt." (Yeah it troubled me a lot as well!) Another thing closely related to me was building on Windows, which was largely neglected by KDE. In the afternoon the focus shifted to marketing. I did not know much about it, but it is a fact that we cannot produce electricity out of love. We spent quite a lot of time on the painting competition for Krita. Where it should be held. How to collect the paintings. How to filter out good pictures. Krita promotes new artists. They promote our software.

For the next two days people started leaving. I left on the 10th, and then slept for a whole day when I got to Nanjing (so tired...). On Aug 14th I left again for Toronto, and then restarted to write code and debug. I finally got the time to write this post today, as I finally fixed a crash in my project. It is almost finished, and soon another post would be made on it.

Strokes are Working Now

2019-07-26T15:40:29.000Z

Okay, good news today. I have been porting DefaultTool to the new node-replacing system and it is working now, finally, at least for the part I have already done.

The work involves combining a number of different modules in Krita: the stroke system, KoInteractionTool and its interaction strategies, and, well, the COW mechanism in Flake.

KoInteractionTool is the class used to manage the interaction with vector shapes, and is subclassed by DefaultTool. The behaviours of KoInteractionTool (and thus DefaultTool) are defined by KoInteractionStrategys. Upon the press of the mouse button, DefaultTool creates an instance of some subclass of KoInteractionStrategy, say, ShapeMoveStrategy, according to the point of the click as well as keyboard modifiers. Mouse move events after that are all handled by the interaction strategy. When the mouse is released, the interaction strategy's finishInteraction() is called, and then createCommand(). If the latter returns some KUndo2Command, the command is added to the undo history. Till now it sounds simple.

So how does the stroke system come in? I have experimented the interaction strategy without the stroke system (https://invent.kde.org/tusooaw/krita/commit/638bfcd84c622d3cfefda1e5132380439dd3fdc2), but it is really slow and even freezes Krita for a while sometimes. The stroke system allows the modification of the shapes to run in the image thread, instead of the GUI thread. A stroke is a set of jobs scheduled and run by a KisStrokesFacade (here, KisImage). One creates the stroke in a strokes facade using a stroke strategy, which defines the behaviour of the stroke. After creation, jobs can be added to the stroke and then executed at some later time (it is asynchronous).

So combining these two, we have an interaction strategy and a stroke strategy -- when the interaction strategy is created, we start the stroke in the image; when there is mouse move, we add individual jobs that change the shapes to the stroke; when the mouse released, we end the stroke. My discussion with Dmitry firstly tended to make the interaction strategy inherit the stroke strategy but later it proves not a viable solution since the interaction strategy is owned and deleted by KoInteractionTool while the stroke strategy is owned by the stroke --- which will lead to double deletion. So we divide it into two classes instead: the interaction strategy starts the stroke, and the stroke strategy takes a copy of the current active layer upon creation; when handling mouse move events, a job is added to the stroke to modify the current layer; finally when the interaction finishes, the interaction strategy ends the stroke and creates an undo command if the layer has been changed.

A problem I found lies in the final stage--if the mouse is released as soon as being pressed and no undo command is created, Krita will simply crash. It does not happen when I use gdb to start Krita so it seems to be a timing issue though it leads to difficulty for debugging as well. Dmitry used a self-modified version of Qt to produce a backtrace, indicating the problem probably lies in KisCanvas2's canvasUpdateCompressor, which is not thread-safe. However, after I changed it to KisThreadSafeSignalCompressor, the crash still happens, unfortunately.

The final inspiration comes from the comments in KisThreadSafeSignalCompressor, though. It indicates we cannot delete the compressor from other threads --- we have to use obj->deleteLater() instead, since it lies in the gui thread. And aha, that is the problem. The stroke strategy's destructor is executed in the image thread; if the undo command is not created, there is only one reference to our copied KisNode, namely in our stroke strategy, so it has to be destructed there. However, upon the creation of the KisNode, it is moved into the gui thread. So it simply means we cannot let it be deleted in the image thread. The solution looks a little bit messy, but it works:

KisNode *node = m_d->originalState.data(); // take the address from KisSharedPtr
node->ref(); // prevent KisSharedPtr from deleting the node
m_d->originalState.clear(); // now node is not being referenced by any KisSharedPtr
node->deref(); // the reference count is now zero again
node->deleteLater(); // it will be deleted by the event loop, later

`make -j5 kritaflake`

2019-07-09T17:37:14.000Z

At the end of June I finished copy-on-write vector layers. From the very beginning, I have been researching into possibilities to make kritaflake implicitly sharable. In that post I mentioned the way Sean Parent uses for Photoshop, and adapted it for the derived d-pointers in Flake.

Derived d-pointers

TL;DR: We got rid of it.

As I mentioned in the task page, derived d-pointers originally in Flake are a barrier to implicit sharing. One of the reasons is that we need to write more code (either KisSharedDescendent wrapper class, or repeated code for virtual clone functions). Also, derived d-pointers do not actually encapsulate the data in the parent classes -- for example, the members in KoShapePrivate are all accessible by descendents of KoShape, say, KoShapeContainer. That is probably not how encapsulating should work. So in the end we decided to get rid of derived d-pointers in Flake.

This leads to one problem, however, in the class KoShapeGroup. KoShapeGroup is a descendent of KoShapeContainer, which owns a KoShapeContainerModel that can be subclassed to control the behaviour when a child is added to or removed from the container. KoShapeGroup uses ShapeGroupContainerModel which performs additional operations specific to KoShapeGroup.

After I merged my branch into master, it was said that Flake tests failed under address sanitizer (ASan). I took a look and discovered that there was use after free in the class KoShapeGroup, namely the use of its d-pointer. The use is called by the destructor of KoShapeContainer, which calls KoShapeContainerModel::deleteOwnedShapes(), which removes individual shapes from the container, which then calls KoShapeGroup::invalidateSizeCache(). The original situation was:

destructor of KoShapeGroup was called;
members defined in KoShapeGroup got deleted (nothing, because everything is in the derived d-pointer which is defined in KoShape);
destructor of KoShapeContainer was called, which calls d->model->deleteOwnedShapes();
then that of KoShape, which deletes all the private members.

But after the derived d-pointers are converted to normal ones, the calling sequence upon destruction becomes:

destructor of KoShapeGroup was called;
members defined in KoShapeGroup got deleted (its own d-pointer);
destructor of KoShapeContainer was called, which calls d->model->deleteOwnedShapes();
d->model is a ShapeGroupContainerModel, which will call KoShapeGroup::invalidateSizeCache();
that last function accesses the d-pointer of KoShapeGroup, USE AFTER FREE.

In order to solve this problem we have to manually call model()->deleteOwnedShapes() in the destructor of KoShapeGroup, at which time the d-pointer is still accessible.

q-pointers

TL;DR: We also got rid of it.

q-pointers are a method used in Qt to hide private methods from the header files, in order to improve binary compatibility. q-pointers are stored in *Private classes (ds), indicating the object that owns this private instance. But this is, of course, conflicting with the principle of "sharing" because the situation now is that multiple objects can own the same data. The q-pointers in flake is rather confusing under such circumstances, since the private data cannot know which object is the caller.

To avoid this confusion, there are multiple ways:

to move all the functions regarding q-pointers to the public classes;
to pass the q-pointer every time when calling those functions in private classes; or
to add another layer of "shared data" in the d-pointer and keep the q-pointers in the unshared part.

To enable implicit sharing for the KoShape hierarchy, the only thing left to be done is to change the QScopedPointer<Private> d; in the header file to QSharedDataPointer<Private> d; and make the private classes inherit QSharedData. This step is rather easy and then just run the tests to make sure it does not break anything. Horray!

Snapshot Docker

2019-06-21T15:40:38.000Z

Over the past few weeks I have been working on the Snapshot Docker, and now it is finished already. -))

The idea of snapshots is to make copies of the current document and allow users to return to them at a later time. This is a part of my whole Google Summer of Code project, which aims to bring Krita a better undo/redo system. When fully implemented, it will fully replace the current mechanism that stores actions with one that stores different states. That is to say, Krita will create a snapshot of the document for every undoable step.

Snapshot Docker is not only a feature requested by artists but also a experimental implementation of the clone-replace mechanism. It has the following key parts:

Cloning the document, which is provided by KisDocument::lockAndCloneForSaving(), which is already implemented in master.
Replace the current document by another one, which is previously cloned.

Part (1) is already implemented so the work falls mainly on Part (2). My original approach is to replace the document and image pointers in KisView and KisCanvas, but it is not viable since other parts of the program have signal/slot connections on the KisDocument and KisImage, and directly replacing the two pointers will not only fail to work but also cause weird crashes. After discussing with Dmitry, we find out that it is probably better not to touch these two pointers, but to replace the content within KisDocument and KisImage. It is therefore suggested that two member functions be made, namely KisDocument::copyFromDocument and KisImage::copyFromImage. These functions copies data from another document/image to the current one, avoiding the changes to the pointers inside the original instance. Eh, except for the nodes, since we have to reset and refresh the nodes in the image.

It is also important to notify other parts of Krita about the change in the document. One important thing is tell the layer docker about the changes in the nodes (they are completely different), which is done using the KisImage::sigLayersChangedAsync() signal. The current activated node is also stored and restored, by using the strategy of linearizing the layer tree using a queue, and then finding the corresponding node in the cloned image. Note that when restoring, we are unable to find layer by uuid, since they should change when copied to the current image (the comments in KisImage says the only situation where we should keep the uuids is for saving).

Another interesting thing is the palettes. Krita 4.2.0 allows documents to store their own, local palettes. The palette list is but a QList<KoColorSet *>, meaning that only creating a new QList of the same pointers will not work. This is because, the palettes are controlled by canvas resource manager, which takes the responsibility to delete them. Therefore, when taking snapshots, we had better take deep copies of the KoColorSets. And then another problem comes: the snapshots own their KoColorSets because they are not controlled by the resource manager in any way; but the KisDocument in the view does not. So we have to set up another flag, ownsPaletteList, to tell the document whether it should delete the palettes in the destructor.

And now the work has shifted to the refactoring of kritaflake, the library that mainly handles vector layers and shapes. I converted the whole KoShape hierarchy to implicit sharing where possible, but some tests are broken. I am now on Windows, where unit tests do not run. I will continue the development of flake as soon as I get access to my Linux laptop.

New Style Signal/Slot Connection

2019-06-17T00:12:56.000Z

Yes, I know. The last post on the assistants is rather boring. And yet these days I have been working on the snapshot docker, though it still seems a little (just a little, you see) unfinished as Dmitry is said to experience a relatively high delay when switching between snapshots. However this is not what I can reproduce on my older laptop, so I am really waiting for his test results in order to further investigate the problem.

But there is something interesting happening just when I am randomly testing things. From Krita's debug output, I saw QObject::connect() complaining about the arguments I passed, saying it is expecting parenthesis. "Okay," I thought, "then there have to be something wrong with the code I wrote." And that was quite confusing. I remember having used member function pointers in those places, got a compile-time error since KisSignalAutoConnectionsStore did not support the new syntax, then switched back to the SINGAL() and SLOT() macros. KisSignalAutoConnectionsStore is a helper class to quickly (dis)connect a group of connections. One can use the addConnection() method to add a connection, and use clear() to remove all connections made before.

Well, everything good, apart from the fact that I missed the parenthesis, which I did not discover until I looked into the debug output. So I asked Dmitry why not add the new syntax to KisSignalAutoConnectionsStore, and he said we should.

What is good about the new syntax is compile-time checking. We probably do not want our connections to fail to be made only when you run the program, just because there is a typo in the signature. That is definitely tiring and hard to catch (hmm, I did not notice the problem until today I randomly glanced at the command line; it might be worse if I shipped the snapshot docker together with those careless bugs).

The modification to the code seems straightforward. All what happens is in the KisSignalAutoConnection class. In its constructor, the connection is made using QObject::connect(); in its destructor, the connection is removed by passing the same sets of arguments to QObject::disconnect() currently in master. The signature is just KisSignalAutoConnection(const QObject *, const char *, const QObject *, const char *), as SIGNAL() and SLOT() macros are but to append their arguments to the string "1" and "2" respectively.

So the problem we have is we do not want the arguments that specify the signals and/or slots to be just strings. We want them to be pointers to member functions, or maybe lambdas. According to QObject document, the signature for new-style connect() is:

1	QMetaObject::Connection QObject::connect(const QObject sender, PointerToMemberFunction signal, const QObject context, Functor functor, Qt::ConnectionType type = Qt::AutoConnection)

Okay, so we know that sender and receiver should be pointers to QObjects, and either the type of signal or functor we do not know. Now let's make our KisSignalAutoConnection constructor a template function:

template<class Signal, class Method>
inline KisSignalAutoConnection(const QObject *sender, Signal signal,
                               const QObject *receiver, Method method
                               Qt::ConnectionType type = Qt::AutoConnection);

But when these parameters are passed to QObject::connect(), we get a compile-time error, saying there is no matching overload for connect().

Why?

The answer is the Qt documentation is simplifying, if not hiding, the truth. The real definition for connect() is found in Line 227 of qobject.h:

template <typename Func1, typename Func2>
static inline QMetaObject::Connection connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal,
                                 const typename QtPrivate::FunctionPointer<Func2>::Object *receiver, Func2 slot,
                                 Qt::ConnectionType type = Qt::AutoConnection)

And tracking down the definition of QtPrivate::FunctionPointer, we get it in qobjectdefs_impl.h:

template<class Obj, typename Ret, typename... Args> struct FunctionPointer<Ret (Obj::*) (Args...)>
{
    typedef Obj Object;
    ...
};

And seeing what we have passed to KisSignalAutoConnection (in the test code):

1 2	KisSignalAutoConnectionsStore conn; conn.addConnection(test1.data(), &TestClass::sigTest1, test2.data(), &TestClass::slotTest1);

We can see that Func1 is a member function of TestClass, so QtPrivate::FunctionPointer<Func1>::Object is just TestClass. But the constructor of KisSignalAutoConnection receives a const QObject *. The problem here is that connect() is expecting a const TestClass *, but we give them a const QObject *. A base class pointer cannot be implicitly converted to a derived class pointer, so we have that error.

The resolution seems pretty simple, as we only need to include the types of sender and receiver into the template, and pass everything as-is to QObject::connect():

1
2
3

template<class Sender, class Signal, class Receiver, class Method>
inline KisSignalAutoConnection(Sender sender, Signal signal, Receiver receiver, Method method,
                               Qt::ConnectionType type = Qt::AutoConnection);

Sounds viable. But how can we store the four parameters? It might be intuitive to make another base class, say, KisSignalAutoConnectionBase(), and make KisSignalAutoConnection a template class, so we can store sender, receiver, etc.

But wait, isn't this just too complex? First of all, we do not have any overridden functions except for the destructor. What is more, we do not seem to have any valuable things in that base class -- it would be an empty class. The use of inheritance here is ugly and useless.

And, we do not need to store the four parameters at all. QObject::connect() returns a QMetaObject::Connection, which can be used later to disconnect() it. So instead of the parameters passed to connect(), we just store the Connection object. And that is not part of the template:

public:
    template<class Sender, class Signal, class Receiver, class Method>
    inline KisSignalAutoConnection(Sender sender, Signal signal, Receiver receiver, Method method,
                                   Qt::ConnectionType type = Qt::AutoConnection)
        : m_connection(QObject::connect(sender, signal, receiver, method, type))
    {
    }
    
    inline ~KisSignalAutoConnection()
    {
        QObject::disconnect(m_connection);
    }

private:
    QMetaObject::Connection m_connection;

And with the test code mentioned above, we do make sure that the new implementation works well with both syntaxes.

So, great, krita developers, we can use the new syntax for auto connections as well.

PS: There will soon be another post on my work of the snapshot docker -- it's almost finished!

Assistants -- copy, share, assignment

2019-05-30T18:20:53.000Z

Over the last week I have been investigating into Bug 361012, on the undo history of the modification of guides. But from the very beginning I mixed up the two terms "guides" and "assistants," so I decided to work on both. The work with guides is a lot simpler and will not be covered here, though.

As I write this post, the master branch of Krita does not create any undo commands for the document. I first added undo commands for adding and removing assistants, which seems the easiest. The editing of them is a bit more difficult, as the dragging operations involve the movement of many "handles," the movable round buttons that define the position of one or more assistants. The source code on master for implementing such actions is quite complicated and involves a great number of cases. It would be another great endeavour to put all these bunches of code into a KUndo2Command. But, another thing I have experimented with and I will be working on will immediately clear the clouds.

So I just thought of the copy-on-write mechanism, and yes, why not? Though COW itself is not actually implemented for the guides, it does seem inspiring. I mean, we can just save a copy of all assistants and, when needed, restore that.

The main problem here is the handles. They are represented as shared pointers in individual assistants and may be shared between different ones (e.g. two perspectives share two corner handles and one side handles). When we take a clone of the list of assistants it will be necessary to keep this kind of relationship. My solution is to use a QMap of pointers, which seems to coincide with the logic of exporting to xml, but I had yet to read that part of the code when writing mine so I did not know about that. The logic is to check, for every handle, whether there is a mapping relationship in the map. If there is, we reuse that handle, and if not, we create a new one with the same position and record that relationship in our QMap.

But some display properties are not to be recorded into the undo history. Such properties include the changing of color, visibility, etc. To resolve this problem, I put these data into a shared pointer and, when we are cloning an assistant for undo/redo, we will reuse that pointer. When we replace the assistant list with the one recorded, all the display properties will remain since the data are shared.

And for the next several weeks I will move onto the Snapshot Docker.

Polymorphism and Implicit Sharing

2019-05-18T18:18:41.000Z

Recently I have been researching into possibilities to make members of KoShape copy-on-write. At first glance, it seems enough to declare d-pointers as some subclass of QSharedDataPointer (see Qt's implicit sharing) and then replace pointers with instances. However, there remain a number of problems to be solved, one of them being polymorphism.

polymorphism and value semantics

In the definition of KoShapePrivate class, the member fill is stored as a QSharedPointer:

QSharedPointer<KoShapeBackground> fill;

There are a number of subclasses of KoShapeBackground, including KoColorBackground, KoGradientBackground, to name just a few. We cannot store an instance of KoShapeBackground directly since we want polymorphism. But, well, making KoShapeBackground copy-on-write seems to have nothing to do with whether we store it as a pointer or instance. So let's just put it here -- I will come back to this question at the end of this post.

d-pointers and `QSharedData`

The KoShapeBackground heirarchy (similar to the KoShape one) uses derived d-pointers for storing private data. To make things easier, I will here use a small example to elaborate on its use.

derived d-pointer

class AbstractPrivate
{
public:
    AbstractPrivate() : var(0) {}
    virtual ~AbstractPrivate() = default;

    int var;
};

class Abstract
{
public:
    // it is not yet copy-constructable; we will come back to this later
    // Abstract(const Abstract &other) = default;
    ~Abstract() = default;
protected:
    explicit Abstract(AbstractPrivate &dd) : d_ptr(&dd) {}
public:
    virtual void foo() const = 0;
    virtual void modifyVar() = 0;
protected:
    QScopedPointer<AbstractPrivate> d_ptr;
private:
    Q_DECLARE_PRIVATE(Abstract)
};

class DerivedPrivate : public AbstractPrivate
{
public:
    DerivedPrivate() : AbstractPrivate(), bar(0) {}
    virtual ~DerivedPrivate() = default;

    int bar;
};

class Derived : public Abstract
{
public:
    Derived() : Abstract(*(new DerivedPrivate)) {}
    // it is not yet copy-constructable
    // Derived(const Derived &other) = default;
    ~Derived() = default;
protected:
    explicit Derived(AbstractPrivate &dd) : Abstract(dd) {}
public:
    void foo() const override { Q_D(const Derived); cout << "foo " << d->var << " " << d->bar << endl; }
    void modifyVar() override { Q_D(Derived); d->var++; d->bar++; }
private:
    Q_DECLARE_PRIVATE(Derived)
};

The main goal of making DerivedPrivate a subclass of AbstractPrivate is to avoid multiple d-pointers in the structure. Note that there are constructors taking a reference to the private data object. These are to make it possible for a Derived object to use the same d-pointer as its Abstract parent. The Q_D() macro is used to convert the d_ptr, which is a pointer to AbstractPrivate to another pointer, named d, of some of its descendent type; here, it is a DerivedPrivate. It is used together with the Q_DECLARE_PRIVATE() macro in the class definition and has a rather complicated implementation in the Qt headers. But for simplicity, it does not hurt for now to understand it as the following:

#define Q_D(Class) Class##Private *const d = reinterpret_cast<Class##Private *>(d_ptr.data())

where Class##Private means simply to append string Private to (the macro argument) Class.

Now let's test it by creating a pointer to Abstract and give it a Derived object:

int main()
{
    QScopedPointer<Abstract> ins(new Derived());
    ins->foo();
    ins->modifyVar();
    ins->foo();
}

Output:

foo 0 0
foo 1 1

Looks pretty viable -- everything's working well! -- What if we use Qt's implicit sharing? Just make AbstractPrivate a subclass of QSharedData and replace QScopedPointer with QSharedDataPointer.

making d-pointer `QSharedDataPointer`

In the last section, we commented out the copy constructors since QScopedPointer is not copy-constructable, but here QSharedDataPointer is copy-constructable, so we add them back:

class AbstractPrivate : public QSharedData
{
public:
    AbstractPrivate() : var(0) {}
    virtual ~AbstractPrivate() = default;

    int var;
};

class Abstract
{
public:
    Abstract(const Abstract &other) = default;
    ~Abstract() = default;
protected:
    explicit Abstract(AbstractPrivate &dd) : d_ptr(&dd) {}
public:
    virtual void foo() const = 0;
    virtual void modifyVar() = 0;
protected:
    QSharedDataPointer<AbstractPrivate> d_ptr;
private:
    Q_DECLARE_PRIVATE(Abstract)
};

class DerivedPrivate : public AbstractPrivate
{
public:
    DerivedPrivate() : AbstractPrivate(), bar(0) {}
    virtual ~DerivedPrivate() = default;

    int bar;
};

class Derived : public Abstract
{
public:
    Derived() : Abstract(*(new DerivedPrivate)) {}
    Derived(const Derived &other) = default;
    ~Derived() = default;
protected:
    explicit Derived(AbstractPrivate &dd) : Abstract(dd) {}
public:
    void foo() const override { Q_D(const Derived); cout << "foo " << d->var << " " << d->bar << endl; }
    void modifyVar() override { Q_D(Derived); d->var++; d->bar++; }
private:
    Q_DECLARE_PRIVATE(Derived)
};

And testing the copy-on-write mechanism:

int main()
{
    QScopedPointer<Derived> ins(new Derived());
    QScopedPointer<Derived> ins2(new Derived(*ins));
    ins->foo();
    ins->modifyVar();
    ins->foo();
    ins2->foo();
}

But, eh, it's a compile-time error.

error: reinterpret_cast from type 'const AbstractPrivate*' to type 'AbstractPrivate*' casts away qualifiers
 Q_DECLARE_PRIVATE(Abstract)

`Q_D`, revisited

So, where does the const removal come from? In qglobal.h, the code related to Q_D is as follows:

template <typename T> inline T *qGetPtrHelper(T *ptr) { return ptr; }
template <typename Ptr> inline auto qGetPtrHelper(const Ptr &ptr) -> decltype(ptr.operator->()) { return ptr.operator->(); }

// The body must be a statement:
#define Q_CAST_IGNORE_ALIGN(body) QT_WARNING_PUSH QT_WARNING_DISABLE_GCC("-Wcast-align") body QT_WARNING_POP
#define Q_DECLARE_PRIVATE(Class) \
    inline Class##Private* d_func() \
    { Q_CAST_IGNORE_ALIGN(return reinterpret_cast<Class##Private *>(qGetPtrHelper(d_ptr));) } \
    inline const Class##Private* d_func() const \
    { Q_CAST_IGNORE_ALIGN(return reinterpret_cast<const Class##Private *>(qGetPtrHelper(d_ptr));) } \
    friend class Class##Private;

#define Q_D(Class) Class##Private * const d = d_func()

It turns out that Q_D will call d_func() which then calls an overload of qGetPtrHelper() that takes const Ptr &ptr. What does ptr.operator->() return? What is the difference between QScopedPointer and QSharedDataPointer here?

QScopedPointer's operator->() is a const method that returns a non-const pointer to T; however, QSharedDataPointer has two operator->()s, one being const T* operator->() const, the other T* operator->(), and they have quite different behaviours -- the non-const variant calls detach() (where copy-on-write is implemented), but the other one does not.

qGetPtrHelper() here can only take d_ptr as a const QSharedDataPointer, not a non-const one; so, no matter which d_func() we are calling, we can only get a const AbstractPrivate *. That is just the problem here.

To resolve this problem, let's replace the Q_D macros with the ones we define ourselves:

#define CONST_SHARED_D(Class) const Class##Private *const d = reinterpret_cast<const Class##Private *>(d_ptr.constData())
#define SHARED_D(Class) Class##Private *const d = reinterpret_cast<Class##Private *>(d_ptr.data())

We will then use SHARED_D(Class) in place of Q_D(Class) and CONST_SHARED_D(Class) for Q_D(const Class). Since the const and non-const variant really behaves differently, it should help to differentiate these two uses. Also, delete Q_DECLARE_PRIVATE since we do not need them any more:

class AbstractPrivate : public QSharedData
{
public:
    AbstractPrivate() : var(0) {}
    virtual ~AbstractPrivate() = default;

    int var;
};

class Abstract
{
public:
    Abstract(const Abstract &other) = default;
    ~Abstract() = default;
protected:
    explicit Abstract(AbstractPrivate &dd) : d_ptr(&dd) {}
public:
    virtual void foo() const = 0;
    virtual void modifyVar() = 0;
protected:
    QSharedDataPointer<AbstractPrivate> d_ptr;
};

class DerivedPrivate : public AbstractPrivate
{
public:
    DerivedPrivate() : AbstractPrivate(), bar(0) {}
    virtual ~DerivedPrivate() = default;

    int bar;
};

class Derived : public Abstract
{
public:
    Derived() : Abstract(*(new DerivedPrivate)) {}
    Derived(const Derived &other) = default;
    ~Derived() = default;
protected:
    explicit Derived(AbstractPrivate &dd) : Abstract(dd) {}
public:
    void foo() const override { CONST_SHARED_D(Derived); cout << "foo " << d->var << " " << d->bar << endl; }
    void modifyVar() override { SHARED_D(Derived); d->var++; d->bar++; }
};

With the same main() code, what's the result?

foo 0 0
foo 1 16606417
foo 0 0

... big whoops, what is that random thing there? Well, if we use dynamic_cast in place of reinterpret_cast, the program simply crashes after ins->modifyVar();, indicating that ins's d_ptr.data() is not at all a DerivedPrivate.

virtual clones

The detach() method of QSharedDataPointer will by default create an instance of AbstractPrivate regardless of what the instance really is. Fortunately, it is possible to change that behaviour through specifying the clone() method.

First, we need to make a virtual function in AbstractPrivate class:

virtual AbstractPrivate *clone() const = 0;

(make it pure virtual just to force all subclasses to re-implement it; if your base class is not abstract you probably want to implement the clone() method) and then override it in DerivedPrivate:

virtual DerivedPrivate *clone() const { return new DerivedPrivate(*this); }

Then, specify the template method for QSharedDataPointer::clone(). As we will re-use it multiple times (for different base classes), it is better to define a macro:

#define DATA_CLONE_VIRTUAL(Class) template<>                      \
    Class##Private *QSharedDataPointer<Class##Private>::clone()   \
    {                                                             \
        return d->clone();                                        \
    }
// after the definition of Abstract
DATA_CLONE_VIRTUAL(Abstract)

It is not necessary to write DATA_CLONE_VIRTUAL(Derived) as we are never storing a QSharedDataPointer<DerivedPrivate> throughout the heirarchy.

Then test the code again:

foo 0 0
foo 1 1
foo 0 0

-- Just as expected! It continues to work if we replace Derived with Abstract in QScopedPointer:

QScopedPointer<Abstract> ins(new Derived());
QScopedPointer<Abstract> ins2(new Derived(* dynamic_cast<const Derived *>(ins.data())));

Well, another problem comes, that the constructor for ins2 seems too ugly, and messy. We could, like the private classes, implement a virtual function clone() for these kinds of things, but it is still not gentle enough, and we cannot use a default copy constructor for any class that contains such QScopedPointers.

What about QSharedPointer that is copy-constructable? Well, then these copies actually point to the same data structures and no copy-on-write is performed at all. This still not wanted.

the `Descendent`s of ...

Inspired by Sean Parent's video, I finally come up with the following implementation:

template<typename T>
class Descendent
{
    struct concept
    {
        virtual ~concept() = default;
        virtual const T *ptr() const = 0;
        virtual T *ptr() = 0;
        virtual unique_ptr<concept> clone() const = 0;
    };
    template<typename U>
    struct model : public concept
    {
        model(U x) : instance(move(x)) {}
        const T *ptr() const { return &instance; }
        T *ptr() { return &instance; }
        // or unique_ptr<model<U> >(new model<U>(U(instance))) if you do not have C++14
        unique_ptr<concept> clone() const { return make_unique<model<U> >(U(instance)); }
        U instance;
    };

    unique_ptr<concept> m_d;
public:
    template<typename U>
    Descendent(U x) : m_d(make_unique<model<U> >(move(x))) {}

    Descendent(const Descendent & that) : m_d(move(that.m_d->clone())) {}
    Descendent(Descendent && that) : m_d(move(that.m_d)) {}

    Descendent & operator=(const Descendent &that) { Descendent t(that); *this = move(t); return *this; }
    Descendent & operator=(Descendent && that) { m_d = move(that.m_d); return *this; }

    const T *data() const { return m_d->ptr(); }
    const T *constData() const { return m_d->ptr(); }
    T *data() { return m_d->ptr(); }
    const T *operator->() const { return m_d->ptr(); }
    T *operator->() { return m_d->ptr(); }
};

This class allows you to use Descendent<T> (read as "descendent of T") to represent any instance of any subclass of T. It is copy-constructable, move-constructable, copy-assignable, and move-assignable.

Test code:

int main()
{
    Descendent<Abstract> ins = Derived();
    Descendent<Abstract> ins2 = ins;
    ins->foo();
    ins->modifyVar();
    ins->foo();
    ins2->foo();
}

It gives just the same results as before, but much neater and nicer -- How does it work?

First we define a class concept. We put here what we want our instance to satisfy. We would like to access it as const and non-const, and to clone it as-is. Then we define a template class model<U> where U is a subclass of T, and implement these functionalities.

Next, we store a unique_ptr<concept>. The reason for not using QScopedPointer is QScopedPointer is not movable, but movability is a feature we actually will want (in sink arguments and return values).

Finally it's just the constructor, moving and copying operations, and ways to access the wrapped object.

When Descendent<Abstract> ins2 = ins; is called, we will go through the copy constructor of Descendent:

Descendent(const Descendent & that) : m_d(move(that.m_d->clone())) {}

which will then call ins.m_d->clone(). But remember that ins.m_d actually contains a pointer to model<Derived>, whose clone() is return make_unique<model<Derived> >(Derived(instance));. This expression will call the copy constructor of Derived, then make a unique_ptr<model<Derived> >, which calls the constructor of model<Derived>:

model(Derived x) : instance(move(x)) {}

which move-constructs instance. Finally the unique_ptr<model<Derived> > is implicitly converted to unique_ptr<concept>, as per the conversion rule. "If T is a derived class of some base B, then std::unique_ptr<T> is implicitly convertible to std::unique_ptr<B>."

And from now on, happy hacking --- (.>w<.)

GSoC 2019

2019-05-13T15:16:48.000Z

This summer will be a little bit interesting as I joined the Google Summer of Code (GSoC). The software I will be working on is Krita. Krita is a painting software I have been using for more than one year. Since the (pre)release of Krita 4.0, I use it to paint all my works.

Before using Krita, I used to use PaintToolSAI, and there are quite a lot of concepts and functionalities in it that I find really useful; after getting involved in the Krita community I am pretty lucky to be able to introduce these little shiny stars to our community, and even implement some of them.

My project for GSoC is on the undo/redo system in Krita. The system currently works using an undo stack to storage individual changes to the document, and invoking these commands to perform undos and redos. This system is complex and not easy to maintain. As Dmitry suggests, a better solution would be storing the states of the document as shallow copies, since it simplifies the system and make history brushes possible. It would be a rather huge and fundamental change in the code, and he recommends me to experiment with vector layers first.

Another part of the project, which is not a research, is the snapshot docker that would allow users to temporarily save some states of the document and return to them quickly at a later time. This is an enhancement on the GUI level, as the tile data in paint layers are shallow copied, making it possible to make a clone of the document relatively fast.

I will make more posts on KDE and Krita in the near future. Let's keep in touch! (.w.)

短代码(一个马后炮)

2018-04-29T10:58:57.000Z

没赶上报名截止日期，一直 not invited。就很难过。

E 的题目描述是这样的。

Description

tz学姐做题很忙，有一些简单的问题需要你帮忙解决：给定三个序列A,B,C和一个整数X, 现在需要找到三个数Ai，Bj，Ck，满足Ai+Bj+Ck = X.

Input

第1行三个整数 L, N, M；

第2行L个整数代表序列A

第3行M个整数代表序列B

第4行N个整数代表序列C

第5行1个整数S代表有S个X。

接下来的S行每行一个整数X

1<=L, N, M<=500, 1<=S<=1000. 所有整数均在32位整数范围内

Output

对于S个询问计算X对应的公式是否能被满足。如能满足，输出 "YES", 否则输出 "NO"。

Sample Input

Sample Output

1
2
3

NO
YES
NO

喵

我当时给出的代码是这样的。

#include <iostream>
#include <algorithm>
using namespace std;
int main() {
  int l,m,n;
  cin>>l>>m>>n;
  int a[l],b[m],c[n];
  for(int&p:a)cin>>p;
  for(int&p:b)cin>>p;
  for(int&p:c)cin>>p;
  sort(c,c+n);
  cin>>n;
  for(int p;cin>>p;){
    for(int q:a)
      for(int r:b)
        if(binary_search(c,c+n,p-q-r)) {
          cout<<"YES\n";
          goto l;
        }
    cout<<"NO\n";
  l:1;
  }
}
//292

由于我不能提交，无法判断它是否超时了。查了一下网上的做法，是把 a 和 b 加起来存到另一个数组里，然后对这个新的数组排序查找。

仔细分析一下就是：

我的方法，排序用了 O(n*log n)，查找 O(n**2*log n)。

另一个做法，排序 O(n**2*log n)，查找 O(n*log n)。

看上去好像正好抵消了没什么区别。问题在于查找是多次查找，我们希望每次查找的时间尽量短。

所以改过的代码是这样的：

#include <iostream>
#include <algorithm>
using namespace std;
int main() {
  int l,m,n,r=0;
  cin>>l>>m>>n;
  int a[l],b[m],c[n],S[l*m]; // GNU 扩展的变长数组
  for(int&p:a)cin>>p;
  // range-for 输入第二组数据，同时将输入的数据和第一组的每一个数字相累加，结果存到 `S` 里。
  for(int&p:b) {
    cin>>p;
    for(int&q:a)S[r++]=p+q;
  }
  for(int&p:c)cin>>p;
  sort(S,S+r);
  cin>>n; // 丢弃个数信息，因为不需要
  for(int p;cin>>p;){
    for(int q:c)
      if(binary_search(S,S+r,p-q)){
        puts("YES");
        goto l; // 直接跳到下次输入，不输出 NO
      }
    puts("NO");
  l:1;
  }
}
//311

排名表上最短是345。

但是有什么用呢。我又不能提交(以后一定要提前关注一下)。

开个坑。。。。

2018-01-26T02:08:32.000Z

嗯大约就是这样0 0。

何事西风不待人

夏末秋初~乘着思念去找你~

Day 0：忙碌的白天和安心的晚上

Day 1：约饭和闲逛

Day 2：睡了一天，然后做了

Day 3：意料之外的事情，可能是上天想让我和她多呆一会儿

和笙的对谈

那些让我活下去的人

只是这样的联结，就已经让人无比地心安了

即使如此也还是谢谢你的陪伴

偶然的相遇和偶然的重逢

那是第一个主动找她交往的人

即使是痛苦的过去，也会有着如明星般闪耀的存在

日后谈

Fediverse: the two years 联邦宇宙：这两年来

-1+y: hitorino

0: t.tusooa.xyz

Watching for Pleroma注视到 Pleroma

Hacking Pleroma

My personal life我的个人生活

systemd -> openRC

Why?为什么啊？

Steps步骤

Configuration配置

NetworkManager

Display manager显示管理器

keymaps (replacement for localectl)keymaps（localectl的替代）

lvm

tmpfs on /tmp (systemd auto-mount)在 /tmp 高头的 tmpfs（systemd 自动挂载的）

backlight (replacement for systemd-backlight)backlight（systemd-backlight 的替代）

alsa

cron

time sync (replacement for systemd-timesync)时间同步（systemd-timesync 的替代）

ufw

bluetooth蓝牙

Finalize完成

What's next?然后呢？

Notes on PinePhone and mobile GNU/Linux systems 关于 PinePhone 和移动端 GNU/Linux 系统的笔记

Experience with openSUSEopenSUSE 的体验

What's working什么能用

Problems问题

Other notes别的笔记

From a weird Dolphin bug 从一个奇怪的 Dolphin bug 说起

From Dolphin to KIO从 Dolphin 到 KIO

icu and Qt bugsicu 和 Qt 的 bug 们

How to track down a function call怎么追踪一个函数调用

Some multilingual hacks on Hexo 瞎折腾Hexo的多语言

A weird thing about HexoHexo 的诡异事件

NexT's language switcherNexT 的语言切换器

Fix firefox address bar clickSelectsAll bug (Spoiler: no re-compilation required.)

Some more background

The solution

Pay another respect to kritacommand--which we are going beyond

the HACK code in the stroke strategy

Path tool crashing when editing calligraphic shapes

Keeping selections after undo/redoing

The Sprint

Strokes are Working Now

`make -j5 kritaflake`

Derived d-pointers

q-pointers

implicit sharing

Snapshot Docker

New Style Signal/Slot Connection

Assistants -- copy, share, assignment

Polymorphism and Implicit Sharing

polymorphism and value semantics

d-pointers and QSharedData

derived d-pointer

making d-pointer QSharedDataPointer

Q_D, revisited

virtual clones

the Descendents of ...

GSoC 2019

短代码(一个马后炮)

Description

Input

Output

Sample Input

Sample Output

d-pointers and `QSharedData`

making d-pointer `QSharedDataPointer`

`Q_D`, revisited

the `Descendent`s of ...