2023-10-17 00:21:09 We actually have finally gotten a cool spell. I went to jog a couple of hours ago and it was 69 degrees. It was a great run. 2023-10-17 00:21:53 A month ago I was dealing with 100 degree + temperatures and had to wear my little neck wrap ice pack and my cooling vest and the whole nine yards. 2023-10-17 00:22:13 Ten years ago or so I had a minor heat stroke one summer, and ever since I'm more sensitive to heat. 2023-10-17 00:28:37 I started trying to be regular about this exercise maybe two or three months ago, and before that I'd hardly done anything for years. It was pretty hard there for a while. I finally seem to have gotten fit enough now that I can kind of just go "knock it out" - I'm going to really try not to let it go again like I did. 2023-10-17 00:29:18 I've gotten into a three day on, one day off pattern, and every other day I move some weights around also. 2023-10-17 17:24:13 Interesting how people use the phrase "bare metal." 2023-10-17 17:24:17 Consider thiS; 2023-10-17 17:24:20 https://anthonynsimon.com/blog/kubernetes-cluster-raspberry-pi/ 2023-10-17 17:24:48 In his article title he says he's going to build a "bare metal" cluster, but if you read through it it's anything but bare metal. 2023-10-17 17:25:01 Ubuntu, Kubernetes, Docker, etc. 2023-10-17 17:25:15 Apparently what he means by the phrase is "not virtual." 2023-10-17 17:31:46 or look at how folks use "ASCII" (anything text-like) 2023-10-17 17:33:13 Good example too. 2023-10-17 17:34:10 I'm afraid I have shamelessly dodged learning anything about Docker, containers, etc. By the time that tech came along I was past spending my days doing hands-on work in that arena, and I just never bothered to go out and get the learning. 2023-10-17 17:34:18 "Yet another layer." 2023-10-17 17:34:24 We really seem to love layers. 2023-10-17 17:37:59 It would be interesting to take some typical modern environment running on some typical CPU and count layers, including hardware layers like instruction re-ordering, register renaming, etc. Just to see how big the number was. 2023-10-17 17:38:41 In that sense a "one layer system" would be actual application instructions running on an actual hardware CPU. 2023-10-17 18:30:37 Hmmm. In this little SDL2 test program I've written, if I run it and then just move the mouse around non-stop in the window, it behaves as you'd like for a while, but every 15-20 seconds "sticks" for a second or so. Garbage collection, I suppose, but it just seems to me like they should have been able to do better than that. 2023-10-17 18:31:12 You'd think that work could be distributed in a more fully "behind the scenes" way. 2023-10-17 18:32:24 I probably shouldn't criticize, though, given that I've never solved that problem myself. 2023-10-17 18:37:08 Could this be related? https://stackoverflow.com/questions/71371611/sdl2-following-mouse-position-has-a-delay 2023-10-17 18:40:47 Not sure - the code discussed there does more than I'm currently doing. Mine's about as simple a program as you can get - it creates the window, fills it with a background color, and then just loops. The loop responds to mouse button down events by recording the mouse position, and to mouse up events by grabbing the mouse position again and drawing a red rectangle with those two positions as corner. 2023-10-17 18:41:18 When I ran that it immediate grabbed 100% of the CPU, which makes sense - for now I just put a 10 msec sleep in the loop to fix that. 2023-10-17 18:42:02 I know there are standard ways to control your frame rate - I just haven't bothered to set all that up yet. Looks to me like it just means sleeping for a tailored length of time, based on how much time it took you to do your work. 2023-10-17 18:46:53 All it's really doing is SDL_Pollevent(), a big if statement, and SDL_UpdateWindowSurface() to show any changes I just made. 2023-10-17 18:47:43 Actually I wrote it so that if I get an event then it does the resulting work and does NOT sleep; it does the 10ms sleep only when no event has occurred. 2023-10-17 18:48:05 And in that case does not do the surface update. 2023-10-17 18:48:49 I don't care much for how SDL defaults the window borders. I suppose I could dig through how to control that, but for now I've just suppressed the border altogether. 2023-10-17 18:49:12 The main downside of that is that I lose the "default" way of moving windows around (dragging the titlebar). 2023-10-17 18:50:57 Some systems allow moving a window with Alt+left click 2023-10-17 18:53:43 That doesn't seem to be baked into SDL - it must be something I'd need to arrange on my own. But - if that's a semi-standard way of doing it, I could arrange it that way. 2023-10-17 18:53:58 I'd assumed it would be some combination of keyboard and mouse. 2023-10-17 18:55:46 I don't know what kind of high level window arrangement I want - rather than making everything all fancy and movable / resizable, I may just use a fixed tiled structure. 2023-10-17 18:56:32 I would simplify things a little, by not dealing with any partial overlap. 2023-10-17 19:03:25 I got kind of interested in graphics stuff the other day watching those videos I linked to the other day, and also after seeing that site that had the interactive microprocessor simulations. 2023-10-17 19:03:45 I want to be able to do that kind of work using a Forth I write. 2023-10-17 19:04:23 And actually had first started to consider SDL2 back when we discussed the complexity of my EXPECT word and how that might arise from it being the wrong way to think about inputting text in the first place. 2023-10-17 19:05:02 Here we are with our user interfaces that can create all kinds of events, but once you call a traditional EXPECT then the only thing you can respond to is keystrokes. 2023-10-17 19:05:49 A more general user interface loop that just passes received strings into the interpreter or application seems like a better fit. 2023-10-17 19:13:16 I'm imagining something along the lines of being able to have a window and in that window place a "text box." The *system* will handle giving that box the focus when appropriate and updating it in response to keystroke eents. But the box will also have a role at the application level - maybe hitting Enter causes it to fire an application event so that the text gets processed. 2023-10-17 19:13:33 But maintaining the box is a system job and using the box is an application job. 2023-10-17 19:19:15 Also, I was talking the other day about how APL manages your console experience. Well, that's also just a fancy procedure for maintaining a (large) text box. 2023-10-17 19:19:25 So the same general ideas would apply. 2023-10-17 19:21:45 I've thought of a couple of enhancements for that APL style. Basically it places the cursor at column 6 when it expects input from you, and writes its own output starting in column 1. 2023-10-17 19:22:22 You can cursor up and modify prior lines, but it doesn't retain that - when you hit enter it copies any previous lines + modifications to the bottom as though you typed it as new input. 2023-10-17 19:23:18 I thought it might be interesting to a) treat any user input starting at the far left as commentary / annotation, and b) actually allowing you to go back and make permanent changes to those prior lines. So you could work work work, then go back up and take notes one the results and so on. 2023-10-17 19:23:45 I.e., you could add new lines to the history. 2023-10-17 19:24:32 Modifications to executable lines would continue to be treated the same - those actually happened as part of your history, so you wouldn't want to permanently change them. 2023-10-17 19:31:32 I particularly liked the ray tracing stuff the coding adventures guy did - really amazing that it's that straightforward to calculate such realistic look scenes. 2023-10-17 19:32:35 Do you know of https://fabiensanglard.net/rayTracing_back_of_business_card/ ? 2023-10-17 19:32:37 You do it in reverse. Most light that reflects off of stuff never reaches your "eye." So you go the other way - you "beam paths out of the eye," and trace how they bounce around. If they reach a light source, then that means light from that source is reaching the eye. 2023-10-17 19:33:08 No - not familiar with that site. I'll check it out. 2023-10-17 19:33:15 It has a place in my tab list now. :-) 2023-10-17 19:33:33 I get amused at how many tabs I wind up having open in chrome. 2023-10-17 19:33:51 There's more graphics stuff here https://www.realtimerendering.com/#intro 2023-10-17 19:34:11 Tabbed. 2023-10-17 19:35:05 I think SDL2 is a fairly low-level library, really meant to run in tandem with other things like OpenGL and so on. But that's ok, since I want to write my own stuff in Forth anyway. 2023-10-17 19:35:22 A fairly low-level grip on the hardware is exactly what I want. 2023-10-17 19:38:17 1198 pages?! 2023-10-17 19:41:54 Must be from Intel... 2023-10-17 19:42:29 The Intel manuals are more like 8000 :P 2023-10-17 19:42:37 Yeah - they're nuts. 2023-10-17 19:43:00 ARM is more like 12000 2023-10-17 19:43:37 I understand, but it also strikes as stuff that no one person is ever going to completely absorb. 2023-10-17 19:44:17 there were already too many books to read 2023-10-17 19:44:18 Really only useful as "reference material," and even then only if it's well-orgainzed so you can find the stuff you need at any given time. 2023-10-17 19:47:39 I do support the notion of "having all the answers *somewhere*." 2023-10-17 19:49:03 All of that 3d graphics stuff uses projective geometry heavily, and I've recently been really interested in that too; I want to wire that sort of stuff into my system's array support in a pretty fundamental way. 2023-10-17 19:49:48 Essentially it just involves adding an extra dimension to you vectors. 2D projective geometry uses 3D vectors, etc. 2023-10-17 19:50:28 And it's neat because you can use that extra component to clear fractions - with integer processing only you can more or less get the power of rational numbers. 2023-10-17 20:27:59 Wow - that business card ray tracer compiles and runs on my system and makes that pretty picture. Very cool. 2023-10-17 20:39:05 That ppm image format is pretty cool too - I wasn't familiar with that. 2023-10-17 21:03:12 In that article Sanglard said it took his Macbook Air 27 seconds to render that image. Mine takes 9.33 seconds. :-) 2023-10-17 21:07:49 considerably longer than that on a gen 8 core i7 2023-10-17 21:08:21 1 minute 12 seconds 2023-10-17 21:12:29 Well, that article was written in 2013, so 3x faster in 2023 isn't particularly significant. :-) 2023-10-17 21:13:31 I already think of some experiments, though - I was commenting earlier on projective geometry letting you work with integers - I'd be interesting in seeing if I can modify that so that it no longer uses floats and still get worthwhile results. 2023-10-17 21:13:38 And if so whether or not that speeds it up. 2023-10-17 21:18:15 I assume the AVX instructions on an x86_64 will do integer or floating point calculations? 2023-10-17 21:50:43 GeDaMo: that book you linked looks like it's quite good. 2023-10-17 21:52:10 I still don't know how far I'll go toward supporting GPU computing from my Forth; it just looks like a real knot of complexity. But since I want to support arrays/vectors, I feel obligated to somehow support the AVX instructions. Those are more like "real instructions" and will likely "fit better" in a Forth architecture.