Sub commands on the teletype

sam · 2017-01-05T14:51:52.145Z

Continuing the discussion from Replacing the parser code on the teletype (and also from ʜ⊥ᴚoℲ (and other Teletype ideas))

I’ve started a new topic for this, even though it’s the continuation of the parser work in the linked thread…

For users:

I’ve managed to get multiple commands running on the teletype, this is done by separating additional commands with a semi-colon, e.g.

X 1 ; Y 2 ; Z 3
L 0 3 : PN I 0 1 ; PN I 1 2

In the loop example, the code after the : would be run 4 times.

Do the examples make sense? I’ve got to dash soon, but I can write up a more detailed explanation / tutorial if needed. My feeling is that this (along with the mathematical operators) would be considered an ‘advanced’ topic.

For devs:

As with all things in computer science:

There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

While the first hasn’t been a bother I have struggled a bit with the last two. To that end I’ve tweaked the nomenclature a little and introduced the concept of a sub command:

sub_commands.jpg1024×488 170 KB

(the old concept of a sub command has been renamed to post command)

As it stands the code hasn’t been pushed anywhere yet (or even run on hardware). The changes are actually quite small, but I need to walk away from it for a bit, and then come back and double check it and add comments, tests, etc.

Once all the I2C gremlins have been fixed I’d like to get a PR opened for this (and implicitly the parser work). It’s probably going to be the last big change I make for a while. Things are looking a bit busy for the next few months.

tehn · 2017-01-05T15:01:53.526Z

this all makes wonderful sense and i’m in favor of the update. thank you for your excellent contributions!

sliderule · 2017-01-05T15:10:21.137Z

This is a great addition to the syntax! It expands the capabilities of the PREs without the use of SCRIPT, not to mention extending scripts beyond 6 expressions. (Now, if only there were nested PREs… )

I have a TT sitting here, but my case hasn’t arrived yet. If it doesn’t show up soon, I’m building a power supply for it so I can test and/or develop. I have cycles to burn over the next couple of months, so any time spent not synthesizing will likely be spent staring at code.

(Also, I got a chuckle out of your dev joke. )

glia · 2017-01-05T15:16:05.276Z

woah

need time to contemplate but this looks great

shellfritsch · 2017-01-05T17:52:59.672Z

This looks great. TT just gets better & better - thank you!

laborcamp · 2017-01-05T17:56:10.777Z

I LOVE this idea!

Totally useful.
Increasing code’s available space to functionality ratio.
Super elegant implementation that honors the simplicity of the TT code syntax.

BTW
is there an actual name for the TT code?
it’s not quite a “language” but…

glia · 2017-01-05T18:27:31.528Z

[quote=“laborcamp, post:6, topic:5987”]
is there an actual name for the TT code?
[/quote]good question

I’ve thought about it but never actually asked…

sam · 2017-01-05T18:29:23.273Z

laborcamp:

BTWis there an actual name for the TT code?it’s not quite a “language” but…

It’s basically Forth, but backwards (hence my terrible ‘ʜ⊥ᴚoℲ’ pun).

i.e. on the teletype you’d write ADD 1 1, but in Forth you’d write 1 1 ADD.

It has similarities to Lisp too (as any backwards Forth would). There is a Hackaday article on Forth here too.

laborcamp · 2017-01-05T18:52:05.755Z

Good to know @sam.

but, so:

is htrof as the name for the TT script your idea?

is @tehn calling it anything?

chapelierfou · 2017-01-05T20:06:54.657Z

Sorry for the stupid question, but :
is there any goal other than gaining more code space (which is already awesome) ?

sakul · 2017-01-05T20:15:39.068Z

Note that the PRE is valid on the whole thing (POST)… So as it is now, you have to sacrify a entire script with SCRIPT to do that.

After thinking about it… There is still the end of line constraint. Curly brackets around the statements would be awesome, as it would allow a new line. Then again, probably overkill for this mini language…

glia · 2017-01-05T20:27:55.368Z

[quote=“sakul, post:11, topic:5987”]
There is still the end of line constraint
[/quote]I think it’s buried in the other thread but do you remember how many characters (or spaces) fit per lline?

tehn · 2017-01-05T20:29:43.081Z

laborcamp:

is @tehn calling it anything?

didn’t think of this ever somehow.

laborcamp · 2017-01-05T21:43:38.704Z

it’s a thing.

should have a name, no?

(and monome is notoriously awesome with names of things)

sliderule · 2017-01-05T22:36:04.202Z

