2023-10-09 10: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 10: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 10:17:57 <KipIngram   > represents a "unit" of my coding.
2023-10-09 10:18:03 <KipIngram   > So I need to be able to put the definitions together.
2023-10-09 10:18:35 <KipIngram   > What I'm leaning toward right now is one source module per vocabularly.
2023-10-09 10: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 10:27:01 <KipIngram   > Yes, that's about right.
2023-10-09 10:27:05 <veltas      > It would be fine to store these in 'blocks' if each block was 64 bytes or something
2023-10-09 10: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 10: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 10: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 10: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 10:32:10 <KipIngram   > No particular reason to solve that problem twice.
2023-10-09 10:40:46 <veltas      > Having size 64 blocks actually makes a lot of sense
2023-10-09 10: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 10:41:26 <veltas      > Definitely not as performant or elegant as forth blocks though
2023-10-09 10: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 10: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 10:43:20 <KipIngram   > Last iteration of my stuff arrived at a pretty elegant solution for editing such blocks.
2023-10-09 10:44:42 <veltas      > What's the erase size?
2023-10-09 10: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 10:45:01 <KipIngram   > Erase size is 8kB.
2023-10-09 10:45:14 <veltas      > Could use 8K blocks?
2023-10-09 10:45:20 <KipIngram   > Could, yes.
2023-10-09 10:45:26 <KipIngram   > Good argument for that.
2023-10-09 10: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 10:46:20 <KipIngram   > Editor has a command, bb, that tells me how many bytes of the block are in use.
2023-10-09 10:46:24 <veltas      > Maybe store spaces as 0xFF so you can append to a line with re-programs?
2023-10-09 10:46:30 <veltas      > If you're allowed multiple re-programs?
2023-10-09 10: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 10:46:58 <veltas      > Or store inverted and use 0x00 is space
2023-10-09 10:47:03 <veltas      > as*
2023-10-09 10:47:11 <KipIngram   > I.e., erase sets all the bits to "something" and then write just flips them.
2023-10-09 10:47:18 <KipIngram   > Write can flip the one way but not the other.
2023-10-09 10:47:21 <KipIngram   > I think / assume.
2023-10-09 10: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 10:48:11 <veltas      > Terminology I'm familiar with is the 'write' is called a 'program' in NOR flash
2023-10-09 10:48:22 <veltas      > Because it can only set/clear
2023-10-09 10:49:10 <KipIngram   > Yes.
2023-10-09 10:49:39 <veltas      > It can only punch holes
2023-10-09 10: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 10:49:52 <veltas      > Probably should have been called 'punch'
2023-10-09 10:50:11 <KipIngram   > :-)
2023-10-09 10:50:15 <veltas      > Makes sense to me anyway
2023-10-09 10:50:29 <KipIngram   > sure - it's exactly like punching a punchcard.
2023-10-09 10:50:45 <KipIngram   > Can't put the chad back in.
2023-10-09 10:51:44 <veltas      > Erase cuts a new deck of cards
2023-10-09 10: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 10:55:18 <KipIngram   > Kind of a middle ground between pure blocks and a file system.
2023-10-09 10:56:01 <KipIngram   > I'll just "increment" instead of consulting the file system data structures for next block info.
2023-10-09 10:56:21 <veltas      > Not THRU?
2023-10-09 10: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 10:57:19 <veltas      > INDEX is also your friend
2023-10-09 10: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 10:57:44 <veltas      > You've got that if you have to LOAD from elsewhere already
2023-10-09 10: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 10: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 10:59:25 <KipIngram   > It just wouldn't "automatically" stop at the end of a block.
2023-10-09 11: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 11:08:32 <KipIngram   > So I think the vocabulary organization is pretty similar to that.
2023-10-09 11: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 11:09:03 <KipIngram   > No ability to establish a more flexibile search path.
2023-10-09 11:09:18 <KipIngram   > and you are constrained to only CHANGE variables in your local directory.
2023-10-09 11: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 11:11:38 <veltas      > It's a bit like only having static block scope variables in C
2023-10-09 11: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 11:11:50 <KipIngram   > So I can catch stuff like "shift Enter" and so on.
2023-10-09 11:11:54 <veltas      > Without pointers
2023-10-09 11:12:01 <KipIngram   > Things that really just aren't possible with the conventional approach.
2023-10-09 11: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 11:18:08 <KipIngram   > Anyway, one batch of source compiling to one ram region is appealing.
2023-10-09 11: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 11: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 11:20:37 <thrig       > Chesterton's Fence? we sent it to recycling a long time ago
2023-10-09 11:20:39 <veltas      > Don't fix what isn't broken
2023-10-09 11:20:49 <KipIngram   > Yes.
2023-10-09 11:22:24 <KipIngram   > Ah, i wasn't familiar with Chesterton's fence.
2023-10-09 11:22:52 <veltas      > I agree with Chesterton's Fence as long as it's not interpreted to mean old=good
2023-10-09 11: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 11:23:08 <veltas      > It's a bit more nuanced than that
2023-10-09 11:23:20 <KipIngram   > And right - old=good is too simple.
2023-10-09 11:23:28 <KipIngram   > And, honestly, just not always true.
2023-10-09 11: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 11:25:36 <veltas      > It's a difficult one to swallow I'll admit and I struggle to apply it in practice
2023-10-09 11: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 11: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 11: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 11: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 11: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 11:28:52 <veltas      > fair*
2023-10-09 11:29:14 <KipIngram   > But... all's fair in recreation.  You're not necessarily seeking to impose your work on the world.
2023-10-09 11:29:17 <veltas      > But in my defence, it's in the creative realm of programming
2023-10-09 11:29:19 <KipIngram   > You're just enjoying yourself.
2023-10-09 11: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 11:30:37 <veltas      > My beard's definitely a bit thicker from it
2023-10-09 11:30:38 <KipIngram   > Absolutely.
2023-10-09 11: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 11:46:08 <KipIngram   > I don't think investigations of simplicity are ever out of bounds.
2023-10-09 11:47:06 <veltas      > Yeah and unlike removing a physical fence, my changes don't impose anything on anyone .... yet
2023-10-09 11:47:21 <KipIngram   > :-)
2023-10-09 11:50:14 <veltas      > I'm definitely a .tar.gz person
2023-10-09 12: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 12:16:04 <KipIngram   > So these windows my wind up giving me a view into a blocks.dat file.
2023-10-09 12:16:24 <KipIngram   > In addition to eventually supporting serial or bluetooth connection to a remote gadget.
2023-10-09 12: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 12: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 12:18:31 <KipIngram   > And I'll make font files for that.
2023-10-09 13: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 13: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 13: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 13:20:40 <KipIngram   > Anyway, good suggestion; just took me a few minutes to absorb it.  :-)
2023-10-09 13: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 13:22:00 <KipIngram   > APL output starts at the left margin - user lines start at column 7.
2023-10-09 13: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 13:23:07 <GeDaMo      > It'll be from punch cards
2023-10-09 13:23:20 <KipIngram   > Anyway, I'm just finding the APL screen style to be a little tidier."
2023-10-09 13: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 13:24:55 <KipIngram   > And eight was the first number that popped into my mind too.
2023-10-09 13:24:58 <KipIngram   > Long time ago.
2023-10-09 13: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 13:30:59 <KipIngram   > Tag each line with its origin.
2023-10-09 13:31:35 <KipIngram   > Maybe the indentation is enough for that, but I could trick that up if I tried.
2023-10-09 14:06:45 <KipIngram   > veltas, I think 8kB may be wrong for the 32655 flash - it may be 2kB.
2023-10-09 14:06:52 <KipIngram   > Either way, it's a reasonable block size.
2023-10-09 14: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 14: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 14:18:42 <KipIngram   > I finished up Person of Interest.  Quite a good show.
2023-10-09 14:19:23 <KipIngram   > In spite of what a "non-starter" I regard thinking machines as.
2023-10-09 14: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 14:20:42 <KipIngram   > The movie "Black Hat" still holds the title in my book as "biggest crock of computer sh**."
2023-10-09 14:22:53 <KipIngram   > I can't remember the details - I just remember being quite annoyed at it.
2023-10-09 17:32:51 <veltas      > KipIngram: Maybe store your blocks with data bytes offset by 0x21 (so 0xFF in flash is 0x20 in RAM)
2023-10-09 18:37:38 <lispmacs[work]> Hi, I need to write a terminal emulator for a legacy terminal type, and wanted to use an interesting language like Forth or Lisp. Kind of what I was thinking was either gforth or common lisp, as practical options, but wondered if anybody had any thoughts
2023-10-09 18:39:54 <lispmacs[work]> by "practical" I'm thinking about performance, and also ease of coding it
2023-10-09 18:41:43 <lispmacs[work]> I guess a big question would be what I would use for the gfx toolkit, unless I just translated to ANSI codes
2023-10-09 23:39:34 <KipIngram   > lispmacs[work] What platform will you be writing this on.
2023-10-09 23:46:04 <KipIngram   > Wow.  Gregor Mendel didn't really start out trying to be a monk (or abbot, or whatever he was).  He set out to be a teacher, and clearly had the technical proficiency.  But he had a horrible phobia about speaking in front of groups of people, and as a result he failed the oral review state of the "hiring process."
2023-10-09 23:46:36 <KipIngram   > I guess he cloistered himself in a monastary because he simply couldn't manage out in the world mixing with people.  That's kind of sad, but he still managed to accomplish great things anyway.
2023-10-09 23:47:02 <KipIngram   > I don't love speaking to groups, but I can muddle my way through it when I have to.