The shared conformance corpus, read and run against this client#19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
tamnd merged 8 commits into from
Aug 24, 2026
Merged

The shared conformance corpus, read and run against this client #19

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
ddff050
A reader for the corpus files
tamnd Aug 24, 2026
2129a93
The temporal half of the corpus encoding
tamnd Aug 24, 2026
d26585a
The value half of the corpus encoding
tamnd Aug 24, 2026
c412de2
Reading a result as Arrow through the C Data Interface
tamnd Aug 24, 2026
eeb31fa
The case model and what a corpus file may say
tamnd Aug 24, 2026
48eb24a
The runner and the command that runs the corpus
tamnd Aug 24, 2026
2effe7e
The tests for the runner, and the corpus itself
tamnd Aug 24, 2026
9d17c84
Run the corpus in CI, and say how to run it by hand
tamnd Aug 24, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 53 additions & 0 deletions .github/workflows/ci.yml
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -127,6 +127,59 @@ jobs:

- run: java -jar zudb-bench/target/benchmarks.jar -f 1 -wi 1 -i 1 -r 1s -w 1s

# The cross client corpus, run against the engine this job builds.
# Every client answers the same fourteen hundred cases and a report is
# diffed line for line against the other four, so this is the job that
# says this client agrees with them rather than only with itself.
#
# The cases come from the same checkout the library was built from,
# which is the pairing that makes the report mean anything. A corpus
# ahead of the library reports the engine catching up to its own cases
# as this client failing, and a library ahead of the corpus reports
# nothing at all. This client builds the engine rather than shipping an
# archive of it, so both are the same checkout and there is no revision
# to pin.
#
# A job of its own rather than a step in the one above, because the run
# is fourteen hundred databases and the job above runs its suite three
# times.
corpus:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5

- uses: actions/checkout@v5
with:
repository: tamnd/zu
path: engine

- uses: actions/setup-java@v5
with:
distribution: temurin
java-version: "25"
cache: maven

- uses: Swatinem/rust-cache@v2
with:
workspaces: engine

- name: Build libzu
working-directory: engine
run: cargo build --release -p zu-capi

- name: Where the library landed
run: |
set -eu
lib="$(ls engine/target/release/libzu.so)"
test -n "$lib"
echo "ZU_LIBRARY=$GITHUB_WORKSPACE/$lib" >> "$GITHUB_ENV"

# Verbose, because the run logs every case the engine has not
# caught up to and a release branch is read for exactly that.
- run: mvn $MAVEN_ARGS -pl zudb-corpus -am test -Dsurefire.useFile=false
env:
ZU_CASES: ${{ github.workspace }}/engine/conformance/cases

# The JNI provider on the JDKs it exists for. Panama is not there on
# 17 or 21, so on those two this is the only way to call the engine at
# all, and a client that claims 17 and is only ever tested on 25 is a
Expand Down
12 changes: 12 additions & 0 deletions README.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -360,6 +360,17 @@ ZU_LIBRARY=/path/to/libzu.dylib java -jar zudb-bench/target/benchmarks.jar

`ZU_LIBRARY` rather than `-Dzu.library` there, because JMH forks a JVM of its own and a fork inherits the environment rather than the system properties.

The cross client corpus is a directory of cases in the engine's repository, versioned with it and answered by every client in the family. It is a command as well as a test:

```sh
mvn -pl zudb-corpus -am package -DskipTests
ZU_LIBRARY=/path/to/libzu.dylib java --enable-native-access=ALL-UNNAMED \
-cp "zudb/target/classes:zudb-ffm/target/classes:zudb-corpus/target/classes" \
dev.zudb.corpus.Main /path/to/zu/conformance/cases
```

It prints a line per case that did not pass and then a summary, and the lines are the reference runner's word for word so that two clients disagreeing is a diff. `-strict` makes a case the engine has not caught up to fail the run, which is what a release branch wants, and `-work` keeps the databases rather than removing them. The same run happens under `mvn test` when `ZU_CASES` points at the cases, and skips when it does not, so a checkout of this repository alone is still green.

The leak run is a script rather than a test, because what reads the result is the allocator rather than an assertion:

```sh
Expand DownExpand Up@@ -404,6 +415,7 @@ Inside this repository:
| The Panama provider | `zudb-ffm` |
| The JNI provider, and the C shim it calls through | `zudb-jni` |
| The cases every provider owes, run by both of them | `zudb-tck` |
| The cross client corpus, read and run against this client | `zudb-corpus` |
| Arrow, over the C Data Interface | `zudb-arrow` |
| JMH benchmarks | `zudb-bench` |
| The staged libraries, built by the release rather than by a clone | `zudb-native` |
Expand Down
1 change: 1 addition & 0 deletions pom.xml
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -51,6 +51,7 @@
<module>zudb</module>
<module>zudb-tck</module>
<module>zudb-ffm</module>
<module>zudb-corpus</module>
<module>zudb-jni</module>
<module>zudb-arrow</module>
<module>zudb-bench</module>
Expand Down
84 changes: 84 additions & 0 deletions zudb-corpus/pom.xml
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
The shared conformance corpus, run through this client.

The corpus is a directory of YAML files versioned with the engine and
shipped to every client in the family. A case is a statement and what
running it must produce, so it is a corpus every client can run and no
client has to have written.

These are main sources for the same reason zudb-tck's are: a test
source set is not something another module can depend on without a
test jar, and this one is both a command a person runs against a
corpus directory and a fixture a test can call. Nothing here is
published.

It compiles to 25 rather than to the 17 the API targets, because
reading a result as Arrow through the C Data Interface is what the
Arrow half of the corpus asks for, and doing that without a dependency
on arrow-java wants java.lang.foreign.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<parent>
<groupId>dev.zudb</groupId>
<artifactId>zudb-parent</artifactId>
<version>0.11.0-SNAPSHOT</version>
</parent>

<artifactId>zudb-corpus</artifactId>
<name>zu for the JVM: the shared corpus</name>
<description>The conformance corpus the engine and every other client run, read and run here.</description>

<dependencies>
<dependency>
<groupId>dev.zudb</groupId>
<artifactId>zudb</artifactId>
</dependency>
<!-- A provider at test scope and not at compile scope, because this
module is the API and the corpus and neither of them picks a
provider. Somebody running the command puts one on the path
alongside a library, the same choice they make for their own
program. The tests need one to run at all, and the FFM provider is
the one that fits: this module already compiles to 25 for the sake
of reading a result through the C Data Interface. -->
<dependency>
<groupId>dev.zudb</groupId>
<artifactId>zudb-ffm</artifactId>
<version>${project.version}</version>
<scope>test</scope>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<release>${zu.release.ffm}</release>
<compilerArgs>
<arg>-Xlint:all,-requires-automatic,-requires-transitive-automatic</arg>
<arg>-Werror</arg>
</compilerArgs>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<!-- On the class path and not the module path, because this is
a command a person runs and the way it is run is a class
path with a provider and a library on it. The grant names
the unnamed module for the same reason, and it is the
grant the README tells that person to pass. -->
<useModulePath>false</useModulePath>
<argLine>--enable-native-access=ALL-UNNAMED ${zu.test.args}</argLine>
</configuration>
</plugin>
</plugins>
</build>
</project>
Loading
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
The shared conformance corpus, read and run against this client#19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

tamnd
merged 8 commits into

from

Aug 24, 2026
 Merged


The shared conformance corpus, read and run against this client
#19
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


8 commits


Select commit
Hold shift + click to select a range
ddff050

A reader for the corpus files


tamnd Aug 24, 2026
2129a93

The temporal half of the corpus encoding


tamnd Aug 24, 2026
d26585a

The value half of the corpus encoding


tamnd Aug 24, 2026
c412de2

Reading a result as Arrow through the C Data Interface


tamnd Aug 24, 2026
eeb31fa

The case model and what a corpus file may say


tamnd Aug 24, 2026
48eb24a

The runner and the command that runs the corpus


tamnd Aug 24, 2026
2effe7e

The tests for the runner, and the corpus itself


tamnd Aug 24, 2026
9d17c84

Run the corpus in CI, and say how to run it by hand


tamnd Aug 24, 2026

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


53 changes: 53 additions & 0 deletions
.github/workflows/ci.yml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -127,6 +127,59 @@ jobs:

 - run: java -jar zudb-bench/target/benchmarks.jar -f 1 -wi 1 -i 1 -r 1s -w 1s

 # The cross client corpus, run against the engine this job builds.
 # Every client answers the same fourteen hundred cases and a report is
 # diffed line for line against the other four, so this is the job that
 # says this client agrees with them rather than only with itself.
 #
 # The cases come from the same checkout the library was built from,
 # which is the pairing that makes the report mean anything. A corpus
 # ahead of the library reports the engine catching up to its own cases
 # as this client failing, and a library ahead of the corpus reports
 # nothing at all. This client builds the engine rather than shipping an
 # archive of it, so both are the same checkout and there is no revision
 # to pin.
 #
 # A job of its own rather than a step in the one above, because the run
 # is fourteen hundred databases and the job above runs its suite three
 # times.
 corpus:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v5

 - uses: actions/checkout@v5
 with:
 repository: tamnd/zu
 path: engine

 - uses: actions/setup-java@v5
 with:
 distribution: temurin
 java-version: "25"
 cache: maven

 - uses: Swatinem/rust-cache@v2
 with:
 workspaces: engine

 - name: Build libzu
 working-directory: engine
 run: cargo build --release -p zu-capi

 - name: Where the library landed
 run: |
 set -eu
 lib="$(ls engine/target/release/libzu.so)"
 test -n "$lib"
 echo "ZU_LIBRARY=$GITHUB_WORKSPACE/$lib" >> "$GITHUB_ENV"

 # Verbose, because the run logs every case the engine has not
 # caught up to and a release branch is read for exactly that.
 - run: mvn $MAVEN_ARGS -pl zudb-corpus -am test -Dsurefire.useFile=false
 env:
 ZU_CASES: ${{ github.workspace }}/engine/conformance/cases

 # The JNI provider on the JDKs it exists for. Panama is not there on
 # 17 or 21, so on those two this is the only way to call the engine at
 # all, and a client that claims 17 and is only ever tested on 25 is a
Expand Down

12 changes: 12 additions & 0 deletions
README.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -360,6 +360,17 @@ ZU_LIBRARY=/path/to/libzu.dylib java -jar zudb-bench/target/benchmarks.jar

`ZU_LIBRARY` rather than `-Dzu.library` there, because JMH forks a JVM of its own and a fork inherits the environment rather than the system properties.

The cross client corpus is a directory of cases in the engine's repository, versioned with it and answered by every client in the family. It is a command as well as a test:

```sh
mvn -pl zudb-corpus -am package -DskipTests
ZU_LIBRARY=/path/to/libzu.dylib java --enable-native-access=ALL-UNNAMED \
 -cp "zudb/target/classes:zudb-ffm/target/classes:zudb-corpus/target/classes" \
 dev.zudb.corpus.Main /path/to/zu/conformance/cases
