蔓生庭院

memory consistency model

Thu, 07 May 2026 13:50:47 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

Thu, 07 May 2026 13:50:47 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

Thu, 07 May 2026 13:50:47 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)

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点来源

Simulating Draft Strategies

Sat, 25 Apr 2026 00:00:00 GMT

There have been a few different styles of drafting proposed over the years. Ben Stark’s Drafting the Hard Way is the seminal article on reading signals in draft by trying to intuit what your neighbors are drafting and why that leads to better results over the long run. He also introduces the terminology of drafting “the easy way”: holding onto your first pick for dear life. A few years later, Ondřej Stráský introduced a middle ground concept in his article Drafting the Medium Way, which was later reinforced by Ryan Saxe in his article Maximizing For Your Own Preferences and on Lords of Limited as Drafting with Preferences. These takes suggest leaning into a subset of archetypes in a draft, either because you know they generally result in stronger decks, or perhaps because you’re just more comfortable with them. If there are any of these articles you haven’t read, I’d strongly recommend reading them as they present very helpful concepts useful to any drafter - the descriptions I’ve provided are vast oversimplifications of the information they provide.

There has been debate about which of these methods is best, and any of the authors would likely agree that it depends on many factors. When Drafting the Hard Way came out, it was pretty common for most people to be drafting the “easy way”, and someone who was reading signals in the draft could often get a significant leg up on the others in their pod as a result. These days, with more draft content available than any one person could hope to consume, a lot more people are trying to read signals, and the benefit of doing so is lessened. If everyone is drafting the hard way, it becomes tough for anyone to read clear signals and can result in some weaker decks. If some people at the table are drafting with preferences towards a few decks, they can send better signals that other colors are open and wind up with stronger decks. However, if everyone believes UR to be best and leans into drafting it, those who don’t abandon ship can be left with pretty weak decks as the cards in their colors dry up. There’s a lot of interesting game theory at play here, though we won’t dive too deeply into that.

Through all of these articles, everyone has theorized what impact this may have on a draft and backed it up with their overall experience. It’s easy enough to see for yourself what happens if you try to use one of these techniques in any given draft, but no one ever seals the packs back up and runs it again with a different strategy. Today, however, we’re happy to be able to actually show you what happens if you do just that! Using all the data submitted by 17Lands users, we’ve developed draft bots that can simulate different personalities for us. To see what happens in these scenarios, we’ve put them all at a table together, trying out different configurations but keeping the same set of packs through these different iterations just to see what happens!

Let’s Run It Back

For each of the simulations we run through, we’ll include a visualization of what profile is in each seat, and we’ll highlight the same seat across each draft to see the impact of their and other draft personalities’ choices. “E” indicates an easy-way drafter, “H” indicates the hard-way, and “P +XY -Z” indicates a preference for colors X and Y as well as a tendency to avoid color Z. At the end, we’ll also share with you a number of other different drafts and configurations with all of the draft viewers exposed so you can explore even more for yourself. With that background in mind, let’s get to it!

Our first configuration pits a table full of easy-way drafters against each other. You should take a look at the draft viewer for the highlighted seat here. In this case, we see the drafter take what was deemed the best common early on -

Grasp of Darkness

- over

Thrashing Brontodon

and

Hunter’s Edge

. From there, it avoids taking

Experimental Overload

because that’s pretty unlikely to be played in the same deck as a double-pipped black card and instead takes

Palladium Myr

. A couple of picks later, once

Walking Corpse

is the only remaining black card, it ventures out into another color for a strong white card in

Aven Gagglemaster

. Only when there’s only sideboard-level cards left in the pack does it venture into other colors. The results after pack one are pretty bleak, with a mix of mainly black, blue, and white cards in the pool as the person passing to our featured drafter was also in black. In packs two and three, they move more solidly into blue and are able to pick up a couple of good black cards, but overall, the draft goes pretty poorly, having never moved off of the black that wasn’t flowing.

Next, we use those same packs, but have all the drafters set to do it “the hard way,” including our featured drafter. We can see an immediate difference in pick two, with the drafter recognizing the strength of

Experimental Overload

even though it means giving up on the

Grasp of Darkness

from pick one. If more cards for the blue-red spells deck follow, good things will result. Throughout the rest of pack one, blue and red do seem to be pretty open, so not a whole lot of bobbing and weaving is necessary after the second pick. If you look closely, though, you can even see as early as pick four the results of other drafters altering their picks as well. In the second pack, this drafter is rewarded handsomely for recognizing their lane, with the bot to their right having picked up that UR wasn’t open, passing strong cards for the deck like

Shipwreck Dowser

and

Goblin Wizardry

. Pack three rounds out with some more solid additions to the UR spells deck, leaving many options for how to best configure the deck by the end.

Next, we see what happens when we mix easy- and hard-way drafters at the same table. In this case, our easy-way drafter doesn’t actually have as much of an option to get mixed up in blue or white and actually gets pushed pretty early on into green as their second color. The hard-way drafter passing to them better picked up that white was open, cutting off that avenue. While this draft isn’t necessarily much better or worse for our easy-way drafter, it’s still interesting to note that it winds up significantly different from the all easy-way drafting from our first scenario.

Lastly, we get to mix in drafting with preferences. In M21, the consensus seems to be that the Naya colors (white, red, and green) are the strongest, as they have a deep roster of commons that contribute to the aggressive plan. As such, we see what happens in that same seat with an early preference towards these colors and a bias against black as the worst color. Perhaps unsurprisingly, we wind up with a totally different deck. The drafter forces its way into WG early on, with red not having been flowing much at all. Choices of

Thrashing Brontodon

and*

Quirion Dryad

over somewhat comparable black cards emphasize this preference. In pack two, they’re rewarded with some great cards for the deck, and even see some benefit later on in the pack with cards like

Daybreak Charger

and

Alpine Watchdog

*wheeling, which didn’t happen at all in any of our earlier drafts. While the final result isn’t the best WG deck, it certainly has the tools to rumble with the rest.

More to Explore

What we’ve described here is just one set of packs, and a couple of personality configurations. For those interested, we’ve generated quite a few more scenarios for you to peruse as outlined in the table below. Each link includes the bot personality and the final colors they ended up in. The scenarios described above are pack list “A”.

Pack List	Seat 1	Seat 2	Seat 3	Seat 4	Seat 5	Seat 6	Seat 7	Seat 8
A	E (UB)	E (UR)	E (RG)	E (Wb)	E (WB)	E (UR)	E (Gb)	E (WB)
A	H (UR)	H (Gr)	H (WG)	H (Bu)	H (UB)	H (Rg)	H (Wg)	H (WB)
A	E (BG)	H (UR)	E (RG)	H (Wb)	E (Bu)	H (UR)	E (Gr)	H (WB)
A	P+WRG-B (WG)	H (UR)	E (Gr)	H (Bw)	P+UR-B (UR)	H (WB)	E (BG)	H (WB)
B	E (BG)	E (UB)	E (WR)	E (B)	E (Gr)	E (W)	E (UR)	E (WR)
B	H (BG)	E (UB)	E (WR)	E (B)	E (Gr)	E (W)	E (UR)	E (WR)
B	H (BG)	H (UB)	H (WR)	H (UR)	H (Rg)	H (WG)	H (Ub)	H (W)
B	E (BG)	H (UR)	E (WR)	H (UR)	E (UG)	H (WR)	E (U)	H (WB)
B	H (B)	H (RG)	E (WR)	E (Bu)	H (UR)	H (WG)	E (U)	E (W)
B	P+WRG-B (Gr)	H (WU)	E (WR)	H (UB)	P+UR-B (Ru)	H (WG)	E (U)	H (WB)
B	P+WRG-B (BG)	P+UR-B (UB)	P+WRG-B (WR)	P+UR-B (UB)	H (Rg)	P+WRG-B (WG)	P+UR-B (U)	P+WRG-B (WR)
C	E (UR)	E (U)	E (WG)	E (Rg)	E (Ub)	E (WG)	E (WR)	E (B)
C	H (UR)	E (Ug)	E (WG)	E (R)	E (Ub)	E (WG)	E (WR)	E (B)
C	H (UR)	H (UR)	H (WG)	H (RG)	H (UB)	H (WG)	H (WR)	H (UW)
C	H (UR)	H (U)	E (WG)	E (RG)	H (UB)	H (WG)	E (WR)	E (UB)
C	P +WRG -B (UR)	H (UG)	E (WG)	H (RG)	P +UR - B (UB)	H (WG)	E (WR)	H (UB)
C	P +WRG -B (UR)	P +UR - B (UB)	P +WRG -B (G)	P +UR - B (RG)	H (UB)	P +WRG -B (WG)	P +UR - B (WR)	P +WRG -B (WR)
D	E (WB)	E (UG)	E (WB)	E (R)	E (RG)	E (UR)	E (WG)	E (UB)
D	H (WR)	H (UG)	H (Bw)	H (R)	H (WG)	H (RG)	H (Uw)	H (UB)
D	H (WR)	H (UG)	E (Wg)	E (R)	H (BG)	H (UB)	E (WG)	E (U)
D	P +WRG -B (WU)	H (UG)	E (WG)	H (Rb)	P +UR - B (RG)	H (UB)	E (WG)	H (UB)
D	P +WRG -B (W)	P +UR - B (UB)	P +WRG -B (R)	P +UR - B (Gw)	H (BG)	P +WRG -B (UR)	P +UR - B (UW)	P +WRG -B (UB)

