蔓生庭院

memory consistency model

Sun, 06 Sep 2026 07:29:10 GMT

memory consistency model

memory models: the semantics of shared memory. WMM deals with ordering constraints, but is not just reordering.

Every hardware architecture has its own memory model. memory barrier (fence) can be used to enforce ordering constraints.

Sequential Consistency is the simpliest memory model.

Operational semantics

The operational semantics can be given in small steps semantics. The system is composed of a thread subsystem and a storage subsystem (effectively LTS).

The thread subsystem interpret the sequential program in each thread. It might take internal steps, which does not use memory (such as operation on registers, so ), or take a step that requires memory access $P, S \to^{i : l} P^{'}, S^{'}$ . (The access or fences are represented as labels l)

The memory model defines how the storage subsystem works. It describes the effect of memory access and fences. It might take internal steps as well.

The whole system either takes internal step of either subsystem, or take steps with matching labels.

Transclude of Classification-of-memory-consistency-model

concurrent termination analysis

Sun, 06 Sep 2026 07:29:10 GMT

背景

In concurrent event-driven programming, consider device drivers that provide event-handling services of independent threads, while communicating through shared memory. These device drivers are permitted by operating system to temporarily take over the execution of the threads in which the event occurred. A scenario could occur, where a loop in the code executed by the device driver could diverge when a relevant shared variable is modified by other threads in the same driver. Such scenarios could potentially cause denial of service, rendering the entire system unavailable. Hence, we see that non-terminating execution scenarios can greatly compromise the underlying computing environment’s reliability.

THREAD_STUCK_IN_DEVICE_DRIVER (stop code 0x100000ea)

研究内容

研究高效的并发程序终止性证明方法，能从实际安全攸关代码如驱动程序中寻找到可能的非终止问题。应用符号化方法应对并发程序的状态空间过大的问题。

技术方案

rely-guarantee条件的学习/重用
~~termination under WMM~~ compilation under WMM which preserves termination

Non-Volatile Memory

Sun, 06 Sep 2026 07:29:10 GMT

Non-Volatile Memory (NVM)

Specifically referred to Persistent Memory devices like Intel Optane DIMMs, not traditional storages.

What is Persistent Memory

Persistent Memory (PMEM), also referred to as Non-Volatile Memory (NVM), or Storage Class Memory (SCM), provides a new entry in the memory-storage hierarchy shown in Figure 2 that fills the performance/capacity gap.

持久内存可以像DRAM一样随机访问，同时拥有和传统硬件媲美的空间。一般可以通过和传统存储设备同样的IO接口进行访问，也可以把持久内存当成DRAM来使用，如此在传统架构上编写的程序可以正常在持久内存上运行；要发挥全部特性，则需要考虑PM的持久性，即需要用户确保持久内存上数据的一致性。由于系统产生各种意外中断的可能性，这就要求限制数据写回持久内存的顺序。

What does PM mean for application developers?

The introduction of a persistent memory tier offers application developers a choice of where to put data and data structures. Traditionally data was read and written to volatile memory and flushed to non-volatile persistent storage. When the application is started, data has to be read from storage into volatile memory before it can be accessed. Depending on the size of the working dataset, this can take seconds, minutes, or hours. With clever application design, developers and application architects can now take advantage of this new technology to improve performance and reduce application startup times.

Persistent Memory introduces some new programming concerns, which did not apply to traditional, volatile memory. These include:

Data Persistence:

Stores are not guaranteed to be persistent until flushed. Although this is also true for the decades-old memory-mapped file APIs (like mmap() and msync() on Linux), many programmers have not dealt with the need to flush to persistence for memory. Following the standard API (like msync() to flush changes to persistence) will work as expected. But more optimal flushing, where the application flushes stores from the CPU caches directly, instead of calling into the kernel, is also possible.
CPUs have out-of-order CPU execution and cache access/flushing. This means if two values are stored by the application, the order in which they become persistent may not be the order that the application wrote them.

Data Consistency:

8-byte stores are powerfail atomic on the x86 architecture — if a powerfail happens during an aligned, 8-byte store to PMEM, either the old 8-bytes or the new 8-bytes (not a combination of the two) will be found in that location after reboot.
Anything larger than 8-bytes on x86 is not powerfail atomic, so it is up to software to implement whatever transactions/logging/recovery is required for consistency. Note that this is specific to x86 — other hardware platforms may have different atomicity sizes (PMDK is designed so applications using it don’t have to worry about these details).

Memory Leaks:

Memory leaks to persistent storage are persistent. Rebooting the server doesn’t change the on-device contents. In the current volatile model, if an application leaks memory, restarting the application or system frees that memory.

Byte Level Access:

Application developers can read and write at the byte level according to the application requirements. The read/writes no longer need to be aligned or equal to storage block boundaries, eg: 512byte, 4KiB, or 8KiB. The storage doesn’t need to read an entire block to modify a few bytes, to then write that entire block back to persistent storage. Applications are free to read/write as much or as little as required. This improves performance and reduces memory footprint overheads.

Error Handling:

Applications may need to detect and handle hardware errors directly. Since applications have direct access to the persistent memory media, any errors will be returned back to the application as memory errors.

Characteristics

Persistent
Byte-addressable
Low latency
High capacity

Challenge

Programmers must ensure the Crash Consistency of their programs (a.k.a crash safety). This is because NVM hardwares usually have weak persistency semantics (due to presence of cache). Certain operations (e.g. flush and fence) can be used to constrain the persist order, but require a lot of knowledge and is expensive.

Note providing Strict Persistency solves the problem (‘Cause any post-crash state is a valid volatile state), like Intel eADR, but this is hard in reality.

Semantics models of NVM weak persistency behavious include

Px86, with formalized semantics of Intel-x86 persistency (two variants): Persistency semantics of the Intel-x86 architecture
DPTSO, a varaint of Px86 with synchronous flushes: Taming x86-TSO persistency

Visibility and Persistency

Visibility and persistence are often not the same thing, and changes made to persistent memory are often visible to other running threads in the system before they are persistent.

Data Visibility由架构的Memory Model决定。类似的，Persistency的顺序由Persistency Model决定。

Persistency Model for Intel-X86:

A. Raad, J. Wickerson, G. Neiger, and V. Vafeiadis, ‘Persistency semantics of the Intel-x86 architecture’, Proc. ACM Program. Lang., vol. 4, no. POPL, p. 11:1-11:31, Jan. 2020, doi: 10.1145/3371079. Persistency semantics of the Intel-x86 architecture
A. Khyzha and O. Lahav, ‘Taming x86-TSO persistency’, Proc. ACM Program. Lang., vol. 5, no. POPL, pp. 1–29, Jan. 2021, doi: 10.1145/3434328. Taming x86-TSO persistency

Persistency Model for ARMv8:

A. Raad, J. Wickerson, and V. Vafeiadis, ‘Weak persistency semantics from the ground up: formalising the persistency semantics of ARMv8 and transactional models’, Proc. ACM Program. Lang., vol. 3, no. OOPSLA, p. 135:1-135:27, Oct. 2019, doi: 10.1145/3360561.

Relevant Works

2023

Memento: A Framework for Detectable Recoverability in Persistent Memory (PLDI)
Mumak: Efficient and Black-Box Bug Detection for Persistent Memory (EuroSys)
Spirea: A Mechanized Concurrent Separation Logic for Weak Persistent Memory (OOPSLA, distinguised)

2024

Discovering Likely Program Invariants for Persistent Memory (ASE)

喀耳刻

Sun, 06 Sep 2026 00:00:00 GMT

如果按照女性主义的视角，喀耳刻在本书中是站在父权的对立面，后者主要是以希腊诸神和奥德修斯这样的凡人为代表的。从一开始和普罗米修斯的相识就能看出，喀耳刻对于凡人的态度不一样。她会认罪、为自己的过失感到愧疚，为自己的儿子担惊受怕等等。总体上来说，这是一个虽然有巫术，但其实相当接近凡人的角色。

当然，本书在宣传的时候强调这是希腊神话在现代女性主义下的重写。这更像是一种营销的口号而非事实。本书描写了一个活生生的人，而这个人恰好是个女人。这里面带有典型女性主义特征的地方其实并不多。事实上，把它看作一本写得不错的奇幻小说就可以了。

欢迎来龙餐馆

Sun, 30 Aug 2026 00:00:00 GMT

一部以中国人的旁观视角的反战题材电影，沈腾一反刻板影响，出演了徐福这一并不特别搞笑的角色。整体的节奏很好，拍摄技法也很到位，结尾也留出了悬念，总体是一部不可多得的好电影。

