看了以后我算是了解了下 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()) 的代码呢
看来事情还是要一分为二的去辩证地看待 🤔

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

第一次知道原来大佬也有不重视代码质量的时候（话说我是有点强迫症吧……）
这 20 行要我就不会用 o.addXXX(cfg.build() )

opt.initArgs("""
c client-port language-
s server-port language-
a client-host ?language client hostname, default localhost
i interactive ?start the Arend REPL
""".trimPadding())

我对代码的追求，慢慢也从仅排版整齐上，变成了空格排版项目范围内语义一致、重视代码简洁性和可配置性；想想以前的我看见现在的代码，估计会觉得很难看吧 🤔

fun Options.initArgs(code: String, sep: String = "-") {
addOption("h", "help", false, "print this message")
code.split("\n").forEach { line ->
val (s, sLong, desc) = line.split(' ', limit = 3)
val opt = Option.builder(s).longOpt(sLong)
if (sep in sLong) opt.hasArg().argName(sLong.substringAfter(sep))
opt.desc(if (desc[0] == '?') { opt.optionalArg(true); desc.drop(1) } else { desc }.replace('-', sLong.replace(sep, ' ')) )
addOption(opt.build())
}
}
运行时开销又高了😂 不过总体看处理了 3种 case (normal+1param+optional, 交织的不算)，还是挺清晰的

#Java #Kotlin #GitHub #project #suggest 评论一下我之前开发的 ArgParser 😂
是个好东西，对命令行参数的建模也很好，就是 addHelpSubCommand() 这样的帮助函数，没有考虑到应用的需要，应为 addHelpVerCommand 不对，这个是显示子命令树结构的... 那个 -h -v 的也应该有，但可以另加
还有，生成命令行补全的代码也该加

存在的一些问题，包括强类型约束过于严苛(为此还有 ArgParser4~1 的泛型)， 以及 subcommand&formatter 参数实现未测试的瑕疵("All tests passed" 但它太复杂了 我不敢保证) 😂
(Apache: 你敢和我比?🌚 有它强大吗? 还有 "<!s #d" 的 fmtstr...)
谈谈 "both [src...] [dst] and [dst] [src...] are supported" 是怎么实现的吧
我们的解析器是流式的(因为框架很重视不同甜度需求的复用性，它是一层层建起来的，其根基 SwitchParser 就是基于状态机构建输出数据结构的)

所以实践上 [src...] dst 里你怎么知道 srcs 不能把最后一个 dst 也解析了(看起来 dst 也可以理解为 src 的一项啊) 🤔？ Py 的 argparse 也支持这样（但我不清楚它的架构细节），总之没有一些较 dirty 的 hack 是比较不容易的。

一个即得的技巧是，记住上一次读的 list ，然后读 dst 时从 vararg items 里“偷” 一个项目出来，末尾有 N 项就“偷” N 次。
另一个技巧是寻找 vararg items 的 position ，解析时直接就算 srcs 有多少项，取了跳过 (有点类似 Lua 虚拟机对不定长参函数的编码方法，但这种方法可以做成支持多个 vararg 的不知道有啥样用)

ArgParser 的解决方法比较骚，因为它支持 unparse (backRun) ，换句话说它可以先用无问题的 [dst] [src...] 解析(通过动态构造解析器)，再把整个 items 拼了转过来
没有那么高级，其实只需要把参数输入和解析结果，共反转两次就够了 🌝（不过依然要用到 backRun 😂
这是为什么呢？ 因为我们必须先检查参数是否合法，并且取得其中 item arg 部分…… 但如果你的代码没有用到 reverse, 相应 backRun 逻辑是不需要的(只是即便这样 progurad 等工具也不知道它可以 delete 掉 (x

#tencent #Haha 😂 想到华为之前挺的那个啥 Linux OS

https://twitter.com/magicxqq/status/1351032008533831684?s=19
微信毒瘤特点++

#cplusplus #linux #apple #China #tencent #wechat
相应肇事代码： [lib] [app] (by dlsym(RTLD_DEFAULT,"X") )
奇怪的是，在这些代码 is_debug = (sym!=NULL&&*sym!=0); 里我没有注意到不兼容无此符号的问题，估计是 dlsym 设置了 errno 导致运行时错误。

已经有人开了修复 PR (@NeverBehave 和 @metowolf 对此表示 😂)
我感到非常奇怪， WeChat 凭什么去影响上游，让别人帮忙擦屁股？ 😡
影响力就是这么大！（指文化输出）

为什么人家要修：估计是果粉报给 Apple 了，人家一生气就改了 libmalloc ，反正多个符号也没问题 🌚
为什么人家骂 weird ： stack_logging_enable_logging 实际就是“你怎么证明你活着”，本来被使用了就是 enabled ，何必搞什么 _enable_logging 呢？

#windows #security #chrome #web Win8 无效, Win10 蓝屏重启

好消息 好消息
现在你的 Chrome 可以直接造成系统 BSOD 啦
立刻在地址栏输入 \\.\globalroot\device\condrv\kernelconnect 领取蓝屏大礼包一份
* 就算是放在 <a href/> 里的链接也可以造成蓝屏

https://github.com/ice1000/jimgui/blob/master/core/test/org/ice1000/jimgui/tests/Demo.java ... 看了以后我对冰封哥的审美有点失望
虽然这只是一个直接的重写，我看出 jimgui 没有比 ImGui 本身更高的封装，它仅以 add container 的方式暴露了 tree ，这不符合之前写 TkGUI 时我的期望。

这里也有一个 initNewFrame + listen keyEvent & StringBuilder & draw text 的示例
总的来说是很重视性能的一个 JNI 封装， 利用了Critical Native ，从不在 Java/C++ 之间传输 primitive (array) 外的数据(这是十分推荐的)；也会处理 String/std::string 缓存的问题(感觉管得有点宽,应该解耦了) 甚至可以自定义封送 转换函数
用了 intFlag @MagicConstant 和 @Nullable 有好的 IDE 支持

看了一会想点 star ，突然发现我 GitHub 好像被 @ice1000 ban 了，现在还没有解除一样
可能是以前冒犯过他吧，觉得应该解除了啊，唉🌚
找了半天没找到他之前发的 JLine ，找到这个 ，代码质量……