12:20:31
##forth
<KipIngram>
Regarding all the performance and profiling related stuff, these days I tend to not really think in those terms. For most of what I do any of these things are "fast enough," and I think when I do care about performance it'll be to do with things like numerical analysis and so on, where it's pretty clear what parts of things need optimizing. I'm rather more interested in "cognitive load" - I value
12:20:34
##forth
<KipIngram>
Forth because I view it as a simpler language that's easier to "hold in my mind," and I attach a lot of value to having written it myself so that are no parts of it that are "black boxes" I don't understand and have to putz around with for hours to get working because I'm not quite sure how it's supposed to be used. Forth is simple, clear, and easy to understand, so I don't really care that it's
12:20:35
##forth
<KipIngram>
not the fastest kid on the block.
12:21:56
##forth
<KipIngram>
Not that C itself is "hard to understand," but once you bring libraries in then that's a pile of stuff to learn that likely doesn't do QUITE what I want it to, so I have to code around that "not quite."
12:22:07
##forth
<veltas>
Up early?
12:23:19
##forth
<KipIngram>
I guess. It's about when I get up every day.
12:23:47
##forth
<KipIngram>
I actually regard it as a good night's sleep - sometimes these days I wake up earlier (too early) and can't get back to sleep. This is fine.
12:24:17
##forth
<KipIngram>
I can putz about, sip coffee, and so on now until I go jog around 8am.
12:24:24
##forth
<KipIngram>
Gets too hot later in the day.
12:24:46
##forth
<tpnix>
KipIngram, I firmly believe that C is fine on the PC ( I released a general purpose eprom and micro burner using it, along with the hardware design in 1999) but I think that C is a poor choice for embedded compared to Forth
12:25:21
##forth
<KipIngram>
I definitely regard Forth as the ideal embedded tool.
12:25:35
##forth
<tpnix>
KipIngram, I find I do my best work when I 'wake up early' which is often at 1am
12:26:07
##forth
<KipIngram>
I'm usually not quite that early, but fairly frequently I wind up up at 2:30 or 3:00.
12:26:17
##forth
<tpnix>
Im definitely at my smartest at those times, it's quiet and peaceful
12:26:24
##forth
<KipIngram>
Which means I just got four or five hours of sleep, which isn't ideal.
12:26:37
##forth
<KipIngram>
It is quiet and peaceful.
12:27:05
##forth
<KipIngram>
It's fairly quiet most of the time these days, though - all the kids are grown and out of the house now.
12:27:31
##forth
<tpnix>
what I often do is stay up to 5am, then walk to 5:45 for exercise and then go back top bed until 9 or 10
12:27:59
##forth
<KipIngram>
I don't think I could do that, but maybe if I'd woken up at 1am I could.
12:28:16
##forth
<KipIngram>
Usually once I'm a certain amount awake in the morning that's that.
12:28:23
##forth
<tpnix>
it works out fine for me, I get lots of rem sleep that way
12:28:40
##forth
<KipIngram>
Yes, I bet so. Seems like it would lead to more dreams?
12:28:53
##forth
<KipIngram>
I don't dream much, so I usually find it interesting when I do.
12:28:55
##forth
<tpnix>
I dont see it as 'wasting the morning' as I already enjoyed the sunrise while walking
12:29:06
##forth
<KipIngram>
Certainly.
12:29:53
##forth
<tpnix>
Ive had to develop this technique as I get older because I seemed to need less sleep
12:30:27
##forth
<tpnix>
and if I lay in bed when I wake at say 1 - 3 am, I often cant get back to sleep anyway
12:30:27
##forth
<KipIngram>
Me too - as far as I can tell that's fairly common.
12:30:35
##forth
<tpnix>
yeah, seems so
12:31:04
##forth
<tpnix>
the reason I I cant get back to sleep is my mind is so active at that time
12:31:15
##forth
<KipIngram>
Yes - exactly. Same here.
12:31:41
##forth
<tpnix>
but after a few hours of design and them exercise, I fall asleep no problem
12:31:57
##forth
<veltas>
If you can get a nap after your exercise then you're doing better than a lot of people your age
12:32:12
##forth
<KipIngram>
So, I decided I need to pause a beat and think through some of this text input stuff a bit. I want to support bash style command history in this stuff. In the past I've bolted that on later, but I think it will go better if I plan out exactly how that's all going to work, so I know how to stub it into the preliminary stuff.
12:32:52
##forth
<tpnix>
veltas, really? I had no idea
12:33:08
##forth
<tpnix>
KipIngram, yeah, you gotta have readline imho
12:33:19
##forth
<veltas>
I've known some elderly people who will just sit in bed and don't sleep because they've got nothing else to do
12:33:22
##forth
<KipIngram>
Previously it's just been "per session," but I'd really like to have a way to name histories so I can connect a new session to one.
12:33:24
##forth
<veltas>
Watch TV
12:33:46
##forth
<KipIngram>
So that brings in disk related stuff in some fashion. I don't want to write all that immediately, but I feel like I need to see how it's going to tie in.
12:33:46
##forth
<tpnix>
KipIngram, I have readline compliments of a python wrapper that a guy on my channel made
12:33:56
##forth
<veltas>
Better to exercise if you rise early and then if you nap after you've obviously done something good
12:35:00
##forth
<KipIngram>
So QUERY's main job will be navigating those histories - for the actual line handling it'll just call that EDIT word I mentioned.
12:35:28
##forth
<KipIngram>
And I think it won't call EXPECT as I've had it do in the past - EXPECT is generic and won't hook into the history.
12:36:06
##forth
<KipIngram>
But it will also use EDIT.
12:37:01
##forth
<KipIngram>
EDIT is basically my readln, but one that I can point at arbitrary RAM buffers.
12:37:29
##forth
<KipIngram>
And that can work on buffers that are already initialized.
12:38:09
##forth
<veltas>
EDIT is probably useful for making a text editor
12:38:19
##forth
<veltas>
Can pre-load buffer with content I guess?
12:38:21
##forth
<KipIngram>
Hugely.
12:38:35
##forth
<veltas>
I want something like that for my Forth, just not got around yet
12:39:00
##forth
<KipIngram>
What I found good last time was to let it work on a multi-line buffer. It only shows you the one line you're editing, but it moves the full buffer content around appropriately.
12:39:06
##forth
<veltas>
It's definitely a good benefit / cost ratio because 99% of the code is there already, but as you say EXPECT hides this
12:39:14
##forth
<KipIngram>
So for a block editor it would manage everything from the line being edited to the end of the block.
12:39:37
##forth
<KipIngram>
Move all the rest around as I enter and delete characters in my line.
12:39:47
##forth
<veltas>
Interesting
12:39:52
##forth
<veltas>
I'd have to see it to understand
12:39:53
##forth
<KipIngram>
Won't let any real content be pushed out of the block.
12:40:09
##forth
<veltas>
Did you see my ZX Spectrum text editor?
12:40:17
##forth
<KipIngram>
No, I don't think so.
12:40:35
##forth
<KipIngram>
I've been absent quite a while until recently.
12:41:00
##forth
<KipIngram>
Cool - I will take a gander.
12:46:19
##forth
<KipIngram>
I mean for this system to support multiple processes, and when a process dies all of its resources need to be released. Any RAM buffers allocated, any child processes killed, etc. I'm planning to support an ability for part of the process's RAM to be used as a Lisp style "cons pool." Good place to store lists of stuff like allocated buffers, child processes, and so on, and likely also good for
12:46:21
##forth
<KipIngram>
things I haven't thought of yet.
12:46:45
##forth
<KipIngram>
And simple, because those are fixed size things so a fixed size allocator handles it. And those are really easy to write in Forth.
12:47:14
##forth
<KipIngram>
And a process will only allocate such a pool if it's going to need it.
12:47:27
##forth
<KipIngram>
And will size it per its needs too.
12:48:31
##forth
<KipIngram>
I plan to make the payload size variable; different pool for different needs, but the same code for all of them.
12:49:20
##forth
<KipIngram>
So I'm turning it around a little from Lisp - in Lisp the payload is usually first, with the pointer at the end. I'm putting the pointer first, and then the payload can be whatever size I decide.
12:50:43
##forth
<KipIngram>
Another use for it will be for shared vocabularies being used. I plan for each public vocabulary to sit in its own RAM block. It'll have a reference count, and processes using it will have a list of such vocabularies, so when the process dies I can go decrement all the reference counts. Deallocate the vocabulary if no one's using it anymore.
12:50:57
##forth
<KipIngram>
Sort of my equivalent to dll's.
12:51:41
##forth
<KipIngram>
Just loaded from source instead of as binaries.
12:52:18
##forth
<KipIngram>
So a process can LOAD one of those; if it's not present yet it'll get compiled then, but if it is it'll just get referenced.
12:53:20
##forth
<veltas>
Basically an operating system
12:53:20
##forth
<KipIngram>
But non-public vocabularies will compile in the process's own dictionary as usual.
12:53:51
##forth
<KipIngram>
Yes, it is an operating system. I plan to have it run under Linux, but also be able to start up via UEFI and really BE the operating system.
12:54:20
##forth
<KipIngram>
Or run on some other embedded platform.
12:54:51
##forth
<KipIngram>
Those will all need different ways of doing certain things, but the core system itself I want to be the same across the board.
12:56:26
##forth
<veltas>
If you start with a C VM then porting to all those is quite trivial
12:56:27
##forth
<KipIngram>
My understanding is that UEFI makes a frame buffer available, and when running under Linux I can get a frame buffer from SDL also.
12:56:48
##forth
<veltas>
I'd actually probably guess it's easy to get something started with ChatGPT or the like for UEFI if you've not done it before
12:56:57
##forth
<KipIngram>
Yes, only that VM layer should need to be rewritten. And of course hardware differences will need addressing.
12:57:01
##forth
<veltas>
Rather than trying to read the docs because they're not incredibly well organised
12:57:24
##forth
<veltas>
That's just my opinion, I've written UEFI stuff before
12:57:25
##forth
<KipIngram>
Yeah, I use ChatGPT in that way. It can be pretty helpful.
12:57:32
##forth
<KipIngram>
Good sounding board for ideas, I've found.
12:57:50
##forth
<veltas>
I wrote a UEFI shell tool for flashing BIOS at work
12:58:18
##forth
<KipIngram>
I'll use it's keyboard services too initially, but ultimately I want key press/release events, which will mean programming the keyboard controller in the UEFI context.
12:58:28
##forth
<KipIngram>
But SDL gives me those as part of what it does.
12:58:43
##forth
<veltas>
Yeah makes sense to use SDL on Linux
12:59:07
##forth
<KipIngram>
I decided I liked plan9's Acme, but I want to shift it toward more keyboard centric operation rather than heavy mouse reliance.
12:59:26
##forth
<KipIngram>
With key press/release events I can do things like double tap shift and control keys, do chords, etc.
12:59:26
##forth
<veltas>
I've not got far with acme
12:59:39
##forth
<veltas>
Bjarne Stroustrup likes it
12:59:50
##forth
<KipIngram>
Well, I haven't USED it either - so I might find out it's not all I think it might be.
13:00:53
##forth
<veltas>
Bjarne Stroustrup yelled at Kernighan or someone once for poo-pooing C++
13:00:56
##forth
<KipIngram>
Just reading descriptions of it makes it seem like it could be useful.
13:01:05
##forth
<KipIngram>
Oh dear.
13:01:22
##forth
<KipIngram>
They're just thinking from different places.
13:01:27
##forth
<veltas>
It's just funny now, C++ didn't do so bad in the end
13:02:14
##forth
<veltas>
At risk of Stroustrup yelling me, I get why people weren't universally enthusiastic about C++
13:03:02
##forth
<KipIngram>
I don't know enough about it to really have an opinion. I know "kinda sorta what it is" and that's about it.
13:03:31
##forth
<KipIngram>
I've used some of its simpler mechanisms, like the io streams, but I've really never done "real OO programming."
13:04:41
##forth
<KipIngram>
So my thinking right now is that any process that wants to do console I/O will have a console output structure, that looks to it like it owns the whole screen. Then a single process will be responsible for rendering the frame buffer, drawing information from all the processes that have screen tiles assigned.
13:05:07
##forth
<KipIngram>
The only feedback in the other direction will be tile width, so that processes can handle wrapping if they want to.
13:05:53
##forth
<KipIngram>
I want multiple "screens" I can cycle around among, with each one potentially tiled.
13:06:36
##forth
<veltas>
Am I allowed to say the P word on here?
13:06:51
##forth
<veltas>
Because this reminds me of PolyForth
13:06:55
##forth
<KipIngram>
I've been struck by how our console interface stuff is still 50 years old. We even still call them "tty." And there's just this huge chasm betwen that and "GUI." I feel like there may be value in that "in between land," where console sessions can have some more extensive access to graphical output.
13:07:14
##forth
<veltas>
I keep saying this
13:07:40
##forth
<veltas>
Although that magic in-between land is called the 'web'
13:07:42
##forth
<KipIngram>
:-) You can say anything you want as far as I'm concerned. And very well could be - I tend not to know a lot about stuff already out there. I just sit around and ponder this stuff, and I'm sure most of what I come up with has already been done.
13:08:27
##forth
<veltas>
I'm so glad that we can all go buy a computer that can do so much for so little now
13:08:36
##forth
<KipIngram>
Yeah, I feel like the whole GUI thing had a big marketing factor in it - they deliberately wanted something "totally new," so we never got a smooth evolution from the old ways to the new. The world just piled onto the GUI train whole-hog.
13:08:52
##forth
<KipIngram>
And that console side has just sat there in stasis the whole time.
13:09:16
##forth
<KipIngram>
Oh, heck yes. It's remarkable what we can get so easily.
13:10:34
##forth
<KipIngram>
Another observation about it all - when PC's first appeared, we really did seem to get a transition toward PERSONAL computing for a while. But then it turned around and these days it seems like they're trying to pull everything back under central control again. We still have the processing power in our hands, but more and more it's controlled by "others."
13:11:18
##forth
<KipIngram>
Not by legal mandate or anything like that, but just by "what software is available."
13:11:56
##forth
<KipIngram>
Our "personal" computer operating systems put up walls that cut us off from most of our hardware, etc.
13:12:19
##forth
<KipIngram>
The UEFI version of this thing will run in ring 0 all the time with the whole thing laid at my feet.
13:12:29
##forth
<veltas>
I think really personal computing is still there for all of us
13:13:17
##forth
<KipIngram>
If I want to diddle around with my hardware in some way, I don't want my operating system to tell me no.
13:13:28
##forth
<veltas>
There's uncertainty though, like I feel like Linux might go downhill if Rust takes over
13:14:05
##forth
<KipIngram>
Yeah - I don't know the details, but I have noticed a few headlines that make it seem like there's some dissatisfaction with Rust.
13:15:09
##forth
<KipIngram>
Linux is written with the idea in mind that there will be a bunch of mutually distrusted users on the computer. That's just not going to be the case in my situation, so I don't want any of that security stuff.
13:15:33
##forth
<KipIngram>
My computer - let me do anything I damn well please, with as little friction as possible.
13:16:08
##forth
<KipIngram>
If I shoot myself in the foot, that's my problem. Don't "protect" me.
13:18:19
##forth
<veltas>
Basically KipIngram if you write a decent OS in one language and then someone says they need to rewrite it all in another language, that creates a lot of work and friction
13:18:41
##forth
<veltas>
And instead of just saying "no" to the request Linus is humouring it but not really doing anything decisive so it's just burning a lot of people out
13:18:56
##forth
<veltas>
Unless they're going to rewrite it (a terrible idea) they might as well not bother
13:19:25
##forth
<veltas>
It sort of indicates that Linus is losing his edge
13:19:29
##forth
<KipIngram>
I agree.
13:19:42
##forth
<KipIngram>
If it works don't fix it.
13:19:54
##forth
<veltas>
The edge that used to admittedly upset and bully people but nevertheless was capable of steering the ship out of rocks
13:20:21
##forth
<KipIngram>
Yeah, good leaders are rarely always popular with everyone.
13:20:34
##forth
<KipIngram>
Because it involves saying "No" when it needs to be said.
13:20:48
##forth
<veltas>
He does sometimes say things that go too far, however it's worth bearing in mind just the sheer amount of time he's been online
13:21:07
##forth
<veltas>
I mean you put anyone in front of media all day every day and they'll say some less thought out things
13:21:14
##forth
<veltas>
He's not perfect and doesn't claim to be
13:21:17
##forth
<KipIngram>
I remember plenty of times one or another of my peeps would come to me with what was actually a fairly good idea, but good in isolation and not really compatible with the big picture situation.
13:21:44
##forth
<KipIngram>
But usually they couldn't see that far - that was actually what I earned my money doing. All they saw was that I was blocking their great idea.
13:22:12
##forth
<KipIngram>
I guess that's inevitable, though, when so many of the folks are fairly junior.
13:22:24
##forth
<veltas>
Unfortunately I think the overly critical and sensitive culture out there has ground Linus down, as it has to many public figures
13:22:40
##forth
<KipIngram>
Yes, the world's a mess in that way at the moment.
13:22:50
##forth
<veltas>
I think it's getting better, at least in my bubble
13:22:56
##forth
<veltas>
Seems like people are getting over themselves a bit
13:23:07
##forth
<KipIngram>
We've improved a whole lot of stuff in the world, but not everything for sure - some of the changes are negative ones in my opinion.
13:23:25
##forth
<veltas>
Also having kids has been good because that basically prevents you from being able to have time to worry about pointless nonsense online
13:23:42
##forth
<KipIngram>
That's for sure - they bring you new priorities.
13:23:59
##forth
<veltas>
People my age who don't have kids are basically like children still
13:24:03
##forth
<KipIngram>
Now that I've finally swept work under the rug, the kids and grandkids are really what it's all about.
13:24:17
##forth
<veltas>
They complain about stuff that I think I literally couldn't imagine worrying about, I just don't have time
13:24:23
##forth
<KipIngram>
I believe that - becoming a parent is one of the most "maturing" things you can do.
13:25:11
##forth
<KipIngram>
And you see them being fairly stupid about things and realize "God, that was me back then..."
13:26:13
##forth
<KipIngram>
BTW, I'm actually planning to write this using nasm, not C.
13:26:36
##forth
<KipIngram>
With that Python "meta" thing on top - the Python will actually output the nasm file.
13:27:21
##forth
<veltas>
Good luck
13:27:42
##forth
<KipIngram>
When it comes time to try to meta-compile it, I may have to rewrite in Forth some of the parts that are actual nasm assembly in the meta file, but all of the parts that are straight Forth I hope will just carry over unchanged.
13:28:27
##forth
<KipIngram>
I actually wrote a bit of Forth a while back that could assemble quite a lot of x64 instructions, but the assembly format was "rpn-ized" copared to what one would write in nasm.
13:28:42
##forth
<KipIngram>
Whereas in the meta file I'm just writing straight nasm format instructions.
13:29:25
##forth
<KipIngram>
It might turn out, though that mostly all I nedd to do to convert it is drop the commas and move the opcode to the end instead of the beginning.
13:29:54
##forth
<KipIngram>
It helps a lot that for writing a Forth you don't need anything like all of the x64 instruction set. Just a small core of it.
13:30:14
##forth
<KipIngram>
That whole thing is a monstrosity.
13:34:05
##forth
<veltas>
Hey as long as you understand it and want to do it that way
14:28:06
##forth
<MrMobius>
the problem with C++ is which C++?
14:28:39
##forth
<MrMobius>
seems like they tried to cram 10 different mini languages into one thing
14:30:02
##forth
<KipIngram>
That's about working with UEFI.
15:46:14
##forth
<veltas>
That's not "bare metal" though lol
15:46:17
##forth
<veltas>
UEFI is basically an OS
15:46:54
##forth
<KipIngram>
Well, I think of it more like a BIOS.
15:47:05
##forth
<veltas>
Likewise BIOS wasn't bare metal
15:47:10
##forth
<KipIngram>
And you're right - that's not truly bare. It's close enough to suit me, though.
15:47:25
##forth
<KipIngram>
I don't really feel like having to figure out every piece of hardware in my machine.
15:47:26
##forth
<veltas>
I'm just reacting to the video saying it's "bare metal"
15:47:44
##forth
<KipIngram>
Especially since it would then need to be done all over again (potentially) if I got a new computer.
15:48:39
##forth
<KipIngram>
"bare metal" may be the wrong phrase, but the distinction I'm talking about is that that "other" code runs only when I call it to do something, rather than having tons of stuff going on in the background all the time.
15:49:09
##forth
<KipIngram>
It's subroutines I call - not an "environment I run under."
15:49:30
##forth
<KipIngram>
So, I don't know what the perfect phrase for that would be.
15:50:33
##forth
<KipIngram>
But I see it as a clear distinction between something like BIOS/UEFI vs. something like Linux or Windows.
15:52:13
##forth
<KipIngram>
For graphics, I'll really just be using it to set stuff up, and after that I'll manipulate the frame buffer directly. For keyboard, I'll use it for a while, but I do plan to program the keyboard controller to get press/release events. The disk i/o, on the other hand, I'll likely use UEFI for long-term. Not in a file sort of way, though, even though I think it does that (FAT) - I'll just use it
15:52:16
##forth
<KipIngram>
to read and write raw blocks.
15:52:25
##forth
<KipIngram>
And networking I'll use it for long-term.
15:52:53
##forth
<KipIngram>
It does appear that it's basically single core. It gives me a way to start the other cores up, but those other cores aren't allowed to call into the UEFI.
15:53:24
##forth
<KipIngram>
I was already planning to have dedicated processes handle most of that stuff, though - those processes can just run on the original core, and offer my own service layer to the other cores.
15:58:04
##forth
<veltas>
I don't think there's an objective distinction, UEFI is basically an OS
16:00:08
##forth
<KipIngram>
Surely you see what I mean. It seems plenty objective to me. In the UEFI case, that code will run only if I call it. I'm in charge of when it runs. With what I call on "OS," the os is sitting there running stuff all the time that I have no control over, sopping up my processor cycles. How is that not an objective distinctionN?
16:00:31
##forth
<KipIngram>
s/on/an/
16:00:36
##forth
<veltas>
I mean I'd say Forth was an OS too
16:00:41
##forth
<veltas>
They're not the same sure
16:00:51
##forth
<KipIngram>
Yeah, I think Forth can be thought of that way.
16:00:57
##forth
<KipIngram>
It's capable of it.
16:01:25
##forth
<KipIngram>
And when I run this same thing under Linux, it'll be somewhat like "an os in an os."
16:01:41
##forth
<KipIngram>
I do plan to "run applications" within it, and those won't be aware of the Linux layer.
16:02:14
##forth
<veltas>
You might find the UEFI runs stuff you can't stop that is actually slower than Linux
16:02:52
##forth
<KipIngram>
Maybe - I don't really know.
16:02:59
##forth
<KipIngram>
We'll find out.
16:03:18
##forth
<veltas>
And your firmware can run secret stuff when the OS is running too
16:03:32
##forth
<KipIngram>
But yeah - it did occur to me that just using UEFI doesn't necessarily stop Big Brother style monitoring - there's really no telling what they've crammed in there.
16:03:40
##forth
<veltas>
All part of modern systems unfortunately
16:03:45
##forth
<KipIngram>
It's just as untrustworthy as anything else.
16:03:57
##forth
<KipIngram>
Yeah, extremely unfortunate.
16:04:09
##forth
<KipIngram>
And it kind of blows my mind that no one seems to care.
16:04:31
##forth
<KipIngram>
Long as they can update their Facebook and so on.
16:05:01
##forth
<veltas>
Most of it is just inefficient waste of power and CPU time
16:05:12
##forth
<veltas>
I don't think it's spying on us
16:05:26
##forth
<veltas>
Can't prove it's not though so that's not good either
16:06:00
##forth
<KipIngram>
Another thing I find annoying is start up times. Our computers are thousands of times faster than they were when we first got them - they ought to be fully on and ready to run by the time you get your finger off of the power button.
16:06:21
##forth
<KipIngram>
And certainly by the time you've settled your hands onto the keyboard.
16:06:32
##forth
<veltas>
Ideally you want Linux or whatever OS is active running your computer 100% and firmware should hand off just 'instructions' on how to access root devices etc
16:06:54
##forth
<KipIngram>
That would be a good scheme, yes.
16:07:03
##forth
<veltas>
That's actually how things are on e.g. PowerPC and some ARM systems
16:07:39
##forth
<veltas>
Not in Intel land though