01:10 <siraben> Git is great IMO, would not be able to work this well otherwise

01:11 <siraben> bisect, branch, worktree, cherrypick, rebase, log, blame

01:16 <siraben> For build systems, Nix is definitely my favorite.

01:16 <siraben> Well it's more about package management

01:35 <siraben> Trying to build byok I get,cc -c src/stdio/printf.c -o src/stdio/printf.o -std=gnu11 -O2 -g -Wall -Wextra -ffreestanding -fno-builtin -D__is_byok_libc -Iinclude

01:35 <siraben> src/stdio/printf.c:7:10: fatal error: 'kernel/tty.h' file not found

01:35 <siraben> Heh, wrong folder include

01:54 <siraben> inode: how did you get it to build?

07:58 <inode> siraben: the same way that i listed in that pastebin splurb, i'll do it afresh to see if i've left anything out

08:35 <inode> 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

08:36 <inode> if you want to pastebin your error log, i can take a look

09:54 <shynoob> has anyone built a build system in forth?

13:52 <inode> siraben: did you get gforth cross-compiled?

15:41 <siraben> inode: need to look into it again

16:03 <veltas> shynoob: I'm working on that atm for something

16:12 <shynoob> for which languages?

16:33 <siraben> inode: by the way is your shell prompt set to `$`?

16:33 <siraben> I always edit mine to be `$` in pastes but I wonder if anyone here uses `$` all the time

17:02 <inode> siraben: on that linux system, no. i redacted everything besides $ for clarity

17:03 <inode> but when i used to use ash and ksh on netbsd i typically had only $ (and sometimes #) as my prompt

17:06 <siraben> I see

17:07 <siraben> I'd imagine going with $ as my prompt would imply running pwd a lot, heh

18:10 <inode> hostname as well if you're promptless on multiple systems

18:19 <inode> btw, for cross compiling gforth - i found that you don't really need a prior installation of gforth dispite the warning presented from configure

18:20 <inode> 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

18:26 <inode> 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

19:55 <the_cuckoo> 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

19:55 <the_cuckoo> small details like that make it very frustrating to work with :)

19:58 <the_cuckoo> mercurial could also be a pain, but it would definitely handle that case with a lot more grace

21:14 <neuro_sys> 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?

22:11 <veltas> neuro_sys: Like Python 'lists' or linked lists?

22:13 <veltas> 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

22:15 <veltas> Something like : word ( addr u -- ) over + ?do i @ 2* i ! cell +loop ;

22:35 <neuro_sys> 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).

22:37 <veltas> I think the code to do that would be the same either way, provided you can parse the 'input device'

22:40 <veltas> So we mean list like in Python then?

22:40 <neuro_sys> I see, makes sense.

22:40 <veltas> To me a 'list' is a linked list, but I have been teaching someone programming recently so I am somewhat aware of this terminology

22:41 <neuro_sys> 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.

22:41 <veltas> Well the two are very different things

22:41 <veltas> And it shows in Forth

22:41 <veltas> A classic dictionary is a linked list

22:42 <neuro_sys> 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.

22:42 <neuro_sys> "A classic dictionary is a linked list", that's kind of what I wanted to hear/confirm

22:43 <veltas> 'Modern' dictionaries are generally implemented using hash tables for fast lookup

22:43 <veltas> And more flexibility over deleting entries

22:43 <neuro_sys> But still with a pointer to the next dictionry entry, I suppose.

22:45 <neuro_sys> 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

22:45 <veltas> It really depends what you're doing

22:48 <veltas> I think whether they're "forth way" or not is very subjective, and I don't see anything horrific going on there

22:49 <neuro_sys> 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

22:50 <neuro_sys> 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".

22:50 <veltas> The confusing thing to me is the names they have because I don't remember Lisp's names for basic list operations

22:51 <veltas> 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

22:51 <veltas> It put me off learning guile etc

22:52 <neuro_sys> 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.

22:52 <neuro_sys> But basically, CDR is the left side (value), and CAR is the right side (pointer to the next CONS cell).

22:53 <neuro_sys> 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

22:55 <veltas> It seems that the gist and rosettacode examples do the same thing

22:55 <veltas> They both create the list elements in the dictionary

