#nlp #English 词根(噢不 是 原型)提取

顺便，介绍一种看起来算是高效的词干提取算法：
https://tartarus.org/martin/PorterStemmer/def.txt
截图中展示的是其较为重要的一部分。

#Telegram #web 可以举手了 🌚

telegram更新：
1.数百万的听众可加入的群语音
2.群语音可录制，录播客神器
3.举手功能，和clubhouse类似

都是抄clubhouse，telegram就能搞得清新脱俗，这每项都是成本啊，杜洛夫真的厉害，希望telegram早日能变成盈亏平衡的app，我也愿意贡献绵薄之力
https://t.me/durov/154

Telegram 的 data export 真是太方便了，支持选择 HTML 或 JSON ，支持选择消息区间和 Audio,Video 等类型过滤；支持后台操作 😋
和它即时发布编辑后直接预览的功能一样，业务流设计得真的很厉害

可惜能预览进度却不能跳过部分文件的下载 😢

#bilibili #cg #js B站《春》 的 .animated-banner 是个虽然主元素简单却很好看的动画，尤其是 x 滑动到一定位置渐变透明度的一层很巧妙。

尝试用 iframed = (ee,apend)=>{ let e=document.createElement("iframe"); apend(e); e.contentDocument.body.appendChild(ee); return e; }; ifr=iframed(document.body.querySelector(".animated-banner"), e=>document.body.appendChild(e)) 保存单个 DOM iframe 查看但是失败了（
调试器里 mousemove, setTimeout 都是 sentry 派发的，不好调试，img 的 Node attr modification 断点莫名没用

看 requestAnimationFrame 还是有了（ WebPack 的 source

webpack:///src/international-header/components/animated-banner/extensions/particle/index.js

太酷了！我喜欢，果然 x约束 透明度渐变层 有特别的计算处理 ，整体是靠 mouse deltaX 速率区别来移动的，而樱花下落的动画居然靠 webgl 渲染！难怪要设置一个叠层 canvas

估计延时重置视口的动画就是靠 cubic bezier ! 就是不太懂为什么要靠 filter scale rotate transform 来实现 img 的移动， position:absolute 不行吗

回头我移植一个独立的出来

#js #html
duangsuse:
对了 L ， chrome.runtime.postMessage 的 content/page script 独立你是怎么做的，那个是送信 JSON 一样对吗

duangsuse:
很多事情了…… 主要是 html 的
头很晕，任务队列越来越长，可能马上就要做不到了

一些是对 DOM API 的一些是对数据绑定的，还有几个动画的…… 总之就是非常令人没得话说

duangsuse:
不知道你有没有用到，有人专门做了什么 MessageManager 来弄这个搞得心态有点浮
你用过吗，有什么建议，比如(所用的等效) API 和 URL 上的

rxliuli:
毕竟这种 postMessage/onMessage 的 api 对于开发者很不友好

duangsuse:
我觉得很合理啊，就是 onMessage 可以封一下变成 await 而已
上次那个人直接是做成像 TCP 一样带 transfer num 的格式…… 真的有糊到我

duangsuse:
现在想想 pagescript send/on message 的是太灵活了，其实我就想加载个数据之类的，那么 req/resp C/S 模式就很合适
不然手写 send/recv 也可以但是不优雅，就是单向请求 设计上不可能反过来

#轻松一刻 #js 会不会只是 sort 了一下（草

每次看到「lo 裙」「lo 娘」都想到 loopback。

看到一个 4000 行的 PR，点到 files 里发现 package-lock.json 改了 3900 行.....

#reveng #security #tricks #cplusplus OpenSSL https bypass pin 证书的方法： https://t.me/yscschan/6950
X509_verify_cert() 永远返回 1
或者 ctx->app_verify_callback = []() ret true;

Jack Works:
我也造了轮子，很好用

duangsuse:
可以选择贴下代码

rxliuli:
不太喜欢这种 api 形式，而且文档有点麻烦，所以吾辈并未使用。。。

duangsuse:
估计它是方便 server-side push(不恰当比喻) 模式什么的，可是绝大部分插件根本不需要

Jack Works:
你可以来用我的 rpc 库，把它封装成 server/client 模式

rxliuli:
吾辈指的是 json rpc 的形式

更喜欢 server 实现接口，client 使用 proxy + 接口去调用

Jack Works:
封装的好谁管你底下跑的是什么。
你觉得我这种 API 设计怎么样？

我想问你对 async-call-rpc 的设计的看法

