JZX 轻语

Git连接提示"Connection closed by xxx"的解决方法

Fri, 09 Jan 2026 00:00:00 +0000

今天给自己的Ubuntu系统配置git的时候，发现没法连接Github，clone/fetch/pull此类涉及网络连接的操作都会出错，并提示”Connection closed by 20.205.243.166 port 22”。一开始以为是SSH密钥或者路由器DNS有问题，但重置了一遍后还是报错。经过查阅资料发现，可能是因为网络中的某一环（防火墙/代理服务器）屏蔽掉了22端口导致的。我们可以键入以下命令尝试是否可以通过443端口SSH连接到Github上：

ssh -T -p 443 git@ssh.github.com

如果提示如下信息，说明可以通过443端口连接到Github：

Hi {Your Github Username}! You've successfully authenticated, but GitHub does not provide shell access.

此时我们可以曲线救国，配置git使用443端口进行SSH连接。

具体方法是编辑~/.ssh/config文件（如果没有则新建一个），添加如下内容：

[url "ssh://git@ssh.github.com:443/"]
insteadOf = git@github.com:

上述配置新增一个路径重写（URL Rewriting）规则：每当执行Git操作（如clone、push、pull）且目标地址以“git@github.com:”开头时（通过insteadOf字段指定），Git会自动将其替换为“ssh://git@ssh.github.com:443/”。比如，当你执行命令：

git clone git@github.com:owner/repo.git

Git会转换为：

git clone ssh://git@ssh.github.com:443/owner/repo.git

这样就能通过443端口与Github建立SSH连接，绕过22端口被屏蔽的问题。

参考资料

跨仓库应用Git提交的方法

Wed, 05 Nov 2025 00:00:00 +0000

最近在处理公司项目时，遇到需要将一个Git仓库中的某些提交应用到另一个仓库中的情况。由于是两个分离的仓库，直接使用git cherry-pick命令并不可行。经过一番研究，发现可以通过导出补丁文件并应用到目标仓库来实现这一需求。本文分享具体的操作步骤和注意事项。

太长不看

在源仓库中，使用git format-patch命令将所需要的提交导出成补丁文件。如果需要将多个提交合并成一个补丁文件，可以使用git format-patch -<n> HEAD --stdout > <patch-file>命令。
在目标仓库中，使用git apply或者git am命令将补丁文件应用到目标仓库。如果两个仓库的目录结构不一样，可使用-p<n>选项和--directory选项来调整路径。比如，将仓库A中关于文件src/path/main.cpp的修改应用到仓库B中对应的文件Source/path/main.cpp，可以使用如下命令：

git apply <patch-file> \ 
    -p2 \   # remove 2 leading directory ("a/src/") from the path in the patch
    --directory="Source"  # prepend "Source/" to the path

适用场景

两个仓库A, B中具有相同名字的文件，且文件的内容大致相同，希望能将仓库A中对此文件的修改”cherry-pick”到仓库B中（当然，cherry-pick只能用于同一仓库的不同分支中，并不支持跨仓库提交）
两个仓库具有几乎一致的源码，希望能将仓库A的某个commit应用在仓库B中。这种情况一般发生在工程结构的重构，比如将一个仓库内的某个目录抽出来，单独作为一个新的仓库来维护。但前面的仓库因为某种历史原因，该目录仍未删除，形成了同一份代码（或工程），两个仓库并行维护的状态。因此在开发的过程中，需要往两个仓库提交几乎一致的代码。

具体过程

示例仓库结构

以一个示例仓库为例，我们先用git clone --recursive https://github.com/JezaChen/ApplyPatchAcrossRepoSample将其clone到本地。里面有两个子仓库”repoA”以及”repoB”，其中repoA的目录结构如下：

repoA/
  ├── src/
      └── path
            └── main.cpp

repoB的目录结构如下：

repoB/
  ├── src/
      └── Source
            └── main.cpp

而repoA里面的main.cpp和repoB里面的main.cpp内容大致相同。除了第8行所传入的参数不一样，其他内容是相同的。

输出补丁

我们对repoA的main.cpp进行改动，切去新的分支dev，在第一个提交（da93915）中，将add函数修改成

int add(int a, int b) {
    int sum = a + b;
    std::cout << "The sum is: " << sum << std::endl;
    return sum;
}

然后，在第二个提交（7669cbd）中，给add函数新增一行注释

// This function adds two integers and returns the result
int add(int a, int b) {
    int sum = a + b;
    std::cout << "The sum is: " << sum << std::endl;
    return sum;
}

如果我们想将这两个提交应用到repoB中，要怎么做呢？最直观的想法是使用cherry-pick，但cherry-pick只能用于同一仓库的不同分支中，并不支持跨仓库提交。这时候，git的补丁机制就派上用场了，我们可以将这两个提交导出成补丁文件，然后再将补丁文件应用到repoB中。

使用git format-patch命令导出补丁文件。在dev分支上，使用以下命令导出最近两次的提交：

git format-patch -2 HEAD