23:01 <neuro_sys> I see, it's more clear now.

23:04 <neuro_sys> 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

23:04 <neuro_sys> So I'll study the Dictionary entry structure more to understand how it's manipulated and represented in memory.

23:09 <veltas> Well the structure of dictionary is unrelated here, the dictionary lets you allocate space and they are just putting a list within that

23:10 <veltas> 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

23:10 <veltas> Starting Forth is good to read for an idea of what classic forths would do, although the implementation details are almost entirely outdated now

23:13 <neuro_sys> 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.

23:17 <veltas> 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

23:17 <veltas> Read other people's code

23:17 <veltas> Post your code in here (via pastebin or something) and people can make suggestions

23:18 <veltas> 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

23:18 <veltas> There is a subreddit for forth which has some good posts on it

23:20 <neuro_sys> Thanks these are very useful tips

23:21 <veltas> Listen to some Chuck Moore talks, get to know him a little and a lot of Forth's culture/design makes more sense

23:22 <veltas> 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

23:22 <veltas> 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

23:23 <neuro_sys> 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.

23:24 <veltas> 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

23:24 <veltas> I think I have mostly understood what he's said, although I think I'm just sceptical of some of it.

23:27 <neuro_sys> 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.

23:27 <neuro_sys> I've been thinking about simplicity myself a lot, so that's why I'm drawn to Forth recently.

23:27 <neuro_sys> Some of the things he said in between words were also quite funny, hard to say if he is joking or not.

23:28 <neuro_sys> Such as that computers don't need an operating system in the sense we have them today.

23:28 <veltas> 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

23:29 <veltas> 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

23:30 <neuro_sys> I've seen that a few days ago, and I played around with the idea quickly. Using recursion to implement a loop, that is.

23:30 <veltas> It's not science fiction, I mean that's how most 'loops' are done in functional programming

23:31 <veltas> But does it overcomplicate the idea? Is the forth loop not elegant already?

23:31 <veltas> I think forth's control structures are quite elegant, nothing wrong with a loop

23:31 <neuro_sys> It seemed completely reasonable, especially in the context of Forth the form also yields to be simpler.

23:32 <veltas> It's simpler in one aspect, but I think recursion is a bad fit for lots of problems

23:32 <neuro_sys> I wasn't sure about if there's a tail-call optimization going on, but probably.

23:32 <veltas> I think in the presentation I watched he made it clear that tail-call optimization was done

23:33 <neuro_sys> I agree about recursion, it has only very specific use cases where it's relevant/idiomatic (like tree traversal).

23:34 <veltas> 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

23:34 <neuro_sys> Even then it's best avoided, and using an explicit stack to implement the same is safer.

23:35 <veltas> I think it's encouraging to see a language designer who tries to make their language *smaller* over the years, in different ways

23:36 <neuro_sys> 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.

23:37 <veltas> 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

23:37 <neuro_sys> That recursive loop he mention mandates the loop to be factored, which plays nicely with the general factoring idea.

23:38 <neuro_sys> Stack being implicit in most other languages could be a million dollar problem in terms of education.

23:39 <neuro_sys> Sorry I think "million dollar problem" is not what I meant

23:40 <veltas> 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

23:41 <neuro_sys> So would you say that factoring too much can result in less readable code?

23:44 <veltas> I think I would prefer something half way between what he does and most Forth code

23:44 <neuro_sys> 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.

23:45 <veltas> 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

23:45 <veltas> You can definitely over-do it

23:46 <veltas> 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'

23:47 <veltas> My favourite fizz-buzz implementation for forth has no loops or recursion

23:48 <veltas> https://www.reddit.com/r/Forth/comments/druotn/fizzbuzz_in_forth/f6nfrm2/

23:48 <neuro_sys> 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.

23:49 <neuro_sys> Yeah that looks very nice

23:50 <neuro_sys> Although it's limited to 100 range.

23:51 <veltas> Yes, but if the statement is for 100 then it's a good forth solution

23:51 <veltas> After all you solve the problem at hand in forth, not imagined problems

23:53 <neuro_sys> That's a good one and applicable to all software in general.

23:53 <neuro_sys> If the requirement was that it's 100, then fair enough.