OpenEuphoria

1. Debugging

• Posted by petelomax Feb 04, 2021
• 777 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.

3. Re: Debugging

• Posted by jimcbrown (admin) Feb 07, 2021
• 685 views

I second this. (Though I can be flexible here - a traditional ini is fine, I'd accept things as bad as YAML or even just some extra command line switches.)