Enhancement: Write the bug-report.sh tool

ioccc-src / mkiocccentry

Form an IOCCC submission as a compressed tarball file

Other

28 stars 6 forks source link

Enhancement: Write the bug-report.sh tool #248

Closed lcn2 closed 1 year ago

lcn2 commented 2 years ago

Add a make report that would run the test suite and write various info to say bug-report.txt

The info would include version numbers, out of commands such as uname -a, compiler version info, contents of limit_ioccc.sh, encourage the user to report the contents of the bug-report.txt file in a GitHub bug report, etc.

xexyl commented 2 years ago

Good idea.

For some of the logs it might already be there - the json log comes to mind and so does the txzchk one for example.

Or do I have the wrong idea?

lcn2 commented 2 years ago

This rule is for users, not developers, to generate a problem report.

The bug report template, and README.md documentation would encourage a user, if they ran into a problem, to run make bug-report to generate a diagnostics file containing information that would be useful for submitting a bug report.

UPDATE 0:

Changed suggested make rule to: make bug-report?

xexyl commented 2 years ago

This rule is for users, not developers, to generate a problem report.

If you were replying here to my thought about logs what I meant is maybe those log files could be concatenated to a final report? Not sure. It was a quick idea and I have some other things on my mind as well.

The bug report template, and README.md documentation would encourage a user, if they ran into a problem, to run make chk to generate a diagnostics file containing information that would be useful for submitting a bug report.

Or perhaps this should be called make report?

I'm not sure. bug-report might work as well. The question I have there though is: it suggests it will make a bug report which is not what it does; it's to help make a bug report which is not the same thing. So what to call it I do not know. I might be going too literal there (as I often do).

Alternatively it could have aliases (not sure of the make term for this).

lcn2 commented 2 years ago

Collect into the file bug-report.txt, information about the system such as:

uname -a
C compile version
Bison version
Flex version
Tar and if it supports the required options
Bash version

Etc.

xexyl commented 2 years ago

Collect into the file bug-report.txt, information about the system such as:

Is that why you're thinking calling it make bug-report ?

uname -a

C compile version

Bison version

Flex version

Tar and if it supports the required options

Bash version

Etc.

These make sense. How do you propose to check for the required options being supported? I can only think of one way but it's not really a clean way.

xexyl commented 2 years ago

Something just popped into my head though. This is a mistake on the user but it can easily happen if one is tired or is distracted. Let's say they pull and the Makefile is changed but nothing else. But let's say they also want to make install. There's another way this can happen which I explain below and I've done it to myself several times.

They run sudo make install and then they find out the next time something has to be compiled that they won't have permission to do so with output like:

cc -D_DEFAULT_SOURCE -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=600 -std=gnu11 -O0 -g -pedantic -Wall -Wextra -Werror -Wno-unused-command-line-argument -Wno-poison-system-directories -Wno-unreachable-code-break -Wno-padded -lm txzchk.c -c
error: unable to open output file 'txzchk.o': 'Operation not permitted'
1 error generated.
make: *** [txzchk.o] Error 1

If they had used make install a while back they might forget about it or might not realise the implications. To fix this they can do make clobber or rm -f txzchk.o (or whatever) but it might not be immediately obvious.

I don't see this happening very much if at all but I have inadvertently done this to myself several times when I've:

Added new man page.
Updated Makefiles to install the man page.
Forgetting that updating the Makefile will force a recompile of everything I go ahead and do sudo make install to make sure the installation of the man page works okay. This recompiles everything prior to the make install which means the files in the directory are now owned by root.
Next time I compile the code I run into the error.

Is this an issue? Probably not but figured I'd mention it as I have a few minutes and it popped into my head (not sure why - it just did).

Will be leaving in under an hour and when I get home I have some other things I have to take care of as well before I can get back at the laptop.

lcn2 commented 2 years ago

They run sudo make install and then ...
cc -D_DEFAULT_SOURCE -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=600 -std=gnu11 -O0 -g -pedantic -Wall -Wextra -Werror -Wno-unused-command-line-argument -Wno-poison-system-directories -Wno-unreachable-code-break -Wno-padded -lm txzchk.c -c
error: unable to open output file 'txzchk.o': 'Operation not permitted'
1 error generated.
make: *** [txzchk.o] Error 1
Is this an issue? Probably not but figured I'd mention it as I have a few minutes and it popped into my head (not sure why - it just did).

This is not a issue we should address. It someone is using the superuser we presume that they can address any permissions issues that result from that action.

xexyl commented 2 years ago

They run sudo make install and then ...
cc -D_DEFAULT_SOURCE -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=600 -std=gnu11 -O0 -g -pedantic -Wall -Wextra -Werror -Wno-unused-command-line-argument -Wno-poison-system-directories -Wno-unreachable-code-break -Wno-padded -lm txzchk.c -c
error: unable to open output file 'txzchk.o': 'Operation not permitted'
1 error generated.
make: *** [txzchk.o] Error 1
Is this an issue? Probably not but figured I'd mention it as I have a few minutes and it popped into my head (not sure why - it just did).
This is not a issue we should address. It someone is using the superuser we presume that they can address any permissions issues that result from that action.

Oh I agree. I'm not sure it can even be addressed as far as prevention goes. It also is highly unlikely to happen. The only times it has happened to me is testing the make install of man pages but forgetting that to do that forces a recompile of everything first.

But it felt worthy of noting it anyway.

lcn2 commented 2 years ago

Collect into the file bug-report.txt, information about the system such as:

Is that why you're thinking calling it make bug-report ?

uname -a

C compile version

Bison version

Flex version

Tar and if it supports the required options

Bash version

Etc.

These make sense. How do you propose to check for the required options being supported? I can only think of one way but it's not really a clean way.

How abou something liket:

    ...

    # setup for tar test
    # 
    RUN_TAR_TEST="true"
    TEST_FILE=$(mktemp .hostchk.test_file.XXXXXXXXXX)
    status="$?"
    if [[ $status -ne 0 ]]; then
        echo "$0: ERROR: mktemp $TEST_FILE exit code: $status" 1>&2
        EXIT_CODE=14
        RUN_TAR_TEST=
    fi
    date > "$TEST_FILE"
    if [[ $status -ne 0 ]]; then
        echo "$0: ERROR: date > $TEST_FILE exit code: $status" 1>&2
        EXIT_CODE=15
        RUN_TAR_TEST=
    fi
    if [[ ! -r $TEST_FILE ]]; then
        echo "$0: ERROR: not a readable TEST_FILE: $TETS_FILE" 1>&2
        EXIT_CODE=16
        RUN_TAR_TEST=
    fi
    TAR_ERROR =$(mktemp -u .hostchk.tar_err.XXXXXXXXXX.out)
    status="$?"
    if [[ $status -ne 0 ]]; then
        echo "$0: ERROR: mktemp -u $TAR_ERROR exit code: $status" 1>&2
        EXIT_CODE=17
        RUN_TAR_TEST=
    fi
    TARBALL=$(mktemp -u .hostchk.tarball.XXXXXXXXXX.tgz)
    status="$?"
    if [[ $status -ne 0 ]]; then
        echo "$0: ERROR: mktemp -u $TARBALL exit code: $status" 1>&2
        EXIT_CODE=18
        RUN_TAR_TEST=
    fi

    # run tar test
    #
    TAR_TEST_SUCCESS="true"
    if [[ -n $RUN_TAR_TEST ]]; then
        tar --format=v7 -cJf "$TARBALL" "$TEST_FILE" 2>"$TAR_ERROR"
        status="$?"
        if [[ $status -ne 0 ]]; then
            echo "$0: ERROR: tar --format=v7 -cJf $TARBALL $TEST_FILE 2>$TAR_ERROR exit code: $status" 1>&2
            EXIT_CODE=19
            TAR_TEST_SUCCESS=
        fi
        if [[ ! -s $TARBALL ]]; then
            echo "$0: ERROR: did not find a non-empty tarball: $TARBALL" 1>&2
            EXIT_CODE=20
            TAR_TEST_SUCCESS=
        fi
        if [[ -s $TAR_ERROR ]]; then
            echo "$0: notice: tar stderr follows:" 1>&2
            cat "$TAR_ERROR" 1>&2
            echo "$0: notice: end of tar stderr" 1>&2
            EXIT_CODE=21
            TAR_TEST_SUCCESS=
        fi
    else
        echo "$0: notice: tar test disabled due to test setup error(s)" 1>&2
        TAR_TEST_SUCCESS=
    fi

    # tar test cleanup
    #
    if [[ -n $TAR_TEST_SUCCESS ]]; then
        rm -f "$TEST_FILE" "$TAR_ERROR" "$TARBALL"
    fi

    ...

Or something like that, sans typos. :-)

xexyl commented 2 years ago

Collect into the file bug-report.txt, information about the system such as:

Is that why you're thinking calling it make bug-report ?

