00:00:00 --- log: started forth/19.01.23
00:20:28 --- quit: gravicappa (Ping timeout: 246 seconds)
00:21:13 --- join: gravicappa (~gravicapp@h109-187-28-67.dyn.bashtel.ru) joined #forth
00:54:49 --- join: xek_ (~xek@apn-31-0-23-82.dynamic.gprs.plus.pl) joined #forth
01:46:44 --- join: smokeink (~smokeink@185.189.254.154) joined #forth
01:55:36 --- quit: smokeink (Remote host closed the connection)
02:05:03 --- quit: ashirase (Ping timeout: 272 seconds)
02:07:36 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:21:52 --- join: smokeink (~smokeink@118.131.144.142) joined #forth
02:51:47 --- quit: gravicappa (Ping timeout: 246 seconds)
03:09:17 <rdrop-exit> Hola Forthwrights :)
03:14:47 <crc> good morning
03:22:22 <rdrop-exit> Hi crc
03:25:51 <rdrop-exit> I'm coming down with the flu, can't concentrate on anything.
03:27:35 <WilhelmVonWeiner> good morning/evening forthers
03:28:53 <corecode> hi
03:35:00 <WilhelmVonWeiner> what's good
03:53:21 <crc> Working on man pages for the retro executables and refactoring my glossary tool.
03:54:28 <rdrop-exit> Just relaxing today, nothing productive.
03:54:52 --- quit: smokeink (Remote host closed the connection)
03:58:38 <corecode> nothing forthy yet, getting my esp LED matrix driver ready
04:11:24 --- join: gravicappa (~gravicapp@h109-187-28-67.dyn.bashtel.ru) joined #forth
04:31:32 --- quit: pierpal (Read error: Connection reset by peer)
04:32:28 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:33:10 --- quit: tabemann (Remote host closed the connection)
04:33:23 --- join: tabemann (~tabemann@2600:1700:7990:24e0:8d7a:3d82:9669:8573) joined #forth
04:41:42 --- join: smokeink (~smokeink@118.131.144.142) joined #forth
04:44:49 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
04:56:15 --- quit: proteusguy (Ping timeout: 245 seconds)
05:01:50 --- quit: smokeink (Remote host closed the connection)
05:02:11 --- join: smokeink (~smokeink@218.255.73.180) joined #forth
05:22:47 --- quit: rdrop-exit (Quit: Lost terminal)
05:58:30 --- join: proteusguy (~proteusgu@cm-58-10-154-54.revip7.asianet.co.th) joined #forth
05:58:30 --- mode: ChanServ set +v proteusguy
06:28:31 --- quit: smokeink (Remote host closed the connection)
06:28:54 --- join: smokeink (~smokeink@185.189.254.154) joined #forth
06:30:35 <smokeink> https://github.com/rufig/spf/blob/master/devel/~af/lib/c/define.f     what does HEADER do in this code ?
06:31:00 <smokeink> question2 : what does "0 PARSE EVALUATE ," do ?
06:31:38 <smokeink> 0 PARSE EVALUATE ,   <- does this parse the next number from the input stream and then store it inside the word #define's code ?
06:35:19 <jn__> HEADER probably lays down a word header
06:45:35 <corecode> yea without seeing these functions
06:45:49 <corecode> words*
06:47:59 <crc> https://github.com/rufig/spf/blob/90cc85c92f002bc7dd93077de41b7d97aa5de79d/spf3-src/compiler/spf_defwords.f has HEADER, which lays down a new header
06:55:26 <smokeink> does HEADER get it's "name" parameter from the input stream ?
06:55:34 <crc> https://github.com/rufig/spf/blob/master/src/compiler/spf_parser.f has PARSE
06:55:55 <crc> PARSE takes a delimiter character and returns a string address & length
06:56:39 <crc> yes, HEADER takes the name from the input stream
06:57:00 <smokeink> got it, it uses NextWord (just tried it in the repl to see how it works)
06:59:21 --- nick: xek_ -> xek
07:02:58 <smokeink> everything is clear now
07:26:00 --- join: darithorn (~darithorn@75.174.238.174) joined #forth
07:30:49 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
07:36:57 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth
07:37:53 <dave0> hi
07:38:11 <Zarutian> hi dave0
07:38:35 <dave0> hi Zarutian 
08:15:11 <crc> I'm about halfway through my glossary tool updates. 
08:17:29 <WilhelmVonWeiner> what's the new glossary approach?
08:18:42 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth
08:19:11 <crc> Still using the same data file, but cleaning up and refactoring the code. When I'm done, it'll be easier to maintain.
08:19:44 <PoppaVic> always a Good Thing™
08:20:19 <crc> I'm also adding some new options (e.g., 'missing' to show words with no entries in the data file and more export formats)
08:21:03 <crc> The 'missing' bit is useful; it let me find and add four words I forgot previously
08:21:46 <WilhelmVonWeiner> opcode:comma
08:22:04 <WilhelmVonWeiner> One I think I saw in the source yesterday
08:22:44 <crc> Hmm,  that's not in my source tree
08:22:53 <WilhelmVonWeiner> comma:opcode maybe
08:23:00 <WilhelmVonWeiner> it was in Rx.md
08:24:26 <crc> That's not exposed as a word
08:27:31 <crc> The words data file only includes words visible in the final dictionary, so none of the internal factors are in its
08:46:20 --- quit: nighty- (Remote host closed the connection)
08:48:13 --- quit: smokeink (Ping timeout: 244 seconds)
09:10:52 --- join: dys (~dys@tmo-103-124.customers.d1-online.com) joined #forth
10:51:29 --- quit: gravicappa (Ping timeout: 240 seconds)
11:50:24 --- quit: xek (Remote host closed the connection)
11:51:01 --- join: xek (~xek@apn-31-0-23-82.dynamic.gprs.plus.pl) joined #forth
12:56:58 --- quit: dys (Read error: Connection reset by peer)
12:59:49 --- quit: KipIngram (Ping timeout: 240 seconds)
13:00:06 --- join: KipIngram (~kipingram@185.149.90.58) joined #forth
13:00:30 --- nick: KipIngram -> Guest8377
13:18:24 --- nick: Guest8377 -> KipIngram
13:18:32 --- mode: ChanServ set +v KipIngram
13:31:29 <crc> All that's left is the server part of the glossary tool. I've added an HTML export and refactored most of the other parts.
13:35:27 --- quit: xek (Remote host closed the connection)
13:54:12 --- join: dys (~dys@tmo-103-124.customers.d1-online.com) joined #forth
14:01:34 --- join: smokeink (~smokeink@185.189.254.154) joined #forth
16:05:50 --- quit: proteusguy (Ping timeout: 244 seconds)
16:06:27 --- quit: tabemann (Ping timeout: 250 seconds)
16:30:28 --- join: tabemann (~tabemann@rrcs-98-100-171-35.central.biz.rr.com) joined #forth
16:41:57 --- join: rdrop-exit (~markwilli@112.201.166.158) joined #forth
17:05:05 <tabemann> hey
17:05:08 <smokeink> hey
17:05:23 <zy]x[yz> hey
17:05:56 <smokeink> question: gforth can use $ to read hexnumbers from the input, spf uses 0x instead , is there an easy way to make gforth also understand the 0x syntax? or viceversa, to make spf understand $
17:06:30 <tabemann> the normal forth prefix is $
17:06:46 <tabemann> 0x is heresy that is the product of trying to pander to C programmers
17:07:02 <smokeink> right, it does sound like heresy
17:07:32 <zy]x[yz> radix prefix syntax is king
17:07:38 * tabemann remembers $ from 6502 assembly from back in his Apple //e days
17:07:38 <smokeink> so how to replace 0x with $ , is it difficult?
17:07:52 <tabemann> that's implementation dependent
17:07:56 <smokeink> is $ a normal word ?
17:08:06 <tabemann> in some forths $ is a normal mood
17:08:08 <smokeink> so that I can search for ": $" in the sourcecode?
17:08:11 <tabemann> in most it is a math prefix
17:08:16 <tabemann> *number prefix
17:08:41 <tabemann> you know this is all very dependent on the particular Forth
17:08:57 <tabemann> I cannot speak really for any Forth other than the ones I've coded
17:09:04 <smokeink> I understand yes
17:09:47 <tabemann> you might have to rewrite the math parsing routines, but it might not be able to patch them back onto the existing interpreter without metacompiling a whole new system
17:09:53 <tabemann> s/math/number
17:10:10 <tabemann> it all depends on how hard-coded things are
17:13:18 <tabemann> yes! fixed a stupid-ass bug
17:15:02 <Zarutian> tabemann: but $ is an sigil infront of variables to derefernce them!
17:15:36 <Zarutian> tabemann: so what do you think of 0o, 0q and 0b
17:16:22 <tabemann> if you're gonna use 0x, you should support 0o and 0b - never heard of 0q
17:16:34 <tabemann> Zarutian, lol
17:16:45 <Zarutian> you know for 0o666 in unix file permissions, 0q01332 in quads and such
17:16:58 <Zarutian> but I do support them
17:17:32 <tabemann> I've never used anywhere that used quad numbers
17:17:40 <tabemann> *seen anywhere
17:20:10 <Zarutian> me neither but hey I was adding 0x, 0o and 0b support so I threw 0q in too just for giggles
17:21:21 <Zarutian> the only use for them I can think of is direction encoding for 'needles' as used with GA144 arrays and such
17:31:26 <rdrop-exit> It's simpler to have prefixes such as $ be their own words then to complicate the interpreter, i.e.
17:32:12 <tabemann> I figured I might as well make them part of the numeric parser function because otherwise I'd have to add complexity to save and restore numeric bases and like anyways
17:32:26 <rdrop-exit> "$ f0f0" instead of "$f0f0"
17:32:53 <tabemann> I found the complexity increase of doing $f0f0 isn't much
17:33:14 <PoppaVic> rdrop-exit: immediates?
17:34:14 <rdrop-exit> Yes
17:34:36 <rdrop-exit> Every bit of added complexity counts
17:34:44 <PoppaVic> well, you could have them parse too, I suppose
17:35:20 <rdrop-exit> I don't have a BASE variable
17:35:32 <PoppaVic> yer not missing much.
17:35:59 <PoppaVic> I find BASE to be a pain in the dick. Too many screens/code change base and leave it
17:36:18 <rdrop-exit> It's unecessary state
17:37:17 <PoppaVic> I don't mind $A #10 %1010 - I just get tired of umpty spins on it.
17:37:54 <rdrop-exit> brb
17:41:09 <crc> I only have decimal in my system. Other bases are left up to the user.
17:42:50 <rdrop-exit> My interpreter uses decimal, I have a $ prefix word for hex, and % for binary.
17:43:52 <corecode> that's clever
17:43:57 <corecode> i like forth more and more :)
17:44:27 <rdrop-exit> Cool
17:45:13 <crc> I can't do prefix words like that in mine. I can add single character prefixes, though I use $ for characters.
17:46:16 <corecode> why can't you?
17:46:25 <crc> I've thought about adding a sample of extending the # prefix to support smalltalk style radix changes 
17:47:03 <rdrop-exit> Here's the source code for my $ prefix:
17:47:23 <crc> My system doesn't have a conventional parser. Each token is executed in isolation, with no way to wait for potential future tokens in an input stream. 
17:47:37 <rdrop-exit> : ($) ( <token> -- u ) token 16 unsigned ; compiled
17:47:37 <rdrop-exit> : $ ( <token> -- u ) ($) ; interpreted
17:47:37 <rdrop-exit> : $ { <token> -- } ( -- u ) ($)  & literal ; directive
17:47:40 <corecode> but that's half the forth
17:48:23 <crc> I've not missed it in the last 2-3 years since I started down this path
17:48:36 <corecode> ok
17:49:49 <crc> (my system is very much non-traditional though. It's closer to colorforth than conventional forths)
17:50:56 <smokeink> Can .\" be defined in terms of S\" ?
17:51:18 <rdrop-exit> Gforth? no idea
17:52:26 <smokeink> sp-forth , I'm using this http://www.forth200x.org/escaped-strings.html  but now I also need .\"
17:52:53 <rdrop-exit> I don't use escaped strings, can't help you there
17:53:01 <smokeink> : .\"   POSTPONE S\" TYPE ; IMMEDIATE     \ tried this but fails
17:53:56 <smokeink> it doesn't work when inside a definition of another word, it just works inside the repl
17:54:42 <rdrop-exit> bbiab
17:54:56 <crc> : .\" postpone s\" postpone type ; immediate   \ works in definition but not repl
17:55:46 <smokeink> crc: thanks, it works now
17:56:22 <crc> no problem
17:57:49 --- quit: X-Scale (Ping timeout: 240 seconds)
18:00:30 <smokeink> crc: oh, I didn't read that part of the comment  "but not in repl" :D
18:01:28 <crc> I'll see if I can fix that when I get home from this walk; hard to code on an ssh connection from my phone
18:01:42 <smokeink> I think there must be a way, to use a condition or something, so that it only postpones when it's inside the definition of a word
18:01:49 <smokeink> okay, I'll first try to fix it myself
18:04:48 --- quit: tabemann (Ping timeout: 240 seconds)
18:12:50 --- join: X-Scale (~ARM@46.50.0.93) joined #forth
18:17:30 <rdrop-exit> back
18:26:21 <crc> : .\" STATE @ IF POSTPONE S\" POSTPONE TYPE EXIT THEN ['] S\" EXECUTE TYPE ;  IMMEDIATE
18:27:05 <crc> This works in gforth 0.7.3 both in definitions or at the repl
18:32:10 <PoppaVic> ah, state-smart - the boogeyman of forth
18:33:37 <crc> I try to use them sparingly :)
18:35:22 --- nick: ynoom -> moony
18:35:41 <rdrop-exit> I don't have STATE, it's just bad factoring.
18:42:41 <crc> I've thought about eliminating it, but it's not a high priority for me
18:47:45 <rdrop-exit> I eliminated it 20 years ago.
18:56:10 <smokeink> crc: thanks!
18:57:53 <smokeink> what's bad about STATE ? 
18:58:18 <rdrop-exit> About 20 years ago there was a flurry of discussion on clf on how to deal cleanly with the issues surrounding cleanly with STATE, but the standard punted.
18:59:10 <PoppaVic> No one is supposed to test it or use it - they cry and scream and throw tantrums
19:00:04 <smokeink> then is there a way to redefine the above .\" without using STATE ?
19:00:35 <crc> smokeink: state smart words can lead to subtle, difficult to identify bugs
19:03:35 <rdrop-exit> smokeink: It depends on the Forth
19:05:29 <rdrop-exit> Basically state-smart words are a way to have a non-default combination of interpretation and compilation behaviors.
19:06:10 <rdrop-exit> On my Forth, when I deal with those types of words by factoring the two behaviors into two definitions.
19:06:39 --- join: tabemann (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth
19:06:51 <rdrop-exit> In your case:
19:07:33 <rdrop-exit> : .\" ... ; interpreted
19:07:45 <rdrop-exit> : .\" ... ; directive
19:10:48 <crc> cmforth had separate dictionaries for interpret and compile time
19:11:05 <rdrop-exit> The new standard uses a different approach, can't recall the details.
19:11:23 <crc> mpe's ndcs stuff?
19:11:43 <rdrop-exit> I don't think they've settled it yet.
19:12:53 <rdrop-exit> I looked into MPE's approach, didn't care for it.
19:13:29 <rdrop-exit> I wrote a reddit post on the approach I use. Just a sec...
19:13:51 --- quit: dave0 (Quit: dave's not here)
19:14:08 <rdrop-exit> https://www.reddit.com/r/Forth/comments/9izdtq/a_simple_approach_to_dual_words/
19:16:10 <crc> I remember seeing that
19:17:29 <rdrop-exit> I've since renamed COMPILE-ONLY to COMPILED, and INTERPRET-ONLY to INTERPRETED, but have made no changes to the fundamental approach.
19:18:25 <smokeink> ok, so to avoid STATE altogether the forth must have an alternative  mechanism . Does GForth have any alternative mechanism ? I see it doesn't recognize the words "interpreted" and "directive"
19:19:12 <rdrop-exit> I assume it does, although what the standard mechanism will be hasn't been settled yet.
19:20:12 <rdrop-exit> I'll download the Gforth manual
19:21:30 <crc> https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Combined-words.html
19:22:01 <rdrop-exit> There we go, thanks crc.
19:22:15 <crc> No problem 
19:24:17 <PoppaVic> heh.. rdrop-exit that post is cute.. Mind you, your naming-procedures are a bit skewed.. I like it, though
19:25:10 <rdrop-exit> Thanks PoppaVic
19:25:48 <PoppaVic> Thing is the idea of "normal".. The Compile/Interpret duality dates all the way back.
19:26:33 <PoppaVic> I tend to think we are looking at Macro vs ops - maybe vs the REPL/interp idea.
19:27:29 --- quit: darithorn (Ping timeout: 240 seconds)
19:30:48 <rdrop-exit> There's also inlining, which the standard doesn't really address.
19:31:02 <smokeink> https://el-tramo.be/blog/waforth/
19:31:13 <PoppaVic> I would think it's part of assembly, but that's me
19:32:33 <rdrop-exit> I like to be able to specify wether a definition should be called or inlined.
19:32:51 <PoppaVic> oh, you mean extracting relative code to replonk elsewhere
19:33:09 <rdrop-exit> yes
19:34:20 <rdrop-exit> e.g.
19:34:22 <rdrop-exit>  : off ( a -- )  0 \! ;inline
19:34:22 <rdrop-exit>  : on  ( a -- ) -1 \! ;inline
19:34:25 <PoppaVic> yeah, to me that smacks mostly of a MACRO or fetching something from a db
19:35:22 <rdrop-exit>  : here ( -- a ) dp @ ;inline
19:35:53 <rdrop-exit> etc...
19:38:52 <rdrop-exit> It's basically laying down the code rather than laying down a call to the code.
19:41:38 <rdrop-exit> bbiab
19:57:19 <rdrop-exit> back
20:00:43 <tabemann> back
20:00:53 <tabemann> hey guys
20:01:06 <rdrop-exit> Hi tabemann
20:01:17 <PoppaVic> wb
20:02:42 <tabemann> inlining would also require either relocating inline branches or forbidding branches in inlined code
20:04:00 <tabemann> mind you this is not necessary if you're inlining native code and it only uses relative branches
20:04:24 <rdrop-exit> You only inline code that makes sense to inline, that's the programmer's responsibility to be sure that's what he wants.
20:05:34 <rdrop-exit> e.g. return stack manipulations have a different effect in an inlined definition vs a called definition
20:06:48 <rdrop-exit> If you have to set out to write an inlinable definition.
20:07:57 <rdrop-exit> The mechanism for the actual inlining is trivial though.
20:08:21 <Zarutian> why inline? what is the gain?
20:09:14 <rdrop-exit> 3 possible benefits:
20:10:09 <rdrop-exit> 1) some things are simpler to code for inlining (e.g. avoid a lot of postponing).
20:11:02 <rdrop-exit> 2) size: in a subroutine threaded Forth the code itself may be shorter than a call to the code
20:11:30 <rdrop-exit> 3) speed: avoiding call overhead
20:12:07 <Zarutian> I am going to mull on 1) a bit but respond to 2) & 3)
20:12:55 <Zarutian> 2) are the callsites to words in subroutine threaded forths enormous in the ISAs you are targetting?
20:13:27 <rdrop-exit> Depends on the ISA
20:13:50 <rdrop-exit> BTW 2) also applies to token threaded Forths
20:14:45 <Zarutian> 3) call overheads indicate that direct static branching isnt cheap on the ISA which indicate that something went really wrong at the ISA design phase
20:16:39 <rdrop-exit> It's a tool in the toolkit, you use it when it benefits you. I don't see the issue.
20:18:36 <Zarutian> the issue is program memory bloating, which impacts often on i- and d-cache resedency which in turn turns something that might have been 15 cycle pipeline stall into 600 cycle dram fetch
20:20:35 <rdrop-exit> Like I said, you use it when it benefits you.
20:21:42 <crc> (3) is why I do a small amount of selective inlining. Inlining the primitives corresponding to single instructions and a few other specific words saves a little space, but reduces the call/return overhead significantly.
20:25:28 <rdrop-exit> Let's say you have a token-threaded forth, there's a CALL token, let's say 1 byte, followed by an inlined destination address, let's say 32-bits. In the ON example above -1 and \! are each single-byte tokens.
20:26:04 <rdrop-exit> Why bother calling ON (5 bytes) when you could just inline it (2 bytes).
20:27:00 <rdrop-exit> Faster and smaller.
20:28:52 <rdrop-exit> Any tool requires judicious application, Forth programmers are thinkers.
20:30:41 --- join: darithorn (~darithorn@75.174.238.174) joined #forth
20:39:03 <rdrop-exit> No one is advocating indiscriminate use.
20:44:47 <rdrop-exit> Here's an example of case #1, where inlining simplifies the definition:
20:45:19 <rdrop-exit> 0 shadow  Return Stack Miscellanea
20:45:19 <rdrop-exit> 1
20:45:19 <rdrop-exit> 2 supplant Push the cell at <a> onto the return stack and store
20:45:19 <rdrop-exit> 3          <x'> in its place.
20:45:19 <rdrop-exit> 4
20:45:22 <rdrop-exit> 5 revert   Pop a cell and store at address <a>.
20:45:24 <rdrop-exit> 6
20:45:46 --- quit: rdrop-exit (Quit: Lost terminal)
20:46:46 --- join: rdrop-exit (~markwilli@112.201.166.158) joined #forth
20:47:33 <rdrop-exit> 0 shadow  Return Stack Miscellanea
20:47:33 <rdrop-exit> 1
20:47:33 <rdrop-exit> 2 supplant Push the cell at <a> onto the return stack and store
20:47:33 <rdrop-exit> 3          <x'> in its place.
20:47:34 <rdrop-exit> 4
20:47:36 <rdrop-exit> 5 revert   Pop a cell and store at address <a>.
20:47:39 <rdrop-exit> 6
20:47:54 <rdrop-exit> 0 source  Return Stack Miscellanea
20:47:54 <rdrop-exit> 1
20:47:54 <rdrop-exit> 2 : supplant ( x' a -- )( r: -- x ) !@ push ;inline compiled
20:47:54 <rdrop-exit> 3
20:47:54 <rdrop-exit> 4 : revert ( a -- )( r: x -- ) pop \! ;inline compiled
20:47:57 <rdrop-exit> 5
20:50:44 <rdrop-exit> The above code manipulates the return stack, much simpler to just inline, than to write a call-able version that has to take the call's return stack usage into account.
20:51:55 <rdrop-exit> Note: the standard name for POP is R> and for PUSH is >R
20:52:14 <rdrop-exit> !@ is a memory exchange op
20:55:57 <rdrop-exit> IIRC some Forth's use the names BURY and EXHUME instead of SUPPLANT and REVERT
21:02:23 <rdrop-exit> It's use is to temporarily change the value of a global variable (e.g. BASE) and later restore it.
21:03:14 <rdrop-exit> e.g. 16 base supplant ... base revert ...
21:07:44 <crc> Base [ hex ... ] v:preserve 
21:07:54 <crc> (In mine)
21:10:18 <crc> I don't remember ever encountering BURY/EXHUME or SUPPLANT/REVERT
21:15:49 <rdrop-exit> I can't recall which Forth had BURY/EXHUME, I'll try to dig it up (no pun intended).
21:16:09 <tabemann> aw you should have intended that pun
21:16:15 <rdrop-exit> ;-)
21:19:59 --- join: gravicappa (~gravicapp@h109-187-28-67.dyn.bashtel.ru) joined #forth
21:21:10 <rdrop-exit> BURY/EXHUME is from Thinking Forth, they have the same purpose but work bifferently from SUPPLANT/REVERT
21:25:18 <crc> Thanks
21:26:49 <rdrop-exit> My pleasure
21:28:06 <rdrop-exit> I was lucky to find it, it first checked All About Forth and the HS/Forth manual, then something in the back of my head told me to check Brodie because of the colorful names.
21:29:23 <rdrop-exit> * "I" not "it"
21:38:25 --- quit: dddddd (Remote host closed the connection)
21:39:54 --- quit: darithorn (Quit: Leaving)
22:11:17 --- quit: rdrop-exit (Quit: Lost terminal)
22:24:53 --- join: proteusguy (~proteusgu@mx-ll-14.207.171-27.dynamic.3bb.co.th) joined #forth
22:24:53 --- mode: ChanServ set +v proteusguy
22:37:51 --- quit: pierpal (Quit: Poof)
22:38:09 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth
22:59:10 --- quit: pierpal (Ping timeout: 244 seconds)
23:53:48 --- quit: dys (Ping timeout: 240 seconds)
23:59:59 --- log: ended forth/19.01.23