当项目过于庞大的时候，往往趋向于使用将整个代码分散到多个仓库进行管理，各个仓库对应于项目的哥哥模块，彼此间可以用接口相互关联，但是又可以独立管理，十分地方便

但是怎么管理起来，就一点点说法了

repo工具

这个是google用来管理Android项目的工具，通过一个文件manifest.xml，里面列出相关的仓库和分支以及各个仓库对应的下载位置，来管理全部的仓库

一个典型的manifest.xml内容如下

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote name="origin" fetch=".." review="review.source.android.com" />
<default revision="master" remote="origin" />
<project name="project/build" path="build">
<copyfile src="makefile" dest="makefile.mk" />
</project>
<project name="project/test" path="test" />
<project name="project/apps/hello" path="apps/hello"/>
</manifest>

这里的project没有指定分支branch或者revision，就表示默认下载默认分支master上最新的节点的代码

场景1

获取主线master版本的最新代码，通常用于持续集成和定时构建，如下

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote name="origin" fetch=".." review="review.source.android.com" />
<default revision="master" remote="origin" />
<project name="project/build" path="build">
<copyfile src="makefile" dest="makefile.mk" />
</project>
<project name="project/test" path="test" />
<project name="project/apps/hello" path="apps/hello"/>
</manifest>

使用各个仓库的主线分支，每次下载都是下载这些仓库的主线分支master上的最新代码

场景2

开发中需要适配各种版本，从而需要生成各种manifest.xml，每个manifest.xml中存储这个版本的各个仓库的分支/哈希节点的信息

比如对应release分支，如下，对应的是v1版本

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote name="origin" fetch=".." review="review.source.android.com" />
<default revision="master" remote="origin" />
<!-- project/build是一个通用的仓库，默认分支可以兼容各种发布版本 -->
<project name="project/build" path="build">
<copyfile src="makefile" dest="makefile.mk" />
</project>
<project name="project/test" revision="release_v1" path="test" />
<project name="project/apps/hello" revision="release_v1" path="apps/hello"/>
</manifest>

场景3

某个节点的全部代码都已经测试完毕，bug收敛，达到发布质量标准了，并对每个仓库创建了标记号TAG，比如V1.0

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote name="origin" fetch=".." review="review.source.android.com" />
<default revision="master" remote="origin" />
<!-- project/build是一个通用的仓库，默认分支可以兼容各种发布版本 -->
<project name="project/build" revision="V1.0" path="build">
<copyfile src="makefile" dest="makefile.mk" />
</project>
<project name="project/test" revision="V1.0" path="test" />
<project name="project/apps/hello" revision="V1.0" path="apps/hello"/>
</manifest>

这样在任意时刻，使用这个manifest下载的代码，都是固定的

场景4

当一个大项目中，不同团队开发不同的仓库，但是也存在公共仓库供多个团队开发,如下所示，

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote name="origin" fetch=".." review="review.source.android.com" />
<default revision="master" remote="origin" />
<!-- project/build是一个通用的仓库，默认分支可以兼容各种发布版本 -->
<project name="project/build" groups="public" path="build">
<copyfile src="makefile" dest="makefile.mk" />
</project>
<project name="project/test" groups="public" path="test" />
<project name="project/apps/hello" groups="hello" path="apps/hello"/>
<project name="project/apps/world" groups="world" path="apps/world"/>
</manifest>

hello团队和world团队分别负责自己的仓库，但是project/build和project/test是公共仓库

hello团队使用这个manifest下载时使用命令repo init -u <manifest_url> -b <branch> -g public,hello

world团队使用这个manifest下载时使用命令repo init -u <manifest_url> -b <branch> -g public,world

场景5

当仓库不全部都是来源于一个代码源，如下所示

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote name="origin" fetch=".." review="review.source.android.com" />
<remote name="origin2" fetch=".." review="review2.source.android.com" />
<default revision="master" remote="origin" />
<!-- project/build是一个通用的仓库，默认分支可以兼容各种发布版本 -->
<project name="project/build" revision="V1.0" path="build" remote="origin2">
<copyfile src="makefile" dest="makefile.mk" />
</project>
<project name="project/test" revision="V1.0" path="test" />
<project name="project/apps/hello" revision="V1.0" path="apps/hello"/>
</manifest>

这样，project/build的代码就从review2.source.android.com地址下载，其他仓库就从review.source.android.com下载

总结

可见，使用manifest可以非常灵活地管理各个仓库，如果某个仓库有更新，直接更改manifest里面的仓库的revision就可以实现了，

缺点就是需要用户额外学习manifest的使用和配置了，并且manifest也是存放在一个git仓库里面的，所以这个manifest的git仓库也需要额外管理

git submodule

子模块是内嵌入git的，相关配置都是在git仓库的.gitmodules文件里面，如下所示

[submodule "libfoo"]
  path = src/libfoo
  url = https://github.com/example/libfoo.git
  branch = dev

[submodule "utils"]
  path = src/utils
  url = ../utils-repo.git  # 相对路径
  branch = release

子模块存储在git里面的只能是hash，所以每次子模块存在更新换了新的hash时，都要在git中下载子模块然后做个提交

好处是不需要用户额外学习安装repo，只需要记住几个常用的git submodule命令即可

公共模块更新

当一个公共的仓库有更新时，就需要让所有的包含这个公共仓库的仓库，去进行更新，比较麻烦

比如，hello仓库和world仓库都需要build仓库，那么在hello仓库和world仓库的.gitmodules文件里面都写上如下内容

[submodule "build"]
  path = project/build
  url = git@review.source.android.com/project/build
  branch = master

