https://github.com/duangsuse-valid-projects/Hachiko #GitHub #project #signal 开源了 🤔 还在开发中

#cs #project #tools 经历了好事多磨后，我的第一个脚本语言实践终于成功啦~ 而且支持 lexical scoping ，看这里。 （上图 LexicalScope 的定义，真古怪呢）

嗯…… 今天终于知道 ncat host port 不止可以 sendto() ，也能 recvfrom() 了

而且，这个送信必须是由手机开 nc -l ，如果是从手机送到电脑，那也是在电脑上 recvfrom() ，不能反向开服 bind() 监听，只能是在网关（手机）上。

好像并不能连接到电脑端 ip addr iface 给的那个 inet 地址，但是网关（即开USB绑定共享的，手机电脑都易拿到地址）就可以联通，非常生草

当然如果只是这样就太没意思了，我写了个基于 #Python + socket/sl4a 的剪贴板共享脚本： #code #project

from socket import socket
from androidhelper import Android
sl4a = Android()

def serveTcp(saddr):
sd = socket()
sd.bind(saddr); sd.listen(1)
while True:
try: print("."); acceptReq(sd.accept()[0])
except IndexError: pass

def acceptReq(conn):
seqPrefixBytes = iter(lambda: conn.recv(1), ':'.encode())
act = chr(conn.recv(1)[0])
if act == '-': conn.send(sl4a.getClipboard().result.encode())
elif act == '+':
num = int(b"".join(seqPrefixBytes))
sl4a.setClipboard(conn.recv(num).decode())

serveTcp(("", 12345))

#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

吃饭的路上（最近有点劳累过度了，思量着 ANSI BadApple 赶紧结束休息几天吧），谈到所谓“优雅性”，想了一下 ParserKt 新 LexerFeed 的问题，感觉很 complicated ，流对象的各种属性真的不好办

首先是说这个给冰封提到底有没有意义的问题（毕竟 PM 冰封是一个比较要心理准备的事情，心理难度比与 Python 红姐、九月姐 谈笑风生不低多少），最后结论是有。

虽然 jimgui 的本意未必是做“定义式”的 GUI 框架，更像是学习 JNI 设计，而且 Kotlin wrapper 很可能会有好的接口，技术交流也是不应有太多压力的。
TkGUI 的代码生成方法利用了 Python 无编译期/运行期，虚拟机相关组件基本可用的动态性，以及动态类型；很难(或者说意义不大)移植到 Java ，但我的本意是 GUI 可以这么写， ImGui 的做法可以说是业界惯例(就我的观察, GTK, Wx 的大部分封装不需要为子控件选择 parent, 但没有一个支持树形代码定义一个视图，即便其语言有足够表现力)，Java 的 Swing Frame,Panel 和 Fx Stage,Scene,Group 都必须用 mutate 对象的方法「创建」模板化的视图树(当然这是过程式的自然映照,无可厚非)， Qt 和 C#, VB 有 uic 这样的 code generator ；而 TkGUI 的 way 更像是 parser combinator 那样，尽可能少用外部工具，直接在语言里组合。

这个 way 就是一句话，“优美的代码能直观地反映它所处理数据的结构”，程序结构和数据结构相互照应、谐调统一，虽然会有额外开销，但一件事情只有你重视了才能找到各方面的最优解决办法，否则就永远只是传说。

再谈 ParserKt 的问题，其实最初版本相较于一些同类已经可以算是优雅了（当然离我想的还更远）
几个月前的重计划里包含了“削除 Parser 里 Lexer 相关代码”的改动，可以说是解决了我心头一厌(很多 PEG 生成器都逃不开跳空格注释的问题，要么然写文法里，要么然走 lexer/parser 的老路，要么然可配置性不够好，这是比较草的，因为我觉得在 a b c “按顺序”模式里默认插跳空格的逻辑是接近正解的)

具体实现还算好， Lexer/Parser 的区分、 Token 而非 Char 流的存在，核心原因是空格和注释对语法结构是无效的——最好能无视，免得解析器混杂
scannerless parser 很好，但跳空格其实有更容易的解决方法——为 Input stream 添加 filter ，到底还是 java 那一套自由组合的 stream 最好，连 skipped whitespaces 以及 AST element spans 它都可以往 Map<K,V> 存储好了，这就同时解决了 AST data class 不好写的问题，在不必使用这些信息时，也提升了性能，就从根源上解决了许多联带(代码复用、类型冗余和构造器隐式参数、分词解析器如何相互协调的)问题。

核心思想容易，实现上也有些问题—— Lexer 和 parser 在最近的语言里越来越模糊了，你可以看到 KotlinLexer 里会处理一些嵌套问题(就需要 push/pop state number 了)，而且 >= 与 fun():P<T>= 的区分也使得它必须识别一些本该由文法处理的模式——在过去这是不可想象的，C 的词法规则相当简单

这么做势必造成计算力的浪费(分词器和解析器对同一份数据做了类似的动作——检查它的嵌套结构)，以及编程的冗余、重复代码，是应该努力避免的。

