00:00:00 --- log: started forth/21.06.02
00:09:58 --- quit: crab (Remote host closed the connection)
00:10:21 --- join: crab joined #forth
00:15:32 --- quit: crab (Ping timeout: 252 seconds)
00:29:35 <cbridge_> <hosewiejacke> : ASCII-NAME  OVER + SWAP DO I C@ . LOOP ;
00:29:38 <cbridge_> <hosewiejacke> S" dave0" ASCII-NAME
00:31:51 <cbridge_> <dave0> we totally need a forth bot
00:36:04 <cbridge_> <hosewiejacke> dave0, had the same idea some time ago :)
00:37:51 <cbridge_> <siraben> we would never agree on which implementation to use!
00:38:05 <cbridge_> <siraben> (I'd support gforth)
00:43:48 --- join: Glider_IRC__ joined #forth
00:47:23 --- quit: Glider_IRC_ (Ping timeout: 260 seconds)
01:42:27 <cbridge_> <ttmrichter> I would only accept a bot written in an artisanal Forth created specifically for purposes of this channel.
01:45:35 <cbridge_> <boru> I agree with ttmrichter. Either someone implements ircForth, or don't bother.
01:59:18 <veltas> The ##C bot is written in pascal
01:59:47 <cbridge_> <boru> I'm fairly sure pragma wrote candide in perl.
02:00:14 <cbridge_> <boru> Or the underlying pbot implementation, or whatever it's called.
02:07:07 <cbridge_> <ttmrichter> ircForth or bust.
02:25:19 <cbridge_> -!- tpbsd(~Terry@1.145.32.148) has left ##forth
02:28:56 <veltas> Sorry I mean perl
02:29:03 <veltas> I'm balancing too many plates here
04:07:54 <proteus-person> ttmrichter's answer is the only one a true Forthwright could possible entertain.
04:19:51 <cbridge_> <crc> a long time ago we had a forth bot (sifbot) running a custom forth (sif)
04:20:55 <cbridge_> <crc> http://forth.works/share/sif-0.5.tar.bz2 and http://forth.works/share/sifbot-0.5.tar.bz2
05:19:05 --- quit: cbridge_ (Remote host closed the connection)
05:19:18 --- join: cbridge_ joined #forth
05:21:20 <veltas> I don't think writing an IRC bot is that hard, if anyone wants to try it
05:23:35 <cbridge_> <crc> it's not. I've done it in retro (not running this currently, but did in #retro for a while).
05:53:53 --- quit: bluekelp (Ping timeout: 260 seconds)
05:54:00 --- join: bluekelp joined #forth
06:15:07 --- join: lucasaiu joined #forth
06:15:27 --- part: lucasaiu left #forth
06:35:37 --- join: ldbeth joined #forth
06:41:46 --- quit: ldbeth (Remote host closed the connection)
06:42:09 --- join: ldbeth joined #forth
06:43:02 --- join: lucasaiu joined #forth
07:45:02 --- quit: lucasaiu (Quit: ERC (IRC client for Emacs 28.0.50))
07:46:02 --- join: lucasaiu joined #forth
07:46:39 --- quit: lucasaiu (Remote host closed the connection)
07:51:15 --- quit: ldbeth (Ping timeout: 248 seconds)
07:56:37 --- join: ldbeth joined #forth
08:01:58 --- quit: ldbeth (Ping timeout: 260 seconds)
08:06:52 --- join: ldbeth joined #forth
08:11:16 --- quit: ldbeth (Ping timeout: 258 seconds)
08:25:56 --- join: crab1 joined #forth
08:33:56 <cbridge_> <KipIngram> Ditto on ttmrichter's opinion.  It's "the way of Forth."
08:34:08 <cbridge_> <KipIngram> Or... "the Way of Forth."
08:35:28 <cbridge_> <KipIngram> That does represent a fair bit of work, though.
08:35:49 <cbridge_> <KipIngram> So, on that topic... yes, the philosophy is to craft the system from the ground up for the task at hand.
08:36:25 <cbridge_> <KipIngram> But what does that mean EXACTLY?  Does it mean literally from bare metal?  Is there any "foundation" whatsoever that's generally agreed to be a good starting point for practically anything?
08:36:37 <cbridge_> <nihilazo> I guess an assembler
08:36:43 <cbridge_> <nihilazo> in the software world
08:36:52 <cbridge_> <nihilazo> although if you want to build forth from the hardware up, j1 is there for ya
08:37:01 <cbridge_> <KipIngram> Well, right - yeah; I didn't mean manually enter machine code.  :-)
08:37:37 <cbridge_> <remexre> though, it'd be very bad-ass to build a dedicated computer for this from TTL
08:37:52 <cbridge_> <KipIngram> It feels to me like the higher level parts of the work would be guided by the target application, but the lower levels would be guided by the hardware at hand.
08:37:58 <cbridge_> <remexre> would probably have to do networking over UART
08:38:10 <cbridge_> <KipIngram> As an embedded guy I can think about designing the hardware too, which is fun...  :-)
08:38:13 <cbridge_> <MrMobius> people fall in love with that kind of stuff too quickly and romanticize it. someone made a cpu out of 7400 logic as a hobby project so the next guy built one out of transistors only. next i saw a post asking how to make your own transistors so you could be even closer to the metal
08:38:16 <cbridge_> <remexre> (unless ethernet is much easier to impl than I think)
08:38:29 <cbridge_> <KipIngram> Start with a wafer of silicon, man!  :-)
08:38:43 --- quit: crab1 (Ping timeout: 260 seconds)
08:38:56 <cbridge_> <KipIngram> My understanding is that a "toy" ethernet gadget isn't THAT hard, but there are lots and lots of corner cases to handle to get a formally correct one.
08:39:51 <cbridge_> <MrMobius> half of this stuff wouldnt exist if people couldnt pretend any more that they are elite because they use assembly/7400 logic/transistors
08:39:54 <cbridge_> <KipIngram> Somewhere over the years I saw a little Verilog bit that was a very primitive ethernet interface.
08:39:57 <cbridge_> <nihilazo> 
ACTION is taking a course rn in designing a computer starting with a NAND gate

