1.有哪些读源代码的读源到底读软件？
2.源码阅读忆丛（37）Minigui
3.pytorch源码阅读系列之Parameter类
4.读Zepto源码之Data模块
5.TiDB 源码阅读系列文章（十六）INSERT 语句详解
6.Github 源码阅读神器推荐

有哪些读源代码的软件？

       为了阅读源代码，有许多软件可供选择，码系每种软件都有其独特的列读优势。例如，源码Textastic 是读源到底读一个非常强大的文本编辑器，支持多种编程语言。码系甩甩宝宝源码然而，列读它的源码价格可能对于一些用户来说略显昂贵。

       如果你正在寻找免费选项，读源到底读Documents 的码系文本编辑器和 SSH 到一台 Linux 机器使用 nano 都是不错的选择。Documents 的列读文本编辑器具有简洁的界面和强大的功能，适合阅读各种格式的源码文本文件。

       SSH 到一台 Linux 机器并使用 nano 读取源代码，读源到底读这种方法既经济又实用。码系首先，列读你需要确保目标机器上已经安装了 SSH 服务器和 nano 编辑器。然后，通过 SSH 客户端连接到目标机器，输入 nano 命令并打开所需的源代码文件。这将允许你在 Linux 机器上进行编辑和修改源代码。

       此外，Visual Studio Code、Sublime Text 和 Atom 等现代文本编辑器也提供了强大的功能来阅读和编辑源代码。它们支持语法高亮、自动完成、调试等功能，适合专业开发者和初学者使用。

       总之，选择适合自己的源代码阅读工具取决于个人需求和预算。免费的选项如 Documents 的文本编辑器和 SSH 到 Linux 机器使用 nano 提供了经济实惠的选择，而 Textastic、Visual Studio Code、Sublime Text 和 Atom 等付费软件则提供了更强大的功能和用户体验。

源码阅读忆丛（）Minigui

       探索GUI的历史与实现

       对于GUI的细节仍然存在一些困惑，似乎总是有新的东西需要学习。年轻时，对《Windows程序设计》、MFC等书籍充满热情，那些API的神奇之处让人着迷。然而，花费大量时间深入学习，却似乎事倍功半，微软似乎更倾向于教人如何使用，而非深入解释实现原理。尽管如此，还是尝试实现过文字版的GUI，涉及基本的按钮、滚动条、菜单等元素。但一些细节仍不清楚。

       通过网络搜索，了解到魏永明的Minigui项目是对Windows GUI和GDI的模仿。通过下载vc6版本的MinGUI，能够进行调试。locust源码 分析在分析代码时，发现事件回调、消息链等常见功能并无特别之处。而DefaultMainWinProc、InvalidateRect、PopupMenuTrackProc等函数则更具实际意义。GUI就像是在显存沙漠中绘画，有其既定规则。DefaultMainWinProc负责实现画最大、最小按钮、窗口方框等常规操作，而绘制的动作有其先后顺序，即消息的先后处理。

       GDI部分则展示了如何在显存中书写文字，包括粗体、斜体等效果；如何绘制图标和位图；关键的rgn裁剪矩形技术，用于加速绘制，矩形外的绘制不会进行。rgn裁剪矩形的运算包括加、减、合、并等，对应着窗口的各种移动和形状改变。不同线程之间的窗口管理由HWND_DESKTOP统一处理，desktop-common.c相当于窗口管理器，不同程序无法直接获取其他窗口的位置和大小，由其进行统一管理。desktop包含三个线程，分别负责捕捉键盘、鼠标消息，以及实际消息的处理，以及窗口给desktop的消息交由DesktopWinProc统一处理。

       MinGUI的模拟版本在调试方面虽能使用，但功能实现上有缺失。相比之下，libminigui-1.0.提供了完整的gui、gdi、kernel代码，定义了大部分的画窗套路和动作，只需要关注关键部分和自己定义的动作即可。

       Linux的GUI采用了xwindows，通过socket将xclient进程中的窗口绘制信息传输到xserver，由xserver统一处理。xclient之间互相不知道窗口的位置和大小，因此都通过xserver进行绘制，xserver还包含了窗口管理器。而MinGUI在一个进程的多个线程中实现，不存在窗口管理器与进程间位置信息传递的问题。

       Windows使用wink.sys作为窗口管理器，作为内核态程序，用户态的动态链接库在不同进程间数据段不同，但内核态的数据段统一，因此实现了窗口管理。ssh查询源码Windows显示流畅的原因之一在于窗口管理机制与MinGUI的desktop类似，但实现机制有所不同。

       工作繁忙，业余时间进行学习。尽管以前对GUI有过大量无用功，但这次的探索仅用几天时间便有所收获。

