新世界的大门

今天我写日报

2026-03-30T16:26:24.801Z

今天，我安装ArchLinux^[sic]，我配置安全启动……。我做饭，我吃。……我安装学习配置了rime^[sic]输入法，我分析了笔记本耗电的原因，我反思台式机功耗。

今天，我看到了梓yau谷里形如上文的流水账。我一下就想到了始作俑者 Wandai Blog，但用丑搜搜索“Soha”才找到。

回首博客首页，我的《自新世界》“周报”又有好久木有写了；运行博客程序，居然提醒我有一个大版本：New version of Astro available: 6.1.1。

我觉得这种方式比较好，也不会有输出的压力。因此，今天我写日报。

由于同时操作 4 台灵车设备非常麻烦，我让特工们代我 ssh 到其他机器上运维。我不愿意设置 ssh key，特工卡在了输入密码上；又尝试用 Python 那个我打 CTF 用过的库，但是这倒头库在我的倒头 Windows on ARM 上装不出来。最后，我乖乖地设置了 authorized_keys。

我让手机更新了最新的花粉 Beta 版本。我变成 pollen。我增加了智慧。我打开设置里的开关，看见鸿蒙玻璃材质了。必过，底部 navbar 变得十分窄。

以前的同学展示其每日健身的记录。我发给他看了看我的踩箭头的记录，我选的运动是其他舞蹈，被嘲讽了一番。自然，半个小时都不到，不太可能有多大的运动量。不过，现在至少从尸体便乘僵尸了。循序渐进总归是好的。

是故我蹦跶。舞曲如下：

曲	名	区	星	评
`wdbssszd_2510`	我的悲伤是水做的	花式疯狂	4	长度挺短的
`qby_2301`	千本樱	花式疯狂	4	very ez, 下次别玩真花式了
`idol???`	アイドル	花式学习（竞速模式）	5	似乎在5星里不算难，只是斜角的比较紧促，常常有、、这种步伐

惊鸿一瞥：如何在鸿蒙上运行 Flutter Hello World

2026-03-16T09:52:58.704Z

配置 HarmonyOS SDK

本次安装在鸿蒙电脑的 Windows 迫真机上，即 Windows on ARM。GitCode 上给出了 macOS 的 instructions：

API18, deveco-studio-5.1 或 command-line-tools-5.1 (推荐使用5.1.0 Beta1或更新版本) 我安装了 DevEco Studio 6.0。

配置 Java17 实测不需要。

配置环境变量 (SDK, node, ohpm, hvigor)
export TOOL_HOME=/Applications/DevEco-Studio.app/Contents # mac环境
export DEVECO_SDK_HOME=$TOOL_HOME/sdk # command-line-tools/sdk
export PATH=$TOOL_HOME/tools/ohpm/bin:$PATH # command-line-tools/ohpm/bin
export PATH=$TOOL_HOME/tools/hvigor/bin:$PATH # command-line-tools/hvigor/bin
export PATH=$TOOL_HOME/tools/node/bin:$PATH # command-line-tools/tool/node/bin

但是，注意这个 sdk 不是你在 DevEco Studio 里手动下载的有版本号 15、18、21 之类的那个，而是 DevEco 自带的。在 Windows 上，你可以使用下面的：

$env:TOOL_HOME = "C:\Program Files\Huawei\DevEco Studio"
$env:DEVECO_SDK_HOME = $env:TOOL_HOME + "\sdk"
$env:PATH = "$env:TOOL_HOME\tools\ohpm\bin;$env:PATH"
$env:PATH = "$env:TOOL_HOME\tools\hvigor\bin;$env:PATH"
$env:PATH = "$env:TOOL_HOME\tools\node\bin;$env:PATH"

Flutter 仓

git clone https://gitcode.com/openharmony-sig/flutter_flutter.git

Flutter 官方说 build 时 Flutter version 靠的是 git 上的 tag，不能 shallow clone。如果你这么做了，请 git pull --unshallow，将浅克隆（depth infinite）转为完整克隆，拉取所有历史记录。

你可以参照我设置的环境变量：

# 依赖的缓存
$env:PUB_CACHE = "C:\Users\HongYunVM\Documents\temp\PUB"
 
# 拉取下来的 flutter_flutter/bin 目录
$env:PATH = "C:\Users\HongYunVM\Documents\flutter\bin;$env:PATH"
 
# 国内镜像
$env:PUB_HOSTED_URL = "https://pub.flutter-io.cn"
$env:FLUTTER_STORAGE_BASE_URL = "https://storage.flutter-io.cn"
 
# 鸿蒙化适配的 Flutter repo URL，这个官方文档上没设置
$env:FLUTTER_GIT_URL = "https://gitcode.com/openharmony-tpc/flutter_flutter.git"

构建 SDK

运行 flutter doctor -v 检查环境变量配置是否正确，Futter 与 OpenHarmony 应都为 ok 标识，若两处提示缺少环境，按提示补上相应环境即可。

仍然卡在了 flutter_flutter 出来的 SDK 的 version 是 0.0.0-unknown 导致 pub 没法正常 resolve deps。

尝试修改 Flutter 对于版本判断部分的代码，但还会在 pub resolve 依赖时卡住，即 pub 还会再次读取版本号。

解决方法是此时在已有 build cache 的情况下，编辑 bin\cache\flutter.version.json，将 frameworkVersion 和 flutterVersion 手动改为 "3.32.4"。

  {
-   "frameworkVersion": "0.0.0",
+   "frameworkVersion": "3.32.4",
    "channel": "[user-branch]",
    "repositoryUrl": "https://gitcode.com/openharmony-tpc/flutter_flutter.git",
    "frameworkRevision": "7c7de913d9ccbed777e06dc32dfe1056d495dd56",
    "frameworkCommitDate": "2026-02-13 09:56:53 +0800",
    "engineRevision": "8cd19e509d6bece8ccd74aef027c4ca947363095",
    "engineCommitDate": "1970-01-01 08:00:00.000",
    "dartSdkVersion": "3.9.2",
    "devToolsVersion": "2.45.1",
-   "flutterVersion": "0.0.0"
+   "flutterVersion": "3.32.4"
  }

创建工程

创建工程与编译命令，编译产物在<projectName>/ohos/entry/build/default/outputs/default/entry-default-signed.hap下。

# 创建工程
flutter create --platforms ohos <projectName>
 
# 进入工程根目录编译
# 示例：flutter build hap [--target-platform ohos-arm64] [--local-engine=<DIR>/src/out/ohos_release_arm64] --release
flutter build hap --target-platform ohos-arm64 --<debug|release|profile> [--local-engine=src/out/<engine产物目录> --local-engine-host=src/out/<engine host目录>/]

build 之后应该会提示没有配置签名，打开 DevEco Studio，按照正常鸿蒙应用的调试过程运行即可。

默认的 template 只能在 phone target 上运行，需要修改所有 **/module.json5（main/、ohosTest/）：

    "deviceTypes": [
      "phone", "tablet", "2in1"
    ],

自新世界 #0x1a：六十四分之一的 Visual Studio

2026-02-17T16:19:29.480Z

版权许可

本作品采用 知识共享署名—相同方式共享 4.0 国际许可协议（CC BY-SA 4.0 International）许可，阁下可自由地共享（复制、发行）和演绎（修改、转换或二次创作）这一作品，唯须遵守许可协议条款。

微软说，

Visual Studio 在具有 64 GB RAM 的 Windows 11 和具有 16 个核心或更高版本的 CPU 上运行最佳。它运行速度更快，并且比同一硬件上的 Visual Studio 2022 响应更快。

官方的解释是，这是为了方便开发者有理由向公司争取到更好的硬件。

我这台设备是工控机，4 GB 的内存，处理器则是 2020 年的赛扬 N5095，性能比绿镖上的还差些，只有 4 核。因此，这是推荐配置的。自然，不用再乘上，因为后者反而更像是负优化——而且也确实是的，因为这台机器看起来比我的笔记本更不拖泥带水。

这个设备定期读取串口，测量数据，然后显示在界面里。我的主要任务是修复这个设备上专用的陈年 MFC 程序无法长时间运行的问题。具体来说，在两三天后，程序会先弹出一个有程序名称的、空白的、MsgBox 大小的窗体，然后点确定就会 crash。一看到这个问题，我就想是内存泄露，虽然这么说可能是 hindsight。

代码自然是 GBK 的，甚至没有 formatter 的痕迹。我检查了一遍代码，没有任何在异常时弹窗的代码，即这个弹窗是 MFC 自己画的。代码中使用了 Windows 的临界区 CRITICAL_SECTION，是 Windows 的用户态 mutex，不过这些部分都没什么问题。让 Claude 审了几遍，只查出来几个无关痛痒的问题，比如判断 sleep 的 int 可能会溢出，但这个只会导致某一轮测量的间隔缩短。

x32dbg 调试

这个程序需要读串口，还用了厂家提供的 .h + 闭源 .dll，因此我需要在生产环境中调试。

由于一开始实在是不想折腾开发环境，于是我在现场环境中，先是安装了 x32dbg 企图找到点什么线索。然后成功捕获到一次异常。异常发生时，调试器停在了 RaiseException 和 _CxxThrowException 上，同时还有 ERROR_NOT_ENOUGH_MEMORY 和 STATUS_NO_MEMORY。这说明程序是在某次内存分配失败之后，通过 C++ 异常机制被抛了出来。

工作集（内存）：5,324 K
峰值工作集：753,552 K
提交大小：1,857,512 K

32 位进程默认用户态地址空间通常只有 2GB，Commit size 1.77GB 对 32 位进程来说很危险了。

Registers

寄存器状态转储中，关键的是：

...
EIP : 75670F62     kernelbase.75670F62
EFLAGS : 00000212
...
EBP : 07ECBA3C
ESP : 07ECB9E0
...
LastError : 00000008 (ERROR_NOT_ENOUGH_MEMORY)
LastStatus : C0000017 (STATUS_NO_MEMORY)
...

Log

线程 1596 已创建，入口：wer.6C853F70，参数：2DB43178
线程 1596 退出
EXCEPTION_DEBUG_INFO:
           dwFirstChance: 1
           ExceptionCode: E06D7363 (CPP_EH_EXCEPTION)
          ExceptionFlags: 00000001
        ExceptionAddress: kernelbase.75670F62
        NumberParameters: 3
ExceptionInformation[00]: 19930520
ExceptionInformation[01]: 07ECBA84
ExceptionInformation[02]: mscorwks.6FA04588
第一次异常于 75670F62 (E06D7363, CPP_EH_EXCEPTION)！

Call Stack

栈回溯中可以看到——

线程 ID     地址       返回到      返回自      大小  方    注释
2528
          07ECBA40 74BA8E89 75670F62 38  系统模块 kernelbase.RaiseException+62
          07ECBA78 6F7C7550 74BA8E89 50  系统模块 msvcr80._CxxThrowException+46
          07ECBAC8 6F757C46 6F7C7550 30  系统模块 mscorwks.LogHelp_NoGuiOnAssert+24D
          07ECBAF8 6F5BF2AE 6F757C46 68  系统模块 mscorwks.LogHelp_TerminateOnAssert+3F32
          07ECBB60 76F46F5C 6F5BF2AE EC  系统模块 mscorwks.StrongNameErrorInfo+7DCA
          07ECBC4C 6EFFB1EB 76F46F5C C4  系统模块 ntdll.RtlAllocateHeap+109C
          07ECBD10 007D4987 6EFFB1EB 4   用户模块 mscorlib.ni.6EFFB1EB
          07ECBD14 007DE6EA 007D4987 4   用户模块 [数据删除]e.007D4987
          07ECBD18 007DE6F4 007DE6EA 4   用户模块 [数据删除]e.007DE6EA
          07ECBD1C 00000000 007DE6F4     用户模块 [数据删除]e.007DE6F4
604 - 主线程
          006FF5BC 6FD1E53E 74D8106C 48  系统模块 win32u.NtUserGetMessage+C
          006FF604 6FCFB9A4 6FD1E53E 4C  系统模块 mfc90u.Ordinal#1161+1A
          006FF650 007D4578 6FCFB9A4 4B8 用户模块 mfc90u.Ordinal#2208+12A
          006FFB08 6FCEAEC6 007D4578 14  系统模块 [数据删除]e.007D4578

栈里出现了 mscorwks 和 mscorlib，看着像是 .NET CLR 参与了调用。主线程停在消息循环中，说明 crash 并不是 UI 逻辑主动触发。

配置开发环境

为了调试和修复这个问题，我需要在工控机上配置一个开发环境。机上已经有一份 VS 2008，惟点开后提示已经过期。从互联网档案馆上 VisualStudio2008_Collection 这个 item 里下载了一份 Visual Studio 2008 Standard Edition。安装的时候，为了节省空间，我只勾选了 C++ MFC 部分。然而，正是这个选择让我没有办法正常编译程序——生成时会提示找不到 cl.exe。查找了几天，才发现是因为由于 bug 还要勾选 VC# 才能装上：

微软怎么这么坏啊

StackOverflow 问题 error PRJ0003 : Error spawning 'cl.exe'，CC BY-SA 2.5，有 Cloudflare CAPTHCA，不建议人类和 agent 访问。

There is a bug in the Visual Studio 2008 Standard Edition installer. It does not install cl.exe if you only install Visual C++ but not Visual C#. To work around this you have to install Visual C# even if you do not need this.

查找纰漏

在 VS 上装了 wakatime 和 Github Copilot 扩展，虽然 Copilot 也不是很好用，没有 agent 模式。如果想要 apply 变更，只能手动点 diff 上的按钮，它的方法是让 LLM 生成一个编辑好的版本（这个是和 VS Code 上的一致的）。不过，值得赞扬的是，其界面都使用了原生控件开发。

初步检查了一遍代码，又发现了一些可能导致内存泄露的地方。比如，IP 地址只给了个 char[13]，正好够存 "192.168.1.xx\n"，多了都不行——配置是可以经用户输入改的。

改动后，我把程序的一些时间间隔之类的参数设置为很短的几秒，这样可以在正常调用设备库来 I/O 的情况下加快内存占用的复现。但是，过程中经常会弹窗停住，似乎是错误地 drop 了某些 MFC 的资源，会在 Debug 下触发内部的断点，非常烦人——我并不想调试这些可忽略的错误。之后的两三天都在尝试避免这个问题。最后发现，将 target 的 Debug 改成 Release 即可，同时并不影响正常的内存监控。

内存快照

开始运行后，右侧的 panel 里可以打开诊断工具，抓取快照，后面括号里的内容是与上一个快照相比的 diff。如果是第一行会变成 （不可用），并不是抓取失败的意思。

VS 这个诊断面板不知道是怎么搞的，内存那个图标在我点开后就会变成空白，但鼠标忽上去还是有值。

罪魁祸首

这个 GetSpectrumData 函数并没有要求我们传入一个 char*，所以其字符串显然是自行分配的，而我们每次将这个指针保存，读取解析后，在下一个循环又用新的返回值覆盖了上一个指针而没有 free。

跑了一周，不得问题。不过，弹出了一个 MsgBox，如下：

---------------------------
BackgroundDownload.exe - 应用程序错误
---------------------------
应用程序发生异常 未知的软件异常 (0xe0434352)，位置为 0x00007FFACC1EB699。


---------------------------
确定   取消   
---------------------------

微软怎么这么坏啊x2

吓我一跳，还以为又坏脱；查了查发现是 VS Installer 的问题。也许 VS 真的需要 64 GB RAM 才能正常运行吧。

数字图像处理ㅤ第十一章作业

2026-01-05T16:09:16.570Z

第 11 章形状表示与描述

教材P554页，第11.1题
1. 重新定义链码的一个起始点，以便所得的数字序列形成一个最小值整数．请证明该编码与边界上的初始起点无关．
  设链码．另选一个初始起点，相当于循环位移该链码．设循环左移位，得到链码
  重新定义链码的一个起始点，相当于将该链码循环移动若干位．假设最小数字为．循环左移位得到最小值；由于最小值唯一，所以将循环左移位得到．
2. 求编码10176722335422 的归一化起始点．
  编码 10176722335422 归一化后为01767223354221，起始点为原始链码的第2 个数字．
教材P554页，第11.2题
1. 如11.1.2节中解释的那样，证明链码的一次差分会将该链码关于旋转归一化．
2. 计算编码 0110233210332322111 的一次差分．
  故编码的一次差分为；用循环首差链码计算的一次差分为．
求图 1 中图形的链码、一阶差分、形状数和形状数的阶（起点在左上角，按照顺时针方向）．
图 1 形状
表 1 答案
教材P556页，第11.26题
一家使用瓶子盛装各种工业化学品的公司在听说您成功地解决了图像处理问题后，雇用您来设计一种检测瓶子未装满的方法．瓶子在传送带上移动并通过自动装填和封盖机时的情形如下图所示．当液位低于瓶颈底部和瓶子肩部的中间点时，则认为瓶子未装满．瓶子横断面的侧面与倾斜面的区域定义为瓶子的肩部．瓶子在不断移动，但该公司有一个成像系统，该系统装备了一个前端照明闪光灯，可有效地停止瓶子的移动，所以您可以得到非常接近于这里显示的样例图像图 2．基于上述资料，请您提出一个检测未完全装满的瓶子的解决方案．清楚地陈述您所做的那些可能会影响到解决方案的所有假设．
图 2 原图
假设
- 瓶子位置和尺寸一致：假设瓶子不倾斜，垂直位置和尺寸大致一致．
- 图片拍摄条件一致：假设拍摄条件一致，瓶子在传送带上的位置和角度相对固定．
- 灰度对比明显：假设图像中瓶子和背景有明显的灰度对比，能够通过二值化处理有效区分．
- 传送带速度合适、恒定：假设传送带的速度恒定，瓶子在传送带上的运动速度和方向一致，瓶子中液体不会摇晃．
- 整齐排列：假设瓶子在传送带上排列整齐，水平位置和大小差异不大，便于排序和检测．
方案
1. 图像预处理：读取灰度图像并进行二值化处理，将图像转换为黑白图，以区分瓶子和背景．
2. 形态学操作：对二值化图像进行形态学开操作，去除图像噪声，确保瓶子轮廓清晰．
3. 连通分量分析：使用连通分量分析技术检测瓶子位置，计算各瓶子的统计信息，如面积和位置．
4. 液位检测：根据瓶子的高度和液面位置判断瓶子是否装满．如果液面低于设定的阈值，则认为瓶子未装满．
5. 结果显示：在图像上标注检测结果，使用不同颜色框和编号表示检测结果．
实现
图像预处理与二值化
```
gray_image = cv2.imread("bottles-assembly-line.tif", 0) # 0 表示以灰度模式读取
BW_THRESHOLD = 170 # 二值化阈值
_, binary_image = cv2.threshold(gray_image, BW_THRESHOLD, 255, cv2.THRESH_BINARY)
```
读取灰度图像，并使用阈值170进行二值化处理，将图像转换为黑白图．
形态学操作
```
kernel = np.ones((3, 7), np.uint8)
opened_image = cv2.morphologyEx(binary_image, cv2.MORPH_OPEN, kernel)
```
使用形态学开操作去除噪声，确保瓶子的轮廓更加清晰．若不进行形态学操作，可能会导致连通分量分析不准确，如图 3 所示．
图 3 未进行形态学开操作，直接处理的结果
连通分量分析
```
num_labels, labels_im, stats, centroids = cv2.connectedComponentsWithStats(opened_image)
```
使用 cv2.connectedComponentsWithStats 获取连通分量及其统计信息．
液位检测与结果显示
```
AREA_THRESHOLD = 900 # 面积阈值
components = [
  stats[i]
  for i in range(1, num_labels)
  if stats[i, cv2.CC_STAT_AREA] > AREA_THRESHOLD
]
components.sort(key=lambda x: x[cv2.CC_STAT_LEFT]) # 按水平位置排序

for i, component in enumerate(components):
  x, y, width, height, area = component
  bottom = y + height
  is_full = bottom < 100 # 液面阈值
  color = (0, 255, 0) if is_full else (0, 0, 255) # 满的为绿色，未满的为红色
  cv2.rectangle(output_image, (x, y), (x + width, y + height), color, 2)
  cv2.putText(output_image, f"{i + 1}", (x, y + height + 25), cv2.FONT_HERSHEY_SIMPLEX, 0.75, color, 2, cv2.LINE_AA)
```
根据连通分量的面积和位置筛选出有效的瓶子，计算液面位置，判断是否装满，并在图像上绘制矩形框和编号．液面低于100像素认为瓶子未装满，用红色框表示；否则用绿色框表示．
结果输出
最终输出图片结果如图 4 所示．
图 4 检测结果
控制台输出结果如下：
```
第 0 个连通分量的面积为 2607，高度为 65，液面位置的 y 坐标为 83，是满的
第 1 个连通分量的面积为 3132，高度为 63，液面位置的 y 坐标为 81，是满的
第 2 个连通分量的面积为 8606，高度为 119，液面位置的 y 坐标为 136，不是满的
第 3 个连通分量的面积为 3132，高度为 63，液面位置的 y 坐标为 81，是满的
第 4 个连通分量的面积为 1871，高度为 65，液面位置的 y 坐标为 83，是满的
```
通过以上方法，能够有效检测传送带上未完全装满液体的瓶子，并在图像上直观展示检测结果．

附：程序完整代码
import cv2 import numpy as np # 读取图像 gray_image = cv2.imread("bottles-assembly-line.tif", 0) # 0 表示以灰度模式读取 # 二值化 BW_THRESHOLD = 170 # 阈值 _, binary_image = cv2.threshold(gray_image, BW_THRESHOLD, 255, cv2.THRESH_BINARY) # 对图片进行开操作 kernel = np.ones((3, 7), np.uint8) opened_image = cv2.morphologyEx( binary_image, cv2.MORPH_OPEN, # = 2: 开操作 # cv2.MORPH_ERODE = 0：腐蚀 # MORPH_DILATE = 1：膨胀处理 # MORPH_CLOSE = 3：闭运算处理 kernel, ) # 获取连通分量及其统计信息 num_labels, labels_im, stats, centroids = cv2.connectedComponentsWithStats(opened_image) # 显示每个连通分量 output_image = np.zeros((gray_image.shape[0], gray_image.shape[1], 3), dtype=np.uint8) # 为每个连通分量赋予随机颜色 for label in range(1, num_labels): # 从1开始，0是背景 mask = labels_im == label output_image[mask] = np.random.randint(0, 255, 3) AREA_THRESHOLD = 900 # 面积阈值 components = [ stats[i] for i in range(1, num_labels) # 保存面积大于阈值的连通分量 if stats[i, cv2.CC_STAT_AREA] > AREA_THRESHOLD ] components.sort( key=lambda x: x[cv2.CC_STAT_LEFT], ) # 按照左上角 x 的坐标排序，从左到右 for i, component in enumerate(components): x, y, width, height, area = component bottom = y + height # 液面位置的 y 坐标 is_full = bottom < 100 print( f"第 {i+1} 个连通分量的面积为 {area}，高度为 {height}，液面位置的 y 坐标为 {bottom}，" + ("是满的" if is_full else "不是满的") ) # 绘制矩形框 color = (0, 255, 0) if is_full else (0, 0, 255) cv2.rectangle(output_image, (x, y), (x + width, y + height), color, 2) cv2.putText( output_image, f"{i + 1}", (x, y + height + 25), cv2.FONT_HERSHEY_SIMPLEX, 0.75, color, 2, cv2.LINE_AA, ) # 显示结果 cv2.imshow("Output", output_image) # 保存到文件 cv2.imwrite("output.png", output_image) cv2.waitKey(0) cv2.destroyAllWindows()

数字图像处理ㅤ第三章作业

2025-12-25T17:07:24.134Z

为了展开一幅图像的灰度，使其最低灰度为、最高灰度为，试给出一个单调的变换函数．

记图像中的灰度值的最大值为，最小值为，则可给出一个符合要求的函数

试解释为什么离散直方图均衡技术一般不能得到平坦的直方图？

原图像一般只有有限个灰度级，部分灰度级像素较多，部分灰度级中没有像素．由于均衡化时的变换函数是单调递增的，每个灰度级只能映射到同一个灰度级，所以均衡化后的图像的灰度级数小于等于原图像的灰度级数．

假设对一幅数字图像进行直方图均衡处理．试证明（对直方图均衡后的图像）进行第二次直方图均衡处理的结果与第一次直方图均衡处理的结果相同．

由

和

得第一次直方图均衡化

其中，是图像中的像素总数，表示灰度值为的像素数．

记表示灰度值为的像素数，则第二次直方图均衡化的结果为

由于直方图均衡化使原有的每个灰度级的像素数量保持不变，只是灰度值发生了变化，因此，映射后的每个新灰度级依然保有相同数量的像素，即，所以

4、（a）证明式（3.3.8）中给出的离散变换函数对直方图均衡处理满足3.3.1节中的条件（a）和（b）．

对于

设，

故在区间上是一个单调递增函数，条件 (a) 得证．

故对于，有，条件 (b) 得证．

（b）证明只有在灰度不丢失的情况下，式（3.3-9）表示的离散直方图反变换才满足3.3.1节中的条件（a′）和（b）．

对于，有，条件 (b) 得证．

由 (a)，设时，若且丢失，则，

可能等于，不符合单调递增的要求．

而当灰度不丢失时，，

此时在区间上是一个严格单调递增函数．

下面证明严格单调递增函数的反函数严格单调递增．取，有，因为严格递增，所以，所以在上严格递增．

在给定应用中，一个均值模板被用于输入图像以减少噪声，然后再用一个拉普拉斯模板来增强图像中的细节．如果交换一下这两个步骤的顺序，结果是否会相同？

两个模板均为线性变换，顺序不影响最终结果．即交换前后结果相同．

使用式（3.6-6）给出的拉普拉斯定义，证明从一幅图像中减去相应的拉普拉斯图像等同于对图像进行非锐化模板处理．

非锐化处理中，

由拉普拉斯定义

有．即从一幅图像中减去相应的拉普拉斯图像等同于对图像进行非锐化模板处理．

数字图像处理ㅤ第二章作业

2025-12-24T16:27:28.057Z

将近年末，整理一下学校相关的东西。本文写于2024年3月25日，发表于2025年12月24日，所以我已不知道下面内容在胡说什么了。祝读者好运。

的 CCD 摄像机芯片有 2048×2048 个元素，将它聚焦到相距远的一个方形平坦区域．该摄像机每毫米能分辨多少线对？摄像机配备了一个镜头．（提示：成像处理模型如图2.3所示，但使用摄像机镜头的焦距替代眼睛的焦距．）

物方焦距，像方焦距，物方高度记为，像高记为，则

时，像高，故该摄像机的分辨率为

高清晰度电视（HDTV）使用1080条水平电视线隔行扫描来产生图像（每隔一行在显像管表面画一条线，每两场形成一帧，每场用时秒）．图像的宽高比是16:9．在水平行数固定的情况下，求图像的垂直分辨率．一家公司已经设计了一种图像获取系统，该系统由HDTV图像生成数字图像．在该系统中，每条（水平）电视行的分辨率与图像的宽高比成正比，彩色图像的每个像素都有24比特的灰度分辨率，红色、绿色、蓝色图像各8比特．这三幅原色图像形成彩色图像．存储90分钟的一部HDTV电影需要多少比特？

对于高度为的图像，宽度为

图像面积

每像素需，则每幅图像需

若每场时间，每两场形成一帧，则视频的帧率为

不考虑压缩，存储的一部 HDTV 电影，需要

两个图像子集、的邻接方式？

图 1 通路和通路

图 2 通路

这两个子集

不是邻接的，如图 1，和中没有像素是邻接的；
　是邻接的，如图 2，和是邻接的；
　是邻接的，如图 1，和是邻接的．

给出一个像素宽度的 m 通路转换为 4 通路的一种算法．

考虑如下图的图像分割．

令V={0, 1}，计算和间、和通路的最短长度；
令V={1, 2}，计算和间、和通路的最短长度．

(a)

不存在通路．

    3    1    2    1 (q)
                
    2    2    0    2
              ↑
    1    2    1    1
                
(p) 1  → 0    1    2

通路最短长度为．

    3    1    2    1 (q)
                
    2    2    0    2
              ↑
    1    2    1    1
              ↑ 
(p) 1  → 0  → 1    2

通路最短长度为．

(b)

    3   1 → 2 → 1 (q)
        ↑
    2 → 2   0   2
    ↑
    1   2   1   1
    ↑ 
(p) 1   0   1   2

通路最短长度为．

    3   1   2 → 1 (q)
          
    2   2   0   2
      
    1   2   1   1
    ↑ 
(p) 1   0   1   2

通路最短长度为．

    3   1 → 2 → 1 (q)
        ↑
    2 → 2   0   2
    ↑
    1   2   1   1
    ↑ 
(p) 1   0   1   2

通路最短长度为．

自新世界 #0x17：天津散步

2025-12-22T16:48:17.654Z

版权许可

本作品采用 知识共享署名—相同方式共享 4.0 国际许可协议（CC BY-SA 4.0 International）许可，阁下可自由地共享（复制、发行）和演绎（修改、转换或二次创作）这一作品，唯须遵守许可协议条款。

这次是N3。由于没有决定抢着报名，北京的考场已满，所以我报名了天津的考点，需要从亦庄坐到天津。在前一天，快乐的老鼠宝宝由于也要去N2，提醒我不会没买手表吧。我不响。出门去找一家店，结果这家店只是在外卖平台上有丰富的外卖品类，但线下却很寒酸，因为他们把店挂出去给别人做线上了，实际不是从那里发货。翌日出门之后坐上了公交车，又发现落下了无线耳机。于是通过一个最近没有改名的外卖平台下单买了一个无线蓝牙的耳机。亦庄站距离公路有两个斜着的道路，我本以为骑手找不到。耳机是那种挂脖式的，续航好像很长，我觉得音质居然意外地不差，虽然回家一听有很大的底噪。

到了天津站，我坐了地铁，大概半个小时，到了小白楼^Q6126744。我上次来天津也是初次来天津，就去过那个地方，应该是音乐厅附近。地铁站里面的告示牌声称它是一个地铁重要站点。我在学校旁边的一个星巴克在那里复习，做了很多听力。里面也有好多人，基本上没啥空的座位。家人向我发送了其去其他大学看到的考试告示。

到了整点准备入校，发现有很多人在那里排队。又有三两培训机构人员散发传单。进去之后人也很多。他们那个楼应该是一个连体的楼，我能走很远，到其他考场走了很远才找到饮水机。这个饮水机要微信小程序才能使用，然后你需要先预付费；每次使用的时候则是手机扫对应的出水口上面的二维码，然后手机上会显示出一个二维码出来，再把这个二维码对准机器的那个摄像头识别口。识别的有点慢，一开始以为用不了。旁边有一个中年一点的男人他也来接水。其时，遇到一个小细伢子，中年男问，答曰还在上小学，无需成年即可报考。这让我想起了我上次的散步经历，似乎周围的年龄都比较大，我坐在考场里，略感有些不协调。

已经很久没有考试了，我想。到了40分，即离开考还有20分钟时入场。40分只是场外入场截止时间。这次可以戴机械手表，但是监考老师宣读的考试须知中说不可以，学校的考场都有表。事后我反馈了这一消息，老鼠宝宝说日本的习惯是教室不一定有表，因为自己需要对自己的时间负责；鼠宝又认为国内都是标准化考场了。我说我PTSD了，你知道我高考是什么感受吗？并且复读了前者的质问。从整个流程上来说，与上次考试对比，这次似乎更加正规，考场的各种指导都更完善。

言語知識比较顺利，没背到的主要有两个。一个是第四题读音的「腹痛」，不过想想形近字「复」「通」可以轻松选出。让我想起高中的数学老师说的外地淮语，复数与负数对比，前者两字皆是入声，大概读作focsoc。至于通，ng变为uũ很规律。如果你不知道我在说什么，你可以看这个波兰男娘制作的从韩语汉字音推断日语音读的视频。还有一个是「案外」，意思同「意外」。我本以为「案外道」是什么搭配，不过看来是当作副词。这个不在我所用的Anki卡组中，但群友指出该词在N3高频「意外」这张卡上的synonyms中。阅读似乎有一篇文章说的是野菜皮做的出汁 (だし) 。同样不认识这个单词。后来了解到这是一种汤，不过听起来就不好吃，可能加点咖喱比较好？

遗憾的是，虽然我准备了一些听力，但是似乎情况比上次更糟糕了，依旧处于听不懂的状态。以往考试如坐针毡的场面又浮现在了眼前。此外，我买的一本真题册配套的读音果然有一股以普通话为母语者朗读的味，还有很重的鼻音。虽然在报名时我就料到又是这样缺乏创新性的结果了，权当模拟考试了。毕竟上次连题型都没了解全。而放眼未来，可以料想的是，我肯定还会通过若干次这样的失败，来确认一下我的日语听力的事实水平。

自新世界 #0x15：Carbon Design System

2025-11-21T18:35:29.186Z

日期：2025/11/21

分类：

周报

标签：

tauri

串口

我在干什么

Tauri

最近又有新的需求，决定拿 tauri 糊。serialport 用着没啥问题。

tauri 有个 tauri::ipc::Channel 可以直接作为 #[tauri::command] 的参数，前端那里放个 event handler 就行。至于单次的串口读写/polling之间，照例还是 Mutex，方便解耦 & 在读写前后写点处理数据的代码。

Carbon Design System

前端准备还是用点其他的框架（指非 Svelte）。尝试了 Carbon Design System 的 Vue 库 @carbon/vue3，“文档”仅有个故事书，怎么写都渲染不出来，感觉是漏了 CSS 什么的。这个设计系统是以前用 Svelte 时为数不多的选择——其他要么需要 install package per component 如 Svelte Material UI，要么是 atomic 的需要 Tailwind（如图）。

而且 Carbon 不愧是老牌 IBM 厂设计的，配合着自家的 IBM Plex Sans (SC) / Mono，给人朴实、硬朗的感觉，非常清爽。虽然看着可能没有什么细节上的动效，但是总比隔壁天天在 YT 上拿渲染出来的概念动画发 Shorts 务实——后者的实际体验完全不是那么一回事。

群友阅读本文的预印本后，说：

y****

隔壁是谁

2025/11/19 16:45

前端之猫

2025/11/19 16:45

y****

可惜现在 LLM 只会用 tailwind，没救了

2025/11/19 16:45

从新版 office 图标来看，这家公司已经彻底没救了

2025/11/19 16:46

IBM 可能还在用自己的大型机，所以没有被 MACos 腐蚀脑子

2025/11/19 16:47

mingw

我觉得新图标挺好的

2025/11/19 16:47

y****

自觉退群吧

2025/11/19 16:47

Vibe Coding

一个需求是做一个嵌在软件里面的 manual。让我回想起我小时候用的软件都有 chm 什么的。下面是其中一天的歪卜抠顶的对话记录：

GitHub Copilot Conversation Log

Development session: Manual documentation and UI refinements

Messages

17

AI Responses

9

OverflowCat

@workspace

- 给 PROJECT 写文档 - 现在我有一个比较特殊的需求：客户需要一个比较传统的 software manual。 - 下面，请你在 status bar 的末端加一个揿钮，打开一个全屏的manual介面。其中复用现有的组件来介绍功能。

Workspace

Collecting workspace information

Workspace

我会帮你在状态栏末端添加一个按钮，打开全屏的软件手册界面。让我创建相关的组件和修改：

Full Response

首先，创建手册组件：

Generated Code

然后修改状态栏，添加手册按钮：

Generated Code

最后添加一些样式优化：

Generated Code

这个方案提供了：

完整的使用手册界面：使用 Carbon Design System 的 Modal 和 Tabs 组件
四个主要章节：
- 概述：软件介绍、功能、系统要求
- 主界面：详细介绍各个界面区域
- 标定模式：说明两种模式和偏差计算
- 操作流程：分步骤的操作指南和故障排除
复用现有组件：
- CalibrationModeSelector 用于演示标定模式
- DataDisplay 用于展示数据布局
- 状态栏元素用于说明底部信息栏
状态栏按钮：在 StatusBar 末端添加使用手册按钮，点击打开全屏手册
友好的排版：清晰的标题层级、充足的间距、合理的配色

这样客户可以随时打开手册查看软件的详细使用说明！

OverflowCat

你这边不对—— 1. please 说明开始/停止和其他按钮的 disabled 的状态变化 2. 缺少打开原厂软件的按钮介绍（虽然目前还没实现）

GitHub Copilot

我来修正这两个问题：

Full Response

Using "Replace String in File"

Generated Code

现在修改了手册中控制栏的说明，包括：

详细说明了按钮的 disabled 状态变化：
- 串口输入框：监测停止时可编辑，运行时禁用
- 开始/停止按钮：始终可用，会根据状态切换文字和颜色
- 切换原厂软件：仅在停止时可用
- 退出按钮：仅在停止时可用，运行时禁用
添加了按钮的介绍：
- 说明其功能是启动设备原厂配套软件
- 解释点击后会隐藏当前窗口
- 说明原厂软件关闭后会自动返回
在演示区域也添加了该按钮，使用 Settings 图标来展示

这样用户就能清楚地了解每个控件在不同状态下的行为了！

Made changes.

OverflowCat

這個縮放會讓 Manual 的 Modal 佈局錯誤（超出屏幕），但是我又不能刪掉這個

GitHub Copilot

我理解了，全局的 zoom: 1.2 会影响 Modal 的布局。我们可以在 Manual 的 Modal 上重置 zoom。让我修改 CSS：

Full Response

Using "Replace String in File"

Generated Code

让我查看一下 App.css 文件的完整内容：

Read [](file:///c%3A/.../PROJECT/src/App.css#130-130), lines 130 to 170

我看到问题了，有一个 // ...existing code... 的注释造成了错误。让我修复它：

Using "Replace String in File"

Made changes.

OverflowCat

请改成符合颜色的，不要禁用的

GitHub Copilot

我来修改 Manual 中的演示按钮，让它们显示正确的颜色状态而不是都禁用：

Full Response

Using "Replace String in File"

Generated Code

完成！我已经将演示按钮从 disabled 改为使用 pointerEvents: "none"，这样：

✅ "开始监测" 按钮显示为蓝色主按钮（kind="primary"）
✅ "停止监测" 按钮显示为红色危险按钮（kind="danger"）
✅ "切换原厂软件" 按钮显示为灰色第三级按钮（kind="tertiary"）
✅ "退出" 按钮显示为红色第三级按钮（kind="danger--tertiary"）

所有按钮都保持了正确的颜色，但通过 pointerEvents: "none" 阻止点击，这样在手册中就能看到它们正常的视觉效果了！

Made changes.

OverflowCat

改成 html 列表的，你这是 markdown

GitHub Copilot

我来把 Markdown 格式的列表改成 HTML 列表：

Full Response

Using "Replace String in File"

Generated Code

完成！我已经将 Markdown 风格的列表（使用 • 和 - 以及 <br /> 和  ）改成了正确的 HTML 嵌套列表结构：

使用 <ul> 和 <li> 标签
主要项目作为一级列表
详细说明作为嵌套的二级列表
添加了适当的间距样式

这样语义更清晰，样式也更容易控制！

Made changes.

OverflowCat

请把四个 tab 拆成4个 components文件

GitHub Copilot

我来把四个 Tab 拆分成独立的组件文件：

Full Response

Created [](file:///c%3A/.../PROJECT/src/components/manual/OverviewTab.tsx)

Created [](file:///c%3A/.../PROJECT/src/components/manual/InterfaceTab.tsx)

Created [](file:///c%3A/.../PROJECT/src/components/manual/CalibrationTab.tsx)

Created [](file:///c%3A/.../PROJECT/src/components/manual/WorkflowTab.tsx)

现在更新 Manual.tsx 来使用这些新组件：

Using "Replace String in File"

Generated Code

现在替换 TabPanels 的内容：

Using "Replace String in File"

Generated Code

现在替换 TabPanels 的内容：

Made changes.

OverflowCat

@agent

Try Again

GitHub Copilot

让我重新替换 Manual.tsx 中的 TabPanels 部分：

Full Response

Using "Replace String in File"

Generated Code

Made changes.

OverflowCat

@agent

Try Again

GitHub Copilot

让我查看文件内容并进行修改：

Full Response

Read [](file:///c%3A/.../PROJECT/src/Manual.tsx#115-115), lines 115 to 250

Using "Replace String in File"

Generated Code

让我查看文件中还剩下什么内容需要替换：

Read [](file:///c%3A/.../PROJECT/src/Manual.tsx#125-125), lines 125 to 400

我看到问题了，还有重复的内容。让我删除这些重复的部分：

Using "Replace String in File"

Generated Code

完成！我已经成功将四个 Tab 拆分成独立的组件文件：

OverviewTab.tsx - 概述标签，包含软件简介、主要功能和系统要求
InterfaceTab.tsx - 主界面标签，展示控制栏、数据展示区和状态栏
CalibrationTab.tsx - 标定模式标签，说明两种标定模式和偏差计算
WorkflowTab.tsx - 操作流程标签，提供分步骤操作指南和故障排除

现在 Manual.tsx 变得更加简洁，只负责组织这些Tab组件的结构，而每个Tab的具体内容都在独立的组件文件中，便于维护和复用！

Made changes.

发布

由于不会在 Windows on ARM 上交叉编译 x64 的 Rust 程序，所以我最后掏出了我的旧的华为笔记本。

局域网开了一个 http-server，在 client 机器上下载运行的时候非常麻烦，首先是 Edge 会千方百计地阻止你下载这个程序；其次还会有司马的Screen弹窗。最后将软件刻进光盘，和机器一同寄给客户。

我在看什么

回顾 Claude Code 的成功：天时地利人和+大道至简：

RAG 是 chat 时代的产物，是因为没有 agent 所以搞来的轮椅。并不是轮椅不好，但是轮椅坐久了可能大家就忽略了其实可以用脚走路的。

只有 RAG 不行，但 RAG 本身大概还是有用的。现在会走路了之后还是可以坐高级电动轮椅，说不定可以更加起飞。
Owning a Cat Could Double Your Risk of Schizophrenia, Research Suggests 不过注意，

This kind of research can't show cause and effect, and it often doesn't account for factors that may have affected both the exposure and the outcome.
AI 不是裁员的原因，巨额 AI 支出才是，Solidot
Tim Bray on Grokipedia linked in Daring Fireball:

No encyclopedia in history has been written with less time or effort than Musk’s LLM-generated vanity project. Verbosity is not the worst of Grokipedia’s deficiencies, but it’s one of them.
- [[维基百科不是不经筛选的信息收集处]]。

自新世界 #0x16：制度性失忆

2025-11-19T02:49:05.470Z

版权许可

本作品采用 知识共享署名—相同方式共享 4.0 国际许可协议（CC BY-SA 4.0 International）许可，阁下可自由地共享（复制、发行）和演绎（修改、转换或二次创作）这一作品，唯须遵守许可协议条款。

2025 年 11 月 10 日

同事掏出一个老旧设备和一个有 Android 2 时代截图的说明书，说配对不上了。还说这个 APK 有好几个版本，都是随着安卓升级而改上去的，只有最新的一个版本才能安装上，但是还是会提示此应用专为旧版 Android 打造。我说这个只是个提示，实际应该没有兼容性问题。我们在公司的智选手机、红米手机上都试了试，蓝牙配对本身就很慢；也没能读取出设备的数据。

2025 年 11 月 11 日

于是我现在要逆向自己公司的 APK。

前端之猫

Android resource compilation failed 是什么意思？

2025/11/11 16:14

*座桥在水上

前端猫不会不知道安卓里的 /res 吧。

2025/11/11 16:16

前端之猫

但是，为什么 res 还要编译

2025/11/11 16:18

*kumi

小毛驴变成二进制小毛驴

2025/11/11 16:18

id 变成 int

2025/11/11 16:18

*座桥在水上

听说过 resources.arsc 吗？

2025/11/11 16:19

看来前端之猫没有反编译过安卓爱啪啪。哎，前端。

2025/11/11 16:21

（为保护群友隐私，ID 已隐去一个字）

2025 年 11 月 12 日

Leader 再次强调了写这个程序的人早就离职了，然后第三次向我表明很难找到源代码或文档了。这让我想起了《制度性记忆与反向泄密》¹中说的：

制度性记忆有两种形式：人与文档。人记得事物如何工作，以及为什么能工作。有时候他们会将其写下来，将信息存储于某处。制度性失忆的原理与其类似：人离开了，文档丢失、腐烂或者仅仅被遗忘了。

项目中用的是 Bluetooth Classic SPP（Serial Port Profile）协议。但我在 Windows 上连接设备时，它居然被识别成 BLE，这样的话，Windows 就不会为我映射一个串口，用来交互。这就导致我用 C# 写的 AI 生成版本完全连不上。尝试用 Kotlin 重写也不一定能解决问题，毕竟协议层的兼容性才是关键。尤其是这个 APK 还有多个版本，以前的版本更是连安装都装不上。

今天晚上待到很晚。Leader 坚持说那个程序是使用界面设计器开发的，因为他清楚地记得，在那之前他们只能用 Eclipse。于是我们终于找到了 layout 目录下面的 XML。

鱼鱼给我发了他的高级版永久的MT管理器的帐号和密码，他说逆向一般都不用电脑上的软件；但是逆向出来的一般也编译不成工程，除非是用纯 Java 写的程序。我尝试的结果是一直会出现资源编译错误和资源链接错误。

2025 年 11 月 13 日

让大语言模型用 Kotlin 重写了一版，还是 View 的，但是只包含设备列表和蓝牙连接的部分。但是始终连不上，还闪退了。

再用各种蓝牙调试助手，尝试和设备通信，但是都卡在到蓝牙 SPP 建立 socket 连接上。卓易通里的似乎可能有用，但是我不知道它是不是因为卓易通的 bug。用鸿蒙原生的蓝牙调试助手，有一个甚至都没办法正常授予权限；我用了其中一个，但光 UI 上状态管理的 bug 就挺多的，这让我觉得是软件在蓝牙连接结果显示上有问题。

还有两台备用的设备，这个设备的名称会间歇性地从一个比较长的一个长串的代号变成一个简单的只有两个字符的，我不知道是什么时期要连接它，而且它的说明书上说需要分钟等芯片预热了之后再尝试连接，然后每次测量完了以后需要先关闭软件再关闭设备，否则会出现问题。

实验室的落日余晖照在成排 capsule 状的设备上，很好看。

2025 年 11 月 14 日

发现用蓝牙调试助手都没法正常连接。最后，做硬件的一看发现蓝牙的设备名称都不是伊以前改过的名字，可能是蓝牙模块的主从模式设置错了；而这是因为伊 assume 以前的设备都调试好了，但实际上只在卖出去的时候测试一遍，这个设备只是留存自用，所以没有经历那个步骤。

后首修好了，旧的应用也能用了，就不需要我再处理了。回家看动画片。

2025 年 11 月 15 日

在电视上看动画片。

2025 年 11 月 16 日

在鸿蒙电脑上看动画片。

脚注

知乎译文，似乎最开始是在 Rynco 的频道里看见的。记不起来题目了，我是通过 登月知乎工程资料失传 搜到的。

自新世界 #0x12：私有协议

2025-11-10T03:32:32.871Z

2025 liến 10 yuêc 19 lec

Kì Hốngmống Dà Jiẽudiền. Hèusoc qiángxì suec.

2025 liến 10 yuêc 20 gen 21 lec

Kàendò piên suec Mĩituốn gồngxiãng tsôngdiềnbõ dãyĩi'dii wéndsang, láenhèu jièu dsề jii’sang kàendò’lec.

2025 liến 10 yuêc 22 lec

Kàen faecbùhùi.

2025 liến 10 yuêc 23 lec

Daenwùi sítáng’dii tsề bec láenqic, dàen yíi jiacdùi bec hõqic, há tsángtssì lẽn’dii. Dsìgáen xuẽn’dii fíitsáng dsĩhõ dsìgáen yictec.

2025 liến 10 yuêc 24 lec

Ẽuyù qípa xicbìi gen dsuônyẽu xicyì, pingjìng quếnlic wúfã jiềnsèn.

揚越雙語《金雲翹傳》——《〈斷腸新聲〉題辭》

2025-10-23T13:34:57.331Z

Mac wènxiống hua dsỗng,

Dôngsaen gũ dsèn lống.

《金雲翹傳》，通稱《翹傳》（Truyện Kiều／傳翹）或《斷腸新聲》，是越南的六八體長篇敘事詩，由詩人阮攸依明末清初青心才人小說《金雲翹》以字喃寫成，共 3254 行。

《翹傳》問世後，范貴適讀之，感嘆一位才女的悲劇命運，欽佩作者才華，又嘆世道之痛，遂以漢文作《總詠》及《聽〈斷腸新聲〉有感》兩篇；後又自譯為喃文。

譯文

美人翠翹要是不往錢塘江邊走，她青樓半生情債又怎能收？

那如花美貌何必沉入水底去？冰清玉潔的心才配與金郎久。

這一場斷腸夢如今已得明就，一曲《薄命》彈完怨恨還未休。

爲了一點點才情要受千年苦累，《新聲》這書又爲誰傷感爲誰憂愁？

自新世界 #0x11：入職第一周

2025-10-18T17:11:46.529Z

這咔 Baecyuêcjiêc都過tec了, 前端之貓總算是工作了.

2025 liến 10 yuêc 12 lec

Kì socxìi. 上個 xìiyẽu dsènyò baendsẽu; 還有個 tsuectsê kì了.

2025 liến 10 yuêc 13 lec

和兩個 liũxiá'dsê 一起 bòdò. Dãenwì好多都是 xicmicyồng'dii 不能 sàngwãng的 Win 7. 工位不得電腦, 第一天就隑lãen.

2025 liến 10 yuêc 14 lec

Leader jiòỗyồng C++ / C# 寫 jìimiền, 還講以後可能會要用 Android, 讓我有空 kàenhà jãen lòng. Là dangyáen是選 Avalonia. 試了下 Avalonia 推薦的 Rider, 不丑. Gãenjiac 我以前不歡喜 JetBrains ga IDE 是因為 Jvav 太難用了.

Wakatime IDE 使用 tỗngjì

Dsông'buôn'tiên kì sangtsãng wáen, 不過下次還是要 sò'dii'geu. Xiàwãen'si'heu bo圓tec.

2025 liến 10 yuêc 15 lec

Póngtéulaxi'di kì了 dãenwì. 畫 Visio 圖, yồ 做個運行狀態的動畫放 jìimiền 上. Avalonia 官方提供 Lòti 庫 Avalonia.Labs.Lottie, 能跑.

連接設備到一個五口 gohuàenji, 4個是 PoE 供電; 但是不曉得 IP 地址跟 port. Qíngdò tsãngga的軟件, 能 pìng 通. Tsãngga的庫里向雖然有 pdb 之類的dông'dsê, 但是 DLL 報錯, 一調就 throw tec, láenwáen. 補全是好的.

2025 liến 10 yuêc 16 lec

開會, jìisò了 hà 部門情況. 講產品修好到現場 yèu壞tec, 跟負責 desc'guec的在lec'kuec baen 是哪個的責任, gang了 wù'qi'lê了. Leader 把他的 C 代碼的 dêmo 把我了, 縮進都 locbecdàduìi的. Xiõdsông sí'heu, 把 Claude 望望瞧問題, 改了也不得yồng. 到中了 xiêc so, qí jiõtaecqii kì hec-Látic.

Fàenhèu, yồng ILSpy decompile tec, 發現是 .net framework 3.5, M$ 網站上都下載不到 dev pack. 然後yồng Copilot 摩登-ization agent 升到 .NET 9, 換了個算 MD5 的 háensoc 後, 好像就一diigèu 問題都不得. 可以看到 tsuốn huílế的 JSON, 字段名還是 UTF-8 的中文.

然後 yèulàngsì 能不能連個新的網絡繼電器, 結果呢外頭不得diigèu label. 另一位同事説是三無產品. 好 becyóngyì 拿到 manual, 發現這個也yồng JSON 傳數據了, lési.

2025 liến 10 yuêc 17 lec

嘗試開 .NET AOT 編譯, 失敗tec.

發現 dsá'geu的數據有不得 value 對應的 key, 還真不是 JSON. 哪個 tsaqiò的人寫的?! 個 dsuôc'dii'lii.

Wakatime sígaen tỗngjì

惊鸿一瞥：升级、回退、云备份

2025-09-06T00:49:34.266Z

数据无价，谨慎操作。

绿色部分为推荐的操作；蓝色部分为我没有仔细观察，可能有风险的操作；红色部分为无法后悔的操作。本文仅为参考，请对自己的数据负责。

升级

简而言之：升级前务必备份数据到本机，回退时才能恢复这部分数据。
从杂种鸿蒙升级到纯血鸿蒙，应用数据的保留是通过应用数据迁移实现，具体来说，是升级时 APK 沙箱数据前会被放到中间目录，然后 NEXT 调用 HAP 的 BackupExtensionAbility 处理数据，保存到鸿蒙应用的沙箱。

升级前会有一个强制你备份的流程。这是唯一允许备份数据到本机的地方。
- 然而，安卓应用有一清单值。至少在 2024 年，如果禁止备份，则降级恢复时只能恢复应用本体。
- 不过，对于微信，似乎各大厂商都覆盖了这一限制。尚不清楚目前是否已解除这一限制。
安卓出境易中的应用和数据并不会继承到鸿蒙出境易中。
出境易和卓易通可以有相同应用。
如果不想你的应用被升级到鸿蒙原生版本或受到出境易、卓易通的（主要是升级）限制，那可以事先安装 GBox 等容器应用。GBox 中的应用数据会在恢复备份或者升级后保留。
升级之后，微信需要有一个导入旧聊天记录的功能，需要一定时间。如果你还想在近期内回退，那么建议你暂缓导入。这样，想回退时将消息迁移到其他设备就会只包含新增的消息。

回退

根据鸿蒙设备司法鉴定技术指南：四大调试工具的取证实践 - 安全内参 | 决策者的网络安全知识库：

然而，鸿蒙系统的分布式架构和日志加密机制，让传统取证面临设备连接难、日志解析难、证据固定难等多重挑战。在此背景下，华为面向开发者发布的 HDC（HarmonyOS Device Connector）工具、aa 工具（Ability 助手，简称 aa）、bm 工具（Bundle Manager 包管理工具，简称 bm）与 hilog 工具，成为司法鉴定领域的“破壁利器”，为司法实践提供技术支撑，帮助鉴定人员在纯血鸿蒙设备上实现高效、可靠的电子证据提取与分析。

实际其他的在备份上没有太大用处，目前支持鸿蒙 NEXT 较好的取证软件似乎就是模拟了以下 HiSuite 备份流程的实现。

HiSuite

据官网，支持以下内容：

联系人、信息、通话记录、备忘录、录音、日程、图片、视频、音乐、文档

三方应用及数据：受限于系统和应用兼容性，仅支持部分应用和数据迁移（升级尝鲜类应用暂不支持）

系统设置：桌面布局、天气、闹钟等部分设置项（暂不支持隐私空间）

为避免数据丢失，建议 QQ、微信等三方软件使用三方应用自带的迁移功能进行迁移备份，并确认备份内容完整有效

HiSuite 备份界面

讽刺的是，使用鸿蒙 PC 的用户，和 macOS 用户一样，反而没有支持鸿蒙 5 的 HiSuite。

另外，官网上还有一节 HarmonyOS 5 版本的备份记录在 HarmonyOS 4.2/HarmonyOS 4.3 版本恢复：

支持：
- 联系人、短信（文本信息）
- 日程、备忘录、笔记
- 文档、音乐、录音（含通话录音）、图片、视频。
- 通话记录（备份时 ≥5.0.0.115）
不支持：
- 彩信、5G 消息
- 图库（回收站）、我的收藏
- 三方应用及数据
- 系统设置、隐私空间等
- 文件保密柜数据（请在备份前将文件保密柜数据移出）

将数据备份至云空间

中国人愿用隐私换便利。不开通会员时，登录云空间会每日备份基础数据，包含短信、通话记录、联系人。但尚不清楚是否后续的备份会覆盖前面的备份。
如果你开通了会员：从云空间恢复应用数据时，会覆盖掉本机上的应用数据。因此，仅推荐你用来备份图库。另，在纯血鸿蒙上开通可能会有不定优惠，以及 Petal One 套餐优惠（可视为华为服务的大会员）。

如何导出媒体数据

使用 `hdc`

“答开发者问”之 HarmonyOS 技术问题解析第 15 期（IA）中：

问题五：HarmonyOS NEXT 手机怎么导出照片到电脑？
目前在 mate60 pro 拍摄的照片需要导出到电脑，请问要如何操作？
mediatool 是一个轻量级的命令行工具集合，开发者可通过此工具操作媒体库资源。媒体库为图库提供和管理数据，媒体库中的图片视频会在图库界面呈现。
然而这个工具十分不好用，并不是 mv 那种能做各种文件操作的。建议只使用 mediatool recv all dest 进行全量导出。如果想增量的话，需要自己用 mediatool ls -l /storage/media/local/files/Photo 拉出文件列表然后写脚本。

使用其他软件

安卓上的备份软件自不必说。但 NEXT 上的却寥寥无几。
最早用上访问全部图片权限的是百度网盘，again，如果你愿意用你的隐私换你和艳红的便利。
流舟文件支持 WebDav 和 FTP，但其 OneDrive 支持有 bug，至少我的 1drv Business 会报无法创建目录。

克隆

如果你像我一样，有两台同类型设备处在纯血鸿蒙，那么可以通过数据克隆来在手机间拷贝应用数据，相对比较方便快捷。这也是唯一不太需要其他系统设备的备份纯血鸿蒙的方法。
- 由于我没有相关设备，尚不知道能否跨设备类型迁移（手机、平板以及 2in1）。
克隆应用时，部分应用可迁移数据，会用旧机数据覆盖新机上的应用数据。
克隆桌面布局时，会用旧机数据覆盖新机上的桌面布局。由于鸿蒙 4+完全无法使用第三方桌面，重新摆放图标是很困难的。

如何为 typst 加入 JSX

2025-08-14T11:19:36.693Z

版权许可

本作品采用 知识共享署名—相同方式共享 4.0 国际许可协议（CC BY-SA 4.0 International）许可，阁下可自由地共享（复制、发行）和演绎（修改、转换或二次创作）这一作品，唯须遵守许可协议条款。

你的浏览器不支持视频。请移步至原文查看。

Typst + react-confetti-explosion

本文最初以英文发布于我新开的英文博客。

Astro 是一个 Web 元框架，它非常擅长构建以内容为中心的快速静态网站，比如本博客以及我的英文博客。其最强大的功能之一是 Integrations，借助它我们可以在同一个项目中使用各种前端框架，如 React、Vue 和 Svelte。虽然 Typst 也能导出 HTML，但手写 HTML 从来都不是一件愉快的事。所以，最好还是把前端的事情交给前端工具来处理——这也是我创建 astro-typst 这个 Astro 插件的原因之一。

更棒的是，作为一个内容优先的框架，Astro 支持 MDX，这意味着你可以直接在 Markdown 文件中导入和嵌入动态组件。那么，我们如何将这种能力带到像 Typst 这样的其他标记语言中呢？

在 Typst 中嵌入组件

先来展示一下最终的 API。欲在 Typst 文档中嵌入一个组件，需要添加一个简单的辅助函数：

#let jsx = s => html.elem("script", attrs: ("data-jsx": s))

你可以随心所欲地定制语法，只要确保它返回下面这种格式就行：

// 比如，用代码块的格式
#let jsx2 = cb => html.elem("script", attrs: ("data-jsx": cb.text))

然后，要向页面中添加一个交互式的计数器组件，你只需这样写：

#jsx("import Counter from '../components/Counter.astro'")
#jsx("<Counter client:load />")
 
// 或者：
 
#jsx2[```jsx
<Counter initialCount={10} message='typst' />
```]

这就是你需要知道的全部 API 了。接下来发生的事情才是真正神奇的地方。

渲染管线

我们先来看看 Astro 的 MD(X) 渲染流程 —— 它使用了 Unified 生态系统的处理管线，通过 remark、rehype 和 recma 三个阶段将内容转换为 HTML。

MDX
├ remark-parse
├ remark-mdx
├ remark-mark-and-unravel
├ ...settings.remarkPlugins
├ remark-rehype
├ ...settings.rehypePlugins
├ rehype-remove-raw
├ rehype-recma
├ recma-document
├ recma-jsx-rewrite
├ recma-build-jsx
├ recma-build-jsx-transform
├ recma-jsx
├ recma-stringify
├ ...settings.recmaPlugins
JS

多亏了纸夜的工作，她为自己的 typst.ts 项目添加了 hᴀsᴛ（rehype 使用的抽象语法树）输出。这使得为 Typst 实现同样的功能变得水到渠成。我们只需要确保 JSX 的部分存在于 hᴀsᴛ 中。然后我们可以添加一个 rehype 插件，将这个 hᴀsᴛ 转换成和 MDX 产物完全相同的结构。再将这个结果送入 Astro 管线的其余部分，我们就能有效地替换掉标记语言，同时达到相同的效果。

`script` 标签

现在，回到我们之前的 html.elem。当 Typst 编译器处理你的文档时，#jsx 函数会在中间产物 hᴀsᴛ 中生成一个 <script> 标签：

<script data-jsx="<Counter client:load />"></script>

这个特殊的标签起到了一个标记的作用。

但是，这个标签要如何被处理呢？首先想到的是是伪造一个与 MDX 解析器相似的结构。于是，我用 Proxy 实现了一个简单的函数来劫持对一个对象的属性访问，看看哪些属性被实际访问了，并添加了一个插件来打印出 AST：

function rehypeStealMdxhast() {
  return function (tree: any, file: any) {
    // 将语法树存储在 file.data 中以便后续检索
    file.data.mdxhast = JSON.parse(JSON.stringify(tree));
  };
}
 
...
 
await compile(mdxContent, {
    outputFormat: 'function-body',
    development: false,
    rehypePlugins: [rehypeStealMdxhast],
});

通过调整插件的位置，我们可以在恰当的时机获取到 AST。

下面是一个 AST 的例子：

然后我发现，estree 数据早在 remark 阶段就已经被填充了。此路不通，还是得手动解析 JSX 字符串。

逐个解析

从这里开始，我们的自定义处理器 typstx（随便起的名字，它是我 fork 的 MDX 插件）接管了工作。它会遍历 hᴀsᴛ 查找这些特定的 <script data-jsx="..."> 标签。每找到一个标签，typstx 就会初始化一个新的、独立的 MDX 解析器来处理 data-jsx 属性内的 JSX 字符串。

const createJsxProcessor = () => {
  const pipelineJsx = unified()
    .use(remarkParse)
    .use(remarkMdx)
    .use(remarkMarkAndUnravel)
    .use(remarkRehype, {
      allowDangerousHtml: true,
      passThrough: [...nodeTypes]
    })
    .use(hastHastify)
 
  return pipelineJsx
}

这种方法简单直接，尽管这意味着页面上的每个动态组件都会触发一次独立的解析过程。该解析器将 JSX 字符串转换为一个代表该组件的 hᴀsᴛ 片段。

上面的管线被包裹在另一个转换器 rehypeTransformJsxInTypst 中：

export const rehypeTransformJsxInTypst = () => {
  // 找到所有 html.elem("script", attrs: ("data-jsx": "import Button from 'Button.jsx;'"))
  // 并将它们转换为 html.elem("script", attrs: ("data-jsx": "import Button from 'Button.jsx;'"))
  function compileJsx(node) {
    if (node.type === 'element' && node.tagName === 'script') {
      let hast = jsx2hast(node.properties['data-jsx'])
      hast = hast.children[0]
      ...
      return hast
    }
    if (node.children) {
      node.children = node.children.map(compileJsx)
    }
    return node
  }
 
  return function (tree, file) {
    return compileJsx(tree)
  }
}

通过递归调用 compileJsx，我们可以确保所有的 <script> 标签都被处理。这个新的组件片段随后会替换掉主 hᴀsᴛ 树中原来的 <script> 标签。

没有魔法，只有字符串

在所有标签被替换后，typstx 会将 AST 转换成一个可供执行的 JavaScript 模块字符串。 Astro 并不读取依赖列表，而是直接接收这个生成的完整脚本，并用其服务器端 JavaScript 运行时来执行。这个运行时自带的模块加载器会解析这些 import 语句，就像处理任何标准的 .js 或 .ts 文件一样。你的组件就是这样被定位和打包的。

此外，为了确保组件能在 Astro 生态系统中正确渲染，typstx 接受一个 jsxImportSource 选项。我们将其设置为 'astro'，这会告诉编译器生成调用 Astro 特定的渲染函数（例如，来自 'astro/jsx-runtime'）的代码，而不是其他框架的。

为了进一步提升性能，这种重复的解析逻辑应该被消除，比如可以使用 rehype 插件将不同的 import 语句直接转换为一个已经包含 estree 数据的 AST 对象。但我认为目前的实现更加灵活，也已经足够好用了。

if (node.type === 'mdxjsEsm' ||
    node.type === 'mdxTextExpression' ||
    node.type === 'mdxFlowExpression' ||
    node.type === 'mdxJsxAttribute' ||
    node.type === 'mdxJsxAttributeValueExpression' ||
    node.type === 'mdxJsxExpressionAttribute') { ... }

`unist` 的错误假设

另一个实现上的细节是，复用 unist 的 pipeline 并不是那么的容易。一个常规的 MDX 流程是从 Markdown 文件到 HTML / JSX，输入输出都是文件或字符串（即 VFile）。但在我们的例子中，输入是由 typst.ts 在 Rust 中通过 N-API 创建的 JavaScript 对象 hᴀsᴛ 树。此外，在创建 MDX parser 时，我们需要的输出是一个 estree 对象，它不是字符串也不是 VFile。

从 VFile 到 AST，或者从 AST 到字符串，这两个过程分别是 Parser 和 Compiler 的工作。你可能以前用过 remark-parse 和 rehype-stringify 这两个。我之前也在周报里放过这张图：

| ........................ process ........................... |
| .......... parse ... | ... run ... | ... stringify ..........|

          +--------+                     +----------+
Input ->- | Parser | ->- Syntax Tree ->- | Compiler | ->- Output
          +--------+          |          +----------+
                            X
                            |
                     +--------------+
                     | Transformers |
                     +--------------+

所以手动伪造了一个 Parser 和一个 Compiler 来处理 hᴀsᴛ 树：

let __hast = null
function tryParse() {
  // @ts-ignore
  this.parser = parser
  function parser(_doc, file) {
    if (body) {
      __hast = __hast.children.filter((x) => x.tagName === 'body')
      __hast = __hast.at(0)
    }
    return __hast
  }
}

没错，因为代码不是异步的，我们每次调用 tryParse 时都会修改 __hast。

以及一个假的 Compiler 来让 unified 以为它已经把 estree 对象转换成了字符串：

export default function hastHastify() {
  /** @type {Processor<undefined, undefined, undefined, Root, string>} */
  const self = this
 
  self.compiler = compiler
 
  function compiler(tree) {
    return tree
  }
}

前端生态

通过这样做，我们就能享受到前端生态系统带来的强大能力：

虽然有些前端框架本身不使用 JSX 语法，但 Astro 能很方便地把它们的输出转换为 JSX。

我们现在可以（重新）使用 rehype 插件而不是到处写 html.elem。这是一种非侵入式地增强 HTML 输出的方式。例如，为标题添加类似 GitHub 的锚点链接是这样做的：

import function rehypeAutolinkHeadings(options?: Readonly<Options> | null | undefined): (tree: Root) => undefinedAdd links from headings back to themselves.

###### Notes

This plugin only applies to headings with `id`s.
Use `rehype-slug` to generate `id`s for headings that don’t have them.

Several behaviors are supported:

*   `'prepend'` (default) — inject link before the heading text
*   `'append'` — inject link after the heading text
*   `'wrap'` — wrap the whole heading text with the link
*   `'before'` — insert link before the heading
*   `'after'` — insert link after the heading
@paramoptions Configuration (optional).@returns  Transform.rehypeAutolinkHeadings, { type type Options = {
    behavior?: Behavior | null | undefined;
    content?: Readonly<ElementContent> | ReadonlyArray<ElementContent> | Build | null | undefined;
    group?: Readonly<ElementContent> | ReadonlyArray<ElementContent> | Build | null | undefined;
    headingProperties?: Readonly<Properties> | BuildProperties | null | undefined;
    properties?: Readonly<Properties> | BuildProperties | null | undefined;
    test?: Test | null | undefined;
}Options } from "rehype-autolink-headings";
export default [
  function rehypeAutolinkHeadings(options?: Readonly<Options> | null | undefined): (tree: Root) => undefinedAdd links from headings back to themselves.

###### Notes

This plugin only applies to headings with `id`s.
Use `rehype-slug` to generate `id`s for headings that don’t have them.

Several behaviors are supported:

*   `'prepend'` (default) — inject link before the heading text
*   `'append'` — inject link after the heading text
*   `'wrap'` — wrap the whole heading text with the link
*   `'before'` — insert link before the heading
*   `'after'` — insert link after the heading
@paramoptions Configuration (optional).@returns  Transform.rehypeAutolinkHeadings,
  {
    content?: Readonly<ElementContent> | readonly ElementContent[] | Build | null | undefinedContent to insert in the link (default: if `'wrap'` then `undefined`,
otherwise `<span class="icon icon-link"></span>`);
if `behavior` is `'wrap'` and `Build` is passed, its result replaces the
existing content, otherwise the content is added after existing content.content: [
       {
         Element.type: "element"Node type of elements.type: "element",
         Element.tagName: stringTag name (such as `'body'`) of the element.tagName: "span",
         Element.properties: PropertiesInfo associated with the element.properties: { className: string[]className: ["anchor"] },
         Element.children: ElementContent[]Children of element.children: [{ Text.type: "text"Node type of HTML character data (plain text) in hast.type: "text", Literal.value: stringPlain-text value.value: "#" }],
       },
    ],
    behavior?: Behavior | null | undefinedHow to create links (default: `'prepend'`).behavior: "append",
  } satisfies type Options = {
    behavior?: Behavior | null | undefined;
    content?: Readonly<ElementContent> | ReadonlyArray<ElementContent> | Build | null | undefined;
    group?: Readonly<ElementContent> | ReadonlyArray<ElementContent> | Build | null | undefined;
    headingProperties?: Readonly<Properties> | BuildProperties | null | undefined;
    properties?: Readonly<Properties> | BuildProperties | null | undefined;
    test?: Test | null | undefined;
}Options,
];

更妙的是，你可以直接导入带有动画和交互的 ECharts 组件，而无需通过 WASM 渲染，这样性能也更好。如果你愿意，你甚至可以检查输出的 target，并使用 json() 在 echarm（用于 PDF 输出）和你的前端组件（用于 HTML 输出）之间共享代码。有无限可能！

立即尝试

你可以在这里看到演示。~~虽然这个功能已经被合并到了 master 分支，但一个完全基于 hᴀsᴛ 的方案可能会有性能上的影响，而且还没有经过充分的测试。~~

理论上，同样的方法也可以应用于其他标记语言，只要它们有相应的 hᴀsᴛ 生成器。此外，支持其他 JSX 运行时也是可能的，但我还没有测试过。

~~如果你想尝尝鲜，可以安装 npm 上的 beta 版本。~~欢迎提供反馈！

更新：可安装 0.12.0 及更高版本以使用此功能。

自新世界 #0x10：Link Blog

2025-07-14T14:37:21.004Z

我在读什么
Build you a link blog for great good
- Xuanwo shared Simon Willison's approach to running a link blog and wrote:
  - I decided to follow simon's approach to creating a link blog, where I can share interesting links I find on the internet along with my own comments and thoughts about them.
- This is a nice idea, and I am going to follow suite as well.
  - 实际上，我之前已经以某种形式在做了——比如以“我在读什么”等为标题。而且，
    超文本寫作
    一天世界
    這個話題真的有可能在中文世界討論嗎？John Gruber 在二零二四年說社交網絡打殘了超文本寫作，這句話在中…
    本身就是一种 link blog，link blog 可能只是没有主题的超文本写作。
- I don't want to boombard my readers with a flood of items in the RSS, so I'll keep the aggregate form, rather than splitting them into many snippets, although they may be stored like that in the source code. Another reason is that I don't want to acquire, or suffer from, the instant feedback of posting it like in social media.
- In my opinion, the core of a link blog is to try to add something extra, that is to cite and append whatever thoughts you have. They do not have to be deep insights. Nor do you need to stop yourself from digressing. If you agree with the original author, then write down your resonances. If you disagree, then argue against their opinions. If any part recalls your memory or blows your mind, write them down. To me it is not some kind of read-laters (you have to read it first), but a good way to ease your FOMO — rather than forwarded tens of Hacker News posts, you now act as a news filter for your readers by providing your personal commentary.
- Here are some rules:
  - As for personal reviews, no AI generated content (AIGC); translations may be.
  - To better express my thoughts, I will write in the language in which I feel appropriate for each link.
  - Content may be further re-used in other posts.
  - Content may be re-arranged in the future.
频繁使用AI可能让人越来越笨？来自一项最新研究的结论
- 重思什么是效率：
  - 频繁使用这类工具的用户被要求切换到纯大脑写作时，他们仍然背负着“认知债务”：……记忆痕迹较弱、自我监控能力下降，写作内容呈现碎片化。……人工智能工具虽然有助于提升学习表现，但可能会无意中阻碍深度认知处理、记忆力以及对书面材料的真正参与。用户……可能会获得表面上的“流利”，但无法内化知识或产生对知识的归属感。
  - 是有这样一种感觉，vibe writing 后整个人是懵的。
- 由于使用 ChatGPT 等工具写作时理论上花费的时间更少，用户反而更容易花更长时间投入其中，结果延长了原本完成这一任务所需的时间。
  - 这是好是坏呢？对于 ADHD，如果能减少克服启动困难所需的精力，增加干事情的时间，这无疑是不错的。说不定更长时间的投入在学习上更好呢？
Bandizip編輯檔案後未提示更新？別慌！教你秒速找回臨時存檔
- Personal anecdotes: Edit Word document and save and happily closes Bandizip — I once did the same thing many times in a single zip.
毕业十年
- 正值博主毕业，看到别人的回忆
- 因为那正好是我在农业部的一个奇葩的“体制内研究所”当科研民工的时段，所以只写了很少的文章。现在已经过去很多年了，有些事情保密性没那么强，可以补个档了
  - 感觉我这“周”报也可以这样，延迟一段固定的时间。
- 因为搞人才引进办理深圳户口时需要体检，那里的护士看了我的身份证之后瞪大了眼睛：“北京户口都不要了？”
  - 来去自由。
- 不知是不是因为老板经常拿这个网站去学术会议上炫耀，引起了上级领导的警觉。
  - 现在国内学术网站、数据集，似乎也直接挂 GitHub (Pages) 了。
In China, Coins and Banknotes Have All But Disappeared
- Personal anecdotes: I try to use cash for whole ¥ amounts (i.e. no cents when prices are added up). To my surprise the cashier is practiced. Also there are middle school students who cannot use mobile phones, which makes my pament in cash not that weird.
- (In reviews) They mistake addiction for convenience and the Tech industry loves them for it.
  Not using coins seems convenience at least for me. I cannot promise that I am able to keep a good care of my coins.
- In Yangzhou, coins are called "铅角子" kaengã'ze [outdated] / "硬币" ènbèi. The vowel of 币 should be [ɪ] / [əi] but some may pronounce it as a fricative [ɿ].
排版技术笔记1：杂感
- 野望是，搞文档产品，总是有人用。我想想，可能结合我那个内部的字体软件，可以搞一个很原子化的，自由组合式的排版库。你什么牛档马档，最后落实，不都还是字符的二维有限空间组合？
  - 输出是二维的，不过使用时不一定是。3D plotting & typesetting 你崛起吧
我在听什么
The Type — 文字 / 设计 / 文化 — 字谈字畅 258：论 AI 与预制菜
The Type
今天是 ATypI 2025 系列访谈第四期，我们有幸请到张弛与殷叶航，与大家分享人工智能在字体设计中的应用，及其对字体设计技术和商业的影响。参考链接 Snow White（白雪公主），Apple 产品线在 1980 年代末至 1990 年代使用过的设计语言 “Survive and Thrive in the AI Era”，张弛在 ATypI 2025 的演讲 “Monotype and the Marketplace: A Data Story”，Daniel Rhatigan 在 ATypI 2025 的演讲 “Font Proofer and Rethinking How We Test Type”，Peter Nowell 在 ATypI 2025 的演讲 “Words of Type, a Multilingual Encyclopedia for Typography”，Lisa Huang 在 ATypI 2025 的演讲 “Font Licensing Mess”，María Ramos 在 ATypI 2025 的演讲 “Design Aware Font Similarity”，Rishav Agarwal 和 Sanyam Jain 在 ATypI 2025 的演讲 “Towards Infinite Styles: Do We Even Need Fonts?”，殷叶航在 ATypI 2025 的演讲 Gerrit Noordzij. The stroke: theory of writing. Hyphen Press, 2006 (De Buitenkant, 2019) “Scoreboard Symphony: The Story of Traditional Ballpark Typeface Development”，Keitaro Sakamoto 和 Yuka Homma 在 ATypI 2025 的演讲嘉宾张弛：汉仪字库副总裁，字由创始人殷叶航：字体技术者和设计师，在璇玑造字做汉字艺术与设计主播 Eric：字体排印研究者，译者，The Type 执行编辑欢迎与我们交流或反馈，来信请致 podcast@thetype.com。如果你喜爱本期节目，也欢迎用支付宝向我们捐赠：hello@thetype.com。
- 字体站在人文和科技的十字路口。
  - 非常好的描述。新世界的大门在人文和科技上也需要有所建树（
- 字体作为一个基建 / 工具：例如汉仪给华为做的 Symbol，在用字体的技术解决一些更广阔的问题。
  - 本博客写过一篇关于这个字体的版权问题的文章：
    从 HarmonyOS Sans 谈起：免商字体的协议问题 | 新世界的大门
    新世界的大门
- Words of Type, a Multilingual Encyclopedia for Typography - ATypI在 ATypI 上说自己的网站的维护费用很贵。看样子这个网站是个百科性质的？
- 如今已不是一个字体匮乏的时代。可能有上千款中文字体，AI 可以帮助用户快速选择合适的。
  - AI 的应用之一，说实话比其他场景都更靠谱。
- 来自璇璣造字的暴论
  - 在 ATypI 2025 Copenhagen 上：Towards Infinite Styles: Do We Even Need Fonts?
  - Considering our vision that digital fonts as a product may eventually disappear, let us imagine the potential future roles that future type designers may become.
  - 「璇玑造字」是智琮科技的字库品牌。基于 AI，他们做了朱雀仿宋，以及本站标题的字体光锥宋。
    播客中提到，关于 AI 模型的训练「完全使用免费、免费商用、开源、自由版权和已进入公有领域的字体。」
  - 这个暴论再不放的话就晚了，再不放就有别人放了。反正迟早都要有人放的，所以我要先把它放出来。
    之前其实在去年 6 月他们一次和量子位的直播上我就听过这个暴论，这次更详细，即：
    我们现在都非常习惯于并且接受了日常生活当中大多数时候看到的文字基本上都来自于一个字体的设定，但这个设定它是否真的合理？我们已经掉进了字体的坑里，并且沉溺于字体的繁荣了。……为什么一定要贝塞尔曲线？为什么一定要勾这个贝塞尔曲线？为什么不换一种别的字形的表示方式呢？……字体（Fonts）作为一种文字的实现形式，总会有终结的一天。
  - 不管是手写的也好，还是印出来的也好，它都是字。……现在这些所谓人文温情……其实彻底从我们生活当中离开了。字体设计师在做到让大家生活在一个纯净无暇的这样的一个文字环境当中的同时，也让更多写字不好看的人可以去产出非常漂亮的文字。但另外一方面，我们又发现我们把这些手写的温情给砍掉之后，有非常多的文字风景几乎永远的消失了。
    好多把手写招牌、手写体石刻换成印刷的标准宋体黑体的，完全大奸大恶。
  - 我们处于这样一个惯性的时期，现在所有的文字渲染，所有的文字显示都是基于字体和编码这样一个模型之上的。……这套模型最早是模仿的活字印刷，非常拉丁的一个思维逻辑去做的，在很多文字上面是踢到了铁板，有很多文字它的书写和排版需求其实会给技术提出更高的要求。现在我们其实一直是在已有的技术之上去做提案，然后去修补，然后会去形成一个连人类都很难去理解的的模型。
    See The sorry state of Mongolian in Unicode. 里面还提到了一位日本设计师用阿文模型做假名的连绵。
  - 用户买一个字体，他可能就为了排一个海报标题。……蒙纳有订阅制，但用户不需要几千款字体。
    虽然标题字体是这样，但是如果字体是 on-demand 提供，需要人交流来购买字体感觉就好怪。
  - …模型突然在那段时间普遍具有了能非常好的去生成图像当中的文字的能力……我们是很早就相信这样的事情会发生。
    有时可以以假乱真。
  - 坚信我们现在所处的这样一个文字视觉环境，仍然处于吃糠咽菜阶段。我们作为一家技术公司，我们的目标是让大家吃上预制菜。
    以及，什么时候人人可以吃上丰富的开源字体预制菜、做出开源字体预制菜呢？
我在写什么
CSS

说说最近遇到的 CSS 问题。

UnoCSS

一两个月前发现的 bug：

.aaa {
  @apply text-blue-500;
  font-size: 1.5em;
  /* {} ← empty curly brace in comment will lead to wrong parsing */
  font-weight: 900;
}

生成了

/* layer: playground */
.aaa {← empty curly brace in comment will lead to wrong parsing */
font-weight: 900;
}

Reproduction 在 https://unocss.dev/play/~。

另外提交了一个 PR，支持了 Tailwind 4.1 新增的 @noscript 指令。发现 Unocss 的 mini 和 tailwind 两个 preset 有很多功能是重复的，并非继承关系。

<div class="text-blue-500 @noscript:text-red-500">
  新世界的大门
</div>

如果你禁用了 JavaScript，下面这行字应该是红色的。

新世界的大门

VS Code

写 Zeno 的桥桥给了我一段GitHub 登录页的 CSS 文件中发现的代码，是以 --数字开头的 CSS 变量 --7-grid-columns-minus-last-gap。我并不知道这是合法的 CSS，结果 VS Code 也没法正常高亮出这个来。

目前 VS Code 的语法高亮无法正确地识别

查找了一番，发现根据 spec，一个标识符（<ident-token>）不能以数字开头。但是，对于以双破折号 -- 开头的变量（CSS 自定义属性），紧跟在后面的名称可以以数字开头。

翻岁月屎书，这个对词法语法的改动是在 2014，然后 W3C 搞偷袭，还没有清晰说明：

Change the definition of ident-like tokens to allow "--" to start an ident. As part of this, rearrange the ordering of the clauses in the "-" step of consume a token so that <CDC-token>s are recognized as such instead of becoming a -- <ident-token>.

旧的形式语言如下：

于是便着手修复水 PR。VS Code 的 grammar 是我们的老熟人 tmLanguage.json，之前在《仓颉语言的 AST 操作》里讲过。内置的语法是在额外仓库 microsoft/vscode-css 维护的。但还不是 JSON，而是 cson，是 CoffeeScript 的语法。不过无妨，似乎有字符串的糖会 trim 掉多行之间的 whitespace，方便分隔正则表达式的不同部分。

  (?:[-a-zA-Z_]    | [^\\x00-\\x7F])     # First letter
  (?:[-a-zA-Z0-9_] | [^\\x00-\\x7F]      # Remainder of identifier
    |\\\\(?:[0-9a-fA-F]{1,6}|.)
  )*

把它的 First letter 行删了然后把末尾的 * 改成 +。这个变量的语法还有两处，一个是定义时，一个是使用时，后者直接是固连着 var( 的。

然后是写测试。这个测试也只是检测 token 的第若干个 token 是否是我们想要的：

it('tokenizes custom variables with a leading digit', function () {
  var tokens;
  tokens = testGrammar.tokenizeLine('.flex { grid-template-columns: var(--7-grid-columns-minus-last-gap) var(--4-grid-columns); }').tokens;
  assert.deepStrictEqual(tokens[10], { scopes: ['source.css', 'meta.property-list.css', 'meta.property-value.css', 'meta.function.variable.css', 'variable.argument.css'], value: '--7-grid-columns-minus-last-gap' });
  assert.deepStrictEqual(tokens[15], { scopes: ['source.css', 'meta.property-list.css', 'meta.property-value.css', 'meta.function.variable.css', 'variable.argument.css'], value: '--4-grid-columns' });
});

提交 PR + 解释，然后签 CLA，收到的反馈很好：

Thank you for the detailed description and fix!

LGTM

结果发现两个 approved 的人只是有 read-only 权限的，还需要一个 maintainer approve，现在还卡在这里。唉大企业

Servo

在 macOS 上尝试构建 FireFox，一切正常，非常顺利（里面有个 servo 文件夹），但构建 Servo 遇到问题，开了个 PR #37811。感觉挺搞笑的，servo 自己 rust-analyzer 可以正常工作，但构建不起来；FF 则是反过来，r-a 不行，但构建正常。前述的问题后来被 maintainer 修好了。除此之外本身没什么说头，不过我发现这位同时是 ohrs 的维护者……

Servo 运行在 macOS 上

下一代 typst 包管理器

2025-06-27T06:47:48.730Z

版权许可

本作品采用 知识共享署名—非商业性使用 4.0 国际许可协议（CC BY-NC 4.0 International）许可，阁下可自由地共享（复制、发行）和演绎（修改、转换或二次创作）这一作品，唯须遵守许可协议条款。

众所周知，Typst Universe 是 typst 生态中的三方包 registry。今天，向大家介绍新一代的 typst 包管理和三方包仓库：NPM Universe。顾名思义，就是使用一个名叫「npm」的命令行工具的 Typst Universe 替代品。

NPM Universe 如此重要，甚至被许多运行时捆绑。例如，在你的包管理器上安装 nodejs，即可获取一份 npm 的副本。

pacman -S nodejs # Arch Linux
brew install nodejs # macOS
scoop install nodejs # Windows
 
npm -v
10.9.2

当然，只有一种实现的标准并不健康。你也可以使用速度更快的 pnpm 作为替代品：

pacman -S pnpm # Arch Linux
brew install pnpm # macOS
scoop install pnpm # Windows
npm install -g pnpm # Already installed npm
 
pnpm -v
10.11.0

与以往的简约风格不同，我们开创性地引入了项目的概念，这有助于我们确定我们的 typst 文稿的依赖版本，以及定义常用的配置。执行下面的命令后，会在当前目录生成一个 package.json 文件。

npm init

NPM Universe 和 Typst Universe 一样，提供了一个社区仓库的入口，用户可以在这里检索和查阅。

为了维护各个依赖的版本信息，现在我们不再需要记住特定的版本号，而是直接使用 npm install 就可以安装最新版本了。比如，你可以安装我写的 sigfig 包来处理不确定度。

npm install typst-sigfig

与导入 Typst Universe 的 @preview 类似，我们还需要一个特定的前缀：node_modules。这是 NPM Universe 开创性的「节点模块」架构，每个 typst 包是一个单独的文件夹。

// Pre
// #import "@preview/sigfig:0.1.0": *
 
// Post
#import "node_modules/typst-sigfig/sigfig.typ": *

之所以叫作 Universe，实际上是因为这个包管理器将 typst 包存储在 node_modules 中。互联网上流传了这样一张图片，说明了 typst 生态的繁荣：

此外，NPM Universe 无需经过繁琐的审核流程，init 好之后，几分钟内即可上传你的代码：

npm publish # 初次使用需要注册账号

NPM Universe 还支持命名空间，这意味着当 typst 升级时，你可以自己将 fork 发版，不必苦苦等待作者适配发版，或者让删掉 styles 的库源码污染你的 git 历史。

一个不支持 typst 0.13 的包

更棒的是，NPM Universe 甚至还支持查看 typst 包的源码，还提供完善的代码高亮。这是上一代 Typst Universe 都没做到的功能！

astro-typst 的源码

如果你稍加设置，甚至可以在 README 中展示 typst 片段的渲染结果！

package.json

{
  ...,
  "scripts": {
    ...,
    "pub": "typst compile --features html --format html README.typ README.md && npm publish"
  }
}

当然，NPM Universe 不仅改善了 typst 生态的体验，还意外惠及了前端生态。NPM Universe 慷慨地允许前端开发者分享 Typst 的技术红利——如果你也在使用 astro-typst，可以直接在 .astro 或 .mdx 文件中导入来自 NPM Universe 的包。就以 astro-typst 中的示例来说：

import Simple from "node_modules/astro-typst/src/pages/simp.typ?svg"
 
<Simple />

NPM Universe 不仅向我们展现了开源软件千帆竞发、共建共享的繁荣与崛起，更体现了其海纳百川、兼容并蓄的自由与开放。跨语言的互操作不再是梦想——最后，谨此献上 NPM Universe 的赞歌：

jueqi.typ

#import "@preview/jogs:0.2.4": *
#set text(font: "Sart Sans", weight: 300)
#let lib = "let global = {}, setTimeout = (f, _) => {}; " + read("node_modules/echarts/dist/echarts.min.js")
#let code = ```js
const option = {
  textStyle: { fontFamily: "Sart Sans" },
  title: {
    left: "center",
    text: "Typst & 前端已经崛起了，这人还没收到通知吗？",
  },
  tooltip: { trigger: "axis" },
  legend: {
    data: ["typst/typst", "withastro/astro"],
    top: "bottom",
  },
  xAxis: {
    type: "time",
    axisLabel: {
      formatter: (value) => echarts.format.formatTime("yyyy-MM", value),
    },
  },
  yAxis: {
    type: "value",
    name: "Star Count",
  },
  series: [
    {
      name: "typst/typst",
      type: "line",
      smooth: true,
      itemStyle: {
        color: "rgb(0, 119, 255)",
      },
      areaStyle: {
        color: new echarts.graphic.LinearGradient(0, 0, 0, 1, [
          {
            offset: 0,
            color: "rgb(0, 191, 255)",
          },
          {
            offset: 1,
            color: "rgb(0, 119, 255)",
          },
        ]),
      },
      data: [
        [1679421679000, 0],
        [1679525567000, 5280],
        [1679672355000, 7950],
        [1679931973000, 10620],
        [1680520762000, 13290],
        [1682716282000, 15960],
        [1689665289000, 18630],
        [1698574915000, 21270],
        [1704566769000, 23940],
        [1711434638000, 26610],
        [1720157331000, 29280],
        [1725329624000, 31950],
        [1731535220000, 34620],
        [1739888574000, 37290],
        [1746624740000, 39960],
        [1751012293000, 43295],
      ],
    },
    {
      name: "withastro/astro",
      type: "line",
      smooth: true,
      itemStyle: {
        color: "rgb(255, 70, 131)",
      },
      areaStyle: {
        color: new echarts.graphic.LinearGradient(0, 0, 0, 1, [
          {
            offset: 0,
            color: "rgb(255, 158, 68)",
          },
          {
            offset: 1,
            color: "rgb(255, 70, 131)",
          },
        ]),
      },
      data: [
        [1627474805000, 5280],
        [1639346595000, 7950],
        [1650301136000, 10620],
        [1660134580000, 13290],
        [1660937362000, 15960],
        [1663527602000, 18630],
        [1668506551000, 21270],
        [1674623974000, 23940],
        [1678214898000, 26610],
        [1685431037000, 29280],
        [1693493029000, 31950],
        [1697513567000, 34620],
        [1704893954000, 37290],
        [1710336916000, 39960],
        [1751012349000, 51919],
      ],
    },
  ],
};
 
function generateSVG() {
  const chart = echarts.init(null, null, {
    renderer: "svg",
    ssr: true,
    width: 400,
    height: 300,
  });
 
  chart.setOption(option);
  const svg = chart.renderToSVGString();
  chart.dispose();
  return svg;
}
```
#let result = eval-js(lib + code.text + "\ngenerateSVG()")
#image(bytes(result))

六不答對之二：把我望望瞧

2025-06-23T17:28:39.351Z

決定把關於方言的系列文章塞到一個新的系列中，取名「六不答對」（亦可寫作「六不搭對」），是揚州話中驢脣不對馬嘴的意思。其中的很多內容很難查證，所以列位姑且可以把我寫的內容當作六不答對的東西來看。之前的加零表情包算第一期，這是第二期。本期淺淺寫些關於助詞的東西。

表示「替」「為」

“我给你打开灯”的“给”在其他汉语口语里也是用的同样的表示授予的动词吗？

即使是一些常見的助詞，各地用詞也是有很大差異的。對於這個問題，群友有很多回應：

代的各地方言用詞 [地圖]

數據來自維基詞典，CC BY-SA 3.0
語言	地區	詞^編/edit
Formal 白話文（Standard Chinese）		替、為
燕京官話 Northeastern Mandarin	北京 Beijing	給、替
	臺灣 Taiwan	給、替
	新加坡 Singapore	替
冀魯官話 Jilu Mandarin	濟南 Jinan	給、替
中原官話 Central Plains Mandarin	西安 Xi'an	替、給
西南官話 Southwestern Mandarin	成都 Chengdu	幫、給、跟
西南官話 Southwestern Mandarin	武漢 Wuhan	跟、幫
江淮官話 Jianghuai Mandarin	揚州 Yangzhou	代、替
江淮官話 Jianghuai Mandarin	合肥 Hefei	代、幫
晉語 Jin	太原 Taiyuan	替、給
吳語 Wu	上海 Shanghai	幫、搭
	蘇州 Suzhou	替、搭
	溫州 Wenzhou	代
湘語 Xiang	長沙 Changsha	幫、跟、代
湘語 Xiang	雙峰 Shuangfeng	幫
贛語 Gan	南昌 Nanchang	跟、幫
客家語 Hakka	梅縣 Meixian	同、代
粵語 Cantonese	廣州 Guangzhou	同、幫
	香港 Hong Kong	同、幫
	陽江 Yangjiang	替、幐
閩南語 Southern Min	廈門 Xiamen	替、共
	泉州 Quanzhou	共
	漳州 Zhangzhou	共
	臺南 Tainan	替、共
	新加坡（泉漳） Singapore (Hokkien)	替、共
	潮州 Chaozhou	代、個
	揭陽 Jieyang	個
閩東語 Eastern Min	福州 Fuzhou	替、共
閩北語 Northern Min	建甌 Jian'ou	替、幫

對於揚州話，是「代」 /tɛ/：

你代我寫封信

Lĩi dề'ô xĩi fông xìng.

（你幫我寫封信）
你代我升遠些子

Lĩi dề'ô sen yuễn'xi'dsê!

（你給我滾遠點）
我在塊尋房子，你若沒事，代我明日搬搬家。

——《清風閘》第十二回　看房成交　餪居揎屋

（對於例句，你可以將鼠標懸停在各詞上，以顯示讀音的對應關係。如果你在使用 RSS，請移玉至原文查看。）

「授予」以及把字句

與北方話相同，把字句同樣使用「把」：

哪個能讓這個過路的把身上的大衣拿了除脫，就算哪個本事大。

Lãgèu lén làng dec'geu gồlù'dii bãsen'sang'dii dàyi lá'lec tsú'tec, jièusuồn lã'geu bẽn'si dà.

——《北風跟太陽》
把門拴了。我們此刻來點了香菸，把氈條拿了來。

——《清風閘》第十回　孝姑自縊　大理相救

但揚州話的「把」還可以表示授予，即北方話的「給」。

我家只得一個燈盞掛，何能把你用？

——《清風閘》第十二回　看房成交　餪居揎屋

日常生活中，還常常會說「把我望望（瞧）」「把我看看（瞧）」。例如在這個《如果早知道》的揚州話配音中的 0∶17，

你望，你望望瞧這個彬彬，才喝幾罐就醉了哦，這個彬彬就是垃圾喔

「脫」

「脫」是一個普遍存在於吳語和淮語的助詞，一般可以理解爲「掉」。Mông-dziao 說呉語中的『不能「脫」（去完成）的動詞可以疊，比如開燈是不能說擔燈開脫的，就說開開』。

這個字在淮語中常常會被人誤寫作「得」「的」，比如南京話節目《聽我韶韶》中的字幕，這裏「掉」是指掉落，「脫」纔對應作助詞的「掉」：

……我耳屎都給她韶掉的^[sic]了

不過，揚州話中兩個虛詞掉[tiɔ]和脫[t'ǝʔ]也有區別：前者作可能補語，表示動作的可能性；後者作結果補語，表示動作的結果。兩個詞不能互換使用。

"這碗飯我喫得/不掉"：表示有/沒有能力喫完這碗飯 (可能補語)。
"這碗飯我喫脫了/沒有喫脫"：表示已經/還沒把飯喫完了 (結果補語)。

脫衣服則可以說「把衣服拿了除脫」。此外，我覺得「脫」一般有不好的 outcome。

卡脖子的艺术

2025-06-21T13:06:42.460Z

我要扼住别人的咽喉，使其不能使我完全屈服。

借用一下不知道是谁的表述来形容一下卡脖子这门艺术：卡脖子的精髓在于「用你手中仅有的一点权力去最大限度地为难其他人」。中国自古以来就是一个卡脖子大国；而这是一个每个人都在卡别人，同时又被别人卡的伟大时代。

卡脖子的例子数不胜数。一种情况是毅种循环——就以鸿蒙而言，软件不支持鸿蒙的时候，软件商卡了华为的脖子；等鸿蒙装机量上来了，攻守之势易也，不适配鸿蒙（至少在舆论上）卡了软件商的脖子；鸿蒙不让侧载，卡了玩机爱好者的脖子，而鸿蒙本身也是玩机爱好者们热爱的谷歌用来卡脖子技术的产物。总之，这是一个精妙的权力转移闭环。另一种情况则是黄雀在后——写代码的卡不会写代码的脖子，然后卡脖子工具被统治阶级用来卡写代码的脖子。主动卡别人脖子的人都成了 play 中的一环。此外，从上述这些例子看来，卡脖子行为并非是什么真正遥遥领先的技术，而是刻意刁难的选择。

在没有意义的事情上相互卡脖子令人痛苦，但鲜少招致人们的真正反对。比如，虽然嘴上都不喜欢封闭，但在我身边几乎找不到任何一个言行合一的真 FOSS 人。上一秒还在抨击国产安卓阻止用户自行安装应用的现状，下一秒就虔诚地想尽办法安装 GMS，和朋友炫耀自己的 Play Integrity 等级。如果你真的如此憎恶管控，为何不选择从 F-Droid 下载应用？如果离不开专有软件，为什么不自己用写轮眼、Shizuku 控制权限，而是需要谷歌来越俎代庖？如果自己实在是离不开某些便利的生活服务，为何不选择华为也选择了的 microG，而是想尽办法安装专有软件？表面看来真是一种奇特的精神分裂，实际上 ta 们一点也不讨厌卡脖子，不过是指望通过一个非自由软件去卡另一个非自由软件的脖子，以此来倒逼出自由。这本身就是一种天真的幻想：虽然可能有用，但这只是将自己脖子的控制权转移给另一个人而已。

在这场卡脖子游戏中，玩家们真正迷恋的从来不是什么虚无缥缈的自由，而是控制本身带来的快感，无论是控制别人，还是被一个自己认可的高级意志所控制。诚然，封闭的程度各异，但吊诡的是，囿于封闭的人寻找自由，但自由的人往往会主动选择封闭。封闭的鼓吹者从不掩饰自己的目标——给所有人戴上口球，前锁后塞；而那些看似追求自由的人却在不经意间成了自己枷锁最出色的打磨者。ta 们追求的只不过是在外观各异的电击项圈之间，选择一种更体面、更漂亮也更安逸的被卡。

而在这场循环往复的战争中，让我们看向稳坐钓鱼台的那位——它用小程序卡住了所有装外宾的人，用社会关系卡住了每一个前者的总和。它什么也没说，但它早已是这门艺术真正的、永恒的教父。我们离不开它，正如我们离不开空气，哪怕这空气有时让人窒息。它最令人钦佩的一点或许正是「被人看不惯但对方又拿妳没办法会被公开大剌剌视为一种荣耀」的态度。毕竟，能优雅地卡住所有人的脖子，本身就是这门艺术的最高成就。

光学陀螺初步

2025-06-13T18:45:57.263Z

版权许可

本作品采用 知识共享署名—相同方式共享 4.0 国际许可协议（CC BY-SA 4.0 International）许可，阁下可自由地共享（复制、发行）和演绎（修改、转换或二次创作）这一作品，唯须遵守许可协议条款。

Sagnac 效应和基本表达式

阐述 Sagnac 效应，写出其基本表达式并描述各符号物理意义，由基本表达式推导激光陀螺和光纤陀螺表达式。

Sagnac 效应是指在一个任意几何形状的闭合光学环路中，从任意一点发出的沿相反方向传播的两束光波，绕行一周返回到该点时，如果闭合光路在其平面内相对惯性空间有旋转，则两束光波的相位将发生变化。

光程差和相位差的基本表达式分别如式 1 和式 2 所示。

其中，

: 干涉仪光路包围的面积
: 旋转干涉仪的角速度
: 干涉仪光路的直径
: 干涉仪光路的周长
: 光波的波长
: 真空中光速

激光陀螺

时间差

将此时间差与光程差联系起来：

又，对于周长为 P 的激光腔，谐振频率是的整数倍。由于光程变化引起的频率变化可近似为

代入式 4，得到

又，有

这个拍频就是环形激光陀螺中测量的量。记前面的系数，即为激光陀螺的标度因数。

光纤陀螺

光纤陀螺中光纤绕成直径为、纤长为、面积为的环路，有

对于包围面积为的环路、以角速率旋转的系统，逆、顺光束的往返时间差是，记光的角频率为，则两束光经过时间差产生的相位差为

又

将式 8 和式 10 代入式 9，得

性能指标

列出光学陀螺主要性能指标，并阐述其物理意义。

零位偏置（零漂）: 位漂移或偏置漂移或零偏稳定性，是陀螺输出围绕其均值的起伏或波动，习惯上用标准偏差或均方根差表示。
随机游走（噪声）: 陀螺输出的随机波动。
标度因数: 标度是陀螺仪输出量与输入角速率的比值，标度因数通常用某一直线的斜率表示，可在整个输入范围内通过改变输入角速率所得的输出量与输入角速率数据，用最小二乘法进行拟合求得。

原理和特点

简要描述激光陀螺和光纤陀螺的原理和特点。

激光陀螺

激光陀螺用高品质因子谐振腔增强 Sagnac 效应，气体激光器产生相干光，通过分束器在环形激光腔内将激光分成顺时针和逆时针两束激光，当系统旋转时，两束光因光程差产生相位差，通过干涉测量相位差即可确定旋转速度。

激光陀螺的特点是精度高、动态范围大、可靠性高。

光纤陀螺

光纤陀螺的结构用多圈光纤实现巨大闭合光路来增强 Sagnac 效应。一束或多束激光通过耦合器进入光纤环，分成两个方向相反的光波。当系统旋转时，通过光电探测器检测两束光干涉后的信号强度变化，从而确定旋转速率。

光纤陀螺的特点是体积小、成本低，对温度等环境因素有更好的适应性。

发展历程

进一步查资料，总结「两光」陀螺发明和发展历程。

1913 年，法国科学家萨格奈克论证了采用无运动部件的光学系统同样能检测相对惯性空间的旋转。得益于连续激光器的发明，1962年作为第二代陀螺的环形激光陀螺诞生。1963 年美国 Sperry 公司采用气体激光器建立了激光陀螺装置。1964年，美国 Honeywell 公司得到空军资助开始研制激光陀螺产品，1974 年在飞机上试验成功。1976年美国犹他州立大学 V. Vali 和 R. Shorthill 教授成功进行了第三代陀螺-光纤陀螺的实验演示。90 年代，中高精度的光纤陀螺技术取得了重大突破，出现了谐振式光纤陀螺和布里渊散射式光纤陀螺。

惊鸿一瞥：仓颉语言的 AST 操作

2025-06-06T19:49:53.547Z

这是《仓颉语言程序设计》课程的大作业的实现。大作业要求使用仓颉语言开发一个运行在服务端的仓颉代码工具，实现对仓颉程序的简单语法和语义分析，同时使用前端语言设计一个简单的图形界面，在浏览器实现对代码工具的调用。这个作业主要内容就是操作仓颉代码的 AST。

功能需求

以下内容为作业要求摘录，有改动。脚注为要求原文所加。

后端功能需求

1. 功能接口

创建一个仓颉项目，在源代码根目录（src）下创建 CJCodeTool 类，编写代码实现该类中的四个静态函数。每一个静态函数代表一个基础的代码分析/修改功能，它们都接受一个代表单文件代码文本的字符串类型参数 code，经过一系列处理之后返回处理结果字符串¹。

除了这四种功能以外，你可以至多额外添加一种自定义功能，该功能的复杂度和实现效果会被纳入评分考量。

(a) `generateCodeSignature` 函数

该函数的功能是生成代码文件的签名。此处的“签名”包含“函数签名”和“类（接口）签名”²，具体到仓颉语言，可以理解为定义接口时使用的无实现成员函数。而类签名则包含了类的声明语句以及它内部成员（包括属性，变量，函数）的签名。

具体来说，对于变量、属性、函数、类和接口，签名按次序包含以下内容：

i. 修饰符（如 public）。注意：修饰符可能不存在。
ii. 关键字（如 func）。
iii. 标识符，即命名。
iv. （对于类和接口）以 <: 开头的父接口/类序列，使用 & 连接。注意：该部分可能不存在。
v. （对于函数）参数列表。该部分和源代码保持一致即可。
vi. （对于变量、属性和函数）以冒号开头的返回类型。如果源代码中未显式声明返回类型，则签名中同样不用包含。
vii. （对于类和接口）内部声明的签名。

数据限制：

文件中的一级声明（即最外层的声明）只包含函数（FuncDecl 类）、类（ClassDecl 类）和接口（InterfaceDecl 类）声明；
类和接口内部只包含变量（VarDecl 类）、属性（PropDecl 类）和函数（FuncDecl 类）声明；
函数内部只包含变量声明；
不将形参声明（FuncParam 类）视为声明，也就是不必将其纳入是否满足数据限制的考虑；
不存在泛型类、接口和函数声明；
不存在操作符重载函数声明。

输出要求：

按顺序输出文件中所有函数、类和接口的签名（即图2右图的格式）。对于不符合数据限制的输入，返回字符串 'ILLEGAL INPUT'。
单次缩进为四个空格，每一个签名之间有一个空行。
词法单元之间的空格规范不做要求（但要保证语法正确性）。

(b) `refactorVariable` 函数

该函数的功能是通过 path 参数指定代码中的一个类或者函数，然后将其作用域内的某个标识符（oldName）全部替换为另一个标识符（newName）。对于函数，作用域是函数签名和函数体这个整体，对于类也完全类似。

输入规范：

path：形如 '函数名'、'类名'、'类名.函数名' 的格式。第一种是最外层的函数（不属于任何类的函数）。

数据限制：

不存在内层变量覆盖、重载等影响重构作用域和路径搜索的特殊情况；
标识符都是合法的普通标识符，并且不会和内置类型标识符重名；
使用 std.ast 包解析之后的语法树只存在如下类型的节点：
AssignExpr, BinaryExpr, Block, Body, ClassDecl, Decl, Expr, ForInExpr,
FuncDecl, FuncParam, IfExpr, ImportContent, ImportList, LitConstExpr,
Modifier, Node, PackageHeader, ParenExpr, Pattern, PrimitiveType,
RangeExpr, RefExpr, RefType, ReturnExpr, Token, Tokens, TypeNode,
UnaryExpr, VarDecl, VarPattern。

输出要求：

输出重构后的完整代码。对于不符合数据限制的输入，返回字符串 'ILLEGAL INPUT'。
词法单元之间的空格和换行规范不做要求（但要保证语法正确性）。

(c) `generateDocument` 函数

该函数的功能是通过 path 参数指定代码中的一个类或者函数，然后为其生成解释文档（以块注释的形式展示），用于解释该类或者函数的功能。

输入规范：

path：形如 '函数名'、'类名'、'类名.函数名' 的格式。第一种是最外层的函数（不属于任何类的函数）。

数据限制：

同上（路径仅为三种形式，且必须存在）。

输出要求：

输出生成文档后的完整代码。对于不符合数据限制的输入，返回字符串 'ILLEGAL INPUT'；
除了插入的文档所在的行，其他行的内容与格式应当与源文件完全相同。

(d) `foldConstant` 函数

该函数的功能是将代码中可直接计算的常量进行折叠³，不考虑常量传播。

输入规范：

代码中的常量运算一定合法；
不存在不同字面量类型之间的类型转换；
不存在计算溢出情况。

数据限制：

同上，与 refactorVariable 相同；
字面量只包含 Float64 和 Int64，无前后缀；
运算只包含加/减/乘/除/模和取负。

输出要求：

输出重构后的完整代码。对于不符合数据限制的输入，返回字符串 'ILLEGAL INPUT'；
常量必须被完全折叠；
类型保持不变，浮点数保留位数不做限制；
空格和换行不做要求（保证语法正确性）；
不考虑常量传播。

2. HTTP 服务器

使用仓颉语言的网络编程接口自行设计一个 HTTP 服务器，根据请求路径和报文数据调用相应的功能函数，然后将返回值添加到响应报文中进行响应。

前端功能需求

自行设计并用前端编程语言（html，css，js 等）或前端框架（vue，react 等）编写一个网页，实现对后端各功能接口的调用，页面操作逻辑形式不限。

一种简单的实现思路是：网页仅包含一个文本输入框和一个提交按钮，将调用的功能接口和除 code 以外参数写在第一行，剩余行输入待处理的代码。点击按钮之后，将文本框内容提交至后端进行处理，最后将返回内容以 html 段落的形式展示出来。

本大作业重点在于仓颉语言的综合运用，故无需在前端耗费过多工作量。

实现方式限制

对于后端的所有代码处理函数，请使用仓颉的 std.ast 标准库进行处理。正则表达式或序列处理很难完全实现预期功能；
对于 generateDocument 函数中的文档生成，必须调用 LLM API 来完成，建议使用 DeepSeek；
对于文档的插入，由于仓颉语法树中不存在注释类型节点，建议通过语法树获取类/函数签名所在行列数之后直接使用字符串方法进行插入；
请将主函数单独放在源代码根目录（src）下的 main.cj 文件中。

前端

前端部分使用 React 搭建界面。

代码高亮

采用了 Monaco 提供仓颉代码高亮。Monaco Editor 采用了一种名为 Monarch 的声明式词法规范。通过定义一系列正则表达式规则为词法单元分配特定的类型。

首先创建 editor-config.js，定义 languageDef 对象，包含 keywords、typeKeywords（类型相关的关键字）、operators（操作符）、symbols（符号的正则表达式）和 escapes（字符串中的转义字符规则）。最核心的部分是 tokenizer，它是一个状态机，通过定义一系列正则表达式规则，将代码片段赋予特定的词法类型。

在 CodeInput.tsx React 组件中，使用 @monaco-editor/react 包提供的 Editor 组件。在 editorBeforeMount 函数内部，调用 languages.register({ id: 'cangjie' }) 来注册新语言。然后用 monaco.languages.setMonarchTokensProvider('cangjie', languageDef) 将之前定义的 Monarch 词法规则与 'cangjie' 语言 ID 关联起来，monaco.languages.setLanguageConfiguration('cangjie', configuration) 将语言行为配置与 'cangjie' 语言 ID 关联。在 Editor 组件上设置 defaultLanguage="cangjie" 即可。

HttpServer

主要踩的坑

std.ast.cangjieLex()、parseProgram 甚至部分结构体的 toTokens() 都不是线程安全的，需要调用 CJCodeTool 类中的方法时 spawn：

let output = spawn { CJCodeTool.generateDocument(...) }.get()

类似 Rust，仓颉支持尾语句作为块的返回值，所以写起来不算麻烦。

CORS

现代浏览器在进行网络请求时，会遵循同源策略（Same-Origin Policy），不允许跨域请求，即对于 $协议域名端口$ 这一三元组，如果两个请求的这一三元组不同，则不允许跨域请求。

前端之猫

这是一段经典的前端八股。

因此，如果需要跨域请求，最好的方法是在服务器端设置 CORS 头。

func sendRes(httpContext: HttpContext, output: String) {
    let headers = HttpHeaders()
    // cors
    headers.add("Access-Control-Allow-Origin", "*")
    headers.add("Access-Control-Allow-Methods", "POST, GET")
    headers.add("Access-Control-Allow-Headers", "Content-Type")
    // 设置 content-type
    headers.add("Content-Type", "text/plain")
    httpContext.responseBuilder.addHeaders(headers).body(output)
}

当然，还有下策：

我草 CORS 怎么这么坏啊

(a) `generateCodeSignature` 函数

该函数的功能是生成代码文件的签名。此处的“签名”包含“函数签名”和“类（接口）签名”，具体到仓颉语言，可以理解为定义接口时使用的无实现成员函数。而类签名则包含了类的声明语句以及它内部成员（包括属性，变量，函数）的签名。

实现步骤

使用 cangjieLex(code) 将输入的代码字符串词法分析为 Tokens。
使用 parseProgram(tokens) 将 Tokens 解析为抽象语法树（AST），根节点为 Program 类型。
遍历 program.decls 中的顶层声明。通过模式匹配（match 表达式）区分 FuncDecl（函数声明）、ClassDecl（类声明）和 InterfaceDecl（接口声明）。
对于 FuncDecl：直接提取其函数体起始花括号之前的所有 token。
对于 ClassDecl 和 InterfaceDecl：提取其修饰符、class / interface 关键字、名称、父接口/类序列（如果存在）。然后递归处理其内部成员（VarDecl、PropDecl、FuncDecl），提取这些成员的签名，并进行适当的缩进。类/接口的实现体被省略，仅保留签名的嵌套结构。
实现中，通过获取声明节点的 toTokens()，然后有选择地拼接或替换部分 Token（例如，将类或函数体的 {...} 替换为仅包含成员签名的 {...}）来构造最终的签名字符串。
输出时，确保每个签名之间有空行，缩进使用四个空格。这部分是根据序列化后的实现行为手动加入空行。
若输入不符合数据限制（如顶层声明包含非函数、类、接口，或内部声明不符合要求），则返回 "ILLEGAL INPUT"。

模式匹配类型的语法

tool.cj

class CJCodeTool {
    static func generateCodeSignature(code: String): String {
        let tokens = cangjieLex(code)
        // 任何一个仓颉源码文件都可以被解析为一个 Program 类型。
        let program = parseProgram(tokens)
        let sig = quote()
        for (decl in program.decls) {
            let result = match (decl) {
                case d: FuncDecl => genFuncSig(d)
                case d: ClassDecl => genClassSig(d)
                case d: InterfaceDecl => genInterfaceSig(d)
                case _ => throw Exception("Unexpected Decl")
            } |> sig.append
        }
        return trimTokensEnd(sig).toString()
    }

直接截断

对于 genBlockSig 和 genBodySig 函数，它们分别用于生成函数块和类/接口体的签名。genBlockSig 直接返回空的 Tokens，因为函数签名不需要包含函数体的实现细节。而 genBodySig 则需要递归处理类/接口体内的成员声明，保留其签名结构。

public func genFuncSig(funcDecl: FuncDecl): Tokens {
    let tokens = funcDecl.toTokens()
    let blockSig = genBlockSig(funcDecl.block)
    return genSig(tokens, funcDecl.block.lBrace, funcDecl.block.rBrace, blockSig)
}
 
public func genClassSig(classDecl: ClassDecl): Tokens {
    let tokens = classDecl.toTokens()
    let bodySig = genBodySig(classDecl.body)
    return genSig(tokens, classDecl.body.lBrace, classDecl.body.rBrace, bodySig)
}
 
public func genInterfaceSig(interfaceDecl: InterfaceDecl): Tokens {
    let tokens = interfaceDecl.toTokens()
    let bodySig = genBodySig(interfaceDecl.body)
    return genSig(tokens, interfaceDecl.body.lBrace, interfaceDecl.body.rBrace, bodySig)
}

相等的条件：完全一致

仓颉中 Token 判断相等的条件是位置完全一致，所以不会出现仅仅是重复的 Token 就被认为是相等的情况。借助这个特性，我们可以通过 lParen 等特殊 token 来截取之前的部分。

func genSig(tokens: Tokens, lParen: Token, rParen: Token, innerSig: Tokens): Tokens {
    let sig = quote()
    var isInBlock = false
    for ((index, token) in enumerate(tokens)) {
        if (token == lParen) {
            sig.append(token)
            isInBlock = true
            sig.append(genNewLines(1))
            sig.append(innerSig)
        } else if (token == rParen) {
            sig.append(genNewLines(1))
            sig.append(token)
            isInBlock = false
        } else if (!isInBlock) {
            sig.append(token)
        }
    }
    sig.append(genNewLines(1))
}

测试用例

输入

interface I1 {
    mut prop size: Int64
}
 
class C <: I1 {
    private var mySize = 0
 
    public mut prop size: Int64 {
        get() {
            mySize
        }
        set(value) {
            mySize = value
        }
    }
 
    public func getSize() {
        mySize
    }
}
 
public func testC() {
    let a: I1 = C()
    a.size = 5
    if (a.size == 5) {
        println("Do nothing")
    } else {
        println("Do nothing")
    }
    println(a.size)
}

输出

interface I1 {
    mut prop size: Int64
}
 
class C <: I1 {
    private var mySize
    
    public mut prop size: Int64
    
    public func getSize()
}
 
public func testC() {
    
    
}

(b) `refactorVariable` 函数

该函数的功能是通过path 参数指定代码中的一个类或者函数，然后将其作用域内的某个标识符（oldName）全部替换为另一个标识符（newName）。对于函数，作用域是函数签名和函数体这个整体，对于类也完全类似。

实现步骤

将输入代码 code 解析为 AST。
解析 path 参数（如 "函数名", "类名", "类名.函数名"）以定位目标作用域。
遍历 program.decls 找到路径的第一部分匹配的顶层声明（函数或类）。
如果路径包含 "." (如 "类名.函数名")，则在找到的类声明内部继续查找匹配的函数名。
一旦定位到目标作用域（FuncDecl 或 ClassDecl 节点），将其转换为 Tokens。
遍历这些 Tokens，当遇到 TokenKind.IDENTIFIER 且其 value 等于 oldName 时，将其替换为一个新的 Token，其 kind 仍为 TokenKind.IDENTIFIER，但 value 为 newName。
将修改后的 Tokens 重新组合成字符串。
如果 path 在源代码中不存在或不符合数据限制，返回 "ILLEGAL INPUT"。

主要思想

由于作业要求中明确写了

词法单元之间的空格和换行规范不做要求（但要保证语法正确性），

因此可以直接修改语法树，然后再将语法树转换为词法单元。这样虽然会丢掉原来的空格和换行，但是比直接替换 tokens 要方便得多。

static func refactorVariable(code: String, path: String, oldName: String, newName: String): String {
    let tokens = cangjieLex(code)
    let program = parseProgram(tokens)
    let pathParts = path.split(".")
    for (i in 0..program.decls.size) {
        let decl = program.decls[i]
        if (decl.identifier.toTokens().toString() == pathParts[0]) {
            let replaced = refactorByPath(decl, path, oldName, newName)
            let newDecl = parseDecl(replaced)
            program.decls[i] = newDecl // 词法单元之间的空格和换行规范不做要求（但要保证语法正确性）
            return program.toTokens().toString()
        }
    }
    throw Exception("Variable not found")
}

其实应直接修改 AST 节点中的标识符，然后调用整个 Program 节点的 toTokens().toString() 生成新代码，但仓颉的 AST 各个节点类的字段都是不可变的。因此本实现在定位到具体节点后，对其 toTokens() 的结果进行操作，然后将这部分修改后的 tokens 插入回整体代码结构中。

一些假设

由于这些假设，我们可以直接遍历 program.decls 找到目标声明，然后直接对其 toTokens() 的结果进行替换：

路径唯一且合法；
作用域明确且无变量遮蔽，不考虑形参与内部变量冲突；
不会重载函数；
仅通过词法替换实现重构；
被替换的 oldName 出现在语法树中 toTokens() 的结果中。

public func refactorByPath(decl: Decl, path: String, oldName: String, newName: String): Tokens {
    var tokens = decl.toTokens()
    if (let Some(index) <- path.indexOf(".")) {
        let parts = path.split(".")
        let funcName = parts[1]
        let replaced = quote()
        let classDecl = (decl as ClassDecl).getOrThrow()
        let innerDecls = classDecl.body.decls
        for (i in 0..innerDecls.size) {
            let innerDecl = innerDecls[i]
            if (innerDecl.identifier.toTokens().toString() == funcName) {
                let replaced = refactorByPath(innerDecl, funcName, oldName, newName)
                let newDecl = parseDecl(replaced)
                classDecl.body.decls[i] = newDecl
                tokens = classDecl.toTokens()
                return tokens
            }
        }
        throw Exception("No method found")
    } else {
        let replaced = quote()
        for (token in tokens) {
            if (token.kind == TokenKind.IDENTIFIER && token.value == oldName) {
                replaced.append(Token(TokenKind.IDENTIFIER, newName))
            } else {
                replaced.append(token)
            }
        }
        replaced
    }
}

测试用例

重构参数：testC,a,b

代码输入：

public func testC() {
    let a: I1 = C()
    a.size = 5
    if (a.size == 5) {
        println("Do nothing")
    } else {
        println("Do nothing")
    }
    println(a.size)
}

输出：

public func testC() {
    let b: I1 = C()
    b.size = 5
    if(b.size == 5) {
        println("Do nothing")
    }
    else {
        println("Do nothing")
    }
    println(b.size)
}

测试用例：DocumentReq.deserialize,dms,dataModels

class DocumentReq <: Serializable<DocumentReq> {
    var code: String = ""
    var path: String = ""
 
    public DocumentReq(code: String, path: String) {
        this.code = code
        this.path = path
    }
 
    public func serialize(): DataModel {
        return DataModelStruct().add(field<String>("code", code)).add(field<String>("path", path))
    }
 
    public static func deserialize(dm: DataModel): DocumentReq {
        var dms = match (dm) {
            case data: DataModelStruct => data
            case _ => throw Exception("this data is not DataModelStruct for DocumentReq")
        }
        let code = String.deserialize(dms.get("code"))
        let path = String.deserialize(dms.get("path"))
        DocumentReq(code, path)
    }
}

class DocumentReq <: Serializable < DocumentReq > {
    var code: String = ""
    var path: String = ""
    public DocumentReq(code: String, path: String) {
        this.code = code
        this.path = path
    }
    public func serialize(): DataModel {
        return DataModelStruct().add(field < String >("code", code)).add(field < String >("path", path))
    }
    public static func deserialize(dm: DataModel): DocumentReq {
        var dataModels = match(dm) {
            case data: DataModelStruct => data
            case _ => throw Exception("this data is not DataModelStruct for DocumentReq")
        }
        let code = String.deserialize(dataModels.get("code"))
        let path = String.deserialize(dataModels.get("path"))
        DocumentReq(code, path)
    }
}

(c) `generateDocument` 函数

该函数的功能是通过path 参数指定代码中的一个类或者函数，然后为其生成解释文档（以块注释的形式展示），用于解释该类或者函数的功能。

实现步骤

初始化 LLM 类，配置了 API 地址、从 .key.txt 文件读取的密钥、使用的模型名称（如 Qwen/Qwen3-8B）以及启用记忆功能；
为 LLM 设置了一个系统级指令；
构建一个发送给 LLM 的具体提示词（prompt），包含指令以及用户提供的完整代码；
将此提示发送给 LLM 进行处理，并获取 LLM 返回的结果。由于采用 8B 模型，所以没有使用流式对话。

测试用例

输入

package final
 
import std.io.StringReader
import std.time.Duration
import encoding.json.*
import net.http.*
import net.tls.*
 
enum Role <: ToString {
    I | AI | System
 
    public func toString() {
        match (this) {
            case I => 'user'
            case AI => 'assistant'
            case System => 'system'
        }
    }
}
 
class LLM {
    let client: Client
    let history = StringBuilder()
    public LLM(let url!: String, let key!: String, let model!: String, let memory!: Bool = false) {
        var config = TlsClientConfig()
        config.verifyMode = TrustAll
        client = ClientBuilder().tlsConfig(config).readTimeout(Duration.Max).build()
    }
 
    func encode(role: Role, content: String) {
        '{"role":"${role}","content":${JsonString(content)}}'
    }
 
    func send(input: String, stream!: Bool = false) {
        let message = encode(I, input)
        let content = '{"model":"${model}","messages":[${history}${message}],"stream":${stream}}'
        if (memory) {
            history.append(message)
        }
        let request = HttpRequestBuilder()
            .url(url)
            .header('Authorization', 'Bearer ${key}')
            .header('Content-Type', 'application/json')
            .header(
                'Accept',
                if (stream) {
                    'text/event-stream'
                } else {
                    'application/json'
                }
            )
            .body(content)
            .post()
            .build()
        client.send(request)
    }
 
    func parse(text: String, stream!: Bool = false) {
        println(text)
        let json = JsonValue.fromStr(text).asObject()
        let choices = json.getFields()['choices'].asArray()
        // 流式和非流式情况下，这个字段名称不同
        let key = if (stream) {
            'delta'
        } else {
            'message'
        }
        let message = choices[0].asObject().getFields()[key].asObject()
        let content = message.getFields()['content'].asString().getValue()
        return content
    }
 
    public func chats(input: String, task!: (String) -> Unit = {o => print(o)}) {
        const INDEX = 6
        let response = send(input, stream: true)
        let output = StringBuilder()
        let buffer = Array<Byte>(1024 * 8, item: 0)
        var length = response.body.read(buffer)
        while (length != 0) {
            let text = String.fromUtf8(buffer[..length])
            for (line in text.split('\n', removeEmpty: true)) {
                if (line.size > INDEX && line[INDEX] == b'{') {
                    let json = line[INDEX..line.size]
                    let slice = parse(json, stream: true)
                    if (memory) {
                        output.append(slice)
                    }
                    task(slice)
                }
            }
            length = response.body.read(buffer)
        }
        if (memory) {
            history.append(',${encode(AI, output.toString())},')
        }
    }
 
    public func chat(input: String) {
        let response = send(input)
        let output = StringReader(response.body).readToEnd() |> parse
        if (memory) {
            history.append(',${encode(AI, output)},')
        }
        return output
    }
 
    public func preset(memory: Array<(Role, String)>) {
        history.reset()
        for ((role, message) in memory) {
            history.append(encode(role, message) + ',')
        }
    }
 
    public func reset() {
        history.reset()
    }
}

输出

public func chats(input: String, task!: (String) -> Unit = {o => print(o)}) {
    /**
     * 发送流式聊天请求并实时处理响应内容
     * 
     * @param input 用户输入内容
     * @param task 处理每一块响应内容的回调函数
     *              该函数接收String参数，返回Unit
     * @return 无返回值
     * 
     * 注意:
     * 1. 该方法使用stream模式发送请求
     * 2. 通过task回调实时接收并处理响应内容
     * 3. 若启用memory，会将AI回答内容追加到history
     * 4. 每次调用会重置当前聊天会话的流式状态
     */
    const INDEX = 6
    let response = send(input, stream: true)
    let output = StringBuilder()
    let buffer = Array<Byte>(1024 * 8, item: 0)
    var length = response.body.read(buffer)
    while (length != 0) {
        let text = String.fromUtf8(buffer[..length])
        for (line in text.split('\n', removeEmpty: true)) {
            if (line.size > INDEX && line[INDEX] == b'{') {
                let json = line[INDEX..line.size]
                let slice = parse(json, stream: true)
                if (memory) {
                    output.append(slice)
                }
                task(slice)
            }
        }
        length = response.body.read(buffer)
    }
    if (memory) {
        history.append(',${encode(AI, output.toString())},')
    }
}

(d) `foldConstant` 函数

该函数的功能是将代码中可直接计算的常量进行折叠，不考虑常量传播。例如，如果代码中存在一句 let a = 3 + 2，则折叠之后这句代码就变为 let a = 5。

使用 `visitor` 访问节点

仓颉的 Visitor 类体现了重载的方便之处：只需要实现想要处理的类型的函数实现即可。

class MyVisitor <: Visitor {
    public var result = ArrayList<BinaryExpr>()
 
    private func isConstExpr(expr: BinaryExpr): Bool {
        let isLeftConst = match (expr.leftExpr) {
            case left: LitConstExpr => true
            case left: BinaryExpr => isConstExpr(left)
            case left: ParenExpr => isConstExpr(left)
            case left: UnaryExpr => isConstExpr(left)
            case _ => false
        }
        if (!isLeftConst) { // early return
            return false
        }
        let isRightConst = match (expr.rightExpr) {
            case right: LitConstExpr => true
            case right: BinaryExpr => isConstExpr(right)
            case right: ParenExpr => isConstExpr(right)
            case right: UnaryExpr => isConstExpr(right)
            case _ => false
        }
        isRightConst
    }
 
    private func isConstExpr(expr: UnaryExpr): Bool {
        match (expr.op) {
            ...
        }
    }
 
    private func isConstExpr(expr: ParenExpr): Bool {
        match (expr.parenthesizedExpr) {
            case inner: BinaryExpr => isConstExpr(inner)
            case inner: LitConstExpr => true
            case inner: ParenExpr => isConstExpr(inner)
            case inner: UnaryExpr => isConstExpr(inner)
            case _ => false
        }
    }
 
    public override func visit(expr: BinaryExpr) {
        if (isConstExpr(expr)) {
            result.append(expr)
            breakTraverse() // 不会继续遍历子节点
        }
        return
    }
}
 
...
let program = parseProgram(tokens)
program.traverse(visitor)

解析为 AST（抽象语法树）后，使用 visitor 访问节点
定位所有 BinaryExpr，确保只处理结构合法且可折叠的目标
终止的条件是 BinaryExpr 递归到所有子节点没有变量等标识符
仓颉不支持边访问边替换，将结果收集起来

处理不同数值类型

enum ConstLit <: ToString {
    Float(Float64) | Int(BigInt)
 
    public func toToken(): Token { ... }
    ...
}
...
    match ((left, right)) {
      case (ConstLit.Float, ConstLit.Float) => ...
      case (ConstLit.Int, ConstLit.Int) => ...
    }

整数和浮点数分别使用 BigInt 和 Float64 类型，避免精度丢失或类型错误。
用 ConstLit 枚举包裹值类型，统一抽象、便于扩展。

递归计算收集的常量表达式

private func calculateLit(left: ConstLit, op: Token, right: ConstLit): ConstLit {
    match ((left, right)) {
        case (ConstLit.Float(left), ConstLit.Float(right)) => ConstLit.Float(calculateFloat(left, op, right))
        case (ConstLit.Int(left), ConstLit.Int(right)) => ConstLit.Int(calculateInteger(left, op, right))
        case _ => throw Exception("Unexpected ConstLit")
    }
}
 
private func calculateExpr(expr: LitConstExpr): ConstLit {
    let token = expr.toTokens()[0]
    match (token.kind) {
        case TokenKind.FLOAT_LITERAL => ConstLit.Float(Float64.parse(token.value))
        case TokenKind.INTEGER_LITERAL => ConstLit.Int(BigInt(token.value))
        case _ => throw Exception("Unexpected ConstLit")
    }
}
 
private func calculateExpr(expr: Expr): ConstLit {
    match (expr) {
        case expr: LitConstExpr => calculateExpr(expr)
        case expr: BinaryExpr => calculateExpr(expr)
        case _ => throw Exception("Unexpected Expr")
    }
}
 
private func calculateExpr(expr: BinaryExpr): ConstLit {
    let left = calculateExpr(expr.leftExpr)
    let right = calculateExpr(expr.rightExpr)
    calculateLit(left, expr.op, right)
}

在原始 token 流中直接定位并替换

Tokens 类不是 Array，缺少很多功能，不知道怎么想的。

let startIndex = findTokenIndex(tokens, left)
let endIndex = findTokenIndex(tokens, right)
newTokens = replaceTokensByRange(newTokens, startIndex..endIndex, foldedToken)

通过逆序处理避免 token 替换错位：

public func comparePos(a: Position, b: Position): Ordering {
    match (a.line.compare(b.line)) {
        case Ordering.EQ => a.column.compare(b.column)
        case notEq => notEq
    }
}
...
exprs.sortBy(stable: false) {
  b: BinaryExpr, a: BinaryExpr => comparePos(a.beginPos, b.beginPos)
}

测试用例

输入

interface I1 {
    mut prop size: Int64
}
 
class C <: I1 {
    private var mySize = -10 * (3 + 2 * 4) + (-2) * 2 // -114
    private var mySizeBin = 2 * 4
    private var floatSize: Float32 = 3.0 + 4.5 / 3.3
    private var mySize2 = (32 / 4) % 5
 
    public mut prop size: Int64 {
        get() {
            mySize + mySize2 + (233 -666)
        }
        set(value) {
            mySize -= value
        }
    }
 
    public func getSize() {
        mySize
    }
}
 
public func testC() {
    let a: I1 = C()
    a.size = 12-3*5/(5+6%4)
    if (a.size == 23-5) {
        println("Do nothing")
    } else {
        println("Do nothing")
    }
    println(a.size)
}

输出

interface I1 {
    mut prop size: Int64
}
 
class C <: I1 {
    private var mySize = -114 // -114
    private var mySizeBin = 8
    private var floatSize: Float32 = 4.363636
    private var mySize2 = 3
    
    public mut prop size: Int64 {
        get() {
            mySize + mySize2 +(-433)
        }
        set(value) {
            mySize -= value
        }
    }
    
    public func getSize() {
        mySize
    }
}
 
public func testC() {
    let a: I1 = C()
    a.size = 10
    if(a.size == 18) {
        println("Do nothing")
    } else {
        println("Do nothing")
    }
    println(a.size)
}

(e) `generateJsonAst` 自定义功能

将仓颉代码解析后的 AST 转换为 JSON 格式的字符串。此功能有助于理解 AST 结构，也可用于与其他 AST 可视化工具（如 astexplorer.net 的自定义解析器）集成。

实现思路

使用 cangjieLex(code) 和 parseProgram(tokens) 得到 AST (Program 类型)。
设计一系列递归的 toJson 转换函数，每个函数对应一种 AST 节点类型。
每个 toJson 函数会创建一个 JsonObject。将节点类型和节点的属性作为键值对添加到 JsonObject 中。
如果节点的属性本身也是 AST 节点（如函数体 Block 是一个节点，它包含一系列 Stmt 节点组成的数组），则递归调用相应的 toJson 函数处理这些子节点，并将结果（JsonObject | JsonArray）作为父对象的属性值。
基本类型的属性直接作为 JSON 值。Token 类型的信息，如位置（beginPos, endPos），也一并转换为 JSON 对象。
program.decls 是一个 ArrayList<Decl>，会被转换成一个 JsonArray，数组中的每个元素是对应 Decl 节点转换后的 JsonObject。
最终，整个 Program AST 被转换为一个顶层的 JsonObject 或 JsonArray，然后序列化为 JSON。

为所有 AST 节点类型编写转换函数会导致代码量较大，编译时间也相应增加。即使用了宏，代码量也达到了惊人的上千行。这堆宏具体也是在网页文档中 document.querySelectorAll() 所有标题后复制出来，批量编辑了后写了个 Python 生成的。

前端之猫

代码生成也是一种元编程。

为什么这么想不开呢？这是因为文档里说：

在仓颉编程语言中，所有的泛型都是不型变的。这意味着如果 A 是 B 的子类型，ClassName<A> 和 ClassName<B>之间没有子类型关系。我们禁止这样的行为以保证运行时的安全。

因此，我们无法通过反射判断 ArrayList<Decl> 中的 Decl 是 ClassDecl 还是 FuncDecl 之类。虽然我们可以写出

func toJson(node: Node): JsonObject {
    ...
    let typeinfo = TypeInfo.of(node)
    for (property in typeinfo.instanceProperties) {
        let name = property.name
        let valueInfo = typeinfo.getInstanceProperty(name)
        if (valueInfo.typeInfo.qualifiedName.startsWith("std.collection.ArrayList")) {
            obj.put(name, castArray(node, valueInfo))
        } else {
            let value = valueInfo.getValue(node)
            if (let Some(value) <- value as Node) {
                obj.put(name, toJson(value))
            } else {
                println("No value for ${name} ${valueInfo.typeInfo.qualifiedName}")
            }
        }
    }
    obj
}
 
func toJson<T>(value: ArrayList<T>): JsonArray where T <: Node {
    let arr = JsonArray()Add commentMore actions
    for (elem in value) {Add commentMore actions
        arr.add(toJson(elem))
    }
    arr
}

但 castArray 还是都需要判断一遍：

func castArray(node: Node, valueInfo: InstancePropertyInfo): JsonArray {
    if (let Some(value) <- valueInfo.getValue(node) as ArrayList<ast.Annotation>) {
        toJson<ast.Annotation>(value)
    } else if (let Some(value) <- valueInfo.getValue(node) as ArrayList<Argument>) {
        toJson<Argument>(value)
    } else if (let Some(value) <- valueInfo.getValue(node) as ArrayList<ArrayLiteral>) {
        toJson<ArrayLiteral>(value)
    } else if (let Some(value) <- valueInfo.getValue(node) as ArrayList<AsExpr>) {
        toJson<AsExpr>(value)
    } else ...

编译时间过长，完全不可用。所以最后还是手动对允许继承的类进行类型判断，如下：

func toJson(decls: ArrayList<Decl>): JsonArray {
    let arr = JsonArray()
    for (decl in decls) {
        let res = match (decl) {
            case d: ClassDecl => toJson(d)
            case d: EnumDecl => toJson(d)
            case d: ExtendDecl => toJson(d)
            case d: FuncDecl => toJson(d)
            case d: FuncParam => toJson(d)
            case d: InterfaceDecl => toJson(d)
            case d: MacroExpandDecl => toJson(d)
            case d: MacroDecl => toJson(d)
            case d: MainDecl => toJson(d)
            case d: PrimaryCtorDecl => toJson(d)
            case d: PropDecl => toJson(d)
            case d: StructDecl => toJson(d)
            case d: VarDecl => toJson(d)
            case d: TypeAliasDecl => toJson(d)
            case d: Decl => return arr
        }
        arr.add(res)
    }
    arr
}

生成代码

目前仓颉的增量编译非常局限，导致整个项目的编译时间增加了 800%。可以通过放到单独的包里来解决一部分性能问题。

`quote`

仓颉的 quote 是一个用于生成 Tokens 的特殊语法，其中可以直接写表达式，然后会被转换为 Tokens。比如可以这样生成空行：

let nl = quote(
)

嵌入变量使用 $(变量名) 的形式。但是，对于在一个变量名外加双引号作为字符串，就比较麻烦了：

quote(obj.put($("tokens"), toJson(token.$(tokens))))

这样只会生成 obj.put("tokens", toJson(token.变量名))，而不是 obj.put("变量名", toJson(token.$("变量名")))。因此，我采取的做法是

public macro put(tokens: Tokens): Tokens {
    let wrapped = Token(TokenKind.STRING_LITERAL, tokens.toString())
    let res = quote(
        obj.put($(wrapped), toJson(token.$(tokens)))
    )
    res
}

astexplorer

astexplorer 是一个用于可视化 AST 的工具，支持多种语言。我们将仓颉的 AST 转换为 JSON 后，在 astexplorer 中可以方便地查看。鼠标可悬浮在对应位置跳转到语法树，反之亦然。

astexplorer

注意 astexplorer 项目需要使用 Node 16。

volta pin node@16 # 使用 volta 管理 node 版本
cd astexplorer
yarn install
cd website
yarn start

适配 astexplorer 需要添加新的语言 parser。

async loadParser{：js} 函数在本实现中仅调用回调，因为仓颉目前没法像其他语言一样编译到 WASM，我们在 async parse 中负责接收 Cangjie 代码，计算每行起始偏移量，并通过 fetch 向本地服务 /ast 发送 POST 请求以获取 AST。
getNodeName 函数简单地使用上述我们在输出中添加的 _type 属性作为其在 AST 树视图中的名称。
仓颉 Token 默认给出 line 和 column，辅助函数 getOffset 将 1-based 的行列号转换为 0-based 的字符偏移量。
nodeToRange 是实现 AST 和源码之间映射的关键，它根据节点是否具有 beginPos 和 endPos，或者 pos 和 value 属性来计算节点在源代码中的起始和结束偏移量。对于后者，实现采用 startOffset + node.value.length 的方式计算结束偏移量。
opensByDefault 定义了 AST 一开始是否展开。这里我们让有 _type 属性的节点或数组默认展开，避免显示过多的 Token。

website/src/parsers/cangjie/cj.js

import defaultParserInterface from '../utils/defaultParserInterface';
export default {
  ...defaultParserInterface,
  id: 'cj',
  displayName: ID,
  version: '1.13.4',
  homepage: 'https://cangjie-lang.cn/',
  _ignoredProperties: new Set(['_type']),
  locationProps: new Set(['pos', 'beginPos', 'endPos']),
 
  async loadParser(callback) {
    callback({
      parseFile: (code) => {},
    });
  },
 
  async parse(parser, code) {
    this.lineOffsets = [];
    let index = 0;
    do {
      this.lineOffsets.push(index);
    } while ((index = code.indexOf('\n', index) + 1));
    console.info('lineOffsets', this.lineOffsets);
    let resp = await fetch('http://localhost:8001/ast', {
      method: 'POST',
      body: code,
    });
    return resp;
  },
 
  getNodeName(node) {
    return node._type;
  },
 
  getOffset({ line, column }) {
    return this.lineOffsets[line - 1] + column - 1;
  },
 
  nodeToRange(node) {
    if (node.beginPos && node.endPos) {
      const start = node.beginPos;
      const end = node.endPos;
      const startOffset = this.getOffset(start);
      const endOffset = this.getOffset(end);
      return [startOffset, endOffset];
    }
    if (node.pos && node.value) {
      const start = node.pos;
      const startOffset = this.getOffset(start);
      const endOffset = startOffset + node.value.length;
      console.log('nodeToRange', node, startOffset, endOffset);
      if (Number.isNaN(startOffset)) {
        return;
      }
      return [startOffset, endOffset];
    }
  },
 
  opensByDefault(node, key) {
    return node._type || Array.isArray(node);
  },
};

修改后的代码见 OverflowCat/astexplorer。

代码文本可在北航云盘获取
函数签名的定义可以参考维基百科
常量折叠的定义可以参考维基百科

2024 年 JavaScript 的臃肿状况

2025-05-25T18:26:11.840Z

JavaScript Bloat in 2024

作者：Niki (@tonsky)

I was a bit out of touch with modern front-end development. I also remembered articles about web bloat, how the average web page size was approaching several megabytes!

我有点与现代前端开发脱节了。记得以前看过一些讲 Web 臃肿的文章，说平均网页大小都快接近好几 MB 了！

So all this time I was living under impression that, for example, if the average web page size is 3 MB, then JavaScript bundle should be around 1 MB. Surely content should still take the majority, no?

所以我一直以为是这样：比如平均网页大小要是 3MB，那 JavaScript 包大小估计也就 1MB 左右。内容肯定还是占大头，对吧？

Well, the only way to find out is to fuck around. Let’s do a reality check!

好吧，唯一能搞清楚的方法就是亲自动手折腾一番。我们来看看实际情况！

I’m writing this in 2024, so maybe do a sequel in a few years?

我现在是在 2024 年写的这篇文章，所以也许几年后再写个后续？

Method

测试方法

Firefox on macOS (but should be the same in any browser)
macOS 上的 Firefox（但在任何浏览器中结果应该都一样）
Not incognito (I want to see numbers inside the app, and there’s a better chance it will resemble actual everyday experience)
非隐身模式（我想看看应用实际运行时的加载数据，这样更接近真实的日常使用体验）
All extensions disabled
所有扩展禁用
JavaScript only
仅统计 JavaScript
Uncompressed
未压缩大小
Service Workers enabled (again, more real-life)
Service Workers 启用（同样，为了更贴近真实使用场景）
All caching disabled (cold load)
所有缓存禁用（即冷加载）

Why only JavaScript? Content varies a lot from site to site (surely videos on YouTube are heavier than text messages on Slack), but JavaScript is a universal metric for “complexity of interactions”.

为什么只看 JavaScript？不同网站的内容差异很大（YouTube 上的视频肯定比 Slack 上的文本消息更占地方），但 JavaScript 是衡量「交互复杂度」的通用指标。

The main goal is to evaluate how much work the browser has to do to parse and execute code.

主要目标是评估浏览器为了解析和执行这些代码需要做多少工作。

To set some baseline, let’s start with this blog:

为了设定一个基准，我们从本博客¹开始：

The number here would be 0.004 MB. I also highlighted all the important bits you need to set if you decide to reproduce this at home.

这里的数据是 0.004 MB。我还高亮了所有重要的设置项，如果你想自己动手复现这个过程的话。

Landings

着陆页

Okay, let’s start with something simple, like landing pages/non-interactive apps.

好吧，让我们从一些简单的东西开始，比如着陆页或基本没什么交互的应用。

A normal slightly interactive page looks like this — Wikipedia, 0.2 MB:

一个正常的、略带交互的页面大概是这样——维基百科，0.2 MB：

Slightly bloated — like this — Linear, 3 MB:

稍微有点臃肿的——比如这个——Linear，3 MB：

Remember: that’s without images, or videos, or even styles! Just JS code.

记住：这还不包括图片、视频，甚至样式！仅仅是 JS 代码。

A bad landing page looks like this — Zoom, 6 MB:

一个糟糕的着陆页大概是这样——Zoom，6 MB：

or like Vercel, 6 MB:

或者像 Vercel，6 MB：

Yes, this is just a landing page. No app, no functionality, no calls. 6 MB of JavaScript just for that.

是的，这仅仅是一个着陆页。没有应用本身，没有实际功能，也没有后台调用。就为了这个，要 6 MB 的 JavaScript。

You can do a lot worse, though — Gitlab, 13 MB:

不过，还有更离谱的——Gitlab，13 MB：

Still just the landing.

这也仅仅是个着陆页。

Mostly static websites

大部分是静态内容的网站

Nothing simpler than showing a static wall of text. Medium needs 3 MB just to do that:

没什么比显示满屏幕的静态文字更简单了吧。Medium 就为了这个需要 3 MB：

Substack needs 4 MB:

Substack 需要 4 MB：

Progress?

有进步吗？

Quora, 4.5 MB:

Quora，4.5 MB：

Pinterest, 10 MB:

Pinterest，10 MB：

Patreon, 11 MB:

Patreon，11 MB：

And all this could’ve been a static page...

而所有这些，本可以只是一个静态页面……

Search

搜索功能

When your app’s interactivity is limited to mostly search. Type the query — show the list of results. How heavy is that?

当你的应用交互主要就是搜索。输入查询语句——显示结果列表。这种的需要多重？

StackOverflow, 3.5 MB:

StackOverflow，3.5 MB：

NPM, 4 MB:

NPM，4 MB：

Airbnb, 7 MB:

爱彼迎，7 MB：

Booking.com, 12 MB:

Booking.com，12 MB：

But Niki, booking is complicated! Look at all this UI! All these filters. All these popups about people near you stealing your vacation!

但是，Tonsky，订票页面很复杂啊！看看这满屏的 UI！这么多筛选器！还有那些告诉你手慢无的烦人弹窗！

Okay, okay. Something simpler then. Google. How about Google? One text field, list of links. Right?

好吧，好吧。那来个简单点的。谷歌。谷歌搜索怎么样？一个输入框，然后一个链接列表。对吧？

Well, it’ll cost you whooping 9 MB:

嗯，这就要你足足 9 MB：

Just to show a list of links.

仅仅是为了显示一个链接列表。

Simple one-interaction apps

简单交互型应用

Google Translate is just two text boxes. For that, you need 2.5 MB:

谷歌翻译就俩文本框。就这个，你需要 2.5 MB：

ChatGPT is one text box. 7 MB:

ChatGPT 就一个文本框。7 MB：

I mean, surely, ChatGPT is complex. But on the server, not in the browser!

我的意思是，诚然，ChatGPT 本身很复杂。但复杂的是后端，不是前端啊！

Videos

视频网站

Loom — 7 MB:

Loom — 7 MB：

YouTube — 12 MB:

YouTube — 12 MB：

Compare it to people who really care about performance — Pornhub, 1.4 MB:

跟那些真正关心性能的网站比比——Pornhub，1.4 MB：

Audio

音频网站

I guess audio just requires 12 MB no matter what:

我猜音频网站起步价横竖是 12 MB：

SoundCloud:

SoundCloud：

Spotify:

Spotify：

Email

邮箱

Okay, video and audio are probably heavy stuff (even though we are not measuring content, just JS, remember!). Let’s move to simpler office tasks.

好吧，视频和音频可能确实是大家伙（但是还是想强调，我们测量的可不是内容，只是 JS 代码！）。让我们转向更简单的办公任务。

Google Mail is just (just!) 20 MB:

谷歌邮箱只有（仅仅只有！）20 MB：

It’s a freaking mailbox!!! How on earth is it almost as big as Figma, who ships entire custom C++/OpenGL rendering for their app?

这特喵的是个邮箱！！！它到底是怎么做到几乎和 Figma 一样大的？Figma 可是内置了一整套定制的 C++/OpenGL 渲染引擎的啊！

And if you are thinking: mail is complicated, too. Lots of UI, lots of interactivity. Maybe 20 MB is okay?

如果你在想：邮箱也很复杂啊，那么多界面，那么多交互。也许 20MB 也还行？

No!

不！

Just no. See, FastMail, same deal, but only 2 MB. 10× less!

绝不可能。看，FastMail，干着同样的活儿，但只有 2 MB。少了整整 10 倍！

Productivity

生产力工具

Okay, maybe e-mail is too complicated? How about something even simpler? Like a TODO list?

好吧，也许邮箱还是太复杂了？那来点更简单的怎么样？比如一个待办事项清单？

Well, meet Todoist, 9 MB:

那么，来看看 Todoist，9 MB：

Showing you a list of files in folders requires 10 MB in Dropbox:

在 Dropbox 中显示文件夹里的文件列表，需要 10 MB：

List of passwords? That’ll be 13 MB on 1Password:

密码列表？1Password 上需要 13 MB：

Cards? Add 0.5 MB more, up to 13.5 MB. Trello:

一些卡片？再加 0.5 MB，高达 13.5 MB。说的是 Trello：

Okay, maybe TODO lists are too complex, too? How about chatting?

好吧，也许待办事项清单也太复杂了？那聊天软件呢？

Well, Discord needs 21 MB to do that:

嗯，Discord 需要 21 MB 来实现聊天功能：

Document editing

文档编辑

Okay, document editing is hard, right? You have to implement cursor movement, synchronization, etc.

好吧，文档编辑是挺难的，对吧？你必须实现光标移动、内容同步等等。

Google Docs, 13.5 MB:

谷歌文档（Google Docs），13.5 MB：

Something simpler? Notion, 16 MB:

功能简单点的？Notion，16 MB：

社交网络

The typical size of code that social networks need for like buttons to go brrr is 12 MB.

社交网络为了让点赞量咻咻咻地涨起来，通常需要 12 MB 的代码。

Twitter, 11 MB:

Twitter (X)，11 MB：

Facebook, 12 MB:

Facebook，12 MB：

TikTok, 12.5 MB:

TikTok，12.5 MB：

Instagram is somehow bigger than Facebook, despite having like 10× less functions. 16 MB:

Instagram 不知怎么的比 Facebook 还大，尽管功能少了大概 10 倍。16 MB：

LinkedIn. Is it a blog? A platform? It has search, it has messaging, it has social functions. Anyways, that’ll be 31 MB:

领英。它算博客？还是平台？它有搜索，有消息，还有社交功能。不管怎么说，这是 31 MB：

By the way, I'd like to add you to my professional network on LinkedIn.

顺便说一句，我想在领英上加您为好友来拓展我的人脉圈。

Elephants — its own category

大象级应用——自成一档

Sometimes websites are so stupidly, absurdly large that they deserve their own category.

有些网站大到愚蠢、荒谬的程度，简直应该单独给它们分一类。

Here, Jira, a task management software. Almost 50 MB!

比如，Jira，一个任务管理软件。差不多 50 MB！

Do they ship the entire Electron compiled WASM or what?

他们是把整个 Electron 编译的 WASM 都给打包进来了，还是怎么了？

But that’s not the limit! Slack adds 5 more MB, up to 55 MB:

但这还不是极限！Slack 又多了 5 MB，高达 55 MB：

Yes, it’s a chat. You know, list of users, messages, reactions. Stuff we did on raw HTML, even before JS was invented?

是的，它就是个聊天软件。你想想，用户列表、消息、表情回应。这些玩意儿，我们以前用纯 HTML 都能实现，甚至在 JavaScript 发明之前就可以！

That’s 55 MB in today’s world. It’s almost like they are trying to see how much more bullshit can they put in a browser before it breaks.

在今天这个时代要 55 MB。简直就像是他们在想试试看到底能往浏览器里塞多少垃圾代码才会让它崩溃。

Finally, this blew my mind. Somehow react.dev starts with a modest 2 MB but as you scroll back and forth, it grows indefinitely. Just for fun, I got it to 100 MB (of JavaScript!), but you can go as far as you like:

最后，这个操作惊掉我的下巴。不知怎的 react.dev 网站一开始只有区区 2 MB，但当你来回滚动页面时，它的大小会无限增长。纯粹为了好玩，我把它搞到了 100 MB（的 JavaScript！），但你想搞多大就能搞多大：

What is going on there? Even if it unloads and downloads parts of that blog post, how is it growing so quickly? The text itself is probably only 50 KB (0.05 MB).

这到底是什么鬼？就算它会卸载并重新加载博文的某些部分，它怎么能增长得这么快？文章本身的文本可能也就 50 KB（0.05 MB）。

UPD: It has been brought to my attention that this behavior is not, in fact, representative of normal user experience. Normally embedded code editors will be cached after first load and subsequent loads will be served from disk cache. So as you scroll, you will see no network traffic, but these 100 MB of JS will still be parsed, evaluated and initialized over and over as you scroll.

更新：有人提醒我，这种行为实际上并不代表典型的用户体验。通常情况下，嵌入式代码编辑器在首次加载后会被缓存，后续加载会从磁盘缓存中读取。所以当你滚动时，你不会看到网络流量，但这 100MB 的 JS 仍然会在你滚动时一遍又一遍地被解析、求值和初始化。

How fast are we degrading?

我们这是在以多快的速度开倒车？

Look how cute! In 2015 average web page size was approaching shareware version of Doom 1 (2.5 MB):

瞧瞧这个，多可爱啊！2015 年的时候，平均网页大小快赶上《毁灭战士Ⅰ》共享版的大小了（2.5 MB）：

Source

Well, in 2024, Slack pulls up 55 MB, the size of the original Quake 1 with all the resources. But now it’s just in JavaScript alone.

好吧，到了 2024 年，Slack 一个应用就干到了 55 MB，这都赶上初代《雷神之锤》完整版的大小了。但现在，这仅仅是 JavaScript 代码的大小。

For a chat app!

单就为一个聊天应用！

How big is 10 MB anyway?

10 MB 到底有多大？

To be honest, after typing all these numbers, 10 MB doesn’t even feel that big or special. Seems like shipping 10 MB of code is normal now.

讲真，在敲了这么多数字之后，10 MB 感觉已经不那么大或者特别了。现在看来，动不动就上 10 MB 的代码体积，似乎是家常便饭了。

If we assume that the average code line is about 65 characters, that would mean we are shipping ~150,000 lines of code. With every website! Sometimes just to show static content!

如果我们假设平均每行代码大约 65 个字符，那就意味着我们给每个网站都塞了约 15 万行代码。每个网站都这样！有时仅仅是为了显示一些静态内容！

And that code is minified already. So it’s more like 300K+ LoC just for one website.

而且那些代码已经是压缩过的了。所以一个网站实际的代码行数更可能超过 30 万行。

But are modern websites really that complex? The poster child of SPAs, Google Maps, is quite modest by modern standards — is still just 4.5 MB:

但是，现代网站真的有那么复杂吗？作为单页应用（SPA）的标杆，谷歌地图按现在的标准来看算是相当克制的了——仍然只有 4.5 MB：

Somebody at Google is seriously falling behind. Written with modern front-end technologies, it should be at least 20 MB.

谷歌的人可真是严重掉队了。要是用现代前端技术来写，它至少也得 20 MB 起步。

And if you, like me, thought that “Figma is a really complex front-end app, so it must have a huge javascript download size”, well, that’s correct, but then Gmail is about as complex as Figma, LinkedIn is 1.5× more complex and Slack is 2.5× more ¯\_(ツ)_/¯

如果你和我一样，曾以为「Figma 是个非常复杂的前端应用，所以它的 JavaScript 下载体积肯定很大」，嗯，这想法没错。但照这么说，Gmail 跟 Figma 差不多复杂，领英比它复杂 1.5 倍，Slack 则复杂 2.5 倍 ¯\_(ツ)_/¯

Conclusion

结论

It’s not just about download sizes. I welcome high-speed internet as much as the next guy. But code — JavaScript — is something that your browser has to parse, keep in memory, execute. It’s not free. And these people talk about performance and battery life...

这不仅仅是下载大小的问题。我和其他人一样拥抱高速互联网。但是代码——JavaScript——是你的浏览器必须解析、驻留内存、然后执行的东西。这些都不是零成本的。而那些家伙们还在大谈特谈性能和电池续航……

Call me old-fashioned, but I firmly believe content should outweigh code size. If you are writing a blog post for 10K characters, you don’t need 1000× more JavaScript to render it.

你可以骂我老古董，但我坚信内容本身应该比代码体积重要得多。如果你写的是一篇万字博文，你并不需要用比内容多一千倍的 JavaScript 来渲染它。

This site is doing it right:

这个网站就做对了：

That’s 0.1 MB. And that’s enough!

这才 0.1 MB。这就够了！

And yet, on the same internet, in the same timeline, Gitlab needs 13 MB of code, 500K+ LoC of JS, just to display a static landing page.

然而，在同一个互联网上，在同一个时代背景下，Gitlab 仅仅为了显示一个静态着陆页，就需要 13 MB 的代码，超过 50 万行的 JS 代码。

Fuck me.

日了狗了。

译者注：指原作者的博客。你现在所在的译文页面的 JavaScript 的体积是 0 KB。

自新世界 #0x09：春愁

2025-05-17T17:26:52.348Z

猫猫的奇幻漂流 movie 2024

플로우 Straume Straume Straume Flow, le chat qui n'avait plus peur de l'eau Flow, un mundo que salvar Flow 貓貓的奇幻漂流 喵的奇幻漂流 漂流 Straume 黑猫的奇幻漂流 Flow - À Deriva 喵的奇幻漂流 Straume Straume Straume Flow - katten som slutade vara rädd för vatten Straume 喵的奇幻漂流(台) Flow by 金兹·兹巴洛迪斯、金兹·兹巴洛迪斯

类型：动画 / 奇幻 / 冒险

世界似乎即将毁灭，到处都是人类的遗迹。一只猫的家园被一场大洪水摧毁，它在一艘载满了不同动物的船上找到了避难所。尽管它们之间存在差异，但它必须与它们合作，面临各种未知的挑战。

剧场总集篇『孤独摇滚！』 Re:Re: movie 2024

劇場総集編ぼっち・ざ・ろっく！ Re:Re: 劇場総集編ぼっち・ざ・ろっく！后編‎ by 斋藤圭一郎、青山吉能、铃代纱弓、水野朔、长谷川育美、内田真礼、千本木彩花、吉田惠里香

类型：剧情 / 动画 / 音乐

您的浏览器或阅读器可能不支持正确渲染含有 foreignObject 的 SVG 图像，请移玉至原文查看。

惊鸿一瞥：仓颉编程语言校园行

2025-05-01T02:45:26.205Z

刘俊杰是华为仓颉编译与运行时团队的核心成员，曾参与仓颉编译器和运行时的设计与开发，目前主要负责仓颉的生态建设。以下内容为其发言概要。

不知道大家是否听说过，中国早期有一家做手机的公司叫做波导。那时候华为甚至还没开始做手机。波导公司的创始人及总工程师赵建东先生今天也来到了现场。

赵总之所以来到这里，是因为他认为中国自主研发编程语言这件事情非常有价值和意义。赵老师现在也是一家芯片公司——视芯科技的老板。他平时并未停歇，还在业余时间开发了自己的编程语言，叫做 Fine 语言。赵老师认为做这件事的长期价值在于，通过我们未来的努力，去打破西方在一些核心技术上的垄断，培养我们自己的人才，同时这对大家未来的工作发展也非常有帮助。他怀着一种公益的心态来做这次分享，也想借此机会鼓励同学们，因为大家未来都可能成为非常优秀的工程师和创业者。

赵建东自述

按东南商报 2005 年 8 月 13 日文《宁波科教界授最高奖 4位科教精英每人重奖60万元》：

赵建东，男，1965 年出生，高级工程师。1990 年毕业于兰州大学，获理学硕士学位；1991 年出任清华大学访问学者；1992 年任美国协和集团顺霸研究院(珠海)射频室主任；1992年底至今先后任宁波波导公司研发部经理、波导研究院院长、副总工程师、总工程师。

赵建东是波导公司创始人之一。作为公司技术负责人，多年来一直在科研一线从事技术开发工作，并带领公司科技人员积极研究新技术，开发新产品。先后开发了中文F系列、数字K系列寻呼机和800系列、900系列、S系列GSM、C系列CDMA手机，其中指纹识别智能手机是国内首创开发的。

以下内容为赵建东自述概要。

我从 1983 年进入兰州大学学习物理学，毕业后保送本校研究生，毕业论文是量子光学方面双光子激光器。1990 年毕业后，进入军工研究所，主要从事轰炸雷达、制导雷达等相关的研发工作，并曾与清华大学电子工程系合作开发项目。

到了 90 年代初，我被师兄说动，下海去了珠海一家美国投资的企业。后来，我创办了波导公司。大家可能对「波导手机，手机中的战斗机」这句广告词还有印象，那是我们那个时代的产品。

在波导期间，大约是 2005 年左右，我们实际上做了两年手机操作系统。我们还和浙江大学计算机学院联合主办了全国性的手机软件大赛，每年吸引很多团队到杭州参赛，我们会收购前十名的团队或作品，并给予奖金。当时，我们就在探索手机软件的下载和安装模式。那时的网络环境还很差，通过 WAP 下载一个几百K的软件需要很长时间，流量费也很高，几乎不可用。后来 GPRS 出现，速度提升到 100-200 Kbps，情况才有所好转。

那段时期，国产手机经历了激烈的竞争，我们算是最后退出的那一批。之后，我又和朋友创办了现在的世芯科技，主要做芯片设计。我想强调的是，我们过去很多技术是跟随性的，缺乏底层创新。芯片设计行业毛利率能达到 35-40%，这是一个创新驱动的领域。因为对操作系统和编程语言的持续兴趣，我了解到华为正在做的仓颉语言和鸿蒙操作系统。我认为这两项工作具有开创性，可能会改变我们国家信息产业未来的发展方向。这也是我今天来到这里的原因。

在过去十几年的时间里，我自己也断断续续地开发了一个类似 C# 的编程语言，叫做 Fine，目前已经比较系统化了，它内置了 GUI、数据库和网络通讯等功能，是一个集成化的开发环境。

我的业余时间主要有两个爱好，打弹弓和写代码。很少参加此类活动，今天主要是来和大家简单交流一下。

技术与生态现状汇报

这一部分的 slides 可以查看可画（canva.cn）。

首先，我们简单回顾一下编程语言的发展历史。最早的 C 语言诞生于上世纪70年代，当时计算机硬件资源有限，C 语言凭借其高效、灵活和贴近硬件的特点，迅速成为开发操作系统、编译器等系统软件的首选。

80年代，C++ 在 C 的基础上引入了面向对象编程，就像从用砖块盖房子，变成了用预制好的门、窗、屋顶等模块来组装，极大地提升了大型程序的开发效率和可维护性。

90年代，Java 和 Python 等语言崭露头角。Java 以其「一次编写，到处运行」的跨平台特性，在企业级应用和安卓开发中非常流行，目前大部分安卓应用仍是Java开发的。Python则因其语法简洁、库丰富，在数据科学和人工智能领域得到了广泛应用。

进入21世纪后，Go、Rust、Swift、Kotlin 等现代编程语言相继出现，它们通常用于云计算、分布式系统等领域，在并发处理、工具链等方面相较于之前的语言有了很大进步。

那么，在当前智能化、万物互联的时代背景下，下一代编程语言应该具备哪些特性呢？华为研发的仓颉语言，正是面向下一代编程语言进行探索，在智能化、高效率、安全可信以及易扩展等方面做了深入研究。

回顾仓颉的发展历程，项目于 2019 年启动，2020 年正式命名为「仓颉」，寓意着像仓颉造字一样，希望这门语言能被广大开发者喜爱并广泛使用。2022 年，仓颉语言首次在华为自研的 HarmonyOS 路由器上首次商用，替换原有的 Go 模块（仓颉在并发策略上参考的 Go 语言）。由，因此在首次商用中表现亮眼，性能有显著提升。

2023年，仓颉语言开始与国内多家头部企业展开深入合作，例如与中航、国家电网等在一些重要场景进行商业验证。整个研发过程中，国家也给予了大力支持。编程语言作为软件产业的根技术，研发自主可控的仓颉语言，有助于我们在核心技术上掌握主动权，尤其是在当前日益严峻的国际形势和科技竞争背景下，可以防范未来可能出现的「卡脖子」风险。

除了战略层面的考量，仓颉语言也是构建鸿蒙生态的重要一环。就像苹果的 Swift/Objective-C 支撑了 iOS 生态，谷歌的 Kotlin/Java 支撑了 Android 生态一样，鸿蒙作为国产操作系统，也需要有自己的原生开发语言来构建繁荣的生态。

2024 年是仓颉语言发展的重要一年，工商银行和力扣发布了使用仓颉编写的原生鸿蒙应用。其中，有道的应用是完全使用仓颉从零开始编写的，这证明了仓颉语言目前已经具备了开发完整应用的能力。在 6 月的华为开发者大会（HDC）上，仓颉语言将正式对外发布，届时开发者可以通过IDE插件等方式来使用仓颉语言。

接下来，介绍一下仓颉语言的主要技术特性，可以概括为智能化、全场景、高性能和强安全。

在性能方面，与目前安卓开发主流的 Java 语言相比，仓颉具有先天优势。仓颉是 AOT 到原生机器码的，相比 Java 需要通过虚拟机解释或 JIT，减少了运行时的翻译开销，因此执行速度更快。

传统的编译器，如 GCC、Clang 等，通常采用一体化设计，从预处理、词法分析、语法分析、语义分析到最终代码生成，整个流程是耦合在一起的。这种方式的局限性在于，为不同语言开发编译器都需要从头构建整个系统。仓颉的编译器架构是基于 LLVM 的模块化设计。它将编译过程划分为前端、IR 和后端。前端负责将不同语言的源代码转换成统一的中间表示（IR），类似于将各种食材加工成半成品。中端 IR 层是核心，它是一种与具体语言和目标机器无关的表示形式，可以在这个层面上进行各种通用的优化。后端则负责将优化后的 IR 生成特定目标机器的机器码。理论上，IR 到机器码的后端部分可以直接复用开源的 LLVM。不过，由于仓颉语言有一些独特的设计，比如参考了 Go 的协程，以及 Actor 并发模型，以及它的一些内建类型和内存管理特性，我们需要对 LLVM 的某些部分进行改造和扩展来适配这些需求（CJNative LLVM）。

在垃圾回收方面，仓颉采用了全并发分代垃圾回收机制。相比于传统的标记-清除算法可能导致的长时间 stop-the-world，分代 GC 能更有效地管理内存，减少 GC 停顿时间，从而降低应用程序的卡顿感，提升用户体验。鸿蒙原生 Markdown 组件（仓颉实现）渲染效果优于安卓版（Kotlin），且不掉帧。在 IO 密集型场景（如网络请求加载图片）下，仓颉的协程能够充分发挥优势，避免线程阻塞，提高吞吐量和响应速度。（仓颉与 ArkTS 对比视频）和 ArkTS 的对比测试中，使用仓颉实现的版本在启动速度和滑动流畅度上均优于 ArkTS 版本。

仓颉语言的另一个重要特性是「天生全场景」，在运行态是指有轻量对象布局、轻量运行时库、轻量用户线程、轻量回栈的特性。

天生全场景另一方面在于语言层面。由于技术变化，通过语法扩展，仓颉可以更好地适应各种新的硬件或软件架构。以及不同的领域对于不同的需求是不一样的。一个简单的例子是，通过给变量增加一个类似 @state 的修饰符，就可以让这个变量具有响应状态变化的能力。当它的值改变时，自动触发 UI 更新，而不需要编写额外的监听或回调代码。

仓颉语言还积极拥抱 AI Agent（智能体）开发。使用 AgentDSL，开发者可以借助操作符，用非常简洁、接近自然语言的方式来与智能体的对话，而无需编写大量复杂的底层代码。

在安全性方面，仓颉也做了很多设计，例如编译期空安全检查、默认数据不可变性、数组越界检查等等。这些特性旨在减少开发过程中的常见错误，提高代码的健壮性和安全性。仓颉语言及其运行时已经获得了业界权威的安全认证。

如果大家想学习和了解仓颉，可以通过以下途径获取资源。仓颉项目目前主要托管在 Gitcode 平台，包括编译器、标准库、文档以及第三方库等。官方网站也提供了丰富的学习资料和开发者社区入口。我们非常欢迎同学们未来能参与到仓颉的开源社区中，贡献代码和应用案例。

从 PL 领域看仓颉

刚刚提到了很多仓颉的特性，从编程语言（PL）领域的角度来看，语言设计是一个核心话题。国内高校很多课程侧重于编译器实现，这是一个偏工程的领域，但也涉及到一些理论，比如形式语言、自动机理论等。今天我尝试从另一个维度，即领域特定语言（DSL）的视角，来通俗地解读一下语言设计的一些趋势，以及仓颉在这方面的考虑。

编程语言的发展，从机器语言、汇编语言到高级语言，本质上是一个抽象层次不断提高的过程。抽象层次越高，语言表达能力越强，越接近人类自然语言，开发效率通常也越高。但代价是可能损失一些底层的控制力和性能，同时，构建更高层次抽象所需的技术和时间成本也可能更高。

当通用编程语言用于解决特定领域的问题时，往往需要编写很多与领域核心逻辑无关的「模板代码」或「胶水代码」。为了提高特定领域的开发效率和表达力，就产生了 DSL。DSL 是专门为某个特定领域设计的语言，它的语法和语义都紧密围绕该领域的需求。例如，SQL是数据库查询的DSL，HTML 是网页结构的 DSL。DSL 的优点是在其适用领域内非常高效、简洁、易于理解和维护，但缺点是通用性差，无法用于其设计领域之外的问题。

业界实践中，我们观察到一种趋势：在各种领域，都存在对DSL的需求。

数据库交互：早期使用 JDBC 等 API，需要手动编写连接管理、SQL 语句构造、结果集映射等大量代码。后来出现了 ORM 框架，通过注解提供了一种 DSL。开发者只需在代码实体类和成员变量上添加注解，就能描述程序实体与数据库表、字段之间的映射关系，框架会自动处理底层的数据库操作。这种基于注解的 DSL，相比于纯 Java 代码，极大地简化了数据持久化操作。
进程间通信：传统的 IPC 方式需要开发者处理复杂的序列化、反序列化、协议定义、连接管理等细节。后来出现了像 Android 的 AIDL（Android Interface Definition Language）这样的 IDL（接口定义语言）。开发者使用 AIDL 这种 DSL 来定义接口，工具链会自动生成底层的 IPC 代码。但这样只能通过在 Java 的基础上外挂实现，而非语言本身。
UI 开发：传统的 UI 开发（如早期使用 C++ 的 MFC 或 Qt）需要编写大量命令式代码来创建、布局、设置样式和处理事件，UI 结构、样式和逻辑代码常常混杂在一起。后来发展出声明式 UI 框架，如 XML 布局，以及现代的 SwiftUI 等。这些框架提供了一种 DSL，让开发者能够更直观地描述 UI 的最终状态和结构，框架负责渲染和状态管理，屏蔽了无关的底层细节，显著提高了代码的可读性和定制化能力。
互操作：例如 JS 调用 C 时需要去写 NAPI，需要调系统接口，做各种类型转换、异常处理。现代框架通常使用注解或更简洁的语法。相比复杂的 JNI/JNA，一些现代语言提供了更简洁的 FFI 机制。

总结这些案例，我们可以看到 DSL 在提升特定领域开发效率上的巨大价值。仓颉语言针对这种趋势，主要通过两种方式来支持 DSL：

原生集成：对于一些非常通用且重要的领域，仓颉在语言层面直接内建了相应的语法和语义支持。这可以看作是一种高度优化的、内建的 DSL。
- 在 C 语言互操作方面，仓颉通过声明式的语法，允许开发者以类似本地函数调用的方式直接声明和使用C函数。调用一个 C 函数只需一行声明，极大地简化了开发流程。
- 在并发方面，传统语言通常通过调用第三方库或标准库实现并发，缺乏语言层面的支持。而仓颉参考了 Go 语言的协程框架，将并发机制内置于语言中，通过关键词 spawn 实现轻量级线程的自动管理和调度。
扩展机制：对于像数据库、化工这些不那么通用，或者需要高度定制化的领域，仓颉提供了语言和编译器的扩展机制。开发者可以通过宏或其他语法扩展方式，在仓颉语言内部定义新的语法结构，实现所谓的 EDSL，即「嵌入式 DSL」。这种方式的好处是，开发者不需要编写独立的编译器或解析器，可以直接利用仓颉的基础设施进行扩展，并且扩展后的 DSL 可以与仓颉代码无缝集成。这与像 Android 在 Java 外挂插件实现 DSL 的方式有所不同。

所以，从 DSL 的视角来看，仓颉的设计哲学是在通用层面提供强大的基础能力和内建 DSL 支持，同时赋予开发者通过 EDSL 机制为特定领域量身定制高效表达方式的能力。这种设计不仅满足了现代软件开发对领域专用表达的诉求，也体现了仓颉作为下一代编程语言的前瞻性，在实际应用中展现了显著优势。有一个国产适配项目需要迁移 4000 多个 C 接口，仓颉通过声明式的互操作机制，将这一过程简化为简单的函数声明，大幅提高了迁移效率。Agent DSL为智能体开发提供了简洁的表达方式，开发者可以通过接近自然语言的语法描述智能体行为，无需深入编写复杂逻辑，从而进一步降低了开发门槛。

动手实践环节

第一个实践题目：并发与系统调用

这个题目与我们刚刚讨论的并发和系统调用（特别是 FFI）有关。程序运行后会弹出一个空白的 Windows 窗口。代码内部已经使用仓颉调用 GDI 注册了窗口类、创建了窗口，并处理了消息循环，画图的基础框架已经搭好。

任务：在这个窗口里画出一条正弦曲线。具体来说，你需要找到代码中预留的位置，添加几行仓颉代码，调用 Windows 的 SetPixel 函数来绘制点。SetPixel 函数的原型可以在微软的 MSDN 文档中查到，或者参考代码中已有的其他 API 调用示例。你需要关注它的参数：第一个是设备上下文句柄（hDC），可以模仿现有代码获取；后面两个是、坐标（整型）；最后一个是颜色值（COLORREF，也是一个整型）。

Cangjie

你需要编写一个循环，计算对应的值，注意可能需要进行类型转换（比如从浮点数转为整型），然后调用 SetPixel 在窗口的对应位置画点。代码中已经导入了所需的 Windows API 函数，可以直接调用。仓颉调用 C 函数时，通常需要将调用代码放在一个用 @ccall 修饰的代码块中，这是一种语法标记，提示开发者这里可能涉及不安全的内存操作，并指导编译器进行一些检查。

最终完成的代码量大概只需要几行。这个练习旨在让大家体验仓颉 FFI 简洁性以及基本的编程。

查 M$ 文档：

COLORREF SetPixel(
  [in] HDC      hdc,
  [in] int      x,
  [in] int      y,
  [in] COLORREF color
);

写出：

src/api.cj

  foreign func BeginPaint(hWnd: Handle, ps: CPointer<PAINTSTRUCT>): Handle
  foreign func EndPaint(hWnd: Handle, ps: CPointer<PAINTSTRUCT>): Bool
  foreign func GetClientRect(hWnd: Handle, rc: CPointer<RECT>): Bool
  foreign func Ellipse(hDC: Handle, left: Int32, top: Int32,
      right: Int32, bottom: Int32): Bool
  // 提示1：在这里声明绘图所需的 SetPixel 函数原型
+ foreign func SetPixel(hDC: Handle, x: Int32, y: Int32, color: UInt32): UInt32

这个文件里面还有些下面会用到的定义：

@C
struct POINT {
    public var x: Int32 = 0
    public var y: Int32 = 0
}
 
@C
struct RECT {
    public var left: Int32 = 0
    public var top: Int32 = 0
    public var right: Int32 = 0
    public var bottom: Int32 = 0
}
 
@C
struct PAINTSTRUCT {
  public var hDC: Handle = NULL
  public var fErase = true
  public var rcPaint = RECT()
  // 以下字段保留，系统在内部使用
  public var fRestore = false
  public var fIncUpdate = false
  public var rgbReserved = VArray<Byte, $32> { _ => 0 }
}

src/main.cj

// 基于 CFFI 的 Windows GUI 编程
package windows
import std.math.sin // 导入标准库中的 sin 数学函数
 
unsafe main() {
    let instance = GetModuleHandleA(EMPTY_STRING)
    // 注册窗口类
    let className = LibC.mallocCString('Cangjie Window')
    var windowClass = WNDCLASSEX(lpszClassName: className,
        hInstance: instance,
        lpfnWndProc: onMessage,
        hbrBackground: CreateSolidBrush(0x0095D6C0) // 中国传统色 欧碧
    )
    if (RegisterClassExA(inout windowClass) == 0) {
        println('RegisterClass Failed: ${GetLastError()}')
        return
    }
    // 创建窗口实例
    let windowName = LibC.mallocCString('Cangjie')
    let window = CreateWindowExA(
        0,                                   // 扩展样式
        className,                           // 窗口类名
        windowName,                          // 窗口标题
        WS_OVERLAPPEDWINDOW,                 // 窗口风格
        CW_USEDEFAULT, CW_USEDEFAULT,        // 窗口位置
        365, 365,                            // 窗口大小
        NULL,                                // 父窗口句柄
        NULL,                                // 菜单句柄
        instance,                            // 实例句柄
        NULL                                 // 附加参数
    )
    if (window.isNull()) {
        println('CreateWindow Failed: ${GetLastError()}')
        return
    }
    // 显示窗口
    ShowWindow(window, SW_SHOWNORMAL)
    UpdateWindow(window)
    // 启动消息循环
    var message = MSG()
    while (GetMessageA(inout message, NULL, 0, 0)) {
        TranslateMessage(inout message)
        DispatchMessageA(inout message)
    }
    // 退出消息循环
    println('Out of Message Loop')
    LibC.free(className)
    LibC.free(windowName)
}
 
func paint(hWnd: Handle, draw: (hDC: Handle) -> Unit) {
    var ps = PAINTSTRUCT()
    let hDC = unsafe { BeginPaint(hWnd, inout ps) }
    draw(hDC)
    unsafe { EndPaint(hWnd, inout ps) }
}

DefWindowProcA 是 Windows 提供的默认窗口过程，当窗口大小改变后，DefWindowProcA 通常会使窗口的客户区无效，从而导致 Windows 发送 WM_PAINT 消息。此时获取 hDC 后使用一个循环（比如 for 循环）遍历窗口的宽度作为坐标。

  unsafe func process(hWnd: Handle, msg: UInt32,
          wParam: UInt64, lParam: UInt64) {
      var result = 0
      if (msg == WM_PAINT) {
          paint(hWnd) { hDC =>
              var rect = RECT()
              GetClientRect(hWnd, inout rect)
              // 提示2：在这里添加绘图代码，绘制正弦曲线 y = 60 * sin(0.1 * x)
+             for (x in rect.left..rect.right) {
+                 let y = 60.0 * sin(0.1 * Float64(x))
+                 SetPixel(hDC, x, Int32(y) + rect.bottom / 2, 0x000000)
+             }
          }
      } else if (msg == WM_KEYDOWN && wParam == UInt64(VK_ESCAPE)) {
          DestroyWindow(hWnd)
      } else if (msg == WM_DESTROY) {
          PostQuitMessage(0)
      } else {
          result = DefWindowProcA(hWnd, msg, wParam, lParam)
      }
      return result
  }

需要调整坐标使其适应窗口坐标系，例如，将原点移到窗口中央。

画出的正弦函数

最后，在 @ccall 块内调用 SetPixel(hdc, x, y, color)。

@C
@CallingConv[STDCALL]
func onMessage(hWnd: Handle, msg: UInt32,
        wParam: UInt64, lParam: UInt64): Int64 {
    unsafe { process(hWnd, msg, wParam, lParam) }
}

这里的 hDC 类型在仓颉中可能用一个别名（如 Handle）表示，它本质上是一个指针或整数。整型参数可以直接传递。颜色可以用 RGB(r, g, b) 宏（如果导入了）或者直接用整型。

第二个实践题目：仓颉智能体框架

仓颉的智能体框架 AgentDSL 的核心思想是将大型语言模型（LLM）的「说话」能力转化为「做事」能力。LLM 理解自然语言、知识和推理能力很强，可以规划任务步骤。我们只需要编写程序，提取 LLM 输出的文本中的意图和参数，然后调用实际的设备驱动或 API，就能让 LLM「指挥」程序执行任务。

业界已有一些框架（如 LangChain）通过 API 调用的方式实现类似功能。仓颉 AgentDSL 的特色在于它采用了「声明式」的方式。开发者不需要编写大量的接口调用和初始化代码，而是通过注解来定义智能体及其能力。

例如，在一个类上使用 @Agent 注解，这个类就具备了与 LLM 交互的基础能力。你可以直接调用它的 chat 方法进行对话。如果在类中定义一些属性或方法，可以设定 Agent 的角色或初始状态。定义函数时可以用 @Tool 注解修饰，包含两个参数：一个是描述这个工具（函数）能做什么，另一个是描述它的参数各自代表什么。

当用户与 Agent 交互时，框架会自动将这些 @Tool 的描述信息整合到发送给 LLM 的 prompt 中。LLM 在理解用户意图后，会决定调用哪个工具以及传递什么参数，并以特定格式返回给框架。框架解析LLM的回复，然后实际执行对应的函数调用。

例子：一个智能家居助手，通过 @Agent 定义助手，用 @Tool 定义控制灯光、空调等的函数。用户说「把客厅灯打开」，LLM理解后指示框架调用「开灯」函数，并附带参数「客厅」。

任务：使用 AgentDSL 来控制一个模拟的魔方。我们提供了一个基础的魔方程序（在控制台打印魔方的状态），它有一个 Cube 类，可以通过调用其成员函数（如 turn(face, direction)）来转动不同的面。参数 face 用字母表示（如 F, B, L, R, U, D），direction 表示顺时针或逆时针。

期望：运行程序后，在控制台输入指令，程序能正确解析并调用对应的魔方转动函数，并打印出转动后的魔方状态。

  package agent
  
  import magic.dsl.*
  import magic.prelude.*
  import magic.config.Config
  
  @agent[model: "ark:deepseek-v3-250324"]
  class CubeAgent {
      // 提示1: 调用 cube.transform('F', true) 可以将魔方正面逆时针旋转 90 度
      // 字母 F, B, L, R, U, D 分别表示魔方的前、后、左、右、上、下 6 个面
      let cube = Cube()
 
      @prompt(
          // 提示2: 在这里添加 Agent 提示词，让 AI 熟悉业务场景，例如它的职责和魔方各面的字符定义等
+         "你是一个魔方大师专家，负责控制魔方的旋转和输出魔方的展开图。\n魔方的各个面用字母表示：字母 F, B, L, R, U, D 分别表示魔方的前、后、左、右、上、下 6 个面"
      )
 
      @tool[description: "获取魔方当前状态下的展开图"]
      func now(): String {
          cube.toString()
      }
 
      // 提示3: 在下面添加两个 @tool 修饰的函数，让 AI 可以控制魔方的旋转
      // 两个函数分别控制顺时针和逆时针旋转，函数参数指定具体旋转哪个面
+     @tool[description: "顺时针旋转魔方的某个面"]
+     func rotate(face: String) {
+         cube.transform(face, false)
+     }
+
+     @tool[description: "逆时针旋转魔方的某个面"]
+     func rotateCounter(face: String) {
+         cube.transform(face, true)
+     }
  }
 
  main() {
      Config.env["ARK_API_KEY"] = "[redacted]"
      Config.maxReactNumber = 100
      let agent = CubeAgent()
      agent.chat("顺时针旋转正面 2 次，逆时针旋转顶面 1 次，输出魔方展开图") |> println
  }

根据演讲者，部分 LLM 对于一些布尔参数支持得不是很好，所以推荐写两个函数。

第三个实践题目：并发网络编程与 AI 结合

最后一个题目结合了网络编程、并发和AI。仓颉编写 TCP 通信和创建协程（用于处理并发连接或任务）的代码非常简洁。提供的代码支持多客户端连接一个服务端。服务端接收控制台输入，并将消息广播给所有连接的客户端。客户端接收控制台输入，并将消息发送给服务端。同时还提供了一个独立的仓颉模块（llm.cj），封装了与大语言模型聊天的功能。这个模块提供了一个类，可以创建实例并调用其 chat 方法（一次性获取回复）或 stream_chat 方法（流式获取回复）来进行对话。可直接运行这个模块体验与 AI 聊天。

任务：修改客户端和服务端程序，让它们不再接收控制台的用户输入，而是各自创建一个 LLM 实例，然后通过网络互相发送消息，实现两个 AI 自动聊天的效果。

步骤：

在服务端和客户端的代码中，import 我们提供的 llm.cj 模块。
在各自的程序初始化部分，创建LLM类的实例。可以给它们设定不同的角色（比如一个扮演贾宝玉，一个扮演林黛玉），通过初始化时的 prompt 来实现。
修改网络消息处理逻辑：
- 当客户端收到服务端的消息后，不再打印到控制台，而是将这个消息作为输入，调用自己的 LLM 实例的 chat 方法获取回复。然后将 LLM 的回复通过网络发送给服务端。
- 当服务端收到客户端的消息后，同样调用自己的 LLM 实例获取回复，然后将回复通过网络发送回该客户端（或者广播给所有客户端，取决于你想要的效果）。
需要一个启动机制，比如让客户端在连接成功后，主动发送第一句话（可以是一个固定的问候语，或者调用 LLM 生成一句开场白）给服务端，来触发对话的开始。
编译时需要将 llm.cj 文件与客户端、服务端代码一起编译，因为它们现在互相依赖。运行命令可能需要指定主模块入口：
build.bat
```
cjc client.cj llm.cj -o client.exe
cjc server.cj llm.cj -o server.exe
```

期望：启动服务端和客户端后，它们能够通过TCP连接，自动地进行一轮又一轮的对话，并将对话内容打印在各自的控制台上（或者你可以选择不打印）。

这个题目的核心在于将原来处理标准输入输出的地方，替换成处理网络收到的消息和调用LLM获取回复。在客户端，收到网络消息后，reply = llm.chat(received_message)，然后 socket.send(reply)。在服务端，收到某个客户端的消息后，reply = llm.chat(received_message)，然后 client_socket.send(reply)。需要注意处理好异步接收和发送的逻辑，以及对话的启动。

package chat
 
import std.console.Console
import std.socket.*
 
func startInputListener(client: TcpSocket) {
    spawn { // 在新线程中接收控制台输入并发送到对端
        while (true) {
            // ...
        }
    }
}
 
main() {
    const IP = "127.0.0.1"
    const PORT: UInt16 = 23456
    const BUFFER_SIZE = 1024
 
    // 使用 SiliconFlow 提供的服务接口
    let robot = LLM(
        url: 'https://api.siliconflow.cn/v1/chat/completions',
        key: 'sk-[redacted]',
        model: 'Pro/deepseek-ai/DeepSeek-V3',
        memory: true
    )
 
    robot.preset([(System, '我会用林黛玉的风格回复哥哥的所有问题')])
 
    let client = TcpSocket(IP, PORT)
    client.connect() // 和服务端建立连接
    startInputListener(client)
    while (true) { // 在循环中不断接收服务端发来的消息并打印
        let data = Array<Byte>(BUFFER_SIZE, item: 0)
        client.read(data)
        println(String.fromUtf8(data))
        let res = robot.chat(String.fromUtf8(data))
        client.write(res.toArray())
    }
}

奖品

写得最快的同学可以获得一个华为手环

不过博主获得的是一个比较有崛起风格的Ｕ盘：

正面

背面印有 logo

另外，反馈说仓颉的鸿蒙部分即将开源。

从 HarmonyOS Sans 谈起：免商字体的协议问题

2025-04-26T15:43:59.124Z

版权许可

本作品采用 知识共享署名—相同方式共享 4.0 国际许可协议（CC BY-SA 4.0 International）许可，阁下可自由地共享（复制、发行）和演绎（修改、转换或二次创作）这一作品，唯须遵守许可协议条款。

HarmonyOS Symbol 图标库包含 1500+ 矢量图标，采用分层结构，支持独立设置颜色和灰度。HarmonyOS Symbol 还提供 7 种动态效果，可与用户操作匹配，实现更丰富的交互体验。这是国内首个以字库形式封装的Symbol资源……其可变字体特性允许图标粗细随字体调整同步变化。

OK，新闻稿上说的看起来很棒，让我看看怎么在 iconify 使用这套图标……等等，看样子是除了华为开发者联盟上需要每个手动选择下载的图标库，只以字体的形式提供了？

语焉不详

我于是便在这一网页上寻找；未果，又在开发者论坛上找相关讨论：

HarmonyOS Symbol 图标库里的资源可否免费商用？协议在哪里？（无回答）
图标、版权、商用。（回答称免费可商用）
华为开发者问答 | 华为开发者联盟（无回答）
HarmonyOS字体企业商用使用范围以及授权？（怎么还有金币悬赏……用户回答，援引百度百科）
鸿蒙HarmonyOS Sans字体可以申请授权使用吗？（无回答）
鸿蒙字体免费可商用细则是什么？（与协议一致）

接着，我试图从开源项目中找到协议。由于 OpenHarmony 与 HarmonyOS NEXT 在 UI 框架上的差异并不多，图标系统可能也和方舟 UI 框架（ArkUI）一样开源了。

翻了半天发现果然有个 ttf，以及一个 Apache 协议——Gitee 组织操作很麻烦。正确的搜索方式是从 OpenHarmony 组织主页的任务（issues）tab 下方的搜索框中搜索，可以找到 OpenHarmony/global_system_resources 仓中的 HMSymbolVF.ttf——再一看，仓库中同时有 LICENSE 和 LICENSE_Fonts，后者才是字体专用的协议：（协议只有英文，并且其中有一处逗号是全角逗号，以及序号后没空格，实在是有点搞笑）

License Notice
Copyright 2021 Huawei Device Co., Ltd.
HarmonyOS Sans Fonts Software is licensed under HarmonyOS Sans Fonts License Agreement.

--------------------------------------------------------------------------------
HarmonyOS Sans Fonts License Agreement

THIS HARMONYOS SANS FONTS LICENSE AGREEMENT ("AGREEMENT") IS A LEGAL AGREEMENT BETWEEN YOU (EITHER A SINGLE INDIVIDUAL, OR SINGLE LEGAL ENTITY) AND HUAWEI DEVICE CO., LTD.( "LICENSOR")FOR THE USE OF THE HARMONYOS SANS FONTS ACCOMPANYING THIS AGREEMENT.BY DOWNLOADING,COPYING OR OTHERWISE USING HARMONYOS SANS FONTS YOU INDICATE THAT YOU AGREE TO BE BOUND BY ALL OF THE TERMS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT, YOU MAY NOT DOWNLOAD, COPY OR OTHERWISE USE THE HARMONYOS SANS FONTS, AND YOU SHALL PROMPTLY DESTROY AND DELETE ALL THE HARMONYOS SANS FONTS.

1.Definition
"HarmonyOS Sans Fonts" shall mean the collection of fonts software components provided by Licensor under this Agreement and clearly marked as "HarmonyOS¬ Sans".

"YOU" shall mean an individual or legal entity exercising permissions granted by this Agreement.

2.GRANT OF LICENSE

Subject to the terms and conditions of this Agreement, Licensor hereby grant YOU a non-transferable, non-exclusive, royalty-free, revocable, worldwide copyright license to use,copy, merge, embed, bundle, redistribute and/or sell unmodified copies of HarmonyOS Sans Fonts with any software except for fonts software，subject to the following conditions:
1)YOU shall make a prominent notice in the software to state that HarmonyOS Sans Fonts are used.
2)YOU may not make any modifications to HarmonyOS Sans Fonts or any of their individual components.
3)Neither HarmonyOS Sans Fonts nor any of their individual components may be redistributed or sold in a stand-alone base. This limitation does not apply to any work created by using HarmonyOS Sans Fonts. You can freely distribute or sell your work, such as materials, logos, application software etc. created by using HarmonyOS Sans Fonts.
4)YOU shall retain the copyright notice and this Agreement in any copies of HarmonyOS Sans Fonts.

3.Termination
This Agreement will be automatically terminated if YOU breach any of this Agreement.

4.NO WARRANTY
YOU AGREE THAT THE HARMONYOS SANS FONTS ARE PROVIDED BY LICENSOR ON AN "AS IS" BASIS. LICENSOR MAKES NO WARRANTY, EXPRESSED OR IMPLIED OR STATUTORY, WITH RESPECT TO ANY OF THE HARMONYOS SANS FONTS, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT.

5.NO LIABILITY

IN NO EVENT SHALL LICENSOR BE LIABLE FOR ANY DIRECT OR INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) ARISING IN ANY WAY OUT OF THE USE OF OR INABILITY TO USE HARMONYOS SANS FONTS, WHETHER UNDER THEORY OF CONTRACT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY OR OTHER LEGAL THEORY, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

YOU EXPRESSLY ASSUME ALL LIABILITIES AND RISKS FOR USE OF HARMONYOS SANS FONTS. SHOULD THE HARMONYOS SANS FONTS PROVE DEFECTIVE, YOU ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

无独有偶

观察行业现状，类似限制性条款并非孤例。MiSans 的授权条款就和华为高度相似，均有禁止单独分发、在软件中需要显著提及使用等限制，其模板高度相似，考虑到两套字体都由汉仪参与制作，协议可能也只是统一的模板。

1） 您应在软件中特别注明使⽤了 MiSans 字体。
1) You shall specifically indicate in the Software that You are using MiSans fonts.
2）您不得对 MiSans 字体或其任何单独组件进⾏改编或二次开发。
2) You shall not adapt or redevelop MiSans fonts or any of their individual components.
3）您不得单独将 MiSans 字体或其组件对外租赁、再许可、给予、出借或进一步分发字体软件或其任何副本以及重新分发或售卖。此限制不适⽤于您使⽤ MiSans 字体创作的任何其他作品。如您使⽤ MiSans 字体创作宣传素材、logo、应⽤App等，您有权分发或出售该作品。
3) You shall not individually rent, sublicense, give, loan, or further distribute the MiSans fonts or their components, or any copies thereof, nor shall you redistribute or sell them. This restriction does not apply to any other work that You create using MiSans fonts. For example, if You use MiSans fonts to create promotional materials, logos, applications (Apps), etc., You shall have the right to distribute or sell that work.
4）您应在 MiSans 字体的任何副本中保留版权声明和本协议。
4) You shall retain the copyright notice and this Agreement in any copies of MiSans fonts.
5）不可将 MiSans 字体⽤于任何违法⽤途。
(5) You shall not use MiSans fonts for any illegal purposes.

那么，这样的限制性协议有什么问题呢？

显著说明

你应该在软件中显著地声明使用了 HarmonyOS Sans 字体。

好吧，我很乐意这么做，但是——

对于设计软件，如果提供一个字体列表供选呢？且不说这是否是再次分发，单就显著说明可能就有问题——字体列表里的名称是不是「显著」？难道要比其他字体都大一号吗？还是专门写一个致谢的页面？
对于其他软件，放到常见第三方开源库列表中，是否又能算是显著说明？

Photopea 的 issues 里就出了纰漏。有用户想加 HarmonyOS Sans，但不在 Google Fonts 之类的网站上。社区里有人翻出华为的英文官方博客说没问题，但又有人附上许可证条款。最后提议者自己怂了，默默关了讨论帖——

It might be better to include only fonts licensed under well-known licenses like OFL, in Photopea, to keep things simple and reduce potential issues.

对开发者来说，与其折腾法律条文，不如直接绕道。毕竟对于可选的、锦上添花的字体，没人想惹上官司的麻烦。

禁止修改

更值得推敲的是协议中的第四条：

您不得对 HarmonyOS Sans 字体或其任何 单独组件 进行任何修改。

「individual components」的定义边界是什么？条款禁止修改「字体或其任何组成部分」，但未界定组件是字体的单个字形（glyph）、轮廓数据（outline），还是其他，以及是否包含字重文件、轮廓数据等元素，抑或是将修改后的字形嵌入到作品中。这种模糊性可能导致，调整字宽、伪粗体是否属于「修改组件」都存在解释空间。不过 Mi Sans 做得不错，在其 FAQ 中解释了：

您可以自由调节字体的粗细、间距等。但您不得单独将 MiSans 字体或其组件进行外观上的更改。

以及，虽然禁止修改，但又允许用户用字体创作作品并自由分发这些作品。那如果我在设计一个 logo 时，对字体的某些部分进行了艺术性调整，这算不算修改？

此外，对于多文种字体，禁止修改会对字体造成很大的限制。Digital Tibetan 中写道：

藏文虽然只有一套定义明确的「标准」藏文音节，但由于梵文转写（如曼怛罗、汉语转写和宗喀语略语），存在许多扩展，因此通过提供所有可能的字形来生成「完整」的藏文字体实际上几乎不可能。

微软曾开发了一个可以动态渲染新的字形变体的系统，但无法在非 Windows 平台上运行，并且缺乏预先设计的字形的审美情趣。因此，藏文字体要么看起来不自然，要么不完整。如果需要录入此类文本，那么就会出现给定字体无法正确渲染所需堆叠的情况。

Mi Sans 作为目前屈指可数的藏文无衬线体，无法分发添加所需字形而对字体所做的任何更改，实在是遗憾。

修改字体本身常常是使用中不得不做的事情，甚至是因为字体提供方本身的原因，比如群友反馈，丁卯点阵体提供的 7px 版本浏览器无法正常解析。其实条款写成禁止再分发（无论是否修改的）字体，可能会更加合理。

再次分发

此外，禁止单独分发的规定对设计中同样令人困惑。

HarmonyOS Sans 字体及其任何单独组件都不得以独立形式重新分发或出售。

协议允许将字体嵌入应用软件或用于物料设计，但「单独分发」的定义却模糊不清。不能出售好说，防止二道贩子转卖；但分发则很广泛。例如将字体嵌入网页时，开发者常需通过 Webfont 分包的形式提供支持，但这是否构成「单独分发」？商业字体一般限制用户自行使用 Webfont，转而提供有页面浏览量限制的 CDN 服务。例如，丁卯点阵体虽然 boast itself as below：

由于「丁卯点阵体」字形大幅简化、文件体积小，适合用作 Webfont（网页字体），这在中文字体中是极其难得的。

但文末却写「个人不可以将字体直接应用于……以 webfonts 的形式嵌入商业网站」。另外，提供服务的做法亦有问题——这些服务提供的常常没有分包，而前端技术日新月异，不喜欢 JavaScript 的前端之猫也有自己的想法。

实际下载下来，你却会发现 Mi Sans 提供了 WOFF(2) 格式的文件，如果不希望用在 Webfont 上，为什么要提供这一格式？另外哔哩哔哩也确实就将 HarmonyOS Sans 用在了 Web 端，还做了 webfont，但这种做法如果不是私下里有沟通过，是否完全合规仍不可知。

应用软件

另一个问题出在 application software 的界定上。协议允许将字体嵌入到应用软件中，但什么是「应用软件」？Wikipedia 将其定义为「面向最终用户的软件」，但这种定义在法律语境中是否足够严谨？假设我写了一个简单的Hello World 程序并嵌入 HarmonyOS Sans，这算不算「应用软件」？如果算，我就可以分发这个程序；如果不算，界限又在哪里？

有趣的是，自由软件基金会（FSF）在评估 SIL OFL-1.1 时提到，虽然 SIL OFL 不允许单独分发字体及其任何一部分单独的元件，但

…字型軟體只要依附於任何一個軟體中，就可以滿足這個條件，即使是一個像 “Hello, World!” 般簡單的小程式也可以，而在不收取費用的狀況下使用者一樣可以自由散布字型軟體，因此 OFL-1. 這樣的規定不會實質地限制字型軟體的自由散布，OFL-1.1 仍被 FSF 判定是符合四大自由內涵的自由軟體授權條款。

不过这里 SIL OFL 并没有说 application software，而是 any software。

结语

私有协议导致字体的应用常面临技术和法律负担。即使是 OSI 认证过的 Mulan PSL 也会因使用较少而引发顾虑。DeepSeek 曾使用过私有协议，后来更换为 MIT，使用更通用的协议也是为了避免私有协议对使用者带来的理解成本。

开源字体生态的发展仍然值得借鉴。思源字体家族族采用 SIL OFL，明确允许字体嵌套于任意软件的条款，如今的使用不可谓不广泛。手机厂商花钱定制字体，但似乎又并不打算从定制字体上牟利，却在私有协议中采用这样不明确的表述，反而不利于字体作为数字基础设施的传播作用。

当然，这篇文章想表达的并不是诸如伪君子不如真小人之类的观点。除了作为一个对想使用这些字体的人的提醒，也是希望字体的版权方，不管是否有志于开源——如果想限制用户仅能在自家操作系统上使用，可以学 Apple 的苹方；如果有 branding 之虞，不希望用户再分发，也不妨避免一下自相矛盾，说得更清楚一点。

2025 年 3 月 5 日动笔，写于 RemNote。新世界的大门不提供法律建议。

BUAA-OS Lab0

2025-04-05T12:35:51.582Z

lab0

Lab 0 主要就是一个 Makefile 和 Linux shell 的练习。你可以从这里获取今年实验的公开指导书（截至发稿时的版本，存于互联网档案馆）。

练习题

Exercise 0.1

好久没写 C。虽然连 palindrome 都不会写了，但是好像懂得比以前多了很多）

剩下 3 问没什么难度。唯须注意的是：

[Makefile 中] 有一点尤为需要注意，每一个命令 (command) 之前必须用一个制表符（Tab）缩进。这里必须使用制表符而不能是空格，否则 make 会报错。

考试的时候被坑了。

Exercise 0.2

Shell 的条件和循环。

a=1
while [ $a -le 100 ]
do
        if [ $a -gt 70 ]
        then
                rm -r "file$a"
        elif [ $a -gt 40 ]
        then
                mv "file$a" "newfile$a"
        fi
        # ((a++))
        a=$((a+1))
        # don't forget change the loop variable
done

Exercise 0.3

# First you can use grep (-n) to find the number of lines of string.
# Then you can use awk to separate the answer.
 
grep -n "$2" "$1" | cut -d: -f1 > "$3"

cut -d 后面是分隔符，-f1 是第一个字段，即行号。

Exercise 0.4

./csc/code/modify.sh

sed -i "s|$2|$3|g" "$1"

需要 include 头文件。

./csc/code/Makefile

all:
        bash modify.sh fibo.c char int
        gcc -c fibo.c main.c -I../include

lab0-exam

GCC & Makefile Quiz

完成初始化后，仓库根目录下已经生成了 Makefile、check.c、src 文件夹和 out 文件夹。

在仓库根目录（如 ~/23xxxxx ）下编写 Makefile。要求实现的功能如下：

执行命令	实现功能
`make check`	利用 gcc 将同目录下的 check.c 编译成名为 check.o 的未链接的目标文件，并放在同目录下。
`make`	完成 `make check` 要求的功能。然后利用 gcc 将 src 下的 main.c、output.c 编译成名为 main 的可执行文件，并放在 out 目录下。
`make run`	直接运行可执行文件 out/main。
`make clean`	删除目标文件 check.o、可执行文件 out/main。

GCC & Bash Quiz

完成初始化后，仓库根目录下已经生成了 exam_1.sh 至 exam_9.sh（从1开始的连续整命令名的.sh文件，共9个）、run_exam.sh、stderr.txt 和 origin 文件夹。

在仓库根目录（如 ~/23xxxxx ）下编写 exam_1.sh 至 exam_9.sh。要求实现且仅实现以下第x点功能。

这些脚本将被 run_exam.sh 调用执行。使用 run_exam.sh 的命令格式为 bash run_exam.sh [n] [s] [t]，其中 n 为小于等于9 的整数，表示将按顺序执行 exam_1.sh 至 exam_n.sh。若 n 未给出，将默认是 9。可选的 s 和 t 用于传递给 exam_9.sh，具体要求见第 9 点功能。（注意：根据命令格式，若要指定 s 和 t，必须先指定 n）

这个部分讨厌的是评测点是累进的，由于后面的操作依赖于前面的操作，所以如果前面的操作没有正确实现，写完提交一看才十几分比较虚。不过文件操作的话，后面的操作可以作为前面的提示。

创建一个新的目录，名为 result。再在 result 目录下创建两个新的目录，名为 code 和 backup。
exam_1.sh
```
mkdir result
mkdir result/code
mkdir result/backup
```
将 origin 目录下的 basic.c 的文件中包含 hello（区分大小写）的行输出。
exam_2.sh
```
grep "hello" origin/basic.c
```
将 origin 目录下的 basic.c 文件移动到 result 目录下。
exam_3.sh
```
mv origin/basic.c result/basic.c
```
将 origin 目录下的 code 目录及其内容复制到 result/backup 目录下。
exam_4.sh
```
cp -r origin/code result/backup/code
cp origin/code/* result/backup/
```
不知道具体要求的是哪一种，似乎第一次尝试时没过评测。
将 origin/code 目录下的 0.c 1.c 2.c …… 20.c（从0开始的连续整数命名的 .c 文件，共21个）文件中的所有 REPLACE（区分大小写）替换为文件名（不含扩展名），替换的结果保存到 result/code 目录下的同名文件中。
如对于这样的 origin/code/1.c：
```
int main() {
    return REPLACE;
}
```
替换的结果如下，并且这个结果保存在 result/code/1.c 中：
```
int main() {
    return 1;
}
```
这里麻烦的是如何从路径提取不含后缀的文件名。之前打 Hackgergame 的时候研究过一番 shell 字符串处理（欠了两年题解没写:），但是都忘了。是次考前从图书馆借了两本 Linux Shell 编程的书，从例子部分偷到了用法。

Linux Shell命令行及脚本编程实例详解（第2版） book 2024 ISBN 9787302660194

by 刘艳涛、

出版社：清华大学出版社

《Linux Shell命令行及脚本编程实例详解（第2版）》是获得大量读者好评的“Linux典藏大系”中的经典畅销书《Linux Shell命令行及脚本编程实例详解》的第2版。本书第1版累计13次印刷，销量超过2万册，被ChinaUnix技术社区大力推荐。本书理论结合实践，全面、系统地介绍Linux Shell（Bash）脚本编程的语法、命令和技巧等内容。本书偏重于实践，在讲解理论知识时结合大量典型实例让读者了解理论知识在实际环境中的应用，并对易混淆和较难理解的知识点做了重点分析，以加深读者对知识的理解。本书提供教学视频、实例源程序、思维导图、教学PPT和习题参考答案等超值配套资源，以帮助读者高效、直观地学习。《Linux Shell命令行及脚本编程实例详解（第2版）》共15章，分为2篇。第1篇“Linux Shell基础知识与命令”，主要内容包括Linux和Linux Shell简介、初识Linux Shell、常用的Shell（Bash）命令、Shell命令进阶；第2篇“Shell脚本编程”，主要内容包括Shell编程基础、Shell的条件执行、Bash循环、Shell函数、正则表达式、脚本输入处理、Shell重定向、管道和过滤器、捕获、sed和awk、其他Linux Shell概述。《Linux Shell命令行及脚本编程实例详解（第2版）》非常适合初次接触Linux Shell命令行和脚本编程的入门读者阅读，也适合有一定基础而想进一步提升的进阶读者阅读，还适合作为高等院校和Linux培训机构的教材。对于基于Linux平台的开发人员而言，本书还是一本不可多得的案头查询手册。刘艳涛，就职于一家全球500强通信公司，从事公司无线产品研发中心的Linux／Unix操作系统的管理和技术支持。有超过15年的Linux系统管理与运维经验，擅长用Shell等脚本语言实现自动化运维管理，以及配置Nagios与Ganglia集成的自动化监控和故障报警平台，对Linux系统性能优化有深入的研究。

第 104 页
exam_5.sh
```
for file in `ls origin/code/*.c`
do
    filename=${file##*/}
    # echo $filename
    # echo ${filename%.*}
    sed "s/REPLACE/${filename%.*}/g" $file > "result/code/${filename}"
    # sed 's/REPLACE//g' $file >
done
```
- 从开头删除最短匹配的模式：var#
- 从开头删除最长匹配的模式：var##
- 从结尾删除最短匹配的模式：var%
- 从结尾删除最长匹配的模式：var%%
用 basename 的话，$(basename "$file" .${file##*.})。
将 result/code 目录下的全部 .c 文件一起编译为可执行文件 result/verify。
exam_6.sh
```
gcc result/code/*.c -o result/verify
```
运行可执行文件 result/verify，将其标准错误输出的内容追加到仓库根目录下的 stderr.txt 文件。
exam_7.sh
```
./result/verify 2>>stderr.txt
```
将 stderr.txt 文件的权限修改为 r--r-----。
exam_8.sh
```
chmod 440 stderr.txt
```
run_exam.sh 以 bash `exam_9.sh [s] [t]` 的格式向 exam_9.sh 传入两个参数 s, t（整数且 s < t）。
- 两个参数缺省时，输出 stderr.txt 的所有内容。
- 仅缺省 t 时，输出 stderr.txt 自行开始（行号从 1 开始编译，输出自第 s 行）至结尾的内容。
- 两个参数指定时，输出 stderr.txt 自第 s 行至第 t 行的内容（输出包含第 s 行，不含第 t 行）。
exam_9.sh
```
if [ -n "$1" ]; then
  if [ -n "$2" ]; then
    # echo "a"
    # echo "$(($2 - 1))"
    sed -n "$1,$(($2 - 1))p" stderr.txt
  else
    # echo "b"
    sed -n "$1,\$p" stderr.txt
  fi
else
  cat stderr.txt
fi
```
这块需要需要注意的是，sed 的 p 命令打印的行数从 1 开始，且包含结束行。head 和 tail 组合也可以，但是仍然需要。

提示

下发文件中包含一个初始化脚本 init.sh，如果你想将你的工作目录下除了 Makefile 和 exam_1.sh 至 exam_9.sh 之外的所有文件恢复到题目下发时的状态，可以使用命令 bash init.sh 执行该脚本。

将多个文件一起编译，可以借助通配符 *。如强制删除当前目录下的所有扩展名为 .txt 的文件可以使用 rm -f *.txt。

参考输出

使用下发的 init.sh 初始化后，执行 make 后再执行 make run 的参考结果为：

惊鸿一瞥 v5.0.0.135：鸿蒙微信现状

2025-03-31T02:30:25.250Z

微信 81 问

在应用商店，评论里会出现关于该应用不支持的功能列表。注意这个列表可能严重过时了，但是基本能代表我从抢测试版到现在的使用体验。我来尝试自适应一下：

不支持翻译
- 不用
不支持 QQ 登录
- 用 QQ 登录的号绑定了不用的手机号，安卓也登不上去
不支持长图查看
- 没遇到
不支持标签分组
- 什么是标签分组
不支持手表登陆
- 鸿蒙 5 的手机上微信不能连鸿蒙 5 的手表
不支持发图片时编辑
- 不需要。Reminder：在微信内编辑图片会上传并审查原图
不支持修改字体大小
- 系统设置里可以缩放显示大小（UI DPI），微信会跟随；但不跟随系统字体大小
不支持生物支付（人脸和指纹）
- 支付宝碰一碰每笔立减
不支持置顶聊天框折叠
- 不需要，另外别人的方法是真好，置顶了所有要用到的群
不支持搜索朋友圈
- 不用朋友圈
不支持搜索联想和记忆
- 不用微信搜索
不支持视频号小窗口化
- 关闭了视频号
不支持视频号转发朋友圈
- 不发朋友圈
不支持收藏转发
- 不转发
不支持收藏及已经收藏后的文件的再编辑
- 收藏了还编辑干嘛
不支持部分微信游戏消息
- 没有实名认证游戏部分
不支持部分二维码扫一扫
- 没遇到过
不支持公众号推荐给朋友
- 不向推荐朋友推荐封闭的内容生态
不支持公众号链接转发朋友圈
- 不发朋友圈
公众号文章不能单独调整字体、查找页面内容
- 这是对前端的侮辱。用正常浏览器，谢谢
公众号文章不能全文翻译
- 还能全文翻译？
公众号文章不能保存为图片、投诉
- 投诉人家干啥
公众号文章不支持浮窗
- 你开小窗吧，虽然这样不能在微信里用了
公众号文章不支持听全文、稍后听
- 用微信读书——哦，鸿蒙的微信读书更新频率太慢了，似乎今年第一次更新是 3 月 22 日，这个版本才加入了阅读时长上报和同步进度的功能。应用商店喜提 1.5 分
公众号文章不能收藏、在微信读书打开
- 当我没说。
长按公众号文章不支持转发、划线、收藏、搜一搜
- 没有表达欲，不过和菜头在槽边往事里乐见其成
不支持朋友圈背景动图视频设置
- 不用朋友圈
朋友圈浏览不支持按照年份浏览
- 不用朋友圈。其他平台上看别人的似乎也很麻烦吧
朋友圈不支持编辑、收藏、搜一搜
- 不用朋友圈
不支持星标
- 什么是星标
不支持更换铃声
- 不在乎别人那里听到什么。另外是不是对方的杀马特歌曲也听不了了？
不支持微信运动
- 看别人步数做啥
不支持群发助手
- 什么是群发助手
不支持面对面建群
- 开学季，不说了。可以扫别人的群二维码
不支持设置黑名单
- 不用
不支持修改微信号
- 不改，改了容易被出道，wxid 伟大发明
不支持设置聊天背景
- 其他平台居然还能设置聊天背景？？？
不支持推荐好友名片
- 不需要
不支持小程序部分功能
- 只遇到过华莱士，可以用支付宝小程序
没有卡包
- 不用
没有看一看
- 你瞅啥？
没有搜一搜
- 不搜，安卓发现页一个都没有
没有购物车
- 还能买东西是吗
没有位置共享
- 不需要
没有附近的人
- 不用
没有深色模式
- 晚上不看晦气东西
没有关怀模式
- 用不到；不过我有一声亲切的问候
没有我的朋友圈
- 不用
没有账号与安全管理
- 你在其他机器上登录的时候会自动帮你安全管理的吧
双击不能回到顶部
- 不用，鸿蒙微信的消息列表有时会很卡，建议你关掉应用重启一下就回到顶部了
撤回消息无法编辑
- 自己重新发一遍
消息不能直达聊天窗
- 什么是直达
聊天界面不支持动态（GIF）图片发送
- 这也不行？不过我似乎确实点不开别人发的丰川祥子动图
朋友圈不支持原图和 live 图发送
- 能不能统一一下话术，华为的这个叫作 moving pictures。另外小红书最近的更新支持在评论区里发了。
语音记录不能长按删除
- 不发语音。覆水难收！
零钱通不能查看资金明细
- 不看
定位不能发送到车机导航
- 没有车哈哈
语音接听挂断后还有小红点
- 小红点积压比较多，不管这个
PC 端聊天记录无法恢复也没法备份至 PC
- 上期说过，你想回退必须要有另一个手机，现在没法备份到 PC
语音或视频电话，挂断后会有提示框的
- 啥是提示框
不支持长按图标快捷扫码
- 实际操作起来并不快吧。另外，鸿蒙的长按图标快捷菜单不能一步到位，必须松手点，否则会拖动应用图标
不支持负一屏快捷扫码
- 鸿蒙负一屏有个快捷支付，只能选华为支付或者支付宝的付款码。
不支持智感扫码/支付
- 养成习惯了，不会使用这种特性
不支持 callkit
- 微信视频非常卡，考验鸿蒙性能的时候到了
全局不支持中转站
- 什么是中转站，鸿蒙以及华为电脑管家的那个？
不支持长按朋友圈联系人头像设置「设置权限和投诉」功能
- 这是什么
不支持分享到我的企业、分享到手机QQ、分享到QQ空间、更多打开方式
- 为什么要分享到 QQ 空间？
不支持当前聊天详情页面设置提醒、设置当前
- 聊天背景、投诉
不支持查看当前联系人的视频号
- 谢谢你
通讯录界面缺失，仅有聊天的朋友、标签、服务号
- 标签确实没有，添加好友的时候就没法设置
设置中缺少个人资料、账号安全、青少年模式、聊天、朋友权限、插件
- 不改就行了
- 这个插件似乎很搞笑，是腾讯自己的功能
新消息通知设置功能缺失：接收语音和视频通话提醒通知、显示消息详情、新消息系统通知、语音和视频通话提醒、聊天界面中的新消息通知
- 企业微信的消息会同时在微信和企业微信里推送，但是点开企微的通知后弹不出来相应的界面
- 在浏览小程序的时候，回到桌面再点开通知消息，仍然会进入小程序界面
缺失表情管理
- 不太发那些
不能清空聊天记录
- 用不到
无法开启横屏模式
- 这是平板吗
无法开启NFC
- 这是要干啥
不支持平板和手机同时登陆
- 真的假的
快速搜索聊天内容不支持类别，即聊天与视频、音乐与视频、交易、小程序、视频号
- 不过搜聊天记录基本能用，而且似乎比安卓上快
长按聊天图片不支持转发给、收藏、搜一搜、编辑、定位到聊天位置、此聊天中的图片视频
- 自己保存下，鸿蒙微信查看文件的功能非常简陋
不能从图片中翻译、提取文字
- 鸿蒙应该跟 Apple 一样提供直接的 OCR 方案吧。你用小艺也行
原先聊天记录里的撤回迁移过来变成了［该消息暂不支持］
- 压根没迁移，直接在电脑上看旧的就行了，这样你想回退的话再迁出聊天记录的时间也短

声音

上几个版本似乎把蓝牙 break 掉了，不管是在出境易中播放音乐，还是在鸿蒙原生应用中看视频，蓝牙耳机都有概率在 3 ~ 20 min 内无声，但实际应用还在播放。此时只要暂停后再播放，就能正常工作了。过了一两周修好了。

输入法

v5.0.0.135 SP5 的更新记录里写，小艺搜索

全面提升搜索体验，输入搜索内容时支持沉浸式键盘及拼音输入透传功能，输入过程中键盘与页面“融为一体”，字母会直接显示在搜索框中进行即刻搜索，搜索速度更快（需搭配使用1.0.17.300及以上版本的小艺输入法）

第一次见到把 buffer 或者 inline preëdit 叫这个的。但是，更新前我试了下，更新后发现似乎没变化，都是一样的行为，双拼「透传」的也是输入码而不是完整的拼音。

prefers-reduced-motion

鸿蒙的开发者选项里动画时长缩放只有一个选项，窗口切换都是算动画。关掉后，连滚动屏幕松开手指后的惯性、桌面左右切换的动画都没了，真的爽。

其他

负一屏可以添加卡片了。

最近写了一些仓颉，不出意外下一篇文章是这个。

制导与控制基础（中）：卫星轨道控制与姿态控制

2025-03-14T19:12:26.924Z

本文是课程《制导与控制基础》笔记的第二部分。该篇将聚焦于卫星轨道控制和姿态控制，包括卫星控制原理、卫星运动数学描述、卫量轨道控制以及卫星姿态稳定和机动。

写于 RemNote。

Typst 2025 社区通话

2025-03-09T19:24:52.281Z

Your browser does not support the audio element.

Laur

Question is asked the same question, really. There are a bunch of other things which I consider as important, which are not quite as large, but also complex. For example, better font handling across the board, like there's bunch of open issues with regards to font selection, font fallback, warnings, loading fonts from files, bundling fonts with packages or templates. So there's a lot of design space to be explored there, but it is quite important. Okay, what is the vision of the Typst Universe package approval process? Long term, especially as the amount of packages and updates would increase over time?

实际上，这个问题和之前问的差不多。还有一些我认为很重要，但规模没那么大，但也比较复杂的事情。比如，全面提升字体处理能力，像字体选择、字体回退、警告、从文件加载字体、将字体与包或模板捆绑等方面，都存在很多未解决的问题。这方面有很多设计空间可以探索，而且非常重要。好的，Typst Universe 包的审批流程的愿景是什么？特别是长期来看，随着包的数量和更新的增加？

Reknih

Yes, that's definitely something we've discussed. And in the team, the question is to like, to what extent, for example, do you can involve AI? We think that ultimately human review will be required to meet the requirements such as Typst Universe, especially the naming requirements. But we want to automate more of the process and we want to move into a model where some authors with like a good track record have a certain level of trust and can, for example, publish updates rapidly without blocking on human review.

是的，这绝对是我们讨论过的事情。团队内部的问题是，比如，在多大程度上可以引入 AI？我们认为，最终仍然需要人工审核来满足 Typst Universe 的要求，特别是命名要求。但我们希望更多地自动化这个过程，并希望转向一种模式，即一些拥有良好记录的作者可以获得一定程度的信任，例如，可以快速发布更新，而无需等待人工审核。

Laur

Especially for updates. Yeah, I think we could make that faster for initial. I think in general, the naming rule has been a success. People might have different opinions on that, but I personally consider it a success. I would say it's a larger success for packages than for templates, especially for templates, lots of templates are just the descriptive name with the prefix modern.

特别是对于更新来说。是的，我认为我们可以让初始设置更快。总的来说，我认为命名规则是成功的。人们可能对此有不同的看法，但我个人认为它是成功的。我想说它在包方面比在模板方面更成功，尤其是对于模板来说，很多模板只是带有前缀“modern”的描述性名称。

Reknih

Yeah, that's a bit of a disaster. But yes.

嗯，那确实有点糟糕。不过是的。

Laur

it's a bit defeating the purpose of the thing. Not really since but there still isn't one canonical package versus which is the point of the rule. But yeah, it's not great, but. Yeah, overall. Well, I could, I could imagine. I mean, and I also some thoughts on this, but right now it's already pretty automated. And we also want to have a custom basically website to submit packages in the future, gotta moving away from GitHub. And then aside from the name, there really isn't that much that needs to be checked manually. So I think the process can be scaled without basically not being true to its core anymore.

这有点违背了初衷。倒也不是说完全违背，因为仍然没有一个规范的软件包，而这正是规则的意义所在。但总的来说，情况不太好。嗯，我可以想象。我的意思是，我对此也有一些想法，但现在它已经相当自动化了。而且我们将来也想拥有一个定制的网站来提交软件包，从而摆脱 GitHub。然后，除了名称之外，实际上没有太多需要手动检查的东西。所以我认为这个过程是可以扩展的，而不会背离其核心。

Reknih

Yeah, and one thing that will make us migrate away from the repository eventually is not only that the number of package submissions is growing, but also the size of that repository is growing. And at some point, it becomes untenable to keep it in Git.

最终促使我们放弃这个仓库的原因，不仅是提交的软件包数量在增长，而且仓库的规模也在增长。在某个时候，用 Git 维护它变得难以为继。

Laur

Yeah, greetings to next packages.

祝贺下一个软件包。

Laur

Okay?

好吗？

Laur

Yeah, maybe. Imagine you can take this one with a journalist.

也许吧。想象一下，你可以和记者一起讨论这件事。

Reknih

Yeah, so right now we're working, started working together with a publisher and larger publisher in Scandinavia was not only publishing scientifically, but sort of across the board to work on a Typst enabled process. And that will be an interesting case study. What we think is that the typst adoption in the sciences basically needs to come bottom up. We think that Typst it is and should be adopted first for teaching, for theses, for tech reports, and for submissions where users publish camera ready documents and that only then there is leverage and demand in the community that allows us to approach publishers. So that's like from the social engineering side and also from the technical side and being a compelling proposition to the publishers.

好的，所以现在我们正在和一家出版商合作，是斯堪的纳维亚半岛一家比较大的出版商，他们不仅出版科学类书籍，也出版其他类型的书籍，一起合作开发一个支持 Typst 的流程。这将会是一个有趣的案例研究。我们认为 Typst 在科学领域的应用基本上需要自下而上地进行。我们认为 Typst 应该首先被用于教学、论文、技术报告以及用户提交相机就绪文档的场景，只有这样，社区中才会有足够的推动力和需求，从而使我们能够与出版商进行合作。所以这是从社会工程的角度来看，同时也是从技术的角度来看，使其成为对出版商有吸引力的提议。

Reknih

As businesses, we think that we want to flesh out HTML's support and bring it out of the experimental stage so that doing submissions and is really compelling with regards to multi-channel channel, independent publishing, and getting a web version of a paper right away. And that could bring the publisher a tangible benefit. And at that time, it's a survival for us to approach them to do deals. I don't think that currently work manpower is best invested in approaching publishers because I think those projects have quite long lease cycles.

作为企业，我们认为我们应该完善对 HTML 的支持，并使其脱离实验阶段，以便在多渠道、独立发布和立即获得论文的 Web 版本方面，提交内容真正具有吸引力。这可以为出版商带来切实的利益。到那时，为了生存，我们需要与他们达成协议。我认为目前投入人力去接触出版商并不是最佳选择，因为我认为这些项目的周期相当长。

Laur

Whereas one quick interruption. I think we learned from the previous multi calls is that not just we, but also you want a bit more interactivity? It's quite a frontal right now. So if you want to speak at any point in time, you can just request to speak and then you can also just tell us your question or tell us your opinion so that we can have a bit of more of a discussion here. Only if you don't do that, we will just continue to read the Q&A.

刚才有个小小的打断。我想我们从之前的多次会议中了解到，不仅仅是我们，你们也希望有更多的互动性？现在这种形式有点像单方面的演讲。所以如果你想在任何时候发言，你可以请求发言，然后你也可以直接告诉我们你的问题或你的意见，这样我们就可以进行更多的讨论。如果你们不这样做，我们就只能继续读问答环节的内容了。

Reknih

so for example Adrik has raised their hand. Hey, Adrik?

比如，Adrik 举手了。嘿，Adrik，你好吗？

Laur

Yes, let's mute.

让我们静音。

Reknih

Request him to unmute. If I can do that on Discord, I don't think so. Yes.

请求他取消静音。如果我能在 Discord 上做到，我想应该也可以在这里做到。是的。

Adrik Ivanov

yes, okay. So I have also posted it on Slido, but, you said that there is warichū or whatever in the roadmap. So as far as I know, what is like Japanese and CJK annotation for text, kind of like the footnotes and also Ruby and then some, no, something relating to Japanese typesetting. How far along in the development process is it going to take to get a point, the CJK typesetting things, CJKV?

好的。我也在 Slido 上发布了，但是，你说路线图里有割注之类的东西。据我所知，那是指日语和 CJK 文本的注释，有点像脚注和 Ruby，还有一些与日语排版相关的东西。

Laur

So, what we, what I can say is that we have this is maybe also an announcement.

要到什么程度的开发过程才能实现 CJK 排版，CJKV？我们可以说——这也许也是一个公告……

Laur

We will hire a new Rust developer, full time Rust developer soon. Thanks to external funding from a company that we will also disclose soon, I think. And CJK will probably not be their first focus, but I think this could be a focus. So right now we're just quite stretched for resources. But once that person is more, basically. Involved in the project then, I could imagine, for example, making CJK a priority there. So I really can't give a time frame, but I would say in the medium term, it is definitely a priority.

我们很快会聘请一位新的全职 Rust 开发者。感谢一家公司的外部资助，我们也会尽快公布这家公司。CJK 可能不会是他们首要关注的重点，但我认为这可以成为一个重点。所以现在我们的资源非常紧张。但是一旦那个人更多地参与到项目中，我就可以想象，例如，将 CJK 作为优先事项。所以我真的无法给出时间表，但我想说，在中期，这绝对是一个优先事项。

Reknih

Yeah, and what I also want to say in terms of CJK is that we are really dependent on the community for the moment since we do not have any native speakers of any CJK language or even a second language speakers of a CJK language on our team. So we don't really know firsthand what the conventions are. And I think we've got a few amazing contributors in the community. For example, around Tinymist, where a lot of the community members contributing there are from China. And then also in the main compiler repo, and that we are dependent on the input and export. And I would say that if you're a resident of either France or Germany, then you should keep your eyes peeled if you want to join us as a full time developer for Rust in our team and, um, we will post a job posting here on our Discord and it will be visible on GitHub and on our web page as well.

是的，关于 CJK（中日韩统一表意文字），我想说的是，目前我们非常依赖社区，因为我们的团队中没有任何以 CJK 语言为母语的人，甚至没有以 CJK 语言为第二语言的人。所以我们并不真正了解第一手的惯例。我认为我们在社区里有一些很棒的贡献者。例如，在 Tinymist 方面，很多贡献者都来自中国。然后在主编译器仓库中，我们也依赖于大家的输入和输出。我想说，如果你是法国或德国的居民，如果你想加入我们的团队，成为 Rust 的全职开发者，请密切关注，我们将在 Discord 上发布招聘信息，GitHub 和我们的网页上也会显示。

Laur

I mean this is a small ad ad segment. This is will be the dream open source job because we are contractually obliged because this wrote a sponsors that the person only works on open source stuff.

这是一个小小的广告环节。这将是梦想中的开源工作，因为我们有合同义务，因为我们的赞助商规定这个人只能从事开源工作。

Reknih

Exactly and in the chat with regards to only hiring in Benelux, only hiring in Germany and France or and not in Benelux, they say speakers, we have our payroll setups for Germany and France and really for each European country. You need your own payrolls accountant and we are not in the business of collecting payroll accountants now and hiring outside of the European Union is even more complicated. And ultimately, that's money we want to pay as a salary and not to some third party accountant.

没错，在聊天中，关于只在比荷卢经济联盟、德国和法国招聘，或者不在比荷卢经济联盟招聘的问题，他们说，我们的工资系统是为德国和法国设置的，实际上每个欧洲国家都需要自己的工资单会计，而我们现在不做收集工资单会计的事情，而且在欧盟以外招聘就更复杂了。最终，我们希望把钱作为工资支付，而不是给第三方会计。

Laur

If another person that had requested to speak. Shockjaw? I'll invite you to the stage.

如果还有其他人想发言——Shockjaw？我会邀请你上台。

Shockjaw

Thanks, I appreciate you dragging me up here.

谢谢，感谢你把我拉上来。

Shockjaw

One thing I am kind of curious about, is the potential roadmap for tagged PDFs for like accessibility requirements and other fun stuff like. What that roadmap may look like?

我有点好奇的一件事是，带标签的 PDF 的潜在路线图，比如可访问性要求和其他有趣的东西。这个路线图可能是什么样的？

Laur

Yeah, so the first thing that will need to happen, but to make this journey start is that the outstanding pull request and to migrate Typst to killer needs to be completed and merged. So this is something that Laur also Laurenz, like me, is working on. He's also in the call. That is also sort of a bit blocked on me, but this is definitely something we want to get done for v0.14. And then hopefully we'll also start with tagging. v0.14 will most likely not have and full support that we can really confidently say tagged true, but we will start and then hopefully continue over the next release or releases. But it is alongside HTML the top priority on the compiler side. I'm curious. I'm curious whether you have had requirements for tech PDF or whether you're just an accessibility enthusiast.

好的，要开始这个过程，首先需要完成并合并待处理的 pull request，将 Typst 迁移到 killer。Laur，也就是 Laurenz，和我都在做这件事，他也在这次会议中。这件事也稍微卡在我这里了，但我们肯定想在 v0.14 版本中完成。然后希望我们也能开始使用 tagging。v0.14 版本很可能不会有完整的支持，让我们能自信地说 tagging 为 true，但我们会开始，然后希望在接下来的一个或多个版本中继续。但在编译器方面，它与 HTML 一起是最优先事项。我很好奇_我想知道你是否有对 tagged PDF 的需求，或者你只是一个无障碍爱好者。

Shockjaw

As a part of my government work, yes. PDF 2/A requirements are part of it.

作为我政府工作的一部分，是的，PDF 2/A 是其中一部分要求。

Laur

An arduous requirement nonetheless.

尽管如此，这仍然是一个艰巨的要求。

Reknih

Yeah, sounds like a lot of things are coming off the back of HTML support, which I'm quite stoked about. Exactly, and we also have a contributor contributing, as Laurence said, new PDF stag. So there should be a lot of work on tech PDF coming from that as well.

是的，听起来很多东西都是基于 HTML 支持而来的，我对此感到非常兴奋。没错，正如劳伦斯所说，我们还有一位贡献者在贡献新的 PDF 功能。因此，在 tagged PDF 方面应该会有很多工作。

Laur

Yeah, it should take credit, but purchase Duo. I think this is the larger thing that enables this now than the HTML work. All right?

是的，……。我认为这比 HTML ……

Reknih

Exactly, and okay, exactly. You can just request to speak and otherwise we'll keep the storytel in the slider and we'll send an email to the speaker who has with their session and if they come online of they should request to speak. That's the ERP talk. And if not, we'll continue with the call as we are right now.

没错，好的，没错。你可以直接申请发言，否则我们会保持故事在幻灯片中，我们会给会议的发言人发送邮件，如果他们上线，他们应该申请发言。这是 ERP 的讨论。如果没有，我们将像现在这样继续通话。

Reknih

All right, do we dive into the next top right question? Or do we have .

好的，我们直接开始下一个右上角的问题吗？还是说…

Laur

the third one done? Because the one, so I don't think we have current numbers, but if you want to have a rough idea where we add, then you can go to YouTube and watch the video of Martin's keynotes he gave at the Typst's Berlin meet where some of these numbers are.

第三个做完了吗？因为那个，所以我不认为我们有最新的数据，但如果你想大致了解我们在哪里增加，你可以去 YouTube 观看 Martin 在 Typst 柏林聚会上发表的主题演讲视频，里面有一些数据。

Reknih

I can just that we have about 10K weekly active users in the web app and that the growth trajectory has recovered from Christmas. And that growth, especially around Typst 0.13 as well, is quite dynamic at the moment.

我可以说我们在 Web 应用中大约有 1 万名周活跃用户，并且增长轨迹已经从圣诞节恢复。而且，尤其是在 Typst 0.13 版本发布前后，增长势头目前非常强劲。

Laur

All right, would CeTZ has to be a package level? Typst have some high level capabilities like that directly?

好的，CeTZ 必须是包级别的吗？Typst 是否有一些类似的高级功能可以直接使用？

Reknih

Um, I think I think question marks betray a French speaker.

嗯，我想问号暴露了法语使用者的身份。

Laur

Yes, definitely, you can always see a French speaker online, But so, so I, what I want to in the medium term is not replacing CeTZ, I think.

是的，当然，你总能在网上看到说法语的人。但所以，我中期想做的不是替换 CeTZ。

Laur

That is not the right direction to go in, but rather to have more useful primitives that packages like CeTZ can use. Right now, they really have to do a lot of basically working around the compiler or shipping complex things. At least that's my understanding of it. So for example, the for the path function, the old one, which is not duplicated, didn't allow for multiscale point path, which is a pain.

那不是正确的方向，而是应该有更多有用的原语，像 CeTZ 这样的包可以使用。现在，他们真的必须做很多基本上是绕过编译器或者发布复杂的东西。至少我理解的是这样。所以例如，对于路径函数，旧的那个，没有被复制的那个，不允许使用多尺度点路径，这很麻烦。

Laur

And I could also imagine having things like polygon intersections or binary shape operations natively in typst and better alignment primitives. But it would be more the drawing side and maybe even a bit more low level than CeTZ. Then we do not plan to have plotting built into Typst anymore. Like we had that on our website for a while, but we have removed that. I think that's best left to packages and it's cool that packages can do so many things without having to build everything in.

我还可以想象在 Typst 中原生支持多边形相交或二元形状运算，以及更好的对齐原语。但这更多的是绘图方面，甚至可能比 CeTZ 更底层一点。我们不打算在 Typst 中内置绘图功能了。就像我们之前在网站上放了一段时间，但我们已经删除了。我认为最好留给包来做，而且包可以在不必构建所有东西的情况下做这么多事情，这很酷。

Reknih

And I also think that, especially with Typst upcoming, if you have seen, for example, make sense's talk about Lilac at the meetup and he's working on that. Yeah, definitely a definitely watch that because it's a great talk. And second of all, I think that with plotting libraries in the community, there can be some competition about API design and stuff. And it's a more dynamic space in which it's easier to like iterate on these giant API surfaces.

而且我也认为，特别是随着 Typst 的发展，如果你看过，比如说，make sense 在 meetup 上关于 Lilac 的演讲，他正在做那个。是的，绝对值得一看，因为那是个很棒的演讲。其次，我认为社区中的绘图库在 API 设计等方面可能会存在一些竞争。这是一个更具活力的领域，更容易在这些巨大的 API 表面上进行迭代。

Laur

You see that even just with our official templates, which sadly, less well maintained than many community or let's say the good community templates, our packages, I think spreading things out of the community is good because it just gives just a larger space to the mass stuff, people working on stuff and coming up with stuff.

你可以看到，即使是我们的官方模板，很遗憾，它们的维护不如许多社区模板，或者说好的社区模板、我们的包。我认为将事情分散到社区中是件好事，因为它只是给大众提供了更大的空间，让人们可以做事情、想出东西。

Reknih

All right? Then I think we have a speaker request, and I'll invite whomever had that request to stage or no, they've withdrawn their request. This is your opportunity to read request to go to stage. Otherwise, I think we'll move on with the questions.

好的吗？然后我认为我们有一个演讲者请求，我会邀请提出请求的人上台，或者不，他们已经撤回了请求。这是你提出上台请求的机会。否则，我想我们将继续提问。

Reknih

Right?

是吗？

Laur

I guess.

我猜是的。

Reknih

questions. I guess our balance columns are short term goal. If you ask me, they are. I have, yes, yes, and unfortunately, Laurenz is a compiler tech lead, so unless I have been told that in principle they are easy, but there are few annoying edge cases which I don't want to think about right now, not ever.

问题。我猜我们的平衡列是短期目标。如果你问我，它们是。我有，是的，是的，但不幸的是，Laurenz 是一个编译器技术负责人，所以除非有人告诉我原则上它们很容易，但有一些烦人的边缘情况，我现在不想考虑，甚至永远不想考虑。

Reknih

Yeah, the last part maybe wasn't entirely truthful.

嗯，最后一部分可能不完全是实话。

Laur

I think the right time for balance comes might have been 0.12 because it's fits with all these relay out things we did then. So that would have deleted even further. In principle? It is not super complex, I think, but it is definitely tricky because it involves relayer to balance things out. And I don't want to really want to drag the focus away from HTML and PDF right now. Yeah.

我觉得平衡的最佳时机可能是 0.12 版本，因为它与我们当时做的所有这些重排版的东西相吻合。所以这可能会进一步删除。原则上来说，它不是超级复杂，我认为，但它绝对很棘手，因为它涉及到重排版来平衡。而且我现在真的不想把注意力从 HTML 和 PDF 上移开。是的。

Reknih

and I'd say that tax point 12 was like a giant a cycle thriller because the release cycle was so fucking long. We wanted to ship and like two months before the release, we thought we could ship, We could cut the release in 10 days.

我觉得 Typst 12 就像一部巨大的周期惊悚片，因为发布周期太他妈长了。我们想发布，在发布前两个月，我们认为可以发布，我们可以在 10 天内完成发布。

Laur

Try refactoring footnotes and making them work in a new layout engine. Another the constant block of release.

尝试重构脚注，使其在新布局引擎中工作。另一个是持续不断的发布障碍。

Reknih

like. Like for example, like my family is like, what's what's happening at Typst? So we are working on footnotes, but we're working on footnotes. Four months ago, I was like, yes.

比如，比如，我的家人会问，Typst 进展如何？所以我们正在研究脚注，但我们已经在研究脚注了。四个月前，我就觉得快完成了。

Laur

Anyway, so balanced columns, I would say are a medium priority. Probably not 0.14, maybe 0.15. It's...

总之，我认为平衡列是一个中等优先级的功能。可能不会在 0.14 版本中发布，也许会在 0.15 版本中。

Reknih

Yeah, it can excuse for me personally, after this call.

好的，对我个人来说，这次通话结束后可以请假。

Laur

And if someone wants to step up, I think that is possible, but tricky. So I'm definitely open to it. But to step up for this, you would basically need to get your mind into this whole relay out thing, maybe read the layout blog post I wrote, and maybe start a discussion in the layout forge. And then it can be done as a community contribution. Otherwise it we'll need to wait for one more one or two releases.

如果有人想主动承担，我认为这是可能的，但很棘手。所以我对此持开放态度。但要主动承担这件事，你基本上需要全身心投入到整个布局相关的事情中，也许可以读一下我写的布局博客文章，也许可以在布局的 forge 中发起讨论。这样就可以作为社区贡献来完成。否则，我们需要再等一到两个版本。

Reknih

Yeah, and I hear that Tinger has a water situation on his hands in the chat, so I would like to extend my excuses for being too entertaining on this call. I see that that wasn't expected.

好的，我听说 Tinger 在聊天中遇到了问题，所以我想为我在这次通话中过于活跃而道歉。我看到这是意料之外的。

Laur

The whole point.

重点就在于此。

Reknih

I think, I think that was the whole point. Entertaining sexy people and preparing 5 minutes before. Yes, em, but you can see that since our speakers aren't here, by the way, if you are the speaker for Typst in an ERP session, again, if you're join now, no problem, please request this week. Let's move on to the next operated question. Directory Walking would be awesome for the next version. I have a few use cases for dynamically passing files in my project dictionary directory. Laurenz, Does directory walking violate the guarantees that Typst give to its users or is it okay since in the project dictionary directory.

我觉得，我觉得这就是重点。让性感的人娱乐，并在 5 分钟前准备。是的，嗯，但你可以看到，因为我们的演讲者不在这里，顺便说一句，如果你是 Typst 在 ERP 会议上的演讲者，再说一遍，如果你现在加入，没问题，请在本周提出请求。让我们继续下一个操作问题。目录遍历对于下一个版本来说会很棒。我有一些用例，可以在我的项目目录中动态传递文件。Laurenz，目录遍历是否违反了 Typst 给用户的保证，或者在项目目录中是否可以？

Laur

it doesn't violate anything? It needs to have a good interface and in the compiler, basically, and it needs to have a good interface in the language, which is basically two design problems. And if I remember correctly, there is a bunch of discussion around that already on GitHub, and we decided that it is blocked on a path type because if you basically just have a walk or whatever function, then you can't really distinguish well between files and directories. And with a path type, that would be a bit nicer. The path type is something that I definitely also want to ship soon.

它没有违反任何东西，是吗？它需要在编译器中有一个好的接口，基本上，并且需要在语言中有一个好的接口，这基本上是两个设计问题。如果我没记错的话，GitHub 上已经有很多关于这方面的讨论了，我们认为它被路径类型阻塞了，因为如果你只是有一个 `walk` 或者其他什么函数，你就不能很好地区分文件和目录。有了路径类型，会更好一些。路径类型也是我肯定想尽快发布的东西。

Reknih

I'm not sure the next one after. Basically, the whole path situation also plugs into yielding, for example, multiple files out of one Typst document when doing HTML export. So you have like multiple HTML document I can link to each other that you can navigate between. That's one of the things we want to do, for example, to switch our internal documentation systems payload to Typst, either standalone or integrated into our web framework. And path type is maybe a part of the puzzle there, or at least a related topic.

我不确定下一个是什么。基本上，整个路径的情况也与 yielding 有关，例如，在进行 HTML 导出时，从一个 Typst 文档中导出多个文件。所以你有多个 HTML 文档，它们可以相互链接，你可以在它们之间导航。这是我们想做的事情之一，例如，将我们的内部文档系统 payload 切换到 Typst，无论是独立的还是集成到我们的 Web 框架中。路径类型可能是其中的一部分，或者至少是一个相关的话题。

Laur

Yeah. And the path type...

是的。而且路径类型...

Reknih

...

Laur

...thought of prepared a bit?

...想好了准备一下吗？

Reknih

The last with...

Laur

The deprecation of the path function, because I didn't just want to swap it out.

路径函数的弃用，因为我不想直接替换它。

Reknih

And I just wanted to answer the second post. I voted questions since it's so similar to what we've answered before, which is what will be the focus of the next release? And we've all already talked about it a lot. So the focus will be improvements through HTML export like asked and PDF accessibility, as well as like some standards, in particular PDF/UA-1 and PDF/H too, eh.

我只是想回答第二个帖子。我投了重复问题，因为它和我们之前回答过的问题非常相似，也就是下一个版本的重点是什么？我们都已经讨论过很多次了。所以重点将是通过 HTML 导出的改进，比如提问和 PDF 可访问性，以及一些标准，特别是 PDF/UA-1 和 PDF/H too。

Laur

Once again, the reminder... This is exactly what I'm talking about. The reminder that if you request to speak, you get protein treatment in response to the questions because we prefer to not speak into the void.

再次提醒...这正是我要说的。提醒一下，如果你请求发言，你会得到针对问题的优先处理，因为我们不喜欢对着空气说话。

Reknih

Yes? Welcome back.

是吗？欢迎回来。

Reknih

Yeah. Thanks for round 2. So I guess mine's a little bit more specific. I've noticed that quarto is kind of taking a liking to Typst for PDF exports. Are there more conversations with Posit as a whole for and...

好的，感谢第二轮。我觉得我的问题可能更具体一些。我注意到 Quarto 似乎越来越喜欢用 Typst 来导出 PDF 了。那么，和 Posit 整体之间，是否有更多关于……的讨论？

Pachi

maybe hopefully funding. Who knows?

也许能拿到资金，谁知道呢？

Laur

This is the time to mention that Posit is the company that will sponsors of the full of time road.

现在是时候提一下，Posit 公司将会赞助全职的 Road 项目。

Reknih

Haha, I figured.

我猜到了。

Reknih

Yeah.

Reknih

And so first of all, thank to them for their support. And second of all, I feel like with their contribution Quatro's needs will have like a direct connection with them and going forward we will have regular syngaps with posets team Carlos from Caro in particular. So if there's something they need, certainly input they are entitled to give.

首先，感谢他们的支持。其次，我觉得有了他们的贡献，Quatro 的需求会和他们直接联系起来，未来我们会和 Posets 团队定期进行同步，特别是和 Caro 的 Carlos。所以如果他们有什么需要，当然有权提出意见。

Laur

Then, since somebody else requested to speak, we can continue in the slido. Revoke route update. Yeah, so I think that fits into a general like to the styling topic. There are a bunch of things I don't really like about the styling system. For example, how default `show`, `set` rules work, basically that if you write show heading and then replace it with something entirely else, it's still bold. This was sort of a side effect of the way we changed.

既然有人要求发言，我们可以继续处理 Slido。撤销路由更新。是的，我认为这属于一个更广泛的样式主题。我对样式系统有很多不喜欢的地方。例如，默认的`show`、`set`规则的工作方式，基本上如果你写了 show heading，然后用完全不同的东西替换它，它仍然是粗体。这是我们改变方式的副作用。

Laur

It will definitely become a topic again. But not for 0.14. It also ties in with custom elements because for custom elements of the hacks that we have in the compiler, we will need decide whether we expose them or not. For example, we have this locatable annotation on elements in the compiler that basically says, does this work with query? And the reason this exists is because making everything locatable is just not really feasible in the current implementation is too expensive. Our custom, some elements. I don't want to have a locatable annotation, so we'll need to figure something out. And this is also part of the reason why custom elements are for key. Next question is custom elements when we already answered that.

这肯定会再次成为一个话题。但不是在 0.14 版本。它也与自定义元素有关，因为对于编译器中我们所做的自定义元素 hack，我们需要决定是否公开它们。例如，我们在编译器中的元素上有一个可定位的注解，它基本上说明了这个元素是否能与 query 一起使用？之所以存在这个注解，是因为在当前的实现中，让所有东西都可定位实际上是不可行的，成本太高了。我们的自定义元素，我不想有一个可定位的注解，所以我们需要想出一些办法。这也是自定义元素是 key 的原因之一。下一个问题是自定义元素，我们已经回答过了。

Reknih

yeah.

Reknih

And I want to, I just have had a look at the questions that are done there. And I want to pull one up because we already sort of talked about it. Yes UA will be a focus for the next release.

我想，我只是看了一下那里提出的问题。我想挑一个出来，因为我们已经讨论过了。是的，UA 将是下一个版本的重点。

Reknih

And one thing that I want to add to the whole European regulation, I think, yeah, there's upcoming regulation for accessible documents the Americans cited for a while and the Americans with it. AB, this act, otherwise known as Ada. But there's another piece of European regulation that is upcoming, which is that electronic invoicing will be compulsory for B2B transactions. And that means that you PDF file basically contains an attachment XML file that is machine readable and describes your invoice. And largely thanks to contribution PDF, embedding any file as a feature that shipped in 0.1. But we're still missing the last puzzle piece, which is amending the Pdf's metadata stream such that it says, hey I'm an invoice. And that's something that could certainly ship in a PDF focus release.

我想补充一点关于整个欧洲监管的，我认为，是的，即将出台关于无障碍文档的法规，美国人引用了一段时间，还有美国的 AB 法案，也就是 Ada。但还有一项即将出台的欧洲法规，即电子发票将成为 B2B 交易的强制要求。这意味着你的 PDF 文件基本上包含一个附件 XML 文件，该文件是机器可读的，并描述了你的发票。很大程度上要感谢 PDF 的贡献，嵌入任何文件都是 0.1 版本中的一个功能。但我们仍然缺少最后一块拼图，那就是修改 PDF 的元数据流，使其声明，嘿，我是一张发票。这肯定可以在 PDF 重点版本中发布。

Laur

Okay, so on the question of which breaking changes you would like to do, if you had something to change the Typst right now, what would it be so? I have an old message in the Discord server about that, and part of it is still applicable. So let me just link that in the chat, A bunch of it would maybe be a bit different though, but some of these things I still would like to change, but they're just so, so large breaking changes that we sort of have to bundle them to not make it a horrible experience.

好的，关于你想做的重大更改的问题，如果你现在要更改 Typst，你会改什么？我在 Discord 服务器上有一条关于此的旧消息，其中一部分仍然适用。让我把它链接到聊天中，其中很多可能有点不同，但其中一些东西我仍然想改变，但它们是如此巨大的重大更改，以至于我们必须将它们捆绑在一起，才不会造成糟糕的体验。

Laur

Okay, will it be possible to write tabs universe readme of packages in types?

好的，是否可以用 Typst 编写关于包的 tabs universe 自述文件？

Reknih

I would say that it's safe to say that yes, once HTML export is more mature.

我认为可以肯定地说，是的，一旦 HTML 导出更加成熟。

Reknih

And have you considered? Yeah.

你考虑过吗？嗯。

Laur

the list is old. Not all of the things in the list are accurate. I just didn't want to make a new list now because I don't have any.

这个列表有点旧了，里面的东西不完全准确。我只是现在不想重新做一个新的列表，因为我手头没有。

Reknih

What.

Laur

and I don't have a new list, That's what I want to say because that was not English.

我没有新的列表，我想说的是这个，因为刚才说的不是英语。

Reknih

yeah. All right, let's go for the next question. Have you considered a way to give more? Version compatibility, Just compiler version and all other packages. I would like to maybe invite the guy.

好的。我们来看下一个问题。有没有考虑过提供更多的版本兼容性？比如编译器版本和所有其他包的版本。我想邀请一下这位朋友。

Laur

And so many of them became breaking with Evers. And I was wondering if there would be maybe a way to define a maximum version... compatibility version with Typst or something that could be useful.

很多包在最新版 break 掉了。我在想是否有可能定义一个与 Typst 的最大版本兼容性或类似的东西，这可能会有用。

Laur

This has come up a bunch of times, but it's sort of tricky because if you put it in your Typst ???, you basically didn't look into the future, right?

这个问题已经出现过很多次了，但这有点棘手，因为如果你把它放在你的 Typst ???中，你基本上没有考虑到未来，对吧？

Lord

Yeah. That's the issue. And so I was just wondering if you had maybe discussed of a system that could work for this, because I saw there was an issue on GitHub, I think that was closed for the reason you just said.

是的。这就是问题所在。所以我只是想知道你们是否讨论过一个可行的系统，因为我看到GitHub上有一个问题，我认为是因为你刚才说的原因而被关闭的。

Laur

I think the only way I can see doing it is having this metadata externally somehow in Typst Universe. But what I dislike about that, I don't really want the compiler to make choices depending on separate metadata that doesn't come with a package, because the package doesn't necessarily come from type universe. It should come from a directory or somewhere else. I think a better way to go about this is to have. I'm not quite sure whether I would have this in the compiler, but definitely in things like Tinymist and the web app now just to upgrade packages. And we could we have like a warning. Oh, this package is outdated. Perhaps try updating it if there's an error.

我觉得我能想到的唯一方法是在 Typst Universe 中以某种方式外部存储这些元数据。但我不喜欢这样，我真的不希望编译器根据与包不在一起的单独元数据做出选择，因为包不一定来自 type universe。它应该来自一个目录或其他地方。我认为更好的方法是拥有。我不太确定是否应该在编译器中加入这个，但肯定会在 Tinymist 和 Web 应用程序中加入，以便升级软件包。我们可以发出一个警告，例如“哦，这个软件包已过期。如果出现错误，请尝试更新它。”

Reknih

I was in a culture talk with someone who was using the Springer paper templates. So Springer paper template, basically. And she said, oh, it's not compatible with Typst 0.13 because it didn't updated...

我当时在和一个使用 Springer 论文模板的人进行文化交流。就是 Springer 论文模板。她说，哦，它与 Typst 0.13 不兼容，因为它没有更新……

Reknih

Says I could imagine that we introduced a new package submission process. Typst could be aware of the test suit offer package Typst could be aware of, all right there examples. And new readme and we need those to compile. And if they stop compiling, then Typst Universe will start like graying out the package and displaying a warning. This thing is not compatible with the latest Typst version. So basically that would mean a problem each release, rerunning acceptance shapes against the packages and marking the packages that don't pass as not compatible.

我觉得我们可以设想一下，引入一个新的包提交流程。Typst 可以知道测试套件，提供包 Typst 可以知道的例子，都在那里。还有新的 readme，我们需要它们能够编译。如果它们停止编译，那么 Typst Universe 就会开始灰显该包并显示警告，提示此包与最新的 Typst 版本不兼容。所以基本上，这意味着每次发布都会出现问题，需要针对这些包重新运行验收形状测试，并将未通过测试的包标记为不兼容。

Laur

Well, I think there's a bunch of things we can do, but ideally outside of the compiler. Thank you?

嗯，我认为我们可以做很多事情，但理想情况下是在编译器之外。谢谢？

Laur

Because there'd be a place like Typst Universe that store showcase of article projects written in Typst.

因为会有一个像 Typst Universe 这样的地方，存储用 Typst 编写的文章项目的展示。

Reknih

Yeah, which I just wanted to say, this is a place like this on a forum. I think it's less discoverable than Universe, the showcase category on the forum. But in principle, you can go there and post and it's meant for things like this. Exactly, so let me just bring up the link. Or. Yeah exactly. Yeah.

是的，我只是想说，论坛上也有类似的地方。我认为它不如 Universe 那么容易被发现，论坛上的展示类别也是如此。但原则上，你可以去那里发帖，它是为类似的事情准备的。没错，让我把链接发出来。或者，是的，没错。

Laur

something you could do is have Typst Universe be a bit more of a hub to explore other things like showcasing the forum and stuff. That's the way it was intended. That's where it's called the Typst Universe.

你可以做的是让 Typst Universe 成为一个中心，去探索其他东西，比如展示论坛之类的。这才是它原本的意图。这就是它被称为 Typst Universe 的原因。

Reknih

Yeah, and we could definitely do that. And maybe also if the person who has asked the question has some more input on what they've thought about then. They can come up to the stage or maybe put it in the chat so we can have a better idea.

是的，我们肯定可以这样做。也许如果提问者对他们的想法有更多的补充，他们可以上台或者在聊天中提出，这样我们就能更好地了解情况。

Laur

Is this person telling you the farm is down right now from from 10 people clicking on it or no?

这个人告诉你现在服务器宕机是因为有 10 个人点击它造成的吗？还是什么原因？

Reknih

I fucking hate Discourse. I fucking hate her so much. Just let me control the cubes real quick.

我真他妈讨厌 Discourse，我太讨厌它了。让我赶紧控制一下这些立方体。

Laur

Okay, for me it is sort of working. It's just slow.

好吧，对我来说，它算是能用，就是有点慢。

Reknih

Yeah, it...

Laur

seems that it's really, it's really sad, like it's not, not a lot of people.

感觉有点惨，好像没多少人。

Reknih

Yeah, it's said it is wet and weird. Yeah, let's not talk about it.

好的，他们说它又湿又怪。好的，我们别谈这个了。

Laur

I mean, there are large discourse forums. I don't know whether we're doing something wrong, but .

我的意思是，有很多大型讨论论坛。我不知道我们是不是做错了什么，但是...

Reknih

I'm don't know how they do it. They must run it on like the fucking...

我不知道他们是怎么做到的。他们肯定是在跑，就像那个...

Laur

Microsoft Mariana 1.

微软的 Mariana 1。

Reknih

Yes, that's a quantum chip for everyone who hasn't seen, and it really does have a name that is almost as ridiculous. But enough renting about this course. Let's, em.

是的，这是一个量子芯片，给那些还没见过的人看的，而且它的名字确实也很离谱。不过关于这个课程的吐槽就到此为止吧。我们，嗯。

Laur

This is a nice question. Who are the current team members and what do they each work on? So I can start? I'm working on the compiler as the core compiler developer. Martin can continue.

这是个好问题。目前的团队成员有哪些，他们各自负责什么工作？我可以先开始吗？我作为核心编译器开发者，正在研究编译器。Martin 可以继续。

Reknih

Yeah I'm working on the web app and the home page and I'm currently go working on the brand a bit too and making the homepage better. So that's exciting.

是的，我正在开发 Web 应用程序和主页，目前也在做一些品牌方面的工作，并改进主页。这很令人兴奋。

PgSuper

Well I'm working on a compiler and I mostly work on layout stuff. Or you might have seen like some features like line numbers simple, which was a very unexpected feature. And I see the lots of work on tables. For me, the tables guy.

我正在研究编译器，主要负责布局方面的工作。或者你可能见过一些功能，比如行号，这算是个非常出乎意料的功能。我还在做很多表格方面的工作。我是表格负责人。

Laur

Well, I guess I can also answer. I'm working on plushies. Yeah I'm basically working on brands and like typst's brand and other aspects of the company. Yeah, thank you.

嗯，我想我也可以回答。我正在做毛绒玩具。是的，我基本上在做品牌，比如 Typst 的品牌和公司的其他方面。好的，谢谢。

Ana

And I'm a developer to, and I used to contribute to the compiler a little, but I mostly work on the web app these days. And I'm also like the chief package officer. So I review all the packages that are submitted, the Typst Universe.

我也是一个开发者，以前也为编译器贡献过一点代码，但现在我主要在 Web 应用程序上工作。我也是首席包管理官，负责审核所有提交的 Typst Universe 包。

Reknih

Exactly, and Ana is currently working on a secret upcoming Typst Pro future.

没错，而且 Ana 目前正在开发一个秘密的 Typst Pro 特性项目。

Laur

Top secret.

绝密。

Reknih

Top secret. I mean, there are upcoming Sub Pro features that are unexpected.

绝密。我是说，即将推出的 Sub Pro 功能会出乎意料。

Laur

Yes, not the one she's working on though, anyway. And is content flowing into designated areas on the roadmap? Yes, I would say yes. Not in the near future, but in the medium to far future.

是的，但不是她正在做的那个。内容是否流入路线图上的指定区域？是的，我觉得是的。不是在近期，而是在中远期。

Reknih

In the Typst lingo that is called box chaining. And I think there's a GitHub issue for that.

在 Typst 的术语里，这叫做盒子链。我觉得 GitHub 上应该有个 issue 讨论过。

Laur

Maybe. There was some discussion about it briefly after 0.12 with some ideas being thrown around. Maybe it was in the layout for it so? Probably doable to find that if you're interested in it. If you don't get I'm just seen it.

可能吧。0.12 版本发布后，曾经有过一些简短的讨论，也提出了一些想法。也许是在布局相关的讨论里？如果你感兴趣，应该可以找到。如果你没找到，我好像见过。

Reknih

Any updates or thoughts on internal introspection re-layouting to circumvent the five layout reiteration limit without increasing it? Asking for frame? We see you. Local introspection is certainly something that is appealing to us, and I think it has not come up since. When worked on the new table of contents four times.

关于内部 introspection 重新布局，有没有什么更新或想法，可以在不增加五次布局迭代限制的情况下绕过它？要 frame？我们加了。局部 introspection 对我们来说肯定是有吸引力的，而且我觉得自从上次我做了新的目录之后，就再也没有人提过了。

Laur

but I at least done at least on my end.

但至少我这边已经完成了。

Reknih

All right, and should I repeat what I said before?

好的，需要我重复我之前说的话吗？

Laur

I think now it's better.

我觉得现在这样好多了。

Reknih

And basically that's by Ana. It's something we worked on. Would have liked to have when we did the new outlines and I think Laurenz may have some more thoughts to share.

基本上，这是 Ana 做的。是我们一起完成的。希望我们在做新的大纲时就能有这个，我想 Laurenz 可能会有更多想法要分享。

Laur

Yeah, so maybe we do sort of have something in the end, re-layouting, em, recompiling, realizing, and resell everything. We have something similar in layout engine already for read outing a page to make footnotes work and to make floating figures work and stuff. So it's natural to it have the middle ground between we read out the whole document, we re-layout the page, and we relayed something that the user specifically asked to be relay outed and stabilized locally. But I have not yet thought about it really, what would be needed to implement that and to expose that. So it's a design discussion we can start, but, yeah, I don't have any updates or thoughts to share right now.

好的，所以也许我们最终可以做一些事情，比如重新排版、重新编译、重新渲染，然后重新显示所有内容。在布局引擎中，我们已经有类似的东西，可以用来重新排版页面，以实现脚注和浮动图形等功能。所以很自然地，可以在重新排版整个文档、重新排版页面以及重新排版用户明确要求重新排版并局部稳定的内容之间找到一个中间地带。但我还没有真正考虑过，实现这一点需要什么，以及如何暴露它。所以这是一个我们可以开始的设计讨论，但是，是的，我现在没有任何更新或想法可以分享。

Laur

There some of the, let me quickly finish on the side of the diagnostics. If it does not converge, the title of the next question, I guess. So we don't have plans to increase the number of introspection loops, at least not in a way where the user can control it. I may accept at one day that it might need to be 6 or 7, but we don't have plans to make it user configurable. There's a bunch of discussion about that on GitHub and thoughts about how we can still improve the situation and make it easier to debug. I think that's best just write up on. I can share the link if I can find it.

关于诊断方面，让我快速说完。如果它不收敛，那就是下一个问题了。所以我们没有计划增加内省循环的次数，至少不会以用户可控的方式增加。我可能会在某一天接受它可能需要 6 或 7 次，但我们没有计划让用户可以配置。GitHub 上有很多关于这方面的讨论，以及关于我们如何改进这种情况并使其更容易调试的想法。我认为最好写下来。如果我能找到，我可以分享链接。

Reknih

And we are also considering, for example, allowing you to, in a debug environment in the web app, for example, view the document at each in iteration of the introspection group or maybe even like limit them down so you can use it to debug and see where things have gone wrong. So that's something we're considering. But this one of those instances where we are negotiating with terrorists and just have to tell the community to write better packages.

我们也在考虑，例如，允许你在 Web 应用程序的调试环境中，查看内省组每次迭代时的文档，或者甚至可以限制它们，这样你就可以用它来调试并查看哪里出了问题。所以这是我们正在考虑的事情。但这属于我们与恐怖分子谈判的情况之一，只能告诉社区编写更好的包。

Laur

Yeah, we will just have the entire ecosystem if we make it configurable. Do you think typst release and tinymist release needs to be somehow synchronized? It's an interesting question. I wonder if it comes from the tinymist folks or not. Probably not, but what? Be more interesting if it would.

如果把它做成可配置的，我们就能拥有整个生态系统。你觉得 Types 和 Tinymist 的发布需要某种同步吗？这是个有趣的问题。我想知道这问题是否来自 Tinymist 的开发者。可能不是，但如果真是那样会更有趣。

Laur

It is interesting because I recently thought again about auto formatting on the web app and we still haven't really decided yet on how we do that, whether we integrate a community formatter or whether we write our own. And the problem even already starts ignoring everything else with the fact that when I make a Typst release, I also published the web app at the same time. So I can't really wait for the Typstyle maintainers to upgrade Typstyle to the new Typst version because I need it right away. And so these are definitely interesting problems. But I think so far it's been working well with having tinymist on its own release schedule and well, then maybe the tinymist developers have thoughts on there, but.

这很有意思，因为我最近又在考虑 Web 应用上的自动格式化问题，我们还没有真正决定如何处理，是集成社区的格式化工具，还是自己编写一个。问题甚至在忽略其他一切之前就已经开始了，因为当我发布 Typst 版本时，我也会同时发布 Web 应用。所以我不能真的等着 Typst 维护者将 Typst 升级到新的 Typst 版本，因为我需要立即使用它。所以这些绝对是有趣的问题。但我认为到目前为止，让 Tinymist 拥有自己的发布时间表运作良好，也许 Tinymist 开发者对此有想法，但是…

Laur

Yeah, the tinymist, I'm very, very impressed by the development there. It's probably them oops. I, another...

是的，tinymist，我对那里的开发印象非常深刻。可能是他们…哎呀。我，另一个…

Reknih

We continue to, we continue to joke that @Myriad-Dreamin is actually 20 people.

我们一直开玩笑说纸夜实际上有 20 个人。

Reknih

All right, let's move on to the next question. Will Typst support the digital signature spec and then linked Adobe spec? And I think the answer in the medium term will be no. Why? Because like, I basically don't want to ship stuff in typst that is better suited for specialized tools. And I think that it is more well suited for software that integrates into Typst.

好的，让我们继续下一个问题。Typst 是否会支持数字签名规范？我认为中期来看答案是否定的。为什么？因为我基本上不想在 Typst 中加入更适合专业工具的东西。我认为它更适合集成到 Typst 中的软件。

Reknih

Furthermore, I think that with digital signatures especially, people's requirements are very different based on where they are. For example, for some people, a digital signature from a document reader might be enough. Some people require additional signature to be exclusively from DocuSign, others yet, for example, we in the European Union have a digital signature standard where the only digital signature that is actually corresponds to a physical signature on paper is when you verify with your government issued ID or have a voice chat with an agent, which is a service that we can not offer. I can see integrating third party signing kit into the typst web app with Typst Pro, but I can not see building it into the Typst compiler.

此外，我认为对于数字签名，不同地区的人们的需求差异很大。例如，对某些人来说，文档阅读器提供的数字签名可能就足够了。有些人则要求必须是 DocuSign 提供的签名。还有一些人，例如欧盟，我们有一个数字签名标准，只有通过政府颁发的身份证验证或与客服进行语音聊天才能实现的数字签名，才真正对应于纸质签名，而我们无法提供这种服务。我可以看到将第三方签名工具包集成到 Typst Web App 中，并作为 Typst Pro 的一部分，但我认为无法将其构建到 Typst 编译器中。

Laur

Do we have plans for another meetup? Do we want to spend another full week preparing things? And then at the day of the meetup, drive with a car, sharing and car to get 20 pizzas from the pizzeria clothes to the authors?

我们有计划再搞一次线下聚会吗？我们想再花整整一周时间准备吗？然后在聚会当天，开车，拼车，从披萨店拿 20 个披萨，分发给作者们？

Reknih

Wait, what? Driving in the car?

等等，什么？在车里开车？

Laur

Any plans for another meetup this year? I missed the first one and would be soaked to go to the next. The pizza is awesome, which is why why it was worth it. We could have gotten pizza from any place and they would have delivered it to us, but the pizza they have, it's better, but they don't deliver it.

今年有计划再举办一次聚会吗？我错过了第一次，很想参加下一次。披萨太棒了，所以才值得去。我们可以从任何地方买披萨，他们都会送货上门，但他们提供的披萨更好吃，只是不送货。

Reknih

Yeah, I would say that's like rank theft Laurenz.

是的，我会说这就像是盗用军衔，Laurenz。

Laur

I did pay it. (Laugh)

我付过了。（笑）

Reknih

Yeah, indeed. And I think there will be a meetup this year, but, and there will be Pizza again, I think. Yeah. And we asked people identify, it was hilarious. And the next time when I arrived, like a sorting algorithm, I will make it be aware of spaces.

是的，没错。而且我觉得今年会有聚会，而且我想会有披萨。是的。我们让大家表明身份，那场面很搞笑。下次我来的时候，就像一个排序算法一样，我会让它能识别空格。

Laur

Sorry for all the insiders, people, you need to come to the Meetup villain if you want to learn more about these.

对不起各位内部人士，如果你想了解更多这些事情，你需要来参加聚会。

Reknih

Yeah, and I think the people who have been there can attest to it's having been a lot of fun, I hope. And we had a speak request for about 5 seconds. But this is a meeting.

是的，而且我想去过的人可以证明那真的很有趣，我希望如此。我们收到了一个大约 5 秒钟的发言请求。但这是个会议。

Laur

I didn't invite them. You can, you can join the stage unless you have retracted it again.

我没有邀请他们。你可以加入发言，除非你又撤回了。

Laur

Okay, maybe not.

好吧，可能不是。

Reknih

Okay, wait, I'll just invite to become a speaker. Okay.

好的，稍等，我邀请你成为发言人。好的。

Laur

right. Okay, well, will it that be possible to actually write some package in Rust instead of having to manage the WASM API? Probably no, because then needs to be compiled in some way. And WASM is the best way.

好的，那么，有没有可能用 Rust 编写一些包，而不是必须管理 WASM API？可能不行，因为那样需要以某种方式进行编译。而 WASM 是最好的方式。

Reknih

Yeah, and then you get like platform dependency, and no, thanks.

是啊，然后你就会遇到平台依赖的问题，不了，谢谢。

Laur

So I guess you mean like like a plugin that is directly loaded as a dynamic library or something, but there is a secret nightmare, so probably no.

所以我想你的意思是，像一个直接作为动态库加载的插件之类的，但是这里面隐藏着隐私问题，所以可能不行。

Reknih

Yeah, I guess this person just wants to implement shell escape. Again, I think what I applied super about raising a number of iterations applies here as well. And I think...

嗯，我想这个人只是想实现 shell escape。再说一遍，我认为我之前说的关于增加迭代次数的建议在这里也适用。而且我觉得…

Reknih

Confirm now that we have talked about it. And there you go here, could the shadow scpr be reintroduced, but ensure that it can not be used for piracy related purposes?

现在确认一下我们已经讨论过了。然后这里，shell escape 能否被重新引入，但要确保它不能用于盗版相关目的？

Reknih

There was a Nintendo thing in the PR.

PR 里有个任天堂的东西。

Laur

Right, wait, we can talk about it .

对，等等，我们可以聊聊这个。

Reknih

On April 1?

在愚人节？

Laur

Yeah, in a few weeks, three and a half weeks, we can talk about it.

嗯，几周后，三周半后，我们可以聊聊。

Reknih

Yeah.

是的。

Laur

Do you want to answer the old question from 5:07?

你想回答 5:07 的老问题吗？

Reknih

I think I will do that. Typst is privately funded as a majority. Typst's multiple revenue streams: Typst Pro, Typst on premises and Typst open source support being our commercial revenue streams. Then of course, as we've said before, this call Posit is generously supporting us, as is our community via GitHub Sponsors, the open source. And we are receiving some government grants, in particular from the European Union through the foundation and NL for HTML Export at the moment and save for the European Union money, All of that is private. So I guess, yes, Typst is majority privately funded.

我想我会那样做。Typst 目前主要由私人资助。Typst 有多种收入来源：Typst Pro、Typst 本地部署和 Typst 开源支持是我们的商业收入来源。当然，正如我们之前所说，Posit 慷慨地支持我们，我们的社区也通过 GitHub Sponsors 和开源项目支持我们。我们还收到了一些政府拨款，特别是来自欧盟通过基金会和 NLfor HTML Export 的拨款。除了欧盟的资金，所有其他的都是私人的。所以我想，是的，Typst 主要由私人资助。

Laur

Okay, have we ever get the speak request.

好的，我们收到发言请求了吗？

Reknih

okay? Did somebody confirm? But yeah, that okay, interesting. And that way keep us on your to.

好的？有人确认了吗？好吧，好的，有意思。这样可以让我们随时了解情况。

Laur

Interactive PDF, so I guess you mean forms?

交互式 PDF，所以你指的是表单吗？

Reknih

I think that we once had a contributor who worked on that, but I think he burnt out from it a bit. And since it's sort of floating in the void.

我觉得我们之前有个贡献者做过这个，但他好像有点累了，然后现在就有点悬在空中。

Laur

it's personally for me, not a priority if someone wants to pick it up.

对我个人而言，这不是优先事项，如果有人想接手，也可以。

Laur

Which is now linked in the chat? We'll. Help basically have things over. And we're also obviously there too discuss things, but it's not a priority.

链接已发在聊天框。我们基本上会提供帮助，当然也会讨论问题，但这不是重点。

Reknih

Yeah, and if you do pick it up and need to draw on on our like PDF, better scars and experience, then we'll also be glad to have a call. But it would be maybe a good idea to familiarize yourself with the issue and.

好的，如果你接手了，需要借鉴我们之前在 PDF 上的经验，我们也很乐意开个会。但最好先熟悉一下问题。

Reknih

PDF 2.0 and PDF A 4 on the long term roadmap.

PDF 2.0 和 PDF A 4 在长期路线图上。

Reknih

Certificate types doesn't really do that. Is deprecated in PDF or 2.0 that it needs to do. It has some compatibility behaviors that we would need to remove for the 2.0 export and some other stuff we're to write. But these are mostly like mechanical changes, but PDF Afr won't be a big change to you unless somebody implements forms. So I guess sort of linked together. And I would be interested to know, what's your use case for PDF 2.0 is versus 1.7, which we are outputting right now?

证书类型实际上并没有做这些。它在 PDF 2.0 中已被弃用。它有一些兼容性行为，我们需要为 2.0 导出删除，还有一些其他的东西需要编写。但这些大多是机械性的改变，除非有人实现了表单，否则 PDF Afr 对你来说不会有很大的改变。所以我想这有点关联。我很想知道，你使用 PDF 2.0 的用例是什么，而不是我们现在输出的 1.7？

Laur

Now has some thoughts. Maybe he wants to join the stage.

现在有一些想法，可能想加入进来。

Laur

Sorry, you don't have to.

没关系，你不必这么做。

Reknih

PDF UA 1 is tied to PDF 1.7, and it's true that in PDF 2.0, tagging is different and more rich. And then generate a PDF 2.0 S, some more accessible format, and the PDF UA two standard A requires it and B gives more indep guidance on how to write an accessible PDF.

PDF UA 1 与 PDF 1.7 相关联，确实在 PDF 2.0 中，标记方式有所不同，也更加丰富。然后生成一个 PDF 2.0 S，一种更易访问的格式，PDF UA 2 标准 A 对此有要求，B 提供了关于如何编写可访问 PDF 的更多独立指导。

Reknih

All right?

Laur

Have you thought about improving Typst as a Rust lib, with better docs and word input helpers for diagnostics etc. I mean, sure, we can do that. I think this is a thing that would be fairly easy to contribute to. There's also, for example, the thing that we might want to extract some stuff from the CLI into Typst kit, for example, the watcher. There will, of course, be a bit of bike-shading involved in the APIs.

你有没有考虑过改进 Typst，把它作为一个 Rust 库，提供更好的文档和单词输入助手，用于诊断等等。我的意思是，当然，我们可以这样做。我认为这件事很容易贡献。例如，我们可能想从 CLI 中提取一些东西到 Typst kit 中，比如 watcher。当然，API 中会涉及到一些不必要的争论。

Laur

One thing I definitely want to do is re-export the crates that Typst depends on like commemo and stuff from Typst so that it's not as big a hassle to specify the dependencies and get everything into shape. Yeah, I think I think the world `impl` is the word `trait`. It's interesting. It is like there were a bunch of different interfaces before that. This is like the fifth iteration or something, and I think it is good because it's very flexible. But it takes some time to wrap your head around it, so the better docs will definitely be good and not too much work total. I'm not sure exactly what helpers for diagnostics means, but better document world input is definitely something we can.

我肯定想做的一件事是重新导出 Typst 依赖的 crates，比如 commemo 之类的，从 Typst 导出，这样指定依赖项并使所有内容成形就不会那么麻烦了。对，我觉得 `impl` 这个词就是 `trait`。挺有意思的。好像之前有很多不同的接口。这像是第五次迭代了，我觉得挺好的，因为它非常灵活。但需要花一些时间才能理解它，所以更好的文档肯定会很好，而且总的来说工作量也不会太大。我不确定诊断的 helpers 具体是什么意思，但更好的文档绝对是我们能做的。

Laur

Person that asked this ones.

问这个问题的人。

Reknih

Be kind to us.

Laur

What meanst? What is the meaning of .

什么意思？是什么的意思？

Reknih

What is the meaning of this? Laurenz, I think it just doomed when you accept it worked. It worked, it worked, it worked.

这是什么意思？Laurenz，我觉得你接受它能用的时候，它就注定完蛋了。它能用，它能用，它能用。

Pachi

Can you hear me?

能听到我说话吗？

Reknih

Yes, welcome.

可以，欢迎。

Pachi

Thank you by diagnostics. Well, this design to build an application using Typst for layouting and generating PDF, and for some energy efficiency certificate related issues.

感谢 diagnostics。这个设计的目的是使用 Typst 进行排版和生成 PDF，以及解决一些能源效率认证相关的问题，来构建一个应用程序。

Pachi

And I have to dig in the code to learn how to use the library. That's normal, but for instance, when I want to print the warnings and errors, I have to go deep into the library because it it's not very clear how to do it. And sometimes to recreate or some of the afford that you have for right into the console to the terminal. And I had to dig into some label, but there is even from a different crate that it's not entirely, but it seems to be related. So I mean, it's all very spread around and sometimes it's very difficult to understand how all the pieces fit together.

我不得不深入研究代码来学习如何使用这个库。这很正常，但例如，当我想打印警告和错误时，我必须深入到库的内部，因为它不是很清楚该怎么做。而且有时候为了重新创建或者实现你在控制台或终端上拥有的功能，我不得不研究一些标签，但这些标签甚至来自不同的 crate，虽然不完全相关，但似乎有关联。所以我的意思是，所有东西都非常分散，有时很难理解所有部分是如何组合在一起的。

Pachi

And also the word implementation is really nice once you understand it and maybe even quite easy it. But you have to first understand well what's a file ID and, eh, how you keep the file IDs and how they match between the names of the files and the IDs or how the Typst find a file for a package or a source etc. And there are lots of little missing pieces of information that it would be have better docs on that. But I think it's so fanta-, the library is so fantastic, so great, that I'm sure many more Rust developers would come to improve the library. And the software, they can use it in different ways from the Typst compiler.

而且，一旦你理解了它的实现方式，就会觉得它非常好，甚至可能很简单。但你首先要很好地理解什么是文件 ID，以及如何保存文件 ID，以及它们如何在文件名和 ID 之间匹配，或者 Typst 如何为包或源文件等找到文件。有很多缺失的信息，如果能有更好的文档就好了。但我认为这个库太棒了，太好了，我相信会有更多的 Rust 开发者来改进这个库。而且这些软件，他们可以用不同于 Typst 编译器的方式来使用它。

Laur

Okay, I think that's very fair. Sounds to me like it's really primarily a docs issue. And for example, like for the diagnostics, like the interface that Typst exposes is it tries to be as abstract? Well, not as abstract as possible, but as abstract as necessary so that you can read, display it in any way you like in the terminal or in the web app or wherever, and which is why it's a bit removed from just printed to the console, which is why various other crates like codespan reporting are involved. I think we can try to move some of that stuff to Typst Kit, but to me it sounds like the main issue is to read the docs and that makes a lot of sense like the things like file IDs.

好的，我觉得这很合理。听起来主要是一个文档问题。例如，对于诊断信息，Typst 暴露的接口试图尽可能抽象？好吧，不是尽可能抽象，而是根据需要进行抽象，这样你就可以在终端、Web 应用或任何地方以你喜欢的方式读取和显示它。这就是为什么它与直接打印到控制台有点脱节的原因，这也是为什么涉及到像 codespan reporting 这样的各种其他 crate。我认为我们可以尝试将其中一些内容移到 Typst Kit，但对我来说，主要问题是阅读文档，这很有意义，比如文件 ID 之类的东西。

Reknih

Yeah, and I can say like even back, way back when the file IDs were source IDs, I'd constantly like every two months or something, I have to interact with the web apps while implementation for some reason or other. And every time I have to ask Laurenz, what does the source IDs do and why can't I construct it and stuff like this?

是的，我可以说，甚至早在文件 ID 还是源 ID 的时候，我经常，大概每两个月左右，就不得不因为某些原因与 Web 应用的实现进行交互。而且每次我都不得不问 Laurenz，源 ID 是做什么的，为什么我不能构造它，以及诸如此类的问题？

Laur

Yeah.

Pachi

Yeah. For instance, I only think that README is not having a some way of having access or or packages or some way to extra how to get information from, for instance, embedded packages, from downloaded packages or from. A kiter directory on some directory because those could be quite modular elements. And there is in type this kit. There is a way to have a front-load helper. There's a font load helper, but there's not some helper to get packages from, from the network. You have to search in Typst, and that's another missing part that that are very spread around. There's seeing a Typst embedded packages trait that is quite interesting but difficult to understand how to use it until you know well.

是的。例如，我认为 README 缺少某种访问或获取包的方式，或者某种从嵌入式包、下载的包或某个目录下的 kiter 目录中提取信息的方式，因为这些可能是非常模块化的元素。在 Typst 的 kit 中，有一种预加载助手的方法，但没有助手可以从网络获取包。你必须在 Typst 中搜索，这是另一个缺失的部分，而且非常分散。有一个 Typst 嵌入式包 trait，非常有趣，但很难理解如何使用，除非你非常了解它。

Laur

I think? Well, I do. I do like refactoring stuff. So just moving around stuff from the CLI Typst is actually would be a day well spent for me.

我想？好吧，我是这么想的。我确实喜欢重构东西。所以仅仅是从 CLI Typst 移动东西对我来说实际上就是有意义的一天。

Reknih

Amazing.

Laur

Matthew, Matthew considers that a day well spent for me, but I think this is something we can improve in the short term.

Matthew 认为这对我来说是有意义的一天，但我认为这是我们可以在短期内改进的事情。

Reknih

All right, and thank you for coming to the stage and sharing your feedback.

好的，感谢您来到台上分享您的反馈。

Laur

I think this is something that should be inspiring to other people to join the stage, to join the conversation.

我觉得这件事应该能激励其他人加入进来，参与讨论。

Reknih

Yes, and be an inspiring leader and affect the change you want to see in typst. And so now we are the first time people on stage it again. But is expert.

是的，成为一个鼓舞人心的领导者，并在 Typst 中推动你想要看到的改变。所以现在我们再次邀请了第一批人上台，但这次是专家。

Laur

you don't yet exist, but you would really like to see developers. It's interesting because this was a question that was also asked last time. And we said something about chemistry. And I just recently saw that there is some sort of community working on chemistry packages.

你现在可能还不存在，但你真的很想看到开发者。有趣的是，上次也有人问过这个问题。我们当时提到了化学。我最近看到好像有个社区在开发化学相关的包。

Reknih

Nice, so you should join those people, especially if you know something about chemistry. I think maybe it's being a stoner comes to those always have surprising breadth of knowledge about chemistry.

不错，你应该加入他们，特别是如果你懂一些化学知识的话。我觉得可能成为一个“stoner”总是能带来令人惊讶的化学知识广度。

Laur

Do we have any other packages that we would like to see developed?

我们还有其他希望开发的软件包吗？

Reknih

Um, so...

Laur

I can't even, I can't even keep up with all the tools that @Myriad-Dreamin develops.

我跟不上纸夜开发的所有工具了。

Reknih

Yeah, and so if anybody in this call works at OpenAI, I would ask them to fix their fucking frontier model. It still makes too many mistakes when writing Typst.

是的，如果这次通话中有在 OpenAI 工作的人，我希望他们能修复一下他们那个该死的所谓前沿模型。它在编写 Typst 时还是错误太多。

Reknih

Other than that, All right, let's try it again.

除此之外，好吧，我们再试一次。

Laur

Sorry for missing the first two.

抱歉错过了前两个。

Laur

Will you create a journal like the TUGboat of the LaTeX's?

你们会创建一个像 L^AT_EX 的 TUGboat 那样的期刊吗？

Reknih

I see? So, TUGboat like journal for that? What I think we would first need to the host conference, which I think is quite an escalation from the meetup. When we organize the meetup we, well, like, oh, we have accidentally organized the conference, but Laurenz, what do you think about it? Is TUGboat our style, or are we more casual than that?

我明白了？所以，TUGboat 就像是这方面的期刊？我认为我们首先需要主办会议，这比聚会规模大多了。当我们组织聚会时，就像，哦，我们不小心组织了一场会议。Laurenz，你觉得怎么样？TUGboat 是我们的风格吗，还是我们更随意一些？

Laur

Emm, well, I don't know. But in any case, I agree that it is too early and our resources are already spread too thin.

嗯，我不知道。但无论如何，我同意现在说这些还为时过早，而且我们的资源已经分散得太厉害了。

Reknih

yes?

Laur

All right, there's another request.

好的，还有另一个请求。

Laur

Don't leave us standing in the rain here. Yeah, after we said, yeah.

别让我们在这里干等。嗯，在我们说了之后。

Reknih

Going to re-invite us. Going to hear from the stars.

重新邀请我们。去听听星星的声音。

Laur

Absolutely of them, indeed.

当然可以。

Laur

Please allow using inside path outside the root folder. I use image of college logo on my assignment template. I hvae to copy it in all my assignments folders. You can use either a private package or if you really want to, you can set the route to slash, but you should just create a private package.

请允许在根文件夹之外的路径中使用内部路径。我在我的作业模板上使用了大学登录的图片。我必须把它复制到我所有的作业文件夹里。你可以使用一个私有包，或者如果你真的想，你可以把路由设置为斜杠，但你应该创建一个私有包。

Reknih

yes? And instructions on how that could be accomplished for local installations can be found where.

是的？关于如何在本地安装中实现这一点的说明在哪里可以找到？

Laur

excuse me, it's your turn. Okay, it's for ?.

不好意思，轮到你了……

Reknih

And...

Laur

I think that the documentation cover that should be improved like, like all documentation, but for now it is just README.

我认为文档覆盖范围应该改进，比如所有文档，但目前只有 README。

Reknih

And I would also like to add, if you're a Linux user who's using the Typst Snap due to how snaps are confined, private packages aren't supported in Snaps. You need to install Typst in another way, and for Ubuntu, that would be manually downloading the binary and placing it in your path. And for Debian, it's the same in...

我还想补充一点，如果你是 Linux 用户，并且因为 Snap 的限制而使用 Typst Snap，那么 Snap 不支持私有包。你需要用其他方式安装 Typst，对于 Ubuntu 来说，需要手动下载二进制文件并将其放在你的路径中。对于 Debian 来说，也是一样的...

Laur

Another option to say that if you are a Linux user, please upgrade to save the environment.

另一种说法是，如果你是 Linux 用户，请升级以保存环境。

Reknih

Except if you're using Snap. Except if you're using the Snap because the update for the Snap isn't available yet because I had the token for me to publish on snapcraft.io has expired in the computer where I can renewed that as in the office and I have done home office today.

除非你用的是 Snap。除非你用的是 Snap，因为 Snap 的更新还没出来，因为我在 snapcraft.io 上发布东西的 token 过期了，而我可以在办公室的电脑上更新它，但我今天居家办公。

Laur

Speaking, but we could not hear.

正在说话，但我们听不到。

Reknih

Oh, no, no, no, no, no, no.

哦，不，不，不，不，不，不。

Laur

Invited you to the stage. You need to somehow accept this? I don't know how.

邀请你上台了。你需要以某种方式接受？我不知道怎么操作。

Reknih

Yeah, we are only speaking from the privileged position of stage administrators here.

是的，我们现在只是以舞台管理员的特权身份在发言。

Laur

It seems to be complex.

看起来很复杂。

Laur

Okay, let's try it again.

好的，我们再试一次。

Laur

Yeah, Andrew says you might need to rejoin the call.

安德鲁说你可能需要重新加入会议。

Reknih

Okay, he's gone.

好的，他走了。

Reknih

He's here again. And .

他又来了。而且。

SillyFreak

yes, yes, yeah, sorry about that. Previously, it offered me to leave the stage but not join it. Yeah, sorry for the for the delay.

是的，是的，不好意思。之前它让我离开舞台，但没有让我加入。不好意思耽搁了。

SillyFreak

I wanted to ask my question because it's, was at the top now anyway, so quite at the top, so I asked about planned, web app features that maybe are not confidential or maybe web app features, features that you wish to implement part are not yet close on your roadmap. And one that came to my mind was ser letters and stuff like that. So stuff that is not doing one single document from from a project, but maybe something more than that we have actually talked about that recently about how we would design that. I think that's also something where like generally we like to design the web Hu in the close, but I think this might actually be something where I would be interested in a bit more open design because for the serial thing, so you need to have we need to populate this zestar inputs. And I want to do this in a way where we don't replicate all the like CSV, XML, JSON reading again in the web app. So we're kind of trying to figure out what is the best way to expose that.

我想问我的问题，因为它现在已经在最上面了，反正就在最上面，所以我问了关于计划中的 Web 应用程序功能，这些功能可能不是机密的，或者可能是 Web 应用程序的功能，你希望实现但尚未确定在你的路线图上的功能。我想到的一个就是系列信件之类的东西。所以，不是从一个项目中生成单个文档，而是比这更多的东西。我们最近实际上已经讨论过如何设计它。我认为这也是一个方面，一般来说，我们喜欢在内部设计 Web 界面，但我认为这实际上可能是一个我更感兴趣进行更开放设计的事情，因为对于系列信件，你需要填充这些 Zestar 输入。我想以一种方式做到这一点，即我们不必在 Web 应用程序中再次复制所有的 CSV、XML、JSON 读取。所以我们正在努力弄清楚什么是最好的方式来暴露它。

Laur

There needs to be some way to have a list, basically, and it probably should be a file.

需要某种方式来创建一个列表，基本上，而且它可能应该是一个文件。

Reknih

The question is, how does the file behave in relation to the project? Can the entries in the list contain structured data? If yes, how is it serialized and passed to Typst? Questions like this. And then in like further questions, two Typst Pro users have the opportunity to fetch this data from an API. If so, how can it be shared amongst team? Is it maybe a form that others can complete?

问题是，这个文件与项目之间的关系如何？列表中的条目是否可以包含结构化数据？如果可以，如何序列化并传递给 Typst？诸如此类的问题。还有，如果 Typst Pro 用户有机会从 API 获取这些数据，那么如何在团队中共享？它是否可以是一个其他人可以填写的表格？

SillyFreak

Yeah, and maybe because Typst Pro. Now also the topic regarding the getting into the testing of new Typst Pro features and tests being confidential. Are there any collaborative features that I planned to be tested in this way? And in that case, how would the confidentially apply to testing these collaborative features with selected colleagues that maybe we as that pro users trust .

是的，也许是因为 Typst Pro。现在还有关于测试新的 Typst Pro 功能以及测试保密性的问题。我计划以这种方式测试哪些协作功能吗？如果是这样，保密性如何适用于与我们信任的选定同事一起测试这些协作功能？

Reknih

so? What I want to say in terms of confidentiality is don't post about it on the internet. So as long as that can be done, then I think we are good. And you're free to use these features with Chester colleagues or friends or collaborators.

所以？我想说的关于保密性的是，不要在互联网上发布相关信息。只要能做到这一点，我认为我们就没问题。您可以自由地与您的同事、朋友或合作者一起使用这些功能。

Reknih

Thank you?

Laur

Question?

问题？

PgSuper

So, okay, so I wanted to briefly mention, so everyone about some of my ongoing work. Fortunately, I don't have like some usual thing to show this time, but I'm excited to announce that I've been working on bringing multiple headers and footers to tables. You'll be able to soon, maybe hopefully in the next version, everything goes right.

好的，我想简单提一下我最近在做的一些工作。幸运的是，这次我没有什么常规的东西可以展示，但我很高兴地宣布，我一直在努力为表格添加多个页眉和页脚。如果一切顺利的话，也许在下一个版本中你就能用上了。

PgSuper

You're able to have like subheader subfolders in your tables. So that's very useful for like table sections, that kind of stuff where you have like a global table header with like with what each column means. And then you can have like a sub header for like some specific detail of some part of the table and long and kind of stuff. So I think this exciting. And of course, I hope to, in the future, work more exciting table stuff. So I want to be for maybe Laurenz, could one say something about this, but something eventually want to talk more in the future, which would be nice bit to fix that bug, which everyone keeps asking me about regarding able to style table hazards and screws which show such rules.

你可以在表格中拥有像子标题、子文件夹这样的结构。这对于表格分节之类的情况非常有用，比如你有一个全局的表头，说明每一列的含义。然后你可以为表格的某个部分的特定细节设置一个子标题等等。所以我认为这很令人兴奋。当然，我希望将来能做更多令人兴奋的表格相关的东西。我想也许劳伦茨可以对此说些什么，但最终我想在未来更多地谈论这件事，如果能修复那个大家一直在问我的关于表格标题和规则样式的 bug，那就太好了。

Laur

Yes?

PgSuper

Yeah, I think that would be that's a priority the future as well because yeah, very common request and being the future as well, being able to have better like minimization of tables to show rules and like, for example, a common request is being able to like find the last row and that stuff. So that's something that comes to mind. The future, maybe there could be some more work on that in the future. But yeah, for now, that's but I want to say .

是的，我认为那将是未来的一个优先事项，因为这是一个非常普遍的需求，而且未来也需要能够更好地最小化表格以显示规则，例如，一个常见的需求是能够找到最后一行等等。所以这是我想到的。未来，也许可以在这方面做更多的工作。但是的，目前就这样吧，我想说的是。

Laur

if people want to find the last row, I just realized they probably want to use a photo, right?

如果人们想找到最后一行，我突然意识到他们可能想用页脚，对吧？

PgSuper

What do you mean like I'm speaking mostly genetic. Where people sometimes want to have a guy on the table where you can say like the last line read something.

你是什么意思？我主要说的是排版方面。人们有时希望在表格中有一个地方，你可以说最后一行显示一些东西。

Laur

And exactly what I mean is basically that probably they want that because it's semantically a photo. Yeah, that was.

我说的正是，他们可能想要那个，因为它在语义上是一个页脚。是的，就是这样。

PgSuper

yeah. Yeah, most of the time, yes. But, it's hard to do that like in a showroom.

大部分时候是的。但是，在展厅里很难做到。

Laur

Now you basically need to generate the photo already in the table call.

现在你基本上需要在表格调用中生成照片。

PgSuper

Yeah exactly. So like one crazy idea ahead. So maybe just kind of brainstorming this. Maybe the community can give some input to. But Gray's idea ahead was to provide some sort of like way to access like the all the final positions and roles of everything and there some like methods or something in the table show role. It sounds good, and I'm not sure if it entirely solves the problem. But I guess let's give you the last word at least.

是的，没错。所以，有一个疯狂的想法。也许只是集思广益一下。也许社区可以提供一些意见。 Gray 的想法是提供某种方式来访问所有最终位置和角色，并在表格显示角色中提供一些方法或类似的东西。听起来不错，我不确定它是否完全解决了问题。但我想至少让你最后发言。

Reknih

right?

PgSuper

Anyway, but yeah.

无论如何，是的。

Reknih

requested to come to the stage. Oh, sorry.

请到台上来。哦，不好意思。

PgSuper

yeah I'm done. So yeah, we call Rubik's, I think .

我好了。所以，我们叫它 Rubik's，我觉得。

Laur

there is a table for chess.

这里有一张放国际象棋的桌子。

PgSuper

Yeah, yep, there's table storages, yeah.

嗯，是的，有表格存储，是的。

Reknih

All right, let's invite my group X to the stage. Hello, hey, how are you doing? I'm doing good.

好的，让我们邀请…上台。喂，你们好吗？我很好。

Laur

Well, I just wanted to ask.

嗯，我只是想问一下。

Reknih

currently types is using the wasmeier time to execute WebAssembly plugins and with the latest change to make multithread.

目前 Typst 使用 Wasmer 运行时来执行 WebAssembly 插件，并且最新的更改使其支持多线程。

Laur

it also a greatly improved performance already.

性能已经有了很大的提升。

Reknih

but I was .

Laur

just wanted to ask still on the table .

只是想问一下，切换到性能更好的运行时是否仍在考虑中。

Reknih

to maybe switch to a more performance runtime.

也许切换到性能更好的运行时。

Laur

like maybe was some time or something.

就像可能是有段时间或者什么。

Reknih

and then use the native browser runtime in the web app. That's a question which we have thought about recently. And within this context, it's not as easy as switching out the runtime when something like typst Enterprise Edition has come up and been rejected by for the moment. Laurenz can more on this.

然后在 Web 应用中使用原生浏览器运行时。这是我们最近一直在考虑的问题。在这种情况下，替换运行时并不像 Typst 企业版那样简单，目前已经被拒绝了。Laurenzcan 会详细介绍。

Laur

So for now, it's not really on the table because wasmtime is, in my opinion, too large of a burden in terms of dependence account and portability. So first of all, wasmtime can not run anywhere because it uses JIT compilation so that there's something that I wouldn't want to see the typst library to depend on the hardware architecture in that way. But even if you would say okay, and architectures are not supported, we switch out towards me or something, I think the dependency burden is too large.

所以目前，这还不在考虑范围内，因为在我看来，wasmtime 在依赖项和可移植性方面负担太重。首先，wasmtime 无法在任何地方运行，因为它使用 JIT 编译，我不希望 Typst 库以这种方式依赖硬件架构。但即使你说可以，某些架构不支持，我们切换到 wasmer 或其他东西，我认为依赖负担也太大了。

Reknih

And just in time, compilation also adds a text surface to the Typst compiler because it more closely interacts with the matter.

并且即时编译也增加了 Typst 编译器的攻击面，因为它与硬件的交互更加紧密。

Laur

I was thinking maybe it would be possible to have the system kind of runtime-agnostic and

我在想，也许可以让系统在某种程度上与运行时无关，并且

Laur

be able to choose the runtime as a user. So maybe that the CLI one could choose to use wasmtime, but still use wasmi a default to keep being portable.

能够让用户选择运行时。这样，CLI 可以选择使用 wasmtime，但仍然默认使用 wasmi 以保持可移植性。

Laur

It's something that we have discussed a bit recently also with @Myriad-Dreamin from tinymist. And something that would be necessary to support the browser runtime in the web app? I'm not yet sure. So this may sound egoistical, but I wouldn't really like it if. The Typst CLI was by default just slow or slower than or get your custom Typst built with higher performance here. Oh, for this package, you need to use this customized version because it will be too slow. Otherwise, I see how it it might not be better to just be slow, but it is a concern I have about splitting things up and having different classes. Of performance along way?

最近我们和来自 Tinymist 的纸夜也讨论过这个问题。为了支持 Web 应用程序中的浏览器运行时，这似乎是必要的？我还不确定。听起来可能有点自私，但我不太希望 Typst CLI 默认情况下速度很慢，或者比你自己构建的、性能更高的 Typst 慢。比如，“对于这个包，你需要使用这个定制版本，否则会太慢。” 否则，我觉得还不如慢一点，但我担心的是，将东西拆分并拥有不同性能等级会带来问题。

Reknih

Okay, thanks for your answers.

好的，谢谢你的回答。

Reknih

Thank you? All right, I think we only have 15 minutes left in this call, so how about we do some quick answers? But I think Laurenz and I are gonna go to the audience Q&A and Slido and we are alternatingly gonna answer questions with one sentence and Laurenz, I can start exactly, is there an option for nonprofit clubs in regards to Typst Pro? And we're currently not offering special pricing, but perhaps Typst Pro special pricing in on premises is available.

谢谢。好的，我想我们这次通话只剩下 15 分钟了，不如我们快速回答一些问题？Laurenz 和我将去观众问答环节和 Slido，我们会轮流用一句话回答问题。Laurenz，我可以开始了，Typst Pro 是否为非营利俱乐部提供选项？我们目前没有提供特别定价，但也许 Typst Pro 的本地部署版本可以提供特别定价。

Laur

Are there any plans to enhance scripting, for example Object-oriented programming (OOP) or generally satisfied with the syntax? There are no plans. Well, I guess the custom types is OOP in a sense. So I guess there are plans, but no inheritance, and I like the syntax.

是否有增强脚本的计划，例如面向对象，或者对当前语法总体满意？没有计划。嗯，我猜自定义类型在某种意义上是 OOP。所以我想是有计划的，但没有继承，并且喜欢现在的语法。

Reknih

I'm going to skip. Here? I'm cheating, Okay? Then I'm going to answer us. Okay?

我要跳过。这里？我在作弊，好吗？然后我要回答我们自己的问题。好吗？

Laur

The status is the feature request exists and will maybe be considered alongside general styling improvements in the medium term .

目前的状态是，存在该功能请求，并且可能会在中期与常规样式改进一起考虑。

Reknih

and for any functions. That's basically when we ship type annotations, the custom elements will likely go along with that and allow you to different type set of targets for sure rules .

对于任何函数，基本上当我们发布类型注解时，自定义元素可能会随之一起发布，并允许你为确定规则设置不同的目标类型。

Laur

and maybe flip it around a bit and custom types, but not necessarily ship with type annotations. I'm not yet sure this one will ship with the custom types. I think there's one more question for me. I'm sorry, there has been discussion about Typst's memory use before. Has there been any progress in that area, especially since the bug is limited to 4 GB, there's no current progress, and I would like to optimize it, but again, probably more of a medium term thing.

也许可以稍微调整一下，使用自定义类型，但不一定与类型注解一起发布。我还不确定这个是否会包含自定义类型。我想我还有一个问题。抱歉，之前已经讨论过 Typst 的内存使用问题。这方面有什么进展吗？特别是考虑到 bug 限制在 4GB，目前还没有进展，我很想优化它，但这可能更多的是一个中期目标。

Reknih

Will Typst sort of get more languages with spells? We talked about this today, and in particular looking at adding a German dictionary, which has a license that works with our web app versus GPL. If you request a language, for example, via email to us, then we will look if we can locate a dictionary and edit.

Typst 会增加更多带拼写检查的语言吗？我们今天讨论过这个问题，特别是考虑添加一个德语词典，它的许可证适用于我们的 Web 应用程序，而不是 GPL。如果你通过电子邮件向我们请求某种语言，我们会看看是否能找到一个词典并添加它。

Laur

I mean, there are bunch of features, guys. I'm not sure how realistic that is. Maybe you can send us an email with a link to a dictionary that we can look, whether we can use it.

我是说，有很多功能。我不确定这有多现实。也许你可以给我们发一封电子邮件，附上一个词典的链接，我们可以看看是否可以使用它。

Reknih

yeah? How far will the compatibility between PDF and HTML go? So it will not be pixel perfect because we aren't going to determine the page breaks for your pages and print a footer at each of those page breaks. But other than that, I think that we can target a pretty faithful reproduction of your print document at the highest level. But there will be multiple levels where you can choose semantic vs. like full styling.

PDF 和 HTML 的兼容性会达到什么程度？不会做到像素级别完美，因为我们不会去决定你页面的分页，也不会在每个分页处打印页脚。但除此之外，我认为我们可以尽可能忠实地还原你的打印文档，达到最高水平。不过会有多个级别供你选择，比如语义化优先还是完整样式优先。

Laur

And semantic will be the first priority and full styling only later.

语义化将是首要任务，完整样式稍后才会考虑。

Reknih

Yeah.

Laur

Okay, then go ahead.

好的，开始吧。

Reknih

This will eventually be possible. Multiple HTML files and Typst compiler, Yes, and, publishing something from the web app and having also also, yes, but further down the road, I think so yes, will be possible.

这最终会成为可能。多个 HTML 文件和 Typst 编译器，是的，还有从 Web 应用程序发布内容，是的，但那是更长远的目标，我认为是的，这将会成为可能。

Laur

What about vector math support? Not something I see right now in the compiler. I would leave that to packages for now, especially with custom types.

矢量数学支持怎么样？目前在编译器中我没有看到相关功能。我认为现在应该交给软件包来处理，特别是使用自定义类型的情况下。

Reknih

What about improving this file link? Previous, I actually talked about this today. GitHub is are amazing, would be great to have something similar for documentation, problem is the penalty of generating them. But if we can get some good caching going, I think that could be nice.

如何改进这个文件链接？之前，我今天实际上谈到了这个问题。GitHub 在这方面很棒，如果能有类似的东西用于文档会很好，问题是生成它们的代价。但如果我们能做好缓存，我认为这会很不错。

Laur

Any plans for dynamic modules like a dictionary to model transformation? Now that we can already do dynamic WASM plugins? Yes, I think this would be a fairly easy PR. It should discuss a bit about how this will be constructed, but yes. Regarding the counter rule, what are your main concerns? Look what your and PR 5 7. I haven't looked what that is, but I guess it's the boat has a kind of. I must admit that I still haven't really gotten to that because I'm right now. I was focused a lot on the release and right now I need to work a bit on the web side. I will get back to that, but I can't say anything right now.

有没有计划做像字典到模型转换这样的动态模块？既然我们已经可以做动态 WASM 插件了？是的，我觉得这应该是一个比较容易的 PR。应该稍微讨论一下这个怎么构建，但是是的。关于计数器规则，你主要的顾虑是什么？看看你的 PR 5 7。我还没看过那是什么，但我猜它有点像船。我必须承认我还没真正开始做那个，因为我现在主要专注于发布，现在我需要做一些 Web 端的工作。我会回去做的，但现在我不能说什么。

Reknih

Where do you see in 10 years? Easy completely has superseded Latex. And not only that, but it has also become a great platform and to build your own document solutions upon and has been the standard for technical writing outside of academia.

你觉得 10 年后会是什么样？Typst 完全取代了 L^AT_EX。不仅如此，它还成为了一个很棒的平台，可以在此基础上构建你自己的文档解决方案，并且成为了学术界以外的技术写作的标准。

Laur

Is some basic string formatting a la formatting Rust expected to be available for ... or something like is not needed for very basic needs? I would like to see string interpolation with hashtag or hash expressions. I think I'm not yet really sold on these format strings with there are the columns and hashes and numbers in them. I think they're always a bit, to be honest. I would rather see, like to see some nice composable functions for that. This call would feel more approachable if you guys turned the camera on. Maybe yes. But then we can give more to the void.

是否会像 Rust 那样提供一些基本的字符串格式化功能……，或者说对于非常基本的需求来说并不需要？我希望看到使用井号或哈希表达式进行字符串插值。说实话，我还没完全接受那些带有列、哈希和数字的 f-string。我总觉得它们有点……我更希望看到一些不错的、可组合的函数来实现这个功能。如果你们能打开摄像头，这次通话会让人感觉更亲切。也许吧。但那样我们可能会给虚空提供更多东西。

Reknih

Yeah, we know the feedback and it would be interesting to hear in the chat if more people share the sentiment.

是的，我们了解这个反馈，如果更多人有同感，在聊天中分享一下会很有意思。

Reknih

I think we answered this one already. The answer here was it's good for some more low level drawing parameters will be added especially, especially something like Canvas, we can consider, but we don't necessarily target. Having charting in the compiler?

我想我们已经回答过这个问题了。答案是，添加一些更多低级的绘图参数会很好，特别是像 Canvas 这样的东西，我们可以考虑，但我们不一定以此为目标。在编译器中加入图表功能？

Laur

This one is also for you.

这个也是给你回答的。

Reknih

If there are two components to this, one is export importing packages from arbitrary Git locations with the compiler. Basically, the security implication here that any package could contain a link to a malicious server, that the Typst would then hit, and then you could exfiltrate some information through that. So Typst will need to ask the user before I'd contacted small type service and I'm the web app.

如果这里有两个组成部分，一个是使用编译器从任意 Git 位置导出导入包。基本上，这里的安全隐患是任何包都可能包含指向恶意服务器的链接，Typst 会访问该服务器，然后你就可以通过它泄露一些信息。所以 Typst 需要在联系小型类型服务和 Web 应用程序之前询问用户。

Laur

I think we're not talking about packages, but we're talking about good integration in the web app.

我认为我们不是在讨论包，而是在讨论 Web 应用程序中的良好集成。

Reknih

get integration in the web app? Um. Their support for arbitrary Git servers is blocking that the nodejs implementation that we're using. It's not supporting SSH auth and we don't want to store your password because we know that you are reusing it. And we need to store that in plain text, but we don't have SSH support that in with the CLI. So we need to either contribute that or wait until somebody else does it before we can support this.

网页应用的 Git 集成？嗯。我们使用的 NodeJS 实现不支持任意 Git 服务器，这阻碍了集成。它不支持 SSH 认证，而且我们不想存储你的密码，因为我们知道你可能会重复使用它。我们需要以明文形式存储密码，但 CLI 中没有 SSH 支持。所以我们需要贡献代码，或者等待其他人完成，才能支持这个功能。

Laur

Well, I have some articles I'd like to write for my blog. I think one article that would be fun to write is about currently existing quadratic runtime in Call me My, our incremental compilation library and my plan and how to fix it. But I don't know when I'll get to that or whether I'll write it.

我想为我的博客写几篇文章。我觉得写一篇关于 Call me My（我们的增量编译库）中目前存在的二次运行时，以及我的计划和如何修复它的文章会很有趣。但我不知道什么时候能写，或者是否会写。

Laur

Okay, next question. Wondering if we possibly to find customer element that then we talked a bunch about that it's a high priority, but not for 0.4. It's not possible to manage that in that time frame. But next to HTML and PDF, it is one of the higher priorities. There are no plans to switch from equal sign to a hashtag or switch number around. There's a bunch of discussions about it in different places. I think it just looks worse.

好的，下一个问题。想知道我们是否有可能找到自定义元素，我们已经讨论了很多，这是一个高优先级，但不是 0.4 版本。在这个时间范围内无法实现。但在 HTML 和 PDF 之后，它是优先级最高的任务之一。目前没有计划将等号改为井号，或者改变数字的顺序。关于这个问题有很多讨论，在不同的地方都有。我觉得那样看起来更糟。

Reknih

Will there be a summary of this call? Yes, morph is working on one and it will be posted to January after the call. I think I did good, so I've been writing everything down, no worries.

这次通话会有总结吗？是的，morph 正在写，通话结束后会发布到 January。我觉得我做得很好，我一直在记录所有内容，不用担心。

Laur

Can you provide access to the standards defining it? I think both of these standards can be found on the internet.

你能提供定义它的标准吗？我认为这两个标准都可以在网上找到。

Reknih

Yeah, it was posted in the chat before by Silly Freak. It's in section 12.7 of the PDF 1.7 spec and that is publicly available as well. Recently, since recently, the PDF 2.0 spec that has superseded it. What must be noted is that the PDF 1.7 spec still refers to XML forms architecture in some places, which has been deprecated in PDF 2.0 and shouldn't be used, and that is more difficult to locate than that.

对，Silly Freak 之前在聊天里发过了。它在 PDF 1.7 规范的 12.7 节中，而且是公开的。最近，PDF 2.0 规范已经取代了它。需要注意的是，PDF 1.7 规范在某些地方仍然引用 XML forms architecture，但在 PDF 2.0 中已被弃用，不应该使用，而且比 PDF 2.0 规范更难找到。

Reknih

But you don't need it, so don't look at it. Yeah, the forum doesn't share like same deployment path as the remainder of the website and I haven't gotten around switching that around, but good call. And I will put it on my Twitter list of our Wis 2 FA from of the web app.

但你不需要它，所以别去找了。论坛的部署路径和网站的其他部分不一样，我还没来得及改，不过提得好。我会把它放到我的 Twitter 列表里，作为我们……网页应用。

Reknih

Basically, you need to tell us that it is a blocking feature for page adoption of Typst in your organization, and then we'll have a look at it and prioritize it. But the web development pipeline is quite full at the moment, and it's something we want to do, but we don't currently have the capacity for. So maybe this year. And finally, I saw someone was to hire a jobs expert for their team to plan to offer support for teams. Officially, we do already to multiple companies or do any other insights into this position. So first of all, if you need support with helps, you can always ask us. But I understand that some people want to have like a Typst person in on their staff, just like they have JavaScript developer and their staff. And I think it's wonderful that the Typst of ecosystem can support positions like this.

基本上，你需要告诉我们，这是 Typst 在你组织中页面采用的一个阻碍性功能，然后我们会看看并优先考虑它。但目前 Web 开发流程相当满，这是我们想做的事情，但我们目前没有能力做。所以也许今年可以。最后，我看到有人想为他们的团队招聘 Typst 专家，以便为团队提供支持。正式来说，我们已经为多家公司提供支持，或者对这个职位有任何其他见解。所以首先，如果你需要帮助，你可以随时问我们。但我理解有些人希望他们的员工中有一个 Typst 人员，就像他们有 JavaScript 开发人员一样。我认为 Typst 生态系统能够支持这样的职位是很棒的。

Reknih

Okay, and finally, the typst's official suggestion button to vendor packages and templates that will sometimes listening, tweaking, and something like that. Definitely I've considered that. All right, and with that, I think we clear the questions. Laurenz, any closing words?

好的，最后是 Typst 官方建议的将软件包和模板进行供应商化的按钮，它会时不时地监听、调整等等。我肯定考虑过这一点。好的，这样我们就把所有问题都解决了。Laurenz，有什么结束语吗？

Laur

It was definitely fast clearing of the questions. I think we spoke so many words already .

问题解决得真快。我觉得我们已经说了太多话了。

Reknih

And definitely a lot of words, tremendous amounts of words.

确实说了好多话，海量的话。

Laur

So I think that plays us it up pretty much.

所以我觉得这基本上就说完了。

Reknih

Yeah?

是吗？

Laur

You were just briefly unmuted. I thought you wanted to say something.

不好意思，你刚才短暂地取消了静音。我以为你想说点什么。

PgSuper

Yeah, you said that it was a good time. Really enjoy the call.

是的，你说时间很好。真的很喜欢这次通话。

Reknih

And I hope you did too, in the audience. And thanks to everyone who has gone on stage and spoken. And we will send out more reminders to our speakers next time to join the call. And we will collect the Discord handle so we can ping them. So the next time that we announce sessions on the call, I think we have a good chance that it will actually happen. And with that, I can only thank everyone again for coming and for being so engaged with Typst in our community.

我也希望听众们也喜欢。感谢所有上台发言的人。下次我们会给我们的演讲者发送更多提醒，让他们加入通话。我们会收集 Discord 账号，这样我们就可以 ping 他们了。所以下次我们在通话中宣布会议时，我认为我们很有可能让它真正发生。最后，我只能再次感谢大家的光临，以及对 Typst 和我们社区的积极参与。

Laur

Yeah, also from my side, thank you.

好的，也感谢你。

Reknih

All right.

不客气。

Laur

See you all.

大家再见。

新世界的大门

今天我写日报

惊鸿一瞥：如何在鸿蒙上运行 Flutter Hello World

配置 HarmonyOS SDK#

Flutter 仓#

构建 SDK#

创建工程#

自新世界 #0x1a：六十四分之一的 Visual Studio

版权许可

x32dbg 调试#

Registers#

Log#

Call Stack#

配置开发环境#

查找纰漏#

内存快照#

罪魁祸首#

数字图像处理ㅤ第十一章作业

第 11 章 形状表示与描述#

假设#

方案#

实现#

图像预处理与二值化#

形态学操作#

连通分量分析#

液位检测与结果显示#

结果输出#

附：程序完整代码#

数字图像处理ㅤ第三章作业

数字图像处理ㅤ第二章作业

自新世界 #0x17：天津散步

版权许可

自新世界 #0x15：Carbon Design System

我在干什么#

Tauri#

Carbon Design System#

Vibe Coding#

GitHub Copilot Conversation Log

17

9

Full Response

Generated Code

Generated Code

Generated Code

Full Response

Generated Code

Full Response

Generated Code

Full Response

Generated Code

Full Response

Generated Code

Full Response

Generated Code

Generated Code

Full Response

Generated Code

Full Response

Generated Code

Generated Code

发布#

我在看什么#

自新世界 #0x16：制度性失忆

版权许可

2025 年 11 月 10 日#

2025 年 11 月 11 日#

2025 年 11 月 12 日#

2025 年 11 月 13 日#

2025 年 11 月 14 日#

2025 年 11 月 15 日#

2025 年 11 月 16 日#

脚注#

---#

自新世界 #0x12：私有协议

2025 liến 10 yuêc 19 lec#

2025 liến 10 yuêc 20 gen 21 lec#

2025 liến 10 yuêc 22 lec#

2025 liến 10 yuêc 23 lec#

2025 liến 10 yuêc 24 lec#

揚越雙語《金雲翹傳》——《〈斷腸新聲〉題辭》

配置 HarmonyOS SDK

Flutter 仓

构建 SDK

创建工程

x32dbg 调试

Registers

Log

Call Stack

配置开发环境

查找纰漏

内存快照

罪魁祸首

第 11 章形状表示与描述

假设

方案

实现

图像预处理与二值化

形态学操作

连通分量分析

液位检测与结果显示

结果输出

附：程序完整代码

我在干什么

Tauri

Carbon Design System

Vibe Coding

发布

我在看什么

2025 年 11 月 10 日

2025 年 11 月 11 日

2025 年 11 月 12 日

2025 年 11 月 13 日

2025 年 11 月 14 日

2025 年 11 月 15 日

2025 年 11 月 16 日

脚注

---

2025 liến 10 yuêc 19 lec

2025 liến 10 yuêc 20 gen 21 lec

2025 liến 10 yuêc 22 lec

2025 liến 10 yuêc 23 lec

2025 liến 10 yuêc 24 lec

譯文

升级

回退

HiSuite

将数据备份至云空间

如何导出媒体数据

使用 `hdc`

使用其他软件

克隆

在 Typst 中嵌入组件

渲染管线

`script` 标签

逐个解析

没有魔法，只有字符串

`unist` 的错误假设

前端生态

立即尝试

UnoCSS

VS Code

Servo

表示「替」「為」

「授予」以及把字句

「脫」

Sagnac 效应和基本表达式

激光陀螺

光纤陀螺

性能指标

原理和特点

激光陀螺

光纤陀螺

发展历程

功能需求

后端功能需求

1. 功能接口

(a) `generateCodeSignature` 函数

(b) `refactorVariable` 函数

(c) `generateDocument` 函数

(d) `foldConstant` 函数