08:40:04 <cbridge_> <KipIngram> :-)
08:40:07 <cbridge_> <KipIngram> Nice.
08:40:13 <cbridge_> <nihilazo> 
ACTION writes assembly on an 8-bit stack VM, although that one is actually for cool reasons

08:40:35 <cbridge_> <KipIngram> There's a website out there that does that - it guides you through the construction of a fully working processor, starting with the gates.
08:40:44 <cbridge_> <nihilazo> the course kinda sucks because while it does explain how to build the various parts, the overall architecture is kinda "this is the design, implement it" rather than "here's how an architecture is designed"
08:40:50 <cbridge_> <nihilazo> yeah the website is based on the course :D
08:40:53 <cbridge_> <nihilazo> nand2tetris
08:40:56 <cbridge_> <KipIngram> I don't remember where it was - I played with it for a little while.
08:41:03 <cbridge_> <KipIngram> A friend I can ask might remember.
08:41:31 <cbridge_> <nihilazo> was it https://www.nandgame.com/?
08:41:43 <cbridge_> <KipIngram> As you finished each level correctly, those circuits then got added to your toolbox to help with later levels.
08:41:46 <veltas> KipIngram: It's not a philosophy you can take too far, there's not much you can do totally independently
08:41:50 <cbridge_> <KipIngram> Lemme see.
08:42:15 <cbridge_> <KipIngram> I don't think that's the same one, but it looks "the same" anyway.  Same idea.
08:42:20 <veltas> Chuck Moore wasn't the unabomber like he wasn't saying we had to live in the woods
08:42:27 <cbridge_> <KipIngram> It just doens't tickle my memory quite the right way.
08:42:44 <veltas> wasn't/isn't
08:43:56 <cbridge_> <nihilazo> I think the philosophy is best taken as far as it serves your goal
08:44:15 <cbridge_> <nihilazo> for me, I am usually happy building up from already having an interpreter and/or set of libraries
08:44:37 <cbridge_> <nihilazo> build your own libraries if they serve your purpose better, build your own compiler if it serves your purpose better
08:44:47 <cbridge_> <nihilazo> maybe you have a purpose that *really* needs custom hardware, in which case hardware too, but probably now
08:51:32 <cbridge_> <MrMobius> nihilazo, you sound like you are solving practical problems in an efficient way. that's something else entirely :P
08:53:14 <cbridge_> <nihilazo> is forth not "a language and philosophy for solving problems"?
08:53:40 <cbridge_> <MrMobius> not for decades no
08:53:46 <cbridge_> <nihilazo> fair enough
08:53:52 <cbridge_> <MrMobius> unless you mean problems we're solving because we enjoy it
08:54:15 <cbridge_> <nihilazo> well, yeah
08:54:21 <cbridge_> <nihilazo> solving self-created problems
08:54:28 <cbridge_> <nihilazo> or problems that you are solving for personal reasons
08:54:47 <cbridge_> <remexre> aren't most computing problems self-created :P
08:55:39 <cbridge_> <nihilazo> yeah
08:56:11 <cbridge_> <MrMobius> some of them are boss-created
08:56:24 <cbridge_> <MrMobius> employer-created
08:58:24 --- quit: cbridge_ (Remote host closed the connection)
08:58:39 --- join: cbridge_ joined #forth
09:39:15 <cbridge_> <KipIngram> Forth is fun.
09:40:28 <cbridge_> <KipIngram> Working on mine is probably the closest thing I have to a "hobby."
09:41:05 <cbridge_> <KipIngram> As I retire and get more time on my hands I kind of hope it turns out to be that the hobby is "making stuff," and that this is just the part I'm working on right now.
09:43:05 --- quit: cbridge_ (Remote host closed the connection)
09:43:17 --- join: cbridge_ joined #forth
09:44:15 <cbridge_> <ventyl> nihilazo: about a decade ago, I wrote simple register machine VM together with simple C compiler, static linker and assembler
09:46:34 <cbridge_> <nihilazo> cool
09:49:49 <cbridge_> <MrMobius> ventyl, neat! do you have a link?
10:01:17 <cbridge_> <KipIngram> ventyl: That is very cool.  :-)
10:19:59 --- join: andrei-n joined #forth
10:21:42 <cbridge_> <KipIngram> This disk buffer management appears to be a somewhat complex undertaking, given the features I want.
10:22:15 <cbridge_> <KipIngram> I want to be able to use the bottom 8 bits of the block number as a hash for checking if a block is resident.  That basically means a linked list for each 8-bit value.
10:22:53 <cbridge_> <KipIngram> But then I'd also like to implement a really proper least recently used process, which implies a doubly linked list over all of the pages, and that really makes it preferable to make the first linked list doubly linked as well.
10:23:07 <cbridge_> <KipIngram> So that's two sets of pre and post link pointers for each buffer.
10:23:29 <cbridge_> <KipIngram> A byte likely suffices for each one - that would support up to 255 buffers.
10:23:46 <cbridge_> <KipIngram> And 16 bits would certainly suffice.
10:24:11 <cbridge_> <KipIngram> If both lists are doubly linked, I'm sure I can design it so that the same set of words handles both.
10:24:37 <cbridge_> <KipIngram> And I've written doubly linked list management words before - there is a clean design in there if you dig around a little.
10:25:13 <cbridge_> <KipIngram> It's just a bit more involved than I really "like."
10:27:13 --- quit: cbridge_ (Remote host closed the connection)
10:27:25 --- join: cbridge_ joined #forth
10:40:12 <cbridge_> <ventyl> MrMobius: https://github.com/ventZl/CMaRISC
10:40:43 <cbridge_> <ventyl> MrMobius: it is not finished though. and it is faaaaaaaaaaaaaaar from being an optimized compiler
10:41:08 <cbridge_> <ventyl> optimizing*
10:45:59 --- quit: cbridge_ (Remote host closed the connection)
10:46:12 --- join: cbridge_ joined #forth
10:56:52 <cbridge_> <cess11> KipIngram: does resident in this context mean it's already on disk?
11:02:30 --- quit: cbridge_ (Remote host closed the connection)
11:02:41 --- join: cbridge_ joined #forth
11:12:13 --- quit: cbridge_ (Remote host closed the connection)
11:12:25 --- join: cbridge_ joined #forth
11:14:52 --- join: crab1 joined #forth
11:17:44 --- quit: cbridge_ (Remote host closed the connection)
11:17:54 --- join: cbridge_ joined #forth
11:42:35 --- nick: Glider_IRC__ -> Glider_IRC
11:42:43 --- quit: Glider_IRC (Quit: Leaving)
11:43:16 --- join: Glider_IRC joined #forth
11:44:09 <cbridge_> <KipIngram> No, means it's already in a RAM buffer.
11:44:23 <cbridge_> <KipIngram> And thus doesn't need to be read in from disk.  The "fast path."
11:44:42 <cbridge_> <KipIngram> I want to use the bottom eight bits of the block # to select a (short) linked list, and then rip through that list to see if I already have that block.
11:44:54 <cbridge_> <KipIngram> If I do, I slap the address on the stack and I'm done.
11:45:10 <cbridge_> <KipIngram> If not, then I'm going to have to read it and I'll enter into a fair bit of code written in Forth rather than assembler.
11:45:16 <cbridge_> <KipIngram> Fast path will be in assembly.
11:45:55 <cbridge_> <KipIngram> But, even in the fast path I will need to do a bit of list modification, because that block now becomes the most recently used, so it needs to be moved to the end of the LRU list.
11:46:26 <cbridge_> <KipIngram> If I set the data structures up right it should just take a handful of assembly lines to do that.
11:47:11 <cbridge_> <KipIngram> If I run out of free buffers, then I'll select the one from the OTHER end of the LRU list to be evicted.
11:49:11 --- quit: cbridge_ (Remote host closed the connection)
11:49:23 --- join: cbridge_ joined #forth
11:53:22 <cbridge_> <KipIngram> So the LRU list is one long list containing all resident blocks.  The other list (set) is the hash lists, and most of the time those will only be one maybe two blocks long.
11:54:04 <cbridge_> <KipIngram> They're "almost" not necessary, given the way I expect to be using the system, but the possibility of a low eight bit block number collision has to be considered.
11:58:32 --- quit: cbridge_ (Remote host closed the connection)
11:58:42 --- join: cbridge_ joined #forth
12:43:47 --- join: Glider_IRC_ joined #forth
12:46:50 --- quit: Glider_IRC (Ping timeout: 252 seconds)
13:06:58 --- quit: andrei-n (Quit: Leaving)
13:08:53 --- quit: Glider_IRC_ (Quit: Leaving)
13:09:36 --- join: Glider_IRC joined #forth
13:40:03 --- quit: Keshl__ (Quit: Konversation terminated!)
13:50:16 --- join: Zarutian_HTC joined #forth
13:52:52 --- quit: gravicappa (Ping timeout: 248 seconds)
14:01:16 --- join: Keshl joined #forth
14:08:00 <cmtptr> KipIngram, i was thinking more about this cheap stack frame stuff.  just playing around with it in my head, haven't actually written anything of my own yet, but i was thinking it also could be used as a different way of parameter passing
14:08:25 <cmtptr> like maybe a printing word always uses n1 as the base or something
14:13:07 <cbridge_> <KipIngram> Well, the way I'll do my "printf" will be to pass it the format string, and each time it comes to a format field in that string it will nip an extra argument from the stack.
14:13:29 <cbridge_> <KipIngram> It'll work like TYPE - pass it an address and a count.
14:13:46 <cbridge_> <KipIngram> When it's done, those will be gone, and also an extra item for each format field will be gone.
14:14:17 <cbridge_> <KipIngram> I've also thought about using it as a way to send information to a child task.
14:14:34 <cbridge_> <KipIngram> The child would get it's own stack, of course, but it's frame register could give it a window into the parent's stack.
14:14:43 <cbridge_> <KipIngram> It could fetch or store information that way.
14:15:00 <cbridge_> <KipIngram> The parent would just have to promise not to pop that info off before the child finished.
14:15:20 <cbridge_> <KipIngram> The parent could change it's own frame register after starting the child - the child would get a copy.
14:15:31 <cbridge_> <KipIngram> So the parent could do that repetitively to launch a whole flock of children.
14:17:31 --- quit: cbridge_ (Remote host closed the connection)
14:17:44 --- join: cbridge_ joined #forth
14:17:59 <cmtptr> oh that's cool
14:18:24 <cbridge_> <KipIngram> I thought so too.  :-)
14:18:24 <cmtptr> i really like this idea as like a mechanism to instantiate state
14:18:43 <cbridge_> <KipIngram> Prior to thinking of that I'd always assumed I'd have to copy a block of information over to the child, and copy results back.
14:19:06 <cbridge_> <KipIngram> I feel like it definitely adds power to the system.
14:24:09 <cbridge_> <KipIngram> And it tremendously cuts down on "stack diddling."  I really use very few traditional stack juggling these days.
14:24:31 <cbridge_> <KipIngram> stack juggling *words*
14:28:26 <cbridge_> <KipIngram> I'm not really sure how well that multi-tasking facet of it will work out, though - giving the child a window into the parent's stack region might create cache line sharing problems.
14:28:45 <cbridge_> <KipIngram> The two cores would both want that line, and they might just thrash each other.
14:29:36 <cbridge_> <KipIngram> The parent could be smart and make sure that the region the child was going to be using didn't share a cache line with the region it wanted to be using - hopefully the child could just get that line one time and then would "own it" until done.
14:31:36 --- quit: cbridge_ (Remote host closed the connection)
14:31:47 --- join: cbridge_ joined #forth
16:10:19 <cbridge_> <dave0> maw
16:10:31 <cbridge_> <crc> maw
16:10:42 <cbridge_> <dave0> maw crc 
16:17:29 <cbridge_> <KipIngram> maw dave0
16:22:00 <cbridge_> <dave0> maw KipIngram 
16:48:17 --- join: Glider_IRC_ joined #forth
16:51:38 --- quit: Glider_IRC (Ping timeout: 260 seconds)
17:52:42 <mark4> https://imgur.com/a/zCTKYBT
18:36:59 <cbridge_> <crc> mark4: looks good here in grayscale land
18:41:23 <mark4> you are in full grayscale ? :)
18:41:27 <mark4> cool :)
18:41:52 <mark4> that a 100% text mode tile editor, next i write the map editor :)
18:45:24 --- join: gravicappa joined #forth
18:49:43 <cbridge_> <crc> Myles' I keep my screens set to grayscale
18:50:15 <cbridge_> <crc>   *mark4
18:54:06 --- join: Zarutian_HTC1 joined #forth
18:54:06 --- quit: Zarutian_HTC (Read error: Connection reset by peer)
18:54:14 <mark4> :)
19:43:38 <cbridge_> <tabemann> 
ACTION prefers green on black