While our draft bots don’t mimic human behavior perfectly, this sort of simulation serves as a great learning tool for the effects of these different styles. You’ll see plenty of cases where the preference bots get pushed out of the colors they want, and cases where the easy-way drafters end up in the same lane as if they drafted the hard way. Overall, though, these bots help illustrate some of the nuance that the top limited minds recommend.

Easy-way drafters will see a lot more volatility in their results. In some cases, like this one, you wind up with the nuts aggressive WR deck where your biggest challenge is figuring out all the cuts. In other cases, though, you’ll find yourself one of multiple UB drafters and wind up scrapping for playables. Hard-way drafters may need to bob and weave a bit before settling into the right lane, but they can be very rewarded for doing so in many cases. In other cases, drafting the hard way can wind up postponing the decision too far leaving you unsure what colors you are in or reading signals incorrectly just because the packs fall a certain way. Drafting with preferences will usually leave you with a good second pack if you’re able to force your neighbor to the right out of your colors, but you can also be filling your deck with a bit of chaff in pack three if the person passing to you is in your same colors.

It won’t be universally true, but in a pod full of easy-way drafters (perhaps your local FNM), drafting the hard way will usually yield the best results. In a pod of hard-way drafters (maybe your next MTGO draft), pushing your way into the best colors with preferences will wind up with a good deck. Put in too many preference drafters, though, and drafting the hard way will often take back the crown. The small sample of data we’ve provided here can’t show this outright, but it’s another step along the path to demonstrating these ideas and also perhaps better showing where they might not hold. Our next goal with these simulations will be to recommend a deck build from each drafted pool and estimate the strength of that resulting deck. If we’re able to build a good version of that, you can be sure we’ll run a much larger set of simulations and share the results.

Do you want to help contribute data for analyses like these in the future? Check out our Getting Started page to install the lightweight Arena tracker and get access to all of our deck, draft, and gameplay tracking!

Stark Reality - Drafting the Hard Way

Sat, 25 Apr 2026 00:00:00 GMT

TCGplayer Series:

A lot of people ask me for help with booster drafting. I wish so badly it were the kind of thing where I could take 20 minutes of my time to listen to how they draft, tell them what they are doing wrong, and how to fix it. It just isn’t. Booster drafting well is incredibly complex.

The best way I can describe it is that there are two ways: The easy way and the hard way. If you draft the easy way all the time, you can spike when things line up your way and you are perfectly live to 3-0 and draft good decks when they do, but around half the time you will not end up with a good deck at all and will be liable to 0-3 or 1-2 your draft. If you draft the hard way you can have a good deck in 90 percent of your drafts. Sound great? What’s the problem? Well, the hard way is hard.

Drafting the hard way means analyzing each new format and being willing to forget about whether you like control or beat down, white or black. Forgetting about what was working for you in the last format and starting to evaluate everything from scratch all over again. Always being willing to drop early picks if you realize something else is open. It means not sticking to the strategy or strategies that you think are best but weighting the cards that are important for those correctly, and then still being willing to draft completely different decks if that’s what is open.

It requires allowing your decks to go different directions in each draft and not predetermining where you are going to go. Every draft format is different and every draft is different. I don’t even like doing our house practice drafts, because they bias me into thinking you should go certain directions more than you should, because certain strategies are either open or would work well against what the others in the group are doing. I generally prefer these days to watch the draft so that I don’t get as caught up in trying to win. Instead I spend more time watching how the commons interact with each other and trying to pick up on how the games and format plays out.

Different things are a little more or a little less important in each new format. So at the start of a new format, I’m mostly trying to identify whether flying is a little better (Return to Ravnica). How about lifelink? (Zendikar). Is this a format where drawing cards is a little bit more profitable than usual (Modern Masters)? Or is this a format where a lower mana cost is of extra value (Gatecrash).

Let’s look at a good example of this. I remember when we started our testing for PT Avacyn Restored, most people thought Seraph of Dawn was better than Mist Raven. It’s not hard to see how this happened. In an aggressive format, the 2/4 would be much better, and in a format where the cheap cards were more powerful, the 2/4 would also be much better. Avacyn Restored was neither of those things, but the format directly before, Innistrad - Dark Ascension, was both.

It was a format where the cheap cards like Werewolves and Travel Preparations hit hard and prevented late games, or were still good in the late game. In that format, the 2/4 would have been better than Mist Raven. In Avacyn, however, the cheap cards were horrible. Games were mostly decided by individual powerful cards. The tempo swing from being able to bounce a soulbond that was preventing you from attacking or bouncing their powerful five-plus mana card that they were depending on to swing the game was extremely valuable. The two life a turn that makes it almost impossible to race the 2/4 was not particularly amazing, since you weren’t usually racing. The 2/4 is still a good card, and one that could help you win games, but it was not the bomb it would have been in formats like Innistrad - Dark Ascension, Zendikar or Gatecrash.

The single thing people do that ruins most drafts is stick to their early picks. In the vast majority of draft formats, you should be trying to figure out what is underdrafted at the table so that you can have access to a lot of what you are looking for in packs two and three. Also, by identifying which colors or archetypes the people to your right aren’t playing, you end up having several packs to get incredibly powerful picks from. If you stick to your first picks, you often end up with few packs to select first-pick quality cards from.

People often think that they can just jam what they want, because if they are cutting something off then they will have access to the cards that they want in pack two even if not in pack three. This only works when pack two is specifically more valuable than pack three. Even if you draft mono-white from pick one, there were probably a few other white cards in the packs, and if the guy to your left or to his left is drafting in easy mode (95 percent of people are) and he opened or got passed a white card from the person passing to him (if it’s the guy two seats down), then they are probably still going to draft white despite you not passing them any great cards in that color.

On the other hand, if you get a first-pick quality white card pick four, and a second to fourth pick quality blue card pick eight, while nothing is guaranteed, you can bet your ass the vast majority of the time that the people to your right aren’t drafting white and blue is heavily underdrafted at the table. The exception to this rule are formats where pack two is of disproportionately greater importance to you than pack three.

A perfect example of this is DGR if you start out in a Gatecrash guild. Since you don’t care much about pack three, and pack two is your entire world, if your first two picks put you into a specific Gatecrash guild, you can just jam that guild and not bother to read what the people passing to you are playing, or what is being underdrafted in the pod, since you basically live and die by only pack two, and you are only looking for strong cards out of the first few picks of pack two. Draft formats where this is correct like DGR are few and far between though.