当build仓库有更新的时候，就要把hello仓库和world仓库的子模块build都去更新一下hash，

1. repo manifest只需要修改xml文件里面仓库的revision为目标hash
2. git submodule需要下载submodule的代码并且checkout到目标hash然后提交，仓库越大耗时越长

模拟repo manifest

假设，有个git仓库叫manifest，里面的.gitmodules内容如下

[submodule "build"]
  path = project/build
  url = git@review.source.android.com/project/build
  branch = master
[submodule "test"]
  path = project/test
  url = git@review.source.android.com/project/test
  branch = master
[submodule "hello"]
  path = project/hello
  url = git@review.source.android.com/project/hello
  branch = master

这样这个仓库连带submodule下载完，其实代码格局和repo manifest是十分相似的，但是

1.repo manifest中的revision可以直接看出仓库的hash节点，所以在交付源码时，直接发送一个revision是固定hash的xml即可 2.git submodule中的.gitmodules显示仓库的hash节点，必须把仓库下载到对应hash然后才能查看各个submodule的hash，比较麻烦

个人感觉这种模拟的效果是不如repo manifest的

总结

对于一些简单的仓库依赖场景，比如各个仓库呈现层数不高的树状依赖，就可以使用git submodule来简化操作,如下所示

     build
     /  \
hello    world

    test
    /  \
hello   world

如果是大型项目，存在上百个仓库，十几个开发团队协作，并且存在仓库之间的相互依赖，比如Android项目，还是推荐使用repo manifest管理

昨天刚刚参加高中同学的婚礼，发现18岁前的记忆、以及记忆的情感，总是占大脑中的很重的比重,于是就感叹，即使往后的岁月时长更长，也无法超过18岁之前的记忆

考更高的分数

从70分提升10分到80分，和从90分提升10分到100分，这俩者付出的努力是不同的，后者所需要的努力远远大于前者,如下图所示，

虽然都是提高1分，但是从1分到2分所需要的努力BC远远大于从0分到1分所需要的努力AB，也是边际效用的一种体现

这就是指数/对数关系

怀念青春

“我想起那天夕阳下的奔跑，那是我逝去的青春”

“幸福的人用童年治愈一生，不幸的人用一生治愈童年”

“白月光的杀伤力就是本人来了也没有用”

“人生果只如初见”

“第一印象最重要”

“江山易改，本性难移”

“有些人20岁就已经死了，80岁才埋”

为什么在时间上，一开始的那一段时间的影响，是如此的重要，请看下图

在时间轴上，2-4和4-6是一样的时间，但是俩者产生的记忆认识，却是AB大于BC

有另一种说法，当你十岁的时候，十岁那一年是你生命的1/10,当你30岁的时候，30岁那一年是你生命的1/30，那自然是十岁那一年的记忆认知更明显

假设一个人的寿命是70岁，显然，他的生命终点是35岁，但是，根据对数函数，记忆中点明显是小于35岁，大概是18岁，所以，可能高中毕业后，我们的大脑能认识的记忆就已经过半了，虽然我们的生命还远远没有到一半。

马太效应

为什么越有钱的人，越容易有钱，请看下图

在x轴上，虽然财富2是财富1的俩被，但是财富2获取财富的效率，却是财富1的3倍，这就是马太效应，也是对数/指数关系

在项目代码开发中，往往是使用具有版本管理的开发工具管理代码，比如git，而版本管理中重要的一个功能，就是分支功能，在开发过程中，往往会产生各种分支，而每出现一个分支，就意味着开发成本的增加，所以怎么管理这些分支，就需要好好考虑了

首先，master

假设当前有一个git仓库，有一个分支，叫master，如果为了降低分支开发成本的话，那么最省成本的是只用一个分支，比如叫master，需要开发的功能不断地往这上面提交就可以了,如下所示

当项目需要发布的时候，选择对应节点发布就可以了

这应该是最简单的分支模型了

然后，release

实际上，在公司里面，一个项目或者仓库，往往都是多人参与的，这个时候就有一个问题，每个人以及每个功能的开发进度不一致，有的人开发快，可能已经将下一个阶段的代码开发完成，有的人开发慢，可能还在修复上一个功能引入的bug，这个时候，如果只有一个分支，就很难找到一个commit，满足发布的需求，如下所示,

红色的提交/内容是当前发布不需要的内容，绿色的提交是当前发布需要的内容，这样就找不到可以发布的代码节点

聪明的人就知道，这个时候需要额外一个分支了，如下图所示

在靠前的节点，创建一个release分支，专门用于本次发布，然后将剩下的需要发布的内容，移植到当前的release分支上，这样就可以满足发布需求了

继续，hotfix

某日，正在master分支上开发新的功能，但是，突然，测试人员过来反馈一个V1.0版本的重大bug，需要你立刻响应，进行修复，这个时候，master分支可能已经演进到很后面的阶段了，只能在release分支上临时创建一个新的hotfix分支，用于修复测试，如下所示

在hotfix上提交后，验证测试完成后再移植到release分支上

这个时候就有人会问，为啥不能直接向release分支上提交，“你看，master分支都可以直接提交”，实际上，也是可以这么做的，但是为了保证release分支的质量，即release分支上的节点尽可能都是质量可靠的，所以需要创建hotfix分支，进行预先验证和测试

当然，这些修复的内容，也是需要回归主线master分支上的，避免后续的发布出现问题

番外，feature

当一个人往master分支上提交时，很舒服，因为不会像多人那样产生提交冲突，比如工程师A新建了一个文件叫def.py，工程师也新建了一个文件叫def.py，那么master分支上这个def.py到底应该是那个内容呢，这就是冲突，更准确地说，是文本冲突，

