00:00:00 --- log: started forth/21.04.22 00:12:40 --- join: jedb_ joined #forth 00:16:02 --- quit: jedb (Ping timeout: 252 seconds) 00:26:13 --- join: gravicappa joined #forth 01:22:51 --- join: hosewiejacke joined #forth 01:27:08 KipIngram, your typed forth is pretty close to what I'm doing with ActorForth. Has overloading and also pattern matching! 01:27:41 The difference is I am building a type system first, and a forth on top of it. 01:40:33 --- join: jess joined #forth 01:40:34 --- join: X-Scale` joined #forth 01:41:58 --- quit: X-Scale (Ping timeout: 245 seconds) 01:41:58 --- nick: X-Scale` -> X-Scale 01:49:49 --- join: f-a joined #forth 04:16:26 --- quit: hosewiejacke (Ping timeout: 268 seconds) 04:19:49 --- join: hosewiejacke joined #forth 04:31:34 --- quit: dave0 (Quit: dave's not here) 04:50:43 for the auto generated comments, i was just thinking about showing the stack picture line by line 04:51:48 and of course you cant show anuthing if it depends on runtime data like ?dup so it would only work on some lines 04:53:40 one of the biggest pains is having more than 3 locals in a word and having nested loops. you waste more time on stack juggling than actually doing work. forth is really bad at that kkind of thing so you need the stack pictures 04:56:08 --- quit: hosewiejacke (Ping timeout: 240 seconds) 04:57:30 --- join: crest_ joined #forth 04:58:13 --- quit: crest (Read error: Connection reset by peer) 05:11:41 I think my plan (when I am forthing again, I'm on my lisp holiday), is to use \\ for documentation comments, then consecutive \\ lines and the next line of code will get added to an HTML file 05:11:58 This is something that can be trivially parsed in Forth or some other language 05:12:20 Probably easy to do in Forth with recognisers (ewww standard forth get out!) ;) 05:27:02 --- join: hosewiejacke joined #forth 05:33:43 --- quit: hosewiejacke (Ping timeout: 260 seconds) 05:38:53 --- quit: Vedran (Ping timeout: 252 seconds) 05:52:54 --- quit: f-a (Ping timeout: 265 seconds) 05:54:30 --- join: f-a_ joined #forth 06:04:28 --- quit: f-a_ (*.net *.split) 06:04:28 --- quit: jess (*.net *.split) 06:04:28 --- quit: mtsd (*.net *.split) 06:04:28 --- quit: Zarutian_HTC1 (*.net *.split) 06:04:28 --- quit: tabemann (*.net *.split) 06:04:28 --- quit: kiedtl|ltbx (*.net *.split) 06:04:28 --- quit: xybre (*.net *.split) 06:05:54 --- join: f-a_ joined #forth 06:05:54 --- join: jess joined #forth 06:05:54 --- join: mtsd joined #forth 06:05:54 --- join: Zarutian_HTC1 joined #forth 06:05:54 --- join: tabemann joined #forth 06:05:54 --- join: kiedtl|ltbx joined #forth 06:05:54 --- join: xybre joined #forth 06:09:36 MrMobius: Try out stack frames. It's made stack juggling a thing of the past for me. 06:15:05 --- join: tech_exorcist joined #forth 06:15:13 --- quit: jess (Quit: Reconnecting) 06:15:46 --- join: jess joined #forth 06:21:51 MrMobius: Here are my pertinnent definitionns. There's some macro naming going on here, so don't hesitate to ask if you need anything clarified. 06:21:53 https://pastebin.com/ZTzRj2SF 06:22:20 --- quit: lispmacs[work] (Ping timeout: 252 seconds) 06:23:34 } restores the data stack pointer to what it was when { executed, but it also expects a parameter and drops that many *additional* stack items. 06:24:06 So you can create, use, and get rid of a new stack frame at any time with 06:24:20 { ... use s0-s4 here ... } 06:24:39 s0-s4 simply give the addresses of consecutive stack cells. 06:24:51 relative to the "frame register," which is set by { and restored by } 06:25:29 I was thinking "slot 0," "slot 1," etc. with that naming. 06:26:09 KipIngram, and s0-s4 is stored on the return stack? 06:26:23 No, they just put addresses on the stack. 06:26:32 There's no "content" of s0-s4 to save. 06:26:39 They're just offsets from the frame pointer. 06:26:56 So you could store something in the third item down from the frame pointer with s3 ! 06:27:22 so the data stack then? 06:27:22 They're 'local variable' words. 06:27:41 s0-s4 aren't registers with things stored in them. 06:28:05 They're spots in the stack, relative to the frame register, which does hold a value. 06:28:19 { save the old frame pointer on return stack; } recovers it. 06:28:24 and the frame register is separate from the data stack pointer? 06:28:26 So you can nest these frames. 06:28:28 Yes. 06:28:44 Because you want s0-s4 to keep "meaning the same thing" even while you diddle around the stack. 06:29:11 interesting 06:29:13 When I first made this system I offset from the stack pointer, but that got horribly confusing, because as soonn as you change the stack, the "content" of si changes. 06:29:25 The frame pointer stays put, even as the stack pointer ranges up and down. 06:30:00 It's a "stable reference point" within the { ... } frame, and it defines what addresses s0-s4 are bound to. 06:30:36 Another thing I did that was helpful in reducing stack commotion was to include words based on Hewlett Packard calculator langage. 06:30:51 then you can define s0! and s0@ 06:30:57 So as a synonym for swap, I had x<>y, but then I also had x<>z and x<>t. 06:31:05 I could, yes. 06:31:27 I thought about doing that from the jump, but decided to go with this "address based" approach, just so I wouldn't need such a huge slew of words. 06:31:58 You can do anything with s0-s4 you want - they're just addresses. 06:32:26 I defined a couple of new words that work with any variable. 06:32:44 seems like load and store are the main advantage of those 06:32:53 Like we've always had +! but I added -! and also 1+! and 1-! and some other powers of two as well. 06:33:00 Great for updating s0-s4 when they are pointers. 06:33:29 Like I can step s3 through an array with s3 8+! 06:34:00 --- join: Vedran joined #forth 06:34:02 Purely convenience; I could already have said 8 s3 +! 06:34:12 where did you get this idea? im gonna use it and should say where it comes from 06:34:33 Well, I just made it up. Obviously I've read all kinds of things, but I defined this out myself. 06:34:39 So you can just credit me if you want to. 06:35:05 Are you interested in my "other frame"? I have a second flavor of frame that lets me return up from way deep in a bunch of nested code to a pre-defined exist point. 06:35:12 That's {| and |} 06:35:25 It was enormously useful for dictionary search. 06:35:34 how does that work? 06:35:46 The "normal case" that I actually coded for was to walk the structures without finding a match. That's all the code was prepared to handle. 06:35:58 Then if I do find a match, I |} my way out, from the success point. 06:36:04 Let me pitch those into pastebin as well - one sec. 06:36:36 --- quit: proteus-guy (Ping timeout: 246 seconds) 06:36:57 https://pastebin.com/M1kYP7rG 06:37:04 That setup requires a new register. 06:37:22 I call them "exception frames" and it's the "exception frame register." 06:37:50 It restores both data AND return stack to where it was at {|, but it brings the TOS value from the jump out point back up to the top. 06:38:10 To use it, you say {| ... ... code ... ... |} within a single efinition. 06:38:26 But then, many layers of code lower, down in any sort of complex code structure, you can have a second |} 06:38:44 And it will "send you" back up to the first |} 06:39:18 --- quit: f-a_ (Quit: leaving) 06:39:27 What it mean in my dictionary search code was that all those layers of code didn't have to think about carrying a success result back up through themselves. 06:39:41 It reduced the number of cases they had to consider by one, and that vastly simplified the code. 06:39:42 --- join: f-a joined #forth 06:40:06 And by the way, I used several of the { ... } frames along the way, and it has a very useful feature of "cleaning up" your stack for you. 06:40:21 So you avoid having to drop a bunch of crap when you discover something you need to act on. 06:41:25 So I wrapped { .. } around each bit of "data structure traversal" code. Walkingn the linked list of vocabularies, walking the linked list of words in each vocab, and iterating over the character of words. 06:41:57 When any loop "terminated" (end of word, end of list, etc.) I used } to clean up any artifacts from the stack so the next higher loop could do it's "next" dance. 06:42:32 And at the bottom where I finally found a match, I got the match pointer in TOS and did |}, and that took me all the way back up to the exist point of the topmost word. 06:43:00 I don't want to claim that I did these and no one ever had - I'm sure these ideas are already out there. 06:43:13 But I concocted them on my own; didn't "see them" anywhere. 06:44:10 The operation of |} is slightly subtle. It doesn't really transfer control back up instantly. It modifies the return stack so that when you hit the next ; it will be as though it was the ; from back at the top, instead of the one you're actually executing. 06:44:12 Make sense? 06:44:31 It doesn't do anything weird to the instruction pointer, or save it, etc. 06:44:37 Only the return stack and the data stack. 06:44:56 Jesus, I feel a bit like a truck ran me down. 06:45:03 Aftereffect of the jab yesterday. 06:47:36 My FIND imlementation is here: 06:47:37 https://pastebin.com/t289RZ77 06:47:50 It provides an example of {| ... |} in action. 06:48:16 That little bit of code handles the linked list of vocabularies, the linked list of words in each, and the character loops of comparinng the words. 06:48:20 I was pretty pleased. 06:48:59 --- join: proteus-guy joined #forth 06:49:00 So down in "gotit," there's the second |}. It's immediately followed by the ; of gotit. 06:49:03 You do execute that ;. 06:49:17 But it *does* what the ; after the upper |} would have done. 06:49:29 Returns you to the caller of (find). 06:50:03 If you do NOT find the word, anywhere, then eventually you will execute the upper |}, but anytime you succeed you never reach it. 06:51:15 My code feels much more terse to me than it used to, and I give the credit to { ... } and {| ... |}. 06:51:54 I'm sorry, that code is all strewn with my conditional return and conditional looping mechanisms - ask if anything is unclear. 06:52:12 Notice there are no traditional control structures. 06:52:19 No IF ... THEN, or any of the others. 06:52:33 Conditional return and conditional looping obviate the need for those, I think. 06:52:50 And conditional return as a control mechanism promotes short definitions, too. 07:02:46 I added the conditional returns and what not a couple of Forths ago. 07:03:00 I added the { ... } to the last one, but used it only minimally. 07:03:38 This go round I've realized that using it heavily has a real benefit, and this go round is the first time I've had the {| ... |} also, though I've played some ad hoc r> drop games in the past. 07:03:51 But those were always exceptional cases. 07:03:58 Not something I used as "part of how I program." 07:04:27 These days it is part of me - I start thinking about return structures when I first start designing a bit of code. 07:28:55 interesting 07:32:47 do you ever define local words for s0, s1, etc? 07:33:00 so you can refer to them by name 07:39:23 No, not to date. However, I have a loose vision of a fancy compiler that would bind those to names specified in a stack effect like comment. 07:39:41 That would be a compile-time feature; once the code was compiled it would be back to s0, s1, etc. 07:40:10 But so far I just note down or remember what they all are, and since they don't change the way they would if they were referenced off of the stack pointer it works pretty well. 07:40:29 right. i can think about how to do it with the dictionary but i dont want to lose space if theyre only used temporarily 07:40:41 What I tend to do is define "short words' that are more than just variable wrappers. For example, in my number convnersion code I have this: 07:40:47 : set s1 or! ; 07:40:56 Which calls out s1 as where my "flags" go. 07:41:21 That's a little like what you suggested - it just includes addinng a little functionality at the same time. 07:41:39 --- part: f-a left #forth 07:41:45 ya that works though its still hard on readability which forth generally fails hard at 07:41:47 Right - if I ever do that, it will be using some dynamic compile time structure that keeps up with it for me and then is discarded. 07:41:49 despite other advantages 07:42:05 Along the same lines, there then occurs 07:42:10 : clr not s1 and! ; 07:42:15 : bits s1 @ and ; 07:42:18 and so on. 07:42:45 It's a set of words for flag manipulation. 07:42:47 i understand. thats just not a good solution for a lot of cases 07:42:53 but already better than what you usually have 07:42:53 Sure. 07:43:41 So far I haven't needed an s5. 07:43:51 and of course it would be possible to have sn 07:44:03 Which would be a lot like PICK, except just leaving an address instead of the content. 07:44:11 I don't have that either, though. 07:44:24 what you need is a temporary dictionary that gets dropped on ; 07:44:29 Generally speaking I agree with the Forth philosophy of not having too many active stack items at oncne. 07:44:46 I've just found that once in a while it seems unavoidable. Maybe I'm just not good enough yet. 07:44:52 Right. 07:44:56 I actually had that in my last one. 07:45:05 You notice some of those words have .: instead of : 07:45:10 heh that "philosophy" is like a lot of stuff - not any great insight but instead pretending like an insurmoutable shortcoming of the language is somehow an advantage 07:45:19 In my last Forth .: defined the header in an allocated buffer that I could later get rid of. 07:45:25 other wise you descend into PICK/ROLL hell. i dont buy it for a second 07:45:58 This time I've foregone that complexity - I just have .: set a bit in the header, and later I execute a word .wipe that goes through the search path and unlinks any words with that bit set from the search path. 07:46:11 So I don't actually get the memory back. 07:46:20 But I do get the words out of the namespace. 07:46:25 of course it's unavoidable. it really depends on what youre doing. no need for many stack items if youre blinking LEDs and then those guys pretend they have programming in all spheres at all times mastered 07:47:06 for even medium complexity stuff you need a lot more than that on the stack and there's no way around it other than using global variables or "local variables" as you see them in Starting Forth etc 07:47:22 Take as an example QUERY where you have a command line history like Linux gives you. 07:47:56 You have a buffer pointer, a cursor position, a current size, a max size, and you have pointers that may walk along the command history. 07:48:02 And you have characters coming and going. 07:48:10 ya losing that memory is not such a big deal on a pc but is a deal breaker for me on a 6502 for example 07:48:20 That's a slew of things to work with, and at least part of the time you really at least almost need them all at once. 07:48:32 The { ... } thing was just a LIFESAVER in that situation. 08:04:28 --- quit: andrei-n (Quit: Leaving) 08:04:31 Oh, yes - in an embedded application you can't afford to toss memory aside. 08:04:48 Well, you might be able to. Depends. But certainly in some applications you can't. 08:04:59 Of course, in those cases you might not have a dictionary on the target at all. 08:05:20 I've never really dug into the whole "tethering scenario," but it clearly seems to pose some unique requirements. 08:05:56 I expect most of the things I build one of these days to have fairly significant computing resources on-board. 08:06:35 I generally plan to have the whole system on-board, and I'll connect to it with a bluetooth serial connection or something. 08:07:07 right. you would want a "headerless" forth for a lot of embedded stuff. on my calculator i have a dictionary since the user is typing in commands and defining words 08:07:36 sure. if its a fun project, the sky is the limit. no reason to skimp just to save a dollar on memory 08:09:28 tethering is interesting because you need some kind of device to program the target if its not programming itself 08:10:31 so you can compile everything from scratch like C and let the board you bought reflash everything or you can use the tether to interact with the target and program it 08:17:30 Right. 08:34:26 not a headerless forth, a teathered forth where the headers are all on the host not the target :) 08:36:44 --- join: f-a joined #forth 08:44:36 Yes. 08:45:23 When I've thought about that, I've always felt that you *also* want host-side words blended in as well. You're running your host in Forth, and then you have these other words you use to craft your target image. 08:46:32 One of the next things I do will be the compile support. I want to be careful about that - I don't want to write it so that it's hard to "redirect" the compile output to a secondary image, rather than the running system. 08:46:44 But most of the time I will want compiling to affect the running system. 08:46:53 So I need some kind of a "switch." 08:47:45 It's really the same issue - the fact that the target will run on the host as well is really a non-issue. It's still a "different system" from the one you're working in. 08:48:28 I think it will just be a matter of 1) knowing where HERE is in the image at all times and 2) knowing the base address of the image, so that I compile offsets from there. 08:49:14 I actually have two HEREs and two "origins." One for word bodies and data; one for headers and CFA/PFA pointer pairs. 08:50:23 And after this little dip in the Lisp pool I may wind up adding a third region, as the "Lisp region." 08:50:27 We'll see. 08:50:51 --- part: f-a left #forth 08:51:02 Just having that off to the side and being able to intersperse Lisp code with Forth code will be simple. What I'm unsure of is exactly to what extent they'll "interact with one another." 08:54:37 It would be fairly easy to have the input parsinng stuff "switch gears" inside ( and ). 08:55:12 the distinction between host and target should be utterly seamless 08:55:13 host 08:55:16 : foo .... ; 08:55:18 target 08:55:21 : foo .... ; 08:55:30 host foo 08:55:32 target foo 08:56:09 but words like dot on when target is the taget are somewhat more complex 08:56:31 a dot needs to fetch the top item of the targets parameter stack and display it on the host 08:56:46 Yes, I agree with that, mark4. 08:57:05 mark4, thats no different than storing the headers on your pc so it's still headerless with respect to the taget :) 08:57:27 i spent the last 2 weeks writing my json parser and worrying over it and changing this and chaning that and fixing this over here and NOT RUNNING IT at all lol 08:57:31 Or not - you could use that same syntax with the headers bi-located. 08:57:51 started single stepping it last night at like 1am and it worked flawlessly except for one small mistake i made which i fixed and went to sleep 08:58:07 mark4: That's ok - I looked at my number conversion code in a vim buffer for well over a week before finally pecking it in and shaking it down. 08:58:12 then there was another minor snafu that i fixed and now as best i can tell the entire freeking thing works perfectly lol 08:58:23 Congrats. :-) 08:58:35 * KipIngram totally believes in "up front 'thought' work." 08:58:52 yea i always fret over my code for a while before i exerecise it. constantly goving over every inch of it over and over and over again 08:59:01 Righto. 08:59:06 I know exactly what you mean. 08:59:13 makes you so familiar with it that when you are debugging and you see it zig when it should have zagged you just KNOW where you went wrong :) 08:59:22 Yes. 09:15:35 mark4: Maybe the thing to do re: the situation you described above is to have a finer grain of control. You'd have host and target words like you said, and new definitions would definitely go to the current one. But in cases where a word is found in both dictionaries, maybe you'd also like to specify how to resolve that. You could have "define in target, execute from target," and "define in target, execute 09:15:37 from host." Finally, if you wanted to override that preference, you would have a way to do that too - it would keep effect for one word. 09:15:50 I don't know. I haven't tried that out. Might be too cumbersome or error prone in practice. 09:16:19 The problem only arises when you're interpreting if you're making a definition for the target, then all of its content has to come from the target. 09:16:26 I think. 09:16:30 a target word cannot refer to a word on the host and vice versa 09:16:38 if you want to run foo on the host you type host foo 09:16:40 ^^ Right. 09:17:11 I guess you COULD have a system where you gave them the ability to trigger actions on one another, but that's not the general case we're talking about. 09:17:28 this is where my stats bar comes in real handy in x4, you could add an entry there for which system you are currently targeting 09:17:51 Makes sense. 09:18:12 Here's a possible rub. 09:18:14 or you could type .target or something and it will say "target" or "host" 09:19:26 The way I intend to set this system up, I will have "virtual instruction" words that function as macros. I'll use them to define primitives. So say I'm defining a target primitive. I might use a macro that's supposed to spew several target assembly instructions into the image. Right now. And that amcro would run on the host. But I guess those would be immediate words, so we'd know they aren't "really" 09:19:28 part of the target definition. 09:20:14 Assembly instructions will generally always work that way - they execute immediately and pour binary bits into the target dictionary. 09:21:17 But it shouldn't be a problem - supposedly you wouldn't find those words in the target dictionary. You'd find them in the host dictionary, even though the act to build the target image. 09:25:36 no. if you execute a word on the target thats not there you should not execute a word of the same name on the host 09:25:46 it should be a blah ? 09:26:04 eitehr you forgot to define blah or you MEANT to have host current 09:26:32 but executing blah on the host when you menat to run the non existent definition of it on the target could have disasterous consequences 09:28:00 KipIngram, have you seen mecrisp? 09:30:43 not really looked at it 09:30:47 know of it :) 09:32:05 No, I haven't - I'll look it up. 09:32:25 Oh, nice. 09:32:46 I should look that over as "ARM training." I'm fairly competent at Intel assembly, but zero ARM experience. 09:33:18 That doc dave0 shared with us the other night (the higly commented lisp system source) was for ARM, so that's useful to me in that way as well. 09:33:31 I really had a lot of fun look through that. 09:33:52 Really neat watching the system "rise up out of the ground" so to speak. 09:34:28 I think I'll try to make my "Forth in Forth" source be structured kind of like that, when I get to it. 09:34:43 Though I'm thinking about a way to do the comments other than inline. 09:34:50 Still stuck on that comments database idea. 09:35:58 It's still a very nebulous thing in my mind, but I'm fairly hot for the idea. 09:50:08 i prefer thumb2 to x86 now but i loathe and despise aarch64 produced by gcc 09:50:20 2/3 of the opcodes will be reg, reg move operations. 09:50:38 literally 2/3 of your compiled object code on aarch64 is mov reg, reg 09:51:05 mov reg, reg mov reg, reg mov reg, reg call blah mov reg, reg, mov reg, reg... . 09:53:42 i think the only time arm got their instruction set right was with thumb2 09:55:51 Yuck. 10:00:22 I've always found the "two instruction sets in one" thing to be a little distasteful. 10:06:58 arm was good. thumb was a utter failure. 10:07:10 thumb2 was perfect(ish) 10:07:27 --- join: lispmacs[work] joined #forth 10:07:35 tho ITT blocks are a bit confuzering 10:07:53 prefer being able to put any condition on any opcode 10:08:03 if condition does not exist opcode is a nop 10:09:28 --- quit: Zarutian_HTC1 (Ping timeout: 245 seconds) 10:23:34 I'm not familiar enough with it yet to speak intelligently. 10:30:45 --- join: andrei-n joined #forth 10:30:47 --- join: Zarutian_HTC joined #forth 10:40:02 --- join: mark4_ joined #forth 10:40:31 --- join: Gromboli5 joined #forth 10:41:40 --- join: rann_ joined #forth 10:43:50 --- join: WilhelmV1nWeiner joined #forth 10:44:05 --- join: phadthai_ joined #forth 10:48:56 --- quit: tech_exorcist (*.net *.split) 10:48:56 --- quit: nihilazo (*.net *.split) 10:48:56 --- quit: Gromboli (*.net *.split) 10:48:56 --- quit: mark4 (*.net *.split) 10:48:56 --- quit: WilhelmVonWeiner (*.net *.split) 10:48:56 --- quit: joe9 (*.net *.split) 10:48:56 --- quit: rann (*.net *.split) 10:48:56 --- quit: phadthai (*.net *.split) 10:48:56 --- nick: Gromboli5 -> Gromboli 10:49:06 --- nick: rann_ -> rann 10:50:13 --- join: joe9 joined #forth 10:56:19 --- join: tech_exorcist joined #forth 11:00:25 --- join: nihilazo joined #forth 11:05:21 Ergh. Watching videos on B-Trees. 11:05:37 Looks to me like they'll be handy for this comment system. 11:06:10 The tree will get sorted by the location in the source that the comment attaches to. 11:06:31 Either block / line or block / line / col; haven't decided yet. 11:07:13 So when I go to edit a source block, I won't have any pointers there to tell me there's a comment - I'll need to check the b-tree and see what comments are attached in that block. 11:08:04 Say I decide to attach to block/line. What that would lead me to do is have a panel on the screen for displaying the comment, and when I put the cursor on a line of the block, any associated comment will show up in that other panel. 11:08:47 So the b-tree will have pointers into the source code, that it's sorted on, and pointers into other disk resources where the comments actually live. 11:11:26 B-trees are one of the fundamental data strutures in my opinion 11:12:24 Yes - they're very useful for when you have an access time difference like that between disk and RAM. 11:12:43 Seems like a natural toolkit to have if you're going for raw blocks in your Forth system. 11:12:43 Yes they're suited for hard storage 11:12:49 Nope! 11:13:04 The natural toolkit for raw blocks in Forth is writing out blocks yourself 11:13:09 :-) 11:13:21 Well, but you have to decide how to organize them. 11:13:30 I agree - I want to write all this myself. 11:13:31 Organize it like a filesystem if you want 11:13:49 But I want to do it in a way that promotes good performance, and a b-tree-based scheme will help with that. 11:13:59 Block 1 has the 'root' contents, contains comments with the name and block numbers of main directories 11:14:05 I guess what I'm saying is that if I were going to write a file system, I'd consider making b-trees part of it. 11:14:07 Then subdirectories are referenced from those blocks 11:14:22 Yes, I understand file systems. :-) 11:14:28 You do all this by hand, not with a b-tree 11:14:29 Basically at least. 11:14:39 It's not a "filesystem", such things are not necessary for forth programmers 11:14:42 Blocks are all we need 11:14:56 Well, at the momennt I'm considering this for organizing this comment database. I may decide it's not the way to go, but I'm not there yet. 11:15:00 Just staarted thinking about it. 11:15:15 If I toss it out I'll let you know, and compliment you for forecasting that. 11:15:23 Nah don't automate it, the second you automate a "comment database" you should make a real database or filesystem 11:15:42 I won't use it if it's too much work. 11:16:09 I want a place over there to go type a comment that will stick with that point in the code. 11:16:16 And yet I don't want it "in the code." 11:16:47 That means if I add a line above a comment point, I'll need to increment that comments line # to match. 11:16:55 This would all be part of writing the source editor. 11:17:18 Returning to my video... 11:18:32 It occured to me while writing effectively a filesystem from scratch that the filesystem is a naturally balanced tree, where the balancing part is the user 11:18:50 After all users would keep a sane amount of stuff in each directory/node 11:19:53 how does one program tree structures in Forth - as far as handling the memory allocation? Do you need an allocate/free for that? 11:20:02 Really depends 11:20:19 If it's a tree you can build up and don't want to 'free' any of it you can do it in dictionary 11:20:24 Or in another stack-like place 11:21:04 If you want to add/remove parts then you could use allocate/free, but could also use simpler allocation schemes if data is fixed size like a block pool 11:21:56 yeah, I guess it doesn't sound too complicated if each node memory allocation is the same 11:22:12 If the tree's static and you can write it all out in advance then you might encode it somehow within colon definitions, where each node is a word 11:23:18 i am used to lisp where it is easy to make a tree, but your next node could be allocated from anywhere, and automatically deallocates itself after being unlinked 11:27:19 I am used to Lua where it is easy to make a hash table 11:33:55 --- quit: gravicappa (Ping timeout: 260 seconds) 11:35:36 --- join: gravicappa joined #forth 12:16:49 --- quit: joe9 (Ping timeout: 268 seconds) 12:26:16 lua is good 12:26:47 and so are chairs 12:42:48 --- quit: mtsd (Ping timeout: 245 seconds) 12:53:03 --- quit: crc (Read error: Connection reset by peer) 12:56:05 --- join: joe9 joined #forth 12:57:45 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 12:57:55 --- join: Zarutian_HTC joined #forth 12:58:30 --- join: crc joined #forth 13:14:49 --- quit: wineroots (Quit: Gateway shutdown) 13:18:49 --- quit: jess () 13:19:05 --- join: jess joined #forth 13:24:17 --- join: hosewiejacke joined #forth 13:25:33 --- quit: gravicappa (Ping timeout: 240 seconds) 13:26:51 --- quit: hosewiejacke (Client Quit) 14:19:15 --- quit: andrei-n (Quit: Leaving) 14:26:27 --- quit: tech_exorcist (Quit: tech_exorcist) 14:30:20 I did a fairly extensive amount of stuff with a block pool on my last one; it was fine. Decided this time I didn't want to build that complexity in at the lowest level like I did before. 14:55:25 --- join: dave0 joined #forth 14:55:54 maw 15:06:09 Hey dave0. 15:06:49 maw KipIngram 15:11:52 :-) 15:21:12 I've found that Forth is probably the easiest language to debug 15:21:49 in my experience. as far as tracing my mind through the code I've written 15:31:23 I've found it fairly straigtforward to debug stuff even with a barely (or not) working system. 15:31:58 Before anything much was working at all, I'd just push an exit call through my test code, until I segfaulted instead of exited. 15:32:05 Then I knnew where the fault was. 15:32:17 Move down into the offending word, lather rinse repeat. 15:32:51 Pretty quickly it's narrowed down enough that you can just look carefully at the code and find out what's wrong. 17:43:32 --- quit: cantstanya (Remote host closed the connection) 17:45:53 --- join: cantstanya joined #forth 18:22:33 --- quit: Zarutian_HTC (Ping timeout: 260 seconds) 18:23:04 --- join: Zarutian_HTC joined #forth 18:23:32 --- join: boru` joined #forth 18:23:34 --- quit: boru (Disconnected by services) 18:23:37 --- nick: boru` -> boru 19:05:29 --- join: wineroots joined #forth 19:39:41 veltas - that was an interesting idea earlier - that a typical hierarchical file system approximates a self-balancing tree. Not exactly, of course, but I suspect you're right in most cases. 19:46:23 --- quit: sts-q (Ping timeout: 268 seconds) 19:58:06 --- join: sts-q joined #forth 20:56:00 --- join: mtsd joined #forth 21:13:28 --- nick: phadthai_ -> phadthai 21:17:47 KipIngram, are your stack frames effectively offering a C-call ABI to forth words? 21:23:49 Possibly. Tell me a little more about what that means. 21:24:56 { saves the existing frame register on the return stack and mirrors the stack pointer into the frame register. 21:25:08 At that point references off of either of them would be the same. 21:26:05 But nothing else changes the frame register, so even as the stck wiggles back and forth it provides a stable reference. } retrieves the frame register from the return stack and does a final adjustment on the data stack. 21:51:11 --- quit: sts-q (Quit: ) 21:51:37 --- join: sts-q joined #forth 22:35:24 --- quit: mtsd (Quit: Leaving) 22:39:49 --- join: mtsd joined #forth 22:41:33 :* how clever? 22:41:40 Ooops. 22:41:43 Sorry. 22:50:24 --- quit: jedb_ (Quit: Leaving) 22:50:59 --- join: jedb_ joined #forth 22:51:13 --- nick: jedb_ -> jedb 22:56:33 KipIngram, what happens if your word starts with { but exits early without calling }? 23:20:16 --- join: andrei-n joined #forth 23:22:16 --- join: andrei_n joined #forth 23:25:50 --- quit: andrei_n (Client Quit) 23:36:49 --- quit: jedb (Quit: Leaving) 23:37:15 --- join: jedb joined #forth 23:38:38 --- join: gravicappa joined #forth 23:59:59 --- log: ended forth/21.04.22