00:00:00 --- log: started forth/18.10.30 00:01:57 --- join: xek (~xek@apn-37-248-138-80.dynamic.gprs.plus.pl) joined #forth 00:43:46 --- quit: pierpal (Ping timeout: 244 seconds) 00:57:12 --- quit: dys (Ping timeout: 272 seconds) 01:25:36 --- join: pierpal (~pierpal@95.234.60.245) joined #forth 01:29:16 --- quit: pierpal (Read error: Connection reset by peer) 01:38:39 --- join: pierpal (~pierpal@95.234.60.245) joined #forth 01:40:37 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 01:56:38 --- quit: pierpal (Ping timeout: 250 seconds) 01:57:10 --- quit: mstevens (Read error: Connection reset by peer) 01:57:21 --- join: mstevens (sid285816@gateway/web/irccloud.com/x-mhpcntcqgjvqxsdu) joined #forth 01:58:50 --- join: pierpal (~pierpal@95.234.60.245) joined #forth 01:59:11 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 01:59:21 Hey 02:03:04 --- quit: ashirase (Ping timeout: 272 seconds) 02:07:28 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:17:04 --- quit: ncv (Remote host closed the connection) 02:19:54 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth 02:19:54 --- quit: ncv (Changing host) 02:19:54 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 03:18:04 --- quit: smokeink (Remote host closed the connection) 03:28:20 --- quit: pierpal (Ping timeout: 245 seconds) 03:36:32 --- join: pierpal (~pierpal@95.234.60.245) joined #forth 03:43:58 --- quit: wa5qjh (Ping timeout: 252 seconds) 03:46:30 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 03:47:12 --- join: smokeink (~smokeink@118.131.144.142) joined #forth 03:50:18 --- quit: john_cephalopoda (Read error: Connection reset by peer) 03:52:13 --- quit: wa5qjh (Ping timeout: 252 seconds) 03:52:34 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 04:03:39 --- quit: smokeink (Remote host closed the connection) 04:22:07 Huh, nice: https://www.taygeta.com/fsl/scilib.html 04:22:52 --- join: smokeink (~smokeink@118.131.144.142) joined #forth 04:27:07 --- join: wa5qjh (~quassel@175.158.225.208) joined #forth 04:27:07 --- quit: wa5qjh (Changing host) 04:27:07 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 04:43:38 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 05:17:59 --- quit: pierpal (Read error: Connection reset by peer) 05:20:02 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 05:24:42 Hey, which one of you guys was talking yesterday about the book that described a "prefetch" unit for Forth? 05:25:18 logged by clog at http://bit.ly/91toWN 05:26:21 Ok, looks like rdrop-exit. 05:27:43 Here's the book, in case anyone is interested: 05:27:45 https://smile.amazon.com/Interpretation-Instruction-Coprocessing-Computer-Systems/dp/0262041073/ref=smi_www_rco2_go_smi_9689862631?_encoding=UTF8&SubscriptionId=AKIAILSHYYTFIVPWUY6Q&camp=2025&creative=165953&creativeASIN=0262041073&ie=UTF8&linkCode=xm2&tag=duckduckgo-d-20 05:29:10 I just picked up a used copy for under $13. 05:31:31 I'm guessing that the approach there is to have a bit set in the instruction cell if it's a "call," and not set if it's a primitive. If the coprocessor sees that bit set, it handles it - it would have the return stack there local to the coprocessor. When it comes to one that doesn't have the bit set (a primitive) it would pass that on th the main cpu. 05:31:49 So the main CPU would essentially just execute a stream of primitives, and never see the other parts. 05:32:59 That's basically how I'd planned it in the fetch unit of that FPGA thing. 05:33:46 I think if I were doing such a thing I'd put the return stack IN the coprocessor - not in RAM - to eliminate that extra memory contention. 05:37:34 I guess you'd also keep IP in the coprocessor, since it needs to know where to fetch from. 05:37:41 --- join: pierpal (~pierpal@95.234.60.245) joined #forth 05:37:55 The main CPU would just fetch "next primitives" from a fixed address. 05:38:26 There'd be some sync issues for sure - imagine when you EXECUTE an xt that's on the data stack. 05:39:01 By then the coprocessor has fetched and unwound calls well ahead, but you need to execute the one from the data stack first. 05:39:48 Maybe the way to handle that is for the CPU to write that xt to the coprocessor - that would instantiate a new prefetch instance on the coprocessor. 05:40:04 So you'd fetch from a different address for a while, until that was empty, and then go back to the first one. 05:42:05 conditional jumps are the big issue. The coprocessor could make an assumption and continue to fetch along that path. The CPU would need to know what that assumption was; if it was wrong, the CPU would redirect the coprocessor down the other path. 05:48:02 --- quit: pierpal (Read error: Connection reset by peer) 05:48:13 --- join: pierpal (~pierpal@95.234.60.245) joined #forth 05:51:20 --- quit: john_cephalopoda (Quit: Trees can see into your soul. They lurk everywhere.) 05:54:14 Anyway, this strikes me as a quite tractable process - I could see the coprocessor going in a system as a PCIe peripheral. 05:54:52 Though you'd probably want two - one with affinity to each of the usual two PCIe "domains." 05:55:28 You could put multiple copies of the coprocessor logic on each one, so cores could have exclusive use of a coprocessor circuit. 06:01:02 --- quit: pierpal (Ping timeout: 246 seconds) 06:12:20 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 06:27:21 KipIngram: I just bought a copy yesterday. I'm looking forward to reading it. 06:33:42 --- quit: smokeink (Remote host closed the connection) 06:41:08 Yeah, me too. :-) 06:41:42 I've sunk a lot of thought into that general "coprocessor" idea anyway, but I'd never clicked to the idea of putting just that piece outboard of a standard processor. It's a really neat idea. 06:42:08 I've done a lot of thinking about how to optimize the conditional branch situation. 06:49:50 wouldn't putting the coprocessor in a PCIe peripheral introduce too much latency? 06:58:37 --- quit: tabemann_ (Ping timeout: 264 seconds) 07:03:49 it introduced so much latency that his irc connection timed out 07:11:34 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth 07:30:18 --- quit: rdrop-exit (Quit: Lost terminal) 07:57:05 :-) 07:57:09 I was driving. 07:57:34 Yeah, it might; I don't know. Is there a special way for putting coprocessors in systems? 07:58:00 no i mean tabemann pinged out 08:08:48 KipIngram: Considering that GPUs are some kind of coprocessor and they are bound in via PCI, it might just work. 08:09:21 well, arent GPUs usually somewhat latency tolerant? 08:21:54 Probably more than this would be, given they're "output only." 08:22:01 Not a bi-direction sort of thing. 08:26:04 --- join: TheCephalopod (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 08:26:28 The latency would hurt you when you came to conditional branches - the longer it takes to have the CPU figure out which way the branch should go, the more time the coprocessor would spend waiting. 08:27:03 For just peeling through unconditional code, though, the latency isn't that bad - it would be like having a lot of latency in a YouTube video - it still looks fine even though you're seeing it a second after it was sent. 08:28:10 True. And input lag from input devices is so long that it doesn't matter much how much delay the GPU adds. 08:29:14 --- join: proteusguy (~proteus-g@cm-134-196-84-17.revip18.asianet.co.th) joined #forth 08:29:14 --- mode: ChanServ set +v proteusguy 08:31:20 hmm.. such itc coprocessors are pretty much pointer chasers, no? 08:47:58 Yes, that's what I think it would be. 08:48:10 Just chasing through the threading structures. 08:49:21 Mostly. Whenever it came across a primitive invocation, it would have to be able to recognize that immediately, from looking at that cell. 08:49:31 Those cells would get pushed into a fifo that was being emptied by the CPU. 08:50:10 Normally in a Forth system you can't tell just by looking at a cell in a definition whether it's invoking a primitive or a definition. 08:50:25 So I think you'd want "soemthing extra" there - a bit reserved as a flag. 08:51:05 I mean, you could fetch where that cell points and see if it's docol, but that's a whole layer of work that would be easy to avoid. 08:52:26 You could avoid having CFAs for primitives altogether - if that flag bit said "primitive," then the cell content could just be the address of the primitive's code. 08:52:34 CPU would just jump there. 08:52:36 the itc coprocessor idea got me thinking on more general pointer-chaser coprocessor. You give it an counted array of cells, first cell is the first pointer while the rest of the array are relative offsets. 08:54:01 that is, fetch from first pointer the next pointer add offset to that then that pointer becomes the first pointer in next iteration. 08:54:11 Ok, so this is an interesting idea in systems with some cell bits to spare. 08:54:34 You could dispense with CFAs altogether - you could have a bit field in the cell that indicated what kind of word it was (primitive, variable, definition, etc.) 08:54:50 The coprocessor could have a table of addresses you could fill with your routines for those things. 08:55:03 or systems like J1 or the canonical dual stack machine from the New Wave book 08:55:05 So the coprocess would fetch the cell, look at that bit field and decide what to do from there. 08:55:17 It would supply the CPU with a code address and a parameter address. 08:55:34 The CPU would just fetch the parameter address into a register and jump to the code address. 08:55:57 You'd also want to be able to indicate "return" in that bit field, I think. 08:56:11 Since everything about navigating the code stream needs to be discernable by the coprocessor. 08:56:22 yeah 08:56:46 That's the direction I was going in my processor - I had 32-bit cells that were fetched by the fetch unit. 08:56:56 A couple of bits in that cell told it these things. 08:57:08 And the remaining bits were packed 5-bit opcodes, or an address. 08:57:24 The execution unit saw nothing but a stream of 5-bit opcodes. 08:57:31 Except for a couple of corner cases, like literals. 08:58:39 I believe I didn't have enough cases (I only had two spare bits) to indicate return at that level - I believe I invoked logic that would take a cell of opcodes and "recognize" if any of them were return. 08:58:49 So the fetch unit pre-screened the opcode stream for a return. 08:59:06 Which made return a noop as far as the execution unit was concerned - it had already been handled. 08:59:31 so, let me guess, msb bit told if the cell was a call or opcodes, next msb bit if cell was opcodes, indicated that there was a return in it? 08:59:46 No. See ^ that. 08:59:55 I used up my "two bits" for other things. 09:00:05 I had to actually test all the opcodes to see if any of them were return. 09:00:15 I see 09:00:21 I believe I had 1) packed opcodes, 2) call, 3) jump, 4) conditional jump. 09:00:49 And it was all oh so nice until conditional jumps introduced a lot of extra nastiness. 09:02:28 why have both conditional and unconditional jumps? why not just conditional jumps but with a fast_literal op before pushing an true before it? 09:04:21 naah, that does not get rid of the opcode scanning 09:04:30 that the coprocessor has to do 09:05:17 at least looking for an instance of the return opcode is solvable with combinational boolean circuit 09:06:31 if you're going to go that route, why have jumps at all instead of just conditional swap, >r and ret :P 09:06:41 i guess that would make it hard to have position-independent code 09:07:02 and hm 09:07:35 it would be hard to implement with the f21-style "do everything always and use the opcode to select where to latch from" 09:07:50 because it would need to reach deeper into the stack 09:07:53 Zarutian: That's an idea. 09:07:56 I didn't think of it. 09:08:14 Yes, catching the returns was no problem. 09:08:28 koisake: Also possibilities. 09:09:56 haven't read the scrollback yet so i'm probably missing a lot of important context 09:11:34 have never attempted to actually develop a cpu in a hdl. things to do someday 09:12:49 KipIngram, were you implementing this as an FPGA or what kind of environment? 09:13:44 I was planning it with the Spartan 6 Xilinx FPGAs in mind, but I never got it beyond "paper." 09:14:01 I knew the Spartan 6's pretty well, though, so I'm 99% sure everything I did would have dropped in pretty well. 09:14:03 +1 you and me both... ;-) 09:14:28 +1 you and me both... ;-) (not beyond paper that is...) 09:14:46 I had 32-element hardware data and return stacks. 09:15:18 And I'd worked out an eccoding for the 5-bit instructions so that I could do all the stack ops and so on with just two levels of LUT logic delay. 09:19:54 That was the fun bit right? How quick can we make instructions work when we have complete control over the processor... Quickly lose sight of the bigger picture haha. 09:23:34 1 bit for stack pointer direction, 1 bit each for where to source contents for top and second positions of stack? 09:25:51 but that wouldn't get one swap.. 09:31:13 Yes, that was fun. :-) 09:31:20 trying to puzzle this out 09:31:30 Letting a third layer of logic slip in would have been a big clock speed hit. 09:32:07 thinking of things that are either sparse enough to use up the whole 5 bits or else yield a pretty inconvenient set of stack ops 09:32:42 hm. 09:33:22 S never stays the same, so it can get its value from 2 locations, old T, or old 3rd item) 09:34:02 T can get its value from T (nip, dup) or S (everything else) 09:34:31 so that is one bit each 09:36:07 stack pointer can be -1 (drop, nip), 0 (swap), +1 (over, dup) 09:36:41 so 2 bits there. i'm not a big enough fpga person to know if there is a way not to waste the unused encodings without an extra level of lookups 09:36:44 am i close? 09:43:32 --- quit: TheCephalopod (Quit: Trees can see into your soul. They lurk everywhere.) 09:45:12 KipIngram: My interest in the book was for decentralizing the inner interpreter to various peripherals and devices on the pcb, not as much for a coprocessor ic. 09:45:34 I used them up pretty thoroughly. 09:45:35 The bus would have to satisfy the distributive property somehow. 09:46:12 I don't have it in front of me right now, though. 09:47:05 I would be going for a return *queue* (lazy evaluation) rather than a return stack. 09:48:59 The return queue might actually be easier to manifest in hardware than a return stack. The queue is after all just bits moving through a wire. 09:51:45 The book will help make this whole idea concrete enough to implement. 09:51:48 Not sure I'm following your return queue idea. I'm sort of multi-tasking right now, th ough. 09:53:01 You need the last address first. That says "stack" to me. 09:55:40 A stack lends itself to depth-first eager evaluation. A queue lends itself to breadth-first lazy evaluation. 09:55:45 Breadth-first gives the interpreter an opportunity to short-circuit unnecessary code (aka lazy eval). 09:56:40 You're way off somewhere other than where I was. 09:57:34 If a call is made, I push the return address. I use it when I need it. 09:57:37 Very simple. 09:57:48 Seems like you're in a more abstract head space. 10:13:15 My goal was to keep the thing brutally simple, so that a) I could do what was needed with just two logic layers, and b) I'd have room for as many "cores" as possible. 10:13:25 pointfree: FIFO return stack, eh? 10:13:30 interesting 10:13:53 That said, the Spartan 6 has a way of using the LUTs as 16-deep fifos, so something interesting might live in there. 10:23:12 As far as avoiding unnecessary code goes, I can implement short circuiting manually with multiple conditional returns. 10:24:03 ... .0=; .0=; .0=; drop 1 ; 10:24:11 Or something like that. 10:24:30 If an early test passes and its conditional return is taken, the rest don't run. 10:25:25 Or possibly I could just run the last and return - depends really on whether any non-zero value will do for the return or not. 10:40:17 Of course now I'm crossing wires - I didn't HAVE conditional returns in that processor design. 10:40:25 That's a new feature in this latest one I'm writing. 10:59:03 pointfree: Please do say more when you get back - I'm quite interested. 11:57:32 Have any of you ever used CodeWars? 11:58:01 It's a site for little programming challenges, I use it for Python similar to crosswords 12:00:25 No, I've heard of it but never given it a try. 12:01:32 If you do try it out, make sure to message support asking them to add gforth 12:20:55 --- quit: ncv (Remote host closed the connection) 13:08:59 Ok, so I went to search up info on codewars. 13:09:08 I left out the e by accident, and found this instead: 13:09:09 https://en.wikipedia.org/wiki/Cod_Wars 13:09:16 Actual rather fascinating history. :-) 13:10:03 i hope it's a war over codpieces and not the fish 13:17:54 No, it's the fish. 13:18:00 They weren't really quite real wars. 13:18:27 Just some VERY tense disputes, primarily over how far out Iceland's territorial fishing exclusivity would extend from its shores. 13:18:58 Iceland, on several occasions, unilaterally declared increased territorial limits. 13:19:06 Britain objected. 13:19:11 Hijinx ensued. 13:19:45 kinda gives me a hankering to play rise of nations 13:19:47 Iceland couldn't hold Britain off directly, so they threatened at one point to quit NATO and eject US military presence from Iceland. 13:20:17 That got the US and other NATO nations' attention, so basically Iceland has wound up winning all of these things. 13:21:12 I'll tell you what, one thing you can definiteily say about human civilization - we have damn sure given rise to some interesting tidbits of history during our time on this ball. 13:22:37 Apparently a super-critical bit of seabed (critical in controlling Soviet submarine access open warm water seas) is in Icelandic territory. 13:22:46 Turned out to be a huge ace in their hand. 13:23:47 is that how you play poker? you go by who has the biggest cards? 13:23:56 :-) 13:24:23 In the 1971 "war" all European nations and the Warsaw Pact as well opposed Iceland's unilateral increase. 13:24:55 But African nations sided with Iceland, because Iceland diplomats successfully convinced them that the whole thing was just a chapter of a bigger issue having to do with European imperialism. 13:25:26 I don't actually play poker. If it were just about the cards I think I could be extremely good - I have a head for numbers and a good grip on probability and so on. 13:25:37 But it's not - at all. It's a head game. 13:25:52 The one who can out-psych the other wins. 13:25:59 And I'm NOT good at that. 13:26:46 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 13:26:50 I think that having a basic grasp of the "technical" aspects is just the minimum required to even sit down non-suicidally. 13:27:10 So much more is required to be a real pro. 13:51:33 --- nick: NB0X-Matt-CA -> nonlinear 13:53:56 so sometimes I find myself in a situation where, based on the data available to me right now, I need to influence behavior later in the pipeline 13:54:25 I've been doing it mostly by setting some flag bit somewhere and testing it later, but I wonder if it would be a good idea to just compile a word 13:55:07 like, have a "deferred execution" word that's reset to nop at the start, and then as it goes through my logic, when I want something to happen before the end, then at that point append something to the deferred execution word 13:57:13 That sounds automatically interesting. 13:57:29 Like you might realize it had more applications than what you're thinking of right now. 13:58:16 I wrote a pick-and-place machine control code in pforth once. 13:58:45 The actual code was just a loop, that called the words for all of the "resources" in the system. A fast loop, so that everyone got run several times a second. 13:59:01 The actual magic was in information passing around that told the words when it was actually time to do something. 14:25:27 --- join: dys (~dys@tmo-101-161.customers.d1-online.com) joined #forth 14:55:03 --- quit: john_cephalopoda (Read error: Connection reset by peer) 15:08:22 So one problem with the "Forth coprocessor" is that in the tight inner loops where performance really counts, you're probably going to get all of your code in cache. So nothing will be going on outside of the chip, and the coprocessor couldn't act. 15:08:47 Given that it sits between the CPU and physical RAM, it's unlikely it could compete speed-wise with cache-based operation. 15:09:25 Where you'd really want it is inside your CPU. 15:31:32 --- quit: xek (Ping timeout: 246 seconds) 15:40:10 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 15:51:45 KipIngram, what is the emacs ctrl- to jump backwards a word 16:04:16 --- quit: dys (Ping timeout: 252 seconds) 16:15:09 M-b 16:17:45 thanks 16:18:07 oh, meta 16:18:24 I was hoping for something that worked at the shell prompt 16:20:41 --- join: pierpal (~pierpal@95.234.60.245) joined #forth 16:26:35 zy]x[yz: You can also use ctrl-. 16:29:36 nice thanks 16:47:18 zy]x[yz: Which shell prompt? 16:47:28 zy]x[yz: 16:47:43 Hm Riot seems to glitch out with your username :P 16:47:58 zy]x[yz 16:48:27 Shouldn't M-b work too? 16:48:33 --- join: smokeink (~smokeink@118.131.144.142) joined #forth 16:53:17 well, i actually don't know what it is but i assume it's using readline because C-a and C-e and C-p/C-n all woek 16:53:47 it's the cli for the product i work on 16:58:12 --- quit: nighty- (Quit: Disappears in a puff of smoke) 16:59:40 Could you read what key code it reads? 17:00:17 --- nick: moony -> moonythevampire 17:00:31 i mean 17:00:43 i could just go find the code 17:00:58 but i'm too lazy 17:01:26 Right. 17:01:33 i would rather just assume it's libreadline since that's worked out for me so far 17:01:37 zy]x[yz: Heh, I got the same issue with xterm and my server via ssh. 17:04:52 I use emacs for converting org-mode markup to html. I wrote a script for that conversion and now write my whole website in org-mode. 17:05:07 https://thecutecuttlefish.org/gol.html :) 17:08:33 --- quit: john_cephalopoda (Quit: Trees can see into your soul.) 17:39:34 --- quit: wa5qjh (Read error: Connection reset by peer) 17:44:45 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 18:39:57 --- quit: wa5qjh (Remote host closed the connection) 18:43:08 --- join: wa5qjh (~quassel@175.158.225.202) joined #forth 18:43:08 --- quit: wa5qjh (Changing host) 18:43:08 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 18:43:47 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:1870:3255:3792:ba89) joined #forth 18:44:56 --- quit: wa5qjh (Remote host closed the connection) 18:46:57 --- join: wa5qjh (~quassel@175.158.225.202) joined #forth 18:46:57 --- quit: wa5qjh (Changing host) 18:46:57 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 18:47:00 --- join: leaverite (~quassel@freebsd/user/wa5qjh) joined #forth 18:47:34 --- quit: leaverite (Client Quit) 19:23:40 --- quit: smokeink (Remote host closed the connection) 19:24:22 --- join: smokeink (~smokeink@185.189.254.154) joined #forth 19:50:25 --- quit: smokeink (Remote host closed the connection) 19:51:38 --- join: smokeink (~smokeink@42-200-116-228.static.imsbiz.com) joined #forth 20:00:27 pointfree, I've also considered the use of fifos in my environment. Mine's inherently an Actor model so it's more obvious in my case. 20:02:12 --- quit: proteusguy (Remote host closed the connection) 20:22:18 --- quit: pierpal (Read error: Connection reset by peer) 20:44:46 --- quit: dddddd (Remote host closed the connection) 20:47:05 --- join: pierpal (~pierpal@95.234.60.245) joined #forth 20:49:20 --- quit: pierpal (Read error: Connection reset by peer) 20:49:35 --- join: pierpal (~pierpal@95.234.60.245) joined #forth 20:53:49 --- quit: pierpal (Ping timeout: 240 seconds) 22:30:34 --- join: proteusguy (~proteus-g@110.164.126.166) joined #forth 22:30:34 --- mode: ChanServ set +v proteusguy 22:37:53 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 22:40:30 --- quit: MrMobius (Ping timeout: 246 seconds) 22:40:30 --- nick: [1]MrMobius -> MrMobius 23:25:34 --- quit: proteusguy (Ping timeout: 272 seconds) 23:42:26 --- join: proteusguy (~proteus-g@110.164.126.166) joined #forth 23:42:26 --- mode: ChanServ set +v proteusguy 23:56:21 --- quit: proteusguy (Read error: Connection reset by peer) 23:56:46 --- join: proteusguy (~proteus-g@110.164.126.166) joined #forth 23:56:46 --- mode: ChanServ set +v proteusguy 23:59:59 --- log: ended forth/18.10.30