Spurious chars in ONOFF output

[varenius]

Using commit fbd0133b0953b344d698254d8547a60010ea4cce : The ONOFF VAL and SIG lines appar OK, but others have a spurious char inserted after #onoff#, for example:

2020.171.07:34:20.63#onoff#ðAPR ih     9552.00 1.573  371.67  0.027000 1.00000  0.027000 11600.00 p 0.16620
[...]
2020.171.07:36:07.12#onoff#¶ONSC   104.0   0.00000   0.00000 ig     2399.0      1.4 ih     2570.0      4.2

Is this correct? Please see attached logfile dc6.log. Again, it doesn't happen for the VAL or SIG lines, but for the others.

[wehimwich]

Hi Eskil,

This baffles me. It does not happen at either KPGO 20m or 12m (we have no other testers with antennas so far, except you). None of the relevant code has changed since the versions KPGO are running, 229f696ea124a8b495935bc0ad0f64a68261b266 (12m) and 10396864bf19aa3f87cdf5b0061064d484b0f500 (20m) . The code is structured so that the operations should be the same for VAL/SIG compared to other records. The code seems to be pretty straightforward in this regard. If it is in the code anywhere, it is most likely in poclb/logit.c.

I am not labelling this as "cosmetic" because if the spurious character was a new-line. it would cause a problem for gndat (the only downstream user of this data), even though it uses strstr(line,"APR") to find the APR records.

if you have time, just as a shot in the dark, could you please try (as prog at a shell $ prompt):

 $ cd /usr2/fs
 $ make rmdoto rmexe
 $ make >&/dev/null
 $ make -s                     #no news is good news

(you could rebuild your station software from scratch as well, but that should not be necessary)

reboot and try again?

Thanks, Ed

[varenius]

Tried

prog@njord:/usr2/fs-git$ git checkout master
[...]
prog@njord:/usr2/fs-git$ git pull
[...]
prog@njord:/usr2/fs-git$ git rev-parse HEAD

which shows I'm using the latest de9dd2ab8b11ec858488b46e4901bd0967843f74. Then, as instructed:

prog@njord:/usr2/fs-git$ make rmdoto rmexe
rm -f `find . -name '*.[oas]' -print`
rm -rf oprin/readline-2.0
rm -f `find . -name '*.pyc' -print`
rm -rf third_party/include third_party/lib third_party/bin
find third_party/src/* \
    ! -iname '*.tar.gz' \
    ! -iname '*.make' \
    ! -iname '*.template' \
    -delete
rm -fr bin/*
prog@njord:/usr2/fs-git$ make >&/dev/null
prog@njord:/usr2/fs-git$ make -s

and then "reboot". Didn't work, still spurious char as before (i.e. not before VAL/SIG lines). Also tried

cd /usr2/st
make rmdoto rmexe
make
reboot

... but still the same problem.

Note: Originally I got different spurious chars. In my few tries this morning, I always got the "?" char (except for VAL/SIG lines). Not sure if this means anything.

Weird bug, this one!

[wehimwich]

Found it. Whew! It was a bug I introduced in 651701a6c, a really dumb error. I have left the fix (unstaged) in poclb/logit.c on your machine and your FS remade so you can use it. I will introduce it as a commit on master shortly. Frankly, I am surprised that it wasn't apparent for other users and more apparent in general, but it is entirely my fault.

I didn't want to mess with your unstaged and untracked files. It looks to me like they are related to Mikael's version of ibcon. We can look into getting that merged into the FS if you all would like. In the meantime, we could at least include the changes to boss/rdtib.f; they look entirely backward compatible. That way you won't have to re-update it when there is a new FS release. Life is easier if the working directory is clean. :)

In the meantime. I would encourage moving Mikael's version of ibcon to /usr2st, for the same reason. The only revisions necessary for that should be to change the .. references in the Makefile to ../../fs, the same change to include file references in the code, and to add it to /usr/st/Makefile. OTOH, if the ibcon changes are backward compatible, maybe they could be merged in first. It make be a little while until there is a chance though since we have to be really sure they are backward compatible. We could also put it on another branch initially.

Just as an aside, I noticed that you said that you were testing with fbd0133, which was actually before -beta1 and before the erroneous commit. Maybe that was the last version you tried before -beta1. According to the log you attached, dc6.log, you were testing with 7c2a0b11 (-beta1-97-g7c2a0b11-dirty), which doesn't seem to be on master. Maybe it was a local commit, but at 97 commits after -beta1 it is almost certainly after the bad commit which was 21 commits after -beta1. This didn't confuse the debugging process in anyway, but I noticed it as I traced the trail of my error. Thank you for testing with master and I apologize for the bug.

[dehorsley]

This is a good argument for using a code formatter :)

On Sun, 5 Jul 2020 at 08:12, Ed Himwich notifications@github.com wrote:

Closed #53 https://github.com/nvi-inc/fs/issues/53 via 1d9137b https://github.com/nvi-inc/fs/commit/1d9137bce6c236f75df50dee8795e1a9304fcb01 .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nvi-inc/fs/issues/53#event-3512875645, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZ6PRGC4DTKUJK3HMLAJVTRZ6SMVANCNFSM4OCVAFPQ .

[wehimwich]

I am game. The one thing I have never really recovered from by leaving emacs was losing its indentation features (otherwise I like vim much more), but we are discussing indentation on a different thread.