与文本冲突相对比的另一种冲突，是内容冲突,即在文本上，不存在冲突，比如工程师A在def.py第一行定义变量var = 1,而工程师B在def.py第十行也定义变量var = 2,那么在合并俩者的修改时，是不会报文本冲突的，但是，由于工程师A在开发的时候，不知道工程师B在第十行将变量var改成了2，就会一直按照var = 1的逻辑继续编写代码，这样在运行过程中，就会出现超出预期的异常

当每天都有来自不同的工程师，大量向master分支提交的时候，就可能出现很多的文本冲突，从而造浪费工程师大量精力在解冲突上，于是乎，就可以基于master分支，让每个工程师创建属于自己的feature分支，如下所示

这样，工程师就可以在自己的分支上开发，验证测试完善后，再合入master分支，在合入master分支的时候，一次性解决所有的冲突，从而节省了开发成本。

注意，随着时间推移，master分支的内容和工程师自己的feature分支内容，可能差距会越来越大，毕竟，master分支往往每天都会有很多提交合入，等到feature合入的时候，可能会有海量的冲突，为了避免到时候冲突太多，建议feature分支的周期不要维护太长，在一个短的周期内，比如2天以内，就完成修改然后合入master。如果feature分支开发周期较长，比如一周，那么就建议每天晚上定时将master最新的代码同步到feature分支，从而避免合入时的海量冲突。

总结

在大型项目中，比如Android项目，往往需要几十上百个仓库联合在一起，从而编译出项目产物，而不同的仓库，并不是全部都能按照计划完美无bug地进行，也不可能让每个仓库的所有开发人员在每次发布的时候，全体停下来，全身心投入本次发布，（当然，有些重大发布还是需要的），有些仓库可能超过计划进度完成，有些仓库可能落后计划进度，这都是很常见的情况。

这个时候，就会在项目的计划节点，让相关仓库创建出专门用于本次发布的分支，然后将本次需要的功能都移植到release分支，然后编译测试，等bug收敛后，正式将release的内容发布并创建TAG版本号。

所以创建release分支，即是方便聚合本次发布的功能代码，也是方便在发布过程中，提交修复代码，发布是需要一定时间的，比如持续一周

另一种分支模型

在小型项目中，比如小的前后端网站，往往开发人员不是很多，并且代码提交量不算很多的情况下，往往都可以按时完成开发任务，这个时候，就可以直接将代码进行发布，如下所示

因为代码都是按照计划进行的，所以不存在本次发布不需要的代码，从而可以直接移植到master分支，

其实这里的dev分支就是相当于之前的master分支，master分支相当于release分支

这种分支模型下，可以直观地在master分支上看到过往的各个版本历程，因为都是从master分支上发布的。

首先是外网连接权限，这个是大前提，如果你使用的是公司的网络，大概率就没这个问题，毕竟，使用公司网络是合法的，🐶

官方的插件都是在网站https://gerrit-ci.gerritforge.com/上面编译发布的，如果想知道编译的环境，直接从官网上查看日志就可以了

比如上图，看出来需要jdk21 和 bazel 7.2.1,那么就去安装这个环境

sudo apt install openjdk-21-jdk-headless

安装bazel的方式在官网上https://bazel.build/install/ubuntu?hl=zh-cn

wget https://github.com/bazelbuild/bazel/releases/download/7.2.1/bazel-7.2.1-installer-linux-x86_64.sh
chmod +x bazel-7.2.1-installer-linux-x86_64.sh
./bazel-7.2.1-installer-linux-x86_64.sh --user
export PATH="$PATH:$HOME/bin"

下载gerrit代码

 # 下载整个gerrit的代码
 git clone "https://gerrit.googlesource.com/gerrit" gerrit2
 cd gerrit2
 # 注意一定要下载submodule，否则就会有奇怪的报错
 git submodule update --init --recursive

下载需要编译的插件的代码

这里用官方的checks插件为例，进行编译

git clone https://gerrit.googlesource.com/plugins/checks
# 把插件代码复制到gerrit仓库源码的plugins目录里面
cp -r checks gerrit2/plugins/

开始编译

cd gerrit2
bazel build //plugins/checks:checks

我在wsl里面进行编译的，这里报错缺少zip工具，那么我就安装一个zip工具继续编译

终成正果，阿弥陀佛 ✔

checks插件

checks插件是官方提供的前后端都一起剩下的插件，理解了这个插件，就基本掌握了gerrit的插件开发

首先看一下官方画的大饼

https://gerrit-review.googlesource.com/Documentation/pg-plugin-checks-api.html

这里的功能包括

1. 和标签比如Code-Style联动，检查项失败标签自动-1
2. 展示失败详情和链接，这个链接可以是自定义的具体CI上的检查详情
3. 红色表示失败，黄色表示告警，绿色表示成功，灰色表示等待或运行，蓝色表示有信息，展示各个检查项的状态
4. 可以点击重试
5. 可以给各类检查结果贴上标签
6. 可以展示大文本，用于描述检查项更具体的信息

但是，上面的这么多功能，目前的checks插件里面没有使用起来，官方只是在上面这个截图上演示一下而已，实际的代码中，很多功能都没被用上

从fetcher.ts谈起

为什么从这个文件谈起呢，应为就是这个文件控制着checks面板的页面显示样式

看代码，如下，导入了@gerritcodereview里面的各类包

