2023-05-05 00:01:12 <vms14       > unjust: what are you planning to do with that forth in js?
2023-05-05 00:01:54 <vms14       > decay: don't you have your own forth currently?
2023-05-05 00:02:02 <decay       > Not really.
2023-05-05 00:02:09 <vms14       > and not willing to?
2023-05-05 00:02:21 <decay       > I have many languages. I haven't found a favorite.
2023-05-05 00:02:40 <vms14       > I enjoy a lot making a toy language
2023-05-05 00:03:33 <decay       > I'm trying to find something I can just settle down in for a few years.
2023-05-05 00:03:43 <vms14       > and being able to implement my own language in any other language is a cool feature
2023-05-05 00:03:51 <decay       > I'm having... considerable difficulty.
2023-05-05 00:03:54 <vms14       > I can steal a lot of stuff
2023-05-05 00:05:39 <vms14       > for php makes more sense to make a transpiler
2023-05-05 00:05:42 <unjust      > vms14: not sure, draw on a canvas probably
2023-05-05 00:05:52 <vms14       > but I don't like it
2023-05-05 00:05:53 <unjust      > vms14: maybe generate svg
2023-05-05 00:06:08 <vms14       > unjust: I was going to start adding canvas bindings
2023-05-05 00:06:22 <vms14       > my goal is to make a simple game
2023-05-05 00:07:01 <vms14       > but wanted to make a todo app, as it's like the next program after a hello world
2023-05-05 00:08:59 <vms14       > I think my favourite lang has become my own language
2023-05-05 00:13:25 <unjust      > a few years ago, part of a customer information display system that i built had an in-browser feature that used a canvas element (plus javascript) to allow a user to generate an overlay definition (featuring dynamic text + graphics sourced from other data providers, in JSON) on top of a JPEG/PNG image
2023-05-05 00:13:56 <unjust      > it had a nice grid + vert/horiz line guidance system with auto-snapping
2023-05-05 00:14:26 <unjust      > i would like to recreate something similar without javascript getting in the way this time
2023-05-05 00:15:06 <vms14       > :0
2023-05-05 00:15:12 <vms14       > I want to see the code when you do it
2023-05-05 00:15:18 <vms14       > the code in your forth
2023-05-05 00:17:04 <unjust      > sure, if i ever get around to that, i'll show you
2023-05-05 00:17:10 <vms14       > :D
2023-05-05 00:21:02 <vms14       > decay: wouldn't a language implemented by you be enough to settle on?
2023-05-05 00:21:26 <vms14       > for example if you do like crc, making a vm, it would be quite portable
2023-05-05 00:21:35 <thrig       > not with that greener grass being right over there
2023-05-05 00:21:44 <vms14       > which means you can benefit from almost every language
2023-05-05 00:22:13 <vms14       > yeah and it's almost summer, there's a lot of bugs
2023-05-05 00:23:06 <decay       > vms14: I've implemented everything from tiny concatenative languages, to term rewriting languages that are suitable for hardware synthesis.
2023-05-05 00:23:37 <vms14       > so you can't decide on which kind of language to implement?
2023-05-05 00:23:56 <decay       > There are caveats with all of them. But I have a model that I'm happy with, I just need to put a method of programming into it.
2023-05-05 00:24:27 <vms14       > what are the caveats of concat langs more than stack juggling?
2023-05-05 00:24:54 <vms14       > I miss optional arguments, it forces me to use lists, but it's doable
2023-05-05 00:25:06 <decay       > My requirements are pretty strict, in that things as basic as numbers aren't included.
2023-05-05 00:25:48 <vms14       > do you have documentation on some of those langs?
2023-05-05 00:26:12 <decay       > The caveats of concatenative languages is that you have two flavors: you have languages like Joy, and languages like Forth. Forth always assumes some underlying machinery, and things need to "look" like a traditional von Neumann machine.
2023-05-05 00:26:39 <decay       > Joy is more symbolic, but you need quotations, which are more complex than you'd think.
2023-05-05 00:27:07 <decay       > So you have this duality between wanting to be symbolic, far away from a specific machine architecture, and being very close to a specific machine architecture.
2023-05-05 00:27:40 <decay       > There's a gradient between the two.
2023-05-05 00:28:17 <decay       > The same can be said for most languages/models of computation.
2023-05-05 00:28:37 <vms14       > my lang does not even know what the machine is
2023-05-05 00:28:49 <decay       > You either have machinery following an instruction graph or symbolic manipulation that warrants reduction steps.
2023-05-05 00:29:02 <decay       > I have not been happy with either.
2023-05-05 00:31:24 <decay       > I think I'm getting closer to what I want, though. I have a model that functions as a model of concurrency, a model of capabilities (security-wise) and a method of modeling mobile agents.
2023-05-05 00:31:43 <decay       > I just don't have a programming method for the agents.
2023-05-05 00:31:59 <xelxebar    > decay: That's really interesting. In a way, we could view both term rewriting and assembly are both languages implemented in their respective metalogics.
2023-05-05 00:32:32 <decay       > xelxebar: One's mind starts focusing on the modeling overhead of each method.
2023-05-05 00:32:48 <decay       > And it really comes out in something like sending a running program over the network.
2023-05-05 00:33:11 <decay       > If I wanted to lift a running program from my machine to another machine, _while it's running_, I need to transmit three things.
2023-05-05 00:33:34 <decay       > The memory that the program is using, the program memory that the program code exists in, and the program counter.
2023-05-05 00:34:16 <decay       > That's assuming a traditional VM. But, what happens if I change the model? Let's assume I have a bunch of term rewrite rules, with one large term as my program state.
2023-05-05 00:34:38 <decay       > The number of things I need to transmit, now, is just 2: the list of term rewrite rules, and the term under rewrite.
2023-05-05 00:34:52 <decay       > The state of the "program" is just the current term.
2023-05-05 00:35:56 <decay       > What if you go further, to something like Joy? I could send a quotation across a network after composing it with its required arguments, so that when it's evaluated, it "unpacks" itself and starts running. All of a sudden, the number of things I need to transmit drops to 1: the code I want to run.
2023-05-05 00:36:14 <decay       > The number of conceptual objects matters.
2023-05-05 00:36:38 <vms14       > yeah, but somehow giving the memory feels more powerful
2023-05-05 00:36:55 <vms14       > it could send a program while it's running
2023-05-05 00:37:02 <decay       > The latter two do the same thing.
2023-05-05 00:37:10 <vms14       > stopping before send, and resuming once it arrives on the other machine
2023-05-05 00:37:17 <decay       > That's.. what all of them do.
2023-05-05 00:37:45 <vms14       > giving code is not as giving the state of the whole program
2023-05-05 00:37:46 <xelxebar    > There are likely clear mechanical transformations between the different models, but I gather you're focusing more on the "conceptual weight". Is that true?
2023-05-05 00:38:10 <decay       > vms14: I'm not giving code. I'm giving code + state.
2023-05-05 00:38:23 <decay       > It turns out that in the latter two, you can start merging them.
2023-05-05 00:38:33 <vms14       > then it should be the same as with memory the code is part of the state itself
2023-05-05 00:38:33 <decay       > xelxebar: Yeah. Conceptual weight would be a good way to put it.
2023-05-05 00:38:46 <decay       > Because conceptual weight translates into implementation weight.
2023-05-05 00:40:07 <xelxebar    > Interesting. How base conceptual models impact downstream maintenance and dev costs is something I've been starting to cognate concretely about lately.
2023-05-05 00:40:49 <decay       > It becomes pretty expensive.
2023-05-05 00:41:12 <decay       > Even something as trivial as word size in a VM impacts things like algorithm complexity unless you stick with high word sizes.
2023-05-05 00:41:28 <vms14       > we are rich in resources
2023-05-05 00:41:38 <vms14       > is the only way I can be rich
2023-05-05 00:41:41 <decay       > We are gluttonous with resources and cannot plan for usage.
2023-05-05 00:41:56 <decay       > I want to know the concrete memory footprint of 20,000 agents, for example.
2023-05-05 00:42:13 <decay       > But I can't do that if the internal model of those agents includes dynamic memory allocation (implicit or explicit).
2023-05-05 00:42:33 <vms14       > agents as in the actor model?
2023-05-05 00:42:39 <decay       > No.
2023-05-05 00:43:00 <decay       > Running pieces of code that can interact with some surrounding environment via synchronous communication methods.
2023-05-05 00:44:08 <xelxebar    > APL is actually pretty nice in that regard. It affords static analysis of exact memory footprint down to the byte.
2023-05-05 00:45:49 <xelxebar    > Not just theoretically, even. It's something APLers actually end up doing in practice. I'm still don't grok the precise design decisions of APL as a programming language that manifest such a thing, though.
2023-05-05 00:47:07 <decay       > Resource planning also allows you to do things like run untrusted code.
2023-05-05 00:47:12 <decay       > From arbitrary sources.
2023-05-05 00:47:21 <decay       > If you know an agent takes, say, 32 bytes.
2023-05-05 00:47:38 <decay       > You can say that an assemblage of them coming from some network location is only allowed to be 300 agents wide.
2023-05-05 00:52:26 <xelxebar    > Trust models are certainly important, but that seems like a pretty orthogonal issue. Just as mutual cooperation in the prisoner's dilemma leads to better outcomes than defecting, defaulting to adversarial models incurs pretty high costs.
2023-05-05 00:53:56 <xelxebar    > In this case, giving hard upper bounds on memory usage is a much weaker guarantee than *also* having tight lower bounds as well.
2023-05-05 00:54:55 <decay       > Why?
2023-05-05 00:55:29 <decay       > The assumption that any code that runs on your machine will be malicious isn't exactly something divorced from reality.
2023-05-05 00:55:39 <decay       > Especially if you accept it from any source.
2023-05-05 01:08:59 <xelxebar    > Depends on what you're doing. I'm imagining that you're designing a language with concurrent agents. Building in adversarial semantics means that I have to pay the cost of guardrails even in cases where I'm the one controlling all agents.
2023-05-05 01:09:56 <xelxebar    > Within-aplication agents usually go out of their way to cooperate, and we only need to cordon off specific ones, like those that handle user input or whatever.
2023-05-05 01:10:23 <xelxebar    > That is, unless your threat model is really hard, and you want to be extremely cautious :D
2023-05-05 01:12:13 <xelxebar    > Anyway, I'm just making a descriptive statement, not a normative one. Adversarial agents cost more overhead than cooperative ones. It makes sense to ask when and where you want to spend that cost.
2023-05-05 08:48:15 <veltas      > This is a great read about TCL https://yosefk.com/blog/i-cant-believe-im-praising-tcl.html
2023-05-05 08:48:39 <veltas      > And it's about how useful it can be with embedded work, and I think that a lot of what's praised here applies to Forth as well
2023-05-05 08:50:28 <drakonis    > and later thishttps://yosefk.com/blog/my-history-with-forth-stack-machines.html
2023-05-05 08:50:30 <drakonis    > also
2023-05-05 08:50:45 <drakonis    > i think it was here that tclforth got linked, right?
2023-05-05 08:52:21 <veltas      > Well I seem to remember he doesn't like Forth
2023-05-05 08:53:08 <veltas      > My point in linking the article is just that it helps illuminate slightly why languages like Forth and Tcl have good syntax/features for something interactive
2023-05-05 08:53:26 <drakonis    > aye
2023-05-05 08:55:12 <veltas      > Also they were wondering how to achieve something as 'nice' in an infix language, well Haskell didn't get mentioned. I think Haskell's syntax is a good effort at removing unncessary commas and parentheses
2023-05-05 08:55:39 <veltas      > From a language with more strong syntax, rather than just shell-style "everything is a string" syntax
2023-05-05 08:58:40 <unjust      > drakonis: yes, i think someone linked to https://github.com/wejgaard/TclForth
2023-05-05 09:00:10 <unjust      > the Expect library for TCL is an underappreciated tool for automation
2023-05-05 09:01:04 <unjust      > the TclForth creator's Holon* projects are pretty interesting
2023-05-05 09:01:28 <drakonis    > surprisingly smalltalk-ish
2023-05-05 09:30:05 <thrig       > TCL: what if a shell was bitten by a radioactive lisp
2023-05-05 09:31:23 <KipIngram   > Ugh.  Controversy in the reddit community I help moderate.
2023-05-05 09:31:57 <KipIngram   > A couple of folks posted AI generated arwork, in the "Fan Art" category.  They got reported for copyright violation, and now there's a big stew brewing about the issue in general.
2023-05-05 09:32:20 <drakonis    > which one?
2023-05-05 09:32:30 <KipIngram   > On the grounds that those engines scrape existing artwork online, and thus violate the rights of the creators of that art.
2023-05-05 09:32:48 <thrig       > notice how the little people get the copyright violation notices, not le googles
2023-05-05 09:32:48 <KipIngram   > Midjourney on the first one.  Different engine on the second.
2023-05-05 09:33:04 <KipIngram   > Yeah.
2023-05-05 09:33:24 <KipIngram   > Well, no one is arguing that punitive action should be taken against the people that produced the images.
2023-05-05 09:33:37 <KipIngram   > The critics just want us to ban AI art from the community.
2023-05-05 09:34:10 <KipIngram   > It's an issue I'd just never previousl given any thought to.
2023-05-05 09:34:25 <KipIngram   > I actually didn't even know Midjourney existed until this came up.
2023-05-05 09:34:26 <drakonis    > its not /r/art, is it?
2023-05-05 09:34:48 <KipIngram   > No, it's /r/dresdenfiles.  Aimed at a particular urban fantasy series.
2023-05-05 09:34:52 <drakonis    > ah yes.
2023-05-05 09:35:18 <drakonis    > AI art has interesting consequences such as ending the trade of being an artist
2023-05-05 09:35:25 <KipIngram   > It's not an activity I'd have expected to find myself engaged in before I started, but I've had a good time helping out.
2023-05-05 09:35:28 <unjust      > that's just an AI bot being a great artist, isn't it? stealing instead of copying?
2023-05-05 09:35:29 <drakonis    > (its a really bad consequence)
2023-05-05 09:35:39 <KipIngram   > Yeah, it's a thorny issue for sure.
2023-05-05 09:35:53 <KipIngram   > And is going to be a lot more widespread than just art in the long run.
2023-05-05 09:37:29 <unjust      > i doubt AI art is going to kill human (or other lifeform?) rendered art, there'll always be people who want to support other people in creative endeavours
2023-05-05 09:38:17 <drakonis    > the consequence is that less people commission art because of it
2023-05-05 09:38:51 <drakonis    > why pay someone when you can feed the AI what you want until you get the desirable results
2023-05-05 09:39:01 <thrig       > creative endeavours... how's that going... https://www.eff.org/deeplinks/2023/01/have-you-tried-turning-it-and-again-rethinking-tech-regulation-and-creative-labor#main-content
2023-05-05 09:39:19 <unjust      > the advent of photograpy had the same effect, it didn't kill off the portrait and landscape artists altogether
2023-05-05 09:39:38 <KipIngram   > Sure.  PowerPoint did it to some fraction of the "graphic artist" biz.
2023-05-05 09:40:45 <KipIngram   > Lot of technology has had this sort of effect.  Early in the industrial revolution people would sabatage machinery because they felt like it destroyed jobs (which it did).
2023-05-05 09:42:01 <thrig       > a) work 14 hour days in factory b) starve to death
2023-05-05 09:42:07 <unjust      > things evolve and people adapt, new vocations appear to fill the void inevitably
2023-05-05 09:44:49 <drakonis    > yes, though you have horrid things like hollywood execs wanting to use chatgpt to generate scripts
2023-05-05 09:44:50 <KipIngram   > That's the hoped for result, yes.  I'm not sure it's an inexhaustible resource, though.
2023-05-05 09:45:05 <drakonis    > because the writer's guild is on strike
2023-05-05 09:47:42 <unjust      > if they blindly rely on the output of artificial intelligence, i'd agree that's pretty terrible. but what if they use it as augmented intelligence instead and edit/extend/redact the generated script to their liking?
2023-05-05 09:47:42 <drakonis    > the difference between the industrial revolution and AI is that AI replaces an inherently creative endeavor
2023-05-05 09:49:02 <drakonis    > the machines sped up repetitive work during the industrial revolution
2023-05-05 09:50:21 <drakonis    > it was less safe yet you still needed underpaid humans to operate the machines
2023-05-05 09:50:25 <decay       > AI as it stands is just a fuzzy search over a corpus. It can't replace creative endeavors, only regurgitate and mix the end results of creativity and hand that mixture back to you.
2023-05-05 09:51:14 <drakonis    > exactly that
2023-05-05 09:51:51 <drakonis    > it is inherently dependent on existing human creations to output its data
2023-05-05 09:52:14 <decay       > The only "surprise" is that the granularity got better. Take voice generation for example.
2023-05-05 09:52:41 <decay       > Given a sentence, and a person's voice profile, generate an audio file of the person saying the sentence.
2023-05-05 09:52:42 <drakonis    > if it somehow managed to make it impossible to live off art, it would have less data to work off
2023-05-05 09:52:44 <KipIngram   > Well, you might argue that the industrial revolution replaced "inherently skilled" labor.
2023-05-05 09:52:50 <drakonis    > it did not
2023-05-05 09:52:56 <KipIngram   > I'm not sure the nature of the ability makes a lot of difference.
2023-05-05 09:53:29 <decay       > At one point we relied on, essentially, sentence mixing by picking out words from the chunks of audio of that person.
2023-05-05 09:53:45 <decay       > And stitching them together and applying postprocessing to them.
2023-05-05 09:53:50 <KipIngram   > Yeah, I've heard of people using AI to generate voices, which they then use to contact someone's parents and ask for emergency money to be sent.
2023-05-05 09:53:52 <decay       > To make one word flow into the next. It sucks.
2023-05-05 09:53:59 <KipIngram   > My wife read about it in an article a week ago or so.
2023-05-05 09:54:36 <decay       > Flash forward a couple of years, it got more granular: instead of vowels, you can now do it with phonemes.
2023-05-05 09:54:40 <KipIngram   > I figure we'll get to the point where photographic evidence is no good in court anymore.
2023-05-05 09:55:00 <decay       > Courts have provenance, that hasn't changed.
2023-05-05 09:55:16 <decay       > Chain of custody of evidence always will be a thing. The photographic evidence had to come from somewhere.
2023-05-05 09:55:40 <unjust      > just wait, someone will try and sell the idea of an AI judge + jury
2023-05-05 09:55:41 <decay       > But, on voices, now we've gone from phonemes to sub-phoneme construction. The only thing that's improved over that span of time is granularity.
2023-05-05 09:55:42 <KipIngram   > Well, but take security camera footage or something.  Yes, it's in a chain of custody after it's first secured.
2023-05-05 09:55:48 <KipIngram   > But there's no telling where it came from.
2023-05-05 09:56:42 <KipIngram   > unjust: At least one state is already using AI to determine criminal sentences.
2023-05-05 09:56:52 <decay       > There are nuances that make that less likely. For one, security camera footage comes from security cameras. So there are audit logs, access logs, etc.
2023-05-05 09:57:05 <thrig       > don't need AI for that. poor? throw 'em in jail
2023-05-05 09:57:06 <KipIngram   > And when a defense attorney requested to study the source code, the request was denied.
2023-05-05 09:57:17 <decay       > If someone had that level of control over a security system and had enough training data to fake footage, they wouldn't even need AI.
2023-05-05 09:57:20 <unjust      > KipIngram: sentence duration only?
2023-05-05 09:57:33 <KipIngram   > I don't know that detail.
2023-05-05 09:57:49 <KipIngram   > It was somewhere up in the farm belt - been a couple of years since I read about it.
2023-05-05 10:12:33 <thrig       > actually with AI you might get rid of the competent judges and replace them with kowtowing flunkies
2023-05-05 10:12:56 <drakonis    > oh yes.
2023-05-05 10:13:00 <drakonis    > lots of potential for abuse
2023-05-05 10:13:16 <drakonis    > https://twitter.com/AlexBlechman/status/1457842724128833538
2023-05-05 10:13:25 <drakonis    > an evergreen tweet
2023-05-05 10:14:06 <KipIngram   > It's the kind of thing I would have just never believed would even be considered earlier in my life.
2023-05-05 10:14:43 <KipIngram   > But new generations come along and just don't have the same "core principles."
2023-05-05 10:14:47 <decay       > thrig: ...you mean like the thing that's already happening? :P
2023-05-05 10:15:45 <thrig       > shush!
2023-05-05 10:16:11 <decay       > KipIngram: What do you mean by "core principals"?
2023-05-05 10:16:12 <thrig       > this is some, uh, hypothetical future dystopia we would never be so foolish to dabble with
2023-05-05 10:16:38 <decay       > Or, rather, what principals are you talking about specifically.
2023-05-05 10:17:09 <KipIngram   > Um, well, just things that we'd fundamentally not want to give up, like the right to trial by jury of our peers.  AIs wouldn't be our peers.
2023-05-05 10:17:39 <decay       > I'm pretty sure nobody wants to be tried by an AI...
2023-05-05 10:17:55 <decay       > Intergenerationally.
2023-05-05 10:17:59 <KipIngram   > Back some years ago I saw some girl in a news interview.  No one particular, just a "face on the street."  And she actually said outright "This freedom of speech thing has got to go."
2023-05-05 10:18:08 <KipIngram   > I nearly fell out of my chair.
2023-05-05 10:18:16 <decay       > And, how old was that girl. :P
2023-05-05 10:18:24 <KipIngram   > Oh, young, but voting age.
2023-05-05 10:18:29 <decay       > Young as in..
2023-05-05 10:18:37 <KipIngram   > That's what I mean about new generations coming along.
2023-05-05 10:18:44 <KipIngram   > Twenty?
2023-05-05 10:18:58 <decay       > And some years ago would be, what, a decade? 5 years?
2023-05-05 10:19:04 <KipIngram   > 6-7.
2023-05-05 10:19:14 <decay       > Well, 7 years ago, I was 20.
2023-05-05 10:19:23 <decay       > I'm pretty sure it's not a generational thing.
2023-05-05 10:20:08 <KipIngram   > Fair enough - I wouldn't want to imply that it's a universal thing.  And I'm sure you could have found someone much earlier.  But it was just a shocking thing to hear on the news.
2023-05-05 10:20:10 <decay       > 7 years ago was 2016, which was just the beginning of the social erosion of our country.
2023-05-05 10:20:13 <KipIngram   > Of course, "shock" is what they go for.
2023-05-05 10:20:49 <KipIngram   > That's a separate problem - the tendency of the news to focus on sensation instead of "best truth."
2023-05-05 10:20:57 <decay       > If you ever want to understand Russia's actions on the world stage... https://en.wikipedia.org/wiki/Foundations_of_Geopolitics#Content
2023-05-05 10:21:05 <KipIngram   > There's always been yellow journalism.
2023-05-05 10:21:11 <KipIngram   > But these days it's practically all yellow.
2023-05-05 10:21:39 <KipIngram   > And I've watched that happen during my life.
2023-05-05 10:21:54 <decay       > I'd call it green journalism, as in the color of money. And the Russians pay well.
2023-05-05 10:22:35 <decay       > Anything profit driven will optimize itself for the largest market share.
2023-05-05 10:22:40 <KipIngram   > That's fair too - yellow is just a euphemism that's been around for a long time.
2023-05-05 10:22:49 <KipIngram   > But yeah, money is part of it too.
2023-05-05 10:23:01 <KipIngram   > I mean, they go yellow because they decide that makes more money.
2023-05-05 10:23:08 <decay       > I'd say money is the only driving factor. Shock value means attackment.
2023-05-05 10:23:11 <decay       > *attachment
2023-05-05 10:23:30 <decay       > It taps into the cyclical expectation-reward system.
2023-05-05 10:23:44 <KipIngram   > I'm willing to believe that money is the ultimate root cause.
2023-05-05 10:23:59 <decay       > If you can deliver shock value that's ideologically pleasing to the reader, you have a hooked market.
2023-05-05 10:24:03 <KipIngram   > Yellow journalism is a "behavior."  And probably motivated by money.
2023-05-05 10:24:16 <decay       > Hence, Fox, Newsmax...
2023-05-05 10:24:26 <KipIngram   > And so on.
2023-05-05 10:24:36 <KipIngram   > I don't know one that remains immune to this.
2023-05-05 10:24:42 <KipIngram   > No big one, at least.
2023-05-05 10:24:47 <decay       > Agreed.
2023-05-05 10:25:01 <KipIngram   > My wife thinks the Wall Street Journal is better than most.
2023-05-05 10:25:10 <KipIngram   > But I haven't read it, so I don't have an opinion there.
2023-05-05 10:25:25 <decay       > The fact that it's incentivized even at the lower levels, i.e on individual reporters to find a "scoop" (which is a trope that's been around for longer than either of us), is a problem.
2023-05-05 10:25:34 <KipIngram   > Yes.
2023-05-05 10:25:49 <decay       > But that's a symptoms of seeking markets.
2023-05-05 10:25:53 <decay       > *symptom
2023-05-05 10:25:59 <decay       > fingers, brain, get together and figure it oout
2023-05-05 10:26:03 <KipIngram   > I think the internet and "deep conversation" podcasts and so on are our best option these days, but you can't consume just one.
2023-05-05 10:26:04 <decay       > *out, damnit.
2023-05-05 10:26:12 <KipIngram   > You need to consume a bunch of them, across the spectrum.
2023-05-05 10:26:17 <KipIngram   > And then think about things yourself.
2023-05-05 10:26:34 <decay       > I would really rather we just report things that happened rather than also offering accessory perspective.
2023-05-05 10:26:42 <decay       > The Fairness Doctrine needs to come back.
2023-05-05 10:26:50 <KipIngram   > Would suit me.
2023-05-05 10:27:34 <nmz         > I did find a news website that was just data, graphs and so on
2023-05-05 10:27:37 <KipIngram   > When I was in college I made a point to watch the NBC news every evening.  Just to keep up with the world.  As the years went by that became a waste of time.
2023-05-05 10:27:56 <decay       > What year?
2023-05-05 10:27:59 <decay       > Or, rather, years.
2023-05-05 10:28:09 <KipIngram   > I've given thought to writing my own "AI" news scraper.
2023-05-05 10:28:20 <decay       > I'm imagining you weren't in college during the Reagan years.
2023-05-05 10:28:22 <KipIngram   > Just to gather multiple sources up into one place.
2023-05-05 10:28:29 <decay       > Or post-Reagan.
2023-05-05 10:28:39 <KipIngram   > I was, in fact.
2023-05-05 10:28:44 <KipIngram   > 1981-1985.
2023-05-05 10:28:46 <nmz         > like https://ground.news ?
2023-05-05 10:28:53 <decay       > ooooo just before it got revoked.
2023-05-05 10:29:15 <decay       > 1987.
2023-05-05 10:29:20 <nmz         > sorry for butting into the conversation
2023-05-05 10:29:26 <KipIngram   > That sounds about right.
2023-05-05 10:29:38 <KipIngram   > nmz: No problem, man, it's not like we're on topic or anything here.
2023-05-05 10:29:40 <nmz         > 1440 is also a sort of aggregator or news scraper
2023-05-05 10:30:03 <KipIngram   > Part of that desire is just to try my hand at that kind of AI.
2023-05-05 10:30:09 <KipIngram   > "DIY" mentality.
2023-05-05 10:30:21 <KipIngram   > Plus I'd run it in console.
2023-05-05 10:31:57 <nmz         > someone made a summary AI thing but they charge for the API
2023-05-05 10:45:59 <unjust      > would be great if you could slap [citation needed] on most of the news out there
2023-05-05 10:46:55 <thrig       > or ignore it, as it's mostly shocking and/or depressing
2023-05-05 10:47:37 <unjust      > i'd bet there'd be less garbage out there, if (for the most part) the journalists had to divulge the sources of their info
2023-05-05 10:48:54 <KipIngram   > Probably, but there are downsides of that too - it would be a tradeoff.
2023-05-05 10:57:25 <KipIngram   > So, I'm running a drive test at the moment that uses 2.85:1 compressible data - I write enough of it to fill the drive 50% full physically.
2023-05-05 10:57:37 <KipIngram   > Normally I format before such tests, but I forgot this time.
2023-05-05 10:57:56 <KipIngram   > It's not really a problem - the previous data on the drive also filled 50% of it and was 1:1; it will all get overwritten.
2023-05-05 10:58:07 <KipIngram   > But it is kind of interesting to watch the fill percentage as this happens.
2023-05-05 10:58:26 <KipIngram   > It goes down from 50% at first, as some of the 1:1 data is overwritten with 2.85:1 data.
2023-05-05 10:58:44 <KipIngram   > It will go down for a while and then start going back up, and will go back to 50% in the end.
2023-05-05 10:59:33 <decay       > I've often wondered why we don't have drives that have hardware compression.
2023-05-05 10:59:52 <KipIngram   > This drive does.
2023-05-05 11:00:05 <decay       > ...
2023-05-05 11:00:08 <decay       > show me
2023-05-05 11:00:14 <thrig       > I know kung-fu!
2023-05-05 11:00:29 <decay       > LOL.
2023-05-05 11:00:36 <KipIngram   > https://www.ibm.com/docs/en/flashsystem-9x00/8.2.x?topic=overview-flashcore-modules
2023-05-05 11:01:13 <KipIngram   > The biggest one holds 38.4 TB physical.  You could put 100 TB or so of English text on it.  Palm of your hand.
2023-05-05 11:01:47 <decay       > Jesus.
2023-05-05 11:01:56 <KipIngram   > Yeah, it's pretty impressive.
2023-05-05 11:02:12 <decay       > What kind of algorithm do they use?
2023-05-05 11:02:13 <KipIngram   > We don't sell it standalone - we put it in rackmount products that we build.
2023-05-05 11:02:19 <KipIngram   > You can get a box with 48 of them.
2023-05-05 11:02:24 <KipIngram   > 2U rack box.
2023-05-05 11:02:26 <decay       > I keep forgetting you work at IBM.
2023-05-05 11:02:46 <decay       > Does it compress at rest or compress in-stream?
2023-05-05 11:02:55 <KipIngram   > On the fly.
2023-05-05 11:03:04 <decay       > Damn.
2023-05-05 11:03:13 <decay       > I'm even more interested in the algorithm.
2023-05-05 11:04:18 <KipIngram   > I don't "know it" to any extent.  I can ask about it and see what aspects of it might be sharable.
2023-05-05 11:04:52 <KipIngram   > I'm even more impressed with the error detection and correction hardware, though.
2023-05-05 11:05:10 <KipIngram   > This QLC flash is crap - it develops bit errors over time just sitting there.
2023-05-05 11:05:39 <KipIngram   > But we have a background process running that scans through all the written data (takes a week or two to get to all of it), reads each page and counts the errors.
2023-05-05 11:05:54 <KipIngram   > When that rises above a certain threshold, we re-write that page to a new location.
2023-05-05 11:06:03 <KipIngram   > Sets the error count back to zero.
2023-05-05 11:06:16 <KipIngram   > We don't let pages accumulate more errors than the algorithm can correct.
2023-05-05 11:06:43 <KipIngram   > So you can't turn these boxes off and walk away for a month or anything like that - they need to be running all the time.
2023-05-05 11:07:19 <decay       > Gross.
2023-05-05 11:07:20 <KipIngram   > When a page starts developing errors at too high a rate, we retire it.
2023-05-05 11:07:30 <decay       > We're just moving to battery backed SRAM by the day. :P
2023-05-05 11:07:34 <KipIngram   > Yeah, sometimes I describe it by saying that we make armor out of tissue paper and spit.
2023-05-05 11:07:57 <KipIngram   > We start with this problematic flash substrate, and wind up with enterprise grade data storage.
2023-05-05 11:08:09 <thrig       > actually paper/glue armor is pretty good
2023-05-05 11:08:13 <KipIngram   > It is actually fun work.  Not that I actually do the development work.
2023-05-05 11:08:27 <decay       > I can imagine! I wouldn't wanna use it, but the work itself sounds fun as hell.
2023-05-05 11:08:35 <thrig       > (or can be pretty good, if you do it right)
2023-05-05 11:08:44 <KipIngram   > I do performance testing, which involves enough "understanding" of the innards that I'm able to keep my developer pallete wet enough.
2023-05-05 11:08:46 <KipIngram   > Most of the time.
2023-05-05 11:09:08 <KipIngram   > It's like all this stuff has its own laws of physics.
2023-05-05 11:09:25 <decay       > It really does.
2023-05-05 11:09:43 <KipIngram   > I'd like to make my own flash-based storage box one of these days.
2023-05-05 11:10:19 <KipIngram   > It would never be something I could sell, though, because I'd build things into infringed, most likely.
2023-05-05 11:10:24 <KipIngram   > into it
2023-05-05 11:10:30 <KipIngram   > into it that
2023-05-05 11:10:31 <KipIngram   > Ugh.
2023-05-05 11:10:57 <KipIngram   > fingers are lagging behind my brain this morning.
2023-05-05 11:11:57 <KipIngram   > Anyway, I talk at times with the guy that does the error detection and correction FPGA.  Really fancy stuff, involving polynomial fields and so on.
2023-05-05 11:12:26 <decay       > Oh hell yeah.
2023-05-05 11:12:46 <KipIngram   > I'll definitely see if I can at least find out what general family of compression algorithms we draw from.
2023-05-05 11:12:54 <KipIngram   > I'm sure it "starts out" as something well known.
2023-05-05 11:13:09 <decay       > With minor touches being added in, I'm sure. ;)
2023-05-05 11:13:24 <KipIngram   > Yeah, which I probably won't even get to know about.  :-)
2023-05-05 11:13:29 <KipIngram   > The "secret sauce."
2023-05-05 11:13:56 <decay       > I wonder, given the battery technologies we have now, if it'd be possible to build a battery-backed SRAM drive.
2023-05-05 11:14:03 <KipIngram   > We're not the fastest drive on the block.  Samsung makes drives that outrun us by a fair margin.  But they're much lower capacity.
2023-05-05 11:14:05 <decay       > With similar capacities.
2023-05-05 11:14:25 <KipIngram   > There is some kind of drive that is basically that.
2023-05-05 11:14:35 <KipIngram   > I'm trying to think of the algorithm.
2023-05-05 11:14:56 <KipIngram   > And part of what our box level software does is let you mix a few of those in with the flash drives, and it runs a "tiered" storage system on all that.
2023-05-05 11:15:03 <KipIngram   > Keeping the hot data in the faster drives.
2023-05-05 11:15:10 <decay       > Smart!
2023-05-05 11:15:27 <KipIngram   > That's mostly what these boxes are - a big bag of small smart things.
2023-05-05 11:16:02 <KipIngram   > Then some additional caching is done with ram directly in the box, rather than packaged as drives.  Even faster.
2023-05-05 11:16:08 <KipIngram   > But still less capacity.
2023-05-05 11:16:24 <decay       > I was wondering if there was a hot RAM cache.
2023-05-05 11:16:42 <KipIngram   > Yeah, but my work doesn't expose me to the box level.
2023-05-05 11:16:47 <KipIngram   > I do single-drive testing.
2023-05-05 11:17:46 <KipIngram   > So I put drives in a Linux host, and run open source storage testing tools.
2023-05-05 11:18:12 <KipIngram   > I don't use the Linux nvme driver, though - I replace it with a third party thing from Intel that has a lot less overhead.
2023-05-05 11:18:57 <KipIngram   > I'm not really interested in that overhead at all, so the lower I can make it the better.
2023-05-05 11:20:00 <KipIngram   > A few years ago there was a bit of a flap because my single-drive performance numbers were coming in 10% or so higher than the single drive performance "extracted" from system level tests.
2023-05-05 11:20:22 <KipIngram   > And some big shots started watching and wanted to know why we weren't getting my measured performance in the system.
2023-05-05 11:20:45 <KipIngram   > Turned out it's because I only run one CPU thread per PCI port - that thread doesn't have to contend for it.
2023-05-05 11:20:55 <KipIngram   > The system runs a whole bunch of threads, and they have to share.
2023-05-05 11:21:09 <KipIngram   > Once I did a test to emulate that setup, I measured the same thing they did.
2023-05-05 11:21:24 <decay       > Bahahahaha.
2023-05-05 11:21:30 <KipIngram   > But the system is trying to run 48 drives, not just one.
2023-05-05 11:21:47 <KipIngram   > So it pretty much has to use all the cores and they have to share all the drives - there's really no way around it.
2023-05-05 11:22:24 <decay       > Yeah, you're going to get some contention unless you straight up have a 48 core+ CPU..
2023-05-05 11:22:43 <KipIngram   > But we at least came to understand the difference - that was good enough for the big shots.
2023-05-05 11:57:25 <jgaz        > Is there a forth word to flush (drop) the entire stack?
2023-05-05 11:57:47 <thrig       > bye
2023-05-05 11:58:27 <jgaz        > I mean without exiting
2023-05-05 11:58:33 <thrig       > details, details
2023-05-05 11:58:36 <jgaz        > heh
2023-05-05 11:59:09 <thrig       > : empty     BEGIN DEPTH 0> WHILE DROP REPEAT ;
2023-05-05 11:59:15 <thrig       > is what I have in my pforth.fs
2023-05-05 11:59:20 <jgaz        > k, thanks
2023-05-05 12:04:52 <unjust      > there's CLEARSTACK too in some forths
2023-05-05 12:17:58 <KipIngram   > sp0 @ sp!
2023-05-05 12:18:24 <KipIngram   > If your Forth is written that way.
2023-05-05 12:20:11 <thrig       > ANS aside, there's a lot of unportability
2023-05-05 12:21:21 <KipIngram   > Possibly.  But that's not as far out in left field as the number format stuff I was talking about yesterday, which I cooked up from scratch.
2023-05-05 12:21:42 <KipIngram   > Well, it was suggested to me by a friend.  But I'd never seen it in a Forth previously.
2023-05-05 12:23:43 <KipIngram   > That stack stuff I have, and I've also seen it in some books.
2023-05-05 12:23:55 <KipIngram   > I think it may be of FIG origins.
2023-05-05 12:32:53 <KipIngram   > Anyway, it has the virtue of being the simplest way to do it.
2023-05-05 12:59:59 <KipIngram   > I'm torn over whether to store a thread's register values, when it's not running, on its data stack or in some system buffer.  I want to think it doesn't really matter much either way.
2023-05-05 13:00:07 <KipIngram   > But I'm not quite sure of that yet.
2023-05-05 13:00:38 <thrig       > we are the registers of christmas past!
2023-05-05 13:02:18 <KipIngram   > If I keep them on the stack, then every thread's stack space will have to be sufficient to hold that, in addition to whatever the thread has on the stack.  But that space has to be somewhere, so why not there?
2023-05-05 13:03:13 <KipIngram   > I suppose you could argue that the thread could use that space for itself, so long as it didn't let that condition persist across a thread swap.
2023-05-05 13:03:24 <KipIngram   > But having the thread be aware of that has its own yuck.
2023-05-05 13:04:18 <KipIngram   > Ok, my drive just finished overwriting all the 1:1 data - the fill state has started to move back up.
2023-05-05 13:04:43 <KipIngram   > It pulled down from 50% to 35.5%, and now has turned around and is headed back up about twice as fast.
2023-05-05 13:05:00 <KipIngram   > On the way down there was a one step up, two steps down thing going on, and now it's two steps up.
2023-05-05 13:05:47 <KipIngram   > Because the drive has two data connections, and one of those connections was laying down new data on unwritten resources right from the start - it was just the other one that was overwriting previously written 1:1 data.
2023-05-05 13:06:09 <KipIngram   > Took me a while to figure out when I expected it to turn around, but I did have the right answer before it turned.
2023-05-05 13:18:25 <KipIngram   > I also want to give these threads a mechanism for communicating with one another - I'm thinking along the lines of those "synchronous communicating processes" laid out in that Rob Pike paper we discussed a few months ago.
2023-05-05 13:18:35 <KipIngram   > Have to also decide how to implement that.
2023-05-05 13:19:10 <KipIngram   > Simplest way may be to just endow message pipes with names, and let threads connect to them that way.
2023-05-05 13:19:44 <KipIngram   > But I want that mechanism to support not just sending and receiving information, but also thread synchronization.
2023-05-05 14:03:31 <decay       > The simplest way to do this is, effectively, a lock with some additional metadata.
2023-05-05 14:03:59 <decay       > Synchronous communication means one thread is stuck in `send` until another thread executes `receive`.
2023-05-05 14:04:43 <decay       > `send` plops down a datum, `receive` grabs that datum and clears the comm channel.
2023-05-05 14:05:15 <KipIngram   > Yes.
2023-05-05 14:05:54 <KipIngram   > Pike's paper was good - it seems like a good model for parallelizing certain things.
2023-05-05 14:06:24 <decay       > He definitely didn't invent synchronous comms, but came up with a calculus that used synchronous comms.
2023-05-05 14:08:31 <KipIngram   > Yeah, it just happened to be his paper I read.  He didn't claim it was his idea - he was more just "promoting it."
2023-05-05 14:08:39 <decay       > That's one of the things I really dislike about the "actor model": liveness assertions become really, really difficult to ascertain when you allow for asynchronous, unbounded comms.
2023-05-05 14:09:01 <decay       > Whereas with synchronous comms you can effectively just use TLA or some other temporal logic.
2023-05-05 14:09:27 <decay       > You always know the threads that'll be alive at some point, because they're just communicating state machines.
2023-05-05 14:10:27 <decay       > So if they're in a state that they can only exit via some `send` or `receive`, you know they're dead unless another thread is in the same state, communicating over the same port.
2023-05-05 14:12:24 <vms14       > what kind of conventions do you follow on your word names?
2023-05-05 14:13:10 <KipIngram   > Yes, and the resources that you need for a synchronous pipe are lower.  It's either got something in it or it doesn't.  You don't need a big buffer like you'd need for asynchronous ones.
2023-05-05 14:13:14 <vms14       > for example I append a * to indicate an alternative version of a word, which usually operates in a different way or taks different arguments
2023-05-05 14:14:02 <vms14       > I append a ~ to indicate a version of a word that does not return some value
2023-05-05 14:14:04 <KipIngram   > A common relationship you see is foo and (foo) where (foo) winds up being called by foo and performs the real work except accepts an additional parameter.
2023-05-05 14:14:15 <vms14       > like a drop after the word
2023-05-05 14:14:41 <KipIngram   > Like we were talking about numeric base yesterday, and I mentioned (.) which is basically . but with a base parameter, so that you wind up with : .  10 (.) ;
2023-05-05 14:14:50 <decay       > KipIngram: Exactly. Annd if you wanted to, you could chain together multiple synchronous pipes to form a queue, where the element at the end, on completion of a `send` to some output port (to the thing using the queued elements), executes a `receive` on a port from the prior element.
2023-05-05 14:15:11 <KipIngram   > Yeah.
2023-05-05 14:15:11 <decay       > (This is very effective in asynchronous logic.)
2023-05-05 14:15:28 <decay       > Asynchronous/clockless.
2023-05-05 14:15:43 <KipIngram   > I always liked asynchronous logic, but the old saw about it being easy to get yourself in trouble is certainly true.
2023-05-05 14:15:56 <KipIngram   > But sometimes it can solve problems that synchronous logic can't.
2023-05-05 14:16:12 <decay       > I forget which class of async logic is TC but I don't think QDI is.
2023-05-05 14:17:22 <vms14       >    : >+++:)  ." I'm a skeletal fish, indicating something fishy here." ;
2023-05-05 14:17:23 <vms14       > hahaha
2023-05-05 14:17:28 <vms14       > https://www.taygeta.com/forth_intro/ellipses.htm
2023-05-05 14:18:02 <vms14       > https://github.com/ForthHub/discussion/issues/73
2023-05-05 14:22:30 <vms14       > perl -pne 's/foo/oh/ig'
2023-05-05 14:23:16 <vms14       > https://termbin.com/tbwhf
2023-05-05 14:27:22 <crc         > http://forth.works/demo/ (now loading default image & blocks from server, blocks are cached in ram and can be downloaded/uploaded again)
2023-05-05 14:28:02 <thrig       > mixing -p and -n to perl doesn't make much sense
2023-05-05 14:29:36 <vms14       > yeah forgot p implies n
2023-05-05 14:30:11 <thrig       > not so much implication as they are the opposite of one another
2023-05-05 14:35:57 <vms14       > https://wiki.c2.com/?ForthObjects
2023-05-05 14:36:54 <vms14       > I assume most forthwrights despise objects, as they have a lot of ways to abstract stuff
2023-05-05 14:37:30 <vms14       > but I should add some syntax to create js objects
2023-05-05 14:37:43 <vms14       > as I see there, class could just create a package
2023-05-05 14:39:42 <vms14       > there's one oop system in forth you like?
2023-05-05 14:40:35 <thrig       > javascript required for "measured improvement in server performance" ... lol, wtf wiki.c2.com
2023-05-05 14:44:59 <veltas      > jgaz: The ANS forth word to drop the stack is ABORT , but that also quits out of any running function
2023-05-05 14:45:47 <veltas      > thrig's code looks like a safe way to achieve the same thing if you don't want to quit out of the currently running word
2023-05-05 14:57:46 <vms14       > crc I'm reading the manual
2023-05-05 14:57:48 <vms14       > it's cool
2023-05-05 15:00:42 <vms14       > crc how do you debug your programs in retro?
2023-05-05 15:01:01 <vms14       > when you have an error, what info does retro show you?
2023-05-05 15:01:49 <thrig       > ?
2023-05-05 15:03:54 <vms14       > https://www.reddit.com/r/Forth/comments/7hxgpb/debugging/
2023-05-05 15:05:17 <vms14       > oh there's a crc comment there
2023-05-05 15:05:28 <vms14       > I do have plans for a flexible debugger, but probably won't actually write it until sometime next year.
2023-05-05 15:05:39 <vms14       > crc that comment is 5 years old
2023-05-05 15:05:42 <vms14       > where's the debugger?
2023-05-05 15:08:07 <crc         > For RetroForth, it's mostly autospy (examples/autopsy.retro)
2023-05-05 15:10:35 <crc         > Next release of Retro will have more debugging support. It adds stack checks to the VM instructions, and I'm adding an i/o extension that will allow for running words on specific types of errors and getting more data on the location of errors.
2023-05-05 15:12:07 <vms14       > https://retroforth.org/examples/autopsy.retro.html
2023-05-05 15:12:47 <vms14       > does it make any sense to have unit tests in forth?
2023-05-05 15:13:35 <thrig       > yes? you can write bugs in your 3UP just as easily as in other languages
2023-05-05 15:16:35 <crc         > The unu format allows for test blocks, though I've not done an actual testing vocabulary yet
2023-05-05 15:17:05 <vms14       > yeah, but it's hard to imagine a forth dev using testing suites when they have tested every line of code they type
2023-05-05 15:17:34 <thrig       > have they?
2023-05-05 15:17:50 <decay       > They certainly have not.
2023-05-05 15:17:51 <vms14       > I assume a forth dev tests a word when is defined
2023-05-05 15:18:02 <decay       > That assumption isn't universal.
2023-05-05 15:18:28 <thrig       > and then you refactor and now what? where are the bugs you added?
2023-05-05 15:18:53 <vms14       > would you refactor a word and left it untested?
2023-05-05 15:19:00 <vms14       > leave*
2023-05-05 15:19:26 <unjust      > vms14: what if the words that the "tested" word depends on change their behaviour?
2023-05-05 15:19:34 <thrig       > it's silly not to have a test suite for easily tested things
2023-05-05 15:20:28 <vms14       > unjust: that only happens on my language, unless we talk about state
2023-05-05 15:21:47 <vms14       > https://users.ece.cmu.edu/~koopman/forth/koopman90a.pdf
2023-05-05 15:22:56 <unjust      > you can be a lot more confident about making changes and/or refactoring things when you have a decent test suite written for parts of your program, if it's written reasonably well you can just run it again once you've made any changes to confirm that you haven't broken anything
2023-05-05 15:23:23 <unjust      > well anything you considered important enough to write a test for, at least
2023-05-05 15:23:30 <crc         > vms14: I test code as I write it, but having tests is still beneficial.
2023-05-05 15:24:40 <vms14       > I want to see in how many ways I can improve debugging and a simple test suite looks like the first step
2023-05-05 15:24:42 <crc         > The (incomplete) tests I have written have found bugs introduced during later edits
2023-05-05 15:25:49 <vms14       > I'd like also to be able to tell the proper line of the source code when something happens
2023-05-05 15:26:16 <vms14       > but no idea on how to know the line of a loop
2023-05-05 15:26:54 <vms14       > well I need to add much more info to the interpreter
2023-05-05 15:28:06 <vms14       > when I make a program more complex than a hello world I have some troubles debugging
2023-05-05 15:29:05 <vms14       > I suppose I have to make extensive checking on all words, like checking the integrity of the values before using them
2023-05-05 15:30:09 <vms14       > for example words working with lists do not check if the element is a list
2023-05-05 15:32:28 <vms14       > an error/condition system is also interesting
2023-05-05 15:52:42 <KipIngram   > When Forth is interpreting, you have either typed a line of code at it or it is interpreting source code from a disk block.  It knows its offsset within that block at any given time; it advances a counter through there to move through the source.
2023-05-05 15:53:22 <KipIngram   > When an error occurs, it's not uncommon at all for Forth to tell you the block number and line number where the error popped up.  If you fancy things up it can even open that block up and put the cursor on the word that it last ran.
2023-05-05 15:54:41 <KipIngram   > It's harder when executing a compiled word.  *Normally* there is no information maintained at that level - it would have a large performance impact.  So usually this kind of debugging information only gets you to the last t hing *interpreted*, and where you are in the code that's triggered by that is something you then have to chase down by replicating the event and using debug prints or something to home in
2023-05-05 15:54:43 <KipIngram   > on the problem.
2023-05-05 15:55:52 <vms14       > I have last word and last atom executed and the error() function does tell its values
2023-05-05 15:56:08 <vms14       > also the error function when called can count lines until the source pointer to tell a line
2023-05-05 15:56:27 <vms14       > but usually that line has nothing to do with the place of the bug
2023-05-05 15:56:54 <vms14       > I also now have a "inside" error log, which tells if i'm inside colon words
2023-05-05 15:57:26 <vms14       > : oh ah ; : ah meh ; : meh error ;
2023-05-05 15:57:34 <vms14       > inside [ 'oh', 'ah', 'meh' ]
2023-05-05 15:58:23 <vms14       > but it's not too much
2023-05-05 15:58:38 <KipIngram   > I agree - the bug is usually down in the call tree of the interpreted word.
2023-05-05 15:58:57 <KipIngram   > You can't "wire in" tracing to that level without destroying your performance.
2023-05-05 15:59:14 <vms14       > yeah, that's why thinking in performance limits you a lot
2023-05-05 15:59:19 <KipIngram   > But you might be able to capture the call stack at the time of the error, and then studying that might tell you a lot.
2023-05-05 15:59:50 <KipIngram   > But a related problem is that where the bug causes a failure is often not related to what sowed the seed of that failure.
2023-05-05 15:59:54 <vms14       > I yet have to find the day I really need performance
2023-05-05 16:00:01 <KipIngram   > You have to develop an "understanding" of the whole failure mechanism.
2023-05-05 16:00:29 <KipIngram   > The Forth model offers a certain amount of performance, and I can't bring myself to willingly give it up.
2023-05-05 16:00:50 <vms14       > but for example thinking in performance, even without noticing, is why my words don't have checks
2023-05-05 16:01:00 <KipIngram   > The call stack analysis would be hugely informative, at least in terms of telling you the location of failure.
2023-05-05 16:01:22 <vms14       > it's why assume a word that expects a type of value, will receive that type of value
2023-05-05 16:01:32 <KipIngram   > Most Forths don't trap "runtime" errors, though - most of Forth's error handling stuff is around compile errors.
2023-05-05 16:01:56 <KipIngram   > I've written signal handling into mine to capture RAM address errors, divide by 0, and things like that.
2023-05-05 16:02:02 <vms14       > I try to say I don't want to care about performance, but I do without noticing
2023-05-05 16:02:05 <thrig       > bitmap(1) had a bug where a bad value got set on the config parse branch that only blew up very far away on another branch
2023-05-05 16:02:06 <KipIngram   > But only the things that naturally throw signals.
2023-05-05 16:02:32 <KipIngram   > thrig: Yes, and there's really no way for a system to aim you right at those problems.
2023-05-05 16:02:44 <KipIngram   > The system doesn't understand your code in that way.
2023-05-05 16:03:07 <vms14       > I suppose simplicity also comes in to play
2023-05-05 16:03:27 <vms14       > I can't see together extensive testing and simplicity
2023-05-05 16:03:29 <KipIngram   > When I have that kind of problem, the only thing for it is to roll up my sleeves.
2023-05-05 16:03:34 <KipIngram   > It's time consuming sometimes.
2023-05-05 16:04:06 <vms14       > but reflection is good in a language, and "metadata" helps debugging
2023-05-05 16:04:56 <vms14       > say you can mantain the number of elements every word takes from the stack
2023-05-05 16:06:50 <vms14       > KipIngram: you use signals as error system?
2023-05-05 16:07:22 <vms14       > like they're fired events
2023-05-05 16:07:55 <KipIngram   > Yeah.  Those signals already exist in the Linux underpinnings.  Normally a RAM address error will throw a segfault and return you to the bash prompt.
2023-05-05 16:08:02 <KipIngram   > Unless your code catches it and handles it.
2023-05-05 16:08:35 <vms14       > it's cool how you change a segfault for error handlers
2023-05-05 16:08:38 <vms14       > xD
2023-05-05 16:08:41 <KipIngram   > I did that - I wrote in a signal handler that routes me through my already existing error recovery system, which essentially restores the system to the state it had before I started typing the last line and sends me back to the interpreter.
2023-05-05 16:09:15 <KipIngram   > I already had a fairly typical error handler (except for the "restore" thing - usually Forth will just clear the data stack and go to the interpreter).
2023-05-05 16:09:26 <KipIngram   > But originally it only got tickled by compiler errors.
2023-05-05 16:09:44 <KipIngram   > Catching those signals wasn't easy, and there is NOT good documentation on how to do it out there.
2023-05-05 16:09:58 <KipIngram   > Because it necessarily involves processor architecture dependent details.
2023-05-05 16:10:04 <KipIngram   > It wouldn't be "portable."
2023-05-05 16:10:14 <vms14       > so every line you read you save the current state
2023-05-05 16:10:16 <KipIngram   > The idea would be, but details would have to be changed.
2023-05-05 16:10:27 <vms14       > no matter is from a block or stdin
2023-05-05 16:10:40 <KipIngram   > Everytime the interpreter prompts me to type a line, I make a full snapshot of my system and save it.
2023-05-05 16:10:44 <KipIngram   > Horribly expensive.
2023-05-05 16:10:55 <KipIngram   > then part of the error handling is to restore from that snapshot.
2023-05-05 16:11:06 <KipIngram   > If no error occurs, the snapshot is just abandoned.
2023-05-05 16:11:16 <KipIngram   > And overwritten by the next one.
2023-05-05 16:12:00 <KipIngram   > Linux just has the hardware set up so that those errors cause traps.
2023-05-05 16:12:12 <KipIngram   > It handles the traps in a certain way - I'm just specifying a different handling.
2023-05-05 16:12:14 <vms14       > horribly expensive, but not much memory at all
2023-05-05 16:12:21 <KipIngram   > Not really, no.
2023-05-05 16:12:34 <KipIngram   > On a regular computer with as much RAM as we have, I figured "why not."
2023-05-05 16:12:43 <KipIngram   > You see, the first system I did this on had command line history.
2023-05-05 16:13:13 <KipIngram   > What I was aiming at was to type a line with an error, and when the error occurred I wanted to just hit up-arrow to recover that line, cursor around in it and fix the error, and hit Enter again.
2023-05-05 16:13:19 <vms14       > I'd like to have a proper error system
2023-05-05 16:13:27 <KipIngram   > So I wanted the system state to be what it was when that line started to be processed.
2023-05-05 16:13:39 <vms14       > I have to learn about first
2023-05-05 16:13:50 <KipIngram   > I worked my way up to this - at first I had a pretty simple error handler.
2023-05-05 16:13:59 <KipIngram   > But then I started to run into situations it didn't handle well.
2023-05-05 16:14:25 <KipIngram   > Esepcially when lines made changes to vocabularies.  Or what if the line defines a word, successfully, before the error?
2023-05-05 16:14:52 <KipIngram   > I kept finding one thing after another I needed to struggle to "unwind," and finally I just said "Screw it" and decided to save and restore EVERYTHING.
2023-05-05 16:14:57 <KipIngram   > A literal image of the entire system.
2023-05-05 16:15:38 <KipIngram   > So it restores the dictionary, the stacks, the CONTEXT and CURRENT vocabularies, and so on.  All of it.
2023-05-05 16:15:47 <KipIngram   > Sledge hammer.
2023-05-05 16:15:59 <vms14       > in a vm is also easy to have snapshots
2023-05-05 16:16:37 <vms14       > a bytecode interpreter ends providing a lot of benefits
2023-05-05 16:16:48 <vms14       > and it's just a switch case with another nam
2023-05-05 16:16:50 <vms14       > name*
2023-05-05 16:17:04 <KipIngram   > Sure.  And doesn't HAVE to be inefficient, if you're careful with your code.
2023-05-05 16:17:31 <KipIngram   > I think the next Forth I write may wind up being a "token threaded" system more than anything else.  Except I'm thinking of 16-bit tokens instead of byte tokens.
2023-05-05 16:17:36 <vms14       > I suppose a vm is my next logical step
2023-05-05 16:18:02 <vms14       > crc has shown me several times how much portability adds
2023-05-05 16:18:03 <KipIngram   > Well, Forth systems actually ARE vms.  In a very literal way, it's a vm and the primitives are the instructions.
2023-05-05 16:19:06 <KipIngram   > You breach that barrier a bit if you have an assembler.  But as long as you're writing "just Forth," you're working no lower than with those primitive instructions.
2023-05-05 16:19:46 <KipIngram   > Forth just offers you the "elegance" of being able to define new words that "work" exactly like the primitives do.
2023-05-05 16:20:01 <vms14       > what will you store on those 16 bit
2023-05-05 16:20:04 <KipIngram   > You don't need a special format for invoking your added functions, the way you do in most other languages.
2023-05-05 16:20:26 <KipIngram   > An index into a table of code and parameter pointers.
2023-05-05 16:20:44 <KipIngram   > The same pointers that Forth would normally use, only collected into a pair of tables.
2023-05-05 16:21:02 <KipIngram   > Those tables are why I say it's more of a token threaded system.
2023-05-05 16:21:21 <KipIngram   > In my current and past systems, those pointers have been spread out in the headers of words.
2023-05-05 16:22:09 <KipIngram   > I haven't started this yet - I may change my mind.
2023-05-05 16:22:23 <KipIngram   > It just currently appeals to me, because having 16-bit xt's makes for such a compact system.
2023-05-05 16:23:13 <KipIngram   > For fastest performance, though, those tables will need to have 64-bit entries, and that makes me wince.
2023-05-05 16:23:33 <KipIngram   > That's 16 bytes per word, right there, before I've actually provided ANY actual implementation of the word.
2023-05-05 16:23:57 <KipIngram   > I could make those table entries 32 bits instead, but then I'd have to run a little slower; the mechanics of the vm would be made more complex.
2023-05-05 16:24:21 <KipIngram   > But I could just have one table then instead of two, with each "entry" being a CFA / PFA pair.
2023-05-05 16:24:28 <KipIngram   > Lot of small decisions to make around it.
2023-05-05 16:24:57 <KipIngram   > And these tables are two more things that have to be somewhere in RAM and have to have room to grow, so it fragments up my memory model more than other approaches.
2023-05-05 16:26:00 <KipIngram   > So we're talking about at least three regions, and maybe four - depending on one table vs. two.
2023-05-05 16:26:22 <KipIngram   > An implementation region, where code and definition lists go, the one or two table regions, and the header region.
2023-05-05 16:28:30 <KipIngram   > Another annoying aspect of it involves wasted space on primitives.  Primitives don't need a parameter pointer.  For built-in primitives I can avoid any waste, but if I add a primitive later, with an assembler, it will have to have a slot in both tables, in spite of not needing a slot in the parameter table.
2023-05-05 16:28:53 <KipIngram   > Otherwise the table locations for a given word would get out of sync.
2023-05-05 16:29:09 <KipIngram   > A word's index has to point to the right thing in both tables.
2023-05-05 16:31:10 <KipIngram   > But if I accept that and also accept the eight-byte table entries, then the "inner interpreter" (next) is only two instructions, and next, docol, and the multi-thread switching machinery all together are only nine.
2023-05-05 16:31:13 <KipIngram   > It's beautiful.
2023-05-05 16:32:11 <KipIngram   > Oh, it also calls for registers dedicated to pointing to each of the two tables.
2023-05-05 16:33:27 <KipIngram   > But in my old systems I use a register to point to the header region, and in this new system I'm talking about that could be demoted to a variable.
2023-05-05 16:33:43 <KipIngram   > Since anything having to do with headers isn't relevant to run-time performance.
2023-05-05 16:36:09 <vms14       > I'm trying to convince myself about making a switch case
2023-05-05 16:36:23 <vms14       > https://jilp.org/vol5/v5paper12.pdf
2023-05-05 16:36:34 <KipIngram   > What's "easy" in Forth is an indexed jump table.
2023-05-05 16:36:37 <vms14       > The Structure and Performance of Efficient Interpreters
2023-05-05 16:36:55 <KipIngram   > I.e., a "switch" with integer cases, 0, 1, 2, 3, ...
2023-05-05 16:36:56 <vms14       > yeah, a hash with functions as values also works
2023-05-05 16:37:07 <KipIngram   > Having arbitrary case trigger values is a lot more tedious.
2023-05-05 16:37:10 <vms14       > but a switch is usually faster
2023-05-05 16:37:43 <vms14       > a hash with functions is better than a switch
2023-05-05 16:37:45 <KipIngram   > I think if I were going to do that, I'd supply a mechanism to map arbitrary case identifiers onto integers.
2023-05-05 16:37:53 <KipIngram   > And call that first and then use a jump table.
2023-05-05 16:38:51 <KipIngram   > It would still be harder.
2023-05-05 16:47:32 <vms14       > I'm curious about using a forth-like to write assembly code
2023-05-05 16:47:54 <vms14       > you can add layer to layer until having something quite advanced
2023-05-05 16:48:31 <vms14       > but it's strange to see you don't usually do that
2023-05-05 18:14:51 <KipIngram   > Well, that's exactly how Forth is intended to be used, though.
2023-05-05 19:52:20 <KipIngram   > Lot of Forth I see in other places just looks like C.  At least it's laid out on the page like C.
2023-05-05 20:22:46 <thrig       > maybe that's C coders trying to make it look more Cish
2023-05-05 21:30:01 <KipIngram   > Yeah, my presumption too.
2023-05-05 21:30:51 <tabemann_   > I fully admit to making C-like Forth - I've learned to love the local variable
2023-05-05 21:31:52 <tabemann_   > (seriously, just try to write code that blits from one rectangle on one bitmap to another rectangle on another bitmap without them)
2023-05-05 21:32:09 <tabemann_   > (which is precisely why I gave in and added them to my Forth)
2023-05-05 21:32:58 <thrig       > a RNG was a bit tricky without local variables, there were like five little fiddly state variables
2023-05-05 21:35:02 <tabemann_   > the thing is that my local variable-using code is simpler (and probably much faster) than what its traditional counterpart would be
2023-05-05 21:35:07 <tabemann_   > far less ROT, no ROLL
2023-05-05 21:35:13 <tabemann_   > ROT and -ROT are expensive
2023-05-05 21:35:20 <KipIngram   > I've run into Forth cases where I needed more that the two two items on the stack.  We talked about that at length here one day.  It's what prompted me to add stack frames to my Forth.  They're basically local variables - just unnamed.
2023-05-05 21:35:20 <tabemann_   > setting a local variable is not
2023-05-05 21:35:57 <KipIngram   > Yeah, there's nothing "expensive" about indexing into the stack.  It's just not well thought of.
2023-05-05 21:36:17 <tabemann_   > my local variables live on the return stack, and I've made DO LOOP's use local variables behind the scenes so they're compatible with local variables
2023-05-05 21:36:22 <KipIngram   > Especially if you set up a mechanism to make it efficient.
2023-05-05 21:36:24 <tabemann_   > also, my local variables are block-scoped
2023-05-05 21:36:32 <tabemann_   > KipIngram, PICK is very cheap
2023-05-05 21:36:41 <tabemann_   > ROT, -ROT, and especially ROLL are not
2023-05-05 21:36:44 <KipIngram   > Yeah.
2023-05-05 21:37:13 <KipIngram   > I work on the data stack, because it's not so much "locals" I want as access to parameters and intermediate results.
2023-05-05 21:37:24 <KipIngram   > I don't use the mechanism very much.
2023-05-05 21:37:24 <tabemann_   > my code prior to my learning to love the local variable was chock full of ROT and -ROT
2023-05-05 21:37:32 <KipIngram   > I look for ways to avoid it.
2023-05-05 21:38:19 <tabemann_   > to me local variables make it easier to make more reliable code faster because I then don't have to constantly keep mental state of the state of the stack all the time
2023-05-05 21:38:33 <tabemann_   > or otherwise write detailed stack annotations on each line, and hope I got them right
2023-05-05 21:39:44 <tabemann_   > for my pre-local variable code I now go back to it and often don't understand a thing
2023-05-05 21:44:55 <KipIngram   > I understand and actually support the general "no locals" philosophy.  In most cases, if you need that much data around you haven't factored enough.  Now and then, though, I bumped into cases I couldn't figure out how to handle by further factoring.
2023-05-05 21:45:08 <KipIngram   > So I pull that tool out just for those cases.
2023-05-05 21:46:07 <tabemann    > to me the issue is when you simply cannot remove state
2023-05-05 21:46:23 <KipIngram   > Yeah - some things just have complex state.  That's exactly it.
2023-05-05 21:46:29 <tabemann    > e.g. when you have to work with two strings, both with a pointer and a count
2023-05-05 21:46:49 <KipIngram   > And when you need to get at a lot of it, and not just pieces of it at a time, it's hard with normal Forth words.
2023-05-05 21:46:57 <tabemann    > saying "oh you have to limit yourself to two things on the top of the stack" doesn't cut it
2023-05-05 21:47:13 <KipIngram   > Well, I find that it's often possible to do that though.
2023-05-05 21:47:22 <KipIngram   > And it usually does strike me as cleaner code.
2023-05-05 21:47:31 <KipIngram   > But not "always."
2023-05-05 21:47:42 <tabemann    > to me stack churn is a code smell
2023-05-05 21:48:03 <tabemann    > and a lot of time stack churn is unavoidable unless you use local variables
2023-05-05 21:48:49 <tabemann    > pre-local variables I'd use >R R@ R> a lot to simplify my data stack usage, but local variables do the same thing while being far more readable and far less error-prone
2023-05-05 21:49:10 <KipIngram   > Sometimes.  You can avoid it in many cases.
2023-05-05 21:49:35 <KipIngram   > You've got to think ahead so things are arranged the right way on the stack.
2023-05-05 21:50:38 <KipIngram   > I don't think there's anything wrong with having a way to reach into the stack.  It's nice when you don't have to, but as we noted earlier, it's not inefficient.
2023-05-05 21:51:03 <tabemann    > my usual pattern would be to identify the single most important thing in a word (what is called "this" or "self" in OO languages), and I'd stick it on the return stack
2023-05-05 21:52:37 <tabemann    > the problem with PICK is the mental gymnastics of having to identify how deep to reach into the stack each time you use it
2023-05-05 21:52:45 <tabemann    > it's error-prone
2023-05-05 21:53:06 <KipIngram   > Yes it is.  That's what my stack frames avoid.
2023-05-05 21:53:15 <tabemann    > and to make it work you have to stick an ( x y z foo bar baz etc etc etc ) at the end of each line of your code to keep track of it all
2023-05-05 21:53:17 <KipIngram   > I do a stack frame with { ... }
2023-05-05 21:53:30 <KipIngram   > The { sets a "frame pointer," and then inside the frame I index off of it.
2023-05-05 21:53:39 <KipIngram   > The top of the stack can move around, but the frame pointer stays put.
2023-05-05 21:53:45 <KipIngram   > So the offset of things remains unchanged.
2023-05-05 21:54:08 <tabemann    > I use { ... } for defining local variables
2023-05-05 21:54:13 <KipIngram   > { sets the frame pointer to the stack pointer, and } sets the stack pointer to the frame pointer.
2023-05-05 21:54:20 <KipIngram   > Existing frame pointer is saved on the return stack.
2023-05-05 21:54:54 <tabemann    > note, however, that I can define local variables multiple times in a word, and I can access them from within DO LOOP's
2023-05-05 21:55:05 <tabemann    > traditional, standard local variables can't do that
2023-05-05 21:55:33 <KipIngram   > That restoring the stack pointer at the end is a nice fringe benefit.  I make control structures using conditional single and double returns, so I can "return back up" into a stack frame from multiple places sometimes, and those routes might leave different amount of stuff on the stack.
2023-05-05 21:55:40 <tabemann    > in Standard forth you can define local variables once in a word, outside of any blocks, and you can't access them within DO LOOP's
2023-05-05 21:55:43 <KipIngram   > I don't have to worry about that because } will clean things up.
2023-05-05 21:56:39 <tabemann    > 
ACTION has been following gforth as a model for his local variables

2023-05-05 21:56:55 <KipIngram   > I actually give } a parameter - it's a number of "additional" items to drop from the stack.  Nice way to get rid of parameters no longer needed.
2023-05-05 21:57:57 <KipIngram   > If I wanted "locals," I'd probably just move the stack pointer further along, allocating space below the frame pointer, and index off of it in the negative direction.
2023-05-05 21:58:36 <tabemann    > if I were you I'd make } take its number of extra items to drop at compile time
2023-05-05 21:59:01 <tabemann    > reason being is then you can just compile it into the code as a simple addition, in many cases as a single instruction
2023-05-05 21:59:52 <tabemann    > a big advantage of how I've implemented local variables is that dropping them is simply ADD SP, SP, #<number of items to drop * 4>
2023-05-05 22:00:02 <tabemann    > and this is all automated for you
2023-05-05 22:00:33 <KipIngram   > Is your Forth code-threaded?
2023-05-05 22:00:47 <tabemann    > my Forth is an inlining native code Forth
2023-05-05 22:01:08 <KipIngram   > Ok, sure then.  My Forth is indirect threaded, and } is a primitive - that's as "compiled" as it gets in my system.
2023-05-05 22:01:30 <KipIngram   > I suppose I could create 0} and 1} and 2} and so on if I wanted to, but I haven't.
2023-05-05 22:01:54 <KipIngram   > I write fairly primitive-heavy Forths already.
2023-05-05 22:02:20 <tabemann    > I personally criticize the design of standard forth +LOOP because it's a pain to optimize because it takes its argument at runtime
2023-05-05 22:02:27 <KipIngram   > I do just that kind of thing on the stack *access* words.  I have 1@ and 1! and 1+! and 2@ and ...
2023-05-05 22:02:36 <KipIngram   > You get the idea.  On up to 5 or 6.
2023-05-05 22:02:48 <tabemann    > yeah
2023-05-05 22:03:02 <thrig       > car cdr caar cadr cdar cddr caaar
2023-05-05 22:03:07 <tabemann    > yeah
2023-05-05 22:03:51 <thrig       > ... cddaar cddadr cdddar cddddr
2023-05-05 22:03:55 <tabemann    > actually
2023-05-05 22:04:19 <tabemann    > if you're really smart about it, you can optimize much of that stuff even without explicitly specifying it at compile time
2023-05-05 22:04:27 <KipIngram   > My reasoning was that I use the stack access words a fair bit, whereas { and } themselves are used less often.
2023-05-05 22:04:43 <tabemann    > what I do is I "defer" literals and constants
2023-05-05 22:04:52 <tabemann    > I don't immediately compile them into instructions
2023-05-05 22:05:01 <KipIngram   > the other nice thing about my mechanism is that I can call from inside { ... } and no matter how deep down I go I can still access the frame with the same indices.
2023-05-05 22:05:10 <KipIngram   > Unless I open another frame down there.
2023-05-05 22:05:16 <tabemann    > and then if I have a word like +, it detects whether there's a deferred literal or constant
2023-05-05 22:05:28 <tabemann    > and if there is, it folds it into the compiled instruction
2023-05-05 22:05:44 <tabemann    > for instance 1 + compiles to a single instruction, ADDS R6, #1
2023-05-05 22:05:46 <KipIngram   > Yeah, with a system with a lot of inlining there are all kinds of fun games you can play.
2023-05-05 22:06:45 <KipIngram   > I just like indirect threading, and I always figure that if I need peak performance I can custom assemble those bits.  It's usually only a very small part of your code that makes any big difference.
2023-05-05 22:07:12 <KipIngram   > And I want a good profiling mechanism.  I haven't written one yet, but I know how I want to write it.
2023-05-05 22:07:25 <tabemann    > you could do something like this - make words like s! s@ s+! and have a deferred literal/constant mechanism
2023-05-05 22:07:31 <KipIngram   > Especially with this table-based scheme I'm considering it will be quite easy.
2023-05-05 22:07:47 <tabemann    > and when you compile s! s@ or s+! have it check for a deferred literal/constant
2023-05-05 22:08:17 <tabemann    > and if it is within a certain range, it generates a hardcoded word, such as 2 s+! could compile to 2+!
2023-05-05 22:08:18 <KipIngram   > My interests at the moment are just pointing in other directions.
2023-05-05 22:08:32 <KipIngram   > This threading and piping stuff is on my mind.
2023-05-05 22:10:51 <tabemann    > I'm into native code compiling because I want to squeeze out the performance of the systems I target, and the systems I target are large enough that I don't have to worry that much about code size (they're certainly not PC's or even the SoC RPi's though)
2023-05-05 22:12:36 <tabemann    > still, my compiler doesn't rival Matthias Koch's Mecrisp-Stellaris - Matthias is a veritable compilers wizard
2023-05-05 22:13:14 <KipIngram   > I'm a big fan of performance.  I just find indirect threading... "endearing."  :-)  Like I said, I want to profile and optimize where it matters.
2023-05-05 22:16:12 <tabemann    > I'm in the habit of writing a lot of primitives in Forth that generate native code directly
2023-05-05 22:17:03 <tabemann    > e.g. my local variable code is in Forth, but it generates native instructions