编程语言编译器语言运行时开发工具【免费下载链接】unisonA friendly programming language from the future项目地址https://gitcode.com/gh_mirrors/un/unison点击查看免费下载导读serial-test-05 是 Unison 编译器仓库中一组「序列化回归测试」的第五个用例。它的核心任务不是测试某个业务功能而是验证一个把函数当作普通值塞进自定义 Map 的复杂 Unison 值能否被序列化为自包含文件、并在后续的序列化/哈希版本v4、v5下被可靠地读回、还原和校验。读完本文你将理解 Unison 的 transcript 测试体系如何运作、saveTestCase系列工具如何生成和保存测试样本、v4/v5 版本号的真实含义以及随机回放脚本如何用「输出比对 Sha3_512 哈希比对」双重手段守住序列化兼容性底线。一、transcript 输出文件在 Unison 测试体系中的角色本文关联文档 serial-test-05.output.md 属于unison-src/transcripts-using-base/目录。该目录下的每个主题都维护一对文件手写的 transcript 脚本如 serial-test-05.md与运行后自动生成的输出实录.output.md。两者关系可以这样理解.md文件里是unison代码块与ucm命令块描述「要加载什么代码、执行什么命令」.output.md则是 Unison Codebase Managerucm实际执行后自动回填的 stdout 快照其中:added-by-ucm前缀的行见输出第 19–28 行就是 ucm 在运行过程中补写的类型检查结果例如Loading changes detected in scratch.u. f : (Nat, Nat, Nat) - Nat g : Map Nat ((Nat, Nat, Nat) - Nat) -{g} Text m : Map Nat ((Nat, Nat, Nat) - Nat) mkTestCase : {IO, Exception} () Run update to apply these changes to your codebase.这段输出原样展示了 ucm 对四个声明的类型推断结果其中g的类型打印含 ability 请求标记{g}是 ucm 当时的原始渲染本文照实引用。随后执行 add与 run mkTestCase最终返回()表示用例生成成功。需要注意目录内 README 明确写了一句约束「Transcripts in this directory are only run using the new runtime.」也就是说这组序列化用例是绑定到新运行时之上的这也是为何它们要单独放在transcripts-using-base而不是普通 transcripts 目录的原因。此外运行前需要先加载 _base.md 描述的 prelude执行builtins.mergeio、load base.u、add把测试辅助函数灌入代码库。二、被测数据把函数当作值存进 Mapserial-test-05 的输入代码非常短但结构上刻意选择了一个「刁钻」的数据形态——函数被当作普通值存放在自定义的平衡树/Map 里f : (Nat, Nat, Nat) - Nat f cases (x, y, z) - x y z g : Map Nat ((Nat, Nat, Nat) - Nat) - Text g m match Map.get 0 m with Some f - Nat.toText (f (1, 2, 3)) None - problem m : Map Nat ((Nat, Nat, Nat) - Nat) m Bin 1 0 f Tip Tip mkTestCase do saveTestCase None case-05 v4 g m saveTestCase (Some 5) case-05 v5 g m逐项拆解f一个三元组求和函数(1,2,3) - 6。Map不是内建类型。它来自测试前导文件 base.u 中自定义的structural typeunique[s9drbo3urtmpecjn6ivkj5mn0vr11gfn] type Map k v Tip | Bin Nat k v (Map k v) (Map k v)即一棵带 size 字段的二叉查找树Tip为空Bin Nat k v l r存放键值对与左右子树。mBin 1 0 f Tip Tip构造一棵只有一个键值对的树——键是0值是函数f本身。这是整个用例的测试重点序列化器必须能处理「数据结构的叶子节点是闭包/函数」这种场景。g通过Map.get 0 m取出该函数若能取到就f (1,2,3)得到6再经Nat.toText转为文本取不到则返回problem。Map.get的实现同样在 base.u按compare k kx的结果-1/1/0递归下降查找命中键即返回Some x。由于g m的结果固定为6序列化产物对应的期望输出文件case-05.out内容正是单个字符6已在仓库产物中验证。这样回放脚本就有一个明确的、与代码行为强绑定的判据。三、mkTestCase 与 saveTestCase序列化样本的生成机制mkTestCase两次调用辅助函数saveTestCase其签名与实现在 base.usaveTestCase : Optional Nat - Text - Text - (a -{} Text) - a -{IO,Exception} () saveTestCase mv name ver f i dir unison-src/transcripts-using-base/serialized-cases/ sfile dir name . ver .ser ofile dir name .out hfile dir name . ver .hash output f i saveSelfContained mv (f, i) sfile writeFile ofile (toUtf8 output) writeFile hfile (Bytes.toBase32 (crypto.hash Sha3_512 (f, i)))参数含义与调用对应关系如下参数含义case-05 的两次调用mv版本标记Optional NatNone或Some 5Nonev4、Some 5v5name用例名用于拼文件名case-05ver序列化/哈希版本字符串v4/v5f把输入转成期望输出的函数此处是ggi被测值本体此处是含函数的 Mapm一次调用会向serialized-cases/目录写出三类产物.ser文件saveSelfContained mv (f, i) sfile把(f, i)二元组序列化为自包含self-contained值写入。自包含意味着依赖闭包里的函数定义必须一并嵌入序列化流读回时无需依赖外部代码库。.out文件output f i即g m的文本结果此处为6作为回放时的期望输出。.hash文件对(f, i)本体计算Sha3_512哈希再 base32 编码作为内容指纹回放时用来校验「读回的值在结构上是否与原值完全一致」。对应地读取侧在 base.u 的loadSelfContained里体现了完整链路fromB32 (readFile path)把 base32 文本还原为二进制 →loadValueBytes反序列化出依赖列表与值 →cache deps用 validateLinks / cache_ 验证依赖并重建缓存失败会报cache: missing binding group、cache: rehash failed、code not self-contained等错误→Value.load v加载出可运行的值。这些错误信息本身就是对「自包含」约束的精确描述序列化产物必须在无外部依赖的情况下被还原成可计算的值。仓库中已存在的 case-05.v4.ser 与 case-05.v5.ser 是两份实际的运行产物大小分别为4648 字节与 1392 字节——同样一个值两种序列化格式的体积差异明显说明 v4/v5 不是简单的版本号重命名而是两套真实的格式实现。而两个版本的.hash文件内容完全一致同为 base32 编码的同一Sha3_512摘要恰好验证了哈希针对的是值本身而非序列化字节流值不变指纹就不变格式变了字节流可以变指纹必须稳定。四、v4 / v5 版本号的真实含义为什么一个测试样本要保存 v4、v5 两个版本这对应 Unison 序列化与哈希方案的版本演进。哈希版本机制的权威说明位于 unison-hashing-v2/src/Unison/Hashing/V2/Tokenizable.hs-- | The version of the current hashing function. -- This should be incremented every time the hashing function is changed. -- -- The reasoning is that, if a change to the hashing function changes the hashes for _some_ -- values, it should change it for _all_ values so that we dont have collisions between -- different hashing function versions. ... hashingVersion :: Token hashingVersion Tag 2源码注释点明了设计动机哈希函数每次修改都必须整体升级版本号。如果只影响部分值那么「旧版本哈希」与「新版本哈希」可能同时存在于哈希表中某些结构简单、哈希恰好没变的值就会与新版本的同名哈希发生碰撞。Tag 2这样的全局版本标记以及Tokenizable类型类Tokenizable.hs的 token 化哈希管线就是为了让哈希变化是「全或无」的。因此transcripts-using-base里的 v4/v5 双版本产物其战略意义是把旧格式的样本保留在仓库中随时可以用新代码重新加载它们确认反序列化、哈希与计算结果没有回归。这也是随机回放脚本会固定覆盖 3、4、5 三个版本号的原因。五、回放验证random-deserial 的随机化双指标校验序列化样本存好之后谁来「考试」答案是同目录的 random-deserial.md它实现了回放与校验的完整逻辑collectFailures name version target第 29–43 行对某个版本的.ser文件执行loadSelfContained把读回的值(f, i)重新应用若f i target不成立则报output mismatch若.hash文件与对读回值重新计算的Sha3_512base32 不一致则报hash mismatch。同一份样本同时经受「行为一致性」与「结构指纹一致性」双重校验。runTestCase name第 45–62 行从.out读期望值对版本集合[3, 4, 5]逐一跑collectFailures全部通过记Ok (name v toText ver)有失败则记Fail。serialTests第 64–68 行枚举serialized-cases/下所有含.ser的用例即 case-05.v4/v5 等会被自动纳入用shuffle打乱执行顺序再经bSort排序输出最后汇总为测试结果。随机化顺序是为了暴露潜在的用例间状态依赖。注意这里校验的是「读回值重算哈希 仓库保存的哈希」而仓库保存的哈希由saveTestCase在生成时对原值计算。只要序列化/反序列化有任何信息丢失或重排output mismatch或hash mismatch就会立刻出现——这正是 serial-test-05 这类用例存在的全部意义。六、从 serial-test-00 到 05被序列化对象的覆盖面设计case-05 并非孤例而是覆盖矩阵中的一环。对比同目录各serial-test-*.md的saveTestCase调用即可看出被测数据形态的多样性用例被测数据结构对应脚本case-00结构类型Tree aLeaf/Node与foldMapserial-test-00.mdcase-01多参数组合combines (l1, l2, l3)serial-test-01.mdcase-02积类型/产品值products (l1, l2, l3)serial-test-02.mdcase-03记录式 trip 值serial-test-03.mdcase-04相互递归定义mutual1 5serial-test-04.mdcase-05Map 中存储函数并取出调用serial-test-05.md每一档都对应一类序列化器的难点树形结构、多参函数、嵌套积、记录、递归闭包、以及「数据结构承载一等函数」。case-05 补上的正是最后一块拼图——函数的序列化依赖闭包环境的完整捕获这比序列化普通数据更考验自包含机制的完备性。七、如何在本仓库中复现与继续探索复现这组测试的前置动作已记录在 _base.md 的 Usage 一节在 ucm 中执行builtins.mergeio、load unison-src/transcripts-using-base/base.u、add把saveTestCase、loadSelfContained、Map等辅助定义装入代码库然后即可运行 transcript。整体测试的批量入口可以参考仓库的 scripts/transcripts.sh 与 scripts/unisonloop.sh而 random-deserial.output.md 中也能看到case-05 v3/v4/v5被逐一列出并验证的实录其中 v3 是仓库预置的更早样本。想深入阅读源码的读者建议按三条线索展开序列化工具层base.u 中的saveSelfContained/loadSelfContained/cache与loadValueBytes理解「自包含 依赖校验」的完整往返哈希版本层unison-hashing-v2/src/Unison/Hashing/V2/Tokenizable.hs 中Tokenizable与hashingVersion Tag 2的机制注释回放校验层random-deserial.md 中collectFailures的「输出 哈希」双指标逻辑。小结serial-test-05 表面上只是一小段 Unison 代码和一段 ucm 输出但它完整地串联了 Unison 序列化测试的四个关键环节用真实运行时生成自包含序列化样本.ser→ 用Sha3_512固化值指纹.hash→ 用期望输出固化行为.out→ 用随机化脚本跨 v3/v4/v5 版本回放比对。当「函数作为值藏在 Map 里」这种最考验序列化器的场景都能在任意旧版本样本上稳定读回、正确重算、哈希不变时Unison 的代码库迁移与序列化格式演进就有了可信的回归底线。赞分享编程语言编译器语言运行时开发工具【免费下载链接】unisonA friendly programming language from the future项目地址https://gitcode.com/gh_mirrors/un/unison点击查看免费下载相关推荐深入解析 Unison 序列化回归测试以 serial-test-05 为例的函数值持久化与版本兼容验证深入解析 Unison 序列化回归测试以 serial test 05 为例的函数值持久化与版本兼容验证 Unison 是一门内容寻址的函数式编程语言其编程语言编译器语言运行时开发工具Unison 序列化回归测试实战从 serial-test-00 Transcript 理解跨版本 Value 序列化Unison 序列化回归测试实战从 serial test 00 Transcript 理解跨版本 Value 序列化 导读 本篇文章围绕 Unison 语言编程语言编译器语言运行时开发工具Unison 序列化测试深度解析互递归函数的跨版本持久化验证serial-test-04Unison 序列化测试深度解析互递归函数的跨版本持久化验证serial test 04 导读 本文以仓库中 serial test 04.output.编程语言编译器语言运行时开发工具上一篇CNTK 语音识别入门实战基于 AN4 数据集训练 FF 与 LSTM 声学模型下一篇终极指南解决ML-Agents Protobuf版本冲突的完整方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考