pytorch源码阅读系列之Parameter类

       Parameter类在PyTorch中扮演着关键角色，主要用于封装weight和bias等参数。在Module类中，weight与bias通过Parameter实例定义，如Linear层初始化函数所示。选择Parameter作为存储方式涉及Module类的多个函数，同时在定义网络时，可能需要将Parameter对象作为Module实例的属性。这涉及到参数的注册问题。首先分析在Module实例中使用Parameter的行为，然后从源码角度详细解读。

       Parameter类的主要作用是充当Module类的参数，允许自动添加到Module实例的参数列表中，并可通过Module.parameters()方法获取。验证Net实例属性为Parameter对象时，Net会自动将该Parameter对象注册到参数列表中。通过自定义Net实例验证了此行为。

       深入分析Parameter类的__new__()方法，发现其通过类方法实现实例化，并继承自torch.Tensor类，但没有单独的__init__()方法。Parameter实例包含了Tensor类的全部方法，功能强大。接下来分析Parameter是如何注册到Module类中的。

       Parameter的注册在Module类的__setattr__()函数中进行。该函数包含内部函数remove_from()用于处理重复定义的情况。通过self.__dict__维护实例的全部属性，其中_parameters参数用于存储Parameter对象。isinstance()函数用于判断value是否为Parameter类型，并在Module的__init__()函数调用后进行注册。注册过程通过self.register_parameter()函数完成，将Parameter对象添加到Module实例的_parameters属性中。

       总之，通过分析Parameter类的行为和注册机制，可以深入了解PyTorch中参数管理的细节。这包括自动注册、重复名称处理以及参数列表的构建，这些机制确保了网络训练过程的高效性和灵活性。

读Zepto源码之Data模块

       Zepto的Data模块主要负责处理DOM节点的数据，包括获取和存储与DOM相关的信息。本文将深度解析Data模块的工作机制，以Zepto1.2.0版本的源码为例。《reading-zepto》在GitHub上开源，欢迎star。

       在内部方法中，attributeData负责获取节点中所有data-*属性的值，并将它们存储到store对象中。面试 spark源码node.attributes获取的是所有属性，所以遍历时需要判断属性名是否以"data-"开头。存储时，去掉"data-"并转换为驼峰式，作为store对象的键。属性值默认为字符串，为方便操作，通过deserializeValue方法转换成对应的数据类型。

       setData方法用于存储数据，通常不需要写入DOM，而是在内存中进行操作。它首先读取node的exp属性，以确保属性名的唯一性，避免覆盖用户自定义属性。如果node尚未标记exp，则设置数据存储。从data中获取缓存数据，如果为空，则调用attributeData获取所有data-*属性的值并缓存。

       getData方法根据指定的属性名获取缓存值。没有指定名则返回所有缓存，缓存为空则调用setData。如果指定name在store中，则返回结果。兼容camel-name参数形式，提供更灵活的API。如果store中未找到，则返回通过$.fn.data查找的结果。

       data方法能设置或获取节点的缓存数据，调用setData或getData。当传递name和value时，设置缓存，遍历所有元素进行设置。对于对象传值，遍历设置缓存。最后返回第一个元素的name缓存。

       removeData方法用于删除缓存数据。若无参数，则清空所有，若有参数则仅删除指定数据。names为字符串时先转换为数组，遍历元素进行删除操作，根据names删除指定数据或清空store缓存。

       .remove和.empty方法在移除DOM节点后，需要清空对应节点的数据以释放内存。elements包含所有子节点，如果是.remove方法，自身也被移除，因此加入到要删除的节点中。最后调用removeData方法清空数据，再移除节点。

       $.data方法最终调用DOM的.data方法。$.hasData判断元素是会员源码破解否有缓存数据。通过从缓存中获取对应DOM的缓存store，若store存在且不为空，则返回true，反之返回false。

       所有文章在微信公众号上同步发布，欢迎关注和提出宝贵意见。

