I've moved this conversation to its own topic. The other one is complete.
Simon said:
So you've took the manual steps that where opened in a new cmd window, and found all good so answered with "Y" - correct?
Did you recognize anything "new" to you related to GnuCOBOL screenio or things that seemed "special" with the new PDCursesMod?
Can you picture more tests that may should be added for checkmanual?
I've only run it the once with somewhat confused results against 3.2dev.
Unpacked the source files into my mingw system - edited the atlocal.in in the gnu*/tests folder to remove the cygwin lines as suggested by Simon then continued the configure, make, make install & finally ran the make checkmanual.
This then produced a second cmd prompt screen with the tests run inside it.
Several of the tests 'appeared' to me to run twice - identically - although I'm unable to confirm that.
Certainly in my system - Win10 64bit there were a number of tests that actually failed - blink, underline and so on - see attached test results captured - xx along with a screen copy of a test -z.
I'd really like to run the tests again so I did the following.
Edited my build script to just run the make checkmanual in the /mingw/msys/gnu*/tests folder - but it just ran thru and failed all the tests.
How do I rerun the tests without doing an actual build ?????.
I would also suggest that the test number be displayed in the body of the test - like this:
Test 27 Enter "y" if you cannot continue without filling all of the below field:
I'm going to redo the build & tests & take more notice this time.
The usage of the tests is somewhat strange - as follows:
You're asked to enter a y if the test displays what it says - however the majority of tests already display a Y in some position on the screen (although that isn't necessarily where the cursor end up).
In addition - there is at least 1 test where you enter 5 characters and it jumps to another accept line where you enter another 5 characters and then press enter - it just exited the test at that point.
IF you don't enter a y then I think it's accepting that the test failed.
Perhaps IF the test ONLY accepted y/Y or n/N before it continued would be better.
And maybe a r/R to rerun the test would be good.
There was also 1 test where there was no way I could exit the test without Ctl/Brk - it just wouldn't go to the y position.
Having a test number like I suggested above would be nice .
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi David and thanks for the testing and first feedback. I agree that a separate issue is very useful.
First: re-running the test after the initial build would mean one of:
direct:
open MSYS
either
cd /to/build/folder && make checkmanual or
make -C /to/build/folder checkmanual
make invocation from cmd: set PATH=%MINGWDIR%\bin;%MINGWDIR%\msys\1.0\bin;%PATH%
set MSYSTEM=cmd
make -C X:\Path\To\GC-Build\tests checkmanual
msys invocation from cmd (that works with msys2, maybe similar also with an updated msys.bat): msys2_shell.cmd -where X:\Path\To\GC-Build\tests -no-start -c "make checkmanual"
We added the "Y" as the common answer as a default value, but it may be reasonable to use the original "value is space" approach.
The test topic and the number should be visible in the "original" test window, isn't that enough? At least the number is in the environment of the process so it could be used with an ACCEPT FROM ENVIRONMENT - I'm just not sure about its usefulness yet (also because the numbers change more often than the title part).
The R is a good idea (although it may not work 100% - because the screen is already initialized and was used) and would be quite easy to implement (IF ANSWER = "R" DISPLAY " " EOS GO TO MAIN.). Do you think it is still useful?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The test topic and the number should be visible in the "original" test window, isn't that enough?
I agree that it's in the 'original' running window - but that doesn't relate to the cmd window - you have to alt tab between them to see the topic & number.
Maybe it's not necessary - but trying to understand what the test is actually trying to achieve would be nice.
Which is the build folder - gnu or gnu/tests ???
I've tried 'as I've said' doing a cd msys/gnu/tests followed by a make checkmanual - as well as a cd msys/gnu followed by a make checkmanual and both fail miserably.
Even running a build with the make checkmanual included in it (which works) followed by a make checkmanual (which then fails miserably).
I can't get it to run stand alone without actually doing a build first - even though a build is the last thing I've done. strange.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The build folder is whereever you run "configure"; which may be the same as the sourcedirectory - where the configure script is.
If you only want to run the tests there is no use in letting make go through all the directories, so it is best to use the tests directory in this case
... actually that reminds me that for the autoconf generated testsuites make is not even necessary - because the testsuite it is a single generated script (which sources atconfig and atlocal to know how/where to run the tests), but it definitely eases the call as make executes that from the builddir/tests and executes it from sourcedir/tests.
Rechecked: there's the variable at_group which contains the current group, it seems there is also at_desc_line which contains the test number and description; the test title could use that... checking ... yes, should be possible - they aren't exported so not visible, but the testsuite could pass those...
I've finally came up with more changes, and those will provide the number and line in the xterm and cmd window title, as well as the title for the GNU screen session which is used as fallback (commonly this won't be seen, but now it is at least "there"). Checked in to 3.x with [r4552], given the last timing it may be available in about 45 minutes as CI tarball - I've attached the two files that you may copy into an old version for convenience.
Thank you Simon - Numbering with test name works fine - the only tests that didn't work (except those expected to fail) were:
17 Auto - still can't get the 2nd box to allow me to enter the 3rd box - pressing enter at the end of box 2 just exits the test.
23 Blink - (running on PC so actually expected)
27 Full & Required - Unable to enter the Y as it wouldn't exit the box - had to ctl/brk.
38 Underline - Running on PC again so expected ??.
46 Alt RT Arrow - moving right to end of field exited the test - silly me..
Several tests still actually seem to accept the Y key in the test area as opposed to the displayed Y character. Tests - 3, 22, 29, 34?, 37, 39 - Maybe just me - sorry.
I'm still messing with running the checkmanual on its own - maybe tomorrow I'll get it to work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've moved this conversation to its own topic. The other one is complete.
Simon said:
So you've took the manual steps that where opened in a new cmd window, and found all good so answered with "Y" - correct?
Did you recognize anything "new" to you related to GnuCOBOL screenio or things that seemed "special" with the new PDCursesMod?
Can you picture more tests that may should be added for checkmanual?
I've only run it the once with somewhat confused results against 3.2dev.
Unpacked the source files into my mingw system - edited the atlocal.in in the gnu*/tests folder to remove the cygwin lines as suggested by Simon then continued the configure, make, make install & finally ran the make checkmanual.
This then produced a second cmd prompt screen with the tests run inside it.
Several of the tests 'appeared' to me to run twice - identically - although I'm unable to confirm that.
Certainly in my system - Win10 64bit there were a number of tests that actually failed - blink, underline and so on - see attached test results captured - xx along with a screen copy of a test -z.
I'd really like to run the tests again so I did the following.
Edited my build script to just run the make checkmanual in the /mingw/msys/gnu*/tests folder - but it just ran thru and failed all the tests.
How do I rerun the tests without doing an actual build ?????.
I would also suggest that the test number be displayed in the body of the test - like this:
Test 27 Enter "y" if you cannot continue without filling all of the below field:
I'm going to redo the build & tests & take more notice this time.
The usage of the tests is somewhat strange - as follows:
You're asked to enter a y if the test displays what it says - however the majority of tests already display a Y in some position on the screen (although that isn't necessarily where the cursor end up).
In addition - there is at least 1 test where you enter 5 characters and it jumps to another accept line where you enter another 5 characters and then press enter - it just exited the test at that point.
IF you don't enter a y then I think it's accepting that the test failed.
Perhaps IF the test ONLY accepted y/Y or n/N before it continued would be better.
And maybe a r/R to rerun the test would be good.
There was also 1 test where there was no way I could exit the test without Ctl/Brk - it just wouldn't go to the y position.
Having a test number like I suggested above would be nice .
Hi David and thanks for the testing and first feedback. I agree that a separate issue is very useful.
First: re-running the test after the initial build would mean one of:
cd /to/build/folder && make checkmanualormake -C /to/build/folder checkmanualset PATH=%MINGWDIR%\bin;%MINGWDIR%\msys\1.0\bin;%PATH% set MSYSTEM=cmd make -C X:\Path\To\GC-Build\tests checkmanualmsys2_shell.cmd -where X:\Path\To\GC-Build\tests -no-start -c "make checkmanual"We added the "Y" as the common answer as a default value, but it may be reasonable to use the original "value is space" approach.
The test topic and the number should be visible in the "original" test window, isn't that enough? At least the number is in the environment of the process so it could be used with an
ACCEPT FROM ENVIRONMENT- I'm just not sure about its usefulness yet (also because the numbers change more often than the title part).The R is a good idea (although it may not work 100% - because the screen is already initialized and was used) and would be quite easy to implement (
IF ANSWER = "R" DISPLAY " " EOS GO TO MAIN.). Do you think it is still useful?The test topic and the number should be visible in the "original" test window, isn't that enough?
I agree that it's in the 'original' running window - but that doesn't relate to the cmd window - you have to alt tab between them to see the topic & number.
Maybe it's not necessary - but trying to understand what the test is actually trying to achieve would be nice.
Which is the build folder - gnu or gnu/tests ???
I've tried 'as I've said' doing a cd msys/gnu/tests followed by a make checkmanual - as well as a cd msys/gnu followed by a make checkmanual and both fail miserably.
Even running a build with the make checkmanual included in it (which works) followed by a make checkmanual (which then fails miserably).
I can't get it to run stand alone without actually doing a build first - even though a build is the last thing I've done. strange.
The build folder is whereever you run "configure"; which may be the same as the sourcedirectory - where the configure script is.
If you only want to run the tests there is no use in letting make go through all the directories, so it is best to use the tests directory in this case
... actually that reminds me that for the autoconf generated testsuites make is not even necessary - because the testsuite it is a single generated script (which sources atconfig and atlocal to know how/where to run the tests), but it definitely eases the call as make executes that from the builddir/tests and executes it from sourcedir/tests.
Rechecked: there's the variable
at_groupwhich contains the current group, it seems there is alsoat_desc_linewhich contains the test number and description; the test title could use that... checking ... yes, should be possible - they aren't exported so not visible, but the testsuite could pass those...I've finally came up with more changes, and those will provide the number and line in the xterm and cmd window title, as well as the title for the GNU screen session which is used as fallback (commonly this won't be seen, but now it is at least "there"). Checked in to 3.x with [r4552], given the last timing it may be available in about 45 minutes as CI tarball - I've attached the two files that you may copy into an old version for convenience.
Related
Commit: [r4552]
Thank you Simon - Numbering with test name works fine - the only tests that didn't work (except those expected to fail) were:
17 Auto - still can't get the 2nd box to allow me to enter the 3rd box - pressing enter at the end of box 2 just exits the test.
23 Blink - (running on PC so actually expected)
27 Full & Required - Unable to enter the Y as it wouldn't exit the box - had to ctl/brk.
38 Underline - Running on PC again so expected ??.
46 Alt RT Arrow - moving right to end of field exited the test - silly me..
Several tests still actually seem to accept the Y key in the test area as opposed to the displayed Y character. Tests - 3, 22, 29, 34?, 37, 39 - Maybe just me - sorry.
I'm still messing with running the checkmanual on its own - maybe tomorrow I'll get it to work.