to anyone with Racket 8.0 or 8.1 handy, does this program run for you? #lang racket/base (struct a (n1) #:prefab) (struct b a (n2) #:prefab) (define val #s((b a 1) 0 1)) (unless (b? val) (+ "unreachable 1")) (unless (a? val) (+ "unreachable 2")) 7.9CS is ok 8.2CS hits unreachable 2

8.1CS gives a contract violation involving “unreachable 2”

All of 8.0, 8.1, 8.2, and HEAD give that result

thanks! I’ll open an issue

Do you think it is enough to change it to [(regexp-match #px"^fc\\d\\d" uname) 'fedora] I.e. only match “fc” at the beginning?

Maybe?

Here’s what uname -a produces in a docker container: root@b60ac181bef4:/# uname -a Linux b60ac181bef4 5.11.0-34-generic #36-Ubuntu SMP Thu Aug 26 19:22:09 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

I’ll look for the result of uname on a Fedora machine.

It shows something like: uname -a Linux <http://ourhost.edu\|ourhost.edu> 4.19.12-301.fc29.x86_64 #1 SMP Mon Dec 24 01:58:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux So simply adding ^ won’t work.

Maybe the suggestion of @samdphillips of using /etc/os-release might work. Is that available on all distributions?

Or … simply skip the two first fields returned by uname.

FWIW /etc/os-release exists on Amazon Linux 2, Debian (used in the full install Racket docker image), and Ubuntu. It’s part of systemd so a “modern” Linux distro should have it.

Works fine in DrRacket for me: version 8.2.0.8--2021-09-07(-/f) [cs].

i.e. no contract violation

Do you have “debugging” on in DrR?

How do I determine that?

it does fail at command line for me

In the Language dialog

Yes, as you can see “Debugging and profiling” is checked

top right

Also it should print “Language: racket/base, with debugging; memory limit: 256 MB.” in the Interactions window

Yes, I do see that. I don’t know the full effect of that being on or off.

thanks @badkins I’ll add that to the issue

Ah, yes, I see it in the Language: line.

That turns on debugging annotations with errortrace. If I turn it off the error comes back.

racket -l errortrace -t bug.rkt also succeeds

@mflatt I don’t know where to give you a feedback on expeditor, so let me use this space.

; seems to terminate the REPL. This is not ideal because code copied from various places could have comments.

Also, thanks for adjusting return in the middle! That was kinda annoying.

I pushed a repair for ; - thanks!

When typing ,help or any xrepl command that has an optional argument for the first time, it will wait for the optional argument. Interestingly, subsequent commands will not wait for optional arguments.

Yes, I haven’t yet sorted that out. xrepl assumes that input all goes through (current-input-port), but that’s not how expeditor works. Also, xrepl assumes S-expressions. I guess this issue is the most important one left.

I’m not sure if this is intentional, but typing 1 2 results in 1 being evaluated, and 2 is left on the editor. I can then enter again to evaluate 2. In the previous REPL, it would evaluate both 1 and 2.

Not saying it’s wrong. The behavior is somewhat reasonable.

One thing that does seem weird is the the history, because I would have:

• 1 2 • 2 in the history. I would expect 1 and 2, or just 1 2 with both 1 and 2 evaluated together.

I’ve pushed some improvements on the xrepl side.

Related to the previous issue: consider:

;; a ;; b ;; c 1

Enter it, and press up. The history entry initially appears to be

;; a it requires a down key to reveal that there is a next line:

;; a ;; b and two more down keys to reveal the whole

;; a ;; b ;; c 1 I would expect that there is only one history entry, and it’s the full

;; a ;; b ;; c 1