00:00:00 --- log: started forth/19.02.08
00:00:54 --- join: dys (~dys@tmo-120-233.customers.d1-online.com) joined #forth
00:14:51 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
00:15:24 --- quit: dys (Ping timeout: 244 seconds)
00:17:19 --- quit: MrMobius (Ping timeout: 250 seconds)
00:17:19 --- nick: [1]MrMobius -> MrMobius
00:34:13 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth
00:46:13 --- join: xek (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth
00:54:25 <john_cephalopoda> I just had an interesting idea.
00:55:08 <john_cephalopoda> The dictionary words are stored as a linked list, but with two pointers: One "kernel" pointer and one "user" pointer.
00:56:58 <john_cephalopoda> When searching a word from kernel-mode, it uses the complete kernel linked list, which gives you all the words. When searching a word from user mode, the user pointer is used, which only lets you access specific words.
00:57:27 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
00:58:14 <john_cephalopoda> When running EXECUTE, the dictionary is checked for that token. If it isn't in the dictionary, the caller apparently tries to build some gadget or otherwise fiddle with code that shouldn't be directly executed.
00:58:53 <presiden> yes
00:58:58 <john_cephalopoda> That way, a separation of user words and kernel words, plus a safe implementation of EXECUTE would exist.
01:00:00 --- quit: MrMobius (Ping timeout: 245 seconds)
01:00:01 --- nick: [1]MrMobius -> MrMobius
01:00:01 <john_cephalopoda> (Without the need of building some facade for users or doing complex bound checks)
01:00:56 --- join: X-Scale` (~ARM@85.59.43.5.rev.vodafone.pt) joined #forth
01:02:37 --- quit: X-Scale (Ping timeout: 246 seconds)
01:02:37 --- nick: X-Scale` -> X-Scale
02:04:38 --- quit: ashirase (Ping timeout: 252 seconds)
02:07:02 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
03:36:40 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
03:55:36 <corecode> hi
03:56:40 <corecode> john_cephalopoda: not just execute, also return
04:05:41 <john_cephalopoda> Returning is an issue. One could use a shadow stack or make the return stack unwritable, offering a "secondary stack" for things you'd usually use R for.
04:06:02 <corecode> "meh"
04:06:10 <corecode> yea i had thought about this before
04:06:20 <corecode> i don't remember what my solution was
04:55:33 --- quit: mtsd (Quit: WeeChat 1.6)
05:33:06 --- join: john_metcalf (~digital_w@host86-169-226-30.range86-169.btcentralplus.com) joined #forth
06:18:13 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
06:20:18 <rdrop-exit> I remember Starflight, it's one of the handful of computer games I've played. I remember reading an interview of one of the developpers a few years back.
06:22:38 <rdrop-exit> Good evening Forthwrights :)
06:24:57 --- quit: dave0 (Quit: dave's not here)
06:37:08 <john_cephalopoda> Hey rdrop-exit 
06:38:09 <rdrop-exit> Hi John
06:52:27 --- quit: john_metcalf (Quit: http://corewar.co.uk)
07:09:13 <rain1> does anyybody stream or make videos of forth programming?
07:09:18 <rain1> i could learn by watching it
07:09:51 <zy]x[yz> lol
07:10:12 <zy]x[yz> millennials, man
07:14:50 <corecode> rain1: you could learn by doing it
07:15:01 <travisb> hey guys
07:15:53 <travisb> rdrop-exit, look at the architecture docs for hashforth again
07:16:44 <travisb> now no mention of word names, flags, or next values is present
07:16:50 <phadthai> one that I've seen lately was dvTI3KmcZ7I I think, not really a tutorial
07:17:10 <phadthai> err https://www.youtube.com/watch?v=dvTI3KmcZ7I
07:17:34 <travisb> (there is still a mention of a word count, because it needs to know how big of a token table to alllocate out of the specified block of memory size)
07:25:54 <rdrop-exit> Hi travisb, what do you by "token table", why is it needed?
07:28:19 --- quit: travisb (Ping timeout: 240 seconds)
07:46:34 --- quit: rdrop-exit (Quit: Lost terminal)
07:51:40 --- quit: Zarutian (Ping timeout: 245 seconds)
07:52:05 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
07:53:20 --- join: MickyW (~MickyW@p5492671E.dip0.t-ipconnect.de) joined #forth
07:58:27 --- quit: MickyW (Quit: Leaving. Have a nice time.)
08:04:07 <WilhelmVonWeiner> Hello all
08:04:19 <WilhelmVonWeiner> how goes it
08:04:23 <corecode> hi
08:04:34 <corecode> i want to try my forth cpu
08:04:56 --- quit: PoppaVic (Ping timeout: 250 seconds)
08:16:50 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth
08:25:50 <WilhelmVonWeiner> what's stopping you
08:26:09 <PoppaVic> oh! I know! Mime Wall!
08:27:14 <corecode> WilhelmVonWeiner: i need to figure out how to wire up gpio in the fpga so that i can observe the cpu running
08:27:46 <WilhelmVonWeiner> why not use some kind of simulator
08:27:58 <corecode> yea in the simulator i can run instructions
08:30:52 <WilhelmVonWeiner> colorforth is so annoying. the keyboard thing is so, so annoying.
08:31:10 <WilhelmVonWeiner> I love the intent but the keyboard thing is absolutely mental
08:38:10 --- quit: nighty- (Quit: Disappears in a puff of smoke)
09:43:37 <PoppaVic> I never really liked his "color" fixation - and his kbd madness is known: he really wants a multi-button clicker, I swear. (Might as well use voice).
09:52:33 <crc> I don't mind the colors, though I prefer to keep a textual representation of my source.
09:53:31 <PoppaVic> Well, some folks have color-issues; some also fight with the damned termwin - chroma, etc - you can get blind, (I remember green and amber screens too well). 
09:55:51 <crc> there are ways around these issues. (I tend to think of the prefixes in my forth as being similar to the colors, and I've seen colorforth code rendered using font attributes like bold and italics instead of colors)
09:59:51 <rain1> what can I read online to understand the forth way better?
10:00:20 <WilhelmVonWeiner> Starting Forth
10:00:29 <PoppaVic> "way better" or "forth way"? ;-)
10:00:41 <WilhelmVonWeiner> The only Forth book Chuck thinks accurately gets the spirit of Forth across
10:01:26 <PoppaVic> Except, it requires you still have your system-docs around, since it was written against Polyforth.
10:02:02 <PoppaVic> You certainly should own a copy of Starting Forth; I also like Thinking Forth.
10:02:18 <WilhelmVonWeiner> I Nah, Forth Inc republished it online, for SwiftForth
10:03:06 <PoppaVic> cool. I also have FIG docs around, Forth79, F-pc, F-83 books. All I have for gforth is the info-file.
10:04:27 <rain1> forth way
10:04:55 <WilhelmVonWeiner> is that a "no" to Starting Forth?
10:05:41 <rain1> i got the pdf
10:05:43 <rain1> thanks
10:05:43 <PoppaVic> WilhelmVonWeiner: Hmm? I've had a hardcover since the 80's - and the SF book in hardcover as well.
10:06:03 <WilhelmVonWeiner> i meant to rain1
10:14:57 --- quit: Keshl (Read error: Connection reset by peer)
10:15:16 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth
11:05:51 <corecode> rain1: wjat
11:05:58 <corecode> rain1: what are you up to?
11:24:30 --- quit: pierpal (Read error: Connection reset by peer)
11:24:46 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth
11:55:19 --- quit: gravicappa (Ping timeout: 240 seconds)
12:09:22 --- join: twinshadow (~Adium@c-73-169-238-182.hsd1.wa.comcast.net) joined #forth
12:09:51 --- part: twinshadow left #forth
12:23:44 <bluekelp> does anyone know of a quick tutorial for the dev environment setup used in the youtube video by 
12:23:47 <bluekelp> jephthai
12:23:48 <bluekelp> ? 
12:24:22 <bluekelp> I really like his setup but am not familiar with mecrisp yet - but it's exactly what i wanted to mess with when i tried making my own stm32 forth on an m4 (?) demo board
12:24:59 <bluekelp> i was using some open jtag etc etc on OSX and it was years ago and I do not remember. hoping things are easier and pretty established now
12:25:17 <bluekelp> also a system on a board for under $4 is amazing!
12:29:01 <pointfree> bluekelp: Maybe some jeelabs mecrisp forth articles https://jeelabs.org/article/
12:29:02 <pointfree> They seem to be a hub for the mecrisp forth community
12:32:12 <pointfree> bluekelp: I should try this Folie tool for mecrisp https://jeelabs.org/article/1718b/
12:56:09 <bluekelp> thank you!
13:00:54 --- join: pagnol (~me@p54BE8B45.dip0.t-ipconnect.de) joined #forth
13:02:47 <pagnol> is there something like a 'forth by example'? I would like to learn some forth but the textbooks I saw have a lot of prose talking about alls sorts of things and it just bores the hell out of me
13:03:37 <pagnol> for example the one I'm looking at explains at length what it means to 'compile' a program
13:03:43 <pagnol> *right now
13:07:16 <zy]x[yz> there's jonesforth, which i found extremely useful for understanding the fundamentals in the beginning, but just be aware that it has some minor inconsistencies to it which don't necessarily reflect traditional forth
13:07:52 <zy]x[yz> in other words: i think jonesforth is a good resource for explaining how forth works, but a terrible resource for explaining forth conventions
13:08:43 <pagnol> zy]x[yz, thanks, I'll take a look
13:10:43 <pagnol> that's interesting
13:27:23 <bluekelp> yes - jonesforth is wonderful. i learned so much by reading through it.
13:28:26 <bluekelp> Starting Forth is great for getting to know how to use forth but my attempt at creating a forth after reading it lead me to a very ineligant solution.
13:28:26 <zy]x[yz> aside from reading through it, i would even encourage you to build your own along with it, but experiment with a slightly different implementation so that yours isn't just a copy-and-paste of jonesforth
13:37:01 --- join: dys (~dys@tmo-116-186.customers.d1-online.com) joined #forth
13:54:47 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth
13:55:05 <dave0> hi
13:57:38 <zy]x[yz> nobody say anything. maybe he'll go away
14:00:30 <WilhelmVonWeiner> dave is like a t-rex
14:08:06 <pagnol> dave0, HI DAVE
14:08:46 <pagnol> dave0, to what use have you been putting your mad forth skillz lately?
14:10:28 --- quit: Croran (Quit: No Ping reply in 180 seconds.)
14:11:04 <dave0> i don't have mad forth skilllz yet :-(
14:11:20 <dave0> i'm still a newbie :-p
14:11:40 --- join: Croran (~quassel@2601:601:1801:6dde:a024:a39a:633c:7ee8) joined #forth
14:13:16 <pagnol> dave0, are you starting out
14:13:19 <pagnol> ?
14:13:38 <pagnol> what resources are you using
14:15:25 <dave0> i've been going a while
14:16:25 <dave0> pagnol: jonesforth, brad rodriguez, lbforth, the 2012 standard
14:16:38 <dave0> i just downloaded a bunch of forths and had a look :-)
14:16:51 <dave0> oh gforth too
14:17:13 <WilhelmVonWeiner> I would recommend Lina Forth instead
14:17:19 <WilhelmVonWeiner> also make sure to read Starting Forth
14:17:36 * dave0 googles
14:20:24 <john_cephalopoda> The ANS standard is a nice ressource, too.
14:20:35 <pagnol> starting forth is so wordy
14:21:13 <dave0> oh lina for linux
14:21:18 <WilhelmVonWeiner> It's the best Forth book
14:21:38 <WilhelmVonWeiner> you will learn about thinking in a Forth-oriented way
14:21:47 <john_cephalopoda> pagnol: It's like most programming books. They start wordy, telling you tons of stuff about things you already know and at some point they start explaining something new, but you never reach that point.
14:22:07 <WilhelmVonWeiner> "you never reach that point" 
14:22:28 <pagnol> john_cephalopoda, I used paul grahams book to learn lisp a while back and it's not like that
14:22:32 <WilhelmVonWeiner> Forth isn't just another c-style syntax for a c-like language on c-oriented hardware
14:22:58 <WilhelmVonWeiner> You have to start from the fundamentals
14:23:35 <WilhelmVonWeiner> otherwise you can write mandelbrot with variables but not utilising the stack
14:24:24 <john_cephalopoda> pagnol: Maybe I just read through the wrong books. There's some extremely thick books about C++, that start by explaining what a "char" and an "int" are, and how you add stuff. Eventually, after like half the book, they suddenly get into really complex stuff.
14:24:39 <pagnol> I will give starting forth a second chance
14:25:06 <WilhelmVonWeiner> if you think it's getting too easy, skip ahead - but do all the exercises
14:25:21 <WilhelmVonWeiner> there's an online version on Forth Inc's website
14:25:30 <john_cephalopoda> WilhelmVonWeiner: Forth is a language. A language can be used in many ways. Only using variables and not using the stack (at least not much) might be the "wrong way" in the eyes of some, but it is syntactically and semantically correct Forth and a computer can work with that.
14:25:44 <WilhelmVonWeiner> ignore the chapter on the block editor though
14:26:00 <WilhelmVonWeiner> being "syntactically and semantically correct" doesn't mean "good"
14:26:38 <john_cephalopoda> What is "good"?
14:27:00 <john_cephalopoda> As long as the code is readable and maintainable, I'd call a program "good".
14:27:47 <john_cephalopoda> Just because a program isn't written like somebody in the 70s imagined it should be written doesn't mean it's the wrong or bad way.
14:28:57 <pointfree> pagnol: For embedded forth there are the noforth project tutorials http://home.hccnet.nl/willem.ouwerkerk/egel-for-msp430/egel%20for%20launchpad.html
14:30:20 <WilhelmVonWeiner> never seen this before, looks interesting
14:52:47 <pagnol> is there anyone here who writes forth code for a living?
14:54:49 <WilhelmVonWeiner> does living to write Forth code count? kekeke
14:56:50 <pagnol> no, sorry
14:58:11 <john_cephalopoda> "How to get a job in the extremely profitable, emerging forth industry - a practical guide". That will be a bestseller.
14:58:28 <KipIngram> I used Forth for a consulting project once, and at National Instruments I based the "os" of an outboard peripheral box to allow old closed Macintoshes to talk to peripherals on Forth.
14:58:41 <KipIngram> So for a couple of brief periods I could claim I was writing Forth for my living.
14:58:48 <KipIngram> Those were both a LONG time ago, though.  :-)
14:58:58 <pagnol> KipIngram, did anyone else know what you were doing? :-)
14:59:06 <KipIngram> Yes.
14:59:22 <KipIngram> The client on the consulting gig, and my boss and coworkers at NI.
14:59:41 <KipIngram> One of the NI software guys harassed me about it, but couldn't do anything about it.
15:00:30 <pagnol> how did forth make it easier to accomplish what you were hired to do?
15:00:35 <pagnol> assuming that it did
15:01:55 <pagnol> I slipped in some lisp in a project at work, perhaps one day I will succeed at doing the some with forth
15:02:04 <KipIngram> Well, at NI I was very young and don't know that it was really the best approach.  It was a good fit for the consulting gig, though - the Forth was running on a PC that lived in a pick and place machine.  It had originally been designed to run via a DOS application, and the customer wanted to be able to drive it from Windows boxes.
15:02:23 <KipIngram> The Forth provided an excellent "scripting" language.
15:03:18 <KipIngram> I replaced the console connection with a network socket; the Windows machine just talked to it via that socket, and could push source definitions over to "package functionality" that could then be invoked with just a one-word command.
15:03:45 <KipIngram> So it served as an *extensible* scripting language.
15:04:33 <KipIngram> I didn't create the Forth - it was pforth.
15:04:53 <KipIngram> But pforth has a great license - basically says "do any damn thing you please."
15:05:27 <KipIngram> I guess that was 15-16 years ago.
15:06:03 <KipIngram> I was 40 or so and the women still turned their heads my way.  Doesn't happen as often these days.  :-)
15:06:50 <KipIngram> At least not the ones I enjoy looking back at. 
15:08:25 <KipIngram> I'm not sure what happened with the box at NI.  I left there and went to graduate school.
15:08:40 <KipIngram> The next guy may have immediately trashed it.
15:08:42 <pagnol> you must be so much better-looking than me, I'm 28 and it doesn't often happen to me
15:09:33 <pagnol> you returned to uni at age 40?
15:09:44 <KipIngram> No - 40 was the consulting project.
15:09:55 <KipIngram> The NI gig was... 1986/87.
15:09:59 <pagnol> ah
15:10:10 <KipIngram> I was 24.
15:10:15 <pagnol> ok sorry
15:10:53 <KipIngram> No worries.  But hey - I'll tell you a secret.  The best years for getting attention from women run from 33 or so up to early / mid 40's.
15:10:59 <KipIngram> So you still have the best in front of you.
15:11:22 <pagnol> how come
15:11:42 <pagnol> I thought my life was basically over at least in that regard
15:11:58 <KipIngram> Uh... women notice men that are established and prosperous, and that usually happens later on.
15:12:09 <KipIngram> No way man.
15:12:13 <KipIngram> Seriously.
15:12:16 <KipIngram> I'm not kidding you.
15:12:31 <pagnol> I really didn't expect such profound wisdom when I typed /join #forth
15:12:36 <KipIngram> Women that reach their mid 30's or so without landing a man start to get a bit itchy.
15:12:44 <KipIngram> Hah hah.
15:12:51 <KipIngram> Well, whether it's "profound" or not...
15:13:34 <KipIngram> Anyway, slightly off topic.  But don't throw in the towel - you'll see.
15:13:48 <KipIngram> I don't know you, but whatever "level you're at," it will be better then than now.
15:14:09 <pagnol> speaking of throwing in the towel, I'm going to marry this year
15:14:17 <WilhelmVonWeiner> unlucky
15:14:19 <WilhelmVonWeiner> kekeke
15:14:31 <WilhelmVonWeiner> just kidding enjoy it mate
15:14:46 <KipIngram> Ah, well, excellent.
15:15:14 <KipIngram> Gotta run - got dinner with friends.  
15:15:20 <pagnol> bye
15:15:20 <KipIngram> Take care guys.
15:15:29 <pagnol> thanks for the new outlook
15:15:35 <pagnol> you gave me ;-)
15:15:38 <KipIngram> :-)
15:15:47 <KipIngram> Sure thing - my pleasure.
15:16:18 <KipIngram> I don't know if you know Jordan Peterson - he's gotten prominent lately.  Canadian psychologist.
15:16:31 <WilhelmVonWeiner> controversial figure
15:16:44 <WilhelmVonWeiner> generally spot on
15:16:50 <KipIngram> In one of his lectures he mentioned this - he said "there's almost nothing the world values more than a young woman."  Then a minute later he said "there's almost nothing the world values less than a young man."
15:16:59 <KipIngram> But that just toally turns around the other way later on
15:23:15 <john_cephalopoda> Yuck, "find" wants a counted string...
15:33:52 <PoppaVic> Loeligers book is also excellent for "ah-HAH!"
15:41:16 <pagnol> I can only find a book on git
15:41:36 <pagnol> ah you probably mean Threaded Interpretive Languages by R. G. Loeliger?
15:41:37 <PoppaVic> <shrug> try amazon
15:41:40 <PoppaVic> Yes
15:41:47 <PoppaVic> Excellent book.
15:42:22 <pagnol> PoppaVic, what did you get out of it?
15:45:01 <PoppaVic> betweem that and Brad, you get a clue about the damned inner-interpreters, (and I can  grok z80 easier than x86)
15:45:36 <pagnol> inner-interpreters?
15:46:54 <PoppaVic> You've got a pile of reading to do ;-)
15:48:31 <pagnol> I only decided to look into forth yesterday
15:50:07 <dave0> pagnol: what's your "usual" program language?
15:50:48 <pagnol> mostly python, node...
15:51:08 <pagnol> at least at work
15:51:52 <pagnol> we've begun using purescript, too
15:53:30 <pagnol> and we're using postgrest, so I find myself writing a lot of plpgsql, too
15:53:35 <pagnol> which I have mixed feelings about
15:54:03 <pagnol> dave0, you?
15:55:16 <dave0> c
15:55:26 <dave0> i write almost everything in c
15:55:46 <dave0> Forth is an eye-opener
15:55:53 <pagnol> in what way?
15:56:36 <dave0> Forth is totally different to c and it makes sense
15:57:43 <pagnol> in what way different
15:57:45 <dave0> c is rigid and inconsistent
15:58:58 <dave0> c is really hard to write correct programs
15:59:27 <dave0> forget about writing a c compiler heh
15:59:36 <dave0> but in forth it's so simple
16:00:25 <dave0> i'm still a newbie so i find it hard to juggle the stack :-(
16:00:41 <zy]x[yz> i'm not convinced that ever gets any easier
16:01:45 <dave0> zy]x[yz: how long have you been doing forth?
16:02:20 <dave0> 2 huge stengths with forth is it's extensible and it's interactive
16:02:26 <dave0> c just can't do that
16:03:05 <pagnol> how do you extend forth?
16:03:11 <dave0> i believe python is interactive, so you might not be very impressed with that... but extensible... forget about it!
16:03:49 <pagnol> I've been using common lisp too
16:03:52 <dave0> pagnol: every time you create a word you extend the language
16:04:26 <pagnol> aren't you 'extending' the language the same when you define a function in c?
16:04:35 <pagnol> *way
16:04:36 <zy]x[yz> dave0, i've been playing with it as a curiosity as a time killer for about two years.  i've never actually done anything significant or productive with it
16:04:55 <PoppaVic> forth allows you to add not only "functions" but also compilers.
16:05:59 <pagnol> I'm not sure I can appreciate the significance of this
16:06:08 <dave0> brb coffee
16:07:17 <zy]x[yz> pagnol, the sales pitch is that rather than trying to make your problem fit into the constraints of the language, for allows you to design a language to better describe the problem space
16:07:39 <pagnol> that's what they all say, especially lispers
16:07:55 <zy]x[yz> (i'm just repeating what i've heard.  i won't say that's been my experience)
16:08:00 <pagnol> ok
16:08:55 <zy]x[yz> i haven't used lisp, but forth really does give you more direct control over what's compiled than anything else i've seen
16:09:44 <zy]x[yz> it's a fun idea, but it comes at a cost.  the mantra with forth is bare-minimum simplicity, so it imposes a significant burden on the user
16:13:13 <dave0> pagnol: i thought of an example... say you write a function to compute the nth fibonacci number... in Forth you can use that word WHILE you're compiling, but in c, you can only use it when you actually run the program
16:15:27 <dave0> you can execute words at compile time
16:15:39 <pagnol> like macros in other programming languages?
16:16:01 <dave0> i believe lisp does it.. but not c
16:16:09 <pagnol> yes
16:16:49 <pagnol> how do you tell the compiler that something should be run at compile time rather than at runtime in forth?
16:17:06 <pagnol> a word
16:17:13 <pagnol> I have to get used to the terminology
16:18:00 <zy]x[yz> you don't have to
16:18:31 <zy]x[yz> well
16:18:34 --- quit: xek (Ping timeout: 246 seconds)
16:18:38 <zy]x[yz> you might mean immediate
16:19:08 <dave0> or switching from compile to interpret back to compile with   [ ]
16:19:11 <zy]x[yz> if you just want to execute a word outside of the definition of another word, you don't have to do anything
16:19:50 <zy]x[yz> if you want to define a word which does something when it's parsed during the compilation of another word, then that's an immediate word
16:20:55 <dave0> pagnol: you might do     : test [ 123 456 * ] literal . ;
16:21:16 <dave0> pagnol: that would compute 123*456 and compile it into the word
16:21:29 <dave0> same as   : test 56088 . ;
16:21:39 <dave0> . is print number
16:22:14 <zy]x[yz> also as an example, if and then are immediate words that compile branching words
16:32:24 <pagnol> hmm...
16:33:53 <corecode> hi
16:34:02 <pagnol> hi
16:35:13 <pagnol> this channel is more lively than I expected
16:35:56 <corecode> because forth is an old language?
16:36:10 <pagnol> not primarily because of its age
16:36:21 <PoppaVic> It's been vastly improved over the last year or three.
16:36:27 <pagnol> the common lisp channel for example is bursting with people
16:36:37 <pagnol> the language or the channel?
16:36:46 <PoppaVic> #forth
16:38:20 <corecode> pagnol: so are you starting with forth programming?
16:39:12 <pagnol> corecode, after having been carrying the intention in my mind for many years, I decided to begin this weekend
16:39:44 <corecode> cool
16:39:47 <pagnol> what about you
16:39:55 <corecode> i did that just before christmas
16:40:04 <corecode> decided to implement my own forth kernel
16:40:13 <pagnol> sounds ambitious
16:40:13 <corecode> haven't programmed so much forth yet
16:40:24 <corecode> it's not so difficult, as it turns out
16:42:49 <pagnol> 'forth kernel' means a forth compiler or an operating system kernel?
16:43:11 <pagnol> I'm not familiar with forth lingo 
16:44:55 <corecode> the thing that runs the forth
16:45:04 <corecode> it's a compiler and runtime in one
16:45:06 <corecode> usually
16:52:19 --- quit: john_cephalopoda (Ping timeout: 240 seconds)
16:54:19 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:44:46 <Croran> and interpreter
17:44:50 <Croran> and potentially OS too
17:46:22 <PoppaVic> Traditionally, it IS the OS - everything else is considered a "hosted" system.
18:08:09 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
18:12:06 <rdrop-exit> And if you go down even further, even your CPU(s) is/are Forth chip(s).
18:12:34 <rdrop-exit> Good morning Forthwrights.
18:17:29 <zy]x[yz> what is this witchcraft
18:17:51 <zy]x[yz> joining the channel and immediately adding to a conversation that took place before you joined
18:17:52 <rdrop-exit> :))
18:18:37 <rdrop-exit> I usually try to catch up using the logs just before I log on.
18:18:58 <zy]x[yz> what are you the nsa
18:19:01 <PoppaVic> he's a SNEAK!
18:19:14 <PoppaVic> Quick! It's the NARCS!
18:19:24 <rdrop-exit> I could tell you, but ...
18:19:30 <zy]x[yz> am i being detained
18:20:12 <rdrop-exit> #forth is now my morning coffee routine
18:21:28 <rdrop-exit> It's a refreshing change from clf
18:30:00 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
18:32:47 --- quit: MrMobius (Ping timeout: 250 seconds)
18:32:47 --- nick: [1]MrMobius -> MrMobius
18:39:09 <PoppaVic> uselessnet lost my interest long ago.. And google made it worse - which is hard to imagine, given the trolling-twits that long-roamed it.
19:01:12 --- join: travisb (~travisb@rrcs-162-155-170-75.central.biz.rr.com) joined #forth
19:02:36 --- nick: travisb -> tabemann
19:08:09 --- quit: rdrop-exit (Quit: Lost terminal)
19:08:41 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
19:10:08 <tabemann> hey
19:10:18 <rdrop-exit> Hi tabemann
19:10:29 <tabemann> I got rid of the names, flags, and last bits of wordlist support from the VM
19:11:02 <tabemann> names only exist in that a word table may be optionally passed to the VM to aid in displaying names during tracing
19:11:08 <tabemann> *name table
19:11:46 <tabemann> (but that's not necessary, because without it it will still display token numbers in the tracing)
19:14:57 <rdrop-exit> Passing a name table to the VM sounds strange to me, is that the "token table" you mentioned earlier?
19:15:48 <PoppaVic> hmm, a token-table would just be a vector from ID# to actual code.
19:15:49 <tabemann> there's still a token table, but now all it contains is a native code pointer, a data pointer, and a TTC code pointer, with no mention of names or flags or like
19:16:13 <tabemann> PoppaVic, exactly
19:17:12 <rdrop-exit> Why is this token table needed?
19:17:21 <tabemann> the name table is just an array of name pointers and name lengths, used so the VM can map from tokens to human readable names - this is not part of the VM, and is managed by the application running on top of the VM
19:17:43 <PoppaVic> rdrop-exit: I'm fairly sure it's part & parcel of his VM behind the scenes.
19:17:59 <tabemann> rdrop-exit, because the VM runs TTC code
19:18:00 <PoppaVic> jump-table shitzu
19:18:36 <PoppaVic> tabemann: a table isn't a necessity, (is I believe the counterpoint).
19:19:07 <rdrop-exit> I think there's a fundamental confusion on the TTC aspect
19:20:07 <tabemann> the tokens are indices into the token table, from which the code pointer is executed
19:21:14 <tabemann> and if the code pointer points to enter, enter begins execution of TTC code pointed to by the TTC code pointer
19:21:31 <PoppaVic> I sinply think those details are behind the Wizards Curtain <shrug>
19:22:32 <rdrop-exit> You're doing TTC twice then
19:23:37 <tabemann> how so? tokens are indices into an array, from which actual pointers to native code are gotten, which are then called
19:24:13 <tabemann> it's like ITC except array indices are used rather than word header addresses
19:26:37 <rdrop-exit> The *internal* threading of a VM is TTC.
19:27:12 * PoppaVic chortles
19:27:21 <rdrop-exit> i.e. the tokens of the VM are its opcodes, it's a virtual machine.
19:27:31 <PoppaVic> the inside of a VM is no one outside the VM's business
19:27:33 <PoppaVic> https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
19:28:44 <rdrop-exit> That's unrelated to the threading used by the Forth on top of the VM, SRT most likely.
19:29:29 <PoppaVic> the forth "on top of" is the application. The VM is still the VM ;-)
19:29:53 <tabemann> in this VM primitives and colon words differ only in that all colon words have the same code pointer, to ENTER
19:30:11 <rdrop-exit> From the perspective of the Forth running on the VM the tokens of the VM are the opcodes of the CPU it's running on.
19:30:36 <rdrop-exit> * it's being the Forth in question
19:31:04 <tabemann> so you want more levels of abstraction?
19:31:21 <rdrop-exit> No, less.
19:32:02 <tabemann> in this VM creating a word simply adds an entry to the token table, which can be invoked like any other token
19:32:02 <tabemann> ]
19:32:35 * PoppaVic chortles
19:32:39 <tabemann> whereas you are proposing creating a CALL token which takes an argument to call
19:33:36 <rdrop-exit> Look at it this way, the primitives of a Forth are in the native code of the machine it's running on. If the Forth is running on top of a virtual machine then the primitives are written in the native code of the virtual machine.
19:35:11 <PoppaVic> I disagree, lightly: the prims can be written in the tokens; secondaries are still lists <shrug> No need to expose the native-code. Recompile the damned VM for that.
19:35:51 <rdrop-exit> Well in the case of a VM, the tokens are the native code of the machine.
19:36:00 <PoppaVic> correct.
19:36:23 <tabemann> you want a Forth layer with its own primitives where the primitives themselves are written in VM opcodes, whereas I want a Forth layer where its primitives are primitives of the VM itself and are written in the implementation language of the VM (C or assembly)
19:36:26 <rdrop-exit> e.g. DUP is a VM machine instruction
19:36:37 <PoppaVic> rdrop-exit: yes
19:36:43 <rdrop-exit> NOT a primitive from the perspective of the Forth
19:37:12 <PoppaVic> it means the VM becomes a sort of forth-processor-emulator. All to the good.
19:37:52 <rdrop-exit> Yes, it's a portable virtual machine,
19:38:17 <PoppaVic> rdrop-exit: [.$][dup][next]
19:38:20 <tabemann> with my VM of course someone could write a Forth on top of it which does not expose the underlying VM, but that would be wasteful performance-wise
19:38:44 <PoppaVic> performance-wise, I'd write it in C and drop the mike.
19:38:57 <PoppaVic> ..if I was torqued, I'd find the assembler.
19:40:16 <rdrop-exit> You can write the VM in C, sure. There's a spec, when porting the VM to a new platform the implementor is free to use whatever he wants.
19:40:29 <PoppaVic> yup
19:40:41 <tabemann> this is like if Sun had written Java such that the javac didn't compile code for the JVM but rather for a separate Java implemntation which then was written in JVM instructions
19:41:16 <PoppaVic> Happily, I never compare with jaba - unless I want to speak of fat, bloated pigs.
19:42:03 <rdrop-exit> What? The JVM doesn't care what development environment was used to generate the bytecodes, it just runs them.
19:42:24 <tabemann> yes, I know
19:42:27 <rdrop-exit> Many languages generate Java opcodes so they can run on the JVM.
19:42:37 <tabemann> my point is that javac directly outputs JVM bytecode
19:42:52 <rdrop-exit> Don't conflate the development environment and the runtime environment.
19:43:18 <tabemann> my point is the runtime environment is the JVM - not a language layer on top of it
19:43:57 <rdrop-exit> Exactly
19:44:31 <rdrop-exit> And we're doing the equivalent
19:45:19 <tabemann> for hashforth I implemented all the Forth specific stuff in VM assembly that runs on top of it, or in Forth which is interpreted/compiled by the code in VM assembly
19:45:35 <rdrop-exit> The JVM is a bytecoded virtual machine, it's native code is the bytecode (i.e. tokens)
19:46:04 <tabemann> but at the same time the VM primitives are directly callable - there aren't Forth primitives that call VM primitives which are otherwise hidden from the user
19:46:38 <tabemann> when one executes DUP one is directly executing the VM primitive
19:47:09 <rdrop-exit> When one is executing DUP one is executing the DUP opcode of the VM
19:48:08 <rdrop-exit> I would assume DUP is an opcode in any stack machine
19:48:48 <rdrop-exit> It's even an opcode in the JVM IIRC
19:49:03 <tabemann> most VMs are stack machines
19:50:25 <rdrop-exit> right, but unlike a Forth machine they usually don't separate the data and return aspects
19:50:54 <tabemann> yes
19:51:20 <tabemann> or at least they don't expose the return stack for general access
19:52:12 <rdrop-exit> So lets say the Forth you have running on the VM is Subroutine Threaded, and I define:
19:52:58 <rdrop-exit> : test dup dup dup ;
19:55:53 <rdrop-exit> In SRT the compiler lays down the three DUP opcodes
19:56:52 <tabemann> my VM could be actually programmed in a subroutine-threaded fashion, but it would be inefficient because it has no actual CALL opcode, so you'd have to do (LIT) <return address> >R BRANCH <subroutine address>, and it wouldn't properly relocate the code
19:58:05 <tabemann> it is optimized for TTC usage
19:58:36 <PoppaVic> colon would lay down a secondary, I presume DUP is a primitive of entry/exit and DUP token; so now you lay down three CALLS to the DUP primitive
19:59:53 <tabemann> I think rdrop-exit is saying that with SRT/NCI DUP would be inlined so there'd be no CALLs to it
20:00:39 <PoppaVic> sounds like a magic compiler, since inlining words is certainly not std; and inlining the "assembler" isn't either.
20:01:17 <PoppaVic> Which is not to say you can't write such a beast - it's just Not An Issue.
20:02:20 <rdrop-exit> Yes, only a pure SRT Forth would make a call to a DUP primitive, most would inline it.
20:02:40 <rdrop-exit> Since it is an single instruction of the CPU.
20:03:21 <rdrop-exit> Most SRT Forths are actually SRT/NCI
20:04:07 <rdrop-exit> The inlining opens up the possibility of peephole optimization.
20:05:25 <PoppaVic> well, it's beyond the scope of my interest/skills, but I can see it working - just not "forth" to me
20:06:51 <rdrop-exit> It's what Chuck does (in his own special ways)
20:07:32 <PoppaVic> Chuck is waiting for his Wand to arrive from Diag-on Alley.
20:08:15 <tabemann> that I did not parse
20:08:46 <rdrop-exit> Another way to look at it is that the Forth doesn't know it's running on, or compiling code for, a virtual machine. From the perspective of the Forth it's just a target chip, like any other.
20:09:04 <PoppaVic> yup
20:10:05 <rdrop-exit> If your portable VM becomes super popular, any existing Forth could target it.
20:11:55 <rdrop-exit> For example I could take my Forth and port it to your VM, or I could just write a cross-compiler/assembler that targets your VM, or both.
20:13:10 <rdrop-exit> It's like a JVM that's better suited to running Forth than the actual JVM.
20:13:53 <rdrop-exit> bbiab
20:13:59 --- quit: dddddd (Remote host closed the connection)
20:14:14 <tabemann> the main defining architectural decisions with my VM is that it has a data stack and a return stack and that it is TTC from the user's perspective (even though the VM could internally transpile the TTC code to native machine code)
20:15:34 <rdrop-exit> Like I said, you're doing TTC twice
20:17:21 <rdrop-exit> I have to walk the dogs, catch you all later. Keep on Forthin'
20:17:31 --- quit: rdrop-exit (Quit: Lost terminal)
20:18:12 <tabemann> I don't get how I'm doing TTC twice! rather it's that opcodes and user-defined tokens exist in the same namespace
20:21:34 <PoppaVic> offs, https://stackoverflow.com/questions/44014281/dissassembly-of-forth-code-words-with-see -- I'll be goddamned if that isn't the exact problem.. wtf sudo.
20:22:52 --- join: pagnol_ (~me@p54BE8803.dip0.t-ipconnect.de) joined #forth
20:26:28 --- quit: pagnol (Ping timeout: 244 seconds)
20:26:29 --- join: gravicappa (~gravicapp@h109-187-219-85.dyn.bashtel.ru) joined #forth
20:43:48 --- quit: tabemann (Ping timeout: 268 seconds)
20:52:42 --- join: whisky (~whisky@64.189.131.108) joined #forth
20:56:06 --- join: travisb (~travisb@2600:1700:7990:24e0:f928:da5c:c249:1b0a) joined #forth
21:06:51 --- nick: travisb -> tabemann
21:59:12 --- quit: whisky (Quit: WeeChat 2.3)
22:05:11 --- join: whisky (~whisky@64.189.131.108) joined #forth
22:43:13 --- quit: dys (Ping timeout: 246 seconds)
23:10:57 <proteusguy> rain1, https://www.youtube.com/watch?v=mvrE2ZGe-rs is a great video that demonstrates a correct approach to building apps with forth. That is, every app is a little DSL trying to get out! ;-)
23:15:17 --- join: dys (~dys@tmo-118-83.customers.d1-online.com) joined #forth
23:59:59 --- log: ended forth/19.02.08