啊？这玩意还能有第三期？

起因是想玩玩ChatGLM3，然后发现这个库用的pytorch版本特别新（说是要求2.0以上，实测1.12也行），于是就打算自己编一个新版本玩玩。然后人就傻眼了：编了几天，编译过程是挺顺利的，结果编出来的whl用不了，一import就报OSError 1114，说是某个DLL的初始化函数出了问题，一开始以为是编译器坏了（因为就在当天一次重启把我CUDNN炸了，也不知道是不是SSD的问题 汰渍全责！），前后更换配置（Python版本/MSVC版本/是否启用CUDA，甚至换了电脑）编了几天，SSD都写了快1TB了，还是没有任何进展。

然后也是因为各种配置问题没文档，编不出Debug版的wheel来，就着RelWithDebInfo版用regsvr32看了半天，发现好像是因为某个全局静态变量没有初始化还是咋的，导致DLL加载过程中抛出了c10库的异常，没给任何有用信息就直接把主程序炸了；然而由于该方法只是简单地加载了一个DLL，并不一定遵循PyTorch应有的初始化逻辑，所以也不知道有没有参考价值。

最后实在想不通了，为什么官方编出来的装了可以直接用，于是决定去偷学官方ci的编译脚本，看看编译流程上和自己的到底有啥区别，结果最后发现，好像最大的差别是他用的是Ninja生成，而我用的是MSBuild。虽然认为本质上应该没啥区别，但是抱着死马当活马医的心态，装了VS自带的CMake工具（对，这玩意其实也自带Ninja的），然后有样学样，用Ninja来编译PyTorch。虽然不是很想用咕果家的东西，但是不得不承认的是，Ninja的TUI还是做得比MSBuild好的，至少可以大致了解到编译流程进行了多少= =

这里贴一下中间需要设置的变量：

1. set CMAKE_GENERATOR=Visual Studio 16 2019（因为我没把Ninja加到PATH，以及VS2017编译会有报错）；
2. set DISTUTILS_USE_SDK=1，不然CUDA配置那里可能报一些奇奇怪怪的错误；
3. python setup.py bdist_wheel，然后理论上他configure完会出现异常终止，因为MSBuild内部调的Ninja和我们设置的环境变量不符合；
4. set CMAKE_GENERATOR=，取消generator的设置；
5. 重新执行3，理论上应该不出现任何问题，直到编译完成。

然后就是经典环节了。pip安装编完的whl，import，没有报错，直接成功了，是的，成功了。

很喜欢计算机人的一句话：啊？

只能说是在摸清问题之前解决了问题了罢。咱又不开发AI框架，既然问题解决了，那探究先到此为止吧。

鉴于某些众所周知的原因，GitHub传输速度太拉，gitee又半死不活的，于是决定给自己搭个本地git仓库用，一方面解决了公私有代码的问题 反正都是私有了，另一方面上传下载快的1p，还可以选择自己喜欢的管理风格。然后简单整理了一下现有的开源git服务器。只能说这玩意一团散沙，不靠友商对比都不知道有哪些，在这里简单列一下。

1. ruby系：GitLab。这个没什么好说的，说到私有git服务器第一反应必然是这个，似乎也是目前已知的开源git服务器中体量最大的，功能齐全，界面美观。问题在于自己编linux包麻烦，我omnibus-gitlab整了几天都没编出来= =

2. golang系：Gogs、gitea、forgejo。这仨一脉相传，我是先用的forgejo，然后又回头试用了下gogs，发现两者的html模板几乎都长得一模一样，后知后觉地搜了下才发现的。简单概括来说，就是先有的gogs，然后一群贡献者嫌gogs更新慢、不加新功能，然后fork出了gitea；然后gitea搞了几年之后开公司了，codeberg担心gitea搞收费，就又从gitea代码fork出了一个forgejo自己开发（贵圈真乱.jpg）。但是不得不提的是，gogs的确太老了，甚至不支持统计展示当前仓库各个语言的代码量。。

3. Java系：gitbucket、GitBlit、OneDev。这三家都是个搞个的，其中OneDev比较新，界面做的也比较现代化。

CAP理论指的是分布式系统通常难以同时达成Consistency一致性（任意规则读写均返回最新数据）、Availability可用性（一个节点挂了不影响其余部分正常服务）和Partition Tolerance可分区性（即使集群被网络切割开来，仍然能正常工作）三个特性。其原因大约可以归纳如下：

1. CA系统：缺少P，相当于完全不允许节点间出现短时（如网络延迟）或长时（如网络中断）导致的不一致性，与现实条件相悖；
2. CP系统：缺少A，摆烂，炸了就是炸了，以可用性为代价允许对系统分区（但是通信必须正常以保证一致性）；
3. AP系统：缺少C，还是摆烂，各个节点仅提供尽力服务，不保证数据是最新的。

基于CAP理论，业界主流产品都有自己的设计考量，产生了如下主流副本读写方案：

1. Quorum(NRW)：正如其名，三个参数，一共N个副本，客户端读取时指定R个副本，写入时指定W个副本，只有这些读写操作成功完成才能算读写操作成功。代表产品为DynamoDB、Cassandra，优点为读写并行、延迟较低，缺点为读开销大（R份全部读取成功才行），属于AP系统，容错级别为2F+1（为了容忍F个错误，需要2F+1个副本）；
2. Raft/类Paxos：写leader节点和一定数量的Quorum，如果出错则根据一致性协议重新选举，直至完成写操作。代表产品为Zookeeper、PolarDB，优点为客户端读写流量相对较少，缺点为串行写延迟较高（leader去写Quorum），属于AP系统，容错级别为2F+1；
3. Replicate：客户端写leader（master），leader把所有副本写完后才算写成功。代表产品为Hadoop、Ceph等，优点为容错级别较高（F+1），缺点为副本完全落盘带来的木板效应，可能由于某个副本延迟过高或者失效而导致客户端卡写IO，显然属于CP系统。

