#TypeScript 没有 in, out 和 * 真是不如 #Kotlin 好啊！还是 Kotlin 设计有创意……

#TypeScript 的 overloads list 有点不直接，而且是半自动的多态…… 定义侧还得手动 typeof

#TypeScript TS 也有『半dependent type』的特性——输出类型可按照实际参数而定。

interface Monkey {
Hou: HappyMonkey;
Jun: SadMonkey;
}

function getMonkey<K extends keyof Monkey>(name: K): Monkey[K] {/**/}

#TypeScript #testing

https://github.com/dhakehurst/net.akehurst.kotlin.kt2ts #Kotlin #TypeScript #dev #tools 🤔 第一次知道可以这么干
看来 ParserKt 的 Kotlin/JS document 要靠这个人的实践经验了

#web #js #TypeScript #tool 过于生草😳

索引 slice (视口计算) 起来还挺麻烦的，开始用脑子都搞错了，亏了我的工程/调试经验…… 勉强试出来了 😥

老实说我对这个内带优化元素的特性本身认知都不明确，不过终于是写出来了

改日，这个项目会被重写打包成支持 ES5 的 Web Extension ，感谢 #TypeScript .

#TypeScript #parser 🤔lex-yacc 式框架... 但是感觉代码质量不过关啊，文档也没写

#Kotlin #coroutine 应该说有了可以挂起恢复的协程后， launch 里面的东西就可以理解为「被添加的Task」吧（此例只是闭包住了变量i），由线程(池)上执行的调度器来运行它们，类似于 event loop 这样

第一个 async fun delay 本身也是调度器操作，不是 Thread.sleep 不会休眠线程，是完全不同的概念，当然不会卡死调度器，举个例子：

var t0 = time(); var t1:Long
for (task in cyclic(tasks)) {
t1 = time()
if (task.delay>=0) task.delay -= (t1-t0)
else { task.run() }
t0 = t1
}

这个 launch 本身就是独立于 for (i in iprog) 顺序的，不是说得 i=9 的 launch 完了才能发 i=8 的，而 suspend fun() {} 的独立性可以理解为 #TypeScript 式的 async state machine 基本就是单独的闭包了，调度分次不会互相冲突。（或者根本是独立的程序流？）

https://lab.xecades.xyz/Fourier/?img=5
感觉自己的智商严重需要重构了…… 看了下基本绘制结构我明白了，当时找 img= 参数引用的时候想当然查 (n + 1) 这个表达式，三次没找到后才在已发现 loadPageVar() 后明白编号到零基数组引数是 -1，明显没过脑子（或者记性不好/数性太差），就凭这？心理各种崩溃。

是用 setInterval (timer) 累积dt 更新的(缺点 dt 是常量)
generate(t) 基于 getSvgInfo() (load onto <svg> tag)和 getDotInfo() (use style "offset-distance"&canvas.origin)
整体代码质量较好，非常简短而整洁，建立了 Axis 和 complex 的 class，helper(common abst.)/canvas/main logic 三文件符合拆分直觉，命名和算法封装方式偏 C 化（静态指定子程序输出的目标存储空间，对应其参数也是写死的；即便程序生命周期仅调用一次）

待会重构下（也只能是拿 #TypeScript 了），算是安抚可怜的我…… 😭

呃… 昨天晚上半天没睡着，想了一下，记得当时的优化是解决尾递归(当然是 js 层的啦)问题，避免用递归实现(REDO 的)循环，这算是必须的基础算法的优化了。

也就是说，计算器目前的性能应该还有问题，每执行一个操作都要操纵 DOM 两次(单击、读写...)。
本来还想 #TypeScript 重写，突然发觉好像已经是 TS 了……
我要写的绘图暂时还不打算支持自定义表达式或关系式(特指我亲自编写解析器的版本,本来是早有设计打算的)，只能线性 evaluate(x) 来求值

如果现在要实现 evaluator(no) => (x) => ，显然是要把 x 放到 <input> 里，调用内部 redo(no) 函数... (否则就要用 DRedo，这个计算机本身有点像错误设计的虚拟机，寄存器不够，控制指令全是零地址)
如果要手工计算一批数据倒还无所谓，用来绘图显然是太草了

我觉得，大概可以把 (a,b)=>a+b 这些基础函数暴露出来，让 DOM 监听自己再去组织，然后通过这个的一部分(+-*/ 什么的) 制作一个 {} 和一个 [] ， evaluator 里用 {} 去给指令编址，执行时只需一个 accumulator = 0 就够了，都是 acc = ops[opcode](acc, b) 的形式
如果出现不支持的指令，就同步 acc 到 DOM 再用 DOM 的方法去点击(协处理器)

—
关于 canvas 绘制的方法我觉得现在就可以探索
设计时大概需要这几个参数：
[x] axis [x] legend [ ] grid [ ] points
mutable: step, vp_xy, scale_xy
immutable: descPosneg, range, valueRange

