kanakana

V2EX member #629909, joined on 2023-05-20 16:40:06 +08:00

Today's activity rank 5559

kanakana 提问技术话题好玩工作信息交易信息城市相关

Per kanakana's settings, the topics list is hidden

Deals info, including closed deals, is not hidden

kanakana's recent replies

Aug 26

Replied to a topic by tangler › 程序员 › 用 vscode 开发 Java 项目竟然这么煎熬吗

Vscode 有两个 Java 插件，一个微软自己推的，一个 Oracle 的。记得之前用的时候 Oracle 自家做的比微软的体验要好，不知道现在怎么样了。

Jul 1

Replied to a topic by xiaofangcode › 推广 › [bytecat]v 友赛博领鸡蛋 claude，新用户留言送 10 刀，十楼抽奖还送 10，中奖率 20%

ID: 2763
（一条五毛，括号内删除）（误

用了挺久，总之还挺稳定的（真的渠道出了问题的话也可以看到群里火急火燎在修
付费群里也经常发免费 key ，好用爱用

May 17

Replied to a topic by Karlbaey › 问与答 › 国内的企业是压根不在乎域名吗

@Magicdove 我才反应过来为什么饿了么把 Element UI 命名成 Element UI……

Feb 24

Replied to a topic by xiaofangcode › 推广 › 开工福利： Codex 免费蹬， Claude 低至 0.03 一次。助力 v 友开工

参与一下

Jan 19

Replied to a topic by zhouqian › 输入法 › 用这么多年的十指打字法，居然错误的

但其实看各种人体工学键盘的话，楼主的“错误”按法才是最符合人体工学的；反而标准按法会导致左手一直是扭着的姿势。

甚至 Colemak 配列就是为了应对传统键盘对左手的反人体工学姿势而专门有个 angle mod：

https://colemakmods.github.io/ergonomic-mods/angle.html

Dec 22, 2025

Replied to a topic by weiwenhao › 程序员 › Nature vs Golang: 性能基准测试

> Golang 采用了抢占式调度，不需要关注 GC safepoint ，但仍需要关注协程栈是否需要扩容。

> Nature 采用了协作式调度，所以需要处理 GC safepoint 。但 nature 采用共享栈协程，所以不需要关心栈扩容问题。

好奇问几个问题。从 Go 的源码注释 [1] 看来，Golang 还是有 safe-point 的，这里的“不需要关注”具体是指什么？如果 Go 用 safepoint 切协程的话是不是就与 Nature 比较相像了？

另外，Go “关注协程栈是否需要扩容”的另一个理由是：不同携程需要的栈大小不同，通过动态扩容我们可以先分配小的栈，再给需要的携程分配大号栈，从而节省内存。Nature 是怎么处理的？会有栈溢出吗？

[1] https://go.dev/src/runtime/preempt.go

Dec 12, 2025

Replied to a topic by movq › 分享发现 › 维基百科把 Google AI Overview 酸爆了

AI Overview 劝人吃石头补充维生素、胶水粘披萨也就一年前的新闻吧。去看了对应的页面，后面 Reception 和 Criticism and challenges 两节也给了更多的参考链接。你可以说 AI 发展迅速，维基可能有点过时，那你注册个帐号上去补充不就行了，没必要加戏。

Dec 4, 2025

Replied to a topic by guoguobaba › Python › 问个汉字处理的问题

@kanakana 等下弄错了，楼主的是 CJK RADICAL EAT ONE ，这个的确没有 compat normalization ，必须要 confusables 了……

Dec 4, 2025

Replied to a topic by guoguobaba › Python › 问个汉字处理的问题

还挺神奇的，U+2EDD （⻝）和 U+2F29 （⼩）都是康熙部首字符：

2F29;KANGXI RADICAL SMALL;So;0;ON;<compat> 5C0F;;;;N;;;;;

2FB7;KANGXI RADICAL EAT;So;0;ON;<compat> 98DF;;;;N;;;;;

UnicodeData.txt 里面也都相应标出了 <compat> 的分解形式：一个是 U+5C0F （汉字的“小”），一个是 U+98DF （汉字的“食”），但是它们 NFKC normalize 的结果却不同：

>>> f'U+{ord(unicodedata.normalize('NFKC', chr(0x2F29))):04X}'

'U+5C0F' (中文“小”）

>>> f'U+{ord(unicodedata.normalize('NFKC', chr(0x2FB7))):04X}'

'U+2FB7' (仍然是康熙部首“⻝”）

感觉会不会是 Unicode 的问题……但无论如何，要想手动 normalize 的话应该把 UnicodeData.txt 里面的第六列提出来也可以。但例如 Firefox 用的似乎是 confusables.txt [1]，比 UnicodeData 来说提供了更多基于字形的 normalization ，也可以考虑一下。

[1] https://github.com/unicode-org/icu/blob/main/icu4c/source/data/unidata/confusables.txt

» More replies by kanakana