s7 Error messages in VSCode
14 views
Skip to first unread message
George
Jul 7, 2026, 6:14:45 PM (8 days ago) Jul 7
to Extempore
Ben
I’m finding some strange behaviour in the VSCode terminal when Scheme s7 error messages are displayed.
Firstly the error messages are more verbose now which is good I think.
However in any one working session it retains and displays a list of minimum versions of earlier errors during that session.
If you clear the Terminal display and make another error the new error is at the top of the display.
If you make lots of errors you get quite a display!
I am not up to following the detail of all your changes to the init.xtm where you override s7's catch
but maybe somewhere near this line in the new init.xtm
I haven’t tested xtlang error messages.
Regards
George
Ben Swift
Jul 7, 2026, 8:04:16 PM (8 days ago) Jul 7
to 'George' via Extempore
Hi George,
You were looking in the right neighbourhood, but the culprit was one level down from the catch override, in how the interpreter runs the code your editor sends it.
The more-verbose error text was intentional, but the pile-up wasn't: after an uncaught error, s7's stack wasn't being wound back to the top, so every mistake left a few frames behind. s7 builds its stacktrace by walking that stack, so each new error dragged along the leftovers from all the earlier ones — hence the growing wall of text. Clearing the terminal only hid the earlier printed output; the frames were still there, so the next error brought them all back.
The same bug bit scheduled callbacks (temporal recursion) even harder — a beat loop with a bug errors every firing. Both paths now run inside a proper catch that unwinds cleanly: you still get the terse "message / offending form / location" report, minus the trailing stacktrace, and repeated errors no longer accumulate. xtlang compile errors go through the same path, so they're covered too.
Fixed in v0.10.2, just tagged — binaries will follow once the release build finishes.
Cheers,
Ben
>--
>You received this message because you are subscribed to the Google Groups "Extempore" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to extemporelan...@googlegroups.com.
>To view this discussion visit https://groups.google.com/d/msgid/extemporelang/594de434-b9ef-4735-8d31-dd7556430230n%40googlegroups.com.
--
Cheers,
Ben
You were looking in the right neighbourhood, but the culprit was one level down from the catch override, in how the interpreter runs the code your editor sends it.
The more-verbose error text was intentional, but the pile-up wasn't: after an uncaught error, s7's stack wasn't being wound back to the top, so every mistake left a few frames behind. s7 builds its stacktrace by walking that stack, so each new error dragged along the leftovers from all the earlier ones — hence the growing wall of text. Clearing the terminal only hid the earlier printed output; the frames were still there, so the next error brought them all back.
The same bug bit scheduled callbacks (temporal recursion) even harder — a beat loop with a bug errors every firing. Both paths now run inside a proper catch that unwinds cleanly: you still get the terse "message / offending form / location" report, minus the trailing stacktrace, and repeated errors no longer accumulate. xtlang compile errors go through the same path, so they're covered too.
Fixed in v0.10.2, just tagged — binaries will follow once the release build finishes.
Cheers,
Ben
>You received this message because you are subscribed to the Google Groups "Extempore" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to extemporelan...@googlegroups.com.
>To view this discussion visit https://groups.google.com/d/msgid/extemporelang/594de434-b9ef-4735-8d31-dd7556430230n%40googlegroups.com.
--
Cheers,
Ben
George
Jul 8, 2026, 3:40:48 AM (7 days ago) Jul 8
to Extempore
I'm in awe!
Regards
George
Reply all
Reply to author
Forward
0 new messages