Post by Robert on Jan 13, 2024 23:02:24 GMT -5
George, as you know all too well, much of your time is spent debugging - in particular, debugging edit scenarios we encounter as users. Oftentimes, we describe only generally the steps that we took to encounter a particular problem. But, sometimes we remember the steps inaccurately. It can be hard to meticulously test something one step at a time, and write down somewhere (on paper, in a Notepad window, etc.) what we did at each an every step. Those inevitable inaccuracies only make your job harder.
The idea here is to implement a "state" in which the editor runs in "command log mode". Here is the basic outline:
1. A new keyboard primitive of (CmdLog) would be made.
2. (CmdLog) acts to toggle logging mode on or off. By default, command logging is off. When logging mode is on, all commands issued by the user are written to a logging file. A possible naming convention might be:
SpfCmdLog.yyyymmdd.hhmm.txt
3. When logging mode is off, and (CmdLog) is issued, a new command log file is created, in the main SPFLite home directory, with a name that has a date/time stamp as part of the name.
4. Every command issued by the user, whether primary, line or keyboard primitive, would be written to the log file, when logging is on.
5. A possible logging format might be:
hhmmss nnnnn t command
where hhmmss is the time the command as issued
nnnnn is a sequence number, starting at 00001
t is a code indicating the command type: P/L/K for primary, line or keyboard primitive
command is the command that was issued
6. When command logging is in effect, every effort is made to ensure that the logging file survives a crash. To do that:
(a) every write to the logging file is "flushed" to ensure it it written to disk every time.
(b) the logging line is written before the command is actually issued.
(c) to provide an indication if the command succeeded, the logging line would be written without a CRLF first. Then, when the command finished, a "closure" mark would be written. For laughs, let's say the closure mark was "[ok]" + $CRLF. That closure mark would be (separately) written and flushed to the log file. So there would be evidence whether the last command logged to the file actually finished.
In the event of a crash, a user would send you the command log file, to help you reproduce the steps that led up to the crash event.
Why do this, when there is a command trace in the crash file? Because the crash file has a limited number of entries. Unless the cause of the crash involved only a few steps, important steps leading up to the crash would fall off the trace record and be lost.
Obviously, the hardest part of this idea is finding convenient points to capture each command, just before and after it is executed. The better job you can to to log things, the more useful the log would be. Ideally, if you can find really good places to insert the logging calls, it would minimize the code impact of this feature. And, perhaps the logging doesn't have to perfectly detect absolutely everything, but mainly what is important.
As this is simply an idea, I don't claim that every possible nuance has been considered here. That would come if/when you chose to implement it.
Comments invited.
R
The idea here is to implement a "state" in which the editor runs in "command log mode". Here is the basic outline:
1. A new keyboard primitive of (CmdLog) would be made.
2. (CmdLog) acts to toggle logging mode on or off. By default, command logging is off. When logging mode is on, all commands issued by the user are written to a logging file. A possible naming convention might be:
SpfCmdLog.yyyymmdd.hhmm.txt
3. When logging mode is off, and (CmdLog) is issued, a new command log file is created, in the main SPFLite home directory, with a name that has a date/time stamp as part of the name.
4. Every command issued by the user, whether primary, line or keyboard primitive, would be written to the log file, when logging is on.
5. A possible logging format might be:
hhmmss nnnnn t command
where hhmmss is the time the command as issued
nnnnn is a sequence number, starting at 00001
t is a code indicating the command type: P/L/K for primary, line or keyboard primitive
command is the command that was issued
6. When command logging is in effect, every effort is made to ensure that the logging file survives a crash. To do that:
(a) every write to the logging file is "flushed" to ensure it it written to disk every time.
(b) the logging line is written before the command is actually issued.
(c) to provide an indication if the command succeeded, the logging line would be written without a CRLF first. Then, when the command finished, a "closure" mark would be written. For laughs, let's say the closure mark was "[ok]" + $CRLF. That closure mark would be (separately) written and flushed to the log file. So there would be evidence whether the last command logged to the file actually finished.
In the event of a crash, a user would send you the command log file, to help you reproduce the steps that led up to the crash event.
Why do this, when there is a command trace in the crash file? Because the crash file has a limited number of entries. Unless the cause of the crash involved only a few steps, important steps leading up to the crash would fall off the trace record and be lost.
Obviously, the hardest part of this idea is finding convenient points to capture each command, just before and after it is executed. The better job you can to to log things, the more useful the log would be. Ideally, if you can find really good places to insert the logging calls, it would minimize the code impact of this feature. And, perhaps the logging doesn't have to perfectly detect absolutely everything, but mainly what is important.
As this is simply an idea, I don't claim that every possible nuance has been considered here. That would come if/when you chose to implement it.
Comments invited.
R
