Kotlin 16：值类和 reified 保留了哪些类型信息
submitValidated(store, "alpha", "task-1") 两个参数都是字符串：如果调用方把任务 ID 和文本调换，编译器无从发现。给 ID 做一层值类后，可以要求调用处明确提供 TaskId。另一个疑问来自 15 的类型擦除：内联函数写了 reified，能否就此识别 List<String> 中的实际元素？本章用同一任务系统的可控调用、预期编译失败及当前构建的 javap 结果回答这两个问题，不根据一次生成物宣称未来所有 Kotlin 编译器都产生同样的 ABI。 实验版本仍为 Kotlin/JVM 2.2.21、JDK 21、Gradle 8.14；编译器上游 tag v2.2.21 对应 SHA 2146684dcba708e5a304758b41a9e4ec9c7eff71，冻结信息见仓库 writing-plans/kotlin/VERSIONS.md。官方 inline 文档与 值类表示文档解释语义边界；本篇只读了生成字节码，尚未跟踪编译器 lowering 内部源码，后续 36 再补符号级...
Python E08：如何审计依赖与不可信输入
一个 tasklab wheel 在干净环境里安装成功，依然无法回答两个问题：下载的到底是不是当时检验的制品？网络请求中自称“任务类型”的字符串会不会被当成可执行模块？此前 26 的安装验收解决的是构建与运行可重放；本篇用现成 wheel 和 JSON 行入口审计供应与输入边界，不引入任意代码插件。 主线 wheel tasklab-0.1.0-py3-none-any.whl 的当前路径、SHA-256、成员清单和源码文件哈希记录在 examples/python-language/evidence/completion/acceptance/wheel.json；元数据要求 Python >=3.12、没有 Requires-Dist。E05 的 Starlette/HTTPX/Uvicorn 和 E06 的 NumPy 均是可移除实验环境中的额外依赖，不能从主线 pyproject.toml 推出这些工具已被主线用户安装，也不能把 pip freeze 当作经过哈希校验的跨平台锁。 先验证制品，后讨论信任 experiments/E08_audit.py 在导入位置...
Kotlin 15：泛型边界如何限定任务状态的读写
已经有一批 TaskState.Failed，想让只关心 TaskState 的代码读取它们；另有一个接收所有 TaskState 的写入口，想把它交给只会提交失败状态的调用方。前者与后者的赋值方向正好相反。若把可读、可写混在同一个泛型接口里，调用方既难获得类型上的自由，也可能把不兼容的状态放进列表。本篇在 14 的任务状态格式化旁边建立两个小端口，并用独立编译失败样本检查类型允许的动作；外部来源的嵌套列表仍需逐值校验。 本章继续使用 Kotlin/JVM 2.2.21、JDK 21、Gradle 8.14。术语与约束取自 官方泛型文档的型变与投影，具体编译诊断和运行结果取自冻结版本的 15 实验。没有 Java 适配、持久化或受管任务工作者。 只读状态源能向哪个方向赋值 把“读取一个状态”与“接收一个待写状态”拆开，接口只暴露必要的一种操作： 1234567interface TaskStateSource<out State : TaskState> { fun current(): State}interface TaskStateS...
Python E07：子解释器提供了怎样的隔离
一个进程里运行两个解释器，能否让 tasklab 的两个任务彼此不共享对象，同时避免起两个进程？在冻结的 CPython 3.12.3 上，公开标准库还没有可依赖的高级解释器池入口；实验只能明确使用当前实际存在的私有 _xxsubinterpreters 模块。它暴露 create/run_string/destroy，但本机构建里没有 channel_send 等通道 API。没有通道，就要先交代输入输出怎样过边界，不能用进程池的名义代替子解释器实验。 这项选修不改 30 的进程策略 或 29 的线程池。local、线程、进程和子解释器四种执行方式都从当前源码树导入同一份 tasklab，对 "one two one " * 50 计算已有 cpu_work(iterations=120)，并提交、执行、查询词频任务。各自看到相同业务结果 {"one":100,"two":50} 和校验值 754902074；相同结果不代表存储空间相同。 哪些东西能越过解释器边界 在当前私有模块里 is_shar...
Python E06：向量化何时减少 Python 层成本
词频任务原本逐个字符找单词，再把词写进字典。如果输入只含单字母小写 ASCII 单词，整批词频能换一种做法：把字节映射为 uint8 数组，对 a 到 z 做直方图。这样减少 Python 层的逐词更新，却额外发生编码、拼接、筛选和分配。换成中文、多字母单词或任意 Unicode 文本，这个实验函数就不再与原任务等价。 本篇沿用 36 的基准限制 和 04 的文本/字节边界。选修只读已有 tasklab 的 count_words、word_batches、submit/run/query；NumPy 不进入主线 wheel，也不替换在线任务分派。当前 completion 使用仓库外 optional venv，NumPy 1.26.4 来自 PyPI 解析锁，模块路径是 /private/tmp/python-language-completion/optional/lib/python3.12/site-packages/numpy/__init__.py；这与主线运行依赖分开记录。 先关住适用域 实验输入固定为 256 段文本，每段 "a b a c &quo...
Go 26：事务与条件更新怎样防止重复领取
上篇先把 QUEUED 写进真实 PostgreSQL，但 worker 完成时 SQL 还是 QUEUED。若服务把数据库改成查询状态来源，却不改变领取和完成路径，用户会一直看见一项“等待执行”的任务。本篇继续修改同一个任务服务：领取必须先在表中赢得一个条件更新，终态和结果一起提交。完整累计工程、摘要及独立解包步骤包含本次正反证据。 领取的判断要落在数据库提交点 表中一行是 id=task[shared], status=QUEUED。两个 worker 同时先查询、都看见 QUEUED、再各自修改内存标志，并不能阻止它们重复领取。sqlTaskRepository.Claim 开始一个 database/sql 事务，在事务里执行 UPDATE go_tasks SET status='RUNNING' WHERE id=$1 AND status='QUEUED'。检查 RowsAffected()：只有影响一行的调用才提交并进入分析器；另一个没有命中条件的调用回滚并报告未领取。这样做不把 Go 的互斥锁误当成跨数据库连接的领取仲裁。 本次用 PostgreSQL 16.1...
Kotlin 14：扩展分派取决于哪种类型
任务已经失败，变量 failed 打印 failed:disk；把同一个对象交给只接受 TaskState 的格式化函数，输出却是 terminal。失败信息没有消失，变的是调用处可见的接收者类型。本篇接续 13 的失败类型，在不启动后台任务的前提下核对扩展函数的分派，再用 let、run、apply、also 检查一段任务格式化代码究竟返回字符串还是原对象。 基线仍是 Kotlin 2.2.21 / JDK 21 / Gradle Wrapper 8.14；一手资料见 官方扩展文档 与 作用域函数文档，实际测试和命令见本章证据目录。文档是语义依据，具体运行结果由冻结组合验证。 同一个实例，为何选择另一段实现 给领域状态提供一个粗略标签，给失败状态提供一个更详细的标签： 12345678910fun TaskState.statusLabel(): String = when (this) { TaskState.Queued -> "queued" TaskState.Running -> "running&qu...
Kotlin 13：拒绝提交与任务失败为何不是同一种错误
同一个 submit 调用有三种不同的坏消息：文本为空，任务尚未创建；任务已经开始，执行结果是失败；提交时存储接口抛了异常，调用方甚至不知道本次写入是否成功。如果一律返回 null，调用方既不能给出准确提示，也无法决定能否重试。本篇沿用 12 的同步任务状态，只处理提交决策，不把已经运行的任务状态塞进提交结果。 实验仍是 Kotlin/JVM 2.2.21、JDK 21、Gradle Wrapper 8.14，内存 TaskStore 和一个注入故障的替身。runCatching 的宽捕获范围尤其值得留意：这里没有协程，不能把这段同步包装照搬到取消路径。 提交结果描述调用方能采取的动作 先看一条具体路径：任务 ID task-1、文本 alpha 已存在。再次提交相同文本，调用方可解释为“已有相同内容”；换成 other，则要明确拒绝，不能假称请求已被复用。如果 ID 或文本全为空白，也应该在接触存储之前返回拒绝。 1234567891011121314151617181920sealed interface SubmissionDecision { data ...
Go 25：database/sql 如何管理连接与结果集
上篇把出站 HTTP 的请求期限与任务取消分开。任务服务仍有一处更大的缺口：已接受任务只在进程内的 map 中，进程一停，按 ID 查询就失去依据。本篇在同一工程中添加真实 PostgreSQL 入口，从最早的一步——先保存待领取任务——检查 database/sql 管理连接和结果集的方式。完整工程及原始实验、SHA-256、独立解包运行说明与本篇一起交付。 sql.Open 返回了什么 先把一条提交的文字 Go 记录为 task[0]。若把 sql.Open("postgres", dsn) 没有报错理解成“数据库可用”，在服务真正需要提交时才会撞上连接错误。本版 Go 1.27.1 的 database/sql.Open 文档说 Open 可能只校验参数，不立刻建立连接，返回的 *sql.DB 是维护连接池的句柄，并非某一条固定连接。这里固定 PostgreSQL 16.15 与驱动 github.com/lib/pq v1.12.3；go.mod、go.sum 锁住实际模块版本与摘要，驱动使用 postgres 名称。没有把 PostgreSQL 服务...
Kotlin 12：任务状态怎样拒绝非法转移
任务还在排队，突然收到“完成”；已经标成取消，又收到“成功”。如果状态只是一串可以任意覆盖的字符串，两次写入都可能看起来合法。类型能帮忙列清有哪些状态，但“允许从哪儿走到哪儿”必须另外定义。本篇为同一任务系统规定顺序执行时的状态转移，保留非法转移和遗漏分支的编译反例；真实取消与完成的同时竞争要到后续有闸门和受管任务树时再验收。 沿用 11 的内存 TaskStore，状态还没有写回 Store，也没有接入旧 submit CLI。当前只用同步纯函数 advanceTask 处理本地状态值。Kotlin/JVM 2.2.21、JDK 21、Gradle Wrapper 8.14 的原始实验记录放在 12 证据目录。 sealed 说明分支，负载也属于状态的一部分 状态不是一个随处拼接的字符串： 1234567sealed interface TaskState { data object Queued : TaskState data object Running : TaskState data class Succeeded(val result:...