TiDB 源码阅读系列文章（十六）INSERT 语句详解

       作者：于帅鹏

       在已有的文章《TiDB 源码阅读系列文章（四）INSERT 语句概览》中，探讨了 INSERT 语句的基本流程。本文将深入解析 TiDB 中 INSERT 语句的多样性，特别是处理Unique Key冲突的各种策略。我们将了解六种不同类型的INSERT，包括基本插入、忽略冲突、更新冲突、警告更新、替换插入和特殊的LOAD DATA导入。

       六种INSERT语句如下：

       基本插入：当遇到唯一键冲突时，返回失败。

       忽略冲突：插入时遇到冲突，忽略并记录警告。

       更新冲突：在冲突后尝试更新并插入，若更新后仍有冲突，报错。

       警告更新：同上，冲突后更新，冲突再冲突则为警告。

       替换插入：冲突时删除并插入，重复此过程直到无冲突。

       LOAD DATA：类似忽略冲突，数据来自csv文件，但处理方式特殊。

       基本插入的执行逻辑在executor/insert.go，其中InsertExec实现了Executor接口。执行流程根据是否使用SELECT语句获取数据，分为insertRows和insertRowsFromSelect。insertOneRow是处理基本插入的核心部分，它在事务提交时检查冲突，利用batchChecker进行高效冲突检测。

       对于INSERT IGNORE，虽然基本插入在提交时检测冲突，但INSERT IGNORE需要立即检测，因此使用batchChecker实现批量检查，以提高效率。而INSERT ON DUPLICATE KEY UPDATE更为复杂，涉及插入和更新操作，通过batchChecker读取和更新数据，处理各种可能的冲突情况。

       REPLACE INSERT语句则具有特殊性，它会删除冲突行直到成功插入，这与其它INSERT语句处理冲突的方式有所不同。

       理解这些INSERT语句的实现，对于使用TiDB的高效执行以及潜在的代码贡献具有重要意义。继续阅读源码，掌握这些细节，将有助于你更准确地运用INSERT语句。

Github 源码阅读神器推荐

       一款高效阅读和学习源码的开源项目，source-code-hunter（doocs.github.io/source-code-hunter），为源码阅读爱好者提供便利。

       借助source-code-hunter，用户能够系统化阅读各种框架的源码，包括spring全家桶、Mybatis系列、Netty、dubbo等，以及中间件、JDK源码解析。

       该项目为初学者和源码学习者提供了学习心得，帮助他们建立学习模式，避免无用阅读，加速学习进程。

       对于没有源码阅读经验的用户，建议先阅读学习心得，了解学习方法和思考。在日常学习中，先通过视频了解源码的大致设计和功能点，再结合source-code-hunter阅读源码，同时使用本地调试跟踪实现，提升学习效率。

       source-code-hunter涵盖了常见框架的源码解析，为用户提供了丰富的学习资源，帮助用户深入理解源码逻辑，提高编程技能。