```

It prints a line per case that did not pass and then a summary, and the lines are the reference runner's word for word so that two clients disagreeing is a diff. `-strict` makes a case the engine has not caught up to fail the run, which is what a release branch wants, and `-work` keeps the databases rather than removing them. The same run happens under `mvn test` when `ZU_CASES` points at the cases, and skips when it does not, so a checkout of this repository alone is still green.

The leak run is a script rather than a test, because what reads the result is the allocator rather than an assertion:

```sh
Expand DownExpand Up@@ -404,6 +415,7 @@ Inside this repository:
| The Panama provider | `zudb-ffm` |
| The JNI provider, and the C shim it calls through | `zudb-jni` |
| The cases every provider owes, run by both of them | `zudb-tck` |
| The cross client corpus, read and run against this client | `zudb-corpus` |
| Arrow, over the C Data Interface | `zudb-arrow` |
| JMH benchmarks | `zudb-bench` |
| The staged libraries, built by the release rather than by a clone | `zudb-native` |
Expand Down

1 change: 1 addition & 0 deletions
pom.xml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -51,6 +51,7 @@
 <module>zudb</module>
 <module>zudb-tck</module>
 <module>zudb-ffm</module>
 <module>zudb-corpus</module>
 <module>zudb-jni</module>
 <module>zudb-arrow</module>
 <module>zudb-bench</module>
Expand Down

84 changes: 84 additions & 0 deletions
zudb-corpus/pom.xml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
 The shared conformance corpus, run through this client.

 The corpus is a directory of YAML files versioned with the engine and
 shipped to every client in the family. A case is a statement and what
 running it must produce, so it is a corpus every client can run and no
 client has to have written.

 These are main sources for the same reason zudb-tck's are: a test
 source set is not something another module can depend on without a
 test jar, and this one is both a command a person runs against a
 corpus directory and a fixture a test can call. Nothing here is
 published.

 It compiles to 25 rather than to the 17 the API targets, because
 reading a result as Arrow through the C Data Interface is what the
 Arrow half of the corpus asks for, and doing that without a dependency
 on arrow-java wants java.lang.foreign.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>

 <parent>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb-parent</artifactId>
 <version>0.11.0-SNAPSHOT</version>
 </parent>

 <artifactId>zudb-corpus</artifactId>
 <name>zu for the JVM: the shared corpus</name>
 <description>The conformance corpus the engine and every other client run, read and run here.</description>

 <dependencies>
 <dependency>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb</artifactId>
 </dependency>
 <!-- A provider at test scope and not at compile scope, because this
 module is the API and the corpus and neither of them picks a
 provider. Somebody running the command puts one on the path
 alongside a library, the same choice they make for their own
 program. The tests need one to run at all, and the FFM provider is
 the one that fits: this module already compiles to 25 for the sake
 of reading a result through the C Data Interface. -->
 <dependency>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb-ffm</artifactId>
 <version>${project.version}</version>
 <scope>test</scope>
 </dependency>
 </dependencies>

 <build>
 <plugins>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-compiler-plugin</artifactId>
 <configuration>
 <release>${zu.release.ffm}</release>
 <compilerArgs>
 <arg>-Xlint:all,-requires-automatic,-requires-transitive-automatic</arg>
 <arg>-Werror</arg>
 </compilerArgs>
 </configuration>
 </plugin>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-surefire-plugin</artifactId>
 <configuration>
 <!-- On the class path and not the module path, because this is
 a command a person runs and the way it is run is a class
 path with a provider and a library on it. The grant names
 the unnamed module for the same reason, and it is the
 grant the README tells that person to pass. -->
 <useModulePath>false</useModulePath>
 <argLine>--enable-native-access=ALL-UNNAMED ${zu.test.args}</argLine>
 </configuration>
 </plugin>
 </plugins>
 </build>
</project>
Loading
Loading

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
The shared conformance corpus, read and run against this client#19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

tamnd
merged 8 commits into

from

Aug 24, 2026
 Merged


The shared conformance corpus, read and run against this client
#19
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


8 commits


Select commit
Hold shift + click to select a range
ddff050

A reader for the corpus files


tamnd Aug 24, 2026
2129a93