不幸的是，执行之后，会发现这个命令生成了两个补丁文件——能否将其合并成一个呢？当然可以！我们可以通过--stdout选项将其打印到终端上，然后重定向一个文件里（在例中，我们命名为my.patch）：

git format-patch -2 HEAD --stdout > my.patch

最后，我们将所输出的my.patch文件移动到repoB里。

应用补丁

补丁有了，怎么应用到目标仓库（repoB）里面呢？我们不难想到git apply命令，但直接应用git apply my.patch命令会报错，毕竟两个仓库的目录结构是有区别的。

还好，Git提供了灵活的选项——我们可以利用-p<n>和--directory来fix上述的问题：

git apply my.patch -p2 --directory="Source"

其中，-p<n>选项用于去掉补丁文件中路径的前n个目录层级，在本例中，补丁文件中的路径是a/src/path/main.cpp（注意补丁文件里面有个a/），我们需要去掉前两个目录层级a/和src/，使其变成path/main.cpp；

而--directory="Source"选项则是告诉git apply命令，将补丁应用到当前目录下的Source目录中。最终，我们应用补丁的路径就是Source/path/main.cpp，正好对应上了repoB中的main.cpp。

命令执行完毕后，我们可以使用git status命令查看repoB的状态，发现main.cpp文件已经被修改了，且改动的内容是一致的！

除了上述的git apply命令外，我们也可以使用git am命令来应用补丁文件，命令如下，可以发现与git apply命令类似：

git am my.patch -p2 --directory="Source"

两者的区别在于，git am应用补丁后会自动帮你提交，甚至能保留源仓库中的提交信息（比如作者、提交时间、提交说明等）；而git apply则只会应用补丁的内容，不会保留原有的提交信息。

contextlib.contextmanager源码分析

Wed, 10 Sep 2025 00:00:00 +0000

之前一直想写contextlib.contextmanager的实现原理，但也一直都没时间，今天看了Real Python关于上下文管理器的文章，打算补一下之前的坑。

预备知识

Python的语法糖很多，而contextlib.contextmanager主要涉及了三个比较常用的语法糖：装饰器、生成器和上下文管理器（with语句）。

装饰器

装饰器本质上原理很简单：它无非就是起到一种“锦上添花”的功能，在原有的函数上补充功能。被包装的函数以参数的形式传入到装饰器。也就是

@decorator
def func(): ...

本质上等价于

func = decorator(func)

生成器

生成器则可以看成能中途停下来（暂停的时候还能通过yield往外部抛出值），等待下一步指令并继续执行（外部可调用send方法传进指令，也可以直接通过next(...)让它继续）的函数。这里不再赘述，直接来个简单的例子：

def gen():
    print("gen(): Start...")
    first_command = yield "First"
    print(f"gen(): {first_command = }")
    second_command = yield "Second"
    print(f"gen(): {second_command = }")


if __name__ == '__main__':
    g = gen()
    print(f"recv1: {next(g)}")
    print(f"recv2: {g.send('Command1')}")
    try:
        print(f"recv3: {g.send('Command2')}")  # This will raise StopIteration
    except StopIteration:
        pass

可以看到，我们首先调用生成器函数gen得到一个生成器迭代器g，然后使用next(g)激活生成器迭代器g（此时会输出"gen(): Start..."），激活后，会返回一个字符串"First"。然后，我们使用g.send('Command1')发送字符串'Command1'到生成器迭代器中，此时生成器迭代器内的first_command = yield "First"收到外部传入的参数并赋值first_command，也就是first_command='Command1'，并继续执行下去。当生成器迭代器到达终点时，其会抛出一个StopIteration异常告知外部已经。

需要注意的是，如果外部不使用send发送参数而是直接调用next，则生成器迭代器内通过yield表达式所收到的值为None。

这里厘清一下生成器相关的术语：

生成器函数（generator function，大多数场合下，生成器（generator）指的是生成器函数）：函数体内包含yield语句的函数，调用它会返回一个生成器迭代器。
生成器迭代器（generator iterator）：生成器函数所创建的对象，其实现了迭代器协议（__iter__和__next__方法），具有send、throw、close等方法。

一般来说，生成器指的是生成器函数，但有时候也会指生成器迭代器，具体要看上下文。

上下文管理器

上下文管理器则是实现了__enter__和__exit__这两个魔术方法的类，使用时，将该类的实例传入到with语句即可。

我们可以简单实现一个上下文管理器，其会在进出上下文的时候输出一些信息，并且捕获with语句体内的ZeroDivisionError异常。

class SimpleCtxManager:
    def __enter__(self):
        print("Entering the context")
        return self

    def __exit__(self, exc_type, exc_value, traceback):
        print("Exiting the context")
        print(f"{exc_type  = }")
        print(f"{exc_value = }")
        print(f"{traceback = }")

        if isinstance(exc_value, ZeroDivisionError):
            print("Handled ZeroDivisionError")
            return True  # Suppress the exception
        return False  # Propagate other exceptions

我们可以写个简单的使用例子：

