2023-10-27 03:55:26 <veltas      > That's how OpenGL handles integers as well I think, or similar anyway
2023-10-27 03:55:40 <veltas      > I think they go from -1 to 1 over some or all of the integer range
2023-10-27 03:56:00 <veltas      > Fixed point arithmetic is certainly familiar to Forthers
2023-10-27 07:36:30 <KipIngram   > Zarutian_iPad - I'd just call that "revs" or "rotations."
2023-10-27 07:37:18 <KipIngram   > Or "turns"
2023-10-27 08:04:09 <veltas      > turn isn't as specific, e.g. you can do a left turn or right turn, neither is a revolution
2023-10-27 08:04:26 <veltas      > So turns is fine depending on context
2023-10-27 08:04:38 <veltas      > The term is revolution really
2023-10-27 08:08:02 <veltas      > KipIngram: I think for general computing it's useful to have files and directories
2023-10-27 08:08:25 <veltas      > Blocks are too restrictive for general work, but they're very retro and fun, but not to be taken as a serious alternative
2023-10-27 08:08:32 <veltas      > And you know I don't say this lightly
2023-10-27 08:10:17 <veltas      > I also think half-decent version control is useful for basically any development
2023-10-27 08:12:07 <veltas      > I think you can "get away" with losing a lot of things without impacting productivity noticeably, but files/directories/VC are not such things
2023-10-27 08:34:15 <joe9        > veltas: I agree. Files/directories is a better way of organizing over blocks.
2023-10-27 09:28:33 <KipIngram   > veltas: I feel the same; I definitely want to include some sort of "file" support in my system.  I can envision managing things manually with blocks for "small to medium applications," but I think given the massive size of storage devices available today usin them in any practical way requires some sort of "organizing setup."
2023-10-27 09:29:12 <veltas      > Files to avoid partitioning stuff constantly, and annoyance of moving blocks around manually. Directories to handle a large number of files nicely
2023-10-27 09:29:16 <KipIngram   > At the moment, though, I'm leaning toward a "file system" that still recognizes files as comprised of "block sized pages."
2023-10-27 09:29:29 <veltas      > Yeah if there's a small device with limited scope it's fine to work around
2023-10-27 09:29:39 <veltas      > But for general computing work you quickly want more
2023-10-27 09:30:15 <veltas      > Having a granularity for file size is annoying but not a deal breaker
2023-10-27 09:30:30 <KipIngram   > I wouldn't demand that blocks be either 0% used or 100% used, t hough - I do plan to "remember" how much of a block has "real content."
2023-10-27 09:30:54 <veltas      > The C standard actually allows for this technically, but zero real programs support this because otherwise you can't tell where a binary stream ends
2023-10-27 09:31:03 <KipIngram   > So I'll still be able to think of a file as a large continuous blob of data.
2023-10-27 09:31:16 <veltas      > Cool
2023-10-27 09:31:23 <veltas      > Trust me it's desirable
2023-10-27 09:31:41 <KipIngram   > I'm just going to avoid things like splitting words across block boundaries and so on.
2023-10-27 09:31:45 <KipIngram   > Or even lines, for that matter.
2023-10-27 09:32:13 <KipIngram   > A file will be like a notebook - when I need to turn the page to keep writing, I will.
2023-10-27 09:32:38 <KipIngram   > but that page boundary will function like whitespace.
2023-10-27 09:32:45 <KipIngram   > In text applications.
2023-10-27 09:32:53 <KipIngram   > In binary applications it will just be ignored.
2023-10-27 09:33:34 <KipIngram   > So something like an audio file or a video file - the last byte in this block will be contiguous with the first byte of the next block.
2023-10-27 09:33:48 <veltas      > This sounds like a messy compromise to try and get blocks to 'act' like forth source blocks in situ
2023-10-27 09:34:09 <veltas      > I think just move on from blocks if you're doing files, less messy
2023-10-27 09:34:16 <KipIngram   > I see it just as the application determining how to treat the block boundary.
2023-10-27 09:34:40 <veltas      > You can still limit your files to 64 columns and tell your grandkids about why you do that
2023-10-27 09:35:06 <veltas      > When they're old enough to understand
2023-10-27 09:35:14 <KipIngram   > :-)  I've kind of put 64-char lines behind me at this point.
2023-10-27 09:35:43 <KipIngram   > My current source editor uses newlines and that's fairly "baked in."
2023-10-27 09:36:36 <KipIngram   > But, I can't say that I've actually done all this and worked with it and had it go well - it's all still just ideas.
2023-10-27 09:36:40 <KipIngram   > I may try it and hate it.
2023-10-27 09:36:44 <KipIngram   > Time will tell.
2023-10-27 09:37:11 <veltas      > Sounds like progress to me
2023-10-27 09:37:30 <veltas      > Progress is an ugly word to my ears, yet I am proud of you
2023-10-27 09:37:39 <KipIngram   > lmao
2023-10-27 09:37:44 <KipIngram   > I'm honored...
2023-10-27 09:38:01 <KipIngram   > One thing driving my thinking here is that remote comment functionality I want.
2023-10-27 09:38:24 <KipIngram   > Those comments won't actually be stored in some  "separate named file."
2023-10-27 09:38:39 <KipIngram   > The blocks allocated for those will be tied to the source text via these links.
2023-10-27 09:38:45 <KipIngram   > I don't need named access to them as well.
2023-10-27 09:39:14 <KipIngram   > Though the mechanism will still let me create links between pairs of named files, if I want to.
2023-10-27 09:39:46 <KipIngram   > You might think of the comment blocks like "footnotes."  They're really part of the main document.  Just used in a different way.
2023-10-27 09:40:41 <KipIngram   > When I attach a comment to my source, I don't need to have to answer the question, "Oh, what am I going to name that comment file?"
2023-10-27 09:40:59 <KipIngram   > I just need a place, somewhere, to put the comment.
2023-10-27 09:46:13 <veltas      > In my mind a 'file' is a bit like a flexible sized array
2023-10-27 09:47:18 <veltas      > It's not actually a very complicated abstraction either, we just tend to overcomplicate things
2023-10-27 09:47:45 <veltas      > If you've used a B-tree or journal you've made it more complicated than it needs to be
2023-10-27 09:48:14 <veltas      > That's a nice project idea actually, a simple dumb filesystem
2023-10-27 09:48:32 <veltas      > Basically FAT lite, that's my suggestion
2023-10-27 09:51:59 <KipIngram   > Well, I did at one point feel like a b+tree would be a good way to organize this "link" info, but that was some time ago.  And generally I agree with you - I want "more than nothing," but I don't feel any burning need to create the most sophisticated file system on the planet.
2023-10-27 09:53:21 <KipIngram   > I am planning to implement this in a way that doesn't REQUIRE a b+tree.  I've already thought through how I can put a bit of connectivity information in each block and it will make "files" that I can navigate like a linked list.
2023-10-27 09:53:53 <KipIngram   > I want that part to work stand-alone.  If I do do anything like a b+tree, it will be an "additional index."
2023-10-27 09:54:53 <KipIngram   > Something that would accelerate seek operations in very large files.  But who knows when I'll actually NEED any very large files.
2023-10-27 09:55:00 <veltas      > Exactly
2023-10-27 09:55:46 <KipIngram   > And even if I do put something in a large file (say some big video), that doesn't necessarily mean I need high speed seek ability in it.
2023-10-27 09:56:04 <KipIngram   > It might make more sense to let that be an application dependent thing.
2023-10-27 09:57:41 <KipIngram   > So, step 1 is to include a bit of admin information at the end of each block.  A "next" block, a "prev" block, and "bytes used in this block."  To round that out to an integer cell count makes room for some status bits.
2023-10-27 09:58:01 <KipIngram   > then the one further concession I'm making, step 2, is to include one additional cell that I think of as a "parent" pointer.
2023-10-27 09:58:09 <KipIngram   > That would lead up into an indexing structure.
2023-10-27 09:58:14 <KipIngram   > Or it can just go unused.
2023-10-27 09:59:01 <KipIngram   > So we're talking the last 2-3 cells.
2023-10-27 10:00:09 <KipIngram   > Two 64-bit cells would hold 32-bit next, prev, and parent pointers, then 12-bits of the remaining 32 would be byte count.  That leaves me 20 bits for whatever I may decide I need later.
2023-10-27 10:01:07 <KipIngram   > If I do add something higher level, those status bits can identify what this block is - is it a file block, a directory block, a b+tree node, or whatever.
2023-10-27 10:01:08 <veltas      > I would make a 'file' a linked list in blocks containing all block numbers of blocks containing the file contents in order
2023-10-27 10:01:20 <veltas      > Then you get reasonable seeking performance for most things
2023-10-27 10:01:49 <KipIngram   > Well, yeah - something like that could be that higher level, and the parent field in each content block would point up into that.
2023-10-27 10:02:04 <KipIngram   > So i could get from any block of the file to its "index."
2023-10-27 10:02:31 <KipIngram   > That leaves wide open exactly how that higher layer is "organized."
2023-10-27 10:03:01 <KipIngram   > I've mapped out a reasonable layout for "directory" files.
2023-10-27 10:03:26 <KipIngram   > And like in linux, directories will just be files, with some  particular content layout.
2023-10-27 10:03:48 <KipIngram   > I doubt I will ever have directories bigger than single blocks.
2023-10-27 10:04:03 <KipIngram   > Maybe I'll want to put a thousand files in some directory someday, but likely not.
2023-10-27 10:04:54 <KipIngram   > But my current plan is to definitely implement a fairly "dumbed down" file system first, just with a small bit of space reserved for expanded capabilities "someday, maybe."
2023-10-27 10:05:34 <KipIngram   > And the whole business of allocating and freeing blocks is just going to be the same very simple scheme I've used in the past for RAM.
2023-10-27 10:06:45 <veltas      > Free list?
2023-10-27 10:06:53 <KipIngram   > One block in the system will be 'special' - I call it the "anchor" block.  The values required for the block allocator will live in that block, as will the first part (or all of) the / directory.
2023-10-27 10:07:05 <KipIngram   > Yes, freed blocks will just be shoved onto a free list.
2023-10-27 10:07:19 <KipIngram   > And I'll nudge up a "frontier pointer" if I need a block and the free list is empty.
2023-10-27 10:08:32 <veltas      > Yeah I call that a root block
2023-10-27 10:08:36 <veltas      > Block zero
2023-10-27 10:08:53 <KipIngram   > Yes.
2023-10-27 10:09:00 <veltas      > Actually that's not what I call it because I call the root directory that
2023-10-27 10:09:20 <veltas      > I put root directory at block 1, and that first block is called the base block I think
2023-10-27 10:10:24 <KipIngram   > The allocator management variables and possibly some other things will sit in the low part of the anchor block.  The / directory information will grow down from the top (starting just below those reserved admin cells).
2023-10-27 10:10:36 <KipIngram   > So one variable in the low end will point to the start of the / directory info.
2023-10-27 10:12:36 <veltas      > Putting root directory in block 1 (second block) just makes the code shorter, it's just like any directory, just at a fixed block number
2023-10-27 10:12:46 <KipIngram   > Right.
2023-10-27 10:13:05 <KipIngram   > All of my directory blocks will grow "down from the top," for consistency.
2023-10-27 10:13:25 <KipIngram   > That's not necessarily a final decision, but it's how I'm leaning right now.
2023-10-27 10:14:13 <KipIngram   > I struggled a bit over whether or not to make directory entries fixed size (so they could be binary searched).  Keeping them in sorted order would be kind of a pain anyway, so at the moment i'm leaning toward not fixed size - fixed size info fields but a variable length name.
2023-10-27 10:14:49 <KipIngram   > I'm looking at making those exactly the same sort of linked list layout that vocabularies will have.  Just a different amount of fixed info.
2023-10-27 10:15:19 <KipIngram   > I'll get from one directory entry to the next by skipping over the fixed size stuff and then using the count byte to skip over the name.
2023-10-27 10:15:42 <veltas      > I choose fixed size so names can go in there and removing from the directory is as simple as moving the end item to the 'hole'
2023-10-27 10:15:52 <KipIngram   > If a directory block no longer has room for the next entry I want to add, I'll just grow that "file" by linking on a new block.
2023-10-27 10:16:10 <KipIngram   > Yeah - I struggled over that question some.
2023-10-27 10:16:18 <KipIngram   > There are merits to either option.
2023-10-27 10:17:08 <KipIngram   > You make a good point - with my current idea I'd have to shift everything below up to get rid of holes.
2023-10-27 10:17:44 <KipIngram   > But fixed size names introduces the question "how big?"
2023-10-27 10:18:06 <KipIngram   > I rarely ever use long variable names, but sometimes I do use long file names.
2023-10-27 10:18:25 <KipIngram   > i have a tendency to embed fair bits of information in structured file names.
2023-10-27 10:19:50 <KipIngram   > For example, a 'job name' in my tests at work might look like this: 2023-10-27-1444_FCM4-38p4TB_v4p0p1p44_2p85to1-50Percent-PCIe4-30W_Combo-c41.
2023-10-27 10:20:02 <veltas      > I have aimed for 64 bytes per entry
2023-10-27 10:20:11 <veltas      > I think that's reasonable, names would be like 56 bytes
2023-10-27 10:20:16 <KipIngram   > That's a sensible length.
2023-10-27 10:20:24 <veltas      > Tell people to fuck off if they want longer names, they're using it wrong
2023-10-27 10:20:35 <veltas      > It's the right length for "dirt simple FS"
2023-10-27 10:20:36 <KipIngram   > But then I wind up feeling heartburn over the 60 wasted bytes on short names.  :-(
2023-10-27 10:20:56 <veltas      > Aren't you the one going on about how big computer memory is now?
2023-10-27 10:21:07 <KipIngram   > And if I do it this way I'll be able to use the same code to navigate directories that I use to navigate vocabularies.
2023-10-27 10:21:37 <KipIngram   > Up to and including the code that does the name matches.
2023-10-27 10:22:13 <veltas      > Sounds like a plan
2023-10-27 10:22:26 <KipIngram   > Well, I guess it's at least that.  :-)
2023-10-27 10:22:43 <KipIngram   > Geez, I've got such a long list of things to do on this system now.
2023-10-27 10:23:15 <KipIngram   > All that F18A-like vm stuff, this, the SDL2 tie ins, etc.
2023-10-27 10:23:22 <KipIngram   > It's grown into quite a project.
2023-10-27 10:24:01 <KipIngram   > Wanting it to run as a notebook-based Forth, and the vm parts portable to things like the MAX32655...
2023-10-27 10:24:09 <KipIngram   > Lot of things to check off.
2023-10-27 10:24:28 <KipIngram   > The array stuff I steal from APL.
2023-10-27 10:24:44 <KipIngram   > That part will come later, though - that's not "base system."
2023-10-27 10:25:12 <KipIngram   > But I do want to be able to wire the future type support in at the vm level.
2023-10-27 10:25:57 <KipIngram   > A vm instruction like + should run in the base system at normal full native speed you'd expect, but then when type support is in I want to be able to adjust the vm jump table to make such words trigger type-specific operations.
2023-10-27 10:26:42 <KipIngram   > I want to divide the vm instructions into two classes - those that do the same thing always (swap, dup, etc.) and those that do type-specific things (+, other arithmetic, etc.)
2023-10-27 10:27:06 <KipIngram   > I call those categories "agnostic" and "non-agnostic.'
2023-10-27 10:27:52 <KipIngram   > when type support is switched on, non-agnostic instructions will just get re-vectored to more sophisticated code that checks the types of the stack items.
2023-10-27 10:28:22 <KipIngram   > The payoff is that I'll still get to use compact 6-7 bit opcodes for those operations.
2023-10-27 10:28:43 <KipIngram   > I've got a number of ideas in mind aimed at making this system very very compact.
2023-10-27 10:31:08 <veltas      > How will you do resizable arrays?
2023-10-27 10:33:26 <veltas      > I've realise there's no such thing, actually
2023-10-27 10:36:01 <KipIngram   > I haven't thought about that in a while, but at one point was considering those ropes based memory methods.
2023-10-27 10:36:11 <KipIngram   > But an "array" really begs to be one big chunk of stuff.
2023-10-27 10:36:26 <KipIngram   > I don't know for sure yet.  I imagine I'll wind up with some sort of heap.
2023-10-27 10:37:08 <KipIngram   > I'm not really 100% sure I need "resizable" arrays - a typical application for me might be some kind of numerical model, and maybe i just decide how big the array is going to be and make it that big.
2023-10-27 10:38:03 <KipIngram   > If you create a finite element  model, for example, it generally has a certain number of nodes and elements, and that doesn't change during the analysis.
2023-10-27 10:40:07 <veltas      > What is interesting to me is how common std::vector is, and yet it's actually a terrible choice for most serious things
2023-10-27 10:40:21 <veltas      > But it is quite convenient when you're not being serious, I'll admit
2023-10-27 10:40:58 <veltas      > It's trivial to have something like std::vector in C and Forth, to access like a normal array. Just hide the bookkeeping in front of the buffer.
2023-10-27 10:41:13 <veltas      > Just needs to be resized and deallocated with special functions/words
2023-10-27 10:42:12 <veltas      > std::vector is a bit like that gambling fallacy where you think "well if I lose a bet I'll double my next bet, and keep doubling until I win, then I'm guaranteed not to lose money"
2023-10-27 10:43:32 <veltas      > The fallacy is that you can amortise your resize cost, you actually can't. In real life it actually matters whether the next insert is going to cause a massive resize operation.
2023-10-27 10:43:51 <veltas      > If it didn't matter then we'd all be using Java because who cares about garbage collection overhead
2023-10-27 10:45:46 <veltas      > std::deque is probably underrated, and *sometimes* what you want instead of std::vector
2023-10-27 10:55:24 <KipIngram   > Oh, yeah - the Martingale method.
2023-10-27 10:55:42 <KipIngram   > the problem with that is that because the house has an edge, you will always go broke sooner or later.
2023-10-27 10:56:00 <KipIngram   > You may pull ahead at some point, and if you quit then you win.
2023-10-27 10:56:09 <KipIngram   > But if you try to keep on going, eventually you're ruined.
2023-10-27 10:57:17 <KipIngram   > Your best outcome is to bet it all on one go.  If you try to split your wagering over a lot of rounds, you're just making it more certain that they eventually get you.
2023-10-27 10:57:36 <KipIngram   > Unless you can gain an advantage, like by counting cards or somethin.
2023-10-27 10:59:54 <veltas      > Best way to win is to not play
2023-10-27 11:00:16 <KipIngram   > True.
2023-10-27 11:00:47 <KipIngram   > Anyway, if I had to guess now I'd say I'll have arrays that get their size determined when they're created, and then stay that way.
2023-10-27 11:03:33 <KipIngram   > Oh, yeah - I'm also looking at wiring in projective geometry ideas, and also geometric algebra support.  In geometric algebra you can have quantities that have a scalar part, a vector part, a bivector part, and so on, all mixed together into one item.
2023-10-27 11:04:46 <rendar      > KipIngram, well, speaking of that green array board of 144 cores, can we say that we have a "distributed" Forth there, since every Forth can talk to the neighbor ?
2023-10-27 11:05:09 <KipIngram   > And the projective geometry stuff gives you a way to handle rational numbers while doing only integer operations - I may make a go at doing the modeling I'm talking about using fixed point / integer arithmetic (i.e., no floating point).
2023-10-27 11:05:11 <KipIngram   > We'll see.
2023-10-27 11:05:57 <KipIngram   > Yes, sure, you can say that.  There's a project out there where someone uses two GA144s - one is the "target" where you run the code you're developing, and the other is used to run the Forth development system.
2023-10-27 11:06:04 <KipIngram   > I'll try to find you the link to that.
2023-10-27 11:06:25 <KipIngram   > Looking at how that Forth dev system is mapped onto a GA144 is a great example of how to use the thing effectively.
2023-10-27 11:06:35 <KipIngram   > I need to remember a particular name to find it for you.
2023-10-27 11:06:40 <KipIngram   > It'll come to me in a few minutes.
2023-10-27 11:07:19 <KipIngram   > Yes.
2023-10-27 11:07:21 <KipIngram   > http://www.etherforth.org/
2023-10-27 11:07:49 <KipIngram   > I thought the way the dev system GA144 is used is a lot more like "circuit design" than normal embedded programming.
2023-10-27 11:08:06 <KipIngram   > Each core only does one tiny little thing - the real magic is in how the cores are connected up to one another.
2023-10-27 11:08:54 <KipIngram   > It's like each core is a little "component" and they're wired together into a "circuit design."
2023-10-27 11:09:55 <KipIngram   > I think even someone who's done a lot of embedded design would still need some practice to get handy with the GA144.
2023-10-27 11:11:41 <KipIngram   > I can't help thinking, though, that the GA144 is the sort of direction we should have gone with microprocessors all along, though, instead of pouring so many resources into trying to speed up individual cores.
2023-10-27 11:12:08 <KipIngram   > It's gotten so on modern Intel / AMD processors more of your logic is devoted to that kind of thing than to actual compute power.
2023-10-27 11:12:46 <KipIngram   > All in the name of being able to run the same old legacy C code faster and faster, instead of creating new designs that would require new programs be written.
2023-10-27 11:14:15 <KipIngram   > The GA144 is kind of an extreme case, though - those cores aRE REALLY small.  I don't know that that aspect is "optimum."  But it would be interesting, for example, if Intel would sell us a chip with 64 or 256 cores, that together used most of the logic on the chip for actual data processing.
2023-10-27 11:14:29 <KipIngram   > Networked together in some sort of way, perhaps like the ga144.
2023-10-27 11:14:43 <KipIngram   > But with each core having more room to play than the GA144 offers.
2023-10-27 11:16:34 <veltas      > Interested to know of any real applications of GA144
2023-10-27 11:16:41 <veltas      > Especially where it was a good fit
2023-10-27 11:16:47 <veltas      > I don't think there's any of either
2023-10-27 11:26:00 <KipIngram   > I suspect he was aiming it at military signal processing applications.
2023-10-27 11:26:09 <KipIngram   > Very specific niche type things.
2023-10-27 11:26:46 <KipIngram   > That's the only sort of thing I can thnk of where the extremely tight resources each core has make much sense.
2023-10-27 11:28:34 <GeDaMo      > I feel like I saw someone using one for video decoding
2023-10-27 11:28:45 <KipIngram   > Yes, that seems reasonable too.
2023-10-27 11:29:04 <KipIngram   > Doubt you'll ever see one used in cloud applications.
2023-10-27 11:29:58 <rendar      > i was wondering how to create a distributed forth, i mean, how you send computations to one core? say the left core, you can send it with `'2 + 2' 'left' send` ?
2023-10-27 11:30:36 <rendar      > sorry, i meant '2 2 +' of course
2023-10-27 11:32:00 <GeDaMo      > You might have a thread running on each core and send an xt or similar
2023-10-27 11:36:01 <rendar      > what is an xt?
2023-10-27 11:36:26 <GeDaMo      > Execution token, similar to a function pointer
2023-10-27 11:40:40 <GeDaMo      > If you define : test  ." test" ; then ' test puts the xt on the stack and execute will run the xt
2023-10-27 11:42:38 <GeDaMo      > https://ideone.com/q1rfXc
2023-10-27 11:48:50 <KipIngram   > rendar: Well, look over that etherforth stuff - that's one way.
2023-10-27 11:49:18 <rendar      > i see
2023-10-27 11:49:35 <KipIngram   > Modern microprocessors aren't really well suited for "fine grain" parallelism.  Better to make each core responsible for a "stage" of your work, and have them hand data off one to the next in batches.
2023-10-27 11:49:52 <KipIngram   > When you try to split things up as finely as you just mentioned, you wind up with cache issues and so on.
2023-10-27 11:50:09 <KipIngram   > If you have two cores trying to mess with the same small set of variables, they'll be constantly invalidating one another's caches.
2023-10-27 11:50:31 <KipIngram   > You want each core to "own the datta" for a while, do what it needs to do to it, and then hand it down the line.
2023-10-27 11:50:46 <KipIngram   > Like this:
2023-10-27 11:50:48 <KipIngram   > https://en.wikipedia.org/wiki/Flow-based_programming
2023-10-27 11:51:31 <rendar      > i see
2023-10-27 11:51:44 <KipIngram   > Back in the 1980's when I was hugely interested in  parallel computing, there was a lot of literature on the really fine-grain parallelism, where different hardware shared the work almost on an instruction by-instruction basis.  But that's just not the direction the world went.
2023-10-27 11:52:04 <rendar      > hey how old are you? :P
2023-10-27 11:52:09 <KipIngram   > ;-)
2023-10-27 11:52:16 <rendar      > i was born in 1983
2023-10-27 11:52:22 <KipIngram   > I'll turn 61 in January.
2023-10-27 11:52:26 <KipIngram   > 1963 for me.
2023-10-27 11:52:43 <rendar      > ^_^
2023-10-27 11:53:00 <KipIngram   > Yeah, I've started to actively look down the short remaining road toward retirement.
2023-10-27 11:53:17 <KipIngram   > From what I can tell, so long as social security doesn't go belly up my wife and i will manage fine.
2023-10-27 11:53:22 <KipIngram   > Long as we're not stupid about thins.
2023-10-27 11:53:26 <KipIngram   > things
2023-10-27 11:53:38 <rendar      > you're lucky you live in the US and you have 401(k) and all stuff
2023-10-27 11:54:00 <KipIngram   > Yeah, it's been a good place to live.  I can't complain.
2023-10-27 11:54:29 <KipIngram   > I was also lucky I was born to parents that valued education and so on.  Lot of good luck.
2023-10-27 11:55:53 <KipIngram   > Oh, and also very lucky to have stumbled upon my wife.  It took me two tries to get that part right, but second go round has been wonderful.
2023-10-27 11:56:28 <KipIngram   > We'll celebrate our 27th anniversary in February.
2023-10-27 11:56:39 <rendar      > wow etherforth is amazing!
2023-10-27 11:56:51 <KipIngram   > It is - I think it's super-instructional.
2023-10-27 11:56:51 <rendar      > KipIngram, wow.. that's great!
2023-10-27 11:57:02 <rendar      > you mean very very factored
2023-10-27 11:57:22 <KipIngram   > Oh, and third grandchild coming in March.
2023-10-27 11:57:46 <KipIngram   > First one was born two and a half years ago, and I picked up a second by daughter's marriage almsot a year ago.
2023-10-27 11:57:48 <rendar      > wow, what a full life! congrats!
2023-10-27 11:58:07 <KipIngram   > Like I said - can't complain.  I try to remember all that when the annoying crap comes along.
2023-10-27 11:58:14 <rendar      > i'd like to have a granpa who knew Forth! heh
2023-10-27 11:59:01 <KipIngram   > At this point the main open question re: retirement is "Will we stay in this house, or will we need to downsize?"
2023-10-27 11:59:25 <KipIngram   > I like the idea of staying, because this is "home" to our kids, but it honestly is bigger than we'll need.
2023-10-27 11:59:52 <KipIngram   > I think it will mostly depend on what kind of breaks my county offers retirees on property taxes.
2023-10-27 12:00:11 <KipIngram   > that varies county-to-county here in Texas.
2023-10-27 12:00:42 <KipIngram   > As in, we will be able to find a property tax break, but we may have to move to get it.
2023-10-27 12:01:08 <KipIngram   > And if we move, there's no reason not to downsize considerably.
2023-10-27 12:04:35 <rendar      > yeah i agree
2023-10-27 12:04:58 <rendar      > iirc Texas has a 4% yearly property tax on houses/real estate
2023-10-27 12:07:56 <rendar      > brb
2023-10-27 12:14:42 <KipIngram   > Ours comes in more around 3%.
2023-10-27 12:14:59 <KipIngram   > But like I said, apparently there are special programs for retirrees.  I have no details yet.
2023-10-27 12:15:26 <KipIngram   > But by the time we think about retiring, the mortgage itself will be paid off, so it will really only be the property taxes, utilities, and insurance to think about.
2023-10-27 12:16:02 <KipIngram   > And I figure we do want to have a "nest egg" that is untouched unless catastrophic medical needs come up - it wouldn't necessarily be out of the question to let that just be our house equity.
2023-10-27 12:23:49 <KipIngram   > That 3% vs. 4% thing may just be "market value vs. tax authority appraised value," though - you may have the number in mind better than I do.
2023-10-27 12:24:09 <KipIngram   > Anyway, that's all still years away, but not so many that I don't think about it.
2023-10-27 12:24:38 <KipIngram   > And honestly, work is so easy right now that I might see no reason not to just carry on taking their money.
2023-10-27 12:26:47 <KipIngram   > The pandemic just changed things so much - so much of work is from home these days.
2023-10-27 12:27:35 <KipIngram   > Though part of that is just my particular work; some of the guys who work more tightly toether generally go in several days a week.
2023-10-27 12:27:58 <thrig       > that water cooler won't lean itself
2023-10-27 12:28:16 <KipIngram   > I push buttons on a computer 99.9% of the time, and no one else in the Houston office is even really officially "in my org."
2023-10-27 12:28:46 <KipIngram   > My manager and most of my team mates hail from Hursley, England, and a few more from Guadalajar, Mexico.
2023-10-27 12:28:53 <KipIngram   > One guy's in Dallas.
2023-10-27 12:29:04 <KipIngram   > Guadalajara
2023-10-27 12:30:27 <KipIngram   > I do work "for" a subset of the Houston office developers, but that's really jUst a "request/fulfill" type thing.
2023-10-27 12:30:42 <KipIngram   > They tell me when they need tests run, give me the firmware to run them with, etc.
2023-10-27 12:30:50 <KipIngram   > I run the tests and send them the reports.
2023-10-27 12:31:15 <KipIngram   > Not nearly so exciting as some of the stuff I did in earlier parts of my career.
2023-10-27 12:42:32 <KipIngram   > thrig: Yeah, the whole water cooler motif needs to be tended to.  I do get it, though, that actual produce developers working on different parts of the same system can profit from facetime.
2023-10-27 12:42:41 <KipIngram   > Not just ANY work can be effectively remoted.
2023-10-27 12:42:54 <KipIngram   > s/produce/product/
2023-10-27 13:10:01 <KipIngram   > Oh, veltas, another aspect of all these recent thoughts is that I still would like to, at least potentially, end up with something that would fit well and run well on a calculator platform.  I kind of mentally imagine putting it on my DM-42, so that sets RAM constaints and so on.
2023-10-27 13:10:21 <KipIngram   > And it needs to have a structure that would "play well" in a calculator context.
2023-10-27 13:10:42 <KipIngram   > But I'd still like to imagine running it throuh a more typical computer console interface as well.
2023-10-27 13:11:13 <KipIngram   > In fact, I'd like for large parts of it to be written in the vm instruction set and just be wholly portable between the two platforms.
2023-10-27 20:58:39 <KipIngram   > Nice intro to geometric algebra here:
2023-10-27 20:58:41 <KipIngram   > https://www.youtube.com/watch?v=hTa_gErsrtM
2023-10-27 22:03:26 <KipIngram   > So, looks like Henry Cavill is going to star in a remake of Highlander.
2023-10-27 22:16:04 <thrig       > with music by the AI formerly known as prince
2023-10-27 22:19:28 <KipIngram   > Doh...
2023-10-27 22:19:49 <KipIngram   > Queen did a great job with that soundtrack.
2023-10-27 22:21:49 <KipIngram   > Except the cover of New York New York they did while the Kurgan was driving Brenda across town - Freddie Mercury supposedly despised it and it wasn't on the album.
2023-10-27 22:22:32 <KipIngram   > I love that movie, but I wish it had been a little longer.  Parts of it felt super-rushed.
2023-10-27 22:22:53 <KipIngram   > It's one of my top 2-3 favorite movies just the same, though.
2023-10-27 23:38:19 <KipIngram   > For any of you who haven't had the pleasure...
2023-10-27 23:38:22 <KipIngram   > https://www.youtube.com/watch?v=pInk1rV2VEg
2023-10-27 23:38:31 <KipIngram   > A classic...