docs: fork 规范形态、fontconfig 实况、沙箱盲点(v1.3) - #309
Merged
Merged
Conversation
§14 fork 的规范形态。本轮前半段用 sh + python 预生成、把产物签进仓——那是错的。 关键是我一开始判断错了 build.mcpp 是什么:它是 mcpp 编译并运行的 C++ 程序, import mcpp; 给指令 API,所以任何「读文件、变换文本、写文件」的生成器都能在 里面做,不需要外部解释器。libdisplay-info(#308)是按新形态重做的样板。 没有签进仓的生成物,所以也没有「重生成再 diff」的 CI 步骤——「数据与代码 不一致」这个状态不存在。 §14.2 模块能顺手消掉一类上游缺陷:libdisplay-info 七个公共头一个 extern "C" 都没有,有了模块消费者就不用自己包。compat.libseat 有同样问题而没有模块,两者 对照说明模块层不只是风格。 §14.3 生成器可以比上游更正确:PNP 表逐行 diff 过,2583 行除几个非 ASCII 名字 外一致,而那几个这边是对的(上游按码点转义 U+00A0 成单字节 \240,不是 UTF-8)。 §15 fontconfig:我的估算错了。说过它「中,和 libinput 同量级」,实测 7 个生成物, 其中 fc-lang.py 387 行吃 281 个 .orth 文件编译成 FcCharSet 位图。已在 build.mcpp 里做通 5 个(含用二分查找替掉 gperf 完美哈希——唯一消费者只读一个字段,72 条目, 语义等价而少一个工具和一遍预处理)。剩下两个及建议的混合形态写在 §15.3。 §16 沙箱验证的盲点:合成 home 带的索引快照早于被测的包,脚本因此把一个已发布 一小时的包报成「找不到」。任何 --sandbox 里的验证第一步必须是 mcpp index update, 否则测的是镜像打包那天的生态。 只改 .agents/docs/,不触发任何 CI。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
§14 fork 的规范形态
本轮前半段的 fork 用
sh+python预生成、把产物签进仓 —— 那是错的。根因是我一开始判断错了build.mcpp是什么:它是 mcpp 编译并运行的 C++ 程序,import mcpp;给指令 API,所以任何「读文件、变换文本、写文件」的生成器都能在里面做,不需要外部解释器。libdisplay-info(#308)是按新形态重做的样板:pnp-id-table.c(2583 行)build.mcpp→ out dirsrc/libdisplay-info.cppm(206 名)build.mcpp→ src/没有签进仓的生成物,所以也没有「重生成再 diff」的 CI 步骤 —— 「数据与代码不一致」这个状态不存在。
§14.2 模块能顺手消掉一类上游缺陷:那七个公共头一个
extern "C"都没有,有了模块消费者就不用自己包。compat.libseat有同样问题而没有模块,两者对照说明模块层不只是风格。§14.3 生成器可以比上游更正确:PNP 表逐行 diff,2583 行除几个非 ASCII 名字外一致 —— 而那几个这边是对的(上游按码点把 U+00A0 转义成单字节
\240,不是 UTF-8)。§15 fontconfig:我的估算错了
fc-case.py240 行 +fc-lang.py387 行,吃 281 个.orth已在
build.mcpp做通 5 个,含用二分查找替掉 gperf 的完美哈希 —— 唯一消费者只读一个字段、72 条目,语义等价而少一个工具和一遍预处理。剩下两个与建议形态见 §15.3。§16 沙箱验证的盲点
合成 home 带的索引快照早于被测的包,脚本因此把一个已发布一小时的包报成「找不到」。任何
--sandbox验证第一步必须mcpp index update。只改
.agents/docs/,不触发任何 CI。