Mastodon Feed: Posts

ireneista@irenes.space ("Irenes (many)") wrote:

we would very much want that to be somehow applying the same rules that are used for typed command lines

ireneista@irenes.space ("Irenes (many)") wrote:

this form of it would require an approach similar to the thing we proposed above for the typed ./evoke inscribe evoke.e command, allowing the word "inscribe" to have special behavior attached to it that changes the meaning of following utterances.

ireneista@irenes.space ("Irenes (many)") wrote:

it's really tempting, though, to think about what kinds of rules might allow the voice user to simply say

"dot slash evoke inscribe evoke"

leaving out the string delimiters and the dot-e

ireneista@irenes.space ("Irenes (many)") wrote:

that's a little awkward, but probably acceptable. if anything, it's better than the typed shell version, as long as it's processed in a way that handles the quoting

ireneista@irenes.space ("Irenes (many)") wrote:

or if the user had "evoke" installed somewhere globally because they were very fond of using it this way, they could leave out that first "dot slash"

ireneista@irenes.space ("Irenes (many)") wrote:

so that last version of the invocation would become something like

"dot slash evoke string evoke dot e end string inscribe"

ireneista@irenes.space ("Irenes (many)") wrote:

now, one more thing. imagine the someday-voice-control version of this UI. in that setting, we don't get to directly type punctuation marks, we have to say everything out loud as a word, which means we need a vocabulary of words and short phrases that deal with our syntactic constructs. it's highly important that it be a very small vocabulary, to make things easier for the speech-to-text engine and for the user; larger vocabularies lead to ambiguity problems.

ireneista@irenes.space ("Irenes (many)") wrote:

it does require the user to work around the shell's handling of quotation marks, but that may be worth it for consistency. after all, it's their shell, they can swap it if they want...

ireneista@irenes.space ("Irenes (many)") wrote:

or, we could forgeo all these special rules and treat the command line parameters as just like any other execution context. then the invocation would be

./evoke 's" evoke.e"' inscribe

there's stuff to like about that approach

ireneista@irenes.space ("Irenes (many)") wrote:

(of course * won't work in that context anyway because it's special to the shell, but let's imagine we have a user who doesn't mind working around that every time)

ireneista@irenes.space ("Irenes (many)") wrote:

an alternate rule would be that the only words that can happen on the command line are words drawn from a specific closed vocabulary which provides special syntax support for being used that way. so there would be some sort of internal inscribe-from-command-line helper which gets called for this situation.

that would let ./evoke inscribe evoke.e work, at the cost of forbidding the user from doing ./evoke 2 3 + 9 * logfloor . or whatever

ireneista@irenes.space ("Irenes (many)") wrote:

a rule we could create is that filenames as CLI parameters are turned into string literals, while other types of word are executed as they're encountered. this would make ./evoke evoke.e inscribe work as-written. but, uh, is that.... good? lol

ireneista@irenes.space ("Irenes (many)") wrote:

the usual non-Forth conventions for command-line parsing treat each word as potentially affecting the syntax of everything later on the line, but not before it. breaking with that would be a big deal and should only be done if it allows a different form of consistency that we find more important

ireneista@irenes.space ("Irenes (many)") wrote:

and how would this relate to situations where we're not compiling anything and we want to use the parameters as something else, a list of files to pre-load or a list of stack operations to perform?

ireneista@irenes.space ("Irenes (many)") wrote:

so if we make it so that the new helpers enchant and inscribe both take a filename string as their only parameter

using that interactively would look something like

$ ./evoke
s" evoke.e" enchant
bye

or

$ ./evoke
s" evoke.e" inscribe
bye

except, of course, you wouldn't do that because it would spew output on your screen, but leaving that aside

ireneista@irenes.space ("Irenes (many)") wrote:

so right now the ahem invocation to compile the compiler is

cat evoke.e | ./evoke > evoke2

and the way to compile the hex dump version of it is

cat inscribe-evoke.e | ./evoke > evoke.hex