The temporal half of the corpus encoding


tamnd Aug 24, 2026
d26585a

The value half of the corpus encoding


tamnd Aug 24, 2026
c412de2

Reading a result as Arrow through the C Data Interface


tamnd Aug 24, 2026
eeb31fa

The case model and what a corpus file may say


tamnd Aug 24, 2026
48eb24a

The runner and the command that runs the corpus


tamnd Aug 24, 2026
2effe7e

The tests for the runner, and the corpus itself


tamnd Aug 24, 2026
9d17c84

Run the corpus in CI, and say how to run it by hand


tamnd Aug 24, 2026

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


53 changes: 53 additions & 0 deletions
.github/workflows/ci.yml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -127,6 +127,59 @@ jobs:

 - run: java -jar zudb-bench/target/benchmarks.jar -f 1 -wi 1 -i 1 -r 1s -w 1s

 # The cross client corpus, run against the engine this job builds.
 # Every client answers the same fourteen hundred cases and a report is
 # diffed line for line against the other four, so this is the job that
 # says this client agrees with them rather than only with itself.
 #
 # The cases come from the same checkout the library was built from,
 # which is the pairing that makes the report mean anything. A corpus
 # ahead of the library reports the engine catching up to its own cases
 # as this client failing, and a library ahead of the corpus reports
 # nothing at all. This client builds the engine rather than shipping an
 # archive of it, so both are the same checkout and there is no revision
 # to pin.
 #
 # A job of its own rather than a step in the one above, because the run
 # is fourteen hundred databases and the job above runs its suite three
 # times.
 corpus:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v5

 - uses: actions/checkout@v5
 with:
 repository: tamnd/zu
 path: engine

 - uses: actions/setup-java@v5
 with:
 distribution: temurin
 java-version: "25"
 cache: maven

 - uses: Swatinem/rust-cache@v2
 with:
 workspaces: engine

 - name: Build libzu
 working-directory: engine
 run: cargo build --release -p zu-capi

 - name: Where the library landed
 run: |
 set -eu
 lib="$(ls engine/target/release/libzu.so)"
 test -n "$lib"
 echo "ZU_LIBRARY=$GITHUB_WORKSPACE/$lib" >> "$GITHUB_ENV"

 # Verbose, because the run logs every case the engine has not
 # caught up to and a release branch is read for exactly that.
 - run: mvn $MAVEN_ARGS -pl zudb-corpus -am test -Dsurefire.useFile=false
 env:
 ZU_CASES: ${{ github.workspace }}/engine/conformance/cases

 # The JNI provider on the JDKs it exists for. Panama is not there on
 # 17 or 21, so on those two this is the only way to call the engine at
 # all, and a client that claims 17 and is only ever tested on 25 is a
Expand Down

12 changes: 12 additions & 0 deletions
README.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -360,6 +360,17 @@ ZU_LIBRARY=/path/to/libzu.dylib java -jar zudb-bench/target/benchmarks.jar

`ZU_LIBRARY` rather than `-Dzu.library` there, because JMH forks a JVM of its own and a fork inherits the environment rather than the system properties.

The cross client corpus is a directory of cases in the engine's repository, versioned with it and answered by every client in the family. It is a command as well as a test:

```sh
mvn -pl zudb-corpus -am package -DskipTests
ZU_LIBRARY=/path/to/libzu.dylib java --enable-native-access=ALL-UNNAMED \
 -cp "zudb/target/classes:zudb-ffm/target/classes:zudb-corpus/target/classes" \
 dev.zudb.corpus.Main /path/to/zu/conformance/cases
```

It prints a line per case that did not pass and then a summary, and the lines are the reference runner's word for word so that two clients disagreeing is a diff. `-strict` makes a case the engine has not caught up to fail the run, which is what a release branch wants, and `-work` keeps the databases rather than removing them. The same run happens under `mvn test` when `ZU_CASES` points at the cases, and skips when it does not, so a checkout of this repository alone is still green.

The leak run is a script rather than a test, because what reads the result is the allocator rather than an assertion:

```sh
Expand DownExpand Up@@ -404,6 +415,7 @@ Inside this repository:
| The Panama provider | `zudb-ffm` |
| The JNI provider, and the C shim it calls through | `zudb-jni` |
| The cases every provider owes, run by both of them | `zudb-tck` |
| The cross client corpus, read and run against this client | `zudb-corpus` |
| Arrow, over the C Data Interface | `zudb-arrow` |
| JMH benchmarks | `zudb-bench` |
| The staged libraries, built by the release rather than by a clone | `zudb-native` |
Expand Down

1 change: 1 addition & 0 deletions
pom.xml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -51,6 +51,7 @@
 <module>zudb</module>
 <module>zudb-tck</module>
 <module>zudb-ffm</module>
 <module>zudb-corpus</module>
 <module>zudb-jni</module>
 <module>zudb-arrow</module>
 <module>zudb-bench</module>
Expand Down

84 changes: 84 additions & 0 deletions
zudb-corpus/pom.xml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
 The shared conformance corpus, run through this client.

 The corpus is a directory of YAML files versioned with the engine and
 shipped to every client in the family. A case is a statement and what
 running it must produce, so it is a corpus every client can run and no
 client has to have written.

 These are main sources for the same reason zudb-tck's are: a test
 source set is not something another module can depend on without a
 test jar, and this one is both a command a person runs against a
 corpus directory and a fixture a test can call. Nothing here is
 published.

 It compiles to 25 rather than to the 17 the API targets, because
 reading a result as Arrow through the C Data Interface is what the
 Arrow half of the corpus asks for, and doing that without a dependency
 on arrow-java wants java.lang.foreign.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>

 <parent>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb-parent</artifactId>
 <version>0.11.0-SNAPSHOT</version>
 </parent>

 <artifactId>zudb-corpus</artifactId>
 <name>zu for the JVM: the shared corpus</name>
 <description>The conformance corpus the engine and every other client run, read and run here.</description>

 <dependencies>
 <dependency>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb</artifactId>
 </dependency>
 <!-- A provider at test scope and not at compile scope, because this
 module is the API and the corpus and neither of them picks a
 provider. Somebody running the command puts one on the path
 alongside a library, the same choice they make for their own
 program. The tests need one to run at all, and the FFM provider is
 the one that fits: this module already compiles to 25 for the sake
 of reading a result through the C Data Interface. -->
 <dependency>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb-ffm</artifactId>
 <version>${project.version}</version>
 <scope>test</scope>
 </dependency>
 </dependencies>

 <build>
 <plugins>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-compiler-plugin</artifactId>
 <configuration>
 <release>${zu.release.ffm}</release>
 <compilerArgs>
 <arg>-Xlint:all,-requires-automatic,-requires-transitive-automatic</arg>
 <arg>-Werror</arg>
 </compilerArgs>
 </configuration>
 </plugin>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-surefire-plugin</artifactId>
 <configuration>
 <!-- On the class path and not the module path, because this is
 a command a person runs and the way it is run is a class
 path with a provider and a library on it. The grant names
 the unnamed module for the same reason, and it is the
 grant the README tells that person to pass. -->
 <useModulePath>false</useModulePath>
 <argLine>--enable-native-access=ALL-UNNAMED ${zu.test.args}</argLine>
 </configuration>
 </plugin>
 </plugins>
 </build>
</project>
Loading
Loading

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
The shared conformance corpus, read and run against this client#19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

tamnd
merged 8 commits into

from

Aug 24, 2026
 Merged


The shared conformance corpus, read and run against this client
#19
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


8 commits


Select commit
Hold shift + click to select a range
ddff050

A reader for the corpus files


tamnd Aug 24, 2026
2129a93

The temporal half of the corpus encoding


tamnd Aug 24, 2026
d26585a

The value half of the corpus encoding


tamnd Aug 24, 2026
c412de2

Reading a result as Arrow through the C Data Interface


tamnd Aug 24, 2026
eeb31fa

The case model and what a corpus file may say


tamnd Aug 24, 2026
48eb24a

The runner and the command that runs the corpus


tamnd Aug 24, 2026
2effe7e

The tests for the runner, and the corpus itself


tamnd Aug 24, 2026
9d17c84

Run the corpus in CI, and say how to run it by hand


tamnd Aug 24, 2026

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


53 changes: 53 additions & 0 deletions
.github/workflows/ci.yml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -127,6 +127,59 @@ jobs:

 - run: java -jar zudb-bench/target/benchmarks.jar -f 1 -wi 1 -i 1 -r 1s -w 1s

 # The cross client corpus, run against the engine this job builds.
 # Every client answers the same fourteen hundred cases and a report is
 # diffed line for line against the other four, so this is the job that
 # says this client agrees with them rather than only with itself.
 #
 # The cases come from the same checkout the library was built from,
 # which is the pairing that makes the report mean anything. A corpus
 # ahead of the library reports the engine catching up to its own cases
 # as this client failing, and a library ahead of the corpus reports
 # nothing at all. This client builds the engine rather than shipping an
 # archive of it, so both are the same checkout and there is no revision
 # to pin.
 #
 # A job of its own rather than a step in the one above, because the run
 # is fourteen hundred databases and the job above runs its suite three
 # times.
 corpus:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v5

 - uses: actions/checkout@v5
 with:
 repository: tamnd/zu
 path: engine

 - uses: actions/setup-java@v5
 with:
 distribution: temurin
 java-version: "25"
 cache: maven

 - uses: Swatinem/rust-cache@v2
 with:
 workspaces: engine

 - name: Build libzu
 working-directory: engine
 run: cargo build --release -p zu-capi

 - name: Where the library landed
 run: |
 set -eu
 lib="$(ls engine/target/release/libzu.so)"
 test -n "$lib"
 echo "ZU_LIBRARY=$GITHUB_WORKSPACE/$lib" >> "$GITHUB_ENV"

 # Verbose, because the run logs every case the engine has not
 # caught up to and a release branch is read for exactly that.
 - run: mvn $MAVEN_ARGS -pl zudb-corpus -am test -Dsurefire.useFile=false
 env:
 ZU_CASES: ${{ github.workspace }}/engine/conformance/cases

 # The JNI provider on the JDKs it exists for. Panama is not there on
 # 17 or 21, so on those two this is the only way to call the engine at
 # all, and a client that claims 17 and is only ever tested on 25 is a
Expand Down

12 changes: 12 additions & 0 deletions
README.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -360,6 +360,17 @@ ZU_LIBRARY=/path/to/libzu.dylib java -jar zudb-bench/target/benchmarks.jar

`ZU_LIBRARY` rather than `-Dzu.library` there, because JMH forks a JVM of its own and a fork inherits the environment rather than the system properties.

The cross client corpus is a directory of cases in the engine's repository, versioned with it and answered by every client in the family. It is a command as well as a test:

```sh
mvn -pl zudb-corpus -am package -DskipTests
ZU_LIBRARY=/path/to/libzu.dylib java --enable-native-access=ALL-UNNAMED \
 -cp "zudb/target/classes:zudb-ffm/target/classes:zudb-corpus/target/classes" \
 dev.zudb.corpus.Main /path/to/zu/conformance/cases
