00:00:00 --- log: started forth/18.06.13 00:30:53 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 00:58:24 --- join: ncv_ (~neceve@90.221.115.70) joined #forth 00:58:24 --- quit: ncv_ (Changing host) 00:58:24 --- join: ncv_ (~neceve@unaffiliated/neceve) joined #forth 02:11:37 --- quit: mtsd (Read error: Connection reset by peer) 02:16:43 --- join: mtsd (~mtsd@77.110.61.100) joined #forth 03:06:57 --- quit: dys (Ping timeout: 260 seconds) 03:39:59 --- quit: nighty- (Quit: Disappears in a puff of smoke) 03:49:26 --- join: dys (~dys@tmo-098-25.customers.d1-online.com) joined #forth 03:53:55 --- join: TCZ (~Johnny@ip-91.246.66.248.skyware.pl) joined #forth 05:01:40 --- quit: mtsd (Remote host closed the connection) 05:02:38 --- quit: TCZ (Quit: Leaving) 06:15:13 --- join: dave9 (~dave@207.213.dsl.syd.iprimus.net.au) joined #forth 06:30:17 --- quit: pierpal (Remote host closed the connection) 06:31:34 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 06:42:09 --- quit: dave9 (Quit: dave's not here) 07:36:50 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 08:00:51 --- quit: pierpal (Quit: Poof) 08:01:11 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 09:35:32 --- join: Labu (~Labu@labu.pck.nerim.net) joined #forth 10:06:22 --- quit: ncv_ (Ping timeout: 260 seconds) 10:09:29 --- quit: Keshl (Quit: Konversation terminated!) 10:23:21 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 10:33:35 --- join: ncv_ (~neceve@2a02:c7d:c5c9:a900:c1c7:50c:8461:8572) joined #forth 10:33:35 --- quit: ncv_ (Changing host) 10:33:35 --- join: ncv_ (~neceve@unaffiliated/neceve) joined #forth 10:38:54 --- quit: Keshl (Ping timeout: 255 seconds) 10:40:20 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 10:49:42 --- quit: Keshl (Ping timeout: 255 seconds) 11:14:59 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 11:24:57 --- quit: Keshl (Ping timeout: 240 seconds) 11:56:49 --- quit: ncv_ (Ping timeout: 245 seconds) 12:03:09 --- quit: pierpal (Remote host closed the connection) 12:39:35 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 12:45:37 --- join: ncv_ (~neceve@unaffiliated/neceve) joined #forth 12:52:41 --- join: Keshl_ (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 12:52:49 --- quit: Keshl (Read error: Connection reset by peer) 12:53:57 --- quit: ncv_ (Ping timeout: 276 seconds) 13:16:32 --- quit: Keshl_ (Ping timeout: 260 seconds) 13:23:20 --- join: Keshl_ (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 13:29:51 --- join: Keshl__ (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 13:30:47 --- quit: Keshl_ (Read error: Connection reset by peer) 13:38:28 --- quit: Keshl__ (Ping timeout: 268 seconds) 13:51:44 --- join: pierpa (57100917@gateway/web/freenode/ip.87.16.9.23) joined #forth 14:12:54 --- join: Keshl__ (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 14:21:41 --- join: Keshl___ (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 14:21:54 --- quit: Keshl__ (Read error: Connection reset by peer) 14:28:15 --- quit: Keshl___ (Read error: Connection reset by peer) 14:28:20 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 14:30:28 hi 14:34:59 --- quit: Keshl (Read error: Connection reset by peer) 14:35:25 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 15:12:37 --- quit: dys (Ping timeout: 260 seconds) 16:36:39 Hi Dave. 17:06:34 --- join: yuiop (2d1f5dab@gateway/web/freenode/ip.45.31.93.171) joined #forth 17:11:14 --- quit: yuiop (Client Quit) 17:18:53 --- quit: nighty- (Quit: Disappears in a puff of smoke) 17:32:44 --- quit: dddddd (Remote host closed the connection) 17:45:04 hi KipIngram 17:45:09 how's it going? 17:48:31 i read through "starting forth" and started reading "thinking forth" 17:49:55 most of it clicked, except the DOES> thing where there's different code for compile time/run time, i couldn't get my head around that after only 1 reading :-) 17:50:34 the whole extending the compiler was a bit voodoo :-) 17:56:04 :-) 17:56:13 DOES> will sink in. 17:56:56 Think of it like this. For example, VARIABLE is a defining word. When you use it, one cell of memory is allocated to hold your variable's value. 17:57:11 Then when you run the word created with VARIABLE, the run-time action is to leave its address on the stack. 17:57:31 CREATE ...compile time... DOES> ...run time... ; 17:57:51 ...compile time... happens right then, and usually involves allocating dictionary space. 17:58:21 When you run , its address is put on the stack and then the code after DOES> is executed. 17:59:24 And extending the compiler. Well, your whole system is basically represented in the data structure we call "the dictionary." Since you have access to the dictionary in a completely general way, you can write words that modify it as you see fit. 17:59:55 So we're back to what I told you the other day - you can do anything, because you're prevented from doing nothing. 18:00:13 it's the whole executing a word created with VARIABLE 18:00:39 only in forth do you "execute" a "variable" heh 18:00:52 In Forth you execute everything. 18:00:56 Except numbers. 18:01:27 When you run VARIABLE var, the word var is created in the dictionary, and its CFA is pointed to a bit of code often called dovar. 18:01:38 The effect of dovar is to place the variables address on the stack. 18:01:50 Same deal as using : word ... 18:02:04 That creates word in the dictionary and points its cfa at a routine called docol. 18:02:29 The effect of docol is to push IP onto the return stack and point IP at the address of word, which is where its definition will be put. 18:02:53 So all of the magic involves the code that gets run when a word is executed - the actual machine code. 18:02:57 Like dovar or docol. 18:03:17 Here, for example, say your system didn't support CONSTANT, but you want it. 18:03:21 You can do this: 18:03:46 : CONSTANT CREATE , DOES> @ ; 18:03:51 KipIngram: in your forth, do you have one "dovar" and variables call it, or do you copy the code for "dovar" for every variable? 18:04:25 When you run CONSTANT const, CREATE creates a word called const. It then ticks the value on the stack (your constant value) into the next cell of the dictonary. 18:04:28 That's it at compile time. 18:04:40 When const is executed, the system places its pfa on the stack. 18:04:59 but that's the location you ticked const into, so @ gets run (because you saidi DOES> @ ;), which fetches that value to the stack. 18:05:10 That would just be slower than a machine-code implemented "doconst." 18:05:12 But it would work. 18:05:22 You have thus extended the compiler by adding CONSTANT to your system. 18:05:45 I am indirect threaded - I have one dovar, and a pointer to it goes at my CFA. 18:05:55 lots of information in what you just said 18:06:02 ah okay indirect 18:06:06 In your direct threaded Forth, you could either put a jump to dovar at the CFA or you could put all of dovar at each variable's CFA. 18:07:12 If you use a jump, you will need to use your same [sp-4] trick to get at the right address again, just like you do in docol. 18:08:08 KipIngram: on a side note, i saw that [IP-4] trick in a forth document 18:08:22 so i didn't invent it :-P 18:08:35 If you put the whole of dovar before the cell allocated for the variable, you can use a pc-relative op that will load the right address into your tos. 18:08:49 Oh, I long since gave up on inventing anything. 18:09:07 I've had some damn good inspirations over the years too - just none that hadn't already been had by someone esle. 18:09:08 else 18:11:06 I've nudged mine forward over the last couple of days. I'm still just running the same bit of test code and then exiting, but now I'm doing it from a "process block" that I allocate at start up and "prepare" appropriately. So it's closer to working the way it's intended to in practice. 18:11:14 http://www.bradrodriguez.com/papers/moving2.htm search for "DTC-NEXT" and about 30 lines down 18:11:32 I use resb (reserve bytes) in the assembler to create a huge .bss section, and I"m treating it as a heap of 64kB blocks. 18:11:47 Each process will get one of those at birth for its private extensions to the dictionary. 18:12:11 oh sounds like you're making a multi-process OS in forth 18:12:19 That's the idea, yes. 18:12:42 that's over my head :-) 18:12:49 I've decided that what I'm going for is something suitable for implemented the "back end" of enterprise grade applications, like database engines and so on. 18:13:58 jeez 18:14:03 I'm also hoping to support things like I/O redirection, pipelines of processes, and so on. 18:14:19 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth 18:14:36 I mentioned that I hope to build a completely from scratch computer someday - I'm wanting this to be suitable as its operating system. 18:14:54 I expect to have many cores, so I need a way to put them all to use simultaneously. 18:15:24 i bought a couple of books on operating systems, but they're too unix 18:15:47 But I don't want to "rely" on custom hardware design so much that it won't run without it - I'd also like to be able to 1) run it on top of Linux or MacOS or 2) run it on a conventional multi-core machine in a bare metal way. 18:16:15 oh right you've got a mac 18:16:32 were you able to get my code to work on it? 18:16:54 Yeah. I've spent this afternoon studying how GNU screen handles the window buffers of all of its windows. 18:17:00 What sort of data structures and so on. 18:17:13 Because it does a good job of popping hte right content onto the screen when you switch windows. 18:17:39 these are what worked for crc on FreeBSD: https://ufile.io/qjtbm https://ufile.io/7qao3 18:17:53 The data structures for that wind up closely related to stdin, stdout, i/o redirection, piping and so on. 18:18:38 i used screen once years ago when i only had telnet access to a machine while i was at uni 18:19:14 my friend gave me his password to computers i didn't normally have access to, and i used to run ircii on screen 18:20:19 i always thought it should have been more integrated into the OS... like the OS should have presented "virtual" terminals automatically 18:20:20 I really like screen. 18:20:34 Lots of folks like tmux instead, but screen has satisfied my needs just fine. 18:21:14 Well, the os DOES do that, for different users. 18:21:25 Screen just lets you a unique user extend that capability. 18:22:38 dave0: so you are interested in how oses work? Heard of Capros or seL4+Genode ? 18:23:06 not capros or genode, but ive heard of seL4 18:23:29 Exactly how functionality got partitioned between kernel and user space is a long sordid story of gradual evolution, spanning decades. 18:23:32 i know they proved seL4 correct, the first kernel to do so 18:24:56 Early on, stuff was missing from the kernel so innovative folk wrote userland support for it. Once that existed, it got down-prioritized by the kernel developers, because "there is already a way to do this." 18:25:03 Stuff like that. 18:26:19 KipIngram: yeah, know of that. 18:26:43 termios had a lot of that sort of thing happen around it. 18:27:06 there is an old IBM 390 os called Keykos that is much more sensibly made imo 18:27:11 i saw that with x-windows.. i think video drivers should be in the kernel, but because x already has drivers in userspace, they wont put it in the kernel 18:28:27 video drivers or drivers at all should NOT be in kernel space at all 18:28:48 that's a different argument for another day lol 18:28:50 ^ I agree with Z. 18:29:03 I really like the micro-kernel idea. 18:29:47 shame that context switching was made so expensive on most contemporal architectures. 18:30:30 Yeah - I'm trying to keep that very lean on this that I'm writing. 18:30:51 (ARM has nice feature of Address Space id. Both a priviledged register and it gets prepended to the virtual address before it goes into the TLB) 18:32:07 on something like x86, just init the minimal hardware and then enter virtual processor emulator. A virtual processor that is better designed than x86 18:32:57 I suspect x86 stopped being "designed" long ago and has since "grown." 18:33:22 you mean "kludged" 18:33:29 or even "bodged" 18:33:38 Yes, correct. :-) 18:33:57 A process with all of the chaos normally associated with wild growing life. 18:34:15 And as a result we get stuff like Meltdown. 18:34:36 nono, there is method to the chaos of wild growing life. None what so ever with x86 18:34:41 Left and right hands both happy with what they're doing, but they crucify each other. 18:35:45 "We don't have to check privilege on speculatively executed instructions - we'll let the commit hardware catch that for us." 18:35:50 Ooops. 18:36:45 GreenArrays went into the more sensible direction of having simple processing units that communicate with neighbours 18:36:58 ABSOLUTELY. 18:37:08 but I think they went a bit too far in making it simpler 18:37:10 The industry should have bitten the bullet and taken that path decades ago. 18:37:37 Yeah, those cores are extremely minimal. 18:37:39 nope, must run the old single exec-threaded code fast 18:38:09 Sure - 15 years from now doesn't matter - only the next quarter or two. 18:38:22 there is even a programming paradigm that works well with many medium simple processing units though. 18:39:18 it is called Flow Based Programming and originates from using unit machines and card decks in a setup the reminds one of processing lines in a factory 18:42:34 Interesting - that flow based programming looks somewhat like the thoughts I've had for ganging my cores together in this thing I'm working on. 18:42:41 I'll have to read up on that more thoroughly. 18:43:59 I just spent most of this afternoon thinking about "streams," and even chose that word for the things. 18:44:17 I was thinking of it more in the context of stdin, stdout, etc. 18:44:55 But I started to see that I needed to define what those were, and develop a good data structure for them, before going much further. 18:45:00 well, some people try out FBP via pipelines in shell with tees and named fifos 18:45:14 Makes sense. 18:45:36 I feel that a lot of the power Linux offers comes from that facility. 18:45:37 you could use SEXPs or even msgpck 18:50:44 In my case the stream structure (well, output streams at least, and I think I want them all to be the same) have to work well with fast re-writing of the screen when I switch the console to a process. 18:51:05 So I'm thinking about a linked list of "lines" - the payload of the line has to be directly writable with the MacOS "write" system call. 18:51:17 KipIngram: enter the fun that are ansi control codes 18:51:27 So to redraw a screen I check how tall it is, skip back that far in the output stream using the links, and then write those payloads. 18:51:52 Right - if I want to be perfectionist about it I have to recognize the cases where one of those payloads might move the cursor up or down. 18:52:02 So that simple "skip back that many lines" doesn't work. 18:52:52 I'm willing to let that slide if I have to; it's a corner case. But I'll at least make a run at it. 18:53:10 I'd rather find a way to handle it without having to make that particular code understand all of the control codes itself. 18:54:09 If I structure input streams identically then I have a data structure I can use to implement a command line history fairly easily too. 18:54:58 So when a process runs KEY or EMIT, it won't necessarily do anytihng involving the physical console - it will just work with those streams. 18:55:20 Somewhere there will be code that does manage the physical console that will also work with the streams of the "console owning" process. 18:57:10 well to an electronics minded guy like me, a physical console could be just two wires TX and RX 18:57:59 Yes. My background is also in EE. At least right now, working under MacOS, the "physical console" is a couple of system calls. 18:59:03 I dickered around a couple of months ago with termios and trying to figure out a smooth way of getting a non-blocking check for available keyboard data. 18:59:19 Wasn't completely happy with where I got to before getting busy with other stuff. 19:07:02 one work around I heard was someone who wrote a tiny c program that used a small library to check its stdin for available keystrokes and on its stdout it constantly wrote the SYNchronous idle ascii char (0x16) unless a key was written then it outputed whatever that key was. 19:07:34 Then he just piped that to his forth vm process 19:52:14 --- quit: pierpa (Quit: Page closed) 20:04:49 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 21:03:26 --- join: karswell_ (~user@89.39.107.201) joined #forth 21:06:41 --- join: smokeink (~smokeink@59-125-75-78.HINET-IP.hinet.net) joined #forth 21:08:59 http://wickedsource.tumblr.com/post/66804897524/1-the-forth-challenge-what-is-forth-forth-is : x + ; : y postpone x ; immediate I understand that this y gets executed when it's in other words definitions and the effect is that x's code will be compiled into those words . But what does the word y do when I execute it in the repl ? does it have any effect? 21:09:46 y ok \ gforth just says ok , but I want to know whether this has any side effect or not 21:24:33 --- quit: karswell_ (Read error: Connection reset by peer) 21:25:31 --- join: karswell_ (~user@89.39.107.201) joined #forth 21:48:52 --- nick: karswell_ -> karswell 22:03:18 --- join: karswell_ (~user@89.39.107.201) joined #forth 22:03:44 --- quit: karswell (Read error: Connection reset by peer) 22:13:37 --- nick: karswell_ -> karswell 22:13:56 --- quit: ThirtyOne32nds (Ping timeout: 264 seconds) 22:59:25 --- quit: Labu (Quit: WeeChat 2.0.1) 23:59:59 --- log: ended forth/18.06.13