缓存一致性与内存模型的关系

Fri, 21 Aug 2026 00:00:00 GMT

根据cache coherence与memory consistency model之间的关系，可以分为两大类：

Consistency-agnostic coherence：此类缓存一致性是同步实现的，此时，缓存仿佛在内存层级中不存在，对程序和程序员完全透明，内存系统可以被当作是原子的。在此类情况下，memory consistency model通过处理器的微架构实现。
Consistency-directed coherence：缓存一致性是异步实现的，因此可能会出现过时的数据被读取的情况。此时，缓存一致性协议和处理器一同实现内存模型。这种协议主要出现在异构系统中，如GPU。（SC和TSO都可以实现）

This definition highlights an important distinction between coherence and consistency in the literature: coherence is specified on a per-memory location basis, whereas consistency is specified with respect to all memory locations. A Primer on Memory Consistency and Cache Coherence

Memory Hierarchy

Fri, 21 Aug 2026 00:00:00 GMT

理想情况下,我们希望拥有无限大的存储容量,这样就可以立刻访问任何一个特定的机器字…但我们 … 必须认识到构建一个存储器层次结构的可能性,其中每一层次的容量都比前一层次大,但访问速度却比前一层次慢。 A. W. Burks、H. H. Goldstine 及 J. von Neumann, Preliminary Discussion of the Logical Design of an Electronic Computing Instrument ( 1946 )

利用局部性原理设计的存储器结构。

“In most cases (but not all) the data contained in a lower level are a superset of the next higher level. This property, called the inclusion property, is usually maintained by the main memory in the case of caches and by secondary storage (disk or Flash) in the case of virtual memory.”

“Virtually all computers since 1975 have used DRAMs for main memory and SRAMs for cache, with one to three levels integrated onto the processor chip with the CPU. Today, all PMDs and laptops and most desktops use Flash rather than disk drives. Many servers use Flash in combination with disk drives.”

Computer Architecture: A Quantitative Approach

Fri, 21 Aug 2026 00:00:00 GMT

Computer Architecture: A Quantitative Approach

Cite

John L. Hennessy, David A. Patterson, and Christos Kozyrakis. 2026. Computer Architecture: A Quantitative Approach (7th ed.). Morgan Kaufmann Publischers an imprint of Elsevier, San Francisco.

Attachments

Collections

A 计算机科学/1 系统结构

Annotations

The late 1970s saw the emergence of the microprocessor.

two significant changes in the computer marketplace made it easier than ever to succeed commercially with a new architecture. First, the virtual elimination of assembly language programming reduced the need for object-code compatibility. Second, the creation of standardized, vendor-independent operating systems, such as UNIX and its clone, Linux, lowered the cost and risk of bringing out a new architecture.

Intel rose to the challenge, primarily by translating 80x86 instructions into RISC-like instructions internally, allowing it to adopt many of the innovations first pioneered in the RISC designs.

In 1974, Robert Dennard observed that power density was constant for a given area of silicon even as you increased the number of transistors because of smaller dimensions of each transistor.

This change forced the microprocessor industry to use multiple efficient processors or cores instead of a single inefficient processor.

Whereas the compiler and hardware conspire to exploit ILP implicitly without the programmer’s attention, DLP, TLP, and RLP are explicitly parallel, requiring the restructuring of the application so that it can exploit explicit parallelism. In some instances this is easy; in many it is a major new burden for programmers.

The only path left to improve energy-performance-cost significantly is specialization. Future microprocessors will include several domain-specific cores that perform only one class of computations well, but they do so remarkably better than general-purpose cores.

ome are investigating alternatives that have not yet had significant commercial impact, e.g., analog, biological, quantum, neuromorphic, or asynchronous computing.

Although the range of computing power in the embedded computing market is very large, price is a key factor in the design of computers for this space. Performance requirements do exist, of course, but the primary goal often meets the performance need at a minimum price rather than achieving more performance at a higher price.

Energy and size requirements lead to the use of Flash memory for storage (Chapter 2) instead of magnetic disks.

We use the ability to run third-party software as the dividing line between nonembedded and embedded computers.

the cost target for servers is total cost of ownership (TCO) rather than purchase price. TCO is the purchase price plus the cost of operation over the lifetime of the computer, which includes the cost of electricity, cooling, maintenance, and space.

the purchase price of the server processor can be a quarter of the total TCO.

Clusters are collections of typically inexpensive servers connected by local area networks to act as a single larger computer. Each node runs its own operating system, and nodes communicate using a networking protocol.

Single instruction stream, single data stream (SISD)dThis category is the uniprocessor. The programmer thinks of it as the standard sequential computer, but it can exploit ILP.

Single instruction stream, multiple data streams (SIMD)dThe same instruction is executed by multiple processors using different data streams.

In the early SIMD computers each processor had its own data memory (hence the MD of SIMD), but there is a single instruction memory and control processor, which fetches and dispatches instructions. (Recent SIMD computers fetch multiple data items at a time from a single shared memory.)

Multiple instruction streams, single data stream (MISD)dNo successful commercial multiprocessor of this type has been built to date, but it rounds out this simple classification

Multiple instruction streams, multiple data streams (MIMD)dEach processor fetches its own instructions and operates on its own data,

The architect’s or designer’s job is much more than instruction set design, and the technical hurdles in the other aspects of the project are likely more challenging than those encountered in instruction set design.

There are two basic choices for encoding: fixed length and variable length.

All ARMv8 and RISC-V instructions are 32 bits long, which simplifies instruction decoding.

The x86 encoding is variable length, 1 to 18 bytes. Variable-length instructions can take less space than fixed-length instructions, so a program compiled for the x86 is usually smaller than the same program compiled for RISC-V.

ISA

Thu, 20 Aug 2026 00:00:00 GMT

软件与硬件之间的分野，可见于开发者的编程界面

Classification

如今几乎所有指令集架构都被归类为通用寄存器架构，其中操作数要么是寄存器，要么是内存地址。

register-memory ISA, such as the x86: access memory as part of many instructions
load-store ISA, such as ARMv8 and RISC-V: access memory only with load or store instructions. All ISAs announced since 1985 are load-store.

寻址

几乎所有ISA（包括x86、ARMv8和RISC-V）都使用字节寻址来访问内存操作数。某些架构（如ARMv8）要求对象必须对齐。x86 和 RISC-V 不要求对齐，但如果操作数对齐，访问通常更快。

编码

编码有两种基本选择：固定长度和可变长度。x86 采用可变长度编码，RISC-V 和 ARM 为固定长度。

The History of FORTRAN

Sun, 16 Aug 2026 00:00:00 GMT

FORTRAN was the world’s first high-level programming language. It was developed at IBM by a small team led by John Backus. The earliest version of FORTRAN was released in 1957 as a programming tool for the IBM 704. Fifty years later, FORTRAN remains the programming language of choice for large-scale numerical calculations in science and engineering.

Before FORTRAN

Programs for the earliest computers consisted of sequences of numerical codes. Each code represented a basic operation such as ‘fetch a number from memory location X and put it in register A’ or ‘add the number in register A to the number in register B’. This style of programming was time-consuming and error-prone. Mistakes were difficult to find.

By the time John Backus joined IBM as a scientific programmer in 1950, it had become possible to write programs using mnemomics such as ADD in place of the numerical codes. A special program (which we would call an assembler today) converted the mnemonics into the corresponding numerical codes. This made programming a little easier, but even a simple program required dozens of operations, and it was still difficult to track down mistakes.

Backus reasoned that it should be possible to create a programming language which allowed a series of calculations to be expressed in something resembling mathematical notation. A translation program (a compiler, in today’s terminology) would then convert it into the numerical codes which the computer understood. Backus proposed this idea to his manager in 1953. He was given a budget and encouraged to hire a small team to test the feasibility of the notion.

Three years later, the team published a manual which described the IBM Mathematical Formula Translating System, or FORTRAN for short. Soon after, IBM made the first FORTRAN compiler available to users of the IBM 704.

Backus and his team had created the world’d first high-level programming language. Scientists and engineers would no longer have to write their programs as numerical codes or long-winded mnemonics.

Significantly, Backus’s team had implemented the first optimizing compiler, which not only translated FORTRAN programs into the IBM 704’s numerical codes, but produced codes which ran very nearly as fast as anything that could be crafted by hand.