if __name__ == '__main__':
    with SimpleCtxManager() as s:
        print(f"{s = }")
    print("OK, no exception\n")

    with SimpleCtxManager() as cm:
        1 / 0  # This will raise ZeroDivisionError
    print("Go ahead, no exception propagated\n")

    with SimpleCtxManager() as cm:
        a = []
        a[1] = -1
    print("This line will not be printed due to IndexError")

运行程序，可以看到无论是否有异常，上下文管理器都能执行到__exit__方法，从而确保其所托管的资源能释放。当然，如果异常继续传播，with语句之后的代码也不会执行了（除非遇到finally语句）。

Entering the context
s = 'Hello'
Exiting the context
exc_type  = None
exc_value = None
traceback = None
OK, no exception

Entering the context
Exiting the context
exc_type  = <class 'ZeroDivisionError'>
exc_value = ZeroDivisionError('division by zero')
traceback = <traceback object at 0x000001AA8C7CFA40>
Handled ZeroDivisionError
Go ahead, no exception propagated

Entering the context
Exiting the context
exc_type  = <class 'IndexError'>
exc_value = IndexError('list assignment index out of range')
traceback = <traceback object at 0x000001AA8C7CF9C0>
python-BaseException
Traceback (most recent call last):
  File "C:\Users\Jeza\PyQtEx\test1.py", line 43, in <module>
    a[1] = -1
    ~^^^
IndexError: list assignment index out of range

`contextmanager`的简单用法

主角终于登场，现在我们使用contextlib.contextmanager对上文的上下文管理器类SimpleCtxManager做个等价的改造：

@contextlib.contextmanager
def SimpleCtxManager():
    print("Entering the context")
    try:
        yield
    except Exception as e:
        print(f"exc_type = {type(e)}")
        print(f"exc_value = {e}")
        print(f"traceback = {e.__traceback__}")
        if isinstance(e, ZeroDivisionError):
            print("Handled ZeroDivisionError:", e)
        else:
            raise
    finally:
        print("Exiting the context")

可以看到，contextlib.contextmanager是一个装饰器，其所包装的是一个生成器函数，其中yield语句前面的代码可以看成__enter__的逻辑，而后面的except…finally…语句则可以看成__exit__的逻辑（处理异常/清理资源）。对比发现，使用contextlib.contextmanager 不仅能让代码易读（看起来更流程化），而且不用专门写一个类，仅需一个生成器函数即可做到一样的功能。

`contextmanager`的源码分析

OK，终于讲到contextlib.contextmanager的原理了。我们可以在Python官方标准库中找到contextlib.py的源代码，定位到contextmanager的实现：

def contextmanager(func):
    @wraps(func)
    def helper(*args, **kwds):
        return _GeneratorContextManager(func, args, kwds)
    return helper

由代码看出，contextmanager是一个装饰器，其接受一个函数func作为参数，在闭包helper内用它来继续构造上下文管理器类_GeneratorContextManager的实例并返回。我们将装饰器contextmanager所返回的闭包helper视作为一个上下文管理器工厂（在外部看起来，它其实用法和上下文管理器是一样的），其接受任意的参数，负责在使用处构造出真正的上下文管理器_GeneratorContextManager的实例。

三个基类的分析

我们继续研究_GeneratorContextManager类的实现，首先看看它的基类：

class _GeneratorContextManager(
    _GeneratorContextManagerBase,
    AbstractContextManager,
    ContextDecorator,
):
    ...

可以看到其继承了三个基类，我们首先看第一个基类_GeneratorContextManagerBase的实现，这也是所有基于生成器的上下文管理器的公共基类：

class _GeneratorContextManagerBase:
    """Shared functionality for @contextmanager and @asynccontextmanager."""

    def __init__(self, func, args, kwds):
        self.gen = func(*args, **kwds)
        self.func, self.args, self.kwds = func, args, kwds
        # Issue 19330: ensure context manager instances have good docstrings
        doc = getattr(func, "__doc__", None)
        if doc is None:
            doc = type(self).__doc__
        self.__doc__ = doc
        # Unfortunately, this still doesn't provide good help output when
        # inspecting the created context manager instances, since pydoc
        # currently bypasses the instance docstring and shows the docstring
        # for the class instead.
        # See http://bugs.python.org/issue19404 for more details.

    def _recreate_cm(self):
        # _GCMB instances are one-shot context managers, so the
        # CM must be recreated each time a decorated function is
        # called
        return self.__class__(self.func, self.args, self.kwds)

不难分析，这个基类所实现的逻辑比较简单：保存生成器函数func以及调用func所需的参数args，kwds 、将func的__doc__属性复制到生成器里面去，以及提供一个_recreate_cm方法，以用来重新创建一个新的上下文管理器实例，保证该实例作为装饰器使用时，在每一次函数调用都能秽土重生，重新生成一个全新的实例用来执行上下文——因为生成器迭代器是一次性的，一旦激活并next下去，就没有回头路了。需要回头？只能重来。（让生成器函数再生一个出来）

