00:00:00 --- log: started forth/21.04.21 00:28:18 Oh, just things like memory layout, any tag bits, and so on. To whatever extent there's a vm involved, its spec, etc. 00:28:45 How it "works," under the hood. 00:28:55 That's the part of Forth I most enjoy as well. 01:41:09 --- join: X-Scale` joined #forth 01:41:33 --- quit: X-Scale (Ping timeout: 240 seconds) 01:41:42 --- nick: X-Scale` -> X-Scale 03:05:58 --- join: f-a joined #forth 03:07:46 https://github.com/schani/forthlisp 03:07:57 mhhhhhhhhhhh 03:09:41 --- join: andrei_n joined #forth 03:09:50 --- quit: andrei-n (Read error: Connection reset by peer) 03:49:02 --- quit: andrei_n (Read error: Connection reset by peer) 04:05:52 --- join: andrei-n joined #forth 05:55:51 --- quit: Zarutian_HTC (Remote host closed the connection) 06:02:26 --- join: tech_exorcist joined #forth 06:19:33 --- quit: f-a (Quit: leaving) 06:34:58 --- quit: dave0 (Quit: dave's not here) 06:36:16 If you can imagine it - you can find it in gforth... 06:36:18 :-) 06:37:06 When I burned the hamburger buns the other night if I'd thought to search I could probably have found a gforth bun recovery package. 06:39:03 The gforth guys have also conntributed some nice research over the years. Performance studies and things like that. Definitely have made a mark. 06:43:47 f-a: that's missing both a copyright notice and a license :( 07:51:36 --- join: f-a joined #forth 08:31:35 --- quit: tech_exorcist (Remote host closed the connection) 08:32:25 --- join: tech_exorcist joined #forth 08:38:34 --- join: cess11 joined #forth 08:52:08 --- join: hosewiejacke joined #forth 08:56:48 --- quit: hosewiejacke (Ping timeout: 240 seconds) 09:47:14 --- join: hosewiejacke joined #forth 09:47:30 --- quit: hosewiejacke (Remote host closed the connection) 09:59:09 --- join: Zarutian_HTC joined #forth 09:59:09 --- quit: gravicappa (Read error: Connection reset by peer) 10:00:36 --- join: gravicappa joined #forth 10:01:27 Well, just got the first covid jab. 10:01:31 About an hour ago. 10:02:14 congrats 10:07:34 well done KipIngram 10:07:39 my mum got AZ 10:07:47 dad pfizer 10:15:33 i was gonna get one but canceled since i already had it in 2018 10:16:23 2018? 10:19:08 KipIngram: yay 10:19:29 i kid 10:19:29 the sooner everyone gets it quicker we return to normalcy everywhere 10:41:50 This was Moderna. They said that each of the two shots gets you about half the benefit. So in a couple of weeks I'll be around "half protected." 10:54:31 I really like the format of that doc that dave0 posted the link for last night. Long, massively detailed narrative comments, with the code interspersed. And buildable. 10:54:49 And they didn't cram a bunch of comments into the code - where there's code, it's CODE. 10:55:13 That feels like what I want to do when I get my system so it can rebuild, in the blocks file, not in the nasm source. 10:55:59 Well, they do have some comments "interleaved" with the source. It's just a minority of the commenting. 10:56:10 Most of it's in big block comments between code sections. 11:02:40 Those big block comments are exactly the sort of material I envision putting in shadow screens alongside my code. 11:03:35 Or in a "comments database" if I implement such a thing. Main advantage that would have would be that the comments could be as voluminous as I wanted them to be - not limited to a "block per block of code." 11:08:25 --- quit: f-a (Ping timeout: 252 seconds) 11:10:28 --- join: f-a joined #forth 11:48:26 Ok, I'm going to work on that some now. Start hasing out the architecture of this "comment database." 11:50:03 I think each "attach point" in the code will just be a (block / line / col) triple, and the comment entry itself will be located at (block / line). And perhaps I'll specify there how many lines the block is, and if it needs to flow to another block I'll be able to chain one on somehow. 11:50:49 Each entry will have some attributes - I envision being able to flag a comment as "inline" and be able to turn off and on the rendering of inline comments. 12:28:42 Feels to me that something along the lines of a B-tree might be in order here, for organizing all the data. 12:41:59 ive always thought autogenerated stack pictures would make life so much better 12:42:08 in a separate pane to the right 12:59:32 --- quit: gravicappa (Ping timeout: 252 seconds) 13:05:59 that would be very un-forth like though 13:16:49 Yeah, this would give me a place to put stack effect comments as well. The whole idea is kind of un-Forthlike, but really mostly due to "tradition. I guess shadow screens aren't reall un-Forth. 13:24:57 --- join: kiedtl|ltbx joined #forth 13:53:15 --- quit: jedb (Quit: Leaving) 13:53:54 --- join: jedb joined #forth 14:02:59 --- join: Gromboli8 joined #forth 14:04:54 --- quit: Gromboli (Ping timeout: 240 seconds) 14:04:55 --- nick: Gromboli8 -> Gromboli 14:11:58 --- quit: mtsd (Ping timeout: 245 seconds) 14:23:14 --- quit: andrei-n (Quit: Leaving) 14:35:05 --- quit: tech_exorcist (Remote host closed the connection) 15:09:18 --- quit: f-a (Ping timeout: 252 seconds) 15:14:03 --- quit: nihilazo (Ping timeout: 240 seconds) 15:41:21 --- quit: tabemann (Remote host closed the connection) 15:41:37 --- join: tabemann joined #forth 15:54:48 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 15:54:52 --- join: Zarutian_HTC1 joined #forth 16:14:46 --- nick: Zarutian_HTC1 -> Zarutian_HTC 17:04:40 --- join: dave0 joined #forth 17:05:23 maw 17:09:57 --- quit: dave0 (Quit: dave's not here) 17:17:12 so i guess maw means bye as well as hello 17:17:22 KipIngram, thought any more about building a calculator? 17:40:27 is there sort of a standard way to drop your current return frame in Forth? Or is that very implementation dependent? 17:42:00 or, what I meant to ask was if you could make a call without building a return frame 17:42:20 like, tail call recursion but at an arbitrary place 17:43:31 maybe a word to jump to an arbitrary address and continue executing, though that seems rather implementation dependent 17:49:49 lispmacs[work], how about RDROP? 17:51:01 drop the return address so that when you hit the end of the word it doesnt returned to the word that called it but to the word that called that word 17:53:21 MrMobius: I don't think rdrop would work, per my requirement, since you would have to do the rdrop after getting into the word you had called 17:53:31 hmm ya 18:03:20 19 18:03:22 oops 18:07:07 the problem with RDROP is it breaks if the calling word was using the rstack for something other than just a return address 18:09:09 yeah, I definitely wouldn't want to call rdrop from within the called word 18:09:41 I was thinking like a special version of EXECUTE that doesn't leave a return frame/address on the return stack 18:10:57 seems like it would be real easy for the FORTH system designer to make such a word 18:11:51 but I don't know if there is any provision for that in anything like core or core-ext 18:12:54 it would be real handy for things like recursion and mutual recursion 18:13:12 like my mutual recursion example in gforth: 18:13:14 https://bpa.st/TPBA 18:24:01 --- join: boru` joined #forth 18:24:03 --- quit: boru (Disconnected by services) 18:24:06 --- nick: boru` -> boru 18:46:47 --- join: eli_oat joined #forth 18:51:21 --- quit: eli_oat (Client Quit) 19:00:39 I have words that can do a double return, but I take responsibility for only using them when it's not going to cause a problem. 19:02:40 Since I started using this stack frame capability that I designed, I do very, VERY little "stack twiddling." I haven't run into a need for a >R ... R> action. 19:17:29 --- join: Zarutian_HTC1 joined #forth 19:17:29 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 19:48:13 --- quit: sts-q (Ping timeout: 245 seconds) 19:52:41 --- join: sts-q joined #forth 20:19:40 --- join: dave0 joined #forth 21:14:54 --- join: mtsd joined #forth 21:50:22 --- part: Regenaxer left #forth 22:02:49 --- quit: Keshl (Read error: Connection reset by peer) 22:03:23 --- join: Keshl joined #forth 22:08:21 --- join: andrei-n joined #forth 22:28:22 MrMobius, I think autogen stack pictures would be very "forthy". Can't see any downside to it at all and would absolutely add to the correctness of the app. 22:34:43 You're talking about deriving the stack motion specification from the definition itself? 22:35:48 I've thought about that. In particular, I once had an idea for a "typed Forth" of sorts, and you would specify the effects on the type stack of each native word, and then the compiler would have to figure out the effects of new words on its own. 22:36:13 The idea was that you could overload word names by letting the operand type help choose the word. So 22:36:15 a b + 22:36:29 would add ints if a and b were ints, or add matrices if a and b were matrices. 22:36:38 Because the system would know what a annd b were. 22:36:59 It also allows compile time detection of over/under flow. 22:37:35 This wasn't something I envisioned building into a base system - I viewed it as a sort of "application shell" that I might implement on top of the base. 22:38:06 The difficulty arises with words like ?dup which have variant effects on the stack. 22:38:16 Until execution time you don't know what its effect is goinng to be. 22:38:36 And I very much wanted this done all at COMPILE time - not sittinng there effecting run-timer performannce. 22:52:56 --- quit: jedb (Quit: Leaving) 22:53:21 --- join: jedb joined #forth 22:57:02 MrMobius: Not any really recent serious thoughts. I'm focused mostly on the software side of things right now. 22:57:13 (re: building a calculator) 23:01:11 I think about it from time to time, but eventually wind up asking myself what I'd really ever DO with it. 23:01:47 I really haven't put a calculator to SERIOUS use since college. 23:04:51 --- join: nihilazo joined #forth 23:50:35 --- join: lispmacs joined #forth 23:59:59 --- log: ended forth/21.04.21