2022-12-25 00:05:22 <KipIngram   > So, we were talking earlier about curses style screen updates, and "re-writing only what changed."  I do think the first step in that direction is the easiest, and that's re-writing or not on a line-by-line basis.  If anything on the line changes, you rewrite it.
2022-12-25 00:05:37 <KipIngram   > In a lot of applications that's just going to be ONE LINE - the ine you're editing on or something.
2022-12-25 00:06:10 <KipIngram   > But in some other kinds, where maybe you have a batch of bar graphs wiggling up and down, it could be spread out, and could be a good bit less than one line.
2022-12-25 00:06:21 <thrig       > but then the music title wraps to the next line...
2022-12-25 00:06:25 <KipIngram   > Maybe we should think in terms of "fields.  A field could be a piece of a line.
2022-12-25 00:06:59 <KipIngram   > Yeah, wrapping is an issue; I think if you wanted to do it right you'd just not show anything that stretched past an edge of the panel.
2022-12-25 00:07:07 <KipIngram   > It would be a "window into" a larger block of stuff.
2022-12-25 00:07:16 <KipIngram   > Then that problem goes away.
2022-12-25 00:07:47 <KipIngram   > So you could have your screen organized as these fields, each of which is part of a line, and as you did your updates you could build a linked list of dirty fields.
2022-12-25 00:07:58 <KipIngram   > Then just rip through it and write them out.
2022-12-25 00:08:04 <KipIngram   > And clear the list.
2022-12-25 00:08:36 <KipIngram   > That setup subsumes the "line based one" - in that one the fields are just all full width.
2022-12-25 00:09:30 <KipIngram   > I should do some more timing - I should measure how the time required for screen writing changes as the number of characters increases.
2022-12-25 00:09:32 <KipIngram   > Get a curve.
2022-12-25 00:09:51 <KipIngram   > Start from an empty string, and work up to the whole screen.
2022-12-25 00:10:15 <KipIngram   > No doubt there's a "fixed part" and a proportional part, or something close to that.
2022-12-25 00:10:23 <KipIngram   > That would be useful knowledge to have.
2022-12-25 00:10:42 <KipIngram   > And I'm set up to measure it with my system, down to the microsecond.
2022-12-25 00:11:18 <KipIngram   > I could do each length a thousand time or something, measure each one individually, and get mean and standard deviation.
2022-12-25 00:15:16 <KipIngram   > Anyway, with that information in hand, you could calculate how long that dirty list would need to be before you were better off rewriting the whole screen.
2022-12-25 00:17:18 <KipIngram   > If I want to think about doing something like this on that little LCD panel, then I'll be writing RGB pixel information into the buffer that holds the panel data.
2022-12-25 00:17:54 <KipIngram   > And to update a character will involve writing a item to each row of pixels that is part of that character.
2022-12-25 00:18:48 <KipIngram   > What are the typical pixel dimensions of a character cell in common displays these days?
2022-12-25 00:19:38 <KipIngram   > Well, I can figure that out for my screen right now.
2022-12-25 00:21:25 <KipIngram   > Looks like 10 wide and 20 high, at this font size.
2022-12-25 00:22:27 <KipIngram   > At that dimension that little panel would give me 80 wide x 24 tall (which isn't surprising at all).
2022-12-25 00:27:13 <KipIngram   > This window I run my IRC session I keep at 80x25, purely for nostalgia reasons.  :-)
2022-12-25 00:32:08 <KipIngram   > I'll be happy with 64 wide, so I could use 12-wide character cells if I wanted to.
2022-12-25 00:32:32 <KipIngram   > If I grow it the other way to match that would be 24 high, which would let me have 20 lines.
2022-12-25 00:33:03 <KipIngram   > That's fine as well - I want at least 16, but extra for status info / control buttons would be nice too.
2022-12-25 00:35:50 <KipIngram   > Oh, look what I found:
2022-12-25 00:35:52 <KipIngram   > https://github.com/idispatch/raster-fonts/blob/master/font-12x24.c
2022-12-25 00:35:57 <KipIngram   > I'm snagging that.
2022-12-25 00:37:51 <KipIngram   > Hee hee hee... that just saved a LARGE amount of work.
2022-12-25 00:40:44 <KipIngram   > The panel is 800 pixels wide.  64*12 is actually 768, so that leaves 32 pixels horizontally.  That's enough room to do a line number for a block editor.
2022-12-25 00:41:10 <KipIngram   > So what I'll actually want to do is 66 wide.
2022-12-25 00:41:38 <KipIngram   > Number the lines 0-F, and have a line down between that and the block content.
2022-12-25 00:48:54 <KipIngram   > That project has a whole bunch of different fonts; I just git cloned it into my Dropbox.
2022-12-25 10:30:46 <KipIngram   > So, Merry Christmas, Happy Holiday, etc., guys!  Hope you all have a wonderful day.
2022-12-25 10:32:54 <f-a         > thanks Kip
2022-12-25 10:34:01 <KipIngram   > I'm up alone at the moment - savoring a little quiet.  My oldest daughter and my grandson visited up through yesterday; that along with the three kids living here recently made for a noisy place.
2022-12-25 10:34:53 <f-a         > weee
2022-12-25 10:34:54 <KipIngram   > The pandemic resulted in my third and fourth oldest daughters living here for a period of time that hadn't been "expected."  It was kind of a silver lining of the situation, getting to have them around for longer than I'd anticipated.
2022-12-25 10:35:43 <KipIngram   > Third oldest, though, is moving to North Carolina for graduate school Tuesday, so I'm really trying to savor this last little time with her.  It's quite likely she won't ever be "back" as strongly as she has been since 2020 again.
2022-12-25 10:36:19 <KipIngram   > Fourth oldest will no doubt launch some plans of her own at some point, and the youngest is starting college next fall.
2022-12-25 10:36:27 <KipIngram   > So in a year the house may feel a lot emptier.
2022-12-25 10:38:17 <KipIngram   > I thought the fourth oldest was "out" when she got married a few years ago, but that cam unglued and she moved back in for a time.
2022-12-25 10:38:33 <KipIngram   > The oldest two are thoroughly "launched," though.
2022-12-25 10:46:27 <KipIngram   > So there is some remaining flexibility in this processor design.  The block RAM holding stack elements below the top two doesn't currently ever get written to via the second RAM port.  Also, there's a 4-1 selector that feeds the NOS register that only has three of its inputs used currently.
2022-12-25 10:46:40 <KipIngram   > I just haven't thought of anything to use it for.
2022-12-25 10:47:07 <KipIngram   > So both of those are opportunities to easily support "innovative instructions."
2022-12-25 10:48:51 <KipIngram   > I hadn't planned ROT and -ROT until last night, but they don't need either of those spare resources.
2022-12-25 10:52:59 <KipIngram   > x<>z and x<>t would be easy, also without using the extra capabilities, and would be in line with HP calculator stuff.
2022-12-25 10:53:39 <KipIngram   > So would z@ and t@ (over fills the roll of y@).
2022-12-25 10:54:22 <KipIngram   > If I also did the store versions of those, z! and t!, then t! would use that currently unused write port.
2022-12-25 10:54:47 <KipIngram   > But yeah, y@ is over and x@ is dup.
2022-12-25 10:56:01 <KipIngram   > And those words would offer a "middle ground" between tradition and my "frame access" words.  Slightly different, though - with the frame words the locations don't move around as the stack grows and shrinks.  With the HP-style words what was "in" z or t would change with every stack motion.
2022-12-25 10:56:16 <KipIngram   > That's how I'd first implemented the stack access words - indexed off of the stack pointer.
2022-12-25 10:56:41 <KipIngram   > But that proved really hard to keep track of - I couldn't really use those words without keeping notes on paper about what was going on.
2022-12-25 10:56:50 <KipIngram   > The frame register took out that "variation."
2022-12-25 11:32:19 <KipIngram   > I rather hate not having byte-level access to RAM at the instruction level.  But doing so would be quite expensive.  I can write words for those, of course, but they'll be rather expensive too.
2022-12-25 11:32:23 <KipIngram   > Just in time.
2022-12-25 11:33:28 <KipIngram   > I could potentially have a "mask register" that's normally full of 1's, but if I turned off bits it would cause the corresponding bytes to read zero and not write.
2022-12-25 11:33:45 <KipIngram   > Sort of a "compromise" solution that would eliminate SOME of the work associated with byte level access.
2022-12-25 11:34:10 <KipIngram   > Then c@ could be done with @ followed by a set of 8>> instructions.
2022-12-25 11:34:59 <KipIngram   > That would require deploying the block RAM in a way that provided all of the necessary write enables.
2022-12-25 11:35:59 <KipIngram   > Or maybe I could have circuitry that converted the low bits of an address into a suitable group of such enables.
2022-12-25 11:36:09 <KipIngram   > Then the mechanism would work on the fly.
2022-12-25 11:43:35 <KipIngram   > So c@ and c! would do the byte access, but just wouldn't do the shifting.
2022-12-25 11:43:49 <KipIngram   > I like that - it feels like the right thing to do.
2022-12-25 11:44:26 <KipIngram   > If I wanted to spend the opcodes I could do w@ / w! and h@ / h! as well.
2022-12-25 11:46:41 <KipIngram   > Using the mechanism would probably lead me to have rather large code sections, that "unrolled" the handling of each of the bytes in a cell.
2022-12-25 11:47:04 <KipIngram   > the same code, repeated several times, with the number of 8>> or 8<< items varying.
2022-12-25 11:47:50 <KipIngram   > But at least on c!, where the 8<< operations preceed the !, I oculd do it as one word with multiple entry points.
2022-12-25 11:48:14 <KipIngram   > Or have words 8>>'s and 8<<'s that worked that way.
2022-12-25 11:48:41 <KipIngram   > Complicated a bit by the fact that I can't jump into the middle of a cell.
2022-12-25 11:51:14 <KipIngram   > Oh, by the way - the 32-bit vs. 64-bit question.  If I use 64-bit cells, then we're looking at 10 6-bit opcodes, with four leftover bits.
2022-12-25 11:51:48 <KipIngram   > That's a rather large  number of slots - the "wastage" when I couldn't use the rest of the slots in a word would become pretty significant.
2022-12-25 11:52:03 <KipIngram   > I think 32 bits if fairly attractive because of that.
2022-12-25 11:52:32 <KipIngram   > I don't really want to do 16, because it only leaves me one spare bit, so there's no easy way to implement tail optimization.
2022-12-25 11:53:05 <KipIngram   > With 32 bits and two extra bits, I can have a two-bit pattern for "call," and a two-bit pattern for jump (call but don't push a return address).
2022-12-25 11:57:15 <KipIngram   > Ok, so the way I'm doing @ and ! is the way Chuck does in the F21.  The address goes into a register (A reg for @, B reg for !).
2022-12-25 11:58:07 <KipIngram   > I could easily "catch" the low bits of such addresses in an internal count register, possibly setting me up to do do this:
2022-12-25 11:58:16 <KipIngram   > : 8<<'s  8<< rep ;
2022-12-25 11:58:23 <KipIngram   > : 8>>'s  8>> rep ;
2022-12-25 11:58:45 <KipIngram   > So c! would be
2022-12-25 11:58:57 <KipIngram   > b! 8>>'s !
2022-12-25 11:59:46 <KipIngram   > Or maybe : c!  8<<'s rep ! ;
2022-12-25 12:00:09 <KipIngram   > Well, no - c! needs to be an instruction.
2022-12-25 12:00:24 <KipIngram   > Either that or I activate that byte mode manually.
2022-12-25 12:00:54 <KipIngram   > Oh, and 8>>'s isn't an instruction.  Ok; bad idea.
2022-12-25 12:01:10 <KipIngram   > Only instructions can be rep'd.
2022-12-25 12:08:28 <KipIngram   > Anyway, I should go with 32 bits.  I eventually want to put this thing in a smaller, lower power device for that other work; no point making that any harder than necessary.
2022-12-25 12:30:15 <KipIngram   > Hmmm.  Maybe I WILL add byte and word level RAM access.  Given the ideas from earlier, it wouldn't be that had.  Nothing even close to a full generic barrel shifter required.
2022-12-25 12:31:09 <KipIngram   > One set of LUTs could use the low two bits of the address register to select no shift, 1 byte, 2 bytes, 3 bytes.  That in combination with that mask value, also generated from those low bits, gets the job done.
2022-12-25 12:31:35 <KipIngram   > So basically it would cost around 64 LUTs; 32 for c@ / w@, 32 for c! / w!.
2022-12-25 12:31:51 <KipIngram   > And having those would just remove so many future headaches.
2022-12-25 12:46:43 <KipIngram   > So if I recall correctly, store nstructions on the H41CV didn't drop the value form the stack.
2022-12-25 12:47:16 <KipIngram   > Which made STO Z and STO T make a lot more sense, since the instruction didn't MOVE Z or T.
2022-12-25 12:47:46 <KipIngram   > I remember recognizing early on that Forth was "different" in that regard.
2022-12-25 13:25:49 <nmz         > quick question, in forth, a word is a jump right? that means that the more you factor, the more jumps there are, is this a performance penalty of sorts?
2022-12-25 13:27:30 <veltas      > Merry Christmas everyone!
2022-12-25 13:28:05 <nmz         > merry merry
2022-12-25 13:28:08 <veltas      > nmz: More like a call or jump. Some Forths have inlining
2022-12-25 13:28:23 <veltas      > So it depends
2022-12-25 13:28:25 <nmz         > does that mean they don't jump?
2022-12-25 13:28:35 <veltas      > No jump at all
2022-12-25 13:28:50 <nmz         > the entire word?
2022-12-25 13:28:55 <veltas      > This is also very premature optimisation
2022-12-25 13:28:57 <nmz         > and all it entails?
2022-12-25 13:29:04 <veltas      > Sometimes
2022-12-25 13:29:16 <veltas      > Depends on word and on the Forth
2022-12-25 13:30:12 <nmz         > seems like factoring is a double edged sword
2022-12-25 13:33:11 <MrMobius    > Yes, factoring generally has a performance hit if not inlining
2022-12-25 13:33:41 <thrig       > also inlining can make debugging fun
2022-12-25 14:36:04 <xcombelle   > hi i'm reading jonesforth
2022-12-25 14:51:25 <vms14       > :0
2022-12-25 14:51:55 <vms14       > you can even assemble it if you're on linux
2022-12-25 14:52:52 <vms14       > there are more like this one
2022-12-25 14:53:02 <vms14       > like basicforth or idk how it was named
2022-12-25 14:53:42 <vms14       > oh he died
2022-12-25 14:53:43 <vms14       > https://gist.github.com/lbruder/10007431
2022-12-25 16:26:48 <KipIngram   > nmz: Generally on a small part of an application is "really" performance critical.  So it makes sense to design factored code, then profile it and make change where the profiler tells you they will pay off.  Inlining is just one example of such a change.
2022-12-25 16:27:22 <KipIngram   > Of course you don't factor "just for the sake of factoring" - the idea is that you factor for optimum understandability and maintainability.
2022-12-25 16:27:36 <KipIngram   > Then deviate from that for performance sake only where necessary.
2022-12-25 16:28:02 <KipIngram   > But yes, subroutine calls and jumps are performance issues in practically every language.
2022-12-25 16:28:40 <KipIngram   > well, performance "affectors."   Whether it causes an ISSUE for you depends on the situation.
2022-12-25 16:30:02 <KipIngram   > And if you think about it, there's no way the could not be.  Instead of picking up the next instruction and executing it, you pick up an address that you have to go visit to get that next instruction.  With heavy factoring, you might pick up the address, of an address, of an address , of an address, where you finally find the next instructions.
2022-12-25 16:30:10 <KipIngram   > Takes time to pick through that.
2022-12-25 16:32:47 <KipIngram   > The highest caliber weapon in your arsenal of performance improving techniques is the ability to write generic assembly code.  Find the bits of your application that need to go fast, and if necessary write custom code in those places - that's even a step beyond inlining.
2022-12-25 16:33:43 <KipIngram   > I guess if you wanted to go beyond that you could investigate making a hardware accelerator for those bits of functionality.
2022-12-25 16:37:41 <KipIngram   > The fact that Python can be used for numerical work, using packages like numpy and so on, illustrates the same point.  All that Python code you write winds up just being infrequently executed "glue," that holds together your numpy calls.  That glue is slow.  But it doesn't matter, because the heavy liting being done in those apps is done by numpy code, which is written in optimized C.
2022-12-25 16:38:00 <KipIngram   > So you get the convenience and usability of Python, but still get C performance *where you need it*.
2022-12-25 16:39:46 <KipIngram   > Even if the Python represents most of your "lines of code used," it's a tiny fraction of your loc *executed*, because of the complex nature of those numerical tasks.
2022-12-25 16:40:07 <KipIngram   > So speeding the Python up, even a lot, has negligible effect on your app performance.
2022-12-25 16:40:07 <thrig       > Ansible glueing SSH calls together is somehow about six times slower than C
2022-12-25 16:40:50 <KipIngram   > Geez, I learned a little bit about Ansible just a few weeks ago, but I've already forgotten it.
2022-12-25 17:04:12 <vms14       > I like "factoring" cause it's related with bottom up programming
2022-12-25 17:04:26 <vms14       > bottom up is mostly what I like from forth and why I love the colon words
2022-12-25 17:04:53 <vms14       > in lisp there's also a way to bottom up, but forth kind of encourages it much more
2022-12-25 17:05:06 <vms14       > almost any program in forth is a dsl, which means bottom up
2022-12-25 17:05:22 <eris[m]     > not according to the forth books
2022-12-25 17:05:29 <eris[m]     > you're meant to design the DSL top down
2022-12-25 17:05:33 <vms14       > mainly bottom up programming is to "extend your language" until it understands what the problem is
2022-12-25 17:05:38 <eris[m]     > and start with the word 'run'
2022-12-25 17:06:10 <vms14       > you end with a language built for solving the kind of problems you're going to solve
2022-12-25 17:07:01 <vms14       > eris[m]: what books?
2022-12-25 17:07:23 <vms14       > anyways I always hear people use a mix of both
2022-12-25 17:07:38 <vms14       > and something like design with one and program with the other
2022-12-25 17:07:48 <eris[m]     > vms14: Thinking Forth
2022-12-25 17:07:49 <thrig       > it's a tastes great/less filling sort of debate
2022-12-25 17:09:49 <vms14       > I don't think it's just a taste
2022-12-25 17:10:07 <vms14       > I always considered bottom up to give flexibility and modularity benefits
2022-12-25 17:10:58 <thrig       > gemini://marginalia.nu/log/68-wizards-vs-sorcerers.gmi
2022-12-25 17:12:48 <vms14       > eris[m]: "I also program everything bottom up, rather than top down. I'm pretty sure this is from the influence Thinking Forth had on me as a programmer."
2022-12-25 17:12:56 <vms14       > https://news.ycombinator.com/item?id=14842736
2022-12-25 17:14:46 <eris[m]     > fucming hackernews
2022-12-25 17:14:57 <eris[m]     > why are we arguing about this
2022-12-25 17:15:06 <eris[m]     > thinking forth has you start with the word run
2022-12-25 17:16:21 <MrMobius    > I dont get how top down or bottom up is any better in forth if you have a file system
2022-12-25 17:16:31 <MrMobius    > obviously bottom up if you have to type the words in one by one
2022-12-25 17:18:42 <MrMobius    > better as in inherent to the language not as in personal preference
2022-12-25 17:26:08 <vms14       > bottom up is what made me look at forth
2022-12-25 17:26:29 <vms14       > also I always wanted to learn about bottom up and I was told several times to try forth
2022-12-25 17:26:50 <vms14       > and it was a guy who preaches about the thinking forth book
2022-12-25 17:27:12 <vms14       > he says it does not use forth the language, but forth the philosophy, always
2022-12-25 17:27:55 <vms14       > I was like meh, and never tried it, but somehow I ended looking at it and loved the colon words
2022-12-25 17:28:48 <vms14       > also the fact a concatenative language (not a real forth) is quite easy to implement
2022-12-25 17:29:28 <vms14       > just needs a dictionary and some interpreter that reads word by word
2022-12-25 17:29:50 <vms14       > if you provide access to the source code in words, the words are able to implement any kind of other syntax
2022-12-25 17:30:24 <vms14       > the interpreter only needs to read by words and execute them, the words will do the rest
2022-12-25 17:30:43 <KipIngram   > I agree with eris here.  Design top-down, implement bottom-up, testing along the way.  And even that you can fudge using stubs.
2022-12-25 17:31:13 <KipIngram   > But yes, vms14, I agree that achieving a DSL that makes good sense to users is the goal of creating a Forth "application."
2022-12-25 17:31:17 <vms14       > I always hear that when ask about which method to use
2022-12-25 17:31:24 <vms14       > they say they use a mix of both
2022-12-25 17:31:34 <KipIngram   > That's connected with the fact that Forth encourages you to *use the interpreter* instead of building a user interface from scratch.
2022-12-25 17:31:40 <vms14       > and exactly that: design top down, code bottom up
2022-12-25 17:31:46 <KipIngram   > Because it's the interpreter that "accepts" the words of your DSL.
2022-12-25 17:32:43 <KipIngram   > I imagine a lot of the time even if we start coding at the bottom we may still be doing top down design - it's just a matter of how much of that overall structure you can picture in your mind.
2022-12-25 17:33:07 <KipIngram   > You want that top level code to be graceful, and after all, that is where the DSL interface lives.
2022-12-25 17:33:20 <KipIngram   > You RUN high level words - if you don't run them, they need not be there.
2022-12-25 17:33:20 <vms14       > I'm not an experienced dev, so most of my code are just a bunch of tests
2022-12-25 17:34:02 <vms14       > I don't usually know the problem beforehand so I have to try stuff and see what happens xD
2022-12-25 17:34:06 <KipIngram   > MrMobius: If you're going to try to write it all before you run it, then it hardly matters which you write first.
2022-12-25 17:34:45 <KipIngram   > Writing from the top with stubs gives you experience with how your DSL is going to work.  Writing from the bottom with incremental testing lets you solidify lower layers before trying to use them from higher layers.
2022-12-25 17:35:22 <KipIngram   > And yeah, I imagine a lot of us ultimately have a dash of both in our work.
2022-12-25 17:35:24 <vms14       > even with the language, I started having no idea of what I was doing. In every iteration the language adquired a better defined shape
2022-12-25 17:35:59 <vms14       > still sucks, but compared with the start it improved a lot
2022-12-25 17:40:08 <vms14       > In a bottom-up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed.
2022-12-25 17:40:14 <vms14       > this is almost the definition of forth
2022-12-25 17:40:15 <vms14       > xD
2022-12-25 17:43:23 <KipIngram   > If I were, say, bringing up a piece of hardware that was NOT my end goal - say I'm trying to make a serial port fly.  Ok, I'm interested in how I will interact with the final result from other code I write.   That's in some sense thinking about a "DSL for working with a serial port."
2022-12-25 17:43:45 <KipIngram   > But chances are at some point I'm going to write words to poke registers and so on, and I can test those words by running them manually.
2022-12-25 17:44:11 <KipIngram   > So in a case like that, and maybe in "most cases," you may wind up working from both ends until they meet in the middle.
2022-12-25 17:44:29 <KipIngram   > Trying to have it be all one way or all the other way seems misguided to me.
2022-12-25 17:49:09 <KipIngram   > The middle is where there is flexibility.  The bottom end MUST work with whatever you're hooking it to (unless perhaps you control the hardware as well, in which case it's not really "the bottom"), and the top end must be a nice application DSL.  What's in the middle doesn't really matter - it just needs to 1) work and 2) be somewhat easy to understand and maintain.  And not crush your performance.
2022-12-25 17:49:58 <KipIngram   > In some cases you might have the "DSL" *prescribed* (yuck - they usually haven't thought it through as well as you wind up being able to do after you've worked on it).
2022-12-25 17:50:32 <KipIngram   > So this is really just saying "work from your interfaces inward," and oh by the way, maybe one of the interfaces is somewhat malleable and you get some choices.
2022-12-25 17:51:15 <KipIngram   > Or maybe they're both malleable sometimes - if you DO control the hardware, you could change it if you ran into some obtuse issue with how it initially worked.
2022-12-25 17:51:19 <vms14       > I'm not sure which approach I do really use
2022-12-25 17:51:42 <vms14       > I usually start defining the data I will need and then operations with that data
2022-12-25 17:51:42 <KipIngram   > That's exactly the same - me either.  I don't think either "pure" description fits how I work.
2022-12-25 17:52:01 <KipIngram   > exactly the *point*
2022-12-25 17:52:21 <vms14       > like for example a snake game, I start thinking what the snake data will really be
2022-12-25 17:52:35 <KipIngram   > I was always happiest when I was designing the hardware completely, all the way down to component choices.
2022-12-25 17:52:54 <vms14       > as it has to have several pieces I'd make it an array, then a function to draw the snake, to move the points and to add a point
2022-12-25 17:53:19 <vms14       > then the food and to detect collisions
2022-12-25 17:53:37 <vms14       > and then hook the movements to a keypress or something
2022-12-25 17:53:51 <vms14       > I suppose this is mainly top down
2022-12-25 17:54:05 <vms14       > well idk xD
2022-12-25 17:54:38 <vms14       > yes, top down, bottom up would start by making a language specially made for making a snake game
2022-12-25 17:55:04 <KipIngram   > It's kind of a Gordion's Knot problem.  There's not always an "obvious" starting point, and yet if you don't start, you don't finish.
2022-12-25 17:55:19 <KipIngram   > So you have to make decisions, and sometimes such decisions are made on "feel."
2022-12-25 17:55:34 <vms14       > I remember Chuck saying something like: start by the funniest part
2022-12-25 17:55:36 <KipIngram   > You can't always explain exactly why you made them that way.
2022-12-25 17:55:42 <KipIngram   > It's an experience thing.
2022-12-25 17:56:38 <KipIngram   > Maybe you've done a project in the past with similarities, so you know a certain approach probably won't run into insurmountable roadblocks.
2022-12-25 17:57:24 <KipIngram   > The sooner you can recognize that a path is going to dead end, the sooner you can get off of it and try something different.
2022-12-25 17:58:33 <vms14       > still I'd like to learn more about bottom up
2022-12-25 17:59:02 <vms14       > in the case of a snake game, I'm not sure how would it be
2022-12-25 17:59:26 <vms14       > it would end having operations to manage the kind of data the snake uses
2022-12-25 17:59:37 <KipIngram   > Well, choosing how to represent the "state" of your game is a "bottom decision," isn't it?
2022-12-25 18:00:04 <KipIngram   > In my case "bottom" was almost always "poking the hardware."
2022-12-25 18:00:06 <vms14       > I think start by defining the kind of data and then the operations on this data is bottom up
2022-12-25 18:00:12 <KipIngram   > Bottom of the software work, at least.
2022-12-25 18:00:13 <vms14       > but the rest was top down
2022-12-25 18:00:24 <KipIngram   > so, can I make the chip I'm interfacing "do its basic things"?
2022-12-25 18:00:30 <KipIngram   > That was "bottom level."
2022-12-25 18:00:37 <vms14       > and not sure if it's bottom up
2022-12-25 18:00:47 <KipIngram   > And as I noted above, that might result in a DSL itself: a DSL for *working with that chip*.
2022-12-25 18:00:53 <vms14       > if you make a word to move the snake, it's top down
2022-12-25 18:00:55 <KipIngram   > But that's not the FINAL, total task DSL.
2022-12-25 18:01:03 <vms14       > and this is what operates on the data
2022-12-25 18:01:04 <KipIngram   > So sometimes it can be DSLs all the way down.
2022-12-25 18:01:40 <KipIngram   > All a word to move the snake can do, if you haven't defined the bottom yet, is say "I moved the snake for you."
2022-12-25 18:01:50 <vms14       > xD
2022-12-25 18:02:01 <KipIngram   > You can't actually WRITE IT until you know what the bottom is going to look like.
2022-12-25 18:02:10 <vms14       > : move-snake " I moved the snake for you." . cr ;
2022-12-25 18:02:18 <KipIngram   > Stubs.
2022-12-25 18:02:28 <KipIngram   > You can use those to exercise your user interface.
2022-12-25 18:02:36 <vms14       > nah
2022-12-25 18:02:48 <KipIngram   > In that code I just wrote at work, I made some final modifications to it and tried it on a complex test (it already was running simple tests).
2022-12-25 18:02:56 <KipIngram   > I won't dwell on what complex vs. simple actually MEANT.
2022-12-25 18:03:05 <KipIngram   > Anyway, I went back a couple days later and it had bombed.
2022-12-25 18:03:09 <KipIngram   > So, needed some work.
2022-12-25 18:03:22 <KipIngram   > To get a handle on it, I made a copy and ripped out all of the guts.
2022-12-25 18:03:27 <KipIngram   > So that it wasn't really doing anything.
2022-12-25 18:03:38 <KipIngram   > Instead, I just had it print the name of each directly it would have run a test from.
2022-12-25 18:03:46 <KipIngram   > I.e., I stubbed out the bottom layers.
2022-12-25 18:03:49 <KipIngram   > And ran it, and it bombed.
2022-12-25 18:04:02 <KipIngram   > But now I had something that would run fast, and it only took a few minutes to find the one small bug.
2022-12-25 18:04:16 <vms14       > hmm
2022-12-25 18:04:20 <KipIngram   > I was referring to a file, work/step, at a time when I was already in the work subdirectly.
2022-12-25 18:04:23 <KipIngram   > subdirectory
2022-12-25 18:04:31 <vms14       > I find it hard to find bugs in my lang
2022-12-25 18:04:38 <KipIngram   > So I just changed that to step, and ran it again, and got a beautiful list of test subdirectories.
2022-12-25 18:04:41 <vms14       > that's why I made that kind of debugger
2022-12-25 18:04:48 <KipIngram   > Made that same change in the real script, and started it.
2022-12-25 18:04:58 <KipIngram   > I went back a couple days later and it was marching right along perfectly.
2022-12-25 18:05:02 <Zarutian_iPad> https://www.youtube.com/watch?v=7hdJQkn8rtA
2022-12-25 18:05:03 <KipIngram   > So that's the kind of value stubs could have.
2022-12-25 18:05:10 <vms14       > also if something fails it just tells the last atom and word executed
2022-12-25 18:05:18 <KipIngram   > I used stubs to work on the UPPER LAYERS of the algorithm.
2022-12-25 18:05:35 <KipIngram   > Because I knew from the simple tests that the lower layers were already working.
2022-12-25 18:05:46 <vms14       > I find myself typing .s in front of suspicious words to see what happens
2022-12-25 18:06:01 <KipIngram   > But they were time consuming, so I needed them out of my way for troubleshooting.
2022-12-25 18:06:36 <KipIngram   > All I wanted to achieve over the holiday swas to get a successful run of that complex test under my belt.
2022-12-25 18:06:44 <KipIngram   > So I'm content on the work front right now.
2022-12-25 18:07:04 <KipIngram   > Except I let my password expire, and didn't notice that they had retired the previous "recovery" mechanisms and replaced them with new ones.
2022-12-25 18:07:10 <KipIngram   > Which one has to register for, and I didn't.
2022-12-25 18:07:10 <vms14       > KipIngram: what would let you avoid to have to writing an additional test file with stubs?
2022-12-25 18:07:27 <vms14       > write*
2022-12-25 18:07:27 <KipIngram   > So I can't get out of it without manager help - he'll have to request a password reset for me and send me the new password.
2022-12-25 18:07:50 <KipIngram   > I could reset it myself, but I have no way to receive the new one, and he wouldn't get it either, if I request it.
2022-12-25 18:08:10 <KipIngram   > I just started with the actual script and ripped out the lower level layers.
2022-12-25 18:08:30 <KipIngram   > Basically just removed inner loops and replaced them with an echo command (it's a bash script).
2022-12-25 18:08:59 <KipIngram   > So it never actually ran the performance tools, or communicated with the other canister, or anything.
2022-12-25 18:09:11 <KipIngram   > It just walked the work directory and processed step subdirectories.
2022-12-25 18:09:17 <KipIngram   > But that's where it was broken, so...
2022-12-25 18:09:27 <KipIngram   > It took about ten minutes to find the problem and fix it.
2022-12-25 18:09:49 <KipIngram   > Which was a happy experience.
2022-12-25 18:10:06 <KipIngram   > I have also had experiences where I spent DAYS searching for what ultimately turned out to be a small stupid mistake.
2022-12-25 18:10:08 <vms14       > in my case I find it difficult to write stuff in my lang more than a hello world
2022-12-25 18:10:23 <vms14       > I'd like to find ways to make it better suited to express my ideas
2022-12-25 18:10:32 <KipIngram   > So you're saying it's actually not a good DSL for much of anything?
2022-12-25 18:10:33 <vms14       > and to catch bugs easier
2022-12-25 18:10:46 <KipIngram   > Nonetheless, I think you've profited from this work you've done.
2022-12-25 18:10:54 <KipIngram   > That's how it's felt to me, at least.
2022-12-25 18:11:02 <KipIngram   > I think just "exposing yourself to thiings" brings benefits.
2022-12-25 18:11:08 <vms14       > I mostly mean I need to get used to my own lang, but also that it needs to improve in some ways
2022-12-25 18:11:14 <KipIngram   > Even if it's not necessarily "leading you anywhere."
2022-12-25 18:11:18 <thrig       > something something writers have to write a lot before they get good
2022-12-25 18:11:39 <KipIngram   > ^ right.
2022-12-25 18:12:09 <KipIngram   > If you go to learn woodworking, how many pieces of wood are you going to throw into your scrap box before you make something beautiful?
2022-12-25 18:12:09 <vms14       > it's hard sometimes to express what I want to do
2022-12-25 18:12:41 <vms14       > haha remembers all the times I rewrote this lang
2022-12-25 18:12:45 <KipIngram   > The payoff of this work is in the neural pathways in your brain.
2022-12-25 18:13:03 <vms14       > it's also cause I don't like patches
2022-12-25 18:13:33 <vms14       > I prefer to start from scratch, and sometimes the thing I realized or decided is not compatible with the way I started doing things
2022-12-25 18:13:43 <KipIngram   > I hear you - amen.
2022-12-25 18:13:53 <KipIngram   > I like solving problems myself.
2022-12-25 18:14:04 <KipIngram   > I probably "under-use" libraries and so on.
2022-12-25 18:14:17 <KipIngram   > Some folks over-use them, but I guess the other direction is a possible excess too.
2022-12-25 18:14:21 <vms14       > I refuse to use a library if I can do it myself
2022-12-25 18:14:30 <vms14       > but it's not a good thing, usually
2022-12-25 18:14:35 <KipIngram   > I'm currently linking ZERO libraries into my Forth.
2022-12-25 18:14:52 <KipIngram   > And in a way it's painful to think about linking in SDL.
2022-12-25 18:15:04 <KipIngram   > It'll probably make the thing 10x bigger or something.
2022-12-25 18:15:33 <vms14       > well in your case it's different
2022-12-25 18:15:44 <vms14       > you're going to implement sdl eventually
2022-12-25 18:16:22 <KipIngram   > Well, yeah - if I make this pocket gadget, or anything else of that type with a graphics screen, FROM SCRATCH, I'll have to.
2022-12-25 18:16:29 <KipIngram   > Or at least some subset of it.
2022-12-25 18:16:33 <vms14       > I wouldn't dare to even try that
2022-12-25 18:16:46 <KipIngram   > It's one reason that little notion of a big screen buffer that I just wrote out all in a shot caught my attention the other day.
2022-12-25 18:16:57 <KipIngram   > I could do that with nothing but syscalls that I already have.
2022-12-25 18:17:22 <KipIngram   > And I could do, say, a Chuck style tile editor just by manipulating foreground and background colors.
2022-12-25 18:17:33 <KipIngram   > So that's a path that could work perfectly well.
2022-12-25 18:18:13 <KipIngram   > An it would put me back in the familiar old situation of having a screen buffer.  Granted, just updating it wouldn't change the screen - I'd have to pump it out.
2022-12-25 18:18:25 <KipIngram   > But it would work an awful lot like old school systems used to work.
2022-12-25 18:18:29 <vms14       > I just need crc to adopt me, so he will give me the gameboy-like thing he is building
2022-12-25 18:18:37 <KipIngram   > :-)
2022-12-25 18:18:55 <KipIngram   > I have a feeling that ten years from now you'll be doing all kinds of things yourself.
2022-12-25 18:19:13 <KipIngram   > You gotta start somewhere, right?
2022-12-25 18:19:40 <vms14       > who knows how things will be in 10 years
2022-12-25 18:19:55 <KipIngram   > True.
2022-12-25 18:20:07 <KipIngram   > Crazy as the world feels to me these days there really is no telling.
2022-12-25 18:20:16 <KipIngram   > Pace of change has done nothing during my life but accelerate.
2022-12-25 18:20:39 <KipIngram   > I'm sure it's because it's become a lot easier for us to communicate with each other, regardless of distance.
2022-12-25 18:20:50 <KipIngram   > Information flows like lightning now.
2022-12-25 18:21:35 <vms14       > embedded devices do fascinate me, even more than programming
2022-12-25 18:21:47 <vms14       > I always wanted to reach the middle point of both worlds
2022-12-25 18:22:10 <vms14       > where I can make my own embedded device and program it
2022-12-25 18:22:20 <vms14       > but I never went to that path, for some reason
2022-12-25 18:23:15 <vms14       > still if in 10 years I end being a good programmer, it's fair enough :D
2022-12-25 18:27:51 <KipIngram   > That's a fun, fun thing to be able to do, let me tell you.
2022-12-25 18:28:40 <KipIngram   > And it is within reach.  If you ever decide to study some electronics let us know - I can recommend some good books, and I imagine others here can as well.
2022-12-25 18:29:12 <KipIngram   > It's especially feasible these days, since "hardware design" (I'm speaking of FPGA logic here) is more like programming than it used to be.
2022-12-25 18:30:51 <vms14       > I'd like to start with some devkits or similar stuff
2022-12-25 18:31:08 <vms14       > actually I was interested in the PIC microcontrollers
2022-12-25 18:31:26 <vms14       > they seemed a good start to both embedded devices and assembly
2022-12-25 18:31:46 <vms14       > people today uses arduino, but it's not what I want
2022-12-25 18:32:04 <Zarutian_iPad> vms14: U recommend that you look into AVR instead
2022-12-25 18:32:20 <Zarutian_iPad> s/U/I/
2022-12-25 18:32:28 <vms14       > cause pic are dead?
2022-12-25 18:32:48 <vms14       > oh cause flash?
2022-12-25 18:32:53 <Zarutian_iPad> no, because I had some experience with those
2022-12-25 18:33:12 <MrMobius    > PIC32 is pretty cool. just MIPS under the hood which is a nice ISA
2022-12-25 18:33:44 <Zarutian_iPad> pic32 is okay, but not pic12 or pic16
2022-12-25 18:35:10 <KipIngram   > This FPGA kit I just got was easy to bring up under my Linux.
2022-12-25 18:35:52 <KipIngram   > So, if I wanted to implemnt Chuck's "tiles" using a console-based approach, I think I'd need to make each tile 5 chars square.  With each char completely filled with some chosen color.
2022-12-25 18:36:18 <KipIngram   > Looking at his tiling characters, that's the resolution that would be required.
2022-12-25 18:36:39 <KipIngram   > The downside of doing it that way is that would be no good way to zoom out.
2022-12-25 18:36:42 <vms14       > https://flashforth.com/
2022-12-25 18:36:43 <vms14       > :0
2022-12-25 18:37:39 <KipIngram   > And that's a fairly zoomed in resolution - wouldn't be able to see much of the design at once.
2022-12-25 18:44:20 <KipIngram   > There might be utf8 characters that meet the requirements.  Those old fashioned "box drawing" chars almost get there.
2022-12-25 18:44:43 <KipIngram   > Hmmm.  Maybe they get ALL the way there, and they're accessible through utf8.
2022-12-25 18:45:02 <KipIngram   > Referred to as "box drawing" and "block drawing" characters.
2022-12-25 18:45:44 <vms14       > this reminds me I want to make a text editor
2022-12-25 18:45:56 <vms14       > I want to get rid of emacs
2022-12-25 18:46:12 <vms14       > I hate it so much, but didn't find a better one
2022-12-25 18:47:22 <KipIngram   > A tile editor would need to be able to scroll, because even Chuck's small MuP21 was 600 tiles square.
2022-12-25 18:47:38 <vms14       > what is a tile editor
2022-12-25 18:47:49 <KipIngram   > So the screen would get output as window wide segments of consecutive lines.
2022-12-25 18:48:04 <KipIngram   > Um,  back in the day Chuck Moore wrote his own CAD software to design his Forth chips with.
2022-12-25 18:48:18 <KipIngram   > I'm infatuated with the idea and think I want to play with it, somehow.
2022-12-25 18:48:30 <vms14       > :0
2022-12-25 18:48:35 <KipIngram   > He laid the transistors out directly on screen, using what he called a tile editor.
2022-12-25 18:48:46 <KipIngram   > Five material layers, 600x600 tiles.
2022-12-25 18:49:06 <KipIngram   > He could set any tile to one of 16 "shapes," which specified how the doping should look in that region.
2022-12-25 18:49:31 <KipIngram   > The he wrote Forth code to scan that structure, extract a netlist, compute the capacitances of everything, and then simulate the operation of the circuit.
2022-12-25 18:49:51 <KipIngram   > When it worked the way he wanted it to, he output it to a format the chip fabricators could use, and had them make his chips.
2022-12-25 18:49:55 <vms14       > yeah then you can add a way to simulate the behavior
2022-12-25 18:50:05 <KipIngram   > That's the sort of process that led to all of his devices, including the GA144.
2022-12-25 18:50:10 <KipIngram   > He did write simulation code.
2022-12-25 18:50:17 <KipIngram   > 30 ps time steps.
2022-12-25 18:50:23 <vms14       > must be hard and not always 100% trustworthy, but cool and useful
2022-12-25 18:50:39 <KipIngram   > He got working results with it, and he felt it was more accurate that commercial systems.
2022-12-25 18:50:47 <KipIngram   > than
2022-12-25 18:51:02 <KipIngram   > Used fixed point math.
2022-12-25 18:51:05 <KipIngram   > No floating point.
2022-12-25 18:51:40 <KipIngram   > I regard the whole thing as almost the ultimate expression of the "Forth way" of doing things.
2022-12-25 18:51:51 <KipIngram   > Solve the WHOLE PROBLEM, on your own.
2022-12-25 18:52:12 <KipIngram   > Furthermore, he built this system by using the debugger to poke the first bytes of code into his 386 computer's RAM.
2022-12-25 18:52:16 <vms14       > so the forth way is do everything by yourself?
2022-12-25 18:52:22 <KipIngram   > Part of it.
2022-12-25 18:52:29 <vms14       > no wonder why I like it, I'm a masochist :D
2022-12-25 18:52:41 <KipIngram   > Don't rely on "canned" solutions (libraries) that are likely sub-optimal for your problem.
2022-12-25 18:52:49 <KipIngram   > No fat.
2022-12-25 18:53:03 <vms14       > yeah you load 342432 modules to just use a function
2022-12-25 18:53:11 <KipIngram   > yeah.
2022-12-25 18:53:14 <vms14       > like react developers
2022-12-25 18:53:15 <vms14       > :D
2022-12-25 18:53:21 <Zarutian_iPad> oh, I do like libraries. To read them but not to include them
2022-12-25 18:53:25 <KipIngram   > Anyway, I'm kind of in awe of him doing that.  Amazing achievement.
2022-12-25 18:53:42 <vms14       > they just wanted to <html> {dynamic stuff} </html>
2022-12-25 18:53:51 <vms14       > but had to load the whole react
2022-12-25 18:54:14 <vms14       > and then to use react router and whatever additional modules it has
2022-12-25 18:54:51 <vms14       > I like to do things by myself if I know how to do X thing, but this is not usually the case
2022-12-25 18:55:07 <vms14       > and most of the time the random library will be much better implemented than mine
2022-12-25 18:55:09 <KipIngram   > I don't know if I'll ever get around to actually having a chip made, but hey - it COULD happen.
2022-12-25 18:55:28 <KipIngram   > MOSIS exists, and while that's a good bit of money for me, it's something I COULD do if it became important to me.
2022-12-25 18:55:51 <vms14       > also I'm not able or willing to write stuff like curses, sdl, database bindings for mysql or alike
2022-12-25 18:56:03 <KipIngram   > That would be even a step beyond running my own processor in an FPGA.  It would be sort of the ultimate, short of trying to fab the chip myself (which is something I wish there was a way for us to do).
2022-12-25 18:56:21 <KipIngram   > Sure - there's no doubt that you can do more stuff by using tools others have built.
2022-12-25 18:56:28 <Zarutian_iPad> I heard Google or some such had cheap tapeout program where you can design all layers
2022-12-25 18:56:29 <KipIngram   > There's just no hope of replicating all that work.
2022-12-25 18:56:42 <vms14       > well in your case you just can't if it's going to end in a microchip
2022-12-25 18:56:43 <KipIngram   > that's basically what MOSIS is.
2022-12-25 18:56:52 <KipIngram   > they aggregate a bunch of people's projects onto a single wafter.
2022-12-25 18:56:55 <Zarutian_iPad> but there are macrocell chips where you just design the metal layers
2022-12-25 18:56:56 <KipIngram   > wafer
2022-12-25 18:57:24 <Zarutian_iPad> that latter is much much cheaper
2022-12-25 18:58:12 <Zarutian_iPad> but then there are folks like the guy making 3 or 6 micron chips in his garage
2022-12-25 18:59:08 <Zarutian_iPad> swapping out the masks for parts from a video projector in the stepper
2022-12-25 18:59:42 <KipIngram   > I'd enjoy trying even that.
2022-12-25 19:00:01 <KipIngram   > It just feels like something we should be further along on.
2022-12-25 19:00:08 <Zarutian_iPad> and adapting the stuff to work with 300 mm diameter wafers
2022-12-25 19:00:33 <KipIngram   > Like I mentioned the other day, when we were talking about it - you'd have a "clean aquarium" instead of a "clean room."
2022-12-25 19:00:46 <KipIngram   > And there would be no mass production going on - just one-off work.
2022-12-25 19:00:53 <Zarutian_iPad> which is gaining dominance in industry and actually arent that expensive
2022-12-25 19:01:45 <Zarutian_iPad> ”clean aquirium” is just like a laminar flow high class hood cabinate
2022-12-25 19:02:03 <vms14       > I'd like to get to the point I can steal random stuff from a broken electronic device and do something with that
2022-12-25 19:02:25 <vms14       > like stealing a microcontroller from a radio or whatever
2022-12-25 19:02:44 <vms14       > then do something and watch how it burns
2022-12-25 19:02:55 <KipIngram   > Chuck's tiles were 4 microns square.
2022-12-25 19:03:30 <KipIngram   > Problem with that is that for micros you then need a dev system that will handle that micro.
2022-12-25 19:03:45 <Zarutian_iPad> vms14: where in the world are ya? if you are near texas you might look into visting futo.org
2022-12-25 19:03:53 <Zarutian_iPad> the location
2022-12-25 19:03:59 <vms14       > Zarutian_iPad: Barcelona
2022-12-25 19:04:25 <Zarutian_iPad> then I recommend that uou find the nearest fablab
2022-12-25 19:04:32 <Zarutian_iPad> you*
2022-12-25 19:05:34 <Zarutian_iPad> https://fablabbcn.org
2022-12-25 19:07:03 <KipIngram   > Those box drawing chars work find in my Forth; I can copy them out of the Wikipedia article and paste them into KEY.  Once I've got the value, I can print it.
2022-12-25 19:08:06 <KipIngram   > For example, 0x8394E2 is ┳
2022-12-25 19:08:56 <KipIngram   > And that was basically one of Chuck's 16 tile codes.
2022-12-25 19:10:22 <KipIngram   > What seem to be missing, though, are chars that completely fill the bottom or top half of the character cells, all the way to the top / bottom edges.
2022-12-25 19:10:35 <KipIngram   > The chars I see that are "close" have small gaps along the top/bottom.
2022-12-25 19:11:44 <vms14       > Zarutian_iPad: I'm looking at it
2022-12-25 19:12:07 <Zarutian_iPad> those chars that are “close” are supposed to be complete with no gaps top or bottom
2022-12-25 19:12:17 <vms14       > it is free?
2022-12-25 19:12:21 <vms14       > it mostly seems so
2022-12-25 19:13:30 <Zarutian_iPad> vms14: you can show up there and chat with the folks running it. During their open days that should be weekly.
2022-12-25 19:14:11 <vms14       > seems worth to give it a try
2022-12-25 19:14:15 <vms14       > thanks Zarutian_iPad :D
2022-12-25 19:31:54 <KipIngram   > Ah.  Apparently there's a Linux package, Glyphtracer, that will let you make your own fonts.
2022-12-25 19:32:09 <KipIngram   > so that would solve that problem - I could just make a font that had Chuck's tile characters in it.
2022-12-25 19:32:24 <KipIngram   > And perhaps make the chars have a square aspect ratio.
2022-12-25 19:33:02 <vms14       > hmm I want to implement 'recurse'
2022-12-25 19:33:07 <KipIngram   > Oh, btw, for those of you who missedme rejoicing last night, I found a github project that had C files containing a whole slew of bitmap fonts.
2022-12-25 19:33:14 <KipIngram   > In a nice easy to get at format.
2022-12-25 19:33:17 <Zarutian_iPad> KipIngram: have a look at https://int10h.org/oldschool-pc-fonts/readme/
2022-12-25 19:33:28 <vms14       > as my lang has nothing to do with forth I can't do it in a nice way
2022-12-25 19:33:33 <Zarutian_iPad> you might find an 8x8 font in there
2022-12-25 19:33:35 <KipIngram   > So if I get to the point of trying to drive that LCD panel, I'll have the data needed to do it.
2022-12-25 19:33:46 <KipIngram   > I'll take a look.
2022-12-25 19:34:20 <vms14       > I'm thinking in making words that use recurse a special thing, with a special way to evaluate them, which would be a loop
2022-12-25 19:34:35 <vms14       > I already had this, but the loop was for all words
2022-12-25 19:35:07 <vms14       > something like while (flag) { flag = 0; execute colon word }
2022-12-25 19:35:23 <vms14       > recurse does set this flag into 1, so the loop executes again
2022-12-25 19:35:52 <vms14       > but does not make sense to have this loop for all words, when only recursive words would apply
2022-12-25 19:38:26 <vms14       > and the "compiler" (there's no compiler, it's just the : word :D) can't really know if a word is recursive by just checking the items
2022-12-25 19:39:10 <vms14       > no cause the 'recurse' word could be inside a list, as I use lists as code too
2022-12-25 19:39:22 <vms14       > and I don't want to make the : word look recursively on every list
2022-12-25 19:39:29 <KipIngram   > In theory recursion is "call yourself," which means put a return address on the return stack.  So your ability to do true recursion is limited by the size of your return stack.
2022-12-25 19:39:52 <KipIngram   > But if the recursive call is the last call in the definition, you can convert it to a jump, which is really no longer recursion but rather iteration.
2022-12-25 19:39:59 <vms14       > so I'll make a 'recursive' function that converts a word into a subroutine with that loop
2022-12-25 19:40:10 <KipIngram   > That's called "tail recursion," and doing that conversion to a jump is something that's built into most Forth systems.
2022-12-25 19:40:17 <vms14       > KipIngram: yeah, but I don't even have a return stack :/
2022-12-25 19:40:30 <vms14       > still with this loop you can recurse for ever
2022-12-25 19:41:13 <KipIngram   > My "me" words let me make that "recursion" conditional.
2022-12-25 19:41:25 <KipIngram   > Without having to build a conditional structure around it, that is.
2022-12-25 19:41:41 <KipIngram   > It's really my only way of looping.
2022-12-25 19:42:16 <KipIngram   > I mean for this processor to fully support it, and in addition will offer that "rep" mechanism for counted loops.
2022-12-25 19:42:24 <vms14       > ah your replacement of if and alike
2022-12-25 19:42:27 <KipIngram   > rep will only work for short sequences of opcodes, though.
2022-12-25 19:42:34 <KipIngram   > Yes.
2022-12-25 19:42:56 <vms14       > that was interesting stuff
2022-12-25 19:43:22 <KipIngram   > In my system you'd take the code inside your if ... then an dput it in its own word, and lead that word off with a 0=; (return if zero).  So, if top of stack is zero, you do NOT execute that code.
2022-12-25 19:43:39 <KipIngram   > So really it's the conditional RETURN that handles IF.
2022-12-25 19:43:50 <KipIngram   > the conditional "me" stuff gets actual loops.
2022-12-25 19:43:56 <KipIngram   > Which if ... then isn't.
2022-12-25 19:45:55 <vms14       > why did you call it 'me'
2022-12-25 19:46:20 <vms14       > funny cause I was reading the ans standard for recurse
2022-12-25 19:46:23 <vms14       > This is Forth's recursion operator; in some implementations it is called MYSELF.
2022-12-25 19:46:33 <KipIngram   > Because it's equivalent to calling the word you're executing, and "me" is shorter than "self".
2022-12-25 19:47:02 <KipIngram   > Unconditional "me," which is the first thing I had, is equivalent to calling yourself by name.
2022-12-25 19:47:04 <vms14       > https://forth-standard.org/standard/core/RECURSE
2022-12-25 19:47:13 <KipIngram   > "self" would have been more "tuned in" to software lingo, for OO land.
2022-12-25 19:47:18 <KipIngram   > But "me" was shorter.
2022-12-25 19:47:33 <vms14       > it was also funny to see the way to recurse in forth is calling 'recurse'
2022-12-25 19:47:39 <KipIngram   > You know, normally you'd say
2022-12-25 19:47:46 <KipIngram   > : foo  ... ... ... foo ;
2022-12-25 19:47:54 <vms14       > cause I was blaming myself for having a function named recursion in lisp
2022-12-25 19:47:59 <KipIngram   > And Forth would convert that call to foo into a jump, since nothing comes after it.
2022-12-25 19:48:29 <vms14       > yeah that was my first way to have recursion, just call itself
2022-12-25 19:48:36 <vms14       > but I'm going to use 'recurse'
2022-12-25 19:48:38 <KipIngram   > recurse has seven characters, man.
2022-12-25 19:48:54 <KipIngram   > That takes up five more chars on your line.
2022-12-25 19:48:57 <vms14       > the reason is mainly 'recurse' is a word that sets that flag into 1
2022-12-25 19:49:21 <KipIngram   > me compiles a jump to the most recently defined name in the dictionary.
2022-12-25 19:49:26 <vms14       > so there's no need to look for the same name in a colon word definition
2022-12-25 19:49:46 <vms14       > and recurse really tells what is going to happen
2022-12-25 19:49:51 <KipIngram   > In the processor, though, I'm going to capture that address in an internal stack when I call each word.
2022-12-25 19:50:08 <vms14       > also it's a standard forth word
2022-12-25 19:50:25 <KipIngram   > So no jump target will need to be compiled - it'll just jump to whatever address is on the top of the stack.
2022-12-25 19:50:49 <KipIngram   > And I'll have an instruction that will let me overwrite that value with the now current IP, so that I can jump back to places within the word other than the beginning.
2022-12-25 19:50:51 <vms14       > I was also wondering if to make an 'alias' word, to set an alias for an existing word in the case the user didn't like some name
2022-12-25 19:50:53 <KipIngram   > :.
2022-12-25 19:51:02 <KipIngram   > I can do that now, like this:
2022-12-25 19:51:04 <vms14       > '+ 'haha alias
2022-12-25 19:51:08 <vms14       > 1 2 haha .
2022-12-25 19:51:20 <KipIngram   > : foo  ... ... : (foo)  ... ... me ;
2022-12-25 19:51:34 <KipIngram   > That will jump back to (foo), because that's the lastest name in the dictionary.
2022-12-25 19:51:51 <KipIngram   > But with this internal stack there's no need to use the dictionary at all, which is better.
2022-12-25 19:52:22 <KipIngram   > Subroutine calls will push the new word's first address onto that stack; subroutine return will pop it.  Double return will pop it twice.
2022-12-25 19:52:27 <KipIngram   > :. will overwrite it.
2022-12-25 19:53:10 <KipIngram   > It's really not an independent stack - it's more like making the return stack wider so I can keep the caller's return address and the callee's jumpback address on it, beside each other.
2022-12-25 19:55:05 <vms14       > seems to work
2022-12-25 19:55:13 <KipIngram   > Yeah, I see no reason it won't work.
2022-12-25 19:55:29 <KipIngram   > And it'll shrink my code, since I don't have to compile any targets.
2022-12-25 19:55:32 <vms14       > I meant my shit recursion xD
2022-12-25 19:55:37 <vms14       > : oh 1 2 3 .s recurse ;
2022-12-25 19:55:50 <vms14       > won't recurse unless you: 'oh recursive
2022-12-25 19:55:55 <KipIngram   > Hope you have ctrl-C working...
2022-12-25 19:56:07 <vms14       > :D
2022-12-25 19:56:10 <KipIngram   > I need to put that into mine, actually.
2022-12-25 19:56:18 <KipIngram   > I have signal handling working, so it shouldn't be too hard.
2022-12-25 19:56:40 <vms14       > once you: 'oh recursive the word gets converted into a subroutine with that loop
2022-12-25 19:56:41 <KipIngram   > right now, though, I'm only catching floating  point exceptions and addressing exceptions.
2022-12-25 19:56:48 <vms14       > recurse only sets the flag to 1
2022-12-25 19:57:00 <KipIngram   > Awfully nice no longer segfaulting every time I foul something up.
2022-12-25 19:57:11 <vms14       > https://hastebin.com/kepuperiye.pl
2022-12-25 19:58:10 <vms14       > then I'll make a 'compile.recursive' word when I have the fake compile function
2022-12-25 19:58:32 <vms14       > KipIngram: do you have documentation for your forth?
2022-12-25 19:59:04 <vms14       > I assume no, but I think it can be interesting to have a look on your forth
2022-12-25 19:59:20 <vms14       > a lot of ideas to steal :D
2022-12-25 20:00:29 <KipIngram   > Wow - glyphtracer is pretty cool.
2022-12-25 20:00:57 <KipIngram   > No, so far it's a "me only" project.  I'm going to try to do better with the processor, though - I plan to put the Verilog online.
2022-12-25 20:01:11 <vms14       > oh I need to fix it, it does not stop the remaining execution of the word
2022-12-25 20:01:32 <vms14       > : oh 1 2 .s recurse 3 .s ;  for example the 3 should never get printed
2022-12-25 20:01:35 <vms14       > it does xD
2022-12-25 20:01:52 <KipIngram   > With glyphtracer, you somehow make an image of your "alphabet."  Just a list of characters in a tabular format.
2022-12-25 20:01:54 <vms14       > I need to set another inner loop
2022-12-25 20:02:18 <KipIngram   > Prep that image (contrast, I think) using ImageMagick, then run it into glyphtracer, and it creates a font file.
2022-12-25 20:02:57 <vms14       > https://github.com/jpakkane/glyphtracer
2022-12-25 20:03:00 <vms14       > this thing?
2022-12-25 20:03:11 <KipIngram   > It outputs Spline Font Database, which you can convert to a truetype font with FontForge.
2022-12-25 20:06:56 <vms14       > https://hastebin.com/zoyipitoqe.pl
2022-12-25 20:07:00 <vms14       > now it works as it should
2022-12-25 20:07:16 <vms14       > : oh 1 2 .s recurse 3 .s ;  the 3 is never printed
2022-12-25 20:07:25 <vms14       > nor pushed
2022-12-25 20:08:27 <vms14       > KipIngram: so you're making your own fonts?
2022-12-25 20:11:46 <vms14       > also how your signal handling differs from the unix one?
2022-12-25 20:12:20 <vms14       > I assume it's similar, but that you're not going to implement term,chld,pipe,etc
2022-12-25 20:23:03 <KipIngram   > Oh, I'm talking here about my x86 Forth running under Fedora Linux.
2022-12-25 20:23:11 <KipIngram   > It uses the OS's signal handling infrastructure.
2022-12-25 20:23:33 <KipIngram   > When I catch either of those aforementioned signals, I just route control through my standard error handler.
2022-12-25 20:23:54 <KipIngram   > Which restores the system to the state it was in before I started typing the line that contained the error, and runs the QUIT loop.
2022-12-25 20:24:24 <KipIngram   > The idea is that later, when I have command history working, I can up-arrow back to that line, fix the problem, and hit enter to try again.
2022-12-25 20:24:52 <KipIngram   > My last one worked like that, but only caught the typical compile errors - it would segfault on an exception.
2022-12-25 20:25:12 <KipIngram   > But the general approach really makes errors painless.
2022-12-25 20:25:38 <KipIngram   > It's expensive, though - to make it work well I had to snapshot the WHOLE SYSTEM at the beginning of each line.
2022-12-25 20:25:47 <KipIngram   > If no errors occur, that snapshot is just abandoned.
2022-12-25 20:25:53 <KipIngram   > If an error occurs, it's restored.
2022-12-25 20:25:54 <vms14       > in perl there's a %SIG hash where you set the values as subroutines which are the handles of signals
2022-12-25 20:26:09 <vms14       > $SIG{TERM} = sub { do something };
2022-12-25 20:26:14 <KipIngram   > I found that part of Linux to be VERY poorly documented.
2022-12-25 20:26:32 <vms14       > you can set it to 'ignore' or 'default'
2022-12-25 20:26:36 <KipIngram   > Problem is that it necessarily involves implementation dependent stuff; it's not "generic" across systems.  At least the fine details aren't.
2022-12-25 20:27:39 <KipIngram   > I had to actually find where the user context was stored in the stack, and modify it to make it so when I returned it would be aimed at the error handler.
2022-12-25 20:29:22 <KipIngram   > I haven't given more than a minute or two of thought to how I might handle interrupts in this processor.  I really should pay that some attention.
2022-12-25 20:29:47 <KipIngram   > Probably will just force a word call.
2022-12-25 20:29:56 <KipIngram   > And that word will have to promise not to change the stack.
2022-12-25 20:30:42 <KipIngram   > And it will probably be easier to make it work if interrupts can "get in" after every instruction *cell*, rather than every *instruction*.
2022-12-25 20:30:51 <KipIngram   > I don't have a way of returning back into the middle of a cell.
2022-12-25 20:31:22 <KipIngram   > Though of course I could invent it - I could push the necessary info onto a small internal stack and have "iret" pop it back.
2022-12-25 20:31:49 <vms14       > it won't be hard to make a better signal handling than the unix one
2022-12-25 20:31:59 <vms14       > also threads and fork
2022-12-25 20:32:16 <KipIngram   > I'm not really aiming for something that sophisticated.
2022-12-25 20:32:28 <KipIngram   > I'm living in embedded system land at the moment.
2022-12-25 20:32:37 <KipIngram   > Interrupts are probably important.
2022-12-25 20:32:58 <KipIngram   > I don't know if I'll do multiple threads beyond the possibility of multiple cores, when there's room in my device.
2022-12-25 20:33:44 <KipIngram   > I was reading about the LCD panel I was looking at last night.
2022-12-25 20:33:52 <KipIngram   > That requires full time attention.
2022-12-25 20:34:02 <KipIngram   > The pixel data has to be streamed to it in real-time.
2022-12-25 20:34:33 <KipIngram   > The timing of this processor will be precise enough that it could do the job, but I'll probably put a manager circuit for it in there.
2022-12-25 20:35:01 <KipIngram   > And it will need to use external RAM, because there's not enough internal RAM to hold a full image.
2022-12-25 20:35:29 <vms14       > shouldn't you have an additional thing that streams the data to it?
2022-12-25 20:35:36 <KipIngram   > That means it'll be a single-port RAM, and THAT means that I'll need to access it with new data updates during the vertical or horizontal retrace periods.
2022-12-25 20:35:46 <vms14       > so you can just send updates to that thing
2022-12-25 20:35:51 <KipIngram   > Mid-line stream the graphics circuit will keep the RAM busy.
2022-12-25 20:36:09 <KipIngram   > yeah, that's exactly what I'm talking about.
2022-12-25 20:36:18 <KipIngram   > Something  like a special purpose DMA controller.
2022-12-25 20:36:57 <KipIngram   > Mostly it will just need to increment through the RAM, just resetting at the right time and getting the timing right.
2022-12-25 20:37:48 <KipIngram   > Then I'll need to decide whether to have it be "pixel graphics only" or whether to have a hardware accessed font table that lets my software work with "characters."
2022-12-25 20:37:53 <vms14       > will it flicker when sending updates?
2022-12-25 20:38:06 <KipIngram   > No, not if I do it right.
2022-12-25 20:38:17 <vms14       > like if it's receiving data it can't stream at the same moment
2022-12-25 20:38:21 <KipIngram   > That's one reason  not to try to write to the RAM with new data while it's actually sending data out.
2022-12-25 20:38:28 <KipIngram   > Yes.
2022-12-25 20:38:40 <KipIngram   > So I'll need to restrict the updates to the retrace periods.
2022-12-25 20:39:06 <KipIngram   > You get one at the end of each  pixel line (horizontal retrace) and one at the end of each frame (vertical retrace).
2022-12-25 20:39:22 <vms14       > I think you can find screens that automatically handle that
2022-12-25 20:39:35 <KipIngram   > You can, and maybe I will.
2022-12-25 20:39:39 <KipIngram   > But... it's fun.
2022-12-25 20:39:42 <vms14       > but you like this kind of stuff
2022-12-25 20:39:46 <vms14       > haha I knew it
2022-12-25 20:39:53 <KipIngram   > To some extent the more of this I do myself the more pleased I am.
2022-12-25 20:40:29 <vms14       > yeah and also makes the device be able to work with those kind of screens
2022-12-25 20:40:40 <KipIngram   > Which will tend to be cheaper.
2022-12-25 20:41:03 <vms14       > if you want to upgrade to another screen, it will be easier
2022-12-25 20:41:10 <vms14       > but you won't be restricted to them
2022-12-25 20:41:39 <KipIngram   > Yeah; if I get this working I'll probably want an actual tablet-size thing too.
2022-12-25 20:41:48 <KipIngram   > This is intended to be shirt-pocket size.
2022-12-25 20:42:32 <KipIngram   > I want to be able to hold it, landscape, in the palm of my left hand, and write on it with my right hand with a stylus.
2022-12-25 20:42:45 <KipIngram   > I want the old original Palm Graffiti.
2022-12-25 20:42:49 <KipIngram   > As my input method.
2022-12-25 20:42:53 <KipIngram   > That stuff WORKED.
2022-12-25 20:42:59 <KipIngram   > But they got sued, and they had to change it.
2022-12-25 20:43:13 <KipIngram   > The changed version was never as good.
2022-12-25 20:43:58 <KipIngram   > The Palm Vx had a dedicated Grafitti area down at the bottom, but I want to just use the whole screen.
2022-12-25 20:44:11 <KipIngram   > With no markings related to it.
2022-12-25 20:44:22 <KipIngram   > And a good block editor is a primary goal.
2022-12-25 20:44:33 <KipIngram   > So that I can diddle with my system software "whereever."
2022-12-25 20:45:07 <KipIngram   > What I'm picturing is a setup where I can edit a screen, save it, and cycle the whole thing very quickly, to try the change out.
2022-12-25 20:45:11 <KipIngram   > If it works, great.
2022-12-25 20:45:25 <KipIngram   > But if I hose myself, there should be an easy way to revert the last save.
2022-12-25 20:45:33 <KipIngram   > Or the last several, or whatever.
2022-12-25 20:49:29 <vms14       > :0
2022-12-25 20:49:39 <vms14       > I always wanted a umpc with a keyboard
2022-12-25 20:49:51 <vms14       > that's why I have a gpd micro pc
2022-12-25 20:56:08 <KipIngram   > Battery wise I just want it to handle "heavy use all day," and recharging it every night is fine.
2022-12-25 20:56:22 <KipIngram   > Don't want it to be "iffy" about making it through the day.
2022-12-25 20:56:34 <KipIngram   > The LCD will be the big power consumer.
2022-12-25 20:59:00 <KipIngram   > Oh, this glyphtracer approach is nice - once you have a TrueType font, the system can resize it, so that takes care of the zooming issue.
2022-12-25 21:06:57 <KipIngram   > Wow - FontForge is rather amazing.
2022-12-25 21:18:23 <KipIngram   > The part of the whole chip design process (a la Chuck) that particularly fascinates me is the extraction of the netlist and the simulation.
2022-12-25 21:18:44 <KipIngram   > It would be interesting to experiment with that, starting with a single transistor.
2022-12-25 21:19:31 <vms14       > this gpd micro pc has a shit battery
2022-12-25 21:19:42 <vms14       > it's the only real complaint I have with it
2022-12-25 21:20:04 <vms14       > but is super cool to have a computer in your pocket and program wherever you go
2022-12-25 21:20:43 <vms14       > KipIngram: you can start simulating a transistor without a gui
2022-12-25 21:21:06 <KipIngram   > Sure.
2022-12-25 21:21:26 <KipIngram   > But the capacitance data comes from the geometry.  I could just punch in coordinates, I suppose.
2022-12-25 21:21:43 <KipIngram   > But the extraction of the netlist and the calculation of the capaictances - that's interesting too.
2022-12-25 21:21:54 <KipIngram   > Those bits are all kind of tied together.
2022-12-25 21:23:01 <vms14       > well I'd say to not rush into something just because you want to do X thing
2022-12-25 21:23:18 <KipIngram   > :-)  I find it all interesting.
2022-12-25 21:23:24 <vms14       > like wanting to do that cad so hard that you rush the screen stuff
2022-12-25 21:23:35 <KipIngram   > If I just want to simulate a transistor I can use spice.
2022-12-25 21:23:47 <vms14       > specially when the screen stuff needs to be thought with time, as you choose the hard way
2022-12-25 21:24:10 <vms14       > ah, right you have a forth in linux too
2022-12-25 21:24:21 <vms14       > you could use whatever gui library there
2022-12-25 21:24:21 <KipIngram   > I'm mixing up talk about my x86 Forth and the pocket gadget here; it's not all single-thread.
2022-12-25 21:25:20 <vms14       > a sad way to do it could be to pipe your forth into a wrapper that does the gui stuff
2022-12-25 21:25:25 <vms14       > it's not nice
2022-12-25 21:25:35 <MrMobius    > re chip fab, what's the advantage over an FPGA other than hassle of config mem and soldering package? ie faster clock speed or less power consumption?
2022-12-25 21:26:28 <KipIngram   > You don't really need to worry - I'm not going to do anything I don't want to do.  The point of all of these things is that they strike me as fun.
2022-12-25 21:27:19 <KipIngram   > Well, custom chip can be faster and lower power, but a custom chip *I* could afford wouldn't be faster than a commercial FPGA, because it would use some huge primitive process.
2022-12-25 21:27:29 <KipIngram   > So even though that is an "advantage," it's not in this context.
2022-12-25 21:27:54 <KipIngram   > The main payoff for me, in the situation I've described, would be the accomplishment of having done yet another layer of it myself.
2022-12-25 21:28:43 <vms14       > and price :D
2022-12-25 21:28:44 <KipIngram   > Without using someone's chip design, without using someone's fancy synthesis hardware, etc. etc.
2022-12-25 21:28:56 <KipIngram   > Oh, a chip would cost me a hell of a lot more.
2022-12-25 21:29:01 <vms14       > :/
2022-12-25 21:29:08 <KipIngram   > I'd have to want it really badly - you're talking "new car" kind of price.
2022-12-25 21:29:42 <thrig       > getting someones grad students to do it is one trick
2022-12-25 21:29:44 <KipIngram   > I've only been in financial shape to consider something like that once in my life, and I'm not really expecting it again.
2022-12-25 21:29:59 <KipIngram   > That was right after the little company I worked for got bought by my current employer.
2022-12-25 21:30:18 <KipIngram   > But I sank most of that into home equity and had to pay for some expensive treatment for one of my daughters.
2022-12-25 21:30:36 <KipIngram   > I guess in theory I've still "got" the home equity.
2022-12-25 21:31:37 <KipIngram   > These days things are "fine," but I don't feel like I've got piles of cash lying around.
2022-12-25 21:35:19 <vms14       > for some reason I'm always happy after creating the emit word
2022-12-25 21:35:20 <vms14       > xD
2022-12-25 21:35:48 <vms14       > then I do: 42 emit   and smile when I see the *
2022-12-25 21:36:04 <vms14       > I suppose it's cause the starting forth book
2022-12-25 21:41:30 <KipIngram   > Plus it's "the answer."
2022-12-25 21:43:15 <vms14       > yeah, it was fun to see * is the answer of everything as * is a metacharacter to match everything in a regex
2022-12-25 21:43:53 <KipIngram   > :-)
2022-12-25 21:44:33 <KipIngram   > It was also Jackie Robinson's team number.
2022-12-25 21:59:31 <vms14       > I realized most of my words take 2 elements
2022-12-25 22:00:07 <vms14       > I have two functions to take elements from the stack, get and getn, get takes 1 element and getn the number of elements you want
2022-12-25 22:00:16 <vms14       > I made a get2 function xD
2022-12-25 22:00:37 <vms14       > it does not really improve much the performance
2022-12-25 22:01:09 <vms14       > 0 1 1000000 range [ + ] do.list .   this takes 3 seconds
2022-12-25 22:01:25 <vms14       > now that + uses get2  takes 2.8 seconds
2022-12-25 22:02:58 <vms14       > still it's sad to see that a real forth takes 0.0X seconds for the same operation
2022-12-25 22:03:33 <vms14       > but meh, as long as I can make a simple game I don't need that performance
2022-12-25 22:07:07 <vms14       > I'm reading the forth fundamentals book and adding the words I see there
2022-12-25 22:14:32 <vms14       > KipIngram: I see the book says 1 pick is equivalent to dup
2022-12-25 22:14:40 <vms14       > 2 pick is equivalent to over
2022-12-25 22:14:55 <vms14       > but in pforth 0 pick is dup and 1 pick is over
2022-12-25 22:15:27 <vms14       > in pforth: 1 2 3 1 pick    ok =>  1 2 3 2
2022-12-25 22:15:47 <vms14       > 1 2 3 0 pick    ok => 1 2 3 3
2022-12-25 22:16:03 <vms14       > which one I should believe xd
2022-12-25 22:16:45 <vms14       > https://forth-standard.org/standard/core/PICK
2022-12-25 22:16:56 <vms14       > the standard says it's like pforth
2022-12-25 22:17:04 <vms14       > so the book seems wrong there
2022-12-25 22:25:34 <vms14       > but roll in pforth seems wrong
2022-12-25 22:25:50 <vms14       > the book says it's like in the standard
2022-12-25 22:26:10 <vms14       > ah no, the book is wrong again
2022-12-25 22:26:11 <vms14       > xD
2022-12-25 22:26:17 <vms14       > pforth is fine
2022-12-25 22:26:37 <vms14       > the standard says: 2 ROLL is equivalent to ROT, 1 ROLL is equivalent to SWAP and 0 ROLL is a null operation.
2022-12-25 22:26:54 <vms14       > the book says 3 roll is equivalent to rot
2022-12-25 22:27:13 <vms14       > 2 swap and 1 null
2022-12-25 22:27:52 <thrig       > one wonders how much test code was behind the book
2022-12-25 22:29:51 <vms14       > I hope it only was that time, as it talks about roll and pick at the same time
2022-12-25 22:33:57 <vms14       > I miss a lot a way to reset the stack in a real forth
2022-12-25 22:34:09 <vms14       > more than making an error xD
2022-12-25 22:34:30 <vms14       > I have 'r' to reset the stack, as I don't have a return stack anyways
2022-12-25 22:34:55 <vms14       > I use it a lot while testing words
2022-12-25 22:35:36 <KipIngram   > That's adding all the numbers up to ten million?
2022-12-25 22:36:09 <vms14       > yes
2022-12-25 22:36:19 <vms14       > you did that benchmark some time ago I guess
2022-12-25 22:36:28 <vms14       > and it was like 0.0X
2022-12-25 22:36:31 <vms14       > 
ACTION cries

