Hypercube's Channel

图 1 完全不如图 2 好吃🥲 品牌形象反面教材，同一个牌子、商品名主体部分完全相同，居然是配方完全不一样的两种东西。（这里区别应该在于图 2 是“汤好喝”这个子品牌下的）

Glory to Arstotzka!

音阶跑动实在练不好😅气到改成滑奏（是的我知道这个滑奏弹得也很糟）

这两天在玩 SpaceChem，和 TIS-100 有点像，都是并行的，都可以通过正好对齐周期数来节约同步开销，排行榜都分为周期数、节点数、指令数三个榜。SpaceChem 的代码阅读/调试体验比 TIS-100 好多了，但每关只支持保存一个存档，没法存储多个解法，坏。 视频为 Danopth（第 3 个星球）的 In-Place Swap 这一关只用 1 个 reactor 我能想出的最快解法。

看到这个讨论[1]，意识到有朋友可能还不知道：Python venv 会对所有安装到 venv 的 bin 目录的东西带上合适的 shebang，使得直接运行或软链接都能工作，不需要 activate venv。我觉得这样非常方便，已经很久没 activate 过任何 venv 了。 $ python3 -m venv path-to-venv $ path-to-venv/bin/pip install fava # 不用进入 venv，直接运行其中的 pip 就可以 $ ln -s path-to-venv/bin/fava ~/.local/bin/fava $ fava # 软链接也可以直接运行 [1]: https://news.ycombinator.com/item?id=45523767

有的论文用极其大量的矢量图形绘制散点图[1]，PDFium（pypdfium2、Chrome 内嵌 PDF 查看器）渲染这种情况时会消耗大量内存。MuPDF（PyMuPDF）没有此问题，虽然仍然要跑很久才能渲染出来，但使用的内存很少。 顺便一提，MuPDF 渲染线条时会做反走样，PDFium 则会至少渲染成 1 像素宽，因此生成的低分辨率缩略图很丑，需要渲染到高分辨率再手工缩小才好看。 [1]: 截图来自 arXiv:2401.00997v3

前天看维基百科，想学习一下什么是 drywall（干壁、石膏板），突然看到石膏的用途之一是“豆腐的凝结剂，膳食钙的重要来源”，意识到自己并不知道豆腐是怎么做的，于是学习了一番豆腐、豆干、豆皮、腐竹、豆腐乳等等食品的做法，感到非常神奇。 于是就想起来了以前在家里偶尔吃的豆腐乳（我家吃的是红方的，王致和的“大块腐乳”“玫瑰腐乳”皆为此方，但应该也有不少人常吃到的是白方的），遂网购一罐。下单时又看到王致和也生产臭豆腐（青方豆腐乳），想起来在维基百科上学习到这种臭豆腐和供油炸臭豆腐使用的臭豆腐干是不同的东西，我只吃过油炸臭豆腐，还没见过此物，就也买了一罐。 今天收到了，真是臭死了！还没打开就好臭啊！（商品介绍中专门说了，因为持续在发酵，会产生气体，所以发货时瓶盖只拧半紧，会有一些气体和汁水漏出来，我想是这导致没开罐就很臭了。）开始思考这个能生吃吗，我想就是应该生吃的，但它已经臭了！上知乎看看别人怎么吃，发现有人试图油炸（这个不能油炸的，和油炸的那种不一样），“家里就开始油炸屎了，锅臭了好几天”😂 我现在觉得说榴莲或者螺蛳粉像厕所炸了的人真的是什么都不知道，榴莲/螺蛳粉和这个比起来算什么啊。这么说吧，我觉得大家不会质疑榴莲/螺蛳粉已经变质了，但这个臭豆腐，我完全理解知乎上有人说直接就扔了。它！已！经！臭！了！（让我怀疑是不是变质了的食物除此之外可能只有豆汁）我觉得这是便携生化武器，投掷使用可能会很有效果。

和 @hejiyan 研究了一下 iOS 26 的 Safari/WebKit 的两个坑： 1. 在 https://t.me/SmartHypercube_channel/172 中我推荐了 text-wrap: pretty 这个 CSS 属性，标准是允许浏览器灵活实现的，但之前据我观察各浏览器都是很简单地通过提前换行避免最后一行只有一个字/词。WebKit 最近搞了一套更精致的排版算法[1]，打开 text-wrap: pretty 时英文排版确实更好一些（图 1：关；图 2：开），但中文排版会过早换行（图 3：关；图 4：开）。 paper.dou.ac 暂时改成了只给英文文本打开 text-wrap: pretty，以及给大段英文文本再加了个 text-align: justify，看起来好像不错。 2. 之前各移动端浏览器基本都有这个性质：网页可以简单地认为自己有一个（尺寸会变的）矩形画布，画布内没有任何遮挡/穿孔/灵动岛，画布外不会渲染任何内容（除非网页使用 viewport-fit=cover 等方式主动要求渲染到更大范围）。iOS 26 的 Safari 打破了这个假设[2]，使得排版时尺寸相关的一些概念复杂了，例如图 5 中一个 position: fixed; inset: 0 的框居然无法遮住背后的所有内容，上下会透出来。暂时改成了为背后的内容设置 visibility: hidden。 [1]: https://webkit.org/blog/16547/better-typography-with-text-wrap-pretty/ [2]: https://stackoverflow.com/questions/79753701/ios-26-safari-web-layouts-are-breaking-due-to-fixed-sticky-position-elements-g

玩桌游的时候总是怀疑我没把牌洗好，尤其是好几张特殊的牌聚在一起出现时。于是做了个能把随机排列转换成容易手工操作的步骤的工具： https://shuffle-helper.0x01.me/ 。 （有比手工执行 n 次“从第 x 叠取出第 y 张”更简单的方案吗？我也想了一些别的方案，比如限制每一步的格式都是“把第 x 叠的顶部 y 张挪到第 z 叠顶部”，这样每一步执行需要的时间应该会短一点点，因为从牌堆中间抽出一张比拿顶部的更难。但这个方案想实现随机排列需要的平均步骤数应该会更高。） （给定一个排列，从一叠开始，每一步都是“把第 x 叠的顶部 y 张挪到第 z 叠顶部”，经过若干步后变为给定排列的一叠，最少需要多少步？我怀疑这是个 NPC 问题😂）