“叫你们给境外势力递刀子” “中国人没那么重视隐私，愿意用隐私获取便利” “腾讯是知名企业，可以信赖的，你们凭什么造谣抹黑污蔑它？” #China 🌚

看雪论坛 bbs.pediy.com 被打

我写了一个拿无损视频存下终端色号的…… 估计虽然修改版性能有改善，还是要把整帧 buffer 下来才不会抹布…… 要考虑是不是做一个 buffer ， chunked 化 stdout 呢
https://stackoverflow.com/questions/15728939/lossless-compression-for-video-in-opencv
https://docs.opencv.org/4.5.0/dd/d9e/classcv_1_1VideoWriter.html#ad59c61d8881ba2b2da22cff5487465b5

还有这个 at(i,j) 的 operator= 及性能比较的 https://learnopencv.com/parallel-pixel-access-in-opencv-using-foreach/
https://www.pyimagesearch.com/2017/08/28/fast-optimized-for-pixel-loops-with-opencv-and-python/
https://stackoverflow.com/questions/9841900/whats-the-fastest-way-to-iterate-over-a-cvmat-in-python-using-opencv 这个“入门教程”(迫真...感觉讨论的人少)

不追求优化性能了，也懒得用函数指针替换静态 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>>>
🌚？？ 这么麻烦