2022-12-25 22:40:01 <KipIngram   > Oh, I remember that now.
2022-12-25 22:40:17 <KipIngram   > I think we're just working in entirely different ways.
2022-12-25 22:40:32 <vms14       > haha obviously
2022-12-25 22:40:56 <vms14       > I'm relying a lot on a scripting language while you're doing everything from scratch
2022-12-25 22:41:06 <KipIngram   > Some of the data structure manipulation your stuff does under the hood would probably be a lot of work for me.
2022-12-25 22:41:09 <vms14       > also my lang has almost nothing to do with forth
2022-12-25 22:41:38 <vms14       > I feel in my case it's counterproductive to make a real forth with a scripting lang
2022-12-25 22:41:41 <KipIngram   > Mine was designed from the start to have as "little overhead" as possible.
2022-12-25 22:41:44 <vms14       > I could, but makes no sense
2022-12-25 22:41:56 <vms14       > I have already a call stack, garbage collection, etc
2022-12-25 22:42:10 <KipIngram   > It's really just a very straightforward design - it's certainly not the fastest Forth around.
2022-12-25 22:42:40 <vms14       > still I can't compete with something written in asm
2022-12-25 22:42:49 <vms14       > even the js implementation takes 0.3 seconds for that
2022-12-25 22:42:55 <thrig       > fear not, you can write stupid asm too
2022-12-25 22:42:56 <vms14       > while the perl takes 3
2022-12-25 22:43:12 <vms14       > thrig: yeah, but I want gui, sockets, db, etc
2022-12-25 22:43:19 <vms14       > the thing would be to write it in C
2022-12-25 22:43:34 <KipIngram   > I just did this:
2022-12-25 22:43:38 <vms14       > but it's a lot of headache just to get a performance I'm not sure I need
2022-12-25 22:43:38 <KipIngram   > uet 1000000 * + uet 1000000 * + swap - . 72  ok
2022-12-25 22:43:49 <KipIngram   > That says that the two calls to uet were 72 microseconds apart.
2022-12-25 22:44:44 <KipIngram   > On the other hand,
2022-12-25 22:44:48 <KipIngram   > : test uet 1000000 * + uet 1000000 * + swap - . ;  ok
2022-12-25 22:44:50 <KipIngram   > test 1  ok
2022-12-25 22:44:52 <KipIngram   > test 0  ok
2022-12-25 22:44:54 <KipIngram   > test 0  ok
2022-12-25 22:44:56 <KipIngram   > test 0  ok
2022-12-25 22:44:58 <KipIngram   > test 0  ok
2022-12-25 22:45:05 <KipIngram   > Compile it and the microsecond counter usually doesn't even tick.
2022-12-25 22:45:14 <KipIngram   > Just happened to on that first one; caught it just right.
2022-12-25 22:45:29 <vms14       > :0
2022-12-25 22:45:42 <KipIngram   > If I ran it a thousand times and averaged (scaled of course) I could get a sub-microsecond measure.
2022-12-25 22:49:33 <vms14       > btw I see roll is kind of a discouraged word in forth
2022-12-25 22:49:43 <vms14       > that using pick and roll means you're a noob
2022-12-25 22:49:44 <vms14       > xD
2022-12-25 22:50:03 <vms14       > well, means that you're not factoring properly and you're messing too much with the stack
2022-12-25 22:50:37 <vms14       > I'd like to have some forth words so a forthwright does not feel too sad using this lang
2022-12-25 22:50:46 <vms14       > it will feel sad anyways for a number of reasons xD
2022-12-25 22:51:06 <vms14       > but still some basic stack manipulation words should exist
2022-12-25 22:51:50 <vms14       > anyways I guess I won't implement roll
2022-12-25 22:52:08 <vms14       > already implemented pick, but I don't think I would use any of those
2022-12-25 22:52:39 <vms14       > I also will have a way to bind temporary words so meh
2022-12-25 22:52:49 <vms14       > I won't even use swap over rot or alike
2022-12-25 22:53:01 <vms14       > only dup sometimes when I don't want to bind a value
2022-12-25 22:56:48 <KipIngram   > Yeah, roll has to move every word all the way down to the one you target.
2022-12-25 22:57:12 <KipIngram   > Inefficient, and it's considered bad form to "deal with" items deeper than a couple or three on the stack.
2022-12-25 22:57:20 <KipIngram   > I'm of mixed feelings on that.
2022-12-25 22:57:23 <KipIngram   > I get the reasoning.
2022-12-25 22:57:53 <KipIngram   > But in my current implementation I've found words that can access (but not MOVE) several more than 2-3 to be extremely useful.
2022-12-25 22:58:08 <vms14       > well I can't care about efficiency
2022-12-25 22:58:23 <KipIngram   > Well, not *frequently* useful, but very valuable in the cases where I needed them.
2022-12-25 22:58:30 <vms14       > but spending time implementing a thing I won't ever use makes no sense
2022-12-25 22:58:35 <KipIngram   > I try to confine my work to the top 2-3.
2022-12-25 22:58:43 <vms14       > and if I feel I need it, I can provide it at any time
2022-12-25 22:58:56 <KipIngram   > Yeah - I wouldn't put it in "just for fun."
2022-12-25 22:59:11 <vms14       > but it's not fun xD
2022-12-25 22:59:13 <KipIngram   > I don't  have roll in my system.  My stack access words were more akin to PICK.
2022-12-25 22:59:22 <KipIngram   > Except I could store to a deep item as well as load from.
2022-12-25 22:59:38 <KipIngram   > PICK doesn't move all the data in between.
2022-12-25 23:00:18 <dave0       > 
ACTION is a noob :-)

