00:00:00 --- log: started forth/19.03.24 00:18:36 --- quit: PoppaVic (Ping timeout: 268 seconds) 01:03:03 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth 02:01:04 --- join: dys (~dys@tmo-084-125.customers.d1-online.com) joined #forth 02:02:38 --- quit: ashirase (Ping timeout: 255 seconds) 02:07:30 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:34:28 --- quit: DKordic (Quit: ERC Version 5.3 (IRC client for Emacs)) 03:22:40 Question for you, though. Did you already know that in 2016? Or has it been his actions as Prez that has tained Trump for you? 03:25:18 I didn't really think we had a very good choice in 2016. I voted for Trump, as an "anti-Hillary" vote. I didn't think he had any chance of winning. When he did win, I allowed myself to feel some hope. I thought perhaps he would be surprised and "overwhelmed" with the idea that the nation had put so much trust in him, and could come to Washington intent on doing things really right. Well, hasn't turned out 03:25:20 that way. But I had no idea what kind of President he'd be beforehand. 03:26:09 after the muller report are you guys starting to wake up? 03:28:54 Oh, I woke up a while ago. 03:32:46 I just wish I knew how our "process" here in the States got so broken that the candidates we were given to choose between in 2016 were Trump and Hillary? 03:33:01 There was no good choice. 03:33:09 yea i mean for sure half the people in that list of 2 should never have been allowed to run :) 03:44:37 i try to avoid politics in tech forums, but it was clear that you guys were given a very poor choice - trump would never got my vote though 03:46:07 #YANGGANG2020 03:46:14 i don't think politics really should come down to a popularity contest between 2 people though - it should be about policy, not personality 03:46:22 Andrew Yang for 2020 or bust 03:48:02 the rest of the world will watch with interest to see what happens next :) - i for one would not be surprised if trump swings it, but i hope not - i don't think the position is good for him, the US or the world in general 03:48:20 Already have money on Yang at 33/1 03:48:46 I will cover any money I bet on Yang with equivalent bets on Trump 03:49:13 since if Yang isn't the democratic candidate, Trump has won 03:49:35 That's not what Ben Shapiro thinks. He thinks Trump beats any of them except Biden. 03:49:53 Apparently there are already polls that indicate Biden could take Trump handily. 03:50:27 Ben "If we give every us citizen $1k a month, how will we send $104 a second to Israel" Shapiro 03:50:48 Yeah, no comment on his ideas, but he's a smart guy clearly. 03:51:23 I'd sure hate like the dickens to have to debate him - he'd crucify me. He's so FAST. 03:52:24 that's the problem with the debate format though 03:52:38 I actually think some kind of universal basic income is where we wind up in the end, because of tech progress. We keep automating away more and more jobs. It undermines the economies ability to *distribute* the money. 03:52:50 it's just about quips, platitudes and well-remembered statistics 03:53:05 Eventually that's going to reach a critical point and we're not going to be able to just look the other way and whistle any more. 03:53:25 You should listen to Andrew Yang on Joe Rogan. 03:53:37 Goes into some reasonable depth on this. 03:53:56 Oh, has he been on Joe? I'll check it out. I read an article that covered how he planned to fund it, and it sounded at least reasonable. 03:54:04 3.5m truckers who jobs will very reasonably be automated in the next decade if not sooner 03:54:29 Yes. No one seems to be paying any attention to that part of it. 03:54:52 even if minimum wage were reduced to zero, robots are more economic in the long run 03:55:32 Yang is a former tech CEO and programs robots for fun. I bet he could be a forther in another timeline 03:55:35 And with AI coming into play automation is coming for the white collar jobs too. 03:56:46 McDonalds where I am (England) has these big ipads you can order your meals from, don't know how ubiquitous that is in the US but very few people I know talk to a cashier at all 03:57:24 they'll usually have the tills empty because the staff have been restructured to work in the kitchen or redundant 03:57:33 Yeah, the one by my office has four of those setup as a pair of kiosks. 03:57:53 And the banks more and more have almost no tellers. 03:58:25 My bank almost demands you use the robots if you're doing a transaction worth less than 1k 03:58:42 You can still order from a human in mine, and I do - I hate to see those little human interactions vanish from our culture. 03:59:32 Yeah - I love talking to humans 04:00:14 I hated seeing self-checkuout show up in grocery stores for the same reason. 04:00:33 a couple words a day keeps the existential lonliness away 04:01:16 Yes, and it also promotes at least some interaction amongst the more and less affluent people in society. 04:03:22 A grocery store chain here in the Houston area is planning to start doing grocery delivery by self-driving vehicle. I heard about that and thought great - they're going to send self-driving vans right into residential neighborhoods where children play in and around the streets. 04:03:30 That's a nighmare waiting to happen. 04:10:14 fly your groceries in by drone :-) 04:14:11 nah, entirely unrealistic. 04:14:19 I'd worry less about that. But groceries are heavy. 04:14:23 you'll drone yourself to the grocery store and back 04:52:17 Ah, just noted that my path: ;path stuff isn't managing CURRENT. 04:52:23 Looks simple enough to fix, though. 05:08:40 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth 05:17:11 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 05:19:55 Yeah. I just had PATH: fetch current and push it as an extra item to the parent's context. Then ;PATH restores that context, and knowing that there's one extra item there it runs DEFS to re-establish that top one as current and then drops it. 05:20:49 and when I ask for my parent context to be copied to my new context, I get that extra item too, so once again I run DEFS and drop it. 05:31:35 Also, I had the word FORTH chopping the stack back down to just the one vocabulary, which was Forth by default. 05:31:55 Sounds complicated, what's it all for? 05:32:10 I changed that - I made FORTH just push the Forth voc to the context, and added the word ONLY - it takes the top item, makes it the only item, and makes it CURRENT as well. 05:32:22 Vocabulary management. 05:32:41 And in terms of the amount of code it's a heck of a lot simpler than any of my past iterations on it. 05:33:03 Do you have any kind of namespace management in yours? 05:33:17 May not be something your interests cause you to need. 05:33:46 I have some non-standard words for the context stack 05:34:11 I've had 2 or 3 different things wind up being a lot cleaner on this implementation - I must have made some good decisions somewhere early on. 05:34:24 I have no idea how my words match up with the standard. 05:35:12 My vocabulary word is just a synonym for a variable 05:35:43 I call them lexicons to avoid confusion with classic system 05:36:09 Basically I have capability to 1) create a new vocabulary, 2) add a vocabulary to the context stack, 3) drop a vocabulary from the context stack, 4) make the top context item CURRENT, 5) make the top vocabulary CURRENT and the ONLY vocabulary on the stack, and 6) the ability to open a whole new clean context stack that I can do what I want with, and later to fall back to the previous one. 05:36:34 For that last I don't allocate any new region or anything, I just stack the new context up on top of the old one, with a zero cell separating them. 05:36:51 I define a new vocabulary with LEXICON (which is just a synonym of VARIABLE) 05:36:57 But that lets me do any namespace manipulation I want and then restore what existed previously. 05:37:18 I use VOC, and it invokes the CREATE ... DOES> facility. 05:38:07 e.g. LEXICON COMMON is equivalent to VARIABLE COMMON 05:38:16 Right. 05:38:30 I shortened VARIABLE and CONSTANT to VAR and CONST yesterday. 05:38:39 My ONLY takes a lexicon address as a parameter 05:38:48 And had already shortened VOCABULARY to VOC, right from the outset. 05:38:48 e.g. COMMON ONLY 05:39:03 Yes, I can now say FORTH ONLY 05:39:21 That just tosses EVERYTHING and takes me back to the start-up situation. 05:39:26 Would result in having only the COMMON lexicon on the context stack 05:39:36 same principle 05:40:03 To push another lexicon onto the context stack I use USAGE 05:40:16 Today I need to work through the code I've written so far and put this to use. Get all those assembler words, and the ansi control sequence words, and so on into vocabularies and out of the main word list. 05:40:39 e.g. X86 USAGE 05:40:42 I just execute the vocabulary name for that. 05:40:59 But I remember us talking about this before, and I do think there's a certain "cleanliness" in your approach. 05:41:09 We touched on it several months ago. 05:42:03 So I can't really "get at" the storage my vocabularies live in. Except for the Forth voc, which has a variable (FORTH). 05:42:06 I seem to remember discussing it as well 05:42:14 For others I'd have to FIND them and pick through the pointers. 05:43:07 I also added .VAR and .CONST to my "temporary names" utility yesterday. 05:43:13 COMMON ONLY TEST USAGE X86 USAGE 05:43:40 Would result in the context stack having those 3 lexicons 05:43:51 PREVIOUS just pops the top one off 05:44:15 -VOC for me. 05:44:58 If you try to pop the lowest one off, it raises an exception 05:45:07 I think I'll most commonly wind up using PATH: ... ;PATH 05:45:28 PATH: pushes a 0 to the context, and then Forth, and makes Forth current. 05:45:33 I have two FIND like words 05:45:37 So I have a clean context to compile new code in. 05:45:50 if I do want to build on hte previously existing context, I can then sap PRIOR 05:45:57 CONSULT looks up words in a particular lexicon 05:46:01 When I'm done, ;PATH drops everything down through that zero. 05:46:20 LOOKUP looks up words in the whole context stack 05:46:26 WORDS shows me the words in my CURRENT vocabulary. 05:46:46 I did realize this morning I have no good way to find the NAME or a context or current item. 05:47:08 So it would be hard for me to print the current context list, or organize a word listing by vocabulary name. 05:47:28 I may add a pointer to my vocabulary data regions back to its header so that I can get at the name directly. 05:48:08 I could see wanting PATH? and CURRENT? to query those names. 05:48:38 Since my vocabularies are just regular variables it's trivial to get at their names 05:48:44 Or CONTEXT? and CURRENT? 05:49:12 Well, that wouldn't be trivial for me either, because my headers are separate from the bodies. 05:49:22 And there's no general pointer back from bodies to headers. 05:49:52 The main purpose of doing the separation was so definition bodies would butt right up against each other. 05:50:04 Adding a pointer back would disrupt that and defeat the entire point. 05:50:12 Doing that made it trivial for me to do this: 05:50:20 That's what I do for targets, the headers are on a different machine 05:50:33 : entry-1 ...code... : entry-2 ...code... ; 05:50:52 Since the cells representing the first and second ...code... secctions are contiguous. 05:51:02 The headers just point in to the right places. 05:51:12 I do that for target forths 05:51:23 The headers are on the host machine 05:51:25 I only have the one. 05:51:52 But for the host IDE forth I kept it simple 05:52:15 Well, nothing is simpler than just one continuous run of everything, mixed together. :-) 05:53:29 Yes, I prefer it for a host Forth 05:54:21 For a target I don't normally want to waste space and keep them on the host machine 05:54:34 * so I keep them ... 05:54:41 I do plan to use this for "gadgets," but the gadgets I have in mind will have ample RAM and I'll just run the system directly on them and communicate over a link of some kind. 05:55:15 So it won't really be what you'd call "tethered" development. 05:56:05 By having a tethered system I keep my options open, the target can just be machine code up to a full fat forth if I ever need 05:56:16 This is the current word that gets called after the CREATE in the voc declaration: 05:56:18 .: voc.c 2 cells allot wlink vlink ; 05:56:29 I think if I want a pointer back to the name, that just becomes 05:56:44 .: voc.c 3 cells allot wlink vlink nlink ; 05:57:16 Then nlink will just grab LATEST and stick it in that 3rd cell. 05:58:04 I just have the one link field at the start of a header 05:58:30 : link, ( -- ) align current @@ , ; compiled 05:59:42 Oh, well right. In my *headers* I just have a link back to the previous header in that list. 05:59:56 Though I do keep my name strings elswhere, and I have an index into that table in the header. 06:00:24 I eventually mean for that string table to become a block-resident persistent thing, with usage counts. 06:01:06 Whenever I add a new word to my body of source code, it will get added to the table. If I delete the last reference to a word, it will get removed. 06:01:52 Then I'll be compress my source by having it only contain indices instead of strings. 06:01:56 I just make the whole host forth persistent 06:02:21 I've designed a little scheme to represent those integer indices in as few bytes as possible. 06:02:59 That sounds over-sophisticated 06:03:19 :-) 06:03:36 We've established that you're quite averse to "non-simple." :-) 06:04:33 I got that idea initially from some work that Chuck did, though. I think he later moved on from there toward "sourceless." 06:04:37 --- quit: dys (Ping timeout: 246 seconds) 06:05:11 And his was simpler, because he had his string table contain a pointer to the CFA of the word. So he got blindingly fast compilation, because there were no searches. 06:05:40 But I thought about that for a while, and I think it only works if you have any given string have only ONE meaning in your system, system-wide. 06:05:45 I find it simpler just to keep the source on the development host 06:06:06 That really makes multi-process with per-process dictionaries and even vocabularies pretty impractical. 06:06:13 I have some ideas on the sourceless front, haven't coded them up yet 06:06:22 Given my goals for this system I cannot say that a string will only ever have one meaning system wide. 06:06:55 So I will get faster compilation, but not as fast as him, and I will get the source compression benefits. 06:07:23 I still have to search dictionaries, but the comparisons during those searches are integer compares rather than string compares. So that will definitely speed things up. 06:07:31 The best source compression is just not storing the source in the target system 06:07:47 Yes, but I don't have "target system." 06:07:50 I have "system." 06:07:58 We are pursuing different goals. 06:08:34 My impression is that you've done a damn fine job optimizing for your environment. 06:09:01 Thanks 06:09:10 Source compression is pointless here on my Mac. I have more disk space than I could ever fill up with Forth source. 06:09:28 Right 06:09:36 But one thing I'm interested in is porting the whole thing over to this little Cortex M4 gadget I've got. I have considerably less storage space there. 06:10:08 But I still want to experiment with treating that thing as a general purpose computer that I connect to and do multi-screen sessions and so on. 06:10:32 I want to make it behave a lot like the first DOS-based PC I ever had, only with more features (like multi-process etc.) 06:10:37 Just for fun. :-) 06:10:45 Sure 06:11:49 I'm interested in the sourceless angle not so much for the space savings but for the simplicity and integrity 06:13:21 --- join: forthen (~qc@217-215-144-40-no249.tbcn.telia.com) joined #forth 06:13:35 hmm. 06:13:49 brb 06:13:56 Chuck gave up on sourceless, so, good luck? 06:14:37 Oh, did he chuck that? No pun intended... 06:14:57 Sourceless seems to me to fit the best if you have virtual memory hardware. 06:15:10 Then you craft all that stuff on disk as thought your directly crafting RAM. 06:15:25 Without virtul memory support, it seems like it gets cumbersome. 06:15:27 He gave up on it for a long while, but he's back to exploring it again 06:16:13 Also seems like it would work better if there was a perfect one-to-one correspondence between source and object. 06:16:42 The way we "morph" stuff a little, like turning IF ... THEN into a conditional jump and so on, also would require some work to deal with. 06:17:16 Sourceless requires that you be able to render the compiled code back into the source listing, and ideally you want that to render back to you exactly what you typed in to start with. 06:17:17 depends, one could use (if) (then) and other such aliasing words 06:17:41 And along with that, at least at one point in time, Chuck abandoned any formatting of the source on screen, and I think that would just break my brain. 06:17:44 I'd find it intolerable. 06:18:12 Well, but there nothing in the compiled code at the location of the THEN / (then). 06:18:16 so formatting control words that are just nops when executed? 06:18:26 You'd have to figure out from the jump where to put the then. 06:18:46 It boils down to interactive assembly/disassembly 06:18:47 Yes, but that's inefficient - to put stuff inline with your code that doesn't do anything. 06:18:55 depends if your 'compiled code' is unportable machine code or much more portable virtual machine code 06:18:55 But yeah, you could solve these things. 06:19:01 They all just lead to imperfections. 06:19:11 Chuck wants a 1-1 correspondence 06:19:26 I'd have guessed that he would. 06:19:37 It fits his nature. 06:19:50 That's a starting assumption for a sourceless system 06:19:59 * Zarutian has given up on x86 machine code and he has too changed computer architecturs too often to care what the underlying chip is doing exactly. 06:20:19 If you have that, then you just pick up the next thing from compiled code and search your string table for what to show as the source for that. 06:20:43 You need 3 things (to my mind) 06:20:58 An opcode name table 06:21:08 A label name table 06:21:24 and a comment table 06:21:24 Also, say you come to (LIT) . 06:21:32 What radix do you render that number in? 06:21:41 hex 06:21:59 In a perfect system, it would be rendered however I had typed it in the first place. 06:22:12 You would have typed it in hex :) 06:22:29 But I could type 64 or x:40 or b:1000000 06:22:50 No, I'd have typed it however I wanted to - whatever I felt best fit the situation I was working in. 06:23:16 If you want to be able to do that, then you'll need a literal base table as well 06:23:40 Right. All I'm saying is that all of these things make sourceless a complicated endeavor. 06:24:13 There used to be a sourceless assembly system that supported many chips in the 80s or 90s 06:24:13 And ultimately it's only useful if it makes you a better programmer. 06:24:51 I know my own personality well enough to know that I will NOT be giving up formatting in my source. :-) 06:24:55 --- quit: Zarutian (Read error: Connection reset by peer) 06:25:05 It was called M-code 06:25:10 --- part: forthen left #forth 06:25:12 Oh, I remember that name. 06:25:15 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 06:25:18 Never really knew much about it. 06:25:44 It's all about tradeoffs, I'd like to explore the advantages/disadvantages 06:25:56 --- join: forthen (~qc@217-215-144-40-no249.tbcn.telia.com) joined #forth 06:26:35 I have an article on it that I retyped into a text file, so I could ponder it 06:27:14 If you like I can paste some extracts 06:29:57 Guess not :) 06:30:33 brb 06:32:56 Yes, I totally agree with that, and it is a fun exploration. 06:33:14 Some of the stuff I do is driven almost totally by curiosity and love of tinkering. 06:33:22 Here's some extracts: 06:33:27 Yes, please. 06:33:50 M-Code lets you employ assembly-like mnemonics whereupon it will produce the 06:33:50 executable codes. 06:33:50 But you can type in the hex codes directly and it will show you the mnemonics as 06:33:50 a kind of comment (in the case of the call instruction, you will be prompted for 06:33:50 a "target"... an address or symbolic label). 06:33:52 What M-Code does is create an executable file as it goes along; it incrementally 06:33:55 assembles each instruction as it is entered, or reassembles if an instruction 06:33:57 was changed (sounds like a spreadsheet, a little). 06:34:01 The input method is user-selectable (i.e. choose mnemonics or machine code, 06:34:02 further choose binary or hex as you like.) 06:34:05 Add symbolic labels as targets of jumps or calls and M-Code builds a label file 06:34:07 to keep track of them, too. 06:34:10 No source code. 06:34:13 No assembly code. 06:34:15 No high-level program. 06:34:19 No syntax. 06:34:20 When you pick up your work and restart M-Code, it gets the executable file you 06:34:22 specify and disassembles it (like DEBUG only better), combines this information 06:34:49 with the support files (labels, comments, etc...) and displays it all on the 06:34:49 screen for you (see Fig.1). 06:34:50 What you see looks a lot like a listing file produced by an assembler. 06:35:19 --- end of extract 06:35:35 Ah, that sounds quite interesting. 06:36:53 Here's another extract: 06:37:14 But you never create source code in the vaccum of a dumb text editor; you never 06:37:14 wait for the assembler to syntax check / assemble your program; and you never 06:37:14 crank up a linker to produce an executable image. 06:37:14 It's the job of the M-Code "intelligent" field editing tools to know; to check 06:37:14 for mistakes as you type, to ask for parameters when needed and to show help 06:37:16 windows to prompt you for input in whatever format you find most natural. 06:37:19 Your work is, in effect, under constant surveillance. 06:37:21 You aren't allowed to make stupid low-level mistakes. 06:37:24 Forget about the ORG assembler directive; if you want code to start at $0100, 06:37:26 don't write: 06:37:29 ORG 0100h 06:37:31 in an assembler source file; just start writing instructions at that address. 06:37:34 --- end of extract 06:38:04 This feels like something PoppaVic would like. 06:38:12 He despises linkers. 06:38:52 Me too :) 06:40:47 <`presiden> "it is acceptable to explore a diversity of fields if that is where your curiosity leads" -- Feynman 06:42:12 Feynman, my favorite genius :) 06:43:32 Gotta go, catch you all later 06:43:40 --- quit: rdrop-exit (Quit: Lost terminal) 08:02:04 --- join: DKordic (~user@79-101-206-168.dynamic.isp.telekom.rs) joined #forth 08:25:37 --- quit: dave0 (Quit: dave's not here) 08:52:55 --- join: gravicappa (~gravicapp@h37-122-117-136.dyn.bashtel.ru) joined #forth 08:57:32 --- quit: pierpal (Quit: Poof) 08:57:50 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth 09:06:28 --- join: dys (~dys@tmo-112-153.customers.d1-online.com) joined #forth 09:41:42 I can't find online references to that m-code stuff. 10:00:55 --- quit: nighty- (Quit: Disappears in a puff of smoke) 11:34:35 --- quit: ashirase (Ping timeout: 255 seconds) 11:39:34 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 11:43:45 --- quit: ashirase (Ping timeout: 245 seconds) 11:52:00 --- join: xek_ (~xek@user-5-173-136-24.play-internet.pl) joined #forth 11:53:39 --- quit: xek_ (Remote host closed the connection) 12:05:38 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 12:10:47 --- join: xek (~xek@public-gprs403116.centertel.pl) joined #forth 12:26:23 --- part: forthen left #forth 12:55:31 --- quit: gravicappa (Ping timeout: 246 seconds) 13:14:56 bar show nicks 13:14:59 Ooops. 13:20:55 --- quit: pointfree (Ping timeout: 252 seconds) 13:21:04 --- quit: cheater (Ping timeout: 246 seconds) 13:22:10 --- join: pointfree (sid204397@gateway/web/irccloud.com/x-ohetdurdweolydpd) joined #forth 13:31:01 Hey - all of my irc seems awfully quite - can someone reply just so I know I haven't gotten my system fouled up? 13:31:22 KipIngram: shalom 13:31:28 Thank you sir. 13:47:25 https://memeworld.funnyjunk.com/pictures/Mer 13:47:30 ugh 13:47:37 why did that happen 13:47:59 link is invalid 13:48:05 yeah 13:48:13 https://memeworld.funnyjunk.com/pictures/Merriam+webster_9e82a5_7006077.jpg there we go 13:48:55 lol. 13:54:47 --- quit: Zarutian (Ping timeout: 246 seconds) 13:58:56 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 14:09:28 --- quit: tabemann (Ping timeout: 250 seconds) 14:22:37 --- join: tabemann (~tabemann@24.196.100.126) joined #forth 14:40:06 --- join: cheater (~cheater@unaffiliated/cheater) joined #forth 14:49:25 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth 15:04:30 --- quit: tabemann (Ping timeout: 250 seconds) 15:05:52 hi 15:08:29 hey 15:10:21 hi rain1 15:12:56 Hi dave0. 15:13:06 hi KipIngram 15:15:13 i read about open firmware IEEE 1274 the bios with Forth in it... it uses the 1994 Forth standard 15:20:14 --- join: mark4 (~mark4@12.41.103.244) joined #forth 15:36:34 Cool. 15:39:10 --- quit: xek (Ping timeout: 250 seconds) 15:40:06 So I got my vocabulary stuff polished to my satisfaction. Added a backpointer from the vocabulary information in the body region the the vocabulary's header, so that I can get at the names for various printing. 15:40:42 Took all the code I've written in the last month or so and organized it a bit and deployed it in low blocks, with block 1 as a "load block" (it just loads other blocks). 15:40:58 So now when I start up I can just say 1 load and I have the system the way I want it, ready to work on stuff. 15:41:40 I could get back to the assembler now, but I'm thinking about writing a few words to output word lists, vocabularly lists, and that sort of thing. And maybe "SEE". "Perusal tools." 15:42:35 --- quit: mark4 (Remote host closed the connection) 15:49:31 When rdrop-exit shows back I want to ask him more about his output library. Sounded like it was pretty slick. 15:52:57 KipIngram: I am of 2 minds on SEE.. otoh, it's convenient; on the other, VIEW fields made more sense; on the gripping hand, you DO need something - even if it does disasm. 15:53:19 I'm not familiar with VIEW. 15:53:25 What does it do that's different? 15:53:45 I don't know that I agree that such a tool is *required*. 15:53:53 KipIngram: it was an F83 thing: "View WORD" would load the releated block (recorded in the head) and give you a listing. 15:53:57 If you know what the word's supposed to do, that really ought to be enough. 15:54:05 Oh. 15:54:07 I see. 15:54:18 Sure - for words you write. 15:54:30 That would get you commentary as well. 15:54:34 No, I think you need at least a DUMPER - because, you want to at least look at it and go "umm.. wtf happened to my 12 $FF bytes?" 15:54:50 and yes, F83 was pretty neat. 15:55:09 I do think F79 and F83 were near the high water mark. 16:00:15 I somehow got hold of a physical copy of the F79 standard back in the day. 16:00:21 I can't for the life of me remember how. 16:00:37 It's the only Forth standard I've ever had in printed form. 16:00:42 iirc, it was just a doc from FIG anyway - I think I had one as well 16:01:31 White cover with blue writing and border? 16:22:42 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth 16:22:59 Good morning Forthwrights :) 16:23:56 <`presiden> good morning rdrop-exit 16:24:24 Hi `presiden 16:25:23 Hi rdrop-exit. I've been waiting for you to show up. 16:25:39 Can you tell me again / some more about your output subsystem? 16:25:46 Hi KipIngram 16:25:58 You said it had a lot of curses-like features. 16:26:08 And I seem to recall it works off of "diffs" somehow. 16:26:22 Yes, just a sec 16:28:18 c[_] Needed to coffe-up :) 16:28:29 Oh, take your time and do this at your leisure. 16:31:52 I keep a cache representation of the character-cells 16:32:26 and a caches of the rendition settings, cursor position, etc... 16:34:31 When I need to update the VDT display I compare the desired state of the display with the cached state and write the ECMA-48 codes to convert one to the other to a buffer which gets flushed all at once 16:35:14 What is ECMA-48? 16:35:24 These caches - they are for the entire screen? 16:35:41 ansi escapes 16:35:56 It's the current standard for what used to be called ANSI escape codes 16:35:57 Oh, ok. 16:36:01 Go tit. 16:36:03 :-) 16:36:07 Got it. 16:36:09 lmao 16:36:55 Is your cache system for the whole screen? 16:37:00 There's a cache for the entire screen, and individual cache variables to track current settings 16:37:34 When you do the "all at once update," is that one single "write" to the entire screen, or is it per line, or what exactly? 16:38:25 So you must have some kind of data structures that you can use to "index into" the caches at the spot corresponding to a particular screen position? 16:38:44 One single write for the entire screen, but the write only contains the control sequences to change the current screen to the desired screen 16:38:59 Right, because you've diffed. Ok. 16:39:13 Ah. Ok, now that seems to be clicking a bit. 16:39:32 Are all these caches row/column arrays of strings? 16:40:16 Not really, let me get some code 16:40:48 <`presiden> how's the latency? 16:40:57 fine 16:41:09 0 preamble Host UI - Cached Character-Cells 16:41:09 1 16:41:10 2 The Cached Character-Cells hold a representation of what we 16:41:10 3 assume to be the current state of the host VDT character-cells. 16:41:10 4 |refresh| compares the desired display state with the cache 16:41:12 5 and transmits control sequences and content to transition the 16:41:14 6 actual host VDT character-cells to the desired state. 16:41:17 7 16:41:19 8 Each cached character-cell is represented by 16 bits, the low 7 16:41:22 9 bits of which contain the ASCII code of the displayed character, 16:41:24 a other bits encode the rendition attributes for the 16:41:27 b character-cell (i.e., underlining, boldness, foreground color, 16:41:29 c and background color). 16:41:32 d 16:41:34 e 16:41:37 f 16:41:56 Ok, so you keep two bytes per cell. 16:42:11 Yes 16:42:37 So all of your screen locations are held in the same 16-bit size thing. 16:42:55 Yes 16:43:00 So that helps - I was picturing trying to hold the actual ANSI stuff, and that makes them variable size. 16:43:21 0 source Host UI - Cached Character-Cells - Basics 16:43:21 1 16:43:21 2 #ccells 2* buffer ccells' compiled 16:43:21 3 16:43:21 4 : ccell' ( position -- a ) 2* ccells' + ;inline compiled 16:43:23 5 16:43:26 6 \ fedcba9876543210 16:43:28 7 % 0000000010000000 constant underlining% 16:43:29 But I see now - for any thing that has changed you generate the ANSI to go there and write the update. 16:43:31 8 % 0000000100000000 constant boldness% 16:43:33 9 % 0000111000000000 constant background% 16:43:36 a % 0111000000000000 constant foreground% 16:43:38 b 16:43:41 c 16:43:43 d 16:43:46 e 16:43:48 f 16:43:51 Yes 16:44:28 ccells' is the character cell cache, I use names ending in ' for caches 16:45:41 Ok. I think the key thing I was missing was how you bring in the ansi codes at sort of the "last minute." 16:45:46 You'll need more than 16 bits if you go beyond the ECMA standard (more colors, attributes, etc...) 16:45:54 Which solves all the problems pretty nicely. 16:46:46 So when you write output to this system, do you have two copies of the screen array? The cache and the one you literally write to? 16:46:51 So that you can then compare? 16:46:58 Or do you generate the diff as you write? 16:47:04 I guess that would make the most sense. 16:47:14 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 16:47:38 Like if EMIT places a character at a certian location. 16:47:44 I generate the diff into a buffer and then flush the buffer, its a batch 16:47:58 You could look at the old value, compare to the new value, if they're different append to your ansi string. 16:48:28 Yes but not during EMIT, only at the time I refresh 16:49:02 Ok, so if you don't do the compare at EMIT time, you must have two copies of the information - old and new. 16:49:10 Else how can you compare? 16:49:34 How do you decide it's' time to do an update? 16:49:39 Yes, old and new 16:50:15 Then I guess you just reverse the roles of old and new after each update? 16:50:25 To avoid have to copy? 16:50:39