@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.
04daa5eis from 20-sep.
pair!type to use
float32!components instead of
integer!. As using floats for pairs is not always desirable (because of side-effects in float handlings), we are considering keeping the
pair!as is, and introducing a new similar 2D type, but relying on floats. The hard part, as usual, is coming up with a proper syntax for such type (in addition to a proper name). So we are proposing
coordinate!for such new type name and using the same syntax as pairs, but with mandatory decimal markers, e.g.
1.0x2.0. Such type would allow also an optional third coordinate. Would such syntax be acceptable?