2022-12-25 23:00:45 <KipIngram   > Hey, I don't know if you can claim that honor anymore, man.
2022-12-25 23:00:54 <KipIngram   > You've been around the Forth block a few times.
2022-12-25 23:00:55 <dave0       > ehehe
2022-12-25 23:01:30 <vms14       > anyways I won't follow forth too much
2022-12-25 23:01:37 <dave0       > i only did pick and roll, and i made dup & over use pick and swap & rot use roll
2022-12-25 23:01:42 <KipIngram   > vms14: I'm making decisions about stack access right now on the processor.  My old HP calculator in college let me access the top four items fairly flexibly.
2022-12-25 23:01:49 <vms14       > for example 'and' and 'or' are similar to lisp instead of forth
2022-12-25 23:02:04 <vms14       > and they take  a list of instructions to execute
2022-12-25 23:02:05 <KipIngram   > In particular, in addition to SWAP (which it called X<>Y), it offered X<>Z and X<>T.
2022-12-25 23:02:15 <vms14       > [ 1 2 3 ] and
2022-12-25 23:02:15 <KipIngram   > I can add those amost for free, and I think I'm probably going to.
2022-12-25 23:02:28 <KipIngram   > The logic necessary to do the motions is already there.
2022-12-25 23:02:35 <vms14       > will execute the instructions until one returns a false value or the end
2022-12-25 23:02:45 <vms14       > the last instruction value will be returned
2022-12-25 23:02:47 <KipIngram   > It would also let me store to and fetch from all of those.
2022-12-25 23:02:50 <vms14       > also accepts nested lists
2022-12-25 23:02:57 <vms14       > [ 1 [ 2 3 ] 4 ] and
2022-12-25 23:02:58 <KipIngram   > On that calculator that was the whole stack - it was only four deep.
2022-12-25 23:03:11 <vms14       > same for 'or' but will stop when some value is true and return that
2022-12-25 23:03:34 <vms14       > [ 0 1 2 ] or   returns 1
2022-12-25 23:03:40 <vms14       > 2 will never be executed
2022-12-25 23:03:45 <KipIngram   > I see.
2022-12-25 23:03:56 <KipIngram   > that's how conditionals work in some languages.
2022-12-25 23:04:05 <vms14       > I like them, and also work like a normal and and or
2022-12-25 23:04:11 <KipIngram   > As soon as you know what the result has to be, it doesn't process any more.
2022-12-25 23:04:33 <vms14       > they're useful for me
2022-12-25 23:04:40 <KipIngram   > The problem with store and recall to stack locations, though, is that in Forth ! and @ move the stack pointer.
2022-12-25 23:04:45 <vms14       > [ some-word another-word ] or
2022-12-25 23:04:51 <KipIngram   > So... are you storing to the old Z, or the new Z?
2022-12-25 23:04:59 <vms14       > if some-word returns false, I'll get the another-word value
2022-12-25 23:05:09 <KipIngram   > On the calculator, store didn't drop the item from top of stack.
2022-12-25 23:05:16 <KipIngram   > But of course, fetch pushed the stack.
2022-12-25 23:05:29 <KipIngram   > It would fetch the register content from before the command.
2022-12-25 23:06:10 <vms14       > also makes no sense to start adding forth words if I won't use them
2022-12-25 23:06:22 <KipIngram   > I agree.
2022-12-25 23:06:30 <vms14       > so if a forthwright ends trying my lang he will just cry
2022-12-25 23:06:46 <KipIngram   > Chuck would sometimes drop words, if he found better ways to do things.
2022-12-25 23:07:16 <vms14       > and most words won't behave as he expects
2022-12-25 23:07:21 <vms14       > but I like emit :D
2022-12-25 23:07:54 <KipIngram   > In one of those UltraTechnology papers Jeff Fox said that "most of us Forth folk" were ten years or so behind Chuck.  We were out here coding the way he did back then, and meanwhile he'd moved on.
2022-12-25 23:08:37 <vms14       > well it's hard to pass a guy in his own language
2022-12-25 23:08:54 <vms14       > unless he teaches you
2022-12-25 23:09:22 <vms14       > which is fine for me as my lang will be my own design stealing concepts from whatever I see
2022-12-25 23:09:57 <vms14       > I'd say to chuck, look at those sockets storing data into a db and showing it in a gui
2022-12-25 23:10:31 <vms14       > nah, I'd like the lang to be at least 10% of correct as forth is
2022-12-25 23:10:38 <KipIngram   > What kind of makes me cry, though, is to see Forth written like this:
2022-12-25 23:10:41 <KipIngram   > FORTH : ]   BEGIN 2 -'  IF  1 -FIND IF  NUMBER  \ LITERAL
2022-12-25 23:10:42 <KipIngram   >    ELSE DUP @
2022-12-25 23:10:44 <KipIngram   >       DUP 140040 AND  140040 =  OVER 170377 AND  140342 XOR AND
2022-12-25 23:10:46 <KipIngram   >       SWAP 170040 AND  100040 = OR IF  @ 40 XOR  ,C
2022-12-25 23:10:48 <KipIngram   >       ELSE  ,A  THEN THEN
2022-12-25 23:10:50 <KipIngram   >    ELSE  EXECUTE  THEN AGAIN ;  RECOVER
2022-12-25 23:10:57 <KipIngram   > That's... a ghastly long definition.
2022-12-25 23:11:18 <KipIngram   > That's from cmForth, so I assume it was originally written by Chuck himself.
2022-12-25 23:11:27 <KipIngram   > That's just not how my Forth code looks anymore.
2022-12-25 23:12:21 <vms14       > well you may be one of the exceptions from that paper
2022-12-25 23:12:46 <vms14       > stuff like your conditionals are cool
2022-12-25 23:13:25 <vms14       > and it makes no sense to implement your lang exactly like forth is if another way suits you better
2022-12-25 23:13:37 <vms14       > forth was just the way chuck thinks
2022-12-25 23:13:58 <KipIngram   > Fox also stated, though, that he had analyzed a bunch of Chuck's code and found the average definition length to be 44 characters.
2022-12-25 23:14:01 <vms14       > you can learn from it and adapt it to your own way
2022-12-25 23:14:08 <KipIngram   > Now... that's a lot more like it.  I usually come in between 40 and 50.
2022-12-25 23:14:51 <vms14       > haha my code is much larger
2022-12-25 23:14:59 <vms14       > I have to learn to use my lang yet
2022-12-25 23:15:06 <vms14       > and to get used to refactor
2022-12-25 23:15:16 <vms14       > https://termbin.com/t63b
2022-12-25 23:15:22 <vms14       > this is a broken snake game
2022-12-25 23:15:25 <KipIngram   > Yeah, I factor a lot better than I used to.
2022-12-25 23:15:33 <KipIngram   > I think it just takes a little while to start thinking that way.
2022-12-25 23:15:37 <vms14       > does not even work and the code sucks a lot
2022-12-25 23:18:28 <vms14       > https://vms.neocities.org/a.html
2022-12-25 23:18:34 <vms14       > this was fun xd
2022-12-25 23:19:20 <vms14       > https://termbin.com/hg2t this is the code of that kind of screensaver
2022-12-25 23:20:47 <vms14       > but for example the move.up down left right should be one word
2022-12-25 23:21:09 <vms14       > they share a lot of common code, just only one thing changes
2022-12-25 23:21:16 <vms14       > and I can have metaprogramming
2022-12-25 23:22:08 <vms14       > for example another version where the dots move randomly
2022-12-25 23:22:21 <vms14       > :dot :dot .x [ ++ -- ] pick.random eval .x!      :dot :dot .y [ ++ -- ] pick.random eval .y
2022-12-25 23:22:41 <vms14       > it evaluates ++ or -- randomly
2022-12-25 23:22:50 <KipIngram   > Or you could take all that common code at the end and put it in a word of its own, then call that word from the two places.
2022-12-25 23:22:59 <KipIngram   > : move.up  pre -- post ;
2022-12-25 23:23:07 <KipIngram   > : move.down  pre ++ post ;
2022-12-25 23:23:14 <vms14       > yeah
2022-12-25 23:23:23 <vms14       > but not that repetition I have
2022-12-25 23:24:26 <vms14       > brb