savetty now failing with pdcurses 4.3.2a

[David Wall]

One of my standard test programs is a screen display of all the colours - with the ability to resize the screen using savetty & resetty.
Recently was advised of a later release of PDCurses 4.3.2a so decided to have a play.

Built pdc432 & then rebuilt 3.2dev.

Got a - Assertion failed: SP, file ../pdcurses/kernel.c, line 209 when test program run.
line 209 & surrounding lines say:

int savetty(void)
{
    PDC_LOG(("savetty() - called\n"));
    assert( SP);                                                                // ----   line 209
    if (!SP)
        return ERR;
    _save_mode(PDC_SAVE_TTY);
    return OK;
}

So I'll assume it's the savetty in my prog that's failed. ??

Any ideas. ??

[David Wall]

Actually - removing the savetty & resetty made no difference - other than the program no longer crashes with the Assert fail.
I get NO display whatsoever whereas it works fine under PDC 4.3 1.
Ah well - shouldn't have bothered

[Simon Sobisch]

Recompiling GnuCOBOL is definitely reasonable as the symbol names changed - for configure to pass you don't need any defines set; for the build to work you still have to define the appropriate macros. I highly suggest to do it with any PDCurses version similar to ncurses: have a subfolder with the "real" header and a wrapper that points to it; and if (like any with PDCurses version so far) the header is not adjusted during install place the appropriate defines in the wrapper. More or less like done here https://github.com/msys2/MINGW-packages/blob/43a36f62155a3fe37e9c0ed914b656f2d040e746/mingw-w64-pdcurses/PKGBUILD#L121-L127 (adjusted with whatever defines are set when building pdcurses, of course).

To the original issue: The assert tells you:initsrc() was not called before (doing an "extended" DISPLAY will do so) or raised an error.

If you have built GnuCOBOL with the correct set of defines (possibly with the wrapper header approach from above) and initsrc() was called and it still doesn't work: you likely want to send that issue upstream: https://github.com/Bill-Gray/PDCursesMod/issues

[David Wall]

Simon - Since I'm originally from the UK - I 'understand' the words - BUT the context once again goes right over my head.
I've NO idea what a 'wrapper' is or "real" headers.

I've always built PDCurses with the following configure lines:
make -f Makefile INFOEX=N CHTYPE_32=Y DLL=Y

and the compiler with the following:
./configure "CPPFLAGS=-DCHTYPE_32 -DPDC_DLL_BUILD -Dinitscr=initscr_x32" --prefix=/mingw --with-vbisam --disable-rpath

at least from pdc3.8 onwards.

I just noticed that the cobc -info shows the following:

build information
build environment        : i686-pc-mingw32
CC                       : gcc
C version                : (MinGW) "9.2.0"
CPPFLAGS                 : -DCHTYPE_32 -DPDC_DLL_BUILD -Dinitscr=initscr_x32
                           -I/mingw/include
CFLAGS                   : -O2 -pipe -finline-functions -fsigned-char -Wall
                           -Wwrite-strings -Wmissing-prototypes
                           -Wno-format-y2k
LD                       : e:/mingw/mingw32/bin/ld.exe
LDFLAGS                  : 

GnuCOBOL information
COB_MODULE_EXT           : dll
dynamic loading          : system
"CBL_" param check       : disabled
64bit-mode               : no
BINARY-C-LONG            : 4 bytes
endianness               : little-endian
native EBCDIC            : no
variable file format     : 0
sequential file handler  : built-in
indexed file handler     : VBISAM
mathematical library     : GMP, version 6.2.1
XML library              : disabled
JSON library             : disabled
extended screen I/O      : disabled
mouse support            : disabled

So obviously something screwed up.

[Simon Sobisch]

Since I'm originally from the UK - I 'understand' the words

I'm not, so my words may be misleading :-) additional, there's the potential nerd-technobabble issue when doing things "too long". It is always helpful when you ask back in those cases.

So obviously something screwed up.

The important part here: read the Changelog for the new version, in this case https://github.com/Bill-Gray/PDCursesMod/releases/tag/v4.3.2a with

The "mangling" of initscr() to avoid versioning errors (see 'curses.h') is now done instead to endwin(). It makes no difference to PDCurses, but some other build processes relied on seeing an unmangled initscr().

So the configure line above - which was always the "bad hack" - tells configure to look for a symbol not there any more. Just drop that part and configure should find the library again (as it was pre 3.8).

Back to my technobabble: My suggestion is to follow the part of the "recipe" I've linked when installing pdcurses:

• install includes under include/pdcurses/*
• install a separate, manually created "include/pdcurses.h" which includes the necessary defines -and includes the installed header in your case that would be something along

#define DPDC_DLL_BUILD 1
#define CHTYPE_32 1
#include "pdcurses/curses.h"

This way you won't need to setup those on the configure line (that applies both to PDCursesMod 4.3.2 and the "classic" PDCurses, both new and old versions).

And now the assert you've seen also makes sense: because GnuCOBOL did not do any curses setup those functions cannot work and ... assert.

[David Wall]

OK - I had 1 last try & as you say above - removed the reference to initscr_xZZ where ZZ was either 32 or 64 depending on which one I wanted to use in the Cob Build.
Doing it the other way - by editing a pdcurses.h is a rather strange (in my opinion) way of doing the same thing - except that in your case it has to be edited EACH time you get a new PDC - whereas doing the CHTYPE & DPDC_DLL stuff on the Cobc Configure - no change has to be made to the PDC at all.
Horses for Courses I suppose.

Anyway - the test prog is working now & I didn't have to do anything to the PDC build - just removed the reference to initscrxxxx from my cobc build.
Thanks muchly.

One minor whinge though - the 'new' version of PDC certainly likes to 'FLASH' the screen whenever anything is done - my test prog changes the screen size on the fly and I'm getting screen flash after screen flash (showing scroll bars all the time) whenever the size changes - whereas it's certainly NOT so obvious under PDC431.

[Simon Sobisch]

The flashy part sounds bad, can you please create an issue at the PDCM site given above with details: "I call functions x, y, z and see a flash now" to either have the flash being removed or at least an option to tweak that flashing.

[David Wall]

Maybe it's just me - I do a resetty to change the screen size and that can happen quite quickly - so maybe i'm imagining it.
I sent a copy of my prog to AT - since he's the only one I know who would have PDC432 at hand.
I've asked him to see if he thinks there's a problem or not.

Still hoping to have a play with make checkmanual

Am having keyboard problems at the moment - my PS/2 k/b is doing strange things in upper case so I've had to resort to a usb k/b - which I don't like.

[Simon Sobisch]

Question: Did you already used the "manual testsuite" of GnuCOBOL's screenio? There was an update last year to it for supporting test runs started from a MSYS shell (but actually running under control of a plain "cmd"). If not: please do so: make checkmanual and report the results with the new PDCursesMod version (and possibly also with a rebuild of a 64bit chtype version).

This is an "interview" test - "Do you see XYZ, does ABC happens when you do DEF?" and also showcases some of the extended screenio features.

[David Wall]

I haven't done that yet - didn't know it existed to be honest. Will have a play today.

[David Wall]

Didn't get very far - stddef.h file not found - see attached log.

[David Wall]

Although the file does exist in E:\MINGW\libx\gcc\mingw32\9.2.0\include ??.

[Simon Sobisch]

I'm confused.
You'd just take your normal MinGW build that runs via configure && make, then do make checkmanual.

[David Wall]

Well - edited my build script to add make checkmanual in after the build & install.
see results attached - all 50 tests skipped ??.

This was for the latest 3.2 dev downloaded yesterday.

[Simon Sobisch]

You possibly want to edit test/atlocal and remove the following lines:

if test "x$MSYSTEM" != "x" -o "$OSTYPE" = "cygwin"; then
    # running MSYS builds as not-visible child processes result in
    # "Redirection is not supported" (at least old PDCurses)
    # --> disabling the tests for this feature
    # ncurses is known to work as long as TERM is appropriate
    if test $(grep -i -c "ncurses" info.out) != 0; then
        if test "x$MSYSTEM" != "x"; then
            TERM=""
        else
            TERM="xterm"
        fi
        export TERM
        # no change here... COB_HAS_CURSES="yes"
    else
        COB_HAS_CURSES="no"
    fi
fi

(if you need to do it before running configure - adjust tests/atlocal.in instead)

[David Wall]

Edited the atlocal.in file prior to running the configure and it all went thru - built my output folder fine.
Ran it against 4.0 as opposed to 3.2 and failed 50 tests and skipped 1.
See attached .log I'm off to bed as it's 1.30am here in OZ.

[Simon Sobisch]

and it all went thru

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?

Ran it against 4.0 as opposed to 3.2 and failed 50 tests and skipped 1.

I see, that's because of a missing merge of [r4481] from 3.x, just did this with [r4551] (note: there's no current CI build of 4.x because there's an issue with initialization of WORKING STORAGE so one test is failing and no newer CI tarball generated - if you use that you'd have to take over tests/run_prog_manual.sh.in from a 3.x one for now).