19:44:30 <cbridge_> <tabemann> websites because they are typically dark on light annoy me because they're commonly too bright
19:45:12 <KipIngram> For me that seems to depend on the app.
19:45:24 <KipIngram> I decided that I liked Discord better dark on light.
19:45:53 <cbridge_> <crc> tabemann: that's fine too :)
19:46:01 <cbridge_> <KipIngram> Weird Discord behavior today.  I tried to start it up and it told me an update was needed.
19:46:10 <cbridge_> <KipIngram> But it doesn't really download anything sane.
19:46:27 <cbridge_> <KipIngram> I wound up logging in via my browser, getting the desktop app, and running that.
19:46:43 <cbridge_> <KipIngram> But it's not using my formally installed Discord - it's just using the stuff I downloaded.  
19:46:55 <cbridge_> <KipIngram> And the GUI doesn't know about it - I had to open a terminal and run it from there.
19:56:35 <cbridge_> <crc> odd
20:00:32 <cbridge_> <tabemann> <KipIngram> And it tremendously cuts down on "stack diddling."  I really use very few traditional stack juggling these days. < this is why I like PICK - you just quickly copy data from deeper in the stack to the top of the stack, with very little expense - but for some reason this is looked down upon by people who like to see Forth as a pure "stack machine"
20:01:33 <cbridge_> <tabemann> whereas traditional stack juggling with ROT and like is so much more expensive
20:02:31 <cbridge_> <crc> PICK is expensive if your stacks aren't addressable :)
20:02:58 <cbridge_> <tabemann> well unless you're coding for an FPGA where your stack is a shift register...
20:03:45 <cbridge_> <crc> My emulated MISC architecture doesn't have addressable stacks :)
20:04:11 <cbridge_> <tabemann> well that isn't an inherent limitation but rather a design choice
20:10:29 <cbridge_> <tabemann> hell, if I wanted to I could implement an optimized, constant-folding PICK for zeptoforth
20:11:25 <cbridge_> <crc> indeed. I'm pragmatic enough to not rule out PICK or similar if it makes the overall readability and maintenance easier.
20:12:52 <cbridge_> <tabemann> over time I have gotten better at not stack diddling and keeping my working set shallow, but even still, it's very useful sometimes to just reach into the stack and grab a value rather than try to stack juggle to bring it to the surface, while rearranging everything thing else near the top of the stack
20:13:04 --- quit: cbridge_ (Remote host closed the connection)
20:13:14 --- join: cbridge_ joined #forth
20:14:17 <cbridge_> <KipIngram> PICK doesn't bother me nearly so much as ROLL does.
20:14:33 <cbridge_> <KipIngram> My stack frames enable a sort of PICK.  
20:14:39 <cbridge_> <KipIngram> Along with a lot of other capabilities.
20:14:39 <cbridge_> <tabemann> ROLL is horrible
20:14:47 <cbridge_> <KipIngram> Indeed.
20:14:53 <cbridge_> <tabemann> I've had to use ROLL at itmes but I've never liked it
20:15:04 <cbridge_> <KipIngram> I don't even really like ROT and -ROT.
20:15:17 <cbridge_> <KipIngram> At least you can do them with a short string of xchg instructions, though.
20:15:17 <cbridge_> <tabemann> agreed
20:15:31 <cbridge_> <tabemann> ROT and -ROT are unnecessarily expensive
20:16:24 <cbridge_> <tabemann> people seem to treat PICK and ROLL as if they were the same thing
20:16:37 <cbridge_> <tabemann> whereas PICK is cheap while ROLL is very expensive
20:16:38 <cbridge_> <KipIngram> Right.
20:17:25 <cbridge_> <KipIngram> ROT isn't THAT expensive.  It's just two xchg instructions plus next.
20:17:30 <cbridge_> <KipIngram> Lots of primitives are more expensive than that.
20:18:06 <cbridge_> <tabemann> tis true
20:20:06 --- quit: cbridge_ (Remote host closed the connection)
20:20:19 --- join: cbridge_ joined #forth
20:20:45 <cbridge_> <KipIngram> One advantage ROT and -ROT have is that they don't move the stack pointer.
20:21:54 <cbridge_> <KipIngram> There are a few tasks that ROLL "fits."  But I'm with you - it's ugly.
20:44:40 <cbridge_> <tabemann> that is true
20:45:49 <cbridge_> <tabemann> when I started out coding in Forth I'd often have a bunch of stuff sitting at the top of the stack which I'd be constantly PICKing and ROLLing, but I don't do much of that anymore thank gawd
21:02:43 --- quit: Glider_IRC_ (Remote host closed the connection)
21:03:28 --- join: Glider_IRC joined #forth
21:16:48 <crab1> what's ROLL do
21:19:00 <crab1> Keeping words short seems to naturally prevent the need for excessive fancy stack manipulations
21:19:12 <crab1> in my limited experience
21:20:57 <crab1> if I can't manage with dup, swap, over, rot, drop, and the 2s then I probably should rethink my factoring
21:22:10 <cbridge_> <KipIngram> ROLL takes a numeric parameter n, and it REMOVES the nth item down in the stack and places it on top of the stack.
21:22:35 <cbridge_> <KipIngram> PICK, on the other hand, places a COPY of the nth item on the top of the stack, without removing the original.
21:22:51 <cbridge_> <KipIngram> So ROLL is bad because it has to move every item on the stack from the top down to the item you specify.
21:23:04 <cbridge_> <KipIngram> So <n> ROLL with large <n> is very inefficient.
21:25:30 <crab1> ah got it
21:26:11 <cbridge_> <KipIngram> Both PICK and ROLL are generally frowned upon - especially ROLL.
21:27:03 --- join: andrei-n joined #forth
21:27:10 <cbridge_> <KipIngram> Well, I'm gonna hit the sack.  Night guys - have a good one.
21:27:26 <cbridge_> <crc> Goodnight KipIngram
21:28:29 <cbridge_> <crc> I have implementations of PICK a and ROLL, but haven't ever actually used them. http://forth.works/examples/ans-pick-roll.retro.html
21:29:05 <crab1> do you have some version or another of most of the words in ANS?
21:30:17 <cbridge_> <crc> I don't aim to be compatible with ANS, but other than PICK and ROLL, I have some additional words in http://forth.works/examples/compat.retro.html
21:31:01 <cbridge_> <crc> There are a number I'll never implement (listed at the bottom of that file) for various reasons
21:32:27 <cbridge_> <crc> Some of that has changed slightly. E.g., I now have a `Base` variable, which could be aliased to BASE. I think that's the only one though
21:34:27 --- quit: cbridge_ (Remote host closed the connection)
21:34:41 --- join: cbridge_ joined #forth
21:34:56 <cbridge_> <crc> It looks like TYPE is broken, (should be something like `:TYPE [ fetch-next c:put ] times drop ;`
21:58:43 --- quit: crab1 (Ping timeout: 248 seconds)
22:15:39 --- quit: proteusguy (Ping timeout: 265 seconds)
22:28:17 --- join: proteusguy joined #forth
22:28:17 --- mode: ChanServ set +v proteusguy
22:38:58 <cbridge_> <dave0> crc: i remember your choose !
22:40:45 <cbridge_> <dave0> crc: ( a b flag -- a | b )   is picks a if flag is true, otherwise b
22:42:09 <cbridge_> <crc> almost
22:42:47 <cbridge_> <crc> ( flag a b -- ), executing word a or b depending on flag
22:43:18 <cbridge_> <dave0> crc: i searched for ages until i found "multiplex" which is what choose is
22:44:46 <cbridge_> <dave0> https://en.wikipedia.org/wiki/Multiplexer
22:46:26 --- quit: andrei-n (Quit: Leaving)
23:39:04 <veltas> Nothing wrong with PICK and ROLL
23:39:17 <veltas> If you care about keeping your programs short you'll not use them constantly anyway
23:43:03 --- join: test3274089237 joined #forth
23:47:23 --- quit: test3274089237 (Quit: Connection closed)
23:59:59 --- log: ended forth/21.06.02