00:00:00 --- log: started forth/19.06.21
00:22:54 --- quit: proteusguy (Remote host closed the connection)
00:31:53 --- join: proteusguy (~proteusgu@cm-58-10-208-178.revip7.asianet.co.th) joined #forth
00:31:54 --- mode: ChanServ set +v proteusguy
00:46:14 --- quit: reepca (Ping timeout: 245 seconds)
03:24:49 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:43:54 --- quit: proteusguy (Remote host closed the connection)
04:53:39 --- join: proteusguy (~proteusgu@cm-58-10-208-178.revip7.asianet.co.th) joined #forth
04:53:39 --- mode: ChanServ set +v proteusguy
06:51:08 --- quit: deesix (Ping timeout: 246 seconds)
06:51:27 --- quit: dddddd (Ping timeout: 258 seconds)
07:10:08 --- quit: irsol (Remote host closed the connection)
07:11:59 --- join: irsol (~irsol@unaffiliated/contempt) joined #forth
07:16:39 --- quit: jedb (Ping timeout: 245 seconds)
07:18:54 --- join: jedb (~jedb@103.254.153.113) joined #forth
07:30:06 --- quit: tabemann (Ping timeout: 252 seconds)
08:02:44 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
08:13:24 --- quit: irsol (Remote host closed the connection)
08:31:20 --- join: irsol (~irsol@unaffiliated/contempt) joined #forth
09:12:11 --- join: reepca (~user@208.89.170.37) joined #forth
11:37:26 --- join: sarna (~sarna@d146-51.icpnet.pl) joined #forth
11:38:05 <sarna> hi, I have a question, I couldn't find the answer anywhere on the web - does Forth have UB like C and C++?
11:43:12 <zy]x[yz> c and c++ have UB because they are standards
11:43:15 <zy]x[yz> forth isn't a standard
11:43:35 <zy]x[yz> and is an ANS forth standard, but nobody likes it
11:44:09 <zy]x[yz> instead, you should think of forth more as a model to DIY
11:44:22 <zy]x[yz> in which case, you can have as much or as little UB as you want
11:44:59 <zy]x[yz> s/and is an/there is an/
11:50:44 <WilhelmVonWeiner> sarna: refer to your Forth's documentation
12:00:15 <CORDIC> sarna: Would Your dialect of Forth have UB?  
12:03:15 <sarna> thanks zy]x[yz 
12:03:36 <sarna> WilhelmVonWeiner: yeah I tried searching it, but found nothing
12:04:23 <sarna> CORDIC: fully mine - wouldn't :^)
12:04:26 <WilhelmVonWeiner> what kind of UB are you worried about?
12:04:40 <sarna> every kind
12:04:48 <sarna> since on UB compiler can do *anything*
12:04:53 <sarna> and that scares me :^)
12:04:55 <WilhelmVonWeiner> Forth is so simple it's pretty hard to have a behaviour that's poorly defined
12:05:37 <WilhelmVonWeiner> of course, between Forths implementing a standard complicitly
12:06:21 <WilhelmVonWeiner> I guess I can see it happening...
12:06:42 <sarna> also, I guess Forths that compile to C have UB to some degree by extension?
12:06:59 <WilhelmVonWeiner> There are Forths that compile to C?
12:08:01 --- quit: dave0 (Quit: dave's not here)
12:18:19 <sarna> doesn't gforth do that? I saw some paper titled "generating optimized C code from Forth" or something like that
12:18:24 <sarna> let me find it
12:22:55 --- quit: gravicappa (Ping timeout: 245 seconds)
12:23:38 <sarna> "Translating Forth to Efficient C"
12:23:45 <sarna> http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Performance.html
12:23:48 <sarna> at the bottom of this page
12:25:11 <WilhelmVonWeiner> why is it a fucking postscript file
12:25:18 <WilhelmVonWeiner> what is it with gforth and being annoying
12:26:07 <WilhelmVonWeiner> I don't think that's actually an implementation of a Forth->C compiler though, Gforth is an implementation of Forth
12:26:23 <reepca> WilhelmVonWeiner: http://www.complang.tuwien.ac.at/anton/why-not-pdf.html
12:27:34 --- join: gravicappa (~gravicapp@h83-174-248-9.dyn.bashtel.ru) joined #forth
12:28:07 <WilhelmVonWeiner> could've been anything from text to djvu but whatever
12:29:25 <sarna> WilhelmVonWeiner: and Forth compiles straight to machine code?
12:30:06 <reepca> sarna: some do, many just thread primitives implemented in assembly or C though.
12:30:42 <WilhelmVonWeiner> sarna: Forth is usually implemented as an interpreter similar to Python or LISP
12:31:29 <WilhelmVonWeiner> So when you run Forth, it's running a little virtual machine
12:31:39 <sarna> reepca: sorry, but what does "threading" mean?
12:32:08 <WilhelmVonWeiner> sarna: https://www.bradrodriguez.com/papers/moving1.htm
12:32:10 <sarna> WilhelmVonWeiner: oh, I see
12:32:50 <sarna> thanks! I'll read that :^)
12:35:51 <reepca> in short, instead of a dispatch loop (fetch instruction, execute, repeat), each "instruction" (primitive) dispatches the next instruction. So once the first primitive is invoked, it will invoke the next one, which will invoke the next one, and so on. Because of this, the code ends up looking like just an array of addresses.
12:37:16 <sarna> oh, that's super neat
12:37:33 <WilhelmVonWeiner> reepca: what a nive description
12:37:38 <WilhelmVonWeiner> s/nive/nice
12:38:19 --- quit: gravicappa (Ping timeout: 245 seconds)
12:38:59 <reepca> I guess it's probably not technically much easier than subroutine-threaded (which is basically native code but the only instructions you actually compile are "call" and "return"), but it can be very compact.
12:42:00 <sarna> which Forth would would you recommend for learning? I've been using SwiftForth, but I've heard good things about Retro (it's kind of custom though)
12:42:34 <WilhelmVonWeiner> I love Retro
12:42:54 <WilhelmVonWeiner> but it isn't the fastest (though for most things that's irrelevant) and it's very non-confomring
12:43:01 <WilhelmVonWeiner> it's so unique in a good way
12:43:15 <sarna> is VFX the fastest?
12:43:24 <WilhelmVonWeiner> No idea, it's proprietary.
12:43:43 <WilhelmVonWeiner> Lina Forth is quite good and all assembler so notably fast
12:43:48 <WilhelmVonWeiner> brb
12:44:01 <zy]x[yz> WilhelmVonWeiner> what is it with gforth and being annoying
12:44:08 <zy]x[yz> s/gforth/gnu/
12:44:43 <sarna> thanks, I'll check out Lina
12:45:35 <reepca> if you want a system that tries to be a model for the standard and is free software, gforth would be a good fit. It's not very minimalist compared to other systems, though.
12:50:52 <sarna> yeah, I've seen code in it and uh.. I don't recognize many of the words
12:51:44 <sarna> by the way, don't you have problems with all words being in the global scope? especially when it's encouraged for them to be short
13:07:30 <WilhelmVonWeiner> no
13:07:40 <WilhelmVonWeiner> never once have I had that issue
13:07:49 <WilhelmVonWeiner> never have I once had that issue*
13:09:33 <sarna> do you use any prefixes though?
13:12:10 <WilhelmVonWeiner> what, in retro?
13:12:25 <WilhelmVonWeiner> or regular Forth?
13:13:54 <sarna> regular Forth
13:14:23 <WilhelmVonWeiner> you mean prefixes just like `complex:+` to help with reading? I do that sometimes
13:14:26 <sarna> like, you know, C programmers with nameofthelibrary_nameofthefunction
13:14:38 <sarna> I see
13:15:11 <WilhelmVonWeiner> you can always just overwrite existing words that you're done using
13:15:37 <john_cephalopoda> In retro, libraryname:wordname is often used.
13:16:00 <sarna> well yeah :^)
13:17:23 <sarna> last question for now - is there something like switch/case in Forth?
13:17:33 <WilhelmVonWeiner> there is CASE
13:17:49 <WilhelmVonWeiner> but personally it's anti-Forth and you should learn about rdrop
13:18:27 <sarna> oh okay, thank you :^)
13:18:45 <WilhelmVonWeiner> http://forth-standard.org/standard/core/CASE
13:21:05 <sarna> where can I find rdrop?
13:22:33 <WilhelmVonWeiner> if you're very new to Forth
13:22:50 <WilhelmVonWeiner> check out Forth, Inc's "Starting Forth"
13:23:01 <sarna> I'm reading it :)
13:23:06 <WilhelmVonWeiner> oh good
13:23:50 <sarna> is rdrop one of these return stack words?
13:23:59 <john_cephalopoda> sarna: "rdrop" is a command that throws away the top element of the return stack. You can do some fun stuff with it. I like to avoid it because it forces you to keep track of where the return stack is pointing.
13:24:07 <WilhelmVonWeiner> sarna: yep
13:24:18 <john_cephalopoda> But WilhelmVonWeiner loves that word and uses it everywhere :þ
13:24:22 <WilhelmVonWeiner> mastering rdrop is the first step to mastering your control flow
13:24:40 <sarna> ah, I see :^)
13:24:52 <WilhelmVonWeiner> leave everything to DO..LOOP and CASE..ENDCASE and it's unnecessary complexity
13:25:32 <sarna> john_cephalopoda: do you prefer CASE in these situations or something else?
13:25:48 <WilhelmVonWeiner> if you're losing track of your return stack, you might be doing the complicated, inelegant solution.
13:26:33 <sarna> true, getting something elegant is hard though
13:27:08 <WilhelmVonWeiner> it's why you avoid the bollocks and KISS
13:27:53 <john_cephalopoda> WilhelmVonWeiner: When I use the return stack for program flow, I am doing a complicated, inelegant solution ;þ
13:28:34 <john_cephalopoda> sarna: I usually use "dup 0 = if <do something> then" "dup 1 = if <do something else>" ... "drop".
13:29:14 <sarna> john_cephalopoda: I see :^)
13:29:28 <WilhelmVonWeiner> ANS style gets you IF .. IF .. IF .. IF .. THEN THEN THEN THEN... but that's just my opinion
13:29:50 <sarna> yeah I was scared by all these THENs
13:31:29 --- nick: CORDIC -> DKordic
13:55:16 <WilhelmVonWeiner> yeah don't be afraid to just define words and rdrop out
13:55:47 <WilhelmVonWeiner> way more undrstandable than so many THENs
14:17:55 <john_cephalopoda> WilhelmVonWeiner: Nested IFs are a different thing. When "case" is applicable, you usually got a bunch of mutually exclusive options, so IFs replacing them wouldn't have to be nested.
14:19:28 <john_cephalopoda> "#12 [ 'Test s:put ] case" is equivalent to "dup #12 eq? [ 'Test s:put ] if drop".
14:22:15 <reepca> With that approach you end up incurring the full cost of checking every single case every time. Checking if it's equal to 12, figuring out that it is, and then going on to check whether it's equal to several other values is a bit wasteful.
14:23:35 <reepca> (though if we were concerned about the algorithmic characteristics of our selection, we'd probably be using some sort of jump table instead of a linear search for the matching case)
14:26:33 <WilhelmVonWeiner> Retro's case is completely different to ANS CASE
14:27:58 <reepca> personally I think that there are several cases (heh) where CASE is a perfectly fine solution, though they mostly come up when interfacing with other people's code (usually C libraries)
14:28:14 <WilhelmVonWeiner> dup #12 = [ 'Test s:put ] if; is simpler though
14:28:57 <WilhelmVonWeiner> `dup #12 eq? [ 'test s:put ] if;` even.
14:30:30 <reepca> the main issue I have with it is that it's complicated to implement it both correctly and portably. There's just not much that's guaranteed about the control stack by the standard.
14:30:34 <WilhelmVonWeiner> simpler source-
14:30:54 <WilhelmVonWeiner> *source-wise (i.e., with the underlying retro implementation)
14:32:16 <WilhelmVonWeiner> guess you have to drop too but *shrug* point made
14:40:30 --- join: dys (~dys@tmo-103-50.customers.d1-online.com) joined #forth
14:53:03 <john_cephalopoda> reepca: If I go through very large case or if-else constructs a lot of times, then a jump table or a different approach might be better.
15:22:14 --- quit: sarna (Ping timeout: 248 seconds)
16:32:53 --- quit: john_cephalopoda (Ping timeout: 250 seconds)
16:37:35 <tp> what a interesting discussion! I thought I'd add that as a technician and not a real programmer, I use  IF .. IF .. IF .. IF .. THEN THEN THEN THEN and CASE all the time. I don't care if it's wasteful, all I care about is that the real time limits for my hardware design are met and the code is easy for me to implement and maintain
16:39:36 <tp> Im a Forth user, and have no desire to ever write my own forth, which is why I'm ok at writing documentation such as my mecrisp unofficial doc site: https://mecrisp-stellaris-folkdoc.sourceforge.io/index.html
16:41:03 --- join: deesix (~dddddd@unaffiliated/dddddd) joined #forth
16:46:22 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:42:06 --- join: rdrop-exit (~markwilli@112.201.174.189) joined #forth
18:07:55 --- quit: dzho (Ping timeout: 245 seconds)
18:23:48 --- join: dzho (~dzho@unaffiliated/dzho) joined #forth
19:42:04 --- join: tabemann (~tabemann@2600:1700:7990:24e0:a8c3:b476:359:e7d9) joined #forth
20:46:47 --- join: tpbsd (~Terry@mecrisp/staff/tp) joined #forth
20:46:56 --- quit: tp (Remote host closed the connection)
20:52:05 --- join: gravicappa (~gravicapp@h83-174-248-9.dyn.bashtel.ru) joined #forth
20:56:14 --- quit: gravicappa (Ping timeout: 245 seconds)
21:21:45 --- quit: dddddd (Remote host closed the connection)
21:31:24 --- quit: dys (Read error: Connection reset by peer)
21:36:09 --- join: dys (~dys@tmo-103-50.customers.d1-online.com) joined #forth
21:48:48 --- join: `presiden (~presiden@unaffiliated/matematikaadit) joined #forth
22:14:37 <proteusguy> tp +1 (although I think the syntax is horrid - your desire to represent it in a manner that best matches your mental model over the cpu's efficiency is correct)
22:15:45 --- quit: proteusguy (Remote host closed the connection)
22:18:17 <tabemann> back
22:18:36 * tabemann just got backtraces working in hashforth!
22:19:19 <`presiden> https://prog21.dadgum.com/32.html
22:20:26 <`presiden> nice idea
22:20:39 <rdrop-exit>  : k ( #k -- #bytes ) %k lshift ;inline
22:21:02 <`presiden> what %k does?
22:21:34 <rdrop-exit> It's the binary logarithm of 1024, i.e. 10
22:21:38 --- quit: reepca (Remote host closed the connection)
22:22:00 --- join: reepca (~user@208.89.170.37) joined #forth
22:24:45 <rdrop-exit> 10  constant %k
22:25:23 <rdrop-exit> or if you prefer...
22:25:32 <rdrop-exit> 1024 log2  constant %k
22:29:38 --- join: proteusguy (~proteusgu@cm-58-10-208-178.revip7.asianet.co.th) joined #forth
22:29:38 --- mode: ChanServ set +v proteusguy
22:30:25 --- quit: proteusguy (Remote host closed the connection)
22:31:03 <rdrop-exit>  : u/k   ( u -- u' ) %k   rshift ;inline
22:31:16 <rdrop-exit>  : /k ( n -- n' ) %k arshift ;inline
22:33:31 <rdrop-exit> I use %foo to denote a binary logarithm,
22:33:41 <rdrop-exit> and foo% to denote a bit mask
22:38:53 <rdrop-exit>  : top? ( a -- -1|0 ) row% reset? ;inline
22:39:03 <rdrop-exit>  : bottom? ( a -- -1|0 ) row% set? ;inline
22:40:03 <rdrop-exit>  : top ( a -- a' ) ~row% and ;inline
22:40:11 <rdrop-exit>  : bottom ( a -- a' ) row% or ;inline
22:42:43 <rdrop-exit> etc...
22:48:10 * tabemann finally fixed the bug that was causing unexpected exits when combining heavy output loads with significant multitasking cycling
22:48:20 <tabemann> and now I have backtraces to work with!
22:48:40 <rdrop-exit> What was the cause of the bug?
22:49:23 <tabemann> it was a stupid bug - I was forgetting to pop a placeholder value off the stack when write() was encountering an EWOULDBLOCK/EAGAIN condition
22:50:18 <rdrop-exit> Ah
22:51:24 <tabemann> and now I can finally test what effect the load example I wrote has on the Life simulation run side-by-side with it
22:51:37 <rdrop-exit> Cool
22:51:43 <tabemann> now that it won't cause hashforth to fall over
23:51:46 <DKordic> `presiden: : B  allocate throw ;  : Ki  10 << ;  ' noop Alias B#
23:59:59 --- log: ended forth/19.06.21