Forwarded from Deleted Account
GitHub
ParserKt/ParserKt
Naive one-pass recursive descent, scannerless parser framework for Kotlin - ParserKt/ParserKt
Forwarded from Deleted Account
说起来，关于类似 Telegram bots 这样的东西，我想面向 1:1 关系/流程建模，而不是面向事件 handler/callback 建模
感觉还是不喜欢显式状态机/event handler query 的东西
有人有相关经验吗（哪怕是用闭包什么的）？
coroutine 会对这样的封装有帮助吗，要求支持最大 application scope 的状态
1:1 关系例如
感觉还是不喜欢显式状态机/event handler query 的东西
有人有相关经验吗（哪怕是用闭包什么的）？
coroutine 会对这样的封装有帮助吗，要求支持最大 application scope 的状态
1:1 关系例如
TimerMap<ID: Any> { fun createFor(id: ID, op: Comsumer<ID>) ; fun cancelFor(id: ID) }Forwarded from Deleted Account
感觉面向流程建模和面向 event+state 建模在设计直觉上也差不多的，就是 state 可能维护起来压力略大，不知道如果可以面向 procedure 本身建模，会不会在可维护性有提升
1:1 关系说的就是类似 Telegram bots 这种关于（用户上的状态）的 handler
1:1 关系说的就是类似 Telegram bots 这种关于（用户上的状态）的 handler
Forwarded from Deleted Account
想想 iseki 能随便 persistent 掉 Kotlin continuation，太dalao了 （
Forwarded from Deleted Account
感觉 OOP 的（单向）子类 extends 超类偶尔有点糊……
constructor 的 call-super 里不能用到 this，因为对象创建里每层架构器都要先调用 super 才能运行
有时候 override val 也不得不改成 fun。偶尔超类架构器用个闭包 hack 一下编程风格都提心吊胆，心累……
不过要是先运行子类 constructor 再运行超类就反了，而且「继承」的确是单向关系，不能循环引用……
constructor 的 call-super 里不能用到 this，因为对象创建里每层架构器都要先调用 super 才能运行
有时候 override val 也不得不改成 fun。偶尔超类架构器用个闭包 hack 一下编程风格都提心吊胆，心累……
不过要是先运行子类 constructor 再运行超类就反了，而且「继承」的确是单向关系，不能循环引用……
Forwarded from Deleted Account
其实这个也算是封装了一个基于状态机的 handler
我之前臆想的是类似 Kotlin/ES6/Python 的 await/async 的那种，显然单单 await/async 做不到良好处理这种本质是状态机的模式
看来仅仅用函数闭包也是足够的
sence greeter
onEnter = say "Hi"
onLeave = say "Bye"
onMessage = if (it.text == "hi") leave()
else it.replyWith("say hi") 我之前臆想的是类似 Kotlin/ES6/Python 的 await/async 的那种，显然单单 await/async 做不到良好处理这种本质是状态机的模式
看来仅仅用函数闭包也是足够的
Forwarded from Deleted Account
其实听开发 Kotlin 的朋友说，Telegram 的 Bots API 的 message variants 处理得也相当“动态类型”
弄得别人建模往往就只能判断 hasWtf 再 getWtf，没有子类型
弄得别人建模往往就只能判断 hasWtf 再 getWtf，没有子类型
Deleted Account
其实听开发 Kotlin 的朋友说，Telegram 的 Bots API 的 message variants 处理得也相当“动态类型” 弄得别人建模往往就只能判断 hasWtf 再 getWtf，没有子类型
我觉得这样的话干脆直接弄 flag 模式，containsAll 好了（笑）
ratio = 1.0
h, w = (img.h, img.w)
step_x, step_y = w//(ratio*w), h//(ratio*h)
for y in range(0, h, step_y):
for x in range(0, w, step_w):
xs = range(x, x+step_w)
ys = range(y, y+step_h)
onBlock((x, y), img.subimage(xs, ys))
onLine(y)
/tmp/duangsuse.sock
ratio = 1.0 h, w = (img.h, img.w) step_x, step_y = w//(ratio*w), h//(ratio*h) for y in range(0, h, step_y): for x in range(0, w, step_w): xs = range(x, x+step_w) ys = range(y, y+step_h) onBlock((x, y), img.subimage(xs, ys)) onLine(y)
……我不明白
(0, 0) (1, 0) ...(x, 0) 的顺序么
那么 for x for y 呢
那么用 comprehension 呢
那么左开右闭区间 有没有写错 overlap……
(0, 0) (1, 0) ...(x, 0) 的顺序么
那么 for x for y 呢
那么用 comprehension 呢
那么左开右闭区间 有没有写错 overlap……
Deleted Account
其实这个也算是封装了一个基于状态机的 handler sence greeter onEnter = say "Hi" onLeave = say "Bye" onMessage = if (it.text == "hi") leave() else it.replyWith("say hi") 我之前臆想的是类似 Kotlin/ES6/Python 的 await/async 的那种，显然单单 await/async 做不到良好处理这种本质是状态机的模式 看来仅仅用函数闭包也是足够的
用 user-session-wise state 也是可以的吧，每次判断 state 行事，然后 assign state = nextState(state)
fun onMessage(m: Message) {
if (state.predicate(m.text))
state = state.next
else state = State.INITIAL
}