<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Space</title>
  <link href="https://space.torus.icu/"/>
  <link rel="self" href="https://space.torus.icu/atom.xml"/>
  <id>https://space.torus.icu/</id>
  <icon>https://space.torus.icu/static/rss.svg</icon>
  <logo>https://space.torus.icu/static/rss.svg</logo>
  <updated>2026-08-15T00:00:00Z</updated>
  <author><name>berberman</name></author>
  <entry>
    <title>Magical Structure</title>
    <link href="https://space.torus.icu/scribbles/2026-8-15-magical-structure/"/>
    <id>https://space.torus.icu/scribbles/2026-8-15-magical-structure/</id>
    <updated>2026-08-15T00:00:00Z</updated>
    <author><name>berberman</name></author>
    <summary type="text">

今天学习了一些 Lean 4 里 structure elaborator 的实现，
实际上 structure 比预想的要复杂得多！这里记录一些有趣的现象，没用的知识又增加了.jpg。</summary>
  </entry>
  <entry>
    <title>First Scribble</title>
    <link href="https://space.torus.icu/scribbles/2026-8-14-first-scribble/"/>
    <id>https://space.torus.icu/scribbles/2026-8-14-first-scribble/</id>
    <updated>2026-08-14T00:00:00Z</updated>
    <author><name>berberman</name></author>
    <summary type="text">不知不觉距离更新上篇技术性博客已经过去四个月了！
最近一段时间攒起来的想法应该能写出几篇了——
但是想要系统性地把一些知识讲明白、并且组织成条理分明的文章还是很耗时的，
所以就没有投入时间把它们写出来。不过仔细想想，
即使是零散的、未成熟的想法也有分享的价值，并且能督促我时常回顾它们。

因此我打算在这个网站开一个新的“小碎片系列”，平行于其他博客文章。
它基本上是一个公开的 Obsidian/散装的知识库，包括比较随机多草稿和片段。
这些碎片最终会被整理编排成正式的博客文章，大概。
此外，这个系列会保持中文（我太久没有用中文写过东西了……）、使用尽量随意的语言、
并附带上我的个人想法，而非全部中立的陈述。

总之希望这个决定能增加一些更新频率。
目前 Verso 还不支持非英文标题，刚刚提了个 Issue。
维护一个 fork 稍微魔改一下不会很困难，不过还是希望能得到官方支持。

顺带一提，这些碎片会在 Atom feed 上和正式博客交替出现，欢迎点击页脚的 Atom 图标订阅！
</summary>
  </entry>
  <entry>
    <title>More Verso</title>
    <link href="https://space.torus.icu/blog/2026-6-30-more-verso/"/>
    <id>https://space.torus.icu/blog/2026-6-30-more-verso/</id>
    <updated>2026-06-30T00:00:00Z</updated>
    <author><name>berberman</name></author>
    <summary type="text">

This blog has been around for a while, but every time I visited it, something about the visual design felt off.
The typography was not elegant enough; Lean code blocks had no color scheme; the palette lacked quality; and the font size were not quite right.
Overall, the site did not feel modern, and both UI and UX needed work, even though it retained kind of minimalist style. RSS/Atom feeds were also missing.

So I decided to refine the styling on top of existing foundation, and add a few interesting features.</summary>
  </entry>
  <entry>
    <title>Dependent Pattern Matching and Convoy Patterns</title>
    <link href="https://space.torus.icu/blog/2026-4-18-dependent-pattern-matching-and-convoy-patterns/"/>
    <id>https://space.torus.icu/blog/2026-4-18-dependent-pattern-matching-and-convoy-patterns/</id>
    <updated>2026-04-18T00:00:00Z</updated>
    <author><name>berberman</name></author>
    <summary type="text">

One day my friend CircuitCoder asked a Rocq question in a group chat:

How do you prove the following theorem without using the dependent destruction tactic?
  It seems to require the Convoy Pattern, which I tried learning but still don&apos;t quite grasp...



Let&apos;s explore dependent pattern matching and the convoy pattern in Lean!</summary>
  </entry>
  <entry>
    <title>HEq and Axiom K: An Exploration in Lean</title>
    <link href="https://space.torus.icu/blog/2026-2-23-heq-and-axiom-k-an-exploration-in-lean/"/>
    <id>https://space.torus.icu/blog/2026-2-23-heq-and-axiom-k-an-exploration-in-lean/</id>
    <updated>2026-02-23T00:00:00Z</updated>
    <author><name>berberman</name></author>
    <summary type="text">

