fix(bklog):Update plan, bump version (bklog working)
authorSteven Baltakatei Sandoval <baltakatei@gmail.com>
Tue, 14 Jul 2020 22:27:50 +0000 (22:27 +0000)
committerSteven Baltakatei Sandoval <baltakatei@gmail.com>
Tue, 14 Jul 2020 22:27:50 +0000 (22:27 +0000)
Complete fix for `bklog` duration string bug.

exec/bklog
exec/bklog-plan.org

index a99468a5eaf6297abe13fea82420ea2322ccc5f1..504ecbc579da321bb6c5f52a51e1cfa0df745ee4 100644 (file)
@@ -11,7 +11,7 @@ dirTmpDefault="/dev/shm"; # Default parent of working directory
 
 # Script Metadata
 scriptName="bklog";             # Define basename of script file.
-scriptVersion="0.1.28-test4";          # Define version of script.
+scriptVersion="0.1.29";         # Define version of script.
 scriptURL="https://gitlab.com/baltakatei/ninfacyzga-01"; # Define wesite hosting this script.
 scriptTimeStartEpoch="$(date +%s)"; # Save start time of script in epoch seconds
 scriptTimeStart="$(date +%Y%m%dT%H%M%S.%N)"; # YYYYmmddTHHMMSS.NNNNNNNNN
index 597f653a5f8cc95fd5e2e16f462a60b65629fd99..36dd08be600a2bd9d5d79869e92873dd98ae524f 100644 (file)
@@ -1,5 +1,6 @@
 * bklog task list
-** TODO Adjust filename duration dynamically
+** DONE Adjust filename duration dynamically
+   CLOSED: [2020-07-14 Tue 22:17]
 2020-07-12T21:17Z; bktei> Currently, the "duration" component of the
 output filename for a given chunk is calculated from the ~bufferTTL~
 variable which does not necessarily reflect the amount of buffer lines
@@ -53,7 +54,11 @@ in seconds between ~bufferTimestampOld~ and ~bufferTimestampNew~ may
 be calculated and an appropriate duration string generated from the
 ~timeDuration()~ function.
 
-** TODO Update ~SECONDS~ variable during while read loop
+2020-07-14T22:17:16Z; bktei> Initial adjustment of SECONDS
+implemented. Ongoing monitoring of end time of each buffer round
+~while read~ loop checked.
+** DONE Update ~SECONDS~ variable during while read loop
+   CLOSED: [2020-07-14 Tue 16:22]
 2020-07-14T00:58Z; bktei> The starting timestamps of each output file
 still drifts against system time. Although the ~while read~ loop does
 not lose data, the drift causes the output files to be named weirdly.
@@ -67,11 +72,20 @@ number of lines being read in each buffer round should be tracked and
 a modulus comparison may be implemented within the ~while read~ loop
 so that a correction is made after some fraction of the expected lines
 to be read are read.
+
+2020-07-14T16:21Z; bktei> I ran a test to see if SECONDS drifts and it
+does not. The lag is caused by other synchronous commands. The
+solution will be to adjust the variables against which SECONDS is
+compared.
 ** TODO Account for "early-exit" bug in input script
-2020-07-14T03:00Z; bktei> What happens if the script piping its stdout
-into ~bklog~ immediately exits without providing any stdout (ex: a
-python script with a missing module)? ~bklog~ should be able to detect
-the latest exit code and exit early. It should also be able to detect
-if the incoming pipe is closed.
+*** 2020-07-14T03:00Z; bktei>
+What happens if the script piping its stdout into ~bklog~ immediately
+exits without providing any stdout (ex: a python script with a missing
+module)? ~bklog~ should be able to detect the latest exit code and
+exit early. It should also be able to detect if the incoming pipe is
+closed.
+
+*** 2020-07-14T22:25Z; bktei> 
+Possible solution using ~dd~, ~od~, and ~if [ -z string ]~ [[https://unix.stackexchange.com/a/33055][here]].
 * bklog narrative