* Re: testsuite under wine [not found] ` <CAF1jjLvJU2fnU0u0p9SwPre5mnhFdmv9pm_OvZGOvjQApCROqw@mail.gmail.com> @ 2022-12-17 10:52 ` Thomas Koenig 2022-12-17 23:24 ` NightStrike 0 siblings, 1 reply; 23+ messages in thread From: Thomas Koenig @ 2022-12-17 10:52 UTC (permalink / raw) To: NightStrike; +Cc: fortran, gcc mailing list On 17.12.22 01:26, NightStrike wrote: > On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote: >> >> On 16.12.22 03:20, NightStrike via Fortran wrote: >> >>> When I run the testsuite under wine, I'm getting a lot of ANSI escape >>> sequences. We had fixed this long ago, but it seems to be back. Any >>> idea what I should change in my configuration to have this not happen? >> >> This should probably be fixed properly in some *.exp file, but you can >> try setting the GCC_COLORS environment variable to an empty string >> before running the test. > > That didn't help. It looks like this is always escape 25h to start > the output and 25l to end it, which I think is turning the cursor on > and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code). I > apparently fixed this previously by building wine with > --without-curses > (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that > option to wine was removed. Is there a way to hack this on the Deja > side to ignore the escapes? Or to tell it to run in a way that makes > wine not emit them? Truth is, I don't know. I have included the gcc mailing list in this reply, where more knowledgeable people can be found :-) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2022-12-17 10:52 ` testsuite under wine Thomas Koenig @ 2022-12-17 23:24 ` NightStrike 2022-12-18 3:44 ` Jacob Bachmeyer 0 siblings, 1 reply; 23+ messages in thread From: NightStrike @ 2022-12-17 23:24 UTC (permalink / raw) To: Thomas Koenig; +Cc: fortran, gcc mailing list, dejagnu On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig <tkoenig@netcologne.de> wrote: > > On 17.12.22 01:26, NightStrike wrote: > > On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote: > >> > >> On 16.12.22 03:20, NightStrike via Fortran wrote: > >> > >>> When I run the testsuite under wine, I'm getting a lot of ANSI escape > >>> sequences. We had fixed this long ago, but it seems to be back. Any > >>> idea what I should change in my configuration to have this not happen? > >> > >> This should probably be fixed properly in some *.exp file, but you can > >> try setting the GCC_COLORS environment variable to an empty string > >> before running the test. > > > > That didn't help. It looks like this is always escape 25h to start > > the output and 25l to end it, which I think is turning the cursor on > > and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code). I > > apparently fixed this previously by building wine with > > --without-curses > > (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that > > option to wine was removed. Is there a way to hack this on the Deja > > side to ignore the escapes? Or to tell it to run in a way that makes > > wine not emit them? > > Truth is, I don't know. > > I have included the gcc mailing list in this reply, where more > knowledgeable people can be found :-) Thanks. I'm including the dejagnu list, maybe someone there can help, too. For clarity, this is an example of what I see: Output was: ^[[mM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[ ?25h^[[?25l8^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M ^[[?25lM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1 ^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M ^M^M Should match: My_R1 : 78 56 34 12.* My_R2 : 12 34 56 78.* Local_R1 : 78 56 34 12.* Local_R2 : 12 34 56 78.* Local_R1 : 78 56 34 12.* Local_R2 : 12 34 56 78.* Local_R1 : 78 56 34 12.* Local_R2 : 12 34 56 78.* ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2022-12-17 23:24 ` NightStrike @ 2022-12-18 3:44 ` Jacob Bachmeyer 2022-12-18 21:13 ` NightStrike 0 siblings, 1 reply; 23+ messages in thread From: Jacob Bachmeyer @ 2022-12-18 3:44 UTC (permalink / raw) To: NightStrike; +Cc: Thomas Koenig, fortran, gcc mailing list, dejagnu NightStrike wrote: > On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig <tkoenig@netcologne.de> wrote: > >> On 17.12.22 01:26, NightStrike wrote: >> >>> On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote: >>> >>>> On 16.12.22 03:20, NightStrike via Fortran wrote: >>>> >>>> >>>>> When I run the testsuite under wine, I'm getting a lot of ANSI escape >>>>> sequences. We had fixed this long ago, but it seems to be back. Any >>>>> idea what I should change in my configuration to have this not happen? >>>>> >>>> This should probably be fixed properly in some *.exp file, but you can >>>> try setting the GCC_COLORS environment variable to an empty string >>>> before running the test. >>>> >>> That didn't help. It looks like this is always escape 25h to start >>> the output and 25l to end it, which I think is turning the cursor on >>> and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code). I >>> apparently fixed this previously by building wine with >>> --without-curses >>> (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that >>> option to wine was removed. Is there a way to hack this on the Deja >>> side to ignore the escapes? Or to tell it to run in a way that makes >>> wine not emit them? >>> >> Truth is, I don't know. >> >> I have included the gcc mailing list in this reply, where more >> knowledgeable people can be found :-) >> > > Thanks. I'm including the dejagnu list, maybe someone there can help, too. > > For clarity, this is an example of what I see: > > Output was: > ^[[mM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[ > ?25h^[[?25l8^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > ^[[?25lM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1 > ^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > ^M^M > > Should match: > My_R1 : 78 56 34 12.* > My_R2 : 12 34 56 78.* > Local_R1 : 78 56 34 12.* > Local_R2 : 12 34 56 78.* > Local_R1 : 78 56 34 12.* > Local_R2 : 12 34 56 78.* > Local_R1 : 78 56 34 12.* > Local_R2 : 12 34 56 78.* > DejaGnu cannot routinely strip escape sequences because they could be part of the intended output---or strictly forbidden in the intended output. Further, I suspect that the comparison is being carried out in the testsuite code rather than the framework, but the thread that arrived on the DejaGnu list does not mention what test is failing or what testsuite is being run. Based on the inclusion of fortran@gcc.gnu.org, I am guessing this is an issue with the GNU Fortran tests. This is either a testsuite problem or an environment problem. The GNU Fortran I/O module certainly has interesting behavior here. Try setting TERM=dumb in the environment while running the testsuite. If that fixes the problem, it may be appropriate to add "set ::env(TERM) dumb" to the tool init file for GNU Fortran. -- Jacob ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2022-12-18 3:44 ` Jacob Bachmeyer @ 2022-12-18 21:13 ` NightStrike 2022-12-19 4:29 ` Jacob Bachmeyer 0 siblings, 1 reply; 23+ messages in thread From: NightStrike @ 2022-12-18 21:13 UTC (permalink / raw) To: jcb62281; +Cc: Thomas Koenig, fortran, gcc mailing list, dejagnu On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > > NightStrike wrote: > > On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig <tkoenig@netcologne.de> wrote: > > > >> On 17.12.22 01:26, NightStrike wrote: > >> > >>> On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote: > >>> > >>>> On 16.12.22 03:20, NightStrike via Fortran wrote: > >>>> > >>>> > >>>>> When I run the testsuite under wine, I'm getting a lot of ANSI escape > >>>>> sequences. We had fixed this long ago, but it seems to be back. Any > >>>>> idea what I should change in my configuration to have this not happen? > >>>>> > >>>> This should probably be fixed properly in some *.exp file, but you can > >>>> try setting the GCC_COLORS environment variable to an empty string > >>>> before running the test. > >>>> > >>> That didn't help. It looks like this is always escape 25h to start > >>> the output and 25l to end it, which I think is turning the cursor on > >>> and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code). I > >>> apparently fixed this previously by building wine with > >>> --without-curses > >>> (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that > >>> option to wine was removed. Is there a way to hack this on the Deja > >>> side to ignore the escapes? Or to tell it to run in a way that makes > >>> wine not emit them? > >>> > >> Truth is, I don't know. > >> > >> I have included the gcc mailing list in this reply, where more > >> knowledgeable people can be found :-) > >> > > > > Thanks. I'm including the dejagnu list, maybe someone there can help, too. > > > > For clarity, this is an example of what I see: > > > > Output was: > > ^[[mM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[ > > ?25h^[[?25l8^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > > ^[[?25lM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1 > > ^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > > ^M^M > > > > Should match: > > My_R1 : 78 56 34 12.* > > My_R2 : 12 34 56 78.* > > Local_R1 : 78 56 34 12.* > > Local_R2 : 12 34 56 78.* > > Local_R1 : 78 56 34 12.* > > Local_R2 : 12 34 56 78.* > > Local_R1 : 78 56 34 12.* > > Local_R2 : 12 34 56 78.* > > > > DejaGnu cannot routinely strip escape sequences because they could be > part of the intended output---or strictly forbidden in the intended > output. Further, I suspect that the comparison is being carried out in > the testsuite code rather than the framework, but the thread that > arrived on the DejaGnu list does not mention what test is failing or > what testsuite is being run. Based on the inclusion of > fortran@gcc.gnu.org, I am guessing this is an issue with the GNU Fortran > tests. Every GCC language testsuite has these failures, I just singled out Fortran because I was interested in it. > This is either a testsuite problem or an environment problem. The GNU > Fortran I/O module certainly has interesting behavior here. Try setting > TERM=dumb in the environment while running the testsuite. If that fixes > the problem, it may be appropriate to add "set ::env(TERM) dumb" to the > tool init file for GNU Fortran. Setting TERM doesn't help. Wine tries to emulate the windows console, which requires outputting this stuff. It does so any time there's a pty, and I believe that Deja creates a pty when running the tests. Wine people suggested if I could somehow run the test as "wine ./a.exe | cat", that it would prevent this behavior, but I couldn't find a way to do that. For now, I modified Wine to kludge out the code that creates the console, and a long term solution needs to be on the Wine side. I was just hoping for a less dirty hack from the Deja side. Note that there are other problems, too. It seems that when Deja is matching against "\n", it doesn't handle the different line endings of Windows correctly in a cross environment. Is there a way that I can set how to interpret \n in a target-board file? This affects fortran and other language tests also. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2022-12-18 21:13 ` NightStrike @ 2022-12-19 4:29 ` Jacob Bachmeyer 2022-12-19 10:43 ` Torbjorn SVENSSON ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Jacob Bachmeyer @ 2022-12-19 4:29 UTC (permalink / raw) To: NightStrike; +Cc: Thomas Koenig, fortran, gcc mailing list, dejagnu NightStrike wrote: > On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > >> [...] >> This is either a testsuite problem or an environment problem. The GNU >> Fortran I/O module certainly has interesting behavior here. Try setting >> TERM=dumb in the environment while running the testsuite. If that fixes >> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the >> tool init file for GNU Fortran. >> > > Setting TERM doesn't help. Wine tries to emulate the windows console, > which requires outputting this stuff. It does so any time there's a > pty, and I believe that Deja creates a pty when running the tests. > That is a bug in Wine: the escapes should be suppressed entirely if the terminal does not support them---and the "dumb" terminal does not support them. > Wine people suggested if I could somehow run the test as "wine ./a.exe > | cat", that it would prevent this behavior, but I couldn't find a way > to do that. Actually... I think you can, as long as the programs to be run do not require input, but you will need to modify the testsuite to spawn programs differently when using Wine. There is probably a "spawn" command somewhere in the testsuite. You will want to change that to add a conditional for cross-testing using Wine and to use a pipeline in that case. Something like: 8<------ if { ![isnative] && ![isremote target] && [istarget *-*-mingw*] } { # or similar pattern spawn -open [open "| wine ${command} </dev/null" r] } else { # the original "spawn" command spawn $command } 8<------ If these are "dg" tests, the code you need to change should be in the ${tool}_load procedure in the tool init file, most likely in testsuite/lib. Again, this can work only if the test programs are non-interactive, since Tcl does not allow running a subprocess with both input and output on pipes connected to the main program. (Expect does, but uses a pty instead of a pair of pipes to accomplish this.) The above example connects the child process's stdin to /dev/null and its stdout to a pipe to the Tcl interpreter running the testsuite; Expect then wraps the file handle in an Expect spawn handle and the rest of the code can use the 'expect' command as normal to read its output. Also, "wine" should probably be instead a global variable WINE that can be set to a specific Wine executable if needed, but the best long-term solution is probably to fix the console emulation in Wine. There may be more layers of indirection involved, possibly back into the framework; I am somewhat less familiar with the details of the GCC testsuite, so it would be very helpful if you could point me to one of the tests in question. This may turn into a feature request for general framework support for emulated targets using "interposition emulators" such as Wine or QEMU. I will think about that, but it probably will not be in 1.6.4. > For now, I modified Wine to kludge out the code that > creates the console, and a long term solution needs to be on the Wine > side. I was just hoping for a less dirty hack from the Deja side. > I think that the long-term solution is that Wine should properly honor the TERM environment variable and not produce escape codes that the declared terminal does not support. > Note that there are other problems, too. It seems that when Deja is > matching against "\n", it doesn't handle the different line endings of > Windows correctly in a cross environment. Is there a way that I can > set how to interpret \n in a target-board file? This affects fortran > and other language tests also. No---problems related to line endings are bugs in the testsuite. This caveat is documented in *Note: (dejagnu)Writing a test case. The manual explains: "Note that terminal settings may result in the insertion of additional `\r' characters, usually translating `\n' to `\r\n'." At the terminal layer, POSIX can *also* use "\r\n" sequences, since some terminals historically needed them, even though the standard line ending *within* a POSIX system is "\n" by itself. Because a pty simply presents the "terminal" side of the interface to the controlling program, Expect can receive "\r\n" when the subprocess emits "\n"; the translation is performed by the kernel terminal driver and DejaGnu testsuites must be prepared to receive (and discard) excess carriage returns in the general case. -- Jacob ^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: testsuite under wine 2022-12-19 4:29 ` Jacob Bachmeyer @ 2022-12-19 10:43 ` Torbjorn SVENSSON 2022-12-19 11:00 ` NightStrike 2022-12-19 11:13 ` NightStrike [not found] ` <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com> 2 siblings, 1 reply; 23+ messages in thread From: Torbjorn SVENSSON @ 2022-12-19 10:43 UTC (permalink / raw) To: jcb62281, NightStrike; +Cc: Thomas Koenig, fortran, gcc mailing list, dejagnu Hi, > -----Original Message----- > From: dejagnu-bounces+torbjorn.svensson=st.com@gnu.org <dejagnu- > bounces+torbjorn.svensson=st.com@gnu.org> On Behalf Of Jacob Bachmeyer > Sent: den 19 december 2022 05:29 > To: NightStrike <nightstrike@gmail.com> > Cc: Thomas Koenig <tkoenig@netcologne.de>; fortran@gcc.gnu.org; gcc > mailing list <gcc@gcc.gnu.org>; dejagnu@gnu.org > Subject: Re: testsuite under wine > > NightStrike wrote: > > On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer > <jcb62281@gmail.com> wrote: > > > >> [...] > >> This is either a testsuite problem or an environment problem. The GNU > >> Fortran I/O module certainly has interesting behavior here. Try setting > >> TERM=dumb in the environment while running the testsuite. If that fixes > >> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the > >> tool init file for GNU Fortran. > >> > > > > Setting TERM doesn't help. Wine tries to emulate the windows console, > > which requires outputting this stuff. It does so any time there's a > > pty, and I believe that Deja creates a pty when running the tests. > > > > That is a bug in Wine: the escapes should be suppressed entirely if the > terminal does not support them---and the "dumb" terminal does not > support them. I'm not sure if this helps anyone, but I experienced something similar with Cygwin a while back. What I had to do in order to have expect working when testing GCC on Windows 10 was to defined the "CYGWIN" environment variable to "disable_pcon" (https://cygwin.com/cygwin-ug-net/using-cygwinenv.html). If I did not define this variable, then Cygwin would inject an escape sequence that would make all pattern checks fail on the output. I don't know if Cygwin might has changed this behavior, but it was an issue in the past anyway. Kind regards, Torbjörn ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2022-12-19 10:43 ` Torbjorn SVENSSON @ 2022-12-19 11:00 ` NightStrike 0 siblings, 0 replies; 23+ messages in thread From: NightStrike @ 2022-12-19 11:00 UTC (permalink / raw) To: Torbjorn SVENSSON Cc: jcb62281, Thomas Koenig, fortran, gcc mailing list, dejagnu On Mon, Dec 19, 2022 at 5:43 AM Torbjorn SVENSSON <torbjorn.svensson@st.com> wrote: > I'm not sure if this helps anyone, but I experienced something similar with Cygwin a while back. > What I had to do in order to have expect working when testing GCC on Windows 10 was to defined the "CYGWIN" environment variable to "disable_pcon" (https://cygwin.com/cygwin-ug-net/using-cygwinenv.html). If I did not define this variable, then Cygwin would inject an escape sequence that would make all pattern checks fail on the output. > > I don't know if Cygwin might has changed this behavior, but it was an issue in the past anyway. This is extremely helpful for when I start testing natively, thank you. I think in general the problem is the same, but Wine doesn't immediately have a comparable workaround. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2022-12-19 4:29 ` Jacob Bachmeyer 2022-12-19 10:43 ` Torbjorn SVENSSON @ 2022-12-19 11:13 ` NightStrike 2022-12-20 3:51 ` Jacob Bachmeyer [not found] ` <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com> 2 siblings, 1 reply; 23+ messages in thread From: NightStrike @ 2022-12-19 11:13 UTC (permalink / raw) To: jcb62281; +Cc: Thomas Koenig, fortran, gcc mailing list, dejagnu On Sun, Dec 18, 2022 at 11:29 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > > NightStrike wrote: > > On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > > > >> [...] > >> This is either a testsuite problem or an environment problem. The GNU > >> Fortran I/O module certainly has interesting behavior here. Try setting > >> TERM=dumb in the environment while running the testsuite. If that fixes > >> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the > >> tool init file for GNU Fortran. > >> > > > > Setting TERM doesn't help. Wine tries to emulate the windows console, > > which requires outputting this stuff. It does so any time there's a > > pty, and I believe that Deja creates a pty when running the tests. > > > > That is a bug in Wine: the escapes should be suppressed entirely if the > terminal does not support them---and the "dumb" terminal does not > support them. I think it's a paradigm difference. I'm just guessing here, but Wine runs in a terminal that doesn't know about TERM. It's mimicking the "cmd.exe" that you'd run on a native Windows system (I think... I'd welcome corrections from those more knowledgeable). In theory, the effect would be the same if I set up a remote target board to ssh to a windows system and get dropped into a cmd.exe shell (I used to run this way... it'd take about a week to run the whole testsuite. It sucked...) [...snip for now, I'm working on getting reasonable output back to you, including an example of a case that fails, and how it responds to your suggestion. Stay tuned...] > > For now, I modified Wine to kludge out the code that > > creates the console, and a long term solution needs to be on the Wine > > side. I was just hoping for a less dirty hack from the Deja side. > > > > I think that the long-term solution is that Wine should properly honor > the TERM environment variable and not produce escape codes that the > declared terminal does not support. Agreed, just trying to get by for now. > > Note that there are other problems, too. It seems that when Deja is > > matching against "\n", it doesn't handle the different line endings of > > Windows correctly in a cross environment. Is there a way that I can > > set how to interpret \n in a target-board file? This affects fortran > > and other language tests also. > > No---problems related to line endings are bugs in the testsuite. This > caveat is documented in *Note: (dejagnu)Writing a test case. The manual > explains: "Note that terminal settings may result in the insertion of > additional `\r' characters, usually translating `\n' to `\r\n'." > > At the terminal layer, POSIX can *also* use "\r\n" sequences, since some > terminals historically needed them, even though the standard line ending > *within* a POSIX system is "\n" by itself. Because a pty simply > presents the "terminal" side of the interface to the controlling > program, Expect can receive "\r\n" when the subprocess emits "\n"; the > translation is performed by the kernel terminal driver and DejaGnu > testsuites must be prepared to receive (and discard) excess carriage > returns in the general case. Here's one that tries to handle different line endings (most tests do not do this): gfortran.dg/parameter_array_dummy.f90 which uses: ! { dg-output " *1 aa(\n|\r\n|\r)" } ! { dg-output " *2 ab(\n|\r\n|\r)" } ! { dg-output " *3 aaab(\n|\r\n|\r)" } ! { dg-output " *4 abaa(\n|\r\n|\r)" } ! { dg-output " *5 ababab(\n|\r\n|\r)" } But this results in: FAIL: gfortran.dg/parameter_array_dummy.f90 -O0 output pattern test Output was: 1 aa^M^M 2 ab^M^M 3 aaab^M^M 4 abaa^M^M 5 ababab^M^M Should match: *1 aa( |^M |^M) *2 ab( |^M |^M) *3 aaab( |^M |^M) *4 abaa( |^M |^M) *5 ababab( |^M |^M) The problem being that we are getting "0x0d 0x0d 0x0a", or \r\r\n. (Other examples fail differently, for instance there's a Rust test that outputs \r\r\n\n... but let's start with this one). ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2022-12-19 11:13 ` NightStrike @ 2022-12-20 3:51 ` Jacob Bachmeyer 0 siblings, 0 replies; 23+ messages in thread From: Jacob Bachmeyer @ 2022-12-20 3:51 UTC (permalink / raw) To: NightStrike; +Cc: Thomas Koenig, fortran, gcc mailing list, dejagnu NightStrike wrote: > On Sun, Dec 18, 2022 at 11:29 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > >> NightStrike wrote: >> >>> On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: >>> >>> >>>> [...] >>>> This is either a testsuite problem or an environment problem. The GNU >>>> Fortran I/O module certainly has interesting behavior here. Try setting >>>> TERM=dumb in the environment while running the testsuite. If that fixes >>>> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the >>>> tool init file for GNU Fortran. >>>> >>>> >>> Setting TERM doesn't help. Wine tries to emulate the windows console, >>> which requires outputting this stuff. It does so any time there's a >>> pty, and I believe that Deja creates a pty when running the tests. >>> >>> >> That is a bug in Wine: the escapes should be suppressed entirely if the >> terminal does not support them---and the "dumb" terminal does not >> support them. >> > > I think it's a paradigm difference. I'm just guessing here, but Wine > runs in a terminal that doesn't know about TERM. Terminals never know about TERM. TERM exists to inform programs what terminal type they are running with. X11 terminal emulators *set* TERM in the environment given to their child processes to identify themselves for this reason. > It's mimicking the "cmd.exe" that you'd run on a native Windows system (I think... I'd welcome corrections from those more knowledgeable). Yes, but Wine must emulate a console window with the terminal that it has, which is not necessarily a VT100-alike, therefore it should be checking the TERM variable at the minimum, and preferably using terminfo to adapt whatever escape sequences the terminal in use actually expects, or gracefully degrade when the terminal simply does not support the needed features. (Minor technical note: while cmd.exe is a console program, it does not actually provide the console; that is a different part of the NT system, but I am not certain exactly what. Wine is trying to emulate the Windows console, not cmd.exe.) > In theory, the effect would be the same if I set up a remote target board to ssh to a windows system and get dropped into a cmd.exe shell (I used to run this way... it'd take about a week to run the whole testsuite. It sucked...) > Ah yes, Windows has some serious performance problems related to spawning processes. :-D I once cross-compiled GNU libc from a Windows (98SE) host while setting up my first GNU/Linux system. It took about three days and the machine needed a universal Windows fix-it (reboot) afterwards due to memory leaks resulting in swap thrashing that continued even after all application programs had been closed---just a desktop, disk light on almost solidly, mouse pointer lagging mouse movement visibly. Later, on the same hardware but using a Linux kernel, rebuilding glibc took the expected two hours. Also, the same hardware semi-regularly locked up solid (even the mouse pointer would not move) with Windows... and not even once with GNU/Linux/XFree86. [...snip extended rant...] > [...] >>> Note that there are other problems, too. It seems that when Deja is >>> matching against "\n", it doesn't handle the different line endings of >>> Windows correctly in a cross environment. Is there a way that I can >>> set how to interpret \n in a target-board file? This affects fortran >>> and other language tests also. >>> >> No---problems related to line endings are bugs in the testsuite. This >> caveat is documented in *Note: (dejagnu)Writing a test case. The manual >> explains: "Note that terminal settings may result in the insertion of >> additional `\r' characters, usually translating `\n' to `\r\n'." >> >> At the terminal layer, POSIX can *also* use "\r\n" sequences, since some >> terminals historically needed them, even though the standard line ending >> *within* a POSIX system is "\n" by itself. Because a pty simply >> presents the "terminal" side of the interface to the controlling >> program, Expect can receive "\r\n" when the subprocess emits "\n"; the >> translation is performed by the kernel terminal driver and DejaGnu >> testsuites must be prepared to receive (and discard) excess carriage >> returns in the general case. >> > > Here's one that tries to handle different line endings (most tests do > not do this): > > gfortran.dg/parameter_array_dummy.f90 > > which uses: > ! { dg-output " *1 aa(\n|\r\n|\r)" } > ! { dg-output " *2 ab(\n|\r\n|\r)" } > ! { dg-output " *3 aaab(\n|\r\n|\r)" } > ! { dg-output " *4 abaa(\n|\r\n|\r)" } > ! { dg-output " *5 ababab(\n|\r\n|\r)" } > > But this results in: > > FAIL: gfortran.dg/parameter_array_dummy.f90 -O0 output pattern test > [...] > > The problem being that we are getting "0x0d 0x0d 0x0a", or \r\r\n. > These are testsuite bugs. This detail also (finally) tells me that the framework /is/ involved here after all, so there are possibilities for enhancing lib/dg.exp to reduce these issues. One possibility could be to use "$" in dg-output patterns as an end-of-line marker, internally substituted with a known EOL pattern for the platform being tested. (Not yet implemented, and testsuites using it would not be able to run with older framework versions.) Another solution is to note that dg-output matching does *not* use Expect and is actually batch-oriented: the test program is run (and its output gathered) using ${tool}_load, and then the patterns are matched against that returned output. This means that the Expect caveats described in the manual for normal tests do not apply here, and a simple EOL subpattern is usable: "[\r\n]+" (using that subpattern with Expect *will* cause subtle timing-related bugs) > (Other examples fail differently, for instance there's a Rust test > that outputs \r\r\n\n... but let's start with this one). > I believe that dg-output could reliably match that with an "[\r\n]+" subpattern, too. :-) One last detail that might help you: ${tool}_load has a chance to apply regsub(n) to the output before returning it. If the testsuite should ignore escape sequences, and you can match them with a Tcl regexp, you could use a similar conditional as my previous suggestion to prune the output before dg.exp examines it. -- Jacob ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com>]
* Re: testsuite under wine [not found] ` <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com> @ 2022-12-22 1:01 ` NightStrike 2022-12-22 4:37 ` Jacob Bachmeyer 0 siblings, 1 reply; 23+ messages in thread From: NightStrike @ 2022-12-22 1:01 UTC (permalink / raw) To: Jacek Caban; +Cc: jcb62281, fortran, Eric Pouech, gcc, dejagnu On Wed, Dec 21, 2022 at 12:38 PM Jacek Caban <jacek@codeweavers.com> wrote: > > Hi all, > > > I'm responsible for Wine changes that cause your problems. I'm also > CCing Eric, who is Wine console expert, maybe he has better ideas. Eric, > see [1] if you're interested in the context. > > > Recent Wine versions implement Windows pseudo-consoles, see [2] for a > bit more details. It's generally Microsoft's semi-recent API that's > intended to be more compatible with POSIX than what was present in > previous versions of Windows. In theory, with that implemented, we could > just plug tty fds that we get from Unix and have Unix consoles working > using those Windows APIs. In practice, it's not quite as good as > promised and we need some tweaks to make it work nicely. We could > improve those tweaks, but there are architectural limitations that will > come to play sooner or later. > > > > I think that the long-term solution is that Wine should properly honor > > the TERM environment variable and not produce escape codes that the > > declared terminal does not support. > > > I think that it would not be enough. The way Windows consoles work is > that we manage complete internal screen buffer and emit output that > synchronizes the buffer with Unix terminal inside conhost.exe process. > It means that its output heavily processed and may be very different > from what application writes to its console handle. While escape codes > discussed in this thread are the most prominent difference (and that > part could, in theory, be improved on our side), there are more > differences. For example, if application writes "\rA\rB\rC", conhost > will process it, update its internal buffer which changes just one > character and cursor position, and emit sequence to update it in Unix > terminal, which could be just "\rC" (or even "C" if cursor was already > at the beginning of the line). Another example would be long lines: > conhost will emit additional EOLs instead of depending on embedder to > wrap the line. I'm not really familiar with DejaGnu, but if you want to > match application output, that's probably not what you're looking for. > > > The reason the previous workaround of compiling Wine without ncurses > worked is that if made Wine treat tty stdin/stdout in a way very similar > to regular pipes, so no extra processing was performed. This was more of > a side effect than a design choice. It should be possible to provide > some way to achieve that with the new Wine architecture. I'm attaching > an example of Wine patch that would allow it. With that patch, you may > disable conhost.exe (via winecfg or WINEDLLOVERRIDES=conhost.exe=d > environment variable) and achieve something similar to previous workaround. > > > Long term, I think that it would be best to get rid of console behaviour > expectations by using Windows build of DejaGnu. My understanding is that > it requires Cygwin, so the stack would be: Windows DejaGnu on Cygwin on > Wine on Linux. This would make all similar mismatches in expectations > non-existent. Cygwin is tricky to run on Wine, there are a few known > problems like [3], but we're getting there. > > > Jacek > > > [1] https://gcc.gnu.org/pipermail/fortran/2022-December/058645.html > > [2] > https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ > > [3] https://bugs.winehq.org/show_bug.cgi?id=47808 First, a big giant thank you for this patch. I confirmed that I can use this to replace the "return immediately from init_console" hack, and it applies cleanly to 7.20. Second, the problems with extra \r's still remain, but I think we've generally come to think that that part isn't Wine and is instead either the testsuite or deja. So I'll keep those replies to Jacob's previous message. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2022-12-22 1:01 ` NightStrike @ 2022-12-22 4:37 ` Jacob Bachmeyer 2022-12-23 10:36 ` NightStrike 0 siblings, 1 reply; 23+ messages in thread From: Jacob Bachmeyer @ 2022-12-22 4:37 UTC (permalink / raw) To: NightStrike; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu NightStrike wrote: > [...] > Second, the problems with extra \r's still remain, but I think we've > generally come to think that that part isn't Wine and is instead > either the testsuite or deja. So I'll keep those replies to Jacob's > previous message. > Most likely, it is a combination of the MinGW libc (which emits "\r\n" for end-of-line in accordance with Windows convention) and the kernel terminal driver (which passes "\r" and translates "\n" to "\r\n" in accordance with POSIX convention). Wine, short of trying to translate "\r\n" back to "\n" in accordance with POSIX conventions (and likely making an even bigger mess---does Wine know if a handle is supposed to be text or binary?) cannot really fix this, so the testsuite needs to handle non-POSIX-standard line endings. (The Rust tests probably have an outright bug if the newlines are being duplicated.) -- Jacob ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2022-12-22 4:37 ` Jacob Bachmeyer @ 2022-12-23 10:36 ` NightStrike 2022-12-23 12:43 ` Eric Pouech 2022-12-24 4:00 ` Jacob Bachmeyer 0 siblings, 2 replies; 23+ messages in thread From: NightStrike @ 2022-12-23 10:36 UTC (permalink / raw) To: jcb62281; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > > NightStrike wrote: > > [...] > > Second, the problems with extra \r's still remain, but I think we've > > generally come to think that that part isn't Wine and is instead > > either the testsuite or deja. So I'll keep those replies to Jacob's > > previous message. > > > > Most likely, it is a combination of the MinGW libc (which emits "\r\n" > for end-of-line in accordance with Windows convention) and the kernel > terminal driver (which passes "\r" and translates "\n" to "\r\n" in > accordance with POSIX convention). Wine, short of trying to translate > "\r\n" back to "\n" in accordance with POSIX conventions (and likely > making an even bigger mess---does Wine know if a handle is supposed to > be text or binary?) cannot really fix this, so the testsuite needs to > handle non-POSIX-standard line endings. (The Rust tests probably have > an outright bug if the newlines are being duplicated.) You may be onto something here. I ran wine under script as `script -c "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r prepended to the \r\n. I was making the mistake previously of running wine manually and capturing it to a file as `wine64 ./a.exe > out`, which as several have pointed out in this thread, that would disable the quirk, so of course it didn't reveal any problems. I'm behind, but I'll catch up to you guys eventually :) So at least we know for sure that this particular instance of extra characters is coming from Wine. Maybe Wine can be smart enough to only translate \n into \r\n instead of translating \r\n into \r\r\n. Jacek / Eric, comments here? I'm happy to try another patch, the first one was great. Rust is getting \r\r\n\n (as opposed to \r\n\r\n), so... yeah. Could be the rust test, could be the rust frontend, could be another weird Wine interaction. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2022-12-23 10:36 ` NightStrike @ 2022-12-23 12:43 ` Eric Pouech 2022-12-24 4:00 ` Jacob Bachmeyer 1 sibling, 0 replies; 23+ messages in thread From: Eric Pouech @ 2022-12-23 12:43 UTC (permalink / raw) To: NightStrike, jcb62281; +Cc: Jacek Caban, fortran, gcc, dejagnu Le 23/12/2022 à 11:36, NightStrike a écrit : > On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: >> NightStrike wrote: >>> [...] >>> Second, the problems with extra \r's still remain, but I think we've >>> generally come to think that that part isn't Wine and is instead >>> either the testsuite or deja. So I'll keep those replies to Jacob's >>> previous message. >>> >> Most likely, it is a combination of the MinGW libc (which emits "\r\n" >> for end-of-line in accordance with Windows convention) and the kernel >> terminal driver (which passes "\r" and translates "\n" to "\r\n" in >> accordance with POSIX convention). Wine, short of trying to translate >> "\r\n" back to "\n" in accordance with POSIX conventions (and likely >> making an even bigger mess---does Wine know if a handle is supposed to >> be text or binary?) cannot really fix this, so the testsuite needs to >> handle non-POSIX-standard line endings. (The Rust tests probably have >> an outright bug if the newlines are being duplicated.) > You may be onto something here. I ran wine under script as `script -c > "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r > prepended to the \r\n. I was making the mistake previously of running > wine manually and capturing it to a file as `wine64 ./a.exe > out`, > which as several have pointed out in this thread, that would disable > the quirk, so of course it didn't reveal any problems. I'm behind, > but I'll catch up to you guys eventually :) > > So at least we know for sure that this particular instance of extra > characters is coming from Wine. Maybe Wine can be smart enough to > only translate \n into \r\n instead of translating \r\n into \r\r\n. > Jacek / Eric, comments here? I'm happy to try another patch, the > first one was great. > actually, it depends on how the file has been opened by the application. if it's done in binary mode, no \n => \r\n translation takes place but it the file is opened in text mode, wine just does what the application requires, which is \n => \r\n translation (and by default, stdout and stderr are opened in text mode) IMO, you should not expect more from Wine. Wine's goal is to run windows application on Unix ; it's not to run windows applications on Unix and requiring that they behave as they had been written for Linux semantics anyway, we (wine) have to go back to blackboard to figure out a solution for disabling nicely conhost in the meantime, you could use (without any patch to wine), some wrapper (bash) script like: #!/bin/bash # assumes wine is in $PATH case "$1" in --unix-raw) shift; cat | wine $* 1> >(tee /dev/null) 2> >(tee /dev/null >&2);; --unix-lf) shift; cat | wine $* 1> >(tee /dev/null | sed 's/\r$//' ) 2> >(tee /dev/null | sed 's/\r$//' >&2);; *) wine $*;; esac using --unix-raw will just disable conhost (hence shall remove most of the ansi sequences reported) using --unix-lf will also disable conhost and replace \r\n with \n this shall put wine in the behavior as you expect, and still allow using proper redirection and piping on the shell script if needed (without alterning wine's behavior) (this could be further improved by not adding a pipe for fd:s that are not tty, or adapted to be triggered when, say, TERM=dumb) HTH ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2022-12-23 10:36 ` NightStrike 2022-12-23 12:43 ` Eric Pouech @ 2022-12-24 4:00 ` Jacob Bachmeyer 2022-12-24 11:05 ` Mark Wielaard 2023-01-05 2:50 ` NightStrike 1 sibling, 2 replies; 23+ messages in thread From: Jacob Bachmeyer @ 2022-12-24 4:00 UTC (permalink / raw) To: NightStrike; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu NightStrike wrote: > On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > >> NightStrike wrote: >> >>> [...] >>> Second, the problems with extra \r's still remain, but I think we've >>> generally come to think that that part isn't Wine and is instead >>> either the testsuite or deja. So I'll keep those replies to Jacob's >>> previous message. >>> >>> >> Most likely, it is a combination of the MinGW libc (which emits "\r\n" >> for end-of-line in accordance with Windows convention) and the kernel >> terminal driver (which passes "\r" and translates "\n" to "\r\n" in >> accordance with POSIX convention). Wine, short of trying to translate >> "\r\n" back to "\n" in accordance with POSIX conventions (and likely >> making an even bigger mess---does Wine know if a handle is supposed to >> be text or binary?) cannot really fix this, so the testsuite needs to >> handle non-POSIX-standard line endings. (The Rust tests probably have >> an outright bug if the newlines are being duplicated.) >> > > You may be onto something here. I ran wine under script as `script -c > "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r > prepended to the \r\n. I was making the mistake previously of running > wine manually and capturing it to a file as `wine64 ./a.exe > out`, > which as several have pointed out in this thread, that would disable > the quirk, so of course it didn't reveal any problems. I'm behind, > but I'll catch up to you guys eventually :) > So close, and yet so far... script(1) /also/ uses a pty, so it is getting the same translations as Expect and therefore DejaGnu. > So at least we know for sure that this particular instance of extra > characters is coming from Wine. Maybe Wine can be smart enough to > only translate \n into \r\n instead of translating \r\n into \r\r\n. > Jacek / Eric, comments here? I'm happy to try another patch, the > first one was great. > I doubt that Wine is doing that translation. MinGW libc produces output conformant to Windows conventions, so printf("\n") on a text handle emits "\r\n", which Wine passes along. POSIX convention is that "\n" is translated to "\r\n" in the kernel terminal driver upon output, so the kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be prepared to discard excess carriage returns. The first CR came from MinGW libc; the second CR came from the kernel terminal driver; the LF was ultimately passed through. > Rust is getting \r\r\n\n (as opposed to \r\n\r\n), so... yeah. Could > be the rust test, could be the rust frontend, could be another weird > Wine interaction. > That is probably either a Rust bug or the intended behavior. Does the test produce "\n\n" or "\r\n\n" when run natively? (Note that the terminal driver could reasonably optimize: once one CR has been produced, any number of LF may follow: the cursor is assumed to remain at the left edge. It is possible that the kernel terminal driver could even strip the second CR in "\r\n\r\n" since its only effect on an actual serial terminal would be wasting transmission time.) -- Jacob ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2022-12-24 4:00 ` Jacob Bachmeyer @ 2022-12-24 11:05 ` Mark Wielaard 2023-01-05 2:50 ` NightStrike 1 sibling, 0 replies; 23+ messages in thread From: Mark Wielaard @ 2022-12-24 11:05 UTC (permalink / raw) To: jcb62281; +Cc: NightStrike, Jacek Caban, fortran, Eric Pouech, gcc, dejagnu Hi, On Fri, Dec 23, 2022 at 10:00:36PM -0600, Jacob Bachmeyer via Gcc wrote: > NightStrike wrote: > > Rust is getting \r\r\n\n (as opposed to \r\n\r\n), so... yeah. Could > > be the rust test, could be the rust frontend, could be another weird > > Wine interaction. > > That is probably either a Rust bug or the intended behavior. Note that in rust a string tokens or doc comments with an "Isolated CR" (a \r not immediately followed by an \n) is an error and the testsuite contains a couple of tests to make sure the compiler detects that. Which might cause even more confusion. Cheers, Mark ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2022-12-24 4:00 ` Jacob Bachmeyer 2022-12-24 11:05 ` Mark Wielaard @ 2023-01-05 2:50 ` NightStrike 2023-01-06 3:33 ` Jacob Bachmeyer 2023-01-06 3:41 ` Jerry D 1 sibling, 2 replies; 23+ messages in thread From: NightStrike @ 2023-01-05 2:50 UTC (permalink / raw) To: jcb62281; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > NightStrike wrote: > > On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > >> NightStrike wrote: > >> > >>> [...] > >>> Second, the problems with extra \r's still remain, but I think we've > >>> generally come to think that that part isn't Wine and is instead > >>> either the testsuite or deja. So I'll keep those replies to Jacob's > >>> previous message. > >>> > >>> > >> Most likely, it is a combination of the MinGW libc (which emits "\r\n" > >> for end-of-line in accordance with Windows convention) and the kernel > >> terminal driver (which passes "\r" and translates "\n" to "\r\n" in > >> accordance with POSIX convention). Wine, short of trying to translate > >> "\r\n" back to "\n" in accordance with POSIX conventions (and likely > >> making an even bigger mess---does Wine know if a handle is supposed to > >> be text or binary?) cannot really fix this, so the testsuite needs to > >> handle non-POSIX-standard line endings. (The Rust tests probably have > >> an outright bug if the newlines are being duplicated.) > >> > > > > You may be onto something here. I ran wine under script as `script -c > > "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r > > prepended to the \r\n. I was making the mistake previously of running > > wine manually and capturing it to a file as `wine64 ./a.exe > out`, > > which as several have pointed out in this thread, that would disable > > the quirk, so of course it didn't reveal any problems. I'm behind, > > but I'll catch up to you guys eventually :) > > > > So close, and yet so far... script(1) /also/ uses a pty, so it is > getting the same translations as Expect and therefore DejaGnu. > > > So at least we know for sure that this particular instance of extra > > characters is coming from Wine. Maybe Wine can be smart enough to > > only translate \n into \r\n instead of translating \r\n into \r\r\n. > > Jacek / Eric, comments here? I'm happy to try another patch, the > > first one was great. > > > > I doubt that Wine is doing that translation. MinGW libc produces output > conformant to Windows conventions, so printf("\n") on a text handle > emits "\r\n", which Wine passes along. POSIX convention is that "\n" is > translated to "\r\n" in the kernel terminal driver upon output, so the > kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding > "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be > prepared to discard excess carriage returns. The first CR came from > MinGW libc; the second CR came from the kernel terminal driver; the LF > was ultimately passed through. Jacek and I have been digging into this on IRC, and he's been very helpful in trying to get further, but we're still stuck. We tried to be more introspective, inserting strace both as "strace script wine" and as "script strace wine". We tried running just "wine a.exe" without any extra glue, and logging the raw SSH packets from putty. After many iterations on these and other tests, Jacek finally had the idea to try removing Windows entirely from the equation, and we ran with a purely unix program / compiler combination: #include <unistd.h> int main() { write(1, "test\r\n", 6); return 0; } (and also as "test\n", 5) In both versions, the following was observed: case 1) ./a.out | xxd case 2) script -c ./a.out out; xxd out case 3) enable putting logging, ./a.out In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n). So, is it possible after all of this back and forth regarding mingw, wine, and others, that it's down to the write() system call that's inserting extra \r's? Is this expected? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2023-01-05 2:50 ` NightStrike @ 2023-01-06 3:33 ` Jacob Bachmeyer 2023-01-06 3:44 ` Jerry D 2023-01-08 7:12 ` NightStrike 2023-01-06 3:41 ` Jerry D 1 sibling, 2 replies; 23+ messages in thread From: Jacob Bachmeyer @ 2023-01-06 3:33 UTC (permalink / raw) To: NightStrike; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu NightStrike wrote: > On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > >> NightStrike wrote: >> >>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: >>> >>>> [...] >>> So at least we know for sure that this particular instance of extra >>> characters is coming from Wine. Maybe Wine can be smart enough to >>> only translate \n into \r\n instead of translating \r\n into \r\r\n. >>> Jacek / Eric, comments here? I'm happy to try another patch, the >>> first one was great. >>> >>> >> I doubt that Wine is doing that translation. MinGW libc produces output >> conformant to Windows conventions, so printf("\n") on a text handle >> emits "\r\n", which Wine passes along. POSIX convention is that "\n" is >> translated to "\r\n" in the kernel terminal driver upon output, so the >> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding >> "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be >> prepared to discard excess carriage returns. The first CR came from >> MinGW libc; the second CR came from the kernel terminal driver; the LF >> was ultimately passed through. >> > > Jacek and I have been digging into this on IRC, and he's been very > helpful in trying to get further, but we're still stuck. We tried to > be more introspective, inserting strace both as "strace script wine" > and as "script strace wine". We tried running just "wine a.exe" > without any extra glue, and logging the raw SSH packets from putty. > After many iterations on these and other tests, Jacek finally had the > idea to try removing Windows entirely from the equation, and we ran > with a purely unix program / compiler combination: > > #include <unistd.h> > > int main() > { > write(1, "test\r\n", 6); > return 0; > } > > (and also as "test\n", 5) > > In both versions, the following was observed: > > case 1) ./a.out | xxd > case 2) script -c ./a.out out; xxd out > case 3) enable putting logging, ./a.out > > In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an > extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n). > > So, is it possible after all of this back and forth regarding mingw, > wine, and others, that it's down to the write() system call that's > inserting extra \r's? Is this expected? > "This is why DejaGnu testsuites must be prepared to discard excess carriage returns." The write(2) system call inserts nothing and simply hands off the buffer to the relevant part of the kernel I/O subsystem. (The kernel in POSIX is *not* a monolithic black box.) When stdout for your test program is a pty slave, that relevant part is the kernel terminal driver. The kernel terminal driver is converting "\n" to "\r\n" upon output to the associated port, since hardware terminals typically *do* require CRLF. The associated port in this case is virtual and part of the kernel pty subsystem, which presents octets written to that port to its associated pty master device. The user-visible pty slave device acts just like a serial terminal, including all translations normally done for handling serial terminals. A pty is conceptually a null-modem cable connected between two infinitely-fast serial ports on the same machine, although the slave will still report an actual baud rate if queried. (Run "stty" with no arguments under script(1), an ssh session, or an X11 terminal emulator to see what a pty slave looks like on your machine.) In your case 1, the pty subsystem is not used and output is collected over a pipe. Using "./a.out > out; xxd out" would produce the same results. In cases 2 and 3, there is a pty involved, either set up by script(1) or by sshd (assuming you meant "enable putty logging" in case 3) that performs the standard terminal translations. In all cases, strace(1) will show the exact string written to the pty slave device, which will not include any extra CRs because *those* *are* *inserted* *by* *the* *kernel* *terminal* *driver* as the data is transferred to the pty master device's read queue. This insertion of carriage returns is expected and standardized behavior in POSIX and is the reason Unix could use bare LF as end-of-line even though hardware terminals always needed CRLF. CP/M (and therefore MS-DOS which began its existence as a cheap CP/M knockoff) did not have this translation layer and instead dumped the complexity of a two-octet end-of-line sequence on user programs, leading to much confusion even today. This is not a Wine issue, although the terminal escape sequences in your original issue *were* from Wine. Note that the number of excess carriage returns that a DejaGnu testsuite must be prepared to discard is unspecified because running tests on remote targets may result in *any* *number* of CRs preceding each LF by the time the results reach the test driver machine in more complex testing lab environments. -- Jacob ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2023-01-06 3:33 ` Jacob Bachmeyer @ 2023-01-06 3:44 ` Jerry D 2023-01-08 7:12 ` NightStrike 1 sibling, 0 replies; 23+ messages in thread From: Jerry D @ 2023-01-06 3:44 UTC (permalink / raw) To: jcb62281, NightStrike; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu On 1/5/23 7:33 PM, Jacob Bachmeyer via Fortran wrote: > NightStrike wrote: >> On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> >> wrote: >>> NightStrike wrote: >>>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer >>>> <jcb62281@gmail.com> wrote: >>>>> [...] >>>> So at least we know for sure that this particular instance of extra >>>> characters is coming from Wine. Maybe Wine can be smart enough to >>>> only translate \n into \r\n instead of translating \r\n into \r\r\n. >>>> Jacek / Eric, comments here? I'm happy to try another patch, the >>>> first one was great. >>>> >>> I doubt that Wine is doing that translation. MinGW libc produces output >>> conformant to Windows conventions, so printf("\n") on a text handle >>> emits "\r\n", which Wine passes along. POSIX convention is that "\n" is >>> translated to "\r\n" in the kernel terminal driver upon output, so the >>> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding >>> "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be >>> prepared to discard excess carriage returns. The first CR came from >>> MinGW libc; the second CR came from the kernel terminal driver; the LF >>> was ultimately passed through. >> >> Jacek and I have been digging into this on IRC, and he's been very >> helpful in trying to get further, but we're still stuck. We tried to >> be more introspective, inserting strace both as "strace script wine" >> and as "script strace wine". We tried running just "wine a.exe" >> without any extra glue, and logging the raw SSH packets from putty. >> After many iterations on these and other tests, Jacek finally had the >> idea to try removing Windows entirely from the equation, and we ran >> with a purely unix program / compiler combination: >> >> #include <unistd.h> >> >> int main() >> { >> write(1, "test\r\n", 6); >> return 0; >> } >> >> (and also as "test\n", 5) >> >> In both versions, the following was observed: >> >> case 1) ./a.out | xxd >> case 2) script -c ./a.out out; xxd out >> case 3) enable putting logging, ./a.out >> >> In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an >> extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n). >> >> So, is it possible after all of this back and forth regarding mingw, >> wine, and others, that it's down to the write() system call that's >> inserting extra \r's? Is this expected? > > "This is why DejaGnu testsuites must be prepared to discard excess > carriage returns." > > The write(2) system call inserts nothing and simply hands off the buffer > to the relevant part of the kernel I/O subsystem. (The kernel in POSIX > is *not* a monolithic black box.) When stdout for your test program is > a pty slave, that relevant part is the kernel terminal driver. The > kernel terminal driver is converting "\n" to "\r\n" upon output to the > associated port, since hardware terminals typically *do* require CRLF. > The associated port in this case is virtual and part of the kernel pty > subsystem, which presents octets written to that port to its associated > pty master device. The user-visible pty slave device acts just like a > serial terminal, including all translations normally done for handling > serial terminals. > > A pty is conceptually a null-modem cable connected between two > infinitely-fast serial ports on the same machine, although the slave > will still report an actual baud rate if queried. (Run "stty" with no > arguments under script(1), an ssh session, or an X11 terminal emulator > to see what a pty slave looks like on your machine.) > > In your case 1, the pty subsystem is not used and output is collected > over a pipe. Using "./a.out > out; xxd out" would produce the same > results. In cases 2 and 3, there is a pty involved, either set up by > script(1) or by sshd (assuming you meant "enable putty logging" in case > 3) that performs the standard terminal translations. In all cases, > strace(1) will show the exact string written to the pty slave device, > which will not include any extra CRs because *those* *are* *inserted* > *by* *the* *kernel* *terminal* *driver* as the data is transferred to > the pty master device's read queue. > > This insertion of carriage returns is expected and standardized behavior > in POSIX and is the reason Unix could use bare LF as end-of-line even > though hardware terminals always needed CRLF. CP/M (and therefore > MS-DOS which began its existence as a cheap CP/M knockoff) did not have > this translation layer and instead dumped the complexity of a two-octet > end-of-line sequence on user programs, leading to much confusion even > today. This is not a Wine issue, although the terminal escape sequences > in your original issue *were* from Wine. Note that the number of excess > carriage returns that a DejaGnu testsuite must be prepared to discard is > unspecified because running tests on remote targets may result in *any* > *number* of CRs preceding each LF by the time the results reach the test > driver machine in more complex testing lab environments. > > > -- Jacob Agree ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2023-01-06 3:33 ` Jacob Bachmeyer 2023-01-06 3:44 ` Jerry D @ 2023-01-08 7:12 ` NightStrike 2023-01-11 2:30 ` Jacob Bachmeyer 1 sibling, 1 reply; 23+ messages in thread From: NightStrike @ 2023-01-08 7:12 UTC (permalink / raw) To: jcb62281; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu On Thu, Jan 5, 2023 at 10:33 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > > NightStrike wrote: > > On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > > > >> NightStrike wrote: > >> > >>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > >>> > >>>> [...] > >>> So at least we know for sure that this particular instance of extra > >>> characters is coming from Wine. Maybe Wine can be smart enough to > >>> only translate \n into \r\n instead of translating \r\n into \r\r\n. > >>> Jacek / Eric, comments here? I'm happy to try another patch, the > >>> first one was great. > >>> > >>> > >> I doubt that Wine is doing that translation. MinGW libc produces output > >> conformant to Windows conventions, so printf("\n") on a text handle > >> emits "\r\n", which Wine passes along. POSIX convention is that "\n" is > >> translated to "\r\n" in the kernel terminal driver upon output, so the > >> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding > >> "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be > >> prepared to discard excess carriage returns. The first CR came from > >> MinGW libc; the second CR came from the kernel terminal driver; the LF > >> was ultimately passed through. > >> > > > > Jacek and I have been digging into this on IRC, and he's been very > > helpful in trying to get further, but we're still stuck. We tried to > > be more introspective, inserting strace both as "strace script wine" > > and as "script strace wine". We tried running just "wine a.exe" > > without any extra glue, and logging the raw SSH packets from putty. > > After many iterations on these and other tests, Jacek finally had the > > idea to try removing Windows entirely from the equation, and we ran > > with a purely unix program / compiler combination: > > > > #include <unistd.h> > > > > int main() > > { > > write(1, "test\r\n", 6); > > return 0; > > } > > > > (and also as "test\n", 5) > > > > In both versions, the following was observed: > > > > case 1) ./a.out | xxd > > case 2) script -c ./a.out out; xxd out > > case 3) enable putting logging, ./a.out > > > > In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an > > extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n). > > > > So, is it possible after all of this back and forth regarding mingw, > > wine, and others, that it's down to the write() system call that's > > inserting extra \r's? Is this expected? > > > > "This is why DejaGnu testsuites must be prepared to discard excess > carriage returns." > > The write(2) system call inserts nothing and simply hands off the buffer > to the relevant part of the kernel I/O subsystem. (The kernel in POSIX > is *not* a monolithic black box.) When stdout for your test program is > a pty slave, that relevant part is the kernel terminal driver. The > kernel terminal driver is converting "\n" to "\r\n" upon output to the > associated port, since hardware terminals typically *do* require CRLF. > The associated port in this case is virtual and part of the kernel pty > subsystem, which presents octets written to that port to its associated > pty master device. The user-visible pty slave device acts just like a > serial terminal, including all translations normally done for handling > serial terminals. > > A pty is conceptually a null-modem cable connected between two > infinitely-fast serial ports on the same machine, although the slave > will still report an actual baud rate if queried. (Run "stty" with no > arguments under script(1), an ssh session, or an X11 terminal emulator > to see what a pty slave looks like on your machine.) > > In your case 1, the pty subsystem is not used and output is collected > over a pipe. Using "./a.out > out; xxd out" would produce the same > results. In cases 2 and 3, there is a pty involved, either set up by > script(1) or by sshd (assuming you meant "enable putty logging" in case > 3) that performs the standard terminal translations. In all cases, > strace(1) will show the exact string written to the pty slave device, > which will not include any extra CRs because *those* *are* *inserted* > *by* *the* *kernel* *terminal* *driver* as the data is transferred to > the pty master device's read queue. > > This insertion of carriage returns is expected and standardized behavior > in POSIX and is the reason Unix could use bare LF as end-of-line even > though hardware terminals always needed CRLF. CP/M (and therefore > MS-DOS which began its existence as a cheap CP/M knockoff) did not have > this translation layer and instead dumped the complexity of a two-octet > end-of-line sequence on user programs, leading to much confusion even > today. This is not a Wine issue, although the terminal escape sequences > in your original issue *were* from Wine. Note that the number of excess > carriage returns that a DejaGnu testsuite must be prepared to discard is > unspecified because running tests on remote targets may result in *any* > *number* of CRs preceding each LF by the time the results reach the test > driver machine in more complex testing lab environments. First, I just want to thank you for your patience. You are putting a lot of effort into these replies, and it is appreciated. I did another little test to try to better understand your point. I ran a linux native testsuite under a simulator that just sets SIM to " ". This resulted in extra ^M's also, although many tests pass because they're already looking for \r\n to accommodate windows. So I think I've come around to grasp what you've been heroically re-explaining... So if we have to modify every test in the entire testsuite to check for zero or more \r's followed by zero or more \n's, would it be better to add a dg-output-line proc that does this automatically everywhere? I feel like changing every output pattern test won't be too maintainable. You had mentioned previously modifying ${tool}_load to filter out extra \r's, but I couldn't see where or how to do that. For completeness, setting a random selection of tests to look for \r*\n? worked (this would cover even deprecated systems that only use CR as well as flagging the weird rust case of \r\r\n\n as bad). ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2023-01-08 7:12 ` NightStrike @ 2023-01-11 2:30 ` Jacob Bachmeyer 2023-01-11 9:33 ` NightStrike 0 siblings, 1 reply; 23+ messages in thread From: Jacob Bachmeyer @ 2023-01-11 2:30 UTC (permalink / raw) To: NightStrike; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu NightStrike wrote: > [...] > I did another little test to try to better understand your point. I > ran a linux native testsuite under a simulator that just sets SIM to " > ". This resulted in extra ^M's also, although many tests pass because > they're already looking for \r\n to accommodate windows. So I think > I've come around to grasp what you've been heroically re-explaining... > > So if we have to modify every test in the entire testsuite to check > for zero or more \r's followed by zero or more \n's, would it be > better to add a dg-output-line proc that does this automatically > everywhere? Two problems: first, you need zero-or-more \r and *one*-or-more \n. Second, dg-output is not defined as an anchored match, and therefore cannot do this automatically. > I feel like changing every output pattern test won't be > too maintainable. You had mentioned previously modifying ${tool}_load > to filter out extra \r's, but I couldn't see where or how to do that. > > For completeness, setting a random selection of tests to look for > \r*\n? worked (this would cover even deprecated systems that only use > CR as well as flagging the weird rust case of \r\r\n\n as bad). Do not worry about classic Mac OS---running DejaGnu on that platform is not possible, nor is it possible to run test programs remotely on that platform. Classic Mac OS is a pure-GUI system with no command interface whatsoever. Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl exec(n) command. Due to limitations of the platform, porting Expect to classic Mac OS is simply not possible. Any compatibility layer would be reasonably expected to translate CR<->LF, if, for example, someone wrote a telnet server (and associated POSIX-alike environment) for Mac OS. The later Mac OS X is a quasi-POSIX mostly compatible with the GNU system that uses POSIX line endings. DejaGnu should run normally there. Are there other systems that used bare CR as end-of-line? If not, the correct pattern is therefore {\r*\n} (here written using braces as quotes around the pattern). -- Jacob ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2023-01-11 2:30 ` Jacob Bachmeyer @ 2023-01-11 9:33 ` NightStrike 2023-01-12 4:11 ` Jacob Bachmeyer 0 siblings, 1 reply; 23+ messages in thread From: NightStrike @ 2023-01-11 9:33 UTC (permalink / raw) To: jcb62281; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > > NightStrike wrote: > > [...] > > I did another little test to try to better understand your point. I > > ran a linux native testsuite under a simulator that just sets SIM to " > > ". This resulted in extra ^M's also, although many tests pass because > > they're already looking for \r\n to accommodate windows. So I think > > I've come around to grasp what you've been heroically re-explaining... > > > > So if we have to modify every test in the entire testsuite to check > > for zero or more \r's followed by zero or more \n's, would it be > > better to add a dg-output-line proc that does this automatically > > everywhere? > > Two problems: first, you need zero-or-more \r and *one*-or-more \n. > Second, dg-output is not defined as an anchored match, and therefore > cannot do this automatically. "or more" \n is valid? That would make the rust bug of \r\r\n\n pass when I assume it shouldn't. > > I feel like changing every output pattern test won't be > > too maintainable. You had mentioned previously modifying ${tool}_load > > to filter out extra \r's, but I couldn't see where or how to do that. > > > > For completeness, setting a random selection of tests to look for > > \r*\n? worked (this would cover even deprecated systems that only use > > CR as well as flagging the weird rust case of \r\r\n\n as bad). > > Do not worry about classic Mac OS---running DejaGnu on that platform is > not possible, nor is it possible to run test programs remotely on that > platform. Classic Mac OS is a pure-GUI system with no command interface > whatsoever. Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl > exec(n) command. Due to limitations of the platform, porting Expect to > classic Mac OS is simply not possible. Any compatibility layer would be > reasonably expected to translate CR<->LF, if, for example, someone wrote > a telnet server (and associated POSIX-alike environment) for Mac OS. > > The later Mac OS X is a quasi-POSIX mostly compatible with the GNU > system that uses POSIX line endings. DejaGnu should run normally there. > > Are there other systems that used bare CR as end-of-line? If not, the > correct pattern is therefore {\r*\n} (here written using braces as > quotes around the pattern). Maybe none that matter. From https://en.wikipedia.org/wiki/Newline#Representation: Commodore 8-bit machines (C64, C128), Acorn BBC, ZX Spectrum, TRS-80, Apple II series, Oberon, the classic Mac OS, MIT Lisp Machine and OS-9 The article also goes on to mention that OpenVMS and RSX-11 can be configured to use CR. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2023-01-11 9:33 ` NightStrike @ 2023-01-12 4:11 ` Jacob Bachmeyer 0 siblings, 0 replies; 23+ messages in thread From: Jacob Bachmeyer @ 2023-01-12 4:11 UTC (permalink / raw) To: NightStrike; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu NightStrike wrote: > On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: > >> NightStrike wrote: >> >>> [...] >>> I did another little test to try to better understand your point. I >>> ran a linux native testsuite under a simulator that just sets SIM to " >>> ". This resulted in extra ^M's also, although many tests pass because >>> they're already looking for \r\n to accommodate windows. So I think >>> I've come around to grasp what you've been heroically re-explaining... >>> >>> So if we have to modify every test in the entire testsuite to check >>> for zero or more \r's followed by zero or more \n's, would it be >>> better to add a dg-output-line proc that does this automatically >>> everywhere? >>> >> Two problems: first, you need zero-or-more \r and *one*-or-more \n. >> Second, dg-output is not defined as an anchored match, and therefore >> cannot do this automatically. >> > > "or more" \n is valid? Only if you are ignoring blank lines. Note that you had earlier said zero-or-more \r and zero-or-more \n, which would be a pattern that can match with zero length. > That would make the rust bug of \r\r\n\n pass > when I assume it shouldn't. > The pattern that I suggested as correct is zero-or-more \r followed by exactly one \n. If you are ignoring blank lines in buffered text, but /not/ in live Expect, you can use {[\r\n]+} (any non-empty sequence of \r and \n) but this will /not/ work with live Expect, because it can match a prefix of the intended text. >>> I feel like changing every output pattern test won't be >>> too maintainable. You had mentioned previously modifying ${tool}_load >>> to filter out extra \r's, but I couldn't see where or how to do that. >>> >>> For completeness, setting a random selection of tests to look for >>> \r*\n? worked (this would cover even deprecated systems that only use >>> CR as well as flagging the weird rust case of \r\r\n\n as bad). >>> >> Do not worry about classic Mac OS---running DejaGnu on that platform is >> not possible, nor is it possible to run test programs remotely on that >> platform. Classic Mac OS is a pure-GUI system with no command interface >> whatsoever. Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl >> exec(n) command. Due to limitations of the platform, porting Expect to >> classic Mac OS is simply not possible. Any compatibility layer would be >> reasonably expected to translate CR<->LF, if, for example, someone wrote >> a telnet server (and associated POSIX-alike environment) for Mac OS. >> >> The later Mac OS X is a quasi-POSIX mostly compatible with the GNU >> system that uses POSIX line endings. DejaGnu should run normally there. >> >> Are there other systems that used bare CR as end-of-line? If not, the >> correct pattern is therefore {\r*\n} (here written using braces as >> quotes around the pattern). >> > > Maybe none that matter. From > https://en.wikipedia.org/wiki/Newline#Representation: > > Commodore 8-bit machines (C64, C128), Acorn BBC, ZX Spectrum, TRS-80, > Apple II series, Oberon, the classic Mac OS, MIT Lisp Machine and OS-9 > DejaGnu is not going to run on any of those, and remote testing with any of those as targets gets ... "interesting" ... very quickly. Oberon, similarly to classic MacOS simply does not have a command line, although it /does/ have enough infrastructure that implementing some kind of line-oriented command interface could be feasible and some Oberon versions do have network capability. Nonetheless, the entire Oberon system is written in its own language, so a testsuite for an Oberon target would be expected to be specially written accordingly. I already mentioned classic MacOS. Lisp Machines evaluate similarly to Oberon, using their own language for all software (in this case, Lisp) with the additional element of being highly unlikely to be found outside of a computer museum, having never been common. OS-9 is interesting, but is an oddball nonfree system with niche uses. Nonetheless, it does have a shell, so it fits in with the others mentioned below. The rest are various 8-bit systems, where some level of remote testing might be possible over a serial line, but see stty(1) and the icrnl and inlcr options for that case (the POSIX terminal driver can translate incoming CR to LF and vice versa). > The article also goes on to mention that OpenVMS and RSX-11 can be > configured to use CR. > Those systems actually store each line as a separate record; the /same/ file can be read with LF or CRLF by simply asking, if I read that article correctly. -- Jacob ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: testsuite under wine 2023-01-05 2:50 ` NightStrike 2023-01-06 3:33 ` Jacob Bachmeyer @ 2023-01-06 3:41 ` Jerry D 1 sibling, 0 replies; 23+ messages in thread From: Jerry D @ 2023-01-06 3:41 UTC (permalink / raw) To: NightStrike, jcb62281; +Cc: Jacek Caban, fortran, Eric Pouech, gcc, dejagnu On 1/4/23 6:50 PM, NightStrike via Fortran wrote: > On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: >> NightStrike wrote: >>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote: >>>> NightStrike wrote: >>>> >>>>> [...] >>>>> Second, the problems with extra \r's still remain, but I think we've >>>>> generally come to think that that part isn't Wine and is instead >>>>> either the testsuite or deja. So I'll keep those replies to Jacob's >>>>> previous message. >>>>> >>>>> >>>> Most likely, it is a combination of the MinGW libc (which emits "\r\n" >>>> for end-of-line in accordance with Windows convention) and the kernel >>>> terminal driver (which passes "\r" and translates "\n" to "\r\n" in >>>> accordance with POSIX convention). Wine, short of trying to translate >>>> "\r\n" back to "\n" in accordance with POSIX conventions (and likely >>>> making an even bigger mess---does Wine know if a handle is supposed to >>>> be text or binary?) cannot really fix this, so the testsuite needs to >>>> handle non-POSIX-standard line endings. (The Rust tests probably have >>>> an outright bug if the newlines are being duplicated.) >>>> >>> >>> You may be onto something here. I ran wine under script as `script -c >>> "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r >>> prepended to the \r\n. I was making the mistake previously of running >>> wine manually and capturing it to a file as `wine64 ./a.exe > out`, >>> which as several have pointed out in this thread, that would disable >>> the quirk, so of course it didn't reveal any problems. I'm behind, >>> but I'll catch up to you guys eventually :) >>> >> >> So close, and yet so far... script(1) /also/ uses a pty, so it is >> getting the same translations as Expect and therefore DejaGnu. >> >>> So at least we know for sure that this particular instance of extra >>> characters is coming from Wine. Maybe Wine can be smart enough to >>> only translate \n into \r\n instead of translating \r\n into \r\r\n. >>> Jacek / Eric, comments here? I'm happy to try another patch, the >>> first one was great. >>> >> >> I doubt that Wine is doing that translation. MinGW libc produces output >> conformant to Windows conventions, so printf("\n") on a text handle >> emits "\r\n", which Wine passes along. POSIX convention is that "\n" is >> translated to "\r\n" in the kernel terminal driver upon output, so the >> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding >> "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be >> prepared to discard excess carriage returns. The first CR came from >> MinGW libc; the second CR came from the kernel terminal driver; the LF >> was ultimately passed through. > > Jacek and I have been digging into this on IRC, and he's been very > helpful in trying to get further, but we're still stuck. We tried to > be more introspective, inserting strace both as "strace script wine" > and as "script strace wine". We tried running just "wine a.exe" > without any extra glue, and logging the raw SSH packets from putty. > After many iterations on these and other tests, Jacek finally had the > idea to try removing Windows entirely from the equation, and we ran > with a purely unix program / compiler combination: > > #include <unistd.h> > > int main() > { > write(1, "test\r\n", 6); > return 0; > } > > (and also as "test\n", 5) > > In both versions, the following was observed: > > case 1) ./a.out | xxd > case 2) script -c ./a.out out; xxd out > case 3) enable putting logging, ./a.out > > In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an > extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n). > > So, is it possible after all of this back and forth regarding mingw, > wine, and others, that it's down to the write() system call that's > inserting extra \r's? Is this expected? I have reproduced this test with C. I suspect that the 'write' function was written to accommodate non standard behavior of windows which expects a CR-LF. This means that POSIX compliant code is adjusted by the C or gfortran libraries to emit a extra CR so that on Windows it will just work ok. So the test is doing exactly what you are telling it to do. An LF causes the run times to add a CR in front. With libgfortran I remember implementing some of this code myself and this is the reason, to keep applications happy on Windows. So the gfortran tests we wrote to accept either a CR or a CR-LF, and in the test code to only issue a normal line ending which on UNIX will be an LF and Windows an CR-LF. I lose track of details in between looking ta the test cases. let me know one of them to study that is gfortran side and will see what it is doing. Jerry ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2023-01-12 4:11 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAF1jjLtJW0juQR6L-VybJ8SSaqkfi=qN9FnxJVaY=oQBtkSLxA@mail.gmail.com> [not found] ` <3f62bac2-ac1b-5c55-2488-ede2389d35d2@netcologne.de> [not found] ` <CAF1jjLvJU2fnU0u0p9SwPre5mnhFdmv9pm_OvZGOvjQApCROqw@mail.gmail.com> 2022-12-17 10:52 ` testsuite under wine Thomas Koenig 2022-12-17 23:24 ` NightStrike 2022-12-18 3:44 ` Jacob Bachmeyer 2022-12-18 21:13 ` NightStrike 2022-12-19 4:29 ` Jacob Bachmeyer 2022-12-19 10:43 ` Torbjorn SVENSSON 2022-12-19 11:00 ` NightStrike 2022-12-19 11:13 ` NightStrike 2022-12-20 3:51 ` Jacob Bachmeyer [not found] ` <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com> 2022-12-22 1:01 ` NightStrike 2022-12-22 4:37 ` Jacob Bachmeyer 2022-12-23 10:36 ` NightStrike 2022-12-23 12:43 ` Eric Pouech 2022-12-24 4:00 ` Jacob Bachmeyer 2022-12-24 11:05 ` Mark Wielaard 2023-01-05 2:50 ` NightStrike 2023-01-06 3:33 ` Jacob Bachmeyer 2023-01-06 3:44 ` Jerry D 2023-01-08 7:12 ` NightStrike 2023-01-11 2:30 ` Jacob Bachmeyer 2023-01-11 9:33 ` NightStrike 2023-01-12 4:11 ` Jacob Bachmeyer 2023-01-06 3:41 ` Jerry D
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).