uname -a

C compile version

Bison version

Flex version

Tar and if it supports the required options

Bash version

Etc.

These make sense. How do you propose to check for the required options being supported? I can only think of one way but it's not really a clean way.

How abou something liket:

    ...

    # setup for tar test
    # 
    RUN_TAR_TEST="true"
    TEST_FILE=$(mktemp .hostchk.test_file.XXXXXXXXXX)
    status="$?"
    if [[ $status -ne 0 ]]; then
        echo "$0: ERROR: mktemp $TEST_FILE exit code: $status" 1>&2
        EXIT_CODE=14
        RUN_TAR_TEST=
    fi
    date > "$TEST_FILE"
    if [[ $status -ne 0 ]]; then
        echo "$0: ERROR: date > $TEST_FILE exit code: $status" 1>&2
        EXIT_CODE=15
        RUN_TAR_TEST=
    fi
    if [[ ! -r $TEST_FILE ]]; then
        echo "$0: ERROR: not a readable TEST_FILE: $TETS_FILE" 1>&2
        EXIT_CODE=16
        RUN_TAR_TEST=
    fi
    TAR_ERROR =$(mktemp -u .hostchk.tar_err.XXXXXXXXXX.out)
    status="$?"
    if [[ $status -ne 0 ]]; then
        echo "$0: ERROR: mktemp -u $TAR_ERROR exit code: $status" 1>&2
        EXIT_CODE=17
        RUN_TAR_TEST=
    fi
    TARBALL=$(mktemp -u .hostchk.tarball.XXXXXXXXXX.tgz)
    status="$?"
    if [[ $status -ne 0 ]]; then
        echo "$0: ERROR: mktemp -u $TARBALL exit code: $status" 1>&2
        EXIT_CODE=18
        RUN_TAR_TEST=
    fi

    # run tar test
    #
    TAR_TEST_SUCCESS="true"
    if [[ -n $RUN_TAR_TEST ]]; then
        tar --format=v7 -cJf "$TARBALL" "$TEST_FILE" 2>"$TAR_ERROR"
        status="$?"
        if [[ $status -ne 0 ]]; then
            echo "$0: ERROR: tar --format=v7 -cJf $TARBALL $TEST_FILE 2>$TAR_ERROR exit code: $status" 1>&2
            EXIT_CODE=19
            TAR_TEST_SUCCESS=
        fi
        if [[ ! -s $TARBALL ]]; then
            echo "$0: ERROR: did not find a non-empty tarball: $TARBALL" 1>&2
            EXIT_CODE=20
            TAR_TEST_SUCCESS=
        fi
        if [[ -s $TAR_ERROR ]]; then
            echo "$0: notice: tar stderr follows:" 1>&2
            cat "$TAR_ERROR" 1>&2
            echo "$0: notice: end of tar stderr" 1>&2
            EXIT_CODE=21
            TAR_TEST_SUCCESS=
        fi
    else
        echo "$0: notice: tar test disabled due to test setup error(s)" 1>&2
        TAR_TEST_SUCCESS=
    fi

    # tar test cleanup
    #
    if [[ -n $TAR_TEST_SUCCESS ]]; then
        rm -f "$TEST_FILE" "$TAR_ERROR" "$TARBALL"
    fi

    ...

Looks like a good start. This would be in hostchk.sh ?

Or something like that, sans typos. :-)

Of course. I do indeed see some and I'd fix them. I ask the file name because if that's the case and I have a little bit of time and energy maybe I'll start out by putting it into that file.

I believe I replied to everything now but if not please let me know. I'm doing something else now. Good day!

lcn2 commented 2 years ago

Looks like a good start. This would be in hostchk.sh ?

Yes, some concept code for you to consider.

lcn2 commented 2 years ago

Perhaps other things hostchk.sh could do is to check for a bison and flex.

Of course, the advice one could give is to accept the reference C code or to download and install the tools.

It would probably be good to try and compile a little C program that contains a few key elements such as:

...

    intmax_t val1 = 21701;
    uintmax_t val2 = 23203;

...

    ret = printf("val1: %jd val2: %ju\n", val1, val2);
    (void) printf("printf returned: %d\n", ret);

...

Something real simple: something that does not require any other code except system include files and libc.

You might want to simply include all of the system include files used in the repo:

#include <ctype.h>
#include <errno.h>
#include <fcntl.h>
#include <float.h>
#include <getopt.h>
#include <inttypes.h>
#include <limits.h>
#include <math.h>
#include <stdarg.h>
#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <strings.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <time.h>
#include <unistd.h>

Something simple like that.

xexyl commented 2 years ago

Looks like a good start. This would be in hostchk.sh ?

Yes, some concept code for you to consider.

Perhaps tomorrow I can at least put that (with typos fixed) in the file if nothing else.

I am not sure what else I might do. I think it depends on how tonight goes. I will be leaving soon for the night.

xexyl commented 2 years ago

Perhaps other things hostchk.sh could do is to check for a bison and flex.

Of course, the advice one could give is to accept the reference C code or to download and install the tools.

It would probably be good to try and compile a little C program that contains a few key elements such as:
...

    intmax_t val1 = 21701;
    uintmax_t val2 = 23203;

...

    ret = printf("val1: %jd val2: %ju\n", val1, val2);
    (void) printf("printf returned: %d\n", ret);

...
Something real simple: something that does not require any other code except system include files and libc.

You might want to simply include all of the system include files used in the repo:
#include <ctype.h>
#include <errno.h>
#include <fcntl.h>
#include <float.h>
#include <getopt.h>
#include <inttypes.h>
#include <limits.h>
#include <math.h>
#include <stdarg.h>
#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <strings.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <time.h>
#include <unistd.h>
Something simple like that.

In other words if compilation fails due to missing header files it could tell the user what is missing. It might be that the compiler would be doing it for us.

I am not sure how many errors would be reported. I know that often it’s limited to 20 but we can in the script have the limit disabled so that no matter how many header files might be added this same script would work in this way.

Probably could come up with a command that extracts all the header files used at the time of execution rather than updating the file each time a header file is added.

I have an idea on how it might be done but I won’t try saying it here when not at the laptop. In theory it should be quite straight forward.

The ideas you have had are good.

Well since last night I lost a lot of sleep I am going to go get ready to sleep.

Hope you have a great night! Sleep well when you do. Look forward to seeing what you come up with and also if you think of anything else here.

Good night!

xexyl commented 2 years ago

Just to be sure: that is what you mean with including all the header files. Right?

Going for the night now.

lcn2 commented 2 years ago

Just to be sure: that is what you mean with including all the header files. Right?

Sure. A simple hello world program with two header files foo.h and stdio.h'. It fails to compile, suggest that the repo code won't compile because they don't havefoo.h`. Do that for each of the head files needed.

UPDATE 0:

Easier still .. see the next comment.

lcn2 commented 2 years ago

    ...

    # setup for compile test
    # 
    RUN_INCLUDE_TEST="true"
    C_FILE=$(mktemp -u .hostchk.src.XXXXXXXXXX.c)
    status="$?"
    if [[ $status -ne 0 ]]; then
        echo "$0: ERROR: mktemp -u $C_FILE exit code: $status" 1>&2
        EXIT_CODE=40
        RUN_INCLUDE_TEST=
    fi
    PROG_FILE=$(mktemp -u .hostchk.prog.XXXXXXXXXX)
    status="$?"
    if [[ $status -ne 0 ]]; then
        echo "$0: ERROR: mktemp -u $PROG_FILE exit code: $status" 1>&2
        EXIT_CODE=41
        RUN_INCLUDE_TEST=
    fi

    # run include tests
    #
    INCLUDE_TEST_SUCCESS="true"
    if [[ -n $RUN_INCLUDE_TEST ]]; then

        # test each required system include file
        #
        for h in ctype.h errno.h fcntl.h .. unistd.h; do

            # form C prog
            #
            rm -f "$C_FILE" "$PROG_FILE"
            echo "#include <$h>" > "$C_FILE";
            echo 'int main(void) { return 0; }' >> "$C_FILE";

            # test compile
            #
            cc "$C_FILE" -o "$PROG_FILE"
            status="$?"
            if [[ $status -ne 0 ]]; then
                echo "$0: FATAL: missing system include file <$h>" 1>&2
                EXIT_CODE=42
                INCLUDE_TEST_SUCCESS=
            fi
            if [[ -s "$PROG_FILE" && -x "$PROG_FILE" ]]; then
                ./"$PROG_FILE"
                status="$?"
                if [[ $status -ne 0 ]]; then
                    echo "$0: FATAL: unable to run executable compiled using include file <$h>" 1>&2
                    EXIT_CODE=43
                    INCLUDE_TEST_SUCCESS=
                fi
            else
                echo "$0: FATAL: unable to form an executable compiled using include file <$h>" 1>&2
                EXIT_CODE=44
                INCLUDE_TEST_SUCCESS=
            fi

            # cleanup after compile test
            # 
            rm -f "$C_FILE" "$PROG_FILE"
        done
    else
        echo "$0: notice: include test disabled due to test setup error(s)" 1>&2
        INCLUDE_TEST_SUCCESS=
    fi

