@loziniak in current codec implementation (which is not even 1.0, mind you), error reporting has coarse granularity, i.e. it marks location before malformed JSON value (object in this case), and reports it only after parsing have failed.
As for "poor Red messages" see red/red#3282 thread. Informative error reporting in dynamic and homoiconic language (such as Red) is not a trivial problem to solve.
I appreciate that error reporting is not trivial, but what we have at the moment is not fit for purpose. It may be more-or-less adequate when debugging the latest dozen lines of code writte while developing (9/10 times the problem is in those lines). But it seems to fundamentally put a limit on the size of Red systems - and/or the ability to easily integrate two separate code bases.
User example - a couple of weeks ago, I experimentally tried to convert a Rebol/Core system (60 scripts, 25,000 lines of code) to Red. I did not expect it to be easy or fun. But I was not expecting to be so misled by errors messages.
Take this one - it took a couple of hours of my life to resolve:
type: 'script id: 'invalid-type arg1: word! near: none where: 'set-path
There is not a single instance of SET-PATH in the 60 scripts / 25,000 lines of code. So basically, not a single clue in the message where to start looking.
(If you are interested, the bug fix was to make the 'word in a FOREACH local to its function). I got a log of around 20 other errors which might as well have just said "Shrug. Magic bad".
So attacking the non-trivial problem with some priority could well be a unique selling point for Red.
GTKbranch last week, but this week there is activity in
refactor-lexerand it does not show up. The links are like
https://github.com/red/red/tree/refactor-lexerand similar for all branches.
I have just published a small program to check if you have the latest Red version. It is in my Gist
Very cool @meijeru !
@JacobGood1, thanks for those links. We have various elements of debugging to address: language (errors), instrumentation/tracing (runtime), and environment (tooling). @maximvl did some CL-like experiments, which were pretty cool, showing how Red can be adapted at the user level for some things. Tooling is probably the easiest thing to address, because we can build them as needs arise, and use the future plugin system in the console and full IDEs. e.g. a 5-minute object inspector:
debug-obj: function ['obj [word!] "Ref to object"][ o: get obj spec: copy [across] repend spec ['h3 rejoin ["Editing: " obj] 'return] foreach word words-of o [ repend spec [ 'text form word to set-word! rejoin ['f- word] 'field 'data o/:word compose [ (to set-path! reduce [obj word]) face/data probe o ] 'return ] ] probe spec view spec ] o: object [x: y: 0] debug-obj o o2: object [x: y: z: 1] debug-obj o2
Instrumentation is an interesting area I'm keen on (think DTrace), and Red's dynamism is great and terrible for some of these issues. e.g., it's not just a compiler optimization switch we can flip. We also constantly push and pull, on the design side, about what needs to be in R/S for performance, and what can be built at the user/mezz level. Also figuring out what hooks are necessary in order to facilitate probing and AOC type features, without going full MOP on people. I'm not saying MOP is bad, not at all, just that it's not part of Red's design today.
It all raises questions about debugging in general, and that one size does not fit all. Sometimes you're debugging a function, working in the REPL, sometimes an application, other times a complete system.
debug-onkeyword and the point where you should end the debugger with
selected the point where you wanted to start debugging
I hope you realize that in Red this "point" cannot even exist in a textual program at the time of debugging (e.g. code generation). Traditional breakpoints are extremely limited, and cover only a naive, static subset of the language.
Type help or h or ? for help at the prompt (rdbstep) *** Script Error: stepnext does not allow string! for its redsrc argument *** Where: stepnext *** Stack:
send-keys, which is a Windows-only GUI lib for keystroke pumping. Another was an old Install Helper app that launched apps, watched for dialogs and interacted with them, etc.
red.exefor Windows (22-Sep-2019, sha: 7daa2dd5) and compiled the console (yielding
gui-console-2019-9-22-34786.exe) but, strangely, when I ask for
about, it gives me
Red 0.6.4 for Windows built 20-Sep-2019/18:03:51+02:00 commit #04daa5e, which is a much older version. What am I doing wrong? Also, I can't see a commit with sha: 7daa2dd5 anywhere.