00:00:00 --- log: started forth/18.10.29
01:27:24 --- quit: dys (Ping timeout: 272 seconds)
01:35:21 --- quit: pierpal (Ping timeout: 246 seconds)
01:39:42 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
01:42:57 --- join: xek (~xek@apn-37-248-138-80.dynamic.gprs.plus.pl) joined #forth
01:48:03 --- quit: pierpal (Quit: Poof)
01:48:24 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
01:55:23 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth
01:55:23 --- quit: ncv (Changing host)
01:55:23 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
01:56:43 --- quit: pierpal (Read error: Connection reset by peer)
02:02:17 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
02:07:04 --- quit: smokeink (Remote host closed the connection)
02:08:52 --- join: smokeink (~smokeink@118.131.144.142) joined #forth
02:17:47 --- quit: dave0 (Quit: dave's not here)
02:37:59 --- quit: nighty- (Quit: Disappears in a puff of smoke)
03:23:48 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth
03:41:42 --- quit: proteusguy (Remote host closed the connection)
03:42:22 --- quit: wa5qjh (Remote host closed the connection)
03:53:32 --- quit: pierpal (Read error: Connection reset by peer)
03:53:48 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
04:01:23 <KipIngram> Morning gents.
05:24:57 --- quit: clog (^C)
05:24:57 --- log: stopped forth/18.10.29
05:25:08 --- log: started forth/18.10.29
05:25:08 --- join: clog (~nef@bespin.org) joined #forth
05:25:08 --- topic: 'Forth Programming | logged by clog at http://bit.ly/91toWN | If you have two (or more) stacks and speak RPN then you're welcome here! | https://github.com/mark4th'
05:25:08 --- topic: set by proteusguy!~proteus-g@cm-134-196-84-89.revip18.asianet.co.th on [Sun Mar 18 08:48:16 2018]
05:25:08 --- names: list (clog WilhelmVonWeiner pierpal nighty- smokeink ncv xek tabemann jn__ MrMobius proteus-guy Zarutian nerfur jedb NB0X-Matt-CA rdrop-exit Labu dne Lord_Nightmare catern +KipIngram APic irsol phadthai a3f_ X-Scale ttmrichter malyn dave9 cheater Keshl johnnymacs sigjuice pointfree groovy2shoes ecraven FatalNIX zy]x[yz bluekelp rpcope lonjil moony carc pointfree[m] djinni siraben ovf vxe mstevens jackdaniel koisoke bb010g jimt[m] dzho diginet2 rain2 newcup +crc)
05:25:08 --- names: list (jhei rann amuck C-Keen rprimus yunfan)
05:25:36 <KipIngram> Ok.  For either of us if the jump back is happening at the end we could just use the name itself; tail optimizaiton will make it into a jump.
05:25:56 <KipIngram> : foo ... : bar ... bar ;
05:26:20 <KipIngram> But I like ME/RECUR because you can use it anywhere in the definition.
05:26:24 <rdrop-exit> I wanted to keep the old version of foo callable from a new version
05:26:38 <KipIngram> I found myself putting it in conditionals a good bit, but then I made conditional versions of ME.
05:26:46 <KipIngram> 0<ME etc.
05:28:07 <rdrop-exit> That's why I didn't use Chuck's approach
05:30:43 <KipIngram> Why exactly?  I lost the thread.
05:30:48 <KipIngram> The extra fetch cost?
05:31:07 <rdrop-exit> I'll restate
05:31:39 <rdrop-exit> The reason I didn't use Chuck's : foo ... foo ; approach is that
05:32:00 <rdrop-exit> I wanted to be able to call the previous version of foo if any
05:32:07 <KipIngram> Ah.
05:32:09 <KipIngram> Yes.
05:32:50 <KipIngram> I decided I valued the recursion more, but now that I have ME it may be a non-issue.
05:33:53 <rdrop-exit> BTW if you're wondering the code I posted is from my host TTC forth, the reason the BRANCH looks strange
05:34:25 <rdrop-exit> is it's getting the address from the stack rather then inlined.
05:38:24 <rdrop-exit> My host TTC forth is has a simplisitc VM processor, all addresses are literals.
05:39:49 <KipIngram> Interesting.
05:39:57 <KipIngram> I thought your code looked fine.  :-)
05:40:03 <rdrop-exit> (rather than being immediate data in the branch instructions)
05:40:39 <rdrop-exit> Simplifies many things, but there's a performance cost of course
05:41:36 <rdrop-exit> But the host Forth is just an IDE for talking to targets, so performance is not an issue.
05:42:46 <rdrop-exit> Another simplification is that backward branching in loops is done from the return stack.
05:45:02 --- quit: pierpal (Read error: Connection reset by peer)
05:46:22 <rdrop-exit> i.e. BEGIN pushes an address, AGAIN non-destructively uses it to jump back to the beginning of the loop.
05:47:17 <rdrop-exit> All looping operators work this way on the TTC Forth
05:48:05 <KipIngram> Yes, I've thought about that.
05:48:12 <KipIngram> That's what I thought of using the word "mark" for.
05:48:21 <KipIngram> push an address, then return to it later.
05:49:16 <rdrop-exit> It's an interesting tradeoff,
05:49:45 <rdrop-exit> saves dictionary space, but uses an extra cell on the return stack at runtime
05:50:04 <KipIngram> How does it save space?
05:50:11 <KipIngram> You have a cell to mark and a cell to jump.
05:50:15 <KipIngram> Instead of two cells to jump.
05:51:04 <rdrop-exit> There's no cell to mark
05:51:09 <KipIngram> BEGIN usually doesn't put anything in the dictionary.
05:51:24 <KipIngram> How does that address get onto the return stack?
05:52:13 <rdrop-exit> BEGIN compiles a VM bytecode that pushes the ip onto the return stack.
05:52:55 <rdrop-exit> AGAIN compiles a VM bytecode that uses jumps the address that's on the return stack.
05:53:11 <WilhelmVonWeiner> Structured Query Language (SQL) is a strange thing to Forth
05:53:11 <WilhelmVonWeiner> programmers, since it is neither structured, nor confined to queries, nor a
05:53:12 <WilhelmVonWeiner> language in the Turing sense of the word.
05:53:22 <WilhelmVonWeiner> Sorry, that was supposed to paste as one line.
05:53:40 <WilhelmVonWeiner> Just a funny quote from a paper I'm reading
05:54:34 <rdrop-exit> This apprach is useful in token-threaded Forths because all instructions are one byte, so addresses are long compared to the instructions.
05:55:57 <rdrop-exit> Did I explain that understandably?
05:56:50 <KipIngram> rdrop-exit: But in my system BEGIN would put nothing in the dictionary.
05:56:51 <rdrop-exit> I think I'm getting dyslexic in my old age
05:56:58 <KipIngram> Then AGAIN compiles a jump and an offset.
05:57:08 <KipIngram> Looks to me like you've just moved one of those cells up to BEGIN.
05:57:17 <KipIngram> Though if your bytecodes are really  BYTES then  you'll still save some space.
05:58:13 <KipIngram> You did explain well.
05:58:29 <KipIngram> In my system, which uses full cells instead of byte codes, the dictionary space would be the same.
05:58:48 <KipIngram> I have nothing at begin, but jump, offset at AGAIN.
05:58:55 <KipIngram> The other way I'd have a cell at begin and a cell at again.
05:58:57 <rdrop-exit> Yes, laying down addresses is costly compared to bytecodes, plus its faster.
05:59:22 <KipIngram> Yes, I see that it would be advantageous in a byte-code system.
06:01:09 <rdrop-exit> The savings are better with loops that start conditionaly, since a single byte code can also check the condition and skip the loop or enter the loop.
06:02:12 <rdrop-exit> My TTC system is 64-bit BTW.
06:03:46 <rdrop-exit> Basically the dictionary the layed down bytecodes would look like this for a ?DO loop.
06:05:09 <rdrop-exit> <lit><addr><(?do)>......<loop>
06:05:24 <rdrop-exit> correction
06:05:50 <rdrop-exit> <lit><addr><(?do)>....<(loop)>
06:06:47 <rdrop-exit> let me check something
06:06:59 <rdrop-exit> Sorry another correction
06:07:20 <KipIngram> :-)  No worries.
06:07:33 <rdrop-exit> <ipr8><offset><(?do)>....<(loop)>
06:07:43 <rdrop-exit> IIRC that's it
06:08:49 <rdrop-exit> those are all single bytes, including the offset
06:10:01 <rdrop-exit> the offset points to after the loop
06:11:21 <rdrop-exit> ipr8 is a bytecode, it stands for instruction pointer relative 8 bits
06:11:41 <rdrop-exit> its stack picture is ipr8 ( -- addr )
06:12:47 <rdrop-exit> it reads the one byte offset adds it to the address in the ip and pushes the address onto the data stack
06:14:06 <KipIngram> Yeah, byte code can be super compact.
06:14:08 <KipIngram> Nothing better.
06:16:06 <rdrop-exit> I mostly just stick to the two extremes of the threaded code spectrum, subroutine threading with inlining, and bytecode threaded.
06:17:08 <rdrop-exit> What I like about them is that they're actually very similar despite being on opposite ends of the spectrum.
06:18:08 <KipIngram> I've always been an indirect threaded guy.
06:18:21 <rdrop-exit> I was for a long time too.
06:19:46 <KipIngram> How do you compile your word calls when you're byte coding?
06:19:55 <KipIngram> Just a "call byte" followed by the address?
06:21:04 <rdrop-exit> That's the normal way, but I now use a less efficient way
06:21:28 <rdrop-exit> <lit><addr><execute>
06:21:46 <KipIngram> Ah, I see.
06:22:31 <rdrop-exit> It's less efficient but it creates simplification opportunities elsewhere
06:25:03 <rdrop-exit> I have mutiple literal bytecodes: lit8 lit16 lit32 lit64, ~lit8, ~lit16, ~lit32, ipr8
06:25:37 <rdrop-exit> LITERAL is smart enough to laydown the most space efficient one
06:26:20 <rdrop-exit> I even have nibble literals, 0 through f, -1, mnn, mpn
06:28:44 <rdrop-exit> I don't want to lay down 64 bits if 8,16, or 32 will do
06:29:28 <KipIngram> Yes, I have 32-bit and 64-bit literal primitives.
06:29:47 <rdrop-exit> mnn is most negative number, i.e. $ 800 ... 000
06:29:48 <KipIngram> The compiler checks the number being compiled to see if it can use the 32-bit one; if not it falls back to 64-bit.
06:30:11 <rdrop-exit> mpn is most positive number, i.e. $ 7f ... fff
06:30:21 <KipIngram> But my dictionary internals are 32 bits, and I want to stay 32-bit aligned, so there's no reason to go below 32.
06:30:30 <rdrop-exit> right
06:30:30 <KipIngram> And when I compile a string, I 32-bit align afterwards.
06:31:04 <rdrop-exit> you could add a ~lit32 to you system
06:31:28 <rdrop-exit> ain addition to your lit32
06:31:41 <KipIngram> Ah, yes, that would extend the 32-bit range a bit.
06:31:51 <KipIngram> But I figure how often am I going to use numbers in that range?
06:32:06 <rdrop-exit> negative numbers
06:32:10 <KipIngram> Probably not enough times to pay for the extra primitive space.  :-)
06:33:06 <KipIngram> Well, my 32-bit literal now will cover -80000000 through 7fffffff.
06:33:16 <KipIngram> With two literals I'd get everything from -ffffffff to ffffffff.
06:33:26 <KipIngram> So it would only be numbers in the latter but not the former that would call for it.
06:33:38 <KipIngram> MOST literals I use are small integers anyway.
06:34:02 <rdrop-exit> right
06:34:06 <KipIngram> But you seem to share a trait with me - once I've set out to optimize something, I often tend to want to *fully* optimize it.
06:34:11 <KipIngram> Just as a matter of principle.
06:34:26 <KipIngram> In this case I let pragmatism rule, but I don't always.
06:35:13 <KipIngram> Like my number converter.
06:35:25 <KipIngram> I could have had a fair bit less code if I'd been willing to accept some bogus strings.
06:35:45 <KipIngram> Like --17 or extra radix specifiers like 16:16:ffe7.
06:35:58 <KipIngram> But I just decided I wanted to make it exactly correct.
06:36:12 <KipIngram> A simpler one would parse --17 as positive 17.
06:36:39 <KipIngram> As far as I know it's 100% rigorous in rejecting numbers that don't adhere in any way to my "spec."
06:36:44 <rdrop-exit> My outer interpreter just does 64-bit decimals, signed and unsigned.
06:37:13 <rdrop-exit> Binary and Hex are taken care of by prefix words $ for hex, % for binary
06:37:20 <KipIngram> I can do signed integers in any radix, 2-62, and they'll be compiled as 32 bits if possible, 64 bits if necessary.
06:37:35 <KipIngram> And floating point numbers too - they're compiled in IEEE 64-bit format.
06:37:45 <KipIngram> And they land on the FPU stack, not the Forth stack.
06:38:35 <rdrop-exit> I don't need floats, and I don't need doubles on a 64-bit system
06:39:31 <KipIngram> Right - I didn't implement doubles.
06:39:47 <KipIngram> Of course, now I'm looking at porting to a Cortex M4 that's 32 bits.
06:39:54 <KipIngram> So I may decide I want doubles there.
06:39:54 <rdrop-exit> Although internaly my */mod and u*/mod use a 128-bit internal intermediary
06:40:10 <KipIngram> And if I write them, then I may bring them into the 64-bit system too, just for the heck of it.
06:40:12 <rdrop-exit> Right, targets are a different story
06:40:31 <KipIngram> But I definitely wanted floats - I've done a lot of numerical work over the years, and want to be able to do that with this.
06:40:57 <KipIngram> Yes, my u/mod does as well (haven't written */mod yet).
06:41:02 <KipIngram> All in registers, though.
06:42:38 <rdrop-exit> BTW, are you a block-man or a file-man? :)
06:43:04 <KipIngram> Blocks.  Though this time I'm contemplating a very thin file system overlay.
06:43:14 <KipIngram> But built on blocks - not something that connects to the OS file system.
06:43:28 <rdrop-exit> I'm also blocks
06:43:41 <KipIngram> Basically just a simple way to name blocks (name -> number) and an ability to link multiple blocks into a chain against that name.
06:43:58 <KipIngram> Still just thinking about that - I've never done it before.  Not sure yet.
06:44:34 <rdrop-exit> You can always define a constant to give a block number a name
06:44:42 <KipIngram> That old book of Chucks (https://colorforth.github.io/POL.htm) introduced a method for disk-based association of values with names.
06:44:48 <KipIngram> I think it was the forerunner of modern vocabularies.
06:44:54 <KipIngram> But it has some interest to me in its own right.
06:45:12 <rdrop-exit> It's been a long time since I read it
06:45:40 <KipIngram> It has a number of "interesting" ideas in it.
06:45:51 <KipIngram> Some of which I'm sure I don't want to do, but interesting anyway.
06:46:06 <rdrop-exit> His approach was more text macro oriented at the beginning
06:46:08 <KipIngram> He's got an idea in there for, upon failure to find a word in the dictionary, to drop the last character and try again.
06:46:19 <KipIngram> Iteratively.
06:46:30 <rdrop-exit> Have you looked at tforth on the Canon Cat?
06:46:32 <KipIngram> If you eventually find a word, it can then use the full name as "data."
06:46:39 <KipIngram> I don't think I want to do that, but it's still intriguing.
06:46:48 <KipIngram> No, I haven't seen that one.
06:47:25 <rdrop-exit> It has some interesting concepts too, when you redefine it overwrites the old definition.
06:47:54 <KipIngram> Right.  I can do that easily in my system.  At least operationally - I don't really have any plans for re-using the old memory.
06:48:21 <KipIngram> But since I have the CFA/PFA stuff separate from the definition, I can just point the PFA pointer at a new definition, and it will become the definition for that word.  Everywhere.
06:48:25 <rdrop-exit> Vocuabularies entries are kept in ascii order, find uses binary search.
06:48:44 <KipIngram> Oh, Chuck very firmly advocates definition order.
06:48:51 <KipIngram> And searching from the end backward.
06:50:16 <rdrop-exit> Yes, but if redefining a word changes the original, then definition order isn't as important.
06:50:26 --- quit: xek (Remote host closed the connection)
06:50:43 <zy]x[yz> that's very tcl-esque
06:50:46 <zy]x[yz> I don't like it
06:50:52 --- join: xek (~xek@apn-37-248-138-80.dynamic.gprs.plus.pl) joined #forth
06:51:35 <rdrop-exit> I don't care for it either, but it's interesting to see the ripple effects of different design decisions
06:53:37 <rdrop-exit> I think that's why many people get confused by Chuck, he tries different things and follows the ripple effects to see where they take him
06:54:40 <rdrop-exit> a small change can move the whole structure in a new direction
06:56:00 <rdrop-exit> as he did with cmForth, Ok, colorForth, etc...
06:56:12 <rdrop-exit> Not to mention the chips
06:57:01 <KipIngram> Yes, he's an explorer.
06:57:09 <rdrop-exit> I always find his explorations interesting
06:57:25 <KipIngram> Me too - always the possibility of new ideas that I like.
06:58:08 <rdrop-exit> BTW, have you ever read the book, Interpretation and Instruction Path Coprocessing?
06:58:55 <rdrop-exit> Fascinating book
07:00:14 <rdrop-exit> It's an anlysis of the different type of threaded code, and the design
07:00:49 <rdrop-exit> of coprocessor chips to accelerate threaded code interpretation
07:08:42 <Zarutian> rdrop-exit: Now I am curious, how can one accelerate threaded code interpretation?
07:12:45 <rdrop-exit> By putting a coprocessor chip onn the instruction path prefetching and decoding the treaded code
07:13:36 <rdrop-exit> Gotta go, my better half just arrived
07:13:45 --- quit: rdrop-exit (Quit: Lost terminal)
07:26:43 <KipIngram> No, haven't read that book.
07:27:17 <KipIngram> That sounds like the "fetch unit" in my FPGA Forth processor thinking.
07:27:42 <KipIngram> It's main purpose was to wind down through the call hierarchy and keep a fifo loaded with opcodes for the execution unit to process.
07:27:56 <KipIngram> I'd never thought of making that a separate unit that sat outboard of a traditional processor - interesting idea.
07:29:13 --- quit: tabemann (Ping timeout: 252 seconds)
07:37:48 --- join: proteusguy (~proteus-g@cm-134-196-84-17.revip18.asianet.co.th) joined #forth
07:37:48 --- mode: ChanServ set +v proteusguy
07:41:03 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
07:47:49 --- quit: smokeink (Remote host closed the connection)
08:16:47 --- quit: bb010g (Ping timeout: 250 seconds)
08:17:04 --- quit: carc (Ping timeout: 252 seconds)
08:18:45 --- join: carc (~carc@unaffiliated/carc) joined #forth
08:19:37 --- join: bb010g (bb010gmatr@gateway/shell/matrix.org/x-vdfwvjmfebqrlxtw) joined #forth
11:11:13 <WilhelmVonWeiner> You think Forth can be accurately described as a data-oriented language?
11:13:51 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
11:13:57 <john_cephalopoda> Hey
11:58:47 <WilhelmVonWeiner> john_cephalopoda: Hello
12:02:10 --- quit: Keshl (Quit: Konversation terminated!)
12:13:12 --- join: dys (~dys@tmo-101-161.customers.d1-online.com) joined #forth
12:33:11 <KipIngram> Hi John.
12:33:38 <KipIngram> I'm not sure what criteria they'd use to declare a language "data oriented."
12:33:44 <KipIngram> I mean, it can manipulate data...
12:37:18 --- quit: Labu (Quit: WeeChat 2.0.1)
12:46:36 <Zarutian> hmm.. I would say Hypercard is more data oriented than code oriented
12:46:58 <Zarutian> Hypercard on classic MacOS 9.0 and earlier btw
13:07:07 --- join: Labu (~Labu@labu.pck.nerim.net) joined #forth
13:16:50 <KipIngram> I remember that, but I never sussed out what to do with it.
13:17:52 <Zarutian> well, basically think of them as computerized flashcards, but with internal hyperlinks and programability.
13:18:03 --- quit: ncv (Remote host closed the connection)
13:18:44 <Zarutian> saw an example where someone had made a contact info carddeck, basically a personal phonebook in a way
13:19:27 <Zarutian> another use I saw it used was a slidedeck, way before there was anything called MicroSoft PowerPoint
13:21:17 <Zarutian> heck I saw a use where the slidedeck had multiple choice quizes and if you got wrong answer it linked you back to the slide that talked about the concept, often with additional info underlined
13:22:16 <KipIngram> Yeah, I've seen things like that.
13:22:18 <Zarutian> hell, Myst was pretty much all hypercard
13:22:50 <KipIngram> First place I ever saw that idea used, though, was in the library at the university my dad taught at.  In an algebra book.
13:23:21 <KipIngram> Book would ask question - you'd answer.  Based on your "incorrectness" it would send you to the section of the book that talked about that.
13:23:29 <Zarutian> I saw recently-ish (only two or so years ago) a tool that took in a native hypercard file and emitted html5 page that behaved exactly the same.
13:24:17 <Zarutian> yeah, nowdays I think Brilliant.com does that
13:33:22 <WilhelmVonWeiner> does ALLOT guarantee a bunch of zeroes or should I ERASE just to be sure
13:35:10 <Zarutian> iirc ALLOT just increases the HERE pointer iirc
13:35:16 <WilhelmVonWeiner> ...definitely the latter.
13:36:06 <WilhelmVonWeiner> 1760 characters of garbage just popped into my screen
14:00:09 <KipIngram> Yes, ALLOT just moves the pointer.
14:01:16 <KipIngram> 22 80-char lines?
14:02:56 <WilhelmVonWeiner> yup
14:03:16 <WilhelmVonWeiner> does the standard provide a way to TICK but for a number
14:04:29 <Zarutian> WilhelmVonWeiner: ,
14:05:29 <KipIngram> What would that do?  Numbers aren't in the dictionary.
14:05:43 <KipIngram> so there's nothing to "point at."
14:06:19 <Zarutian> I mean literally the word ,
14:06:31 <WilhelmVonWeiner> that would just place it in the dictionary
14:07:02 <KipIngram> What are you wanting to do with it?
14:07:02 <WilhelmVonWeiner> was just wondering if parsing ahead for a number had ever been needed
14:07:25 <KipIngram> BL WORD NUMBER or something to that effect?
14:07:27 <WilhelmVonWeiner> I wouldn't have a use for it personally
14:07:55 <KipIngram> Ah, yes - that works in mine.
14:08:48 <KipIngram> Oh, wait.
14:08:51 <KipIngram> Not sure if it did or not.
14:08:53 <WilhelmVonWeiner> surprised TICK doesn't in ANS
14:09:29 <WilhelmVonWeiner> since the interpreter checks if your word is a number before giving you an error
14:09:45 <WilhelmVonWeiner> surprised a tick doesn't do the same
14:13:38 <KipIngram> ok, BL WORD NUMBER seems to do the trick.
14:14:15 <KipIngram> Though I have a tendency to depart here and there from the standard.
14:20:58 <Zarutian> the ANS standard is more of a guideline, methinks
14:23:27 <KipIngram> :-)  That's definitely how I treat it.
14:34:39 <john_cephalopoda> Reminds me: Is there some way to go through memory in 8 bit steps? It is kinda cumbersome to have a S" String" in memory and walking through it in steps of several bytes, extracting the characters with shift magic.
14:35:48 <WilhelmVonWeiner> You mean like C!/C@ ?
14:37:14 <john_cephalopoda> Thanks, didn't find that one before.
14:37:30 <WilhelmVonWeiner> no problem bud
14:37:59 <john_cephalopoda> Here's some Conway's Game of Life in Forth: https://gist.github.com/jmf/d48272fb188c7dfea3947004ee95ddf2
14:40:00 <WilhelmVonWeiner> awesome i'll run it later and play with your code
14:41:13 <WilhelmVonWeiner> You have a lot of repeated code like `TO_INDEX CELLS NEWGRID + !` which could just be a word `TO-GRID` or something
14:43:15 <WilhelmVonWeiner> and `POINTER_Y @ 1 - 20 MOD POINTER_Y !` could be `20 WORD-NAME` and `WORD-NAME` can be `POINTER_Y @ 1 - SWAP MOD POINTER_Y !` if my eyes don't decieve me
14:43:29 <WilhelmVonWeiner> but that's just Forthy code deduplication
14:44:29 <WilhelmVonWeiner> and those VARIABLE KEY_x could be defined as CONSTANTS to save you accessing memory
14:44:33 <john_cephalopoda> That TO_INDEX CELLS NEWGRID + ! is basically drawing a glider "by hand", not really an integral part of the code.
14:46:30 --- quit: xek (Ping timeout: 244 seconds)
14:46:51 <john_cephalopoda> I tried to minimize the code as much as possible before. It can get very small and obfuscated. All in all I prefer to write stuff out instead of using some magic word that is defined somewhere.
14:48:23 <john_cephalopoda> Also setting KEY_x to CONSTANT would be difficult because I use them throughout the code but only set them at the start of the program. So I'd have to let the user define them and then start defining all the words that depend on them.
14:48:49 <WilhelmVonWeiner> oh right sorry
14:48:57 <WilhelmVonWeiner> completely missed that
14:49:13 <WilhelmVonWeiner> carry on then
14:52:59 <KipIngram> WilhelmVonWeiner: I have pre/post increment decrement versions of c@ c! as well.
14:53:29 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
14:54:36 <WilhelmVonWeiner> john_cephalopoda: code works and is very cool
14:54:53 <john_cephalopoda> WilhelmVonWeiner: Thanks!
14:55:37 --- quit: moony (Max SendQ exceeded)
14:56:04 --- join: moony (moony@unaffiliated/moonythedwarf) joined #forth
15:06:46 <KipIngram> But hey - the parsing a number from the input stream you were talking about earlier works for that.
15:06:54 <KipIngram> You could do this at the top:
15:07:26 <KipIngram> ." Enter <parameter>: " BL WORD NUMBER CONSTANT <parameter_name>
15:09:23 <WilhelmVonWeiner> Why BL?
15:09:55 <KipIngram> Um, in my system that's the character WORD uses as a parsing separator.
15:10:36 <WilhelmVonWeiner> OH
15:10:52 <WilhelmVonWeiner> I clearly need sleep soon
15:10:53 <WilhelmVonWeiner> DUH
15:10:58 <KipIngram> :-)
15:12:39 <KipIngram> Anyway, with that approach the user would be prompted for the parameters when the code was loaded.
15:13:41 <KipIngram> The other possibility is to be sneaky and change the constant values later.
15:27:42 <KipIngram> Actually that bl word ... trick wouldn't work, would it?  When loading code, the "input stream" is the source block.
15:27:53 <KipIngram> So it would just parse the word out of there - it wouldn't prompt the user for it.
15:28:30 <KipIngram> More would be required - you'd have to EXPECT some text from the user, and then run NUMBER on it.
15:29:17 <john_cephalopoda> KipIngram: You are trying to get a number as user input and save it to a const, right?
15:31:09 <john_cephalopoda> KipIngram: You could have a loop that uses KEY to get some input looks if it is a number, puts it on the stack and quits when RETURN (13) is pressed.
15:32:00 <WilhelmVonWeiner> I think he's still looking to TICK ( ' ) for a number
15:33:40 <WilhelmVonWeiner> john_cephalopoda: are you a programmer with any other languages 
15:34:21 <WilhelmVonWeiner> at a "I could solve most problems if I really put my mind to it, potentially not most efficient but technically solved" level
15:35:37 <KipIngram> Well, that's what I thought he was wanting to do.
15:36:11 <KipIngram> Yes, but EXPECT and WORD and NUMBER already can an awful lot of that for you, John.
15:36:17 <KipIngram> Along with line editing and so on.
15:36:58 <KipIngram> John: You pass EXPECT a buffer address and size, and it reads the keyboard into it, handles cursor keys, etc. etc.
15:37:23 <KipIngram> You might not even need WORD, if you know what's going to be typed is a single WORD.
15:37:41 <KipIngram> NUMBER takes a pointer to some text in memory and converts it to a number on the stack.
15:38:36 <john_cephalopoda> WilhelmVonWeiner: With KEY parsing, I could verify all the input while it is written and make sure that it is valid.
15:39:23 <john_cephalopoda> Users can be malicious and checking input has high priority.
15:40:11 <KipIngram> Yes, true, but you could check the characters after they were in memory too.  Do you want line editing (cursor keys, backspace, etc. etc.)?
15:40:22 <KipIngram> If so, it's a BIG pile of code if you build it all up from KEY.
15:40:31 <KipIngram> And that's just what EXPECT is for.
15:40:45 <KipIngram> Actually my WORD won't work for this (and this may hold for most systems).
15:40:52 <WilhelmVonWeiner> well his program doesn't need EXPECT
15:40:59 <KipIngram> WORD automatically takes from the source stream.
15:41:25 <WilhelmVonWeiner> I don't see why the user needs to rebind keys. that's my inner Chuck speaking (lol)
15:41:28 <KipIngram> Ok.  I'm just trying to point out the pros and cons here.
15:41:59 <WilhelmVonWeiner> my other inner chuck is going "who's putting malicious input into a Game of Life program"
15:42:07 <KipIngram> lol
15:42:20 <WilhelmVonWeiner> Reminds me of the time Jeff Fox replaced a bunch of error checking an ANS Forther wrote with "2DROP"
15:42:24 <KipIngram> Hmmm.  My number doesn't work well here.  It exepcts a counted string; EXPECT doesn't provide that.
15:42:41 <KipIngram> Looking to see if I can add an entry point to handle that.
15:43:04 <WilhelmVonWeiner> john_cephalopoda: I can see why you used KEY nothing wrong with it
15:44:01 <WilhelmVonWeiner> I do suggest you could keep XY on the stack and DUP /MOD to get the individual X and Y pos when you want it 
15:44:54 <KipIngram> Yes, second entry point to NUMBER code worked nicely.
15:45:39 <john_cephalopoda> Hmm, does anybody have an interesting Forth project that I could join so I can learn a bit more Forth on the way?
15:45:53 <WilhelmVonWeiner> also I noticed you wrote "DUP 50 / SWAP 50 MOD SWAP". You might be interested in the word /MOD, 50 /MOD does that in one fell swoop.
15:46:15 <WilhelmVonWeiner> john_cephalopoda: have you read/surfed through Starting Forth?
15:47:18 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth
15:47:59 <WilhelmVonWeiner> also this video helped me immensely https://www.youtube.com/watch?v=mvrE2ZGe-rs
15:48:42 <WilhelmVonWeiner> personally I don't know of many projects. I could put my pre-alpha-proto-emacs on Github if you want to fork it lol
15:51:42 <john_cephalopoda> WilhelmVonWeiner: Yeah, browsed the Starting Forth book, but reading a book is never as good as actually getting some hands-on experience.
15:56:31 <WilhelmVonWeiner> I feel that book *is*. I don't remember where, but Chuck Moore once said on the design of Forth that it's about learning to use the words provided to build your own dictionary, and Starting Forth is a run-through most of the fundamental words you will ever need 
15:57:10 <WilhelmVonWeiner> It's not like learning Scala or Python, because it's not just a new syntax for the same old same old
15:57:57 <WilhelmVonWeiner> found it. http://www.ultratechnology.com/f70c8.html
15:58:12 <WilhelmVonWeiner> 2nd paragraph, the rest is outdated since it's talking about FORTH circa 1970
15:58:56 <WilhelmVonWeiner> as in the rest of the document, nouns and verbs etc 
16:02:23 <john_cephalopoda> What's the link to the nearly-emacs-project you talked about?
16:04:46 <WilhelmVonWeiner> somewhere in my home directory. There's a much more developed similar project by larsbrinkhoff on Github called fmacs
16:05:40 <WilhelmVonWeiner> I'm trying to write a mostly "system agnostic" version, my own way.
16:06:25 <john_cephalopoda> Mmh, fmacs says "Only runs in lbForth."
16:06:43 <WilhelmVonWeiner> lbForth is fine afaik, not weird or anything
16:07:04 <john_cephalopoda> It being system agnostic is one of the things I like about forth. You can easily write code that should run anywhere.
16:07:28 <WilhelmVonWeiner> eeeh, notsomuch
16:08:03 <WilhelmVonWeiner> architecture agnostic
16:08:24 <WilhelmVonWeiner> but implementations can (and do) vary widely though most similarly implement core ANS
16:08:52 <john_cephalopoda> I'm sticking to gforth since it aims to support ANS.
16:10:17 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
16:10:39 <WilhelmVonWeiner> good call
16:21:25 <siraben> Ah I've tried fmacs, it's a good start but it's very imcomplete
16:21:28 <siraben> incomplete*
16:22:11 <WilhelmVonWeiner> very.
16:38:59 <KipIngram> john_cephalopada: I also recommend Thinking Forth.
16:39:07 <KipIngram> Very different from Starting Forth - different "focus."
16:39:39 <WilhelmVonWeiner> Not really the same
16:40:05 <KipIngram> Not at all.
16:40:08 <WilhelmVonWeiner> Thinking Forth is about how to develop a program in Forth, not how to write Forth
16:40:17 <KipIngram> I wouldn't suggest it as a *replacement* for SF.
16:40:31 <KipIngram> Yes, I think that's accurate.
16:40:37 <KipIngram> But it's also good stuff.
16:40:49 <KipIngram> SF should be first.
16:44:07 <john_cephalopoda> Night
16:44:11 --- quit: john_cephalopoda (Quit: Trees can see into your soul. Here they come.)
16:44:20 <WilhelmVonWeiner> peace
17:01:39 <WilhelmVonWeiner> so in my editor, I keep the XY position on top of the stack so it saves me doing memory accesses and whatever
17:02:12 <WilhelmVonWeiner> but god my code is turning into spaghetti.
17:02:30 <KipIngram> That's what led me to my stack frame mechanism.
17:03:18 <KipIngram> In your case, once you have X and Y in place, you could say {{ and then access X as 0@ and Y as 1@.  Meanwhile you could use the stack however you wanted, as long as you didn't drop into the frame.
17:03:23 <KipIngram> When you're done, you say }}
17:03:54 <KipIngram> You can 0! or 0+! or 0-! etc.
17:04:21 <KipIngram> Basically you're treating them like variables, but you don't have to actually have the variables.
17:04:27 <WilhelmVonWeiner> oh no, my point was "even with measures my code is beoming annoying to read"
17:05:08 <KipIngram> So the multiple entry thing really paid off a little while ago when I realized that NUMBER needed a counted string but EXPECT gives a null-terminated string.
17:05:22 <KipIngram> The first word in NUMBER is CSTR, which converts the counted string to a null terminated string.
17:05:30 <KipIngram> So I just inserted another entry point right after that.
17:05:44 <KipIngram> Called it (NUMBER).
17:06:18 <KipIngram> I guess I also could have moved the CSTR out of the definition; I think I only use NUMBER in one place.
17:06:30 <KipIngram> That might actually be better.
17:30:25 --- quit: wa5qjh (Ping timeout: 245 seconds)
17:31:35 --- join: smokeink (~smokeink@118.131.144.142) joined #forth
17:32:11 --- join: wa5qjh (~quassel@110.54.156.205) joined #forth
17:32:11 --- quit: wa5qjh (Changing host)
17:32:11 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
17:49:11 --- join: tabemann (~tabemann@rrcs-162-155-170-75.central.biz.rr.com) joined #forth
17:56:53 --- quit: wa5qjh (Remote host closed the connection)
18:00:31 --- join: wa5qjh (~quassel@175.158.225.210) joined #forth
18:00:31 --- quit: wa5qjh (Changing host)
18:00:31 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
18:14:10 --- quit: tabemann (Ping timeout: 252 seconds)
18:31:17 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
18:34:21 --- quit: MrMobius (Ping timeout: 244 seconds)
18:34:21 --- nick: [1]MrMobius -> MrMobius
19:29:28 --- quit: smokeink (Remote host closed the connection)
19:42:06 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:1870:3255:3792:ba89) joined #forth
20:35:13 --- quit: proteusguy (Ping timeout: 264 seconds)
20:43:14 --- join: smokeink (~smokeink@118.131.144.142) joined #forth
20:44:10 --- quit: dddddd (Remote host closed the connection)
20:47:21 --- join: proteusguy (~proteus-g@cm-134-196-84-17.revip18.asianet.co.th) joined #forth
20:47:21 --- mode: ChanServ set +v proteusguy
20:50:59 --- quit: smokeink (Remote host closed the connection)
21:07:52 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
21:10:09 --- join: smokeink (~smokeink@118.131.144.142) joined #forth
22:08:47 --- join: tabemann_ (~tabemann@2602:30a:c0d3:1890:1870:3255:3792:ba89) joined #forth
22:09:13 --- quit: tabemann (Ping timeout: 252 seconds)
22:09:37 --- quit: pierpal (Read error: Connection reset by peer)
22:09:58 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
22:18:20 --- quit: smokeink (Ping timeout: 245 seconds)
22:47:46 --- quit: pierpal (Read error: Connection reset by peer)
22:53:45 --- join: smokeink (~smokeink@118.131.144.142) joined #forth
23:00:08 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
23:05:55 --- quit: proteusguy (Remote host closed the connection)
23:17:13 --- quit: pointfree (Ping timeout: 264 seconds)
23:18:24 --- join: pointfree (sid204397@gateway/web/irccloud.com/x-ecgzqqlecaspsrqw) joined #forth
23:59:59 --- log: ended forth/18.10.29