import {PluginApi} from '@gerritcodereview/typescript-api/plugin';
import {RestPluginApi} from '@gerritcodereview/typescript-api/rest';
import {
  Category,
  ChangeData,
  CheckRun,
  ChecksProvider,
  LinkIcon,
  ResponseCode,
  RunStatus,
} from '@gerritcodereview/typescript-api/checks';

这些包的具体位置，是在编译后的plugins/node_modules/目录里面，

最新sora发布，让ai的热度更上一层，而我自己工作在ai相关的行业，平常也试着在使用ai提升工作效率，

也可能感觉很有必要学习这些内容，这些可能是必备的技能了

当然，大量的内容都是从网上搜寻的，自己学力有限，只能拾人牙慧了

从拟合一元一次函数说起

先记录一个视频：再讲梯度下降算法

不知道大家在中学时段有没有做过一类题目，给出，1 一组映射，2 已知是一元一次函数，让大家求出或者选择出最接近的函数。

如果映射是(1,2)分别映射（3,5），那对于这个问题，实际上就是组个二元一次方程组就可以解决了，当然，对于这组映射，聪明的人都一眼看出是y=2x+1。

如果映射是（1.0231,1.9887,4.1008）映射（2.998,5.1212,9.02323)，以及不容易一眼看出的映射，这时，我们就假设这个函数是y=ax+b,然后设法求出a和b了。

那么如何求a和b呢，想想，我们的目标是找出a和b，让y=ax+b的结果和真实值差距尽可能的小，那么衡量a和b的拟合程度好坏的就是拿a和b去预测出的值和真实值之间的差距，差距越小，说明a、b就拟合的越好

那么第一时间想到的计算这个差距的方式就是将真实值和预测值相减，同时为了避免正负差值的相互抵消带来的影响，使用平方,如下所示

m可以是给出的真实数据组数，$x_i$和 $y_i$就是这些真实数据，上述函数就是关于变量a和b的函数，我们的目标是让J(a,b)的值最小，那么对于这个二次函数，可以用数学方法去寻找。

这里，我们先随机给a和b赋值，比方说a=-2，b=8,那么计算出的映射就是（5.9538，4.0026，-0.2016），和真实的结果差距较大，需要调整a和b去进一步缩小差距，

怎么去调整呢？观察函数J，为了让其值更小，需要将a向当前所在点的斜率反方向去调整，为什么？对这个二次函数来说，当一点的斜率大于0，函数值会随着自变量增加而增加，反之则减小；那么斜率大于0，a必须要减小，斜率小于0，a必须要增加，这样才能让函数J向更小的值去变化。

那么一次变化多少呢？如果太大，过了最佳的值，下次可能就会往回退，如果太小，就要经过更多的轮次才能找到最佳的值，所以这里的一次变化的大小需要谨慎设置。

如以下的公式，ξ就表示一次变化的大小，又称为步长,△J/△a （$\frac{\delta J}{\delta a}$）和△J/△b （$\frac{\delta J}{\delta b}$）分表表示函数J在这俩个变量上的斜率，减号表示相反的方向

通过以上俩个公式，结合计算结果，得知此时，a需要增加，b需要减小

经过多轮迭代后，就会让a和b的值更加接近于拟合效果更好的值

回味一下，这里例子中又a和b俩个变量，可以组成一个平面，(a,b)的变化方向，实际上就是朝着这个平面上(-△J/△a,-△J/△b) 这个向量的方向去变化的，这里可以结合梯度向量为什么是函数增加最快的方向？ 这个回答里面的图像去理解下，而向量(△J/△a,△J/△b)就是梯度向量，向量(-△J/△a,-△J/△b)所指的方向，就是梯度向量的反方向。

我说的有些啰嗦，上面俩个链接里面的内容更加丰富可靠。

万里长征第一步啊

通过上面的例子，其实已经初步接触到了深度学习的一些概念，比如梯度向量(△J/△a,△J/△b)，梯度下降，步长ξ，损失函数J，当然还有没接触到的，比如步长ξ在每次迭代中如何调整所涉及的优化方案，如何选取训练数据、批量/随机/小批量，等等概念就要后续渐渐学习了

最近遇到一个问题，就是jenkins job上传日志到es的时候，需要针对关键字前后各100行进行上传，其余的全部丢弃，（别问我为什么丢弃，es不至于这点儿日志里都撑不住），但是日志是实时的流式生成，logstash似乎不直接支持这类处理，所以需要自己想点儿法子

我爱说实话

那么维护一个滑动窗口就很有必要了，

1. 初始化一个滑动窗口，这个窗口容量为201，内容是空的
2. 初始化一个flag = false，表明窗口内有没有包含关键字的一行日志
3. 每当生成一行日志，
   1. 如果这行日志不包括关键字，那么把这行日志入栈滑动窗口
   2. 如果包括关键字，那么把这行日志入栈滑动窗口，并记录关键字位置/坐标1，并记录此时已经找到关键字了flag = true，准备100行后上传日志，即把窗口的剩余容量调整为100
   3. 如果接下来又遇到了一行包括关键字的日志，但是窗口还没填满，那么再次将窗口的剩余容量调整为100
   4. 一旦窗口满了，如果flag == true，将窗口内的所有日志上传，然后清空重置窗口和flag，当然，flag == false，保留窗口内最新的100个内容，将剩余容量调整为101
   5. 循环以上1-4即可

时间为O(n)，空间大概也是O(n)吧，不是很确定

当前做了一些gerrit的插件开发，主要是前端的js插件，记录一些坑

主要文档

• 官方插件说明

• 自己搭建的gerrit的前端插件地址： http://localhost:89/Documentation/pg-plugin-dev.html

入门