源码阅读忆丛（）eBPF

       eBPF：革新内核的瑞士军刀

       eBPF的发展如火如荼，其势头正盛，似乎有潜力彻底重塑Linux内核的可能。初识eBPF，源于对复杂源码的渴望，Hotspot、V8等大型项目让人望而却步，于是选择了一款小巧且充满潜力的eBPF来探索。深入学习后发现，eBPF的内容丰富多样，不仅提供了强大的调试工具，还能深入探测性能，勾起了我浓厚的兴趣。

       通过百度和阅读电子书《BPF之巅-洞悉Linux系统和应用性能》，我对eBPF的原理有了初步了解。书中的前五章着重介绍了eBPF的原理和技术，而后续章节则详细阐述了其工具的使用方法。这些工具的功能确实强大，但更多是在调试器层面的延展。我尤其对性能探测工具感到好奇，这促使我进一步深入研究。

       对eBPF原理的兴趣驱使我追溯其发展脉络。从年eBPF的早期版本开始，我发现其基础架构已足够强大，足以替代iptables。从年到年，这个领域似乎并未取得显著进展，这可能是因为它被忽视了。

       随着深入研究Linux 4.1版本（年发行），我浏览了samples/bpf和kernel/bpf目录下的源代码，重点分析了libbpf.c、bpf_load.c、core.c、syscall.c、verifier.c等关键文件。这些代码揭示了eBPF的加载和编译机制，包括在用户态标记并记录映射和函数调用，然后在内核态通过verifier.c的bpf_check(...)函数实现映射地址或函数地址的真实替换。至于代码的动态编译和优化，我选择跳过，因为涉及到的JIT等技术我已经较为熟悉。

       在理解eBPF动态插桩和静态插桩技术的基础上，我回顾了Linux 2.6.版本（年）的trace静态插桩技术。这个版本的trace功能较为基础，主要记录函数调用地址，但提供快速写入功能，即使数据来不及读取也会被覆盖。然而，读取数据时需要比较所有CPU的环形缓冲区记录，找到最久的记录。虽然功能有限，但trace静态插桩在内核重要函数的调用跟踪中发挥了作用。

       此外，我还研究了Linux 2.6.版本的kprobes动态插桩技术。kprobes提供了一种动态跟踪函数调用的方法，主要通过kernel/kprobes.c和arch/x/kernel/kprobes.c文件实现。reenter_kprobe函数处理调试中断时的重入问题，而kretprobe则将第二个CPU核单步执行，避免冲突。jprobe则通过插入代码改变程序流程，理论上避免了重入问题。

       在回顾了这些源码后，我发现它们的难度并不高，结合网络资源，我能够顺利阅读并理解。我仅记录了当时重点思考的部分，这些部分涉及了源码的关键功能和实现细节。

