Chevrotain is a very fast and feature rich JavaScript LL(k) Parsing DSL. It can be used to build parsers/compilers/interperters for various use cases ranging from simple configuration files, to full fledged programing languages. 我就不说什么了，没啥学术气息、接口又混乱，到处乱用 {} configure object，还是传统的 lexer-parser 架构。
Bennu is a Javascript parser combinator library based on Parsec. The Bennu library consists of a core set of parser combinators that implement Fantasy Land interfaces. More advanced functionality such as detailed error messaging, custom parser state, memoization, and running unmodified parsers incrementally is also supported. 这种框架就不是为了给人用的，主要还是为了让作者能弄一些非常高大上的函数式数据结构弄的。
val aOrB = elementIn('a', 'b') //item('a') or item('b'); aOrB.read("b")//'b'
/tmp/duangsuse.sock
PEG.js is a simple parser generator for JavaScript that produces fast parsers with excellent error reporting. 可惜就是参数名黏糊了一点，不能体现重点。
以上我把许多同类框架/工具/库 都给得罪了一遍 🤪
得罪得真舒服啊
其实 ParserKt 和它们大部分框架都不在一个思维频道上
如果你试着把一些框架的代码移植到 ParserKt，而不是直接从语法的角度重新设计，你可能会发现自己写了很多错误的置换，
因为 ParserKt 完全面向对象设计，Pattern 就是高复用代名词，用 Pattern 和 PatternWrapper 和用一些很基础复用性灵、活性很低的 组合子，思路完全不一样。
得罪得真舒服啊
其实 ParserKt 和它们大部分框架都不在一个思维频道上
如果你试着把一些框架的代码移植到 ParserKt，而不是直接从语法的角度重新设计，你可能会发现自己写了很多错误的置换，
因为 ParserKt 完全面向对象设计，Pattern 就是高复用代名词，用 Pattern 和 PatternWrapper 和用一些很基础复用性灵、活性很低的 组合子，思路完全不一样。
/tmp/duangsuse.sock
[duangsuse@susepc pkt_9]$ kotlin Arithmetic 1 + (2 - 3) + 4 + + 1 (- 2 3) 4 = 4 [duangsuse@susepc pkt_9]$ kotlin Arithmetic 1+(2 - 3 + 4 null = null [(<stdin>:2:0#13, expecting ')' (from <stdin>:1:3)), (<stdin>:2:0#13, infix 1 parse failed at +)] 又拿 ParserKt…
ParserKt 现在的代码简洁性已经蛮够了，用来实现各种解析器/REPL 都不是问题
因为解析器框架本身很具有复用性，现在又有了 LexicalBasics 对其复用性的利用
因为解析器框架本身很具有复用性，现在又有了 LexicalBasics 对其复用性的利用
/tmp/duangsuse.sock
Waxeye is a parser generator based on parsing expression grammars (PEGs). It supports C, Java, Javascript, Python, Ruby and Scheme. 我唯一看得上眼的工具，可惜在文档上还是略微欠缺了些。
可惜 Waxeye 是工程系和学术系表示法的杂交，虽然支持的目标语言多而且也算是蛮工整，
那个又 bash 又 Haskell 的语法规则，我真是一些不懂。
那个又 bash 又 Haskell 的语法规则，我真是一些不懂。
Forwarded from HenTaku
同場加映(別群朋友做的工具
https://forum.xda-developers.com/chef-central/android/guide-tool-projekt-scribt-v1-33-t3503018
https://forum.xda-developers.com/chef-central/android/guide-tool-projekt-scribt-v1-33-t3503018
XDA Forums
[Guide-Tool][Linux] Projekt ScriBt v2.2.1...
[~] Projekt ScriBt [~]
Projekt ScriBt, is a Bash Shell Script which helps a Aspiring Developer to build an Android ROM, in an understandable way :highfive:
Only for Serious students...
Projekt ScriBt, is a Bash Shell Script which helps a Aspiring Developer to build an Android ROM, in an understandable way :highfive:
Only for Serious students...
Forwarded from Deleted Account
三种方法，既能让某个“悬浮窗”对象独立于插件的 static root 或至少不泄漏 Context，又能保证所有事件里能引用到这个对象
泄漏和不泄漏，其实就是时间（生命周期）和作用域（可以引用某对象）的问题。
作为一个扩展，泄漏当然会和宿主的使用方法相关。
Android API Platform 对 android.content.Context 的限制也是可以理解为『宿主(系统平台)』对『扩展(应用程序)』的限制的，这个根本的限制就是，Context 不应该是 application-level 的，而是由类似 Activity 的任务启动时由系统提供的。
不说一些很玄学的问题（比如说弄个
比如你要 setXXXListener，我们所需要唯一的限制，就是这些 Listener 实例访问到的 Context 必须是 valid 的，这个容易。
不然就无法保证某 Context 存在的时候，它代表的组件也实际“存活”，仅说 Activity，先存某活动"A"的引用，退出稍后再在另一个活动"B"里访问存下的 Context，整个应用的虚拟机可以复用，但是 A 的句柄却失效了，这就是泄漏问题（也不完全算是内存泄漏）。
模型是 线程(只需暴露出类似 Executor 的代码执行资源)、服务(和线程差不多、接口也差不多，但可以直接封送对象协同并发工作)
1. 只要提供 onDestroyPlugin，利用
2. 利用 GC 细化封装对实例的依赖（所有依赖 context 的操作和 val ctx 封装成一个类，甚至利用 inner class）
插件的实例保留 Context 量，并且提供所有事件和扩展的 handler，只要应用不再需要插件则对应的 Context 也失去了所有引用
3 . 利用“singleton”的 Service 保留一个 context 引用，在插件移除时候终止 Service，可以保证不会泄漏引用的单实例。
实际上是利用插件和插件Service 1:1 的数量关系设计，而对引用本身依然保持在某种 Runnable 的 object instance 里，但那就和主要的 app_process 的 static root 隔离开了
泄漏和不泄漏，其实就是时间（生命周期）和作用域（可以引用某对象）的问题。
作为一个扩展，泄漏当然会和宿主的使用方法相关。
Android API Platform 对 android.content.Context 的限制也是可以理解为『宿主(系统平台)』对『扩展(应用程序)』的限制的，这个根本的限制就是，Context 不应该是 application-level 的，而是由类似 Activity 的任务启动时由系统提供的。
不说一些很玄学的问题（比如说弄个
static List<Context> 或者在别的线程操作 Context、把 Context 到处传这样）比如你要 setXXXListener，我们所需要唯一的限制，就是这些 Listener 实例访问到的 Context 必须是 valid 的，这个容易。
不然就无法保证某 Context 存在的时候，它代表的组件也实际“存活”，仅说 Activity，先存某活动"A"的引用，退出稍后再在另一个活动"B"里访问存下的 Context，整个应用的虚拟机可以复用，但是 A 的句柄却失效了，这就是泄漏问题（也不完全算是内存泄漏）。
模型是 线程(只需暴露出类似 Executor 的代码执行资源)、服务(和线程差不多、接口也差不多，但可以直接封送对象协同并发工作)
1. 只要提供 onDestroyPlugin，利用
/*static*/ var ctx: Contex? = null 就可以在插件移除时保证 Context 不再能被访问到，缺点是这种做法对 lint 不可见2. 利用 GC 细化封装对实例的依赖（所有依赖 context 的操作和 val ctx 封装成一个类，甚至利用 inner class）
插件的实例保留 Context 量，并且提供所有事件和扩展的 handler，只要应用不再需要插件则对应的 Context 也失去了所有引用
3 . 利用“singleton”的 Service 保留一个 context 引用，在插件移除时候终止 Service，可以保证不会泄漏引用的单实例。
实际上是利用插件和插件Service 1:1 的数量关系设计，而对引用本身依然保持在某种 Runnable 的 object instance 里，但那就和主要的 app_process 的 static root 隔离开了
Forwarded from Deleted Account
gradle 卡 kotliln compiler 下载，一直没法过
Searched in the following repositories:
Gradle Central Plugin Repository
Searched in the following repositories:
Gradle Central Plugin Repository
Forwarded from Deleted Account
Gradle 终于开始下载了，还是我 pacman -Syu 以后才能下载的，之前都直接卡死在 select() 系统调用上
我去
不对,这个不是阿里的
gradlew -Dhttps.proxyHost=127.0.0.1 -Dhttps.proxyPort=3129 了 Ali 的 proxy不对,这个不是阿里的