2023-10-19 00:54:31 <KipIngram   > Anyone know how to resolve something like this?
2023-10-19 00:54:34 <KipIngram   > /usr/include/SDL2/SDL_surface.h:72:16: note:   no known conversion for argument 1 from ‘SDL_Surface*’ to ‘const SDL_Surface&’
2023-10-19 00:54:35 <KipIngram   > /usr/include/SDL2/SDL_surface.h:72:16: note: candidate: ‘constexpr SDL_Surface& SDL_Surface::operator=(SDL_Surface&&)’
2023-10-19 00:54:37 <KipIngram   > /usr/include/SDL2/SDL_surface.h:72:16: note:   no known conversion for argument 1 from ‘SDL_Surface*’ to ‘SDL_Surface&&’
2023-10-19 01:40:21 <KipIngram   > ok, I figured out that there's a function SDL_SetClipRect() that will limit drawing to a particular rectangle on the screen.
2023-10-19 01:40:31 <KipIngram   > That will let me carve the screen up into individual windows.
2023-10-19 01:40:54 <KipIngram   > Kind of a pain, because they'll still be using their SCREEN coordinates - I'll have to know those and integrate them in the right way.
2023-10-19 01:41:14 <KipIngram   > Every window will need an x/y offset.
2023-10-19 02:08:44 <GeDaMo      > KipIngram: is this for something like separate programs drawing to their own windows? Could you have them write to a bitmap then composite onto the screen?
2023-10-19 03:02:43 <veltas      > KipIngram: Sounds like it's compiling as C++
2023-10-19 03:03:02 <veltas      > KipIngram: I think schemas are just another table often, yes
2023-10-19 03:03:14 <veltas      > Use what you have etc
2023-10-19 03:04:20 <veltas      > KipIngram: In that compiler error sounds like issue is you're passing a pointer when a reference is needed (i.e. give *p instead of p)
2023-10-19 03:04:44 <veltas      > But what's really needed is C :P
2023-10-19 10:07:41 <KipIngram   > I eventually got it to work.  I was looking in the wrong place for my mistake, so no wonder nothing I tried would fix it.
2023-10-19 10:08:16 <KipIngram   > I had declared a variable as a surface when it should have been a pointer to a surface.  :-|  Made total sense once I actually saw it.
2023-10-19 10:09:37 <KipIngram   > I was trying out that CreateRGBSurfaceFrom() idea.  Didn't get me the result I wanted, though, so I still must not fully understand it.
2023-10-19 10:09:46 <KipIngram   > Clipping rectangle works fine, though.
2023-10-19 10:28:00 <KipIngram   > What it looks to me like the "surface from" thing is supposed to do is give you a surface, with its own boundaries and so on and starting coordinates from 0, 0 that just peers into an already existing surface for its pixel data.
2023-10-19 10:28:13 <KipIngram   > But I haven't gotten an example working that actually seems to DO that.
2023-10-19 11:03:39 <veltas      > KipIngram: I'm looking forward to some screenshots of this!
2023-10-19 11:04:12 <veltas      > Not sure what you're doing but I think doing a sort of graphical windowing system inside Forth would be cool, anything in between is interesting to me as well
2023-10-19 11:04:36 <veltas      > And stay away from C++, it's bad for one's health
2023-10-19 11:19:18 <KipIngram   > Well, I mostly use C, even though it's a .cpp file.
2023-10-19 11:21:10 <KipIngram   > What I'm picturing at the moment is a large window, full height of screen, on the right, that I'll "draw things" in as I work on this projective geometry stuff.  And on the left, a 60-80 column window that's initially full height as well but can split, and those will have text.  One will be my "console," and the others will be those commentary windows and so on.
2023-10-19 11:21:55 <KipIngram   > I'm leaning toward APL style console operation, where instead of an "ok" prompt at the end of output I get a newline and an indent.
2023-10-19 11:23:43 <KipIngram   > I don't know yet how I plan to incorporate Forth into it - I really don't want to implement the Forth in C.  Maybe it winds up being nasm and gets linked in.
2023-10-19 11:23:55 <KipIngram   > I've only got the barest outlines of it in mind right now.
2023-10-19 11:24:00 <veltas      > You probably would have got a better error message compiling as C, mind if I ask why you're compiling as C++?
2023-10-19 11:24:43 <KipIngram   > The SDL2 "hello world" program I found to start it all off was a cpp file.
2023-10-19 11:25:07 <KipIngram   > And I've just been hacking on it from there, familiarizing myself with SDL2 widgets.
2023-10-19 11:25:15 <KipIngram   > It's not necessarily the "real project" yet.
2023-10-19 11:25:27 <KipIngram   > I'm just tinkering and figuring out what stuff actually does.
2023-10-19 11:27:58 <KipIngram   > I just renamed main.cpp main.c and tried compiling with gcc instead of g++.  Looks like the main impediment to that is that it does stuff like std::<blah> in some places.
2023-10-19 11:28:10 <KipIngram   > I can probably fix that without too much trouble.
2023-10-19 11:32:54 <KipIngram   > Where are min() and max() functions in c?
2023-10-19 11:37:02 <KipIngram   > Ok, I got it so it compiles and runs as c now.
2023-10-19 11:37:23 <KipIngram   > I just used conditional expressions for my min and max operations.
2023-10-19 11:38:45 <KipIngram   > All it's doing right now is letting me draw rectangles by clicking and dragging - if I drag left or drag right, it changes how I get the specs for the rectangle.
2023-10-19 11:44:50 <KipIngram   > I've got a good bit of work to do before I get any interesting screenshots, though - I have to make my font bitmap and get the ability to copy character rectangles into my windows and so on.
2023-10-19 11:45:17 <KipIngram   > And I'm planning to map those utf8 APL chars into the 128-255 range, so I'm working all with bytes.
2023-10-19 11:54:24 <KipIngram   > veltas: At some point I'd like to try translating that "back of business card" ray tracer to Forth.
2023-10-19 12:00:24 <KipIngram   > I'm going to have to eventually bite the bullet and get these SDL2 functions "callable" directly from Forth, but I think the text aspects of it I can do with a message pipe between the nasm and the C.
2023-10-19 12:00:39 <KipIngram   > The graphics calls, though, I'll really want to do directly.
2023-10-19 12:01:43 <KipIngram   > Though that does raise the issue of how I might support Forth running on a remote gadget having the ability to show graphical results on the notebook.
2023-10-19 12:01:49 <KipIngram   > Just a lot of stuff to figure out.
2023-10-19 12:02:40 <KipIngram   > Probably I just don't do that - such situations would probably involve wanting to plot some data created on the gadget, and I guess I likely will just want to pipe the data over and the notebook will graph it.
2023-10-19 12:03:16 <KipIngram   > Anyway, I'm focusing on the text interface first.
2023-10-19 12:12:14 <KipIngram   > The main adjustment to make there is that instead of getting its input character by character, the Forth will get it in the form of completed strings.
2023-10-19 12:12:43 <KipIngram   > The C will let me diddle around in the text window, and when i eventually hit Enter it will have formed a set of strings to send to the Forth, one by one.
2023-10-19 12:13:00 <KipIngram   > It'll send each one, echoing it, and take whatever comes back and display that too.
2023-10-19 12:13:40 <KipIngram   > so that's a clear split that will work the same way regardless of whether the Forth is running on the same machine or not.
2023-10-19 12:14:13 <KipIngram   > Eventually / someday I'd like to have *Forth* on the notebook doing that instead of C, but I can live with C initially.
2023-10-19 12:14:43 <KipIngram   > Even then it will be separate threads doing those things and communicating via some pipe.
2023-10-19 12:16:05 <KipIngram   > I guess the Forth will still actually "take possession" of the command strings one char at a time, but what I meant earlier was that it won't get any of the chars until I've finished my editing and hit enter.
2023-10-19 12:17:11 <KipIngram   > That's that split I mentioned the other day - system code will manage the input interface / application will respond to the actual data input.
2023-10-19 12:27:41 <veltas      > KipIngram: Do you know about vector graphics terminal stuff?
2023-10-19 12:27:48 <veltas      > I think xterm and maybe others support it
2023-10-19 12:27:57 <KipIngram   > Not sure - probably not.
2023-10-19 12:28:04 <veltas      > Let me find some info
2023-10-19 12:28:26 <KipIngram   > Cool.  I know kitty supports a protocol for graphics data delivered over the console stream.
2023-10-19 12:28:55 <KipIngram   > It will let you dribble images over a little at a time and then command them to be displayed, which I think is kind of nice.
2023-10-19 12:29:27 <GeDaMo      > https://en.wikipedia.org/wiki/Tektronix_4010#Graphics_protocol
2023-10-19 12:29:28 <KipIngram   > It caches them so they can be re-used, etc.
2023-10-19 12:32:14 <KipIngram   > What I picture eventually winding up with is Forth on the notebook which offers a terminal emulation function with which I can talk to Forth on gadgets (as well as the local Forth).
2023-10-19 12:32:37 <KipIngram   > I envision using Gnu Screen type key sequences to jump from window to window.
2023-10-19 12:33:04 <KipIngram   > Though it would be possible to have several visible at once, of course, and then I could mouse click them.
2023-10-19 12:33:49 <KipIngram   > The 32655 has Bluetooth - eventually I'd like for all the powered on gadgets around to form up a mesh network automatically.
2023-10-19 12:33:59 <KipIngram   > "Discover" one another.
2023-10-19 12:34:33 <KipIngram   > But the notebook will be the only place any actual user interface code runs.
2023-10-19 12:37:40 <KipIngram   > Ugh.  Lot of moving parts in this plan, and I keep hopping around "focus areas" day to day to day.
2023-10-19 13:42:41 <veltas      > Sorry KipIngram got totally sidetracked
2023-10-19 13:43:36 <veltas      > GeDaMo posted it
2023-10-19 13:44:01 <veltas      > Vector displays are awesome
2023-10-19 13:48:11 <GeDaMo      > "Quake on an oscilloscope" https://www.youtube.com/watch?v=aMli33ornEU
2023-10-19 13:51:54 <veltas      > Well partly I thought of it because you can stick to terminal I/O and display graphs etc, which might be sufficient for KipIngram
2023-10-19 13:55:56 <KipIngram   > Yes, it's definitely related to what I'm looking toward.  I just have a lot of details to work out.
2023-10-19 13:56:22 <KipIngram   > Right this moment I got sidetracked on file systems again.
2023-10-19 13:56:44 <KipIngram   > Historically I've been very resistant to the idea of using any space in actual data blocks for file system bookkeeping.
2023-10-19 13:57:25 <KipIngram   > But I think I just need to swallow that pill.  At the moment I'm considering using the last six bytes of a block to hold a pointer to the next block in a file and a count of file bytes in that block.
2023-10-19 13:57:51 <KipIngram   > With that, once I find the first block of a file, I've got the whole file via that linked list, if I want to traverse it that way.
2023-10-19 13:58:39 <KipIngram   > But additionally I picture a b+tree indexing the whole thing, which will be both how I find first blocks and also how I find middle blocks of large files more quickly.
2023-10-19 13:59:41 <KipIngram   > I like it because I can move toward it incrementally, similar to how I noted yesterday that a vocabulary could be searched in a linked list way but could also have a hash table "glued onto it."
2023-10-19 13:59:52 <KipIngram   > I like incremental improvement when it's "non-hacky."
2023-10-19 14:00:28 <KipIngram   > My feeling is that keeping it "non-hacky" mostly just means thinking the whole thing through clearly before building the first pieces.
2023-10-19 14:00:41 <KipIngram   > so you know how the later bits are going to "attach."
2023-10-19 14:02:16 <KipIngram   > I only need 12 bits to specify byte count in a 4k block, so the other four bits of those two bytes can be flags of various sorts.  Maybe one of them says "I am a first block of a file."
2023-10-19 14:02:45 <KipIngram   > Then even if the directories and b+trees got lost, a disk scan could still recover all the files using the in-block links.
2023-10-19 14:03:09 <KipIngram   > You wouldn't get the file names back, or where they were in a disk hierarchy, but at least you'd find all of your data.
2023-10-19 14:04:59 <KipIngram   > For managing disk space I picture the same sort of "fixed size allocator" I've used for RAM - freed blocks would go on a free list, and there would be a "frontier"  pointer I could nudge up when I needed a new block and the free list was empty.
2023-10-19 14:06:03 <KipIngram   > That would grow from low block #'s - later if I wanted to I could add an ability to allocate large contiguous block ranges down from the top, if I wanted to do that for big database tables.  That space would be manually managed, though.
2023-10-19 14:15:04 <KipIngram   > Maybe just have a "high end frontier" pointer as well, just so the file system part of things would know what part of the disk had been carved off for manual handling.
2023-10-19 14:53:47 <KipIngram   > What got me thinking about this was recognizing the similarities between the vocabulary stuff I was discussing yesterday and "directories."
2023-10-19 14:53:59 <KipIngram   > In both cases, you have a set of names with some fixed size associated data.
2023-10-19 14:54:49 <KipIngram   > For a vocabularly, the fixed data is a CFA; for a directory, it's block one of the file, maybe the file size, and whatever other tidbits of status you need to keep up with (permissions if you did that, etc.)
2023-10-19 14:55:30 <KipIngram   > But a block can store a chunk of a directory just as readily aS a RAM buffer can store vocabulary headers.
2023-10-19 14:56:03 <KipIngram   > And then you could link together a set of blocks, each containing a portion of the directory, using the link fields I mentioned earlier.
2023-10-19 14:56:14 <KipIngram   > Each one would just store however many fit.
2023-10-19 14:57:00 <KipIngram   > I'm inclined to search a directory for a particular entry linearly - it lets the names be variable size and I don't really expect to have any huge number of files in a directory.
2023-10-19 14:58:46 <KipIngram   > I did decide to make the linked list tying a file's blocks toether a doubly linked one.  that lets me insert a new block locally, without having to come through from the first block to find the predecessor.
2023-10-19 14:59:05 <KipIngram   > And THAT means instead of having an "I am block 1 of a file" bit, I'd just have a null prev pointer.
2023-10-19 15:14:44 <xcombelle   > hi
2023-10-19 15:15:41 <KipIngram   > Hi xcombelle.  Welcome.
2023-10-19 15:15:50 <KipIngram   > What's up today?
2023-10-19 15:20:06 <xcombelle   > I love stacks
2023-10-19 15:28:19 <veltas      > Yup
2023-10-19 15:36:43 <KipIngram   > That's pretty much the only requirement for getting in around here.  :-)
2023-10-19 15:57:28 <lispmacs[work]> just curious, has anybody ever tried to do anything more with sectorforth (libraries? drivers? number conversion?)
2023-10-19 15:57:48 <lispmacs[work]> I booted up into it this week, using a REAL 3.5" floppy
2023-10-19 15:59:16 <lispmacs[work]> pretty neat project, though have a way to input numbers other than KEY would be convenient
2023-10-19 16:05:44 <KipIngram   > I made a pass at writing a one-sector version of PlanckForth, but never actually tried to run it.  I nominally made it fit, though.
2023-10-19 16:06:32 <KipIngram   > We were talking at the time about both SectorForth and PlanckForth, and it just seemed like a merger would be fun.  :-0
2023-10-19 16:06:35 <KipIngram   > :-)
2023-10-19 16:08:48 <KipIngram   > So, file system wise, I think it makes sense to also include a parent pointer at the end of each block, along with prev and next pointers and a block bytes used field.  So I think I'll reserve the last two cells of each block for disk management / file system administration.
2023-10-19 16:09:14 <KipIngram   > That parent pointer will make me able to climb up into the b+tree when I eventually add it.
2023-10-19 16:09:44 <KipIngram   > b+tree sibling nodes will be linked with the prev and next pointers; I see no reason not to.
2023-10-19 16:10:26 <KipIngram   > So 20 bits of those reserved cells will be available for "status use."
2023-10-19 16:10:43 <KipIngram   > The first 4080 bytes of each block will be "content."
2023-10-19 16:20:23 <KipIngram   > I'll have one "reserved block."  That one, which I'll just know the location of, will hold the variables required for maintaining the block allocator, a menu of block ranges pointing to bootable images, and the first directory entries in the / directory.
2023-10-19 20:25:03 <KipIngram   > Wow, it's pretty straightforward using AVX instructions in C.
2023-10-19 20:25:10 <KipIngram   > Discussion here:
2023-10-19 20:25:12 <KipIngram   > https://www.codeproject.com/articles/874396/crunching-numbers-with-avx-and-avx
2023-10-19 20:25:24 <Zarutian_iPad> via intristics?
2023-10-19 20:25:28 <KipIngram   > Yes.
2023-10-19 20:25:44 <KipIngram   > Looks like cleverly arranging your data is a key  part of it.
2023-10-19 20:26:17 <Zarutian_iPad> well, does avx have scatter and gather vectors?
2023-10-19 20:27:03 <Zarutian_iPad> basically an vector of addresses to gather data from or writing data to
2023-10-19 20:33:46 <KipIngram   > They do appear to have something along those lines.  Still reading.
2023-10-19 20:37:03 <Zarutian_iPad> if it also has the equiv of conditional move but in vector form then implementing an multi instance dual stack machine virtual machines like I described many moons ago is possible.
2023-10-19 22:52:09 <KipIngram   > Well, that's a little disappointing, though not wholly surprising.
2023-10-19 22:52:44 <KipIngram   > Cores will downclock when the start to overheat.  They heat faster when you make heavy use of the AVX instructions (no surprise there).
2023-10-19 22:53:00 <KipIngram   > So when it's all said and done it's hard to know exactly how much performance you gain.
2023-10-19 22:53:11 <KipIngram   > From the instructions, I mean.
2023-10-19 22:54:05 <KipIngram   > I saw a blurb once that implied thermal performance was the big advantage of going to graphene as a substrate rather than silicon.
2023-10-19 22:54:15 <KipIngram   > apparently it conducts heat much, much better than silicon.
2023-10-19 22:54:33 <KipIngram   > The blurb mentioned 100x clock speed potential.
2023-10-19 22:54:46 <KipIngram   > Just from better ability to remove heat.
2023-10-19 22:55:02 <KipIngram   > I guess that didn't mean we'd know how to go that fast - just that from a cooling perspective we could imagine it.
2023-10-19 23:14:23 <KipIngram   > Geez.
2023-10-19 23:14:51 <KipIngram   > I remember the good old days, when I could pick up a book that documented cycles per instruction and tell you EXACTLY how fast a piece of code would run.
2023-10-19 23:15:33 <KipIngram   > But these days, what with cache and downclocking based on temperature, etc. etc. etc...
2023-10-19 23:15:42 <KipIngram   > It's more or less just impossible to know.
2023-10-19 23:25:08 <KipIngram   > I always admired the "precision timing" aspect of digital electronics.  Quartz crystal, man.  It was just one of the perks.
2023-10-19 23:26:19 <KipIngram   > Of course, interrupts could dicker with it some, even then, but you could turn those off in the most real-time critical bits of your work.
2023-10-19 23:28:42 <KipIngram   > Looks like my processor supports avx2 but not avx512.
2023-10-19 23:46:52 <KipIngram   > Zarutian_iPad: looks like there are quite a few GATHER instructions.
2023-10-19 23:49:12 <KipIngram   > Looks like they're calling the latest round AVX-10.  It was announced in August.