2023-10-09 00:00:08 <KipIngram   > Hmmm.  I'm tinkering with SDL2 via g++ today.  For some reason it doesn't seem to register my touch pad, as a touch device.  Mouse motions report fine, as do actuall clicks.  Two-finger motions trigger mouse wheel events.
2023-10-09 00:00:37 <KipIngram   > But no other activity at all from the touch pad.  Tapping it, double tabbing, pinch / zoom type gestures, etc. - no events at all.
2023-10-09 00:03:06 <veltas      > Possibly a Linux implementation quirk
2023-10-09 00:03:13 <veltas      > Maybe ask in SDL IRC
2023-10-09 00:03:23 <veltas      > I'm assuming they have one anyway
2023-10-09 00:04:14 <KipIngram   > I'm reporting "unrecognized" events, so it's not as simple as just not knowing what event types to expect.
2023-10-09 00:05:02 <KipIngram   > Also, resizing windows in SDL2 seems a bit... "manual."  From what I can tell so far you put the window into a "resizing mode," and while it's in that mode mouse icons change and so on - it's prepped to register your mouse motions resizing the window.
2023-10-09 00:05:19 <KipIngram   > I assume I have to collect the resizing info that way and then perhaps call a function to do the actual re-size.
2023-10-09 00:05:31 <KipIngram   > At least moving the window around seems to be a "fully automated" thing.
2023-10-09 00:05:37 <thrig       > games probably don't resize windows much?
2023-10-09 00:07:38 <ghoulpine   > i think theres a flag to allow resizing the window you can set when creating it
2023-10-09 00:08:42 <ghoulpine   > SDL_WINDOW_RESIZABLE
2023-10-09 00:10:21 <KipIngram   > Yes, actually I think you just make a call to do the actual resizing - I think that flag mostly "re-interprets" incoming events in the context of a resizing operation.  Changes the mouse icon, etc.  But I think if I want the window size to change dynamically while I'm making the motion, I have to set the size to the new values over and over, and probably call the update screen function too>  not sure yet,
2023-10-09 00:10:22 <KipIngram   > though.
2023-10-09 00:25:19 <KipIngram   > Anyway, yes - further experiments seem to confirm it's modal.  If I set the resizable bit at start up, then the window comes up with the mouse icon reflecting "resize mode," and the usual mouse motion / mouse wheel events appear to be filtered out.
2023-10-09 00:41:57 <KipIngram   > Also, the window appears to have an unpainted "boundary layer."
2023-10-09 00:42:19 <KipIngram   > If I move the mouse slowly toward the window, an event type 3 will fire before I actually reach the window.
2023-10-09 00:42:57 <KipIngram   > Mouse motion events are not registered while I'm in that zone though (they're also not registered when I completely outside the window).
2023-10-09 00:43:15 <KipIngram   > If I continue then a different event fires when enter the literal window area, and a different one when I leave.
2023-10-09 00:43:42 <KipIngram   > These are all of type SDL_WINDOWEVENT; there's data within that distinguishes entering the window from leaving it.
2023-10-09 04:08:29 <KipIngram   > I notice one other little quirk with this too.  When my window first appears, there is a noticeable difference between the titlebar color (dark gray) and my console background (black).  But as soon as I make the first call to SDL_UpdateWindowSurface() (which you must do to get your changes actually on-screen) then the titlebar turns pure black.  The title is still there, but the background color changes.
2023-10-09 04:08:54 <KipIngram   > As far as I can tell so far SDL2 doesn't offer control over titlebar color.
2023-10-09 04:30:15 <thrig       > that could be something your window manager is doing
2023-10-09 04:33:32 <KipIngram   > Well, it will let me have no titlebar at all, which is likely my perference.  THEN the anomaly is that it initially draws the window up in the top left of my screen, and then moves it to some centered-ish position on the first screen update.
2023-10-09 04:33:56 <KipIngram   > Suppressing the titlebar does seem to eliminate those "extra zones" that surrounded the window otherwise.
2023-10-09 04:36:41 <KipIngram   > What got me to pecking around with this was that website I linked yesterday that had the interactive microprocessor simulators.
2023-10-09 04:37:18 <KipIngram   > Like this one:
2023-10-09 04:37:20 <KipIngram   > https://floooh.github.io/visual6502remix/
2023-10-09 04:37:39 <KipIngram   > Made me think about the stuff I've read re: Chuck's cad system.
2023-10-09 04:39:19 <KipIngram   > If I recall correctly, he had five or six layers and each layer was just a 6000x6000 or so grid.  Each layer represented a different material, and he had a "character set" that let him draw his designs by just setting each cell of each layer to one of those characters.  It was all very much "font like" - he couldn't draw arbitrary lines, but I guess he felt he didn't need to.
2023-10-09 04:39:55 <KipIngram   > I think he had his system set up so that the mousewheel would revolve the tile under the cursor through all of its possible "character" settings.
2023-10-09 04:41:01 <KipIngram   > And if you had words to set tiles, relative to where the cursor is now, then I can see easy enough how you could write a definition to drop a particular transistor geometry somewhere, and then definition that used that to make gates, then that to make an adder, and so on.  It's easy to see how you would factor that work.
2023-10-09 04:41:29 <KipIngram   > Thos images on that website are very much what I think his screen would have looked like.
2023-10-09 04:42:49 <KipIngram   > That website is neat - I think it will actually simulate the designs.  At least if you click on a trace, everything connected to that lights up, all across the design.
2023-10-09 04:48:33 <KipIngram   > Ah, yeah - there's a "play" button, and off it goes, running through all of its states.
2023-10-09 04:48:51 <KipIngram   > MrMobius - I gotta think you'll like that.
2023-10-09 05:43:07 <KipIngram   > You know, thinking about what I just said about Chuck's CAD system, and how he used pre-defined tiles like characters to pave the screen.  Wouldn't that mean he'd have to have more than just one basic tile set in order to support different zoom levels?  In fact, I'm having trouble seeing how it would be done, because you know you could zoom out until whole transistors fit in individual tiles.
2023-10-09 05:43:19 <KipIngram   > Obviously he couldn't show that detail, but what WOULD he show?
2023-10-09 16:16:37 <KipIngram   > So I've been debating between Forth's fundamental approach to source storage (blocks) vs. the way it's done on my wife's calculator (each definition is stored in a variable bearing the name of the word).  So basically like "one file per definition."
2023-10-09 16:17:55 <KipIngram   > I've decided this morning that for me at least the Forth approach is better.  I tend to program such that small groups of definitions cooperate to get various things done, and it's important to how I think about it and process it that I see all those definitions together on the screen - they usually lay out as little blocks, maybe 7-12 lines of 40-50 chars each.  And it's that GROUP of definitions that really
2023-10-09 16:17:57 <KipIngram   > represents a "unit" of my coding.
2023-10-09 16:18:03 <KipIngram   > So I need to be able to put the definitions together.
2023-10-09 16:18:35 <KipIngram   > What I'm leaning toward right now is one source module per vocabularly.
2023-10-09 16:26:39 <veltas      > For your style a definition is logically similar to 'one line of code', and is literally one line of code in most cases
2023-10-09 16:27:01 <KipIngram   > Yes, that's about right.
2023-10-09 16:27:05 <veltas      > It would be fine to store these in 'blocks' if each block was 64 bytes or something
2023-10-09 16:28:03 <KipIngram   > true, but then I'd be wanting to display blocks in sequence.  I can't really imagine wanting to view the source any other way.
2023-10-09 16:30:42 <KipIngram   > I'm envisioning each vocabulary compiling into its own RAM region, probably with names at the high end and bodies at the low end.
2023-10-09 16:31:32 <KipIngram   > Though I'm still considering the possibility of separate regions for names and bodies.  That would allow me to discard names completely from a vocabulary.
2023-10-09 16:31:53 <KipIngram   > I'm just not sure if I need that, given that I'll have the .: / .wipe mechanism to toss un-needed names.
2023-10-09 16:32:10 <KipIngram   > No particular reason to solve that problem twice.
2023-10-09 16:40:46 <veltas      > Having size 64 blocks actually makes a lot of sense
2023-10-09 16:41:06 <veltas      > And then you need to implement file ranges of blocks for different things, have easy insertion/deletion/etc for lines
2023-10-09 16:41:26 <veltas      > Definitely not as performant or elegant as forth blocks though
2023-10-09 16:42:16 <KipIngram   > Well, the flash on that 32655 uses 128-bit writable units; 16 bytes.  So any multiple of that makes a degree of sense.
2023-10-09 16:42:49 <KipIngram   > I am planning to support newlines, though, so my definitions won't have to be a multiple of 64 bytes in storage.
2023-10-09 16:43:20 <KipIngram   > Last iteration of my stuff arrived at a pretty elegant solution for editing such blocks.
2023-10-09 16:44:42 <veltas      > What's the erase size?
2023-10-09 16:44:55 <KipIngram   > Basically EXPECT manages the entire buffer space  you give it when you specify the "max size."  Only everything up to the first newline is actually shown on the screen, but all the stuff beyond that to the "end of the block" is shifted back and forth on insert and delete.
2023-10-09 16:45:01 <KipIngram   > Erase size is 8kB.
2023-10-09 16:45:14 <veltas      > Could use 8K blocks?
2023-10-09 16:45:20 <KipIngram   > Could, yes.
2023-10-09 16:45:26 <KipIngram   > Good argument for that.
2023-10-09 16:45:43 <KipIngram   > So basically when I edit a "line" in a block, I'm working with the entire remainder of the block.
2023-10-09 16:46:20 <KipIngram   > Editor has a command, bb, that tells me how many bytes of the block are in use.
2023-10-09 16:46:24 <veltas      > Maybe store spaces as 0xFF so you can append to a line with re-programs?
2023-10-09 16:46:30 <veltas      > If you're allowed multiple re-programs?
2023-10-09 16:46:57 <KipIngram   > I think so.  I'll need to test that.  But I think so long as I haven't "changed" an erase bit it can be changed with an additional write.
2023-10-09 16:46:58 <veltas      > Or store inverted and use 0x00 is space
2023-10-09 16:47:03 <veltas      > as*
2023-10-09 16:47:11 <KipIngram   > I.e., erase sets all the bits to "something" and then write just flips them.
2023-10-09 16:47:18 <KipIngram   > Write can flip the one way but not the other.
2023-10-09 16:47:21 <KipIngram   > I think / assume.
2023-10-09 16:47:48 <KipIngram   > When I've seen that in the past it's been "erase to 1's, write to 0's.'
2023-10-09 16:48:11 <veltas      > Terminology I'm familiar with is the 'write' is called a 'program' in NOR flash
2023-10-09 16:48:22 <veltas      > Because it can only set/clear
2023-10-09 16:49:10 <KipIngram   > Yes.
2023-10-09 16:49:39 <veltas      > It can only punch holes
2023-10-09 16:49:52 <KipIngram   > I'm not too worried about the wear leveling at this point though - I think that will be ok without too much "trickery."  Just need to be "straighforwardly careful" about it.
2023-10-09 16:49:52 <veltas      > Probably should have been called 'punch'
2023-10-09 16:50:11 <KipIngram   > :-)
2023-10-09 16:50:15 <veltas      > Makes sense to me anyway
2023-10-09 16:50:29 <KipIngram   > sure - it's exactly like punching a punchcard.
2023-10-09 16:50:45 <KipIngram   > Can't put the chad back in.
2023-10-09 16:51:44 <veltas      > Erase cuts a new deck of cards
2023-10-09 16:55:02 <KipIngram   > I also think I'm going to write LOAD so that it has to be manually terminated.  When I reach the end of the block, I'll just continue loading from the next block.
2023-10-09 16:55:18 <KipIngram   > Kind of a middle ground between pure blocks and a file system.
2023-10-09 16:56:01 <KipIngram   > I'll just "increment" instead of consulting the file system data structures for next block info.
2023-10-09 16:56:21 <veltas      > Not THRU?
2023-10-09 16:57:10 <veltas      > THRU is best IMO, your 'file system' is directory blocks that contain ranges of blocks that are loaded as a THRU statement, with comment saying what they are
2023-10-09 16:57:19 <veltas      > INDEX is also your friend
2023-10-09 16:57:24 <KipIngram   > Well, I'm not 100% sure of that.  But forcing the splitting up  of logically connected source doesn't seem good to me.
2023-10-09 16:57:44 <veltas      > You've got that if you have to LOAD from elsewhere already
2023-10-09 16:58:19 <KipIngram   > I'll need to think about it.  I've never gotten far enough along with any of my systems to be faced with managing a large amount of source.
2023-10-09 16:58:57 <KipIngram   > This wouldn't stop me from using THRU, though - I could still include and end directive on each block and load with THRU.
2023-10-09 16:59:25 <KipIngram   > It just wouldn't "automatically" stop at the end of a block.
2023-10-09 17:08:12 <KipIngram   > The wife's calculator presents what looks for all the world like a hierarchical file structure - you can create directories, and then have variables and code in those directories.
2023-10-09 17:08:32 <KipIngram   > So I think the vocabulary organization is pretty similar to that.
2023-10-09 17:08:48 <KipIngram   > Except on the calculator your name search is in your local directory, then the parent, then the grandparent, etc.
2023-10-09 17:09:03 <KipIngram   > No ability to establish a more flexibile search path.
2023-10-09 17:09:18 <KipIngram   > and you are constrained to only CHANGE variables in your local directory.
2023-10-09 17:09:31 <KipIngram   > Which seems like a bit of a limitation to me, but I haven't used that calculator enough to really know for sure.
2023-10-09 17:11:38 <veltas      > It's a bit like only having static block scope variables in C
2023-10-09 17:11:41 <KipIngram   > I like how SDL2 delivers key down and key up events.  That allows for fully flexible processing of modifier keys (which get reported just like every other key).
2023-10-09 17:11:50 <KipIngram   > So I can catch stuff like "shift Enter" and so on.
2023-10-09 17:11:54 <veltas      > Without pointers
2023-10-09 17:12:01 <KipIngram   > Things that really just aren't possible with the conventional approach.
2023-10-09 17:12:43 <KipIngram   > Yeah, it is kind of like that.  And like not being able to modify your parent's environment in bash.
2023-10-09 17:18:08 <KipIngram   > Anyway, one batch of source compiling to one ram region is appealing.
2023-10-09 17:19:40 <KipIngram   > Forth doesn't encourage me to impose that limitation on changing things only in my own vocabulary, though.  At the moment I'm inclined to go with Forth's usual way of doing things.
2023-10-09 17:20:04 <KipIngram   > In general I think I should only change things after careful consideration - Forth's been around for a while.
2023-10-09 17:20:37 <thrig       > Chesterton's Fence? we sent it to recycling a long time ago
2023-10-09 17:20:39 <veltas      > Don't fix what isn't broken
2023-10-09 17:20:49 <KipIngram   > Yes.
2023-10-09 17:22:24 <KipIngram   > Ah, i wasn't familiar with Chesterton's fence.
2023-10-09 17:22:52 <veltas      > I agree with Chesterton's Fence as long as it's not interpreted to mean old=good
2023-10-09 17:23:07 <KipIngram   > I always felt like it was important to try to get the guys I managed to be aware of the second order thinking on things.  Otherwise they constantly showed up asking "Why don't we do it this way instead?"
2023-10-09 17:23:08 <veltas      > It's a bit more nuanced than that
2023-10-09 17:23:20 <KipIngram   > And right - old=good is too simple.
2023-10-09 17:23:28 <KipIngram   > And, honestly, just not always true.
2023-10-09 17:25:24 <veltas      > Change has unintended consequences, and you don't always get nice explanations for why things exist, and you've got too many fences in life to question all of them
2023-10-09 17:25:36 <veltas      > It's a difficult one to swallow I'll admit and I struggle to apply it in practice
2023-10-09 17:25:53 <veltas      > I think at some point you're in Chesterton's Labyrinth and you need to just burn it all down
2023-10-09 17:26:59 <KipIngram   > Right, but so often it seems like we engage in change purely for the sake of change.  The exact opposite of "old=good"; "new must be better."
2023-10-09 17:27:29 <KipIngram   > Plus everyone in sight is always looking for a chance to get their name attached to something - to be viewed as the "spearhead" of a change.
2023-10-09 17:27:51 <KipIngram   > If nothing needs fixing, they'll find something that doesn't need fixing and set out to fix it.
2023-10-09 17:28:48 <veltas      > I think it's fare to describe most of my recreational programming as that category of things that don't need fixing
2023-10-09 17:28:52 <veltas      > fair*
2023-10-09 17:29:14 <KipIngram   > But... all's fair in recreation.  You're not necessarily seeking to impose your work on the world.
2023-10-09 17:29:17 <veltas      > But in my defence, it's in the creative realm of programming
2023-10-09 17:29:19 <KipIngram   > You're just enjoying yourself.
2023-10-09 17:29:57 <veltas      > Quite often I find solutions to real problems based on my recreational programming so it's not all a loss
2023-10-09 17:30:37 <veltas      > My beard's definitely a bit thicker from it
2023-10-09 17:30:38 <KipIngram   > Absolutely.
2023-10-09 17:31:27 <veltas      > I think my programming language without a type system is definitely in a chesterton's fence category, but Forth doesn't have a type system so you can't say I've not researched it a bit
2023-10-09 17:46:08 <KipIngram   > I don't think investigations of simplicity are ever out of bounds.
2023-10-09 17:47:06 <veltas      > Yeah and unlike removing a physical fence, my changes don't impose anything on anyone .... yet
2023-10-09 17:47:21 <KipIngram   > :-)
2023-10-09 17:50:14 <veltas      > I'm definitely a .tar.gz person
2023-10-09 18:15:35 <KipIngram   > So where I'm vaguely poking at right now is being able to open some arbitrary set of SDL2 windows on my notebook and type text into them.  With the notion that each one would eventually become source for a vocabulary.
2023-10-09 18:16:04 <KipIngram   > So these windows my wind up giving me a view into a blocks.dat file.
2023-10-09 18:16:24 <KipIngram   > In addition to eventually supporting serial or bluetooth connection to a remote gadget.
2023-10-09 18:17:03 <KipIngram   > I still may eventually want a Forth-based implementation, but I decided not to let that block me from progress on other fronts.
2023-10-09 18:18:12 <KipIngram   > I'm going to define a character mapping that maps the APL unicode glyphs into the 128-255 extended ASCII range, and the system will be rigorously 1 byte per char.
2023-10-09 18:18:31 <KipIngram   > And I'll make font files for that.
2023-10-09 19:16:53 <KipIngram   > Oh, now I see what you meant with the 0xFF=space suggestion earlier.  It would let me ADD content to blocks without having to erase.  Of course, on the 32655 I don't have to write a whole 8kb block when I write - I can just write the 16-byte records that need writing.  The unused bytes at the end of the last one should certainly be left in the erased state, if it works that way.
2023-10-09 19:17:56 <KipIngram   > I currently use a null termination at the end of a block's content.  Perhaps I change that to a 0xFF termination.
2023-10-09 19:18:22 <KipIngram   > Because once I write a null byte, an erase would be required to change it to allow additional content.
2023-10-09 19:20:40 <KipIngram   > Anyway, good suggestion; just took me a few minutes to absorb it.  :-)
2023-10-09 19:21:46 <KipIngram   > By the way, I'm thinking about shifting from Forth-style screen layout with the ok prompt to APL-style, where a six-byte indentation indicates the user is being prompted to type.
2023-10-09 19:22:00 <KipIngram   > APL output starts at the left margin - user lines start at column 7.
2023-10-09 19:22:44 <KipIngram   > I wonder if they got that indent size from FORTRAN; I'm trying to remember what column its source started in.  It was somewhere there around 6-8.
2023-10-09 19:23:07 <GeDaMo      > It'll be from punch cards
2023-10-09 19:23:20 <KipIngram   > Anyway, I'm just finding the APL screen style to be a little tidier."
2023-10-09 19:24:46 <KipIngram   > Yeah, you're right.  I'm looking at images of punch cards - I want to think I'm seeing an indication that it was eight reserved columns, but it's not really completely clear.
2023-10-09 19:24:55 <KipIngram   > And eight was the first number that popped into my mind too.
2023-10-09 19:24:58 <KipIngram   > Long time ago.
2023-10-09 19:30:50 <KipIngram   > I also think I want to arrange that output setup so that later on I can distinguish echoing of my own typing from actual application output in the buffer.
2023-10-09 19:30:59 <KipIngram   > Tag each line with its origin.
2023-10-09 19:31:35 <KipIngram   > Maybe the indentation is enough for that, but I could trick that up if I tried.
2023-10-09 20:06:45 <KipIngram   > veltas, I think 8kB may be wrong for the 32655 flash - it may be 2kB.
2023-10-09 20:06:52 <KipIngram   > Either way, it's a reasonable block size.
2023-10-09 20:09:14 <KipIngram   > But what I may be remembering there is that the 512kB flash could be thought of as 256 2kB pages, and that would let me use one-byte translation table entries.
2023-10-09 20:09:41 <KipIngram   > So I still lean toward it being 8kB for erasure; I was just thinking about mapping it as a collection of 2kb pages.
2023-10-09 20:18:42 <KipIngram   > I finished up Person of Interest.  Quite a good show.
2023-10-09 20:19:23 <KipIngram   > In spite of what a "non-starter" I regard thinking machines as.
2023-10-09 20:20:15 <KipIngram   > I'm pretty sensitive to "completely non-realistic" portrayals of computer technology, and they definitely went beyond what's realistic, but somehow they managed to do so in a "non-offensive" way.
2023-10-09 20:20:42 <KipIngram   > The movie "Black Hat" still holds the title in my book as "biggest crock of computer sh**."
2023-10-09 20:22:53 <KipIngram   > I can't remember the details - I just remember being quite annoyed at it.
2023-10-09 23:32:51 <veltas      > KipIngram: Maybe store your blocks with data bytes offset by 0x21 (so 0xFF in flash is 0x20 in RAM)