晚安世界。

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

后来我考虑了一下 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

从一读到一亿需要多少个汉字？ #zhihu

实在是太艹了！我们必须理智分析一下

『数字到汉字』并非进制转换（这也包括时间单位选择等）那样简单容易，随便 div+mod 除余就可以完成。

三百一十 是相同的情况
三十亿 是不同的情况

用了个很 dirty 的变通法

我太贱了（注：关注频道的小朋友们不要模仿，这是很无脑暴力的写法，正确的做法是先分析找思路再解答）

稍微 apply 了一下渐进设计，但我还是无法感知算法的灵魂

化成数学问题用基本数论的位置计数法和对数 log_k 也是容易解决的，但汉字数这个东西需要分区间处理，而且变化比较大，不好直接化单位，不得不使用非常 dirty 的变通。绝句当时支持也只是说解释上能兼容这种格式，没说要默认用这种格式。

>>> hanTextFromInt(10000000)
一千
>>> hanTextFromInt(1000000000)
一十

之所以说它 dirty 是因为这种情况它会傻眼，所以递归算法里必须有修改，但我才懒得改呢…… 绝句也不需要支持 hanziFromInt

我才懒得写能 pass 的版本呢（喷），这个版本 (1..100_000_000).map(::hanTextFromInt).sumBy { it.length } 算不出来，太难了，但可以用模拟只记 sum 长度列表算，而且写出正确算法以后带换下抽象数据类型就可以得到 partial info 的计算结果，那是不需要脑子的。