文档中给了一个最简单的前端插件使用，将下面这个js放到gerrit安装目录中的plugins目录中，就可以直接生效了

Gerrit.install(plugin => {
  const domHook = plugin.hook('reply-text');
  domHook.onAttached(element => {
    if (!element.content) { return; }
    // element.content is a reply dialog text area.
  });
});

hook

这个reply-text就是页面上的一个组件，可以hook的组件必须是官方支持的，具体那些页面组件可以hook，在http://localhost:89/Documentation/pg-plugin-endpoints.html

这里面就有一个比较坑人的地方，就是文档里面提示了有一些参数可以使用，比如当hook的对象是change-view-integration的时候，提示有change和revision这个俩个参数可以使用，

但是结合上面的示例代码，发现根本没有这俩个参数！翻遍了所有文档，都没见到如何使用这俩个参数，试了无数遍，最终发现，这俩个参数是存在element对象里面的字段，所以可以如下调用

Gerrit.install(plugin => {
  const endpoint = 'change-view-integration';
  plugin.hook(endpoint).onAttached(element => {
    console.log(element.change);
    console.log(element.revision);
  });
});

Promise

在查看到高级api的时候，发现restApi有接口返回Promise对象,所以需要学习一下

一个复制出所有topic其他提交的按钮

Gerrit.install(plugin => {
  const endpoint = 'commit-container';
  const domHook = plugin.hook(endpoint);

  function copyToClipboard(s) {
            if (window.clipboardData) {
                window.clipboardData.setData('text', s);
            } else {
                (function(s) {
                    document.oncopy = function(e) {
                        e.clipboardData.setData('text', s);
                        e.preventDefault();
                        document.oncopy = null;
                    }
                })(s);
                document.execCommand('Copy');
            }
        }


  domHook.onAttached(element => {
    const el = element.appendChild(document.createElement('button'));
    el.innerHTML = "copy"
    el.onclick = function(){
      topic_changes = document.getElementById("app").shadowRoot.getElementById("app-element").shadowRoot.querySelector("main gr-change-view").shadowRoot.getElementById("relatedChanges").shadowRoot.querySelector("gr-endpoint-decorator").querySelector("#sameTopic > gr-related-collapse").getElementsByTagName("gr-related-change")
    console.log(topic_changes.length);
    changes = []
    for(var index = 0; index< topic_changes.length;index++){
      change_href = window.location.href.replace(window.location.pathname,"") + topic_changes[index].shadowRoot.querySelector("a").getAttribute("href");
      console.log(change_href);
      changes.push(change_href);
    }
      copyToClipboard(changes.join());

    }
  });
});

最近在写gerrit的rules.pl，一开始我以为是perl语言，看了文档才发现这个是prolog语言，于是，就搜文档看看，这个语言的思路和平常的开发语言很不一样，很清奇

一个例子

% 表示love(X,Y)为true，语句以.结尾，X -> love -> Y，这个是单向的，不能理解成Y->love->X
love(X,Y).

% 表示当love(X,Y)为true、且love(Y,X)为true的时候，lovers(X,Y)为true，右边是左边的充要条件
lovers(X,Y):-love(X,Y),love(Y,X).

%

一些理解

• prolog程序没有特定的运行顺序，其运行顺序是由电脑决定的，而不是编程序的人。
• prolog的原理就是关系数据库，它是建立在关系数据库的基础上的。
• 强大的递归功能

知识点

事实

事实（facts）是prolog中最简单的谓词（predicate）。它和关系数据库中的记录十分相似。

语法结构如下 pred(arg1, arg2, … argN).

其中pred为谓词的名称。arg1，…为参数，共有N个。

参数可以是以下四种之一：

1. 整数（integer)
2. 原子（atom） 由小写字母开头的字符串。
3. 变量（variable） 由大写字母或下划线（_）开头。
4. 结构（structure）

可以将事实理解成，向数据库里面写数据。

常用的内部谓词

1. write/1 把参数当作字符串输出到屏幕
2. nl/0 在屏幕上输出回车
3. tab/1 输出n个空格
4. not/1 取反
5. =/2 此谓词当它的两个参数能够联合时成功，反之则失败。它的语法如下：

规则

pred(x):- pred(Y),pred(Z).

前面我们已经说过，谓词是使用一系列的子句来定义的。以前我们所学习的子句是事实，现在让我们来看看规则吧。规则的实质就是储存起来的查询。它的语法如下：

head :- body 其中，

head 是谓词的定义部分，与事实一样，也包括谓词名和谓词的参数说明。 :- 连接符，一般可以读作‘如果’。 body 一个或多个目标，与查询相同。

数学计算

X is <数学表达式>

X is 3*(1+2).
X > Y
X < Y
X >= Y
X =< Y

= 时赋值不计算， is 计算 而=:=是两头都计算

结构

functor(arg1,arg2,…)

类似于结构体

location_s(object(candle, red, small, 1), kitchen).

联合

变量&任何项目: 变量可以与任何项目绑定，其中也包括变量 原始项目&原始项目: 两个原始项目（原子或整数）只有当它们相同时才能联合。 结构&结构: 如果两个结构的每个相应的参数能联合，那么这两个结构可以联合。

=(arg1, arg2)

为了方便阅读，也可以写成如下形式：

arg1 = arg2

列表

list [a,b,c] [X|Y] X 是列表头(head), 它可以是一个列表，或其他任何数据结构 Y 是列表尾(tail), 它只能可以是一个列表

gerrit

gerrit中的设置submit的规则时，需要设置成，至少有一个+2，并且总分是4分及以上才能submit