再次强调下，这里的_recreate_cm方法仅用于该上下文管理器实例作为装饰器使用的场合。其覆写了第三个基类ContextDecorator的同名方法，后面会讲到。

这个上下文管理器的实例如何作为装饰器使用呢？后面第三个基类ContextDecorator的分析会有例子。这两个基类的关系很密切。

OK，我们来看第二个基类AbstractContextManager的实现：

class AbstractContextManager(abc.ABC):

    """An abstract base class for context managers."""

    __class_getitem__ = classmethod(GenericAlias)

    def __enter__(self):
        """Return `self` upon entering the runtime context."""
        return self

    @abc.abstractmethod
    def __exit__(self, exc_type, exc_value, traceback):
        """Raise any exception triggered within the runtime context."""
        return None

    @classmethod
    def __subclasshook__(cls, C):
        if cls is AbstractContextManager:
            return _collections_abc._check_methods(C, "__enter__", "__exit__")
        return NotImplemented

这个没什么好说的，其就是所有上下文管理器的基类。当然，由于Python是鸭子类型语言，并不强制上下文管理器的实现必须继承这个基类，这个基类只是用来加强类型检查，避免__enter__或__exit__方法没有实现（即上述的__subclasshook__所做的）。比如在下面的例子中，我们定义WrongCtxManager类的时候，犯了个很致命的错误——只实现了__enter__却漏了__exit__——还好！由于这个类继承了AbstractContextManager，在实例化的时候Python解释器会“贴心”地抛出异常，告知你没有实现完整的上下文管理协议。

from contextlib import AbstractContextManager

class WrongCtxManager(AbstractContextManager):
    def __enter__(self):
        print("Entering the context")
        return self

cm = WrongCtxManager()  # error!

~~可见当鹅比当鸭好！~~

我们来看第三个基类ContextDecorator：

class ContextDecorator(object):
    "A base class or mixin that enables context managers to work as decorators."

    def _recreate_cm(self):
        """Return a recreated instance of self.

        Allows an otherwise one-shot context manager like
        _GeneratorContextManager to support use as
        a decorator via implicit recreation.

        This is a private interface just for _GeneratorContextManager.
        See issue #11647 for details.
        """
        return self

    def __call__(self, func):
        @wraps(func)
        def inner(*args, **kwds):
            with self._recreate_cm():
                return func(*args, **kwds)
        return inner

这个基类更像是一个mixin，为子类实现了一个__call__魔术方法，使得上下文管理器实例可作为装饰器使用。在被包装函数调用的前后，执行__enter__和__exit__方法。关于_recreate_cm，前面已经提前路透了，这里不再多说了。

以前面的SimpleCtxManager为例，我们为它加上父类ContextDecorator，此时其实例就可以作为装饰器来用了。

from contextlib import ContextDecorator

class SimpleCtxManager(ContextDecorator):  # Inherit from ContextDecorator
    def __enter__(self):
        print("Entering the context")
        return self

    def __exit__(self, exc_type, exc_value, traceback):
        print("Exiting the context")
        print(f"{exc_type  = }")
        print(f"{exc_value = }")
        print(f"{traceback = }")

        if isinstance(exc_value, ZeroDivisionError):
            print("Handled ZeroDivisionError")
            return True  # Suppress the exception
        return False  # Propagate other exceptions

cm = SimpleCtxManager()

@cm  # Use the instance as a decorator
def func():
    print("func...")

func() 

# Outputs:
# Entering the context
# func...
# Exiting the context
# exc_type  = None
# exc_value = None
# traceback = None

回到`contextlib.contextmanager`

好了，分析完三个基类后，我们终于轮到分析主角contextlib.contextmanager了，可以看到，通过继承上述的三个基类后，contextlib.contextmanager只需将精力花在最核心的__enter__和__exit__两个方法：

（为减少篇幅，下面的源码去掉了注释）

class _GeneratorContextManager(
    _GeneratorContextManagerBase,
    AbstractContextManager,
    ContextDecorator,
):
    def __enter__(self):
        del self.args, self.kwds, self.func
        try:
            return next(self.gen)
        except StopIteration:
            raise RuntimeError("generator didn't yield") from None

    def __exit__(self, typ, value, traceback):
        if typ is None:
            try:
                next(self.gen)
            except StopIteration:
                return False
            else:
                try:
                    raise RuntimeError("generator didn't stop")
                finally:
                    self.gen.close()
        else:
            if value is None:
                value = typ()
            try:
                self.gen.throw(typ, value, traceback)
            except StopIteration as exc:
                return exc is not value
            except RuntimeError as exc:
                if exc is value:
                    exc.__traceback__ = traceback
                    return False
                if (
                    isinstance(value, StopIteration)
                    and exc.__cause__ is value
                ):
                    value.__traceback__ = traceback
                    return False
                raise
            except BaseException as exc:
                if exc is not value:
                    raise
                exc.__traceback__ = traceback
                return False
            try:
                raise RuntimeError("generator didn't stop after throw()")
            finally:
                self.gen.close()