Subcommands also open up the ability to ‘pass arguments’ to a ‘subroutine’ SCRIPT, e.g.:

L 1 4 : A MUL I 5 ; SCRIPT 2

Really this isn’t ‘new’ functionality, as you could just

X ADD X 1

inside script 2 to derive I because I always increments up by 1. It comes at the cost of an additional variable though, so the new functionality is cheaper. Also you save code space in script 2 and it’s arguably cleaner.

sam · 2017-01-10T14:04:33.422Z

Actually tried the code on my Teletype today! Did my usual Turing Machine / Noisering / SoU script, but tweaked to take advantage of all the new features.

sub_command_init.jpg1024×768 174 KB

This is the I script, the first 3 lines set up a pentatonic scale in pattern 3. The 4th line empties patterns 0 and 1. And the final 2 lines set the first 8 entries of patterns 0 and 1 to random 0s and 1s.

sub_command_tm.jpg1024×768 167 KB

And then this is the actually Turing Machine-esque script. (Though there is a minor typo, PN 4, should really be PN 3, but it still works!)

(one caveat, I increased the number of ops per line from 12 to 16, just for my local build)

Here is the commit for anyone that wants to see:

github.com/samdoshi/teletype

add sub commands

by samdoshi on 01:30PM - 10 Jan 17 UTC

changed 12 files with 189 additions and 88 deletions.

In particular see process_command:

(I’ve added some comments so hopefully it’s easy to follow along.)

github.com

samdoshi/teletype/blob/09f95021c6a817e51199f0b5ad4c7f68761a7b01/src/teletype.c#L206


    exec_state_t es;
    es_init(&es);
    return process_command(&es, cmd);
}




/////////////////////////////////////////////////////////////////
// PROCESS //////////////////////////////////////////////////////


// run a single command inside a given exec_state
process_result_t process_command(exec_state_t *es, const tele_command_t *c) {
    command_state_t cs;
    cs_init(&cs);


    // 1. Do we have a PRE seperator?
    // ------------------------------
    // if we do then only process the PRE part, the MOD will determine if the
    // POST should be run and take care of running it
    ssize_t start_idx = 0;
    ssize_t end_idx = c->separator == -1 ? c->length : c->separator;

It still needs more testing, in particular I need to check things like delays and stacks work properly. I’m stilling aiming to put a PR in once the I2C stuff is sorted out.

sliderule · 2017-01-10T15:26:57.089Z

Fantastic!

I’ve been playing around with the parser in the simulator. I have been running with

mod_separator = ':';

without any problems. All the tests run okay, including all permutations of existing tests using no spaces around the colon.

The semicolon might be able to be afforded the same treatment. Code density is a big concern in these little scripts!

sam · 2017-01-10T15:54:43.409Z

Yeah, there is some discussion of it on the parser thread:

Replacing the parser code on the teletype Tech

Right. I’ve successfully managed to replace strtok with a custom Ragel scanner. The code is a bit yucky still, I’ll tidy it up before I push it to my parser branch. Basically I extracted out a match_token function from parse, then replaced parse with Ragel code, while keeping match_token. One quick question, should we commit the Ragel generated .c files? Or put it in the .gitignore file? My preferences is to not commit it, Ragel appears to be available in all Unix package managers, as well as H…

The tl;dr is that everyone wants to get rid of the spaces around : (and therefore ; too) but the font needs a bit of fiddling with, plus print_command will need updating too.

If you interested it would be a good little project to do, update the font, get print_command working (add some tests for it…). I can help you out if you need, though I think I’d rather get my code merged to master first.

sliderule · 2017-01-10T16:11:44.048Z

Yeah go ahead and get your stuff merged to master. I don’t have a functioning TT yet (still waiting for case to arrive) so I don’t have a real test environment, I’m just exploring the code base.

I hadn’t considered print_command. I’m not sure there’s an easy solution there, it’s ambiguous. Either the lack of spaces will be enforced (which will reduce legibility for short lines) or lost (breaking/overflowing long lines), or we’ll have to carry around state information for which spaces are present somehow.

One solution not mentioned in the thread is 4 different tokens for the separator with identical behaviour / parsing. [':', ' :', ': ', ' : ']

It would probably be less ROM intensive than storing the text representation of the script, but on the other hand: eeeeeeeeeew.

sam · 2017-01-19T13:34:54.234Z

I’ve had another play on hardware today. Everything still seems fine.

Early next week I’m going to merge master into my branch and open up a PR.