duangsuse::Echo
713 subscribers
4.24K photos
127 videos
583 files
6.46K links
import this:
美而不丑、明而不暗、短而不凡、长而不乱,扁平不宽,读而后码,行之天下,勿托地上天国。
异常勿吞,难过勿过,叹一真理。效率是很重要,盲目最是低效。
简明是可靠的先验,不是可靠的祭品。
知其变,守其恒,为天下式;穷其变,知不穷,得地上势。知变守恒却穷变知新,我认真理,我不认真。

技术相干订阅~
另外有 throws 闲杂频道 @dsuset
转载频道 @dsusep
极小可能会有批评zf的消息 如有不适可退出
suse小站(面向运气编程): https://WOJS.org/#/
Download Telegram
#CG #cv #DontKnow #cs encoding
Forwarded from &'a ::rynco::UntitledChannel (Rynco Maekawa)
BlurHash: 用于占位符的图片摘要算法
https://blurha.sh/
#GUI gnome Widget factory (草
#nlp #English 词根(噢不 是 原型)提取
Forwarded from Phonograph (Ralph 萌新喵)
顺便,介绍一种看起来算是高效的词干提取算法:
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 了一下(草
Forwarded from Yuuta 🎀 | clrd enroute
每次看到「lo 裙」「lo 娘」都想到 loopback。
Forwarded from Indian Summer
看到一个 4000 行的 PR,点到 files 里发现 package-lock.json 改了 3900 行.....
duangsuse::Echo
#js #html duangsuse: 对了 L , chrome.runtime.postMessage 的 content/page script 独立你是怎么做的,那个是送信 JSON 一样对吗 duangsuse: 很多事情了…… 主要是 html 的 头很晕,任务队列越来越长,可能马上就要做不到了 一些是对 DOM API 的一些是对数据绑定的,还有几个动画的…… 总之就是非常令人没得话说 duangsuse: 不知道你有没有用到,有人专门做了什么 MessageManager 来弄这个搞得心态有点浮…
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 「归纳」就是指把一个序列总结出一个值,当然归纳出另一个序列也可以