可以看到，_GeneratorContextManager是幕后真正起作用的上下文管理器。我们抛开一些细节性的校验逻辑，分析下__enter__的主要思路：使用next(self.gen)激活生成器迭代器（也就是contextmanager包裹的生成器函数所返回的生成器迭代器），使其走到yield语句处停下——这也意味着，yield语句前面所执行的代码拿来充当__enter__的逻辑了！

我们再看__exit__的实现思路，分两种情况：

如果with语句块没有抛出异常：使用next(self.gen)恢复生成器迭代器，并期望它能执行到最后（包括走完finally语句块）。如果发现生成器迭代器暂停了（说明又遇到了yield），则这个生成器函数的实现不符合contextmanager的规范，抛出RuntimeError。
如果with语句块抛出了异常：将异常转发到生成器迭代器的yield 表达式处（self.gen.throw(typ, value, traceback)），给它一个机会做清理或选择抑制异常，然后再根据它所抛出的异常再做处理——
- 如果抛出的是StopIteration且其异常实例不同于所传入的异常实例（确保了这个StopIteration是生成器迭代器自己执行完毕所抛出的，而非重新raise了所传入的异常（尤其这个所传的异常也是StopIteration）），意味着它选择了抑制异常，此时__exit__返回True；
- 如果抛出的是其他异常，则说明生成器选择了不抑制异常，此时__exit__返回False，让异常继续传播。

里面还有一些细节也挺有意思的，这里就先不讲了，有空的话再原地补坑。先这样，睡觉~

穷哥们的电子书及笔记多平台同步免费方案

Sat, 06 Sep 2025 00:00:00 +0000

随着电子书资源如雨后春笋般地涌现在互联网，很多人都从传统的纸质书阅读转移到电子书上。对于一些专业相关的书籍，电子书往往都是PDF格式，且需要做大量的笔记。我们往往希望这些笔记能够多端同步，可随时随地地翻阅以前的读书心得。而目前也有不少的解决方案，比如MarginNote，GoodNotes这些，但这些应用往往需要收费，且可同步的平台往往也受限颇多。对于穷哥们而言，我们需要探索更实惠且更实用的阅读及同步方案，在不花一分钱的前提下，能够白嫖享受同步的便利。

使用Zotero进行笔记管理及多端同步

一般对于苹果全家桶而言，使用PDF Expert，MarginNote这些同步PDF及笔记足矣，但这些App大多并不支持Windows，Linux平台，说不上是一个合适的多端同步方案。还好，在学术圈中，还有一个大名鼎鼎的软件——Zotero。虽说Zotero的使用场合大多都是文献管理，但用在PDF电子书阅读上也足够合适。

Zotero官网地址：https://www.zotero.org/

建议注册一个Zotero账号，方便能同步自己的设置到各端。

使用Chrome内嵌PDF阅读器进行OCR分析

对于一些扫描版的PDF，我们没办法直接选择文本进行高亮。在过去，一般都需要借助一些专业PDF工具进行OCR扫描，这些工具往往需要收费，即便有免费使用往往也会存在额度，对于大部头而言可谓杯水车薪。还好，Chrome从2024年的126版本后，其内嵌PDF阅读器已经支持了免费的本地OCR扫描功能！穷哥们的我们可以利用这个功能，不用一分钱即可轻松给扫描版的PDF文件提取文字。

怎么启用这个功能呢？很简单，直接在Chrome里打开PDF文件即可。如果是扫描版PDF，此时Chrome会自动开启OCR，并在左下方会出现一个“正在从PDF文件中提取文本…”的提示。

Chrome上“正在从PDF文件中提取文本”的提示

耐心等待，直至提示消失，此时我们可以发现所有的页面都可以直接选择文字了。完美！

OCR转换后，所有的页面都可以直接选择文字了

遗憾的是，Chrome并不支持将这些文本保存在原PDF中。我们需要曲线救国，使用打印功能将文本保留下来。注意目标打印机选择“另存为PDF”，别选错成自己现实的打印机了，要不然浪费一堆纸🤪

使用打印功能将文本保留下来

可以发现，这时候“打印”下来的PDF文件是可以选择文本的了，但遗憾的是，“打印”之后，书签内容丢失了😨，我们还需要借助PDF工具，将书签迁移过来。

还好还好，书签导入导出功能在很多PDF编辑器中是免费的（毕竟技术含量不算高，收费就过分了）。我们可以使用福昕PDF编辑器，从原来的扫描版PDF导出书签内容，然后导入到“打印”后的PDF就好啦。

在福昕PDF编辑器导出/导入书签内容

此时，我们再导入到Zotero里面，就可以轻松选择并高亮文本了。

使用Infini Cloud进行WebDAV同步

我们还缺最后一步，也是最关键的一步：PDF及笔记的同步。

如果使用Zotero进行PDF及笔记的同步，一般有两种办法：