参考：

1. https://zhuanlan.zhihu.com/p/351979103
2. 钝角

出于兼容性考虑，还是编译一份32位版的，哪都能用。

装包：

pacman -S mingw-w64-i686-gtk3 pkg-config mingw-w64-i686-amtk mingw-w64-i686-tepl mingw-w64-i686-libpeas mingw-w64-i686-gobject-introspection mingw-w64-i686-gspell mingw-w64-i686-vala mingw-w64-i686-itstool mingw-w64-i686-desktop-file-utils

其中有几个地方要修改一下：

1. 复制一份pkgconfig的tepl-6.pc到tepl-5.pc，msys2没有这个包；
2. meson改了API导致语法不兼容，可以选择装meson的时候指定版本为0.59（参见meson.build），或者把data/meson.build文件第七行删掉。

配置：

git checkout gnome-3-38-fix-build
MSYS2_ENV_CONV_EXCL='PKG_CONFIG_PATH' meson

其中MSYS2_ENV_CONV_EXCL是针对MSYS2会自动改变环境变量的分隔符而加的。MSYS2装的pkgconfig只认冒号分隔符，但是MSYS2会自动转成分号，这样pkgconfig就只认PKG_CONFIG_DIR中的最后一个，导致pc文件找不到。

编译完成之后，在MSYS里设置好XDG_DATA_DIRS就可以使用了。界面和Linux下完全一样，win的标题栏都没了。然而非常诡异的一点是，如果试图把dll文件复制到gedit一起打包的话，会发现根本启动不起来，两者只能单独分开，然后通过PATH联系起来，就tm离谱。在3.36版本之前是有win32打包脚本的，不过之后被移除了，可以去git历史里面去看，然而我执行又是各种报错= =

===

第二天更新

又看了眼，发现相比于把dll复制到install目标文件夹里，官方脚本里的配置方式是把gedit install到现有的mingw环境中。那么一种可行的方式是，先用pacman装好需要的库，然后把编译好的gedit install到这个chroot环境中。假设安装到E:\gedit\mingw32目录，那么根据make-gedit-installer脚本，可以有如下操作：

pushd /e/gedit
mkdir -p var/lib/pacman
mkdir -p var/log
mkdir -p tmp
pacman -Syu --root `pwd`
pacman -S mingw-w64-i686-gtk3 ...  # 后面的库略

这个地方的mingw32文件夹是不可少的，主要是因为msys2为了做环境隔离，设立了多个子文件夹。后续可以把这个mingw32文件夹单独提出来，重命名后自由使用。

还有一种偷懒的方法是，先直接用pacman装gedit，再卸掉这个包，剩下来的就是依赖环境了

然后再用meson去reconfigure gedit，指定prefix为E:\\gedit\\mingw32，重新执行ninja和ninja install即可完成安装。安装完大小接近1个G，如果需要精简空间，可以参考remove_useless_stuff函数，改改路径前缀执行，最终能把大小控制在400MB以内。（经典的gedit 2.30展开安装也才80MB左右，通货膨胀严重啊）

因为这里不打算发行，就不按照原始脚本用wix进行后续打包工作了。

最近写CMU15-445的时候，project 1里面有个任务类似于写unique_ptr智能指针PageGuard，创建时增加引用计数，销毁时减少引用计数。然后这里有个让人疑惑的地方，就是他要求写移动构造函数。当时我想着，这跟用= default应该没啥区别，后来不放心，还是做了个实验验证下，发现和想象中的还是有些出入。

废话不多说，直接贴代码：

#include <bits/stdc++.h>

using namespace std;

struct A {
    int val = 0;
    string msg = "";
};

int main()
{
    A a1{114514, "1919810"};
    printf("a1{%d,%s}\n", a1.val, a1.msg.c_str());

    A a2(std::move(a1));
    printf("a2{%d,%s}\n", a2.val, a2.msg.c_str());
    printf("a1{%d,%s}\n", a1.val, a1.msg.c_str());

    return 0;
}

然后结果是，a2能成功继承a1的所有数据，但是在move后的a1中，只有std::string的值被清空，而int类型的数据仍然保持了原有值，而非初始化到0。这个结果就与成员变量的平凡性有关了：对于平凡类型，move和直接复制该类型没有任何区别。也就是说，仅仅对于非平凡类型而言，才会存在真实的move动作，并将被move对象重置为设定的某个中间状态——平凡类型要求使用编译器隐式生成的移动构造函数，因而并不会对原有数据进行修改，move之后还是保持原有的值。

由于规定以C语言生成的所有数据结构都是平凡的，我们可以推测指针本身也是一种平凡类型，move后不会被清空。那么这下问题就解决了：要求我们自己实现移动构造函数的原因是，在对象中使用了C指针而非智能指针，并不能通过move的方式来解除被move对象与内存区域的绑定，需要自己手动使用nullptr来重置这些指针，防止它们在预期的生命周期外修改数据，制造未定义行为。