#Kotlin #Algotithm

两个文件均可在 GitHub Share 里访问到。 [1]
随时欢迎大家加入讨论和使用（暂时没有附加任何许可证）。

我马上要把它们移植到 Kotlin Common（因为它们本来就对 Java 特性没啥依赖）
然后我会写 TypeEqualizer，写完我最后修复、更新一下我的《抓周》

[master 78af361] Kotlin: three files
 3 files changed, 283 insertions(+)
 create mode 100644 Others/three-kt-files/DiffAlgorithm.kt
 create mode 100644 Others/three-kt-files/RingBuffer.kt
 create mode 100644 Others/three-kt-files/common.kt

因为是自己的抽象，完美兼容 KotlinJS/JVM，除了 java.io.Closeable 和 Kotlin @Throws, assert 不能用外都可以，其中前两个接口都可以直接在 Common 里静态链接实现

#sysadmin #linux 更新时间……

我更新了 IDEA，可是我还是觉得原来的版本好用；我想写一个 Parser.kt 框架，可是我觉得现在弄一个解释器就好了；我工作效率很低；我这个下午只是重构了这个项目，我只学会提出函数是 Ctrl+Alt+M、找引用是 Shift+Alt+7 （好像）；我累死了

我想写的 TypeEqualizer 还没动笔，一个有点麻烦的算法（numpreety.hanShow）现在基本上是没心情写的……

我应该把困难一点的东西留到以后做，比如把 26 格式化成 二十六 的算法……
理论不困难，但是实现真的不容易

你们不要喷我的代码复杂，你自己来写一个试试？这个是 Kotlin Mulitplatform(JVM/JS) 的

写的算法是 diff 算法，我也尽可能的在简化代码了，可这毕竟本身就有点多分支…… 也容易把人弄糊涂…… 比如说我就不是很理解 isEnd 都有哪些含义

现在想起来了，刚才的想法，是原来想让 Parser.kt 变成有一个 Describle 接口和 Document （就是 Haskell 的 Text.PP）模型而方便 REPL 什么使用的风格，不过就是有点麻烦（只要区间模型不滑坡，肯定是容易写出来的，关键就是有些时序逻辑，比如 Feeder 的那个 Iterator 就容易有问题）

可是看起来好像不能立刻考虑 toString() 的漂亮程度这种不重要的东西了…… 慢慢来，太多会要我的命

Feeder 已经是很方便的东西了，虽然它不是很优雅，比如每次 EndStream: Error 总是会得到 max - position == 2 的结果，因为首先我用的是 xs[position++] 所以最后一项被读取后 position=4，然后是有一次 FinalConsume（为了保证 peek 的确指示了 consume() 的一项这个性质）

不对，好像有个 bug，不管怎么样都不应该是 3(> 5) 这个结果啊

真是太过分了，我打算出去买薯片来着

val r = >>> val r = Feeder.of("Hell")
>>> r.consume()
H
……
>>> r.consume()
l
>>> r.consume()
StreamEnd(position=5, max=3)
        at StreamKt.eofError(Stream.kt:7)
        at Feeder.checkIsEOS(Feeder.kt:34)
        at Feeder.access$checkIsEOS(Feeder.kt:9)
        at Feeder.consume(Feeder.kt:18)

还好我只是用 REPL 调试，要不然我会吐槽我自己面向 REPL 编程
欸不对，不会用 Git SCM（所以经常忘记 pull 结果 merge origin/master……） 和 IDEA Refactor（所以经常手改代码） 和 Debugger（所以只会用 debug print），不才是我最大的嘈点么，我艹。

#Kotlin 谁写代码经常用到 IDEA/Android 的 Contract？我一直没用

我算一下：['H', 'e', 'l', 'l']
迭代 consume() 到第一个 l 是（这就是说 Feeder 有点真正意味『peek1』的意思了）
（我之前还打算支持 Stream 来着，不过到底也就是 PeekStream<out E>……）
（我讨厌分析型变，尤其是，不过我看了 #Java #Gradle 插件们的一大堆 Action<? super T>，我瞬间高*哦不是自豪感爆棚…… 声明处型变是哪些个地方……）
所以请容许我在这里再次强调： Java 是辣鸡

是 position=3，接下来的一位是最后一个 l
然后此时 position=4，还没有 consume() 消耗掉它
接下来 position=4，此时不应该有 next，不过依然有一次机会

然后 consume() 调用 s.next()，position=5（因为我们一律是先自增 inc()，再索引，所以无论如何也会自增……），失去第一次保持机会（FinalConsumeIter）
不行，这看起来是太荒谬…… 虽然 xs[index++] 看起来更好看，我不能允许暴露的细节也这样……

我们的自增（当然这个比较麻烦）表达式 (index++) 是在结果为原来值的基础上顺便更新左值，所以应该不会有太多问题，这个问题是我的实现会至少多调用一次 next()，导致索引失真

不过这毕竟是『Peek』流，虽然我没暴露编程接口，负责的方法是把原来（其实也涉及到接口本身偏向应用化的原因）改的东西改回来

我怎么感觉 peek xs = zip xs (drop 1 xs) …… 或者是别的方法，因为 1 就不能 peek 了？
感觉很不对称，没办法，只能用这种方法解决，应该是那种理论上给人的无力感……

这样。每次改完害怕测试不通过的无所适从……

> Configure project :
Kotlin Multiplatform Projects are an experimental feature.

> Task :compileKotlinJvm
> Task :jvmProcessResources NO-SOURCE
> Task :jvmMainClasses
> Task :compileTestKotlinJvm
> Task :jvmTestProcessResources NO-SOURCE
> Task :jvmTestClasses
> Task :jvmTest

BUILD SUCCESSFUL in 11s
3 actionable tasks: 3 executed
17:20:59: Task execution finished 'jvmTest'.

一看到 All Passed 兴奋的

解决了，好了

居然是可愛 KDE！

好康的

我该去吃饭了，呼。
啊不对，已经九点了，我好像没吃晚饭
艹，说不定超市已经关门了

这么晚不吃饭吃零食会不会长胖
（反正我也很瘦…… 怎么个受瘦法呢，上面的那一张里齐景轩很瘦，就体型来说我和他一样瘦…… 艹）

我对 Kotlin 实在是太凶残了…… 艹，这么密集的代码 放到 Java 8 里基本写不出来，Java 7 里完全写不出来

马上开源来的
明天可以写基于它们的解释器（虽然 RingBuffer 是凑数的（其实没有凑数的，都 TMD 是我的心血啊！！！
可是我不想写，虽然很简单
可是我觉得也有必要写，可是没时间了，艹 *3
其实我觉得 Parser.kt 的一部分代码，写出来都会很有意思，体积不知道怎么样，应该没问题

我不知道是因为时间太少、还是任务太多、还是上机的时间太珍贵、还是我自控力差，为什么我第一次有这种看瞎眼的感觉？我开了红移(redshift)…… 🤔