sum_list([], 0).
sum_list([H | Rest], Sum) :- sum_list(Rest,Tmp), Sum is H + Tmp.

% 这部分是统计2的个数
count_twos([], 0). % 初始条件
count_twos([2|T], N) :- count_twos(T, N1), N is N1 + 1. % 动态规划之表第一个元素是2
count_twos([H|T], N) :- H \= 2, count_twos(T, N). % 动态规划之表第一个元素不是2


add_category_min_score(In, Category, Min,  P) :-
    findall(X, gerrit:commit_label(label(Category,X),R),Z),
    count_twos(Z, Twos), % 统计2的个数
    Twos >= 1, % 如果打分列表中的2的个数大于1，即至少有一个2
    sum_list(Z, Sum),
    % member(2, Z),!,member没法直接用，这里会报错
    Sum >= Min, !,
    gerrit:commit_label(label(Category, V), U),
    V >= 1,
    !,
    P = [label(Category,ok(U)) | In].

add_category_min_score(In, Category,Min,P) :-
    P = [label(Category,need(Min)) | In].

submit_rule(S) :-
    gerrit:default_submit(X),
    X =.. [submit | Ls],
    gerrit:remove_label(Ls,label('Code-Review',_),NoCR),
    add_category_min_score(NoCR,'Code-Review', 4, Labels),
    S =.. [submit | Labels].

通过以上例子发现，prolog语言实际上非常适合用来实现动态规划，简直是完美符合

作为一个集成构建工程师，一直对古老的构建工具make都是一直半解，这样下去是不行的，所以现在需要认真学习了

一个简单的操作

当你的工作目录下有一个叫makefile的文件，并且里面的内容是

a.txt: b.txt c.txt
	cat b.txt c.txt > a.txt

并且，工作目录下也有b.txt和c.txt文件，那么当你执行make a.txt的时候，就会在控制台输出cat b.txt c.txt > a.txt，并且生成了文件a.txt。

注意，第二行开头必须是一个tab

默认配置文件名是makefile

当直接执行make a.txt，这里的a.txt就是在makefile定义的目标名，默认配置文件名是makefile，当然也可以手动指定自己命名的makefile，比如使用make -f mymakefile a.txt，那么就会使用mymakefile文件中的内容执行构建了。

其实大多数构建系统都有这样的规则，比如使用docker打包镜像的时候，就是默认的Dockerfile文件名就叫Dockefile。

makefile的基本格式

[目标名]: [依赖]
[tab][shell 命令]

目标名就是执行make时所指定的，依赖一般是文件，make会在构建前确认依赖是否存在，shell命令就是执行具体的编译命令。

这么看上去，就很像在jenkins中编写groovy的dsl配置文件。

执行make构建

很简单，就是make加上目标名即可，实际make做的事情就是，找到对应的目标，然后检查目标的依赖是否存在，然后执行对应的语句。

makefile文件语法

通过上面的例子，明白了makefile文件就是一种约定，约定与执行间有着对应关系，这其实就是想导演手中的剧本，当然，在it领域，我们称之为脚本。

目标可能是文件，也可能不是文件（伪目标）

a.txt是一个文件，当执行make的时候，如果发现a.txt已存在，并且依赖文件没有改动，即modify时间没变，那么就不会执行构建，

当执行目标不是文件，比如删除文件

clean:
	rm *.o

那么，如果这个时候真的有个文件叫clean，那么这个clean就不会被执行，所以需要伪目标，

使用.PHONY去声明伪目标即可，如下

.PHONY: clean
clean:
        rm *.o temp

可以使用RECIPEPREFIX指定命令前缀

默认使用tab键开始识别shell命令，实际上可以使用RECIPEPREFIX去自定义这标识，下面这个例子就是使用>去做命令开始标识

.RECIPEPREFIX = >
all:
>echo hello world

shell语句默认在行与行之间无联系

如下是无法使用变量foo的

var-lost:
    export foo=bar
    echo "foo=[$$foo]"

有俩种方法，一种是携程一行，可以直接写在一行，也可以用反斜杠表示一行

var-kept:
    export foo=bar; echo "foo=[$$foo]"

var-kept:
    export foo=bar; \
    echo "foo=[$$foo]"

另一种是使用.ONESHELL命令

.ONESHELL:
var-kept:
    export foo=bar;
    echo "foo=[$$foo]"

注释默认会被打印，可以被关闭打印

cmd:
	# 这个注释会被打印
    @# 这个注释不会被打印

模式匹配

Make命令允许对文件名，进行类似正则运算的匹配，主要用到的匹配符是%。比如，假定当前目录下有 f1.c 和 f2.c 两个源码文件，需要将它们编译为对应的对象文件

%.o: %.c

等同于

f1.o: f1.c
f2.o: f2.c

makefile的变量

在makefile中，有如下的方法定义变量

VARIABLE = value
# 在执行时扩展，允许递归扩展，即展开makefile后最终的值

VARIABLE := value
# 在定义时扩展，即在写这赋值语句的地方付给变量的值

VARIABLE ?= value
# 只有在该变量为空时才设置值。

VARIABLE += value
# 将值追加到变量的尾端。

使用shell的变量需要使用俩个$$符号

p:
	echo $$HOME

内置变量

使用make -p -f /dev/null可以查看内置变量

常用的内置变量

1. $(CC) 指向当前的C的编译器
2. $(CXX) 当前的C++的编译器
3. $(MAKE) 指向当前make工具

自动变量

$@指代当前目标

a.txt b.txt:
    touch $@

等同于

a.txt:
    touch a.txt
b.txt:
    touch b.txt

$<指代第一个前置条件

a.txt: b.txt c.txt
    cp $< $@

