game-log-sdk-go

经过两年多的测试，新版本的腾讯游戏日志服务（TencentGameLog，简称TGLog）的go语言版本SDK game-log-sdk-go 正式开源了，本服务支撑了腾讯互娱内部的PB级日志上报，支持了TCP/UDP日志上报，具体可以参考我们的文档。

最近因为开了两个 操作系统 和 linkers 的新坑，一直在学习硬件和汇编相关的知识，所以这里找了一个简单的小游戏 MHRD(Micro Hard Rock Deluxe) 用来复习一些基础的CPU相关的知识，以下是官方的描述：

MHRD is a hardware design game, in which you design various hardware circuits in a hardware description language. The hardware circuits you design get more complex as you go until you create a fully functional CPU design.

语法

A design consists of the Inputs, Outputs, Parts and Wires section:

---
title: GRAMMER
---
flowchart LR

design("design"):::pink

subgraph grammer
	direction LR
	input_section("input_section"):::green
	output_section("output_section"):::green
	part_section("part_section"):::green
	wire_section("wire_section"):::green
end

design --> grammer

classDef pink 1,fill:#FFCCCC,stroke:#333;
classDef green fill: #696,color: #fff,font-weight: bold;
classDef purple fill:#969,stroke:#333;
classDef error fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5

前言

在最近实现一个 简单的kv数据库 中又重新思考了一些问题。

当我第一次尝试了解数据库底层原理的时候，就从各个角度了解到了选择B+树而不是B树的很多理由，基本上无非是以下这些因素：

• B+树支持范围查询。B+树非叶子节点不存储数据，并且成熟的B+树实现的叶子节点都会通过指针连接起来构成一个单独的链表；所以当我们进行范围查询的时候，只需要找到起始叶子节点之后遍历链表找到对应的结尾叶子节点即可。但是B树的非叶子节点也可以存储数据，所以无法实现；
• 更适合磁盘存储：B+树的内部节点只存储键值的索引，而叶子节点存储实际的数据。这种设计使得每个节点的大小更小，可以容纳更多的键值对，减少了磁盘I/O的次数。另外，由于叶子节点之间通过链表连接，可以更好地利用磁盘预读取的特性，提高查询性能。
• 更适合索引：数据库通常需要支持快速的索引查找，而B+树的结构更适合作为索引结构。B+树的内部节点只存储键值的索引，可以更好地利用内存空间，提高索引的效率。
• 查询效率更稳定：B树的查询时间复杂度在1到树高之间，因为数据可能存储在根节点、内部节点或叶子节点，查询效率会因数据所在位置不同而波动。B+树的所有数据都存储在叶子节点，查询复杂度则稳定为树高，查询效率更加稳定。

当时觉得很有道理，然而随着水平和眼界的提升，却发现这里存在相当多的地方值得商榷：

早上逛 reddit rust 时偶然看到了 Ian Lance Taylor 介绍 linkers 的系列文章，觉得很有意思，决定开一个新坑来看看能不能自己实现一个简单的 linkers，目前找了一些资料，看起来工作量并不小。这里先做个简单的记录，参考的文章和书籍：

• linkers by Ian Lance Taylor
• byo-linker
• Linkers and Loaders

可能会涉及到的基础知识包括：

• SPARC (Scalable Processor ARChitecture)
• x86 instruction listings
• Executable file: ELF, PE, OMF
• Symbol table
• shared libraries
• Static library
• dynamic linker
• 其他待总结

第一印象

一个最简单的链接过程

---
title: 一个简单的链接过程
---
flowchart LR

source1("source1"):::purple
of1("object_file1.o"):::purple

source2("source2"):::purple
of2("object_file2.o"):::purple

linkers("linkers"):::pink

executable("executable"):::green

source1 -->|gcc -o| of1
source2 -->|gcc -o| of2

of1 --> linkers
of2 --> linkers

linkers --> executable

classDef pink 1,fill:#FFCCCC,stroke:#333;
classDef green fill: #696,color: #fff,font-weight: bold;
classDef purple fill:#969,stroke:#333;
classDef error fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5

链接过程可能涉及到的产物

test-fsm-arithmetic-operations

