00:00:00 --- log: started forth/18.09.23
01:23:00 --- quit: Keshl (Ping timeout: 252 seconds)
02:03:34 --- quit: ashirase (Ping timeout: 246 seconds)
02:09:29 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:15:26 --- join: dave9 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth
02:15:38 <dave9> hi
02:47:36 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth
02:47:36 --- quit: ncv (Changing host)
02:47:36 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
02:49:54 --- quit: ncv (Remote host closed the connection)
02:51:13 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
03:14:21 --- quit: ncv (Remote host closed the connection)
03:14:47 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth
03:14:47 --- quit: ncv (Changing host)
03:14:47 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
03:24:05 --- join: dys (~dys@tmo-120-127.customers.d1-online.com) joined #forth
03:25:09 --- quit: ncv (Remote host closed the connection)
03:25:32 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth
03:25:32 --- quit: ncv (Changing host)
03:25:32 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
03:31:22 --- quit: ncv (Remote host closed the connection)
03:33:16 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth
03:33:17 --- quit: ncv (Changing host)
03:33:17 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
04:23:19 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
05:14:19 --- quit: epony (Read error: Connection reset by peer)
05:39:40 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
05:47:23 <WilhelmVonWeiner> God bless Brad Rodriguez
06:04:56 --- join: epony (~epony@unaffiliated/epony) joined #forth
08:27:20 --- quit: Zarutian (Read error: Connection reset by peer)
08:28:48 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
09:30:52 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth
09:36:08 --- quit: dave9 (Quit: one love)
09:56:04 --- quit: ncv (Remote host closed the connection)
10:04:25 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth
10:17:57 --- quit: rdrop-exit (Quit: rdrop-exit)
12:13:26 --- join: lemonpepper24 (~lemonpepp@c-24-6-137-62.hsd1.ca.comcast.net) joined #forth
12:30:02 --- quit: lemonpepper24 (Ping timeout: 260 seconds)
14:24:12 --- join: wa5qjh (~quassel@175.158.225.222) joined #forth
14:24:13 --- quit: wa5qjh (Changing host)
14:24:13 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
14:25:34 --- quit: dne (Remote host closed the connection)
14:27:16 --- join: dne (~dne@jaune.mayonnaise.net) joined #forth
14:47:52 --- quit: tabemann (Ping timeout: 252 seconds)
14:57:37 --- quit: dys (Ping timeout: 260 seconds)
15:47:24 --- join: mark4 (~mark4@cpe-2606-A000-8096-FE00-5A94-6BFF-FEA6-29D4.dyn6.twc.com) joined #forth
16:01:36 --- join: tabemann (~travisb@rrcs-162-155-170-75.central.biz.rr.com) joined #forth
16:07:27 --- join: lemonpepper24 (~lemonpepp@c-24-6-137-62.hsd1.ca.comcast.net) joined #forth
16:17:11 <tabemann> yay! I now have working condition variables!
16:17:26 <mark4> condition variables?
16:17:32 <tabemann> yeah
16:17:39 <siraben> I have a working REPL with compilation!
16:17:45 <mark4> what are those?
16:17:53 <tabemann> tasks wait on them, and other tasks wake up the tasks waiting on them
16:17:55 <siraben> I can define "IF" and "THEN", with primitives like 0BRANCH and BRANCH
16:18:05 <tabemann> cool
16:18:23 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth
16:18:26 <PoppaVic> whee
16:18:32 <tabemann> the only thing is that I feel like I'm cheating with how I implemented compare-and-set
16:18:50 <tabemann> because I did not implement it with processor instructions dedicated to it
16:19:01 <mark4> siraben: https://github.com/mark4th/x4/blob/master/src/ext/loops.f  <-- like this?
16:19:04 <KipIngram> You mean you didn't use atomic operations?
16:19:17 <tabemann> but rather based upon that the execution of every single Forth word is atomic since all Forth tasks execute in the same OS thread
16:19:20 <KipIngram> I think if you don't use the underlying processor support for that it won't really be threrad safe,right?
16:19:31 <siraben> mark4: Similar
16:19:40 <siraben> mark4: https://github.com/siraben/ti84-forth
16:19:42 <siraben> Scroll down the README
16:19:44 <KipIngram> Oh, well, if they're all in one Forth thread then you ought to be ok, I think.
16:20:06 <siraben> It's based of jonesforth mostly, but different architecture
16:20:16 <tabemann> the only exception is that compare-and-set won't work with buffers written to by the IO manager
16:20:25 <tabemann> because the IO manager executes in a separate OS thread
16:20:47 <tabemann> I could make it lock the IO manager while doing CAS
16:20:48 <mark4> siraben: what processor is that for?
16:20:51 <siraben> Z80
16:20:57 <tabemann> but that would probably result in too much of a performance hit
16:20:57 <mark4> oooh wow
16:20:57 <siraben> TI-84 calculators
16:20:59 <mark4> ancient :)
16:21:10 <mark4> shud try 6502 :P
16:21:29 <tabemann> my Forth targets x86-64, x86, ARM, and ARM64 - lol
16:21:40 <tabemann> basically any "big" architecture
16:21:48 <siraben> I just have a Z80 computer (the calculator) lying around, so that's why.
16:21:55 <siraben> tabemann: How can it target so many?
16:22:20 <tabemann> siraben: because it is implemented in processor-agnostic C
16:22:35 <mark4> tabemann: from same sources?
16:22:42 <tabemann> yes
16:22:43 <siraben> tabemann: Is the implementation available?
16:22:46 <mark4> must be written in a high level language then
16:23:00 <tabemann> http://github/tabemann/attoforth
16:23:10 <mark4> im kind of diametrically opposed to forths written in ANYTHING other than forth/assembler lol
16:23:22 <siraben> tabemann: Lucky.  No compiler exists for the TI calculator.  I handwrote 1687 lines of ASM
16:23:29 <siraben> mark4: Why?
16:23:37 <siraben> A good compiler can go a long way.
16:23:48 <mark4> siraben: because C is horrendously inefficient even when optimized
16:24:09 <PoppaVic> since "assembler" is such a massive pain - with linkers and relocation and such - "assemblers" ain't what they wuz ;-)
16:24:27 <tabemann> my Forth is already a "slow" Forth because it does stack checks on ever operation - even though it should be able to comment out all the stack checks
16:24:38 <siraben> Oh, I should add that to mine.
16:24:48 <siraben> But anyways the programmer is responsible for stack checking :)
16:24:50 <KipIngram> "Typical" Forths check the stack after each *interpreted* word.
16:24:51 <PoppaVic> mark4: which is why you learn to torture the compiler to write naked C funcs and code inline asm therein ;-)
16:25:04 <mark4> PoppaVic: doing forth in assembler is ONLY a pain when said assembler is 3rd party
16:25:11 <mark4> if its built into the forth is ultra painless
16:25:15 <mark4> and simple
16:25:32 <mark4> and you have the3 entire forth programming language as an assembler macro facility
16:25:38 <KipIngram> Yes, I'll be really happy when I get mine to the point where it can rebuild itself.
16:25:44 <PoppaVic> mark4: lemme' put it this way: the days of our beloved z80/cp/m assemblers are gone. Fighting the tools is a pain in the pecker
16:26:01 <MrMobius> siraben, is there no decent Z80 C compiler?
16:26:09 <mark4> no. the gnu assembler is a pain in the pecker
16:26:16 <PoppaVic> amen to that
16:26:17 <mark4> pick an architecture
16:26:39 <mark4> writing a forth compiler INSIDE a forth compiler is trivial 
16:26:44 <mark4> well. if you have the assembler
16:26:56 <PoppaVic> I've also always just loved the gas penchant for screwing with the comment-symbol across platforms
16:27:01 <mark4> i dont have an x86 assembler for my compiler nor an arm one for the other version
16:27:05 <mark4> maybe never will
16:27:17 <mark4> use nasm for x4 and (ugh) as for the thumb2 version
16:27:18 <tabemann> that's kinda like how I implementered my interpreter in Forth itself
16:27:54 <tabemann> even though I also implemented a simpler interpreter in C, so I could compile much of the functionality of the Forth interpreter itself
16:29:02 <tabemann> (the simpler interpreter can only interpret code from a string; for interactive or from-file interpretation, the interpreter written in Forth is needed)
16:30:26 <siraben> MrMobius: For this calculator
16:31:00 <MrMobius> siraben, what do you mean? there is a decent z80 c compiler but not for this calculator?
16:31:01 <PoppaVic> happily, readline fetches 'strings' ;-P
16:31:10 <siraben> MrMobius: There's a Z80 compiler?
16:31:17 <MrMobius> siraben, no im asking
16:31:17 <siraben> Probably, yeah, the small device c compiler
16:31:17 <PoppaVic> what's a C compiler?
16:31:19 <PoppaVic> what
16:31:32 <siraben> MrMobius: I haven't managed to find one.
16:31:38 <PoppaVic> s a z80? ;-P
16:31:43 <tabemann> I haven't implemented readline yet, just refill
16:32:21 <tabemann> readline as in reading arbitrary lines from files
16:32:39 <PoppaVic> there's a bare-bones, cheapy, OSS version of "readline" called "linenoise" available, as well.
16:33:06 <PoppaVic> well, FILE is a "file"; stdin is a FILE.
16:33:17 <tabemann> I'm not using FILEs
16:33:20 <tabemann> I'm using fds
16:33:29 <PoppaVic> fdopen ;-)
16:34:03 <tabemann> I'm using system calls for IO, not C standard library functions
16:34:49 <tabemann> interpreting without a readline function works because I do have a buffering mechanism for interpreting
16:35:00 <tabemann> but otherwise file accesses are completely unbuffered
16:35:23 <tabemann> I plan on writing a buffered file layer on top of my lower-level IO manager though
16:37:20 <tabemann> I also at some point should fix my terminal input
16:37:57 <tabemann> and implement something that overrides the default terminal behavior
16:38:12 <tabemann> like when you enter something you get, e.g
16:38:20 <tabemann> : FOO ." foobar" ;
16:38:22 <tabemann>  ok
16:38:28 <tabemann> FOO
16:38:34 <tabemann> foobar ok
16:38:42 <tabemann> when it should really be
16:38:49 <tabemann> : FOO ." foobar" ; ok
16:39:04 <tabemann> FOOfoobar ok
16:39:47 <tabemann> extra nice would be to something like GNU readline implemented, but that's probably too much work
16:39:51 --- quit: siraben (Ping timeout: 252 seconds)
16:41:52 --- join: siraben (~user@unaffiliated/siraben) joined #forth
16:42:52 <siraben> What is meant by buffered input?
16:42:58 <siraben> Is mine buffered?  I'm reading a line into a memory location until [ENTER] pressed, then WORD calls get_char which just reads from this buffer
16:43:41 <PoppaVic> that's buffering
16:43:43 <siraben> If get_char returns 0 (indicating a NUL byte), WORD calls get_str again, so we can handle empty input by just asking the user until we get something
16:43:45 <siraben> I see.
16:44:12 <PoppaVic> Otherwise, you can REACT to some keystrokes - delete, next/last word, begin/end of line, insert, overwrite, etc
16:45:21 <siraben> The user can press CLEAR or DEL to clear or do a backspace, as long as they're in the get_str routine.
16:51:19 <zy]x[yz> buffer means you have more muscles than the next guy
16:57:12 --- quit: tabemann (Ping timeout: 260 seconds)
16:58:07 --- join: tabemann (~travisb@rrcs-162-155-170-75.central.biz.rr.com) joined #forth
17:06:54 <reepca> The closest thing (standard) forth seems to have to closures is CREATE - assign compile-time-constant code to run-time-varying data. But it really isn't suited for run-time closure creation - it's a parsing word, and you have to use nonstandard stuff like latestxt in order to even get the xt produced by it. It's also limited to dictionary allocation only. A word like CREATE that doesn't have those limitations would, I think, make it
17:06:54 <reepca> possible to implement locals-style closures in standard forth. And that sounds kind of neat at least.
17:07:30 <siraben> I see
17:11:02 --- quit: siraben (Quit: ERC (IRC client for Emacs 26.1))
17:21:19 <tabemann> yes!
17:21:49 <tabemann> I got my terminal input to work as I want
17:22:31 <pointfree> You could do closures, continuations with outer exits RDROP
17:23:38 --- part: PoppaVic left #forth
17:25:59 <tabemann> I have a stupid question
17:26:05 <tabemann> if you have something like:
17:26:06 <reepca> pointfree: could you give an example?
17:26:15 <tabemann> : FOOBAR ." foobar" ;
17:26:19 <tabemann> FOOBAR
17:26:23 <tabemann> should it come out as
17:26:26 <tabemann> FOOBARfoobarok
17:26:30 <tabemann> FOOBARfoobar ok
17:26:35 <tabemann> FOOBAR foobarok
17:26:36 <tabemann> or
17:26:39 <tabemann> FOOBAR foobar ok
18:12:23 --- quit: wa5qjh (Remote host closed the connection)
18:15:42 --- join: wa5qjh (~quassel@175.158.225.222) joined #forth
18:15:43 --- quit: wa5qjh (Changing host)
18:15:43 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
18:25:27 --- join: dave9 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth
18:25:37 <dave9> hi
18:41:02 <tabemann> hey
18:46:45 <mark4> tabemann: : foo ." foo" ;  foo foo 
18:47:47 <tabemann> so I'm correct in assuming that NL results in a space being echoed
18:48:36 * tabemann is happy that he got BASE properly implemented
18:49:11 <tabemann> now I just need to remember what prefixes are used for different bases generally
18:49:23 <tabemann> I know $ means hexadecimal (reminds me of my old Apple //e days)
18:49:32 <tabemann> but the others that gforth uses I don't remember
18:49:44 <tabemann> and the main source of gforth documentation seems to be down at the present
18:54:48 <reepca> tabemann: what do you mean? The source code is always available! /s
18:54:55 <reepca> # means decimal
18:55:04 <tabemann> lol
18:55:20 <mark4> for me $ is hex no prefix is decimal (OR THE CURRENT BASE) and / is octal
18:55:37 <mark4> 123  \ this is either decimal 123 or whatever 123 is in the current base
18:55:52 <mark4> $123  \ this is always HEX 123 no matter what the current base is
18:56:10 <mark4> %1010101 is binary of course
18:56:27 <mark4> you can look at the sources for the x4 number.f extension :)
18:56:36 <mark4> erm actually its in number.s in the kernel my bad
18:57:15 <reepca> also, in gforth 0x starts a hex number as well
18:59:28 <mark4> gforth is not forth :P
18:59:35 <mark4> and 0x is stupid 
18:59:50 <mark4> why use two characters to represent something that has traditionally been represented with ONE
18:59:56 <mark4> just because C does it that way
19:00:01 <tabemann> I personally like $
19:00:05 <mark4> assemblers have always used $ for hex
19:00:05 <dave9> i've also seen suffix "h" for hex  abcdh
19:00:20 <mark4> 123h  <-- sorry but H is not a hex number
19:00:28 <tabemann> suffix h makes me think of x86 asm
19:00:35 <tabemann> it's not to my taste though
19:00:36 <mark4> and its a postfix notation. you dont knonw what base its going to be till AFTER you have parsed it
19:00:38 <reepca> ¯\_(ツ)_/¯ anything to make the newbs feel more comfortable I guess
19:00:40 <mark4> bad in forth
19:00:55 <mark4> which is my major critisim of ANS forth
19:01:22 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth
19:01:37 <tabemann> ANS forth is the forth that tries to do everything
19:01:50 <tabemann> rather than the Forth you implemented yourself for some tiny system
19:02:08 <mark4> oh no! we cant use !>  (store to) because NOOBS cant read ! as "store" and > as "to". so lets be limp wristed and invent a new word called "TO" 
19:02:23 <mark4> ans forth tries to be all things to all people.
19:02:43 <mark4> noooo! we cant define NOT because there are TWO versions of it in the wild. one of them is stupidly broken, and the other one is correct!
19:02:57 <mark4> crap! if we define NOT one way or the other were going to break someones code! omg!
19:03:02 <mark4> lets invent INVERT !!!!!!
19:03:05 <mark4> idiots
19:03:07 <mark4> i hate ans forth
19:03:35 <mark4> the fig (79?) standard for NOT was identical to 0=. the 83 standard FIXED IT! to be a 1's complement
19:04:09 <tabemann> I don't mind POSTPONE though, because it handles both compiled and immediate words correctly in one word
19:04:32 <dave9> i dig how = means compare
19:04:46 --- quit: dddddd (Remote host closed the connection)
19:04:51 <mark4> postpone is another abomination.
19:05:05 <mark4> because morons cant figure out how either compile or [compile] work
19:05:25 <mark4> i also hate : fud postpone x postpone y postpone z ;
19:06:18 <rdrop-exit> Hi
19:06:28 <tabemann> I've got a number of functions in my bootstrapping code which are like POSTPONE POSTPONE POSTPONE
19:07:04 <tabemann> s/functions/words
19:07:11 <rdrop-exit> I abbreviate POSTPONE with &
19:07:36 <tabemann> GOOD IDEA
19:07:41 <rdrop-exit> : fud & x & y & z ;
19:07:48 <tabemann> whoops why did I write that in all caps
19:08:02 <tabemann> maybe because I've been writing in all caps all day long lol
19:08:34 <tabemann> (for some reason I decided to write my bootstrapping code in all caps even though it could be lowercase because it's all case-insensitive)
19:09:07 <rdrop-exit> I reserve all-caps for meta-compiler configuration constants
19:09:37 <rdrop-exit> buffer sizes and such
19:10:13 <rdrop-exit> … that can be changed before mata-compiling a system
19:10:37 <rdrop-exit> s/mata/meta/
19:11:32 <rdrop-exit> Haven’t finished morning coffee
19:12:24 <mark4> in x4 i have a macro colon definiton word 
19:12:29 <mark4> m: foo x y z ;m
19:12:42 <mark4> or better yet
19:12:48 <tabemann> I assume x4 is your Forth?
19:12:52 <mark4> m: foo 100 0 do ." foo" loop ;m
19:13:06 <mark4> : bar 100 0 do  foo loop ;
19:13:08 <mark4> yes x4 is mine
19:13:29 <mark4> with the postpone method you cant do loops, you cant do strings
19:13:51 <mark4> in the above code the definiton for bar will be : bar 100 0 do 100 0 do ." foo" loop loop ;
19:14:11 <tabemann> with postpone what I've done is
19:14:24 <tabemann> compile the address and length of strings into the code
19:14:42 <tabemann> with POSTPONE (LITERAL) , POSTPONE (LITERAL) ,
19:14:57 <tabemann> I can get away with it since my Forth is an indirect threaded one
19:16:26 <tabemann> and compiling in loops I use POSTPONE BRANCH , and POSTPONE ?BRANCH , for
19:18:24 <mark4> learn how "compile" and "[compile]" work
19:18:39 <mark4> your basically using postpone as a replacement for compile
19:19:21 <mark4> : if xxxx xxxx compile ?branch xxx xxx xxx ;  fill in the blanks
19:19:51 <mark4> compile takes the next execution token out of the execution steam as a literal and compiles it
19:20:33 <rdrop-exit> Need more coffee, brb
19:22:45 <reepca> mark4: I take it m: is based on EVALUATE? Couldn't that cause issues in the event of name collisions?
19:23:03 <mark4> [compile] on the other hand compiles the next token out of the INPUT stream (usually an immediate)
19:23:06 <mark4> i dont use evaluate
19:23:16 <mark4> i dont have "something to evaluate" evaluate
19:23:22 <rdrop-exit> Me neither
19:24:02 <mark4> https://github.com/mark4th/x4/tree/master/src/ext/macros
19:25:03 <tabemann> I've played around with EVALUATE to make sure that executing from a string worked properly
19:25:10 <tabemann> but aside from that I haven't really used it
19:26:03 <tabemann> this was before I implemented INCLUDE and INCLUDED
19:27:31 <rdrop-exit> I use blocks
19:29:50 <tabemann> considering that my Forth runs on Linux, blocks seem superfluous because they'd ultimately be stored in files yet would be harder to use than plain files
19:30:11 <mark4> blocks WERE simpler to begin with
19:30:30 <tabemann> (well, it should be portable to xBSD, macOS, and Cygwin)
19:30:37 <mark4> but most forths these days run on top of operating systems that have file operations built in
19:30:51 <rdrop-exit> My host Forth runs on POSIX, blocks are just 1k chunks of memory
19:31:19 <tabemann> blocks make sense when you have no operating system and are literally just addressing row blocks of disk storage
19:31:21 <mark4> rdrop-exit: thats the traditional way of doing things because one sector of a floppy disk was 1k
19:31:54 <rdrop-exit> My blocks are just part of the host Forth’s memory
19:32:20 <tabemann> I can see blocks being used in a modern context in the forms of blocks of flash memory though
19:32:29 <tabemann> on embedded systems
19:34:05 <tabemann> okay, I'm gonna head out; will be back on later
19:36:42 <mark4> tabemann: chuck moore also uses blocks as a way of doing structures
19:38:34 <rdrop-exit> : block ( blk# -- a ) k STORAGE + ;inline
19:39:09 --- quit: tabemann (Ping timeout: 252 seconds)
19:40:56 <rdrop-exit> STORAGE is just a meta-compiler configuration constant that holds the start address of blocks within the host Forth’s binary.
19:47:08 <rdrop-exit> brb
19:51:44 <rdrop-exit> I haven’t chatted on IRC in about 30 years, figuring out how this client works
19:54:24 <mark4> heh
19:54:29 <mark4> which client?
19:54:37 <rdrop-exit> Colloquy
19:54:37 <mark4> rdrop-exit: where are you located?
19:54:42 <rdrop-exit> Manila
19:54:47 <mark4> aha
19:55:14 <mark4> glad you found my little channel :)
19:55:28 <rdrop-exit> Cool, thanks :)
19:56:46 <mark4> well. i dont actually claim any ownership over it tho i did start it :P
19:56:52 <mark4> it belongs to the idlers in here
19:57:19 <rdrop-exit> Nice
19:57:25 <mark4> can you have a > in your name?
19:57:31 <mark4> r>drop-exit
20:01:31 <rdrop-exit> It’s the user name I use on reddit. In my Forth I named the primitive for  ‘r> drop’ as ‘rdrop’, and the primitive for ‘rdrop exit’ is actually named ‘bail’
20:01:58 <mark4> oh nice name!
20:02:08 <rdrop-exit> thanks :)
20:02:13 <mark4> i have some non standard defintions in x4 too
20:02:22 <mark4> like "either" and "neither"
20:02:40 <mark4> x y z either - return true if z is equal to either x or y
20:02:56 <mark4> x y z neither - return true if z is equal to neither x or y
20:03:02 <rdrop-exit> Nice
20:03:18 <mark4> and ?:  <-- my personal favorite
20:03:34 <mark4>  blah blah ?: xxx yyy blah blah
20:03:48 <mark4> at ?: if top of stack is true xxx is executed and yyy is skipped
20:03:54 <mark4> else xxx is skipped and yyy is executed
20:04:10 <mark4> more efficient than if xxx else yyy then
20:04:15 <mark4> both for execution speed and space
20:05:23 <rdrop-exit> I only use ‘else’ once in my codebase, I’m going to revisit that word and see if I can refactor to eliminate the ‘else’.
20:06:00 <mark4> ive also been known to do funky things like "begin while until else then" loops lol
20:06:20 <mark4> think of it as a "begin IF until else then; 
20:06:23 <rdrop-exit> Here’s a fun one:
20:06:26 <rdrop-exit> : cancel ( x1 x2 -- x1|0 ) over <> and ;inline
20:06:51 <rdrop-exit> Cancel (zero) on equal, return zero if <x2> equals <x1>, otherwise return <x1>.
20:07:13 <mark4> thats <> but different!
20:08:00 <mark4> instead of false or true it returns 0 or x1
20:08:35 <rdrop-exit> right, I use it to cancel exceptions
20:09:23 <rdrop-exit> that’s one of the uses, would have to check my codebase to refresh my memory on others
20:10:06 <mark4> ooh yea. i have variable and constant which perform as you would expect. but i HATE the ans word "value" and never use that word name because numbers have a value, addresses have a value the 0 value foo does not express that foo is a variable.
20:10:12 <mark4> so i called it far
20:10:13 <mark4> var
20:10:16 <mark4> i have var and const
20:10:21 <mark4> 0 var foo  ; like value
20:10:39 <mark4> 0 const foo ; when you reference the foo constant it compiles an inline literal or returns its value
20:10:56 <mark4> so const creates a state smart immediate word lol
20:11:03 <mark4> 123 const foo
20:11:07 <mark4> foo is immediate and state smart
20:11:50 <mark4> so : blah xxx xxx foo xxx xxx ; compiles a (lit) 123
20:12:11 <mark4> lol foo is an immediate state smart COMPILING word lol
20:12:39 <mark4> i think the way my var and const words work is how variable and constant SHOULD have worked from day 1
20:12:51 <rdrop-exit> That’s what my constants do, they compile inline literals.
20:13:28 <mark4> well constant and variable in x4 are traditional. x4 is direct threaded, not native
20:13:47 <mark4> t4 (the thub 2 version) is sub threaded
20:13:59 <mark4> but neither of them do ANY code optimizations
20:14:10 <mark4> 1:1 co-relation between source and object
20:14:17 <mark4> guaranteed
20:14:42 <rdrop-exit> My host Forth is token-threaded (bytecoded) so it’s similar to a native code compiler in many ways.
20:15:37 <mark4> is it open source?
20:16:04 <rdrop-exit> Not yet, some day
20:16:13 <mark4> token threading is more space efficient but not as speed efficient?
20:16:24 <mark4> tho on modern hardware neither is much of an issue lol
20:16:35 <mark4> unless you coding embedded
20:17:06 <dave9> mark4: what cpu is your t4 subroutine threaded forth?
20:17:07 <mark4> but these days armv8 with a full blown OS is considered embedded 
20:17:16 <mark4> arm v7a
20:17:34 <mark4> x4 stands for x86 forth. t4 stands for thumb2 forth
20:17:40 <mark4> i have x64 and t64 planned
20:17:46 <dave9> ah
20:17:51 <mark4> and im working on n4 (native ndk)
20:18:00 <mark4> n4 is indirect threaded and not thumb2
20:18:02 <rdrop-exit> The speed of the host Forth doesn’t really matter much, it’s just used as a development environment for umbilical cross-compilation.
20:18:11 <mark4> tho im considering converting it from arm to thumb2
20:18:19 <mark4> ya
20:18:29 <mark4> which target?
20:19:00 <mark4> im not sure if i ever released my avr assembler
20:19:18 <mark4> i think it will work for just bout any avr device except the tiny's
20:20:04 --- join: tabemann (~travisb@2602:30a:c0d3:1890:ccf2:f6ec:5a58:6b88) joined #forth
20:20:07 <mark4> yea, not relased
20:22:07 <rdrop-exit> PIC32 will be the initial target for the new version
20:22:39 <mark4> pic32 is mips
20:23:12 <mark4> not a fan of pic but not had any exposure to pic32
20:23:20 <mark4> mips is nice tho, better than arm imho
20:24:40 <mark4> i was very depressed when microchip finally managed to purchase atmel :(
20:24:44 <mark4> now they own avr.
20:25:06 <mark4> i think the pic controllers are some of the most unadulterated garbage ever produced
20:25:16 <mark4> other than pic32 which i never touched
20:25:33 <mark4> but pic16 and pic24 are utter GARBAGE
20:25:41 <mark4>  xxxxx xxx
20:25:46 <rdrop-exit> lol
20:25:55 <mark4>   xxxxx   ; put a breakpoint here
20:25:57 <mark4>   xxx
20:26:02 <mark4>   xxx ; stop here
20:26:25 <mark4> which is why asm coders on pics use what they call a skid bucket
20:26:33 <mark4>  xxx   ; put a breakpoint here
20:26:38 <mark4>  nop
20:26:49 <mark4>   nop  ; come to a screeching halt here
20:27:02 <mark4> so you inject your code with skid buckets all over the palce to test and debugg
20:27:11 <mark4> and when you remove them your code is no longer tested
20:27:24 <rdrop-exit> brb need more coffee
20:27:31 <mark4> or you leave them in and waste countless clock cycles and memory
20:28:21 <tabemann> why would you use PIC if you had a choice in the matter (PIC32 aside)?
20:28:29 <mark4> rdrop-exit: i usually make a pot of cofffee and put it in my HUGE thrumos flask. does not cook on the burner all day. stays hot and i can keep it with me where ever i am :)
20:28:44 <tabemann> are they that much cheaper than AVR or ARM or like that the cost difference alone justifies them?
20:28:48 <mark4> pic controllers are MAJORY cheap
20:28:54 <mark4> BOM costs are lower
20:29:02 <mark4> yes
20:29:23 <mark4> also microchip goes above and beyond the call of duty with supporting their product
20:29:44 <mark4> including sending support right out to your shop to help you fix what ever it was that was broken
20:29:53 <mark4> if you are a big enough customer 
20:30:07 <mark4> but try getting intel to send someone out to help you debug your code lol
20:30:08 <mark4> or arm
20:30:10 <rdrop-exit> I’m an espresso drinker, making a new cup is a whole ritual
20:30:20 <mark4> aha
20:30:30 <mark4> well espresso is good
20:30:41 <mark4> have you ever looked into roasting your own coffee beans?
20:30:59 <mark4> literally roast only enough for one week and do NOT grind it till you are about to use it
20:31:36 <mark4> coffee is stale (lost 90% of its flavors) 2 weeks after roasting and FIVE MINUTES after grinding
20:32:10 <tabemann> so literally all of us are drinking stale coffee then
20:32:23 <tabemann> because literally how many of us are roasting our own coffee
20:32:41 <tabemann> even if we may grind it before we use it
20:33:20 <rdrop-exit> Torrefaction? No I just grind.
20:34:23 <mark4> i have not roasted in a while because ive been broke and my coffee roaster also literally broke lol
20:34:28 <mark4> wore it out after years of use
20:35:00 <mark4> so i just use store bought coffee (whole bean) but its no where near as good
20:35:05 <mark4> its good just not AS good
20:35:22 <mark4> you cant pay me to drink *$ coffee
20:35:25 <rdrop-exit> I get beans from the local Italian importer
20:35:43 <mark4> does HE roast them?
20:35:49 <mark4> or buy them roasted in bulk
20:36:46 <rdrop-exit> No, I get bags of Lavazza Oro. My favorite brand is Cafe Mauro but nobody imports it here.
20:38:50 <rdrop-exit> Which is too bad since Mauro is cheaper.
20:40:54 <mark4> do a goole search for "burman coffee"
20:41:03 <rdrop-exit> ok
20:41:40 <mark4> he travels the world to visit coffee plantations and buys 100% of the crop from good growrs. 
20:42:06 <rdrop-exit> I’ll check out his youtube channel later
20:42:14 <mark4> so a small family in some 3rd world country who is growing coffee instead of cocain gets to support his family
20:42:23 <mark4> he has a youtube channel?
20:42:25 <mark4> lol
20:42:31 <mark4> i didnt know
20:42:41 <mark4> not bought beans from him in ages
20:42:56 <rdrop-exit> Dogs are bugging me for a walk, I’ll catch you all later. Keep on Forthin’
20:43:49 <mark4> i had a gene cafe till i wore it out lol
20:44:05 <tabemann> I know you don't like POSTPONE, but I'm going to stick with it because it will allow me to write code that essentially does inlining without having to go back and change each COMPILE to [COMPILE]
20:45:26 <tabemann> and from reading the Forth 2012 draft standard, this kind of thing is why they removed COMPILE and deprecated [COMPILE]
20:47:01 * tabemann did create : & POSTPONE POSTPONE ; IMMEDIATE though, because he had too many sequences of POSTPONE x POSTPONE y POSTPONE z in his doe
20:52:22 <mark4> well compile is the same as postpone SORT OF
20:52:47 <mark4> [compile] is different, but postpone does the job of both
20:55:45 --- quit: dave9 (Quit: one love)
20:55:52 <tabemann> COMPILE compiles code to compile an xt into a word, while [COMPILE] compiles an xt into the current word being compiled, from what I gather
20:57:02 <tabemann> like : ENDIF POSTPONE THEN ; IMMEDIATE is equivalent to : ENDIF [COMPILE] THEN ; IMMEDIATE
20:57:43 <tabemann> because THEN is an immediate word
21:07:44 <mark4> yes postpone does the job of compile AND [compile] 
21:07:58 <mark4> the theory is with postpone YOU dont need to know what words are and are not immediate
21:08:10 <mark4> its an attempt to make code portable
21:08:18 <mark4> portable code is a *****MYTH****
21:08:26 <mark4> it has NEVER existed in ANY language
21:09:02 <MrMobius> mark4, ???
21:09:25 <mark4> what if IF/ELSE and THEN are not imediate
21:09:33 <mark4> what if they ARE?
21:09:41 <mark4> with postpone you dont need to know
21:09:55 <mark4> your code will work on a forth where they are immediate and where they are not
21:10:16 <mark4> but postpone is horrendously complicated compared to compile and [compile]
21:11:40 <mark4> : [compile] ' , ;  immediate
21:11:48 <mark4> and compile is not much more complicated
21:12:17 <mark4> they are TRIVIAL. and not broken
21:12:24 <mark4> no need to fix them with "postpone"
21:13:19 <tabemann> : COMPILE ' LITERAL [COMPILE] , ; IMMEDIATE
21:13:47 <tabemann> is that right?
21:13:54 <mark4> not quite but close
21:14:15 <mark4> : compile ['] literal , ; 
21:14:19 <mark4> no need to bbe immediate
21:14:31 <mark4> i think thats right, x4's definition is slihtly different
21:14:52 <tabemann> that can't be right
21:15:04 <tabemann> because ['] literal compiles to literal's xt
21:15:22 <mark4> i have a word called param that fetches the next xt
21:15:31 <mark4> so : compile param , ;
21:15:54 <mark4> param fetches the next xt from the execution stream as a literal
21:16:24 <mark4> erm yea (lit) maybe
21:16:44 <tabemann> and it has to be immediate, or otherwise you'd be fetching the xt *at the time the code calling compile would execute, not at the time that compile was fed into the interpreter*
21:17:05 <mark4> [compile] has to be immediate
21:17:09 <mark4> compile does not
21:17:19 <mark4> : foo compile bar ;  compiles to 
21:17:20 <mark4> foo:
21:17:25 <mark4>   .int compile
21:17:30 <mark4>  .int bar
21:17:36 <mark4>  .int exit
21:17:42 <mark4> or some such
21:17:47 <reepca> ah, your version of compile takes an inline argument?
21:18:02 <mark4> no. not at compile time, at RUN time
21:18:22 <mark4> compile fetches the xt of bar and then the comma commas it
21:18:30 <mark4> erm i forgot the .int comma
21:18:47 <mark4> erm no the comma is inside compile sorry im tired lol
21:18:56 <mark4> : foo compile bar ;
21:19:13 <mark4> this literally just compiles two xt's the xt for compile and the xt for bar
21:19:22 <mark4> at run time COMPILE fetches the xt for bar and commas it
21:19:44 <mark4> : compile ' , ; immediate
21:19:51 <mark4> : [compile] param , ;
21:20:08 <mark4> erm no blagh the other way round lol. told you im tired lol
21:20:20 <mark4> : compile param , ;
21:20:32 <mark4> : [compile] ' , ;
21:20:44 <mark4> the tick makes [compile] a parsing word
21:20:59 <mark4> compile takes an xt out of the EXECUTION stream at run time and compiles it
21:21:16 <mark4> [compile] takes a token out of the INPUT stream at compile time and compiles it
21:22:49 <reepca> technically, isn't the next thing in the execution stream at the time the PARAM in COMPILE is run always ,? I take it PARAM looks one "level" higher than the current definition or something like that, so that it can be used inside colon definitions?
21:24:33 <rdrop-exit> hi
21:25:12 <mark4> param:
21:25:18 <mark4>  push ebx  ; cached top of stack
21:25:33 <mark4>  mov ebx, [ebp]  ; top item of return stack
21:25:56 <mark4>  add dword [ebp], byte 4 '; advance return address past literal
21:26:13 <mark4>  mov ebx, dword [ebx] ; fetch the item to be compiled
21:26:16 <mark4>  next
21:27:23 <mark4> the item on the retun stack points to the item we are compiling,
21:44:53 <rdrop-exit> Compatibility means deliberately repeating other people's mistakes. -- David J. Wheeler aphorism
22:30:24 --- quit: lemonpepper24 (Ping timeout: 245 seconds)
23:00:00 --- join: dys (~dys@tmo-113-41.customers.d1-online.com) joined #forth
23:50:10 --- quit: jedb (Ping timeout: 252 seconds)
23:59:54 --- join: mtsd (~mtsd@77.110.61.100) joined #forth
23:59:59 --- log: ended forth/18.09.23