近日发现了一个非常刁钻的可能引起基于 Emscripten 编译的 WASM 程序内存泄漏的问题。Emscripten 工具链提供了 Fetch 功能模块，这个模块允许我们调用浏览器的 fetch 接口来进行网络访问。

之前我写过一篇文章来吐槽 Nextcloud 的性能问题。当时我是尝试在群晖上试用 Nextcloud。考虑到我使用的群晖服务器的 CPU 性能比价差，因此我尝试在 Unraid 上部署 Nextcloud。但是性能差的问题仍然没有改观。不过近期在 Unraid 发布了 6.12.0 版本以后这个问题得到了很大的改观。

首先要声明的是，尽管 Python 是一种动态类型¹的语言，但是 Python 在 3.x 版本中还是引入了类型标注 (Type Annotation) 机制，使得我们可以以一种类似静态语言的方式来标注函数入参、返回的类型，或是类的成员类型。这种方式看似使得代码变得更加繁琐，但是合理的类型标注可以被编辑器/IDE 的静态检查机制所利用，进而提供更丰富的代码补全服务和静态错误排查服务。这使得我们在使用 Python 开发结构非常复杂的软件的时候能够提高编写效率，并减少大部分低级错误。

1 问题描述

JSON 格式的数据在和服务器通信过程中很常见，用 Python 处理我们可以用 json 库来读取，将其转化成一个字典。不过字典访问语法太繁琐了，我们需要将其转化一般对象，然后用访问类属性的方法去访问 Key-Value 对。直接硬写的非常繁琐，我们需要显式地讲类定义出来，然后一个个读取属性然后完成复制。我们需要一个更加符合 DRY (Dont Repeat Yourself) 原则的方法。

之前我在 Hexo + Mathjax: 公式离线渲染 介绍了在服务器端，也就是 Hexo 端渲染时就将 Mathjax 公式渲染成 Html 的方法。不过随着文章数量的增加，Hexo 渲染时会出现并发渲染公式的页面太多导致服务器内存溢出的问题（我用一个小虚拟机来做服务器博客后端，内存只有 2 GB）。因此有必要控制公式渲染的并发数。另一方面，公式渲染时纯 CPU 计算过程，不涉及 IO，因此使用异步函数加速意义也不太大。因此我们的核心思想是把之前实现的异步渲染版本换成同步渲染。

1 背景

今天在 Github 的时间线上看到了一个有意思的 Python 库，名字叫做 "IceCream"。这个库用来取代 print() 函数，实现更加可控且优雅的调试输出。IceCream 的接口形式非常简单，只要直接将函数的调用形式传入即可。如下面的代码：

1
2
3
4
5
6

from icecream import ic

def foo(i):
    return i + 333

ic(foo(123))

会产生下面的输出

1

ic| foo(123): 456

这个是怎么实现的呢？我查了一下代码发现 ic 函数（实际上一个实现了 __call__ 的类的实例）主要使用了 inspect 这个库。这是一个 Python 的标准库而我从来没有用过。

原文链接：My current HTML boilerplate

提交 Issue 到了 Hexo 官方 Github 仓库