2024-01-24 12:57:02 I was pleasantly surprised that my code that I'm writing with gforth worked pretty much out of the box with ueForth (I had to poly fill some words, like source, etc.) Although it didn't work completely, something is failing, and it's hard to debug. 2024-01-24 14:41:54 sounds about right 2024-01-24 14:42:20 the last part, that is 2024-01-24 15:35:23 What are your debugging techniques? I use T{ }T a lot throughout the code (several assertions for each word). 2024-01-24 15:35:35 I also use debugger.ans but it only works with ANS forth 2024-01-24 15:36:09 And for quick things use cr ." D: " .s but not the most convenient. 2024-01-24 15:50:06 i've actually never used a forth written by someone else, so my debugging techniques often come down to strategic prints or exit codes (because often what i'm debugging is so broken that it can't facilitate a print). sometimes i try to step through it with gdb, but this is extremely tedious because i have to have a hexdump of my binary up and manually decode addresses into words 2024-01-24 15:51:15 somebody else should probably help you. i'm not a good source for forth help, because as interested in it as i am, so far i am not actually demonstrably productive with it 2024-01-24 16:04:53 neuro_sys_: I mostly just print out strategic stack values at strategic places and zero in on my problem. Even when a system is incomplete and first coming up, I can use an "exit to OS" word and move it around in my code to bracket failure points, pushing it deeper into the call stack as I get closer, until I know precisely where the failure occurs. 2024-01-24 16:05:17 I've dreamed of writing fancy debug environments, but to date have only done this "the old fashioned way." 2024-01-24 16:07:25 I've found stack imbalances the hardest thing to chase down. For that I have a word that will print my current stack pointer up in one corner of my screen, and another that prints the stack pointer one line below that first print. By moving those around I can zero in on where stack imbalances are "happening." 2024-01-24 16:09:45 A word I've thought about writing but havn't so far is kind of an "assert_depth" word. DEPTH? for example - it would do nothing if the depth matches, but print a notification and perhaps dump some other info if it doesn't match. 2024-01-24 16:10:13 Well, it would consume its argument on depth match. 2024-01-24 16:10:35 yeah, i've done that once or twice. but it was just a temporary debug word with a hard-coded expected depth that i deleted once i was finished with it 2024-01-24 16:10:54 Since the programmer ought to know how deep the stack is SUPPOSED to be - at least relative to some reference point - as the program executes. 2024-01-24 16:11:36 in production, the relativity is the issue. you'd have to track that, and that adds overhead 2024-01-24 16:12:27 I sometimes add .s at various points so I can see what's on the stack 2024-01-24 16:13:32 The nice things about interactivity, is you can test individual words 2024-01-24 16:14:26 Yes, for sure. 2024-01-24 16:15:21 I think we discussed this before, a nice thing to have would be a view of the returns stack with the names of the word to be returned to 2024-01-24 16:18:06 Sure. That's not usually "offered," but the return stack is accessible, so it's straightforward to use the values found there, search the dictionary to find the word they're in, and print out some readable name based on that. 2024-01-24 16:18:21 That's definitely something a debug environment would do as part of it's core operation, I think. 2024-01-24 16:19:31 As usual with Forth, you can have anything you want as long as you're prepared to write it yourself :P 2024-01-24 16:19:39 Yep. 2024-01-24 16:20:03 my new listener for retro does some things to aid in debugging displaying the top 5 stack values; the leading part of strings on the stack (for temporary strings); and has a space for watching several variables