duangsuse::Echo
关于 Kamet 里 val/var 和 let 的区别,本来我的意思是要除掉 let 的,但它的语义也的确不同 最开始, Kamet 只有栈上局部变量 var 和 const var (即后来的 val) 后来 Mivik 可能是发现 fun add1(n:Int) { val res = n+1; return res } 完全不需要实际栈上分配而可以内联,于是又新加入了 let 看起来 var / val 和 let 是各司其职、其区分无可厚非,我相信这种做法仍是不好看的,并且 val 应该默认具有…
现在想来 Mivik 必须区分 val/let 的问题,除了局部 struct/array 分配的必要性,大概是对
这有关于 inline 开销——无论是先算完存下来(就必须在栈上分配),还是每次去算都好,该取最优化的结果;譬如
和函数的 inline 不同,因为
选择让用户决定无可厚非,但不利于代码的可移植性和语义泛用性,而且这样容易引起麻烦—— let 和 val 后面都可以跟任何表达式,但
其实 kamet 的处境也很麻烦——全部栈上吧,不知道 LLVM 是否会有优化(目前只已知 mem2reg 的 alloca 寄存器分配优化),不想分配多余栈空间
全部 IR 节点内联吧,如上例不科学;而自动选择是内联还是缓存变量, LLVM 貌似没提供(只有函数级别的内联开销,不适用)
所以就只好分出了 val/let ,当然我个人是拼命不会用这种做法的(我大概就会做成有 1 层计算
(xs.size-1) inline 还是局部分配计算&引用的问题。这有关于 inline 开销——无论是先算完存下来(就必须在栈上分配),还是每次去算都好,该取最优化的结果;譬如
xs.size 是 struct(named product type) 上的解指针,完全可以内联,而 x+1*2/3 这种复杂计算显然不应该到处内联;但开销除了计算量也是关于引用处的分数,譬如 val size = xs.size 解指针计算量小,但如果有许多引用则还是作变量缓存比较好。和函数的 inline 不同,因为
inline val lastIndex get() = size-1 是绝对的内联表达式,不会存栈帧局部分配。选择让用户决定无可厚非,但不利于代码的可移植性和语义泛用性,而且这样容易引起麻烦—— let 和 val 后面都可以跟任何表达式,但
let user = User() 接着 user.name = "wtf" 是有效的,但应该是不可行的;这会降低语言的一致性和安全性。其实 kamet 的处境也很麻烦——全部栈上吧,不知道 LLVM 是否会有优化(目前只已知 mem2reg 的 alloca 寄存器分配优化),不想分配多余栈空间
全部 IR 节点内联吧,如上例不科学;而自动选择是内联还是缓存变量, LLVM 貌似没提供(只有函数级别的内联开销,不适用)
所以就只好分出了 val/let ,当然我个人是拼命不会用这种做法的(我大概就会做成有 1 层计算
a.name 式的就内联,否则就局部分配的形式... 很反智,不知道有没有更好的方法https://github.com/JetBrains/kotlin/blob/master/compiler/backend/src/org/jetbrains/kotlin/codegen/FrameMap.kt 草,这个算局部表么…… Kt 的编译器好复杂,找不到它是咋用 JVM 栈的
https://github.com/JetBrains/kotlin/blob/master/compiler/backend/src/org/jetbrains/kotlin/codegen/codegenUtil.kt#L95
不过倒是找到了 is, as? 的生成代码…… 原来 Adapter 是这么用的草
https://github.com/llvm-mirror/clang/commit/3c1c202adacce7479418fdb83d8257e2d9e0f125
看不懂,但找到了许多冗余代码…… 不愧是 C++ ,不过我看 Kotlin 也没法规避更多的吧
https://github.com/JetBrains/kotlin/blob/master/compiler/backend/src/org/jetbrains/kotlin/codegen/codegenUtil.kt#L95
不过倒是找到了 is, as? 的生成代码…… 原来 Adapter 是这么用的草
https://github.com/llvm-mirror/clang/commit/3c1c202adacce7479418fdb83d8257e2d9e0f125
看不懂,但找到了许多冗余代码…… 不愧是 C++ ,不过我看 Kotlin 也没法规避更多的吧
GitHub
JetBrains/kotlin
The Kotlin Programming Language. Contribute to JetBrains/kotlin development by creating an account on GitHub.
https://lingdong.works/ #life #tech #cs 真的好无奈,这些前端类大佬,虽然并不真正了解你的领域,但基于数据结构算法的基础也可以轻松做一个能用的玩具出来,这能灵活利用他们的智商。
而且他们的行动力超强,即便是这种麻烦的设计,也是在他们眼中“不起眼”的小把戏,好打击自信呢。
而且他们的行动力超强,即便是这种麻烦的设计,也是在他们眼中“不起眼”的小把戏,好打击自信呢。
lingdong.works
Lingdong Huang
Projects by Lingdong Huang and collaborators.
#reveng 草,之前听到过,不过不知道可以动态 hook 各种函数…… 当时不理解它说的 "magic" 是啥玩意,我运行过测试但啥输出没有
Forwarded from dnaugsuz
人家都 root 了你对抗个毛啊…… 这里知道这个工具的人估计都少
去 StackOvf / Stack Exchange 或者 SegFault 什么的看看? 🤔
去 StackOvf / Stack Exchange 或者 SegFault 什么的看看? 🤔
我尝试着建模一下 Firefox 的 Copy Tab URLs 插件:
templates = {
"Markdown": "[%t](%l)"
}
function fill(text, values) { return text.replace(/%(\d+)/, it => values[it]) }
function copier(urls) {
return Object.fromEntries(...templates.map(it => [it, () => copy(urls.map(tl => fill(it, tl)).join("\n") ) ]) )
}
let ctxMenu = {}
browser.locationbar.contextMenu = ctxMenu
ctxMenu["Copy Tab URL"] = copier(() => browser.tabs.current.location)
const toURLs = (get) => () => [...get().map(it => it.location)]
ctxMenu["Copy Other Tab URLs"] = copier(toURLs(() => { let tabs = [...browser.tabs]; tabs.remove(browser.tabs.current); return tabs }))
ctxMenu["Copy Tab URLs"] = copier(toURLs(() => browser.tabs))Forwarded from dnaugsuz
说到区间我就想到之前写的 RangeMap (虽然不是
这个玩意是用 JDK collections framework 的 TreeSet 弄二分查找的,所以只有 jvmMain 有 TreeRangeMap 实现
kotlin.ClosedRange 开区间上的)这个玩意是用 JDK collections framework 的 TreeSet 弄二分查找的,所以只有 jvmMain 有 TreeRangeMap 实现
/** The greatest element in this set ≤ [target] */实现起来主要就一个函数,太草了
protected fun searchMaxLE(target: N): Ray<N, T>? = tree.floor(edgeAt(target))
protected fun edgeAt(start: N) = Ray.Blank(start)
GitHub
ParserKt/ParserKt
Naive one-pass recursive descent, scannerless parser framework for Kotlin - ParserKt/ParserKt
Forwarded from dnaugsuz
嗯,这个的确不好理解
就是假设把 0..1, 10..15 这些 Range 里的所有数各自映射到某个值的话,用
比如
然后查找法就是一条直线数轴, 所谓的 "Ray" 是其上的射线(右无端点),它的定义是由
数轴上有 Ray(pos, value) 保存值 和 White(pos) 标记左 Ray 结束 两种项,就构成了
就是假设把 0..1, 10..15 这些 Range 里的所有数各自映射到某个值的话,用
Map<Int, V> 实在是太浪费了,可以用特化的 RangeMap 比如
intRangeMapOf(7+1990..2020 to "🇨🇳")[2000] == "🇨🇳" 然后查找法就是一条直线数轴, 所谓的 "Ray" 是其上的射线(右无端点),它的定义是由
searchMaxLE (某点的最大左部值)确保的;这些 Ray 的 Comparable 实现也都是由其左端点 Int 值来代理数轴上有 Ray(pos, value) 保存值 和 White(pos) 标记左 Ray 结束 两种项,就构成了
TreeRangeMapForwarded from dnaugsuz
iseki 你这个 vert.x codegen 真的可有意思了,之前从没试过这个玩法……
Gist
codegen for vert.x eventbus on kotlin.
codegen for vert.x eventbus on kotlin. GitHub Gist: instantly share code, notes, and snippets.
Forwarded from dnaugsuz
感觉 Gradle 写死的 Kotlin 插件版本真是害死人,偶尔换个老的工作环境,忽然发现 Gradle configure project 卡死了…… 害得我以为 IDEA 不能用了,草生
现在基本记住 G:A:V, project, plugin, buildscript; repositories, dependencies, implementation=runtime, api=compile, task 之类的 Gradle 构造了,手写 buildscript 和用 shadow minize 也能行
不过一般都复制粘贴自己既有项目的,感觉这些结构真是无聊……
现在基本记住 G:A:V, project, plugin, buildscript; repositories, dependencies, implementation=runtime, api=compile, task 之类的 Gradle 构造了,手写 buildscript 和用 shadow minize 也能行
不过一般都复制粘贴自己既有项目的,感觉这些结构真是无聊……
dnaugsuz
感觉 Gradle 写死的 Kotlin 插件版本真是害死人,偶尔换个老的工作环境,忽然发现 Gradle configure project 卡死了…… 害得我以为 IDEA 不能用了,草生 现在基本记住 G:A:V, project, plugin, buildscript; repositories, dependencies, implementation=runtime, api=compile, task 之类的 Gradle 构造了,手写 buildscript 和用 shadow minize…
之前一直对 Gradle 的 module, project hierarchy 和 sourceSet, dependency scope 感到困惑 🤔
尤其是 Kotlin Multiplatform 可以用
突然明白过来,
尤其是 Kotlin Multiplatform 可以用
src/jvmMain/kotlin(java) 而不是 src/kotlin/jvmMain , 我就思量着是不是 SourceSet 可以嵌套……突然明白过来,
jvmMain 什么的其实是子 Module ,也就是和 rootProject 同样级别的东西,所以可以有 kotlin/ java/ 什么的…… 噢,,Forwarded from Solidot
Python 3.9 发布
Python 语言释出了 3.9 版本。从 Python 3.9 开始,项目从 18 个月发布一个大版本改为每年发布一个大版本。3.9 发布之后并不是 4.0 而是 3.10,Python 3.10 相对于 3.9 以及 3.9 相对于 3.8 都是渐进式改进版本。Python 3.9 的主要变化包括:新的字典合并操作符 | 和 |=;放宽对 Decorators 的语法限制;新的字符串方法 removeprefix() 和 removesuffix() 简化从字符串数据中移除不需要的前缀或后缀;新的解析表达式语法取代了 LL(1);类型提示泛型,等等。Media
https://www.solidot.org/story?sid=65730
Python 语言释出了 3.9 版本。从 Python 3.9 开始,项目从 18 个月发布一个大版本改为每年发布一个大版本。3.9 发布之后并不是 4.0 而是 3.10,Python 3.10 相对于 3.9 以及 3.9 相对于 3.8 都是渐进式改进版本。Python 3.9 的主要变化包括:新的字典合并操作符 | 和 |=;放宽对 Decorators 的语法限制;新的字符串方法 removeprefix() 和 removesuffix() 简化从字符串数据中移除不需要的前缀或后缀;新的解析表达式语法取代了 LL(1);类型提示泛型,等等。Media
https://www.solidot.org/story?sid=65730