某一天在和 ksyx 同学讨论参与 LLVM 开发过程中遇到的的事情,ksyx 同学提到 llvm 有一个开发者保存了每一天的 clang format 的构建产物,以便于出现问题时二分引入问题的 commit。由此我产生了一个想法,由于主要耗时是在构建庞大的 LLVM,我们何不像 mozregression 一样保存每个 commit 的构建产物,并提供一个工具来完成二分,于是就有了这个项目。
基本思路很简单,就是一个使用预编译二进制版本的 git bisect。用户选定好和坏两个节点,然后程序自动找到二分的中间节点,用户判断好还是坏,如此迭代直至找到第一个坏的commit。
但是这个方案还不够优秀,于是提出了一些改进。
在这个二分的过程中,需要人工干预的部分是判断该 commit 是否正常。由于 llvm 作为一个编译基础设施项目,要判断的东西基本上是编译的输出和结果,不像 Firefox 那样需要进行复杂的 GUI 操作。因此可以考虑自动比对输出结果与正确和错误的结果。
更进一步的,我们可以设计两个机制:其一是维护两个集合,保存正确的和错误的结果,每当遇到不在集合里的结果,就询问用户,并且根据答案将结果加入集合,如此迭代,考虑到大部分情况下大多数结果应该是一样的,这样应该可以大大减少人工介入;其二是维护一个检测脚本模式,对于那些结果不稳定,但是具有特征的情况,用户可以提供一个脚本来判断正确和错误,这样可以大大减少人工判断,考虑到实际情况,这个脚本功能应当支持「无法判断」结果。
可以将构建系统和 LLVM 项目的 CI 结合,复用 LLVM CI 的编译产物,减少资源占用。
考虑到一台 CPU、内存储存和网络带宽俱佳的六边形服务器价格昂贵,又考虑到实际使用场景,应该类似 CDN 和镜像站,提供专门的储存分发节点,此类节点应具有良好的储存和网络环境,专职于内容分发,剩下的少数节点作为编译节点,编译节点应具有高性能的 CPU、充足的内存和快速的储存以加速构建。
为使这个网络简单易维护,考虑使用P2P技术,使得储存节点可以自动的互相获取编译产物,并且自动从编译节点获取编译产物。
编译节点类似于 Bit Torrent 中原始做种者的角色,编译并分发那些没有足够数量的存储节点的东西,当网络中有足够的节点保存有产物副本时,其删除产物以节省本机资源。编译节点同时分发一份映射表,类似于种子,其声明每个产物的校验和,以保证产物未被篡改。
考虑到有些情况下,用户的空间和性能可能不足,我们可以设计一种节点,专职负责进行二分,通过用户计算机上简单低占用的程序通信。
这样可以带来以下的好处:由于检查节点可以和储存节点以及编译节点运行在同一内网,可以获得很高的带宽,甚至使用更直接的方式访问储存节点,这可以很好的提升性能和节省外部带宽;可以不受制于客户端的环境,比如 CPU 和内存资源不足,储存空间不足,带宽不足以及网络不稳定等。
更进一步,既然检查节点可以独立运行,则我们可以提供一个 Web 界面,以进一步降低对客户端的要求。
这项改进带来的问题是,我们需要设计一个权限机制和安全机制,以避免遭到攻击。
]]>CSP 的时候我还和可橙(不认识可橙?这里有一些链接 这个,这个还有这个,如果你还要,那么还有 这个 和 「THUPC 2021 初赛」M. 自白书,以及凤凰周刊2021年第2期(总第747期))面了姬,并约好 NOIP 一起去街上游荡。
可谁曾想,11月29日,我却与她完全断了音讯……我们努力了许多,或者说,挣扎了许多,可是依旧没能带回我们的可橙……
12月11日,NOIP 复赛,可橙依旧没能回来。我怀着悲痛和慌乱的心情走进考场……说实话,我自己也不知道我究竟在考场里发了多久的呆……考场外可橙的事情牵动着我的心弦,我的心无法平静下来,或者说,也不该平静下来。统共四道题,我只做完了一道变草草收回了心神……
自然的,成绩并不理想。但是我并不后悔,或者说,我有什么可后悔的呢……或许,我唯一后悔的,就是没拦下可橙,让她重新回到了父母的魔爪吧……
所以,可橙……我们什么时候才能让你回来呢……
]]>自由软件存在的意义不是为了更好的体验,而是保证在其他有“更好体验”的玩意儿蹬鼻子上脸的时候,你有那个最基本的掀桌子的底气。
(当然这不能成为我不去骂傻× Gnome 和 Rime 开发者的理由,该骂还是要骂 (谁让这俩,尤其是前者还有其他自由软件选择呢
打字的时候基本没有生僻字出来干扰视线(当然这也导致如果你想打生僻字基本打不出来),没有用 OpenCC,避免了使用这种方式实时转换遇到的问题
GitHub 地址:hosxy/rime-aurora-pinyin
AUR 地址:rime-aurora-pinyin
AOSC 的 rime-data
中已包含了此方案
Rime 的简体中文输入主要有两种思路:
前者的优势是用词和词频等都比较准确,简单来说就是用户体验比较好,缺点是总维护量大;
后者则恰好相反,虽然维护量骤减至不到原来的一半,但是用词和词频的准确性大幅度下降,表现为经常出现一些简体中文和现代汉语(大陆)不常用的词汇排在候选词的前面,同时,这种方案采用了实时繁简转换,还会遇到另外一个非常影响用户体验的问题:
部分可被认作繁体的简体字可能会被错误的再次翻译
例如:“徴羽摩柯”这个词中的“徵”就很容易被当作繁体而错误转换为“征”(当然这个字的问题已经修复,但是还有很多很多这样的字,同时又有新词不断产生,怎么能改得完呢?
同样的例子还有“复投”
官方为了减轻工作量采用第一种方法制作了 luna-pinyin-simp 朙月拼音简化字方案,完美的撞上了这两个问题(此外官方给出的理由竟然是选择繁体码表和词库更准确?
后来,官方又制作了 pinyin-simp 袖珍简化字方案和 c2h6-pinyin 乙烷拼音(这次是简体码表了),但是,这个方案延续了官方一贯的态度,不管你用不用的上,先都塞给你,哪怕牺牲用户体验也在所不惜:生僻字比例极高,大量的古音(甚至不是专门研究古代汉语音韵的人都不一定知道这个音……这里就有一个小故事:
AOSC rime-data 维护者:c2h6 打出来的都是那种万年不见一次的生僻字,最重要的是没人用,于是我就 drop 了
一位群友:我就知道佛振搞简体方案会变成这样……
一位群友:这个方案名起的非常应景……
还有一堆古音……
给简体汉语拼音方案上古音……
綾香姐姐:其实有可能是台湾国语(
一位群友:下次让他给繁体方案用大陆简化字音(
https://github.com/lotem/rime-c2h6-pinyin/commit/5fcd1228d35d64f99d334c75114eaf7f3d34a081#diff-6ca64afcf64d153d02639c5e12253dc5R8601 比如这里……我完全没找到出处……
而且有很多字……noto字体都没有……
只有 ttf-hanazono 才有……
綾香姐姐:《集韻》䉷/厂「說文隿射所蔽者也」(打鳥的用來掩蔽的物體)魚杴切 = yán 😂
不知道佛振怎麼找到這讀音的(
一位群友:如果一个汉字 noto 这种字体都没的显示……那么大概率一般人也不会用到……除了研究古文……但是研究古文用繁体啊……
本人保证这个故事的真实性,不信者可自行尝试乙烷拼音以及前往 Rime Telegram 群组观看聊天记录查证
这个方案,其实最初只是 hosxy 自用的方案,可能是处于备份或者分享还是其他的目的,hosxy 将它发布到了 GitHub 上。这个时间点,是2020年3月19日。
后来,由于官方的简化字八股文注音能力过于生草……hosxy 将其从方案中移除。
再后来,hosxy 从 sunpinyin 拿来了约5w条词语……
然后,因为词频问题,hosxy 简单的为其按照教育部标准一二三级字添加了粗略的字频
随后,这个方案被群友发现大家开始合理试图改进这个方案:綾香姐姐根据 Unihan 数据库调整了单字字频,hosxy 又单独将简化字八股文的词库抽出使用
渐渐的,这个方案变得越来越好用了……
我觉得,官方关于分别维护繁简码表工作量大的理由不成立,先不说官方最后还是维护了单独的简体码表,就说一件事:这简体码表何必官方维护?官方在群里的发言更是令人气愤,他们说我们自立门户自行维护简体码表是增加官方负担,“徒增混乱”。粗俗一点说,他们这和主动去吃屎又说屎难吃不能吃有什么区别呢?没有人强求官方维护简体码表
]]>目前来看火狐应该是初步实现了 X11 下的 VA-API 硬解……期待后续的发展……
使用最新版 Nightly,开启设置中的 vaapi
和 webrender
相关选项,使用环境变量 MOZ_X11_EGL=1
即可测试
试用了一下目前在我的机子上表现还不错……当然刚刚实现肯定还有很多 bug,只能说我是运气比较好的那批人吧……
Bug Tracker:Implement ffmpeg/VAAPI video playback
2015年12月,计科杀手 csslayer 创建了fcitx/fcitx5代码库,独自开始了对 Fcitx5 的开发。
如今五年过去了,Fcitx5 也日渐成熟。(个人感觉算法上相当不错
今年年初,我从 fcitx-rime
换到 fcitx5-rime
,感觉并不明显 (毕竟对于 Rime 用户来说从4到5最大的变化是界面
然后,在 Arch Linux CN 众多群友的诱惑下, 我决定尝试一下 Fcitx5 自带的拼音输入法。
首次使用的体验是相当的棒的,Fcitx5 在默认配置下表现良好,云拼音也有百度,Google,Google CN 三种可选尽管我不怎么用云拼音,整句输入也是相当的棒,还有输入预测功能。
但这并不是让我抛弃我在 Rime 积攒下的词库投靠老K输入法Fcitx5自带拼音的理由……真正的原因是最近发生的几件事……
fcitx
, fcitx5
, ibus
的输入法模块(感觉黑科技在经历了一天的过渡之后,我的主力输入法从 Rime 迁移到了 Fcitx5, 到目前为止体验良好
fcitx5-rime
支持加载动态库形式的 Rime 插件,在设置中填写插件名称即可使用,注意 octagram 插件名称与文件名并不一样(fcitx-rime
无此支持,ibus-rime
有此支持但是似乎配置文件有点问题(喜讯:Arch 官方仓库中的 librime
已经打包了 lua 和 octagram(即语料库)插件开发者老K有一篇 官方博文 可供参考,此外 Arch Linux CN 提供了 Git 版本的打包,虽然 Fcitx5 还没有发布正式版,但是Arch的[community]
源已经提供了打包
可 sudo pacman -S fcitx5-im fcitx5-chinese-addons
直接安装,另外 CN 源有词库可用 sudo pacman -S fcitx5-pinyin-{zhwiki,moegirl}
李先生有一篇 如何现在就在 Ubuntu 20.04 用上 Fcitx 5
hosxy 大佬提供了一个 PPA,将 Debian Sid 的 Fcitx5 port 到 Ubuntu 20.04 (Ubuntu 官方源中的 Fcitx5 是较旧版本,而 Fcitx5 最近几个月活跃开发并更新,很多东西都跟不上时代了 ( 与此相关的是一个 bug fix 修正了一个拼音:聒噪(guo zao)仅记录了古音“聒(gua)”,此外,Ubuntu 20.04 打包的版本未打包配置工具。
来自一个朋友的安装配置方法(不能保证一定可行):
用Ubuntu官方源安装fcitx5
sudo apt install fcitx5 fcitx5-pinyin fcitx5-chinese-addons fcitx5-frontend-gtk2 fcitx5-frontend-gtk3 fcitx5-frontend-qt5
然后再添加ppa安装kde-config-fcitx5
sudo add-apt-repository ppa:hosxy/test
sudo apt update
然后千万不要升级任何软件包
若要尝试自行编译,请参考 Debian 官方包打包脚本
PS1:Ubuntu 官方只为20.04及以后的版本提供了包
PS2: 若尝试在 Ubuntu 18.04 编译,请注意依赖问题,另外最新版 kcm-fcitx5
依赖 Qt 5.14+ 版本
参考 Ubuntu
Gentoo-zh Overlay 有提供打包
其官方有提供打包
M17N 源有打包,但是似乎遇上了 已修复json-c
的依赖问题,等待维护者更新中
Manjaro Dev. 应该已经把肥猫的包偷过去了吧(
Parabola 有包,看签名应该 x86_64 的包是从 Arch 拿过去的
已提交请求,位于 NixOS/nixpkgs#102626
目前似乎无人打包,
已经有打包者在尝试打包了1,
现在 Copr 有包了 yanqiyu/fcitx5,
目前已在 Fedora 32 testing 有包2,
目前已在 Fedora 32 stable 有包,
打包者写有一篇介绍博客 如何下周就在 Fedora 32 用上 Fcitx 5(这文章名颇有 Fcitx5 博客一贯风格,还有一篇 如何更加优雅的在 fedora 上安装 fcitx5
自行编译请注意依赖问题
有 Flatpak 版本啦,参见 如何现在就用上 Fcitx 5 (Flatpak)
推荐以下设置:
有以下几种选择:
kimpanel
(KDE)/gnome-shell-extension-kimpanel
(Gnome) (同时这也应该是目前 Wayland 下唯一的方案)fcitx5-skin-material
以上主题在 AUR 皆有打包(似乎目前已有主题在 AUR 上都有打包了
开发者明确表示不会考虑开发基于 GTK 的图形配置工具,但在 fcitx5-configtool
中可以同时编译出 KCM 版本和纯 Qt 版本的配置工具(至于会不会依赖 KDE 就看你的发行版拆不拆包了(Arch 的做法是 KDE 相关依赖作为可选依赖,因此其他桌面环境用户安装 fcitx5-configtool
并不会引入 KDE
PS1: 老K终于想起来把那个极易引起误解的 repo 名改掉了
PS2: Ubuntu 20.04 打包的版本未打包配置工具。(不知道他们怎么想的)
最新版本的 fcitx5-configtool
已经添加了迁移工具3,可执行文件名为 fcitx5-migrator
,GUI 工具。
目前支持 pinyin, skk, rime, kkc, table(码表输入)和全局设置的迁移。
Fcitx5 相比 Fcitx4 增加了对于动态库形式(即 .so)的 librime
插件支持,几乎是你使用 librime
插件的唯一途径(Arch 官方的 librime
已经打包了 lua
和 octagram
插件
在5月25日之前的 fcitx5 的主题代码中存在 bug fcitx/fcitx5#65,如果主题中直接使用了 RGB 颜色代码,那么显示时颜色会出现问题,表现出类似反色的效果。 该问题在5月25日修复4; 如果是 Material Color 主题 用户,可 checkout 至 hosxy/Fcitx5-Material-Color#commit=e57e56 或更新 fcitx5 使用。5
在10月2日之前的 Fcitx5 中,词库不会预先加载,而是会在第一次切换到对应输入法时加载,这使得使用较大词库时最初几秒不可用,此问题在10月2日修复6, 现在 Fcitx5 会在启动时预先加载默认的输入法的词库。
现在的问题是没有(很少有)其他发行版用户尝试 Fcitx5 来找出在其他发行版上的问题…… Arch 上的虫已经捉的差不多了……其他发行版上体验的改进需要你们的参与……
先写到这里,有需要再补充
kcm-fcitx5
到 fcitx5-configtool
的包名变更,添加词库安装方案(Arch)1991年4月,微软发布了 Visual Basic 1.0 for Windows,这是新时代的开始。 历史上第一个“可视”的编程软件诞生了。
VB的一生都在争论中度过:
VB的诞生是历史的必然,也是那个时代的诉求。但是作为一门编程语言来讲,和老骥伏枥的C不同,VB已经不再适应这个时代:过高的平台绑定(这本身并不是特别严重的问题,虽然我不喜欢,但是真正可怕的是VB作为一门和Windows系统绑定的语言,不能很好地综合 Windows 的基础API,甚至很多时候要使用低级运算的“小伎俩”来进行编程。),不高的运行效率,自身的兼容性问题(VB6与VB.NET);而如果作为入门语言来讲,他又会带来很多不好的编程习惯。
]]>