we're trying to make it so inscribe-evoke.e doesn't need to be a separate file, that's the goal of this work

ireneista@irenes.space ("Irenes (many)") wrote:

we're also thinking way ahead to how we'd do a voice-control interface for this

(you may remember we had that RSI scare earlier this year that motivated us to start exploring the landscape of free software and voice control. it would be the right thing to do even if we didn't expect to personally need it, of course)

ireneista@irenes.space ("Irenes (many)") wrote:

we do want these to have a consistent interface, so we're probably going to make "enchant" take whatever parameters "inscribe" does

right now it's looking like that means a filename, probably

ireneista@irenes.space ("Irenes (many)") wrote:

or rather, we could hack around that but it would be horrifying.

ireneista@irenes.space ("Irenes (many)") wrote:

and that in turn means that, although "enchant" can take the actual data values if it wants to, "inscribe" always needs to be told where that data is defined so it can have the hex transform read it again.

ireneista@irenes.space ("Irenes (many)") wrote:

today we realized that that isn't quite sufficient. the two helper words can't simply be called from within the hex transform, they need to be properly inside it so that magic comments in them can be processed. that means we need to re-lex them, we can't just accept them as execution tokens.

ireneista@irenes.space ("Irenes (many)") wrote:

last night we figured out a mechanism whereby the "inscribe" helper can pass pointers into the code to be run under the hex transform.

we had to write some new basic output code because previously, we'd only been able to format integers to stdout, not to strings. it's good that we wrote that code, regardless, it was a longstanding TODO.

ireneista@irenes.space ("Irenes (many)") wrote:

a few days ago, we successfully got "enchant" (make a regular executable) working given that state. of course, "inscribe" was always going to be harder. (that's the thing that uses the hex transform, for those who follow our threads long-term...)

ireneista@irenes.space ("Irenes (many)") wrote:

last week, we figured out that the actual state needed to kick off the compilation process comes down to two lists of filenames, and two helper words that are called at the beginning and end

ireneista@irenes.space ("Irenes (many)") wrote:

we aren't implementing support for command-line parameters at this time, but we've been thinking ahead, all along, to what this sort of task might look like from a proper CLI (rather than relying on shell pipelines as we have been up to now)

ireneista@irenes.space ("Irenes (many)") wrote:

most of the challenge of this has been figuring out what the interface should be

ireneista@irenes.space ("Irenes (many)") wrote:

so in Evocation we've been attempting, for a couple days now, to factor out the actual calls that create an executable or a hex-dump of an executable into common infrastructure, letting the actual process of defining one be data-driven

Boosted by pixxl:
dansup ("Daniel Supernault") wrote:

RE: https://mastodon.social/@pixelfed/117350705262301318

Spread the word!

Boosted by stephen@social.calmabiding.me ("Stephen Castro-Starkey"):
mhamzahkhan@intahnet.co.uk ("M. Hamzah Khan") wrote:

Hey everyone. This is a post I didn’t really want to make, but I lost my job a couple of months ago and the market is quite brutal right now, so I’m turning to the Fediverse for help.

If you or anyone you know has any #DevOps positions - either #Remote or in #London, open to contract or perm - I would be very interested in hearing about them. I really like working with #Kubernetes, #Ansible, #Terraform, and #GitLab.

Any boosts are hugely appreciated. Thank you! #GetFediHired #FediJobs

Boosted by stephen@social.calmabiding.me ("Stephen Castro-Starkey"):
kimcrawley@stopgenai.org ("Kim Crawley 😷 (server owner) she/her") wrote:

Recovering After Gen Al: An open discussion

#NoAI

Share! 🎉 🎉

Free-of-charge Zoom event to promote upcoming book.

Microsoft document: "It is highly unusual that an end-product threatens the economic foundations of its essential suppliers, but that is the situation we have created of our LLM business in respect to its 'content supply chain.'"

Sunday October 4th, 2026

Register for free: https://t.ly/AfterAl