duangsuse:
https://github.com/DimensionDev/Holoflows-Kit/blob/master/src/Extension/MessageChannel.ts
的确有四百行

Jack Works:
还有一个必要的依赖，在同文件夹的 context.ts 里

rxliuli:
不太喜欢，尤其不喜欢 client 依赖于实现而非接口的行为

duangsuse:
server = AsyncCall({add:(a,b)=>a+b}, channel)
await server.add(2,50)
这样啊，看你代码挺多的， event Target/Emitter/Iterator 和 environment 都出来了, serialization 还是从两个 mod 里导入的

Registry 大概就是实现 onMessage 的地方，有 Bound, Unbound=Omit<Bound,"send">; Target 与否四个符号和一个 domainRegistry ，依赖 runtime.Port 在 L368 支持 background.js 有 runtime.MessageSender 的特例情况，再看看

Jack Works:
这只是在两端都在同一代码库内最方便的用法而已

我们也有那种和 native 端约定好interface 的那种用法

duangsuse:
我感觉不需要 close() 或者 cfg object 什么的，一个注册 onMessage 的函数可能就够了🤔…… 或是利用 object prop 提供服务名，两边统一下就够了
类似这样吧

function PortServer(port, table) {
if (!!table) { port.onMessage = (sender,[k,args])=>self.sendMessage(sender, table[k](args)) }
function get(self,k) { return (...args)=> port.postMessage(id, [k, args] ) }
return ReflectProxy({}, {get})
}
server=PortServer(mainPort, {add:(a,b)=>a+b})
await server.add(1,2)

基本上就是 RPC req-resp 配对下双工 socket 一样，当然 client side 的 queue 要做，需要三四行代码吧
呃不对，不能假定顺序是先调先返，所以还是要计 seq num 然后用类似 dict 模式的…… 明白了 😢
毕竟我没研究这个问题没法参照需求设计

Jack Works:
这是我按照我们业务需求设计的最适合的 API，让其他人可以自然表达自己的意图而不用去接触 chrome 底层的消息 API ，当然就是 req resp 配对一下了

duangsuse:
https://github.com/DimensionDev/Holoflows-Kit/blob/master/src/Extension/MessageChannel.ts#L296 你这里给一大堆可参数化的东西设计成了方法名 suffix 的形式，我也不清楚有什么亮点，大概是可以 on/off/pause()(reducer=xs=>xs/*all send*/) 和直接 send 吧（补充一句， T[]=>T[] 不叫 reducer (归纳是从 T[]=>R 多变1才对) ，可以叫 preprocess 或者 op(eration)

回头我设计完 LittleDict 有上下文了再来评价下...

Jack Works:
send* 那些是用起来方便而已，给常用的直接弄成方法免得再写 flag

duangsuse:
函数式里 reduce 「归纳」就是指把一个序列总结出一个值，当然归纳出另一个序列也可以

#Learn #OOP #js #design #Java #Kotlin
duangsuse:
大失败，不会写了；第一次还觉得需要 RingBuffer 或者双指针维护缓冲器那样……

其实根本没有那么麻烦， post 的时候带上 queue index ，全部完成右移视口 offset 就够了，如果没全完成右移也不行
简单设计复杂化

许久没有编程的动苏眼高手低到了这样的程度，不行，一定要写出来刚才那个的核心逻辑😡

……草，竟然真的可以用了，虽然没测试 原来 runtime.Port 真的像 channel 一样要 sender自己 onMessage 也能收到，所以要先 verify 吗

基础封装的逻辑就是封装 channel ， create server 可选， client 一定；兼容了 DOM postMessage API

假定 Function 的 que 无法共享，利用 seqNum (传输侧别名为 no) 指代响应目标，然后 que 本身利用 offsetL 压缩一下，不会一直增长
核心部分 20 行

仔细想想这个封装的确很有必要，总体 post/onMessage 请求一次 backend 是 callback(proc(msg)) ，C/S 两边都要 post,onMessage,msg,post 还难复用信道，call 了服务端处理完还要尝试按原名回调，容易重复标识符数据。

Jack Works:
来，把异常处理也加上

duangsuse:
Uncaught DOMException: The object could not be cloned.
不得不想序列化变形的办法…… 而且 JS 还是弱类型

好吧，好像需要一个完整的序列化方法，这个方法必须介入 sendMessage 数据来允许保留类型信息，如果不止要存留 Error message 的话 🌚

Jack Works:
到最后你会发现你重新发明了 JSON RPC

所以我把我的实现改造成了 JSON RPC 做成了通用的库

