2022-12-26 00:46:01 <KipIngram   > Well, I got Icarus Verilog and GTKWave running and did a quick test of a four-bit counter.  Turned out just right.
2022-12-26 00:46:26 <KipIngram   > https://imgur.com/a/pYCKPWe
2022-12-26 00:46:38 <KipIngram   > No rocket science there.
2022-12-26 00:47:14 <KipIngram   > I presume I could feed the processor into it with initial RAM contents corresponding to some instruction sequence and then evaluate the RAM and register content at the end to see if it ran right.
2022-12-26 00:47:34 <KipIngram   > I'm not well-calibrated on how long such a thing would take - that counter of course took no perceptible time.
2022-12-26 01:01:05 <KipIngram   > So, I don't find Chuck's "OK" operating system to be of terribly much interest.  He did that work while he was fooling around with that 7-key keyboard, and he was also on his "sourceless programming" jag, which he later declared to be a failure.
2022-12-26 01:01:46 <KipIngram   > He more or less constructed the OK system "in memory," directly in machine code, and it didn't even really have a Forth associated with it.
2022-12-26 01:02:23 <KipIngram   > Later he said that he reached the point where he needed to automate various processes, and he had no good way to do it - the menu driven structure of the operating system didn't lend itself well to that work.
2022-12-26 01:03:41 <KipIngram   > Also, he apparently later did want to see the source code that his system would correspond to, and it turned out that that source code was not unique - there was no way to decompile the system with "certainty" into unambiguous source.
2022-12-26 01:03:53 <KipIngram   > He went back to using Forth as his foundation layer.
2022-12-26 01:04:30 <KipIngram   > I kind of write the whole phase off as something that turned into a dead end.
2022-12-26 05:25:14 <eris[m]     > <KipIngram> "Later he said that he reached..." <- couldnt it be done as treating each menu as an opcode of sorts
2022-12-26 10:01:29 <KipIngram   > I assume he found some way to get through it; after all, what you just said would work.  But I think he found it cumbersome.
2022-12-26 10:04:55 <KipIngram   > I presume that it was merely somehow recording what actions he took, but rather it was going through various processes algorithmicaly.  Honestly, I think it gets a little bit at the fact that a command interface can be a lot more productive than a GUI if you know how to use it.
2022-12-26 10:05:40 <KipIngram   > I've always felt like what a GUI mainly accomplishes is to offer a way for lese competent users to "stumble there way through" some work.
2022-12-26 10:05:50 <KipIngram   > Those menu items and so on - they're like crib notes.
2022-12-26 10:06:09 <KipIngram   > dialog boxes tell you what information to put where, etc.
2022-12-26 10:06:38 <KipIngram   > On a command line you could type anything whatsoever - you have to KNOW what to type.
2022-12-26 10:07:05 <eris[m]     > KipIngram: a CLI is less helpful when you're woeking with inherently visual things, however
2022-12-26 10:07:09 <KipIngram   > There's no built in guidance.  Though I've seen CLIs that flash up hints, so there is a middle ground.
2022-12-26 10:07:14 <thrig       > a gui is handy to look at western music notation with
2022-12-26 10:07:23 <eris[m]     > lord knows I'd want to die if I had to typeset a document in ed
2022-12-26 10:07:30 <KipIngram   > Yeah, I do think there are applications for which a GUI is "natural."
2022-12-26 10:07:35 <eris[m]     > same goes for edit a video together with ffmpeg
2022-12-26 10:07:58 <KipIngram   > I don't think there's a "one size fits all."
2022-12-26 10:08:28 <KipIngram   > I've long wondered if I could cook up an effective PCB layout tool that worked at the console level, but I've never really come up with anything good.
2022-12-26 10:08:46 <KipIngram   > Some tasks bear too much information for you to hold in your head.
2022-12-26 10:09:21 <KipIngram   > But in those cases (maybe this is the way to spit them), it's the TASK ITSELF that has the visual information, not the "how the computer works."
2022-12-26 10:09:46 <eris[m]     > something that really, really irks me is the fact that people use CLI synonymously with terminal
2022-12-26 10:09:58 <KipIngram   > It's your LAYOUT you can't keep all in your head without an image in front of you.
2022-12-26 10:10:08 <eris[m]     > vim is not a CLI editor :v
2022-12-26 10:10:26 <eris[m]     > ex is, vim isnt
2022-12-26 10:10:31 <KipIngram   > That's fair, yeah.  And it's the content of your file that it displays to you.
2022-12-26 10:10:34 <f-a         > ed
2022-12-26 10:10:40 <eris[m]     > no
2022-12-26 10:10:41 <eris[m]     > ex
2022-12-26 10:10:46 <KipIngram   > Same idea, just with text instead of imagery.
2022-12-26 10:10:51 <f-a         > ed is too
2022-12-26 10:10:55 <eris[m]     > mhm
2022-12-26 10:11:11 <eris[m]     > but i brought up ex because ex is the cli editor of vim
2022-12-26 10:11:14 <KipIngram   > It doesn't have info up there on the screen about what key to hit next to run a particular function.
2022-12-26 10:11:15 <f-a         > and the (closest to) original one, I suspect
2022-12-26 10:11:16 <f-a         > yeah
2022-12-26 10:11:22 <f-a         > ex is a new and improved version
2022-12-26 10:11:27 <f-a         > actually quite useful to learn
2022-12-26 10:11:35 <f-a         > sometimes ssh connections are broken
2022-12-26 10:11:38 <eris[m]     > thats because ex is inside vim
2022-12-26 10:11:45 <f-a         > also tun understand how blind peple use the terminal
2022-12-26 10:11:47 <eris[m]     > f-a: i'd use sshfs :)
2022-12-26 10:11:48 <KipIngram   > That collapseos had some interesting line editor methods built into it.
2022-12-26 10:12:06 <KipIngram   > I had the feeling it would actually be a fairly effective editor.
2022-12-26 10:12:09 <eris[m]     > i use a Tk gui text editor for my day to day
2022-12-26 10:12:12 <KipIngram   > They had a screen editor too, though.
2022-12-26 10:12:35 <eris[m]     > it's about 70 odd lines because most of the work is done for me by Tk
2022-12-26 10:12:59 <KipIngram   > What's it called?
2022-12-26 10:13:37 <KipIngram   > That collapseos line editor worked by searching for patterns for you.
2022-12-26 10:13:50 <KipIngram   > You'd type a word, it would find it and "place" the cursor there for you.
2022-12-26 10:14:06 <eris[m]     > Ha!
2022-12-26 10:14:12 <eris[m]     > That's the canon cat
2022-12-26 10:14:17 <KipIngram   > People do that in vim, too - sometimes instead of moving the cursor myself I'll /<pattern> to move the cursor to that spot.
2022-12-26 10:14:29 <KipIngram   > Usually followed by moving a character or two or three to get to my final location.
2022-12-26 10:14:35 <eris[m]     > Uxn's text editor, Left, has that
2022-12-26 10:14:51 <eris[m]     > and my editor has a similar functionality (that i barely use tbf)
2022-12-26 10:15:07 <eris[m]     > let me pull up a gif of my similar functionality
2022-12-26 10:15:20 <KipIngram   > I probably move the cursor that way maybe 10% of the time.
2022-12-26 10:15:25 <KipIngram   > Usually I'm not moving very far.
2022-12-26 10:15:33 <thrig       > what do you mean there's no keys to quickly get to the 3rd f on this line
2022-12-26 10:15:36 <KipIngram   > And just moving is faster.
2022-12-26 10:16:56 <eris[m]     > hmm, i seem to have accidentally deleted my demo gifs from my phone D:
2022-12-26 10:18:54 <eris[m]     > 
ACTION uploaded a video: (4874KiB) < https://libera.ems.host/_matrix/media/v3/download/the-apothecary.club/2ad48c23cfae5baeaf79b51f62d73548fa5d7795/c58ff4c5616539af(1).mp4 >

