Vector vol. 23 Nos. 1&2 Contents Editorial Stephen Taylor 2 Sustaining Members News
Download 0.53 Mb.
|
- Navigate this page:
- Code Snippet
- Restarting and Resetting
- Here is one I made earlier
- Rules of Thumb
- “Have you stopped beating your wife yet A simple yes or no answer is all that is required.”
ErrorbotAs he wrote with a pen in each hand, And explained all the while in a popular style If your users are bent on producing lots of errors you may wish to automate the documentation of them, via an “errorbot” which, without your intervention, quietly extracts the end-user environment and error information, and then (with a pen in each hand) writes it to log file, printer, web page and email. Under Dyalog APL it is possible, but not straightforward, to create an environment that can automatically extract the ⎕DM and ⎕SI as text from a CONTINUE workspace. I will leave that as an exercise for the advanced user to work out. (I believe it is also now much simpler under Version 11 to extract this info from an APLCORE workspace.) Alternatively, your bulldozer error trap can attempt to save this information at the point of the error into variables known to your pet errorbot, from where a simple ⎕CY command can extract it. Code SnippetN.B. The last (fourth) line of APL is split onto several lines, as shown by ellipses. ⎕ML is assumed to be 0 or 1. The code is ⎕IO-independent. #.quaddm←⍬ ⍝ initialise ⎕DM store #.quadsi←0⍴⊂'' ⍝ initialise ⎕SI store continue←'''',(ExpandPath ⎕WSID,'..\..\continue.dws'),'''' ⎕TRAP← (0 'E'( … '⎕TRAP←(0 1000) ''S'' … ⋄ #.quaddm,←⎕dm … ⋄ #.quadsi←↑⎕XSI,∘{''['',(⍕⍵),'']''}¨⎕LC … ⋄ ⎕save ',continue,' … ⋄ ⎕off ')) Restarting and ResettingJust the place for a Snark! I have said it twice: That alone should encourage the crew. Just the place for a Snark! I have said it thrice: What I tell you three times is true. If you )XLOAD a CONTINUE workspace, it may be possible to correct the problem and then restart the workspace to test if the fix has worked. File ties are independent of saving or loading workspaces. So an )XLOADed CONTINUE workspace will need any files retied before restarting. I have found that by: [1] using )RESET to clear the stack; [2] running the workspace to a stop placed near where the error occurred; [3] without untying the files, )XLOADing the CONTINUE workspace again we are almost ready to restart the workspace. Unfortunately, the CONTINUE workspace does not contain the ⎕PATH at the point of the error. So before restarting, you may need to set the ⎕PATH. CONTINUE workspaces preserve even OLE links to Microsoft Word, etc.! Now activate Debug Mode via Ctl-Enter, and you’re ready to roll. (Or at least roll over dead with the same error the user got.) If you can’t reproduce the error using his data, start by looking at the differences between his environment and yours. A pre-Version 11 APLCORE cannot be )XLOADed but data may sometimes be copied into the active workspace with )COPY or ⎕CY. (An )XLOAD is preferable because it preserves the stack.) To determine, without the stack, where the SYSERROR occurred, I find it useful to ⎕CY the whole of the APLCORE into a clear workspace, and then look at all the local variables. )CLEAR
⍝ use ⎕CY because )COPY omits local variables ⍝ APLCOREs don't have .DWS extensions, so use full pathname ⎕CY 'C:\Dyalog\APLCORE.' Since the local variables of functions on the stack at the point of the SYSERROR are accessible, their names and values can be used to determine which functions are in the stack. Distinctive local names help this process; reusing similar names, (e.g. x, y, r, data, text, mat, name) make it far more difficult. Here is one I made earlier“Two added to one – if that could but be done,” It said, “with one's fingers and thumbs!” Recollecting with tears how, in earlier years, It had taken no pains with its sums. If you really want to know exactly which functions are active at the time a SYSERROR occurred, try putting into every function a label that identifies the function’s name. For example, for a function Foo, name the label Lab_Foo.) Only the labels of functions in the stack will be ⎕CY copied from the APLCORE, so listing all variables starting with Lab_ will list all the functions on the stack at the time of the SYSERROR. Unfortunately you can’t put a label in a D-function, but if the Dfn is dynamically created and localised, it is not a problem. Then the very fact that the Dfn has been copied by ⎕CY proves it was on the stack at the time of the SYSERROR.
2. Part-tested code that fails in production often does so on “edge conditions”. 3. That the code works with 2, 3 or 4 elements, but fails with a scalar, is a mistake typical of a newbie. A more experienced writer’s code might fail with zero elements. Well-tested code could still fail with twenty million elements (or fewer) due to WS FULL. 4. Virtually all code will fail at the extremes, or if the environment is changed. “Have you stopped beating your wife yet?
|