xexyl commented 2 years ago

Good morning! Please see commit https://github.com/ioccc-src/mkiocccentry/pull/251/commits/7cef83f35b6de446616284b898159151e808847f.

I think you'll be pleased to see that I bypassed the need for writing to a file for each header file and I also made it so the script does not have to be updated each time a header file is added or removed.

For the former the magic is something I used in a (losing admittedly) entry before (probably blatant abuse of the Makefile for one reason) which is the -x c option for the compiler and using stdin for the file. Why write many files to a disk each time the script is run when you can do it this way?

And then for the latter it's just a pipeline where the relevant commands are:

    while read -r h; do
...
        printf "%s\n%s\n" "$h" "int main(void){ return 0; }" | cc -x c - -o "$PROG_FILE"
...
    done < <(grep -h -o '#include.*<.*>' ./*.c ./*.h|sort -u)

For now it only tests header files (system header files of course) and if tar will work. No options parsed yet so no debug level or anything else. But it does test the two things so far.

I'm taking a break now and I don't anticipate returning to work more on it today but we shall see. I think I need to take it easy today as the week was really hectic. Good day!

xexyl commented 2 years ago

This is not a issue we should address. It someone is using the superuser we presume that they can address any permissions issues that result from that action.

Oh I agree. I'm not sure it can even be addressed as far as prevention goes. It also is highly unlikely to happen. The only times it has happened to me is testing the make install of man pages but forgetting that to do that forces a recompile of everything first.

But it felt worthy of noting it anyway.

Speaking of people using root when they shouldn't ... here's a funny albeit scary example. The best part? It's someone running an IOCCC entry as root. And it's actually on Wikipedia. Took a screenshot for posterity.

wikipedia-example-of-ioccc-entry-logged-in-as-root

lcn2 commented 2 years ago

OT: Wow

xexyl commented 2 years ago

OT: Wow

Yes it's crazy isn't it? Yet you get that a lot I guess. People don't understand the importance of not being root. They're root just in case they need it. I'm sure there are a lot of other reasons as well but it's dangerous anyway. I think it's incredible that anyone would consider being root to run code that is deliberately hard to understand.

I'd be more curious to see who actually did it. I personally don't like the politics of wikipedia (not that I like any other politics) so even if I had the patience to learn the system I wouldn't even consider editing an article. I'm reminded of the absolutely ridiculous time where they deleted some changes an author made on the page of HIS OWN book because he clearly wouldn't know what it was about - it has to be research from others or however they word it.

xexyl commented 2 years ago

OT: Wow

Yes it's crazy isn't it? Yet you get that a lot I guess. People don't understand the importance of not being root. They're root just in case they need it. I'm sure there are a lot of other reasons as well but it's dangerous anyway. I think it's incredible that anyone would consider being root to run code that is deliberately hard to understand.

I'd be more curious to see who actually did it. I personally don't like the politics of wikipedia (not that I like any other politics) so even if I had the patience to learn the system I wouldn't even consider editing an article. I'm reminded of the absolutely ridiculous time where they deleted some changes an author made on the page of HIS OWN book because he clearly wouldn't know what it was about - it has to be research from others or however they word it.

They also have an article that states they're not reliable. It's amusing to me.

Edit: They also have an article that states Wikipedia is wrong. Well they might not be in every case but they often are. I've noticed things that I know for a fact are wrong. But I guess it's like everything - you have to sometimes take it with a pinch of salt. Anyway I was amazed that they would run that code as root and since it was relevant to a point made I figured I'd share it.

I'll be leaving shortly so I'll bid you a good day!

xexyl commented 2 years ago

I am typing this on the phone so you know.

Now as far as the script goes you suggested it could check flex and bison. What checks did you have in mind with this?

I can think of more than one. It might be the version which could use limit_ioccc.sh and verge but it might also try running the scripts. But is this actually necessary? Either of those?

Whether or no it could be something of a dry run of the scripts?

What about compilers? We already test the header files but what other tests do you think might be good? Standard? If so do you think it could be done similarly to how tar is checked ?

And finally what else do you think should be checked? After all these are added we have to look at how to construct the log file. But perhaps that’s another comment entirely so I will not say any more about that right now.

Otherwise I do need to update txzchk.1 to mention the test suite. Perhaps the other man pages for tools that have test suites should also be updated.

And what about discussing the dbg documentation ? Am I right in saying that it is less important for the time being?

Will be trying to sleep soon. Good night my friend!

lcn2 commented 2 years ago

I am typing this on the phone so you know.

Now as far as the script goes you suggested it could check flex and bison. What checks did you have in mind with this?

Not checks, just gathering information about the environment that might be helpful in debugging.

I can think of more than one. It might be the version which could use limit_ioccc.sh and verge but it might also try running the scripts. But is this actually necessary? Either of those?

You want to have the C compiler print its version. If there is bison, what version it is. If there is `flex, what version it is.

Perhaps make clobber all output to try and collect compiler warnings and errors, etc.

Whether or no it could be something of a dry run of the scripts?

Yes, perhaps the output from make test.

What about compilers? We already test the header files but what other tests do you think might be good? Standard? If so do you think it could be done similarly to how tar is checked ?

Record where tar is located, and as suggested, and what happens when the required flags are used, etc.

And finally what else do you think should be checked? After all these are added we have to look at how to construct the log file. But perhaps that’s another comment entirely so I will not say any more about that right now.

Perhaps the output of uname -a to collect a bit of system information.

xexyl commented 2 years ago

I am typing this on the phone so you know. Now as far as the script goes you suggested it could check flex and bison. What checks did you have in mind with this?

Not checks, just gathering information about the environment that might be helpful in debugging.

I can think of more than one. It might be the version which could use limit_ioccc.sh and verge but it might also try running the scripts. But is this actually necessary? Either of those?

You want to have the C compiler print its version. If there is bison, what version it is. If there is `flex, what version it is.

Perhaps make clobber all output to try and collect compiler warnings and errors, etc.

Whether or no it could be something of a dry run of the scripts?

Yes, perhaps the output from make test.

What about compilers? We already test the header files but what other tests do you think might be good? Standard? If so do you think it could be done similarly to how tar is checked ?

Record where tar is located, and as suggested, and what happens when the required flags are used, etc.

And finally what else do you think should be checked? After all these are added we have to look at how to construct the log file. But perhaps that’s another comment entirely so I will not say any more about that right now.

Perhaps the output of uname -a to collect a bit of system information.

For all of this: it should just be gathered and stored in a log file. Is that right?

What about if the compilations fail (or any other kind of error)? My thinking is it would go to both stderr and the log file. Does that sound reasonable?

lcn2 commented 2 years ago

Again the purpose of this make bug-report rule is to create a bug-report.$(/bin/date '+%%Y%m%d.%H%M%S').txt file (out a timestamp containing information information that might be helpful to understand why someone might be having a problem compiling and running code.

Use the output of $(/bin/date '+%%Y%m%d.%H%M%S') to put a timestamp into the filename.

So things like the following could be written to this file:

make clobber
uname -a
cc -v
which cc
which tar
if tar supports the required flags
make all
./run_bison.sh -v 1
./run_flex.sh -v 1
./hostchk.sh -v 1
make test

Then each of the executables should be tested if they exist and are executable. If so then run them with the -h flag:

./dbg -h
./dyn_test -h
./fnamchk -h
./hostchk.sh -h

Note, this test should have a -h option, a -v level option and use getopts
./ioccc_test.sh -h
./iocccsize -h
./iocccsize_test.sh -h
./jauthchk -h
./jcodechk.sh -h
./jinfochk -h
./jnum_chk -h
./jnum_gen -h
./jparse -h
./jparse_test.sh -h
./json_test.sh -h
./jstr_test.sh -h
./jstrdecode -h
./jstrencode -h
./mkiocccentry -h
./mkiocccentry_test.sh -h
./prep.sh -h
./reset_tstamp.sh -h
./run_bison.sh -h
./run_flex.sh -h
./txzchk -h
./txzchk_test.sh -h
./utf8_test -h
./verge -h
./vermod.sh -h

If the -h for a given code does NOT include a version string, it should. That way we have a better idea of what version their code is.

.. and anything else you might think might be useful to try and understand the user's problematic environment.

xexyl commented 2 years ago

Again the purpose of this make bug-report rule is to create a bug-report.$(/bin/date '+%%Y%m%d.%H%M%S').txt file (out a timestamp containing information information that might be helpful to understand why someone might be having a problem compiling and running code.

Use the output of $(/bin/date '+%%Y%m%d.%H%M%S') to put a timestamp into the filename.

That makes sense yes and it's a good idea name wise.

So things like the following could be written to this file:

make clobber

uname -a

cc -v

which cc

which tar

if tar supports the required flags

This might be where the confusion of the hostchk versus this rule first occurred. That script also checks for this so maybe that's how this confusion happened. I'm not even sure how to go about checking if the required flags are supported. I don't know if the exit code is enough. I mean the hostchk script checks that tar succeeds but is that the same thing? What if it fails for some other reason? Or does that not matter?

make all

./run_bison.sh -v 1

./run_flex.sh -v 1

./hostchk.sh -v 1

How would this relate to the above on tar? And also does it not somewhat overlap?

make test

Then each of the executables should be tested if they exist and are executable. If so then run them with the -h flag:

./dbg -h

./dyn_test -h

./fnamchk -h

./hostchk.sh -h

Note, this test should have a -h option, a -v level option and use getopts

By test you mean script? That's indeed to be added but thank you for the reminder.

./ioccc_test.sh -h

./iocccsize -h

./iocccsize_test.sh -h

./jauthchk -h

./jcodechk.sh -h

./jinfochk -h

./jnum_chk -h

./jnum_gen -h

./jparse -h

./jparse_test.sh -h

./json_test.sh -h

./jstr_test.sh -h

./jstrdecode -h

./jstrencode -h

./mkiocccentry -h

./mkiocccentry_test.sh -h

./prep.sh -h

./reset_tstamp.sh -h

./run_bison.sh -h

./run_flex.sh -h

./txzchk -h

./txzchk_test.sh -h

./utf8_test -h

./verge -h

./vermod.sh -h

If the -h for a given code does NOT include a version string, it should. That way we have a better idea of what version their code is.

Good idea.

.. and anything else you might think might be useful to try and understand the user's problematic environment.

Will give it some thought over time. Not today though. I'm much too worn out. It's not been an easy day and if there's any misunderstanding here that might be part of the problem (and apologies if some of my comments are not entirely clear - same reason likely along with the fact I am wanting to head off for the day soon).

Tomorrow I have a zoom meeting and Tuesday I have a doctor appointment out of town (will be discussing surgery - I'll tell you when that's expected and more about recovery later). But I should be able to do some things each day nonetheless.

lcn2 commented 2 years ago

if tar supports the required flags

This might be where the confusion of the hostchk versus this rule first occurred. That script also checks for this so maybe that's how this confusion happened. I'm not even sure how to go about checking if the required flags are supported. I don't know if the exit code is enough. I mean the hostchk script checks that tar succeeds but is that the same thing? What if it fails for some other reason? Or does that not matter?

We are being generically. If the "if tar supports the required flags" is done by some script, then the make bug-report rule should run that script. The point is to collect a bunch useful info to pack into a bug-report.$(/bin/date '+%%Y%m%d.%H%M%S').txt file for when a user submits a bug report (or we remind / ask the user to upload that file :) ).

So if make hostchk does some useful checking, then perhaps hostchk.sh -v 1 could produce useful output that gets put into the bug report file.

BTW: make hostchk should, if all is well, be silent and exit 0. Perhaps this means that make hostchk executes hostchk.sh -v 0 whereas the bug-report.sh script runs hostchk.sh -v 1. Just an idea.

lcn2 commented 2 years ago

will be discussing surgery - I'll tell you when that's expected and more about recovery later

ouch 🤕‼️

xexyl commented 2 years ago

will be discussing surgery - I'll tell you when that's expected and more about recovery later

ouch 🤕‼️

I appreciate the sentiment. I have had more surgeries than most people could even imagine having in a lifetime. Most of them don’t really bother me. I have been known to have surgery and then after that go and do programming and various other things.

This surgery is the only one I have had that has awful recovery. At least only one for me. I am sure some of them would be horrible for most people.

I don’t exactly recall how productive I was after it but I was in a better place at the time in early 2020. Even so it’s gone on too long once again so I just want to get it over with. It’s really stressing me out and is causing a lot of problems. Once I have fully recovered I should be fine.

I will reply to the other things in the morning. I need to get some sleep. Hope you have a great night my friend!

lcn2 commented 2 years ago

OT

We had open heart surgery to repair a defective heart value in 2016. It was an experience we decided was going to be fun during the process: even designed some experiments to conduct around the procedure, etc. Sure it was a serious event, but our complaining and being miserable wasn't going improve things, so we opted for the fun option and to be highly prepared.

Recovery was something that being very well prepared for helped. For example, pre-surgery, we interviews a number of nurses about what makes a good patient in the hospital. We talked to the hospital discharge people about what they used to determine when a patent was ready to leave the hospital. We talked to the rehab / recovery people about what was needed at home, processes, etc .. all pre-surgery. We talked to the surgeon, the anesthesiologist, surgery nurse ahead of time.

The surgery was delayed for about an hour because we got so busy talking about astronomy, prime numbers, etc. The kockout drugs too longer to take ahold, we guess.

For example: We had an experiment that was done while going under. Instead of counting down from 100, we arranged to factor numbers starting from 100: "100 is 2 times 2 times 5, 99 is 3 times 3 times 11, 98 is 2 times 7 times 7, 97 is prime., ...etc." The numbers were being factored in real time. The idea what they could check if we were really thinking rationally, or just rattling off numbers, because they could check if my products sounded correct. We made it down all the way to -5 before stopping. All the products were accurate. There was no "fuzzy' period of babble or bad products, etc.

There were metal experiments to focus on while waking up from surgery. Etc.

We were able to leave the hospital 50 hours after open heart surgery (we neat the record by 2 all days). And while home recovery took several months, it was less dramatic because we were prepared and willing to make the event a fun adventure. :-)

We cannot promise such results every time. Nevertheless we found preparation and participation and positive attitudes were useful.

lcn2 commented 2 years ago

As for moving forward with the parser I had the thought that after compound forms are parsed before working on jinfochk and jauthchk I will look at the book more and maybe that will help us make it even better. Or would you prefer that after that I go straight for the jinfochk and jauthchk so that the mock contest can go ahead?

Perhaps working on the issue #248 and issue #250? Also if there is anything left to write on issue #232 that might be good too.

Sounds good. But now I'm a bit unsure of something. I had thought that the bug-report rule was the hostchk.sh script. Apparently this is not the case which means that the make rule has to be changed.

I'm not sure how this confusion even happened so I'll take a look at each issue separately and go from there.

As for issue #232 I'm holding off for discussion there. I'm happy to discuss it but I wanted input on the man page and how you might like the markdown file to be updated etc. (I mean to refer to the man page).

The make bug-report is for a user to help is understand what went wrong by providing us with useful information about their environment in for form of a file.

We can mode the GitHub issue text to ask them to attach the file created by make bug-report.

The hostchk.sh script and make hostchk rule it to allow the Makefile to detect if something is seriously wrong or missing from their environment. If there is an issue such as a missing include file, or a C compiler that doesn't work, it can write a warning, plug maybe useful information to stderr for the user to look at.

Certainly the make bug-report, via the bug-report.sh, should also run this hostchk.sh script.

xexyl commented 2 years ago

I will reply to this and worry about the other things later or tomorrow.

OT

We had open heart surgery to repair a defective heart value in 2016. It was an experience we decided was going to be fun during the process: even designed some experiments to conduct around the procedure, etc. Sure it was a serious event, but our complaining and being miserable wasn't going improve things, so we opted for the fun option and to be highly prepared.

Crikey! That is serious. I'm glad you're okay though. At least I think all damage was resolved? The heart is so important. And the way you went about it is wise and not something many people can do. I have a story about the most invasive surgeries I've had below but first I'll reply to your comments.

Recovery was something that being very well prepared for helped. For example, pre-surgery, we interviews a number of nurses about what makes a good patient in the hospital. We talked to the hospital discharge people about what they used to determine when a patent was ready to leave the hospital. We talked to the rehab / recovery people about what was needed at home, processes, etc .. all pre-surgery. We talked to the surgeon, the anesthesiologist, surgery nurse ahead of time.

It's funny but actually a lot of people don't understand that. My mum had a major fall in 2020 (3 May) and shattered her knee and wrist. Thank goodness I live with her as I could take care of calling an ambulance and taking care of things when she was gone. We help each other out a lot.

She didn't even have morphine right away. They offered it but she wanted to know what it was first though I think she knew. I have seen her do some incredible things so hearing her and seeing her on the floor unable to get up was horrible! But I've always been calm in emergencies and I took care of the problem. Had to hang up on the call I was on at the time but that was okay.

But when she was going through physical therapy they actually asked her what she wanted to accomplish. Turns out some people just want it as easy as possible even if that means they don't have the same mobility as before. I found this incredible. Normally for the injuries she sustained she would have had to use a cane but she bypassed that entirely as she was doing so well - her exercises and everything like a good patient.

But many people want it as easy as possible even with serious medical things when they're not always easy. This surgery I will have to have is not an easy one but it's better to get it out of the way. It was never off the table when I went in. There were some times where it appeared I might not need it but I was always afraid I would need it. Unfortunately I will and so it's a matter of discussing it with him (he already wondered it as well but we tried one last time to take care of the problem) and then scheduling a surgery date.

The surgery was delayed for about an hour because we got so busy talking about astronomy, prime numbers, etc. The kockout drugs too longer to take ahold, we guess.

That's very cool! I've been wide awake (as I've told you before) on diazepam and sound asleep with caffeine in me. But anaesthesia doesn't usually have that problem. Even so I tell them always I have high tolerance and so they adjust it for that reason. When it's a surgery or procedure that doesn't require being put to sleep I ask for twilight. Or in the case (as you'll see below) I refer to I stayed awake and was making jokes with the surgeon and really having a lot of fun!

For example: We had an experiment that was done while going under. Instead of counting down from 100, we arranged to factor numbers starting from 100: "100 is 2 times 2 times 5, 99 is 3 times 3 times 11, 98 is 2 times 7 times 7, 97 is prime., ...etc." The numbers were being factored in real time. The idea what they could check if we were really thinking rationally, or just rattling off numbers, because they could check if my products sounded correct. We made it down all the way to -5 before stopping. All the products were accurate. There was no "fuzzy' period of babble or bad products, etc.

Doesn't surprise me in the slightest!

There were metal experiments to focus on while waking up from surgery. Etc.

Please elaborate?

We were able to leave the hospital 50 hours after open heart surgery (we neat the record by 2 all days). And while home recovery took several months, it was less dramatic because we were prepared and willing to make the event a fun adventure. :-)

You broke the record of fastest recovery in that hospital you mean?

We cannot promise such results every time. Nevertheless we found preparation and participation and positive attitudes were useful.

Very true.

As for the story. In 2002 and also 2003 I had brain surgery. Well I have never liked anaesthesia so the second time I decided to stay wide awake. It was fascinating. But this time I was also part of a study. With wires attached to my head they were studying how I was thinking and [whatever else]. They created what I thought of as a game from my childhood (very similar to Atari 2600 games - or some of them):

Five arrows would be on the screen and the object of the game was to move the joystick in the direction of the middle arrow. I did perfect. They were astounded! They couldn't do it and they designed it! But then at one point when the nurse walked into the operating theatre the surgeon had just asked me how I was doing and I replied 'pretty good for a guy with two holes in his head'. Well that does sound like me!

Then the surgeon made a mistake in speech when going to my mum (who was worried as they kept me in hours longer than normal because they were making use of such a good case). His first words to my mum were 'I'm sorry'. She started to fall apart (though as a child someone once told her that he thought I was dead and she was calm .. didn't believe it and had him take her to me, see below). Anyway the surgeon then said 'no no no .. I didn't mean that! I mean I'm sorry we kept him so long but he was so incredible!'

For my part they gave me a significant amount of money for participating in their study. But because I was able to give them so much more they gave me more than they had agreed on (though I would have done it even without any money involved).

What had happened is I was riding my bike in property we shouldn't have been in (it was fenced off but we threw the bikes over and scaled the fence). Just a lot of land with hills and other things that made a fun obstacle thing. But I always enjoyed deliberately crashing on my bike (never would do that now though) so I deliberately went straight down a steep rocky hill rather than follow the path. I went over the handlebars and got a huge bruise on my side. Was fun though.

I also prefer needles in the hand or wrist when they draw blood or need an IV. I've had to argue with nurses about this. One was particularly irritating me so I said that I also stayed wide awake during brain surgery. The look on her face was wonderful so naturally I made it even more 'wonderful': I told her 'well it's not like I'm normal ...' She didn't appreciate that but I didn't appreciate them trying to tell me where the needle goes. It doesn't hurt me there. If it was IM or subcutaneous or some other kind where it has to be in certain spots that's one thing but a needle for blood work can go in the hand or wrist and I prefer it there over the arm.

Anyway I'm glad you're okay. I'll reply to the other comments another time. Too tired to think about those things now. Good day!

xexyl commented 2 years ago

I have a little bit of time and some energy to write more comments that might help move forward a bit.

As for moving forward with the parser I had the thought that after compound forms are parsed before working on jinfochk and jauthchk I will look at the book more and maybe that will help us make it even better. Or would you prefer that after that I go straight for the jinfochk and jauthchk so that the mock contest can go ahead?

Perhaps working on the issue #248 and issue #250? Also if there is anything left to write on issue #232 that might be good too.

Sounds good. But now I'm a bit unsure of something. I had thought that the bug-report rule was the hostchk.sh script. Apparently this is not the case which means that the make rule has to be changed. I'm not sure how this confusion even happened so I'll take a look at each issue separately and go from there. As for issue #232 I'm holding off for discussion there. I'm happy to discuss it but I wanted input on the man page and how you might like the markdown file to be updated etc. (I mean to refer to the man page).

The make bug-report is for a user to help is understand what went wrong by providing us with useful information about their environment in for form of a file.

We can mode the GitHub issue text to ask them to attach the file created by make bug-report.

The hostchk.sh script and make hostchk rule it to allow the Makefile to detect if something is seriously wrong or missing from their environment. If there is an issue such as a missing include file, or a C compiler that doesn't work, it can write a warning, plug maybe useful information to stderr for the user to look at.

Certainly the make bug-report, via the bug-report.sh, should also run this hostchk.sh script.

So now we have a name of the script: bug-report.sh. It will call hostchk.sh. But make bug-report itself calls hostchk.sh. Should it only call bug-report.sh which will call hostchk.sh?

Also the current hostchk.sh has some of the code you referred to above e.g. detecting if tar works. It also has the checks for each system header file the repo uses (automatically generated on each run).

If bug-report.sh calls hostchk.sh what should be in hostchk.sh and what should be in bug-report.sh ? From some of the comments I sense an overlap so I'm not sure what should go where. Maybe a list of what tests should be where so that it could be written without having to guess?

lcn2 commented 2 years ago

I have a little bit of time and some energy to write more comments that might help move forward a bit.

As for moving forward with the parser I had the thought that after compound forms are parsed before working on jinfochk and jauthchk I will look at the book more and maybe that will help us make it even better. Or would you prefer that after that I go straight for the jinfochk and jauthchk so that the mock contest can go ahead?

Perhaps working on the issue #248 and issue #250? Also if there is anything left to write on issue #232 that might be good too.

Sounds good. But now I'm a bit unsure of something. I had thought that the bug-report rule was the hostchk.sh script. Apparently this is not the case which means that the make rule has to be changed. I'm not sure how this confusion even happened so I'll take a look at each issue separately and go from there. As for issue #232 I'm holding off for discussion there. I'm happy to discuss it but I wanted input on the man page and how you might like the markdown file to be updated etc. (I mean to refer to the man page).

The make bug-report is for a user to help is understand what went wrong by providing us with useful information about their environment in for form of a file. We can mode the GitHub issue text to ask them to attach the file created by make bug-report. The hostchk.sh script and make hostchk rule it to allow the Makefile to detect if something is seriously wrong or missing from their environment. If there is an issue such as a missing include file, or a C compiler that doesn't work, it can write a warning, plug maybe useful information to stderr for the user to look at. Certainly the make bug-report, via the bug-report.sh, should also run this hostchk.sh script.

So now we have a name of the script: bug-report.sh. It will call hostchk.sh. But make bug-report itself calls hostchk.sh. Should it only call bug-report.sh which will call hostchk.sh?

Also the current hostchk.sh has some of the code you referred to above e.g. detecting if tar works. It also has the checks for each system header file the repo uses (automatically generated on each run).

If bug-report.sh calls hostchk.sh what should be in hostchk.sh and what should be in bug-report.sh ? From some of the comments I sense an overlap so I'm not sure what should go where. Maybe a list of what tests should be where so that it could be written without having to guess?

For bug-report.sh: the main purpose is for when a user (not a developer) of the repo encounters a problem and wants to raise an issue, the can provide as a attachment information that might be useful about their build environment.

For hostchk.sh: the main purpose is an automatic make rule that is involved early to perform a few sanity checks on the build environment.

For bug-report.sh: try and avoid "your code does not work" and we ask "how does it not work?" and they say "it does not compile" and we ask "what is wrong" and they say "I get compiler errors" and we ask ... Hopefully by including the bug-report.timestamp.txt file, we can get a better idea of what is happening. So think about what you would want to know about someone's build environment and what might be going wrong. Have bug-report.sh write that sort of stuff into a bug-report.timestamp.txt file.

For hostchk.sh: It should be fast. If all is well, it should print NOTHING and exit 0. However, not it finds something wrong, it should issue an Warning message and perhaps a useful hint of what is wrong, such as "cannot find system include file ", or "grep command missing", etc.

The hostchk.sh should use a -v level' such that-v 0(the default) prints nothing and-v 1` starts to announce each check as they are being performed.

There is a tricky issue about how hostchk.sh should be used in the Makefile. We don't want the early running of hostchk.sh to stop the make by default. The purpose of hostchk.sh is to warn the user about a problem, NOT to prevent it. So when we have the make rule, we should not allow a non-zero exit to halt the make. So perhaps a rule like this is needed:

...
hostchk: hostchk.sh Makefile
        @-./hostchk.sh -v 0; status="$$?"; if [[ $$status -ne 0 ]]; then \
            echo "Warning: you may not be able to compile this code, see above for details." 1>&2; \
        fi
...

So if all is well, nothing is printed. If hostchk.sh finds problems, it issues warnings on stderr an exits non-zero. The Makefile, on the other hand, does NOT abort when hostchk.sh exits non-0, but rather issues a final warning before the make proceeds.

UPDATE 0:

The hostchk.sh should not call bug-report.sh. However given the purpose of bug-report.sh, having that script call hostchk.sh -v 1 and record the output might be a good thing to do.

xexyl commented 2 years ago

I have a little bit of time and some energy to write more comments that might help move forward a bit.

As for moving forward with the parser I had the thought that after compound forms are parsed before working on jinfochk and jauthchk I will look at the book more and maybe that will help us make it even better. Or would you prefer that after that I go straight for the jinfochk and jauthchk so that the mock contest can go ahead?

Perhaps working on the issue #248 and issue #250? Also if there is anything left to write on issue #232 that might be good too.

Sounds good. But now I'm a bit unsure of something. I had thought that the bug-report rule was the hostchk.sh script. Apparently this is not the case which means that the make rule has to be changed. I'm not sure how this confusion even happened so I'll take a look at each issue separately and go from there. As for issue #232 I'm holding off for discussion there. I'm happy to discuss it but I wanted input on the man page and how you might like the markdown file to be updated etc. (I mean to refer to the man page).

The make bug-report is for a user to help is understand what went wrong by providing us with useful information about their environment in for form of a file. We can mode the GitHub issue text to ask them to attach the file created by make bug-report. The hostchk.sh script and make hostchk rule it to allow the Makefile to detect if something is seriously wrong or missing from their environment. If there is an issue such as a missing include file, or a C compiler that doesn't work, it can write a warning, plug maybe useful information to stderr for the user to look at. Certainly the make bug-report, via the bug-report.sh, should also run this hostchk.sh script.

So now we have a name of the script: bug-report.sh. It will call hostchk.sh. But make bug-report itself calls hostchk.sh. Should it only call bug-report.sh which will call hostchk.sh? Also the current hostchk.sh has some of the code you referred to above e.g. detecting if tar works. It also has the checks for each system header file the repo uses (automatically generated on each run). If bug-report.sh calls hostchk.sh what should be in hostchk.sh and what should be in bug-report.sh ? From some of the comments I sense an overlap so I'm not sure what should go where. Maybe a list of what tests should be where so that it could be written without having to guess?

For bug-report.sh: the main purpose is for when a user (not a developer) of the repo encounters a problem and wants to raise an issue, the can provide as a attachment information that might be useful about their build environment.

[...]

Thank you. This is a lot to think about and I'm afraid it's not something I feel up to today. I shall return to this soon I hope. To help though: I guess these two scripts have higher priority than updating the txzchk_test.sh script. Is that correct?

When I get back to this I probably will have some questions or want some clarifications (and maybe confirmations) but I'll worry about that at the time.

Today I did a pull request but I doubt I'll do more today than what I did some hours ago.

lcn2 commented 2 years ago

I guess these two scripts have higher priority than updating the txzchk_test.sh script. Is that correct?

Possibly yes. 🙂

The txzchk_test.sh script is a way to be sure txzchk is working correctly (we are fairly sure that this code is in good shape: still it doesn't hurt to check) AND that is isn't broken by some further change (we don't see how such a change could do this: still it doesn't hurt to check).

So one could argue that txzchk_test.sh improvement is not the topmost priority.

The two tools needed to help a user report a repo build problem, and to warn a user about something missing in their building environment, are needed when it comes time to release the repo code to the wider general public.

So it could be argued that these two tools are not a upmost time critical path priority.

Because is not clear as to which has the higher priority, use your judgment as to which you work on first/next.

BTW: It's clear that our focusing on the backend support needed to parse complex JSON items is the critical path last top priority. And for that we're working on it and making good progress.

UPDATE 0:

Fixed a few typos in the text of this comment.

xexyl commented 2 years ago

I guess these two scripts have higher priority than updating the txzchk_test.sh script. Is that correct?

Possibly yes. 🙂

The txzchk_test.sh script is a way to be sure txzchk is working correctly (we are fairly sure that this code is in good shape: still it doesn't hurt to check) AND that is isn't broken by some further change (we don't see how such a change could do this: still it doesn't hurt to check).

I couldn't agree more with that - all parts.

So one could argue that txzchk_test.sh improvement is not the topmost priority.

Makes sense.

The two tools needed to help a user report a repo build problem, and to warn a user about something missing in their building environment, are needed when it comes time to release the repo code to the wider general public.

So it could be argued that these two tools are not a upmost time critical path priority.

Because is not clear as to which has the higher priority, use your judgment as to which you work on first/next.

My guess is these two are probably more important at least for wider public use. However what I'll work on at any given time probably depends on what I feel up to working on especially since there doesn't seem to be a different clear path.

BTW: It's clear that our focusing on the backend support needed to parse complex JSON items is the critical path last top priority. And for that we're working on it and making good progress.

That's great to hear! I look forward to that being completed. Of course once that is completed I guess more important than the scripts would be to work on the json file checkers.

xexyl commented 2 years ago

Perhaps other things hostchk.sh could do is to check for a bison and flex.

Of course, the advice one could give is to accept the reference C code or to download and install the tools.

It would probably be good to try and compile a little C program that contains a few key elements such as:
...

    intmax_t val1 = 21701;
    uintmax_t val2 = 23203;

...

    ret = printf("val1: %jd val2: %ju\n", val1, val2);
    (void) printf("printf returned: %d\n", ret);

...
Something real simple: something that does not require any other code except system include files and libc.

You might want to simply include all of the system include files used in the repo:

.. this I did but what about the above? Do we need a test that uses different types or are the header file inclusion tests enough ? If they're not enough what should be checked ?

xexyl commented 2 years ago

BTW: It's clear that our focusing on the backend support needed to parse complex JSON items is the critical path last top priority. And for that we're working on it and making good progress.

How is that going anyway ? I brought the repo up to someone else the other day and I referred to how there are things I can do but there are these things that I cannot do. Still making good progress here? Or is this not related to the server maybe ?

xexyl commented 2 years ago

The make bug-report is for a user to help is understand what went wrong by providing us with useful information about their environment in for form of a file.

We can mode the GitHub issue text to ask them to attach the file created by make bug-report.

The hostchk.sh script and make hostchk rule it to allow the Makefile to detect if something is seriously wrong or missing from their environment. If there is an issue such as a missing include file, or a C compiler that doesn't work, it can write a warning, plug maybe useful information to stderr for the user to look at.

Certainly the make bug-report, via the bug-report.sh, should also run this hostchk.sh script.

See it's this I'm unclear on because right now make bug-report will run hostchk.sh. There seems to be an overlap of uses here. If hostchk.sh should not call bug-report.sh but bug-report.sh should call hostchk.sh what should hostchk rule do? Right now it's:

hostchk bug-report:
        @-./hostchk.sh -v 0; status="$$?"; if [[ $$status -ne 0 ]]; then \
            echo "Warning: you might not be able to compile this code, see above for details." 1>&2; \
        fi

but it seems that:

the bug-report part will have to be removed and changed to its own rule which will call bug-report.sh
this bug-report.sh will instead call hostchk.sh with -v 1 and presumably attach the results to the log file (I guess bug-report.log is what it was ?)?

The hostchk.sh currently:

checks for tar
checks for cc
checks that both cc and tar are regular executable files
tries to make a tarball with the correct options (like -J)
automagically compile a set of C files with each include file used in the repo - determined at runtime of the script

I had the idea to do it this way and use the -x c - option to the compiler which I've used before in rare cases (take a guess where).

That's all it does now but should it do anything else? I'll get to the other thread and maybe find out but I'm still not clear on the overlap.

xexyl commented 2 years ago

I have a little bit of time and some energy to write more comments that might help move forward a bit.

As for moving forward with the parser I had the thought that after compound forms are parsed before working on jinfochk and jauthchk I will look at the book more and maybe that will help us make it even better. Or would you prefer that after that I go straight for the jinfochk and jauthchk so that the mock contest can go ahead?

Perhaps working on the issue #248 and issue #250? Also if there is anything left to write on issue #232 that might be good too.

Sounds good. But now I'm a bit unsure of something. I had thought that the bug-report rule was the hostchk.sh script. Apparently this is not the case which means that the make rule has to be changed. I'm not sure how this confusion even happened so I'll take a look at each issue separately and go from there. As for issue #232 I'm holding off for discussion there. I'm happy to discuss it but I wanted input on the man page and how you might like the markdown file to be updated etc. (I mean to refer to the man page).

The make bug-report is for a user to help is understand what went wrong by providing us with useful information about their environment in for form of a file. We can mode the GitHub issue text to ask them to attach the file created by make bug-report. The hostchk.sh script and make hostchk rule it to allow the Makefile to detect if something is seriously wrong or missing from their environment. If there is an issue such as a missing include file, or a C compiler that doesn't work, it can write a warning, plug maybe useful information to stderr for the user to look at. Certainly the make bug-report, via the bug-report.sh, should also run this hostchk.sh script.

So now we have a name of the script: bug-report.sh. It will call hostchk.sh. But make bug-report itself calls hostchk.sh. Should it only call bug-report.sh which will call hostchk.sh? Also the current hostchk.sh has some of the code you referred to above e.g. detecting if tar works. It also has the checks for each system header file the repo uses (automatically generated on each run). If bug-report.sh calls hostchk.sh what should be in hostchk.sh and what should be in bug-report.sh ? From some of the comments I sense an overlap so I'm not sure what should go where. Maybe a list of what tests should be where so that it could be written without having to guess?

For bug-report.sh: the main purpose is for when a user (not a developer) of the repo encounters a problem and wants to raise an issue, the can provide as a attachment information that might be useful about their build environment.

That makes sense.

For hostchk.sh: the main purpose is an automatic make rule that is involved early to perform a few sanity checks on the build environment.

That is involved early ... where though? In what rule? Or do I misunderstand 'involved early' ?

For bug-report.sh: try and avoid "your code does not work" and we ask "how does it not work?" and they say "it does not compile" and we ask "what is wrong" and they say "I get compiler errors" and we ask ... Hopefully by including the bug-report.timestamp.txt file, we can get a better idea of what is happening. So think about what you would want to know about someone's build environment and what might be going wrong. Have bug-report.sh write that sort of stuff into a bug-report.timestamp.txt file.

That makes sense yes. It'll require some thought on what kinds of information is needed though. I think you already gave some examples in another comment like versions of different tools we need.

For hostchk.sh: It should be fast. If all is well, it should print NOTHING and exit 0. However, not it finds something wrong, it should issue an Warning message and perhaps a useful hint of what is wrong, such as "cannot find system include file ", or "grep command missing", etc.

So..does it need to check for grep then? Because recently when I added a check in the Makefile for grep you weren't even sure if this was necessary (though you added that of course it wouldn't hurt). Or is this just an example command you thought of perhaps because the script makes use of it?

The hostchk.sh should use a -v level' such that-v 0(the default) prints nothing and-v 1` starts to announce each check as they are being performed.

The -v 0 certainly prints nothing but I'm not sure on higher levels. I'll have to check.

There is a tricky issue about how hostchk.sh should be used in the Makefile. We don't want the early running of hostchk.sh to stop the make by default. The purpose of hostchk.sh is to warn the user about a problem, NOT to prevent it. So when we have the make rule, we should not allow a non-zero exit to halt the make. So perhaps a rule like this is needed:

Stop the make by default .. which make? Or which target/rule do you refer to ?

...
hostchk: hostchk.sh Makefile
        @-./hostchk.sh -v 0; status="$$?"; if [[ $$status -ne 0 ]]; then \
            echo "Warning: you may not be able to compile this code, see above for details." 1>&2; \
        fi
...

That's now in the Makefile though I'm not sure if that has been merged yet.

So if all is well, nothing is printed. If hostchk.sh finds problems, it issues warnings on stderr an exits non-zero. The Makefile, on the other hand, does NOT abort when hostchk.sh exits non-0, but rather issues a final warning before the make proceeds.

Ah so above maybe you just mean that hostchk.sh can fail but it's okay: continue anyway. But the thing is if the primary use is bug-report how to integrate this idea? Make the call to hostchk.sh in bug-report.sh not exit with an error?

UPDATE 0:

The hostchk.sh should not call bug-report.sh. However given the purpose of bug-report.sh, having that script call hostchk.sh -v 1 and record the output might be a good thing to do.

xexyl commented 2 years ago

if tar supports the required flags

This might be where the confusion of the hostchk versus this rule first occurred. That script also checks for this so maybe that's how this confusion happened. I'm not even sure how to go about checking if the required flags are supported. I don't know if the exit code is enough. I mean the hostchk script checks that tar succeeds but is that the same thing? What if it fails for some other reason? Or does that not matter?

We are being generically. If the "if tar supports the required flags" is done by some script, then the make bug-report rule should run that script. The point is to collect a bunch useful info to pack into a bug-report.$(/bin/date '+%%Y%m%d.%H%M%S').txt file for when a user submits a bug report (or we remind / ask the user to upload that file :) ).

That sounds like a good idea yes.

So if make hostchk does some useful checking, then perhaps hostchk.sh -v 1 could produce useful output that gets put into the bug report file.

The question is should bug-report.sh only use -v1 or should it first try -v 0? I don't know.

BTW: make hostchk should, if all is well, be silent and exit 0. Perhaps this means that make hostchk executes hostchk.sh -v 0 whereas the bug-report.sh script runs hostchk.sh -v 1. Just an idea.

Okay well this might answer the above then. So what do you think of this?

Once the bug-report.sh exists I can remove 'bug-report' from the hostchk rule. Then bug-report.sh will call hostchk.sh -v 1 and the output will be piped (tee -a?) to the log file as well. Now two questions come to mind immediately.

First is that if hostchk.sh actually has no problems wouldn't the -v 1 be just extra clutter to go through?

The second is .. it already slipped my mind! :-) (I don't think it was important and I think more so I am not sure of what it was because it wasn't a complete thought yet and I focused on the one that already was.) Possibly it's this:

If the purpose of the script hostchk.sh is to be silent if all is well why do we need -v 1 in bug-report.sh? More to the point: would it be a good idea to first determine if it fails and if so then run it with some verbosity?

It might also have been: what should be printed at verbosity level 1? What tests, what output etc.? I think that's most likely what the second question was but the other one is relevant too I think (though it might be said to be part of the first one).

xexyl commented 2 years ago

Again the purpose of this make bug-report rule is to create a bug-report.$(/bin/date '+%%Y%m%d.%H%M%S').txt file (out a timestamp containing information information that might be helpful to understand why someone might be having a problem compiling and running code.

Use the output of $(/bin/date '+%%Y%m%d.%H%M%S') to put a timestamp into the filename.

So things like the following could be written to this file:

The list below is all for bug-report.sh, right? But what about the checks that are also in hostchk.sh e.g. tar command working ? Does this mean the tar test need not be in bug-report.sh since bug-report.sh will call the script itself ?

make clobber

uname -a

cc -v

which cc

which tar

if tar supports the required flags

make all

./run_bison.sh -v 1

./run_flex.sh -v 1

./hostchk.sh -v 1

make test

Then each of the executables should be tested if they exist and are executable. If so then run them with the -h flag:

./dbg -h

./dyn_test -h

./fnamchk -h

./hostchk.sh -h

Note, this test should have a -h option, a -v level option and use getopts

Was done a while back - just to confirm.

./ioccc_test.sh -h

./iocccsize -h

./iocccsize_test.sh -h

./jauthchk -h

./jcodechk.sh -h

./jinfochk -h

./jnum_chk -h

./jnum_gen -h

./jparse -h

./jparse_test.sh -h

./json_test.sh -h

./jstr_test.sh -h

./jstrdecode -h

./jstrencode -h

./mkiocccentry -h

./mkiocccentry_test.sh -h

./prep.sh -h

./reset_tstamp.sh -h

./run_bison.sh -h

./run_flex.sh -h

./txzchk -h

./txzchk_test.sh -h

./utf8_test -h

./verge -h

./vermod.sh -h

If the -h for a given code does NOT include a version string, it should. That way we have a better idea of what version their code is.

So all these should be concatenated to the bug report file? Why not in hostchk ? Or another way of putting it: should any of these be in hostchk.sh instead (which would end up being in the bug report file because of this) ?

.. and anything else you might think might be useful to try and understand the user's problematic environment.

It's a great list so far. Nothing comes to my mind atm except this: right now that list might be good. Or it was when it was written. The lists above are missing for example the output of chkentry and instead have the old tools. So do you have an idea on how to come up with (at runtime) a list of all tools necessary? Perhaps the Makefile variables:

TARGETS
SH_FILES

If so then all these commands should be concatenated to a bug report file as well as (I think?) stdout / stderr? I'll look at the hostchk thread now and then will be doing something else - though might have to take a break before I get to that other thread. Hopefully these comments will help move these things along.

lcn2 commented 2 years ago

BTW: It's clear that our focusing on the backend support needed to parse complex JSON items is the critical path last top priority. And for that we're working on it and making good progress.

How is that going anyway ? I brought the repo up to someone else the other day and I referred to how there are things I can do but there are these things that I cannot do. Still making good progress here? Or is this not related to the server maybe ?

I think we are approaching being code complete on the JSON parser in terms of what IOCCCMOCK will need.

The semantic test code needs to be finished. We would be doing that not, expect that reducing the backlog of important questions in GitHub is a higher priority. :-)

And perhaps the error messages from JSON might be a bit more informative .. but perhaps the a bit more informative should be considered as a much lower priority to being code complete on the JSON parser. Once the semantic test code is written, then we plan to stress test the semantic code AS WELL AS the JSON parser itself by throwing at it a bunch of test cases that will include both invalid JSON and that will include valid JSON that is not what the IOCCC contest wants (semantic errors for otherwise valid JSON).

If, during the stress test the code complete JSON parser (the includes the semantic test code), we are confused by the JSON error messages, then that might a sign that such error messages needs to be improved.

We would keep in mind that as long as mkiocccentry does its job well, the .info.json and .author.json files will be both valid JSON syntax AND will be semantically valid. The cases for BOGUS JSON are probably limited to rare things like filesystem failures, truncated file uploads.

If someone is playing around with the contents of the .info.json and .author.json files, and the JSON parser prints a confusing error message, well that is what they deserve for playing games.

So in all likelihood, improving the JSON parser error messages might be reserved for when the JSON parser becomes its own repo.

xexyl commented 2 years ago

BTW: It's clear that our focusing on the backend support needed to parse complex JSON items is the critical path last top priority. And for that we're working on it and making good progress.

How is that going anyway ? I brought the repo up to someone else the other day and I referred to how there are things I can do but there are these things that I cannot do. Still making good progress here? Or is this not related to the server maybe ?

I think we are approaching being code complete on the JSON parser in terms of what IOCCCMOCK will need.

The semantic test code needs to be finished. We would be doing that not, expect that reducing the backlog of important questions in GitHub is a higher priority. :-)

And perhaps the error messages from JSON might be a bit more informative .. but perhaps the a bit more informative should be considered as a much lower priority to being code complete on the JSON parser. Once the semantic test code is written, then we plan to stress test the semantic code AS WELL AS the JSON parser itself by throwing at it a bunch of test cases that will include both invalid JSON and that will include valid JSON that is not what the IOCCC contest wants (semantic errors for otherwise valid JSON).

If, during the stress test the code complete JSON parser (the includes the semantic test code), we are confused by the JSON error messages, then that might a sign that such error messages needs to be improved.

We would keep in mind that as long as mkiocccentry does its job well, the .info.json and .author.json files will be both valid JSON syntax AND will be semantically valid. The cases for BOGUS JSON are probably limited to rare things like filesystem failures, truncated file uploads.

If someone is playing around with the contents of the .info.json and .author.json files, and the JSON parser prints a confusing error message, well that is what they deserve for playing games.

So in all likelihood, improving the JSON parser error messages might be reserved for when the JSON parser becomes its own repo.

This is great. I will reply in full when I have both my laptop up and my brain up which unfortunately neither conditions are true right now. Well my brain is but I think it is better that I get ready to sleep.

Your reply is good is definitely good and actually more than I had even considered so I look forward to addressing it soon.

Good night my friend! Sleep well.

lcn2 commented 2 years ago

The make bug-report is for a user to help is understand what went wrong by providing us with useful information about their environment in for form of a file. We can mode the GitHub issue text to ask them to attach the file created by make bug-report. The hostchk.sh script and make hostchk rule it to allow the Makefile to detect if something is seriously wrong or missing from their environment. If there is an issue such as a missing include file, or a C compiler that doesn't work, it can write a warning, plug maybe useful information to stderr for the user to look at. Certainly the make bug-report, via the bug-report.sh, should also run this hostchk.sh script.

See it's this I'm unclear on because right now make bug-report will run hostchk.sh. There seems to be an overlap of uses here. If hostchk.sh should not call bug-report.sh but bug-report.sh should call hostchk.sh what should hostchk rule do? Right now it's:
hostchk bug-report:
        @-./hostchk.sh -v 0; status="$$?"; if [[ $$status -ne 0 ]]; then \
            echo "Warning: you might not be able to compile this code, see above for details." 1>&2; \
        fi
but it seems that:

the bug-report part will have to be removed and changed to its own rule which will call bug-report.sh

this bug-report.sh will instead call hostchk.sh with -v 1 and presumably attach the results to the log file (I guess bug-report.log is what it was ?)?

The hostchk.sh currently:

checks for tar

checks for cc

checks that both cc and tar are regular executable files

tries to make a tarball with the correct options (like -J)

automagically compile a set of C files with each include file used in the repo - determined at runtime of the script

I had the idea to do it this way and use the -x c - option to the compiler which I've used before in rare cases (take a guess where).

That's all it does now but should it do anything else? I'll get to the other thread and maybe find out but I'm still not clear on the overlap.

You may be overthinking this.

The bug-report, when generating a bug report, should probably run hostchk.sh with some verbosity level because the hostchk.sh tool might print, for including in the bug report, some useful stuff about the environment.

Consider the case where somebody is filing a bug report because the repo fails to compile. We need some information as to WHY the repo failed to compile. If the hostchk.sh tool observes that <sys/time.h> is missing, that might be a useful clue to include in the bug report.

So as part of bug-report generating a bug report, the verbose output of the hostchk.sh tool might be a useful thing to include.

lcn2 commented 2 years ago

Once the bug-report.sh exists I can remove 'bug-report' from the hostchk rule. Then bug-report.sh will call hostchk.sh -v 1 and the output will be piped (tee -a?) to the log file as well. Now two questions come to mind immediately.

The bug-report.sh should have somewhere in the script, an execution of the hostchk.sh script, with a suitable level of verbosity, and include the output of that script in the bug report file.

So as part of bug-report generating a bug report, the verbose output of the hostchk.sh tool might be a useful thing to include.

lcn2 commented 2 years ago

We lost about 45 minutes trying to type in detailed answers to all the above :( only to have GitHub toss our comment. :-(

xexyl commented 2 years ago

The make bug-report is for a user to help is understand what went wrong by providing us with useful information about their environment in for form of a file. We can mode the GitHub issue text to ask them to attach the file created by make bug-report. The hostchk.sh script and make hostchk rule it to allow the Makefile to detect if something is seriously wrong or missing from their environment. If there is an issue such as a missing include file, or a C compiler that doesn't work, it can write a warning, plug maybe useful information to stderr for the user to look at. Certainly the make bug-report, via the bug-report.sh, should also run this hostchk.sh script.

See it's this I'm unclear on because right now make bug-report will run hostchk.sh. There seems to be an overlap of uses here. If hostchk.sh should not call bug-report.sh but bug-report.sh should call hostchk.sh what should hostchk rule do? Right now it's:
hostchk bug-report:
        @-./hostchk.sh -v 0; status="$$?"; if [[ $$status -ne 0 ]]; then \
            echo "Warning: you might not be able to compile this code, see above for details." 1>&2; \
        fi
but it seems that:

the bug-report part will have to be removed and changed to its own rule which will call bug-report.sh

this bug-report.sh will instead call hostchk.sh with -v 1 and presumably attach the results to the log file (I guess bug-report.log is what it was ?)?

The hostchk.sh currently:

checks for tar

checks for cc

checks that both cc and tar are regular executable files

tries to make a tarball with the correct options (like -J)

automagically compile a set of C files with each include file used in the repo - determined at runtime of the script

I had the idea to do it this way and use the -x c - option to the compiler which I've used before in rare cases (take a guess where).

That's all it does now but should it do anything else? I'll get to the other thread and maybe find out but I'm still not clear on the overlap.
You may be overthinking this.

The bug-report, when generating a bug report, should probably run hostchk.sh with some verbosity level because the hostchk.sh tool might print, for including in the bug report, some useful stuff about the environment.

Consider the case where somebody is filing a bug report because the repo fails to compile. We need some information as to WHY the repo failed to compile. If the hostchk.sh tool observes that <sys/time.h> is missing, that might be a useful clue to include in the bug report.

So as part of bug-report generating a bug report, the verbose output of the hostchk.sh tool might be a useful thing to include.

That’s true. But that is already displayed without verbosity.

But as I said I am very very tired so maybe I just need a better night. I know I said I was going to go but I haven’t put the phone down just yet. I will do that now so that I can get (hopefully) enough sleep. Hopefully it won’t be as bad of a night either but I will see.

I see that you replied to another comment but I will not reply to it now but instead tomorrow. Except the one about losing time. I will take a quick look at that one.