Please let us know when platforms specific packages have been updated to 8.12!
The Void linux package has already been updated: https://voidlinux.org/packages/?arch=x86_64&q=Racket thank you !
Please let us know when platforms specific packages have been updated to 8.12!
The Void linux package has already been updated: https://voidlinux.org/packages/?arch=x86_64&q=Racket thank you !
The snap is building now. It should go live soon.
Thank oyu @zyga - I can see https://snapcraft.io/racket is now 8.12
These package repositories also have Racket 8.12 available:
So thank you to the maintainers doing this work.
I think it is fair to say Debian and package systems downstream from Debian (e.g. ubuntu PPA) do take longer. If you are waiting on these, please be patient, as the maintainers are all volunteers and are doing the best they can.
if you don't want to wait;
The Linux build is generic enough that it should work on most distributions, including relatively old distributions.
After downloading the installer file, run it with
sh racket-8.12-x86_64-linux-cs.sh
to install, possibly adding sudo to the start of the command to install to a location that requires administrator access.
Direct download: https://download.racket-lang.org/releases/8.12/installers/racket-8.12-x86_64-linux-cs.sh
Very pleased to report we have two more
Thank you to the maintainers who did the work updating their repositories to include Racket 8.12 so quickly!
I'm checking in here on the state of racket in Ubuntu. When I search for racket PPA I wind up on Asumu's page, which hasn't been updated since 8.6, so it's now a full year out of date. At one point my understanding was that this PPA couldn't be updated until the debian upstream got updated; I think @bremner is responsible for that, and that one is now at 8.10? So I guess I have two questions: (1) Is it still the case that Asumu can't update the Ubuntu PPA until the debian version is updated? (2) Am I understanding how things work at all, or am I terribly, terribly confused?
John Clements via Racket Discourse
notifications@racket.discoursemail.com writes:
I'm checking in here on the state of racket in Ubuntu. When I search
for racket PPA I wind up on Asumu's page, which hasn't been updated
since 8.6, so it's now a full year out of date. At one point my
understanding was that this PPA couldn't be updated until the debian
upstream got updated; I think @bremner is responsible for that, and
that one is now at 8.10? So I guess I have two questions: (1) Is it
still the case that Asumu can't update the Ubuntu PPA until the debian
version is updated? (2) Am I understanding how things work at all, or
am I terribly, terribly confused?
Although we sometimes trade packaging code, there is no formal
dependence between the Ubuntu PPA and the debian package (either way).
It is correct that debian is still at 8.10. 8.11 would not build with
HOME as non-existent (although that was patchable). 8.12 did not build
for me out of the box either; I haven't had the time to narrow down the
problem to something Debian specific or something upstream.
d
Thanks for the update. Let me know if there's anything I can do to help with the debian build. I'll write to Asumu separately.
I've extended snap package to contain both 8.11.1 (in the channel 8.11/stable
) and 8.12 (in the channels 8.12/stable
as well as latest/stable
).
EDIT: You can see this in the drop-down in the top-right corner of Install racket on Linux | Snap Store as well as in the output of snap info racket
:
zyga@novigrad:~$ snap info racket
name: racket
summary: Racket Language
publisher: Sam Tobin-Hochstadt (samth)
store-url: https://snapcraft.io/racket
contact: https://listed.zygoon.pl/
license: MIT
description: |
Racket is a general-purpose programming language and an
ecosystem for language-oriented programming.
This snap is maintained by https://listed.zygoon.pl/ and the source is
available from https://gitlab.com/zygoon/racket-snap
commands:
- racket.drracket
- racket
- racket.raco
- racket.slideshow
snap-id: NxTKtjBiXwSfqrP5RJSArdVObhzPxuAS
tracking: 8.11/stable
refresh-date: today at 15:50 CET
channels:
latest/stable: 8.12 2024-02-11 (19) 243MB -
latest/candidate: ↑
latest/beta: ↑
latest/edge: ↑
8.12/stable: 8.12 2024-02-20 (19) 243MB -
8.12/candidate: ↑
8.12/beta: ↑
8.12/edge: ↑
8.11/stable: 8.11.1 2024-02-20 (17) 243MB -
8.11/candidate: ↑
8.11/beta: ↑
8.11/edge: ↑
installed: 8.11.1 (17) 243MB -
John Clements via Racket Discourse
notifications@racket.discoursemail.com writes:
Thanks for the update. Let me know if there's anything I can do to
help with the debian build. I'll write to Asumu separately.
There are now 8.12 packages in Debian unstable 1. There is a big
transition going on in Debian right (particularly affecting 32 bit arm),
so it may take a while to migrate to testing (and stable backports).
I haven't heard from Asumu for a bit, but if anyone is working on
packaging for Debian derivative, then I suggest looking at the updated
packaging 2. Quite a lot has changed, and most architectures are using the
CS backend now (in some cases via PB). I'm currently aware of one
architecture specific bug; if someone cares about mips64el then maybe
have a look at 3
I've sent the patch series updating Guix to Racket 8.12: [PATCH 0/6] gnu: Update to Racket 8.12, Chez Scheme 10, and Zuo 1.9. It should be merged once CI and review are done. It took a little time to update (and ultimately simplify) Guix's Chez Scheme packaging now that Racket's changes have been upstreamed.
Re switch to PB backend for powerpc (b494cfd5) · Commits · David Bremner / racket · GitLab, did you encounter a problem with tppc32le
on powerpc
? Because I think it's supposed to work. Note that, confusingly enough, in Chez Scheme machine types, the le
suffix stands for "Linux", not "little endian" (which is l
in pb
-based machine types: for native machine types, endianness implied by the architecture part).
(I don't have reportbug
configured on the (Bookworm) machine where I'm writing this, but I can figure that out if you prefer.)
Philip McGrath via Racket Discourse
notifications@racket.discoursemail.com writes:
Re
switch to PB backend for powerpc (b494cfd5) · Commits · David Bremner / racket · GitLab,
did you encounter a problem withtppc32le
onpowerpc
? Because I
think it's supposed to work. Note that, confusingly enough, in Chez
Scheme machine types, thele
suffix stands for "Linux", not "little
endian" (which isl
inpb
-based machine types: for native machine
types, endianness implied by the architecture part).(I don't have
reportbug
configured on the (Bookworm) machine where
I'm writing this, but I can figure that out if you prefer.)
Yes, the built tppc32le racket crashed when building docs. I was a bit
curious if these errors are really symptoms of running out of memory
during the build, but I haven't investigated further.
raco setup: 1 re-rendering: <pkgs>/racket-index/scribblings/main/search.scrbl
raco setup: --- summary of errors --- [5:05:05]
raco setup: error: during making for <pkgs>/compatibility-lib/mzlib
raco setup: vector-length: contract violation
raco setup: expected: vector?
raco setup: given: #<reg>
raco setup: compiling: <pkgs>/compatibility-lib/mzlib/string.rkt
raco setup: error: during making for <pkgs>/data-doc/data
raco setup: vector-length: contract violation
raco setup: expected: vector?
raco setup: given: 'break-enabled
raco setup: compiling: <pkgs>/plot-lib/plot/private/plot3d/plot-area.rkt
raco setup: error: during making for <pkgs>/plot-lib/plot
raco setup: weak-box-value: contract violation
raco setup: expected: weak-box?
raco setup: given: #<weak-box>
raco setup: compiling: <pkgs>/plot-lib/plot/bitmap.rkt
failed
in build-one
in loop
in module->hash
Full log is at Build log for racket (8.12+dfsg1-6) on powerpc
Interesting that this error matches the one in PB backend fails on mips64el (Debian) · Issue #4952 · racket/racket · GitHub. For weak-box-value
to reject something that prints as #<weak-box>
makes me suspect that some deep internal thing is going badly wrong, but what it would be is beyond me.
I think these failures may be due to a missing write barrier in object initialization. If one place (or OS thread generally) initializes and object and another place tries to read it, then without a write barrier, the reading thread might not yet see the tag that was written for the object. A missing barrier could explain the "box is not a box" kind of error, where the tag was not visible when it was checked, but it becomes visible by the time the error message is constructed.
For tppc32le, I had never tried running on a multiprocessor, and I've been able to confirm that the object-initialization barrier was definitely missing there. A barrier would also have been missing for pb on mips64el. See also add missing memory fences for tppc32le and pb variants by mflatt · Pull Request #825 · cisco/ChezScheme · GitHub.
David Bremner david@tethera.net writes:
I haven't heard from Asumu for a bit, but if anyone is working on
packaging for Debian derivative, then I suggest looking at the updated
packaging 2. Quite a lot has changed, and most architectures are using the
CS backend now (in some cases via PB). I'm currently aware of one
architecture specific bug; if someone cares about mips64el then maybe
have a look at 3
Thanks to the amazing Matthew Flatt, the mipsel64el problem has been
fixed in 8.13, and all Debian release architectures except armel now use
the CS backend (at least in Debian unstable). If anyone is particularly
interested in racket cs on Debian/armel (arm5vte) feel free to contact
me.
In related news, the Debian unstable packages are now updated to 8.13.