This was very important in ensuring the success of FORTRAN. Early computers were very slow by today’s standards, and they represented an expensive commodity to their owners. Inefficient programs wasted time and money. Backus and his team understood this, and they knew that they had to confound their critics who said that a program compiled from a high-level language could never be as efficient as one that was hand-crafted directly using numerical codes or mnemonics.

The Early Years

In 1958, IBM released a revised version of the language, named FORTRAN II. It provided support for procedural programming by introducing statements which allowed programmers to create subroutines and functions, thereby encouraging the re-use of code.

FORTRAN’s growing popularity led many computer manufacturers to implement versions of it for their own machines. Each manufacturer added its own customisations, making it impossible to guarantee that a program written for one type of machine would compile and run on a different type. IBM responded by removing all machine-dependent features from its version of the language. The result, released in 1961, was called FORTRAN IV.

FORTRAN 66

By the early 1960s, there was growing pressure to create a standardised version of FORTRAN which was not tied to any single type of computer. In 1962, the American Standards Association (the precursor of ANSI, the American National Standards Institute) convened a committee to pursue this goal. The result, published in 1966, was a document which defined the language which became known as FORTRAN 66.

FORTRAN 66 marked a significant milestone in computer science. It was the first programming language to be defined by a formal standard.

FORTRAN 77

Within only a few years, the shortcomings of FORTRAN 66 began to become apparent, especially by comparison with other programming languages such as C, Pascal and Algol. Computer manufacturers again added customisations to the language to try to address some of these faults.

This forced the ANSI FORTRAN standards committee, known as X3J3, to start work on a new version of the language in 1969. The resulting standard would take eight years to reach maturity, but the language it defined, known as FORTRAN 77, represented a major enhancement. Among the features which it added were a true block IF statement, a CHARACTER data type, direct-access I/O and the PARAMETER statement to define constants.

FORTRAN 77 became the became the most widely-used version of the language, and it is likely that much of the legacy FORTRAN code around the world is written in this dialect of the language.

FORTRAN 90

FORTRAN 77 faced competition from languages such as C, which allowed programmers to allocate memory dynamically and to define heterogeneous data structures. FORTRAN 77 could do neither of these things. The next version of FORTRAN to emerge from the ANSI X3J3 committee was designed to address these deficiencies. It was tentatively named FORTRAN 8X but by the late 1980s, the committee did not appear to be close to releasing the new standard, and there was a popular joke among computer scientists that ‘X’ would need to be a hexadecimal digit.

The new version of FORTRAN was finally published as a standard by the International Standards Organisation in 1991, and it became known informally as FORTRAN 90.

奥德赛

Fri, 14 Aug 2026 00:00:00 GMT

诺兰导演，改编自希腊史诗。叙事结构相比原著有调整，也改了一些设定。

不讨论古典学和场外争议，其实是不错的电影。最直接想表达的意涵显然是反战的，奥德修斯颇有一种战后PTSD老兵的形象。

Logical Foundations of Example-Driven Specification

Fri, 22 May 2026 00:00:00 GMT

Conjunctive Queries and LTL

Balder ten Cate

Database Query

Fitting problem: given a set of labeled samples, construct a conjunctive query

sample: the answer tuple

conjunctive query: FOL using only existential quantifier and conjunction; Capture the select-project-join queries in SQL

Most-specific fitting CQ

所有满足约束的CQ（对子集关系）组成凸集。如果满足约束的CQ存在，则一定有极点。（PODS23）

Query Repair

Given an existing query that does not hold, find the ‘closest’ that fits the constraints.

different interpretation of ‘closeness’

LTL

Generate a ‘good’ set of examples for a given LTL formula.

Full LTL can’t be uniquely characterized by finite examples

Fragment: LTL with future and no negation

Every formula in this fragment can be uniquely represented by a finite set of transfinite traces, or a finite set of labeled schematic examples.

schematic examples: union-free regular expression over B(AP), the Boolean combination of some atomic propositions.

The proof is straightforward : for finite traces, LTL language is regular, which is equivalent to a union of the language of a union-free regular expression.

Theory and applications of Craig Interpolation

Making a Splash

Tue, 12 May 2026 00:00:00 GMT

To splash, or not to splash in your Draft deck? That is the question.

This is a question that can topple 40-card empires, cause massive deck-building consternation, and be the thin line between victory and defeat.

I’ve reaped the benefits of splashing many times. I’ve also definitely splashed when I shouldn’t have, and errantly left a splash out when I should have put it in. I’d guess that, at some point or another, the same may have been true for you, loyal reader.

Splashing is always so tempting—and it’s important to know when to go for it or have enough discipline to stay the course.

So then, shall we take a look at the art of the splash today?

Bounty of the Luxa | Art by Jonas De Ro

Okay, first, I think it’s important to clarify what exactly a “splash” is when it comes to Limited gameplay.

It’s simple: a splash is when you’re touching just a smidge of a color to play a couple cards of that color. Generally, I’d say it’s something like you’re playing just one to three cards of that color. Usually, in a Limited deck, you’ll be two colors, and when you splash, you splash your third. There are exceptions, sure—I’ve played my fair amount of four- or five-color crazy splashes—but that’s a good way to think about it.

So, for example, you might have drafted green-blue, splashing red for some removal spells. Maybe your deck is something like 21 green and blue cards and two red cards. That’s a splash.

If it was something more like eight green cards, eight blue cards, and six red cards, then I’d be more inclined to say you’re a three-color deck and less of a splash. Generally, splashes are just for a couple cards. This is partially an issue of nomenclature, but it will also help make sure we’re on the same page the whole way through.

As a rule of thumb, I recommend playing about three sources of a given color if I’m going to splash it. This can go up and down depending on the cards you’re splashing. Sometimes it can be two if you’re just splashing one card or you really need the colored mana elsewhere. But three is a good place to start.

So, if I was splashing two red cards, to be safe, I’d try and play at least three Mountains, two Mountains and anEvolving Wilds

, or any combination of cards that gets me to three ways to find my red mana in a pinch. (And generally, I am reticent to splash in the first place without any sort of color fixing.)

Okay. So, now that we’ve established what a splash is, when should you do it? Why would you want to do it?

Let’s cover five dos and don’ts when it comes to splashing.

1. Do Not Splash Cards You Want to Cast Early

Generally, you’re going to be casting any given splash card later in the game rather than earlier. If you’re only playing three Mountains for your red splash, then you not only have to draw the card you want to cast, but you also have to draw a Mountain to help you cast it in the first place!

Some cards fall into poor categories for splashing. For example, creatures you want to cast in the early game are poor choices to splash. By the time you can cast them, the game will likely be in a spot where splashing them wasn’t worth it. Splashing mana fixing or acceleration is an easy trap to fall into when trying to build a three-color deck, but putting the fixing or acceleration into the color you need to fix for in the first place doesn’t actually help you out much!

This isn’t to say that you don’t want to splash cards that are cheap to cast. There can be cheap cards that will still have a large impact. But often this means more along the lines of spells, such as removal, which can be excellent to splash. Something likeGlory-Bound Initiate

, however, loses a bit of its luster on turn ten.

And speaking of splashing removal…

2. Do Splash What Covers Your Weaknesses and Adds Power

A main goal of a splash should be to cover your deck’s weaknesses. (Heeding the first point in mind, of course; you shouldn’t generally go splashing cheap creatures even if early plays are your weakness.)

Most of the time, I would say that this boils down to removal or incredibly powerful “bomb” cards.

Removal spells are key to Limited gameplay. Your ability to kill off your opponent’s creatures and nullify some of their strongest cards is going to be a big factor in most decks’ ability to win or lose.

Splashing removal is also a pretty safe bet. When it comes to cards that are good in the long game (which is where your splashes generally come online), removal spells are great to have around. They’re excellent in any kind of attrition battle and help ensure you have the last creature standing.

While not truly a “weakness,” your deck can always use more powerful bomb rares or uncommons you may have opened. Splashing powerful cards can be worth it if the impact of the card is high enough and you have the means to do it.

Finally, another kind of card I tend to splash sometimes are big creatures. Sometimes, I’ll be playing a slower deck that just needs a way to win. It doesn’t need to be the most efficient way to win—but an extra copy of an expensive flier or huge ground creature can be a good way to close out the game.

Think about what your deck needs and see if your splashes can help cover it.

3. Do Not Ignore Colored Mana Requirements

So you have aGlorybringer

, right? Big awesome Dragon, super powerful rare. You definitely want to splash that, right?

Not so fast.

