2023-02-01 03:24:13 <veltas      > KipIngram: As far as I know most of the gforth websites are out of date too
2023-02-01 03:24:41 <veltas      > I have no clue why they haven't done proper releases in ... must be over a decade now
2023-02-01 03:25:23 <veltas      > Not quite a decade actually
2023-02-01 03:26:32 <veltas      > No actually it is, in 2008 0.7.3 seems to have been built for Debian, so we're 15 years without a proper release
2023-02-01 03:27:07 <veltas      > Unless copyright year wasn't updated
2023-02-01 03:28:18 <veltas      > Frankly, the project is just asking to get forked. Then the fork can do proper releases and the gforth team can carry on just pottering about because they're obviously not interested
2023-02-01 03:28:35 <veltas      > And the fork can probably merge in their updates as well
2023-02-01 03:29:04 <veltas      > But make it properly stable, because gforth hasn't been reliably stable for a while. Ideally it would build out the box too, rather than needing an old version of gforth to build.
2023-02-01 03:29:56 <veltas      > This is probably a more useful thing to do than "making your own forth" because gforth is pretty important
2023-02-01 03:33:07 <veltas      > So, people out there looking for "something to do" ^^^^^^^^^^^^
2023-02-01 03:42:48 <veltas      > Probably just call it "gforth-gold" and try to get it added to Debian, Arch, and Fedora.
2023-02-01 04:10:50 <veltas      > KipIngram, thrig: gforth latest snapshot release has 2736 'words' (probably includes copyright statement so a bit less than that)
2023-02-01 04:10:56 <veltas      > ./gforth -e words -e bye | wc -w
2023-02-01 04:11:29 <veltas      > Not even including loads of stuff in other wordlists
2023-02-01 04:24:30 <veltas      > Re why version 1.0 hasn't been released yet https://lists.gnu.org/archive/html/gforth/2022-06/msg00003.html
2023-02-01 04:24:53 <veltas      > Apparently they want completed documentation first, so that is an alternative to forking, just fix their documentation
2023-02-01 04:25:32 <veltas      > I don't know why that's a prerequisite though, I don't think I've ever seen a GNU project with complete docs
2023-02-01 07:16:32 <veltas      > TIL the SysV ABI for PPC64 doesn't allow tail calls
2023-02-01 07:16:50 <KipIngram   > Well, I always thouht GForth was a more significant "organization" than it seems to be - apparently it's just a guy or two.  Not to much more than a "personal project."  I imagine what has happened is "life," for those guys.
2023-02-01 07:17:00 <KipIngram   > They just got busy taking care of stuff day to day in their worlds.
2023-02-01 07:17:10 <veltas      > PPC64's ABI is probably the worst designed I've ever seen, they get everything wrong. Look at equivalent PPC and PPC64 code, not even funny how much uglier, longer, slower PPC64 seems to always be
2023-02-01 07:17:32 <KipIngram   > And such things are "habits"; when you drift away from something, that kind of gets an inertia.  It's easier to stay away from it when you've stayed away from it for a while.
2023-02-01 07:17:36 <veltas      > It's two people, I know at least one of them is a professor or teacher at a university
2023-02-01 07:18:01 <veltas      > I think they're both involved in Forth200x and at least one social group
2023-02-01 07:18:06 <veltas      > And actively check their mailing list
2023-02-01 07:19:13 <KipIngram   > That kind of thing seems to be easier to stick with.  It delivers "bite sized tasks" to you.  I answer a bunch of Quora questions every day, and I've been far more consistent with that than I hae any of my personal projects.
2023-02-01 07:19:43 <KipIngram   > I've probably answered a dozen-ish questions, varies day to day, virtually every day since like 2017.
2023-02-01 07:20:51 <KipIngram   > When I really get energized on a personal project, I'm kind of driven - tend to get an enormous amount done in a shoort time.  Then something else catches my attention, and I drift away for long periods.
2023-02-01 07:21:58 <KipIngram   > I think you're right that GForth is a ripe fruit for someone to come along and pick.
2023-02-01 07:22:09 <KipIngram   > I.e., fork.
2023-02-01 07:23:50 <KipIngram   > The problem with me doing something like that is that I don't much enjoy working with code someone else wrote.
2023-02-01 07:24:31 <KipIngram   > It's unlikely their "guiding principles and ideas" match up with what I think they ought to be, so it makes it harder for me to follow their reasoning.
2023-02-01 08:05:48 <veltas      > Working with other people's code is inherently difficult. It's part of why maintainability is so important, and just generally understanding how to communicate your code to other people.
2023-02-01 08:06:07 <veltas      > It's so hard that very often it's easier to rewrite someone else's code than it is to patch it
2023-02-01 08:13:54 <KipIngram   > Reading about Erlang thread handling management this morning.
2023-02-01 08:14:31 <KipIngram   > Yes, I'd say ability to work with other people's code effectively is something that separates truly professional software engineers from... "hacks."
2023-02-01 08:15:08 <KipIngram   > I have a lot of respect for the folks that are good at it.
2023-02-01 08:15:13 <veltas      > I'm on the hack end of that spectrum
2023-02-01 08:15:29 <KipIngram   > Me too, even though I've managed software engineers at times.
2023-02-01 08:15:36 <veltas      > I'm quite good at reading and working through code, but unless it's written well I find it extremely taxing reading it
2023-02-01 08:15:38 <KipIngram   > But that's something a little different.
2023-02-01 08:16:01 <KipIngram   > My actual path was through hardware.
2023-02-01 08:16:18 <KipIngram   > And I've gleaned a lot of little "software tidbits" over the years.
2023-02-01 08:17:09 <KipIngram   > Looks like Erlang has the notion of "managed threads" vs. "unmanaged threads."
2023-02-01 08:17:51 <KipIngram   > That solves an issue I'd thought of.  If you think about the primary  Forth process as a thread, it winds up having quite a lot of information associated with it beyond its stacks.
2023-02-01 08:18:09 <KipIngram   > Things like the vocabulary path and BASE its TIB and so on.
2023-02-01 08:18:19 <KipIngram   > If that content is associated with every thread, you get waste.
2023-02-01 08:18:46 <KipIngram   > So I've got this notion of a thread block being a couple of cells at the beginning of a RAM block and then stacks.
2023-02-01 08:18:57 <KipIngram   > That would be an unmanaged thread.  Give it a word address and say go.
2023-02-01 08:19:06 <KipIngram   > It'll run and finish.
2023-02-01 08:19:26 <KipIngram   > But if you want to have it do much, it's going to have to have further resources, and those would be allocated separately.
2023-02-01 08:19:48 <KipIngram   > So I'm thinking a parent identifier, and an "environment" pointer, which will be null on thread creation.
2023-02-01 08:20:34 <KipIngram   > If it wants to, say, have a console, or search the dictionary, etc.
2023-02-01 08:20:38 <KipIngram   > it will need an environment.
2023-02-01 08:20:44 <KipIngram   > Where all the rest of that stuff will go.
2023-02-01 08:23:21 <KipIngram   > For just running a brief simple unmanaged task I'm picturing something like
2023-02-01 08:23:37 <KipIngram   > ' <word> <stacksize> FORK
2023-02-01 08:24:22 <KipIngram   > Somewhere outside of WARM I could have a point in the code TTY, and then you could say
2023-02-01 08:24:37 <KipIngram   > ' TTY 4096 FORK
2023-02-01 08:24:49 <KipIngram   > and that would open another console window running the system.
2023-02-01 08:25:10 <KipIngram   > The stuff in between TTY and WARM would take care of setting up a fresh environment (which would be largely inherited from the parent).
2023-02-01 08:25:53 <KipIngram   > Both would be able to search the dictionary for words to run, but compiling would reqire getting a lock on the dictionary.
2023-02-01 08:28:44 <KipIngram   > <stack size> has to be enough to save all of the registers, plus whatever your thread actually needs.
2023-02-01 08:29:11 <KipIngram   > So a light thread might be a couple hundred bytes.
2023-02-01 08:29:22 <KipIngram   > Which is in line with what Erlang can do.
2023-02-01 08:30:22 <KipIngram   > On a bar metal machine I'd picture a "ring" data structure for each core, that held the running active tasks, but on top of an OS I'm  not sure exactly how I'd set that up.
2023-02-01 08:30:33 <KipIngram   > Since Linux already is doing all that.
2023-02-01 08:31:06 <KipIngram   > I guess I could still set it up that way anyway, but I could also get by with one ring and just rely on Linux to choose the core at any given time.
2023-02-01 08:31:38 <KipIngram   > That timer tick mechanism will just march me around each ring.
2023-02-01 08:32:32 <KipIngram   > A thread could have a "nice" setting, which would govern how many times around the loop it let go by before it actually took a time slice.
2023-02-01 08:33:12 <KipIngram   > So, it could run at every opportunity, or every tenth, or whatever.
2023-02-01 08:39:20 <KipIngram   > Or rather before it was *given* a slice; it wouldn't really be something the task did itself.
2023-02-01 08:42:38 <veltas      > cooperative multitasking with preemptive killing/recovery is the best mix IMO
2023-02-01 08:43:19 <veltas      > No situation where you can't fix a crash or hang, but otherwise trust apps to work properly and they will sort sharing time themselves
2023-02-01 08:43:31 <KipIngram   > I do want to be able to have some things that are guaranteed to run periodically, though.
2023-02-01 08:43:38 <KipIngram   > Without me having to think about it in everything I write.
2023-02-01 08:43:50 <KipIngram   > For example, this handling of escape sequences from the keyboard.
2023-02-01 08:43:58 <veltas      > Sounds like an interrupt/signal
2023-02-01 08:44:09 <KipIngram   > I'm planning there to have a thread that actually monitors the keyboard.  If it gets non-escape it just passes it on through.
2023-02-01 08:44:39 <KipIngram   > If it gets an escape, though, it will sleep for some brief beat and then see if there is anything coming along with the escape key, and if so it will interpret it as an escape sequence.
2023-02-01 08:44:52 <KipIngram   > So it has to run often enough to get an accurate picture of that.
2023-02-01 08:45:04 <KipIngram   > I shouldn't be able to hit escape and another key fast enough to trip it up.
2023-02-01 08:45:08 <veltas      > Could still use cooperative multitasking for that IMO
2023-02-01 08:45:29 <KipIngram   > But then I'd have to yield to it in everything I wrote.
2023-02-01 08:45:45 <veltas      > With coop everything has to yield regularly anyway
2023-02-01 08:46:12 <KipIngram   > Maybe I'm  not grokking exactly what you're talking about, but I don't want to have to put words in my code to share.
2023-02-01 08:46:20 <veltas      > But yes, the variables associated with a *terminal* are very different to the variables associated with a *thread*
2023-02-01 08:46:59 <KipIngram   > Yes.
2023-02-01 08:47:37 <KipIngram   > I figure there will be some small amount of data associated with the terminal input; this thread will handle that and will pass the actually  keystroke stream forward to whatever thread is appropriate at that juncture.
2023-02-01 08:47:52 <KipIngram   > I guess that will depend on which window one has most recently made the focus.
2023-02-01 08:48:56 <KipIngram   > Anyway, this timer tick thing is super simple, and as long as I choose the countdown value intelligently I can make it more or less negligibly expensive in terms of overhead.
2023-02-01 08:49:51 <KipIngram   > Yesterday I thought for a minute I had gotten it down to the point where it was only going to cost the dec instruction, but that idea was to make the register jump I do in NEXT conditional, and apparently the processor can't do that.
2023-02-01 08:50:03 <KipIngram   > You can jump unconditionally to the address held in a register, but not conditionally.
2023-02-01 08:50:22 <KipIngram   > So it's still a dec instruction and a jump not taken, as far as "every time cost" goes.
2023-02-01 08:53:04 <veltas      > In this video they program an old minicomputer that did cooperative multitasking and would kill programs that went a certain amount of time without running a yield operation or doing I/O https://www.youtube.com/watch?v=0CgafaxnQ9A
2023-02-01 08:54:43 <veltas      > These environments have zero security, for one thing it's trivial to write a program to DDOS the entire system. If the wait period before being killed is N microseconds, wait N-1 microseconds and yield in a loop
2023-02-01 08:54:54 <veltas      > "DDOS" I mean "DOS" silly me
2023-02-01 08:55:33 <veltas      > But, security: YAGNI
2023-02-01 08:55:44 <veltas      > Just trust everyone <3
2023-02-01 09:10:10 <KipIngram   > Yeah - I don't really know enough about secure systems to attempt that.
2023-02-01 09:10:21 <KipIngram   > Plus I'm used to Forth being "wide open."
2023-02-01 09:12:03 <KipIngram   > I'm content with using this method to supply guaranteed periodic yields.  That's really all it's doing; it's just using the fact that Forth is already built of operations that pass through this one bit of code periodically.
2023-02-01 09:12:23 <KipIngram   > It's an easy place to put periodic yield that everything I write will automatically do.
2023-02-01 09:13:00 <KipIngram   > I don't know exactly what count I will use; I've figured a million or so, but I may wind up adjusting that.
2023-02-01 09:13:23 <KipIngram   > Big enough to lower the overhead, small enough to get "smooth feeling operation."
2023-02-01 09:14:06 <KipIngram   > I guess the bigger the count is, the fewer tasks I could add to a ring before I started to notice "stutter."
2023-02-01 09:19:43 <KipIngram   > Anyway, practically think I think this really *is* cooperative multi-tasking; I've just implemented the yield using code that all processes have to run.  It's not actually an interrupt doing it - it's the code each task executes.
2023-02-01 09:19:51 <KipIngram   > So in that sense it "works like" cooperative.
2023-02-01 09:20:34 <KipIngram   > And yet if a piece of code was doing something important to a piece of hardware, for example, there's no chance of that being interrupted; the code wouldn't have to "guard against" such a thing.
2023-02-01 09:22:24 <KipIngram   > That's probably one of the things that makes cooperative good in the first place - no chance of critical code sections getting interrupted.
2023-02-01 09:23:36 <KipIngram   > Of course, I still want a way for tasks to yield explicitly.  Might be useful in some situations.
2023-02-01 09:24:03 <KipIngram   > And blocking operations will yield too.
2023-02-01 09:24:35 <KipIngram   > Simplest way to explicitly yield would be to reduce your counter to 1.
2023-02-01 09:25:05 <KipIngram   > As soon as that happened, then the next pass through next would swap you out.
2023-02-01 10:31:26 <KipIngram   > There's info here on Erlang operation:
2023-02-01 10:31:29 <KipIngram   > https://www.erlang.org/doc/apps/erts/threadprogress
2023-02-01 10:32:34 <KipIngram   > I guess my goal here is to have "unmanaged threads" "just work," with as little pain and fuss as possible.  Obviously manged threads that interact with one another will have to handle that properly.
2023-02-01 11:06:38 <KipIngram   > Looks like Erlang refers to memory blocks used for this stuff as "carriers," and they have the notion of a "super-carrier."  That seems an awful lot like this "two tier" memory management structure I've thought about.  The large blocks would be the super-carriers; and "carriers" would be allocated from (some of) those.
2023-02-01 11:07:09 <KipIngram   > The basic idea is that there is no application intelligence at the large block layer at all, but applications can then carve those blocks up with any sort of intelligence they want to.
2023-02-01 12:28:43 <KipIngram   > The docs I linked are pretty good - they go specifically through the steps they took to eliminate nasty cache thrashing and so on.
2023-02-01 12:31:47 <KipIngram   > Basically every tasks updates a variable in a cache line they own; one thread reads all those and updates a "global" variable.  And he's the only one who writes that variable - all the other guys read it.
2023-02-01 12:32:02 <KipIngram   > This is for managed threads of course.
2023-02-01 13:25:04 <KipIngram   > Holy cow.
2023-02-01 13:25:21 <thrig       > blessed are the forks
2023-02-01 13:25:36 <KipIngram   > Looks like last Thursday an asteroid the size of a moving truck passed ***2200*** miles above the tip of South America.
2023-02-01 13:25:41 <KipIngram   > That's CLOSE.
2023-02-01 13:25:53 <KipIngram   > We knew about it in advance this time.
2023-02-01 13:26:34 <Zarutian_iPad> what sort of miles? nautical? old british? old roman?
2023-02-01 13:26:55 <thrig       > bad news: no shuttles to send up some roughnecks in
2023-02-01 13:27:47 <Zarutian_iPad> and what size of moving truck? small Renault Kango or big semi trailer?
2023-02-01 13:28:07 <KipIngram   > Like 20-feet ish.
2023-02-01 13:28:16 <KipIngram   > So no, not a huge truck.
2023-02-01 13:28:24 <KipIngram   > They referred to it as a "box truck."
2023-02-01 13:28:49 <thrig       > meters and kilograms exist...
2023-02-01 13:28:56 <Zarutian_iPad> did it shed some bolides?
2023-02-01 13:28:57 <KipIngram   > Big enough to spoil someone's day pretty well.
2023-02-01 13:29:09 <KipIngram   > My wife didn't read anything about that.
2023-02-01 13:32:59 <KipIngram   > I think this deflection business should be our top agenda item for first-world nation cooperation.  Surely THAT is an achievement we can all agree is important.
2023-02-01 13:33:34 <KipIngram   > For the first time in the history of life on the planet, a species is in a position to exert some CONTROL over that big random factor.
2023-02-01 13:34:27 <thrig       > otoh asteroid hits are pretty rare
2023-02-01 13:34:35 <KipIngram   > If we dodge nuclear holocaust and getting wiped out by a plague,  only to get rubbed out by an asteroid we COULD have diverted, if only we'd worked on the problem, it's going to be pretty damn ironic.
2023-02-01 13:34:55 <KipIngram   > Yes, they are, but all it takes is one.
2023-02-01 13:35:14 <KipIngram   > And even if we see the one coming, you can't just mosey up there and do something about - practice would be good.
2023-02-01 13:35:47 <KipIngram   > But yeah.  They're actually  not completely rare, but significant ones are.
2023-02-01 13:35:57 <KipIngram   > And far and away most of the small ones come down in the oceans.
2023-02-01 13:36:25 <KipIngram   > But there have been numerous (like a couple dozen) impact events in the last 20-odd years that involved more energy than the Hiroshima bomb.
2023-02-01 13:37:20 <KipIngram   > If one of those was headed toward London or Chicago or Moscow, it would be nice to be able to go stop that.
2023-02-01 13:37:42 <KipIngram   > Once we've detected one in the first place, we're super good at figuring out where it's going to land.
2023-02-01 13:37:54 <thrig       > sportsball folks might be happy if the Cubs were no more
2023-02-01 13:38:26 <KipIngram   > :-)  Well, and I could make an off color joke about Moscow, but... really I don't want any big city to suffer that.  Too many innocents involved.
2023-02-01 13:39:50 <KipIngram   > Anyway, my wife read me the article and said something about an asteroid passing "near the tip of  South America."  That got my attention right away, because that meant it was close enough to make it worth specifying a particular point on the planet.
2023-02-01 13:40:36 <KipIngram   > sounds like Earth re-directed it's orbit quite thoroughly.
2023-02-01 13:42:08 <KipIngram   > Solar system dynamics is pretty damn fascinating, really.  The two-body problem can be solved in closed form, but once you add a third body (with none of the three having negligible mass) that goes out the window.  It's chaotic dynamics and all kinds of interestin effects emerge.
2023-02-01 13:42:52 <KipIngram   > Turns out that there are actually "super low energy" trajectories from more or less anywhere to anywhere in the solar system, but they're slow; the trip might take a thousand years or something like that.
2023-02-01 13:43:13 <KipIngram   > But the idea that there's no way to reach the outer solar system without investing a bunch of energy to climb up out of the sun's gravity well isn't correct.
2023-02-01 13:43:29 <KipIngram   > There are trajectories that let you pilfer that energy from the planets you fly by themselves.
2023-02-01 13:45:53 <KipIngram   > My other favorite solar system travel concept is "cyclers."
2023-02-01 13:46:02 <KipIngram   > Especially the idea of an Earth/Mars cycler.
2023-02-01 13:46:17 <KipIngram   > A cycler is an orbit that repetitively passes near the same two planets.
2023-02-01 13:46:40 <KipIngram   > The idea is that you build a really large facility and spend the energy to get it into that orbit one time.
2023-02-01 13:46:53 <KipIngram   > And then you can dock with it as it flies by and reside in it for the duration of the trip.
2023-02-01 13:47:18 <KipIngram   > So you could have luxury hotel accommodations with great radiation shielding while you did the bulk of an Earth / Mars flight.
2023-02-01 13:47:42 <KipIngram   > Use smaller shuttle vehicles to get between the planet and the cycler.
2023-02-01 13:48:40 <KipIngram   > https://en.wikipedia.org/wiki/Interplanetary_Transport_Network
2023-02-01 13:48:56 <KipIngram   > https://en.wikipedia.org/wiki/Mars_cycler
2023-02-01 20:54:23 <KipIngram   > So, the straightforward way for me to do constants in this new system would be for docon to just be dovar with an extra fetch tacked onto the end.
2023-02-01 20:55:07 <KipIngram   > But... I could just let the 32-bit PFA pointer value be the constant too.  If I did that I'd sign extend it on the fetch to 64 bits.  But it would limit my range of constants to those that a signed 32-bit value can hold.
2023-02-01 20:55:10 <KipIngram   > Opinions?
2023-02-01 20:55:27 <KipIngram   > I doubt I have ever used a constant outside that range.
2023-02-01 20:56:21 <KipIngram   > Or maybe the logical thing is to just wait until I have DOES> working and say : CONSTANT  VARIABLE DOES> @ ;
2023-02-01 20:56:54 <KipIngram   > Wait, that's not right.  But you know what I mean, I imagine.
2023-02-01 20:57:11 <KipIngram   > : CONSTANT  CREATE , DOES> @ ;
2023-02-01 21:01:05 <KipIngram   > You know, Tolkien was pretty clever to have the elves of Lothlorien give the Fellowship a stock of "lembas" (elf bread).  It was stated that one little cake could supply nourishment for a man for an entire day.
2023-02-01 21:01:26 <thrig       > Church wrote a bit on lembas calculus
2023-02-01 21:01:26 <KipIngram   > It pretty much just eliminated any need for them to forrage for food during all of their remaining travels.
2023-02-01 21:01:51 <KipIngram   > So Tolkien didn't have to worry about that bit of "realism."
2023-02-01 21:03:05 <thrig       > https://acoup.blog/2019/05/10/collections-the-siege-of-gondor/
2023-02-01 21:12:49 <KipIngram   > :-)
2023-02-01 21:12:56 <KipIngram   > That might be fun to look over.
2023-02-01 21:13:06 <KipIngram   > I'm on a bit of a LotR kick at the moment.
2023-02-01 22:26:00 <Stalevar    > KipIngram, similar thing exist in reality called pemmican or something
2023-02-01 22:26:34 <thrig       > years ago your father served me in the pemmican wars