```

It prints a line per case that did not pass and then a summary, and the lines are the reference runner's word for word so that two clients disagreeing is a diff. `-strict` makes a case the engine has not caught up to fail the run, which is what a release branch wants, and `-work` keeps the databases rather than removing them. The same run happens under `mvn test` when `ZU_CASES` points at the cases, and skips when it does not, so a checkout of this repository alone is still green.

The leak run is a script rather than a test, because what reads the result is the allocator rather than an assertion:

```sh
Expand DownExpand Up@@ -404,6 +415,7 @@ Inside this repository:
| The Panama provider | `zudb-ffm` |
| The JNI provider, and the C shim it calls through | `zudb-jni` |
| The cases every provider owes, run by both of them | `zudb-tck` |
| The cross client corpus, read and run against this client | `zudb-corpus` |
| Arrow, over the C Data Interface | `zudb-arrow` |
| JMH benchmarks | `zudb-bench` |
| The staged libraries, built by the release rather than by a clone | `zudb-native` |
Expand Down

1 change: 1 addition & 0 deletions
pom.xml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -51,6 +51,7 @@
 <module>zudb</module>
 <module>zudb-tck</module>
 <module>zudb-ffm</module>
 <module>zudb-corpus</module>
 <module>zudb-jni</module>
 <module>zudb-arrow</module>
 <module>zudb-bench</module>
Expand Down

84 changes: 84 additions & 0 deletions
zudb-corpus/pom.xml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
 The shared conformance corpus, run through this client.

 The corpus is a directory of YAML files versioned with the engine and
 shipped to every client in the family. A case is a statement and what
 running it must produce, so it is a corpus every client can run and no
 client has to have written.

 These are main sources for the same reason zudb-tck's are: a test
 source set is not something another module can depend on without a
 test jar, and this one is both a command a person runs against a
 corpus directory and a fixture a test can call. Nothing here is
 published.

 It compiles to 25 rather than to the 17 the API targets, because
 reading a result as Arrow through the C Data Interface is what the
 Arrow half of the corpus asks for, and doing that without a dependency
 on arrow-java wants java.lang.foreign.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>

 <parent>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb-parent</artifactId>
 <version>0.11.0-SNAPSHOT</version>
 </parent>

 <artifactId>zudb-corpus</artifactId>
 <name>zu for the JVM: the shared corpus</name>
 <description>The conformance corpus the engine and every other client run, read and run here.</description>

 <dependencies>
 <dependency>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb</artifactId>
 </dependency>
 <!-- A provider at test scope and not at compile scope, because this
 module is the API and the corpus and neither of them picks a
 provider. Somebody running the command puts one on the path
 alongside a library, the same choice they make for their own
 program. The tests need one to run at all, and the FFM provider is
 the one that fits: this module already compiles to 25 for the sake
 of reading a result through the C Data Interface. -->
 <dependency>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb-ffm</artifactId>
 <version>${project.version}</version>
 <scope>test</scope>
 </dependency>
 </dependencies>

 <build>
 <plugins>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-compiler-plugin</artifactId>
 <configuration>
 <release>${zu.release.ffm}</release>
 <compilerArgs>
 <arg>-Xlint:all,-requires-automatic,-requires-transitive-automatic</arg>
 <arg>-Werror</arg>
 </compilerArgs>
 </configuration>
 </plugin>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-surefire-plugin</artifactId>
 <configuration>
 <!-- On the class path and not the module path, because this is
 a command a person runs and the way it is run is a class
 path with a provider and a library on it. The grant names
 the unnamed module for the same reason, and it is the
 grant the README tells that person to pass. -->
 <useModulePath>false</useModulePath>
 <argLine>--enable-native-access=ALL-UNNAMED ${zu.test.args}</argLine>
 </configuration>
 </plugin>
 </plugins>
 </build>
</project>
Loading
Loading

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
The shared conformance corpus, read and run against this client#19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

tamnd
merged 8 commits into

from

Aug 24, 2026
 Merged


The shared conformance corpus, read and run against this client
#19
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


8 commits


Select commit
Hold shift + click to select a range
ddff050

