#Ruby #code #tool #Telegram

#Ruby Dir.glob('.*').let { |fs| fs.zip(fs.map { |name| name.gsub(//){$1} }).each { |c| o,n=c; File.rename(o, n) } }

for ln in $<.each_line do
  next unless ln.start_with?('mv')
  _mv, src, dst = ln.split
  puts("mv #{dst} #{src}")
end
def bulkRename(re_src, pat_dst, fmt_dst)
  re_dst = Regexp.new(pat_dst)
  selected = Dir.glob(re_src)
  for name in selected
    newnam = name.gsub(re_dst, fmt_dst)
    puts("mv #{name} #{newnam}")
    File.rename(name, newnam)
  end
end

case ARGV.size # Just br size is OK
  when 0 then warn("Usage: #{$0} [select] re_dst fmt_dst")
  when 1 then puts(Dir.glob($*[0]))
  when 2 then bulkRename('*', $*[0], $*[1])
  when 3 then bulkRename($*[0], $*[1], $*[2])
end

好久以前的 #Ruby

#Ruby 实在是太过分了……

说实话，看到 #Ruby 关系式求解器 里作者实现了个 Iterable.interleave_with 我觉得挺奇怪的，真的是要 interleave? 总觉得可以 zipWith 什么的，但作者的水平又不可能不知道 zipWith
作者的实现方式也很奇怪， interleaveWith 就是 (xs=[a, b], ys=[c, d]) res=[a, c, b, d] 而已，但他用的方式是一个 Array 不断 push pop 这么 cycle 下去的

嗯…… 谈到 XML 解析突然想到 #Java 的 SAX(Simple API for XML) 和 XMLPull

React 用的也好像 E4X(ECMAScript for XML) 啊

我常区分函数的『主动』与『被动』，比如说计算就是主动，事件和入口就是被动；其实工程界把 push 称为主动， pull 称为被动(当然和 git pull 不同😂)，这也是一个比较 English 化的词

XMLPull 被称为最快的 XML 解析器，其实准确来讲它只是一种数据封装思路——不直接新分配并提供数据对象，而是把尽可能裸值化的它提供给 onXXX 函数（比如你只是找 <a href> 就没必要构造整个 Document 对象），这样就能大幅减轻 GC 压力（C++ 也就没必要用 shared_ptr 了，因为根本不存在对象引用，只有虚表的覆写函数）

这个思路其实也怪好的，而且它也能兼容（利用数据栈）构造如 XMLNode 的递归结构，从而作为可扩展的底层来提供。

之前用过 #Ruby 的 XML 解析器 Nokogiri ，那叫一个烂…… 它不是 XMLPull 模式却有“高性能”的觉悟， Node.attributes 都是 Array 非 Hash... 貌似连 CSS selector 也没有只支持 XPath，实在是太草了

说起来， ParserKt 也包含这种思路。
虽然 Pattern<T> = (Feed,ShowReq?) -> T 是明确要『主动』构造 T (这样看起来它的性能不如 ANTLR, GLL, LALR 这类状态栈算法的『被动』 action)

一方面， ParserKt 的可组合性允许创建不依赖 Pair/Triple/Tuple 的 Seq 而可以复用余下所有定义，是能够通过切换少数调用来支持 pull 模式的 event listener 的

另一方面，pull 一定比 push 快因为使用了“高级算法” 其实是常见的误区，而且对DSL解析器而言构造AST数据是主要目的，实际上有 JS 解析器框架里，JSON 跑分结果最好的反而是手写递归下降法，且 Lua 初版是利用 YaCC 生成解析器，后来反以手工重写。

虽然这种方法有 push 的一些固有限制——阻塞、不能统一处理错误消息/部分结果，但它的高代码质量却能带来意想不到的优化，而这种方法支持的文法并不比 pull 少。

有时候选择代码质量、高抽象度、简化的底层接口并不意味着牺牲性能，因为在其上下建立的实现技巧完全可能追回那点小小的开销。

比如，Fold 模式能支持 asInt(16) 这类已经是最低开销的数值读取，而无需“action”将其“rewrite”成 String.toInt ，从不需要用左递归蹩脚的语法来“优化”，而对于参数列表之类也无出其二， asList() 甚至还能 asMap() ，避免创建多余的结构去保留临时 String/List<Pair> ，直接从提出值到构造大结果，何尝不是一种 XMLPull 式思路

尽管用“万能的”左递归优化可以实现 Fold 和 OpChain 所解决的问题，但没人用它——实际上有 DSL 设计需求的人还不少，但有多少人会把 digits 定义成 (digits digit)|digit 的形式？大家看到左递归链的优先级解析就糊涂，甚至不知道为什么加减在前乘除在后

想像一下，如果一个人为了优化 ES5 的解析器而把所有能 Fold 的循环重写其 action，变成左递归定义，看起来会如何？
所以唯一的解决方案就是简化表示法本身，分清主次，用适度特例化的 API 取代“万能” “广义”的“好好先生”们。

现在看起来这个真的😂 #Telegram
想到那时候写的 #Java RegExp TelegramScanner ，为什么不能直接用爬虫扫 HTML 导出所需 XML 呢，用 JSON 再与 #Ruby/#JS 组合多好啊

那时候对列表处理 #listproc 也不重视，写 sort_by {}.reversed 这种代码，但是更新得非常有序，不过频道一直保持着良好的 hashtag 习惯

