Does somebody know how to revert to expeditor with racket?
I had found on Racket Blog to v8.4 how to change from expeditor to readline. The result looks like this:
wurmli@cirrus7:~$ racket
Welcome to Racket v8.9 [cs].
> ,input readline
>
wurmli@cirrus7:~$ racket
Welcome to Racket v8.9 [cs].
invalid memory reference. Some debugging context lost
and the terminal has to be killed. The same happens when I try the "basic" example from Beautiful Racket:
wurmli@cirrus7:~$ racket -I basic
Welcome to Racket v8.9 [cs].
invalid memory reference. Some debugging context lost
(I run Debian testing and a custom install of Racket v8.9 - as Debian is stuck with v8.7.)
I think this is a problem with our strategy for creating a Racket distribution that runs on a wide range of Linux versions. Part of that involves statically linking to libtermcap, but old versions of libtermcap are not really compatible with newer versions of Linux. Specifically, it looks like the statically linked libtermcap interferes with initialization in libedit or libreadline, while Racket's default expeditor manages to side-step incompatibility in its initialization.
I'm not sure at what point our distibrutions should require newer version of Linux. Meanwhile, the only solution I can offer is to build from source or use a snapshot that's built on a Ubuntu 20 or 22.04 as available via https://snapshot.racket-lang.org/.
Can you please advise me how to proceed after './configure && make' (which ran flawlessly): Do I have to deinstall the existing racket v8.9 first or can I just run 'sudo make install'? Or is there even a simpler way of just replacing some files by hand?
This depends on how you installed Racket. If you used the installer script and chose a "Unix-style installation" or had the script put symlinks in your PATH etc., your PATH should also have a racket-uninstall script to reverse those actions. Otherwise, if you chose a self-contained installation, everything is in a single directory that you are free to remove.
I think you probably want to install into /usr/local. In that case, do uninstall the old version (probably as @LiberalArtist describes), then use ./configure --prefix=/usr/local (ok to do that in a place where you've already run ./configure and built), and then sudo make install.
If you make install after a plain ./configure, the "install" creates an in-place build instead of installing someplace like /usr/local. In that case, you can move the built directory around, and you can discard the src subdirectory, but you might need to update PATH to point to the build.
If it's useful, I looked into this a little with a Trixie podman container (from a Bookworm host). With just libedit installed, I got (having previously done ,input readline):
root@04bc7ba8ba59:/racket# ./bin/racket
Welcome to Racket v8.9 [cs].
; Warning: no readline support (invalid memory reference. Some debugging context lost)
>
I then did raco pkg install readline-gpl and apt install libreadline8, which got me to a worse state:
root@04bc7ba8ba59:/racket# ./bin/racket
Welcome to Racket v8.9 [cs].
invalid memory reference. Some debugging context lost
^C; user break [,bt for context]
^C; user break [,bt for context]
^C; user break [,bt for context]
,q
^[^[^[
^C; user break [,bt for context]
^C; user break [,bt for context]
^C; user break [,bt for context]
(And Ctrl-D didn't get me out of this.)
I'd thought about trying racket-x86_64-linux-natipkg-3 because the Mac equivalents include libedit, but it looks like the Linux ones do not, and I definitely never advocate adding more to those packages other than as a last resort.
(I maintain the Guix packaging of Racket.) We also have racket-minimal, zuo, and chez-scheme-for-racket (in addition to upstream chez-scheme) packaged.
I also expect, now that Bookworm has been released, David will probably update Racket in Debian testing soon, though if I were him I'd wait until after the imminent Racket 8.10 release. Generally he keeps the packaging in testing and backports very up-to-date. Sometimes he's landed updates in Debian before I;ve gotten them into Guix, even though Guix has a rolling release model.
I don't have a principled answer, but, tangentially, this reminded me that I'd found in Native library problem on package-build service · Issue #2 · libgit2-racket/libgit2 · GitHub that your mflatt/pkg-build-deps-min Docker image is still based on Ubuntu 16.04 Xenial, which is getting to be quite old indeed. At least when I wrote my related notes, the Racket releases were building on the slightly newer Debian 9 Stretch (June 2017), which has been out of LTS support for a year and is only covered by the even-more-limited ELTS.
I saw in What is the Racket roadmap? - #6 by mflatt that you are planning to look at the racket/draw native libraries relatively soon. I don't have it all paged in, but I know I've had or heard about various issues and ideas at least somewhat related to native libraries; I can try to make a list relatively soon if something like that might be useful.
Without running the script, typing (find-system-path 'pref-file) into DrRacket also give you the path to the Racket preference file. Yon can manually edit the entry of xrepl-input-mode and change it back to expeditor.
Thank you and also Matthew for your help (which helped, at least mostly). As I never used guix I needed some time to "get it", but now I feel relatively comfortable using it. But using racket I run into some inconveniences and problems.
Is there a simple way to migrate the packages in ~/.local/share/racket/8.9 to ~/.local/share/racket/8.9-guix?
One problem I encounter and cannot resolve myself happens when I try to install a package (with raco or drracket): connecting to the package server I get a certificate verify error:
Make sure you've started a new session since you did sudo apt install guix so the scripts installed to /etc/profile.d/ will have been run.
Do guix install nss-certs.
If it doesn't work at this point, it would be a bug in the Guix packaging (I don't remember if I fixed this or not) not declaring that it needs OpenSSL environment variables at runtime. Please let me know if that's the case. If it is, a workaround is to do guix install openssl.
If it doesn't work at this point, it would be a bug in the Guix packaging (I don't remember if I fixed this or not) not declaring that it needs OpenSSL environment variables at runtime. Please let me know if that's the case. If it is, a workaround is to do guix install openssl.
Rebooting and 'guix install nss-certs' didn't help, but guix-installing openssl did.
On the other hand
raco pkg migrate 8.9
did not actually migrate to 8.9-guix, but doing it by hand is not great problem.
Hi @wurmli, thanks again for this report! The problem should be fixed by Guix commit bce0fe8, which went out on the main Guix channel yesterday along with the update to Racket 8.10. You can get the update by running guix pull && guix upgrade. You'll still need to have nss-certs installed (that's what provides the certificates to be found), but you should no longer need to have openssl installed explicitly: you can remove it with guix remove openssl if you want.
Thank you for letting me know. I'll update later as Debian provided 8.10 already some time ago. But in fact I like guix and sooner or later I'll use more of it.