It can be so tempting to try to get that powerful rare in there. However, there is a limit to the strain you can put on your mana base to try and accommodate for something. And generally, if you want to splash something that has two off-color mana symbols (such as 3RR if you’re playing green-blue) in its mana cost, you’re crossing the line.

There is a tremendous difference between having to find one of a certain color and having to find a second of that color. And unless your deck is really well equipped on mana fixing, this is a splash most often left on the sidelines.

Let’s say you’re playing three red sources as your baseline to castGlorybringer

. You will need to draw two of them plus[

Glorybringer

](https://gatherer.wizards.com/Pages/Card/Details.aspx?name=Glorybringer)over the course of the game to make it relevant. And you could add more sources, but it’s important to keep in mind that the cost is much larger than just “Can I cast this[

Glorybringer

](https://gatherer.wizards.com/Pages/Card/Details.aspx?name=Glorybringer)or not?”—you are also impacting your mana base on the whole. What about the games where you draw a Mountain instead of the Island you need to cast most of the cards in your deck? Those are the ways splashing can start to crunch you.

If you’re already splashing red, you could maybe start to think about finding a way to fit thatGlorybringer

in. But splashing just for it is likely to make your deck weaker on the whole, thanks to your destabilizing mana base.

Now, Amonkhet is a little different than normal in this respect because it does contain a way to pitch away your extra cards: cycling!

Archfiend makes a much better splash. If you ever get to the two black mana needed to cast it, that’s great—but it’s also not going to rot away in your hand since you can always cycle it. I’d be happy to play the Archfiend in my black-splash deck, whereas I’d be a lot more skeptical about theGlorybringer

in a deck with a red splash.

But even then, I wouldn’t splash just for the Archfiend. If I was already playing some black sources for removal and had access to the Archfiend, sure. But splashing just for a double-colored card is something I’d advise against.

4. Do Think About your Splashes During the Draft

If you get to the deck building portion of your draft and you’re not sure if you can splash or not, then it might already be too late.

To try to make your splashes work, you really want to be actively thinking about them during the draft. If I picked a powerful rare, but I moved out of the colors to play it, I’ll keep my eyes open for anything that may help me put it into my deck. For example, a dual land such asSheltered Thicket

could help make the red splash in my green-blue deck happen. Prioritizing[

Spring // Mind

](https://gatherer.wizards.com/Pages/Card/Details.aspx?name=Spring+%2F%2F+Mind)a little bit higher can be the difference between splashing or not.

While maybe there’s another, stronger card in the pack than the mana fixing, if taking the fixing lets you play a couple awesome splash cards, then what you’re really comparing is those awesome splash cards to the other card you could take here. And that’s when you have to ask yourself: which would you choose?

5. Do Not Splash in Decks That Don’t Want Splashes

Finally, think about your deck. Does it want that splash? Does it need that splash? Can it make use of that splash?

A typical example of something I’d warn against is splashing in an aggressive deck. Splashes are best if the game goes long, so unless you have something incredibly powerful or access to very good mana fixing, I generally would lean against splashing in your aggressive Limited deck. Plus, destabilizing your mana can be especially brutal to aggressive decks, since you need to hit your creatures on curve.

But it goes further than that. Sometimes, your deck is just in good shape without that splash you’re considering. If you’re taking out two good cards of another color to make room for two slightly better cards in a splash, you may just be hurting your mana base more than you’re actually helping your deck.

If I’m thinking about splashing at the end of the draft, I’ll always build two versions of my deck: one with the splash, and one without it. Then, compare them. How strong is the splash? Does your deck need the help? Looking at both versions side by side can help answer this question.

And keep in mind, you can always sideboard in and out of a splash! If you’re playing against a quick beatdown deck and don’t have the time to worry about mana problems, sideboard it out. If your game is going to go long and you want more strong threats, bring it in. Sideboarding in Limited is generally underused and a great place to help adjust your splash to match what your opponent is throwing at you.

Splash Attack

A good splash can let you play cards when you otherwise never would have. A bad one can cost you the draft. Hopefully, armed with this information, you can go out and make more informed splashing decisions.

When in doubt, I generally recommend not splashing. I’ve seen plenty of drafts derailed by mana destabilization of a splash a player was on the edge about. If your deck works fine without it, you can usually consider leaving it in the board.

On the other hand, if your mana base is really good with multiple pieces of mana fixing and the splash is nearly free, then I’d be a lot more willing to go for it. In the end, look at your deck and see what looks right for this particular draft.

And where to test this all out? Well, you’re just in time to go draft some Amonkhet! With plenty of opportunities to draft this week, now is a good time to put this into practice. Go forth and splash!

Do you have any thoughts or feedback? I’d love to hear from you! Reaching me is easy: you can always find me on my Twitter, Tumblr, or, alternatively, by sending me an e-mail (in English, please) at BeyondBasicsMagic@gmail.com.

I’ll be back next week with more Beyond the Basics. Enjoy drafting this week, and I’ll talk with you again then!

Gavin
@GavinVerhey
GavInsight

Dependent Function

Thu, 07 May 2026 00:00:00 GMT

A function where the type of its return value is dependent on the value of its argument. That is, the co-domain is not fixed.

Dependent Function Type ( $Π$ -Type)

The type of a dependent function can be described with this notation:

Π_{x \in A} B (x)

If B is a constant function, then this type is reduced to ordinary function type $A \to B$

Dependent Type Theory

Evaluating Combat Tricks In Limited

Tue, 05 May 2026 00:00:00 GMT

What he said was that, because the format has a lot of creatures with high toughness relative to their power, blocking is good, and combat tricks are worse. I argued that the opposite is true, that because creatures have higher toughness, combat tricks are better than they would otherwise be.

I stand by my position here, but his point isn’t exactly wrong; it was just missing a step. Regardless, I think unpacking both positions, as well as discussing evaluations and uses of combat tricks in Limited, is a worthwhile topic. This is especially true for players who mostly know Constructed, as combat tricks are rare there (and mostly used for combo kills), so it can be easy to not build a lot of experience evaluating the nuances of building with, playing with, and evaluating tricks from a Constructed perspective.

At the most basic level, a combat trick is something of a split card that can function as a removal spell or a protection spell (or direct damage spell, I suppose). You’ll usually get a good rate (they don’t tend to cost much mana), but the situations where you can use it to do what you want are somewhat more rare or require some work to engineer.

Combat tricks are generally better in aggressive decks than controlling decks because aggressive decks tend to have cheaper creatures, which are smaller, which attack into larger creatures. When the opponent blocks, the trick allows you to kill the larger creature for much less mana than the larger creature cost (ideally while also pushing damage because other creatures were able to get through unblocked, as having the trick allowed you to attack with all of your creatures).

The larger you creatures are, the less they need tricks to win in combat. Also, it’s much better to play a trick on your turn than on your opponent’s turn. In order to use a trick on your opponent’s turn, you must leave mana unspent to have the option, and then if they don’t play into it, you may not get the opportunity to profitably spend the mana. Also, if you use a trick on your opponent’s turn, it’s very likely that their mana will be untapped, which means they’ll be able to cast any tricks or removal spells of their own, which makes trying to use your trick much more of a gamble.

This is the heart of Ben’s argument. If blocking is good, combat tricks are bad. That sentence isn’t accurate; if blocking is good, combat tricks are good, because the scenario where you want to use them will come up more. What Ben really meant was, “If blocking is good enough that you want to plan to block rather than attack, combat tricks are bad.”

Combat tricks will generally perform best in aggressive decks, and if all the aggressive decks are bad, combat tricks will also be bad. However, if blocking is good, combat tricks will be the best way to draft an aggressive deck that can beat a deck that is trying to block, which was the heart of my argument.

I would unpack this evaluation a little differently. The more good removal there is, the worse combat tricks are, and the more decks there are that don’t rely on combat, the worse combat tricks are. In Shadows over Innistrad, the fact that your opponent might be playing a U/R Rise from the Tides deck makes combat tricks less likely, as there will be some matches where you’ll have trouble finding a profitable spot to use one. This, analogously, is why combat tricks aren’t played in Constructed. Too many decks don’t rely on creature combat or perhaps don’t play creatures at all. Removal, especially efficient, instant-speed removal, is far more common.

If control decks are good, they usually won’t want tricks, which means aggressive decks can get them easily. If control decks are so good that aggressive decks are bad, tricks will usually be pretty bad, but most tricks are actually best when aggressive decks and control decks that play larger creatures and try to block are both good. If only aggressive decks are good, tricks aren’t generally that great, because you’re never getting the highest payoff, killing a large blocker.

Details matter, and not all tricks are created the same.

First, not all tricks just increase power and toughness, and different keywords are clearly differently suited to different strategies.

Deathtouch is at its best in a deck that’s trying to block with small creatures. Large creatures don’t need deathtouch, and giving it to an attacker isn’t great because you’ll usually lose your creature, which isn’t productive, and a trick that gives deathtouch isn’t going to give much power, so it won’t be effective as a “burn” spell to end the game. Tricks that give deathtouch are basically “tempo” cards for control decks; they let you play two spells a turn and kill an attacker. They also work well on defense because they’re good “counter-tricks.” If your opponent plays a trick and you answer with this, you negate their edge at worst and maybe also save your creature, depending on the card.

Regeneration, protection, and indestructibility are best in decks with large creatures, unlike most tricks. This is fairly simple: the larger investment you make in a single creature, the most valuable it is to protect it. This is even more important in decks with Auras, as the investment is even larger.

Tricks that untap a creature are interesting to place. Such spells are best cast on your opponent’s turn to create a surprise blocker. This means the trick will be used defensively, but you’re only getting to do that if your creature is already tapped, which means you probably needed to be attacking. These tricks are best in aggressive decks against other aggressive decks, especially if your aggressive deck has evasive creatures, as you had to be able to attack without telegraphing the trick and then have them attack into it after leaving it up for the maximum benefit.

First strike is best on offense because it’s generally extremely vulnerable to a counter-trick, which means you really want to play it when the opponent is tapped out. Also, if you’re aggressive, it’s more likely you have creatures with high power and low toughness, where first strike is best.

Flying is tricky; while granting reach (as in the mechanic) is obviously best in a control deck, granting the other kind of reach (as in the ability to kill an opponent who has established control of the battlefield) is best in an aggressive deck. In both cases, evaluating this is going to depend on the needs of your deck, and obviously, in both cases, it will be best when your creatures don’t already have flying, not only because it’s redundant on a creature that already has it but because you’ll have less need for it in a single instant.

Sizing of pump spells also matters and needs to be evaluated in the context of a set specifically. As a simplified example, if most of the good common two-drops are 2/1 and the good three drops are 3/2, an instant that gives a creature +1/+1 will be very weak; its only effect among those creatures will to be save the three-mana creature from the two mana creature. If, on the other hand, good two-drops are 2/2 and good three-drops are 2/3, a trick that gives +1/+1 will be relatively strong, allowing any creature to kill another other creature and live.

This principle is why, in general, power/toughness tricks are better in formats that have more toughness than power and worse in formats that have more power than toughness; clearly, the reverse is true of tricks that grant first strike or protection.

Also, the more similar creatures are in size, the better pump spells that only give small bonuses are. In a set with Eldrazi, where one player is likely to have 2/2s and the other 8/8s, Giant Growth is a horrible card. In a set where the biggest creatures you can find are around 4/4, like the original Mirrodin, Giant Growth is at its best (and, in fact, I think Predator’s Strike is the best green common in that set, while it wouldn’t be in most sets).

It’s good to develop a sense of how good pump spells generally are in a format, but honestly, it’s not that important how good they are in general. Because they’re very rarely extremely early picks, you’ll almost always be evaluating them in the context of a deck whose needs and creatures you know something about.

Where I think most players are giving up the most value is in sideboarding with combat tricks. Sideboarding is generally not a topic that gets enough attention, and Limited doesn’t get much attention these days. When people do talk about sideboarding, it’s usually a sideboarding guide for Constructed, and when they talk about Limited, it’s usually card evaluation. Combat tricks are among the most common and important cards to sideboard in or out.

First, consider siding out any combat trick your opponent has seen. This doesn’t mean you should always cut them, because how they’re positioned in the matchup is definitely more important than “have they seen it?”, but you’ll get some value from their knowledge of it without having it in your deck, as they’ll play around it, and it’ll be harder to use well for the same reason.

More importantly, after playing a game, you’ll have a lot more information about creature sizing. Rather than trying to know the set well enough to find generalities about how big creatures are relative to each other, you can write down the size of all the creatures your opponent plays, look at the size of all the creatures in your deck, and then look at how often a particular combat trick will make one of your smaller creatures beat one of their larger creatures. You might realize that your aggressive white deck full of 2/2s doesn’t want a +2/+2 trick against a green deck with mana creatures and 6/5s but that the same trick great against a U/B defensive deck with a lot of 3/3s and 2/4s.

Obviously, don’t just consider combat tricks in your maindeck; also consider how any in your sideboard would impact likely combat steps, and don’t just consider combat. If your opponent has a lot of removal spells that care about the size of your creatures, think about how effective your tricks would be at saving them and how likely the game is to play out in a way where you can have mana to cast them at the right time. If your opponent has Lightning Strike, Giant Growth might not actually be good at saving your Hill Giant because they’ll just kill it on turn 4, but if they have Burn Trail, it will be good at protecting your Grizzly Bears because you’ll have untapped before they have enough mana to cast it. (Why you care about protecting your Grizzly Bears is a separate, and relevant, question.)

Also, there are certain spots where tricks can change value relative to their expectations in other ways. For example, if you have a large creature and you know your opponent’s only way to deal with it is to block it with multiple creatures, a trick that saves it will be outstanding, even though tricks are generally not good with large creatures (as blocking with several creatures isn’t generally the most common way to deal with them).

Clearly, this is about fundamentals, ideas that can be applied to any Limited format. I hope this has improved your ability to ask the right questions and consider the right issues when evaluating inclusion of combat tricks in Limited. As Wizards of the Coast has been finding ways to spread them throughout all the colors at common, and various ways to push their power level, this skill is becoming even more important.

®Atlanta Open Weekend June 4-5!” border=”1″ />

Who's The Beatdown?

Tue, 05 May 2026 00:00:00 GMT

Editor’s Note: A long time ago, the first Magic website was The Dojo – a site that is still legendary for publishing some of the most fundamental principles of Magic. Almost all strategical theory can be traced back to the Dojo’s loyal writers, and any serious Magic player owes these old vets a debt of gratitude.

Unfortunately, thanks to financial troubles, The Dojo went out of business in 2000. In a last-ditch effort to save the four years of wisdom that had been collected there at the time, the editor asked the community to archive the articles for future reference. The best of the Dojo articles are reprinted here because they’re still vital to Magic today… merely reprints them, adding links to clarify older cards that new players probably won’t have seen so that they can understand some of the strategy. Many of the Dojo’s writers are still active in Magic and write for other sites; give them a shout-out for helping the community grow.

Who’s The Beatdown?

The most common (yet subtle, yet disastrous) mistake I see in tournament Magic is the misassignment of who is the beatdown deck and who is the control deck in a similar deck vs. similar deck matchup. The player who misassigns himself is inevitably the loser.

You see, in similar deck vs. similar deck matchups, unless the decks are really symmetrical (i.e. the true Mirror match), one deck has to play the role of beatdown, and the other deck has to play the role of control. This can be a very serious dilemma, if, say, both are playing aggressive decks.

Let me give you an example: At a 1.x PTQ in Washington D. C., my teammate Al Tran was playing for a top 8 slot vs. Sligh. Al was playing Lan D. Ho’s White weenie/Jank deck, normally an aggressive deck… But not vs. Sligh.

The match was split 1-1, and the third game was going to determine who made top 8.

Al’s opponent went first and laid a Jackal Pup. At this point, Al had two Cursed Scrolls, two Swords to Plowshares, an Honorable Passage, and some land in hand. Al chose not to Plow the Jackal Pup, taking 2 on the first attack.

His opponent played another Pup. Al didn’t Plow either, waiting on Scroll mana or a Lightning Bolt.

On his own second turn, Al played another land and a Cursed Scroll, so he only had one land up.

On his opponent’s third turn, you guessed it, another Mountain came down, followed by Ball Lightning. Al was forced to Plow the Ball. He gained control over the next few turns, but ended up dying to Bolts.

What was the problem here? Al was a beatdown deck, and he wanted to deal damage to his opponent via the Jackal Pups. However, in this particular matchup, he had to play the control deck. You see, Sligh is just much faster than Jank, so Jank’s way to win has to be stifling Sligh’s early speed with removal, and then locking down the midgame with Cursed Scrolls. Because Sligh also has Cursed Scrolls, as well as more Bolts than Jank, the only way that Jank can win is to make sure it has a decent life total as it plays its own threat cards.

Though it ostensibly hurts the initial race to give the Sligh player four additional life from the Jackal Pups, you can see from this example that Al had to give him six more life from the Ball Lightning … And still took at least eight from the Pups before he could control them. It would have profited Al much more to Plow the Pups, Passage the Ball, and enter the midgame with twenty life as he started to threaten with his own Paladins, Priests, etc.

The same comparison can be made when two control-based decks slug it out. At the same PTQ, I was playing High Tide against what is normally a dangerous matchup for me, CounterSliver. My opponent was running the usual array of Slivers, Worship, and permission, as well as Cursed Scroll. He made the mistake of thinking he was the control deck.

After playing a turn-2 Crystalline Sliver, he followed up two turns later with Worship, so I Stroked him out. (I killed him the first game with Palinchron, and because I mostly showed him some Disrupts, Force Spikes, and card drawing, he may have thought I was more creature heavy).

It doesn’t matter… He thought he was the control deck in this matchup when clearly I was the control deck. I had a comparable or greater amount of permission, but where he had Slivers, I had card drawing and deck manipulation; where he had dual lands, I had Thawing Glaciers. My Thaws were going to insure that I never missed a land drop. I had already housed a couple of his Brainstorms with Disrupt. This means that I was going to win the long game every single time.

His job, therefore, was to kill me before I killed him. The normal formula is to play some decent-sized Slivers (two power or more) attacking every turn and leaving mana open to try to counter whatever the opposing blue deck does that might be threatening (you know, a Wrath of God, an Engineered Plague, or in this case the High Tide finishing combo). First of all, he probably should have tried to threaten me more aggressively: only one Crystalline gives me a lot of turns of Thawing and card-drawing. Secondly, tapping out is the death knell: I didn’t even have to waste a Turnabout on him.

In similar deck vs. similar deck matchups, there are a couple of things that you want to look at to figure out what role to play:

1. Who has more damage? Usually he has to be the beatdown deck.
2. Who has more removal? Usually he has to be the control deck.
3. Who has more permission and card drawing? Almost always he has to be the control deck.

If you are the beatdown deck, you have to kill your opponent faster than he can kill you. If you are the control deck, you have to weather the early beatdown and get into a position where you can gain card advantage.

For an example of correctly determining who is the beatdown deck and who is the control deck, look at the Sligh vs. Sligh match between Price and Pacifico at the top 8 of the 1998 U.S. Nationals. Although on the surface, the two players seem to be playing very similar decks, there are major design differences:

Dave’s deck was running more Cursed Scrolls than Pacifico’s, and he also had Hammer of Bogardan and Fireslinger. His only real beatdown was Jackal Pup and Ball Lightning – the rest of the deck was more control and utility oriented.

Pacifico’s deck was much more damage-oriented… It was based around attacking and celerity creatures instead of dedicated removal. In addition to Jackal Pup and Ball Lightning, he had Goblin Vandal, Mogg Flunkies, Suq’ata Lancer, and Viashino Sandstalker. Furthermore, Pacifico’s deck lacked Fireslinger and Hammer of Bogardan, and ran only three Cursed Scrolls.

While Dave’s deck could definitely get a quick start, in this matchup, his deck was the control deck, set up for the long game. In one duel, Dave just played land and Scrolls and did very little else. He started by removing Pacifico’s creatures with blocks or Bolts, and then Scroll-locked him, gained a little card advantage, and finished the game.

Had Dave tried to race Pacifico, he might not have won. When two players are just blindly throwing their creatures into one another, the one with more damage-oriented cards is going to win the race (but I figure we expect good Sligh play from the King of Red).

Finally, think about the Suicide Black vs. Sligh matchup. These are both very fast beatdown decks. Sligh invariably wins.

Which deck has more damage? Suicide Black. It runs many high power-to-cost creatures, like Carnophage, Sarcomancy, and sometimes Flesh Reaver. Sometimes it has stuff like Hatred. It damages even itself.

Which deck has more removal? Sligh. If Suicide Black even runs Cursed Scrolls, the Sligh deck can invariably match them. Moreover, the Sligh deck has not just weenies, but Bolts.

Though Sligh is very fast (goldfish around turn 4), Suicide Black can goldfish on turn 2 or 3 depending on the version and the Ritual draw. Clearly, the Suicide Black deck has to be the beatdown deck and the Sligh deck has to be the control deck. However, Suicide Black can’t afford to be the beatdown deck. It can’t lay many of its clocks, especially Sarcomancy or Flesh Reaver, because the Sligh deck has so many bolts. It can almost never cast a Hatred, for fear of auto-loss to an Incinerate. So if it can’t really beat down, the Suicide Black deck has to try to be the control deck.

Anyone who has ever witnessed this matchup (at least when the Sligh deck gets a decent draw) knows how well control-oriented Suicide Black turns out.

Misassignment of Role = Game Loss.

After sideboarding, the Suicide Black deck has traditionally done much better. By taking out a lot of its”damage myself” cards for creature removal and life gaining, it can play the control role more adequately, and has a much improved (if not great) chance of winning.

Cabal Rogue

Team Discovery Channel

madmanpoet@yahoo.com

ocaml guideline

Sun, 03 May 2026 00:00:00 GMT

FORBIDDEN FEATURE

NEVER use Obj.magic: Breaks type safety. There is always a better solution.
There is no place for the double semicolon (;;) in OCaml source code. It is used only interactively in the OCaml toplevel (REPL).
Do not open modules globally. Default to use fully qualified names. Opening a module locally (e.g. let open...) is fine. Introduce aliases if needed.
Do not use the OCaml object/class system. Use modules instead.

Red Flags

Most code does not require references. Introducing them should be well justified. In particular, using references to implement loops and similar local control flow is probably avoidable.
Using != and == for equality is probably wrong and you should use <> and = instead, unless it is performance-oriented code that needs pointer equality.
Make scoping explicit in constructs like if and match. A statement sequence inside an if or else branch must be grouped by begin / end or parentheses to be governed by the guard. The danger of not realising what code is governed by an if-expression is exasperated by incorrect indentation and by incremental changes to existing code.
Two basic strategies for error handling exist: using exceptions, or the Result.result type. The latter has the advantage of making error handling explicit in the types of functions whereas exceptions are not tracked by the type system. If not clear, prefer Result over exception.
Beware! A while loop is usually wrong, unless its loop invariant has been explicitly written.

Best Practices

Purely functional code is easiest to test. Therefore code should be as functional as possible and imperative code minimised.
Factor out snippets of repeated code by defining them in separate functions.
The function’s usage must appear in the module’s interface that exports it, not in the program that implements it. Choose comments as in the OCaml system’s interface modules, which will subsequently automatically extract the documentation of the interface module if necessary.
Use Assertions. Use assertions as much as possible, as they let you avoid verbose comments while allowing a useful verification upon execution.
You must subdivide your programs into coherent modules. For each module, you must explicitly write an interface. For each interface, you must document the things defined by the module: functions, types, exceptions, etc.
Prefer: Option.map, Option.bind, Option.value, Result.map, Result.bind over pattern matching
You must fix every compiler warning, especially about pattern matching.
Prefer monads over nested pattern matching.

Indentation and Line Length

Indentation must always reflect the logic of a program.
In existing code, adopt the existing style for indentation: tabs or spaces.
Line length should not exceed 80 characters. Break up long lines in new code in particular.
Most OCaml code bases use 2 spaces per indentation level.
When making changes ensure that indentation is still correct after your change, re-indenting as necessary, but not excessively.

Naming Conventions

Cases and Names matter in OCaml. The following guidelines MUST be enforced.

Element	Convention	Example
Files	`PascalCase`	`UserProfile.ml`
Modules	`PascalCase`	`UserProfile`
Module Types	`ALLCAPS`	`module type QUEUE`
Constructors	`PascalCase`	`type tree = Node of int`
Types	`snake_case`, primary type is `t`	`type user_profile`, `type t`
Type Variables	`'snake_case`	`'a`
Values and Functions	`snake_case`	`find_user`, `create_channel`
Record Fields	`snake_case`	`type person = { first_name : string; age : int }`

General considerations:

Local names can be short, type variables very short. In general, the length of a name should be proportional to the size of its scope.
Prefer short, but self-describing names in public interfaces.
Use scoping (let, struct) to keep the number of names in a scope small.
Avoid encoding the type into a name: x_int or x_opt is usually not better than x.
Avoid repeating the module name in names for types and values: QMP.connection is a better name for a type than QMP.qmp_connection.
In a functional language like OCaml, using get as part of a name is often redundant unless it involves obtaining a value from a database or file.
You may see auto-generated code use the style .mIX_case where .MIX_case was meant, but record fields cannot start with capital letters. Avoid this style.
You can use longer names for type variables if it improves clarity, e.g. for phantom types.

Scoping

Use the module system to group values. It’s quite common to define simple values that belong together and to indicate this in their names:

let option_debug     = false
let option_verbosity = High
let option_log       = stdout

It is better to let the module system do the work:

module Option = struct
  let debug     = false
  let verbosity = High
  let log       = stdout
end

A value can now be accessed like in Option.debug. A module simply used for grouping doesn’t require an interface.

Order of declarations

In a module, typically the following order is maintained unless dependencies force a different order or mixing declarations:

Exceptions
Types
Modules
Values

Comments

Comments generally go before the code they are referencing. The possible exception are declarations in interfaces (mli files, signatures) and types where they can go after the declaration.

Syntactically there are two kinds of comments:

General comments, enclosed in (* and *)
Special comments (OCamlDoc), enclosed in (** and *)

Special comments are associated with type and values in a program and treated specially by the compiler. They become available in automatically generated documentation. For the association to work, there must be no empty line between a special comment and the element they are associated with.

Code should always be as clear as possible but that clarity cannot always convey the reason behind a design. Comments have the role to provide it: the why.

What to Comment

The purpose of a module or functor
The purpose of a value or function in a signature (interface)
The purpose of a type declaration or its components, if not obvious
The purpose of record components and variants in types, if not obvious
Unusual Algorithms and their complexity
Invariants when not expressed as assertions
Error handling
Basic examples on how to use the library
Known limitations
Short introduction to the technology covered by the library, if not obvious

What not to Comment

Purpose of a local let binding - the name should tell it
Every line in a function

Interfaces

Module interfaces are the best way to document and control an implementation - employ them widely.

Before writing any implementation, design the mli first. Clean interface > clever implementation.

As an exception to this rule, if your module only defines signatures then prefer using a .ml file for this, otherwise either the .mli would just be a duplicate of the .ml file, or you’d have to use .mli -only modules which don’t have good tooling support.

If possible, make a type private and can only be constructed with the function provided by the module.

In order of preference the interface of a module should expose:

immutable data structures and operations on them. Note that the implementation can use mutation if this makes the implementation of the algorithm more natural, as long as it doesn’t “leak” the mutated variable by returning it or storing it outside local variables
idempotent API calls. If the nature of the API requires mutation (e.g. a database) make it idempotent. The reason is that network/RPC calls may get interrupted before getting an answer, and the caller may not know whether the call succeeded or not, so it can just retry. If you make the retry a no-op it simplifies the logic on both sides.

Monads

(* Before - nested matches *)
match fetch_user id with
| Ok user -> (match fetch_perms user with Ok p -> Ok (user, p) | Error e -> Error e)
| Error e -> Error e
 
(* After *)
let open Result.Syntax in
let* user = fetch_user id in
let+ perms = fetch_perms user in
(user, perms)

Conventional Commits

Thu, 30 Apr 2026 00:00:00 GMT

Conventional Commits 1.0.0

Summary

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

The commit contains the following structural elements, to communicate intent to the consumers of your library:

fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.
footers other than BREAKING CHANGE: <description> may be provided and follow a convention similar to git trailer format.

Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE). A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add ability to parse arrays.

Examples

Commit message with description and breaking change footer

feat: allow provided config object to extend other configs

BREAKING CHANGE: \`extends\` key in config file is now used for extending other config files

Commit message with! to draw attention to breaking change

feat!: send an email to the customer when a product is shipped

Commit message with scope and! to draw attention to breaking change

feat(api)!: send an email to the customer when a product is shipped

Commit message with both! and BREAKING CHANGE footer

feat!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

Commit message with no body

docs: correct spelling of CHANGELOG

Commit message with scope

feat(lang): add Polish language

Commit message with multi-paragraph body and multiple footers

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space.
The type feat MUST be used when a commit adds a new feature to your application or library.
The type fix MUST be used when a commit represents a bug fix for your application.
A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):
A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
A commit body is free-form and MAY consist of any number of newline separated paragraphs.
One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a :<space> or <space># separator, followed by a string value (this is inspired by the git trailer convention).
A footer’s token MUST use - in place of whitespace characters, e.g., Acked-by (this helps differentiate the footer section from a multi-paragraph body). An exception is made for BREAKING CHANGE, which MAY also be used as a token.
A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.
If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., BREAKING CHANGE: environment variables now take precedence over config files.
If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.
Types other than feat and fix MAY be used in your commit messages, e.g., docs: update ref docs.
The units of information that make up Conventional Commits MUST NOT be treated as case-sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.

Why Use Conventional Commits

Automatically generating CHANGELOGs.
Automatically determining a semantic version bump (based on the types of commits landed).
Communicating the nature of changes to teammates, the public, and other stakeholders.
Triggering build and publish processes.
Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.

FAQ

How should I deal with commit messages in the initial development phase?

We recommend that you proceed as if you’ve already released the product. Typically somebody, even if it’s your fellow software developers, is using your software. They’ll want to know what’s fixed, what breaks etc.

Are the types in the commit title uppercase or lowercase?

Any casing may be used, but it’s best to be consistent.

What do I do if the commit conforms to more than one of the commit types?

Go back and make multiple commits whenever possible. Part of the benefit of Conventional Commits is its ability to drive us to make more organized commits and PRs.

Doesn’t this discourage rapid development and fast iteration?

It discourages moving fast in a disorganized way. It helps you be able to move fast long term across multiple projects with varied contributors.

Might Conventional Commits lead developers to limit the type of commits they make because they’ll be thinking in the types provided?

Conventional Commits encourages us to make more of certain types of commits such as fixes. Other than that, the flexibility of Conventional Commits allows your team to come up with their own types and change those types over time.

How does this relate to SemVer?

fix type commits should be translated to PATCH releases. feat type commits should be translated to MINOR releases. Commits with BREAKING CHANGE in the commits, regardless of type, should be translated to MAJOR releases.

How should I version my extensions to the Conventional Commits Specification, e.g. @jameswomack/conventional-commit-spec?

We recommend using SemVer to release your own extensions to this specification (and encourage you to make these extensions!)

What do I do if I accidentally use the wrong commit type?

When you used a type that’s of the spec but not the correct type, e.g. fix instead of feat

Prior to merging or releasing the mistake, we recommend using git rebase -i to edit the commit history. After release, the cleanup will be different according to what tools and processes you use.

When you used a type not of the spec, e.g. feet instead of feat

In a worst case scenario, it’s not the end of the world if a commit lands that does not meet the Conventional Commits specification. It simply means that commit will be missed by tools that are based on the spec.

Do all my contributors need to use the Conventional Commits specification?

No! If you use a squash based workflow on Git lead maintainers can clean up the commit messages as they’re merged—adding no workload to casual committers. A common workflow for this is to have your git system automatically squash commits from a pull request and present a form for the lead maintainer to enter the proper git commit message for the merge.

How does Conventional Commits handle revert commits?

Reverting code can be complicated: are you reverting multiple commits? if you revert a feature, should the next release instead be a patch?

Conventional Commits does not make an explicit effort to define revert behavior. Instead we leave it to tooling authors to use the flexibility of types and footers to develop their logic for handling reverts.

One recommendation is to use the revert type, and a footer that references the commit SHAs that are being reverted:

revert: let us never again speak of the noodle incident

Refs: 676104e, a215868

Semantic Versioning 2.0.0

Thu, 30 Apr 2026 00:00:00 GMT

Summary

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Introduction

In the world of software management there exists a dreaded place called “dependency hell.” The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.

In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward.

As a solution to this problem, we propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. These rules are based on but not necessarily limited to pre-existing widespread common practices in use in both closed and open-source software. For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself. Regardless, it is important that this API be clear and precise. Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backward compatible API additions/changes increment the minor version, and backward incompatible API changes increment the major version.

We call this system “Semantic Versioning.” Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.

Semantic Versioning Specification (SemVer)

Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive.
A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 → 1.10.0 → 1.11.0.
Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
Patch version Z (x.y.Z | x > 0) MUST be incremented if only backward compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.
Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.—.
Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD.
Precedence refers to how versions are compared to each other when ordered.
1. Precedence MUST be calculated by separating the version into major, minor, patch and pre-release identifiers in that order (Build metadata does not figure into precedence). 2. Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: Major, minor, and patch versions are always compared numerically. Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. 3. When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version: Example: 1.0.0-alpha < 1.0.0. 4. Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows:
  1. Identifiers consisting of only digits are compared numerically. 2. Identifiers with letters or hyphens are compared lexically in ASCII sort order. 3. Numeric identifiers always have lower precedence than non-numeric identifiers. 4. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

Backus–Naur Form Grammar for Valid SemVer Versions

<valid semver> ::= <version core>
                 | <version core> "-" <pre-release>
                 | <version core> "+" <build>
                 | <version core> "-" <pre-release> "+" <build>

<version core> ::= <major> "." <minor> "." <patch>

<major> ::= <numeric identifier>

<minor> ::= <numeric identifier>

<patch> ::= <numeric identifier>

<pre-release> ::= <dot-separated pre-release identifiers>

<dot-separated pre-release identifiers> ::= <pre-release identifier>
                                          | <pre-release identifier> "." <dot-separated pre-release identifiers>

<build> ::= <dot-separated build identifiers>

<dot-separated build identifiers> ::= <build identifier>
                                    | <build identifier> "." <dot-separated build identifiers>

<pre-release identifier> ::= <alphanumeric identifier>
                           | <numeric identifier>

<build identifier> ::= <alphanumeric identifier>
                     | <digits>

<alphanumeric identifier> ::= <non-digit>
                            | <non-digit> <identifier characters>
                            | <identifier characters> <non-digit>
                            | <identifier characters> <non-digit> <identifier characters>

<numeric identifier> ::= "0"
                       | <positive digit>
                       | <positive digit> <digits>

<identifier characters> ::= <identifier character>
                          | <identifier character> <identifier characters>

<identifier character> ::= <digit>
                         | <non-digit>

<non-digit> ::= <letter>
              | "-"

<digits> ::= <digit>
           | <digit> <digits>

<digit> ::= "0"
          | <positive digit>

<positive digit> ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

<letter> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J"
           | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T"
           | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d"
           | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n"
           | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x"
           | "y" | "z"

Why Use Semantic Versioning?

This is not a new or revolutionary idea. In fact, you probably do something close to this already. The problem is that “close” isn’t good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management. By giving a name and clear definition to the above ideas, it becomes easy to communicate your intentions to the users of your software. Once these intentions are clear, flexible (but not too flexible) dependency specifications can finally be made.

A simple example will demonstrate how Semantic Versioning can make dependency hell a thing of the past. Consider a library called “Firetruck.” It requires a Semantically Versioned package named “Ladder.” At the time that Firetruck is created, Ladder is at version 3.1.0. Since Firetruck uses some functionality that was first introduced in 3.1.0, you can safely specify the Ladder dependency as greater than or equal to 3.1.0 but less than 4.0.0. Now, when Ladder version 3.1.1 and 3.2.0 become available, you can release them to your package management system and know that they will be compatible with existing dependent software.

As a responsible developer you will, of course, want to verify that any package upgrades function as advertised. The real world is a messy place; there’s nothing we can do about that but be vigilant. What you can do is let Semantic Versioning provide you with a sane way to release and upgrade packages without having to roll new versions of dependent packages, saving you time and hassle.

If all of this sounds desirable, all you need to do to start using Semantic Versioning is to declare that you are doing so and then follow the rules. Link to this website from your README so others know the rules and can benefit from them.

FAQ

How should I deal with revisions in the 0.y.z initial development phase?

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

How do I know when to release 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.

Doesn’t this discourage rapid development and fast iteration?

Major version zero is all about rapid development. If you’re changing the API every day you should either still be in version 0.y.z or on a separate development branch working on the next major version.

If even the tiniest backward incompatible changes to the public API require a major version bump, won’t I end up at version 42.0.0 very rapidly?

This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you’ll think through the impact of your changes, and evaluate the cost/benefit ratio involved.

Documenting the entire public API is too much work!

It is your responsibility as a professional developer to properly document software that is intended for use by others. Managing software complexity is a hugely important part of keeping a project efficient, and that’s hard to do if nobody knows how to use your software, or what methods are safe to call. In the long run, Semantic Versioning, and the insistence on a well defined public API can keep everyone and everything running smoothly.

What do I do if I accidentally release a backward incompatible change as a minor version?

As soon as you realize that you’ve broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backward compatibility. Even under this circumstance, it is unacceptable to modify versioned releases. If it’s appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version.

What should I do if I update my own dependencies without changing the public API?

That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. We would usually expect additional code for the latter instance, in which case it’s obviously a minor level increment.

What if I inadvertently alter the public API in a way that is not compliant with the version number change (i.e. the code incorrectly introduces a major breaking change in a patch release)?

Use your best judgment. If you have a huge audience that will be drastically impacted by changing the behavior back to what the public API intended, then it may be best to perform a major version release, even though the fix could strictly be considered a patch release. Remember, Semantic Versioning is all about conveying meaning by how the version number changes. If these changes are important to your users, use the version number to inform them.

How should I handle deprecating functionality?

Deprecating existing functionality is a normal part of software development and is often required to make forward progress. When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.

Does SemVer have a size limit on the version string?

No, but use good judgment. A 255 character version string is probably overkill, for example. Also, specific systems may impose their own limits on the size of the string.

Is “v1.2.3” a semantic version?

No, “v1.2.3” is not a semantic version. However, prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number. Abbreviating “version” as “v” is often seen with version control. Example: git tag v1.2.3 -m "Release version 1.2.3", in which case “v1.2.3” is a tag name and the semantic version is “1.2.3”.

Is there a suggested regular expression (RegEx) to check a SemVer string?

There are two. One with named groups for those systems that support them (PCRE [Perl Compatible Regular Expressions, i.e. Perl, PHP and R], Python and Go).

See: https://regex101.com/r/Ly7O1x/3/

^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$

And one with numbered capture groups instead (so cg1 = major, cg2 = minor, cg3 = patch, cg4 = prerelease and cg5 = buildmetadata) that is compatible with ECMA Script (JavaScript), PCRE (Perl Compatible Regular Expressions, i.e. Perl, PHP and R), Python and Go.

See: https://regex101.com/r/vkijKf/1/

^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$

About

The Semantic Versioning specification was originally authored by Tom Preston-Werner, inventor of Gravatar and cofounder of GitHub.

If you’d like to leave feedback, please open an issue on GitHub.

License

Creative Commons ― CC BY 3.0

MTG

Sat, 25 Apr 2026 00:00:00 GMT

Who’s The Beatdown

限制赛

法术力基础

ref. Frank Karsten

主色均需要至少8点
双色98基本地属于勉强能接受，最好有2个多色地（除非是有很多1费的快攻）
轮抓时要考虑法术力符号
避免无色地
快攻几乎不混色、低费牌几乎不混
混色需要3~4点来源

蔓生庭院

memory consistency model

memory consistency model

Operational semantics

concurrent termination analysis

背景

相关工作

Testing

Verification

研究内容

技术方案

Non-Volatile Memory

Non-Volatile Memory (NVM)

What is Persistent Memory

What does PM mean for application developers?

Characteristics

Challenge

Visibility and Persistency

Relevant Works

2023

2024

喀耳刻

欢迎来龙餐馆

缓存一致性与内存模型的关系

Related

Memory Hierarchy

Related

Computer Architecture: A Quantitative Approach

Computer Architecture: A Quantitative Approach

Attachments

Collections

Annotations

Related Items

ISA

Classification

寻址

编码

Related

The History of FORTRAN

Before FORTRAN

The Early Years

FORTRAN 66

FORTRAN 77

FORTRAN 90

奥德赛

Logical Foundations of Example-Driven Specification

Database Query

Most-specific fitting CQ

Query Repair

LTL

Making a Splash

1. Do Not Splash Cards You Want to Cast Early

2. Do Splash What Covers Your Weaknesses and Adds Power

3. Do Not Ignore Colored Mana Requirements

4. Do Think About your Splashes During the Draft

5. Do Not Splash in Decks That Don’t Want Splashes

Splash Attack

Dependent Function

Dependent Function Type (Π-Type)

Related

Evaluating Combat Tricks In Limited

Who's The Beatdown?

ocaml guideline

FORBIDDEN FEATURE

Red Flags

Best Practices

Indentation and Line Length

Naming Conventions

Scoping

Order of declarations

Comments

What to Comment

What not to Comment

Interfaces

Monads

Conventional Commits

Conventional Commits 1.0.0

Summary

Examples

Commit message with description and breaking change footer

Dependent Function Type ( $Π$ -Type)