owtotwo 最近的时间轴更新 owtotwo 最近的时间轴更新 | owtotwoV2EX 第 175996 号会员，加入于 2016-06-04 20:21:01 +08:00 |
owtotwo
| Python 3.12 稳定版发布啦，哪个改动最有吸引力？ Python owtotwo 2023 年 10 月 12 日 最后回复来自 akaHenry | 30 |
| Python 3.11 稳定版发布啦，速度提升不小 Python owtotwo 2022 年 11 月 25 日 最后回复来自 julyclyde | 47 |
| 经常能收到微软 Office365 相关的邮件(含 jnd/qun 字眼)，是什么新型骗术吗？ 问与答 owtotwo 2022 年 9 月 22 日 最后回复来自 qzwl | 5 |
owtotwo 最近回复了
2025 年 11 月 9 日 回复了 robinlovemaggie 创建的主题 开源软件 理性讨论一下：如何看待某些国产键盘商拿了 QMK 的开源授权却把驱动闭源的行为？ |
nuphy 不是因为这事 被喷了很久之后 才分开有线和无线两部分给固件了么 有线部分 fork 的 qmk_firmware 传到了 nuphy-src 的 github 上 蓝牙和 2.4G dongle 的只提供固件更新 至少这样确实遵守了协议(不严谨地说)
我只好奇 现在客制化圈子里 大家都知道 QMK 都知道 VIA 但那些卖套件的卖成品的宣传支持 QMK 的 VIA 的 连固件都不给 买了才给 via 的 json 文件 然而没看到有复数个用户或者博主去指责或者提一嘴这事 感觉好像大家心照不宣一样
QMK 开源了 强盗们抢 QMK 的东西 强盗们抢完拿去卖 诶他们做过的事他们清楚 一开源肯定被抢 然后更低价卖 哪个强盗愿意呢 我们的指责或者说那一(几)文 License 里的东西 对于他们来说根本就没有任何一点的代价需要为此付出
最后一看原来全都是强盗 装都不装了属于是
我只好奇 现在客制化圈子里 大家都知道 QMK 都知道 VIA 但那些卖套件的卖成品的宣传支持 QMK 的 VIA 的 连固件都不给 买了才给 via 的 json 文件 然而没看到有复数个用户或者博主去指责或者提一嘴这事 感觉好像大家心照不宣一样
QMK 开源了 强盗们抢 QMK 的东西 强盗们抢完拿去卖 诶他们做过的事他们清楚 一开源肯定被抢 然后更低价卖 哪个强盗愿意呢 我们的指责或者说那一(几)文 License 里的东西 对于他们来说根本就没有任何一点的代价需要为此付出
最后一看原来全都是强盗 装都不装了属于是
2025 年 10 月 29 日 回复了 falser101 创建的主题 Apple 求推荐 27 寸 4k 显示器 |
无脑 G27U 不喜欢再换 1500 同价位就那几个除了戴尔 s2725qs 飞利浦有 27E2N5900RW
2024 年 5 月 10 日 回复了 lijxse 创建的主题 硬件 请教键盘改键工具 via，能否完美修改 mac 的 F 功能区（Nuphy GEM80） |
最简化问题
先达成共识 看 nuphy 官网的宣传页面 https://nuphy.com/collections/keyboards/products/gem80 里面的图有标注键盘特色功能(主要是支持 qmk/via 以及有物理切换 Mac/Win 的开关)
我用的是 nuphy air60 v2 同一家的产品 理论上 qmk 固件的内容跟 gem80 应该是差不多的
Win 模式的默认层是第 3 层(0~7 共 8 层) 此问题不需要更多层 所以只考虑 mac 模式的层(即 0 、1 、2 层)
如果我没理解错楼主题意 即 nuphy gem80 默认的 mac 模式的默认层(0 层)的 F1~F12 默认是 mac 上的特殊功能 比如 F1 是亮度减(对应 via 的"Screen-" 在 SPECIAL 里) F3 是 task(对应 via 的"Mac Task" 在 CUSTOM 里) 单按一下 F2 就能亮度加 而 Fn+F2 键才是真正输出"F2"
但楼主希望 F2 键按一下就是"F2" 而非"Screen+" 反而 Fn+F2 键才是亮度加
Mac 模式下键盘上的 Fn 其实就是 0 层里(临时)切换至 1 层的 via 键"MO(1)" 按住切换后再按 F2 就是 1 层的 F2 键上的内容
*解：所以最直接解法就是 在原本默认没有动过 via 配置的初始情况下 将 0 层和 1 层的 F1~F12 直接一一对调 就完成楼主的需求了
补充：nuphy 因为比较往 Mac 用户上靠 所以连默认模式都是 mac 键帽图标也是 mac 的快截效果键(如 Mac Search 这个 F4 上的放大镜图标) 所以 CUSTOM 里也提供了多个 Mac 专用快捷键
另外 nuphy 的 via 就是 qmk 那个 所以能实现的效果很完整 加上对 Mac 的高适配 因此改键的自由度很高 基本你想实现的都能改(非常复杂的需要改 qmk 固件 但是应该是用不到的)
b 站搜一下 via 多层改键的视频就好了(比如 BV1jv4y1o7pk 或 BV1RV4y197s4)
先达成共识 看 nuphy 官网的宣传页面 https://nuphy.com/collections/keyboards/products/gem80 里面的图有标注键盘特色功能(主要是支持 qmk/via 以及有物理切换 Mac/Win 的开关)
我用的是 nuphy air60 v2 同一家的产品 理论上 qmk 固件的内容跟 gem80 应该是差不多的
Win 模式的默认层是第 3 层(0~7 共 8 层) 此问题不需要更多层 所以只考虑 mac 模式的层(即 0 、1 、2 层)
如果我没理解错楼主题意 即 nuphy gem80 默认的 mac 模式的默认层(0 层)的 F1~F12 默认是 mac 上的特殊功能 比如 F1 是亮度减(对应 via 的"Screen-" 在 SPECIAL 里) F3 是 task(对应 via 的"Mac Task" 在 CUSTOM 里) 单按一下 F2 就能亮度加 而 Fn+F2 键才是真正输出"F2"
但楼主希望 F2 键按一下就是"F2" 而非"Screen+" 反而 Fn+F2 键才是亮度加
Mac 模式下键盘上的 Fn 其实就是 0 层里(临时)切换至 1 层的 via 键"MO(1)" 按住切换后再按 F2 就是 1 层的 F2 键上的内容
*解：所以最直接解法就是 在原本默认没有动过 via 配置的初始情况下 将 0 层和 1 层的 F1~F12 直接一一对调 就完成楼主的需求了
补充：nuphy 因为比较往 Mac 用户上靠 所以连默认模式都是 mac 键帽图标也是 mac 的快截效果键(如 Mac Search 这个 F4 上的放大镜图标) 所以 CUSTOM 里也提供了多个 Mac 专用快捷键
另外 nuphy 的 via 就是 qmk 那个 所以能实现的效果很完整 加上对 Mac 的高适配 因此改键的自由度很高 基本你想实现的都能改(非常复杂的需要改 qmk 固件 但是应该是用不到的)
b 站搜一下 via 多层改键的视频就好了(比如 BV1jv4y1o7pk 或 BV1RV4y197s4)
2024 年 3 月 26 日 回复了 studyingss 创建的主题 Windows 同屏幕下对比， windows 的字体渲染确实比 macos 差很多 |
对比字体渲染效果 不是应该
相同字体(如小米字体 MiSans 俩系统都改字体)
相同网页(或能调排版的软件)调好 css 字体参数(大小间隔字重等等)
同一屏幕下(24 寸 4k 苹果 hidpi 微软 200%缩放)
用手机的微距镜头拍屏幕字体？(非截图)
把结果图放上来 一切不就清楚了
我对现今 macOS 了解不深 还停留在几年前的黑苹果印象 但当时就是同一屏幕下(24 寸 4k)双系统(虽然都是默认字体)
因为是普通 IPS 屏 没有 oled(紫边)或其他屏幕等像素排列之类的差异
感觉苹果 UI 很舒适很有设计感和整体性 但别人提到的字体渲染问题 我感觉两者都足够清晰锐利 没有字体边缘的各种问题(不过我更喜欢苹果默认字体)
(可能印象模糊了 但 Win10 的 1909 到现在 Win11 的 23H2 我感觉新软件的高分屏缩放导致的问题愈发减少了 至少现在很舒适)
所以我的个人浅显的主观结论是 Win 的 200%缩放下字体没问题 retina 级别屏下与 masOS 差异不至于有一眼的差距
相同字体(如小米字体 MiSans 俩系统都改字体)
相同网页(或能调排版的软件)调好 css 字体参数(大小间隔字重等等)
同一屏幕下(24 寸 4k 苹果 hidpi 微软 200%缩放)
用手机的微距镜头拍屏幕字体？(非截图)
把结果图放上来 一切不就清楚了
我对现今 macOS 了解不深 还停留在几年前的黑苹果印象 但当时就是同一屏幕下(24 寸 4k)双系统(虽然都是默认字体)
因为是普通 IPS 屏 没有 oled(紫边)或其他屏幕等像素排列之类的差异
感觉苹果 UI 很舒适很有设计感和整体性 但别人提到的字体渲染问题 我感觉两者都足够清晰锐利 没有字体边缘的各种问题(不过我更喜欢苹果默认字体)
(可能印象模糊了 但 Win10 的 1909 到现在 Win11 的 23H2 我感觉新软件的高分屏缩放导致的问题愈发减少了 至少现在很舒适)
所以我的个人浅显的主观结论是 Win 的 200%缩放下字体没问题 retina 级别屏下与 masOS 差异不至于有一眼的差距
2023 年 10 月 11 日 回复了 caobug 创建的主题 Rust RUST 所有权移动问题 |
@caobug #22
有讲清楚了就好 能对别人有帮助还是很开心的 : )
Rust 文章的话 不太好写 写起来时很难兼顾到不同熟练度的 Rust 小伙伴（主要还是我自己能力有限）
举个例子
就像一开始其实我想**直接**用 `while true {}`和`loop {}`为什么不一样 来解释这问题的（前者迭代 0+次 后者 1+次）
但是这样会引入题目中没提到的 while 语句 以及它们另外的差异（ loop-break <value>能返回值而 while 恒为`()`之类的） 最后还得再迁移到 for 语句来解释
这样就有可能将问题复杂化了 而如果跳过中间例子直接说“const_expr 在 borrowck 阶段不求值” 不熟悉的小伙伴有可能一下子转不过来
且问题涉及 if 语句 所以最后决定用`if false {}`作例子来渐进地解释 比较好理解
Rust 文章同理 讲一个点 从多浅讲到多深 我就有点犯难了
有的知识点实在涉及太多 比如 Pin 感觉没十几页纸实在讲不清楚 一想就头都大了 0.o
有讲清楚了就好 能对别人有帮助还是很开心的 : )
Rust 文章的话 不太好写 写起来时很难兼顾到不同熟练度的 Rust 小伙伴（主要还是我自己能力有限）
举个例子
就像一开始其实我想**直接**用 `while true {}`和`loop {}`为什么不一样 来解释这问题的（前者迭代 0+次 后者 1+次）
但是这样会引入题目中没提到的 while 语句 以及它们另外的差异（ loop-break <value>能返回值而 while 恒为`()`之类的） 最后还得再迁移到 for 语句来解释
这样就有可能将问题复杂化了 而如果跳过中间例子直接说“const_expr 在 borrowck 阶段不求值” 不熟悉的小伙伴有可能一下子转不过来
且问题涉及 if 语句 所以最后决定用`if false {}`作例子来渐进地解释 比较好理解
Rust 文章同理 讲一个点 从多浅讲到多深 我就有点犯难了
有的知识点实在涉及太多 比如 Pin 感觉没十几页纸实在讲不清楚 一想就头都大了 0.o
2023 年 10 月 11 日 回复了 caobug 创建的主题 Rust RUST 所有权移动问题 |
@DianQK #21
嗯呐 这个确实就是关键所在
若我没记错的话 似乎 rustc 的编译流程会有两次的常量折叠/传播 一次是在前端的 MIR 中 另一次是在后端如 LLVM 中
（好像是前端优化一次能降低给后端的 IR 代码复杂度）
MIR 中支持常量传播应该是比较早前的事了（或许有相关公告） 似乎是支持控制流的（代码可能在 mir 部分的 const_prop.rs ？文件名应该长得差不多）
但并不知道是否支持“消掉 if const_expr”的行为
（我不知道这种分支优化的术语应该是什么 死代码消除 Dead Code Elim ？或者是叫 Sparse Cond Const Prop ？中文可能是 稀疏条件常量传播 之类的 或许也不准确）
但比较尴尬的是 常量传播是在 MIR 的优化阶段进行的 而 borrowck 是在 mir-opt 之前进行的（如果我没记错的话）
所以正如老哥你所说的 常量传播时应该已经有借用检查了
（以及我感觉理论上应该确实是能在借用检查前算 const 的 就是不知道最终会不会增加 MIR 部分编译的总耗时）
编译流程层面的改动影响对 rustc 而言还是挺大的（如 Polonius 也只是 borrowck 部分的平替） 所以短期内可能不会有相应优化了（个人感觉 不知道目前有没有人提对应的 RFC ）
以上的话并不严谨 我也暂时没能去进行校验 或许会有些错漏或过时（记忆有点旧了）
有条件的朋友或许可以补充下相关链接~
嗯呐 这个确实就是关键所在
若我没记错的话 似乎 rustc 的编译流程会有两次的常量折叠/传播 一次是在前端的 MIR 中 另一次是在后端如 LLVM 中
（好像是前端优化一次能降低给后端的 IR 代码复杂度）
MIR 中支持常量传播应该是比较早前的事了（或许有相关公告） 似乎是支持控制流的（代码可能在 mir 部分的 const_prop.rs ？文件名应该长得差不多）
但并不知道是否支持“消掉 if const_expr”的行为
（我不知道这种分支优化的术语应该是什么 死代码消除 Dead Code Elim ？或者是叫 Sparse Cond Const Prop ？中文可能是 稀疏条件常量传播 之类的 或许也不准确）
但比较尴尬的是 常量传播是在 MIR 的优化阶段进行的 而 borrowck 是在 mir-opt 之前进行的（如果我没记错的话）
所以正如老哥你所说的 常量传播时应该已经有借用检查了
（以及我感觉理论上应该确实是能在借用检查前算 const 的 就是不知道最终会不会增加 MIR 部分编译的总耗时）
编译流程层面的改动影响对 rustc 而言还是挺大的（如 Polonius 也只是 borrowck 部分的平替） 所以短期内可能不会有相应优化了（个人感觉 不知道目前有没有人提对应的 RFC ）
以上的话并不严谨 我也暂时没能去进行校验 或许会有些错漏或过时（记忆有点旧了）
有条件的朋友或许可以补充下相关链接~
2023 年 10 月 10 日 回复了 caobug 创建的主题 Rust RUST 所有权移动问题 |
@DianQK #17
或许有些区别
简单点概况，NLL(Non-Lexical Lifetimes)的迭代进化(即下一代的 Polonius)应该依然并不能解决此问题。
因为楼主这问题本质上是 rustc 编译流程的限制。如图： https://blog.rust-lang.org/images/2016-04-MIR/flow.svg
根据**目前**的编译流程，Borrow Checking 发生在 MIR 阶段，此刻的 CFG(Control-Flow Graph)仅将`if true {}`识别为`if some_cond {}`。
故而`if true { <code> }`无法等价于`loop { <code>; break }`或`{ <code> }`，因为它们的 CFG 是不一致的。（参考引用 数据流分析中的 CFG ）
最后将类似`if false {}`这样的死代码消除的优化行为，是在 LLVM 的 codegen 优化阶段进行的，所以此前 borrowck 并不认识"true"或"false"。
在 Rust 2018(Rust 1.31)引入 NLL 后，生命周期的推断精度更高了，而下一代的 Polonius 会支持更复杂的控制流(Control Flow)。但是如上所述的原由，依然不能在此阶段进行条件求值，所以问题依在。
* NLL: https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-2018.html#non-lexical-lifetimes
* 编译流程中的 MIR: https://blog.rust-lang.org/2016/04/19/MIR.html
* 数据流分析中的 CFG: https://github.com/rust-lang/rustc-dev-guide/blob/master/src/appendix/background.md#what-is-a-dataflow-analysis
* rustc 概览(包含各编译阶段): https://rustc-dev-guide.rust-lang.org/overview.html
我希望能由浅入深解释问题，但无法太深。前面的回答并无涉及到更多的编译器部分的具体内容，是因太冗长容易导致阅读阻力大，很少人愿意认真看(完)。（但即使现在这长度，似乎大家也习惯 tl;dr 了）
希望我有解释清楚。 : )
或许有些区别
简单点概况，NLL(Non-Lexical Lifetimes)的迭代进化(即下一代的 Polonius)应该依然并不能解决此问题。
因为楼主这问题本质上是 rustc 编译流程的限制。如图： https://blog.rust-lang.org/images/2016-04-MIR/flow.svg
根据**目前**的编译流程，Borrow Checking 发生在 MIR 阶段，此刻的 CFG(Control-Flow Graph)仅将`if true {}`识别为`if some_cond {}`。
故而`if true { <code> }`无法等价于`loop { <code>; break }`或`{ <code> }`，因为它们的 CFG 是不一致的。（参考引用 数据流分析中的 CFG ）
最后将类似`if false {}`这样的死代码消除的优化行为，是在 LLVM 的 codegen 优化阶段进行的，所以此前 borrowck 并不认识"true"或"false"。
在 Rust 2018(Rust 1.31)引入 NLL 后，生命周期的推断精度更高了，而下一代的 Polonius 会支持更复杂的控制流(Control Flow)。但是如上所述的原由，依然不能在此阶段进行条件求值，所以问题依在。
* NLL: https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-2018.html#non-lexical-lifetimes
* 编译流程中的 MIR: https://blog.rust-lang.org/2016/04/19/MIR.html
* 数据流分析中的 CFG: https://github.com/rust-lang/rustc-dev-guide/blob/master/src/appendix/background.md#what-is-a-dataflow-analysis
* rustc 概览(包含各编译阶段): https://rustc-dev-guide.rust-lang.org/overview.html
我希望能由浅入深解释问题，但无法太深。前面的回答并无涉及到更多的编译器部分的具体内容，是因太冗长容易导致阅读阻力大，很少人愿意认真看(完)。（但即使现在这长度，似乎大家也习惯 tl;dr 了）
希望我有解释清楚。 : )
2023 年 10 月 8 日 回复了 caobug 创建的主题 Rust RUST 所有权移动问题 |
FIX: @buxiuxi 第 9 项忘 at 了
2023 年 10 月 8 日 回复了 caobug 创建的主题 Rust RUST 所有权移动问题 |
2023 年 10 月 8 日 回复了 caobug 创建的主题 Rust RUST 所有权移动问题 |
续上
3. 对于 Code 3 ，即楼主的第一次修改尝试，实际上等价于将 loop 和 break 去掉（因为此控制流总是执行），所以必然会执行赋值语句，故而编译通过(Ok)。
4.对于 Code 4 ，即楼主的第二次修改尝试，依然可以将 loop 和 break 去掉，此时情况等价于 Code 0 ，所以一样是编译不通过(Error)。
5. 对于 Code 5 ，即 @Kaiv2 提到的编译成功的写法，因为 break 进去 if 里了，情况就不一样了。此时控制流的逻辑只有两种情况：情况一，若不进入 if 语句里，则无限循环，那么就不会执行后面的使用 person 及 person.dog 的代码了，就没问题；情况二，进入 if 语句，则成功执行赋值，且最后必定 break 出去，执行后面的代码，依然没问题。所以这种不涉及对具体求值有依赖的控制流是能编译通过的。
3. 对于 Code 3 ，即楼主的第一次修改尝试，实际上等价于将 loop 和 break 去掉（因为此控制流总是执行），所以必然会执行赋值语句，故而编译通过(Ok)。
4.对于 Code 4 ，即楼主的第二次修改尝试，依然可以将 loop 和 break 去掉，此时情况等价于 Code 0 ，所以一样是编译不通过(Error)。
5. 对于 Code 5 ，即 @Kaiv2 提到的编译成功的写法，因为 break 进去 if 里了，情况就不一样了。此时控制流的逻辑只有两种情况：情况一，若不进入 if 语句里，则无限循环，那么就不会执行后面的使用 person 及 person.dog 的代码了，就没问题；情况二，进入 if 语句，则成功执行赋值，且最后必定 break 出去，执行后面的代码，依然没问题。所以这种不涉及对具体求值有依赖的控制流是能编译通过的。
Select Language