The State of Chez Scheme in Debian - weinholt.se

I have uploaded Chez Scheme 10.4.0 to Debian unstable. It has been a<br>few years since there was a new Chez Scheme version in Debian, and<br>that is all on me. 😅

The new release builds fine on all architectures according to<br>the build logs. In case you missed it, Chez Scheme got an<br>infusion of energy from the Racket people and gained portable bytecode<br>support a few years ago. So for those architectures where there is no<br>native backend, Chez instead generates portable bytecode.

There was a problem with m68k and hppa where they would sometimes get<br>the wrong endianness for the portable bytecode, possibly depending on<br>which buildd picked them up. But that should be fixed now as<br>debian/rules constructs the machine type from Debian’s build variables.

Debian Scheme Dream Team

I moved the package to the Debian Scheme Dream Team! So now there are<br>more people who can help maintain it. The team has been gathering some<br>mass recently, which is really nice to see. I hope that together we<br>can make Scheme a stronger language in Debian.

Cross-compilation was broken

I enabled cross-compilation from amd64 to arm64 in<br>the Salsa pipelines and found that it was actually broken!<br>The problem was that cross-compilation kicks off a secondary build<br>where several of our build parameters were missing. So the secondary<br>build couldn’t find zuo and also got the wrong C compiler.

This has been fixed by patching build.zuo. This patch should<br>be upstreamed.

Future work

The chezscheme-dev package is not something I have actually tested<br>myself. It ships libkernel.a, main.o and scheme.h. Could be<br>working, nobody has ever said otherwise. :)

Then there are the portable bytecodes! It would be possible to de-dupe<br>those in the archive. They could be built as Architecture: all<br>packages and be reused. Now, e.g., sparc64 and ppc64 both build<br>threaded 64-bit big endian bytecode, so those exist at least twice in<br>the archive.

Reproducible builds

Last, but not<br>least, Chez Scheme builds are not reproducible. This is<br>becoming a real problem now<br>because<br>Debian’s release team has made reproducible builds mandatory.<br>Chez Scheme will not be part of future Debian releases unless this<br>gets fixed.

Thankfully it does seem to be fixable. The root of the problem is that<br>unique identifiers are used to support separate compilation. If<br>anyone’s interested in the background then they can check<br>out Oscar Waddell’s Ph.D. thesis (warning: .ps.gz file).

The implementation described in Section 3.5 supports both internal<br>and top-level modules. For internal modules, the new names<br>generated by the expander must be locally unique, i.e., not<br>otherwise visible within the same top-level expression. For<br>top-level modules within a single compilation unit, the names must<br>be unique within the compilation unit. When multiple compilation<br>units may be linked together, the names must be unique across<br>compilation units.

– Oscar Waddell, Extending the Scope of Syntactic Abstraction, §3.6.1

Chez Scheme generates a UUID for each session that gets embedded into<br>gensyms and that then gets embedded into the code. This satisfies the<br>need for unique identifiers that are different between separate<br>compilations. It ensures that things work smoothly when you are using<br>the compiler yourself. But we want reproducible builds, meaning<br>byte-for-byte identical builds, so the UUID is a problem.

When building packages for Linux distributions, things are a bit<br>different than when you’re using the compiler yourself. Our build<br>system can tell us what code went into the build, including the<br>dependencies that brought in Scheme code, and if those stay the same<br>then there is no need to use different identifiers compared to the<br>previous time we built the same code.

I’m toying with the idea of generating a session key from the package<br>version numbers and passing it to configure. I think it can be done<br>without changing anything outside of the build system (the Zuo code).<br>Conceptually we would be doing this:

(#%$set-top-level-value! '$session-key "k-")<br>(compile-file "s/foo.ss")

It remains to be seen if this is enough or if there are other sources<br>of non-determinism.