While reading A Few Constructions on ConstructorsConor McBride, Healfdene Goguen, and James McKinna. 2004. A few constructions on constructors.,
I came across this definition of Heterogeneous Equality (represented here using Lean axioms):</summary>
  </entry>
  <entry>
    <title>Hello Verso</title>
    <link href="https://space.torus.icu/blog/2026-2-14-hello-verso/"/>
    <id>https://space.torus.icu/blog/2026-2-14-hello-verso/</id>
    <updated>2026-02-14T00:00:00Z</updated>
    <author><name>berberman</name></author>
    <summary type="text">

It&apos;s been 6 years since I first built this site using Hakyll—though I barely posted anything.
Recently, I decided to migrate to Verso,
a new static site generator written in Lean. It allows me to write posts directly in Lean and seamlessly integrating code snippets:

theorem Eq.uip {α : Sort u}
    (x y : α) (h₁ h₂ : x = y) : h₁ = h₂ := by
  rfl


#check Nat.succ


Nat.succ (n : Nat) : Nat


I adapted this site from verso-templates,
and with some fine-tuning, I&apos;ve got Prism.js working for non-Lean languages:

</summary>
  </entry>
  <entry>
    <title>Upload Gradle Build Scripts and Android Libraries to GitHub Packages</title>
    <link href="https://space.torus.icu/blog/2023-7-5-upload-gradle-build-scripts-and-android-libraries-to-github-packages/"/>
    <id>https://space.torus.icu/blog/2023-7-5-upload-gradle-build-scripts-and-android-libraries-to-github-packages/</id>
    <updated>2023-07-05T00:00:00Z</updated>
    <author><name>berberman</name></author>
    <summary type="text">This is a simple note I made while I was working on the plugin system in fcitx5-android.
In general, we are using the monorepo policy for this project, which means that the main application and plugins are all in the same git repository
for the sake of reusing build scripts, versions, dependencies, as well as easy for creating releases.
However, recently we decided to make a series of plugins that provide a functionality of shipping data files like Pinyin dictionaries
and table dictionaries to the main program. Obviously, it would be cumbersome to have those plugins with data in our monorepo, and even more they could have different licenses.
So we need an approach to build a plugin application independently from the monorepo, yet reusing the build logic, which is quite complicated
and may deserve a long article to explain. Instead of somehow referencing the build scripts via git submodules, fortunately, GitHub Packages provides a nice maven repository for each organization which we can publish those gradle scripts and libraries to.</summary>
  </entry>
  <entry>
    <title>Default Language Extensions Enabled in GHCi</title>
    <link href="https://space.torus.icu/blog/2021-4-11-default-language-extensions-enabled-in-ghci/"/>
    <id>https://space.torus.icu/blog/2021-4-11-default-language-extensions-enabled-in-ghci/</id>
    <updated>2021-04-11T00:00:00Z</updated>
    <author><name>berberman</name></author>
    <summary type="text">I wrote this post because I stumbled upon the fact that head [] passes type checking in GHCi even with ExtendedDefaultRules disabled.
This surprised me. After some investigation—</summary>
  </entry>
  <entry>
    <title>Setting up a Haskell development environment on Arch Linux</title>
    <link href="https://space.torus.icu/blog/2020-10-27-setting-up-a-haskell-development-environment-on-arch-linux/"/>
    <id>https://space.torus.icu/blog/2020-10-27-setting-up-a-haskell-development-environment-on-arch-linux/</id>
    <updated>2020-10-27T00:00:00Z</updated>
    <author><name>berberman</name></author>
    <summary type="text">Once you accept the principles of Arch Linux -- being simplicity and modernity -- everything goes easier.
In this article, we will use up-to-date Haskell ecosystem by using system provided Haskell packages, getting rid of awkward stack which could eat huge amount of your disk space.
We won&apos;t going to nix or ghcup, since they are both general Haskell toolchain solutions, not specific to Arch Linux.</summary>
  </entry>
</feed>
