2025-10

Alpine Linux

原计划在国庆假期把 Python 相关的包努力做一做，setup.py install 相关函数将要在月底废弃，但是经过努力决定开摆，原因有下：

当前在不测试的情况下完全无法分辨是否依赖有缺失
很多上游不着急，构建系统的切换还是上游做合适
缺少项目经验，不明白 nox、pytest、uv 等的工作原理
使用的 py3-gpep517 脚本协议错误，提了修改没人管

这个月 pmos 的人引入了 systemd 子包功能到 abuild，也算是对社区的又一次冲击（摊手），不知道 WHLUG 能不能做个闪电分享讲讲这些事。

Wless & Wayland

隔了一整个 8 月和 9 月没写，之前写的代码有点看不懂了，于是也重新看。

在 sway 中 layer-shell 是挂在 output 下，渲染时 reparent 到 server
在 dwl 中 border 是挂在 client 下，对于我的场景应该适合挂在 output 里
wlr_scene_node_set_size 需要考虑到 pending 状态（tinywl 的 resize 没考虑）

之前拆多文件是为了使用 AI 写代码理解方便，但是体验了 VSCode + cline + DeepSeek，小几千行的情况下，单文件对 AI 和对我的原生 Vim 来说都更方便，我就改回去了。

协议 wlr output management 是为了客户端 Read 或者 Write 服务端的显示器设置

zwlr_output_manager_v1
- request create_configuration >> zwlr_output_configuration_v1
- request stop
- event head >> zwlr_output_head_v1 只读的广播，没什么逻辑
- event done
- event finished
zwlr_output_configuration_v1
- request enable_head >> zwlr_output_configuration_head_v1 + zwlr_output_head_v1
- request disable_head >> zwlr_output_head_v1
- request apply
- request test
- request destroy
zwlr_output_configuration_head_v1
- request set_{mode,position,etc.}
https://wayland.app/protocols/wlr-output-management-unstable-v1

Bushi & Git

重新审视了这个项目的整体架构，思考下一步真的要做什么。项目已有的“祖先跳表”设计令人兴奋，但是内部数据的生成还是依赖 git fast-export，这不优雅：

很难控制 git-cli 本体的内存占用，据测算需要 800 Mb（使用 aports.git 仓库）
命令行输出的解析是用的手抠字符串，虽然能跑但相当原始
初始化更新和后续更新可能逻辑不一致，写两套函数无法接受

所以最好这里再细节一点。

先尝试的是字符串解析，尝试使用 nom 但阅读文档后发现，这个库必须先把字符串读取为 &str，这就很不合适，因为管道重定向是 Stream 流：数据量大、输出时间长、不保证字符编码。目前也没有什么其他库做这件事很合适，所以搁置。

用原版 git-cli 和 libgit2 各做 1000 次提交差异对比，发现原版速度就是快一个数量级

export GIT_PAGER=cat
git diff --no-color --name-only "$commit_old" "$commit_new"

看了会儿 libgit2 的源码思考为什么如此慢。发现它读取 object-tree 这里可以改一下，用 data 的 size 除以 oid_t + mode + 6，然后拿这个数值去初始化数组，避免很多次 realloc。修改后对比测试，略有提升，效果微乎其微，平均百万次读取超大 object-tree 调用提升 10s（口算）。

读取有 object 后的 diff 运算没有可以优化的地方，就是简单的双指针单向遍历。

从 git-sizer 程序的解析结果看，把仓库中所有的 object-tree 事先解析并塞到 SQLite 的方法会导致程序体积占用很大，预计有 20 倍的膨胀，所以不可取。理想预期：

【内存占用小】全程不超过 200 Mb，而且缓存大小可控
【硬盘占用小】因为必须保留原生 git-objects 做兼容，所以尽可能产物小于同期 fossil
【CPU 消耗低】初始化不作要求，查询时单线程可运行
【解析时间短】初始化时间低于 git-fastexport 耗时的三倍，查询时间低于 git-cli

下一步计划：当前的性能瓶颈有两个，object-tree 的 read 和 diff，它们被广泛压缩在 packfile 中，不仅 IO 紧张而且 CPU 紧张。但是逆转过来想，压缩本身也是一种信息？可能需要写一点优化后的读取方法，在读取时抓取更多信息。

Misc

做了一个用于下载、缓存、解压源码的 rust 小工具 fetchsrc，我的 Option 和错误处理经验还是太匮乏了，这里写的很吃力（和 shell 差不多吃力了！）后面有空找个开源项目跟踪一段时间。

Alpine Linux 合并了对 systemd 子包的支持，后面也许可以自己造点工具链 自立门户。

QT

发现一个 Bug，右键弹出菜单中，分隔线上的点击事件无效但会导致弹出菜单消失。使用 AI 写了个复现小 demo，提交问题到了 QT 上游。

# 感谢子冲帮忙修复 LSP 爆红
sudo apt install libstdc++-13-dev

不知道下一步会不会学习 QT 做点小工具。

Vim

学到了 Vim 自带的 grep 命令，非常好用，再也不需要终端里查询复制到 Vim 中再打开了。

现在是接入了 ripgrep 日常使用，配置文件略微修改：

if executable("rg")
        set grepprg=rg\ --vimgrep\ --smart-case
        set grepformat+=%f:%l:%c:%m
endif

把之前在 Vim 上修的小补丁 cherry-pick 到了 NeoVim 上

LSP

clangd 原来默认也会搜索 build/compile_commands.json，再也不抱怨 LSP 不干活了，之前全靠软链接和 .clangd 配置文件苟活。

https://github.com/llvm/llvm-project/blob/816002523f6562c2b742fbffabb5c4cfc03bed8b/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp#L149

qaqland - hash