A reader for the corpus files


tamnd Aug 24, 2026
2129a93

The temporal half of the corpus encoding


tamnd Aug 24, 2026
d26585a

The value half of the corpus encoding


tamnd Aug 24, 2026
c412de2

Reading a result as Arrow through the C Data Interface


tamnd Aug 24, 2026
eeb31fa

The case model and what a corpus file may say


tamnd Aug 24, 2026
48eb24a

The runner and the command that runs the corpus


tamnd Aug 24, 2026
2effe7e

The tests for the runner, and the corpus itself


tamnd Aug 24, 2026
9d17c84

Run the corpus in CI, and say how to run it by hand


tamnd Aug 24, 2026

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


53 changes: 53 additions & 0 deletions
.github/workflows/ci.yml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -127,6 +127,59 @@ jobs:

 - run: java -jar zudb-bench/target/benchmarks.jar -f 1 -wi 1 -i 1 -r 1s -w 1s

 # The cross client corpus, run against the engine this job builds.
 # Every client answers the same fourteen hundred cases and a report is
 # diffed line for line against the other four, so this is the job that
 # says this client agrees with them rather than only with itself.
 #
 # The cases come from the same checkout the library was built from,
 # which is the pairing that makes the report mean anything. A corpus
 # ahead of the library reports the engine catching up to its own cases
 # as this client failing, and a library ahead of the corpus reports
 # nothing at all. This client builds the engine rather than shipping an
 # archive of it, so both are the same checkout and there is no revision
 # to pin.
 #
 # A job of its own rather than a step in the one above, because the run
 # is fourteen hundred databases and the job above runs its suite three
 # times.
 corpus:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v5

 - uses: actions/checkout@v5
 with:
 repository: tamnd/zu
 path: engine

 - uses: actions/setup-java@v5
 with:
 distribution: temurin
 java-version: "25"
 cache: maven

 - uses: Swatinem/rust-cache@v2
 with:
 workspaces: engine

 - name: Build libzu
 working-directory: engine
 run: cargo build --release -p zu-capi

 - name: Where the library landed
 run: |
 set -eu
 lib="$(ls engine/target/release/libzu.so)"
 test -n "$lib"
 echo "ZU_LIBRARY=$GITHUB_WORKSPACE/$lib" >> "$GITHUB_ENV"

 # Verbose, because the run logs every case the engine has not
 # caught up to and a release branch is read for exactly that.
 - run: mvn $MAVEN_ARGS -pl zudb-corpus -am test -Dsurefire.useFile=false
 env:
 ZU_CASES: ${{ github.workspace }}/engine/conformance/cases

 # The JNI provider on the JDKs it exists for. Panama is not there on
 # 17 or 21, so on those two this is the only way to call the engine at
 # all, and a client that claims 17 and is only ever tested on 25 is a
Expand Down

12 changes: 12 additions & 0 deletions
README.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -360,6 +360,17 @@ ZU_LIBRARY=/path/to/libzu.dylib java -jar zudb-bench/target/benchmarks.jar

`ZU_LIBRARY` rather than `-Dzu.library` there, because JMH forks a JVM of its own and a fork inherits the environment rather than the system properties.

The cross client corpus is a directory of cases in the engine's repository, versioned with it and answered by every client in the family. It is a command as well as a test:

```sh
mvn -pl zudb-corpus -am package -DskipTests
ZU_LIBRARY=/path/to/libzu.dylib java --enable-native-access=ALL-UNNAMED \
 -cp "zudb/target/classes:zudb-ffm/target/classes:zudb-corpus/target/classes" \
 dev.zudb.corpus.Main /path/to/zu/conformance/cases
```

It prints a line per case that did not pass and then a summary, and the lines are the reference runner's word for word so that two clients disagreeing is a diff. `-strict` makes a case the engine has not caught up to fail the run, which is what a release branch wants, and `-work` keeps the databases rather than removing them. The same run happens under `mvn test` when `ZU_CASES` points at the cases, and skips when it does not, so a checkout of this repository alone is still green.

The leak run is a script rather than a test, because what reads the result is the allocator rather than an assertion:

