That's another option.

Some possible hiccups that would need to be considered:

• performance when loading large files.
• Accidental false positives in applications that do funny things with text input parsing and have stray ~~~ chars in unexpected places.

Another option I hadn't considered could be to have some sort of pragma comment that is always on the first line of a non-unu source..

Eg:

\DISABLE_UNU

Thinking about it more, it would seem that having an "Unu-aware" include word might mandate a known file extension. If that's the case, maybe there is no need for a special flag (the Unu-ness of a source file would be inferred from the file extension).

I've seen a few folks get tripped up by Unu, so I think this is a good idea. You could possibly use a -p / --plain flag. I think it would be important to have a unified include word that can mix Unu and non-Unu source files.

Hey everyone,

I wanted to jump back into the discussion we had on Patreon.

With regards to the new comment:

Being hung up on is rather unpleasant.

I totally agree with this sentiment. I've personally experienced this issue, and it's not fun. After hearing more about the context of the situation, I think it would be helpful to determine at runtime whether the -i (interactive) flag has been passed or not.

For example, if I'm using Retro to serve requests to TCP sockets in a production environment, I definitely wouldn't want it to swallow errors when it runs into an error. But if I'm working in interactive mode (trying things out / doing dev work) it would be great not to have to restart my environment every time I make a mistake.

So yeah, I hope that clears things up a bit! Thanks for adding more context to the conversation.

Cheers!

Any idea on how you would do this? I've thought about how this might work also. Maybe a dictionary entry that contains the string and then use a content hash in the header that points to a string lookup table? I don't have enough knowledge of Retro internals to say for sure but am curious.

#Description of Problem

An error message was recently added to assist new users:

warning: no code blocks found!
         filename: foo.retro
         see http://unu.retroforth.org for a brief summary of
         the unu code format used by retro

If the user creates a file that is 100% unit tests, they will erroneously be presented the warning above. This does not stop the program from working, but the behavior might be confusing.

#Steps to Reproduce

1. Create a file, foo.retro, which only contains triple backtick blocks.
2. Run the file via retro -t foo.md
3. Observe the error described above.

After running make, the following error was observed:

cp ../../ngaImage nativeImage
../../bin/retro-extend nativeImage x86/common.retro x86/cmos-rtc.retro x86/serial.retro x86/display.retro x86/ata.retro x86/listener.retro
Initial Image Size: 9914
s:index-of ?
   + 220 tokens from x86/common.retro
   + 59 tokens from x86/cmos-rtc.retro
   + 186 tokens from x86/serial.retro
0xB8000 ?
   + 517 tokens from x86/display.retro
   + 323 tokens from x86/ata.retro
   + 252 tokens from x86/listener.retro
New Image Size: 10814
MAX SP: 16, RP: 55
Stack not empty!

Stack: 
../../bin/retro-embedimage nativeImage >image.c
cc -fno-pie -Wall -m32 -DTARGET_X86              -c retro.c -o retro_qwerty.o
retro.c:7:10: fatal error: sys/limits.h: No such file or directory
    7 | #include <sys/limits.h>
      |          ^~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:7: native386] Error 1

#Steps to Reproduce

1. Run retro -i -t foo.retro (assuming this file does not exist)
2. Observe that retro goes into the REPL, but does not crash or emit warnings about the fact that the file is missing.

#Expected Behavior

Since most CLI tools will exit with code 1 and emit an error message (or emit a warning if they do not crash on bad input), I found the current behavior surprising.

#Version Info

RETRO 12 (2021.7)

EDIT: A previous version of this issue incorrectly stated the problem. The problem does not relate to word not found errors as previously stated.

The current RetroForth REPL behavior differs slightly from what I expected from a traditional Forth.

In REPL mode, a stack underflow error will exit the process:

$ retro
RETRO 12 (2021.7)
524288 Max, 15004 Used, 509284 Free
s:put

ERROR (nga/execute): Stack Limits Exceeded!
At 9320, opcode 29. sp = -1

$ 

This behavior is unlike most desktop Forth systems (GForth, PForth, etc..), which recover from such an error.

As multitasking becomes more integrated, there may be a need for "task local" variables. This is something I've been thinking a lot about lately, especially with regard to how hooks would work in a heavily multitasked VM.