使用Zotero官方的云同步服务：小贵，和账号强绑定
使用WebDAV协议同步：自定义空间比较大，需要自己寻找支持WebDAV云盘

对于穷哥们而言，使用第二个方法可以省下不少银子。但国内可选的云盘并不大，大厂的云盘往往不支持WebDAV，而坚果云的价格也略贵。我们可以将目光投在国外的云盘上，看看有没有羊毛可薅。

InfiniCLOUD是一个性价比较高的WebDAV云盘，注册后即可有20G的免费空间，相比坚果云的免费方案要实用不少。虽然体验下来，InfiniCLOUD网页版的速度不敢恭维，但用作Zotero WebDAV同步此类实时性要求不高的场合还是足够的。

InfiniCLOUD地址：https://infini-cloud.net/en/

注册成功后，我们可在My Page页面中，开启Apps Connection

开启Apps Connection

将InfiniCLOUD提供的WebDAV地址、账号及密码填到Zotero的设置里，然后开启Sync功能即可。

Zotero WebDAV设置

Enjoy Reading!

附：再白嫖InfiniCLOUD 5G的免费空间

可以在My Page → Referral Bonus → Enter Friends Referral Code 填我的邀请码，能再白嫖5G的免费空间🤪：K8K8Z

InfiniCLOUD推荐奖励

在PyCharm中调试PyQt6程序报错"This application failed to start because no Qt platform plugin could be initialized."的解决办法

Sun, 31 Aug 2025 00:00:00 +0000

在使用PyCharm开发PyQt6程序的时候，有时候调试会遇上一些比较诡异的问题。比如在macOS上，会出现以下报错：

objc[69622]: Class QDarwinBluetoothPermissionHandler is implemented in both /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PySide6/QtCore.abi3.so (0x1070333f8) and /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PyQt6/QtCore.abi3.so (0x106ac6f08). One of the two will be used. Which one is undefined.
objc[69622]: Class QDarwinCalendarPermissionHandler is implemented in both /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PySide6/QtCore.abi3.so (0x107033470) and /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PyQt6/QtCore.abi3.so (0x106ac6f80). One of the two will be used. Which one is undefined.
objc[69622]: Class QDarwinCameraPermissionHandler is implemented in both /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PySide6/QtCore.abi3.so (0x1070334c0) and /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PyQt6/QtCore.abi3.so (0x106ac6fd0). One of the two will be used. Which one is undefined.
objc[69622]: Class QDarwinContactsPermissionHandler is implemented in both /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PySide6/QtCore.abi3.so (0x107033510) and /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PyQt6/QtCore.abi3.so (0x106ac7020). One of the two will be used. Which one is undefined.
objc[69622]: Class QDarwinMicrophonePermissionHandler is implemented in both /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PySide6/QtCore.abi3.so (0x107033560) and /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PyQt6/QtCore.abi3.so (0x106ac70c0). One of the two will be used. Which one is undefined.
qt.qpa.plugin: Could not load the Qt platform plugin "cocoa" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: offscreen, minimal, cocoa.

同样地，在Windows上可能也会出现类似的问题：

Windows上类似的错误

看起来是缺少插件或者环境问题导致的。但是诡异的是，直接运行却不会出现上述的问题，只有PyCharm上调试才会出现。那这种大概率是PyCharm内部机制影响到运行环境了。

修复方法

如果出现上述问题，可以先使用pip freeze观察下Python环境是否同时安装了PySide6和PyQt6，如果有，那大概率是PyCharm里面的pydevd调试器的补丁代码影响到程序运行了。

打开PyCharm的设置，在Python -> Debugger面板中，如果PyQt compatible已勾选，且所选项为Auto，此时需要调整为程序所用的框架，即PyQt6。保存设置后，重新调试就好啦。

调整PyCharm里的PyQt compatible设置

为什么会这样？

或许你会好奇为什么会出现这种情况，且为什么直接运行的时候又不会报错呢？其实这是pydevd对Qt框架注入测试代码的时候（参见文件_pydev_bundle/pydev_monkey_qt），如果上述设置所选的PyQt compatible为auto，那么它会根据自己的优先级寻找当前环境所安装的目标框架（pyside6，pyside2，pyside,pyqt6，pyqt5,pyqt4），而非真正的”auto”（智能识别程序所用的Qt框架）。如果pydevd发现PySide6已安装，此时只会注入PySide6，而不会注入PyQt6的。

而注入的过程本质是通过import语句导入相应的框架，然后再对其内部的对象进行猴子补丁。这就意味着，对于PyQt6程序，它会在PyQt6导入前，先导入了PySide6，相当于

# --> Inserted by pydevd
import PySide6
# ... monkey patching for PySide6
# <-- Inserted Finished

# Here is your code...
import PyQt6
# ... your code

所以也就是为什么macOS里的PyCharm会抱怨Class QDarwinBluetoothPermissionHandler is implemented in both /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PySide6/QtCore.abi3.so (0x1070333f8) and /Users/jeza/PyqtInspect/.venv-313/lib/python3.13/site-packages/PyQt6/QtCore.abi3.so (0x106ac6f08). One of the two will be used. Which one is undefined.了😅。