```sh
Expand DownExpand Up@@ -404,6 +415,7 @@ Inside this repository:
| The Panama provider | `zudb-ffm` |
| The JNI provider, and the C shim it calls through | `zudb-jni` |
| The cases every provider owes, run by both of them | `zudb-tck` |
| The cross client corpus, read and run against this client | `zudb-corpus` |
| Arrow, over the C Data Interface | `zudb-arrow` |
| JMH benchmarks | `zudb-bench` |
| The staged libraries, built by the release rather than by a clone | `zudb-native` |
Expand Down

1 change: 1 addition & 0 deletions
pom.xml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -51,6 +51,7 @@
 <module>zudb</module>
 <module>zudb-tck</module>
 <module>zudb-ffm</module>
 <module>zudb-corpus</module>
 <module>zudb-jni</module>
 <module>zudb-arrow</module>
 <module>zudb-bench</module>
Expand Down

84 changes: 84 additions & 0 deletions
zudb-corpus/pom.xml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
 The shared conformance corpus, run through this client.

 The corpus is a directory of YAML files versioned with the engine and
 shipped to every client in the family. A case is a statement and what
 running it must produce, so it is a corpus every client can run and no
 client has to have written.

 These are main sources for the same reason zudb-tck's are: a test
 source set is not something another module can depend on without a
 test jar, and this one is both a command a person runs against a
 corpus directory and a fixture a test can call. Nothing here is
 published.

 It compiles to 25 rather than to the 17 the API targets, because
 reading a result as Arrow through the C Data Interface is what the
 Arrow half of the corpus asks for, and doing that without a dependency
 on arrow-java wants java.lang.foreign.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>

 <parent>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb-parent</artifactId>
 <version>0.11.0-SNAPSHOT</version>
 </parent>

 <artifactId>zudb-corpus</artifactId>
 <name>zu for the JVM: the shared corpus</name>
 <description>The conformance corpus the engine and every other client run, read and run here.</description>

 <dependencies>
 <dependency>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb</artifactId>
 </dependency>
 <!-- A provider at test scope and not at compile scope, because this
 module is the API and the corpus and neither of them picks a
 provider. Somebody running the command puts one on the path
 alongside a library, the same choice they make for their own
 program. The tests need one to run at all, and the FFM provider is
 the one that fits: this module already compiles to 25 for the sake
 of reading a result through the C Data Interface. -->
 <dependency>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb-ffm</artifactId>
 <version>${project.version}</version>
 <scope>test</scope>
 </dependency>
 </dependencies>

 <build>
 <plugins>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-compiler-plugin</artifactId>
 <configuration>
 <release>${zu.release.ffm}</release>
 <compilerArgs>
 <arg>-Xlint:all,-requires-automatic,-requires-transitive-automatic</arg>
 <arg>-Werror</arg>
 </compilerArgs>
 </configuration>
 </plugin>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-surefire-plugin</artifactId>
 <configuration>
 <!-- On the class path and not the module path, because this is
 a command a person runs and the way it is run is a class
 path with a provider and a library on it. The grant names
 the unnamed module for the same reason, and it is the
 grant the README tells that person to pass. -->
 <useModulePath>false</useModulePath>
 <argLine>--enable-native-access=ALL-UNNAMED ${zu.test.args}</argLine>
 </configuration>
 </plugin>
 </plugins>
 </build>
</project>
Loading
Loading

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
The shared conformance corpus, read and run against this client#19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

tamnd
merged 8 commits into

from

Aug 24, 2026
 Merged


The shared conformance corpus, read and run against this client
#19
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


8 commits


Select commit
Hold shift + click to select a range
ddff050

A reader for the corpus files


tamnd Aug 24, 2026
2129a93

The temporal half of the corpus encoding


tamnd Aug 24, 2026
d26585a

The value half of the corpus encoding


tamnd Aug 24, 2026
c412de2

Reading a result as Arrow through the C Data Interface


tamnd Aug 24, 2026
eeb31fa

The case model and what a corpus file may say


tamnd Aug 24, 2026
48eb24a

The runner and the command that runs the corpus


tamnd Aug 24, 2026
2effe7e

The tests for the runner, and the corpus itself


tamnd Aug 24, 2026
9d17c84

Run the corpus in CI, and say how to run it by hand


tamnd Aug 24, 2026

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


53 changes: 53 additions & 0 deletions
.github/workflows/ci.yml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -127,6 +127,59 @@ jobs:

 - run: java -jar zudb-bench/target/benchmarks.jar -f 1 -wi 1 -i 1 -r 1s -w 1s

 # The cross client corpus, run against the engine this job builds.
 # Every client answers the same fourteen hundred cases and a report is
 # diffed line for line against the other four, so this is the job that
 # says this client agrees with them rather than only with itself.
 #
 # The cases come from the same checkout the library was built from,
 # which is the pairing that makes the report mean anything. A corpus
 # ahead of the library reports the engine catching up to its own cases
 # as this client failing, and a library ahead of the corpus reports
 # nothing at all. This client builds the engine rather than shipping an
 # archive of it, so both are the same checkout and there is no revision
 # to pin.
 #
 # A job of its own rather than a step in the one above, because the run
 # is fourteen hundred databases and the job above runs its suite three
 # times.
 corpus:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v5

 - uses: actions/checkout@v5
 with:
 repository: tamnd/zu
 path: engine

 - uses: actions/setup-java@v5
 with:
 distribution: temurin
 java-version: "25"
 cache: maven

 - uses: Swatinem/rust-cache@v2
 with:
 workspaces: engine

 - name: Build libzu
 working-directory: engine
 run: cargo build --release -p zu-capi

 - name: Where the library landed
 run: |
 set -eu
 lib="$(ls engine/target/release/libzu.so)"
 test -n "$lib"
 echo "ZU_LIBRARY=$GITHUB_WORKSPACE/$lib" >> "$GITHUB_ENV"

 # Verbose, because the run logs every case the engine has not
 # caught up to and a release branch is read for exactly that.
 - run: mvn $MAVEN_ARGS -pl zudb-corpus -am test -Dsurefire.useFile=false
 env:
 ZU_CASES: ${{ github.workspace }}/engine/conformance/cases

 # The JNI provider on the JDKs it exists for. Panama is not there on
 # 17 or 21, so on those two this is the only way to call the engine at
 # all, and a client that claims 17 and is only ever tested on 25 is a
Expand Down

12 changes: 12 additions & 0 deletions
README.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -360,6 +360,17 @@ ZU_LIBRARY=/path/to/libzu.dylib java -jar zudb-bench/target/benchmarks.jar

`ZU_LIBRARY` rather than `-Dzu.library` there, because JMH forks a JVM of its own and a fork inherits the environment rather than the system properties.

The cross client corpus is a directory of cases in the engine's repository, versioned with it and answered by every client in the family. It is a command as well as a test:

```sh
mvn -pl zudb-corpus -am package -DskipTests
ZU_LIBRARY=/path/to/libzu.dylib java --enable-native-access=ALL-UNNAMED \
 -cp "zudb/target/classes:zudb-ffm/target/classes:zudb-corpus/target/classes" \
 dev.zudb.corpus.Main /path/to/zu/conformance/cases
```

It prints a line per case that did not pass and then a summary, and the lines are the reference runner's word for word so that two clients disagreeing is a diff. `-strict` makes a case the engine has not caught up to fail the run, which is what a release branch wants, and `-work` keeps the databases rather than removing them. The same run happens under `mvn test` when `ZU_CASES` points at the cases, and skips when it does not, so a checkout of this repository alone is still green.

The leak run is a script rather than a test, because what reads the result is the allocator rather than an assertion:

```sh
Expand DownExpand Up@@ -404,6 +415,7 @@ Inside this repository:
| The Panama provider | `zudb-ffm` |
| The JNI provider, and the C shim it calls through | `zudb-jni` |
| The cases every provider owes, run by both of them | `zudb-tck` |
| The cross client corpus, read and run against this client | `zudb-corpus` |
| Arrow, over the C Data Interface | `zudb-arrow` |
| JMH benchmarks | `zudb-bench` |
| The staged libraries, built by the release rather than by a clone | `zudb-native` |
Expand Down

1 change: 1 addition & 0 deletions
pom.xml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -51,6 +51,7 @@
 <module>zudb</module>
 <module>zudb-tck</module>
 <module>zudb-ffm</module>
 <module>zudb-corpus</module>
 <module>zudb-jni</module>
 <module>zudb-arrow</module>
 <module>zudb-bench</module>
Expand Down

84 changes: 84 additions & 0 deletions
zudb-corpus/pom.xml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
 The shared conformance corpus, run through this client.

 The corpus is a directory of YAML files versioned with the engine and
 shipped to every client in the family. A case is a statement and what
 running it must produce, so it is a corpus every client can run and no
 client has to have written.

 These are main sources for the same reason zudb-tck's are: a test
 source set is not something another module can depend on without a
 test jar, and this one is both a command a person runs against a
 corpus directory and a fixture a test can call. Nothing here is
 published.

 It compiles to 25 rather than to the 17 the API targets, because
 reading a result as Arrow through the C Data Interface is what the
 Arrow half of the corpus asks for, and doing that without a dependency
 on arrow-java wants java.lang.foreign.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>

 <parent>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb-parent</artifactId>
 <version>0.11.0-SNAPSHOT</version>
 </parent>

 <artifactId>zudb-corpus</artifactId>
 <name>zu for the JVM: the shared corpus</name>
 <description>The conformance corpus the engine and every other client run, read and run here.</description>

 <dependencies>
 <dependency>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb</artifactId>
 </dependency>
 <!-- A provider at test scope and not at compile scope, because this
 module is the API and the corpus and neither of them picks a
 provider. Somebody running the command puts one on the path
 alongside a library, the same choice they make for their own
 program. The tests need one to run at all, and the FFM provider is
 the one that fits: this module already compiles to 25 for the sake
 of reading a result through the C Data Interface. -->
 <dependency>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb-ffm</artifactId>
 <version>${project.version}</version>
 <scope>test</scope>
 </dependency>
 </dependencies>

 <build>
 <plugins>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-compiler-plugin</artifactId>
 <configuration>
 <release>${zu.release.ffm}</release>
 <compilerArgs>
 <arg>-Xlint:all,-requires-automatic,-requires-transitive-automatic</arg>
 <arg>-Werror</arg>
 </compilerArgs>
 </configuration>
 </plugin>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-surefire-plugin</artifactId>
 <configuration>
 <!-- On the class path and not the module path, because this is
 a command a person runs and the way it is run is a class
 path with a provider and a library on it. The grant names
 the unnamed module for the same reason, and it is the
 grant the README tells that person to pass. -->
 <useModulePath>false</useModulePath>
 <argLine>--enable-native-access=ALL-UNNAMED ${zu.test.args}</argLine>
 </configuration>
 </plugin>
 </plugins>
 </build>
</project>
Loading
Loading

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
The shared conformance corpus, read and run against this client#19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

tamnd
merged 8 commits into

from

Aug 24, 2026
 Merged


