2023-01-27 00:50:25 <KipIngram   > Well, I've got a C program rolling that will load a bmp file with a font in it.  Loads it into a texture and displays it, using SDL2.
2023-01-27 00:51:00 <KipIngram   > Next step will be to not display it, but rather take a string and step through the chars, copying them to the display.
2023-01-27 00:51:10 <KipIngram   > Not too bad so far
2023-01-27 00:53:03 <KipIngram   > I think the rest is just a matter of specifying particular rectangle in the texture and the renderer, rather than NULL / NULL.
2023-01-27 00:53:50 <KipIngram   > The chars are all 16-wide, 32-high boxes.
2023-01-27 01:11:27 <KipIngram   > Hey - that works!  Copied a single char out of the texture.
2023-01-27 01:23:24 <Bobsyouruncle> Anyone around?
2023-01-27 01:27:49 <decay       > nope. nobody.
2023-01-27 01:52:54 <Bobsyouruncle> hey bud. if you're willing, may i ask you a question about ADC value and dBm? Trying to make heads or tails of this conversion but i dont know where to start.
2023-01-27 01:55:11 <Bobsyouruncle> https://youtu.be/A6Cc2nQInAU?t=300       how does this highly intelligent man get 1860 and 1330 for dBm? I will want to change it around and I dont know what strength the numbers will output. the RF logarithmic meter I'm using, AD8313, goes to -72dBm and he's got those numbers dialed in at -32dBm to -10dBm
2023-01-27 06:30:08 <veltas      > KipIngram: Nice
2023-01-27 07:32:04 <veltas      > Does anyone know where the old Forth Inc stuff would store the DOES> high-level code address in each instance?
2023-01-27 07:32:41 <veltas      > I know fig Forth just reserved an extra cell for it between the code pointer and actual parameter area on every CREATE definition, wondering if they did something else
2023-01-27 07:45:04 <KipIngram   > veltas: It's not perfect, though, because the font bmp has a background color.  So that has to match hte bg color "in use," or it look not quite right.
2023-01-27 07:45:30 <KipIngram   > For now I just made the whole window I was working with have the same bgcolor as the font bmp.
2023-01-27 07:46:05 <KipIngram   > But ideally you'd like for the stuff "around" the character pixels to be transparent.
2023-01-27 07:46:34 <KipIngram   > There's at least one alpha value in play, so it may be I can get it to do that.
2023-01-27 07:49:01 <MrMobius    > KipIngram: when I've worked with sprite stuff in the past, I've picked a sacrificial color and processed the BMP after loading to make that change color transparent
2023-01-27 07:51:06 <KipIngram   > Yes.
2023-01-27 07:51:18 <KipIngram   > There are enough colors around to give one up.  :-)
2023-01-27 07:51:58 <KipIngram   > Anyway, I figure I'm as good as there now - if I can call something from C I can call it from assembly.
2023-01-27 08:08:42 <veltas      > Alpha channel necessary for anything other than pixel art though
2023-01-27 08:13:14 <veltas      > Pixel art and rectangular shaped graphics I suppose
2023-01-27 08:21:42 <veltas      > I wonder how hard it is to actually render OTF or similar
2023-01-27 08:22:00 <veltas      > I'm not suggesting that because that would bog you down, but I just am wondering allowed
2023-01-27 09:12:46 <KipIngram   > Oh, no - comment away.  This is an area I'm pretty unfamiliar with.  Input is welcome.
2023-01-27 09:13:40 <KipIngram   > I'm always kind of miffed at how verbose this kind of code is.
2023-01-27 09:14:08 <KipIngram   > I'm sure a good bit of this I'll want to shove down under the hood in something I put together, so that it's easier to "just do" the stuff I'm actually interested in.
2023-01-27 09:14:32 <KipIngram   > I've been thinking about how to set up to support overlapping windows.
2023-01-27 09:15:10 <KipIngram   > I see a "stack" of windows with rectangle info in them, and a bit of code to take some screen update and run up through that stack whacking off parts of it that won't be visible because of other windows covering them up.
2023-01-27 09:15:35 <KipIngram   > I feel like I'd start with a rectangle, and then as I work my way up I'll gradually get a list of smaller rectangles that define the visible part of my original rectangle.
2023-01-27 09:16:03 <KipIngram   > I may find that some of that is already canned in SDL, though.
2023-01-27 09:16:11 <KipIngram   > Need to get more familiar with the details.
2023-01-27 09:19:13 <KipIngram   > On that little engine to create calculator menu structures, I'd thought I'd just write out what I wanted as a Python structure, but I'm also considering doing it as a text file - basically it's just a simple outline structure, where the indent level defines what level of the hierarchy an item goes on.
2023-01-27 09:19:22 <KipIngram   > Either way would work - haven't really decided yet.
2023-01-27 09:22:33 <KipIngram   > By the way, I do think that even after setting up this SDL stuff my Forth code will still have a word EXPECT, or ACCEPT in it.
2023-01-27 09:22:59 <KipIngram   > But rather than doing all the work itself, basically it's job will be to set some things that say that the tib is the target for keyboard events.
2023-01-27 09:23:29 <KipIngram   > It'll set that up, and then just wait for notification that the Enter key has been hit.
2023-01-27 09:30:39 <veltas      > Do you have any familiarity with something like win32?
2023-01-27 09:31:12 <veltas      > Do you just keep a window visible with IRC KipIngram or do you switch back and forth?
2023-01-27 09:31:36 <KipIngram   > No, no knowledge of this sort of proramming in Windows.
2023-01-27 09:32:01 <KipIngram   > I have on workspace running terminator, and I have it split into several panes of various sizes.
2023-01-27 09:32:08 <KipIngram   > My IRC is in the top left.
2023-01-27 09:32:33 <KipIngram   > And the client is running on a virtual server, so it's always on, and I connect to that with mosh, so I don't have to fret with re-connecting all the time.
2023-01-27 09:32:43 <KipIngram   > It behaves entirely as though it's a local always up session.
2023-01-27 09:32:47 <veltas      > So for one thing, text renderers tend to work within some masked region. This is because you need to draw text 'under' some window usually, and because it is more efficient to just stop when it runs off
2023-01-27 09:33:03 <KipIngram   > Right.
2023-01-27 09:33:09 <veltas      > I think renderers also tend to cache rendered glyphs to avoid drawing them each update
2023-01-27 09:33:32 <veltas      > So therefore you can start with bitmap rendering because that's required in the end anyway
2023-01-27 09:33:32 <KipIngram   > That would be the purpose of that algorithm running up the window stack - to pare down the block to update to what's actually visible.
2023-01-27 09:33:40 <KipIngram   > I may not have to do all of it - SDL may help some.
2023-01-27 09:34:14 <KipIngram   > Yeah, some kind of caching may be of interest.  I do intend, though, to have some kind of knowledge of "what's changed."
2023-01-27 09:35:27 <veltas      > The way window managers worked classically was to render everything on-demand. Individual windows would keep a buffer of more expensive graphics to render
2023-01-27 09:35:49 <KipIngram   > Makes sense.
2023-01-27 09:35:52 <veltas      > Windows would get events asking for an update in some region, up to the window to figure out how to daw
2023-01-27 09:35:55 <veltas      > draw*
2023-01-27 09:36:02 <veltas      > Of course there was the built-in stuff for drawing buttons etc
2023-01-27 09:36:10 <KipIngram   > Yes.
2023-01-27 09:36:10 <veltas      > And that can be done automatically by windows
2023-01-27 09:36:17 <veltas      > Windows* or whatever renderer
2023-01-27 09:36:31 <veltas      > This is the job GTK+ and Qt serve on Linux
2023-01-27 09:36:33 <KipIngram   > That makes sense - that would just be this process living more in the "canned" part of the system than in the application, and I'm in favor of that.
2023-01-27 09:36:49 <KipIngram   > The fewer hoops to jump at the app level the better I'll like it.
2023-01-27 09:37:10 <KipIngram   > The app shouldn't have to be aware that it's sharing the screen.
2023-01-27 09:37:22 <KipIngram   > It just offers the ability to paint regions when they need to be painted.
2023-01-27 09:37:30 <veltas      > Truthfully this is the right way to render, the modern way is more "keep everything alive all the time and my GPU hot, nobody ever rests a laptop on the top of their lap!"
2023-01-27 09:37:53 <KipIngram   > Well, the modern way is not necessarily the right way.
2023-01-27 09:41:06 <KipIngram   > As far as a console type behavior goes, that's going to live in a resizable, overlapping window environment, the best I've been able to come up with is to regard my screen content for a window as an array of lines, and the granularity of updates would be individual lines vertically and sections of lines horizontally.
2023-01-27 09:41:30 <KipIngram   > And I haven't decided whether to support wrapping or not - it's a complication.
2023-01-27 09:41:53 <veltas      > Wrapping is a good flag to support
2023-01-27 09:42:00 <KipIngram   > If a line won't fit across the window, I may just have it able to scroll that direction and only show the part of the line that fits.
2023-01-27 09:42:05 <KipIngram   > I know.
2023-01-27 09:42:08 <veltas      > As well as left-aligned, centre-aligned, and right-aligned
2023-01-27 09:42:16 <KipIngram   > I'll need to think more about how to implement it.
2023-01-27 09:42:23 <veltas      > Also vertical alignment
2023-01-27 09:42:41 <KipIngram   > Maybe it wouldn't be that hard - maybe I just need a way to give a line more vertical space.
2023-01-27 09:42:50 <veltas      > Also usually there is a right-to-left flag for foreign languages that need it
2023-01-27 09:43:01 <KipIngram   > Oh, I won't be doing that.
2023-01-27 09:43:07 <veltas      > And there is a right-to-left codepoint that can change order mid-sentence
2023-01-27 09:43:17 <KipIngram   > Unless it turns out just to be trivially easy.  I will keep it in mind.
2023-01-27 09:43:32 <veltas      > It is worth considering and not implementing
2023-01-27 09:43:41 <KipIngram   > yeah, that's the plan for now.
2023-01-27 09:43:53 <veltas      > If you want broadest application then eventually i18 is required
2023-01-27 09:44:03 <KipIngram   > At least that way I can make choices that are otherwise "arbitrary" based on what supports that the best.
2023-01-27 09:44:21 <veltas      > I mean i18n
2023-01-27 09:44:25 <KipIngram   > I'm really wirting this for me, though I'd have no objection to others using it.
2023-01-27 09:44:28 <KipIngram   > If it suits them.
2023-01-27 09:44:30 <veltas      > "internationalisation" = "i18n"
2023-01-27 09:45:12 <veltas      > You have to share it for other people to use it :P
2023-01-27 09:45:14 <KipIngram   > It's just a really slippery slope -that list of "things that are really important" can easily get very very long.
2023-01-27 09:45:21 <veltas      > Exactly
2023-01-27 09:45:26 <KipIngram   > And then you've got a monstrous amount of code.
2023-01-27 09:45:43 <KipIngram   > I'm already fairly amazed at how voluminous my EXPECT got.
2023-01-27 09:45:44 <veltas      > Well whatever you do, you can always work hard to simplify what you have
2023-01-27 09:45:48 <KipIngram   > Just with what it supports now.
2023-01-27 09:46:06 <KipIngram   > And having escape sequences available to do a lot of things for me.
2023-01-27 09:46:08 <veltas      > But it's worth having a rich EXPECT because you live there all day
2023-01-27 09:46:17 <KipIngram   > I agree with that principle.
2023-01-27 09:46:25 <KipIngram   > I've had that in mind myself.
2023-01-27 09:46:41 <KipIngram   > For one thing, I tried to give it features that would make it easy to implement a screen oriented block editor.
2023-01-27 09:48:30 <KipIngram   > But, for ME to live there all day doesn't require internationalization.
2023-01-27 09:49:05 <veltas      > Of course
2023-01-27 09:49:12 <KipIngram   > But I completely agree that it's all worth thinking about.
2023-01-27 09:49:31 <KipIngram   > And anything that's easy to capture, by sensible design, is worth doing.
2023-01-27 09:49:46 <veltas      > This guy made a simple terminal emulator with full unicode support to demonstrate that Windows Terminal is slower than it should be https://github.com/cmuratori/refterm
2023-01-27 09:49:52 <KipIngram   > I like trying to arrive at "most flexible designs."
2023-01-27 09:50:09 <KipIngram   > There's a real pleasure in finding an "elegant" way of making things work.
2023-01-27 09:50:09 <veltas      > That's an example of i18n not being a massive scope creep
2023-01-27 09:50:35 <KipIngram   > Oh, thanks.  That'll be interesting.
2023-01-27 09:51:04 <KipIngram   > Are you familiar with kitty?
2023-01-27 09:51:24 <KipIngram   > I'm pretty impressed with its feature set.
2023-01-27 09:51:47 <KipIngram   > It defines a protocol for delivering graphics to the console that I may take some cues from.
2023-01-27 09:52:26 <KipIngram   > Among other things, it can deliver them incrementally, and they get locally cached.  Then you can command their display and it's fast, since the data has already been sent over.
2023-01-27 09:52:47 <KipIngram   > Also, it uses the GPU for rendering, so there's probably stuff to learn there.
2023-01-27 09:52:54 <KipIngram   > It's FAST.
2023-01-27 09:52:55 <veltas      > https://sw.kovidgoyal.net/kitty/graphics-protocol/
2023-01-27 09:53:04 <KipIngram   > Right.  I liked that.
2023-01-27 09:53:26 <veltas      > I don't want my terminal touching my GPU
2023-01-27 09:53:40 <KipIngram   > Fair enough.
2023-01-27 09:53:44 <veltas      > So I don't like cmuratori's terminal or kitty
2023-01-27 09:54:09 <veltas      > st renders quite fast without GPU, but has no scrollback. tmux can solve that
2023-01-27 09:54:31 <veltas      > xterm is fine though, that's what I tend to use. Bloated but because it supports all these cool terminal protocols from yore
2023-01-27 09:55:01 <veltas      > Like xterm can render vector terminal protocols
2023-01-27 09:55:10 <KipIngram   > One thing that frustrates me a bit about GPUs (not that I think it could be done any better) is that here I am trying to design a super simple language, but there sits the GPU more or  less imposing a different language on me, if I want to use it in a general way.
2023-01-27 09:55:20 <KipIngram   > Can't use Forth to program my GPU.
2023-01-27 09:55:32 <KipIngram   > But I guess they had to come up with SOMETHING.
2023-01-27 09:56:10 <KipIngram   > Ultimately I'd like to have a way to do calculations on the GPU as well, since it's generally the fastest way we have of doing them.
2023-01-27 09:56:28 <veltas      > You could use forth with a GPU
2023-01-27 09:56:42 <veltas      > It depends on what you're trying to do
2023-01-27 09:57:15 <KipIngram   > I'm sure I can wrap a nice Forth interface around the graphics operations.
2023-01-27 09:57:26 <KipIngram   > I was referring to putting generic calculations on the GPU.
2023-01-27 09:57:35 <KipIngram   > And I can "wrapper" that too.
2023-01-27 09:57:45 <KipIngram   > But the code that the GPU RUNS has to come from somewhere too.
2023-01-27 09:58:29 <veltas      > You can do all of that with forth, but I don't think it's worth the effort of creating that or writing that kind of forth code
2023-01-27 09:59:12 <KipIngram   > Yeah - that's kind of what I meant.  It would be a major effort.
2023-01-27 09:59:15 <veltas      > If I remember rightly there's some kind of standard bytecode you're supposed to be able to pass to OpenGL for shaders
2023-01-27 09:59:24 <veltas      > So you could generate that
2023-01-27 10:00:13 <veltas      > Oh sorry it's not OpenGL, it's Vulkan
2023-01-27 10:00:16 <veltas      > SPIR-V
2023-01-27 10:00:18 <KipIngram   > My knowledge of it is pretty limited.  I've just looked at various examples.  I guess that's really source, though - I suppose it gets compiled into something, and I don't think I've seen that spec.
2023-01-27 10:00:45 <veltas      > https://en.wikipedia.org/wiki/Standard_Portable_Intermediate_Representation
2023-01-27 10:01:24 <veltas      > So you can generate SPIR-V with some kind of cross-forth compiler, that's not too hard, and then the GPU driver can convert SPIR-V for its native tongue
2023-01-27 10:01:44 <veltas      > And it will probably optimise it too so you can probably write really inoptimal code
2023-01-27 10:01:52 <veltas      > and get away with it
2023-01-27 10:01:58 <veltas      > I mean generate bad code and get away with it
2023-01-27 10:02:04 <KipIngram   > Ok, that's nice enough seeming.
2023-01-27 10:02:34 <KipIngram   > I'd like to do some work at the low level of the GPU, because that will get me more into how it's hardware actually works.  I just like working close to the hardware.
2023-01-27 10:02:59 <KipIngram   > Don't like black boxes.
2023-01-27 10:03:06 <veltas      > I think nvidia has got comprehensive low level documentation for their GPUs
2023-01-27 10:03:11 <veltas      > And intel
2023-01-27 10:03:16 <veltas      > Not sure about AMD
2023-01-27 10:03:26 <KipIngram   > Intel is what I've got.
2023-01-27 10:03:34 <veltas      > Intel has good documentation
2023-01-27 10:03:48 <veltas      > But to control at the low level you will need to have a kernel module or something probably
2023-01-27 10:04:07 <veltas      > You're passing up one set of black boxes for another
2023-01-27 10:04:29 <KipIngram   > That does seem to be the story of things these days.
2023-01-27 10:04:31 <veltas      > You can't win, write your own OS and you're relying on firmware black boxes to start the machine and run most of your controllers
2023-01-27 10:04:35 <KipIngram   > A huge stack of black boxes.
2023-01-27 10:04:56 <veltas      > Which is why I'm less interested in developing my own forth for intel gpu control :P
2023-01-27 10:05:00 <KipIngram   > This is why I've contemplated a full machine build, from absolute scratch.
2023-01-27 10:05:04 <KipIngram   > FPGAs.
2023-01-27 10:05:11 <veltas      > If you want low-level graphics maybe write using intel's CPU vector stuff
2023-01-27 10:05:14 <KipIngram   > My own processor, my own graphics, etc. etc.
2023-01-27 10:05:22 <veltas      > Then you're in total control, and get acceleration
2023-01-27 10:05:32 <veltas      > The vector stuff on intel was partly designed with multimedia in mind
2023-01-27 10:05:52 <KipIngram   > I'm glad you're around - there's so much stuff I just don't even know is out there.
2023-01-27 10:05:53 <veltas      > Much more portable
2023-01-27 10:05:57 <KipIngram   > And it's a big world.
2023-01-27 10:05:58 <veltas      > lol
2023-01-27 10:06:22 <veltas      > I work in the firmware trenches so I'm all too aware of this stuff
2023-01-27 10:06:35 <KipIngram   > Of course even working in x64 assembly there's still the processor firmware black box.
2023-01-27 10:06:42 <veltas      > Exactly
2023-01-27 10:06:43 <KipIngram   > I sure wish they'd let us program at that level.
2023-01-27 10:06:48 <veltas      > The CPU optimises your machine code
2023-01-27 10:06:57 <KipIngram   > I think we'd have seen a lot of innovation.
2023-01-27 10:07:02 <veltas      > If you want to actually control your CPU directly you need to go back to 8-bit era
2023-01-27 10:07:10 <KipIngram   > Yep.
2023-01-27 10:07:14 <veltas      > 16-it if you don't mind pipelining
2023-01-27 10:09:10 <veltas      > KipIngram: What I'm doing right now is writing a C forth, because then I can run forth and easily link in C libraries and do cool stuff mostly in forth
2023-01-27 10:09:24 <veltas      > Well I'm at work right now but when I'm clocked out
2023-01-27 10:09:43 <KipIngram   > Yeah.  I did one of those.  What threading?
2023-01-27 10:09:51 <veltas      > Indirect threading, old-school
2023-01-27 10:09:59 <KipIngram   > Oh nice.  gcc?
2023-01-27 10:10:03 <KipIngram   > Pointers to labels?
2023-01-27 10:10:09 <veltas      > Partly because it's a C forth but also because I want to support people learning with starting forth 1st ed
2023-01-27 10:10:15 <veltas      > GCC yeah
2023-01-27 10:10:31 <KipIngram   > I was pleased with how "thoroughly" I was able to make it "run like Forth should."
2023-01-27 10:10:34 <veltas      > But for any C compiler that supports stuff like simple return call optimisations
2023-01-27 10:11:02 <veltas      > Or whatever it's called when "CALL X; RET" gets turned into "JMP X"
2023-01-27 10:11:04 <veltas      > I forget
2023-01-27 10:11:19 <KipIngram   > The low level of that system was all pleasing to me - it just got rather hidious at the top level, because of the way I chose to use macros.
2023-01-27 10:11:22 <veltas      > Because I'm doing stuff like *calling* NEXT function to move around
2023-01-27 10:11:33 <KipIngram   > Interesting.
2023-01-27 10:11:39 <veltas      > I'm barely using macros, I'm assuming a compiler smart enough to inline
2023-01-27 10:11:51 <KipIngram   > No rocket science there in mine - just a standard NEXT implemented in a line of C.
2023-01-27 10:11:55 <veltas      > I'll *share* it when it's running
2023-01-27 10:13:00 <veltas      > But looks like I don't have an easy way of portably doing the smart DOES> optimisation, so might need to reserve an extra cell per-definition to support DOES>
2023-01-27 10:13:32 <veltas      > THat's why I was asking about how that works in old forth, it seems like black magic from the starting forth description of its internals
2023-01-27 10:13:49 <veltas      > But starting forth gets lots of small details wrong
2023-01-27 10:15:09 <KipIngram   > Yeah, if I recall correctly that did take an extra bit of info.
2023-01-27 10:15:29 <KipIngram   > I only had it in the defs that actually needed it.
2023-01-27 10:15:47 <veltas      > Only in CREATE defs?
2023-01-27 10:16:02 <veltas      > I think in one Forth I had a -CREATE that would not allocate the extra space
2023-01-27 10:16:14 <veltas      > In the standard only CREATE is assumed to work with DOES> to allow such optimisations
2023-01-27 10:16:17 <KipIngram   > No, I don't recall doing it at that level.  It's been a while.
2023-01-27 10:16:26 <KipIngram   > CREATE just made the basic standard def, though.
2023-01-27 10:16:37 <KipIngram   > I think DOES> added it.
2023-01-27 10:17:06 <veltas      > How can it do that if the data's already been allotted?
2023-01-27 10:17:29 <KipIngram   > Well, I don't think I supported actually having PLACED specific data there yet.
2023-01-27 10:17:38 <KipIngram   > I think it was just space, and I just adjusted the pointers.
2023-01-27 10:17:43 <veltas      > Well that's how it's allowed in starting forth
2023-01-27 10:17:52 <KipIngram   > Which probably was a shortcoming, now that you've got me thinking about it.
2023-01-27 10:18:03 <veltas      > Otherwise : CONSTANT , DOES> @ ; wouldn't work
2023-01-27 10:18:14 <veltas      > : CONSTANT CREATE , DOES> @ ; rather
2023-01-27 10:18:15 <KipIngram   > Yes, I'm seeing that now.
2023-01-27 10:18:39 <KipIngram   > I just didn't encounter that problem.  I only used CREATE, and then ALLOT in that part of the def.
2023-01-27 10:18:47 <KipIngram   > Damn it.
2023-01-27 10:19:03 <KipIngram   > I'm fairly glad I didn't later run into that problem - that would have been frustrating.
2023-01-27 10:20:11 <KipIngram   > It's probably been seven or eight years since I did that work.
2023-01-27 10:20:44 <KipIngram   > And I will need to be implementing DOES> again, so I better spend some time thinking about it.
2023-01-27 10:20:52 <veltas      > Sometimes I think "oh I got that wrong", go back and look and lo and behold I actually realised and fixed it years ago and forgot I fixed it
2023-01-27 10:20:56 <veltas      > Code is so bloody complicated
2023-01-27 10:21:37 <veltas      > Which is actually a reason to reinvent the wheel, because then you understand the considerations in the tools you use, and understand why they suck at some things and are good at others
2023-01-27 10:21:45 <KipIngram   > So, I haven't really thought this through - it just occurred to me.
2023-01-27 10:21:47 <veltas      > And whether it's just tradition or is a fundamental problem
2023-01-27 10:22:44 <veltas      > There are two ways of doing it I know about, both described in the excellent: https://www.bradrodriguez.com/papers/moving3.htm
2023-01-27 10:23:10 <KipIngram   > But what if there was a bit of code that would "chain" you?  When you see DOES>, you go back to the original header made by CREATE, and change the code pointer to point to this code, and the PFA pointer to point to wherever HERE is at that point (past your data).  Then you have another CFA/PFA pair there that executes the following definition?
2023-01-27 10:23:56 <veltas      > One is to over-allot CREATE, and the other is to generate CODE at the end of each DOES> definition you can use as the CFA which will run (:) and then the following high-level code
2023-01-27 10:24:27 <veltas      > Read Brad R's article if you haven't
2023-01-27 10:25:11 <veltas      > Starting from the "What's a code field" header
2023-01-27 10:25:23 <veltas      > The "Oops" stuff is just errata from previous articles
2023-01-27 10:38:51 <KipIngram   > Ok, I'm not seeing yet why this wouldn't work.  At least in my system, where I've got PFA pointers instead of having the parameter field data just follow the CFA.
2023-01-27 10:39:30 <KipIngram   > DOES> would go back and hijack the fields CREATE made to point at a new bit of code and at another set of fields - those would target the DOES> code and the item's data.
2023-01-27 10:40:14 <KipIngram   > I think you'd just need two new pointers per item and this new bit of code.
2023-01-27 10:41:51 <veltas      > If you have extra space allocated for each item to implement this then you've gone with option 1, which I described as "over allotting". I don't mean manual alotting, I just mean CREATE will leave room for a hidden parameter that would be used by DOES> to say where the high-level code is
2023-01-27 10:43:18 <veltas      > It's what Brad said fig Forth does
2023-01-27 10:44:01 <KipIngram   > I know.  What I'm doing is putting the new fields required after the allotted data.  The old fields direct you to them, and then they direct you to the right code and data.
2023-01-27 10:44:21 <veltas      > That sounds like more overhead for no benefit
2023-01-27 10:44:47 <KipIngram   > It adds an extra level of indirection, but it saves you spending the extra field in every defintion whether you need it or not.
2023-01-27 10:45:01 <KipIngram   > One might call that a benefit.  But yeah, there is a cost too.
2023-01-27 10:45:14 <KipIngram   > Your method would have higher performance.
2023-01-27 10:45:20 <veltas      > How do you say *where* the new fields are?
2023-01-27 10:45:30 <KipIngram   > The old PFA pointer points at them.
2023-01-27 10:45:37 <KipIngram   > The one that otherwise would point to the definition list.
2023-01-27 10:45:51 <veltas      > Okay so you have a PFA pointer
2023-01-27 10:45:55 <KipIngram   > Or at the data.
2023-01-27 10:46:05 <KipIngram   > Right - I mentioned that up there.  It would work in my system.
2023-01-27 10:46:09 <veltas      > The PFA pointer might as well point at the high-level colon def
2023-01-27 10:46:14 <KipIngram   > Woudln't work in an old FIG style system.
2023-01-27 10:46:51 <veltas      > No need for extra fields at the end
2023-01-27 10:47:07 <KipIngram   > Then how do you point at the item data?
2023-01-27 10:47:26 <KipIngram   > In a variable / CREATE word that pointer tells you where the data is.
2023-01-27 10:47:38 <veltas      > That's a good point, I see you have the chain separate from the data
2023-01-27 10:47:45 <KipIngram   > You've now got two things to point at - data and code.
2023-01-27 10:47:50 <veltas      > I'm not thinking in those terms
2023-01-27 10:47:53 <veltas      > Exactly
2023-01-27 10:47:53 <KipIngram   > So there's no way not to need at least one extra field.
2023-01-27 10:48:01 <veltas      > Yes but I think you need two
2023-01-27 10:48:04 <KipIngram   > My suggestion costs another one, because you have to find the new fields.
2023-01-27 10:48:24 <veltas      > You can't put these fields at the end of the data anyway, because that precludes allotting more after DOES> has executed
2023-01-27 10:48:28 <veltas      > Which is unfair
2023-01-27 10:48:38 <KipIngram   > Oh, good point.
2023-01-27 10:48:51 <veltas      > Maybe you can fit this with your chain data though?
2023-01-27 10:48:52 <KipIngram   > You're right - this word might have been used as a starting point for inherited behavior.
2023-01-27 10:49:11 <KipIngram   > Well, it could probably still be made to work somehow, but it begins to get klunky.
2023-01-27 10:49:15 <KipIngram   > memory management issue again.
2023-01-27 10:49:34 <KipIngram   > That's definitely a good point.
2023-01-27 10:49:59 <veltas      > Your headers are in a different place so you've essentially got some room there for out of band metadata anyway
2023-01-27 10:50:16 <KipIngram   > Yeah the way I've set things up does offer some interesting flexibility.
2023-01-27 10:50:33 <veltas      > At great cost
2023-01-27 10:50:38 <KipIngram   > The most prominnent of which is probably the fact that I can "vector" any existing word.
2023-01-27 10:50:49 <KipIngram   > Redefine it in a way that affects already compiled definitions.
2023-01-27 10:50:53 <KipIngram   > I just change that new pointer.
2023-01-27 10:51:28 <KipIngram   > And also lets my definitions butt right up against each other, so one cna execute right into another.
2023-01-27 10:52:08 <KipIngram   > The new changes I'm making on this next go round is to gather all those pointer pairs up into a tabular structure.
2023-01-27 10:52:28 <KipIngram   > Which means yet another pointer type thing somewhere.
2023-01-27 10:52:42 <KipIngram   > I'm going to use an index, but it's still an extra cell of storage required per word somewhere in the system.
2023-01-27 10:53:24 <KipIngram   > It'll actually be two tables - one for CFAs and one for PFAs, with the index tying them together.  That gives me heartburn, but the x64 instruction set won't let me  put them next to each other.
2023-01-27 10:53:50 <KipIngram   > Because the CFA pointer is going to be 64 bits, and 8 is the largest "built in multiplier" you can use in indexed storage access.
2023-01-27 10:54:27 <KipIngram   > But I will no longer have to add a base register to the initial CFA value - I'll be able to just jump indirect through the CFA field.
2023-01-27 10:54:31 <KipIngram   > Without fetching it.
2023-01-27 10:54:52 <KipIngram   > I'll have pre-added the base address to all of 'em.
2023-01-27 10:56:40 <KipIngram   > So far I'm still planning the PFA pointer as 32 bits, but there might be advantages to uprading it as well.
2023-01-27 10:56:51 <KipIngram   > I'm sure there would be, but maybe just not as compelling to me.
2023-01-27 10:56:58 <KipIngram   > Got a meeting - back in a bit.
2023-01-27 11:27:44 <KipIngram   > Well, that was nice.  Just had my second half 2022 performance evaluation.  I was a little nervous that a couple of failures to check all of the "red tape" boxes was going to get me dinged, but my manager just waved them away and told me I was being my own harshest critic.  Turned out be a positive thing all the way.
2023-01-27 11:27:55 <KipIngram   > So nice - that's that worry put to bed for another half year.
2023-01-27 11:28:23 <KipIngram   > I've never really been a fan of the formalities of this system we use - it always feels like it has emphasis on things that just really aren't related to the work.
2023-01-27 11:28:44 <KipIngram   > Got some good kudos for getting us shifted over to that new hardware platform for our drive testing last fall.
2023-01-27 11:30:19 <KipIngram   > Man, I'm not seeing any good way around that extra field on everything now that you've pointed out the need to be able to expand the allot area.
2023-01-27 11:30:49 <KipIngram   > And I'm a little annoyed I ever failed to see that necessity in the first place.
2023-01-27 11:31:23 <thrig       > hindsight (seeing the future) is a bit tricky as you have to try to look behind you
2023-01-27 11:32:21 <KipIngram   > This is a constraint on Forth that you run now and again on multiple fronts - there is only one place to put new stuff.  HERE.
2023-01-27 11:32:40 <KipIngram   > Forth just doesn't give you "smooth" access to any other part of memory.
2023-01-27 11:34:13 <KipIngram   > Actually, wait a minute.
2023-01-27 11:34:24 <KipIngram   > In this new system I'm planning things may be fine.
2023-01-27 11:34:33 <KipIngram   > Because I'm adding a new region anyway.
2023-01-27 11:34:50 <KipIngram   > These pointers are going to go in a separate memory range from where data and definition lists will go.
2023-01-27 11:34:57 <KipIngram   > That will solve the problem, won't it?
2023-01-27 11:35:53 <KipIngram   > However, I'll have to allocate the pointer elements associated with the entire next index to this purpose.
2023-01-27 11:35:59 <KipIngram   > Even if not that much is required.
2023-01-27 11:37:28 <KipIngram   > Actually I think they all will be used.
2023-01-27 11:37:41 <KipIngram   > So words defined with such defining words will consume two indices instead of one.
2023-01-27 11:38:47 <KipIngram   > One of the PFAs will point to the DOES> code definition list; the other will point to the data.  The primary CFA will point to new code designed to handle this situation, and the extra CFA will point to the code that CREATE or CONSTANT or whatever initially specified.
2023-01-27 11:39:13 <KipIngram   > Nothing has to point to "the new pointers," because they will always just be "the next index."
2023-01-27 11:43:29 <KipIngram   > Of course there is a way to do this in any system that would mirror how you do it manually.  You could go and construct the equivalent of this:
2023-01-27 11:43:49 <KipIngram   > CONSTANT foo 100 ALLOT DOES> ...code... ;
2023-01-27 11:43:52 <KipIngram   > would become
2023-01-27 11:44:20 <KipIngram   > : foo-code ...code... ;
2023-01-27 11:44:31 <KipIngram   > CONSTANT (foo) 100 ALLOT
2023-01-27 11:44:42 <KipIngram   > : foo  (foo) foo-code ;
2023-01-27 11:45:15 <KipIngram   > That's sort of a maximum overhead approach - anything clever would be aimed at reducing that cost.
2023-01-27 12:16:16 <Stalevar    > https://github.com/s-macke/starflight-reverse
2023-01-27 12:19:36 <KipIngram   > Ah, fun.
2023-01-27 12:25:33 <nature      > 'sup KipIngram !
2023-01-27 12:27:29 <nature      > Have you made any progress on your side?  I am currently trying to think a bit about strings and chars literals.
2023-01-27 12:30:19 <nature      > I am not really too keen on biting the bullet and implementing dynamic memory..  Although I really liked working with the $tring wordset from gforth, so that would be my ideal in terms of string facilities
2023-01-27 12:54:25 <KipIngram   > I did implement dynamic memory in an earlier system I wrote.
2023-01-27 12:54:43 <KipIngram   > It was quite simple - it was a fixed page size allocator that had a free  list and a "ceiling" variable.
2023-01-27 12:55:02 <KipIngram   > The allocate call would return a page from the free list, if there was one.  Otherwise it would nudge the ceiling up one page and return that.
2023-01-27 12:55:30 <nature      > How big were your pages?
2023-01-27 12:55:32 <KipIngram   > Free just popped the page being freed onto the return list, though it would at least check and see if it was the page immediately below ceiling, in which case it would draw ceiling back down.
2023-01-27 12:55:40 <KipIngram   > I used 4k, but you could set them to anything.
2023-01-27 12:55:56 <KipIngram   > What I think I may do next time is something similar to that but with large blocks - say 1 MB.
2023-01-27 12:56:10 <KipIngram   > And then  have a second level of memory management that can allocate out of each 1 MB block.
2023-01-27 12:56:27 <KipIngram   > The constraint would be that each 1 MB block would have a fixed smaller page size, but it could vary from block to block.
2023-01-27 12:56:44 <KipIngram   > And I'm going to use a ropes data structure to organize within blocks.
2023-01-27 12:57:02 <KipIngram   > That looks like it will let me support dynamically resizable arrays.
2023-01-27 12:57:26 <KipIngram   > Even just the simple fixed page allocator I did before was useful.
2023-01-27 12:57:34 <KipIngram   > I called the words HEAP and -HEAP.
2023-01-27 12:58:13 <KipIngram   > Anyway, the point I'd like to make is that adding that first simple layer is pretty straightforward and requires very little code.
2023-01-27 12:58:21 <nature      > so HEAP would try to allocate a page? aka either remove one page from the return list of bump the ceiling right?
2023-01-27 12:58:29 <KipIngram   > Yes.
2023-01-27 12:58:38 <nature      > okok, that sounds doable
2023-01-27 12:58:45 <KipIngram   > It's very doable.
2023-01-27 12:58:49 <KipIngram   > Just a few short Forth lines.
2023-01-27 12:58:58 <nature      > I am trying to minimize complexity in my system as much as possible
2023-01-27 12:59:00 <KipIngram   > Though by rights those should be primitives for performance.
2023-01-27 12:59:16 <KipIngram   > Yes, and I chose not to do that on the system I have in my hands right now.
2023-01-27 12:59:27 <nature      > I didn't know you could have relatively efficient dynamic memory so simply
2023-01-27 12:59:35 <KipIngram   > It really wasn't the allocator itself that ran me into trouble - I started thinking of too many clever ways to use it and I let it get out of hand.
2023-01-27 13:00:12 <nature      > But so you think the allocator should have opcodes then?
2023-01-27 13:00:18 <KipIngram   > So I haven't yet figured out this SDL2 transparency color yet.
2023-01-27 13:00:38 <KipIngram   > It definitely looks like there should be a way for me to identify a color as the the "transparent" color.  But I haven't pushed the magic button yet.
2023-01-27 13:01:19 <KipIngram   > Apparently a commonly chosen transparent color is red=0xFF, green=0, blue=0xFF.
2023-01-27 13:01:28 <KipIngram   > I've seen it called "magic pink."
2023-01-27 13:02:01 <KipIngram   > And apparently this is much higher performance that having full alpha channel in your image.
2023-01-27 13:02:14 <KipIngram   > Per pixel alpha, that is.
2023-01-27 13:02:24 <thrig       > https://wiki.libsdl.org/SDL2/SDL_SetColorKey
2023-01-27 13:02:26 <nature      > You could also have fg and bg buffers for your screen, and the "black" of the fg is transparent
2023-01-27 13:03:13 <nature      > But I am not exactly sure if this is relevant to you, I haven't dived much into SDL2 yet
2023-01-27 13:05:55 <nature      > I on my side have managed to get some sort of metaprograming/immediate words going on, since my editor is the compiler/assembler, the editor actually runs an instance of the vm itself and feeds it the yellow words as they come along
2023-01-27 13:06:28 <KipIngram   > This page:
2023-01-27 13:06:30 <KipIngram   > https://www.gamedev.net/forums/topic/214487-sdl-bmp-transparency/
2023-01-27 13:06:53 <KipIngram   > makes it look almost trivial.  Unfortunately, that symbol SDL_SRCCOLORKEY gets spit on by the compiler when I try it.
2023-01-27 13:07:06 <KipIngram   > And if it requires an additional include file, I haven't identified it yet.
2023-01-27 13:07:43 <nature      > Is it a macro maybe?
2023-01-27 13:11:06 <nature      > https://github.com/libsdl-org/SDL/search?q=SDL_SRCCOLORKEY
2023-01-27 13:11:17 <nature      > That's true, nowhere to be found...
2023-01-27 13:13:31 <KipIngram   > Oh, I got it.
2023-01-27 13:13:39 <KipIngram   > I had a couple of lines out of order.
2023-01-27 13:14:12 <KipIngram   > I was modifying the surface I'd read the character font into, to give it a transparent color.  But I was creating a texture from it BEFORE I did that modification.
2023-01-27 13:14:18 <KipIngram   > I just swapped those lines and now it works.
2023-01-27 13:16:17 <KipIngram   > nature: What I'm doing here is sending the entire font table over to the GPU as a texture.  Then I can copy arbitrary rectangles from that texture to the screen, at arbitrary locations.
2023-01-27 13:16:47 <KipIngram   > It's a 16-wide, 32-tall font, so finding the right character rectangle is just an indexing process.
2023-01-27 13:21:14 <KipIngram   > (I just used SDL_TRUE for that pesky symbol - it was just a flag).
2023-01-27 13:27:50 <KipIngram   > Wow - this is cool:
2023-01-27 13:27:52 <KipIngram   > https://www.nature.com/articles/d41586-023-00202-1
2023-01-27 13:30:15 <nature      > Really looks like a firework
2023-01-27 13:31:13 <nature      > and got it, I am not sure how deep I'll get into SDL, I mostly want to use it to provide a screen to my system and then let my system take care of drawing pixels
2023-01-27 13:33:38 <KipIngram   > The code to do this simple test is here:
2023-01-27 13:33:40 <KipIngram   > https://pastebin.com/WQWQCp2G
2023-01-27 13:36:13 <nature      > Oohh that's interesting, but doesn't it rely on a lot of SDL internal stuff?
2023-01-27 13:36:45 <nature      > Also do you have a name/term for your simple memory allocator?
2023-01-27 13:40:12 <KipIngram   > Oh, no, not really a name.  It just so simple it hardly deserves one.
2023-01-27 13:40:33 <KipIngram   > I never thought to name it.
2023-01-27 13:41:13 <KipIngram   > And yes, that certainly relies on a lot of internal SDL stuff; that's kind of the point.  I've always resisted linking libraries of any kind into my Forth, but I do want to be able to do graphics this time, and it's going to require SOMETHING.
2023-01-27 13:41:20 <KipIngram   > SDL is just what I've gravitated to.
2023-01-27 13:41:37 <KipIngram   > So I'll link it in, and write suitable Forth wrappers that I come up with.
2023-01-27 13:42:07 <KipIngram   > I probably will NOT try to support SDL in a "completely general way" - I'll "decide" some things and the wrappers will be thusly hard coded, to hide more detail from the application level.
2023-01-27 13:42:17 <nature      > Sure, same for me, but I feel the less I rely on SDL the more "portable" my system would be.
2023-01-27 13:42:39 <KipIngram   > I know, but I guess I'm swallowing the "can't have my cake and eat it too" pill here.
2023-01-27 13:43:21 <nature      > But the texture for the font seems like a pretty good idea to get easy font rendering for relatively low complexity
2023-01-27 13:44:54 <KipIngram   > Yes, it seems like the most straightforward way to do it.
2023-01-27 13:45:10 <nature      > https://wiki.xxiivv.com/site/ufx_format.html
2023-01-27 13:45:19 <KipIngram   > You could do variable width fonts too, but you'd need a table then, to tell you where all the character rectangles were and how big they were.
2023-01-27 13:45:30 <KipIngram   > For a fixed width font you can just compute where to grab from.
2023-01-27 13:45:38 <nature      > In uxn they use some kind of custom font format which is an "array" of sprites
2023-01-27 13:46:12 <nature      > So I guess you end up with the same kind of idea of an "index onto a texture"
2023-01-27 13:46:55 <nature      > uxn does variable width, they store an initial table of width
2023-01-27 13:51:14 <Zarutian_iPad> nature: welcome to the wotld of blittable bitmap fonts
2023-01-27 13:52:57 <nature      > haha I need to learn what blittable means then :D
2023-01-27 13:53:56 <Zarutian_iPad> world*
2023-01-27 16:23:50 <KipIngram   > So, the calculations to work a console with this look like they're pretty trivial, especially if the character dimensions are powers of two.
2023-01-27 16:24:42 <KipIngram   > And as for the screen coordinates, that's just x+=16 each character (for the font I'm using now) and y+=32 for each new line.
2023-01-27 16:25:15 <KipIngram   > The routine that has to be called is SDL-RenderCopy().
2023-01-27 16:25:32 <KipIngram   > Sorry; SDL_RenderCopy()
2023-01-27 16:26:34 <KipIngram   > One call per char.  Then when it's time to show what you've done, there are two calls: SDL_RenderPresent() and SDL_UpdateWindowSurface().
2023-01-27 19:00:07 <KipIngram   > You know,  implementing a flashin cursor will be a little... fun.
2023-01-27 19:00:20 <KipIngram   > On a screen where one can click around with a mouse and move the cursor?
2023-01-27 19:00:37 <KipIngram   > It seems straightforward, but there will be a good bit to it.
2023-01-27 19:13:44 <KipIngram   > It's complicated by the fact that some of the characters reach all the way to both edges of the rectangle.
2023-01-27 19:14:14 <KipIngram   > So putting the cursor up there, even a thin vertical one, will oleave you needing to know the character that was there to put it back.
2023-01-27 19:14:36 <KipIngram   > My understanding is that fetching that data from the GPU is to be avoided.  So you'll have to find it in a record you have on the CPU side.
2023-01-27 20:35:23 <KipIngram   > Well, I added a tad of machinery to that test program so that it writes a string now.
2023-01-27 20:35:39 <KipIngram   > Slightly more pleasing that just one fixed character.
2023-01-27 21:58:54 <KipIngram   > veltas: Let me make sure I understood you correctly earlier.  You were describin the process that system+application go through in overlapping windows environments.  Did you tell me that it's usually done by having the system request that the application redraw specific regions of the screen?
2023-01-27 21:59:51 <thrig       > x11 at a pretty low level does that
2023-01-27 22:00:00 <KipIngram   > If so, does that mean the application has to be able to do that for everything it draws?  E.g., say the app has drawn a line.  If an overlapping window cuts off part of that line, does that mean the app has to be able to calculate the line that reaches right up to the edge of that window and draw that?
2023-01-27 22:00:19 <KipIngram   > And similarly with every single structure it knows how to draw?
2023-01-27 22:00:29 <KipIngram   > That sure seems to be putting a lot of the burden on the application.
2023-01-27 22:01:06 <KipIngram   > What seems like it would be "more right" to me would be for the app to be able to behave as though it had the entire screen to itself, and the system would handle all the cropping and other such business, behind the scenes.
2023-01-27 22:01:40 <KipIngram   > What if the overlapping window covers half of a character?
2023-01-27 22:01:45 <KipIngram   > How does an app draw that?
2023-01-27 22:02:53 <KipIngram   > What I'm trying to be careful about right now is making sure I don't make decisions based on thinking about console windows that then will burn me later when I want to draw more involved things, like real graphics.
2023-01-27 22:03:17 <KipIngram   > Consoles are simpler - you just have nice neat rows of text; nothing going at funny angles and having odd shapes and so on.
2023-01-27 22:04:04 <KipIngram   > But man, I'm not sure I think a system that requires apps to truncate their own content to odd arbitrary shapes is a very good design.
2023-01-27 22:05:24 <KipIngram   > Certainly in the case of multiple text windows I think I could push a lot of the work down into the guts of the system.
2023-01-27 22:16:55 <crc         > KipIngram: I believe X requires the application to be able to redraw portions of the window on request.
2023-01-27 22:17:43 <KipIngram   > I'm open to the idea that there might be no good way around that for fully general graphics apps.
2023-01-27 22:18:02 <crc         > This would be part of the Expose event
2023-01-27 22:18:22 <crc         > https://magcius.github.io/xplain/article/x-basics.html might be helpful
2023-01-27 22:18:33 <KipIngram   > The thing is, though, at some point in time (when it first drew it) the app TOLD the system what was on the screen there.
2023-01-27 22:18:38 <KipIngram   > Why doesn't the system remember?
2023-01-27 22:19:45 <KipIngram   > It feels like that's the system abdicating part of its responsibility.
2023-01-27 22:20:07 <KipIngram   > Which in my opinion should be to provide me with a "virtual screen" that isn't disrupted by other users.
2023-01-27 22:21:18 <KipIngram   > Maybe in the old days when RAM was dear I'd get it, but these days it should just have my whole bitmap somewhere.
2023-01-27 22:23:43 <KipIngram   > Do they mean that rigorously, in that I "must not" draw outside the specified portion, or if I chose to could I just redraw the whole thing and they'd throw away what they didn't need?
2023-01-27 22:24:05 <KipIngram   > I'd feel a bit better about it if it were a "draw at least this" requirement, just because they didn't save it.
2023-01-27 22:24:23 <KipIngram   > Maybe it's  not reasonable for them to save it all - I guess some really high res screens take multiple gig of space.
2023-01-27 22:24:27 <KipIngram   > That's not a small amount.
2023-01-27 22:24:58 <KipIngram   > I the application have the logic that knows how to PRODUCE that bitmap, so...
2023-01-27 22:25:05 <crc         > RAM is part of it, X goes back quite a ways to when RAM was much more restrictive. The other part might relate to the client/server nature; no reason to have the local system duplicate resources already used on the application server
2023-01-27 22:25:09 <KipIngram   > if it must be produced again, it makes sense for me to do it.
2023-01-27 22:25:40 <KipIngram   > Maybe the boundary restrictions are just "hints"?
2023-01-27 22:26:07 <crc         > I've not looked into this extensively yet. The Expose event gives you a rectangle area that you are supposed to provide.
2023-01-27 22:26:11 <KipIngram   > I mean, I could be malicious - surely they won't let me draw outside my boundaries.
2023-01-27 22:26:59 <KipIngram   > But what I had in mind for multiple consoles was basically that when the app wrote to the console, the system would remember that on a "canvas" of some kind, that the user had sized initially.
2023-01-27 22:27:40 <KipIngram   > It would have all of the canvasses, and it would know the window positions, including vertical stacking order, and owuld be perfectly capable of grabing the right parts of the right canvases to redraw the whole screen.
2023-01-27 22:30:51 <KipIngram   > If the system had to redraw the whole screen it would have a function it could pass a line number to, and it would get back a list: columns 1-n1 from canvas A, cols n1+1 to n2 from canvas d, etc.  All the way across the line.
2023-01-27 22:31:10 <KipIngram   > And then it would just do that list.
2023-01-27 22:31:17 <KipIngram   > Loop thorugh the lines.
2023-01-27 22:32:47 <KipIngram   > These canvases wouldn't be bitmaps - they'd be character buffers.
2023-01-27 22:33:21 <crc         > You might be able to have the server remember the pixels to display using PutImage and CopyArea on an Expose request. I haven't tested this though.
2023-01-27 22:33:55 <KipIngram   > Yeah, I guess it would be good not to have to needlessly send the data over a slow link again.
2023-01-27 22:34:16 <KipIngram   > I was talking earlier about how kitty will let you slip images over incrementally, so they're ready when you want to show them.
2023-01-27 22:36:55 <crc         > I don't do a lot of graphical stuff
2023-01-27 22:37:54 <crc         > I have one system with a framebuffer based display with a text console and some drawing primitives; it uses SDL2
2023-01-27 22:38:25 <KipIngram   > That's kind of the direction I'm going.
2023-01-27 22:38:31 <crc         > I'd like to eventually get it to work w/X directly, but that'll be a quite slow process
2023-01-27 22:41:11 <KipIngram   > I was just fretting a little earlier that the recent work I did supporting utf8 collides with this in a not very fun way.
2023-01-27 22:41:43 <KipIngram   > It's easy enough to slap a 16x16 char image over there on the GPU and then index it to get rectangles to draw.
2023-01-27 22:42:01 <KipIngram   > But utf8 is much more far-flung thing, and right now my text consol "just handles" all of that for me somehow.
2023-01-27 22:43:05 <KipIngram   > The utf8 chars I'd be interested in (APL chars, mostly) aren't nearly so tidy and compaactly organized.
2023-01-27 22:43:35 <KipIngram   > It's really kind of a nasty can of worms.
2023-01-27 22:46:00 <KipIngram   > According to wikipedia, there are certain code pages that were set up to handle this.
2023-01-27 22:46:07 <KipIngram   > Like code pages 909 and 910 here:
2023-01-27 22:46:09 <KipIngram   > https://en.wikipedia.org/wiki/Digital_encoding_of_APL_symbols
2023-01-27 22:46:36 <KipIngram   > That would rather handle the output side, but nonetheless hte keyboard would still give me the multi-byte utf8, and I'd somehow have to map.
2023-01-27 22:51:09 <Stalevar    > Bee-see-dick
2023-01-27 22:51:55 <Stalevar    > KipIngram, you can use J which uses ASCII but otherwise similar to APL
2023-01-27 22:52:37 <KipIngram   > I quite like the symbols.
2023-01-27 22:52:49 <KipIngram   > Much prefer them over the verbose styles.
2023-01-27 22:53:24 <KipIngram   > Even before I looked into APL my Forth word names tended toward terse symbolic names.
2023-01-27 22:54:05 <KipIngram   > % instead of mod, & instead of and, etc.
2023-01-27 22:54:40 <Stalevar    > J uses symbols
2023-01-27 22:54:58 <Stalevar    > It only uses words for things like while
2023-01-27 22:55:14 <Stalevar    > but combinators and things are symbolic
2023-01-27 22:58:57 <crc         > I've set aside my work on utf8 for now; I'm not liking variable length encodings
2023-01-27 22:59:23 <Stalevar    > At least UTF-8 is relatively easy to decode
2023-01-27 22:59:58 <Stalevar    > utf8() { for code in "$@"; do dc -e '2 6^sb[Pq]sq?dlb2*>q[dlb%lb2*+rlb/d2 Az-^!>t]dstxlb4*2 8z3--^-+[Pz0<p]dspx'<<<"$code"; done; echo; }
2023-01-27 23:00:09 <Stalevar    > Here is my utf8 encoder in shell-func
2023-01-27 23:00:33 <crc         > My system is 32-bit addressed, so I'll be looking into utf32 in the future
2023-01-27 23:00:45 <Stalevar    > $ utf8 {33..47} {58..64} {91..96} {123..127}
2023-01-27 23:00:45 <Stalevar    > !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~
2023-01-27 23:01:07 <Stalevar    > For example this command generates list of all special chars in ASCII
2023-01-27 23:02:45 <Stalevar    > $ utf8 {1040..1103}
2023-01-27 23:02:46 <Stalevar    > АБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯабвгдежзийклмнопрстуфхцчшщъыьэюя
2023-01-27 23:02:59 <Stalevar    > Or this one prints basic Cyrillic set
2023-01-27 23:04:47 <Stalevar    > KipIngram, do you think UTF-8 encoder in Forth would look better?
2023-01-27 23:05:11 <crc         > Stalevar: what shell is that for?
2023-01-27 23:05:17 <Stalevar    > bash
2023-01-27 23:05:28 <Stalevar    > But the core is  dc -e '2 6^sb[Pq]sq?dlb2*>q[dlb%lb2*+rlb/d2 Az-^!>t]dstxlb4*2 8z3--^-+[Pz0<p]dspx'
2023-01-27 23:05:41 <Stalevar    > The rest is just wrapper feeding decimal codes one by one to it
2023-01-27 23:06:42 <Stalevar    >  utf8() { for code in "$@"; do utf8print_1char <<<"$code"; done; echo; }
2023-01-27 23:09:23 <crc         > works on my linux system (I don't have bash on my main systems); thanks
2023-01-27 23:10:32 <Stalevar    > fu() { for x in `printf '%x ' $*`; do echo -en "\u$x"; done; echo; }
2023-01-27 23:11:11 <Stalevar    > This one is faster, but I like stuff I wrote more
2023-01-27 23:11:50 <Stalevar    > $ utf8 65536
2023-01-27 23:11:50 <Stalevar    > 𐀀
2023-01-27 23:12:03 <Stalevar    > Also utf8 handles stuff way beyond basic plane
2023-01-27 23:12:15 <Stalevar    > $ fu 65536
2023-01-27 23:12:15 <Stalevar    > က0
2023-01-27 23:12:24 <Stalevar    > While fu doesn't
2023-01-27 23:12:30 <KipIngram   > Stalevar: I don't really know; I just modified my Forth enough to accept utf8 sequences from the keyboard and feed them back out to the screen.
2023-01-27 23:12:35 <Stalevar    > Though I guess it can be modified by replacing u with U
2023-01-27 23:12:43 <KipIngram   > There's not really utf8 "intelligence" in the thing to speak of.
2023-01-27 23:13:01 <Stalevar    > But keyboards do not emit UTF-8...
2023-01-27 23:13:09 <KipIngram   > My stack cells hold 8 bytes, so shoving a whole utf8 sequence into key's output is no problem.
2023-01-27 23:13:17 <Stalevar    > They emit some scancodes which are usually within one byte
2023-01-27 23:13:42 <Stalevar    > yeah, UTF-8 can only be up to six bytes long
2023-01-27 23:13:49 <KipIngram   > Maybe some do, but when I type a utf8 char on my keyboard KEY gets several bytes.
2023-01-27 23:13:50 <Stalevar    > But actually only up to four bytes
2023-01-27 23:13:59 <KipIngram   > Yes, no more than 4 for utf8.
2023-01-27 23:14:38 <Stalevar    > They might assign stuff to higher combos when they run out of million codepoints UTF-16 can fit
2023-01-27 23:14:40 <KipIngram   > I just made a few changes in my system to check those higher bytes after calling KEY; if they're there and I'm building a string, I put them all in the string.
2023-01-27 23:15:02 <Stalevar    > What is KEY?
2023-01-27 23:15:02 <KipIngram   > EMIT does hte same - if it's got nonzero bytes in the high part it emits all of them.
2023-01-27 23:15:08 <KipIngram   > emits and shifts until nothing is left.
2023-01-27 23:15:50 <KipIngram   > And I had to modify EXPECT in certain ways, because a one-char cursor move no longer necessarily corresponded to a one-byte buffer move.
2023-01-27 23:16:21 <KipIngram   > That took a few days to work out.
2023-01-27 23:16:25 <Stalevar    > $ dc -e 1468369091346906868067365692907786P
2023-01-27 23:16:25 <Stalevar    > Hello, world!
2023-01-27 23:16:35 <Stalevar    > i like this feature of dc
2023-01-27 23:17:00 <Stalevar    > P command can print arbitrarily large numbers as characters
2023-01-27 23:17:27 <KipIngram   > Nifty.
2023-01-27 23:17:47 <Stalevar    > $ dc -e 78055613996680264584089217100707267768769388778365194P
2023-01-27 23:17:48 <Stalevar    > Привет, мир!
2023-01-27 23:18:02 <KipIngram   > My EXPECT can also handle embedded escape sequences (for color, attributes, etc.).
2023-01-27 23:18:30 <KipIngram   > It doesn't currently know how to insert them or delete them, but if they're in the string already, it will skip over them as I move the cursor.
2023-01-27 23:19:10 <KipIngram   > I don't every plan to "type" those; after I have function key support I'll use those to insert color/attribute changes.
2023-01-27 23:22:29 <Stalevar    > KipIngram, also that's how I get those numbers:
2023-01-27 23:22:31 <Stalevar    > $ echo 'Hello, world!' | xxd -p -u | dc -e '16i?p'
2023-01-27 23:22:31 <Stalevar    > 1468369091346906868067365692907786
2023-01-27 23:23:09 <KipIngram   > Oh, hey - that works on my system too.
2023-01-27 23:23:15 <Stalevar    > Though essentially P prints the number in base-256 system
2023-01-27 23:23:33 <KipIngram   > Ok, my Forth can't do that.
2023-01-27 23:23:38 <KipIngram   > I only go up to base 62.
2023-01-27 23:23:42 <KipIngram   > 0-9, A-Z, a-z.
2023-01-27 23:23:52 <Stalevar    > this is a special case
2023-01-27 23:24:05 <KipIngram   > Up through base 36 it's case insensitive.
2023-01-27 23:24:37 <KipIngram   > I'd type a base 62 number like 62:12zA4q
2023-01-27 23:24:38 <Stalevar    > $ dc -e 256o1468369091346906868067365692907786p
2023-01-27 23:24:38 <Stalevar    >  072 101 108 108 111 044 032 119 111 114 108 100 033 010
2023-01-27 23:24:53 <Stalevar    > dc can handle systems up to base 999
2023-01-27 23:25:04 <Stalevar    > or even base 1000?
2023-01-27 23:25:10 <KipIngram   > Interesting limit for a computer.
2023-01-27 23:25:24 <KipIngram   > Is it storing the individual digits?
2023-01-27 23:25:37 <KipIngram   > Of the base spec I mean.
2023-01-27 23:25:53 <Stalevar    > $ dc -e 65536o1468369091346906868067365692907786p
2023-01-27 23:25:54 <Stalevar    >  18533 27756 28460 08311 28530 27748 08458
2023-01-27 23:26:00 <Stalevar    > Actually I was wrong, it can do this
2023-01-27 23:26:10 <KipIngram   > My system would probably do SOMETHING if I tried a larger than 62 base, but I don't know if it would have any consistency.
2023-01-27 23:26:37 <KipIngram   > There's some noodly code in there to cut out the characters ranges (9, A) and (Z, a).
2023-01-27 23:26:48 <KipIngram   > Which was surprisingly hard to get right, by the way.
2023-01-27 23:27:01 <KipIngram   > I just kept on finding cases that were slipping through my net.
2023-01-27 23:27:04 <Stalevar    > $ dc -e 17o1468369091346906868067365692907786p
2023-01-27 23:27:04 <Stalevar    >  14 16 07 12 11 15 05 00 13 11 13 14 01 02 11 12 07 06 03 14 02 05 00\
2023-01-27 23:27:05 <Stalevar    >  16 13 12 15
2023-01-27 23:27:37 <Stalevar    > KipIngram, dc starts to represent super-digits as sequences of decimal digits from base17
2023-01-27 23:28:02 <KipIngram   > I see.
2023-01-27 23:28:05 <Stalevar    > $ dc -e 60o5000p
2023-01-27 23:28:05 <Stalevar    >  01 23 20
2023-01-27 23:28:19 <KipIngram   > Ok.
2023-01-27 23:28:40 <Stalevar    > This can be useful in case like this. Say, 5000 seconds is one hour twenty-three minutes twenty seconds
2023-01-27 23:28:54 <KipIngram   > I read somewhere that the Sumerians (who used base 60) had better values for various astronomical things than we do, as a consequence of that base.
2023-01-27 23:29:19 <Stalevar    > Their system wasn't truly base-60 though
2023-01-27 23:29:21 <KipIngram   > I assume it's just that they could come closer to the right value of things like the ratio of the year length to the month lenght, etc. with any given number of digits.
2023-01-27 23:29:56 <KipIngram   > Which makes sense - if you s plit something into 60 pieces an integer number of pieces can get closer to arbitrary values than with a 10-split.
2023-01-27 23:30:04 <KipIngram   > The deltas are six times smaller.
2023-01-27 23:30:48 <KipIngram   > Using three digits their worst case error would be like 200 times smaller.
2023-01-27 23:31:01 <Stalevar    > But yeah, 60 is a good number for a numeric base, because it's divisible by 2, 3, 4, 5, 6, 10, 12, 15, 20 and 30
2023-01-27 23:31:14 <KipIngram   > yes.
2023-01-27 23:31:33 <KipIngram   > But man, your times table would be fun, wouldn't it?
2023-01-27 23:32:06 <Stalevar    > Actually, time tables already use 60-base system, don't they?
2023-01-27 23:35:03 <Stalevar    > KipIngram, large base systems are not very good in a sense because their 'digits' require multiple signs, or it would be very hard to remember 60 distinct digits
2023-01-27 23:35:10 <Stalevar    > Base-12 would be a good compromise
2023-01-27 23:35:14 <KipIngram   > Well, I just mean you'd have 3600 facts to learn.
2023-01-27 23:35:36 <KipIngram   > Yes, exactly.
2023-01-27 23:35:48 <KipIngram   > And even harder to remember (number of signs)^2 multiplication facts.
2023-01-27 23:36:19 <Stalevar    > Ah, I kinda mixed up time table and times table
2023-01-27 23:36:29 <KipIngram   > AH!
2023-01-27 23:36:31 <KipIngram   > Now I get it.
2023-01-27 23:36:53 <KipIngram   > But hey, just think of all the folks who get by counting on their fingers who would fall through the cracks if we used base 12.
2023-01-27 23:37:20 <Stalevar    > Base-12 allows counting by fingers, and it even requires just one hand
2023-01-27 23:37:34 <Stalevar    > thumb is pressed to phalanx of other fingers
2023-01-27 23:37:38 <KipIngram   > Yeah, I know there are ways to do that.
2023-01-27 23:38:09 <KipIngram   > You ever messed around with an abaqus much?  Beyond just the extreme basics that a lot of people know?
2023-01-27 23:38:16 <KipIngram   > You can take square roots and stuff on those things.
2023-01-27 23:38:28 <KipIngram   > I don't actually "know it," but I've read a bit about it.
2023-01-27 23:39:15 <Stalevar    > You can take square roots without abacus
2023-01-27 23:39:18 <KipIngram   > Folks who are truly good at it can do some crazy fancy things.
2023-01-27 23:39:36 <Stalevar    > Abacus is just a clutch for one's mind
2023-01-27 23:39:46 <KipIngram   > Oh, also (not really related, but something made the neuron fire), do you know about Cordic algorithsm?
2023-01-27 23:39:46 <Stalevar    > Everything which can be done on it can be done without
2023-01-27 23:40:00 <KipIngram   > Sure - it's just a memory device.
2023-01-27 23:40:01 <Stalevar    > Nope
2023-01-27 23:40:12 <Stalevar    > But I know Newton method of square rooting
2023-01-27 23:40:16 <KipIngram   > Cordic algorithms are good for computer calculation of trigonometric functions.
2023-01-27 23:40:24 <Stalevar    > Binary search
2023-01-27 23:40:26 <KipIngram   > Yeah, Newton works well for that.
2023-01-27 23:40:34 <Stalevar    > For example we want 127 root
2023-01-27 23:40:43 <KipIngram   > it actually works well in general; you can find some trouble cases, but for most things it converges and converges fast.
2023-01-27 23:41:00 <Stalevar    > 10 squared is 10, 11 squared is 121, 12 squared is 144, so we already know it's 11 something
2023-01-27 23:41:09 <KipIngram   > I'm gonna go with 11.2.
2023-01-27 23:41:49 <KipIngram   > Heh.   Looks like the answer is 11.27.
2023-01-27 23:41:59 <Stalevar    > actually, (a+b)²=a²+2ab+b²
2023-01-27 23:42:10 <KipIngram   > Of course?
2023-01-27 23:42:37 <Stalevar    > So if we take a as 11, then 22*b+b²=6
2023-01-27 23:42:52 <Stalevar    > So 11 6/22 is a good approximation
2023-01-27 23:43:10 <KipIngram   > that is nice.
2023-01-27 23:43:24 <KipIngram   > I just started with 11^2=121 and "gut felt" the rest.
2023-01-27 23:43:25 <Stalevar    > Let;s take 6/20, which is 0.30
2023-01-27 23:43:28 <Stalevar    > 11.3 so
2023-01-27 23:43:30 <KipIngram   > But that ^^ is nifty.
2023-01-27 23:43:42 <KipIngram   > It's related to a picture I imagine when doing mental math.
2023-01-27 23:43:51 <KipIngram   > If I know N^2, then I picture that as an NxN grid.
2023-01-27 23:44:01 <Stalevar    > Yeah, but with Newton method we can use binary search
2023-01-27 23:44:08 <KipIngram   > Then I add N for a new row on top, N for a new column along the side.
2023-01-27 23:44:13 <KipIngram   > But that misses the corner, so add one more.
2023-01-27 23:44:25 <KipIngram   > And that's (N+1)^2.
2023-01-27 23:44:40 <KipIngram   > Fairly easy to do with 2 rows, 2 columns and +4 as well.
2023-01-27 23:44:56 <KipIngram   > Or you can go to N-1 or N-2, except then you've double-counted the corner so you subtract it.
2023-01-27 23:45:24 <KipIngram   > I guess you know the trick for squaring a number that ends in five?
2023-01-27 23:45:43 <KipIngram   > N5*N5 = (N+1)*N 25
2023-01-27 23:46:00 <KipIngram   > Like 45*45 = 2025 - 20 is 5*4.
2023-01-27 23:46:29 <KipIngram   > So it's easy to square numbers ending in 5, and eeasier to square numbers ending in 0.
2023-01-27 23:46:57 <Stalevar    > I guess it makes sense, either way you can do it without abacus
2023-01-27 23:47:15 <Stalevar    > Arithmometer is a more interesting device, I even was thinking about getting one
2023-01-27 23:47:20 <KipIngram   > The (N+1)^2 = N^2 + 2N + 1 thing, and it's (N-1)^2 analog (or my imagined grid) gets you numbers ending in digits in between.
2023-01-27 23:47:34 <Stalevar    > KipIngram, do you know those mechanical calculators?
2023-01-27 23:47:46 <Stalevar    > They can multiply and divide with relative ease
2023-01-27 23:50:17 <KipIngram   > Well, of course I know there are such calculators.
2023-01-27 23:50:28 <KipIngram   > I don't really know exactly how they work, unless it's by repeated subtraction.
2023-01-27 23:50:35 <KipIngram   > Or addition.
2023-01-27 23:57:31 <Stalevar    > KipIngram, yeah, repeated additional but with caret being able to move
2023-01-27 23:58:11 <Stalevar    > So if you want to multiply 32345 by 4523 you'd only need to rotate the handle 4+5+2+3=14 times instead of four thousand times
2023-01-27 23:58:32 <Stalevar    > and it has rotation counter so you can easily keep track of  rotations