macOS 15使用brew安装binutils找不到命令(gobjdump, greadelf)的解决办法

Sat, 30 Aug 2025 00:00:00 +0000

最近在看《程序员的自我修养》，想在自己的mac上试验一下ELF文件的解析，找了下教程，使用brew安装了binutils后，直接在命令行输入gobjdump、greadelf还是找不着命令。最后搜了下，发现brew安装的二进制文件放在了/opt/homebrew/opt上了。遂直接添加到环境变量即可。

export PATH=/opt/homebrew/opt/binutils/bin:$PATH

Cursor连接Github Codespaces札记

Sun, 20 Jul 2025 00:00:00 +0000

Cursor可谓是今年AI Agent编程的网红产品了，其本质是在VS Code的基础上新增AI相关的功能。因此，VS Code的特性和大部分插件，它基本也支持。那么，按理说它也同样支持连接到Github Codespaces上进行开发，再加上强大的AI Agent，岂不美滋滋呢！

可惜的是，由于某种限制，Cursor官方并不能直接连接Github Codespaces。即便通过导入的方法安装VS Code的Github Codespaces扩展，尝试了下，也只能登录和查看Codespaces列表，但无法连接到Codespaces上进行代码编辑。只能换别的路子尝试下。

经过周末的一番尝试，终于通过SSH扩展以及Github CLI成功连接上Github Codespaces了，在codespace上使用AI和在本地代码开发一样丝滑，下面简单分享一下搭建的过程。

前提条件

Cursor扩展：Remote - SSH
需要安装好Github命令行工具Github CLI (gh)，然后根据官方指引登录Github和授权访问codespaces上的内容。

配置过程

先启动需要连接的codespace（可以在Github网页上启动；也可以使用Github CLI键入gh codespace ssh，根据交互式提示连接到codespace上启动，SSH连接成功后键入exit退出即可），然后输入命令gh codespace ssh --config生成SSH配置，不处于运行状态的codespace将被跳过（此时会输出”skiping unavaliable codespace xxx”）。如果观察到该命令有有效的输出（开头是Host xxxx），则说明配置生成成功了。

gh codespace ssh --config输出截图
回去Cursor，键入F1拉起命令面板，输入”SSH”，进入”Remote SSH - Open SSH Configuration File…”，打开SSH配置文件。
将第一步gh codespace ssh --config的输出（如果出现”skiping unavaliable codespace”开头的行，不要将这些行复制过去）添加到配置文件中（在后面追加，不要覆盖原来的内容）。

将gh codespace ssh --config的输出复制到SSH配置文件中
保存后，键入F1拉起命令面板，同样输入”SSH”，进入”Remote SSH - Connect to Host…”连接刚刚配置好的Host。

在命令面板输入SSH，进入”Remote SSH - Connect to Host…”

找到刚刚配置好的Host进行连接
大功告成，此时在新拉起的Cursor界面上点击”Open Folder”即可，一般而言项目目录在”/workspaces/"，Let’s use cursor to code!

在新拉起的Cursor界面上点击”Open Folder”，打开项目所在目录

C++模板元编程学习笔记 1: 模板的模板参数

Wed, 16 Jul 2025 00:00:00 +0000

模板的模板参数是C++模板元编程一个重要的基础概念。它允许我们在模板中使用其他模板作为参数，从而实现更复杂的类型和行为。

首先看一段简单的代码示例：

#include <iostream>
#include <tuple>

using namespace std;

template<typename>
struct first_type_getter {};

template<template<typename...> typename Ts, typename T1, typename... TN>
struct first_type_getter<Ts<T1, TN...>> {
    using type = T1;
};

// 不能这样子写
// 这样的话，first_type需要提供不止一个模板参数的
// 原本的 first_type<tuple<int, float, double>> 就要变成 first_type<tuple, int, float, double>
// template<template<typename...> typename Ts, typename T1, typename... TN>
// using first_type = typename first_type_getter<Ts<T1, TN...>>::type;

template<typename T>
using first_type = typename first_type_getter<T>::type;

int main(){
    cout << is_same_v<first_type<tuple<int, float, double>>, int> << endl;  // 1
    cout << is_same_v<first_type<tuple<int, float, double>>, float> << endl;  // 0
    cout << is_same_v<first_type<tuple<int, float, double>>, long> << endl; // 0
}

在这里，我们首先定义了一个通用的模板 first_type_getter，它接受一个类型参数。然后，我们对这个模板进行了偏特化，通过模板的模板参数使其能够深入获取参数内部的类型。这个偏特化版本提取了模板参数Ts中的第一个类型 T1，并将其定义为 type。在后续使用时，我们就可以通过first_type<std::tuple<int, float, double>>来获取元组的第一个类型int。

模板的模板参数语法

需要注意的是，使用模板的模板参数时，正确的语法应该长这样 template<template<typename...> typename Ts>。其中template<typename...>表示这个参数是一个模板，然后后面还需要加上typename以表明这是一个类型参数。