TiDB 源码阅读系列文章（五）TiDB SQL Parser 的实现

       本文是 TiDB 源码阅读系列文章的第五篇，主要内容围绕 SQL Parser 功能实现进行讲解。内容源自社区伙伴马震（GitHub ID：mz）的投稿。系列文章的目的是与数据库研究者及爱好者深入交流，收到了社区的积极反馈。后续，期待更多伙伴加入 TiDB 的探讨与分享。

       TiDB 的源码阅读系列文章，帮助读者系统性地学习 TiDB 内部实现。最近的《SQL 的一生》一文，全面阐述了 SQL 语句处理流程，从接收网络数据、MySQL 协议解析、SQL 语法解析、查询计划制定与优化、执行直至返回结果。

       其中，SQL Parser 的功能是将 SQL 语句按照 SQL 语法规则进行解析，将文本转换为抽象语法树（AST）。此功能需要一定背景知识，下文将尝试介绍相关知识，以帮助理解这部分代码。

       TiDB 使用 goyacc 根据预定义的 SQL 语法规则文件 parser.y 生成 SQL 语法解析器。这一过程可在 TiDB 的 Makefile 文件中看到，通过构建 goyacc 工具，使用 goyacc 依据 parser.y 生成解析器 parser.go。

       goyacc 是 yacc 的 Golang 版本，因此理解语法规则定义文件 parser.y 及解析器工作原理之前，需要对 Lex & Yacc 有所了解。Lex & Yacc 是用于生成词法分析器和语法分析器的工具，它们简化了编译器的编写。

       下文将详细介绍 Lex & Yacc 的工作流程，以及生成解析器的过程。我们将从 Lex 根据用户定义的 patterns 生成词法分析器，词法分析器读取源代码并转换为 tokens 输出，以及 Yacc 根据用户定义的语法规则生成语法分析器等角度进行阐述。

       生成词法分析器和语法分析器的过程，用户需为 Lex 提供 patterns 的定义，为 Yacc 提供语法规则文件。这两种配置都是文本文件，结构相同，分为三个部分。我们将关注中间规则定义部分，并通过一个简单的例子来解释。

       Lex 的输入文件中，规则定义部分使用正则表达式定义了变量、整数和操作符等 token 类型。例如整数 token 的定义，当输入字符串匹配正则表达式时，大括号内的动作会被执行，将整数值存储在变量yylval 中，并返回 token 类型 INTEGER 给 Yacc。

       而 Yacc 的语法规则定义文件中，第一部分定义了 token 类型和运算符的结合性。四种运算符都是左结合，同一行的运算符优先级相同，不同行的运算符，后定义的行具有更高的优先级。语法规则使用 BNF 表达，大部分现代编程语言都可以使用 BNF 表示。

       表达式解析是生成表达式的逆向操作，需要将语法树归约到一个非终结符。Yacc 生成的语法分析器使用自底向上的归约方式进行语法解析，同时使用堆栈保存中间状态。通过一个表达式 x + y * z 的解析过程，我们可以理解这一过程。

       在这一过程中，读取的 token 压入堆栈，当发现堆栈中的内容匹配了某个产生式的右侧，则将匹配的项从堆栈中弹出，将该产生式左侧的非终结符压入堆栈。这个过程持续进行，直到读取完所有的 tokens，并且只有启始非终结符保留在堆栈中。

       产生式右侧的大括号中定义了该规则关联的动作，例如将三项从堆栈中弹出，两个表达式相加，结果再压回堆栈顶。这里可以使用 $position 的形式访问堆栈中的项，$1 引用第一项，$2 引用第二项，以此类推。$$ 代表归约操作执行后的堆栈顶。本例的动作是将三项从堆栈中弹出，两个表达式相加，结果再压回堆栈顶。

       在上述例子中，动作不仅完成了语法解析，还完成了表达式求值。一般希望语法解析的结果是一颗抽象语法树（AST），可以定义语法规则关联的动作。这样，解析完成时，我们就能得到由 nodeType 构成的抽象语法树，对这个语法树进行遍历访问，可以生成机器代码或解释执行。

       至此，我们对 Lex & Yacc 的原理有了大致了解，虽然还有许多细节，如如何消除语法的歧义，但这些概念对于理解 TiDB 的代码已经足够。

       下一部分，我们介绍 TiDB SQL Parser 的实现。有了前面的背景知识，对 TiDB 的 SQL Parser 模块的理解会更易上手。TiDB 使用手写的词法解析器（出于性能考虑），语法解析采用 goyacc。我们先来看 SQL 语法规则文件 parser.y，这是生成 SQL 语法解析器的基础。

       parser.y 文件包含 多行代码，初看可能令人感到复杂，但该文件仍然遵循我们之前介绍的结构。我们只需要关注第一部分 definitions 和第二部分 rules。

       第一部分定义了 token 类型、优先级、结合性等。注意 union 结构体，它定义了在语法解析过程中被压入堆栈的项的属性和类型。压入堆栈的项可能是终结符，也就是 token，它的类型可以是 item 或 ident；也可能是非终结符，即产生式的左侧，它的类型可以是 expr、statement、item 或 ident。

       goyacc 根据这个 union 在解析器中生成对应的 struct。在语法解析过程中，非终结符会被构造成抽象语法树（AST）的节点 ast.ExprNode 或 ast.StmtNode。抽象语法树相关的数据结构定义在 ast 包中，它们大都实现了 ast.Node 接口。

       ast.Node 接口有一个 Accept 方法，接受 Visitor 参数，后续对 AST 的处理主要依赖这个 Accept 方法，以 Visitor 模式遍历所有的节点以及对 AST 做结构转换。例如 plan.preprocess 是对 AST 做预处理，包括合法性检查以及名字绑定。

       union 后面是对 token 和非终结符按照类型分别定义。第一部分的最后是对优先级和结合性的定义。文件的第二部分是 SQL 语法的产生式和每个规则对应的 aciton。SQL 语法非常复杂，大部分内容都是产生式的定义。例如 SELECT 语法的定义，我们可以在 parser.y 中找到 SELECT 语句的产生式。

       完成语法规则文件 parser.y 的定义后，使用 goyacc 生成语法解析器。TiDB 对 lexer 和 parser.go 进行封装，对外提供 parser.yy_parser 进行 SQL 语句的解析。

       最后，我们通过一个简单的例子，使用 TiDB 的 SQL Parser 进行 SQL 语法解析，构建出抽象语法树，并通过 visitor 遍历 AST。我实现的 visitor 只输出节点的类型，运行结果依次输出遍历过程中遇到的节点类型。

       了解 TiDB SQL Parser 的实现后，我们有可能实现当前不支持的语法，如添加内置函数。这为我们学习查询计划以及优化打下了基础。希望这篇文章对读者有所帮助。

       作者介绍：马震，金蝶天燕架构师，负责中间件、大数据平台的研发，今年转向 NewSQL 领域，关注 OLTP/AP 融合，目前在推动金蝶下一代 ERP 引入 TiDB 作为数据库存储服务。