不追求优化性能了，也懒得用函数指针替换静态 if 判断了，思量着解决了个返回变量关系搞好的 bug ，最后重构下发了吧
实在熬不下去了吧 🌚 再说有很多事情可做 为什么要烂苹果啊

C++ 和 Java 的 IO stream 都可以有很多 tweak 啊，数据流各种 buf, chunk, cache 的处理也屡见不鲜，都不知道 setvbuf(); sync_with_stdio(); cout.tie(0); 这些有什么用，但最终还是明白了 termios 怎么写贪吃蛇吧，还是多开坑少硬杠比较健康

执拗的我最后TM 还是写了，但是发现性能并没有比使用 Console.flush 之后有任何改善，看来不是渲染速度问题，是 IO 问题， Jawa 的 IO 速率他妈是废的 🌝
为了寻找减少抹布效应的方法我把原版 StringBuilder 都试过了，结果只是更慢

还是算了吧，不过 chunk buffering 写都写了，还是留着吧（本来直接 while ((frame = vid.getNativeFrame()) != null) 渲染也没问题的）

🌚简单说一下技术细节吧。
这次新增两个py脚本，一个是对 mvn.py 继续缩行的复用性测试，一个是 C++ 版更新(支持 mech=0 ,1,2 变量) 后能播放其录制无损动画的脚本

C++ 这次修复了一个 unstop=vid.read(/*to*/frame) 生命周期关系 使用旧值的 bug(导致视频结束时出错)
性能方面是没什么好说的（我都懒得优化，它毕竟是 C++🌝
mech0 是既有的直接生成 ANSI 控制台转义/换行符序列
1则是带录制到文件效果(编码器参数 FOURCC)的 goto-line 无换行符序列， 2 可以回放生成的 cache.avi (render窗 p键敲字可设置色码偏移)

Java 早就有 b,p,s,sr 四种 MECH
buffered 是用 framebuffer 每帧部分生成色值(渲染)并刷新屏幕，这个很重要，性能往往是最好的(C++: 🌚就是霸道)
posited 就是全屏重绘的 buffered
seq 是用换行符到， seqrst 是用 [y H 转义跳至行的，性能好一点

#oi #algorithm

*Mivik 发觉自己完全不会出题：瞎想两道题一道题不会

毕生出题水平巅峰：
https://www.luogu.com.cn/problem/P7121 | 根据 mt19937 随机数引擎初始化后给出的 N 个随机数反推初始化种子
https://www.luogu.com.cn/problem/U135806 | 求字符串所有子串的本质不同子串个数之和
https://www.luogu.com.cn/problem/P1316 | 一个长度为 n，字符集为 m 的随机字符串的期望本质不同子串个数

https://i.redd.it/ttltg0p0jnb61.jpg #Security IncaseFormat 写出 bug (DAY_MS 过大) 导致的设计发作日期拖延问题

https://i.redd.it/enxjxgp0jnb61.jpg #劳动法 合 理 解 读

https://segmentfault.com/a/1190000012641345 #Java #DontKnow #Stream
其实 ParserKt 里出现过的 Reducer 在 Java stream 里叫 Consumer, 动词都一样

这是个 Java8 StreamForker 实现，可以流一遍出多个结果，实质上和我的版本功能一致

简单说下， builder() 出一个 Consumer 然后会被拿去 sequential().forEach()
其中 m1.entries.reduce(new Map 的是 ... 啊不对， reduce(initial, op, op_finish={ m1.putAll(m2); m1 })
这实际相当于 forEach { (k,v) -> m1[k]=waitOperationTo(queues, v) }
其中 queues:List<BlockingQueue<T>>
m1=forks as Map<Object, Function<Stream<T>, ?>>

waitOperationTo 把 StreamSupport.stream(newSpliterator(addQueue()) ) 在 CompletableFuture.supplyAsync 里 apply 给 op

它返回 ForkingStreamConsumer(queues,actions=m1) , 这个里面定义一个 EndOf S(tream) 对象是“帮助”被 queue 的子 stream 鉴别的, finish() 时使用

accept() = queues.forEach(q -> q.add(item));
get(i) = ((Future<R>) actions[i]).get();

#Kotlin #OOP "小王 老猪 阿司马 某A君".split(" ").map(String::length).fold { reduceAll(::minMaxer, ::averager) } == arrayOf(2 to 3, 2)

看了下 Java8 实战，附录有提到用 StreamForker 并行用一个流出多个结果
有兴趣可以自己去看看，相当于一个 fork 的操作

看了以后我算是了解了下 Java 的流，和 Kotlin 的 Iterable/Collection operators ext funs 完全不是一个概念，这个流是 queue,async 的

但是上面实现的人明显不重视简洁性（甚至在 map.assignEach {v->op(a,v)} 时有拽技巧的嫌疑）

我感觉不是很优雅。(M<V>=Map<Object,V>) 理论上 forks: M<Function<Stream<T>, ?>> 不能说难看，应该说是错的，完全滥用了流窗口大小 （不对，本身没有窗口，应该说传参方式太奇怪了

forks: M<String, Consumer<T>> 才算正常，或者说这根本就应该实现为组合些许 Consumer 的 Consumer 才对

在 build() 里它把函数们默认参 ()->op.apply(queueStream) 再套了一层 future (supplyAsync) ，然后再在 consumer 里 apply(x) = queues.forEach { it.add(x) } ？
get(i)=actions[i].await() ?

实际上就是 workers: M<Pair<Queue<T>, /*supplyAsync(op.bind(queueStream))*/Future<R>>>
🌚？？ 这么麻烦

#essay #Java 想了下最近队列的代码坑 #js #python

RingBuffer 支持的，奇妙的是我还用了 Android 上应该没的 AtomicInteger …… 其实 Queue 的实现才好吧 🌚

#Java #serialize #parsing, [18.01.21 10:11]
chen leiothrix: json反序列化的时候，有key对应两种不同结构有什么办法能针对性读取吗

捏造的信仰: [In reply to chen leiothrix]
这种情况的原因是类型信息缺失。如果你用 Jackson 可以看这篇 https://segmentfault.com/a/1190000023218408

ヾ(^▽^*)))Sam: 这种你的分别处理
要根据value值去if else
没啥好办法

I lluZ: 是的，直接当 map 处理，没法反序列化成一个 List<POJO>

ヾ(^▽^*)))Sam: list不行，因为你的数组不属于同一个类型无法搞

#Kotlin #parser #ce https://t.me/dsuses/4519 🤔看来想做 REPL ，对字符终端模型没有坚实的理解是不可以的
写完贪吃蛇和烂苹果，就有经验了，不要老侥幸，下次就不会出了事，倒大霉。

https://github.com/ice1000/arend-language-server/blob/88dd2e94ea7ae564a743d349b93487dd5aa4b5f8/src/main/kotlin/server.kt 草，原来冰封那么厉害也没有写自己的 Argument Parser... 我还以为函数式爱好者都痛恨 (org.apache.commons.cli) 需要 (opt as Options).addOption(Option.builder("i").build()) 的代码呢
看来事情还是要一分为二的去辩证地看待 🤔

现在想来我几乎从不用第三方的库，凡事只要行数限制不大，能自己动手，决不允许任何可能的辣鸡代码掺进项目里，哪怕有也要自己先封一层。
可能这就是编程习惯的问题吧