Comment by ~crc_ on ~crc_/retroforth
Arland suggests having the
includefunctionality scan the files for ~~~ and/or ``` blocks rather than using a specific file extension (or set thereof).
Comment by ~crc_ on ~crc_/retroforth
REPORTED RESOLVED IMPLEMENTED
Ticket created by ~crc_ on ~crc_/retroforth
RetroForth/nga requires source files to be in unu format (http://unu.retroforth.org). Should I add support for plain, non-unu source files?
Considerations here:
- what new command line arguments are needed
- do we need a variation of
includethat works with non-unu sources?
Ticket created by ~crc_ on ~crc_/retroforth
This is specifically about RetroForth/nga.
In the #retro irc channel, ae_chep said:
I was imagining a forth development experience to be like a conversation had with the interpreter. In which case to be hung up on is rather unpleasant
This is a quite reasonable way to view the expected experience. In the current system, I just report errors and exit, but that's not necessarily the best option in all cases.
Rick suggested adding
hook-able words for logging/instrumentation/alerting. This seems like something that would be worth adding.I think we should look at adding words for this, probably under the err: namespace. It might be worth having two paths. In the case of running a program directly, have these default to reporting error and exit. But in the case of an interactive session, it might be better to offer a way to try resetting the system state to something sane and allowing execution to continue.
Thoughts on this?
Comment by ~crc_ on ~crc_/retroforth
The files are included in the old releases.
For direct links:
- http://forthworks.com:8080/retro-language/file?name=library/fiction.rx&ci=tip is the fiction.rx library
- http://forthworks.com:8080/retro-language/dir?ci=tip&name=library is other libraries from retroforth11
- http://forthworks.com:8080/retro-language/file?name=examples/games/cloak-of-darkness.rx&ci=tip is the cloak-of-darkness.rx game code
Old releases:
Comment by ~crc_ on ~crc_/retroforth
For words in the base image, I'm manually filling in the source data, so those don't have duplications.
I have a couple of easy options for the others:
- setup a table (or linked list?) of source filenames & hashes, and point the d:source field to the existing entries (or add to it if not present)
- use the dictionary. In this case I'd have a word class that identifies these strings, and point the d:source field for words to the d:name field of the dictionary entries whose name matches the source filename
I like the second approach in terms of not needing to add another data structure, but it would add some visual noise to the output of
d:words. I'll probably do a prototype of each and see what feels better in practice.