2022-12-26 10:19:17 <eris[m]     > here's 'leap'
2022-12-26 10:19:58 <eris[m]     > you select a pattern, press control-f once to put it in the 'find buffer', then press control f again to find the next occurence
2022-12-26 10:20:23 <eris[m]     > itd be nice to rework it so that you could type into said buffer directly if you held control f
2022-12-26 10:41:50 <KipIngram   > That's close to how collapseos line editor worked.
2022-12-26 10:41:59 <KipIngram   > I'd have to look it up again to remember for sure.
2022-12-26 10:44:17 <thrig       > also vis apparently has some neat ideas, but I'm too wedded to vi to try it
2022-12-26 11:06:13 <KipIngram   > Yeah, I feel no strong compulsion to explore other editors.
2022-12-26 11:06:43 <KipIngram   > It is a catch-22; it's perfectly possible something "better" might come along - potentially much better.  But I *know* vim.
2022-12-26 11:06:51 <KipIngram   > Learning curves aren't always fun.
2022-12-26 11:19:11 <KipIngram   > It's a little hard for me to imagine what would be "much better" than vim or emacs, though - they're both pretty darn usable.
2022-12-26 11:19:51 <KipIngram   > Some of the guys at the office are so good with one or the other of them that it makes me feel like a child by comparison.
2022-12-26 11:20:31 <KipIngram   > Mostly vim, but we do have a couple of emacs guys.
2022-12-26 11:21:04 <KipIngram   > Of course, I don't use vim all day every day the way they do.
2022-12-26 11:22:34 <KipIngram   > So I think I'll start on this verilog work with this piece I've been talking about - the data stack / ALU section.  The instruction word register is a good division point - there will of course be logic outside of that depositing new instruction words in that register from time to time, but this piece will be responsible for stepping through the opcodes in that word, if that's the kind of word it is.
2022-12-26 11:24:45 <KipIngram   > I guess that register is the very first thing to do.  The two leftover bits will have a particular value if it's an opcode word, and in that case I then need to roll it through five or ten bits per cycle.
2022-12-26 11:25:12 <KipIngram   > I'm sorry - six or twelve.
2022-12-26 11:26:54 <KipIngram   > Each time it reaches the end, then an extra cycle will get inserted during which this part will be idle - that's the cycle for outside logic to manage reloading the IW.
2022-12-26 11:27:53 <KipIngram   > So that means a 4-1 mux on each register input.  6 bits up, 12 bits up, or "new data."  The fourth input will be a copy of the original instruction word - that will support rep.
2022-12-26 11:34:14 <KipIngram   > So I see four control signals for that.  Enable for the working IW, enable for the rep copy IW, and two selector bits.
2022-12-26 11:45:41 <KipIngram   > I probably want to have a "fault" signal that fires if an illegal condition is detected.  An example would be for the opcode in the last slot of an instruction word to be one that requires a conditional field.
2022-12-26 11:46:23 <KipIngram   > Another might be a misaligned fetch or store that would require accessing two cells of RAM.
2022-12-26 11:47:31 <KipIngram   > Or an unimplemented opcode, possibly, though I could just ignore those.
2022-12-26 11:53:11 <KipIngram   > Hmmm.  Actually IW doesn't need to have a direct input from the outside.  On the cell cycle I can load the copy register, and then on the first opcode cycle I can load IW from that.
2022-12-26 11:53:48 <KipIngram   > That frees an input on that 4-1 selector; one thing I could do with that would be to tie it to TOS and support EXECUTE on not only a CFA but also a word full of opcodes.
2022-12-26 11:54:35 <KipIngram   > Oh, no, I guess that's no good - I'd need to get that into the copy register too.  That would add delay.
2022-12-26 11:54:45 <KipIngram   > Might not matter - I'll keep it in mind.
2022-12-26 11:57:56 <KipIngram   > Oh, that extra input might come in handy if I decide to try to eliminate the cell cycle and have only opcode cycles.
2022-12-26 12:14:06 <KipIngram   > So this state machine will sit there in the cell acquire state.  Occasionally external logic will drop a new word into the copy register.  Only if bits 1 and 0 of that word say "opcodes" will it proceed into the remainder of the machine.
2022-12-26 12:14:18 <KipIngram   > Otherwise it will just sit there and do nothing.
2022-12-26 12:18:57 <KipIngram   > https://imgur.com/gallery/fa08Wy4
2022-12-26 12:19:21 <KipIngram   > That 4-1 selector will be built into the slice with the IW flip flops.
2022-12-26 12:22:36 <KipIngram   > I don't immediately think of any reason I shouldn't be able to EXECUTE a cell full of opcodes, but this isn't the part of the system that will handle that.
2022-12-26 12:22:50 <KipIngram   > The decisions and IP management related to it, I mean.
2022-12-26 12:43:08 <KipIngram   > I think I can handle rep here internally in this section.  If it sees rep, it will reset its state machine and NOT assert "valid opcode" to the external logic.
2022-12-26 12:45:04 <KipIngram   > This section will clear the copy register to zero when it finishes with a word, and will return to state zero on the same edge.  That will keep it from re-processing the same word again; it will then be idle until outside drops a new word into the copy register.
2022-12-26 12:45:23 <KipIngram   > It being in state 0 will be the external signal that that's allowed.
2022-12-26 13:34:07 <KipIngram   > Interrupts.  I think there will be a jump table at the start of instruction RAM.  Cell 0 will be the general reset vector.  Cell 1 can be "instruction fault."  Maybe cell 2 is a timer interrupt.  Etc.
2022-12-26 13:34:25 <KipIngram   > Easy to do, since a cell can cause a jump without saving a return address.
2022-12-26 13:34:51 <KipIngram   > If I get an instruction fault, the handler can then let me inspect the return stack to trace out what happened and so on.
2022-12-26 13:35:25 <KipIngram   > Feels to me like there's one more layer of logic outside the one I've worked on this morning, that manages how IP gets modified as we execute things.
2022-12-26 13:36:38 <KipIngram   > Increment, take from return stack, take form loopback stack, or set to a low value.  Or take it from the data stack.
2022-12-26 13:37:22 <KipIngram   > (for execute).  That's five, though, so it may make sense to move a value from the data stack to the return stack in order to do execute.  Four sources is less logic.
2022-12-26 13:38:01 <KipIngram   > Clearing flip flops is a separate path, though, so setting to a low value may not need a path through the selector.
2022-12-26 13:38:49 <KipIngram   > But it's not just clearing it to zero - in those other cases (fault, timer, etc.) the lowest bits have to somehow get set to the right new value.
2022-12-26 13:42:08 <vms14       > haha how crappy is this code
2022-12-26 13:42:20 <vms14       > : tag  'tag.name set  tag.name  tag.name $ dup  [ '< . # . '> . . '</ . # . '> . ] #  word ;
2022-12-26 13:42:43 <vms14       > I need to provide string interpolation so I can get rid of all those .
2022-12-26 13:42:54 <vms14       > but it's defining an html taag
2022-12-26 13:43:25 <vms14       > 'p tag  defines a word named 'p that when used like: 'text p  prints <p>text</p>
2022-12-26 13:43:45 <vms14       > need also to allow stuff like attributes
2022-12-26 13:44:30 <vms14       > word takes a name and a list and defines a colon word
2022-12-26 13:44:57 <vms14       > # is interpolation of values inside a list 1 2 3 [ # # # ] # => [ 1 2 3 ]
2022-12-26 13:45:13 <vms14       > and $ puts '"' between an element from the stack xD
2022-12-26 13:46:17 <vms14       > for example the 'oh tag creates a colon word with the contents ['<,.,"oh",.,'>,.,.,'</,"oh",.,'>,.]]
2022-12-26 13:46:28 <vms14       > xD
2022-12-26 13:47:35 <vms14       > still html with forth in this way is not nice, even if I have a way to insert attributes
2022-12-26 13:48:02 <vms14       > " some text" p div
2022-12-26 13:49:48 <vms14       > it's better to "open" a tag, then do stuff there, and later close it
2022-12-26 13:52:34 <vms14       > [ '<  # .. '> .. swap .. '</ .. # .. '> .. ] #  word ;
2022-12-26 13:52:46 <vms14       > <div><p>some text</p></div>
2022-12-26 13:52:58 <vms14       > .. concatenates strings
2022-12-26 13:54:13 <vms14       > I want to generate some html to start documenting my lang
2022-12-26 13:54:55 <vms14       > althought the documentation should be in some sort of plain text and then have a way to generate html from it
2022-12-26 13:59:09 <vms14       > KipIngram: how would you generate a html tag generator in your forth
2022-12-26 13:59:44 <vms14       > a word that you give a name of an html tag and creates a tag with that name that will wrap the text it receives in <name>text</name>
2022-12-26 14:00:07 <vms14       > " name" tag   " text" name
2022-12-26 14:01:38 <vms14       > creates a word *
2022-12-26 14:02:39 <vms14       > I need to process attributes too
2022-12-26 14:07:45 <KipIngram   > Gosh, I'd have to think about it.  You could get kind of fancy using CREATE/DOES>
2022-12-26 14:08:05 <KipIngram   > And handling a whole string of attributes is kind of an involved process.
2022-12-26 14:08:20 <KipIngram   > So is this for GENERATING HTML, or CONSUMING HTML?
2022-12-26 14:08:20 <vms14       > create/does is the first thing I thought about how would be done in forth
2022-12-26 14:08:25 <vms14       > generating
2022-12-26 14:08:35 <KipIngram   > Ok.  Hmmm.
2022-12-26 14:08:36 <vms14       > what it does is to create words with the tag name
2022-12-26 14:08:39 <vms14       > 'p tag
2022-12-26 14:08:43 <KipIngram   > Show me an example output line.
2022-12-26 14:08:45 <vms14       > now you have a 'p' word
2022-12-26 14:08:57 <vms14       > you use it like " some text" p
2022-12-26 14:08:58 <KipIngram   > Short, but reasonably base-covering.
2022-12-26 14:09:12 <vms14       > it creates a string with <p>some text</p>
2022-12-26 14:09:25 <KipIngram   > Yeah, where do the attributes enter in?
2022-12-26 14:09:39 <vms14       > attributes complicates it a bit more
2022-12-26 14:09:43 <KipIngram   > Most Forths don't have good string handling.
2022-12-26 14:09:54 <vms14       > the 'p' tag would have to process the arguments
2022-12-26 14:09:55 <KipIngram   > It's something I want to improve on eventually.
2022-12-26 14:10:01 <vms14       > receiving a list or alike
2022-12-26 14:10:07 <KipIngram   > So the attribute values would be on the stack?
2022-12-26 14:10:13 <KipIngram   > when you call p?
2022-12-26 14:10:33 <vms14       > but the attributes need to be delimited as you don't know how many can be
2022-12-26 14:10:41 <KipIngram   > Yeah.
2022-12-26 14:10:50 <vms14       > I'd say to just use a string and not process attributes for now xD
2022-12-26 14:10:59 <KipIngram   > So you'd push some marker onto the stack before the attributes, and then process them until you found it.
2022-12-26 14:11:09 <KipIngram   > Or start with your stack empty, and process everything.
2022-12-26 14:11:28 <vms14       > but in my case would be like [ class button style color:red ] " some text" p
2022-12-26 14:11:59 <vms14       > which means I'd have two 'p' words
2022-12-26 14:12:16 <vms14       > one that expects a list and text and another that only expects the text
2022-12-26 14:12:22 <KipIngram   > I see.  So [ would put a marker on the stack.  class and style would parse their arguments out of the input and put something on the stack to reord those. ] would do... something, possibly nothing at all.
2022-12-26 14:12:35 <KipIngram   > And then p would have all it's stuff on the stack, with the end marked down below.
2022-12-26 14:12:38 <vms14       > in my case [ generates an array
2022-12-26 14:12:42 <vms14       > but I could use a hash
2022-12-26 14:12:58 <KipIngram   > Ah, I see.  So you're not really leaving all the attributes "on the stack" as individual items then.
2022-12-26 14:12:59 <vms14       > { style " color:red" class " button" } " some text" p
2022-12-26 14:13:06 <KipIngram   > Ok, so that means p takes a string and an array from the stack.
2022-12-26 14:13:09 <vms14       > it would make it easier for the p word to process them
2022-12-26 14:13:22 <KipIngram   > [ ... ] creates the array, I suppose it leaves a pointer to it on the stack.
2022-12-26 14:13:25 <vms14       > yeah, but you can do it however you want
2022-12-26 14:13:34 <vms14       > it pushes the array on the stack
2022-12-26 14:13:43 <KipIngram   > " ..." puts a string pointer on the stack.  Then p just takes those two pointers and does its thing.
2022-12-26 14:13:45 <vms14       > the stack is able to get any kind of data you can create
2022-12-26 14:14:36 <vms14       > KipIngram: leaving all on the stack without delimiters is hard cause you can't know the exact number
2022-12-26 14:14:45 <vms14       > and it's supposed to be chainable
2022-12-26 14:15:21 <vms14       > { class " div" } { class 'button } " some text" p div
2022-12-26 14:15:36 <vms14       > as p creates a string, div inserts it
2022-12-26 14:16:10 <vms14       > so it would end like: <div class="div"><p class="button">some text</p></div>
2022-12-26 14:16:11 <vms14       > xD
2022-12-26 14:16:22 <vms14       > but as you see it's not nice to do this in forth
2022-12-26 14:16:39 <vms14       > it's better to open a tag, put stuff there, then close it
2022-12-26 14:16:46 <vms14       > easier if you just print the stuff
2022-12-26 14:17:46 <vms14       > anyways KipIngram you're kind of busy as you have a lot of stuff to do much more important than this shit
2022-12-26 14:18:31 <vms14       > I'm just curious about how a real forth would do it, but you shouldn't be loosing time on this thing, so don't do it if you have better stuff to do
2022-12-26 14:19:29 <vms14       > in my case is a simple example of the metaprogramming features
2022-12-26 14:23:33 <KipIngram   > Oh, I'm not going to.  All that was just top of my head stuff.
2022-12-26 14:24:33 <KipIngram   > I don't want to sink ALL of my vacation time into this processor work, though; basically I've been getting into it for a few hours every day or two, and just am pulling bits of it together.  I'll call the section I talked about this morning "op_control."  Maybe tomorrow I'll do "ir_control" (instruction ram).
2022-12-26 14:24:44 <KipIngram   > And I think that's the outermost control layer.
2022-12-26 14:25:44 <KipIngram   > The previous stuff - "data stack / ALU" is just one of the innermost modules (the most complicated, though).  At some point I'll have to do "return stack," "other registers," etc.
2022-12-26 14:26:07 <KipIngram   > But I think those three layers - ir_control, op_control, and "innermost modules" will really be about it.
2022-12-26 14:26:56 <KipIngram   > ir_control will navigate us around instruction ram, op_control will gudie us through instruction words, and inner modules will do whatever they do in response to opcodes.
2022-12-26 14:27:04 <KipIngram   > By the way, I was thinking about timer stuff.
2022-12-26 14:27:13 <KipIngram   > Let's say, just for example, that this thing runs at 200 MHz.
2022-12-26 14:27:58 <KipIngram   > It's 32 bits, so I can count up to 4 billion.  I can have a timer/counter register that ticks down one per cycle (every 5 ns).  I can pick any value I want to measure out one second.
2022-12-26 14:28:13 <KipIngram   > That means I can measure off a second to within +/- 2.5 nanoseconds.
2022-12-26 14:28:32 <KipIngram   > Ok, so how many seconds does it take for a 2.5 nanosecond per second drift to accumulate to a one second error in time?
2022-12-26 14:28:46 <KipIngram   > That turns out to be 12.5 years.
2022-12-26 14:28:57 <KipIngram   > If I come in at 100 MHz, it'll be six years.
2022-12-26 14:29:00 <KipIngram   > Etc.
2022-12-26 14:29:16 <KipIngram   > So this thing will be able to keep perfectly accurate time to within a second ever some number of years.
2022-12-26 14:31:48 <vms14       > : tag 3 duplicate $ swap $ [ # swap # " <~a>~a</~a>" ~ ] # word ;
2022-12-26 14:31:53 <KipIngram   > Because of it's very fixed operation, it will be absolutely capable of doing excellent real-time control.  There won't be any of the common "timing uncertainties" about how fast instructions are processed that you get in modern processors with all their fancy optimizations.
2022-12-26 14:32:02 <vms14       > does the same as before, but with less code xd
2022-12-26 14:32:10 <KipIngram   > Every time you execute a sequence of instructions, it will take EXACTLY the same length of time.
2022-12-26 14:32:15 <vms14       > " ~a" ~ is string interpolation
2022-12-26 14:32:32 <KipIngram   > So this will be a real-time capable setup.
2022-12-26 14:32:38 <vms14       > 1 2 3 " ~a ~a ~a" ~  creates a string with "3 2 1"
2022-12-26 14:32:50 <vms14       > the ~a comes from lisp's format directive
2022-12-26 14:33:19 <vms14       > it also can use lists and if a word 'separator' exists will use that as a separator
2022-12-26 14:33:26 <vms14       > if not it joins without spaces
2022-12-26 14:33:45 <vms14       > [ 1 2 3 ] '~a ~    "123"
2022-12-26 14:33:46 <KipIngram   > Ugh, "separator" has nine characters.
2022-12-26 14:34:04 <thrig       > s7r
2022-12-26 14:34:05 <KipIngram   > 
ACTION shies away from long names.

2022-12-26 14:34:12 <vms14       > : separator ', ; [ 1 2 3 ] '~a ~   "1,2,3"
2022-12-26 14:34:53 <KipIngram   > Yeah, being able to send "output" somewhere other than directly to the console (into a string/buffer, e.g.) is a "good thing" (tm).
2022-12-26 14:35:17 <KipIngram   > Piping is getting into that neighborhood.
2022-12-26 14:36:06 <vms14       > oh '.' can be attached to a socket or a file
2022-12-26 14:36:21 <vms14       > some-socket attach
2022-12-26 14:36:29 <vms14       > now . will print to that socket
2022-12-26 14:36:30 <KipIngram   > I guess you use the OS services to do that, right?
2022-12-26 14:36:36 <vms14       > I use perl :D
2022-12-26 14:36:39 <KipIngram   > If you're running under an OS, it's the obvious way to do it.
2022-12-26 14:36:44 <KipIngram   > Ok, but perl uses the OS.
2022-12-26 14:36:54 <vms14       > I have a variable that '.' checks before printing
2022-12-26 14:37:09 <vms14       > if it's defined it will print into that, if not to stdout
2022-12-26 14:37:24 <KipIngram   > There are probably a lot of good thoughts to think about "gracefully" incorporating Forth under an OS, but it's just not usually where my thoughts go.
2022-12-26 14:37:30 <KipIngram   > It's good work to do, though.
2022-12-26 14:38:10 <KipIngram   > Just being able to slap some Forth between two  pipes in a pipeline - that's interesting.
2022-12-26 14:38:23 <vms14       > sub pr { if ($out) { print $out @_; } else { print @_; } }
2022-12-26 14:38:23 <vms14       > 
2022-12-26 14:38:34 <vms14       > '.' calls that pr sub
2022-12-26 14:38:55 <vms14       > in perl if the first argument of print is a file handle or a socket it will print there
2022-12-26 14:39:30 <vms14       > 'attach' just sets that $out variable
2022-12-26 14:39:49 <vms14       > in the js version I made attach work with dom elements
2022-12-26 14:40:04 <vms14       > so '.' would print into the textContent of that element
2022-12-26 14:41:47 <vms14       > perl is a weird language, but has a lot of convenient stuff
2022-12-26 14:43:46 <vms14       > still I'll have words to create a file from a string and to create a string from a file
2022-12-26 14:44:02 <vms14       > but I can attach '.' to print to that file in a loop or whatever
2022-12-26 14:44:36 <vms14       > and also a temporary binding like 'some.file [ " some text" . ] in.file
2022-12-26 14:44:58 <vms14       > after that code . will print to stdout again, or the last attached file/socket
2022-12-26 14:48:33 <vms14       > I have to handle non blocking sockets better
2022-12-26 14:48:56 <vms14       > like set a callback for when data is read
2022-12-26 14:49:24 <vms14       > but it's likely I'll have to use threads for that
2022-12-26 14:59:32 <KipIngram   > I do really like how "cleanly" this thing is dividing into these layers.  This middle one is very nicely isolated from the others.  It'll definitely be possible to code it up in Verilog and exercise it stand-alone.
2022-12-26 15:00:29 <KipIngram   > Basically, if it is "ready" you apply an instruction word to its input and assert a "go" signal.  It will become "not ready"  on the next cycle.  It's busy sliding out the opcodes in that word.  When it's done, it will become "ready" again.
2022-12-26 15:01:03 <KipIngram   > On the other end, it just outputs a six-bit opcode and asserts its own "go" output, telling the lower layers to handle that guy.
2022-12-26 15:01:28 <KipIngram   > It does some internal things in response to some opcodes (primarily rep, and when we get rep it won't output the downstream "go" signal).
2022-12-26 15:02:15 <KipIngram   > It will produce some yet to be defined precisely outputs which tell the layer above how to get the next instruction word.  Maybe it's from the next location, maybe it's from the return stack address, etc.
2022-12-26 15:03:02 <KipIngram   > If it decides to use the next "instruction word" as a literal, it will tell the layer above so so that it can increment IP again.
2022-12-26 15:03:23 <KipIngram   > So that implies some sort of "next" output.
2022-12-26 15:04:13 <KipIngram   > So outputs may be "next," "continue," "return," "loopback."
2022-12-26 15:05:21 <KipIngram   > Maybe "execute," although the more I think about it the more I think the Forth word EXECUTE will require that I move the xt over to the return stack before getting down to the hardware processing.  So it may just be ">r ;"
2022-12-26 15:05:35 <KipIngram   > : exec  >r ;
2022-12-26 15:13:35 <MrMobius    > vms14: you can use Python to generate html from a mark up text file. I do this a lot and it saves tons of time
2022-12-26 15:13:42 <KipIngram   > Note that "next" there is not an option for how to get the next instruction word - it's just a command telling ir_control to increment the IP.
2022-12-26 15:14:15 <KipIngram   > I.e., "Hey, I used that one - move along to the next one."
2022-12-26 15:15:08 <KipIngram   > Oh hey, it occurred to me this morning that the "hidden stack" I use to handle { and } instructions can *also* be run by the return stack pointer, just like the loopback stack can.
2022-12-26 15:15:44 <KipIngram   > So really I'll have a return stack with "three fields."  A field for how to return to the caller, a field for how to loop back in the callee, and a field for saving and restoring the data stack pointer.
2022-12-26 15:16:12 <KipIngram   > If I do it that way, I get better functionality - I don't have to "balance" actual executions of { and }.
2022-12-26 15:16:48 <KipIngram   > The just need to be paired at each code level, but a multi-level return or an exception "longjmp" thing will set all that back to the right state so that the next } executed uses the right value.
2022-12-26 15:17:05 <KipIngram   > So I can return from or longjmp out of open stack frames.
2022-12-26 15:17:23 <KipIngram   > If it were a separately managed stack I wouldn't be able to do those things from inside a { ... }.
2022-12-26 15:17:48 <KipIngram   > Only the exception (setjmp/longjmp) stack will need to be fully independent with its own managed pointer.
2022-12-26 15:18:43 <KipIngram   > That will be a little wasteful of space, though - a lot of words won't contain a { ... } pair, or a "me" word, but each level will still get its space for storing that information.
2022-12-26 15:19:03 <KipIngram   > Those slots will just go unused in those cases.
2022-12-26 15:35:31 <vms14       > KipIngram: haha I have perl instead :D
2022-12-26 15:35:53 <vms14       > but yeah a simple script to transform some kind of own markdown to html
2022-12-26 15:36:11 <vms14       > I'd like to do that with my lang anyways
2022-12-26 15:36:36 <vms14       > I need to get used to my language
2022-12-26 15:44:23 <vms14       > the sad part of making your own language is no one will understand your code
2022-12-26 15:44:25 <vms14       > :/
2022-12-26 15:44:30 <vms14       > sometimes not even you
2022-12-26 15:44:39 <vms14       > and no one would be able to help you xD
2022-12-26 15:45:07 <vms14       > I have to get users so they can help me with my code
2022-12-26 16:08:05 <vms14       > I don't know how to manage the stack xd
2022-12-26 16:08:15 <vms14       > I try to not bind values and I'm dying
2022-12-26 16:08:21 <KipIngram   > I've never really put a lot of emphasis on writing code "for others."
2022-12-26 16:08:31 <KipIngram   > I've never actually been part of a "programming team."
2022-12-26 16:08:46 <vms14       > KipIngram: I have the attributes processed
2022-12-26 16:08:52 <vms14       > actually is quite easy
2022-12-26 16:08:59 <KipIngram   > So my style is always fairly personal, my knowledge of the finer aspects of version control is limited, etc.
2022-12-26 16:09:02 <vms14       > but now idk how to reorder the elements on the stack xd
2022-12-26 16:09:17 <KipIngram   > I can "do some stuff" with git.  The basics.  But the fancy stuff I'm pretty clueless about.
2022-12-26 16:09:28 <vms14       > : process.attributes [ swap ` ~a="~a"` ~ ] map.hash blank join ;
2022-12-26 16:09:53 <KipIngram   > Ew... 17 character long name...
2022-12-26 16:10:26 <vms14       > it takes a hash like { style 'color:red } and returns a list of [ style="color:red" ] which joins with spaces
2022-12-26 16:10:33 <vms14       > haha you count the letters
2022-12-26 16:10:38 <KipIngram   > You know, when Fox said Chuck's average definition length was 44 characters, I don't know if he was including the name in that or not.
2022-12-26 16:10:50 <vms14       > I don't mind to have long names
2022-12-26 16:10:59 <KipIngram   > But when I say mine are "typically 40-50 characters," I am including the name and I am including the : and the ; as well.
2022-12-26 16:11:03 <vms14       > I like them if they're descriptive enough
2022-12-26 16:11:16 <KipIngram   > And I generally put two spaces between the name and the definition; it includes that too.
2022-12-26 16:12:09 <KipIngram   > Sure - I do understand.  People are different.
2022-12-26 16:12:46 <KipIngram   > A guy I used to chat with before I just couldn't handle his political rants anymore was interested enough in "APL like languages," but not APL itself, because of the terse symbolic names.
2022-12-26 16:12:55 <KipIngram   > He wanted the longer, more "English readable" names.
2022-12-26 16:13:09 <vms14       > hmm seems to work
2022-12-26 16:13:11 <vms14       > { meh 2 } { oh 1 } " some text" p div .
2022-12-26 16:13:21 <vms14       > <div meh="2"><p oh="1">some text</p></div>
2022-12-26 16:13:45 <KipIngram   > On the other hand, I felt like the holy grail of "knowing APL" (and being good at it) would be to develop as much intuition about all of those symbols as most of us have with + - * /
2022-12-26 16:13:52 <vms14       > but I'm not happy with that definition :/
2022-12-26 16:13:54 <KipIngram   > Be just as "fluid" with them.
2022-12-26 16:14:01 <vms14       > : tag 3 duplicate $ swap $ [ swap process.attributes # " <~a ~a>" ~ swap # swap "~a</~a>" ~ ..  ] # word ;
2022-12-26 16:14:09 <KipIngram   > Someone here told me that never happens, though.
2022-12-26 16:14:11 <KipIngram   > Not completely.
2022-12-26 16:14:29 <vms14       > I was getting crazy with the stack so I divided the strings in two xD
2022-12-26 16:14:41 <KipIngram   > But hey, we're not ever really supposed to find holy grails, are we?
2022-12-26 16:14:47 <KipIngram   > It's the quest that's important.
2022-12-26 16:15:13 <vms14       > I won't look at apl
2022-12-26 16:15:26 <vms14       > even if my lang seems to resemble it a bit xD
2022-12-26 16:16:08 <vms14       > and this shitty code is because I'm not binding values
2022-12-26 16:16:21 <vms14       > I decided to not have variables and use words as variables
2022-12-26 16:16:39 <vms14       > but I'm not sure if having vars just inside colon words
2022-12-26 16:16:42 <KipIngram   > I find it fairly fascinating, and I think there are things I can learn from it and snitch from it for my own work.
2022-12-26 16:16:47 <vms14       > that will get reset between execution
2022-12-26 16:16:56 <KipIngram   > It's rigorous mapping onto mathematics is really cool.
2022-12-26 16:17:10 <KipIngram   > ITs
2022-12-26 16:17:12 <KipIngram   > Its
2022-12-26 16:17:17 <vms14       > :D
2022-12-26 16:18:01 <KipIngram   > You know its original purpose was to be a notation for mathematical expression.  It was only later that the guy realized you could make it executable.
2022-12-26 16:18:18 <vms14       > kind of like lisp
2022-12-26 16:18:26 <KipIngram   > Yes - I was just about to say that.
2022-12-26 16:19:05 <KipIngram   > So I've put the pencil and paper down for the day and am now just kind of "idly musing" about ir_control.
2022-12-26 16:19:07 <vms14       > one of the students decided to make an interpreter even when the teacher told him to not do it
2022-12-26 16:19:13 <KipIngram   > Maybe I'll write it down tomorrow.
2022-12-26 16:19:37 <KipIngram   > I approve of rebellion, generally speaking.
2022-12-26 16:19:40 <vms14       > maybe the teacher was encouraging him by sayinh to not do it
2022-12-26 16:19:51 <vms14       > saying*
2022-12-26 16:19:52 <KipIngram   > Heh.  That would be a smart teacher.
2022-12-26 16:21:10 <vms14       > well I have the html tags now
2022-12-26 16:21:20 <vms14       > but still it won't be nice to write html with them
2022-12-26 16:21:23 <vms14       > { class 'meh } { style 'color:red } " some text" p div .
2022-12-26 16:21:33 <vms14       > <div class="meh"><p style="color:red">some text</p></div>
2022-12-26 16:21:56 <vms14       > I also want the tag generator make an additional word that only takes text, but not attributes
2022-12-26 16:22:08 <vms14       > as most of the time you won't set any attribute
2022-12-26 16:22:53 <KipIngram   > I'm not fully seeing what you gain over just writing the HTML i n the first place.
2022-12-26 16:23:08 <KipIngram   > Though maybe you'd be able to automate various aspects of producing large amounts of HTML.
2022-12-26 16:23:59 <KipIngram   > You ought to try writing a LaTeX creator.  Or maybe a LaTeX processor, that read it in and produced images of your pages.
2022-12-26 16:24:04 <vms14       > well this is because I made them in lisp and it was so beautiful
2022-12-26 16:24:08 <vms14       > but not like here :/
2022-12-26 16:25:14 <KipIngram   > I would really like to be better with LaTeX than I am, but I've always felt like the ideal situation would be to be able to write detailed LaTeX if you wanted to, but to also be able kind of "script" it in various ways on the fly - with the scripting and the detailed stuff freely intermingled.
2022-12-26 16:25:16 <vms14       > (html (head (viewport)) (body (div :class 'meh (p :style 'color:red "oh.."))))
2022-12-26 16:25:29 <vms14       > hmmm lates
2022-12-26 16:25:33 <vms14       > latex * xD
2022-12-26 16:25:38 <KipIngram   > that way for "most stuff" you could do something much easier - more like markup, but you could always drop to the detail level if you needed to.
2022-12-26 16:25:50 <KipIngram   > And you could extend the "markup" capability on the fly.
2022-12-26 16:26:49 <KipIngram   > If I were to try and do that, I'd begin by making my Forth capable of processing LaTeX itself, but it would also be able to compile new definitions as I extended the markup shortcuts.
2022-12-26 16:26:54 <vms14       > yeah seems worth to give it a try
2022-12-26 16:27:15 <vms14       > processing latex and write a dvi?
2022-12-26 16:27:30 <KipIngram   > I think of LaTeX as kind of the "ultimate" when it comes to controlling the appearance of your printed final result.
2022-12-26 16:27:38 <KipIngram   > Some of the stuff people do with it is astounding.
2022-12-26 16:27:50 <vms14       > like programs
2022-12-26 16:27:51 <vms14       > xD
2022-12-26 16:28:02 <vms14       > there are several computer programs written in latex
2022-12-26 16:28:24 <KipIngram   > I hadn't ever thought about it, but I suppose there's a way to consider it Turing complete?
2022-12-26 16:28:52 <KipIngram   > Maybe we'd call it LaFortH
2022-12-26 16:29:08 <KipIngram   > Or La4TH
2022-12-26 16:30:03 <KipIngram   > I think I'd have to mull that over a rather long time before having an idea about exactly what direction to go.
2022-12-26 16:30:26 <thrig       > geordi laforth
2022-12-26 16:30:33 <KipIngram   > But the ultimate goal would be to make the production of beautiful documents EASY.
2022-12-26 16:30:42 <KipIngram   > I don't regard using LaTeX as easy.
2022-12-26 16:30:47 <vms14       > I'd stare some time at latex stuff until I decide how I would want to implement it
2022-12-26 16:30:59 <vms14       > I need to learn even the basics xD
2022-12-26 16:30:59 <KipIngram   > For me it involves an enormous amount of trial and error, constantly throughout the process.
2022-12-26 16:31:04 <vms14       > I've just made a hello world pdf
2022-12-26 16:31:21 <KipIngram   > I've done not much more than that.
2022-12-26 16:31:42 <vms14       > I'd look at latex for some time first, to at least get an idea
2022-12-26 16:31:51 <KipIngram   > I toyed with writing some fiction once.  A novel.  I used LaTeX from the outset so that I got good looking pages to look at while working.
2022-12-26 16:32:14 <vms14       > actually postcript could be used to render pdf
2022-12-26 16:32:22 <thrig       > being able to build to ebook formats might also be sensible
2022-12-26 16:32:24 <vms14       > and it's a concatenative stack based rpn lang
2022-12-26 16:32:32 <KipIngram   > I had that set up with my screen split down the middle; on the left was vim with LaTeX and on the right was the PDF.  I had a hotkey in vim that would do all the steps, so I could edit in vim, hit the key, and see the result immediately on the right.
2022-12-26 16:33:01 <vms14       > that remembers me I have to even start with the text editor
2022-12-26 16:33:26 <KipIngram   > Make a line editor first, and then have the screen editor just do a stack of lines.
2022-12-26 16:33:32 <vms14       > but if I end having it, should be nice to define a colon word and assing a keybind to it
2022-12-26 16:33:33 <KipIngram   > That's how I did it, and it felt "simple."
2022-12-26 16:33:54 <KipIngram   > The source for the whole thing fit in one 4kB block.
2022-12-26 16:34:03 <KipIngram   > It was pretty full, but it fit.
2022-12-26 16:34:31 <KipIngram   > All of the commands were bound to control keys.
2022-12-26 16:34:43 <vms14       > actually assign keybinds to colon words must be a lot of fun
2022-12-26 16:34:50 <vms14       > even if it's not a text editor
2022-12-26 16:34:51 <KipIngram   > I could edit two arbitrary blocks side by side, and if I wanted to I could move stuff between them.
2022-12-26 16:34:59 <vms14       > it could be whatever you definee
2022-12-26 16:35:21 <vms14       > the nice thing would be a wm
2022-12-26 16:35:26 <vms14       > but meh
2022-12-26 16:35:31 <KipIngram   > Did not support word wrapping.
2022-12-26 16:35:41 <KipIngram   > Each line was 64 long max and independent of all the other lines.
2022-12-26 16:35:57 <KipIngram   > And it didn't use newlines - every line WAS 64 long.
2022-12-26 16:36:03 <KipIngram   > Like in  old fashioned Forth.
2022-12-26 16:36:41 <KipIngram   > But if you inserted characters on a line it affected only that line.  It pushed spaces off the end and they fell on the floor.
2022-12-26 16:36:51 <KipIngram   > It wouldn't let you push a non-space off, though.
2022-12-26 16:37:04 <KipIngram   > And it would push blank lines off the bottom, but woudln't let you push a non-blank line.
2022-12-26 16:38:48 <KipIngram   > I need to write a new one for this system.
2022-12-26 16:39:08 <KipIngram   > This time I've written EXPECT in a way that should simplify the editor code.
2022-12-26 16:39:18 <KipIngram   > And this time I do intend to support newlines.
2022-12-26 16:39:39 <KipIngram   > But I'll still have the 64 max length limit.
2022-12-26 16:40:29 <KipIngram   > I'm thinking that maybe I'll have it able to edit a continguous range of blocks, so I won't have the 64-line limit.
2022-12-26 16:40:56 <KipIngram   > And then the way will be paved for editing files in the future - it'll be the same job, except the blocks involved won't be sequential necessarily.
2022-12-26 16:42:01 <vms14       > hmm now 'p tag  creates a 'p' and a 'p*' word
2022-12-26 16:42:13 <vms14       > the 'p' takes only one element like at first
2022-12-26 16:42:19 <KipIngram   > Oh, and it will inherit utf8 support from EXPECT.
2022-12-26 16:42:21 <vms14       > the 'p*' takes a hash and text
2022-12-26 16:42:39 <vms14       > but meh, those swaps I'm not liking them
2022-12-26 16:42:59 <vms14       > https://termbin.com/w2cn
2022-12-26 16:43:01 <KipIngram   > Of course, since the SDL discussion the other day I'm thinking of re-doing that whole part of the system.
2022-12-26 16:43:34 <KipIngram   > Instead of having an EXPECT that gets its own keystrokes, the system event loop will get the keystroke events, and if it's appropriate to do so will pass them into code that will insert them into a string somewhere.
2022-12-26 16:43:50 <KipIngram   > That'll basically be a total re-write of that part of things.
2022-12-26 16:44:14 <KipIngram   > But it's more flexible - it will make it so what I do with a keystroke can depend on other things I've done.
2022-12-26 16:44:21 <vms14       > I want Xlib :/
2022-12-26 16:44:33 <vms14       > but I'm not willing to write the lang in C
2022-12-26 16:44:45 <KipIngram   > The other events will be able to adjust the "context" that the keystrokes are affecting.
2022-12-26 16:45:35 <vms14       > I have utf8 support for free
2022-12-26 16:45:48 <vms14       > but I never cared about utf8 as my terminal won't support it
2022-12-26 16:46:39 <vms14       > even perl source code could be written in utf8 xd
2022-12-26 16:47:02 <vms14       > and the lang would be able to use emojis as word names
2022-12-26 16:47:04 <vms14       > hahahaha
2022-12-26 16:47:07 <vms14       > better not
2022-12-26 16:48:37 <vms14       > Xlib has a feature I want
2022-12-26 16:48:43 <vms14       > well it's actually XShape
2022-12-26 16:48:59 <vms14       > it can make a window with any shape, non rectangular
2022-12-26 16:49:26 <vms14       > I made a charmander walking on the screen which was a window changing its shape for every frame
2022-12-26 16:49:30 <vms14       > it was super cool xD
2022-12-26 16:49:41 <vms14       > that's why I want XShape
2022-12-26 16:49:53 <vms14       > you can make any sprite be a window
2022-12-26 16:51:55 <MrMobius    > Are there jobs you can get knowing APL without the CS degree?
2022-12-26 16:52:21 <MrMobius    > adding it to the list with COBOL to things I may learn someday if I switch careers
2022-12-26 16:52:50 <KipIngram   > It's the graphics capabilities that actually make me interested in SDL.
2022-12-26 16:52:55 <KipIngram   > The rest is gravy.
2022-12-26 16:53:27 <vms14       > what graphics capabilities
2022-12-26 16:53:34 <vms14       > draw lines, rects, images?
2022-12-26 16:53:39 <KipIngram   > I just want to do it in a way, though, that doesn't absolutely wreck portability to bare metal systems.  I understand that the only actual functionality I get on are metal is what I write, but I'd at least like for the basic STRUCTURE of things to port over fairly cleanly.
2022-12-26 16:53:55 <KipIngram   > Even if at first the only "events" I get are keystrokes arriving in via a serial port.
2022-12-26 16:54:04 <KipIngram   > I suspect that can be worked out easily enough.
2022-12-26 16:54:51 <vms14       > well in unix sdl events really come from the X server
2022-12-26 16:55:14 <vms14       > same for most graphic primitives
2022-12-26 16:55:58 <KipIngram   > Yeah.
2022-12-26 17:13:19 <vms14       > I did not realize at first, but ended using # for interpolation in lists, like <# # #> forth does with numbers
2022-12-26 17:14:16 <vms14       > I have a symbol with a reference of every lang
2022-12-26 17:14:27 <vms14       > $ makes a string and references perl xD
2022-12-26 17:14:41 <vms14       > ~ references lisp format's directive ~a and ~%
2022-12-26 17:14:50 <vms14       > and # forth's <# # #>
2022-12-26 17:21:25 <vms14       > : ^._.^ 'meow . cr ; hahaha
2022-12-26 17:29:53 <vms14       > hmm having no packages makes sense to have some kind of forget feature
2022-12-26 17:30:09 <vms14       > like load a file, do stuff, forget what was defined
2022-12-26 17:31:06 <vms14       > that way the namespace does not get polluted with random words just cause you wanted to do X thing
2022-12-26 18:51:54 <veltas      > KipIngram: userspace just simulates bare metal, signals and blocking I/O are just like interrupts and busy waiting on registers
2022-12-26 18:52:09 <veltas      > virtual memory simulates having a whole address space to work with
2022-12-26 18:54:06 <veltas      > So in my opinion, don't worry about it, there's a simple analogue between most of what you can do in an OS and bare metal
2022-12-26 18:56:50 <KipIngram   > That's kind of what my instincts are saying to me - that it will workout ok.
2022-12-26 18:57:41 <KipIngram   > I've always just put KEY inside EXPECT because "that's how it was done."  I'm not really "bothered" by turning around the other way so the outside layer collects the events.
2022-12-26 18:57:55 <KipIngram   > I don't see it as "compromising the Forth architecture" or anything.
2022-12-26 18:58:02 <KipIngram   > It's just different, that's all.
2022-12-26 18:58:20 <KipIngram   > And honestly, give all the ways we interact with computers these days, it's better.
2022-12-26 18:58:25 <KipIngram   > given
2022-12-26 18:58:53 <KipIngram   > It makes no advance presumption about how events should be responded to.
2022-12-26 19:02:04 <KipIngram   > You call EXPECT in traditional Forth, and you're situated to do only one thing - respond to keystrokes - until such time as you get to Enter.  Really the minute the user  hits Enter on that line, the system is committed to a particular course of action: the execution of that sequence of words.  No flexibility exists.
2022-12-26 19:02:45 <KipIngram   > With the events entering from the outside perimeter of the system, you're situated to respond to each one given the immediate circumstances.  You can make more flexible decisions.
2022-12-26 19:55:11 <KipIngram   > So, I'm reading about event loops.  The basic idea seems simple enough, but it looks like in actual implementations there's an additional "layer" I wasn't necessarily expecting.
2022-12-26 19:55:54 <KipIngram   > Looks to me like when you write an event loop, it's not really running all time - it sleeps so long as there are no events.  Then it gets woken up to quickly respond to that event, and the loop runs until all pending events are cleared.  Then it goes back to sleep.
2022-12-26 19:56:21 <KipIngram   > So the "other layer" is the part that handles the waking up and so on.  I suppose that's customarily part of the OS.
2022-12-26 19:57:00 <Zarutian_iPad> part of the OS or the interrupt machinery of the MCU
2022-12-26 19:57:02 <KipIngram   > So the real ultimate outer layer is kind of the OS scheduler, and I guess it really uses interrupts to actually detect the events?
2022-12-26 19:57:11 <KipIngram   > ^ Right.
2022-12-26 19:57:18 <Zarutian_iPad> depends
2022-12-26 19:57:52 <Zarutian_iPad> so, the event sources could be interrupt driven or poll driven
2022-12-26 19:58:54 <KipIngram   > So on this processor, when talking to it over a serial cable from my computer, I'd equip the UART with the ability to interrupt.  And in between events, I spend my time in the lowest power mode I've got that still lets me detect UART events and that I can wake up from quickly enough.
2022-12-26 19:59:09 <Zarutian_iPad> in interrupt driven the main program is often either executing an event of the event queue or sleepong in a haltUntilInterrupt instruction
2022-12-26 19:59:28 <KipIngram   > So the UART isr will queue up the character and wake up the process that's waiting for events that include that one.
2022-12-26 20:00:09 <KipIngram   > I'm not sure exactly how this translates into a bare metal system where I don't have an OS, but is that remotely on the right track?
2022-12-26 20:00:30 <Zarutian_iPad> could be, simplest I have seen and heard of is the UART isr just put a char event on the event queue
2022-12-26 20:00:54 <KipIngram   > Ok, but something has to be either already running or woken up to respond to that, right?
2022-12-26 20:01:51 <KipIngram   > It brings up a good question, though, since I ultimately plan to try to use this on a battery powered application.  How do I "stop" and quit burning power while waiting for something to happen?
2022-12-26 20:02:04 <KipIngram   > A polling loop would still be running full-time.
2022-12-26 20:02:15 <Zarutian_iPad> in the poll driven case, you have an poll subroutine that executes at the end of an event loop turn. It looks for things that could generate events and puts those on the event queue
2022-12-26 20:02:34 <KipIngram   > Yeah, that makes sense.
2022-12-26 20:02:44 <Zarutian_iPad> if the event queue has nothing on it then the poll runs again
2022-12-26 20:03:16 <Zarutian_iPad> you can of course mix the two ways
2022-12-26 20:03:17 <KipIngram   > And that sounds more power hungry - I need a way to "stop" - a low power state I can enter that's still event sensitive.
2022-12-26 20:04:02 <Zarutian_iPad> just replace the haltUntilInterrupInstruction with above polling
2022-12-26 20:04:36 <KipIngram   > So the UART needs to be always able to respond to incoming signals.  But the processor itself might be "paused" with nothing changing at all until the UART (or something else) wakes it back up.
2022-12-26 20:05:03 <Zarutian_iPad> indeed, this is why nearly if not all MCUs nowdays use interrupts, and vectored interrupts at that
2022-12-26 20:05:17 <KipIngram   > I hadn't given this any thought at all - in the thinking I've been doing so far it was all doing SOMETHING all the time, even if it was just spinning.
2022-12-26 20:05:42 <KipIngram   > Yeah.  I did give a little thought to interrupts earlier today, looks like it should be fairly straightforward.
2022-12-26 20:07:42 <Zarutian_iPad> in an OS, what happens durring epoll/select from the point of view of the process is that it pauses there until an event is ready. This gives the OS an oppertunity to run a diffrent proccess
2022-12-26 20:08:43 <Zarutian_iPad> event loops and object based systems btw go often hand in hand
2022-12-26 20:09:38 <Zarutian_iPad> but you could do the event queue by having a list of pairs of xt and payload cell
2022-12-26 20:10:20 <Zarutian_iPad> payload cell put on the datastack and the xt executed
2022-12-26 20:10:56 <KipIngram   > Sure - once there are many processes being scheduled it all makes great sense.
2022-12-26 20:11:19 <KipIngram   > I guess what I'm talking about though is avoiding a wait loop when there is actually nothing to do.
2022-12-26 20:12:03 <Zarutian_iPad> pretty much the haltUntilInterrupt instruction I mentioned earlier
2022-12-26 20:12:25 <Zarutian_iPad> or its equiv
2022-12-26 20:12:35 <KipIngram   > Right.  It should be straightforward to have an enable signal for everything.
2022-12-26 20:12:49 <veltas      > None of these considerations requires a total rewrite, it's all stuff that can be tweaked along the app/driver interface
2022-12-26 20:12:56 <veltas      > In baremetal or hosted
2022-12-26 20:13:00 <KipIngram   > When it's disabled, just don't change any signals, don't advance any states, etc.
2022-12-26 20:13:27 <KipIngram   > Maybe slow down the clock.
2022-12-26 20:13:55 <Zarutian_iPad> if you look into how Green Arrays 144 does blocking commports then you see that a blocking read or write actually halts that computer-unit
2022-12-26 20:14:05 <veltas      > The only thing I can think of that's fundamentally different is that disabling interrupts is a valid (and efficient) mutex strategy for baremetal
2022-12-26 20:14:25 <KipIngram   > Yeah, and in that case they're asynch, so that really does mean NO activity; not even a ticking clock.
2022-12-26 20:14:56 <Zarutian_iPad> not recommended if you want to have the option of snappy response time for isrs
2022-12-26 20:15:03 <veltas      > And there is no parallel for OS, but you have mutex libraries so just use them instead, and be careful to avoid deadlock
2022-12-26 20:15:16 <KipIngram   > Yeah, I know  nothing about the timing that would be involved with that on my particular chip.
2022-12-26 20:15:35 <KipIngram   > And that would mess with the accuracy of any timers.
2022-12-26 20:15:47 <KipIngram   > "mess with" == "destroy"
2022-12-26 20:15:55 <veltas      > Zarutian_iPad: If it actually needs to be mutually exclusive, then it's more efficient than the alternatives to disable interrupts temporarily
2022-12-26 20:16:17 <KipIngram   > Oh, sorry - I thought you were responding to me.
2022-12-26 20:16:41 <Zarutian_iPad> veltas: sure, but you want that section to be short like ISRs should be short.
2022-12-26 20:16:47 <veltas      > Yeah
2022-12-26 20:17:42 <Zarutian_iPad> often just to implement an CompareAndSwap factility or such that you can build slower mutexes ontop of
2022-12-26 20:17:57 <veltas      > It goes without saying mutex's need to be short for best performance and lowest latency
2022-12-26 20:18:36 <KipIngram   > Oh, there's a reason right there for having something like that x<>[] word I mentioned the other day.  As an instruction that would be atomic.
2022-12-26 20:18:42 <veltas      > Disabling interrupts is better than software mutexes (and fundamentally different)
2022-12-26 20:19:28 <veltas      > It avoids possibility of deadlocks where it can be used
2022-12-26 20:19:44 <KipIngram   > Hmmm.  The "easy" thing to do in my setup is to respond to interrupts after processing each instruction CELL.  That way when I return from an ISR it's to a cell boundary.
2022-12-26 20:19:58 <KipIngram   > But that combined with my rep mechanism creates a potential weakness, doesn't it?
2022-12-26 20:20:08 <veltas      > What weakness?
2022-12-26 20:20:15 <KipIngram   > I might potentially have a rep  loop, which run sin one cell, with a large countdown.
2022-12-26 20:20:26 <KipIngram   > Arbitrary length of time before interrupts are checked.
2022-12-26 20:20:29 <veltas      > Each step must be a unit then
2022-12-26 20:20:59 <KipIngram   > The alternative is to respond to interrupts after every opcode, but that will require returning to the middle of an instruction cell.
2022-12-26 20:21:07 <KipIngram   > The interrupt will have to save more than just the IP.
2022-12-26 20:21:12 <veltas      > The loop needs to be broken up into one step that conditionally jumps back to itself
2022-12-26 20:21:16 <KipIngram   > It has to save the state of op_control too.
2022-12-26 20:21:29 <KipIngram   > But that's ok - if I plan it from the start it shouldn't be too bad.
2022-12-26 20:25:14 <KipIngram   > If I'm going to do that then there might be other ways I want to apply it too.
2022-12-26 20:25:27 <KipIngram   > For example, earlier I talked about doing EXECUTE like
2022-12-26 20:25:32 <KipIngram   > : EXECUTE >r ;
2022-12-26 20:25:40 <KipIngram   > which I think someone else here mentioned the other day.
2022-12-26 20:26:15 <KipIngram   > But that would require a call in the code streamm, which means nop-ing out the rest of the cell you're in so you can put it in the next cell.
2022-12-26 20:26:50 <KipIngram   > But if I can save op_control state then I could have an exec opcode that would do it RIGHT NOW, just like any other opcode.  When the called word returned, we'd go back to the next opcode slot just like we should.
2022-12-26 20:27:04 <KipIngram   > So it's a more... "smooth" way of doing things.
2022-12-26 20:27:34 <KipIngram   > And I think I need to do it, because now I've decided that servicing interrupts on cell boundaries only just isn't acceptable.
2022-12-26 20:27:47 <KipIngram   > Because of large count rep loops.
2022-12-26 20:28:30 <KipIngram   > But it should be fairly painless to just add those state bits alongside IP on the return stack.
2022-12-26 20:28:58 <KipIngram   > It's just three bits.
2022-12-26 20:29:36 <KipIngram   > Oh, not really - it's three bits for state and it's the partially shifted instruction word.
2022-12-26 20:30:04 <KipIngram   > Ugh - AND it's the unshifted copy of the instruction word that rep uses to reload IW.
2022-12-26 20:30:22 <KipIngram   > So that's a good bit of new information.  Doesn't make it any "harder," but it does make it more expensive.
2022-12-26 20:30:37 <KipIngram   > Glad we had this talk - I need to think about this right now before moving on.
2022-12-26 20:31:10 <Zarutian_iPad> KipIngram: look into how IBM 370 handles long running but interruptable instructions
2022-12-26 20:31:21 <KipIngram   > Ok.
2022-12-26 20:32:26 <KipIngram   > Oh, another option is to check for interrupts on each rep execution - then when we return we know we're returnning to state 1.  No variability.
2022-12-26 20:32:39 <KipIngram   > And that is a quite small amount of time.
2022-12-26 20:32:59 <Zarutian_iPad> all of those kind of instructions like your rep can be interrupted and their count down and moving pointers are saved back. The PC points at the interrupted instruction
2022-12-26 20:33:08 <KipIngram   > Right.
2022-12-26 20:33:24 <KipIngram   > Well, my PC (IP) doesn't point at an *opcode*.
2022-12-26 20:33:31 <KipIngram   > It points at a cell of packed opcodes.
2022-12-26 20:33:44 <KipIngram   > My op_control module has the finer grained information in its state.
2022-12-26 20:33:48 <Zarutian_iPad> so when resuming that instruction gets started again like it had be invoked with lower count and pointers further along
2022-12-26 20:33:55 <KipIngram   > But yeah - some of that will need to be saved and restored.
2022-12-26 20:34:25 <Zarutian_iPad> so, is the rep the first opcode in the cell?
2022-12-26 20:34:27 <KipIngram   > If I guarantee that we restart on slot 1, then I won't have to save both shifted and unshifted versions of IW - just the unshifted one will be adequate.
2022-12-26 20:34:57 <KipIngram   > And I won't need to save the state at all; I'll always be returning to one specific state.
2022-12-26 20:35:39 <Zarutian_iPad> so, you only need to check for interrupts per repetiotion of the cell, no?
2022-12-26 20:35:54 <KipIngram   > Yes, that's what I was talking about here at the last.
2022-12-26 20:36:18 <KipIngram   > That's every five opcodes at most; perhaps less.
2022-12-26 20:36:49 <KipIngram   > I did just think of an issue, though.
2022-12-26 20:37:01 <Zarutian_iPad> so a repeated instruction cell via rep   is functionally equiv to it being repeated in memory only it isnt repeated in memory just that it was fetched once
2022-12-26 20:37:24 <KipIngram   > My data and return stacks are not in general RAM.  They are separate block RAMs.  So the whole idea of "inspecting" the return stack is not an easy thing to see how to do.
2022-12-26 20:37:40 <KipIngram   > If I want to be able to do that, I'll need to plan for that too.
2022-12-26 20:38:00 <KipIngram   > Properly written code may be able to run without using the second of the dual ports.
2022-12-26 20:38:10 <KipIngram   > So I might be able to "borrow it" for stack inspection.
2022-12-26 20:38:23 <Zarutian_iPad> but to the control unit it just looks the same as the same instruction cell had been fetched x times
2022-12-26 20:39:06 <KipIngram   > It's actually not refetched - I cache the instruction word and restore it each time around from the cache.
2022-12-26 20:39:40 <KipIngram   > Anyway, I need to design a method for randomly accessing the stack RAMs.
2022-12-26 20:39:44 <Zarutian_iPad> yeah but from the control units perspective the results is the same
2022-12-26 20:39:53 <KipIngram   > Yes, it is.
2022-12-26 20:40:35 <Zarutian_iPad> stack rams in seperate block rams? those rams dual ported?
2022-12-26 20:41:07 <KipIngram   > Yes, they are, but to get one operation per cycle I need to use both of them.  At least for the data stack; haven't thought through the return stack yet.
2022-12-26 20:41:56 <KipIngram   > I'm speculating now on a special instruction to do an addressed read from that ram.  The hardware would gate the desired address onto port 2 address and return the result.
2022-12-26 20:42:06 <KipIngram   > It's really just another place to get the address from.
2022-12-26 20:42:10 <KipIngram   > I think it'll be fine.
2022-12-26 20:42:49 <KipIngram   > So I could do something like
2022-12-26 20:42:59 <KipIngram   > rp@ n + rsr
2022-12-26 20:43:06 <KipIngram   > rsr = return stack read.
2022-12-26 20:43:45 <KipIngram   > I'll make it work in the hardware.
2022-12-26 20:44:31 <KipIngram   > I just hadn't thought about it yet because it's something you need for debugging, not actually getting app work done.
2022-12-26 20:46:52 <KipIngram   > That actually solves the issue of seeing other information saved too.  These stacks are of limited depth, so I don't need a full 32 bits to address them.  I could use high address bits to select which special purpose RAM I want to read from, and could get them all that way, with one instruction.
2022-12-26 20:47:29 <KipIngram   > I'm glad this came up now instead of after I had the thing nearly done and I faced shoehorning it in.
2022-12-26 20:47:40 <KipIngram   > Right now I can think it through and do it nice and graceful.
2022-12-26 20:48:43 <KipIngram   > Anyone familiar with clock control on FPGAs?  Is it likely to give me an on the fly way to select a variety of clock rates?
2022-12-26 20:50:23 <KipIngram   > It would be nice if when there is no work to do I could slow down to the slowest rate compatible with the most speed-critical event I'm waiting for.
2022-12-26 20:51:46 <KipIngram   > These special reads will probably wind up putting the read result on the return stack, so I'd  need an r> after to get it on the data stack.
2022-12-26 20:52:05 <KipIngram   > I'm fairly well out of data sources on the data stack.
2022-12-26 20:53:00 <KipIngram   > Actually that code above is wrong because rp@ and sp@ are already planned to stow the result on the return stack.
2022-12-26 20:53:18 <KipIngram   > So it would be rp@ r> n + rsr r>
2022-12-26 20:53:46 <KipIngram   > Probably should call that rs@
2022-12-26 20:54:28 <KipIngram   > or maybe br@ for block ram fetch, if the high addy bits choose the block ram.
2022-12-26 20:56:43 <KipIngram   > You know, just to get at the return stack none of this would really be necessary.  A long sequence of opcodes can move the return stack pointer around as it wants to, so long as it's back when I'm done.
2022-12-26 20:56:48 <KipIngram   > Oh, no - not true.
2022-12-26 20:57:30 <KipIngram   > I can't take anything off unless I put it back safely; else while the pointer was pointing into the middle of it all and interrupt might munge the stack.
2022-12-26 20:57:44 <KipIngram   > But I probably could pop it all off and then put it all back.
2022-12-26 20:58:05 <KipIngram   > Pop it all into a data RAM table, then push it all back on.
2022-12-26 20:58:12 <KipIngram   > That should work fine.
2022-12-26 20:58:45 <KipIngram   > I could do the same thing with the data stack.  Kind of ugly, but it should work.
2022-12-26 20:59:14 <KipIngram   > Well, only if I put it ALL back.  I am planning to keep other things "paralleled" with the return stack itself.
2022-12-26 20:59:26 <KipIngram   > I have to be able to push all of it back properly.
2022-12-26 20:59:53 <KipIngram   > Well, that's two ways of handling it; I just need to ponder them.
2022-12-26 21:01:13 <KipIngram   > I'll say it again - I'm SUPER glad to think of this now instead of later.  Thank you guys for your patience listening to me ramble.  :-|
2022-12-26 21:04:24 <KipIngram   > I think br@ is the way to take care of it.  It covers all the things I'll want to inspect and it doesn't play any funky games with stack pointers.
2022-12-26 21:40:37 <vms14       > KipIngram: I'm hooking the lang into apache xD
2022-12-26 21:41:01 <vms14       > it's a bit sad for not, but meh
2022-12-26 21:41:04 <vms14       > 'oh [ 'meh . ] handler
2022-12-26 21:41:11 <vms14       > this registers a handler for the /oh url
2022-12-26 21:41:31 <vms14       > default.handler will be called when a handler isn't found for the url or the url is /
2022-12-26 21:41:44 <vms14       > sad for now*
2022-12-26 21:42:08 <vms14       > it's actually using modperl to hook into apache
2022-12-26 21:42:25 <vms14       > modperl lets you create the same apache C modules you would create, but with perl
2022-12-26 21:43:13 <vms14       > which means you can hook code to any phase of apache, including initialization, reset, child fork, url rewriting, mime chcking, the several phases of a request, etc
2022-12-26 21:43:41 <vms14       > for now I'm only adding the response handlers, which are the ones who actually write the document/text
2022-12-26 21:44:13 <vms14       > I have to add words to check post params and alike
2022-12-26 21:44:35 <vms14       > for now I just want to make a simple crud application
2022-12-26 21:44:38 <KipIngram   > 
ACTION knows more or less nothing about Apache operation.

2022-12-26 21:44:50 <vms14       > then I'll rethink about this shit
2022-12-26 21:45:17 <vms14       > haha KipIngram well, mainly the apache server is "hookable" and you can extend its functionality and alter its behavior with C modules
2022-12-26 21:45:42 <vms14       > modperl is a C module that can hook all the phases, so you can write perl modules like they were the C ones
2022-12-26 21:46:10 <vms14       > so I use modperl to add my lang into apache and then I can alter how apache works with it
2022-12-26 21:46:24 <vms14       > for now I'll just make simple response handlers
2022-12-26 21:46:35 <vms14       > but you can make authentication handlers, url rewriting, etc
2022-12-26 21:47:05 <vms14       > for example you can also add filters, say you have a php file, you can modify the input that php receives, and also modify the output php returns
2022-12-26 21:55:32 <KipIngram   > So, I had a 16:1 selector in the TOS input path, but expected just a 4-1 selector for the TOR selection.  That would have made the TOR path a little faster, but I couldn't really capitalize on that because the clock period had to accomodate the TOS path anyway, even on cycles where that path isn't used.
2022-12-26 21:56:16 <KipIngram   > These latest wrinkles, though will nudge me up to a 16:1 path for TOR as well.  I won't be using all 16 slots there, but once it's over 4 that next layer of logic is required.
2022-12-26 21:56:58 <KipIngram   > I can identify 11 sources supplying that path currently - most of them useful primarily for debugging.
2022-12-26 21:57:19 <KipIngram   > I lament the extra logic a little, but at least it's not costing me any speed.
2022-12-26 22:12:48 <KipIngram   > I think the data stack is the only one where I'm using both RAM ports, actually.  The other stacks can do their job with just one port.
2022-12-26 22:13:05 <KipIngram   > So I can permanently wire the TOS value into port 2 address for all of the others.
2022-12-26 22:15:56 <KipIngram   > Actually may just be able to map all those others in to the general address space via port 2.
2022-12-26 22:21:42 <KipIngram   > Ah, I need to think about overall address space.  Maybe I can find a clever way to map all of these block RAMs to somewhere up in high address space.
2022-12-26 22:50:15 <KipIngram   > Oh, hmmm.  There's more block RAM in this Xilinx FPGA than I thought.
2022-12-26 22:50:32 <KipIngram   > Looks like there's almost 484,000 bytes.
2022-12-26 23:07:58 <KipIngram   > Oh joy - the block rams in the Xilinx part, when set up as 32 bits wide, already have four byte enables.  So I won't have to implement that by splitting block RAMs into byte wide things.
2022-12-26 23:09:08 <thrig       > isn't it the LA Rams and not the block rams?
2022-12-26 23:53:37 <KipIngram   > :-)
2022-12-26 23:53:49 <KipIngram   > Well, finally found some detailed documentation on the block RAMs.
2022-12-26 23:53:55 <KipIngram   > There's a small rub, but it's "recoverable."
2022-12-26 23:54:16 <KipIngram   > Read operations on the RAMs are synchronous.  You have to CLOCK IN the address.
2022-12-26 23:54:37 <KipIngram   > And then later the data will show up (though you can add a register at the output too, if you like).
2022-12-26 23:55:04 <KipIngram   > I hadn't counted on that - I'd assumed that on each clock edge my logic could produce the address I needed and then later (in the same cycle) the data would show up.
2022-12-26 23:55:06 <KipIngram   > Not so.
2022-12-26 23:55:24 <KipIngram   > Writes will be fine - I have data and address ready together for those.
2022-12-26 23:55:29 <KipIngram   > That all gets clocked in too.
2022-12-26 23:55:37 <KipIngram   > Anyway, it can be dealt with.
2022-12-26 23:56:18 <KipIngram   > For a RAM like the instruction ram or the data ram, I will still have my address registers, because my logic needs those values.
2022-12-26 23:56:40 <KipIngram   > But I can clock the INPUTS of those registers into the RAM at the same time I load the registers.  Problem solved.
2022-12-26 23:56:48 <KipIngram   > But... for the stacks it's more delicate.
2022-12-26 23:57:00 <KipIngram   > The block RAMs  offer an optional clock inversion.
2022-12-26 23:57:45 <KipIngram   > I think my approach will need to be to clock my logic with rising edges, let the addresses get ready, and then use the falling edge of the clock to clock that into the RAM.  Then the data will be ready for me to load into my logic by the next rising edge, which is what I need.
2022-12-26 23:57:53 <KipIngram   > It will probably impose a slower clock speed on me.
2022-12-26 23:58:31 <KipIngram   > I think the synchronous operation of these things is designed to offer maximum speed in applications like signal processing where you know cycles ahead of time what addresses you're going to need to read from, and you can get all set up for it.
2022-12-26 23:58:53 <KipIngram   > But I don't KNOW what addresses I'm going to need until I see my opcode, and I don't see it until shortly after my rising edge at the start of the cycle.