https://github.com/dhakehurst/net.akehurst.language/blob/efafa3e57f89ddea2f81ca3080121f2e70cce9e0/net.akehurst.language/agl-processor/src/commonMain/kotlin/parser/sppt/SharedPackedParseTreeDefault.kt
这一系列操作…… 很算法啊
一般类似 ANTLR 一样的工具也会有 rewrite/action 的选择吧，可这个几乎只有 SPPT(shared packed parse tree) 一样……
ParserKt 是纯递归下降解析组合子，所以没有 YaCC 系的 Parser-Tree 说法，只有内部递归的调用树和临时的 Fold 对象，没有这种……
这一系列操作…… 很算法啊
一般类似 ANTLR 一样的工具也会有 rewrite/action 的选择吧，可这个几乎只有 SPPT(shared packed parse tree) 一样……
ParserKt 是纯递归下降解析组合子，所以没有 YaCC 系的 Parser-Tree 说法，只有内部递归的调用树和临时的 Fold 对象，没有这种……
GitHub
dhakehurst/net.akehurst.language
Generic Language (DSL) support for kotlin multiplatform (parser, syntax-analyser, formatter, processor, etc) - dhakehurst/net.akehurst.language
#Math 如何看待《华裔教授发现二次方程「极简」解法：丢掉公式，全球教科书可能都要改了》？ - 王ruo宇的回答 - 知乎
https://www.zhihu.com/question/359765958/answer/930330106
https://www.zhihu.com/question/359765958/answer/930330106
Zhihu
如何看待《华裔教授发现二次方程「极简」解法：丢掉公式，全球教科书可能都要改了》？ - 知乎
对于全球几十亿人口来说，二次公式是必须记下来的一个复杂公式（可能也是唯一的一个），这也是我们必须学…
你以为文言编程只是闹着玩？三个月后，人家IDE、教程、包管理器都有了 - 机器之心的文章 - 知乎
https://zhuanlan.zhihu.com/p/112650761 #PLT #Python
https://zhuanlan.zhihu.com/p/112650761 #PLT #Python
知乎专栏
你以为文言编程只是闹着玩？三个月后，人家IDE、教程、包管理器都有了
用文言文写的官方编程教程《文言陰符》，类似 pip 那样的包管理工具「文淵閣」，还有文言编程开源 IDE「文言齋」，文言编程语言已经这么成熟了？机器之心报道，参与：思、Jamin。机器之心曾介绍过 CMU 计算机专业…
./gui_crop_select.py ~/视频/IMG_6302.MP4
./extract_subtitles.py -crop '593(85,287)[481,38]' --crop-debug -filter-code '~cvInGrayRange(it, 0xcc, 0xff)' -lang chi_sim --chunk-size 1000 --use-sharp ~/视频/IMG_6302.MP4 现场来提取一个字幕时轴^
./timeline_ops.py merge frames/timeline_IMG_6302.MP4.txt 0.25|./timeline_ops.py to-lrc 25 srt>test.srt
duangsuse::Echo
./gui_crop_select.py ~/视频/IMG_6302.MP4 ./extract_subtitles.py -crop '593(85,287)[481,38]' --crop-debug -filter-code '~cvInGrayRange(it, 0xcc, 0xff)' -lang chi_sim --chunk-size 1000 --use-sharp ~/视频/IMG_6302.MP4 现场来提取一个字幕时轴^ ./timeline_ops.py merge fra…
(\d{2}): (\d{2}): (\S+)-> (\d{2}): (\d{2}): (\S+)
$1:$2:$3 --> $4:$5:$6 然后到 Google 上翻译下，以这个正则替换修复破损的 SRT 格式。
ffmpeg -i IMG_6302.MP4 -vf subtitles=IMG_6302_en.srt IMG_6302_zhEn.mp4🤔 我们来说说之前的 Montage.py 策划。
蒙太奇图是一种艺术画，它用许多相对整齐的子构件来构筑一副图画。
之前我们的安排就是，利用 Python Pillow / Java AWT+ImageIO 的接口，有一个画布以后直接取 color average （实际图像一般有三个 channel，我们只需给这片区域
然后遮盖那一部分原图区域的项就用这个颜色。
不过还有个问题，就是怎么知道项都放哪，之前的项目是有一个 LayoutPlanner，它会 yield 给一大堆 Rect（矩形区域），然后作画也在那上面（准确的说是给 draw 的算法一个 "sub-image" (后来改 crop 了) ）完成，结果最后改来改去失败了，效果很不好
但后来我发现呢…… LayoutPlanner 实际上是不能独立于绘制算法要绘制的区域而存在的，所以失败是当然的。
现在的抽象会是这样
然后布局就是经典的 for y for x 了， x >= width 就 y += avg_h 。
参数：
font, font-size
color-mode, crop, scale (float / tuple)
image items
后来看了另一个项目才想起来的：
space-hv (tuple)
tint-color (code on sub-image
draw-unless (code on sub-image
蒙太奇图是一种艺术画，它用许多相对整齐的子构件来构筑一副图画。
之前我们的安排就是，利用 Python Pillow / Java AWT+ImageIO 的接口，有一个画布以后直接取 color average （实际图像一般有三个 channel，我们只需给这片区域
int[3][] 取 avg 即可）然后遮盖那一部分原图区域的项就用这个颜色。
不过还有个问题，就是怎么知道项都放哪，之前的项目是有一个 LayoutPlanner，它会 yield 给一大堆 Rect（矩形区域），然后作画也在那上面（准确的说是给 draw 的算法一个 "sub-image" (后来改 crop 了) ）完成，结果最后改来改去失败了，效果很不好
但后来我发现呢…… LayoutPlanner 实际上是不能独立于绘制算法要绘制的区域而存在的，所以失败是当然的。
现在的抽象会是这样
class Drawable:
def drawOn(img: Image) -> Rect: pass
class TintedDrawable:
def drawOn(img: Image, tint: Color) -> Rect: pass 然后布局就是经典的 for y for x 了， x >= width 就 y += avg_h 。
参数：
font, font-size
color-mode, crop, scale (float / tuple)
image items
后来看了另一个项目才想起来的：
space-hv (tuple)
tint-color (code on sub-image
lambda it: averageColor(it) )draw-unless (code on sub-image
lambda it: pixelsInRange((0xFF,0xFF,0xFF), 10) / it.count() > 0.5 )Telegram
duangsuse::Echo
#memo Doge
#dev #PLT 以前经常把类似 LuaJava, JamRuby, Lua-intrf 之类的东西称为“高阶语言桥”或“语言绑定” （相反 SWIG 之类的 bindgen 就不会了？）
想想这无非是一个好看没不讨喜、充满民科气息的名词。
给两门语言创建“绑定”，其中一般有一个采用比较“脚本化”的实现方式而非静态编译之类，但关键在于提供底层 API (如 C API)，然后再把 API 和另一门语言创建更高层的绑定（整句话都不太严谨，毕竟涉及 FFI(foreign function interface) 这种非常实践性的问题）
绑定和一般的库绑定会有较大的不同之处，主要体现在数据对象的封送、类型转换(可能存在)、对应的 GC 接口互调等等。
一个主动一个从动，但从“语言实现”绑定的角度看，如 LuaJava 在 Lua 侧能访问 Java 的对象成员，Java 侧也能从 Lua 的 boolean, number, table 等获得信息，这是主要功能。
我应该多写点 C++，光 Java 是不够的，但是我现在真的熟悉 JDK 么……
想想这无非是一个好看没不讨喜、充满民科气息的名词。
给两门语言创建“绑定”，其中一般有一个采用比较“脚本化”的实现方式而非静态编译之类，但关键在于提供底层 API (如 C API)，然后再把 API 和另一门语言创建更高层的绑定（整句话都不太严谨，毕竟涉及 FFI(foreign function interface) 这种非常实践性的问题）
绑定和一般的库绑定会有较大的不同之处，主要体现在数据对象的封送、类型转换(可能存在)、对应的 GC 接口互调等等。
一个主动一个从动，但从“语言实现”绑定的角度看，如 LuaJava 在 Lua 侧能访问 Java 的对象成员，Java 侧也能从 Lua 的 boolean, number, table 等获得信息，这是主要功能。
我应该多写点 C++，光 Java 是不够的，但是我现在真的熟悉 JDK 么……