2023-02-11 01:05:24 <KipIngram   > Ok,  no more of The Witcher TV show for me.  I went and found the books instead.
2023-02-11 01:05:56 <KipIngram   > Guy that wrote these is Polish, and apparently the work has quite a cult following over there.
2023-02-11 01:09:46 <thrig       > reverse polish notation also has something of a cult following
2023-02-11 01:10:35 <KipIngram   > So, in Pike's paper, the channels of communication between the processes are typed, and by that I mean that you know in advance what you're going to send over each one and every transmission is of the same kind of structure.
2023-02-11 01:11:09 <KipIngram   > So it would be trivial to implement a channel between two interleaved threads with a shared memory region and write and read pointers.
2023-02-11 01:11:19 <KipIngram   > I don't see any trouble at all setting up the structure he describes.
2023-02-11 01:12:53 <KipIngram   > For that matter, you might not even need much RAM - if I read it correctly he's not talking about channels that can buffer a bunch of messages.
2023-02-11 01:13:15 <KipIngram   > When the sender sends a message, he blocks until the receiver's available to receive it.
2023-02-11 01:13:44 <KipIngram   > Maybe that's why he refers to them as "communicating SYNCHRONOUS processes."  I guess if there was buffering it would be asynchronous.
2023-02-11 01:15:23 <KipIngram   > He said that what it takes to make it work well is that all the processes have to be written to never take long to service their channels.
2023-02-11 01:16:05 <KipIngram   > But in this situation they wouldn't everyone gets to run at least hundreds of times a second.
2023-02-11 01:54:37 <KipIngram   > You know, back to the issue of windows overlapping on the screen.  I'd imagined writing a bit of machine code that could crawl up a stack of such rectangles and resolve it into a new structure with a LIST of rectangles at leach level, such that they defined the visible portions of each window.
2023-02-11 01:54:48 <KipIngram   > But that would of course increase the number of rectangles.
2023-02-11 01:55:25 <KipIngram   > I wonder if maybe it would be faster just to draw all of each one, in the right order so that the higher rectangles overwrote the parts of the screen where the lower rectangles were covered.
2023-02-11 01:55:45 <KipIngram   > It would mean writing some pixels multiple times, wastefully, but it might still be faster.
2023-02-11 01:56:11 <KipIngram   > In general, I mean - I could probably deliberately create cases where it wasn't.
2023-02-11 01:56:36 <KipIngram   > Have a large number of almost completely overlapping rectangles, with only a small slice peeking out.
2023-02-11 01:56:42 <KipIngram   > But that's a pathological case.
2023-02-11 01:56:55 <dave0       > KipIngram: x-windows keeps "bands" of rectangles
2023-02-11 01:57:12 <dave0       > i'll try and draw an ascii diagram
2023-02-11 01:57:58 <KipIngram   > Obviously this wouldn't be done every time - in a lot of cases I'd know exactly which visible part of which layer was getting changed.
2023-02-11 01:58:10 <KipIngram   > The full stack paint would be when I moved or re-sized windows.
2023-02-11 01:58:22 <KipIngram   > I can sort of imagine what you mean, dave0.
2023-02-11 01:58:30 <KipIngram   > At least I think.
2023-02-11 02:01:39 <dave0       > https://termbin.com/8ab3
2023-02-11 02:02:17 <dave0       > KipIngram: it splits the screen at every horizontal line
2023-02-11 02:02:48 <dave0       > KipIngram: you gets bands of rectangles all with the same y coordinates
2023-02-11 02:03:35 <dave0       > the bands are sorted top to bottom, and the rectangles are sorted left to right
2023-02-11 02:03:47 <KipIngram   > You did that fairly fast.
2023-02-11 02:04:03 <dave0       > i've looked into this before
2023-02-11 02:04:11 <dave0       > never wrote any code
2023-02-11 02:04:46 <KipIngram   > So you see exactly what I'm talking about, then.  In the top, you'd draw 0, draw 1, draw 2, and you're done.
2023-02-11 02:04:46 <dave0       > oh i missed a couple rectangles on the left
2023-02-11 02:04:57 <dave0       > yep
2023-02-11 02:05:11 <KipIngram   > In the bottom you have smaller rectangles and no "redundant writes," but a much larger number of calls to the bitblt copy.
2023-02-11 02:05:30 <dave0       > yep
2023-02-11 02:05:50 <dave0       > the more windows there are the more bands and more rectangles in a band
2023-02-11 02:05:53 <KipIngram   > My gut says the first approach would usually be faster, in typical situations.
2023-02-11 02:06:03 <KipIngram   > Yeah.
2023-02-11 02:06:32 <KipIngram   > And I do think that if you had a list of windows that you could traverse bottom to top, the algorithm for generating the small rectangles wouldn't be "awful."
2023-02-11 02:06:43 <KipIngram   > I'd need to think about it a while, but I think it would turn out fairly clean.
2023-02-11 02:07:37 <KipIngram   > The most common operation in a console type application would be to update one character on the screen, and the decision would be "is this character visible or not."
2023-02-11 02:08:03 <KipIngram   > But for that case you wouldn't do the big operation - you'd either update one little char rect or not.
2023-02-11 02:10:28 <dave0       > scrolling is tricky
2023-02-11 02:10:37 <dave0       > scrolling is an overlapping bit blit
2023-02-11 02:10:40 <KipIngram   > For that you'd go to the window you were updating, and ask "is the char in my rectangle?"  If it's not, you have no work to do.
2023-02-11 02:11:01 <KipIngram   > if it is, you then walk up the remainder of the stack and ask if it's in any of those - if it IS then it's covered up and you have no work to do.
2023-02-11 02:11:21 <dave0       > KipIngram: there is an alternative way of doing windows
2023-02-11 02:11:32 <KipIngram   > So you ask whether that screen rectangle is in each window, from the target window up, and only if the answers are "yes, no, no, ... no" do you write the char to the screen.
2023-02-11 02:11:43 <dave0       > KipIngram: keep each window as a texture on the graphics card and make the graphics card draw it with the z-buffer
2023-02-11 02:12:15 <KipIngram   > Well, that is kind of how I'm thinking (texture per window).
2023-02-11 02:12:19 <KipIngram   > What's the z buffer?
2023-02-11 02:12:32 <KipIngram   > Are you about to tell me the hardware will help me with this?
2023-02-11 02:12:50 <dave0       > which texture is in front
2023-02-11 02:13:01 <dave0       > i hope the graphics card can help
2023-02-11 02:13:06 <KipIngram   > Yes, sure.
2023-02-11 02:13:06 <dave0       > i haven't studied graphics cards
2023-02-11 02:13:24 <KipIngram   > Well, what would be idea would be if the graphics hardware was "window aware."
2023-02-11 02:13:39 <KipIngram   > ideal
2023-02-11 02:14:09 <KipIngram   > And would just decide for you whether the display should be updated.
2023-02-11 02:14:31 <KipIngram   > All you'd DO would be to update the texture for the target window.
2023-02-11 02:14:48 <KipIngram   > And the GPU would decide if that part of that window was or wasn't covered up.
2023-02-11 02:14:57 <KipIngram   > But I don't know if it's that smart.
2023-02-11 02:15:27 <KipIngram   > I'm planning to have a texture over there for each character font I'm using.
2023-02-11 02:15:36 <KipIngram   > One texture with all 256 characters in it.
2023-02-11 02:15:53 <KipIngram   > And I can calculate the small rectangle to copy out of that based on my character code.
2023-02-11 02:16:07 <KipIngram   > I've tested that, though I haven't done any performance timing.
2023-02-11 02:16:10 <KipIngram   > I've made it work though.
2023-02-11 02:18:14 <KipIngram   > And then these window textures would be additional textures.
2023-02-11 02:18:26 <KipIngram   > I also don't know how much such stuff I can slap over there.
2023-02-11 02:18:33 <KipIngram   > I figure probably "enough."
2023-02-11 02:20:12 <KipIngram   > You mentioned scrolling - for that you need to be able to do block moves in either direction - low to high or high to low.
2023-02-11 02:20:35 <dave0       > and left/right
2023-02-11 02:20:49 <KipIngram   > Oh, right - sure.  If you scroll that way.
2023-02-11 02:21:06 <KipIngram   > I think it's a nice thing to be able to do, even though I tend not to use really long lines.
2023-02-11 02:21:54 <dave0       > i kinda write however wide the screen is :-)
2023-02-11 02:22:05 <dave0       > so it's a bit uneven
2023-02-11 02:22:24 <KipIngram   > I usually split my screen up so that I wind up doing that too.
2023-02-11 02:22:30 <KipIngram   > except it's "how wide the window is."
2023-02-11 02:22:40 <dave0       > ah yep
2023-02-11 02:22:54 <KipIngram   > Even on this 13" notebook I have a "two wide" arrangement in my console window.
2023-02-11 02:23:08 <KipIngram   > Not quite even - on the left I arranged it to be 80 columns, and the right is "what's left."
2023-02-11 02:23:16 <KipIngram   > Which turns out to be 110.
2023-02-11 02:23:30 <KipIngram   > At the font size I like.
2023-02-11 02:23:49 <KipIngram   > For nostalgia reasons I made my irc window 25 rows and 80 columns.
2023-02-11 02:23:55 <KipIngram   > It's in the top left.
2023-02-11 02:24:25 <dave0       > i never knew where 80 came from
2023-02-11 02:24:39 <KipIngram   > Below it I have a couple of small "utility windows," and one very small window with some power monitoring diagnostics I run all the time.
2023-02-11 02:24:45 <dave0       > it's always just been that wide
2023-02-11 02:24:49 <KipIngram   > And then the big right side is my "main working screen."
2023-02-11 02:25:04 <thrig       > 80 is punch cards. 24 is the height (25 is a DOS perversion)
2023-02-11 02:25:14 <KipIngram   > Yeah, it's 25x80 was just what that green monitor on the IBM PC offered.
2023-02-11 02:25:34 <dave0       > email inherited it
2023-02-11 02:26:00 <dave0       > or mime or whatever
2023-02-11 02:26:09 <dave0       > something about when you send an email it wraps the lines
2023-02-11 02:26:16 <dave0       > and usenet
2023-02-11 02:26:21 <dave0       > that did too
2023-02-11 02:26:34 <dave0       > but they are very old
2023-02-11 02:26:37 <dave0       > even before the www
2023-02-11 02:26:39 <thrig       > various email RFC talk about 72 or so to be nice to small systems and whatnot
2023-02-11 02:27:02 <KipIngram   > Yeah, usenet definitely did.
2023-02-11 02:27:17 <KipIngram   > I'm from before the www.
2023-02-11 02:27:28 <KipIngram   > I watched all this stuff show up.
2023-02-11 02:27:29 <dave0       > lol
2023-02-11 02:27:46 <KipIngram   > It's been farily amazing, actually, how fast it all happened.
2023-02-11 02:27:59 <thrig       > or systems that did char buf[80] and would die if you sent them more than that
2023-02-11 02:30:59 <KipIngram   > https://stackoverflow.com/questions/14315104/optimising-the-drawing-of-overlapping-rectangles
2023-02-11 02:31:24 <KipIngram   > His cost function makes it even more interesting.
2023-02-11 02:33:39 <KipIngram   > This is from the Wikipedia article on z-buffering:
2023-02-11 02:33:41 <KipIngram   > A similar solution to determining overlapping polygons is the painter's algorithm, which is capable of handling non-opaque scene elements, though at the cost of efficiency and incorrect results.
2023-02-11 02:33:50 <KipIngram   > That last bit is... spectacularly unhelpful.
2023-02-11 02:35:33 <KipIngram   > Of course, that article is about real full 3D stuff, where depth changes gradually across the scene.
2023-02-11 02:35:49 <KipIngram   > This prooblem I'm looking at should be much simpler.
2023-02-11 02:37:33 <KipIngram   > My "do it all" method seems to be called the "painter's algorithm."
2023-02-11 02:37:39 <KipIngram   > New paint goes over old paint.
2023-02-11 02:39:48 <KipIngram   > I still figure it's probably the fastest way to do a full refresh.
2023-02-11 02:40:16 <KipIngram   > Each process will just maintain its own window texture, and then we just shoot them to the screen in the right order.
2023-02-11 02:41:09 <KipIngram   > And for single character modifications I'd modify the off-screen texture every time, but then only modify a screen rectangle if that char is visible.
2023-02-11 02:42:14 <KipIngram   > Most updates will only happen when the target window has focus, which means it'll be at the top of the stack.
2023-02-11 02:42:24 <KipIngram   > So in that case you'd only need to re-draw that one.
2023-02-11 02:42:51 <KipIngram   > But some running process might modify a visible character in a lower layer, so you need to be able to handle that.
2023-02-11 02:42:52 <Stalevar    > Does a pointer to pointer break your brain?
2023-02-11 02:43:07 <Stalevar    > or pointer to pointer to pointer
2023-02-11 02:44:00 <Stalevar    > or even pointer to pointer to pointer to pointer to pointer ... to pointer to NULL pointer
2023-02-11 02:44:44 <Stalevar    > It's not really that super complex, but it is sometimes hard to wrap my brain around to get it
2023-02-11 02:45:09 <KipIngram   > No, not really.  I can at least track the idea.
2023-02-11 02:45:21 <KipIngram   > But in an actual situation it might begin to get hard to keep up.
2023-02-11 02:45:38 <KipIngram   > A pointer to something is still a "thing," and so you can point to it.
2023-02-11 02:45:53 <Stalevar    > Yeah, but...
2023-02-11 02:45:56 <KipIngram   > In the old early Macintosh systems they had the concept of a "handle," which was a p ointer to a pointer.
2023-02-11 02:46:28 <Stalevar    > Last time was when I tried to write bin-echo I had to figure out how to use double pointer correctly
2023-02-11 02:46:34 <KipIngram   > You could have as many copies of the handle floating around as you wanted, but they made sure you only ever had one pointer - the one they knew where was.
2023-02-11 02:47:03 <KipIngram   > See, what that let them do was be able to move things around in the heap.
2023-02-11 02:47:20 <KipIngram   > They'd just modify the pointer when they moved something.
2023-02-11 02:47:29 <Stalevar    > #include <stdlib.h>
2023-02-11 02:47:29 <Stalevar    > long strtol(const char *restrict nptr, char **restrict endptr, int base);
2023-02-11 02:47:32 <KipIngram   > But since you weren't using a copy of that pointer, you didn't care.
2023-02-11 02:47:42 <Stalevar    > Here, I got how to use it but it took me several attempts
2023-02-11 02:47:55 <thrig       > I recall rebooting a lot on Mac OS
2023-02-11 02:49:06 <Stalevar    > Do you understand why say nptr (string which to process) is a regular pointer to char, while endptr (string where unprocessed data remains) is double pointer, and base is easy, either 10 to accept only decimal, or 0 to accept decimal, hex and octal
2023-02-11 02:49:15 <Stalevar    > ?
2023-02-11 02:49:54 <KipIngram   > Well, no, not without more exposure to the situation.
2023-02-11 02:50:15 <dave0       > Stalevar: it's a double pointer because it wants to return a pointer to the end of the string
2023-02-11 02:50:16 <KipIngram   > But I think the usual reason you'd have a pointer to a pointer is because some software somewhere wants to be able to know where the level-1 pointer is.
2023-02-11 02:50:25 <Stalevar    > KipIngram, strtol is one of option how to convert string such as "1223" to number such as 1223
2023-02-11 02:50:30 <KipIngram   > And yet it wants you to have something you can carry around and copy and so on.
2023-02-11 02:51:09 <Stalevar    > i wanted to be able to process errors hence strtol instead of atol
2023-02-11 02:51:14 <KipIngram   > It must be important in this situation that endptr only has one pointer, anywhere.
2023-02-11 02:51:18 <KipIngram   > So they can manage it.
2023-02-11 02:51:19 <thrig       > try writing a strtol with char *entptr
2023-02-11 02:51:31 <dave0       > Stalevar: char *string = "12345"; char *endptr = NULL; long number = strtol(string, &endptr, 10); if(*endptr == '\0') { ... endptr points to the end of the string... the entire string was a valid number .. }
2023-02-11 02:51:46 <Stalevar    > KipIngram, actually that's because endptr is a _returned_ parameter
2023-02-11 02:52:00 <Stalevar    > so one level of indirection is because it is a string
2023-02-11 02:52:08 <Stalevar    > and other is because it's returned from a procedure
2023-02-11 02:52:25 <KipIngram   > Oh,  ok - they return it to you, so they can no longer reach what they returned to you.
2023-02-11 02:52:30 <Stalevar    > that's because C doesn't have a proper string type
2023-02-11 02:52:33 <KipIngram   > But they want to be able to reach the pointer.
2023-02-11 02:52:53 <KipIngram   > Yeah, C's not the most friendly thing on strings.
2023-02-11 02:52:54 <Stalevar    > it only has a region of memory instead
2023-02-11 02:53:20 <KipIngram   > You can think of an xt in a Forth definition as a pointer.
2023-02-11 02:53:32 <KipIngram   > And in an indirect threaded system it's a pointer to a pointer.
2023-02-11 02:53:48 <Stalevar    > dave0, exactly, that's what I ended up doing in my code. My point was it was quite _hard_ to get right, as in I didn't do it from the first attempt
2023-02-11 02:53:56 <KipIngram   > and that layer two pointer is right next to another p ointer, which points at the new definition.
2023-02-11 02:54:19 <Stalevar    > of course when it's already explained it looks pretty simple
2023-02-11 02:54:29 <KipIngram   > So Forth involves the huge tree structures of pointers.
2023-02-11 02:56:42 <dave0       > Stalevar: i don't like what c has turned into so i left #c
2023-02-11 02:57:01 <Stalevar    > Hm...
2023-02-11 02:57:03 <dave0       > c is just not that good of a language
2023-02-11 02:57:11 <Stalevar    > Even if C89?
2023-02-11 02:58:00 <dave0       > i didn't find it better
2023-02-11 02:58:14 <Stalevar    > C is a very primitive language in away
2023-02-11 02:58:35 <dave0       > also C89 is 34 years ago
2023-02-11 02:58:47 <dave0       > c hasn't got aprreciably better
2023-02-11 02:58:55 <Stalevar    > Yes, it does at least translate math expressions in machine code, similar to what FORTRAN did (forumula translator, remember), but it doesn't go far beyond that
2023-02-11 02:59:03 <Stalevar    > the rest is almost machine code
2023-02-11 03:00:07 <dave0       > when 64 bit cpu's became mainstream they had a really good chance to make c a whole lot more comfortable
2023-02-11 03:00:08 <KipIngram   > C was invented at a time when computers were very primitive.
2023-02-11 03:00:23 <KipIngram   > At the time it was quite lovely, and fit on, say, the PDP11 like a glove.
2023-02-11 03:00:38 <Stalevar    > But what about Forth, can it fit well on PDP11?
2023-02-11 03:01:14 <KipIngram   > I don't really know the PDP11 architecture that well.  it probably would - Forth is pretty simple.
2023-02-11 03:01:28 <KipIngram   > I don't know how many registers the PDP11 had, for example.
2023-02-11 03:01:37 <Stalevar    > And... why microcomputers (8bit CPU, 16k to 64k of memory) only run Forth and Basic, not say C, even as C is quite small?
2023-02-11 03:02:19 <KipIngram   > Highly recommended reading here:
2023-02-11 03:02:21 <KipIngram   > https://medium.com/@garrytaylor_22287/c-is-not-a-low-level-language-5fca82d56b4
2023-02-11 03:02:55 <KipIngram   > Well, I can't really say why BASIC, except that I suppose Microsoft pushed it.
2023-02-11 03:03:07 <KipIngram   > C was used in the beginning in a different community.
2023-02-11 03:03:15 <KipIngram   > Academia, research, etc.
2023-02-11 03:03:25 <KipIngram   > i think you're getting into a popularity type issue.
2023-02-11 03:03:42 <KipIngram   > Sometimes there really ISN'T a great reason something became popular - it just did.
2023-02-11 03:03:47 <KipIngram   > Human psychology and stuff.
2023-02-11 03:03:57 <Stalevar    > Either way only few languages can fit in 4k of RAM
2023-02-11 03:04:00 <Stalevar    > Basic somehow did
2023-02-11 03:04:08 <KipIngram   > Some really influential guys liked C.
2023-02-11 03:04:11 <Stalevar    > Yeah, it is kinda terrible, but it did ...
2023-02-11 03:04:23 <KipIngram   > Well, remember that a lot of that BASIC was in ROM.
2023-02-11 03:04:33 <Stalevar    > I'm talking about Altair basic
2023-02-11 03:04:37 <Stalevar    > itwas not in ROM
2023-02-11 03:04:43 <dave0       > Stalevar: https://github.com/jart/sectorlisp
2023-02-11 03:04:46 <Stalevar    > First version was 6k, then MS made 4k one
2023-02-11 03:04:54 <KipIngram   > Ok, fair enough.  But I think BASIC is fairly simple.
2023-02-11 03:05:01 <KipIngram   > I haven't thought about it in decades, really.
2023-02-11 03:05:01 <Stalevar    > And yeah, sector languages, only lisp, forth and basic, as far as I know
2023-02-11 03:05:12 <Stalevar    > dave0, there is also sectorforth
2023-02-11 03:05:18 <Stalevar    > but not say sector C
2023-02-11 03:05:24 <dave0       > Stalevar: i love sector forth
2023-02-11 03:05:25 <Stalevar    > or sector Pascal
2023-02-11 03:05:47 <KipIngram   > I think the question is what is it about BASIC that makes it able to be small.
2023-02-11 03:06:03 <KipIngram   > Pascal and C have complex lexical and syntactic analyzers.
2023-02-11 03:06:12 <Stalevar    > Yeah, and it's my less obvious than why Forth or Lisp can be small
2023-02-11 03:06:16 <dave0       > it seems to be interactive languages
2023-02-11 03:06:22 <Stalevar    > * much
2023-02-11 03:06:58 <KipIngram   > Yes.
2023-02-11 03:07:09 <KipIngram   > It's just hard to imagine simpler than Forth.
2023-02-11 03:07:38 <KipIngram   > I guess something that just lets you poke bytes consecutively into RAM and then run them is simpler than  Forth.
2023-02-11 03:07:44 <dave0       > the boot sector basic parses expressions
2023-02-11 03:07:47 <KipIngram   > But... that's not quite a "language."
2023-02-11 03:08:06 <KipIngram   > That would probably be interesting to look at.
2023-02-11 03:08:24 <Stalevar    > it is discussed in sectorforth page
2023-02-11 03:08:25 <dave0       > someone did a REPL for assembly.. i remember it from hackernews
2023-02-11 03:08:30 <Stalevar    > and even the code is there
2023-02-11 03:09:17 <dave0       > https://github.com/tenderlove/asmrepl
2023-02-11 03:09:34 <Stalevar    > KipIngram, I guess, first of all things like IF condition THEN line1 ELSE line2
2023-02-11 03:09:58 <Stalevar    > other highlevel language use less primitive control structures than this
2023-02-11 03:10:37 <Stalevar    > In some basics it's IF cond THEN goto 123 ELSE goto 321 and it can have something else in place of goto
2023-02-11 03:10:57 <Stalevar    > and in simpler basics there is no else
2023-02-11 03:10:58 <KipIngram   > Yes - parsing those structures takes some work.
2023-02-11 03:11:37 <Stalevar    > So it's basically assembly with formulas
2023-02-11 03:11:48 <Stalevar    > gosub / return exactly mirror call / ret
2023-02-11 03:12:00 <KipIngram   > Yeah.
2023-02-11 03:12:24 <KipIngram   > A guy I used to chat with always picked at me by accusing Forth of being a "glorified macro assembler."
2023-02-11 03:12:46 <KipIngram   > And on one side of that coin, it's true - Forth can serve as a very nice macro assembler.
2023-02-11 03:12:51 <KipIngram   > It can do that kind of work.
2023-02-11 03:12:55 <Stalevar    > Forth is a bit different, it uses different paradigm, stack based
2023-02-11 03:12:59 <KipIngram   > But it can also be much more.
2023-02-11 03:13:07 <Stalevar    > while BASIC is much closer to machine code paradigm
2023-02-11 03:13:10 <KipIngram   > Yeah, and that helps it be smaller.
2023-02-11 03:14:24 <Stalevar    > Also, 8080 doesn't even have MUL instruction. So I imagine that's why on x86 BASIC fits in one sector while taking 2 or 4k at least on 8080
2023-02-11 03:19:56 <KipIngram   > Of couse, these days the C compilers do a lot, LOT  more than they NEED to to just get runnable code.
2023-02-11 03:20:07 <KipIngram   > So the target has changed quite a lot too.
2023-02-11 03:33:30 <Stalevar    > Hm... it turns out 8080 and Z80 were designed by same people
2023-02-11 03:36:08 <Stalevar    > https://stardot.org.uk/forums/viewtopic.php?f=3&t=9821&p=116643
2023-02-11 08:44:22 <Stalevar    > KipIngram, anyway, regarding forth, I don't really understand how would I make a Forth program. Well suppose I can add #!/usr/bin/env gforth shebang or something, but then suppose I want to make a simple command line application. I wouldn't know how to access command line args or output elsewhere than stdout, such as stderr, and that's very basic, if I want a "proper" command line thing
2023-02-11 08:44:45 <Stalevar    > and I'm not sure if I need to study it if I can do it in Tcl or C or Pascal already
2023-02-11 08:45:20 <Stalevar    > though it would be interesting to see some simple but complete command line program in Forth, as in reacting to --help, and doing something
2023-02-11 10:42:48 <KipIngram   > Well, gForth probably offers a way to access the command line parameters, but that's not some "standard" thing; you'd have to look it up in the gForth docs.  I've always regarded gForth as fairly "complete" - I'd be surprised if they haven't wired something in for that.
2023-02-11 10:43:20 <KipIngram   > One issue there is that those parameters are strings, and Forth in general doesn't have a highly standard way of working with strings.
2023-02-11 10:44:37 <KipIngram   > I want to support strings in some clean way in my new one, and my notion is that I'll have a dynamic memory  management system that uses ropes data structures for heap-type work.  So I'd probablyl just arrange for an array of strings to exist at startup with that information in it.
2023-02-11 10:45:00 <KipIngram   > But that'll just be because I wrote it that way, not because there's a "traditional way of doing it."
2023-02-11 10:54:12 <Stalevar    > printf %b\  \\x{{2..9},{A..F}}{{0..9},{A..F}} \\xA | fold -w 32 | iconv -f cp437
2023-02-11 10:54:40 <Stalevar    > Unix command line is magic. With this simple command you can say get a complete printout of a certain charset
2023-02-11 11:05:43 <KipIngram   > Yeah, I find the power of that part of Unix/Linux very pleasing.
2023-02-11 11:06:28 <KipIngram   > That and the fact that they've delivered a well-thought out set of small utilities that you can combine to achieve things - it's just a system that works.
2023-02-11 11:07:56 <thrig       > and pleeeenty of rope
2023-02-11 11:08:50 <KipIngram   > Pipelines.  It did occur to me the other day though that that pipeline type mechanism shares a little bit with Forth.  In Unix you use pipes to pass evolving information through a series of configurable commands.  In Forth you use a stack to pass evolving information through a series of words.  So it's a similar mechanism.  In Unix you treat that information as a string; in Forth you treat it as a stack of
2023-02-11 11:08:51 <KipIngram   > integers.  But it's similar just the same.
2023-02-11 11:09:26 <KipIngram   > If you wrote a bunch of Unix commands that treated the standard input string as a stack of integers, then it would be even more similar - for those particular commands.
2023-02-11 11:11:33 <KipIngram   > You could probably cook up a sed command that split off the last two words of an input string, treated them as numbers, added them, and in the output stream replaced them with that sum.  That would basically be +
2023-02-11 11:11:55 <KipIngram   > Or you could use awk and printf, or whatever.
2023-02-11 11:13:06 <thrig       > echo cat dog 41 1 | perl -lane 'print $F[-2] + $F[-1]'
2023-02-11 11:13:21 <KipIngram   > I spent some time thinking about how to do "stdin/stdout pipelining" in a Forth system, and eventually realized that we already do do pipelining, just with the stack instead.
2023-02-11 11:13:34 <KipIngram   > There you go.
2023-02-11 11:14:45 <KipIngram   > The differences in what's "easy to do" and "hard to do" just arise from the difference in the data structure used to carry the data through the pipeline of activities.
2023-02-11 11:15:44 <KipIngram   > And Forth was just designed to make it possible for the "commands" to be short little bits of machine code - simplicity and speed of the commands was a "design criterion" for Forth.
2023-02-11 11:16:02 <thrig       > Powershell tried to add objects and stuff. some seem to like it
2023-02-11 11:16:10 <KipIngram   > The shell was just written to optimize other things, like convenience etc.
2023-02-11 11:16:29 <thrig       > whipitupitude
2023-02-11 11:16:52 <KipIngram   > ;-)  Nice term.
2023-02-11 11:18:32 <thrig       > ... but if it's something you do a lot, or needs to run fast, you'll probably want to write it up in something else
2023-02-11 11:18:34 <KipIngram   > So I think for these "channels" between concurrent threads, I need to think of them as resources associated with the threads.  A small number of them will exist as soon as the thread gains an environment block, but I guess I want to be able to open new ones as well.
2023-02-11 11:19:18 <KipIngram   > I already had the notion that if a thread wanted to access the console, it will need an env block - so channels for its mouse, keyboard, and screen access will just come along with the environment.
2023-02-11 11:19:42 <KipIngram   > Those will be "built ins."
2023-02-11 11:20:04 <KipIngram   > And I'll need words for writing to or reading from a channel.
2023-02-11 11:22:04 <KipIngram   > Looks like in plan9 a process gets multiple channels for the screen - I think what the book explains is that there's a device for writing characters to the console, but also a /dev/draw device for doing graphics to the screen.
2023-02-11 11:22:09 <KipIngram   > Separate devices.
2023-02-11 11:38:38 <KipIngram   > You know, one slightly sad aspect of Lord of the Rings is that poor Frodo never really "recovers" from the whole experience.  He's just "wounded," and it doesn't really go away.
2023-02-11 11:39:15 <KipIngram   > Based on what I've read about Tolkien's life, I think that was autobiographical - I think he was writing about his own feelings in the aftermath of World War I.  Sounds like the guy really went through hell in that situation.
2023-02-11 11:39:48 <KipIngram   > I mean, no more so that a lot of other people - it just sounds like it was a particularly nasty war.
2023-02-11 11:44:40 <thrig       > PTSD is a thing
2023-02-11 11:53:08 <KipIngram   > I believe it and count myself as lucky to have never had to endure somehting like that.
2023-02-11 11:53:18 <KipIngram   > I figure I can't even really imagine what it would actually be like.
2023-02-11 11:53:51 <KipIngram   > I suspect that one part of it could just be remembering the things you'd had to do to survive, many of which might be things you normally wouldn't imagine doing.
2023-02-11 11:54:54 <thrig       > lots didn't survive
2023-02-11 11:55:19 <thrig       > to the point that the French had some new mathematics system to try to preserve the knows
2023-02-11 12:03:10 <KipIngram   > You mean like a new way of announcing battle casualties?
2023-02-11 12:03:43 <KipIngram   > Or do you mean to try to cope with "brain drain"?
2023-02-11 12:06:08 <thrig       > https://en.wikipedia.org/wiki/Nicolas_Bourbaki
2023-02-11 12:08:29 <KipIngram   > Ok.  so yeah - brain drain.
2023-02-11 12:09:06 <thrig       > this group (luckily?) didn't not like some Mandelbrot chap
2023-02-11 12:13:32 <KipIngram   > Oh yeah, the whole business of how infinities are dealth with in math put a lot of guys off.
2023-02-11 12:13:46 <KipIngram   > There are still some holdouts today, but they're thought of as kind of "fringe."
2023-02-11 12:14:02 <KipIngram   > The most outspoken one I'm aware of is that Wildberger guy.
2023-02-11 12:14:40 <KipIngram   > I do think some of his material is well worth learning, but on the other hand I don't know quite what to think of his "core position."
2023-02-11 12:14:55 <KipIngram   > I'm just not strong enough myself in those aspects of pure math to have a competent opinion.
2023-02-11 12:15:45 <KipIngram   > But one theme he harps on is that the *theory* should support extremely crisp treatment of *things we can actually compute*, and that does seem like good sense to me.
2023-02-11 12:16:34 <KipIngram   > One example he gives is a simple little function - I don't remember it exactly right now, but it has a cubic term in it (it's just a two term polynomial), and its curve passes through the point 1, 1.
2023-02-11 12:16:43 <KipIngram   > maybe it's just x^3 - 1 = 0.
2023-02-11 12:17:04 <KipIngram   > anyway, that point 1, 1 is the ONLY point on that curve that has both x and y be rational numbers.
2023-02-11 12:17:14 <KipIngram   > Every other point on the curve involves either irrational x or irrational y.
2023-02-11 12:17:51 <KipIngram   > So the standard math philosophy would let you go off and "compute a million points on that curve" just fine - you'd just give 1, 1 and all the other points would be inexact.
2023-02-11 12:18:11 <KipIngram   > But Wildberger thinks the standard view should be that those other 999,999 points DON'T EXIST.
2023-02-11 12:18:21 <KipIngram   > Because we can't represent them precisely in our calculations.
2023-02-11 12:18:30 <KipIngram   > Now, he's not saying we shouldn't solve the problem at all.
2023-02-11 12:18:48 <KipIngram   > He's saying that the theory should include some notion of "epsilon range" around the points.
2023-02-11 12:19:06 <KipIngram   > So it would be something like "find a million points within distance epsilon of 1-x^3 = 0."
2023-02-11 12:19:19 <KipIngram   > And I do agree that that is a more well-formed problem, that you can PROVE that you have solved.
2023-02-11 12:19:41 <KipIngram   > There's no question about whether your solution is correct or not, given the inclusion of an epsilon factor in the problem statement.
2023-02-11 12:20:18 <KipIngram   > But without that, one could argue that you hadn't solved the hproblem at all, since most of your points that you present aren't actually on the curve.
2023-02-11 12:20:47 <KipIngram   > To the engineer in me, it seems like pedantry, but on the other hand "math" is supposed to be PRECISE.
2023-02-11 12:23:18 <KipIngram   > Looks to me like that French group had a fairly noble mission there - working to maintain knowledge is always a good thing.
2023-02-11 12:24:36 <KipIngram   > https://www.eventbrite.com/e/seti-talks-satellite-constellations-an-existential-threat-for-astronomy-tickets-531219671337
2023-02-11 12:24:43 <KipIngram   > that looks like it might be entertaining.
2023-02-11 12:24:52 <KipIngram   > Something for folks to haggle over.  :-)
2023-02-11 12:25:33 <KipIngram   > I find it hard to believe that no one has come up with a nice AI technique for removing artificial satellite tracks from astronomical images.
2023-02-11 12:25:37 <thrig       > we'll leave it to the private market, what could go wrong?
2023-02-11 12:25:55 <KipIngram   > I mean, the satellite is only over any given spot for a fraction of a second.
2023-02-11 12:26:08 <KipIngram   > No kidding.  Private market is holy, man...
2023-02-11 12:26:12 <KipIngram   > I'm being sarcastic of course.
2023-02-11 12:26:27 <KipIngram   > I'm a big fan of the private market, but it doesn't get EVERYTHING right.
2023-02-11 12:26:29 <thrig       > meanwhile this teardown of the predictions in "the long boom" isn't going to write itself
2023-02-11 12:26:55 <KipIngram   > I really hate the fact that our culture has developed in such a way as to leave 90% of people unable to even really SEE the sky unless they make a special trip somewhere to do so.
2023-02-11 12:27:07 <KipIngram   > It used to be something our ancestors all shared, all the time.
2023-02-11 12:27:11 <thrig       > the stars were purty up in the himalayas
2023-02-11 12:27:12 <KipIngram   > And we've just "undone it."
2023-02-11 12:27:17 <KipIngram   > And continue to do so.
2023-02-11 12:27:38 <thrig       > that a dude was sitting with a flashlight on the front bumper to find the very very narrow road was also pretty exciting
2023-02-11 12:27:56 <KipIngram   > :-|
2023-02-11 12:42:01 <KipIngram   > So, ok - yeah.  I'm going to use the term "channel" to refer to these mechanisms for interprocess communication.  Exactly *what* gets communicated, and whether it's synchronous or asynchronous (unbuffered or buffered) will vary, but the channel mechanism itself will be uniform.
2023-02-11 12:42:33 <KipIngram   > Trying to write to a full channel or read from an empty channel will block.
2023-02-11 12:43:35 <KipIngram   > If multiple processes block on some one such action, they'll queue up and get honored first-come-first-serve.
2023-02-11 12:46:23 <KipIngram   > Such a setup could be used for all kinds of synchronization operations.  One interesting example would be to set a channel up so that a whole bunch of processes blocked trying to read it, and then one write could turn all of them  loose.  Plan9 calls that kind of synchronization a "rendezvous."
2023-02-11 12:48:36 <thrig       > be sure to clean memory after wild liasons?
2023-02-11 12:50:11 <KipIngram   > Good sanitation is vital.  :-)
2023-02-11 13:18:05 <KipIngram   > Ugh.  I'm having a hard time with the last part of Lord of the Rings.
2023-02-11 13:18:31 <thrig       > good old sharkie
2023-02-11 13:18:38 <KipIngram   > The big story is over - Sauron is no more, but now there's this bit of them going home and finding the place taken over by two-bit ruffians, and they have to deal with that.
2023-02-11 13:19:00 <KipIngram   > But after the whole big exciting story it's fairly boring, and I just don't know if I can stomach 150 pages of resolving that.
2023-02-11 13:19:10 <KipIngram   > I may just skip to the end and read that part.
2023-02-11 13:19:19 <KipIngram   > Yeah - gotta love Saruman.
2023-02-11 13:19:23 <thrig       > you can also skip all the poems to make it go faster
2023-02-11 13:19:33 <KipIngram   > Oh, I've been doing that all the way through.
2023-02-11 13:20:10 <KipIngram   > I don't want to criticize them, and if I actually studied them I might find there to be some nice stuff in 'em.  But they just don't really "work" for me.
2023-02-11 13:21:44 <KipIngram   > Of course, this part of the story is a lot more realistic than the other part - this kind of crap has happened all over the place throughly history.
2023-02-11 13:22:03 <KipIngram   > Scumbags taking control of places through fear tactics.
2023-02-11 13:23:20 <KipIngram   > But the unrealistic story was just more interesting.
2023-02-11 13:24:55 <thrig       > nothing that Don Quixote failed to impress into readers
2023-02-11 13:25:21 <KipIngram   > There whole trip back from Minas Tirith the "fantasy" elements of the story have one by one fallen by the wayside, including at last Gandolph, and now this part is all too real.
2023-02-11 13:25:41 <KipIngram   > Ugh.  THEIR whole trip...
2023-02-11 13:26:46 <KipIngram   > I guess the way I want to structure this channel stuff is to have a channel offer a set of standard "calls," and I'll implement that with a table of xt's.
2023-02-11 13:27:05 <KipIngram   > Then I can design the behavior of a channel by writing words and plugging their xt's into that table.
2023-02-11 13:29:38 <KipIngram   > And use it along the lines of
2023-02-11 13:30:04 <KipIngram   > ...values... <channel op> <channel word>
2023-02-11 13:37:09 <KipIngram   > Oh, ok - well, that part of the story wasn't that long after all.  They made pretty quick work of it.  Most of what's left is appendices, and I do want to read those - that's back to interesting "historical" stuff again.
2023-02-11 13:37:27 <KipIngram   > And I'll read the actual story part after Sharkey's dealt with.
2023-02-11 13:59:22 <KipIngram   > Well, finished the book (other than the Appendices).  I do have to say Tolkien was a fantastic writer - he pitched this tale as a story of our own remote past, and he did it so well as to make it almost believable.  The idea that things were just "different" once, and magic abounded, but that that age just passed away.  It's a pretty remarkable story.
2023-02-11 14:00:02 <KipIngram   > Makes me think of Stephen King's  phrase in The Dark Tower - "but the world had moved on since then."
2023-02-11 14:46:36 <KipIngram   > Wow, I am just so often amazed at the... "tackiness" of folks in StackOverflow commentary.  Those folks just seem to love being critical of others and using confrontational language.
2023-02-11 14:46:55 <KipIngram   > It's as though you can just count on finding that kind of thing.
2023-02-11 14:47:14 <KipIngram   > And it's "more so" than in other communities I drop in on now and then.
2023-02-11 14:57:03 <KipIngram   > So I guess in this interface I'll have a process for each device that monitors the actual physical device, using some particular interface, and it will route the information to whatever window has focus at that time.  Meanwhile the interface it presents to the windows will look exactly like the interface it sees on the actual device.
2023-02-11 14:57:49 <KipIngram   > And it'll correct the x/y coordinates, from screen coordinates to window coordinates.
2023-02-11 14:58:12 <KipIngram   > But keeping the interface completely identical seems important.
2023-02-11 14:58:31 <KipIngram   > For one thing, it would make it possible to have windows in windows if I wanted to.
2023-02-11 15:02:26 <KipIngram   > Not that the screen I use currently is really big enough for that, but if I do this well I might find myself really interested in a larger screen setup.
2023-02-11 15:02:35 <KipIngram   > a "real workstation" so to speak.
2023-02-11 16:12:41 <KipIngram   > I guess when a window is created, that would be the time to establish a texture on the GPU corresponding to it's surface.
2023-02-11 16:12:59 <KipIngram   > We know how we're dimensioning the window, so the texture is made to match.
2023-02-11 16:14:32 <KipIngram   > When a window is re-sized, we'd make a new texture for it.  if the new one is larger, then we take the old one ad copy the whole rectangle into the new texture at the right spot.  If the new one is smaller, we copy a suitable rectangle from the old one into it.  In the former case there will be newly visible surface that the application will have to be able to draw.
2023-02-11 16:14:48 <KipIngram   > Since that's bitmap real estate that just didn't exist before the resize.
2023-02-11 16:15:00 <KipIngram   > Anyway, then the old texture is deallocated.
2023-02-11 16:15:47 <KipIngram   > Another way to do this that Pike seems to allude to is that the client creates the new texture and paints it, and then posts a request to have that texture replace its window texture.
2023-02-11 16:16:22 <KipIngram   > Since this resize process may unavoidably call for graphics work from the application, it's suitable to let it drive the process mostly.
2023-02-11 16:16:49 <KipIngram   > Applications may want to own textures that are not visible on the GPU anyway.
2023-02-11 16:17:06 <KipIngram   > Work on those textures has nothing to do with the user interface.
2023-02-11 16:24:15 <KipIngram   > So what the user interface system is really doing is letting the application say "I want this to be visible."  A window is thus made for that bitmap, and along with that the potential to interact with that content via keyboard and mouse.
2023-02-11 16:24:44 <KipIngram   > That also births a process - forking a child process goes right along with that.
2023-02-11 16:25:02 <KipIngram   > But *replacing* the window texture with a new one does not change the process.
2023-02-11 16:25:44 <KipIngram   > And also won't affect the keyboard and mouse channels at all.
2023-02-11 17:38:10 <KipIngram   > So I want this to support either tiled or overlsapping windows - in fact on this 13" screen I'll most likely used tiled for the most part.
2023-02-11 17:38:43 <KipIngram   > The treatment of acme I read yesterday implies that it tries pretty hard to do "intelligent" automatic placement and sizing of windows - that feels like a good thing to me.
2023-02-11 17:39:57 <KipIngram   > It seems to do a lot of "treating various text" like commands, and it figures out what command to run based on what (rather arbitrary) text you click on.
2023-02-11 17:40:26 <KipIngram   > So it's like displaying content in the window changes what the user interface is then capable of doing, since a lot of that content can serve as a guide to choosing commands.
2023-02-11 17:44:37 <KipIngram   > By the way, this dovetails rather nicely with the remote comment stuff - in that case certain mouse actions on source code would be interpreted as a command to open a new window, conttaining any content linked to that part of the source.
2023-02-11 17:45:27 <KipIngram   > There's a fair bit to handle there - when I edit a file or block, the link locations have to move with moving content.  So that'll have to be explicitly checked for and handled.
2023-02-11 17:45:39 <KipIngram   > But I feel like once it's working properly it'll be awfully nice.