真想用中文命名算了（草

#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 重写

#TypeScript #lib #doc https://util.liuli.moe/@liuli-util/async/ 有一大堆 concatMap, debounce, wait 等操作的 async 组合库

https://util.liuli.moe/@liuli-util/array/ 包含 swap, groupBy, segment(即 chunked), diffBy, uniqueBy 等处理函数 ，还有 arrayToMap(即 associate)
https://util.liuli.moe/@liuli-util/string/#StringValidator.isEmail 非常实际的一个值验证
https://util.liuli.moe/@liuli-util/dom/ 包含一些下载 ArrayBuffer 之类的处理，不过没有复制到剪贴板的

https://util.liuli.moe/@liuli-util/other/#EventEmitter EventTarget 一类对象实现
https://util.liuli.moe/@liuli-util/test/#countTime 这个就是 measureTime { } ，要是能写成 Python timeit 的形式就好了
此外还有 tree 库，支持 treeEach 后序遍历树结构，treeToList (即 flatten , 还有 treeFilter 的变体)

#web #js #typescript #Microsoft 最知名 Web 代码编辑控件 Ace(ajax.org Cloud9),Monaco(which powers VSCode) 二者之一， https://microsoft.github.io/monaco-editor/
js,ts,clojure (一个 #functional JVM 语言) 的示例都是 Conway's game of life (当然已经82岁的他已死于去年的新冠) 😋 #listing #ce #tools

https://t.iss.one/mokeyjay_channel/1941 的 github1s.com 用 GH API 下载仓库，即可在用虚拟文件系统的 VSCode (fork ver.) 中打开
对喜爱自定编辑器和编程展示的人 必须了解一下

相关代码：
workbench/contrib/welcome/page/browser/welcomePage.ts#L75 下载
code/browser/workbench/workbench.ts#L403 打开文件夹
extensions/github1s/src/github1sfs.ts#L175 下载插件支持 Unicode

#gui #web #design #tools #TypeScript https://github.com/meetalva/alva
大概是 Electorn 的 form/ui 可视化设计工具，支持引入外部库(可能类似 HBuilderX 什么的 但界面好看许多)

#rust #nodejs #TypeScript https://github.com/denoland/deno#deno 有两年的东西了， 看起来还挺好的，自带 deps 和 fmt 工具，便于安装

#web #js #dalao #friend https://www.yunyoujun.cn/posts/make-an-avg-engine/
我觉得这个大佬比较亲切，或许以后会有机会接触？ 🤔
动苏一贯喜欢风格清新、为人友善开放乐于表达的大佬

虽然看起来这个大佬还在发展阶段，相信我也有可以从中学习的地方
https://github.com/YunYouJun/advjs/blob/main/packages/parser/src/index.ts #TypeScript #parsing 这个大佬也有设计“基于 Markdown 的语言”的想法 😂

#typescript #parsing f<1 是 type error ，怎么可能视为 , 部分单独解析🌚

🌝 好了， pointermove (准确是 touchmove) 的方法找到了……
https://seoi.net/penint/ #nsfw #js canvas 绘画 然后分段渐渐变化 女性勿入。

和之前的傅立叶 https://t.iss.one/dsuse/15530 有异曲同工

duangsuse: #kotlin #typescript #plt
应该是kt的计划
我倒希望安卓写完web也能用（
go好像是tcp层的应用比较多，jvm都在http乃至data-json层

kotlinnative的gc模块体积应该降低了吧
总感觉不够取代C，尽管能充当FFI

反正 语言就是工具 好用就用 不好用就不用

kt敌手：groovy+jb家ide （不是

Go的协程讲真不如Kotlin设计的好

duangsuse:
和lua比呢
嗯对lua是多虚拟机协程，kt是编译期suspend fun

冰封说kt协程是基于cps（调用尾步骤编程）的，陈光剑的书也说ktcoro有 Continuation 的概念，可是我只懂typescript function* 的状态机化

说不定这俩就是一回事 俩名字，我只认 函数协程=闭包+指令位置保留

iseki
go天天吹协程，结果就拉成这个样子
坐等Kotlin解决下调用栈的问题（但估计解决不了）

duangsuse:
是啊有啥了不起的，lua openresty 不厉害吗

Science Yuan:
Cps是延续体传递，不是调用suspend时自动产生一个回调函数
然后调用栈就没了（渐渐远离调试

duangsuse:
当然不是，可也没更好的方式理解
毕竟不能说 1+2+yield 是函数

可es6里func*是不包含调用栈，只有闭包变量状态的；通过__awaiter 执行每个Generator对象

所以我觉得func*都可写成Iterator对象形式

iseki |
kotlin是通过ContinuationImpl执行的吧我记得
里面也是把层拆了，一层一层迭代来着，所以调用栈完全裂开