解析器与“分词器”之间的交流，显然是 parser combinator 的优势——它们的结构对程序员是完全透明的，可以自由定义、随意组合，让 Parser 去驱动其输入流上的 Lexer ，告诉分词器现在是什么状态，需不需要跳空格(例如 "" 里就不能跳)；分词器是一个针对 Feed 流的状态机，本身也是一个 Feed ，而 onChar 的时候被动进行状态转移，就可以 filter 掉那些解析器不想看的字符，同时也能选择性地保留(如语法高亮) 的数据，一举多得。

有的观众就会问了：这么好的方法，比你高到不知哪里去的聪明人可多了，怎么就你想出来？
首先，不能说是没人想，要看编程实践怎么用、怎么组合这些技巧，不是说你去做了，效果就真的能像想象的那样好
其次，如果你没把代码重写 9遍，也容易被 Lexer/parser 和 scannerless 的那群既有实践误导，以为必须有 tokenizer ，或者流只能是一层，不能有“滤过”操作的
如果 LexerFeed 的被动性[2](非阻塞,要不然无法共享 string 等词法的定义)以及 Parser 对其的主动性(传递在解析词条类型号)不能被保证， 许多人对输入字符序列的抽象不够灵活(万恶之源)，使得他们不能够发现这一点。 （所以你在编程的时候，记得重复的少写一点、稀奇的功能特性多写一点，说不定还能帮助你对程序模型整体的理解）
(这种设计也很好的发扬了 ParserKt 的 one-pass 设计，而 C 系语言 // /* 注释与除号的区分早有给 InfixPattern 扫描操作符的 TriePattern 专定子类可轻易完成，PKT 的组合性不加盖的)

但这个封装有很大问题—— ParserKt 最初只有 Feed { val peek; fun consume() } ，不像一些 nextChar() 或 curChar() 数据视口不一致、命名迷惑的框架，它的流模型只允许程序员着眼一项（最本质的问题），结束时抛 Feed.End 异常
尽管这是根基(SliceFeed, Iterator/ReaderFeed 子类)，它也是不切实际的，所以很快有了 Input(s: Feed): Feed, SourceLocated, ErrorHandler [1]，以及一大堆 Feed 上试着 (this as Input) 的扩展函数，允许解析器带行号，尽量减小开销(统计行号信息是要在 Char 输入上，而一些输入根本无需 Input 的一些成员)
而那些接收 Input 的 Input ，就只能用一个代理(delegate)类 Input.By 去 proxy 这 underlying stream 实现的一些特性，这种问题严重后有点像“责任链”的字面含义——不断尝试 unwrap 一个 (可能是Input的)Feed ，寻找某个 trait 的实现者。

如果说你组织流嵌套的方法是手工的，应该不需要滥用多态去做“动态类型”，又或者是自动的——真的到那种“可组合”的地步吗？

最后我觉得，还是做 LexerInput(s:Input): Input.By 比较好，这样 LexerInput(Input(s=SliceFeed(Slice("wtf") ))) 这样的二层就会成为必要的组合法，如果需要其他层，则不能打破 Lexer 需求 Input (SourceLocated) 的类型， 还是取消这样的限制吧…… 真不知该怎样解决这问题 #parser #parsing #learn #Kotlin #project #suggest

[^1] 现在我更倾向 Input: Feed, FeedControl, SourceLocated { val states:Map<String,Any>; val onError; val isCompleteRead:Boolean }
isCompleteRead 是重新建模的(结果存逆波兰栈的)算符链解析器需要的，在非 complete read 时，可以像 Lua 一样直接进行简单的常量折叠，否则不仅不能折叠，还要存语法元素行号、前部空格等(重现原文所需的)信息
[^2] 其实我理解错了，这也是因为 LexerFeed 最开始是能自动识别底层输入的状态机，上级请求字符时肯定是要 blocking consume 直到非空格字符的，所谓非阻塞是因为对非空格单个字符它照样要处理状态转移；现在我倾向把它做成“能暂时屏蔽的自动 ws skip”一些，因为这才能真正统一复用文法/词法规则 ，虽然那样就没有花里胡哨的 List<Triple<Char,Int,Int>> 了(毕竟有效性在那)

#github #china #web #project

#PLT #ce #china #recommended #project #csharp

#gist #string #combinatorics_of_strings #project
计算所有长度为 n 的字符串的自相关位向量（Autocorrelation）
https://gist.github.com/Mivik/6e0459afe6691bce2659e1eaa5141390
没有注释的话只有短短 60 行，并且没有刻意压行，比 某些人 写的 1000 多行版本好多了（写那个的貌似是个学院派，代码里充斥着完全没法编译的怪异头文件以及鬼畜的码风...）
灵感来自于 这篇论文

项目还是 去世 了 😭 #life #project #ce #java #Python
本来就没打算花太多精力，但实际上还是花了，凌晨两点；与之前为防止熬夜休息的意图是背道而驰的
其实我只是想重写 lexer 而已， Text, Diagnostics 的新概念都不足以大张旗鼓、废寝忘食的搞
原因可能是不正常的时间安排以及 挂羊头卖狗肉