等同于

a.txt: b.txt c.txt
    cp b.txt a.txt

$? 指代比目标更新的所有前置条件

$^ 指代所有前置条件，之间以空格分隔

$* 指代匹配符 % 匹配的部分

比如% 匹配 f1.txt 中的f1 ，$* 就表示 f1

判断和循环

使用BASH的判断和循环

ifeq ($(CC),gcc)
  libs=$(libs_for_gcc)
else
  libs=$(normal_libs)
endif

LIST = one two three
all:
    for i in $(LIST); do \
        echo $$i; \
    done

函数

• shell
  • 执行shell语句

    srcfiles := $(shell echo src/{00..99}.txt)
    

• subst
  • 用于字符串替换

    $(subst ee,EE,feet on the street)
    

• patsubst
  • patsubst 函数用于模式匹配的替换

    $(patsubst %.c,%.o,x.c.c bar.c)
    

字典结构体的定义在文件Include/cpython/dictobject.h

具体内容：

typedef struct {
    PyObject_HEAD

    /* Number of items in the dictionary */
    Py_ssize_t ma_used; //字典中的元素个数

    /* Dictionary version: globally unique, value change each time
       the dictionary is modified */
    uint64_t ma_version_tag;//字典版本号，每次字典有变更，这个值也会变更

    PyDictKeysObject *ma_keys; //指针，指向存储的键值对

    /* If ma_values is NULL, the table is "combined": keys and values
       are stored in ma_keys.

       If ma_values is not NULL, the table is splitted:
       keys are stored in ma_keys and values are stored in ma_values */
    PyObject **ma_values; //指向指针的指针，如果为空，则key和value都是存储在ma_keys,否则，key存放在ma_keys,value存放在ma_values，一般创建的字典都是联合表字典combined-table，分离表字典split-table字典用于__dict__属性，它们的键表被缓存在类型属性中，并允许所有该类型的实例共享值。
} PyDictObject;

而存储键值对的结构，PyDictKeysObject，即_dictkeysobject，定义在Objects/dict-common.h中

struct _dictkeysobject {
    Py_ssize_t dk_refcnt; //引用计数

    /* Size of the hash table (dk_indices). It must be a power of 2. */
    Py_ssize_t dk_size; // 容量，是2的倍数，这样在寻址的时候，可以用异或

    /* Function to lookup in the hash table (dk_indices):

       - lookdict(): general-purpose, and may return DKIX_ERROR if (and
         only if) a comparison raises an exception.

       - lookdict_unicode(): specialized to Unicode string keys, comparison of
         which can never raise an exception; that function can never return
         DKIX_ERROR.

       - lookdict_unicode_nodummy(): similar to lookdict_unicode() but further
         specialized for Unicode string keys that cannot be the <dummy> value.

       - lookdict_split(): Version of lookdict() for split tables. */
    dict_lookup_func dk_lookup; // hash查找函数

    /* Number of usable entries in dk_entries. */
    Py_ssize_t dk_usable; // 可使用的entry

    /* Number of used entries in dk_entries. */
    Py_ssize_t dk_nentries; //已使用的entry

    /* Actual hash table of dk_size entries. It holds indices in dk_entries,
       or DKIX_EMPTY(-1) or DKIX_DUMMY(-2).

       Indices must be: 0 <= indice < USABLE_FRACTION(dk_size).

       The size in bytes of an indice depends on dk_size:

       - 1 byte if dk_size <= 0xff (char*)
       - 2 bytes if dk_size <= 0xffff (int16_t*)
       - 4 bytes if dk_size <= 0xffffffff (int32_t*)
       - 8 bytes otherwise (int64_t*)

       Dynamically sized, SIZEOF_VOID_P is minimum. */
    char dk_indices[];  /* char is required to avoid strict aliasing. */
    //存入的entries，元素类型是PyDictKeyEntry
    /* "PyDictKeyEntry dk_entries[dk_usable];" array follows:
       see the DK_ENTRIES() macro */
};

typedef struct {
    /* Cached hash code of me_key. */
    Py_hash_t me_hash; //存储me_key的hash值
    PyObject *me_key; //键
    PyObject *me_value; /* This field is only meaningful for combined tables */ //值
} PyDictKeyEntry;

内存结构图如下

hash冲突

当某俩个不同的key，计算的hash一样的时候，就产生了hash冲突。 产生hash冲突的时候，就需要解决冲突，一般有以下的思路

1. 用某种方法再找个地址，直到没有冲突，这个思路下有以下方法
   • 将key用其他方式再hash
   • 查找这个地址之前/之后的可用地址 以上新增时可能会增加时间，比如出发扩容和多次查找会很耗时，但是访问速度快，可以序列化
2. 将这些冲突的key，额外存储下
   • 用一个链表/红黑树存储这些key，适合经常插入和删除，访问的时间可能会增加
   • 建立公共益处区，专门存储冲突的key

dict的各个接口函数的实现，都在文件Objects/dictobject.c文件中，

一般都是创建dict和给dict添加元素的时候，就会遇到hash冲突，所以可以直接观察插入元素的实现逻辑，从中看看python如何解决hash冲突的