• 测试一下通过 Finite State Machine 实现简单的四则运算解析；
• 全部代码在 test-fsm-arithmetic-operations，因为只是为了测试状态机，所以有非常多的边界条件没有处理。

在之前 Programming Language Monkey 中，其实也实现了一版，但是当时只是简单的根据 Pratt Parsing 实现，并没有画出完整的状态机，所以在这里重新实现了一次，为了避免浪费太多的时间，这次将只会支持以下简单内容：

• 支持 +, -, *, / 四则运算；
• 支持 ()；
• 仅支持标准十进制格式的 number，不支持 0xFF 等其他形式的数字输入；
• 仅支持 int64 类型，也就是说除法会导致会导致数据丢失，但是考虑到本来就是为了了解状态机而实现的玩具，这个完全是可以接受的；

前言

A Tour of Rust - Binary Search Tree

学习Rust已经有一段时间了，最近开始尝试用 Rust 进行一些简单的demo开发进行练手。今天尝试了一下，实现了第一个简单的 Binary Search Tree。必须承认，Rust 的入门曲线确实相当陡峭。本来我的预计是花费2~3小时实现，结果最后花了整整6个小时，比预计的时间超出一倍多。这里记录一下自己的学习心得以及体会。

代码实现

在实现代码的过程中，我使用了两种不同的开发思路：

1. 基于传统的命令式编程语言，使用语言提供的各种控制流语句（如 if, while）来控制逻辑；
2. 基于Rust强大额模式匹配控制逻辑；

act

---
title: act
---
flowchart LR

counter:::prefix
over:::prefix

act:::root

counter --> act --> counteract

counteract --> Counteraction
counteract --> Counteractive
counteract --> Counteractively
counteract --> Counteractant

over --> act --> overact

overact --> Overaction
overact --> Overactivity
overact --> Overacting
overact --> Overactor
overact --> Overacted
overact --> Overactively

classDef root 1,fill:#FFCCCC,stroke:#333;
classDef suffix fill:#969,stroke:#333;
classDef prefix fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5
classDef header fill: #696,color: #fff,font-weight: bold,padding: 10px;

词根/词缀

1. 前缀和词根共同决定单词的意思；
2. 词性由后缀决定；

描述

flowchart TD

subgraph word-form
    direction TB
    col:::prefix
    labor:::front
    ate:::suffix
end

subgraph form
    direction TB
    前缀
    词根
    后缀
end

subgraph descption
    direction TB
    词义
    词性
end

subgraph word-explanation
    direction TB
    一起
    劳动
    动词
end

前缀 --> col
词根 --> labor
后缀 --> ate

col --> 一起:::prefix
labor --> 劳动:::front
ate --> 动词:::suffix

词义 --> 前缀
词性 --> 后缀


word-explanation --> collaborate:::back

classDef back fill:#969,stroke:#333;
classDef front 1,fill:#FFCCCC,stroke:#333;
classDef prefix fill:#90ee90,stroke:#333,stroke-width:4px;
classDef suffix fill:#ff6347,stroke:#333,stroke-width:4px;

前缀

Draw Diagrams in Markdown

I have always been a enthusiast for diagrams because I believe illustrations are a more direct and efficient way to elucidate the truths we want to explore. Meanwhile, I don't need a heavy diagraming tool like PowerPoint. I prefer to a lightweight, cross-platform,easy-to-using tool that can be seamlessly integerated with markdown, and here are several tools build for markdown that I find useful:

• js-sequence-diagrams
• flowchart.js
• mermaid

If you are interested in any one of these tools, just read the tutorial to get started on your journey.

Most Useful Diagrams in Mermaid

A Simple Conclusion for Ownership in Rust

Warm Up

What's my type?

Before we divi into the ownership, there is a essential problem we have to figure out beforehead: What's the type of the variable we just define? Considering the following code snippet:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

fn what_is_my_type() {
    let mut num0 = 0;

    let first_value: &mut i32 = &mut num0;
    println!("{first_value}");
    let second_value: &i32 = &mut num0;
    println!("{second_value}");

    let mut third_value: &mut i32 = &mut num0;
    println!("{third_value}");
    let mut fourth_value: &i32 = &mut num0;
    println!("{fourth_value}");

    let &mut fifth_value: &mut i32 = &mut num0;
    let &mut sixth_value = &mut num0;
}