run lint-md

.github/workflows/lint.yml

@@ -27,4 +27,5 @@ jobs:
           node-version: "latest"
       - name: Prettier check
         run: |
+          echo "If lint fails, run `make format` and commit again."
           make lint

Makefile

@@ -7,7 +7,9 @@ init:
 	git submodule update --init
 
 lint:
+	npx @lint-md/cli  .
 	npx [email protected] . --check
 
 format:
+	npx @lint-md/cli --fix .
 	npx [email protected] --write .

content/post/2023-09-05-bog-gc-1-en.md

@@ -125,7 +125,7 @@ However, Non-Moving GC has its disadvantages:
 
 4. **Memory Overhead**: Due to fragmentation, memory overhead can become less efficient. For instance, if there's a large object without enough contiguous space to store it, it might get split into multiple fragments which could be assigned to different contiguous spaces, potentially decreasing memory utilization.
 
-......
+……
 
 To address these problems requires many complicated steps, which won't be elaborated on here. We'll focus on Bog's GC for the explanation.
 

content/post/2023-09-05-bog-gc-1.md

@@ -119,7 +119,6 @@ Cheney 的拷贝收集器: 是一种用于半区（semi-space）的拷贝垃圾
 2. **内存分配**: 由于内存碎片，内存分配可能会变得更加复杂。例如，如果没有足够的连续空间来满足分配请求，那么分配器可能需要进行更多的工作来查找可用的空间。这可能会导致分配的性能下降。
 3. **内存使用**: 由于内存碎片，内存使用可能会变得更加低效。例如，如果有一个大对象，但是没有足够的连续空间来存储它，那么它可能会被分成多个碎片，这些碎片可能会被分配给不同的连续空间。这可能会导致内存使用率降低。
 4. **内存占用**: 由于内存碎片，内存占用可能会变得更加低效。例如，如果有一个大对象，但是没有足够的连续空间来存储它，那么它可能会被分成多个碎片，这些碎片可能会被分配给不同的连续空间。这可能会导致内存使用率降低。
-   ......
 
 为了解决这些问题需要很多复杂的步骤，在此不多赘述。单以 Bog 的 GC 来讲解。
 

content/post/2023-09-05-hello-world.md

