Interactive protocol (Tunnel)
{a} means (repeat a); (a b c) means (sequence of a b c); (a|b|c) means (a or b or c); a!t means (ensure t unread before read a)
'+', '-' for each file input, '.' normal; '!' (error code) fail
'?' for each file input, 't' immutable flag set; 'f' immutable flag unset; '!' (error code) fail
{a} means (repeat a); (a b c) means (sequence of a b c); (a|b|c) means (a or b or c); a!t means (ensure t unread before read a)
newline '\n'Feedback protocol
Ws {' '|newline}
Tunnel {Operation newline}
Operation Action Count Ws Files
Action '+'|'-'|'?'
Count {digit}
digit [0-9]
Files {Path ws!newline}
Path (Escape|anyChar) until ws
Escape '\\' anyChar
'+', '-' for each file input, '.' normal; '!' (error code) fail
'?' for each file input, 't' immutable flag set; 'f' immutable flag unset; '!' (error code) fail
本来字符级别处理的类 Scanner 的算法我之前写过不止一次，只有写 C++ 的时候老出问题，还无尽循环导致分配太多内存，我估计肯定是某处数据流没移动，可是检查过却都是对的
其实 count 根本就是一个冗余设计…… 但是也不是没道理的，毕竟本来就应该有确定大小，我写的时候随便了点动态大小了
duangsuse::Echo
这样能够做到吗？
我在脑子里模拟然后确认了一下，除了 onHandle 外解析部分应该是完好可以使用的。
因为好像实在是没时间了，而且貌似已经就要收尾了（虽然我还是很不高兴，因为做的不够多）
所以我不得不放弃了使用 EOT 的做法（就是倾向一个正常程序来用，不然得手动kill它），即便其实 Scanner 架构还真没啥不好的…… 除了第一次peek的情况我无法看明白之外。
所以我不得不放弃了使用 EOT 的做法（就是倾向一个正常程序来用，不然得手动kill它），即便其实 Scanner 架构还真没啥不好的…… 除了第一次peek的情况我无法看明白之外。
Forwarded from duangsuse Throws
#life #Telegram 为了方便大家认识我，我把名字里的一些东西移动到 bio 里
这句话的源头是冰封哥 @ice1000 的『菜是原罪』
后来我发现，我不应该尝试跟在他的后面怎么样，每个人都有自己的风格，何况冰封哥不喜欢菜鸡跟在后面的。
Telegram bio的空间很宝贵，我暂时不想在那里放格言，那就简单放一个自己的领域介绍吧。
现在的 first name （名）是 duangsuse，没有 last name（姓）
Technical unfamiliar is origin sin 这句话的源头是冰封哥 @ice1000 的『菜是原罪』
后来我发现，我不应该尝试跟在他的后面怎么样，每个人都有自己的风格，何况冰封哥不喜欢菜鸡跟在后面的。
Telegram bio的空间很宝贵，我暂时不想在那里放格言，那就简单放一个自己的领域介绍吧。
/'dʊɔːŋ sjuːz/; [PLD, FPλ]; @dsuse@dsuses 日常讨论笔记文档代码 17yo CC-BY 现在的 first name （名）是 duangsuse，没有 last name（姓）
Forwarded from dnaugsuz
所以说在设计语言的时候，有些东西是要好好斟酌的。Python 的 slice 区间切片语法其实没什么，我开始也会对自己 Kotlin 里的 (read-only)Slice 抽象写上
但现在我改了，换成了
operator fun get(indices: IntRange): Slice<T> 但现在我改了，换成了
fun slice...。不是因为我嫌它太短，而是它短出了问题，语义上不够优雅。 就像我开始很奇怪 Kotlin 和 Java 为什么允许 integer literal 能够写上默认的正号一样，因为去掉会使得它看起来、感觉起来很奇怪、不对称。Forwarded from dnaugsuz
《Kotlin极简教程》的陈光剑开始会说『明明很多东西(plus, minus, ...)都是一般约定的 operator 名字，为什么还要再加 modifier "
想想Python3现在的元方法，可以说真是能让人看瞎眼了。Python3真是把『元方法』这个概念发挥到了极致，发挥到了邪恶化的地步。
如果说Lua的 __gc, __newindex 什么的还稍微有点规范可言（都是在相当「精炼」的运算语义扩展上），Python3 的已经是玩过火了，它的元方法是什么都有，而且和Kotlin的
operator" 啊』想想Python3现在的元方法，可以说真是能让人看瞎眼了。Python3真是把『元方法』这个概念发挥到了极致，发挥到了邪恶化的地步。
如果说Lua的 __gc, __newindex 什么的还稍微有点规范可言（都是在相当「精炼」的运算语义扩展上），Python3 的已经是玩过火了，它的元方法是什么都有，而且和Kotlin的
operator fun 重载完全不在一个级别。真不知道Van君如果哪天重写Python3，是否能把元方法的规范默写下来。
dnaugsuz
《Kotlin极简教程》的陈光剑开始会说『明明很多东西(plus, minus, ...)都是一般约定的 operator 名字，为什么还要再加 modifier "operator" 啊』 想想Python3现在的元方法，可以说真是能让人看瞎眼了。Python3真是把『元方法』这个概念发挥到了极致，发挥到了邪恶化的地步。 如果说Lua的 __gc, __newindex 什么的还稍微有点规范可言（都是在相当「精炼」的运算语义扩展上），Python3 的已经是玩过火了，它的元方法是什么都有，而且和Kotlin的…
我这里想比较偏激的说，一切不能被它们的创造者默写、可视化下来的设计，都是冗余或者不规范的设计。 #statement
如果说你经常使用类似的设计但从没觉得不对劲，那是因为你从来没完全重写过你的代码，所以感受不到他们的奇怪。
如果说你经常使用类似的设计但从没觉得不对劲，那是因为你从来没完全重写过你的代码，所以感受不到他们的奇怪。
Forwarded from dnaugsuz
所以Python害得定位差不多的Ruby受到迫害用户量减少，真是劣币驱逐良币。
还好在更规范的JVM平台上这是不可能的，虽然很多开发者依然按照习惯继续使用辣鸡到10才有 local variable inference 的Jawa，Kotlin依然已经（虽然是借助Google之手）在许多开发圈里火了起来，是Kotlin驱逐屑Jawa，至少比Python应用的情况好。
还好在更规范的JVM平台上这是不可能的，虽然很多开发者依然按照习惯继续使用辣鸡到10才有 local variable inference 的Jawa，Kotlin依然已经（虽然是借助Google之手）在许多开发圈里火了起来，是Kotlin驱逐屑Jawa，至少比Python应用的情况好。