焦虑园又来了

https://www.cnblogs.com/JulianHuang/p/14505857.html

#windows #android #sysadmin phone? 🤔

x86 模拟都出来了？！

#huawei #linux #android #embedded filesystem

#Kotlin #design 提问！怎么写 matcher 库呢？

你需要了解如何写可组合的操作，这里是 predicate: (T) -> Boolean ，当然实际上必须维护可阅读的结果报告(String path, Map mismatchs)

接着，考虑是 val 还是 fun，用不用 receiver 参数或带 receiver 参数的 Scope 闭包即可。

组合很简单，用函数的闭包(即 #OOP 对象)拼凑实际表达式
1.match { all(eq(1), lt(5)) } 其中 lt 是 lessThan 的意思。
const eq=a=>b=>(a==b), //lt也是一样模式，除了(b,a)=>(a<b)倒个语序
all=(...ps)=>x=>{ for(let p of ps) if(!p(x))return false; return true; }

咱可以看到，这个「高复用」办法本质只是在隐式化、拼凑参数罢了，其实 ==,!=,<>,in 等二元逻辑算符的引入都是预提供一个参数，等另一个参数 ，而 all, any, none (&|, !|) 则是在组合 Predicate 类型，用 for 循环解释 && 等算符短路(即惰性)求值的语义(any,all 等列表处理操作本是如此性质)。

当然，它们本身也是可被组合的，就像程序结构本身一样；但，原来十行代码的东西就只用写一行了，多快好省。

如果只是这样根本没必要单独开项目，反正计算开销小，可以取消 all 等组合器的部分求值，即便已知 mismatch 也只是存到一个结果报告(Map+path 足矣)里继续测试，这只需要让 all matcher 能知道自己的「路径」并且给子项们接上「新路径」。

只需把只能 apply() 的 function value 变成带构造器和 .var 的 interface ，在构造器里给子项进行 .path= 的「注入」隐式提供其路径，它之后的生命里全复用即可。
不过，这么一来就变成 interface Matcher { var name:String, fun test(x:T, m:Map<String,ErrMsg>) } 了，不需要给父组合器提示返回值了呢。
不过，这也照应了程序本身树穷尽遍历的性质，不再是逻辑表达式的「解释器」了。

#endFork #PLT #design 🌝 稍有常识的人不难看出，如果真的用解释器模式 sealed class {data class} + when is 递归 visit 数据节点来动态构筑程序流程的话，其上变换能力会进一步爆表，但是会麻烦些

https://t.me/Javaer/561972 #china #life

https://t.me/solidot/13743 好耶是 Ada 😋 #tech #life

#Java #statement https://t.me/Javaer/561982 但是大佬还是大佬呢
不过即便大佬很大佬，我也会向着既定的目标前进；对自己重视的东西我是有绝对的自信的。
我要扼住命运的咽喉，使它不能阻止我交易

https://t.me/c/1177099937/6456 #ai #轻松一刻

#Python https://github.com/tiangolo/fastapi#example-upgrade doc generator Swagger (笑) 👌

不知道从什么时候开始我懒得看 fast 一词了，你们随意。 🌚 1k forks ，真够的

#日常精神分裂 #DOM #game #js
A: 你看到了吗，那个从视口顶部丢球球下来，像俄罗斯方块一样的球碰撞游戏，是叫合成大西瓜来着
B: 那是个逻辑相当简单的游戏，也看见有三四个人做了翻版（奥利给等），如果按环节重复、更新规则、动画细节三项而言，细节不超过六个
A: 如果我们利用 canvas 做碰撞检测复刻一个，你觉得怎么样？整个绘制只有 Ball(p,r) 一种类型两个参数！简直和只有 fillRect 的贪吃蛇一样简单
B: 和 web asteroids 的 doc.elementFromPoint 不一样-_-|| 这次要手写 2D 游戏引擎碰撞检测部分，除了基础的加速度和碰撞方向检测；老实说都是数理密集算法
A: (不考虑与边界矩形的碰撞)我想到了三种方法做纯圆球的碰撞检测，首先是遍历球表算距离……
B: 没用！这样相当于每个配对你都要检测一次，要知道这个游戏后期会有 20 来个的，为保证不穿模，每一帧都计算？！
A: 那我参考整体动量，间隔毫秒或者帧号判断呢？
B: 都说了会穿模了
A: 第二种方法，参考物体的运动方向延长线，看交点，每对 ab,ba 缓存下只算一次
这种方法也可以用来优化一个物体不动的碰撞，或可预判碰撞发生时间，有变再 cancel 重算
B: 好啊，你怎么取射线和圆的交集？
A: 第三种方法，其实理论上只有画特效需要用到 canvas ，其它的尽量用 DOM 元素，就可以利用浏览器的既有算法，我知道有个 Element.nearest(selector) ，这样每对物体检测一次 d(p1,p2)<(r1+r2) 就够了；对边框是特例，只要对所有物体增加 x,y in clientRect.innerDist(r) 就可以了
B: 是个可取的方法，你不会用框架吗，整个游戏只有 ellipse collision 和 gravity 、force ，再简单点就只有放球和贴图，碰撞只是换贴图+增长，球与上框碰撞结束而已。
A: 嫌大了。 DOM 已经足够强大，何须更多修饰？ 高射炮打蚊子

B: 好了，谈谈复用问题吧，假设你不用框架，却又写了个用途单一的正圆碰撞检测算法…… 我猜测应用部分是这样的：

gameStart() = rateLimit(waitPutBall, 4000)
onEach(ball)
limitInRect(world.rect.innerMinus(ball.r), ball) // 模拟边框碰撞体
if ball.p.y<yTopline: gameOver()
waitPutBall()
ball = newBall(randPick(cfg.sizes), randPick(cfg.colors))
ball.y = yTopline; ball.g = cfg.weight
onmousemove = ev=> ball.x=ev.x
onmousedown = ()=> world.attach(ball) // 球开始下落
onCollide(a,b)
a.r += b.r
a.onChange()
b.remove()

gameOver() 的条件也可以换成在放球和最近球的碰撞检测 避免每个都判断

A: 我相信关于代码复用和框架组织，咱会有办法的！

https://leaky.page/memory.html #security Chrome Uint8Array (ArrayBuffer 系 API) exploit PoC

#rust #parser 普通的 Lex/Recurive 流解析器，分词靠 regexp，中缀优先级分左右，Lua 模式；最后教了 Scheme 的 s-expr 解析