duangsuse:
serialize 本来就应该是框架层做的，而且它也只需要暴露 ser() deser() 两个函数而已
我们只不过应该在框架上写个十来行的小程序就够了

Jack Works:
我也是这么设计的啊， https://jack-works.github.io/async-call-rpc/async-call-rpc.asynccalloptions.html

duangsuse:
中国开发者越来越难了， github.io 都不能用了 #China #net #Freedom

以后写个软件第一关过政审第二关过苹果 Steam 的审，层层加码，服！

duangsuse:
累死了，反正能用就行
格局小了，我本来准备写 DOM 动画的，又鸽子了，再鸽就溢出了……

又到了各种 push 不上去的时间段，中国的网络环境。

Jack 那个我是真的摸不清，骨架太大了，重写人的脑力也是有限的(当然 typing 应该看得懂 就是各种 scope feature 看不懂)，知道 onConnect,disconnect 这些 API 也不好分析
不过好歹是能用一个，虽然肯定有性能开销了

Jack Works:
里面逻辑复杂但是外面接口简单啊

duangsuse:
动苏的标准是从内到外没有业务主干外的代码，如果有就作为插件嵌在骨干外…… 总之就是一句话，强调最根本最必须的算法 #statement

Jack Works:
你只要写一下怎么收发消息的逻辑，我这个框架就能 magically 跑起来

duangsuse:
所以说动苏的编程风格是函数式改 upvalue 而不是 class 属性，因为我强调算法先于架构

Jack Works:
动苏？啥玩意 = =

rxliuli:
你的中文昵称？

Jack 更喜欢在一个文件中编写多个 func，然后全部命名导出，吾辈更倾向于 class method 的形式

Jack Works:
我这个对 tree shake (webpack) 比较好🤔

duangsuse:
是的， duang 源于成龙洗发液的“头发动啊”，suse 是 Linux 发行，所以叫『动苏』😋 #life

动苏会觉得自称「我」或者「咱」(代替「我们」，我w键坏了) 有点生硬，这样就好很多

duangsuse:
这一点我还是倾向 Jack ，毕竟 Java 算是八股文式 OOP ，没有为实际编程有 toplevel func 样的优化

我可没说错话哦，面向对象的 class 本质是对函数式闭包加类型， property 即 upvalue ， method 即子程序化分段，整个对象即 send(name,args) 元方法，真正的面向对象只有「物/例」和其上的名词动词，没有文绉绉的废话甚至混乱 static。 #statement

面向对象把数据和其上操作混合定义是好事，可惜某些人就知道装B 起一大堆半通不通的专有名词，专业术语往往鬼用没得，给人们的思考造成一大堆麻烦。

要是 OOP 最初的作者能有半点实用化的觉悟，绝对不会放任 Jawa 混乱善良合理的编程习性

rxliuli:
但 Java 确实流行起来了而且基本被大规模实用了。。。虽然写起来确实感觉不太舒服，尤其是写过其他更好的语言之后

duangsuse:
所以说它才有机会被 Kotlin 吊打啊~
可惜 JavaEE 是他们自己搞出来自以为高明的八股文，很多 Kotliner 还没做好准备击败他们

CodeHz 📡:
(因为用类作为天然的命名空间分割函数的方法太好了（

duangsuse:
是的，构造器就像可覆写的一个局部变量初始化 header
然后整个类就像一个函数， constructor 提供了初始的变量混入

CodeHz 📡:
(oop 很好)就是无法自然的表达多重dispatch

duangsuse:
polymorphism 多态 不可以吗？

<就有个主次之分了，而且也不是运行时多态

运行时多态上 Sum type 可以 Visitor 啊，也挺方便的

<（有好几个参数需要动态分发的时候写起来还是挺别扭的

c 里搞 tagged union 到处 cast 就不方便吧…… 每个使用处都要检测 tag
请教下什么叫多派发啊

<大概就是这种（ https://en.wikipedia.org/wiki/Multiple_dispatch

C#是直接用动态运行时（DLR)了 #dotnet

类似 #Haskell 的 pat match 啊，那样 visitor 的确就不够了，得 trie 数据结构匹配...

非常疯狂，看起来 A.collideWith(B) 和反过来 B,A 是一样的

看起来是个非常有意思的特性，不过我感觉离算法/设计模式比 PLT 近些， visitor 单判定派发更实用一些

#endFork 关于 #JS 和 postMessage 服务化，以及 #typing 的一段讨论

#Linux #sysadmin unstable 化你的 debain-based 发行版！

用着新内核，属实舒服。

sed -i 's/stable/unstable' /etc/apt/sources.list