其实这可以更 declarative，可比较麻烦，而且我不知道 -T abc 和 -Tabc 该怎么样用 Parser 库的形式一起支持、处理，那样势必得使用带副作用或 contextual 的 parser，虽然我已经写了一个，但那样真的很 dirty 不如不用。

真是太愚蠢了，我连既能 match 又能 format 的东西都写不出来…… 而且 parser 写得还那么不好看

但它可以工作
但我讨厌只能工作的东西
-Tabc | -T, abc 处理起来真是无聊至极，String 层面不好处理因为有 -Tabc 这种连词的情况、Char 层面也不好处理因为有 -T abc…… 而且实在没必要上 Char解决，会引起处理与 shell 不协调。难道这个流就这么难以施用抽象性高的解析器？

唉，它写起来相当麻烦，Workflow 我现在还没想清楚还在渐进设计，但它相当重要，无法逃避。

准确的说 String 层面也可以处理，可我现在安排的 Parser 基本组合和输入流没有 mark/reset 的支持感觉不自在，而且一旦能够区分 -T 后面有没有配置的话，就得上 contextual 解析器了，实在是没必要。

Kotlin 官方都没有提供 Native 侧的 File API，KN 都这么久了还没官方接口
很多类还是得放 jvmMain 里写

这个项目 DOM TypeScript 侧还好，如果要手动处理 Markdown 部分的话感觉有点越俎代疱，最好还是找找 Markdown 的 DOM 库。

现在的模型是这样，-Tgradle

solvePath 是把 (main, kotlin, org.duangsuse.sample) 给映射到一个包的路径如 /src/main/kotlin/org/duangsuse/sample
generateProject 是映射完项目文件后期再来依据之前提供的 CFG 生成 build.gradle 和 settings.gradle、gradle/wrapper/gradle-wrapper.properties 的

AbstractGenerateIntrinsic

readLinks 属于默认实现，取 README.md 的依赖链接
readCompileUnit 属于默认实现，依据之前的默认 pkg 取 scope, sourceset 什么的和 filter code

晚安世界。

介于这个原因，我要好好放松一下，所以真的不想编程什么的

后来我考虑了一下 Lkt 工具…… 怎么工作呢？其实我基本了解生成过程了，就是把所有 markdown resolvePath 安排好，然后弄 config file generateProject 即可
其中最关键的流程就是

启动 -> 令 Plugin 解析 root README -> 创建 Plugin 的 Intrinsic -> handle root README

-T -t 都是创建 GenerateIntrinsic 用的
-s 是 handle root README 用的，它要确定一个位置
-d 才是整个生命周期里都需要的，所以应该把它做成一个字段，destinationBase

而这个 README/literate 的过程实际上是一个文章依赖广度优先搜索的过程，从 README.md 的链接，到图里最终末的端点，然后就像我上面说的那样：

val (unit, code) = op.readCompileUnit(src)
val destination = op.resolvePath(unit)
File(destinationBase, destination).writeText(code)

这个过程我们用一个 Queue<File> 来解决，也是整个生成过程中都要有的。
广度优先搜索的算法很好写，只需加一个 Set<File> 来记录略过环形依赖关系即可（非必需，为增强健壮性）。

注意 plugin 在解析 root README 的时候是拿不到 properties 的，这是为了保证 Intrinsic 能拿到 README 的解析结果，也不是不能解决，但我觉得…… 其实不支持这个也没什么。

#life duangsuse 今天，1 月 13 过十八岁生日～

一个惊喜：其实我记错了，18 号正式过生，不见不散。（喷

刚才大家大概在本苏的频道看见了几条和鸡有关的广播，属于发错频道了（我日常维护两个频道）
请谅解すみません

所以说在项目里注意代码的复用性是很重要的！ #dev #statement

这个例子里，我开始是不明白应该怎么写的，可对最初的设计进行「可扩展性提升」后，变得更容易实现了呢。

这就好像是在操作系统内核和开发工具的共同努力之下，把程序映像分段，虽然内存编址空间没有提升，但可以运行的程序数目却成倍地得到提升。

智商虽然没有得到提升，但解决的问题简单了、细分了，就可以兼容更多能被拆分开的问题，也能方便未来的维护，拥有更清晰的逻辑，为什么不呢？

（TON）Fift 和其虚拟机主要是解释的问题，最大和高性能计算、GPGPU 扯关系，和泛向的程序设计语言关系应该不大吧，要计算来验证虚拟实体是否造假？

#GitHub #ML #CG #CV #security https://github.com/ee09115/spoofing_detection