Debugging
- Posted by petelomax Feb 04, 2021
- 922 views
I've just put in a dirty little hack to impove the ex.err output for builtins/dict.e's trees, in builtins/VM/pDiagN.e:
--4/2/21 -- if lt+lp<MAXLINELEN then if lt+lp<MAXLINELEN and (cdi_filename!="dict.e" or cdi_varname!="trees" or prdx=1 or remainder(prdx-1,5)!=0) then
where cdi_filename and cdi_varname are new and set appropriately elsewhere, so it groups much nicer:
C:\Program Files (x86)\Phix\builtins\dict.e:
trees[1] = {}
trees[2][1..5] = {19006312,{`struct`,`Label`,9,1},6,4,46'.'}
trees[2][6..10] = {19005168,{`struct`,`Fill`,4,1},11,3,21}
trees[2][11..15] = {19004640,{`struct`,`Fill`,4,2},26,2,0}
trees[2][16..20] = {19005344,{`struct`,`Hbox`,7,1},0,1,0}
trees[2][21..25] = {19006136,{`struct`,`Button`,8,1},16,2,0}
trees[2][26..30] = {19004112,{`struct`,`Button`,8,2},0,1,0}
which better matches the
enum KEY = 0, DATA, LEFT, HEIGHT, RIGHT
that builtins/dict.e uses internally. Previously it was a right old mess and very difficult to read.
Of course "by5" is just one of an infinite number of possible "rules".
The question is, do your apps have similar dumps that you wish showed up nicer in the ex.err?
If so, what might be the best way to specify such things?
(Please post similar examples to the above to help me see what you mean/want.)
One possibility might be (in builtins\dict.e itself):
debug_format(trees,"by5") -- or debug_format(trees,routine_id("by5")) -- debug_format(trees,by5) -- (equivalent of course, assuming by5() is a suitable routine)
ie a named pre-defined rule, or a user-level procedure that takes on full responsibility for outputting that variable to the ex.err.
Note this might only be practical for static file-level variables, debug_format() would be more compiler directive than real routine.
If/when said user-level procedure crashes and leaves the ex.err in a mangled state, not my problem.
Obviously if there's no interest, that little hack will stay, and no more will be said.
