`run/repl-paste-parse` fails intermittently on Windows
SethTisue opened this issue · 22 comments
as seen at e.g. https://github.com/scala/scala/actions/runs/4162482310/jobs/7201709419
I hoped this was an intermittent phantom but no amount of hitting "re-run failed jobs" seems to be making it go away
and I don't see what recent change could possibly be related to this :-/
@som-snytt does this ring any bells for you?
!! 675 - run/repl-paste-parse.scala [output differs]
% diff D:\a\scala\scala\test\files\run\repl-paste-parse.check D:\a\scala\scala\test\files\run\repl-paste-parse-run.log--- repl-paste-parse.check
+++ repl-paste-parse-run.log
@@ -1,6 +1,6 @@
Type in expressions for evaluation. Or try :help.
-
-scala> repl-paste-parse.script:1: error: illegal start of simple pattern
+repl-paste-parse.script:1: error: illegal start of simple pattern
val case = 9
^
-:quit
+
+scala> :quit
##### Log file 'D:\a\scala\scala\test\files\run\repl-paste-parse-run.log' from failed test #####
Type in expressions for evaluation. Or try :help.
repl-paste-parse.script:1: error: illegal start of simple pattern
val case = 9
^
scala> :quit
as for why it might be 2.12.x only, maybe a JLine 2 vs JLine 3 thing?
does this ring any bells for you?
Yes, it sounds like one of those issues where you go, Why are people still on 2.12? Why are they still on Windows?
How long, oh Lord?
(If it doesn't ring a bell, don't feel obligated to go chasing it down — I can do it on client time. We're helping that client off 2.12, but it takes a while.)
🔕
It passed locally, PST.
Scala version is: Scala compiler version 2.12.18-20230213-102759-de8fa1e -- Copyright 2002-2023, LAMP/EPFL and Lightbend, Inc.
Java binaries in: C:\Program Files\Eclipse Adoptium\jdk-17.0.5.8-hotspot\bin
Java runtime is: OpenJDK 64-Bit Server VM (build 17.0.5+8, mixed mode, sharing)
ok 1 - run/repl-paste-parse.scala [duration 5.60s]
[info] Passed: Total 1, Failed 0, Errors 0, Passed 1
[success] Total time: 109 s (01:49), completed Feb 13, 2023, 3:17:56 PM
Also Happy Valentine's. Only 3 yrs since the week I was so sick.
The weird diff is that the scala> prompt moves from before the error message to before the :quit (which is emitted on EOF).
That looks like an interweaving of stdout and stderr thing.
I wanted to try bootstrap but on -Dstarr.version, sbt fails (also after re-installing latest sbt).
[info] *** Welcome to the sbt build definition for Scala! ***
[info] version=2.12.18-bin-SNAPSHOT scalaVersion=2.12.17
[info] Check README.md for more information.
[error] Expected letter
[error] Expected symbol
[error] Expected '+'
[error] Expected '++'
[error] Expected 'java++'
[error] Expected 'java+'
[error] Expected '^'
[error] Expected '^^'
[error] Expected '+-'
[error] Expected 'debug'
[error] Expected 'info'
[error] Expected 'warn'
[error] Expected 'error'
[error] Expected 'addPluginSbtFile'
[error] Expected 'sbtRebootNetwork'
This is where I'm like, I don't even want to know. That's the real tragedy, it destroys curiosity.
Edit: oh maybe something about git and version strings. Some scripts might use my local git command, git version 2.24.0.windows.2.
attempting to reproduce without outrageous long turnaround time at scala/scala#10326
the problem went away at https://github.com/scala/scala/actions/runs/4233686910 , so if I'm not able to reproduce it on the PR either, then I guess I'll just close this and hope that it doesn't come back :-/
disabling the test on Windows wouldn't be such an awful thing to do, either. our mothers would still love us
not reproducible on the PR either, so 🤷
randomly popped up, on Windows on JDK 11 this time, at https://github.com/scala/scala/actions/runs/4377747092/jobs/7661611891
@som-snytt is there a simple way to disable a partest on Windows? if it were a JUnit test, disabling would be easy. if the checkfile were empty, disabling would be easy. I'm tempted to just delete the test entirely...
on 2.13.x in scala/scala@8f0d3e3 Adriaan converted the test from a DirectTest to a ReplTest, maybe we could backport that, or maybe doing so would run afoul of JLine 2 vs 3 or run afoul of the Great REPL Refactoring
it failed again at https://github.com/scala/scala/actions/runs/4409400690/jobs/7725643280 😡
and here's a 2.13 failure, so apparently it was never 2.12 only to begin with https://github.com/scala/scala/actions/runs/4532729383/jobs/7984531431
There is no "removed their assignment in disgust." Stopping because cleaning up the computer and wondered why I have a scala repo under Windows.
Our luck on this has been considerably better in recent months 🤷
(Unless it's not luck and some version bump somewhere actually fixed it...)
I believe I can hear the demons responsible for this particular torment chuckling under my feet.
Today I had my first git corruption -- apparently a machine reboot at 11 p.m. while editing a commit message for a test on a fresh branch -- so I'm pretty sure they're planning to bring this one back, probably later this evening as I'm breathing a sigh of relief that I made it through the day.
Edit (with hand on door knob): I'd rather hear one user complain about broken paste on Windows every few years than Jenkins or whoever has a problem with the test.
Are we sure it's not still 2023? It feels like it's still 2023.
The REPL refactor included removing the startup thread that allowed the user to start typing while the REPL initialized. That's why it feels so pokey today. Maybe the other reason is the compilation it does on init. dotr starts in one heartbeat, scala in two. Similar difference under scala-cli.
There are a couple of tests just for related behaviors. This was "what if the -i file has a syntax error? is it reported?"
I speculated above that stderr/stdout is interleaved; the test would error on processing the -i, then output scala> :quit and so on. That could be independent of whether two threads are generating the output, or exacerbated by it.
let's close since the test is now deleted from 2.13 and we can live with the occasional failure on 2.12