The next thing that often ruins drafts is trying to draft the nuts or the best deck. Going for a combo or cards without synergy that don’t fit their deck’s plan, or are difficult to cast but have a high power level. I have 3-0’d so many draft pods with very mediocre looking decks. You don’t need to be in the best color or archetype, you don’t need a way to win, you don’t even need particularly powerful cards to win. If your deck is fully functional, meaning the cards you do have work together, your curve is good for the format, and your mana allows you to cast your spells when you need to cast them (some formats you are under more pressure (Gatecrash), some you have a little more time (Rise of Eldrazi), that is good enough to allow you to 3-0 any pod. Sure you won’t have the best deck in the pod, but that’s not how Magic works.

The most common scenario is not that you have the third best deck, and you play against the best or second best deck you lose, otherwise you win. In that case, drafting the second or third best deck in the pod every time would result in 2-1 every time. In reality, when you have the third best deck and you play against the best deck in the pod, you are usually just a small underdog because your deck is very good anyways. In general I feel outmatched when I play my 2-0 match in my draft pods, but assuming roughly even play skill I win that match around 45 percent of the time, because I have a good, fully functional deck. If he stumbles, gets flooded, or my cards just happen to line up well against his, I can very easily win. When you have good, fully functional draft decks, it is very easy to beat a better deck. When you have trainwrecks/bad draft decks it is very difficult to beat anyone.

A good example of this approach would be my first draft in PT Gatecrash. It was covered in the draft viewer so you can go back and check it out. I started out with some Orzhov stuff (the guild I consider the best by miles in triple-Gatecrash), but I wasn’t seeing Orzhov, so around pick five, pack one, I realized Simic was open and completely jumped ship. I was very fortunate to have this opportunity. I had it because a lot of the other players in the draft were unwilling to draft Simic, because they thought it was the worst of the five guilds (personally I think it was the fourth of the five guilds and not particularly good, but that Dimir was the worst). This imbalance allowed good Simic cards to come late, telling me that Simic was wide open and I jumped ship, drafted a mediocre Simic deck, and went 2-1.

If I had stuck to Orzhov, my deck would have been absolutely terrible, and while I have no idea what my record would have been, my EV in wins in the draft would have been much lower. I obviously was very unhappy to have to move from the best guild in the format to the fourth best guild out of five, but you don’t want to dictate what you draft, you want to draft what you see and what is being underrated. Any fully functional, reasonable draft deck, can 2-1 or 3-0 a pod. Trainwrecks struggle to get a win.

It took many years of endless drafting for me to improve my draft game and I’ve spent many years trying to slowly improve the drafting skill of many of my closest friends. If you are willing to play the game in hard mode, don’t expect to be good at it quickly or to immediately start crushing. However, if you are willing to read every draft, be open to drafting whatever archetype is available that draft, and even drop bomb-rare first picks, you can put together a good draft deck in almost every draft you do and you can be a highly successful booster drafter. Will you accept this challenge? The choice is yours.

SOS轮抓手记

Fri, 24 Apr 2026 00:00:00 GMT

总览

整体趋势是多色控制/5c聚辉 v.s. 快攻；聚辉更强，也更容易抓，调色很重要；快攻组件不齐难成形

多色控制/聚辉

以大法术和回收坟场作为终端，主2~3色，通过珍宝/调色手段混色以及激活聚辉

Ramp/调色：加速神器，红石板，找地载具，两组双色地
聚辉payoff：协力如一，聚辉放逐人，4B弃牌，5G造两token
磨牌库制胜：U磨牌人，XXUU指数抓牌（12费稳定获胜）
红蓝底：可以不混色，单纯走红蓝大法术流
- 调色：Sanar，222珍宝哥布林，抓二弃一造珍宝，213调色人
- 大法术力payoff：XXU小回收，4UUU大回收，XUR爆头，1UURR扫4或者抓4，3UR打5，5UR造两鸟/前期润滑
蓝绿底：几乎必然要混色，补足去除
- 调色：111熊，222找地人，4费回手ramp，死触蛙>递增人
- 大法术力payoff：2UG复制+6豆，XUG分形鸟，XG分形刺探，Jadzi
法术循环组件：蓝色大小回收，绿尊贤，644，322先攻
混色对象：2WR约柜，3WWBB，黑、白、绿杀和扫

Combo

322先攻+2UG复制能达成每回合造66先攻；当回合使用一次比较保险，需要7费4色
黑绿锅+444能无限造11虫和挖坟
2WR打5从坟场或放逐区施放时只需要2费，可以配合约柜、322先攻、石板等
- 同理，1WW脱缰古物此时有加豆效果
任何需要输注的法术都可以先施放，再响应启动加速神器加血
3WWBB和644可以循环
2B捡坟+644

Underrated

3WWBB: Moment of Reckoning
聚辉放逐人：Sundering Archaic

Overrated

除红之外的定式，尤其是黑定式
211云移人，323偷咒语人
拉尔（黑白可用）
10费古旅人，基本只在红蓝底控制有效
黑绿龙

记录

0425 第一抓单抓 1-3

红白，第二包换色到红蓝，整体是个偏控制的法术瞬间套组

失误是

放过了很多红白的法术（比如Molten Note）、生物和地，本来可以是一般的红白套组，或者洁斯凯；
没有wincon。第二包有的Sundering Archaic也可以算制胜（洗回牌库）和法术力水槽，没有意识到

我感觉多色套组会在后续表现更好。从这一抓来看，如果是红白或是黑白快攻都需要不少组件，抓的人基本只在这个体系下有用。有些牌在快攻之外也可以用，比如红白的4费解，前期抓了后面多色控制套组也可以用。所以可能更好的策略是尽量保持开放，留出打多色的可能？

群里老哥的复盘：对牌的强度不敏感，第一包传了很多好牌下去，信号会乱；force红白会更好，至少是一套能玩的红白；第二包抓的很有问题，放了太多牌

0426 第一抓单抓 3-3

苏勒台，有一堆黑去除和扫，蓝绿底不够，少ramp，蓝牌的作用很少；制胜纯靠绿结界

大法术瞬间不够，U磨牌库人基本没用；适合有大量大费牌的控制
黑绿是比较开放的，在抓蓝牌的时候有几张黑绿牌可以抓，可能最后组出来的黑绿强度更高一点
P1P1直接抓熊不太对，应该是黑绿锅的
P1P3过高位抓调色神器，不过它可以配合输注牌瞬间回血（相应输注启动异能），但是注意在17lands数据显示纯黑绿有它胜率暴跌，可能更适合作为插件。
- 这一抓112或者互斗比较好
复盘会发现第一包黑白是开放的（Snooping Page是信号），然后第二包直接P1抓金，后面的所有黑白牌都回传了

0426 第二抓双抓 3-2

带炸弹神器的红白，有不少造22的人，但是没有314

双抓模式下因为开的包只有原来的一半，即使没撞色，有些关键的牌很有可能就是开不出来，所以虽然套牌整体更一致，但是强度不一定就更高。比起单抓，信号更好识别，但是读信号会更重要，force色组更难。

0426 第三抓双抓 4-0

抓的不如上一次，但是卷了。双抓的对手强度似乎要低一点

0426 第四抓双抓 4-0

蓝绿底的铁木尔，核心是前期用死触蛙这种站住+加速，同时大量2跳4，用高费咒语碾压。

抓的时候大概是在第四到第五pick发现信号
444 Sloth很强

0429 第一抓双抓 1-2

铁木尔混黑，ramp太多，payoff太少，制胜竟只有磨牌人，绿结界和分形鸟

0429 第二抓双抓 1-2

又是铁木尔，但是质量差得多

红蓝现在绝对是抢的人很多，而没有红蓝混色payoff蓝绿基本上没什么强度。双抓情况下如果有撞色的情况就会像这样很糟。

0430 第一抓双抓 0-2

没有配合的红白，有白黑炸弹，但没有调色只能卡手里

卡组构建比较矛盾，因为没有红白配合牌，转向前期快攻，小人又不够，同时还有7费的终端，就很呆。

但是另一方面，既没有高费终端，又没有大量低费曲线的中速真的是拉完了。

0510 第一抓快抓 5-3

没有足够payoff，但是离坟挺多的红白，大多数时候是靠横向展开踢死的。

Low-Prio List

Do the Bots Send Signals?

Fri, 24 Apr 2026 00:00:00 GMT

Draft is often cited as the biggest test of skills for a Magic player, as there are three distinct areas where a drafter must excel in order to do well: drafting, deckbuilding, and playing. With the advent of Arena, “the bots” have disrupted the drafting component significantly. In this post, we’ll try to explore how bots affect the way we draft, backed up by data from real Arena and Magic Online drafts.

Drafters’ Incentives

Drafting with humans in seats next to each other is not a zero-sum game. Players must cooperate with the drafters next to them in order to end up with better decks. If they instead fight over cards of the same color, they’ll wind up with worse decks and lose more games. Because 5/7 games (on average) in an 8 person pod are played against opponents that aren’t your neighbors, there is an incentive to make your own deck better, even if it means your neighbors’ decks are a little better too.

The introduction of leagues in Magic Online altered these incentives slightly. When drafting and playing in-pod, “hate drafting” has some benefit if you can make your neighbor’s deck worse at little to no cost to your own deck. In leagues, however, drafters play against opponents outside of their pod, and hate drafting has almost no effect, since the chance of playing against your neighbor is very small.

In Arena, humans draft against seven automated draft bots. Because the bots only take cards out of packs and don’t have to build decks or play matches, the drafting experience is significantly altered. By not playing matches, the bots don’t have any incentive to send or receive signals outside of WotC trying to keep Arena interesting to limited players. With that in mind, let’s try to evaluate how far off from a real drafting experience drafting on Arena is.

Establishing Card Ratings

Because players aren’t allowed to communicate during a draft, the only way for a player to know what colors their opponent is drafting is to infer that information from the cards being passed. The simplest solution might be to count the number of cards in each color, but there’s a lot of variance in that. Instead, we get better signal from the card strength. If the blue, white, and red cards being passed to a player in the first pack are consistently stronger than the green and black ones, it’s more likely that the person to their right is drafting green and black. But what do we mean by “stronger”?

To evaluate strength, we need to understand how our neighbors value the cards. This is challenging to do unless we have lots of data to work with. With hundreds of drafts, we can identify the rating of cards based on how late we see each card in a pack on average. To illustrate with an example, let’s look at

Invading Manticore

in this draft. Throughout the draft, we see it the following times:

Pack 1 pick 1
Pack 1 pick 9 (indicating no one took this picks 2 through 8)
Pack 3 pick 7

For any card that wheels (i.e. we see it again when the pack comes back around), we ignore the first time we saw it. Using just the data from the draft above, the “average available position” for

Invading Manticore

would be 8.0. Averaging across all the WAR drafts shared using 17Lands, the actual number for

Invading Manticore

with the Arena bots is 7.6. We also have data from hundreds of Magic Online drafts with human drafters to compare to, provided by Magic Pro Tools. Averaging across those human drafters, that number for

Invading Manticore

is 6.2. A great card like

Spark Harvest

is usually only available in the first couple of picks, and its number is 3.0.

To turn this “average available position” into a number representing the strength of the cards being passed, we scale this number to be between 0 (lowest valued) and 1 (highest valued), and then square it to account for good cards being significantly more valuable than mediocre cards. The table below shows this value for a sample of War of the Spark cards for Arena drafts logged on 17Lands between May 9 (the most recent announced update to the bots) and June 20 and from the sample of MTGO drafts uploaded to Magic Pro Tools.

Name	Rarity	Colors	Humans Value	Bots Value	Difference
Arlinn’s Wolf	common	G	0.31	0.497	0.187
Arlinn, Voice of the Pack	uncommon	G	0.776	0.787	0.012
Bond of Discipline	uncommon	W	0.166	0.318	0.153
Emergence Zone	uncommon		0.022	0.018	-0.004
Invading Manticore	common	R	0.177	0.074	-0.103
Living Twister	rare	GR	0.552	0.786	0.233
Merfolk Skydiver	uncommon	GU	0.518	0.757	0.239
Mobilized District	rare		0.487	0.881	0.394
Vraska, Swarm’s Eminence	uncommon	BG	0.828	0.846	0.018
Wanderer’s Strike	common	W	0.474	0.567	0.092

Finding Your Lane

We can’t interpret the power level of colors in any one pack to be fully indicative of what our neighbor is drafting. However, if we track the power level throughout all of the picks in a pack, we get a pretty good sense of what those passing to us are drafting. Assuming the other drafters don’t change colors after the first pack, we expect to see the total power level passed to us in pack one to be relatively close to the power level passed to us by those same drafters in pack three.

To evaluate the benefit to finding the open colors, we’ll need a methodical way for doing so. For each color, we take the sum of the maximum-valued card in each pack of that color (we’ll split the value of multicolor cards evenly across their colors). Let’s take blue in this draft as an example.

Pick 1 isn’t passed to us, so we don’t value it.
P1P2, Tamiyo, Collector of Tales adds 0.36 (because it is two colors, we split
P1P3, Eternal Skylord adds 0.79, bringing our total to 1.14.
P1P4, Thunder Drake adds 0.52. Total is 1.66.
P1P5, Tamiyo’s Epiphany adds 0.49, putting the total at 2.15.

And so on through the end of the pack. The total for blue throughout pack one comes out to about 3.26. In pack three, following the same logic, the total is about 3.62.

The chart below shows these values for all the WAR Magic Online drafts submitted to Magic Pro Tools. Each draft has five data points: one for each color. The x-axis represents the total power level throughout pack one, while the y-axis represents the total for that same color seen throughout pack three.

The positive slope demonstrates what we intuited before: there is a definite benefit to identifying the open colors in a draft! If you consistently get passed good cards in a color in pack one, on average you’ll see much better cards in the third pack in that color. This isn’t guaranteed, though. Other drafters could switch colors, or the cards could just be weaker in pack three.

Below is a similar plot using Arena drafts with the bots’ valuations.

We see a similar trend, indicating that the Arena bots mirror the behavior of real drafters. In this case, the slope is even steeper, indicating there may be more value to reading signals drafting with the Arena bots than with humans! If the bots send signals like humans, though, why does drafting against the Arena bots feel different from drafting against humans?

Difference in Pick Order

The most obvious difference in drafting with bots is that their pick order is different. When bots overvalue cards like

Giant Growth

, drafters don’t have a chance to take it where they feel it should be going, and as a result it’s almost never seen in draft play on Arena. It is hard to notice the absence of something, though, and it not being there in any one draft isn’t that odd. What sticks out like a sore thumb, though, is when cards go way later than they should. There have been some extreme examples in past sets, like

Gate Colossus

and

Sauroform Hybrid

in RNA. Since the latest update to the bots, the examples in WAR aren’t quite so bad, but

Lazotep Plating

and

Dreadmalkin

are a couple that still seem to stick out.

Pick Order Variance

Another key insight is that the bots are much stricter with their pick order than the variety of humans who draft. Looking at the variance of how late cards are seen across the pick order, this becomes clear:

The first thing to note from this graph is that there are quite a few cards with zero variance - there are 18 rares and mythics that the Arena bots have never passed in the hundreds of drafts recorded, even in the third pack when it’s not in their colors. This compares to only four cards never passed in the sample of Magic Online drafts. There are three reasons someone might take a card that they’re not going to play: they can sell it, they need it outside of the draft, or they’re hate drafting. Because there’s no secondary market on Arena, the first reason wouldn’t apply, so we would expect less of this behavior, not more.

The other thing to note from this graph is that across the entire pick order, the variance is lower. This indicates that the bots likely have a very strict pick order within each color, and they stick to it throughout the draft. Not only do different human drafters have different valuations of the cards, but even an individual drafter’s pick order will change throughout the draft to fill in holes in their deck. For example, someone might be light on two-drops and take

Kronch Wrangler

over

Bloom Hulk

later in the draft, even though the latter is a better card in a vacuum. Given the data presented, though, it’s unlikely the bots make these sorts of in-draft adjustments.

Self-Correction

The metagame for drafting with humans is usually self-correcting. When blue and red are seen as the deepest colors in a format, more people draft those colors. As a consequence, they get fewer powerful blue and red cards, and the people who are drafting white, black, and green will get their choice of the powerful cards in the shallower colors. With the Arena bots being so strict in their pick order, though, the metagame doesn’t shift, and any mistakes in the bots’ card evaluation continue to be exploited. The table below shows the percentage of decks playing each color for 17Lands users’ opponents and the win rate of those decks (note that 17Lands players are better than average, thus their opponents’ have a win rate of under 50%):

Color	# Games	Metagame Share	Win Percentage
White	1063	35.1%	41.9%
Blue	1490	49.1%	44.4%
Black	1440	47.5%	43.8%
Red	1222	40.3%	43.7%
Green	1273	42.0%	43.1%

Even though white has a very low share of the metagame at around 35%, it still has the lowest win rate. We can see why when looking at another statistic: the power level of Arena packs when using the average human pick order derived from MTGO drafts:

Color	Average Bot Value	Average Human Value
White	2.15	1.69
Blue	2.47	2.15
Black	2.22	1.88
Red	2.16	1.83
Green	2.35	2.06

In forming this data, we use the same methodology for finding the open colors earlier to value each pack, but then average across all packs from all Arena drafts logged. We compare the value using both the bot pick order and the human pick order. While white, black, and red are relatively close in the value the bots perceive they are passing, humans perceive white to be much worse on average. From humans’ perspective, blue is often the strongest. As a result, it’s generally better to move into blue, even if the bots are making it seem slightly less open.

Summary

There’s a lot we can learn about how to best draft in Arena by looking at data. For the War of the Spark bots, at least, it seems they do send signals worth reading, but it’s best to keep in mind that the signals are relative to the bots’ pick orders, not your own.

Learning from the Best

Fri, 24 Apr 2026 00:00:00 GMT

How do the best play? There have been thousands of articles in Magic across the decades talking about this in some form or fashion, but through the magic of 17Lands we get the pleasure of looking at some aspects of this through a pure factual lens.

We constantly hear people talking about “well that card has a higher win rate, but I see XYZ streamer doesn’t like that card” or “that card has a terrible win rate yet XYZ streamer plays it all the time”. For a while, we’ve wanted to provide a segmented view into the data to help dig into some of this, and today we’re announcing the release of a new cut of data to do just that!

At a high level, we’ve broken down some users into different groupings based on their performance over the last few sets and computed many of our common statistics for each of those groups. You’ll be able to see these cuts of the data as dropdowns on pages you’re familiar with, like the Card Performance and Color Performance pages, and you can get more detail on the methodology on the Metrics Definitions page.

As an example, we can segment data by just top players and compare it to our overall user base. With this, we can see how aggregated data might be hiding the true top-end of a card, as it removes players who are more likely to play the card in situations where they aren’t maximizing its full potential.

Below are some of our key takeaways from this cut of the data.

Top players play checks notes the best cards more often

Shock! Awe! These are the top ten commons and uncommons that top players played more frequently than the average player. “Play Rate” means the # of copies of this per deck, on average, for that group. You can sort of think of it like the fraction of decks that include that card, though it’s also bumped up by decks playing multiple copies.

Card	Play Rate (All)	Play Rate (Top)	Δ Play Rate (Top-All)
Run Out of Town	0.279	0.438	0.158
Make Disappear	0.233	0.357	0.124
Raffine’s Informant	0.459	0.579	0.120
Majestic Metamorphosis	0.301	0.411	0.109
Girder Goons	0.371	0.474	0.102
Inspiring Overseer	0.446	0.520	0.073
Expendable Lackey	0.302	0.374	0.072
Brokers Hideout	0.397	0.464	0.067
Backup Agent	0.370	0.437	0.067
Gathering Throng	0.279	0.345	0.065

Conversely, here are the top ten cards that top players put in their decks less often than the average player. Not exactly a “greatest hits” album:

Card	Play Rate (All)	Play Rate (Top)	Δ Play Rate (Top-All)
Kill Shot	0.159	0.099	-0.059
Midnight Assassin	0.115	0.058	-0.057
Obscura Initiate	0.187	0.130	-0.056
Riveteers Initiate	0.144	0.091	-0.053
Celebrity Fencer	0.118	0.066	-0.051
Witness Protection	0.112	0.065	-0.047
Prizefight	0.190	0.145	-0.044
High-Rise Sawjack	0.124	0.081	-0.042
Deal Gone Bad	0.196	0.155	-0.041
Glittermonger	0.099	0.058	-0.041

If you do a pure card quality analysis and say “how much win rate benefit did the top players gain purely from playing with higher card quality”, you come up with about +0.4% benefit to win rate. That’s not deck building, that’s not being better at playing the game, that’s literally just from putting better cards in their decks. Huge? No. But just another way the best players are creating an uneven playing field for themselves before the match even starts

Top players play situational cards… situationally

These are all cards that top players played at least 2 percentage points less often, but when they did, they got much better (relative) performance out of them than the average player.

Card	Play Rate (All)	Play Rate (Top)	Δ Play Rate (Top-All)	Δ GIH WR (Top-All)
Goldhound	0.128	0.092	-0.036	8.5 percentage points
High-Rise Sawjack	0.124	0.081	-0.042	7.1 pp
Celebrity Fencer	0.118	0.066	-0.051	6.5 pp
Witty Roastmaster	0.159	0.123	-0.035	6.2 pp
Midnight Assassin	0.115	0.058	-0.057	6.2 pp
Shattered Seraph	0.149	0.124	-0.025	6.1 pp
Wrecking Crew	0.104	0.079	-0.024	5.8 pp
Kill Shot	0.159	0.099	-0.059	5.8 pp
Prizefight	0.190	0.145	-0.044	5.7 pp
Witness Protection	0.112	0.065	-0.047	5.7 pp

Here are some thoughts on why they’re able to overperform with some of these situational cards:

Goldhound is an inherently weak card, but it does a lot of small things in synergy with treasures-matter, sacrifice-matters, pump spells to 2-1 with first strike/menace, and also fixes and ramps. None of those things individually makes it worth playing a 1/1, but the best players are finding the right spots where the payoff is “good enough”.
Celebrity Fencer doesn’t do as much as other white 4 drops, but can be a fine finisher in a deck that stabilizes and has tons of token producers. The best players know to cut it from all but the most synergistic decks.
High-Rise Sawjack and Wrecking Crew are other examples of cards that more controlling decks with top end are probably fine playing, but you want to avoid most of the time.
Prizefight can be extremely weak in decks without high toughness spells or treasure synergies.

Overall, every single card on this list is a card that works with some types of decks but needs to be cut from many others, and the best players are making the call to correctly cut the card more often.

Top players get the most out of cards that generate lots of decision points or are challenging to maximize<

Here is a list of the cards where top players got their biggest win rate advantage.

Card	Play Rate (All)	Play Rate (Top)	Δ Play Rate (Top-All)	Δ GIH WR (Top-All)
Goldhound	0.128	0.092	-0.036	8.5 pp
Tavern Swindler	0.016	0.013	-0.003	8.3 pp
Torch Breath	0.080	0.062	-0.017	8.2 pp
Angelic Observer	0.048	0.031	-0.016	7.9 pp
Scuttling Butler	0.021	0.016	-0.005	7.4 pp
High-Rise Sawjack	0.124	0.081	-0.042	7.1 pp
Tainted Indulgence	0.059	0.063	+0.004	7.1 pp
Chrome Cat	0.039	0.039	+0.000	7.0 pp
Refuse to Yield	0.023	0.019	-0.003	6.6 pp
Psionic Snoop	0.076	0.079	+0.003	6.5 pp

What’s my theory on why top players get more out of some of these cards?

Talking about Goldhound again! Ok instead of talking about when to play it, let’s talk about how to play it. It’s a sneakily difficult card to play. In particular, there are likely going to come a few critical turns when it may (or may not) be correct to sac it to ramp into a spell. Best players are making better decisions on these key turns.
Tavern Swindler is a big LOL for me (Carl), in that Garrett Gardner and I just released [an entire podcast about this card](https://mysticaldispute.com/episode/045-mystical-dispute-tavern-swindler-snc/). In it, we believe that players are likely just activating the ability too often, and probably are not just relying on it as a 2/2 body often enough.
Angelic Observer needs a TON of support before the card is playable. My guess is most of this win rate differential is deck building.
Chrome Cat ? It’s a metal cat. Very dense. I don’t know. Scrying is hard?
Refuse to Yield always has the obvious play of untapping your creature and blocking to kill something, but it can be tricky to set up at times, and the best players probably have a better sense of when it’s worth the risk of getting blown out by instant speed removal.

Top players play decks when it’s right to play them

The best players learn what’s best quickly. The plots below show what fraction of games were played with a given deck color, with each plot showing data from a different group. Only a subset of decks are shown for ease of reading. As we can see, the best players were quickest to adapt to how good Brokers and Azorious are and how infrequently you should be in Riveteers in SNC.

Fig. 1: Daily deck popularity in SNC by group

Better players are also earlier to recognize new opportunities due to a shifting metagame. In NEO, for example, the top players found mono-red as an opportunity much earlier than other players.

Fig. 2: Deck popularity in NEO by group

Overall, a lot of these point to one larger conclusion: many of the top players are likely more in-tune with much of the data you can find here on 17Lands. Not only do they use our tools to track their own data, but they also actively analyze which colors to play and which cards to draft based on the generally available data. Accessing our data gives them big insights early on that they can use to gain an advantage over the rest of their competition.

These are just a few of the interesting tidbits unlocked with this new data segmentation. We hope the community will find and share many more insights too!

Two Hard Things in Computer Science

Thu, 23 Apr 2026 00:00:00 GMT

“There are only two hard things in Computer Science: cache invalidation and naming things.”

—Phil Karlton

cache coherence

coherence

Thu, 23 Apr 2026 00:00:00 GMT

Unless care is taken, a coherence problem can arise if multiple actors (e.g., multiple cores) have access to multiple copies of a datum (e.g., in multiple caches) and at least one access is a write.

比如日历的同步，网页的同步等都可以算作考虑coherency的场景。

coherence/consistency 都为一致性，但略有区别

extracted from: cache coherence

A Primer on Memory Consistency and Cache Coherence

Thu, 23 Apr 2026 00:00:00 GMT

A Primer on Memory Consistency and Cache Coherence

ToRead

Cite

Vijay Nagarajan, Daniel J. Sorin, Mark D. Hill, and David A. Wood. 2020. A Primer on Memory Consistency and Cache Coherence. Springer International Publishing, Cham. https://doi.org/10.1007/978-3-031-01764-3

Attachments

全文

Collections

Annotations

As part of this consistency model

support, the hardware provides cache coherence (or coherence).

It is worth stressing that unlike consistency which is an architectural specification that defines shared memory correctness, coherence is a means to supporting a consistency model

Essentially, all of the variants make one processor’s write visible to the other processors by propagating the write to all caches

But protocols differ in when and how the syncing happens. There are two major classes of coherence protocols.

In the second approach, the coherence protocol propagates writes to the caches asynchronously, while still honoring the consistency model.

GPUs originally chose not to support hardware cache coherence, since GPUs are designed for embarrassingly parallel graphics workloads that do not synchronize or share data all that much. However, the absence of hardware cache coherence leads to programmability and/or performance challenges when GPUs are used for general-purpose workloads with fine-grained synchronization and data sharing

We classify these protocols into two categories based on the nature of their coherence interfaces—specifically, based on whether there is a clean separation of coherence from the consistency model or whether they are indivisible.

writes are propagated synchronously, the first category presents an interface that is identical to that of an atomic memory system

The cache coherence protocol abstracts away the caches completely and presents an illusion of atomic memory

In the second, more-recent category, writes are propagated asynchronously—a write can thus return before it has been made visible to all processors, thus allowing for stale values (in real time) to be observed.

coherence protocols in this class must ensure that the order in which writes are

eventually made visible adheres to the ordering rules mandated by the consistency model.

We define coherence through the single-writer–multiple-reader (SWMR) invariant.

note that it is possible to to enforce a variety of consistency models, including strong models such as SC and TSO, using this approach

This invariant states that the value of a memory location at the start of an epoch is the same as the value of the memory location at the end of its last read-write epoch.

must appear to execute all threads’ loads and stores to a single memory location in a total order that respects the program order of each thread

Per-location SC=COH

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.

Power is assumed to be incomparable with respect to Alpha, ARM, RMO, and XC until someone proves that one is more relaxed than the other or that the two are equivalent.

VPS 常见工具

Tue, 21 Apr 2026 00:00:00 GMT

基础防护

创建普通用户，加入sudo组
sshd禁用密码登录、root登录
修改ssh端口为高位
安装fail2ban和ufw，开放80、443

评测

无访问权限

bgp.tools
looking glass: nexttrace/traceroute
disvps看延迟波动、线路等，以及各路评测

有访问权限

IP质量检测脚本 bash <(curl -Ls https://Check.Place) -I
线路质量检测脚本 bash <(curl -Ls Net.Check.Place)
流媒体解锁检测 bash <(curl -L -s check.unlock.media)
硬件检测 bash <(curl -Ls Hardware.Check.Place)

Everything We Know About the MTG Arena Log File in 2026

Mon, 20 Apr 2026 00:00:00 GMT

When I started building Manasight and needed to parse the Arena log file, I based my initial design on existing community documentation. About half of my assumptions turned out to be wrong.

API method names I pulled from older parsers didn’t exist in real logs. Game result detection worked differently than documented. A field I expected to be nested inside another was actually its sibling. An entire parser module I wrote had to be deleted because the log event it targeted doesn’t appear in real Player.log files. Parser projects from 2019–2022 documented a format that has changed substantially since, and community gists reference API endpoints that were removed years ago.

This post is what I wish existed when I started. Everything here has been verified against current Arena logs as of early 2026.

Log File Location

Arena writes a single log file per session. When you close and reopen the game, the previous session’s log is preserved as a backup.

Platform	Log Path
Windows	`%LOCALAPPDATA%Low\Wizards Of The Coast\MTGA\Player.log`
macOS	`~/Library/Logs/Wizards Of The Coast/MTGA/Player.log`
Previous session	Same directory, `Player-prev.log`

Prerequisite: You must enable “Detailed Logs (Plugin Support)” in Options > Account. Without this, the log contains only basic diagnostic output and none of the JSON game data that parsers need. This is the most common reason new users can’t get companion tools working.

The log file used to be called output_log.txt and lived in a different location (renamed in May 2020). If you’re reading older parser code and the paths don’t match, that’s why.

Log Structure

The log isn’t a clean structured format. It’s a mix of plain text diagnostic lines and embedded JSON objects. Game-relevant entries are marked by the [UnityCrossThreadLogger] header prefix. Other bracketed headers appear in the log ([PhysX], [Manifest], [TaskLogger], etc.) but contain engine diagnostics, not game data.

A typical sequence looks like this:

[UnityCrossThreadLogger]3/11/2026 12:34:56 PM
==> EventJoin {"EventName":"QuickDraft_MKM_20260307","Id":"abc123"}

[UnityCrossThreadLogger]3/11/2026 12:35:01 PM
{"greToClientEvent":{"greToClientMessages":[{"type":"GREMessageType_GameStateMessage",...}]}}

JSON payloads can span multiple lines. Parsing requires accumulating lines between header boundaries and extracting JSON using brace-depth counting (tracking open/close braces while respecting string literals). A new [UnityCrossThreadLogger] header signals the end of the previous entry.

Lines before the first [UnityCrossThreadLogger] header in a file are Unity engine boot diagnostics (Mono initialization, GPU info, assembly loading) and should be skipped.

Arena writes timestamps in the user’s locale format. This creates a parsing challenge: the log uses multiple date/time formats depending on the player’s system settings, plus several machine-oriented formats inside JSON payloads.

Formats observed in real logs:

Format	Example	Where
US 12-hour	`3/11/2026 6:08:07 PM`	`[UnityCrossThreadLogger]` header lines
ISO 8601 + Z	`2026-03-11T22:48:34.663Z`	JSON datetime fields (`progressedDateTimeUTC`, `_dailyRewardResetTimestamp`)
ISO 8601 + offset	`2026-03-11T18:25:33.906174-07:00`	JSON `ServerTime`, `lastRemotePing` fields
.NET ticks	`639088754738962389`	ClientToGRE `timestamp` fields
Epoch milliseconds	`1773278674334`	GRE `timestamp` fields

On European-locale systems, header timestamps likely use a day-first format (e.g., 11/03/2026 12:34:56), but I haven’t been able to verify this directly since all my test data comes from a US-locale system.

This ambiguity is problematic: when the day is 12 or less, 3/7/2026 could be March 7 (US) or July 3 (European). There is no reliable way to resolve this from the log alone. My parser uses a US-first convention and accepts the loss for ambiguous dates. When I have EU-based logs to validate with, I am considering updating the parser to take a locale hint to break the tie.

Timestamps appear after the header prefix on the same line. If a header line has no parseable timestamp, store the event without one. Synthetic timestamps break deduplication and chronological ordering.

Client API Messages

Outside of gameplay, the log records REST-style API calls between the Arena client and Wizards’ servers. These handle collection data, events, matchmaking, rank, and inventory.

This is the section most existing documentation gets wrong. Older parsers describe a Namespace.MethodName convention with endpoints like PlayerInventory.GetPlayerInventory and PlayerInventory.GetPlayerCardsV3. Most of those endpoints were removed in the August 2021 breaking change and never restored.

Current logs use an arrow-delimited format:

[UnityCrossThreadLogger]==> EventJoin {"id":"abc123","request":"{\"EventName\":\"QuickDraft_MKM_20260307\"}"}

<== RankGetCombinedRankInfo(e1f2a3b4-5678-90cd-ef12-34567890abcd)
{"constructedClass":"Gold","constructedLevel":2,...}

==> marks a client request. <== marks a server response, followed by a UUID in parentheses (matching the request’s id field) and a JSON payload. Note that ==> lines carry the [UnityCrossThreadLogger] prefix, but <== lines appear bare with no header prefix. Request payloads often contain string-escaped JSON nested inside a request field.

What’s Available in 2026

Direction	Method	What It Contains
`==>`	`EventJoin`	Player joins an event
`==>`	`EventClaimPrize`	Prize claim after an event
`==>`	`EventEnterPairing`	Player enters matchmaking
`<==`	`RankGetCombinedRankInfo`	Constructed and Limited rank, tier, level
`<==`	`StartHook`	Startup data: inventory (gold, gems, wildcards), deck summaries, card metadata, server time
`==>` / `<==`	`DraftCompleteDraft`	Human draft completion (request and response)
`==>` / `<==`	`BotDraftDraftPick`	Bot draft pack presentation and pick selection

StartHook is the primary startup data delivery mechanism. It arrives as a single large response containing InventoryInfo (gold, gems, wildcards, vault progress), DeckSummariesV2, CardMetadataInfo, and a dozen other fields. Notably, the player’s card collection (owned cards) does not appear in any ==> / <== API call in current logs. The old GetPlayerCardsV3 endpoint was removed in August 2021 and was not replaced with an equivalent in this API layer.

A complete catalog of every API method that can appear in the log doesn’t exist. You discover new ones by watching the log during different game activities.

GRE Messages

GRE (Game Rules Engine) messages contain the actual game data: every card, zone, phase transition, and player action. This is what makes deck tracking, action logs, and replay viewers possible.

GRE messages are wrapped in a greToClientEvent envelope:

{
  "greToClientEvent": {
    "greToClientMessages": [
      {
        "type": "GREMessageType_GameStateMessage",
        "gameStateMessage": { ... }
      }
    ]
  }
}

GRE Message Types

Type	Description
`GREMessageType_ConnectResp`	Initial connection response with starting game state
`GREMessageType_GameStateMessage`	Full or partial game state update
`GREMessageType_QueuedGameStateMessage`	Queued state update (same structure as above)
`GREMessageType_TimerStateMessage`	Rope timers and timeout info
`GREMessageType_IntermissionReq`	Between-game transition in Bo3 (contains game result)
`GREMessageType_SubmitDeckReq`	Sideboarding prompt between Bo3 games
`GREMessageType_UIMessage`	UI-related noise
`GREMessageType_SetSettingsResp`	Settings acknowledgment

Client-to-GRE Messages

Player actions also appear in the log:

Type	Description
`ClientMessageType_MulliganResp`	Keep or mulligan decision
`ClientMessageType_SelectNResp`	Card selection (e.g., discard, scry ordering)
`ClientToGREUIMessage`	UI interactions (hover, chat). Noise.

Some client-to-GRE payloads contain string-escaped JSON nested inside JSON. Your parser needs to handle both already-parsed objects and string-encoded payloads that need a second deserialization pass.

GameStateMessage

This is the core data structure. Each GameStateMessage contains some or all of these fields:

{
  "gameStateMessage": {
    "gameObjects": [ ... ],
    "zones": [ ... ],
    "gameInfo": {
      "stage": "GameStage_Play",
      "matchState": "MatchState_GameInProgress"
    },
    "turnInfo": {
      "turnNumber": 3,
      "phase": "Phase_Main1",
      "activePlayer": 1,
      "decisionPlayer": 1
    },
    "annotations": [ ... ],
    "timers": [ ... ],
    "diffDeletedInstanceIds": [ 101, 202 ]
  }
}

Note that turnInfo is a sibling of gameInfo, not nested inside it. I initially had it as gameStateMessage.gameInfo.turnInfo, which returned null every time. This is the kind of structural assumption that only breaks when you test against real data.

Key Fields

**gameObjects**: Every card and permanent in the game. Each object has an instanceId, grpId (the card’s global ID), zoneId, ownerSeatId, controllerSeatId, visibility, cardTypes, subtypes, power, toughness, and more. The name field is a numeric ID, not a human-readable string; card names require a separate database lookup. Tracking zone transitions of game objects is how you build a deck tracker.

**zones**: Library, hand, battlefield, graveyard, exile, stack, and others. Each zone has a zoneId, type (e.g., ZoneType_Hand), ownerSeatId, and objectInstanceIds listing what’s in it.

annotations: Records of game actions: zone transfers, damage, counters, life total changes. The format is less intuitive than you’d expect (see next section).

timers: Rope timer state, timeout counts, priority timing.

diffDeletedInstanceIds: Instance IDs that should be purged from your local game state. When Arena sends incremental updates (not full state snapshots), this field tells you what no longer exists. If you don’t process this, your tracker will show phantom cards.

Full State vs. Incremental Updates

A GameStateMessage can be a full state snapshot or a partial delta containing only what changed. There’s no explicit flag that distinguishes them. In practice, early messages in a game (especially from ConnectResp) tend to be full snapshots, and subsequent messages tend to be deltas. Your parser needs to merge incoming fields into a running game state and remove anything listed in diffDeletedInstanceIds.

Annotations

Annotations record game actions within a GameStateMessage. Their format is worth calling out because it’s less intuitive than the rest of the GRE schema.

You might expect named wrapper objects with camelCase fields. What Arena actually writes:

{
  "id": 47,
  "affectorId": 312,
  "affectedIds": [455],
  "type": ["AnnotationType_ZoneTransfer"],
  "details": [
    { "key": "zone_src", "type": "KeyValuePairValueType_int32", "valueInt32": [29] },
    { "key": "zone_dest", "type": "KeyValuePairValueType_int32", "valueInt32": [31] },
    { "key": "category", "type": "KeyValuePairValueType_string", "valueString": ["PlayLand"] }
  ]
}

Two surprises here. First, type is an array of strings, not a plain string. In every annotation I’ve seen in current logs, it’s a single-element array, but the array wrapper is always present.

Second, the data lives in a uniform details array of key-value pairs, each with a typed value field (valueInt32, valueString, etc.). The key names use snake_case (zone_src, orig_id, new_id), not camelCase. You need helper functions to search the details array by key name.

Annotation types include AnnotationType_ZoneTransfer, AnnotationType_ObjectIdChanged, AnnotationType_ResolutionComplete, AnnotationType_DamageDealt, AnnotationType_ModifiedLife, AnnotationType_CounterAdded, AnnotationType_PhaseOrStepModified, AnnotationType_TappedUntappedPermanent, and others.

Message Batching

This is the implementation detail I most wish someone had told me upfront.

Arena frequently batches multiple GameStateMessage values into a single greToClientMessages array. In my testing across multiple play sessions, over half of all GRE events that contain game state data have two or more GameStateMessage entries bundled together. A single log entry might contain three or four game state updates.

{
  "greToClientEvent": {
    "greToClientMessages": [
      { "type": "GREMessageType_GameStateMessage", "gameStateMessage": { ... } },
      { "type": "GREMessageType_GameStateMessage", "gameStateMessage": { ... } },
      { "type": "GREMessageType_QueuedGameStateMessage", "gameStateMessage": { ... } }
    ]
  }
}

If you use a find-first approach to extract the GameStateMessage from this array, you silently discard the rest. In my case, the parser was missing turn changes, creature deaths, and annotation data until I refactored it to iterate every message in the batch. This was the source of most of my “why is the tracker missing data” bugs.

Match Lifecycle

Match Start

Match boundaries come from matchGameRoomStateChangedEvent JSON entries:

{
  "matchGameRoomStateChangedEvent": {
    "gameRoomInfo": {
      "stateType": "MatchGameRoomStateType_Playing",
      "gameRoomConfig": {
        "matchId": "abc123",
        "eventId": "Constructed_BestOf1",
        "reservedPlayers": [
          { "systemSeatId": 1, "userId": "...", "playerName": "..." },
          { "systemSeatId": 2, "userId": "...", "playerName": "..." }
        ]
      }
    }
  }
}

This gives you the match ID, event type, and both players’ seat assignments.

Game Result

Game results are embedded in GRE GameStateMessage payloads, not in a separate event type. When a game ends, the gameInfo field inside a GameStateMessage transitions to:

{
  "stage": "GameStage_GameOver",
  "matchState": "MatchState_GameComplete",
  "results": [
    { "scope": "MatchScope_Game", "result": "ResultType_WinLoss", "winningTeamId": 1, "reason": "ResultReason_Game" }
  ]
}

There’s a catch: Arena sends two GameStage_GameOver messages per game end. The first has matchState: "MatchState_GameComplete" (game-scope result). The second has matchState: "MatchState_MatchComplete" (match-scope result, which also includes both MatchScope_Game and MatchScope_Match entries). If you emit a game result event for both, you get duplicates. Filter on MatchState_GameComplete and skip MatchState_MatchComplete.

I initially built a separate game result parser around LogBusinessEvents entries with a WinningType field, based on documentation from older parsers. That event never appeared in any real log I tested. The entire module had to be deleted.

Match Complete

Match completion uses the same matchGameRoomStateChangedEvent structure:

{
  "matchGameRoomStateChangedEvent": {
    "gameRoomInfo": {
      "stateType": "MatchGameRoomStateType_MatchCompleted",
      "finalMatchResult": {
        "matchId": "abc123",
        "matchCompletedReason": "MatchCompletedReasonType_Success",
        "resultList": [
          { "scope": "MatchScope_Game", "result": "ResultType_WinLoss", "winningTeamId": 1 },
          { "scope": "MatchScope_Match", "result": "ResultType_WinLoss", "winningTeamId": 1 }
        ]
      }
    }
  }
}

For Bo3 matches, resultList contains one MatchScope_Game entry per game played, plus a final MatchScope_Match entry for the overall result. In a 2-0 match, for example, the list contains three entries: two game-scope results and one match-scope result. Between games, the GRE sends GREMessageType_IntermissionReq (containing the game result) followed by GREMessageType_SubmitDeckReq for sideboarding.

Draft Events

Draft parsing requires handling two completely different log formats depending on the draft type.

Bot Drafts (Quick Draft)

Bot draft messages use a CurrentModule / Payload envelope, where the payload is string-escaped JSON. Pack presentation arrives as a BotDraftDraftPick response:

{
  "CurrentModule": "BotDraft",
  "Payload": "{\"Result\":\"Success\",\"EventName\":\"QuickDraft_ECL_20260223\",\"DraftStatus\":\"PickNext\",\"PackNumber\":0,\"PickNumber\":0,\"NumCardsToPick\":1,\"DraftPack\":[\"98361\",\"98498\",\"98358\",...],\"PickedCards\":[...]}"
}

Note that DraftPack is an array of strings, not integers. Same for PickedCards.

Pick selection is sent as a ==> BotDraftDraftPick request (no underscore) with PickInfo containing the chosen CardIds (plural, an array), PackNumber, and PickNumber:

==> BotDraftDraftPick {"id":"...","request":"{\"EventName\":\"QuickDraft_ECL_20260223\",\"PickInfo\":{\"EventName\":\"QuickDraft_ECL_20260223\",\"CardIds\":[\"98546\"],\"PackNumber\":0,\"PickNumber\":0}}"}

Draft completion for bot drafts does not use DraftCompleteDraft. Instead, the final BotDraftDraftPick response returns "DraftStatus":"Completed" with a full PickedCards array and an empty DraftPack. The response also includes DTO_InventoryInfo with card grant details.

Human Drafts (Premier/Traditional)

Pack presentation uses a Draft.Notify entry with draftId, SelfPack, SelfPick, and PackCards (a comma-separated string of card IDs, not an array). One caveat: the very first pick of pack 1 does not generate a Draft.Notify. The first one appears at SelfPick:2. New packs (pack 2 and pack 3) do generate Draft.Notify for their first pick.

Pick selection arrives as EventPlayerDraftMakePick with DraftId, GrpIds (an array of selected card IDs), Pack, and Pick numbers. In formats that allow picking multiple cards (like Pick Two Draft), GrpIds contains more than one entry.

Draft Completion

Human drafts emit a DraftCompleteDraft entry when the draft finishes. Note the exact name: no underscore between “Draft” and “Complete.” The request contains EventName and IsBotDraft: false in string-escaped JSON. The response includes CourseId, InternalEventName, and CardPool (an array of integer card IDs — the complete pool of drafted cards).

Bot drafts (QuickDraft) do not emit DraftCompleteDraft. Completion is signaled by the final BotDraftDraftPick response with DraftStatus: "Completed" (see above).

Session Events

A few log events track the player session:

Signature	What It Contains
`authenticateResponse`	Login confirmation with `clientId`, `sessionId`, and `screenName`
`FrontDoorConnection.Close`	Logout or disconnect (includes reason, e.g., `"OnDestroy"`)

authenticateResponse is the primary source of player identity. It appears at session start and again on each match server reconnection. Identity data also appears in matchGameRoomStateChangedEvent, where the reservedPlayers array includes userId and playerName for both players in a match.

If you’re building a tool that processes this data, strip or hash identity fields before anything leaves the user’s machine. WotC has been moving in this direction themselves: screen names were removed from most log entries in July 2021, and opponent display name tags were removed in July 2024 (see the breaking changes timeline below). Treat the remaining identity fields as data you have access to, not data you’re entitled to store or transmit.

Gap Between Log and UI

This is what got me interested in the project. Arena has all this data. The log proves it. But the game client surfaces almost none of it:

Win rates: Every match result is logged. Arena never shows your win rate.
Match history: Every game is recorded. Arena shows nothing after you close the results screen.
Action sequences: The GRE logs every trigger, every scry result, every combat step. Arena’s in-game log auto-scrolls and clears within seconds.
Revealed cards: When your opponent plays or reveals a card, the GRE logs the full card data. Arena doesn’t surface a history of what’s been revealed during the current game.

Arena is a game client designed to keep you playing, not to surface analytics. That’s a reasonable design choice, but it means there’s a permanent structural gap between what the game records and what it shows you. That’s what I’m building Manasight to address.

Manasight

The parser described in this post is open source, and it’s the foundation for everything below.

The first thing I’m building is a desktop overlay with a scrollable action log, a deck tracker, and a connection health indicator. The action log will be comprehensive: every spell, trigger, scry result, and combat assignment captured in real time, persistent and searchable instead of flashing on screen and disappearing. After that, turn-by-turn game replays.

Manasight will run on both Windows and Mac, track all formats, and the core features will be free. It’s a lightweight standalone app built with Tauri, not a browser extension.

On data: the same care I described in the session events section will apply to Manasight. You’ll know what’s collected, you’ll be able to turn it off, and delete means delete. The parser is open source so you can verify exactly what it reads.

I’ll be writing more about the technical challenges as I build. If you’re interested in Arena tooling or building on game data, follow along on the blog or on Twitter/X.

Appendix

Breaking Changes

Fair warning: the log format is unstable and has broken without notice before.

In the 2021.8.0.3855 update, Wizards removed several log endpoints without warning:

PlayerInventory.GetPlayerInventory: removed
PlayerInventory.GetPlayerCardsV3: removed
Inventory.Updated: removed
Several draft-related endpoints: removed

Collection tracking, inventory updates, and draft pick logging all broke overnight. A community feedback thread collected over 700 votes. Some data eventually reappeared through different endpoints (inventory now comes through StartHook), but the format changed and old parsers needed rewrites. Card collection data (GetPlayerCardsV3) was not replaced with an equivalent in the current API layer.

That wasn’t an isolated incident. A timeline of data removals:

Date	What Changed
Sept 2019	Vault progress info removed
May 2020	Log file renamed from `output_log.txt` to `Player.log`, path changed
July 2021	Screen name removed from most log entries
Aug 2021	Collection, inventory, and draft endpoints removed (partially restored later in new format)
Aug 2022	MMR/rating data removed
July 2024	Opponent display name tag removed

The trend is clear: Wizards has been reducing the data available in the log over time, not expanding it. If you’re building a tool that depends on the log, design for resilience. Assume any field can disappear in the next patch. Anything your parser extracts today might not be there tomorrow.

Open-Source Parsers

If you’re building something, start by reading existing implementations.

Status as of early 2026:

manasight-parser Rust · Active My project. Verified against current logs. Full GRE, client API, draft, and match lifecycle parsing. MIT/Apache-2.0.

rconroy293/mtga-log-client Python · Active 17Lands’ official client. Clean, focused on draft and game event upload.

gathering-gg/parser Go · Unmaintained (2019) Comprehensively typed. Good for understanding message structures, but the format has changed.

mtgatool/mtgatool-desktop TypeScript · Low activity (last release Oct 2024) Full Electron app with log watcher and message dispatcher.

mtgatracker/mtgatracker Python · Unmaintained (2020) Websocket-based overlay. Historical reference.

Razviar/mtgap TypeScript · Archived (April 2025) MTGA Pro Tracker. Rewrote its parser multiple times as the format evolved.

riQQ/MtgaProto Protobuf · Updated periodically Extracted .proto definitions from Arena’s installation files. Reference, not a parser.

Manasight is not affiliated with, endorsed by, or sponsored by Wizards of the Coast or Hasbro.

Have corrections or additions? I’d love to hear from other developers working in this space.

蔓生庭院

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

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

Commit message with! to draw attention to breaking change

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

Commit message with both! and BREAKING CHANGE footer

Commit message with no body

Commit message with scope

Commit message with multi-paragraph body and multiple footers

Specification

Why Use Conventional Commits

FAQ

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

Are the types in the commit title uppercase or lowercase?

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

Doesn’t this discourage rapid development and fast iteration?

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

How does this relate to SemVer?

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

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

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

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

How does Conventional Commits handle revert commits?

Semantic Versioning 2.0.0

Summary

Introduction

Semantic Versioning Specification (SemVer)

Backus–Naur Form Grammar for Valid SemVer Versions

Why Use Semantic Versioning?

FAQ

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

How do I know when to release 1.0.0?

Doesn’t this discourage rapid development and fast iteration?

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?

Documenting the entire public API is too much work!

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

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

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)?

Dependent Function Type ( $Π$ -Type)

0425 第一抓单抓 1-3

0426 第一抓单抓 3-3

0426 第二抓双抓 3-2

0426 第三抓双抓 4-0

0426 第四抓双抓 4-0

0429 第一抓双抓 1-2

0429 第二抓双抓 1-2

0430 第一抓双抓 0-2

0510 第一抓快抓 5-3