ID:1980402
 
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
It would be very nice if runtimes could list elements within a list if a list arg is on the stack.

runtime error: bad index
(...)
Debug (/scrollBar): New("Debug", the sClient (/sClient), /list (/list))
the sClient (/sClient): DEBUGscroller()



instead of /list (/list), it'd be nice to have it show, something like,

Debug (/scrollBar): New("Debug", the sClient (/sClient), /list (index1 = associaton1, index2 = association2) (/list))
the sClient (/sClient): DEBUGscroller()
Lists can be any length at all; going into detail about their contents would be extremely problematic.
Perhaps you could add a limit? So the first 10 elements get outputted and then if there's more just a (...)

At least this way we could split them up for debugging. Obviously there's ways around this, but it'd be a really handy feature to cut down on time spent fixing things.
The thing is I don't think it would be useful to most people to have this information; for most it would simply clutter their logs.
Perhaps it could only be displayed when in DEBUG mode?

Makes sense.

Please.

:(
Lots of games turn on debug mode so they can get more useful info out of their runtime errors.

I'm reluctant to add more info to the runtime errors because as it is I already added loc information. (The loc info, IMO, has more use because in a lot of RPG-type games it may point out which part of the map a problem occurred on.)
I am defeated. I still desire it, but I understand it's particularly specific, can be obtrusive, and is a somewhat unuseful use of your time.

I'll be back next time I run into a /list issue to request it again though, mark my words.
A good short thing to add might be the list's length.
i mean, really, we need a pram for debug, to give a verbosity level

#define DEBUG 0 //removes extra info from runtimes, only enables profiles.
#define DEBUG 1 //current
#define DEBUG 2 // -verbose
#define DEBUG 3 // first and last 3 elements of lists, contents of any vars on the current line
#define DEBUG 4 // full stacks, rather than partial stacks on big stacks, longer list info
#define DEBUG 5 // longer list info,
#define DEBUG 1000 // full lists, all stack vars, on top of all vars of all referenced datums, recursively. anything else you could think to add.
#define DEBUG 9001 // a full mem dump on every runtime.
In response to MrStonedOne
MrStonedOne wrote:
i mean, really, we need a pram for debug, to give a verbosity level

#define DEBUG 0 //removes extra info from runtimes, only enables profiles.
#define DEBUG 1 //current
#define DEBUG 2 // -verbose
#define DEBUG 3 // first and last 3 elements of lists, contents of any vars on the current line
#define DEBUG 4 // full stacks, rather than partial stacks on big stacks, longer list info
#define DEBUG 5 // longer list info,
#define DEBUG 1000 // full lists, all stack vars, on top of all vars of all referenced datums, recursively. anything else you could think to add.
#define DEBUG 9001 // a full mem dump on every runtime.

Posted at 4:20, username checks out.

I'll give it a +420
If not something like MrStonedOne recommends, how about allowing a variable or #define, something along the lines of LIST_MAX, that specifies how many items to dump from lists in runtimes? LIST_MAX = -1 means all items, LIST_MAX = 0 means none (default, so that you have to actually want to be affected by this), LIST_MAX = n to limit to n items.

I suspect it would usually be set to either 0 or -1, but perhaps one would feel more comfortable with, say, LIST_MAX = 10.
Recently I accidentally had a recursion error, in which a single runtime spanned like fourty lines simply due to the stack being so huge.

Is this not inherently the problem you want to avoid with the lists? If it's alright for the stack, why not the lists?

Multiple debug options would be incredibly useful.
bitflags for debug options