2024-12-31 00:02:44 amby: Because the short definitions are easier to be sure are right. 2024-12-31 00:02:58 I just find my code written that way easier to follow and have confidence in. 2024-12-31 00:03:06 fair 2024-12-31 00:03:19 my thing is i'd struggle to name them all 2024-12-31 00:03:41 one of forth's greatest strengths imo is you don't have to name all the little piddly locals 2024-12-31 00:03:42 If I think of a good name I'll use it, but it has to be a short name. 2024-12-31 00:03:43 you can just write 2024-12-31 00:04:25 I'm very "non-verbose" when it comes to naming, and I like symbols if they make sense (which is not usually the case for these helpers). 2024-12-31 00:04:42 But I prefer & | and ^ over and, or, xor. 2024-12-31 00:18:49 technically direct threading is a little older than indirect threading; it's just that *Forth* used indirect threading earlier than directthreading 2024-12-31 00:20:19 KipIngram: I think Chuck Moore did some Forths using conditional return as the only control structure 2024-12-31 00:21:00 writing a function you only call once has a few different merits 2024-12-31 00:23:54 1. shorter definitions are easier to test interactively; 2. shorter definitions are better at building up a domain-specific language you can write more stuff in later 2024-12-31 00:24:07 3. the name serves as a comment 2024-12-31 00:26:24 Yes, and you're just less likely to get them wrong in the first place - less complexity to hold in your mind. 2024-12-31 00:27:55 amby> my thing is i'd struggle to name them all 2024-12-31 00:28:11 that's what i've been saying! 2024-12-31 00:28:35 forth forces me to come up with a lot more names for things than i do in c 2024-12-31 00:28:45 and i find that difficult 2024-12-31 00:37:57 i mean c has the same issue of only having a global namespace for functions 2024-12-31 00:46:07 Forth avoids that problem 2024-12-31 00:46:14 I find the ability to reuse names in forth to be helpful 2024-12-31 00:48:17 and (depending on the system design), it can be possible to extend to add separate vocabularies, or more fine control over name visibility 2024-12-31 00:50:33 amby: yeah but there are a lot of short expressions in c that you'd hapily repeat over and over and over again but that in forth are best factored into words 2024-12-31 00:50:55 simple things like the -> operator 2024-12-31 00:51:28 array[i]->member in c, but that would be gnarly to write more than once in forth 2024-12-31 00:52:31 Yes, I routinely re-use names in these "helper" words. 2024-12-31 00:52:46 Which one? The one defined in the same little block of code. 2024-12-31 00:52:54 (That's how I keep up with it, I mean). 2024-12-31 00:53:32 So I'm trying to suss out how to use the "parametric" features of FreeCAD this afternoon. 2024-12-31 01:18:31 xentrac: What used direct threading first? 2024-12-31 01:19:46 Or before Forth's direct threading, rather 2024-12-31 01:21:17 spitbol I think? 2024-12-31 01:21:36 check cacm 2024-12-31 01:47:27 Glancing at spitbol assembly it looks like it's threaded, not sure of the details 2024-12-31 01:49:25 Well I asked because you said it was not the first 2024-12-31 01:50:03 Not really helpful to say 'check cacm' 2024-12-31 01:51:56 chatgpt thinks spitbol had aspects of indirect threading in it, related to its dynamic compilation. I guess it built such data structures to use during execution. 2024-12-31 01:52:17 Wikipedia says that for a long time spitbol was regarded as impossible to compile, but someone eventually worked it out. 2024-12-31 03:05:43 veltas: sorry, I was on the phone 2024-12-31 03:07:15 https://dl.acm.org/doi/pdf/10.1145/362248.362270 (Bell 01973) is the original paper on threaded code, which was based on work on DEC's Fortran compiler 2024-12-31 03:09:35 https://dl.acm.org/doi/pdf/10.1145/360825.360849 (Dewar 01975) is the original paper on indirect threaded code, which was based on SPITBOL; this is the paper that retronymmed Bell's scheme to "direct threaded code", "although developed independently" 2024-12-31 03:09:59 veltas: I didn't mean to be rude! 2024-12-31 03:50:49 crc what made you decide to use termux and a tablet as your dev env? 2024-12-31 11:44:22 xentrac: No need to apologise, I'm just impatient 2024-12-31 12:03:00 It seems like that Fortran compiler is from around 1970, which is right around when the first compiling Forth was written 2024-12-31 12:03:16 All a bit arbitrary who did what first, probably a lot of people developed similar things around then 2024-12-31 12:04:36 I suspect (although don't know) that Forth's flavour of DTC is a bit unique in terms of how it factors machine code versus words/data; but ITC will probably look the 'same' everywhere 2024-12-31 12:05:09 Whether anyone abused ITC to produce DOES>-style coding elsewhere I don't know, but obviously it's similar to a lot of data+action abstractions 2024-12-31 12:34:36 Chuck claims 1971 was when he had threaded code 2024-12-31 12:34:55 1968 was the first compiler (so either machine code or interpreted/bytecode) 2024-12-31 12:35:54 https://web.archive.org/web/20060615025259/http://www.colorforth.com/HOPL.html 2024-12-31 12:37:24 "The development that made all this possible was indirect-threaded code. It was a natural development from my work at Mohasco, though I later heard that DEC had used direct-threaded code in one of their compilers." 2024-12-31 12:37:52 interesting! so he was an earlier independent reinvention 2024-12-31 12:38:12 but he adopted Dewar's terminology 2024-12-31 12:51:37 I think it's clear from being reinvented, and how 'naturally' it apparently fell out of things, that it was a natural development to achieve more dynamic and space-saving compiling of the era 2024-12-31 12:54:12 Whereas now I think with the larger addresses of modern CPU's the most natural choices are token/bytecode for space saving / highly dynamic data driven code, or subroutine-threaded 2024-12-31 12:55:05 Subroutine threading has advantage of being closer to interoperating with other native code, and being a lot simpler to implement/understand, and also allowing inlining/optimising for performance if desired 2024-12-31 12:55:51 yes 2024-12-31 14:55:12 Seabass_: ultimately, a combination of a need to be able to work when away from a desk, and laptop form factor not working well for me 2024-12-31 14:56:02 due to RSI issues, I find it difficult & painful to use non-ergonomic keyboards for any length of time, and since I thus need to carry a keyboard anyway, can save some weight/bulk this way. 2024-12-31 14:59:02 that said, I might change this setup in the future. I'm working on a portable forth machine, and might get a smallish laptop (mnt pocket reform) for times where I need more flexibility with i/o than the tablets provide. 2024-12-31 15:10:02 portable forth machine sounds interesting 2024-12-31 15:20:47 what kind of hardware are you thinking of using? 2024-12-31 15:23:41 the current design builds around a teensy4.1, with a custom keyboard (similar to an atreus layout) & lcd display. 2024-12-31 15:35:27 Introducing Forth tokens, a Forthy cryptocurrency 2024-12-31 15:35:34 The first MD5 based crypto 2024-12-31 15:35:48 and the honour system 2024-12-31 15:38:06 It's also 100% centralised, to avoid all that unnecessary complexity of a decentralised system 2024-12-31 15:39:11 And usually people buy Forth tokens, enjoy losing some value with them, and then spend a year making their own Forth crypto derivative that nobody will use 2024-12-31 15:39:26 But that's really part of the Forth crypto experience 2024-12-31 15:39:37 i call dibs on dup 2024-12-31 15:41:20 xentrac: I should be wiring up the display & keyboard in january or february; I've been using it via a serial connection for several months 2024-12-31 15:48:02 What's everyone doing for New Years Eve? Going to get a Chinese takeaway and be asleep by 10pm, that's about my limit as a new parent 2024-12-31 15:51:31 at work until around 1400, then head home, dinner at 1700, an evening meeting with friends (1900-2100), then back home & reading before bed by midnight 2024-12-31 15:55:16 veltas: that's been my limit for a long time without ever being a parent 2024-12-31 16:06:07 me and some mates are meeting up and doing a board game night 2024-12-31 16:34:37 crc: I ask because I have been using a similar setup for coding while traveling. I rooted a Kindle Fire I got secondhand for like $10 and use a really crappy BLE keyboard though 2024-12-31 16:35:02 Not sure if Helix editor works on Termux but that + a better keyboard would make my setup a lot more useful 2024-12-31 16:35:59 Currently I mostly just use the tablet for notetaking in vim then I sync the notes to gh 2024-12-31 16:40:23 crc: of note is that the teensy does not have much ram 2024-12-31 16:41:27 4.1 has like 4k iirc 2024-12-31 16:59:17 4.1 has 1024k RAM 2024-12-31 17:18:04 my system doesn't use much; it needs about 300k (I think it's about ~12k for the VM & 256k for the system image memory) 2024-12-31 17:20:17 huh not sure where i got 4k from 2024-12-31 17:25:18 NYE plan, get started on the VM impl of my Forth interpreter thing, then have a small party 2024-12-31 17:25:30 Maybe play Project Zomboid build 0.42 a bit 2024-12-31 17:32:30 amby: I think it has 4k of EEPROM (I don't use this currently, so not 100% sure on that) 2024-12-31 22:59:08 Ok I refactored my Forth implementation to use a VM 2024-12-31 22:59:10 https://github.com/pickles976/SDLForth/blob/main/vm.c 2024-12-31 22:59:18 if anyone wants to take a look 2024-12-31 23:01:32 mmm unchecked malloc calls 2024-12-31 23:07:40 What’s the preferred way of handling that kind of errors in C? Do you just printf and exit the program? 2024-12-31 23:08:04 I need to refactor and add better error handling, right now everything either returns a bool or just doesn’t handle anything 2024-12-31 23:09:25 or have an #ifdef for a oom handler (which might just err(3) out) 2024-12-31 23:10:33 What do you mean by that? I haven’t done any actual professional C programming 2024-12-31 23:10:45 You mean like ifdef to see if there is some OS defined err handling? 2024-12-31 23:18:12 abort(), raise(), longjmp(), return; world's your oyster 2024-12-31 23:18:40 https://thrig.me/tmp/whoops.txt 2024-12-31 23:20:49 Ok cool I’ll do something like that, thanks! 2024-12-31 23:21:15 I'll be honest, never heard of err()/warn() before now 2024-12-31 23:21:29 Looks useful 2024-12-31 23:21:35 I don't do a lot of C on an OS 2024-12-31 23:21:47 I haven’t done C before at all 2024-12-31 23:22:01 Well, maybe a little on embedded but no memory or anything 2024-12-31 23:22:24 C is my day job 2024-12-31 23:24:21 granted on linux you (may) not need the malloc checks because by default the oom killer starts taking drunken shots at your process table 2024-12-31 23:25:37 Is there a convention for how to exit a program? 2024-12-31 23:25:53 Or I can use err everywhere 2024-12-31 23:26:26 thrig: In my opinion it's worth having anyway, because obviously wrong values still return NULL 2024-12-31 23:26:32 I think(?) anyway 2024-12-31 23:26:39 Like malloc(-1) I assume returns NULL 2024-12-31 23:30:42 well, you can just do like pforth, exit with "segmentation fault" 2024-12-31 23:31:46 I just wanna handle things properly 2024-12-31 23:34:46 Seabass_: Look up assert(), and assert anything that is "unexpected" 2024-12-31 23:35:39 i.e. on Windows, Linux, and most systems malloc() will never actually return NULL, so just ptr = malloc(...); assert(ptr); 2024-12-31 23:37:12 Ok will do! 2024-12-31 23:37:48 When I say 'unexpected', I guess I mean anything that's not 'worth' trying to handle 'properly' 2024-12-31 23:38:42 on openbsd malloc will return null, and then Bad Things can happen when your incorrect program continues 2024-12-31 23:38:47 If I'm on an exotic system where malloc is more honest and I get an assertion failure instead of a segfault, that's preferable, and not hard to achieve 2024-12-31 23:41:36 I'm actually surprised OpenBSD doesn't kill programs on allocation failures by default, unless they say "yes I really will actually check the pointers" 2024-12-31 23:42:07 Given that most(?) C programs act like it can't return NULL 2024-12-31 23:43:01 But that's a lot of work to add to all the good C programs, which will be most of what people are using in anger on OpenBSD 2024-12-31 23:45:27 And this is why the subject is a gray matter, because killing on a NULL is just as good as handling the NULL and (likely) ending the program because it can't continue without that memory, and just as good as OOM killer swiping at low hanging fruit 2024-12-31 23:46:51 the oomkiller used to kill sshd, and then I got paged at 4 AM in the morning 2024-12-31 23:47:03 It's not smart at all 2024-12-31 23:47:30 On desktop it tends to kill X, which ends up killing all your open programs anyway 2024-12-31 23:48:20 Alas, we have simple allocations, not safe allocations 2024-12-31 23:49:16 If you can statically allocate or allocate up-front then that's best, and it's the main way to allocate in Forth