static int
insertdict(PyDictObject *mp/*被插入的字典*/, PyObject *key/*需要插入字典的键*/, Py_hash_t hash/*需要插入字典的键的hash*/, PyObject *value/*需要插入字典的值*/)
{
    PyObject *old_value;
    PyDictKeyEntry *ep;

    Py_INCREF(key); //添加引用计数
    Py_INCREF(value); //添加引用计数
    if (mp->ma_values != NULL && !PyUnicode_CheckExact(key)) {
        // ma_values 不为空表示该字典是分离表字典，PyUnicode_CheckExact检查key是否是unicode对象，不能是unicode子类对象
        // 如果mp是分离表字典，且key不是unicode对象
        if (insertion_resize(mp) < 0)
            // 如果无法给mp申请内存，转换成联合表字典，那么直接失败，
            goto Fail;
    }

    Py_ssize_t ix = mp->ma_keys->dk_lookup(mp, key, hash, &old_value);
    // 调用dk_lookup查找需要插入的键值对所在的位置，理论上，为了保证该位置可以插入，那么这个查找函数就需要返回解决hash冲突后的地址了
    // 所以查看dk_lookup的实现
    if (ix == DKIX_ERROR)
        goto Fail;

    assert(PyUnicode_CheckExact(key) || mp->ma_keys->dk_lookup == lookdict);
    MAINTAIN_TRACKING(mp, key, value);

    /* When insertion order is different from shared key, we can't share
     * the key anymore.  Convert this instance to combine table.
     */
    if (_PyDict_HasSplitTable(mp) &&
        ((ix >= 0 && old_value == NULL && mp->ma_used != ix) ||
         (ix == DKIX_EMPTY && mp->ma_used != mp->ma_keys->dk_nentries))) {
        if (insertion_resize(mp) < 0)
            goto Fail;
        ix = DKIX_EMPTY;
    }

    if (ix == DKIX_EMPTY) {
        /* Insert into new slot. */
        assert(old_value == NULL);
        if (mp->ma_keys->dk_usable <= 0) {
            /* Need to resize. */
            if (insertion_resize(mp) < 0)
                goto Fail;
        }
        Py_ssize_t hashpos = find_empty_slot(mp->ma_keys, hash);
        ep = &DK_ENTRIES(mp->ma_keys)[mp->ma_keys->dk_nentries];
        dictkeys_set_index(mp->ma_keys, hashpos, mp->ma_keys->dk_nentries);
        ep->me_key = key;
        ep->me_hash = hash;
        if (mp->ma_values) {
            assert (mp->ma_values[mp->ma_keys->dk_nentries] == NULL);
            mp->ma_values[mp->ma_keys->dk_nentries] = value;
        }
        else {
            ep->me_value = value;
        }
        mp->ma_used++;
        mp->ma_version_tag = DICT_NEXT_VERSION();
        mp->ma_keys->dk_usable--;
        mp->ma_keys->dk_nentries++;
        assert(mp->ma_keys->dk_usable >= 0);
        ASSERT_CONSISTENT(mp);
        return 0;
    }

    if (old_value != value) {
        if (_PyDict_HasSplitTable(mp)) {
            mp->ma_values[ix] = value;
            if (old_value == NULL) {
                /* pending state */
                assert(ix == mp->ma_used);
                mp->ma_used++;
            }
        }
        else {
            assert(old_value != NULL);
            DK_ENTRIES(mp->ma_keys)[ix].me_value = value;
        }
        mp->ma_version_tag = DICT_NEXT_VERSION();
    }
    Py_XDECREF(old_value); /* which **CAN** re-enter (see issue #22653) */
    ASSERT_CONSISTENT(mp);
    Py_DECREF(key);
    return 0;

Fail:
    Py_DECREF(value); //异常情况，去除添加的引用计数
    Py_DECREF(key); //异常情况，去除添加的引用计数
    return -1;
}

没有直接查找到dk_lookup的直接实现,是在实际调用中，给dk_lookup赋值为各种lookdict函数

static Py_ssize_t _Py_HOT_FUNCTION
lookdict(PyDictObject *mp, PyObject *key,
         Py_hash_t hash, PyObject **value_addr)
{
    size_t i, mask, perturb;
    PyDictKeysObject *dk;
    PyDictKeyEntry *ep0;

top:
    dk = mp->ma_keys;
    ep0 = DK_ENTRIES(dk);
    mask = DK_MASK(dk);
    perturb = hash;
    i = (size_t)hash & mask;

    for (;;) {
        Py_ssize_t ix = dictkeys_get_index(dk, i);
        if (ix == DKIX_EMPTY) {//如果查找出的位置是空的，表示，这个位置可以插入新的键值对，那么直接返回这个地址
            *value_addr = NULL;
            return ix;
        }
        if (ix >= 0) {
            PyDictKeyEntry *ep = &ep0[ix];
            assert(ep->me_key != NULL);
            if (ep->me_key == key) {// key一致，表示这个位置就是要找的地方
                *value_addr = ep->me_value;
                return ix;
            }
            if (ep->me_hash == hash) { // key不一致，但是hash一直，表示发生了hash冲突
                PyObject *startkey = ep->me_key;
                Py_INCREF(startkey);
                int cmp = PyObject_RichCompareBool(startkey, key, Py_EQ);
                Py_DECREF(startkey);
                if (cmp < 0) {
                    *value_addr = NULL;
                    return DKIX_ERROR;
                }
                if (dk == mp->ma_keys && ep->me_key == startkey) {
                    if (cmp > 0) {
                        *value_addr = ep->me_value;
                        return ix;
                    }
                }
                else {
                    /* The dict was mutated, restart */
                    goto top;
                }
            }
        }
        perturb >>= PERTURB_SHIFT;
        i = (i*5 + perturb + 1) & mask; // ix <0,否则，将i运算后，进行下一轮计算
    }
    Py_UNREACHABLE();
}

通过上面的源码，看出来，python使用了实现起来最简单的开放地址法解决冲突，果然时刻践行着”怎么简单怎么来”的思想