Runtime arg list listing

ID:1980402
 
Nov 10 2015, 5:18 am
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()
Nov 10 2015, 11:05 am
Lists can be any length at all; going into detail about their contents would be extremely problematic.
Nov 10 2015, 11:07 am
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.
Nov 10 2015, 11:08 am
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.
Nov 10 2015, 11:09 am
Perhaps it could only be displayed when in DEBUG mode?

Makes sense.

Please.

:(
Nov 10 2015, 11:43 am
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.)
Nov 10 2015, 11:53 am
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.
Nov 10 2015, 1:18 pm
A good short thing to add might be the list's length.
Nov 27 2015, 9:20 pm
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.
Nov 28 2015, 2:43 am
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
Nov 28 2015, 6:28 pm
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.
Nov 29 2015, 1:39 am
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.
Dec 1 2015, 12:20 pm
bitflags for debug options