#life #dev duangsuse 落实 10:30 准时睡觉『政策』。 🐱

考虑到健康原因（不让自己的努力白费），每晚 10:30(h:m) 必须立即睡觉

== duangsuse::Echo 参考 #Telegram hashtags

duangsuse::Echo 常年利用 hastags 标记消息所含知识领域，并且，这也会为未来 Echo 频道进行简单准确的数据统计带来可能（不然，我也有其他手段，比如 NLP、统计预测）

以下是新的标签实例（不区分大小写、不能保证消息只含这些标签）：

== 消息平台部分
#Telegram #zhihu #Github #so #Coolapk #book #wiki

== 注释部分
#life #China #School #Statement #lib #recommended #low #fix
#project #blog #share #Learn #paper
#dev #tech #art #meetUp #conference
#Moha #Haha
#gnu
#Microsoft #Mozilla #WeChat #QQ #Weibo #Tencent #Baidu #Ali #Qihoo
#tools #code

== 程序设计语言部分
#Kotlin #Java #JavaScript #JavaScript_ES6 #TypeScript
#Rust #Go #Swift #Dart #Crystal
#Ruby #Python #Perl #Tcl #Lua #PHP
#C #D #Cplusplus #CSharp #Objc
#Pascal #Fortran #Delphi #Ada #Basic #VisualBasic
#Scheme #Haskell #Scala #Clojure
#TeX #Graphviz
#Octave #Matlab
#Shell
（有些写出来是为了鼓励我去写，其实不一定真的写过）

== 软件平台部分
#Android #Windows #Win32 #MacOS #Java #Java_JVM #CLR #Qt #GTK #Tk #WxWidgets
#CSS #XML #JSON #KDE #Postgres #dotnet

== 软件技术领域部分

#backend #sysadmin #frontend #sysadmin_net

#OI #CS #IT #Informatics

#stat #ann #ann_dnn #machl
#math #math_linearAlgebra #math_discrete
#se #se_dia #se_ci #se_ee
#comm #net #www #web #http #html #mail #wireless
#circuit #embedded #os #db #db_relAlgebra #SQL
#bin #encoding #encoding_audio #encoding_image #encoding_video #encoding_text
#hpc #parallelism #distributed #simd #gpgpu #crypto
#pl #pl_plt #ce_vee #ce #ce_optimize #fp_monad #fp_proof #fp #oop #oop_arch #sp #parser
#algorithm #struct #lists #maps #sets
#security #security_lowlevel
#signalProc #nlp #phonetic
#cg #cg_dip #cg_3d #cg_2d #cg_lowlevel
#gui #gui_animation #gui_layouts #cli #visualization

#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