TH1, is there a REPL for it?
(1) By Larry Brasfield (larrybr) on 2022-01-24 13:21:37 [link] [source]
(After a diligent doc search, including search sifting, my desire for an answer on this has overcome dislike of being embarrassed by a too-easy answer.)
TH1 appears to be perfect for customizing or creating most of web page responses. This has made me want to use it in some CLI applications, and perhaps get a few things done conveniently from the CLI that I do often from the CLI. (Point-and-click is not among my favorite program interface methods.)
After looking quite a bit through the docs, both online and available in the Fossil app (through the CLI!), it appears that using TH1 from the CLI is either impossible now or is an extremely obscure feature. I've contemplated reading the source to see which of "impossible" and "obscure" is closer to the truth, but that seems a daunting task.
Does anybody here have an easier answer? (And if so, please feel welcome to show how easily I might have discovered it if only I knew more of Fossil's discoverability features. I almost think there should be a tip sheet on that subject.)
(2) By Stephan Beal (stephan) on 2022-01-24 13:27:42 in reply to 1 [link] [source]
TH1 appears to be perfect for customizing or creating most of web page responses. This has made me want to use it in some CLI applications, and perhaps get a few things done conveniently from the CLI that I do often from the CLI. (Point-and-click is not among my favorite program interface methods.)
There is not a fossil-capable REPL for it, primarily because fossil's internals are very much geared towards "do this one thing and then exit()" and most errors are fatal to the app.
However... some years ago i ported TH1 out of the fossil tree into a standalone library and it would be trivial to wrap a REPL around:
https://fossil.wanderinghorse.net/r/th1-sgb
(haven't tried compiling that in ages - newer gcc's might choke on it)
with, of course, the caveat that it completely lacks fossil-specific capabilities.
And though it's not a REPL, we have a few "test" commands for working with th1:
Wrapping test-th-eval in a shell-script REPL sounds trivial but would of course be stateless so of limited utility.
(3) By Stephan Beal (stephan) on 2022-01-24 13:40:38 in reply to 2 [source]
(haven't tried compiling that in ages - newer gcc's might choke on it)
Scratch that:
[stephan@nuc:~/fossil/th1-sgb]$ m
Generating dependencies...
+ ccache cc -pedantic -Wall -Werror -fPIC -g -std=c89 -DDEBUG -UNDEBUG -I. -I./include -c -o th1.o th1.c
+ ccache cc -pedantic -Wall -Werror -fPIC -g -std=c89 -DDEBUG -UNDEBUG -I. -I./include -c -o th1_lang.o th1_lang.c
+ ccache cc -pedantic -Wall -Werror -fPIC -g -std=c89 -DDEBUG -UNDEBUG -I. -I./include -c -o th1_main.o th1_main.c
+ ccache cc -pedantic -Wall -Werror -fPIC -g -std=c89 -DDEBUG -UNDEBUG -I. -I./include -c -o test.o test.c
+ ccache cc -pedantic -Wall -Werror -fPIC -g -std=c89 -DDEBUG -UNDEBUG -I. -I./include -c -o th1_client.o th1_client.c
+ /usr/bin/ar crs libth1.a th1.o th1_lang.o th1_main.o
+ ccache cc -o th1 -pedantic -Wall -Werror -fPIC -g -std=c89 test.o th1.o th1_lang.o th1_main.o th1_client.o
[stephan@nuc:~/fossil/th1-sgb]$ ./th1 -R script/1.th1
Hi, world.
Got expected error: puts: wrong # args: expecting: STRING ...STRING_N
buffered=this will be buffered this will be buffered this will be buffered
argc=1
arg #1=1
argc=0
argc=3
arg #1=1
arg #2=2
arg #3=3
TH1_RETURN=3
The End TH1_RETURN=3=3
The End TH1_RETURN=3=3
The End TH1_RETURN=3=3
rc=0rc=18=0018=0x0012=18.00
(4) By Larry Brasfield (larrybr) on 2022-01-24 21:02:06 in reply to 2 [link] [source]
I suppose those 3 test commands are almost as good as a REPL, provided no experimentation is needed to figure out what TH1 to submit. (I confess to relying on such experimentation at times.)
BTW, my very first TH1 program, in file sayhi.th1, reading:
puts Hi
, and you'll never guess what it did. (No need to guess:) It blurted:
HiHi
. I hope there is some way to cure its stuttering.
It would also be nice if the test-th-source subcommand would accept '.' as a synonym for reading stdin. Today, that seems to have no effect, not even an error exit. Methinks it needs a little further development to be a good scripting citizen.
(5) By Stephan Beal (stephan) on 2022-01-24 21:07:47 in reply to 4 [link] [source]
I hope there is some way to cure its stuttering.
It's outputing the result of the final expression, which is the string passed to puts. The trick is, IIRC, to end the script with an empty expression (but am away from the computer so can't readily verify that). A couple of semicolons ought to do it.
It would also be nice if the test-th-source subcommand would accept '.' as a synonym for reading stdin
Try a dash. That will work, IIRC, and is the conventional Unix-tool name for stdin/out. Failing that, the name /dev/stdin will work on any Linux and probably WSL.
(6.1) By Larry Brasfield (larrybr) on 2022-01-24 21:36:38 edited from 6.0 in reply to 5 [link] [source]
Try a dash ...
Doh!
Thanks a bunch. It's funny that fossil blurts statement "values" without asking, just like tclsh does, but I had thought that was for interactive use and convenience. The Tcl interpreters typically do not do that for non-interactive input. I'll experiment to see if that spontaneous emission can be avoided without undue clutter in TH1 inputs.
(Amendments:)
The --no-print-result option squelches that extra output.
Strangely, puts does not append a newline. Hmmm.