The shared conformance corpus, read and run against this client
#19
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


8 commits


Select commit
Hold shift + click to select a range
ddff050

A reader for the corpus files


tamnd Aug 24, 2026
2129a93

The temporal half of the corpus encoding


tamnd Aug 24, 2026
d26585a

The value half of the corpus encoding


tamnd Aug 24, 2026
c412de2

Reading a result as Arrow through the C Data Interface


tamnd Aug 24, 2026
eeb31fa

The case model and what a corpus file may say


tamnd Aug 24, 2026
48eb24a

The runner and the command that runs the corpus


tamnd Aug 24, 2026
2effe7e

The tests for the runner, and the corpus itself


tamnd Aug 24, 2026
9d17c84

Run the corpus in CI, and say how to run it by hand


tamnd Aug 24, 2026

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


53 changes: 53 additions & 0 deletions
.github/workflows/ci.yml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -127,6 +127,59 @@ jobs:

 - run: java -jar zudb-bench/target/benchmarks.jar -f 1 -wi 1 -i 1 -r 1s -w 1s

 # The cross client corpus, run against the engine this job builds.
 # Every client answers the same fourteen hundred cases and a report is
 # diffed line for line against the other four, so this is the job that
 # says this client agrees with them rather than only with itself.
 #
 # The cases come from the same checkout the library was built from,
 # which is the pairing that makes the report mean anything. A corpus
 # ahead of the library reports the engine catching up to its own cases
 # as this client failing, and a library ahead of the corpus reports
 # nothing at all. This client builds the engine rather than shipping an
 # archive of it, so both are the same checkout and there is no revision
 # to pin.
 #
 # A job of its own rather than a step in the one above, because the run
 # is fourteen hundred databases and the job above runs its suite three
 # times.
 corpus:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v5

 - uses: actions/checkout@v5
 with:
 repository: tamnd/zu
 path: engine

 - uses: actions/setup-java@v5
 with:
 distribution: temurin
 java-version: "25"
 cache: maven

 - uses: Swatinem/rust-cache@v2
 with:
 workspaces: engine

 - name: Build libzu
 working-directory: engine
 run: cargo build --release -p zu-capi

 - name: Where the library landed
 run: |
 set -eu
 lib="$(ls engine/target/release/libzu.so)"
 test -n "$lib"
 echo "ZU_LIBRARY=$GITHUB_WORKSPACE/$lib" >> "$GITHUB_ENV"

 # Verbose, because the run logs every case the engine has not
 # caught up to and a release branch is read for exactly that.
 - run: mvn $MAVEN_ARGS -pl zudb-corpus -am test -Dsurefire.useFile=false
 env:
 ZU_CASES: ${{ github.workspace }}/engine/conformance/cases

 # The JNI provider on the JDKs it exists for. Panama is not there on
 # 17 or 21, so on those two this is the only way to call the engine at
 # all, and a client that claims 17 and is only ever tested on 25 is a
Expand Down

12 changes: 12 additions & 0 deletions
README.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -360,6 +360,17 @@ ZU_LIBRARY=/path/to/libzu.dylib java -jar zudb-bench/target/benchmarks.jar

`ZU_LIBRARY` rather than `-Dzu.library` there, because JMH forks a JVM of its own and a fork inherits the environment rather than the system properties.

The cross client corpus is a directory of cases in the engine's repository, versioned with it and answered by every client in the family. It is a command as well as a test:

```sh
mvn -pl zudb-corpus -am package -DskipTests
ZU_LIBRARY=/path/to/libzu.dylib java --enable-native-access=ALL-UNNAMED \
 -cp "zudb/target/classes:zudb-ffm/target/classes:zudb-corpus/target/classes" \
 dev.zudb.corpus.Main /path/to/zu/conformance/cases
```

It prints a line per case that did not pass and then a summary, and the lines are the reference runner's word for word so that two clients disagreeing is a diff. `-strict` makes a case the engine has not caught up to fail the run, which is what a release branch wants, and `-work` keeps the databases rather than removing them. The same run happens under `mvn test` when `ZU_CASES` points at the cases, and skips when it does not, so a checkout of this repository alone is still green.

The leak run is a script rather than a test, because what reads the result is the allocator rather than an assertion:

