2023-10-18 00:13:45 <KipIngram   > Aha.  I've finally learned my way around these SDL2 event structures.
2023-10-18 00:14:02 <KipIngram   > Uses a union of a bunch of diferent structure types under the hood.
2023-10-18 01:26:37 <KipIngram   > Well, there's a disappointing bit of news.
2023-10-18 01:27:03 <KipIngram   > It looks like Wayland doesn't provide any functionality for packages like SDL2 to move windows natively.
2023-10-18 01:27:32 <KipIngram   > If I decorate the window with a titlebar, I can grab that and drag the window around - that works.
2023-10-18 01:27:45 <KipIngram   > But I assume that's Wayland doing the moving, not SDL2.
2023-10-18 01:28:01 <KipIngram   > If the window doesn't have a titlebar it seems I can't move it at all.
2023-10-18 01:28:19 <KipIngram   > I was planning to tile several windows onto the screen, with each one a separate SDL2 window.
2023-10-18 01:28:38 <KipIngram   > But it looks like instead I'm going to have to open a window fullscreen (that works) and tile it up manurally.
2023-10-18 01:28:51 <KipIngram   > This was a "security decision" on wayland's part.
2023-10-18 01:28:53 <KipIngram   > Of couse.
2023-10-18 06:24:56 <veltas      > KipIngram: Even in X you shouldn't be moving the window really, that's the window manager's job; right?
2023-10-18 09:38:30 <KipIngram   > That seems to be the reasoning driving the Wayland guys.
2023-10-18 09:39:07 <KipIngram   > Then why does SDL2 offer a function SDL_SetWindowPosition()?
2023-10-18 09:39:35 <KipIngram   > What it means at the very least is that I have to learn another system, link another library, etc. in order to be able to do it some other way.
2023-10-18 09:40:31 <KipIngram   > If I indeed do it that way - there is a possible workaround where I just open a full screen window initially and then use the SDL_CreateRGBSurfaceFrom() call.  Apparently that lets you  make a surface entity which "peers into" a parent surface.
2023-10-18 09:40:37 <KipIngram   > That may be good enough.
2023-10-18 09:41:33 <KipIngram   > I'll have a full screen surface and then a set of window surfaces that tile that parent surface.
2023-10-18 09:42:06 <KipIngram   > I haven't tried it yet, so I don't know what gotchas may be involved.
2023-10-18 09:44:54 <KipIngram   > I found the whole discussion of it online annoying - just another instance where someone makes some decision and then ridicules people who aren't happy with it.  Arrogance - like even wanting to do something they decided you can't do is a sign of stupidity and ignorance.
2023-10-18 09:45:07 <KipIngram   > I find arrogance terribly unappealing.
2023-10-18 09:55:25 <KipIngram   > But there seems to be an enormous amount of it in online software discussions.
2023-10-18 10:31:01 <veltas      > KipIngram: I believe that's how apps do custom window borders, by simulating it all themselves
2023-10-18 10:31:18 <veltas      > In Wayland I suspect they have a special interface for doing this specifically
2023-10-18 10:31:24 <KipIngram   > Yes.
2023-10-18 10:31:45 <KipIngram   > See, "more special interfaces" is exactly what i want to avoid.
2023-10-18 10:31:46 <veltas      > Allowing apps to set their position allows a lot of bad behavior... but honestly an app can be bad other ways
2023-10-18 10:31:53 <KipIngram   > I'm swallowing this SDL library pill.
2023-10-18 10:32:00 <KipIngram   > I don't want to also swallow another one.
2023-10-18 10:32:21 <veltas      > I think my suggestion of developing your own interface is best here
2023-10-18 10:32:37 <veltas      > Because the interface can be far simpler than what SDL etc does
2023-10-18 10:32:54 <veltas      > Why are you supporting custom window borders anyway? Is that the goal?
2023-10-18 10:33:03 <KipIngram   > no, not really.
2023-10-18 10:33:05 <veltas      > Or is it just incidental?
2023-10-18 10:33:11 <KipIngram   > I don't really want borders at all.
2023-10-18 10:33:30 <KipIngram   > I just want to tile windows on the screen, but I want to put them exactly where I want them.
2023-10-18 10:33:43 <KipIngram   > The problem is being able to move the window around.
2023-10-18 10:33:55 <KipIngram   > SDL2 has a call for that, but it doesn't work under Wayland.
2023-10-18 10:34:28 <KipIngram   > I can't move it, and I can't just tell it where I want it when I create it.
2023-10-18 10:34:39 <KipIngram   > Well, I can, but it doesn't change anything.
2023-10-18 10:34:56 <KipIngram   > This subsurface thing may take care of me, though.
2023-10-18 10:35:12 <KipIngram   > I've got something to try.
2023-10-18 10:35:46 <KipIngram   > Opening a full-screen window works fine.
2023-10-18 10:36:21 <KipIngram   > Then I can create subsurfaces that match up with portions of that main surface.
2023-10-18 10:36:49 <KipIngram   > I just don't want to ONLY be able to regard it as one big surface, because then I'd have to handle all the window clipping myself.
2023-10-18 10:37:10 <KipIngram   > But subsurfaces will have "boundaries" that match where I want them on the screen.
2023-10-18 10:39:08 <KipIngram   > If I do decide I want "decorations" on those tiles (there will at least be boundary lines), I'm fine with drawing those on the main surface myself and then set the subsurfaces to be inside those.
2023-10-18 10:40:15 <KipIngram   > I'm not really a fan of too much decoraton, though.  First thing I do when I set up terminator on a system is turn off the title and scroll bars.
2023-10-18 10:40:43 <KipIngram   > I just have one-pixel lines between my tiles and the whole rest of the screen is all business.
2023-10-18 10:54:53 <veltas      > To set window positions you'd need to write a window manager for wayland probab;y
2023-10-18 10:55:30 <veltas      > The problem with things like wayland is eventually someone finds a reason they didn't think of, or just doesn't care about their argument, and adds a separate protocol for moving windows.
2023-10-18 10:55:39 <veltas      > And now wayland doesn't work without that extra protocol
2023-10-18 10:55:45 <veltas      > And we have X11 all over again
2023-10-18 10:56:51 <KipIngram   > Yeah.  Darn people.  Always wanting to do think in a way that makes sense to them.  :-)
2023-10-18 10:57:00 <KipIngram   > s/think/things/
2023-10-18 10:59:21 <KipIngram   > Ok, let's say this is how things are.  I think what should have been done is that the SDL guys should have written SDL_SetWindowPosition() so that it did that for me through Wayland, instead of just punting.
2023-10-18 10:59:30 <KipIngram   > Otherwise they don't really "work" under Wayland.
2023-10-18 10:59:54 <KipIngram   > If you have a function in your library, it needs to work everywhere you claim to be able to run.
2023-10-18 11:00:26 <KipIngram   > Maybe they don't claim to run fully under Wayland, but... lame.
2023-10-18 11:00:36 <Zarutian_iPad> and this is why I do gfx and such via vnc/rfb
2023-10-18 11:01:12 <KipIngram   > Anyway, now I'm just complaining for the sake of it - I think I know what to do to get what I want.
2023-10-18 11:01:14 <KipIngram   > o
2023-10-18 11:01:25 <KipIngram   > I'm fine with this subsurface approach, if it works the way I think it will.
2023-10-18 11:02:27 <KipIngram   > But I think the idea that they've plugged some security hole is silly - why couldn't I just open an invisible FULL SCREEN window instead of a window on top of someone's password box?
2023-10-18 11:02:45 <KipIngram   > Seems to me I could still try to play the same trick, in spite of them narrowing down the ways of doing it.
2023-10-18 11:03:18 <KipIngram   > Kind of like how my company turned off our ability to write USB sticks to 'protect IP' but didn't turn off the ability to burn DVDs via USB.
2023-10-18 11:03:34 <KipIngram   > Maybe I can't write IP to a stick, but I could merrily burn it to DVDs.
2023-10-18 11:03:41 <KipIngram   > That gets it out the door just as well.
2023-10-18 11:03:53 <KipIngram   > So they imposed a massive inconvenience and accomplished... NOTHING.
2023-10-18 11:04:04 <KipIngram   > Except the had the ability to tell their bosses "we did something."
2023-10-18 11:05:44 <Zarutian_iPad> checkbox-compliance kind of thing
2023-10-18 11:06:13 <KipIngram   > Yes>  I think "we took action" drives a huge percentage of corporate processes.
2023-10-18 11:24:37 <KipIngram   > If you think about it, it's predicated on their boss not knowing enough about the issue to see that their action wouldn't fully solve the problem.
2023-10-18 11:26:10 <KipIngram   > I think it'd be funny if the first thing their boss said was "what about DVD drives?"
2023-10-18 11:26:31 <KipIngram   > but the boss probably doesn't know that DVD drives still work.
2023-10-18 11:37:13 <KipIngram   > I guess we could call that "managing upward."
2023-10-18 11:37:27 <KipIngram   > Important skill, I guess.  :-)
2023-10-18 11:43:38 <KipIngram   > So, what do you guys think about these two ways of re-using earlier commands?  The "bash way," where you cursor up and old lines appear on the line you're typing, or the "APL way" where you actually move back up the screen into the previously typed stuff and make modifications there?
2023-10-18 11:44:04 <KipIngram   > Those modification don't stick - the earlier stuff returns to its previous value.  Either way the  FINISHED new line appears down at the bottom, just as though you'd typed it.
2023-10-18 11:44:22 <Zarutian_iPad> bash way because the other gives me therac-25 vibes
2023-10-18 11:44:27 <KipIngram   > One advantage of the APL way is that you can modify several lines, and it will send all of them out one by one.
2023-10-18 11:44:48 <KipIngram   > I'm having to look that up...
2023-10-18 11:45:01 <KipIngram   > Oh.  Cool.
2023-10-18 11:45:30 <KipIngram   > I'm leaning APL way at the moment, but still fretting over it.
2023-10-18 11:46:05 <KipIngram   > Another advantage (if you think of it as advantageous) of the APL way is that you can use OUTPUT lines that way too.
2023-10-18 11:46:12 <KipIngram   > I.e., you can turn them into new input.
2023-10-18 11:46:18 <KipIngram   > I don't know how often that would be useful.
2023-10-18 11:50:51 <KipIngram   > As far as I can tell, any of the lines back up the screen that you actually TYPE something on - even just a space - get flagged for issue as new input.  And they just go in order top to bottom.
2023-10-18 11:51:23 <KipIngram   > The modified lines get echoed down at the bottom and the edits up-screen get reverted out.
2023-10-18 11:51:33 <thrig       > didn't plan9 have something that you could edit code anywhere
2023-10-18 11:51:41 <KipIngram   > Yes, acme.
2023-10-18 11:51:52 <KipIngram   > And maybe other things - acme is just the one i've read about.
2023-10-18 11:52:19 <KipIngram   > Basically you could type a command string anywhere, and then if you clicked on it with the mouse it got executed.
2023-10-18 11:52:27 <KipIngram   > So you could hand craft your user interface that way.
2023-10-18 11:52:59 <KipIngram   > It's an interesting idea - lets you kind have a little "scratch pad" menu type system.
2023-10-18 11:53:23 <thrig       > don't misclick that rm -rf ?
2023-10-18 11:53:36 <KipIngram   > Indeed.
2023-10-18 11:54:14 <KipIngram   > I once did a rm -r *<something> once and inadvertently got a space between * and <something>>  :-(
2023-10-18 11:54:30 <KipIngram   > Killed a source file I'd worked on for about two weeks.
2023-10-18 11:55:02 <KipIngram   > I got lucky that day, though; some clever grep on raw disk sectors found 99% of it for me.
2023-10-18 11:55:14 <KipIngram   > I was able to remember my last couple of edits well enough to write the grep search string.
2023-10-18 11:55:29 <KipIngram   > I copied out the right stuff and only had to make a couple of minor mods to get it back.
2023-10-18 11:55:49 <KipIngram   > Grep was a very good friend that day.
2023-10-18 11:56:12 <thrig       > Apple used to name disks "Macintosh HD". then they started writing unix scripts for the iTunes installer
2023-10-18 11:56:33 <KipIngram   > That's already worrisome.
2023-10-18 11:56:49 <KipIngram   > Spaces are always suspect.
2023-10-18 11:57:17 <thrig       > many bothans (files) died, etc
2023-10-18 12:05:44 <KipIngram   > Very sad.
2023-10-18 12:06:03 <KipIngram   > Entire crops were lost.
2023-10-18 12:28:57 <KipIngram   > Still have in the back of my mind how to do hash tables, with the table doubling thing.
2023-10-18 12:32:44 <KipIngram   > I'm leaning toward having a packed array of counted strings at the bottom of the RAM region.  Then the hash table proper at the top, and its entries will contain a 16-bit offset into that packed array for name checking.  The "real" payload could go either place - either in the hash table itself or adjacent to the names.
2023-10-18 12:33:47 <KipIngram   > To look an entry up you'd hash the name, find the name string offset, and check it.  If it matches, great.  If it doesn't, you'd just advance to the next slot and check again (must have had a collision at some point).  You'd need to reach an "empty" slot in order to know that the string was not there.
2023-10-18 12:34:40 <KipIngram   > It would be possible to delete entries - you'd remove the name string from the packed array, and shift everything else down.  Then you'd have to o through the hash table and adjust everyone that affected.
2023-10-18 12:35:08 <KipIngram   > Deletion probably would not be O(1), but inserts and lookups would be, at least in an amortized way.
2023-10-18 12:38:16 <KipIngram   > I kind of like the notion of putting the payload with the name strings - it means the hash table can just be 16-bit items and the code to manage that would be un-influenced by changes to what you were using the table to store.
2023-10-18 12:38:46 <KipIngram   > For dictionary purposes that payload will be the address of the word's implementation.
2023-10-18 13:00:38 <KipIngram   > The next question then becomes, "Do I write the low-level hash table code using my virtual machine language (portability)?  Or in native assembly (performance)?"
2023-10-18 13:02:26 <KipIngram   > I think it will be a fairly modest amount of code - it might be worth implementing it in "native tongue" for whatever platform I'm interested in.
2023-10-18 13:10:42 <thrig       > I sometimes end up with scripts in perl for portability and also C for speeds on my more used platforms
2023-10-18 13:16:02 <KipIngram   > Yeah, same idea.  It helps to get this boiled down to some quite simple operation.  I'm more willing to do some porting work if it's not too onerous.
2023-10-18 13:17:41 <KipIngram   > Now I'm thinking of having two RAM regions.  One will just be packed entries of <value> <key> pairs.  The keys are counted strings.  So, that's something I could search linearly, with no more muss or fuss.  But then I can attach another RAM region to that with a hash-based "index."
2023-10-18 13:17:52 <KipIngram   > That would bring O(1) performance to the table.
2023-10-18 13:18:19 <KipIngram   > If I want to look an item up while I'm in the middle of a table doubling or halving operation, I could fall back to a linear search.
2023-10-18 13:19:13 <KipIngram   > The table itself will just store in a plain vanilla variable - a pointer to the <value>, <key> table.  Then a few cells at the beginnin of that region will point to the index.
2023-10-18 13:19:37 <KipIngram   > I may not be making it very clear, but it looks simple and easy.
2023-10-18 13:21:31 <KipIngram   > I think with a couple of well-chosen "management" variables I can make the mechanism flexible across different sorts of payload, different types of keys, etc.
2023-10-18 13:22:58 <KipIngram   > I.e., I'd be able to use it anywhere in applications where a dictionary type thing would be useful.
2023-10-18 13:24:41 <KipIngram   > The main reason I'd be deleting items, at least for "Forth purposes," would be to support .: / .wipe.  But if delete is going to be O(N), then it might be smarter for me to just open a new table for temporary names and then throw the whole thing away on .wipe.
2023-10-18 13:24:53 <KipIngram   > I see no reason that wouldn't work fine.
2023-10-18 13:25:21 <KipIngram   > I'll normally be searching a list of vocabularies anyway - that would just mean one additional one whenever temporary names existed.
2023-10-18 13:26:08 <KipIngram   > It would be a vocabulary that sat permanently as the first item in the search order.  Usually it would be empty, but .: words would go there and .wipe would empty it.
2023-10-18 13:27:21 <KipIngram   > And it's kind of nice knowing that the first item will never change - it means I'd not have to "special case" adding a vocabulary to the "start" of the search order (which otherwise would mean updating the variable pointing to the list0.
2023-10-18 13:40:16 <KipIngram   > I'm looking at winding up with this:
2023-10-18 13:40:26 <KipIngram   > : set  ( value key table --) ... ;
2023-10-18 13:40:41 <KipIngram   > : get  ( key table -- value) ... ;
2023-10-18 13:41:04 <KipIngram   > Then perhaps clr for deletion.
2023-10-18 13:51:45 <KipIngram   > Actually I recall now that deletion is also O(1) - what they do is just look the item up and mark as dead.  The entry actually gets swept out on next table double / halve.
2023-10-18 13:56:47 <KipIngram   > So,
2023-10-18 13:56:55 <KipIngram   > : clr  ( key table --) ... ;
2023-10-18 13:59:05 <KipIngram   > Guess I'll need words for creating an empty table and throwing a table completely away.
2023-10-18 13:59:54 <KipIngram   > And it might be nice to be able to "erase" a table (for .wipe).
2023-10-18 14:00:22 <KipIngram   > That will actually be clr - I'll use del for deleting an item.
2023-10-18 14:04:30 <KipIngram   > https://pastebin.com/hAE1bRtM
2023-10-18 14:05:13 <KipIngram   > The "types" referred to there will default on 0 0 to value type = integer, key type = counted string.
2023-10-18 14:05:31 <KipIngram   > And to do anything else will require type support and will come later.
2023-10-18 14:13:41 <KipIngram   > I may go ahead and define the first few type values, even though they won't be explicitly used. 0 = cell, 1 = half, 2 = word, 3 = byte, 4 = counted string, 5 = null terminated string.
2023-10-18 14:14:28 <KipIngram   > I guess that's really more about "size" than type, since it pays no regard to things like signed / unsigned, etc.
2023-10-18 14:14:58 <KipIngram   > Might should include float.
2023-10-18 14:36:39 <KipIngram   > I was thinking of having the hash table be just a table of 16-bit values, based on the notion that every vocabulary gets its own, and 64kB would be plenty big for any single vocabulary.  But... if I want it to be a general purpose tool, maybe I should make those 32-bit values.  Applications may arise where I want to have larger tables.
2023-10-18 14:39:08 <KipIngram   > This is really starting to edge over into database thinking - we've got a table of records and an index into it.  Hash index is appropriate for certain types of keys; other key types might use a different sort of index structure (like an array).
2023-10-18 14:40:22 <KipIngram   > I mentioned using well-chosen management variables to make it flexible - that could also allow me to extend it into disk block stored tables.
2023-10-18 18:02:51 <KipIngram   > Some interesting tidbits here:
2023-10-18 18:02:53 <KipIngram   > https://www.forth.com/forth-books/jfar-archives/
2023-10-18 20:08:35 <KipIngram   > You know, it occurs to me that if you store separated headers for a standard Forth system working down from the top of the RAM region instead of up from the bottom, then you don't need both name count bytes and link fields.
2023-10-18 20:09:15 <KipIngram   > Have the fixed standard size part of the header, and then the name field last.  You know how far to jump over the fixed stuff, and then the count byte tell s you how much further.
2023-10-18 20:09:30 <KipIngram   > Possibly adjusted for alignment, but that's well-defined too.
2023-10-18 20:09:59 <KipIngram   > Whereas working up from the bottom, you still want your count byte at the beginning of the name, so you also need a link field to tell you how far back to go to the previous word.
2023-10-18 20:11:05 <KipIngram   > So, if I have a header region and work down from the top, I can think of that as an entirely standard linked list.  Then I can optionally add a hash index to that if I choose to.
2023-10-18 20:11:42 <KipIngram   > Not sure why that's never occurred to me before.
2023-10-18 20:14:24 <KipIngram   > Since this is going to be more or less a code-threaded structure (over vm instructions), I won't need CFA and PFA pointers.  One that I'll call CFA will be enough - it will just point to where the code for the word starts in the body region.
2023-10-18 20:17:12 <KipIngram   > This does mean, though, that WORD can't place the name char by char in the spot it will need to go if compiled.  It doesn't know how long it's going to be, so it doesn't know where to start it.
2023-10-18 20:17:33 <KipIngram   > I'll have to parse into a scratch area, and then CMOVE it if I compile it.
2023-10-18 20:19:05 <KipIngram   > If Forth had better support for strings then WORD could just put that word "on the stack" as a string item.  The data itself would still be in some scratch space, but it feels like what you'd really like to do.
2023-10-18 21:57:11 <KipIngram   > Hey, I got that notebook holder bolted to my telescope.  Went on real nice.  It's all black, so it really doesn't look out of place at all.
2023-10-18 21:57:50 <KipIngram   > I wouldn't want to have to do a LOT of typing on it there - it wobbles a little, but I already figured out how to rest my palm on the plastic to damp that.
2023-10-18 21:58:20 <KipIngram   > Camera is ordered; not exactly sure when it will come yet.
2023-10-18 21:58:42 <KipIngram   > USB-style handheld controller is also ordered.
2023-10-18 21:59:14 <KipIngram   > That's due Tuesday.
2023-10-18 22:04:09 <KipIngram   > So I think on the vocabularies, each one will have a RAM region.  The names a pointers will grow downward from the top as I described earlier.  The first cell at the bottom will hold the size of the RAM  region, and the second will hold the offset of the last word added.  That's enough for a "linked list search."  Then I'll have a couple of other variables down there that indicate whether or not the
2023-10-18 22:04:11 <KipIngram   > vocabulary is hash indexed, and if it is then pertinent info about that hash table.
2023-10-18 22:06:20 <KipIngram   > The main name table and the hash table can both be subjected to table doubling if I need more room than I originally allocated, and it will be straightforward to save both of them to blocks if that makes sense.
2023-10-18 22:06:43 <KipIngram   > In fact, I think the whole scheme could be expanded on to work with block-based database tables.
2023-10-18 22:07:14 <KipIngram   > I'll have to design the details for that.
2023-10-18 22:08:50 <KipIngram   > I probably won't implement the hasing initially, but I want to know how it's going to work so I'm sure I can add it.
2023-10-18 23:58:04 <KipIngram   > Hey, does anyone know how database systems store their schemas?  Do schemas live in a separate database table?
2023-10-18 23:59:00 <KipIngram   > Basically all it is is just a description of the fields of one row of the table, right?
2023-10-18 23:59:11 <KipIngram   > More or less a "struct"?