要是这个统计再做一遍，肯定就会用 GUI，至少是图表的形式，总结语必须是自动生成，不然嫌对查询式有用性挖掘得不够。 #dev 🤔 #statement (什么时候开始有这种程序泛用化的思想了)

#Ruby gem sources --add https://gems.ruby-china.com/ --remove https://rubygems.org/
草 好怀念啊； Ruby 的 OOP 是怎么玩的都忘掉一大半，还好基础语法、控制流和 mixin 什么的都没忘... 🤪
不过 gem 工具下载也没个提示，还不如 pip 。这些脚本语言的开发者很多人都喜欢搞 term color ，但是竟连搞好交互和灵活性都不会
什么时候能写 bash_completions 才能算好的 cli 开发者吧

Python 的各种新 pm 不用 pip 和 setuptools 都不会弄了， Ruby 还是自带 bundler, install 。
真的搞不懂 isolation 是在干什么，为什么要 isolate dependencies 啊，为什么要 venv 啊，直接用系统版本，向前兼容不好吗

sudo gem pristine commonmarker
妈耶， MRI 2.6 的 libruby.so 更新，还要这么操作才能修复老库，试了半天 #GitHub 发现还是只能按官方用 bundler 来... 不然识别不了插件

echo 'gem "github-pages", "~> 211", group: :jekyll_plugins'>Gemfile

bundler exec jekyll s

这个东西把 Others/CommentBot/vertxBusGen/build/js/node_modules/balanced-match/README.md 的 node_modules 也 include 进去了，结果 Liquid 模板语法错误 😂
还好渲染是正常的，所有 md 文件不管带不带 header 都支持

#HTML #JS #DontKnow 你知道吗？ 🤔
HTMLElement 的 remove() 和 replaceWith(e1) 都不需要手动拿 e.parentElement ，只有 insertBefore(e1, e) 需要在 parent 上
如果不用 JQ ，可选注册 document "DOMContentLoaded" 或 window "load" 事件

element 和 node 的区别在于，前者只能是 <a> <b> <div> 这样的元素，后者可以是 #text 文本标签。

HTML 里基于 XML 的部分有三种情况： <meta charset="UTF-8"> 的单独标签、 <div></div> 的配对标签(with childNodes)、 <link rel="stylesheet"/> 的折叠(collapsed)标签，有些配对标签也有折叠形式，但折叠和 no children 是不同情况。

有许多方法可以缩写 HTML ，最常见的是基于 CSS 选择器的 emmet.io 和基于缩进的 模板语言 #Ruby slim-lang.com ，而 DOMParser 本身也支持兼容解析修正一些不完整的文档。
想在社交平台分享自己的网站， OpenGraph 了解下？

- !!"" 和 !!0 、 !![] 都是 true ，第一点往往造成隐患 必须详细检查
- undefined == null ，所以有时用 === 区别严格相等性
- JS 最不常用的两个关键字： delete o[k]; 和 v=with(o,o1) { attr }

许多时候：
如果用 e.onclick = 的简写，在任何地方的(其他)脚本重复注册时会导致覆盖，所以尽可能用 addEventListener
JS 里较短参数的函数兼容较长处的类型限制（允许无视参数），但在调用时省略默认参数可能造成性能问题，在绘图/大批/频繁处理时，需要多用图形界面的 profiler

#js #DontKnow 原型链：（感谢 @JackWorks 提供相关信息）

访问语法都是动态解析的，比如 x.prop 或

x["prop"]

就是

x.[[Get]]("prop", x)

ES 里一共有五种不同的 [[Get]] 实现，分别是
- 普通对象 [规范]
- Argument 对象（你们今天应该不会用到了）
- 类数组对象（数组的特殊行为就在这里）
- 模块对象（import * as Mod 里的 Mod）
- Proxy 对象(reflect proxy 全 delegate)

此外， Object.getOwnPropertyDescriptor(o, k) 可以获取可配置 enumerable, writeable 等属性的配置对象

Object.[get/set]PrototypeOf(o)

和 o.__proto__ 是它的「超类虚表」

[[Get]] 过程的 Receiver （第二参数）很重要，如果没有这个 Receiver，基于原型链的 OOP 其实是做不起来的

原来是往 proto 上找属性！
这就解释了 Array.prototype.map 之类的东西

parent = { method() { return this; } }
child = {}; child.__proto__ = parent;
child.a = 1; child.method(); // 返回自身

最简单的解释是， Receiver 就是属性访问的时候最上层的那个对象，会被当成 this 用。
因为在这个算法里你可以看到，Receiver 是跟着递归一路传递下去的

原来是 o["RESOLVE"](o.prototype, "attr", receiver=o) ！（当然，肯定是先查本地，然后才查 prototype
本地如果有就不会查 prototype 了

明白了，和之前写的 LuaOOP 很像，都是层叠属性查找

“ 大佬能交换下原型链相关知识吗
之前看加 Mixin 好像是说把 prototype 除了哪两个属性的什么全部复制一下
#Python 和 #Ruby 的情况我都了解， Py 是 mro() 链查询， A.wtf 和 a.wtf 都是往 class A 找成员，后者实质是 type(a).wtf(a) 所以得到 bound method ，而直接 A.wtf 就是 bind 操作
@staticmethod 直接不收 self ，不需要 bound 所以可以在类和实例上用

https://paste.ubuntu.com/p/tJv7QpSjGt/ liuil-util 的 #TypeScript mixin.ts 重写