Package: racket Version: 8.7+dfsg1-1 Severity: normal Dear Maintainer,
Since at least Racket 8.6, the Racket CS implementation runs even on
architectures for which it cannot generate native code. I suggest that the
Debian should package Racket CS for all architectures instead of falling back
to Racket BC for some, e.g. ppc64el.
I don't fully understand the nuances of the bookworm freeze policy. (I'm sorry
I didn't report this sooner.) It seems at least plausible that this could be a
"small, targeted fix[]", especially from the perspective that it would amount
to bringing a few niche architectures to parity with the popular ones, but I
could also understand an argument to the contrary.
Some background: Racket CS (based on "Chez Scheme") is the current default
implementation, having replaced Racket BC ("Before Chez" or "ByteCode") with
the release of Racket 8.0. Racket CS, like Chez Scheme, compiles to machine
code, whereas Racket BC compiles to platform-independent bytecode. Initially,
the recommendation from upstream was to fall back to Racket BC on
architectures which Racket CS didn't support: Debian's packaging did so as of
8.0+dfsg1-2 and 8.0+dfsg1-3.
However, Racket CS is now able to run even on architectures for which it
cannot generate machine code. Initially, support for a "portable bytecode"
backend was added to Racket's variant of Chez Scheme to simplify bootstrapping
during development. Later, variants specialized to word size and endianness
were added (e.g. "tpb64l", suitable for any 64-bit little-endian machine), as
was basic support for chunks of this byte code to C (which was useful for Chez
"boot files"). These improvements are sometimes referred to as "pbarch" and
"pbchunk", respectively.
Ultimately, this worked well enough to make Racket CS viable on architectures
without native compilation support. Performance is reportedly comparable to
Racket BC on those architectures, which never had JIT support on Racket BC.
Changing to Racket CS also enables Racket's "futures" and "places" for those
architectures. Perhaps the most significant benefit, albeit less concrete, is
getting those niche architectures onto the Racket implementation that is
actively developed and used.
The new support was announced with the Racket 8.5 release, but a few pieces
turned out to be missing: there's some discussion at [1]. I maintain the Guix
package of Racket, and we enabled Racket CS on all architectures starting with
Racket 8.6, in particular in [2] and [3]. (Our patches were complicated by the
fact that we expose some of Racket's internals in ways Debian doesn't.)
I'd be glad to help with this as I can, with the caveats that I have very
little time until next week, don't have any relevant hardware, and have only
the tiniest amount of experience with Debian packaging (though I'm a long-time
user of Debian and downstreams).
Thanks for maintaining Racket in Debian!
Philip McGrath
[1]: https://racket.discourse.group/t/950/27
[2]: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a15d72f
[3]: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ed24d6b
signature.asc
Description: This is a digitally signed message part.