@@ -15,7 +15,7 @@ date: "2023-09-05T16:13:13+0800"
 2. 在 `content/post` 内添加自己的文章（md 或 org 格式均可），文件命名为： `${YYYY}-${MM}-${DD}-${SLUG}.md`
 3. 文件开始需要包含一些描述信息，例如[本文件](https://github.com/zigcc/zigcc.github.io/tree/main/content/post/2023-09-05-hello-world.md)中的：
 
-```
+```plain
 ---
 title: 欢迎 Zig 爱好者向本网站供稿
 author: 刘家财

content/post/2023-12-24-zig-build-explained-part1.md

@@ -161,7 +161,7 @@ pub fn build(b: *std.build.Builder) void {
 
 现在，如果你调用 zig build --help 命令，就会在输出中看到以下部分，而之前这部分是空的：
 
-```
+```plain
 Project-Specific Options:
 -Dtarget=[string]            The CPU architecture, OS, and ABI to build for
 -Dcpu=[string]               Target CPU features to add or subtract
@@ -175,7 +175,7 @@ Project-Specific Options:
 
 前两个选项由 standardTargetOptions 添加，其他选项由 standardOptimizeOption 添加。现在，我们可以在调用构建脚本时使用这些选项：
 
-```
+```plain
 zig build -Dtarget=x86_64-windows-gnu -Dcpu=athlon_fx
 zig build -Doptimize=ReleaseSafe
 zig build -Doptimize=ReleaseSmall
@@ -214,15 +214,15 @@ pub fn build(b: *std.build.Builder) void {
 
 现在，当你调用 zig build 时，你会看到一个新的目录 zig-out 被创建了.看起来有点像这样：
 
-```
+```plain
 zig-out
 └── bin
     └── fresh
 ```
 
 现在运行 ./zig-out/bin/fresh，就能看到这条信息：
 
-```
+```plain
 info: All your codebase are belong to us.
 ```
 
@@ -287,7 +287,7 @@ RunStep 有几个函数可以为执行进程的 argv 添加值：
 
 现在，当我们调用 zig build run 时，我们将看到与自己运行已安装的 exe 相同的输出：
 
-```
+```plain
 info: All your codebase are belong to us.
 ```
 
@@ -322,7 +322,7 @@ pub fn build(b: *std.build.Builder) void {
 
 这样就可以在 cli 上的 -- 后面传递参数：
 
-```
+```plain
 zig build run -- -o foo.bin foo.asm
 ```
 

content/post/2023-12-28-zig-build-explained-part2.md

@@ -23,7 +23,7 @@ Zig 提供了 LLVM c 编译器 clang。第一种是 zig cc 或 zig c++，它是
 
 假设我们有一个由 main.c 和 buffer.c 生成的项目，我们可以用下面的命令行来构建它：
 
-```
+```plain
 zig cc -o example buffer.c main.c
 ```
 
@@ -33,7 +33,7 @@ zig cc -o example buffer.c main.c
 
 使用 zig cc 进行交叉编译与使用 Zig 本身一样简单：
 
-```
+```plain
 zig cc -o example.exe -target x86_64-windows-gnu buffer.c main.c
 ```
 
@@ -43,15 +43,15 @@ zig cc -o example.exe -target x86_64-windows-gnu buffer.c main.c
 
 使用 Zig 工具链构建 C 项目的另一种方法与构建 Zig 项目的方法相同：
 
-```
+```plain
 zig build-exe -lc main.c buffer.c
 ```
 
 这里的主要区别在于，必须明确传递 -lc 才能链接到 libc，而且可执行文件的名称将从传递的第一个文件中推导出。如果想使用不同的可执行文件名，可通过 --name example 再次获取示例文件。
 
 交叉编译也是如此，只需通过 -target x86_64-windows-gnu 或其他目标三元组即可：
 
-```
+```plain
 zig build-exe -lc -target x86_64-windows-gnu main.c buffer.c
 ```
 
@@ -93,7 +93,7 @@ pub fn build(b: *std.Build) void {
 
 然后，我们通过 addCSourceFile 添加两个 C 语言文件：
 
-```
+```plain
 exe.addCSourceFile(.{ .file = std.build.LazyPath.relative("main.c"), .flags = &.{} });
 exe.addCSourceFile(.{ .file = std.build.LazyPath.relative("buffer.c"), .flags = &.{} });
 ```
@@ -174,7 +174,7 @@ pub fn build(b: *std.Build) void {
 
 让我们创建程序，并通过 URL 调用它
 
-```
+```plain
 zig build
 ./zig-out/bin/downloader  https://mq32.de/public/ziggy.txt
 ```
@@ -549,7 +549,7 @@ pub fn build(b: *std.Build) void {
 这就是需要做的一切！是这样吗？
 
 实际上，有一种情况现在还没有得到很好的支持：
-您应用程序的入口点现在必须在 Zig 代码中，因为根文件必须导出一个 pub fn main(...) ....。
+您应用程序的入口点现在必须在 Zig 代码中，因为根文件必须导出一个 pub fn main(...) ……。
 因此，如果你想将 C 项目中的代码移植到 Zig 中，你必须将 argc 和 argv 转发到你的 C 代码中，并将 C 代码中的 main 重命名为其他函数（例如 oldMain），然后在 Zig 中调用它。如果需要 argc 和 argv，可以通过 std.process.argsAlloc 获取。或者更好： 在 Zig 中重写你的入口点，然后从你的项目中移除一些 C 语言！
 
 ## 结论

content/post/2023-12-29-zig-build-explained-part3.md

@@ -17,7 +17,7 @@ date: "2023-12-29T19:15:02+0800"
 
 ## 软件包
 
-译者：此处代码和说明，需要zig build-exe --pkg-begin，但是在0.11已经失效。所以删除。
+译者：此处代码和说明，需要 zig build-exe --pkg-begin，但是在 0.11 已经失效。所以删除。
 
 ## 库
 
@@ -39,7 +39,7 @@ date: "2023-12-29T19:15:02+0800"
 如果我们的项目越来越多，那么在构建过程中就需要使用工具。这些工具通常会完成以下任务：
 
 生成一些代码（如解析器生成器、序列化器或库头文件）
-捆绑应用程序（例如生成 APK、捆绑应用程序......）。
+捆绑应用程序（例如生成 APK、捆绑应用程序……）。
 创建资产包
 ...
 有了 Zig，我们不仅能在构建过程中利用现有工具，还能为当前主机编译我们自己（甚至外部）的工具并运行它们。
@@ -58,7 +58,7 @@ pub const Module = struct {
 };
 ```
 
-我们可以看到，它有2个成员：
+我们可以看到，它有 2 个成员：
 
 source_file 是定义软件包根文件的 FileSource。这通常只是指向文件的路径，如 vendor/zig-args/args.zig
 dependencies 是该软件包所需的可选软件包片段。如果我们使用更复杂的软件包，这通常是必需的。
@@ -89,7 +89,7 @@ const pkgs = .{
 };
 ```
 
-随后通过编译步骤exe，把模块加入进来。函数addModule的第一个参数name 是模块名称
+随后通过编译步骤 exe，把模块加入进来。函数 addModule 的第一个参数 name 是模块名称
 
 ```zig
 exe.addModule("lola",pkgs.lola);
@@ -139,7 +139,7 @@ pub fn build(b: *std.Build) void {
 
 不过，您也可以链接您作为二进制文件提供商的库。为此，我们需要调用几个函数。首先，让我们来看看这样一个库是什么样子的：
 
-```
+```plain
 ./vendor/libcurl
 include
 │ └── curl
@@ -167,7 +167,7 @@ include
 
 ### 动态链接
 
-要链接 libcurl，我们需要先添加 include 路径，然后向 zig 提供库的前缀和库名：(todo代码有待验证,因为curl可能需要自己编译自己生成static lib)
+要链接 libcurl，我们需要先添加 include 路径，然后向 zig 提供库的前缀和库名：(todo 代码有待验证,因为 curl 可能需要自己编译自己生成 static lib)
 
 ```zig
 //demo 3.3
@@ -191,9 +191,9 @@ pub fn build(b: *std.build.Builder) void {
 
 addIncludePath 将文件夹添加到搜索路径中，这样 Zig 就能找到 curl/curl.h 文件。注意，我们也可以在这里传递 "vendor/libcurl/include/curl"，但你通常应该检查一下你的库到底想要什么。
 
-addLibraryPath对库文件也有同样的作用。这意味着 Zig 现在也会搜索 "vendor/libcurl/lib "文件夹中的库。
+addLibraryPath 对库文件也有同样的作用。这意味着 Zig 现在也会搜索 "vendor/libcurl/lib "文件夹中的库。
 
-最后，linkSystemLibrary 会告诉 Zig 搜索名为 "curl "的库。如果你留心观察，就会发现上面列表中的文件名是 libcurl.so，而不是 curl.so。在unixoid系统中，库文件的前缀通常是lib，这样就不会将其传递给系统。在 Windows 系统中，库文件的名字应该是 curl.lib 或类似的名字。
+最后，linkSystemLibrary 会告诉 Zig 搜索名为 "curl "的库。如果你留心观察，就会发现上面列表中的文件名是 libcurl.so，而不是 curl.so。在 unixoid 系统中，库文件的前缀通常是 lib，这样就不会将其传递给系统。在 Windows 系统中，库文件的名字应该是 curl.lib 或类似的名字。
 
 ## 静态链接