2023-02-13 04:31:22 Quite famously printers have been exploited by hackers 2023-02-13 04:31:38 At the very least they can waste your energy and paper 2023-02-13 04:31:54 At the worst they can '''start a fire''' although I doubt most printers can be hacked to do that 2023-02-13 04:44:09 Or print things that might defame you if seen being printed, or be illegal to possess, or print propaganda... 2023-02-13 04:44:22 So printers are definitely targets 2023-02-13 10:08:42 man, Sabine Hossenfelder is mean to particle physicists 2023-02-13 10:14:47 is there a forth that uses the stack notations to do a sanity check before compiling? 2023-02-13 10:15:00 like a rudimentary type checker. 2023-02-13 10:43:06 yeah, Sabine is a character. She doesn't pull any punches. 2023-02-13 10:43:41 joe9: There are Forths that do make use of the stack effect "comments" (guess it's questionable calling them "comments" in such systems). 2023-02-13 10:43:51 i've seen them used to implement local variables, for example. 2023-02-13 10:44:22 I don't know a specific example of the sort of thing you're talking about, but you certainly could, for example, use them to confirm there's enough data on the stack before running a word, etc. 2023-02-13 10:44:38 Or if you create a typed system you could use them to confirm that the RIGHT kind of data is on the stack. 2023-02-13 10:44:49 yes, something to do such checks. 2023-02-13 10:44:52 I'm planning eventually to use them to help pick the right word (again, in a typed system). 2023-02-13 10:44:59 the info is right there. 2023-02-13 10:45:07 That is, word search will fail unless a word is available under that name that takes the available types. 2023-02-13 10:46:03 I haven't committed myself completely to using standard style stack comments to carry the type requirements, but it certainly seems like the most straightforward way of doing it. 2023-02-13 10:46:37 It strikes me as verbose, but I doubt any other way will seem less verbose. 2023-02-13 10:46:47 One way or another you have to supply more information. 2023-02-13 10:47:12 As far as "standard" Forth goes, though, no - they're just comments. 2023-02-13 10:51:12 I'm a little concerned I'm going to decide that there's a complication with using SDL2, now that I've found this paper by Pike. 2023-02-13 10:51:40 One of his big notions is that use of concurrent threads can "separate" management of these devices, so that you don't have to have that big event loop at the outside of your system. 2023-02-13 10:51:58 But SDL2 provides precisely such an event loop, as far as my early reading has indicated. 2023-02-13 10:52:12 I'm worried that it's just "expecting me" to use that approach, and that's what it supports. 2023-02-13 10:52:25 So there may be some "friction" here trying to combine these ideas. 2023-02-13 10:53:05 a sample app: https://github.com/telephil9/vdir 2023-02-13 10:53:12 I suppose I could still have an "SDL2 concurrent process," which takes the incoming event stream and then produces separate mouse and keyboard interfaces. 2023-02-13 10:53:36 At least then I've "boxed" the SDL2 native interface in one place. 2023-02-13 10:54:18 Then I could have separate mouse and keyboard processes which handle the demultiplexing of the information out to various windows. 2023-02-13 10:54:49 But it also looks like SDL2 tries to do that demultiplexin as well - when you take an event out of the event stream, it tells you what window that event is associated with. 2023-02-13 10:55:11 Probably it will get more clear when I write it all out. 2023-02-13 10:57:44 Maybe that means the SDL2 process maintains per-window queues of mouse and keyboard events, and then a given window's "mouse process" is responsible for keeping that associated queue empty. It's clear that part of what Pike intends is that the concurrent nature of these processes will prevent any such "queue" from ever getting very deep, or even for that matter beyond one deep. 2023-02-13 11:00:39 So where I just said "queue," it's not really a queue - it's the send end of an unbuffered channel. And if things are working right, that channel should never block the SDL2 process - a block would be an error condition. 2023-02-13 11:01:00 The whole idea here is that these processes are capable of staying ahead of the slow user. 2023-02-13 11:15:09 So I guess it's not quite right to say SDL2 is demultiplexing - rather, it's providing information that makes it easy to demultiplex. I don't have to go and check window coordinates and stuff. 2023-02-13 11:15:44 I don't know yet whether it also provides window *coordinates* - I may still need to do that part. 2023-02-13 11:16:10 Seems like it would be easy for it to, so maybe it does. 2023-02-13 11:21:49 Embrace the main loop + event handler + interrupt handler model 2023-02-13 11:21:57 Too many issues are created by trying to avoid this 2023-02-13 11:21:59 At any rate, I think that SDL2 process will just maintain a "mouse state variable" and a "keyboard state variable" for each window. Whenever it runs, it will empty the incoming event stream, updating those variables appropriately, and then when the event queue is empty it will force it's tick counter down to 1, so it'll swap itself out. There shouldn't ever be multiple updates to either variable on one 2023-02-13 11:22:01 interval. 2023-02-13 11:22:22 I'll need to see that for myself - I don't doubt that you'll prove right. 2023-02-13 11:22:41 But I want to follow a less "faith based" path. ;-) 2023-02-13 11:23:17 It's not as though you're saying "Pike was wrong" - Pike had no idea when he wrote that how practices were going to evolve over the years. 2023-02-13 11:23:50 I may find that SDL2 was written with certain assumptions in mind, and that it's hard to unwind those assumptions. 2023-02-13 11:24:20 I can absolutely imagine it forcing me onto a particular path, just by how it works. 2023-02-13 11:25:00 But I could write that layer just described so that if it finds itself updating the same output variable twice in one interval, I flag that as a problem situation. 2023-02-13 11:25:12 Because it "shouldn't," if I'm really staying ahead of the user. 2023-02-13 11:25:45 The idea would be that it updates that set of variables no more than once, and blocks itself. Then by the time it runs again, it should find that they have all been read by other processes, making it ok to write them again. 2023-02-13 11:28:32 Anyway, IF it turns out I can isolate the SDL2 calls into a single concurrent process, I'll consider that a win. 2023-02-13 11:29:18 I'm referring to the mouse and keyboard parts here - I do expect application processes will directly modify bitmaps for screen output. 2023-02-13 11:29:31 Via various Forth interface words. 2023-02-13 11:30:48 Each window will have a bitmap representing its screen image at any given time, and will be able to update that at any time. But the app level won't do the calls that actually render to the physical screen - the SDL2 process will do that. 2023-02-13 11:31:08 It will own the bitmap that is the current render object. 2023-02-13 11:31:33 And it'll copy from the app window bitmaps to that one as appropriate. 2023-02-13 11:39:55 This extra layer of bitmaps might be an issue if I start trying to write a game or a video player. I think short of that, though, it will work fine and will make the app level interface simpler. 2023-02-13 11:47:08 By the way, there is a middle ground here - one possible outcome is that I do have this SDL2 layer, but still wind up using a master event loop *per window*. I'm not *necessarily* trying to get completely away from having app programs have an event loop. I just want them to see only their own events. 2023-02-13 11:47:41 The main goal is for each application to be totally unaware of all of the others, unless I deliberately connect them with channels. 2023-02-13 11:49:26 Pike is recommending a more thorough separation of events into per-device streams, with apps aware of "each device." But it may turn out that SDL2 makes it preferable not to do that. 2023-02-13 11:49:58 But I don't want apps having to "peek" at the single event stream to see if the next event is for them or not. 2023-02-13 11:53:54 I'm still a little confused as to how this "complete screen editing" capability that acme offers actually gets USED. It lets you cursor back up on the screen and edit prior output. I'm just not quite sure yet what you eventually do with that, in terms of a "console session." 2023-02-13 11:54:12 But the acme documentation implies its quite valuable and useful, someway. 2023-02-13 11:55:17 The claim is that it was optimized for maximizing the "convenience" associated with software development. 2023-02-13 11:55:48 Maybe joe9 can say something about it when he gets back, since he seems to be our plan9 guy. 2023-02-13 11:56:13 maybe unix is good enough 2023-02-13 11:56:20 :-) 2023-02-13 11:56:26 Well, it certainly is good. 2023-02-13 11:57:09 A couple of days ago I quoted, re: plan9, some guy saying something like "The greatest enemy of a new approach is a well-established existing approach that is 'just good enough.'" 2023-02-13 11:57:26 But I've got a blank piece of paper in front of me. 2023-02-13 11:57:42 So I want to consider "better" potential. 2023-02-13 11:57:59 This is that thinking phase I put so much emphasis on. 2023-02-13 12:09:47 Historically I have shunned graphical approaches to this kind of work, but what I'm telling myself is that maybe that's because the graphical approaches I've seen just seem like unnecessary "bolt ons" that don't really advance the cause. Maybe this whole acme approach is a better way that will appeal to me. 2023-02-13 12:10:45 Microsoft tried to be a GUI company for a long while. they had folks wheeling crash carts in data centers to clicky clicky 2023-02-13 12:11:59 My feeling about Microsoft is that they've just waited to see what seems to be winning the popularity contest and then went out and bought that capability. 2023-02-13 12:12:13 Whatever people seem to like, they want to own it. 2023-02-13 12:12:54 I don't really see them as having ever "birthed" valuable new technology. 2023-02-13 12:23:34 This seems like a useful page about part of acme: 2023-02-13 12:23:39 http://acme.cat-v.org/mouse 2023-02-13 12:24:09 Middle button click on a word will execute that word as a command - how that word came to be visible on the screen is irrelevant. 2023-02-13 12:24:23 The same for text swept out while holding the middle button down. 2023-02-13 12:25:04 So that's obviously a pretty broad capability, and it's just hard for me to immediately grasp its full potential usefulness. Probably won't be able to until I can actually try it out for a while. 2023-02-13 12:25:55 That page uses the word "plumb" in connection with the right mouse button, and I don't know what plumb means yet. 2023-02-13 12:25:58 oh, a bit like selecting code in a workspace in Smalltalk80/Squeak and Do It! 2023-02-13 12:47:57 http://doc.cat-v.org/plan_9/4th_edition/papers/acme/ 2023-02-13 12:49:00 I find it potentially appealing because it sounds like actually doing something with the mouse that's well beyond what's done in most standard systems. 2023-02-13 12:49:23 Kind of like when Forth came a long in the first place - it just offered possibilities that weren't common in the then available other systems. 2023-02-13 13:34:46 "Acme has no single notion of ‘current directory’. Instead, every command, file name, action, and so on is interpreted or executed in the directory named by the tag of the window containing the command. For example, the string mammals in a window labeled /lib/ or /lib/insects will be interpreted as the file name /lib/mammals if such a file exists." 2023-02-13 13:38:12 that's how pre-unix did things, and woe betide there not being a tty file present 2023-02-13 13:49:47 Oh - it looks like acme provides a natural incorporation of regular expressions into the interface. 2023-02-13 13:50:26 Well, as a Forth fan I certainly don't balk at there being easy ways of stubbing my toe here and there. 2023-02-13 13:50:55 Now, if I wind up stubbing it constantly on the same rock, I'll have to question whether that rock really should be tolerated. 2023-02-13 13:51:20 damn Earth. we should nuke it from orbit. 2023-02-13 13:51:37 That's how I felt about addressing errors (which are easy to make in Forth) before I installed the signal handling that let me make that fairly painless. 2023-02-13 13:51:52 Almost completely painless, in fact. 2023-02-13 13:52:04 No worse than any typo. 2023-02-13 13:52:23 pforth does segfault a lot 2023-02-13 13:52:46 Well, I'm talking here about segfaults that you'd expect - when you try to access invalid memory. 2023-02-13 13:52:54 Not "bug" segfaults. 2023-02-13 13:54:02 If you click the right way on a filename in acme, it will open that file in a new window. But you can also append // to the end (not sure if that closing / is really required), and it will open that file and find the first match to the regex and highlight it with the cursor there. 2023-02-13 13:54:06 that seems fairly handy. 2023-02-13 13:54:36 I would think that if it's already open in a window it'll just focus that window. 2023-02-13 13:55:10 Oh, sorry - it's not //; it's just : 2023-02-13 13:55:20 Sort of like adding a port # to a URL. 2023-02-13 13:56:05 Of course there is also a way to just search for a literal filename in the current window. It's just a different mouse action. 2023-02-13 13:56:29 And that's how it's handled if it's not the name of an existing file. 2023-02-13 13:56:36 There's a different way to create a new file. 2023-02-13 13:56:53 :>file 2023-02-13 13:59:21 Wow - it's an absolutely gorgeous day down here. 2023-02-13 13:59:27 Definitely need to take a walk later. 2023-02-13 13:59:41 Really couldn't ask for a better temperature. 2023-02-13 13:59:52 especially in FEBRUARY. 2023-02-13 13:59:56 free vitamin D 2023-02-13 14:01:50 Indeed. 2023-02-13 14:01:55 "The overall design is intended to make text on the screen useful without copying or retyping; the ways in which this happens involve the combination of many aspects of the interface." 2023-02-13 14:02:19 I like the *philosophy* that drove Pike on this. 2023-02-13 14:03:06 I'm still needing to do that topmost user interaction layer of this new drive test setup at work (I've been busy RUNNING tests instead of working on the system). I may consider rolling some of these ideas into that. 2023-02-13 14:04:03 It makes sense to me that each running test could have a window on the screen, and from those one could open further windows to see log information, trigger any post operations that weren't just done automatically, and so on. 2023-02-13 14:04:37 I don't really begrudge the period of incompleteness - it's allowed me to have to do the extra steps by hand and that's valuable experience to help me know how I want that top layer to work. 2023-02-13 14:04:37 what if you're running 30,000 tests 2023-02-13 14:05:38 (Windows gets into trouble by having to run everything in a Window, or did, last I ran it, and when it was booting I would amuse myself by trying to close those do-nothing windows at boot) 2023-02-13 14:06:20 Well, one "system" in this setup can hold 12 drives, so 12 is hte one system limit. But, the top layer should allow an arbitrary number of systems. 2023-02-13 14:06:35 I don't know yet - perhaps the main window scrolls so that yes, there is a window for each one. 2023-02-13 14:06:52 But, bottom line is it's not a "30k" kind of number - it's "a dozen"-ish. 2023-02-13 14:07:13 Or there may be a line in the main window for each running test, or in the "running tests" window, and I could explore from there. 2023-02-13 14:07:16 Don't know yet. 2023-02-13 14:10:43 But I've been told by a suitably powerful guy that I will be keeping this unit I'm using now, which I had expected to have to give back to another team at some point, and I have two more of them on order that will show up over the next couple of months. 2023-02-13 14:13:55 Right now I don't have confidence about running more than a small number of tests at once on it (even though capability wise I could test all 12 drives at once). I just don't have enough data to quantify how much interaction there can be between such tests. There's no possibility of CPU or PCIe port contention, because I've designed it so that there won't be. 2023-02-13 14:14:18 And I'm pretty sure at this point there's no possibility of "running out of RAM," unless I tried to run 12 tests that took many days. 2023-02-13 14:14:47 This tool holds performance information in RAM until the conclusion of the test, and it collects an 1856-bin histogram every second. 2023-02-13 14:14:56 But I think there's plenty of RAM for anything I'll want to do. 2023-02-13 14:15:16 But, that leaves RAM bandwidth, and that's where I just don't have enough data yet to make any sort of "declaration" about it. 2023-02-13 14:15:44 But at any rate, I can keep up manually with one of these things the way we're currently using it, but when I get three of them going I need some automated help to keep them busy. 2023-02-13 14:15:56 And that's the purpose of this top layer. 2023-02-13 14:32:13 That last linked item I posted (Pike's introductory paper on acme) is worth reading all of if you're interested in any of this. 2023-02-13 14:32:39 I'm starting to get a better grasp of how this would all work to streamline things for a programmer at work. 2023-02-13 22:05:56 I think when I get around to words to do kick of concurrent processes, something like FORK will be involved. FORK will create a clone of the current process. To the parent it will return the new process id, but to the child it will return 0. So then something like FORK 0!=; ...child code... will get the new process running ...child code... The parent, on the other hand, will return. 2023-02-13 22:06:34 After child code there should be some termination word. 2023-02-13 22:07:22 If I'm not badly off the mark, I think that this acme stuff looks like it involves a process for each window. 2023-02-13 22:07:34 So when a new window opens, you get a new process too. 2023-02-13 22:07:50 The paper says the whole thing is implement as a collection of concurrent processes. 2023-02-13 22:08:30 some are less happy about fork (but then they also wanted the unix tools...) 2023-02-13 22:08:47 What do they like better. 2023-02-13 22:08:50 ? 2023-02-13 22:09:40 https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/ 2023-02-13 22:09:56 Something else might work better; I'm barely beginning to think about it. 2023-02-13 22:11:58 In acme it looks like the same code handles all of the windows - they all basically do the same thing, just with different content. 2023-02-13 22:13:58 Thee's also an API to acme, so that programs can interact with it. 2023-02-13 22:14:50 There's an acme root directory, and there's a subdirectory for weach window in that directory. The files in that subdirectory behave a bit like Linux pseudo files, and by reading and writing them you can access window content, change it, and various other things. 2023-02-13 22:17:07 I kind of get the idea that this type of system can't really exist without a file system. It's VERY filename oriented. 2023-02-13 22:19:28 acme also posts all user interface actions to an "event" file that the external program can access too. 2023-02-13 22:20:01 The program can either choose to interpret some of those actions itself, or it can just reflect them back to acme and let it handle them with its default behavior. 2023-02-13 22:33:17 Another likely rub getting all of this integrated into a Forth system is that the I/O behind these devices is inherently character I/O. 2023-02-13 22:33:49 But Forth doesn't really do character I/O to files/blocks. 2023-02-13 22:34:00 It moves an entire block into / out of RAM all in one shot. 2023-02-13 22:35:13 I guess it probably wouldn't be that hard to put a layer in front of that, but that's a fairly significant "concept change." 2023-02-13 22:47:11 Ah, what a great quote... 2023-02-13 22:47:15 ‘A major source of objection to a free economy is precisely that it … gives people what they want instead of what a particular group thinks they ought to want. Underlying most arguments against the free market is a lack of belief in freedom itself.’ 2023-02-13 22:48:27 sounds like a nice idea. maybe someone should try it some day? 2023-02-13 22:49:05 :-) 2023-02-13 22:50:12 Well, I don't think I'd want to try it "in totality" - I do feel like the free market needs some oversight. We just tend to give it the wrong kind of oversight, and too much oversight. Or rather too much of the wrong kind and not enough of the right kind. 2023-02-13 22:54:39 Acme doesn't put the output of a command into the same window the command executed from. It goes to a new window, which is opened if necessary. 2023-02-13 22:55:30 It's a reasonable idea for programming - run a make, and the output will gnerally consist of error messages. 2023-02-13 22:55:57 So those go into a new window - Pike even named it ...+Errors, where ... (I think) is the name of the window that led to it opening. 2023-02-13 22:56:09 consistent handling of more streams might be nice 2023-02-13 22:56:12 Those error messages will refer to files, and from that output window you can open those files. 2023-02-13 22:56:39 Yeah, I do think that "channels" between these concurrent processes will be important, so having them work in a smooth way would be good. 2023-02-13 22:57:34 I'm pretty clear on how a channel "should work," once it's established. It's how they're set up in the first place that's fuzzy for me. 2023-02-13 22:57:52 but people usually invent logging frameworks or sqlite or something to stuff data into 2023-02-13 23:17:30 Yeah. I'd thought about keeping a history on disk - I wasn't sure whether it would be separate input and output histories, or a blended one, or what, but it seems like something should prove handy. I figured it would be time and date stamped records. 2023-02-13 23:17:44 The command history subsystem would work by walking back into that and finding the prior inputs. 2023-02-13 23:18:29 In acme, though, the window you type commands in IS kind of the history - you can select text from up there and execute it at any time.