```sh
Expand DownExpand Up@@ -404,6 +415,7 @@ Inside this repository:
| The Panama provider | `zudb-ffm` |
| The JNI provider, and the C shim it calls through | `zudb-jni` |
| The cases every provider owes, run by both of them | `zudb-tck` |
| The cross client corpus, read and run against this client | `zudb-corpus` |
| Arrow, over the C Data Interface | `zudb-arrow` |
| JMH benchmarks | `zudb-bench` |
| The staged libraries, built by the release rather than by a clone | `zudb-native` |
Expand Down

1 change: 1 addition & 0 deletions
pom.xml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -51,6 +51,7 @@
 <module>zudb</module>
 <module>zudb-tck</module>
 <module>zudb-ffm</module>
 <module>zudb-corpus</module>
 <module>zudb-jni</module>
 <module>zudb-arrow</module>
 <module>zudb-bench</module>
Expand Down

84 changes: 84 additions & 0 deletions
zudb-corpus/pom.xml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
 The shared conformance corpus, run through this client.

 The corpus is a directory of YAML files versioned with the engine and
 shipped to every client in the family. A case is a statement and what
 running it must produce, so it is a corpus every client can run and no
 client has to have written.

 These are main sources for the same reason zudb-tck's are: a test
 source set is not something another module can depend on without a
 test jar, and this one is both a command a person runs against a
 corpus directory and a fixture a test can call. Nothing here is
 published.

 It compiles to 25 rather than to the 17 the API targets, because
 reading a result as Arrow through the C Data Interface is what the
 Arrow half of the corpus asks for, and doing that without a dependency
 on arrow-java wants java.lang.foreign.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>

 <parent>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb-parent</artifactId>
 <version>0.11.0-SNAPSHOT</version>
 </parent>

 <artifactId>zudb-corpus</artifactId>
 <name>zu for the JVM: the shared corpus</name>
 <description>The conformance corpus the engine and every other client run, read and run here.</description>

 <dependencies>
 <dependency>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb</artifactId>
 </dependency>
 <!-- A provider at test scope and not at compile scope, because this
 module is the API and the corpus and neither of them picks a
 provider. Somebody running the command puts one on the path
 alongside a library, the same choice they make for their own
 program. The tests need one to run at all, and the FFM provider is
 the one that fits: this module already compiles to 25 for the sake
 of reading a result through the C Data Interface. -->
 <dependency>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb-ffm</artifactId>
 <version>${project.version}</version>
 <scope>test</scope>
 </dependency>
 </dependencies>

 <build>
 <plugins>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-compiler-plugin</artifactId>
 <configuration>
 <release>${zu.release.ffm}</release>
 <compilerArgs>
 <arg>-Xlint:all,-requires-automatic,-requires-transitive-automatic</arg>
 <arg>-Werror</arg>
 </compilerArgs>
 </configuration>
 </plugin>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-surefire-plugin</artifactId>
 <configuration>
 <!-- On the class path and not the module path, because this is
 a command a person runs and the way it is run is a class
 path with a provider and a library on it. The grant names
 the unnamed module for the same reason, and it is the
 grant the README tells that person to pass. -->
 <useModulePath>false</useModulePath>
 <argLine>--enable-native-access=ALL-UNNAMED ${zu.test.args}</argLine>
 </configuration>
 </plugin>
 </plugins>
 </build>
</project>
Loading
Loading

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
The shared conformance corpus, read and run against this client#19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

tamnd
merged 8 commits into

from

Aug 24, 2026
 Merged


The shared conformance corpus, read and run against this client
#19
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


8 commits


Select commit
Hold shift + click to select a range
ddff050

A reader for the corpus files


tamnd Aug 24, 2026
2129a93

The temporal half of the corpus encoding


tamnd Aug 24, 2026
d26585a

The value half of the corpus encoding


tamnd Aug 24, 2026
c412de2

Reading a result as Arrow through the C Data Interface


tamnd Aug 24, 2026
eeb31fa

The case model and what a corpus file may say


tamnd Aug 24, 2026
48eb24a

The runner and the command that runs the corpus


tamnd Aug 24, 2026
2effe7e

The tests for the runner, and the corpus itself


tamnd Aug 24, 2026
9d17c84

Run the corpus in CI, and say how to run it by hand


tamnd Aug 24, 2026

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


53 changes: 53 additions & 0 deletions
.github/workflows/ci.yml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -127,6 +127,59 @@ jobs:

 - run: java -jar zudb-bench/target/benchmarks.jar -f 1 -wi 1 -i 1 -r 1s -w 1s

 # The cross client corpus, run against the engine this job builds.
 # Every client answers the same fourteen hundred cases and a report is
 # diffed line for line against the other four, so this is the job that
 # says this client agrees with them rather than only with itself.
 #
 # The cases come from the same checkout the library was built from,
 # which is the pairing that makes the report mean anything. A corpus
 # ahead of the library reports the engine catching up to its own cases
 # as this client failing, and a library ahead of the corpus reports
 # nothing at all. This client builds the engine rather than shipping an
 # archive of it, so both are the same checkout and there is no revision
 # to pin.
 #
 # A job of its own rather than a step in the one above, because the run
 # is fourteen hundred databases and the job above runs its suite three
 # times.
 corpus:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v5

 - uses: actions/checkout@v5
 with:
 repository: tamnd/zu
 path: engine

 - uses: actions/setup-java@v5
 with:
 distribution: temurin
 java-version: "25"
 cache: maven

 - uses: Swatinem/rust-cache@v2
 with:
 workspaces: engine

 - name: Build libzu
 working-directory: engine
 run: cargo build --release -p zu-capi

 - name: Where the library landed
 run: |
 set -eu
 lib="$(ls engine/target/release/libzu.so)"
 test -n "$lib"
 echo "ZU_LIBRARY=$GITHUB_WORKSPACE/$lib" >> "$GITHUB_ENV"

 # Verbose, because the run logs every case the engine has not
 # caught up to and a release branch is read for exactly that.
 - run: mvn $MAVEN_ARGS -pl zudb-corpus -am test -Dsurefire.useFile=false
 env:
 ZU_CASES: ${{ github.workspace }}/engine/conformance/cases

 # The JNI provider on the JDKs it exists for. Panama is not there on
 # 17 or 21, so on those two this is the only way to call the engine at
 # all, and a client that claims 17 and is only ever tested on 25 is a
Expand Down

12 changes: 12 additions & 0 deletions
README.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -360,6 +360,17 @@ ZU_LIBRARY=/path/to/libzu.dylib java -jar zudb-bench/target/benchmarks.jar

`ZU_LIBRARY` rather than `-Dzu.library` there, because JMH forks a JVM of its own and a fork inherits the environment rather than the system properties.

The cross client corpus is a directory of cases in the engine's repository, versioned with it and answered by every client in the family. It is a command as well as a test:

```sh
mvn -pl zudb-corpus -am package -DskipTests
ZU_LIBRARY=/path/to/libzu.dylib java --enable-native-access=ALL-UNNAMED \
 -cp "zudb/target/classes:zudb-ffm/target/classes:zudb-corpus/target/classes" \
 dev.zudb.corpus.Main /path/to/zu/conformance/cases
```

It prints a line per case that did not pass and then a summary, and the lines are the reference runner's word for word so that two clients disagreeing is a diff. `-strict` makes a case the engine has not caught up to fail the run, which is what a release branch wants, and `-work` keeps the databases rather than removing them. The same run happens under `mvn test` when `ZU_CASES` points at the cases, and skips when it does not, so a checkout of this repository alone is still green.

The leak run is a script rather than a test, because what reads the result is the allocator rather than an assertion:

```sh
Expand DownExpand Up@@ -404,6 +415,7 @@ Inside this repository:
| The Panama provider | `zudb-ffm` |
| The JNI provider, and the C shim it calls through | `zudb-jni` |
| The cases every provider owes, run by both of them | `zudb-tck` |
| The cross client corpus, read and run against this client | `zudb-corpus` |
| Arrow, over the C Data Interface | `zudb-arrow` |
| JMH benchmarks | `zudb-bench` |
| The staged libraries, built by the release rather than by a clone | `zudb-native` |
Expand Down

1 change: 1 addition & 0 deletions
pom.xml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -51,6 +51,7 @@
 <module>zudb</module>
 <module>zudb-tck</module>
 <module>zudb-ffm</module>
 <module>zudb-corpus</module>
 <module>zudb-jni</module>
 <module>zudb-arrow</module>
 <module>zudb-bench</module>
Expand Down

84 changes: 84 additions & 0 deletions
zudb-corpus/pom.xml

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
 The shared conformance corpus, run through this client.

 The corpus is a directory of YAML files versioned with the engine and
 shipped to every client in the family. A case is a statement and what
 running it must produce, so it is a corpus every client can run and no
 client has to have written.

 These are main sources for the same reason zudb-tck's are: a test
 source set is not something another module can depend on without a
 test jar, and this one is both a command a person runs against a
 corpus directory and a fixture a test can call. Nothing here is
 published.

 It compiles to 25 rather than to the 17 the API targets, because
 reading a result as Arrow through the C Data Interface is what the
 Arrow half of the corpus asks for, and doing that without a dependency
 on arrow-java wants java.lang.foreign.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>

 <parent>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb-parent</artifactId>
 <version>0.11.0-SNAPSHOT</version>
 </parent>

 <artifactId>zudb-corpus</artifactId>
 <name>zu for the JVM: the shared corpus</name>
 <description>The conformance corpus the engine and every other client run, read and run here.</description>

 <dependencies>
 <dependency>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb</artifactId>
 </dependency>
 <!-- A provider at test scope and not at compile scope, because this
 module is the API and the corpus and neither of them picks a
 provider. Somebody running the command puts one on the path
 alongside a library, the same choice they make for their own
 program. The tests need one to run at all, and the FFM provider is
 the one that fits: this module already compiles to 25 for the sake
 of reading a result through the C Data Interface. -->
 <dependency>
 <groupId>dev.zudb</groupId>
 <artifactId>zudb-ffm</artifactId>
 <version>${project.version}</version>
 <scope>test</scope>
 </dependency>
 </dependencies>

 <build>
 <plugins>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-compiler-plugin</artifactId>
 <configuration>
 <release>${zu.release.ffm}</release>
 <compilerArgs>
 <arg>-Xlint:all,-requires-automatic,-requires-transitive-automatic</arg>
 <arg>-Werror</arg>
 </compilerArgs>
 </configuration>
 </plugin>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-surefire-plugin</artifactId>
 <configuration>
 <!-- On the class path and not the module path, because this is
 a command a person runs and the way it is run is a class
 path with a provider and a library on it. The grant names
 the unnamed module for the same reason, and it is the
 grant the README tells that person to pass. -->
 <useModulePath>false</useModulePath>
 <argLine>--enable-native-access=ALL-UNNAMED ${zu.test.args}</argLine>
 </configuration>
 </plugin>
 </plugins>
 </build>
</project>
Loading
Loading