在上述的例子中，即便Ts的实参是一个类型别名，编译器仍然能够正确解析。

比如，如果我们使用using MyTuple = std::tuple<int, float, double>;，然后调用 first_type<MyTuple>，编译器仍然能够正确解析出 int 作为第一个类型。

为什么这里需要以偏特化的方式来实现第一个类型获取？

我们先假定不用偏特化的形式，直接定义一个模板：

template<template<typename...> typename Ts, typename T1, typename... TN>
struct first_type_getter {
    using type = T1;
};

如此，我们可以使用first_type_getter<std::tuple<int, float, double>>来获取第一个类型吗？答案是否定的。因为在这种情况下，first_type_getter的实例化需要提供不止一个模板参数（因为形参列表有多个参数），和我们的本意相悖。由于我们只需要传一个模板实参，且目的是从该模板实参中提取出内部的参数，所以只能先定义一个通用的、接受一个类型参数的模板，然后再对其进行偏特化。

Python对象dict方法分析札记

Sun, 04 May 2025 00:00:00 +0000

该文章是对Python对象__dict__方法的分析笔记，未完待续…

1: 为什么类里面的`dict`里面有一个键为`dict`的项？

这是因为避免了通过实例调用__dict__的无限递归。对于类A的一个实例a，a.__dict__存储了实例a的属性，而__dict__本身也作为了a的属性。当调用a.__dict__时，根据实例调用属性规则，如果A.__dict__['__dict__']不存在，或者不是一个数据描述器，那么会继而调用a.__dict__['__dict__']，从而陷入无限递归。

>>> a.__dict__
{'a': 8}

>>> A.__dict__
mappingproxy({'__module__': '__main__', 'a': 5, '__init__': <function A.__init__ at 0x0000022E13EA9DA0>, '__dict__': <attribute '__dict__' of 'A' objects>, '__weakref__': <attribute '__weakref__' of 'A' objects>, '__doc__': None})

>>> A.__dict__['__dict__']
<attribute '__dict__' of 'A' objects>

>>> type(A.__dict__['__dict__'])
<class 'getset_descriptor'>

>>> A.__dict__['__dict__'].__get__(a, A)
{'a': 8}

因此，Python在类中的__dict__添加了一个键为__dict__的项，其为一个数据描述器（getset_descriptor，可参见CPython的源码），当通过实例调用__dict__（即a.__dict__）时，解释器会优先调用这个数据描述器，从而避免了无限递归。当然，如果要覆写实例的__dict__属性（比如a.__dict__ = {}），也是会优先调用这个数据描述器实现覆盖，而不会造成a.__dict__['__dict__'] = {}这种情况。（问题来了：那实例的__dict__字典放在哪里了呢？）

如果我想通过改写类的__dict__属性，删掉里面的__dict__项，是否会造成无限递归呢？不会的，因为类的__dict__属性是一个mappingproxy对象，其本质上是一个只读的字典视图，因此无法直接修改，保证了程序的安全性。

>>> del A.__dict__['__dict__']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'mappingproxy' object does not support item deletion

2. 类中的`dict`和实例中的`dict`有什么区别？

类中的__dict__是一个mappingproxy对象，实例中的__dict__是一个普通的字典对象。类中的__dict__是只读的，而实例中的__dict__是可读可写的。本质上，类的__dict__其实就是其超类的__dict__['__dict__']，如此类推。

Github的Python项目发布到PyPI的简单方法札记

Sat, 21 Dec 2024 00:00:00 +0000

最近在弄一个新的Python项目，想把它放在PyPI上。由于之前的项目要么需要手动在本地通过build和twine打包上传，要么就是推上到Github仓库后，再各种设置Github Action以实现自动打包上传，虽然简单了不少，但还是需要自己生成token，并将其设置在仓库的secrets里面，步骤还是有点点多。现在PyPI支持了所谓的“受信任发布者”（Trusted Publisher），让发布流程更加的方便了。本文将以自己的新项目ihook作为例子，简单介绍下如何快速将自己在Github上的Python项目发布到PyPI上。

步骤

不必多说，需要发布到PyPI的Python项目需要有一个构建文件（比如使用setuptools构建的话，就需要setup.py或者setup.cfg）。具体可以参考PyPa的官方文档。我自己小项目的setup.py大差不差，可以参考这里。
注册一个PyPI账号。直接去PyPI注册就好。
将自己的项目推到Github的一个仓库上。
新建一个workflow（仓库网页->Actions->New workflow），选择“Publish Python Package”，此时Github会生成一个workflow文件（类似这样），无需任何改动，直接commit即可。
进去PyPI账号设置页里面的“Publishing”选项卡（可以直接点击这里），在下方的Github选项卡里面输入项目名字、账号名、仓库名以及workflow文件的路径（一般是python-publish.yml），然后点击“Add”即可。

PyPI项目表单填写示意
此时，只需在Github仓库创建Release，即可自动触发workflow，将项目发布到PyPI上！