00:00:00 --- log: started forth/20.11.25 00:36:03 more or less the same as last time, but i've included a sed command to patch kernel/Makefile and some output from qemu at the end: https://pastebin.com/KjWS48CL 00:36:32 if you want to pastebin your error log, i can take a look 01:54:21 --- join: shynoob joined #forth 01:54:31 has anyone built a build system in forth? 03:27:10 --- join: zugzwang_ joined #forth 03:30:02 --- quit: shynoob (Ping timeout: 272 seconds) 03:36:23 --- join: xek joined #forth 03:38:04 --- quit: xek (Remote host closed the connection) 03:38:32 --- join: xek joined #forth 04:13:58 --- quit: hosewiejacke (Ping timeout: 240 seconds) 04:21:04 --- join: Gromboli joined #forth 04:25:40 --- join: hosewiejacke joined #forth 04:44:45 --- quit: xek (Read error: Connection reset by peer) 04:44:52 --- join: xek_ joined #forth 04:55:56 --- quit: dave0 (Quit: dave's not here) 05:05:57 --- join: xek__ joined #forth 05:08:51 --- quit: xek_ (Ping timeout: 260 seconds) 05:31:02 --- quit: zugzwang_ (Quit: Leaving) 05:53:18 siraben: did you get gforth cross-compiled? 07:02:59 --- quit: hosewiejacke (Ping timeout: 264 seconds) 07:28:53 --- join: hosewiejacke joined #forth 07:35:45 --- join: shynoob joined #forth 07:41:53 inode: need to look into it again 08:04:12 shynoob: I'm working on that atm for something 08:12:38 for which languages? 08:28:11 --- quit: hosewiejacke (Ping timeout: 264 seconds) 08:34:07 inode: by the way is your shell prompt set to `$`? 08:34:21 I always edit mine to be `$` in pastes but I wonder if anyone here uses `$` all the time 08:44:32 --- quit: shynoob (Quit: Leaving) 08:57:06 --- join: hosewiejacke joined #forth 09:03:09 siraben: on that linux system, no. i redacted everything besides $ for clarity 09:04:11 --- quit: hosewiejacke (Ping timeout: 264 seconds) 09:04:20 but when i used to use ash and ksh on netbsd i typically had only $ (and sometimes #) as my prompt 09:07:14 I see 09:07:32 I'd imagine going with $ as my prompt would imply running pwd a lot, heh 09:28:59 --- join: lispmacs[work]` joined #forth 09:38:10 --- quit: xek__ (Ping timeout: 260 seconds) 10:11:07 hostname as well if you're promptless on multiple systems 10:19:38 btw, for cross compiling gforth - i found that you don't really need a prior installation of gforth dispite the warning presented from configure 10:20:26 and if you have qemu user emulation available and binfmt_misc support (so your kernel recognises alien binary formats) it should build fine for the most part 10:26:52 and depending on your target, at least if you want to be able to disassemble, you will probably want a standalone build of gdb present at runtime (as opposed to gdbserver) to make use of disasm-gdb 11:14:04 --- quit: lispmacs[work]` (Remote host closed the connection) 11:31:48 --- join: megan joined #forth 11:32:09 --- quit: megan (Client Quit) 11:33:05 --- join: hosewiejacke joined #forth 11:39:58 --- quit: hosewiejacke (Ping timeout: 240 seconds) 11:55:30 siraben: i'm willing to accept that any issues i have with git sit between the keyboard and the chair and i should perhaps be using it differently or updating or something, but a simple case - i'm working on a file that my colleague is, and he checks in first - i pull, get warned of conflict, i stash push, i pull, i stash apply - and now all my mods are staged - being the opposite of what i want or expect 11:56:14 small details like that make it very frustrating to work with :) 11:58:27 mercurial could also be a pain, but it would definitely handle that case with a lot more grace 12:11:56 --- join: xek__ joined #forth 12:23:06 --- join: Zarutian_HTC joined #forth 12:28:22 --- join: xek_ joined #forth 12:28:52 --- quit: Zarutian_HTC (Remote host closed the connection) 12:30:52 --- join: Zarutian_HTC joined #forth 12:31:16 --- quit: xek__ (Ping timeout: 265 seconds) 12:53:00 --- join: dave0 joined #forth 13:09:27 --- quit: gravicappa (Ping timeout: 240 seconds) 13:14:32 Random question: what's a good way to write a Forth word definition that takes a list of numbers and doubles each of them? Related question, for "lists" is it better to use Forth arrays? Or some other way to represent them in memory? 14:08:23 --- quit: xek_ (Ping timeout: 264 seconds) 14:12:05 neuro_sys: Like Python 'lists' or linked lists? 14:13:59 You've got two good ways to double a 'list' of numbers, if they're specified as literals then parse them yourself, otherwise give the address and length to a word and use a ?DO/+LOOP 14:15:03 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 14:15:17 --- join: Zarutian_HTC joined #forth 14:16:03 Something like : word ( addr u -- ) over + ?do i @ 2* i ! cell +loop ; 14:35:30 Thanks, that definition makes sense. About the lists, I was wondering what's a good way to represent them in Forth. Clearly this depends on whether the contents of the list is known at the time when the program is written (in which case, CONSTANT and "," to compile them into Dictionary?), or if the elements are read during run time from an Input device (such as keyboard, disk or network). 14:38:04 I think the code to do that would be the same either way, provided you can parse the 'input device' 14:40:31 So we mean list like in Python then? 14:40:36 I see, makes sense. 14:41:02 To me a 'list' is a linked list, but I have been teaching someone programming recently so I am somewhat aware of this terminology 14:41:37 I'm not familiar with lists in Python. But let's say, in C, I'd implement a linked list, or alternatively an array allocated on heap, and resize it as the number of element grows. 14:41:56 Well the two are very different things 14:42:05 And it shows in Forth 14:42:17 A classic dictionary is a linked list 14:42:27 But in Forth, I have yet no assumptions to try to implement a linked list straight up, and was wondering if there's a different way to store dynamic lists using the built-in constructs. 14:42:56 "A classic dictionary is a linked list", that's kind of what I wanted to hear/confirm 14:43:37 'Modern' dictionaries are generally implemented using hash tables for fast lookup 14:43:49 And more flexibility over deleting entries 14:43:53 But still with a pointer to the next dictionry entry, I suppose. 14:44:21 --- quit: Gromboli (Quit: Leaving) 14:45:51 I came across this when I googled "linked list in Forth", it is clearly not the Forth way as it seems the person tried to replicate Lisp functionality in Forth: https://gist.github.com/niconii/2e2857fb062f46abc164a2cb73db782b 14:46:15 It really depends what you're doing 14:49:14 I think whether they're "forth way" or not is very subjective, and I don't see anything horrific going on there 14:49:46 I see that there's no canonical way to implement a linked list (although the same can be argued for other languages) but this is quite different than the above one: https://rosettacode.org/wiki/Singly-linked_list/Element_definition#Forth 14:50:40 At least the first one I posted looks like "let me implement the Lisp atoms with Forth, and then use them to implement a list". 14:50:57 The confusing thing to me is the names they have because I don't remember Lisp's names for basic list operations 14:51:45 If I remember lisps tend to use names that came from some old assembly language, not sure why they did that in a high level scripting language 14:52:12 It put me off learning guile etc 14:52:38 Yes, CAR and CDR were basically instructions IIRC, and are horrible naming. Thankfully the language has enough high level definitions to not need them for most work. 14:52:58 But basically, CDR is the left side (value), and CAR is the right side (pointer to the next CONS cell). 14:53:49 I'm no Lisp expert, but the first a few chapters of this book is perfect: http://www.softwarepreservation.org/projects/LISP/book/Weismann_LISP1.5_Primer_1967.pdf 14:55:43 It seems that the gist and rosettacode examples do the same thing 14:56:09 They both create the list elements in the dictionary 15:02:11 I see, it's more clear now. 15:04:31 I see that Dictionary is where pretty much where all the data being processed goes: https://www.forth.com/starting-forth/9-forth-execution/#Forth_Geography 15:04:55 So I'll study the Dictionary entry structure more to understand how it's manipulated and represented in memory. 15:10:00 Well the structure of dictionary is unrelated here, the dictionary lets you allocate space and they are just putting a list within that 15:10:37 The 'structure' I would consider e.g. the header of each entry in a classic dictionary, or a more complicated thing in hashed dictionary forths, and it has no impact on how it's 'used' usually 15:11:20 Starting Forth is good to read for an idea of what classic forths would do, although the implementation details are almost entirely outdated now 15:14:09 Any recommendations to read or study? When I get the chance I usually check out Starting Forth (only skimmed through from the beginning to the end) and Gforth manual, and forth-standard.org and try writing small code snippets I think of. 15:17:24 I'm interested to know what other people will say, I think reading and actually trying out code from Starting Forth, writing some very simple projects, stuff like that 15:17:30 Read other people's code 15:17:50 Post your code in here (via pastebin or something) and people can make suggestions 15:18:37 There are people like me in here who can help a little, and then there are some old guard people in here who can probably regularly make you re-think everything about the way you write forth or at least teach you some more cool stuff you didn't think of 15:19:19 There is a subreddit for forth which has some good posts on it 15:20:22 Thanks these are very useful tips 15:21:29 Listen to some Chuck Moore talks, get to know him a little and a lot of Forth's culture/design makes more sense 15:22:40 Apply the concept of a 'minimal viable product' as strictly as possible in everything you do and factor everything as much as possible and your code should be very reliable and you will probably learn stuff about the problem you didn't know before 15:23:17 Something that surprises me is when occasionally I write a program in Forth I've written in 10 other languages and I actually find it *easier* than I did elsewhere 15:23:54 I've been doing that (reading/watching Chuck Moore) a lot lately thanks to Youtube, I'm very puzzled and intrigued at the same time. 15:24:31 You can talk about what he says on here too if you want, like if there's something in particular you question or just don't understand 15:24:51 --- quit: dave0 (Quit: dave's not here) 15:25:00 I think I have mostly understood what he's said, although I think I'm just sceptical of some of it. 15:27:26 I need to immerse myself more and hopefully I'll be very talkative once I'm past a certain point. But on a very superficial level my impression of him is that he's somewhat eccentric. Very much focused (obsessed?) on simplicity and efficiency, and feels like has a very different but top-down understanding of computation than what the industry has evolved to. 15:27:45 I've been thinking about simplicity myself a lot, so that's why I'm drawn to Forth recently. 15:28:07 Some of the things he said in between words were also quite funny, hard to say if he is joking or not. 15:29:07 Such as that computers don't need an operating system in the sense we have them today. 15:29:14 Eccentric but brilliant people like Chuck Moore can make us see things from new perspectives and solve problems differently. I think he's quite serious about most things he says but sometimes he says stuff that's more experimental and less proven 15:29:53 And some of the experimental claims he makes he seems to move away from, like he at one point tried to get rid of loops etc from his programs and I think he's moved away from that idea now 15:30:45 I've seen that a few days ago, and I played around with the idea quickly. Using recursion to implement a loop, that is. 15:31:12 It's not science fiction, I mean that's how most 'loops' are done in functional programming 15:31:38 But does it overcomplicate the idea? Is the forth loop not elegant already? 15:32:01 I think forth's control structures are quite elegant, nothing wrong with a loop 15:32:14 It seemed completely reasonable, especially in the context of Forth the form also yields to be simpler. 15:32:41 It's simpler in one aspect, but I think recursion is a bad fit for lots of problems 15:32:44 I wasn't sure about if there's a tail-call optimization going on, but probably. 15:33:06 I think in the presentation I watched he made it clear that tail-call optimization was done 15:34:13 I agree about recursion, it has only very specific use cases where it's relevant/idiomatic (like tree traversal). 15:34:23 See that's one of the issues I have with it, and I think I can tell he was a bit uncomfortable about that too. These kinds of optimisations playing a role in the functionality and syntax is not very 'nice', the forth loops are much more explict in their operation/implementation 15:34:44 Even then it's best avoided, and using an explicit stack to implement the same is safer. 15:35:42 I think it's encouraging to see a language designer who tries to make their language *smaller* over the years, in different ways 15:36:49 I think there his point was that the loop constructs are all taken from different languages, and now you have multiple things that does the same thing. And he asks the classic question "do we even need any of these constructs?" But I see that a loop construct is ubiqutous in programming languages, and recursions are notorious. 15:37:44 Forth makes recursion much simpler, because the operation of the stack is explict. The stack plays a role in all recursion implementations and usually it's implicit, and I think that confuses people 15:37:58 That recursive loop he mention mandates the loop to be factored, which plays nicely with the general factoring idea. 15:39:08 Stack being implicit in most other languages could be a million dollar problem in terms of education. 15:39:45 Sorry I think "million dollar problem" is not what I meant 15:40:33 There's no question you want highly factored Forth code, I think the question is what compromises you are willing to make to factor it. Chuck Moore seems to prefer doing anything to factorise in the logic it can only be so 'complicated' or 'unmaintainable' if it's 1/10th the code of a more 'readable' solution 15:42:07 So would you say that factoring too much can result in less readable code? 15:44:37 I think I would prefer something half way between what he does and most Forth code 15:44:46 As for factoring in other languages before I met Forth, I had a period when I decided to practice against that idea, and thought: "never factor unless it is needed". Of course in a language like Forth, it is more of a necessity due to stack juggling. 15:45:22 I don't think there's a simple rule for making code readable, I think 'factor' is the best simple advice you can give though 15:45:32 You can definitely over-do it 15:46:36 Tastefully avoiding factoring is normal in forth and some of the best forth code I've read is just writing unrolled logic where a loop would actually be unnecessarily complicated, it's not always shorter but it's clearer, and not exactly less 'maintainable' 15:47:29 My favourite fizz-buzz implementation for forth has no loops or recursion 15:48:56 https://www.reddit.com/r/Forth/comments/druotn/fizzbuzz_in_forth/f6nfrm2/ 15:49:00 I'm more of a plain text person, but it makes me think an editor environment where the Forth words can be expanded inline could help with that. You could still write highly factored code, but expand them in-line if you need context. Just an idea, partly because I'm hooked on Emacs for the past year or so. 15:49:48 Yeah that looks very nice 15:50:41 Although it's limited to 100 range. 15:51:44 Yes, but if the statement is for 100 then it's a good forth solution 15:51:56 After all you solve the problem at hand in forth, not imagined problems 15:53:26 That's a good one and applicable to all software in general. 15:53:52 If the requirement was that it's 100, then fair enough. 16:00:28 neuro_sys, I think you'll find some of the "advantages" of forth are actually disadvantages that proponents are sometime overly optimistic about 16:00:48 like when Michael Scott says his biggest weakness is that he volunteers too much 16:01:34 so the big hype about bottom up design is not because someone compared that to top down design and decided it was better, it's because there's no way to go back and change a word once it's in the dictionary 16:01:54 so you're stuck with bottom up although some people try to pass it off as superior, which is not exactly honest 16:02:13 you'll find a lot of that in Starting Forth like when they discuss "information hiding" 16:02:55 that's an important topic but the term there is misused to try to hide that some things are tough to keep straight that arent tough in other languages 16:03:07 Forth words quickly become unreadable and unmaintainable, forcing you to write shorter and more factored words which turn out to be better code in some ways but you could still have done that in a 'cleaner' language 16:03:24 You can actually have your cake and eat it in other languages 16:04:00 I think Forth wouldn't be interesting if it was just a language, and not an environment, but yes the environment also has a lot of issues 16:04:04 so not saying you shouldnt use forth, just be aware that how it's presented can be very "optimisitic." when you see through that, you still may want to use the language 16:05:14 I like forth and yet I am surprised when problems turn out to be easier in forth, it's not often that happens 16:07:13 Writing forth feels like I am using the same parts of my brain that are active when I'm writing assembly *and* trying really hard to optimise everything like register usage 16:09:07 I have written a software 64-bit division routine in powerpc assembly and forth recently, and I found the powerpc easier 16:10:10 --- quit: pareidolia (Ping timeout: 260 seconds) 16:12:24 I already figured that much quite soon, but I'm a hobbyist at heart, playing around with assembly and homebrew computing just a bit. So my expectations from Forth in practical terms is not that high (at least in my day to day work). Although this video was quite nice: https://www.youtube.com/watch?v=mvrE2ZGe-rs 16:12:37 So I'd like to get to a level where I would solve some of my needs with Forth instead. 16:12:56 I was thinking doing the next Advent of Code 2020 with Forth. 16:13:30 One thing I will claim about Forth is it will make you a better programmer, it made me understand problems I didn't even know I had and has helped me solve problems at work in a much more elegant way even though I mostly write C there. 16:14:03 I also want to do advent of code in forth, I never do them but forth will motivate me 16:14:04 veltas, ya assembly is sometimes preferrable I think. I feel like forth is a way to avoid thinking about registers if youre ok with the performance loss 16:14:33 I wish to get a job where I can write C next year now that I made some money doing dirty job with dirty languages. :) 16:14:37 You stop thinking about registers and start thinking about a stack, I think neither is 'easy' and both require thought 16:15:22 Forth was invented back when it was actually a lot easier and cleaner than most assembly languages of the time, but these days a good macro assembler would be 'better' in some cases depending on what you're used to 16:16:30 8-bit assembly is harder than forth, you don't have multiply, only certain ops are 16-bit, register usage is full of caveats and restrictions, etc 16:16:42 some people say you can (re)write 10% in assembly and get a big boost in performance but still save a lot of time on the 90% written in froth 16:17:17 I think that's true anywhere, even in 8-bit or on modern microcontrollers 16:17:19 --- join: pareidolia joined #forth 16:17:54 It's always worth writing a sensible reasonable solution and then optimising the 1-10% where performance matters in profiling 16:18:11 And any good forth will let you integrate machine code routines as well 16:18:20 * Zarutian_HTC hasnt read the entire backlog 16:21:00 I think the performance loss of running Forth code versus register machine code is mostly the impedence missmatch berween dual stack machines and register machines 16:23:09 specially if you keep your stacks in work ram instead of their own ram devices. This is why I like fpga/clpd/asic implementations of dual stack machines: less same bus contentions 16:23:57 there's a lot actually that slows you down, especially if your forth is like most forths and doesnt optimize 16:24:17 but just having the bottleneck of a stack machine is a hige speed killer 16:24:46 if you could use PICK and insert stuff arbitrarily into the stack without a speed penalty, you could recover a lot of that but your code would look terrible 16:25:26 but yeah Forth is handy even on atmega328p for both the code density and ease of programming/parameterzation even in the field when you do not have the original software build environment 16:25:49 ya speed isnt everything 16:27:16 I also read that register allocation is an NP problem, while using stack for program flow is not. I don't know the specifics though. 16:27:44 s/is not/doesn't have such a problem/ 16:28:11 one bottleneck speed killer for register machines is the register to alu to register muxing 16:29:31 note that I have not started talking about deeply pipelinef out-of-order execution 16:30:08 -lined* 16:30:42 Is branch prediction still relevant in a stack machine? 16:31:29 think of why branch prediction is needed 16:32:13 branch prediction only makes sense in architectures with long execution pipelines 16:33:20 Right, if all instructions took fixed or one clock cycle then there'd be no need for branch prediction. 16:33:23 and if there are instruction cache prefetchers tied in, the branch prediction is also needd 16:34:49 neuro_sys, I don't get your point. a lot of forths on a register machine will use two of the registers for the first two stack items and ignore the rest. im just saying putting those 8 or however many registers to use will be faster if the equivalent forth code has a stack depth more than 2 16:36:01 if you look at say the excamera J1 dual stack machine you can see that all the possible alu ops are performed every instruction but only some instructions select which result get pushed onto the datastack 16:36:45 MrMobius: You're right, register allocation is not relevant when executing Forth code I guess. 16:37:28 register allocation is not a problem, that is. 16:39:43 this means even though an alu op takes x amount of step cycles so long the cpu always takes the same amount of or more step cycles to fetch, decode and then execute/commits it doesnt matter 16:44:01 the analogy I like to use is a fast food place with fixed menu and no per item custimzation options 16:45:36 though in stack machines there is the data depency between values on stack 16:53:43 but because values in TOS and NOS are know at end of each instruction the alu can have at them before even the next instruction has entered its fetch phase 16:54:53 --- quit: boru (Read error: Connection reset by peer) 16:55:43 --- join: boru joined #forth 16:55:47 not only alu but stuff like work ram and program memory read ports can be fed TOS into their address portion of the port 17:02:04 gives those memory devices enough time to get the value at that address to its data output pins for that port even before the cpu 'realizes' that it needs that value 17:16:01 --- quit: boru (Read error: Connection reset by peer) 17:16:48 --- join: boru joined #forth 18:12:59 --- quit: proteusguy (Ping timeout: 265 seconds) 18:24:53 --- join: boru` joined #forth 18:24:56 --- quit: boru (Disconnected by services) 18:24:58 --- nick: boru` -> boru 18:34:57 --- join: dave0 joined #forth 19:04:20 --- join: proteusguy joined #forth 20:12:36 --- quit: Zarutian_HTC (Remote host closed the connection) 20:33:51 --- join: gravicappa joined #forth 20:35:17 --- join: hosewiejacke joined #forth 20:38:36 --- join: hosewiejacke2 joined #forth 20:38:46 --- quit: hosewiejacke2 (Client Quit) 20:56:27 --- quit: sts-q (Ping timeout: 240 seconds) 20:59:59 --- quit: hosewiejacke (Ping timeout: 264 seconds) 21:04:16 --- join: sts-q joined #forth 21:13:56 --- join: hosewiejacke joined #forth 21:20:12 --- quit: the_cuckoo (Quit: WeeChat 1.9.1) 21:26:00 --- join: the_cuckoo joined #forth 21:28:17 --- quit: hosewiejacke (Ping timeout: 246 seconds) 21:35:20 --- quit: dave0 (Quit: dave's not here) 22:00:02 --- join: hosewiejacke joined #forth 22:13:12 --- quit: gravicappa (Ping timeout: 265 seconds) 23:23:42 --- quit: lispmacs (Remote host closed the connection) 23:59:59 --- log: ended forth/20.11.25