2026-03-25 02:12:08 <tpbsd       > veltas, yes, Lua is a easy language to learn
2026-03-25 02:12:39 <tpbsd       > but so is Perl and many others like Forth
2026-03-25 08:20:49 <iv4nshm4k0v > I'd say Jim Tcl is pretty small, too.  And so is http://duktape.org/ .  And given that Tcl was (or so it seems) modelled after Unix shells, I'd expect for Jim to make a better fit for system programming than Lua.
2026-03-25 08:23:16 <tpbsd       > the reason I started using lua was to make a pop up window that searches a Sqlite3 db for Neovim editor, as neovim is written in Lua
2026-03-25 08:27:19 <iv4nshm4k0v > That's, in a way, the exact opposite to what happened to me back in the day: I've started using GNU Emacs because it was written in Lisp.
2026-03-25 08:29:07 <tpbsd       > I nearly did the same, but for some reason went the VIM way
2026-03-25 08:33:08 <iv4nshm4k0v > I, too, went the Vim way initially - I didn't feel like I have enough time to spare on learning Emacs.  I've got back to it in a year or so, and then used it for some two decades straight.  GNU Emacs has since grown too big and monolithic to my taste, though, so I went back to (a minimalist build of) Vim.  (And NetBSD vi.)
2026-03-25 08:34:47 <tpbsd       > I really like LISP, but barely know it as Im only partially into Scheme using RACKET
2026-03-25 08:37:26 <iv4nshm4k0v > I've contributed a few patches to SLIB and Scheme48 in the past (as well as GNU Emacs.)  Ultimately, I've found Scheme a tad impractical - as compared to, say, Perl with its huge library of CPAN modules.  Never got really involved with Common Lisp, though having some interest in Maxima, that still might happen.
2026-03-25 08:38:43 <tpbsd       > yeah, I've grown too old too fast and didnt have time to do everything I wanted
2026-03-25 08:39:14 <tpbsd       > Perl with it's awesome CPAN for everything won me over right away around 2004
2026-03-25 08:39:28 <tpbsd       > it's just too versatile and useful
2026-03-25 08:43:56 <iv4nshm4k0v > I've since learned that using a ton of ready-made libraries is perhaps not the best approach to programming.  As explained in, say, http://spectrum.ieee.org/lean-software-development .
2026-03-25 08:45:31 <tpbsd       > probably not, and I'm no expert, barely a programmer really, but I am a very good electronics guy
2026-03-25 08:46:14 <tpbsd       > but I wrote a lot of Perl code for automated testing of electronics gear and networks, and I found I could build anything with Perl
2026-03-25 10:22:38 <veltas      > tpbsd: I found Lua easier, frankly I'm not that good at learning languages so I think it helped me learn Lua that it's so simple
2026-03-25 10:22:47 <veltas      > I think Forth was easy to learn too
2026-03-25 10:23:11 <veltas      > But learning Forth 'properly' and Lua 'properly' are harder, they're both deceptively deep languages
2026-03-25 10:23:54 <tpbsd       > veltas, yeah, I only learn as much of the language as I need to do stuff, top up when needed
2026-03-25 10:23:57 <veltas      > iv4nshm4k0v: I have no doubt Jim would be better for system programming, Lua is just a fun DSL-ish / embeddable scripting language
2026-03-25 10:25:03 <veltas      > vim is way too bloated but I've not seen any other vi forks that have the features I rely on, so I just use vim and have to occasionally google what the hell e.g. git for windows has broken in its awful forced init
2026-03-25 10:25:41 <tpbsd       > he for anyone who is interested I asked GLM-5 AI how good is it at understanding schematics ---> https://bpa.st/2E3A
2026-03-25 10:25:43 <veltas      > I know people in here use e.g. OpenBSD's fork of vi, and it seems good.  NetBSD's vi is quite good too
2026-03-25 10:27:15 <veltas      > tpbsd: I think my approach tries to be comprehensive because I am a career 'programmer', and you say you are not a 'programmer'
2026-03-25 10:28:14 <veltas      > But also programming languages are a trap for all programmers to get lost in
2026-03-25 10:28:19 <tpbsd       > veltas, Im not a programmer, tho I do program for my own embedded needs, but I'd rate myself as very low on the programmer productivity scale
2026-03-25 10:28:24 <veltas      > It's just a tool at the end of the day
2026-03-25 10:28:34 <tpbsd       > yeah
2026-03-25 10:28:50 <tpbsd       > Im first and formost, and always a electronics guy
2026-03-25 10:29:10 <veltas      > To your credit though, you have delivered a number of useful programs and also much documentation for mecrisp
2026-03-25 10:29:17 <veltas      > So you've been plenty productive
2026-03-25 10:29:19 <tpbsd       > I have been since I was very young, always obsessed with electronics
2026-03-25 10:29:37 <veltas      > And it seems like lots of people use these programs
2026-03-25 10:29:51 <tpbsd       > well, I think Forth can take the credit for that, Forth does stuff to a persons mind ;-)
2026-03-25 10:30:43 <tpbsd       > veltas, over 10,000 users have downloaded my 'Bluepill Diags' which surprised me
2026-03-25 10:31:47 <tpbsd       > I started it when I was reading lots of forum posts about 'fake Chinese bluepills' by people who had zero clue what was going on, and no tools to find out
2026-03-25 10:32:17 <tpbsd       > they were mostly Windows using embedded project hobbyists
2026-03-25 10:33:56 <tpbsd       > it wa clear to me that I could easily make a embedded image for the Bluepill board that deployed  Mecrisp-Stellaris  running on the target to determine if the mcu was a 'fake' or a real STM32F103
2026-03-25 10:34:46 <tpbsd       > and oddly, I didnt get thousands of emails, or any emails really, criticising my release or asking for help using it
2026-03-25 10:35:14 <tpbsd       > people just used it with the simple looping menu it started with
2026-03-25 10:36:07 <tpbsd       > bit by bit I learned that the 'clone' mcus were in fact superior in many ways to the original, cheaper too
2026-03-25 10:49:16 <veltas      > iv4nshm4k0v: Good article and agreed that 'using a ton of ready-made libraries is perhaps not the best approach to programming'
2026-03-25 10:49:56 <veltas      > Hard not to feel guilty writing stuff myself because I feel like I'm reinventing the wheel, but it's always shocking to me just how hard it is to really write reusable good code (if it's possible at all), and how little of what's out there meets that category
2026-03-25 10:51:14 <veltas      > The attitude used to be "use library" and if there wasn't a library then you should "write a library".  If you write a one-off app then people say you need a library for its guts and the app itself should just be a layer under that
2026-03-25 10:51:40 <veltas      > And it sounds reasonable and correct, but you don't realise it's death by a thousand cuts
2026-03-25 10:52:10 <tpbsd       > veltas, in embedded every project has different code in my experience, it cant be 'reused'
2026-03-25 10:52:34 <veltas      > That it's difficult or impossible to write libraries that don't have massive implications for how your program will work, and loads of ways for it to go wrong or limit what you want
2026-03-25 10:52:54 <veltas      > You basically can't use any library seriously without developing it yourself and then maintaining your own fork
2026-03-25 10:52:54 <tpbsd       > just from one Forth user to another, even using the same Forth doesnt mean they can share any code
2026-03-25 10:53:56 <veltas      > There's a massive C library that's full of loads of C++-style generic containers and useful portable programming constructs that people would want called GLib, and the whole thing *aborts your program on allocation failures*
2026-03-25 10:54:29 <tpbsd       > a massive X86 C library ?
2026-03-25 10:54:30 <veltas      > So you could get all this great code for writing advanced C programs... but you're already making concessions that it won't be stable on a system with limited memory or other apps leaking memory
2026-03-25 10:54:59 <veltas      > tpbsd: It's not an embedded library, it's not specific to x86 though
2026-03-25 10:55:18 <veltas      > It's a C library so you could use it with any native programming language, including some Forths
2026-03-25 10:55:52 <veltas      > GLib is one of the foundational libraries for basically all of GNOME, XFCE, libXML, etc etc
2026-03-25 10:56:08 <veltas      > So a huge part of the C ecosystem has fundamental stability issues
2026-03-25 10:56:27 <tpbsd       > yeah, I've seen it while building lots of PC apps on X86
2026-03-25 10:57:08 <veltas      > libXML is no longer being maintained(?), that's one of the two big XML libraries and they're totally different, so that means basically all open source XML-using apps just got more work
2026-03-25 10:58:04 <tpbsd       > I write a lot of XML related stuff and have never used a library, so it wont affect me :)
2026-03-25 10:58:08 <veltas      > libexpat is extremely basic, it's a good choice for lots of things but probably any serious app that uses XML for config or saving content will use libXML
2026-03-25 10:58:30 <veltas      > You use XSLT or whatever it's called right?
2026-03-25 10:58:43 <tpbsd       > but as I keep saying, Im not a real programmer :)
2026-03-25 10:58:57 <tpbsd       > yeah XSLT I use a lot
2026-03-25 10:59:00 <veltas      > What program do you use to run XSLT?
2026-03-25 10:59:08 <tpbsd       > to write XML transforms
2026-03-25 10:59:15 <veltas      > xsltproc?
2026-03-25 10:59:29 <tpbsd       > there are a few, yeah xsltproc is one
2026-03-25 11:00:23 <tpbsd       > but Im very rusty atm, I havent written any new XSLT in a couple of years and Im strugelling with it now
2026-03-25 11:00:25 <veltas      > Guess what: https://github.com/GNOME/libxslt/blob/master/INSTALL
2026-03-25 11:00:55 <veltas      > xsltproc uses libxslt which uses libXML
2026-03-25 11:01:00 <veltas      > And glib
2026-03-25 11:01:08 <tpbsd       > I have to write some new transforms to generate a Sqlite3 database for my new neovim popup
2026-03-25 11:01:12 <veltas      > It's all built on sand, Terry
2026-03-25 11:01:19 <tpbsd       > haha, oops
2026-03-25 11:01:34 <tpbsd       > your point is taken
2026-03-25 11:01:50 <veltas      > Whereas do you know what library I relied on to parse some XML for a recent project at work?
2026-03-25 11:01:59 <tpbsd       > no
2026-03-25 11:02:00 <veltas      > libc, I used scanf
2026-03-25 11:02:31 <veltas      > And if I had written in Forth I could have done similar, altough there would have been more foundational code to write
2026-03-25 11:02:41 <veltas      > But at least in Forth I really would be able to manage the whole dependency chain
2026-03-25 11:02:51 <veltas      > If my scanf broke I'd have a harder time replacing it
2026-03-25 11:03:06 <tpbsd       > Ive only ever used Forth for embedded, never for pc related apps
2026-03-25 11:03:38 <veltas      > I don't think Forth is good for general purpose programming, it's a struggle to write stuff like parsers in Forth
2026-03-25 11:03:38 <tpbsd       > brb
2026-03-25 11:03:48 <veltas      > I have done it though, and they can look okay, but it doesn't feel forthy
2026-03-25 11:20:48 <tpbsd       > bak
2026-03-25 11:21:31 <tpbsd       > veltas, I thinl forths like crc's RETRO would make a good shell replacement, but I havent spent any time on it
2026-03-25 11:32:21 <veltas      > crc: Has retro got something like the feature of pipes from the shell?
2026-03-25 11:32:40 <veltas      > I think that's the main thing missing, that and some way to interrupt a routine like ^C
2026-03-25 11:32:48 <veltas      > Or suspend/resume
2026-03-25 11:33:04 <veltas      > I don't know though, I'm just guessing, so interested to hear what crc has got to say about this
2026-03-25 11:36:49 <tpbsd       > veltas, I think RETRO has a lot more than that and can use the BIOS etc
2026-03-25 11:37:39 <tpbsd       > Ive watched CRC using RETRO like I use the shell all the time, he certainly eats his own dogfood
2026-03-25 11:45:42 <iv4nshm4k0v > Virtual memory is a tad complicated.  Normally, you won't even get an allocation failure: malloc (0x4000000000LL) is likely to succeed even on a RAM-starved 64-bit system.  Trying to actually use that memory, however, may result in SIGSEGV - or SIGKILL.  So while I'm not a fan of Glib, I'm not sure it's all that straighforward to handle allocation failures sensibly.
2026-03-25 11:50:41 <iv4nshm4k0v > Also, I suppose the best way to write reusable code is to do your best, then hope it gets reused.  I'm not aware of /any/ coding practices that are guaranteed to produce reusable code.  Though if your employer has a ton of money, they can probably ensure that the code they've invested in covers sufficiently many real-life use cases so the outside programmers would have little choice but to use it.
2026-03-25 12:00:49 <iv4nshm4k0v > One thing about Jim is that it includes an (optional?) Unix IO library as part of the distribution, making it readily usable for system programming - although it also poses itself as an embeddable interpreter.  I wouldn't mind try using Duktape or Pforth for the same - but I gather I'll have to write an IO library myself.  Looking at $ man 3lua intro suggests that NetBSD has one for Lua.
2026-03-25 12:00:49 <iv4nshm4k0v > And one particularly good thing about Vim is that you can disable features you don't need at build time.  Unlike GNU Emacs - you remove org-mode you don't use, then your gnus stops working.
2026-03-25 12:16:40 <veltas      > iv4nshm4k0v: 32-bit systems are admittedly more likely to get this issue
2026-03-25 12:19:00 <veltas      > Linux and BSDs can be configured not to overcommit, although this probably creates stability issues with everything
2026-03-25 12:20:33 <veltas      > I did have NetBSD working to some extent on my laptop, and then a whole load of other life priorities came along and I realised I needed a system where the wifi wasn't constantly on life support
2026-03-25 12:20:46 <veltas      > And I don't have time to fix the driver, if that's even in my ability
2026-03-25 12:21:23 <veltas      > It was a lot less stable on my desktop, having a lot of major stability issues and freezes
2026-03-25 12:21:40 <veltas      > But that could just be my desktop, I'm not sure if that's software
2026-03-25 12:23:39 <veltas      > Handling allocation failures I would say is not usually too hard... it requires that all code follows a principle of rolling back to a good state, don't leave broken NULL pointers in the wrong place etc
2026-03-25 12:24:04 <veltas      > But the surface area of potential failures, and routes it can take at any allocation, means testing requires some thought
2026-03-25 12:24:27 <KipIngram   > I've worked out a syntax for my new system's "meta compile" capability that's rather nice.  The "extra thing" that's needed is that I need to be able to define vm instructions.  A normal colon definition will define a Forth word implemented IN vm code.  To define a vm instruction I'll use something like : name  [ <lo code> <hi code> vm ] <assembly> ;  <lo code> and <hi code> will specify the jump
2026-03-25 12:24:29 <KipIngram   > table range to assign this code to.  The word vm will tell the system that it's compiling a vm instruction - the header will be so marked and a slight adjustment to the info in the header will be made.  ; will remember that vm was invoked and in that case will append the inner interpreter "next" code to the definition.  For vm instructions that don't require ranges, I'll have a word op+ that just
2026-03-25 12:24:31 <KipIngram   > increments to the next available byte code, and the range spec will just be "op+ dup".  So I just have these two special words, vm and op+, and the rest basically looks like normal Forth.  Here [ and ] do their normal Forth thing - switching out of and back into compile mode.
2026-03-25 12:25:31 <iv4nshm4k0v > veltas: That'd only work with overcommitting.  Like I've said, "allocation failure" in a modern system is more likely result in a SIGSEGV at foo[bar] = 42, than 0 returned from a malloc.
2026-03-25 12:26:12 <veltas      > Only work without overcommitting you mean(?)
2026-03-25 12:26:44 <veltas      > I should say for context I do know about overcommit, virtual memory, etc.
2026-03-25 12:27:40 <iv4nshm4k0v > When you overcommit, you can expect 0 from malloc on allocation failure.  When you do not overcommit, you are unlikely to get 0 from malloc, ever.  Instead, actual VM page allocation will happen on first access - like, say, foo[bar] = 42 - and you will get SIGSEGV on allocation failure, not a particular return code.
2026-03-25 12:28:49 <veltas      > overcommit is when you allow mapping more memory than is reserved physically
2026-03-25 12:28:59 <veltas      > I thought(?)
2026-03-25 12:30:56 <iv4nshm4k0v > I might be mistaken about the terms myself - haven't discussed this thing in a while, I guess - but my understanding is that "overcommit" is when you /force/ allocation of /more/ (hence "over") memory than strictly necessary.  And "malloc (anything)" by itself only needs a tiny bit of memory to record the allocation in Libc's data structures.
2026-03-25 12:32:32 <veltas      > Overcommit is a feature of an OS to be able to allocate more virtual memory to processes than there is available in physical memory
2026-03-25 12:33:05 <iv4nshm4k0v > Yep, I suppose our terms are inverse to each other.
2026-03-25 12:33:40 <veltas      > And there's two main reasons to allow this, memory that's mapped isn't immediately used, so refusing to map the memory essentially makes programs failure earlier than they need to
2026-03-25 12:34:01 <veltas      > And the other reason is some applications require sparse mappings that are mostly zero with only occasional non-zero data
2026-03-25 12:34:06 <veltas      > Like sparse matrices
2026-03-25 12:35:36 <iv4nshm4k0v > FWIW, http://en.wikipedia.org/wiki/Memory_overcommitment seem to align with your definition.
2026-03-25 12:38:48 <veltas      > I'm not an *expert* per-se, but I actually do know a lot about virtual memory, TLBs, allocation etc.  I've implemented a number of allocators ... mostly variants of dlmalloc and jemalloc, as well as 'arena allocators' as people love saying but don't seem to know what it means ... I gave a talk about Doug Lea's allocator
2026-03-25 12:39:13 <veltas      > I've implemented cache-as-RAM in TLBs so I have a good understanding of how virtual memory is handled by the OS
2026-03-25 12:40:35 <veltas      > And just internal free list block allocators which I've mostly found useful for disk/storage
2026-03-25 12:41:04 <veltas      > And ALLOT which is just a pointer, but often enough....
2026-03-25 12:41:18 <veltas      > sbrk() I guess is the same thing but I'm not sure you can even safely use that with libc linked?
2026-03-25 12:41:37 <veltas      > I've not tried
2026-03-25 12:41:51 <iv4nshm4k0v > Still, my point is that, unless the system is configured to force allocation at malloc time, there's always a fair chance of getting a SIGSEGV later in the program, than failure right at the time of malloc.
2026-03-25 12:43:03 <veltas      > Embedded programming is a thing, also it is possible to request sizes so large that malloc() returns NULL regardless ... even on 64-bit with overcommit
2026-03-25 12:43:13 <MrMobius    > why would it be SIGSEGV?
2026-03-25 12:43:26 <veltas      > It wouldn't be SIGSEGV but I get what he's saying
2026-03-25 12:44:42 <MrMobius    > unless you mean having no swap and running out of memory that's actually written to
2026-03-25 12:45:43 <veltas      > I think OOM killer uses SIGKILL but the main point is the program dies without a nice error return code to handle
2026-03-25 12:45:47 <iv4nshm4k0v > M-m; if OOM killer gets involved, I suppose it will be SIGKILL?  Also, just checked NetBSD's sbrk(2): "Also, one must take care not to mix calls to malloc(3) or related functions with calls to brk() or sbrk() as this will ordinarily confuse malloc(3); this can be difficult to accomplish given that many things in the C library call malloc(3) themselves."
2026-03-25 12:45:57 <veltas      > I suppose you can handle SIGSEGV more gracefully if you want
2026-03-25 12:46:59 <veltas      > iv4nshm4k0v: That's not surprising to me re. sbrk(), I just wonder if the compatibilities sake if the vanilla sbrk() function you get with glibc will play nice and create your own sandbox in another map somewhere to wreak havok, and malloc() uses the sbrk() syscall directly
2026-03-25 12:47:07 <veltas      > But that's just not how UNIX tends to work so probably not
2026-03-25 12:48:15 <veltas      > Since sbrk() is clasically a system call, it probably goes straight to the kernel and may God have mercy on you
2026-03-25 12:50:57 <MrMobius    > veltas: any ideas about implementing a garbage collected system on an embedded system? im thinking about using ID numbers and looking up the pointer when the memory block is locked
2026-03-25 12:51:18 <veltas      > What's the primary programming language?
2026-03-25 12:51:22 <MrMobius    > as in the pointer is the return value of lock
2026-03-25 12:51:22 <MrMobius    > C
2026-03-25 12:51:36 <veltas      > Will this be alongside reference counting?
2026-03-25 12:51:41 <MrMobius    > no
2026-03-25 12:52:18 <veltas      > What sort of embedded problem needs garbage collection?
2026-03-25 12:52:21 <MrMobius    > once a block is locked, the GC knows not to touch it. just have to remember to unlock when done and not store old pointers that may have been GC'ed
2026-03-25 12:53:17 <MrMobius    > a graphing calculator that can run a text editor, command line, forth prompt, and optimizing forth compiler all at once
2026-03-25 12:53:42 <MrMobius    > embedded as in no OS or multitasking but 8MB RAM
2026-03-25 12:53:50 <iv4nshm4k0v > Given the warning in sbrk(2), I guess I won't be using sbrk in my C programs anytime soon.  Not sure if I should have reservations were I to decide to write something in, say, "pure" assembly.  (Like E3; see http://texteditors.org/cgi-bin/wiki.pl?E3 .)
2026-03-25 12:54:14 <veltas      > MrMobius: Rather than going for an arbitrary solution I might recommend doing something similar to what mobile phones do, they ocassionally call a handler on every app that can "minimise" memory usage, just go through and free however many allocatable items in each module you can get away with
2026-03-25 12:54:30 <veltas      > I.e. when you start running out of space
2026-03-25 12:54:43 <MrMobius    > veltas: how would you prevent memory fragmentation?
2026-03-25 12:55:01 <veltas      > Pick similar sized allocations for all modules to work with based on the application
2026-03-25 12:55:20 <veltas      > And bundle some kinds of data as necessary to fit this size
2026-03-25 12:55:55 <MrMobius    > the applications are very different and have different needs
2026-03-25 12:56:26 <veltas      > iv4nshm4k0v: I'd have the reservation because as soon as I decided I wanted to call a library, like to use OpenGL or something, I'd probably clash with malloc() somewhere
2026-03-25 12:56:38 <veltas      > Unless it was just a simple piped assembly program relying only on syscalls
2026-03-25 12:57:33 <MrMobius    > veltas, so each module would have the same type of data or a mix?
2026-03-25 12:59:02 <veltas      > I would guess each module would have different kinds of data, maybe a mix depending on what the module does, and then <module>Minimise() would go through whatever list or array had all the references and choose unlocked content to free
2026-03-25 12:59:49 <veltas      > The main minimise() function could check the free space after each module's minimised and then stop if it got to a certain threshold too, to avoid just deleting everything whenever GC is needed
2026-03-25 13:00:17 <iv4nshm4k0v > veltas: Given that OpenGL almost universally requires proprietary GPU microcode on one's system, I take effort to ensure GL(X) doesn't work on my systems at all.  Though I understand the implications, yet I'm no stranger to writing "library-less" code.  When I've started using AVR MCUs, for instance, I've found AVR Libc somewhat difficult to get used to, so my first programs were in assembly.
2026-03-25 13:02:51 <veltas      > MrMobius: The main thing is the whole environment could choose a fixed allocation size and then fragmentation is not going to be a problem
2026-03-25 13:03:10 <veltas      > THey don't have to use the same types of data, they just need to agree on a fixed allocation size
2026-03-25 13:03:44 <veltas      > And if you e.g. have a ... list of numbers, then you could put however many numbers fit into the block with room for the 'next' pointer, for example, it doesn't need a full block per number
2026-03-25 13:03:53 <MrMobius    > veltas: I don't see your point. the problem with fixed allocation is it has to be big enough for the largest thing you'll allocate and then wastes a lot of space if things are smaller. packing multiple things in the same space leads to fragmentation
2026-03-25 13:04:19 <MrMobius    > right. I thought about storing a pointer to the next block
2026-03-25 13:04:31 <veltas      > I personally don't like to do this and just accept that fragmentation is possible and it will need restarting occasionally, when working with small non-virtual addressing
2026-03-25 13:05:53 <MrMobius    > ya, that works for some things. I think locking and GC would be the way to go otherwise as long as you don't store any stale pointers
2026-03-25 13:05:57 <veltas      > Microsoft used another approach called compacting, where you 'lock' memory while it's in use, and they kept a master list of all such allocations.  Occasionally if space was needed they would then *move* all unlocked memory to other locations to free up larger contiguous room
2026-03-25 13:06:12 <MrMobius    > right
2026-03-25 13:06:27 <veltas      > So it's important to lock the memory while you use it, but that's already a concession in your design so it works
2026-03-25 13:06:34 <KipIngram   > I still struggle with exactly how to handle memory allocation in a RAM-constrained environment.  One idea I keep coming back to is having a group of allocators, each providing different fixed-size blocks.  Fixed block size allocators are easy to implement with a free list and never need defragmentation.
2026-03-25 13:06:50 <KipIngram   > Of course, if you're REALLY RAM constrained, you might not have room for that.
2026-03-25 13:07:30 <veltas      > Kip this is literally what I've just been talking about :P
2026-03-25 13:07:40 <KipIngram   > Oh, sorry about that.  :-)
2026-03-25 13:07:53 <KipIngram   > Just waking up.
2026-03-25 13:07:59 <MrMobius    > fixed-sized blocks are good if you know ahead of time how many you need
2026-03-25 13:08:10 <MrMobius    > assuming you have a mix of them
2026-03-25 13:08:24 <KipIngram   > Right - if you have a good idea about the shape of your requirements.
2026-03-25 13:08:41 <KipIngram   > Mostly I've dodged the problem by trying to have plenty of RAM.
2026-03-25 13:09:11 <KipIngram   > I certainly have plenty on my notebook, and even this ESP32 chip I'm using has 512 kB, which is a fair bit for Forth.
2026-03-25 13:09:40 <KipIngram   > Much better than the 96 kB that MAX gadget I was looking at a year or two ago.
2026-03-25 13:10:34 <veltas      > I'm still doing stuff for 48KB ZX Spectrum and I'm not using compacting or block allocation
2026-03-25 13:10:43 <veltas      > And it works surprisingly well
2026-03-25 13:11:14 <veltas      > I will say basically that fragmentation is surprisingly not so much a problem, assuming you prefer allocating smaller free spaces over larger.  There are studies on this
2026-03-25 13:11:36 <KipIngram   > Isn't there an allocation strategy that can take a block from a larger block allocator and use it to issue out more smaller blocks?  I want to think there's a specific name for that one - I think I studied it aeons ago in my data structures course.
2026-03-25 13:11:46 <MrMobius    > buddy allocator
2026-03-25 13:11:56 <KipIngram   > Yes - that's it.  Thank you.
2026-03-25 13:12:41 <veltas      > Sounds not too efficient though
2026-03-25 13:13:07 <veltas      > i.e. I expect more overhead with that approach, even if it leads to less fragmentation
2026-03-25 13:13:16 <KipIngram   > Well, the extra overhead only comes in occasionally, when you run out of your current resources in a block size.
2026-03-25 13:13:39 <KipIngram   > And it does give you a little more flexibility in the face of uncertain requirements going in.
2026-03-25 13:13:56 <KipIngram   > So yes, but there's a benefit you get for that extra cost.
2026-03-25 13:14:44 <veltas      > The overhead is low when you run out of resources
2026-03-25 13:14:53 <veltas      > The overhead is high when you have only used some of a block
2026-03-25 13:33:54 <MrMobius    > not really. it does it in powers of 2. pretty slick how it works
2026-03-25 13:35:13 <crc         > veltas: retroforth has some support for pipes (popen, pclose); a few of the examples show simple demonstrations of this
2026-03-25 13:36:51 <veltas      > Nice
2026-03-25 13:38:58 <veltas      > MrMobius: From wikipedia "However, there still exists the problem of internal fragmentation – memory wasted because the memory requested is a little larger than a small block, but a lot smaller than a large block. Because of the way the buddy memory allocation technique works, a program that requests 66 K of memory would be allocated 128 K, which results in a waste of 62 K of memory."
2026-03-25 13:39:05 <veltas      > This is what I was worried about
2026-03-25 13:39:35 <veltas      > So you avoid fragmentation but create another kind of problem that wastes memory
2026-03-25 13:39:53 <MrMobius    > right it's a trade off. I was just saying I don't think overhead is high
2026-03-25 13:40:04 <MrMobius    > unless you mean overhead as in wasted memory
2026-03-25 13:40:10 <veltas      > Yeah exactly that
2026-03-25 13:40:13 <MrMobius    > as opposed to cycles spent on maintenance
2026-03-25 13:40:21 <MrMobius    > I see
2026-03-25 13:40:26 <veltas      > Overhead as in memory overhead, should have said
2026-03-25 13:51:57 <veltas      > Research has shown fragmentation is not usually bad in most real applications, so I would generally not accept a large memory overhead to reduce fragmentation concern
2026-03-25 13:52:28 <veltas      > And in my own experience a simple allocator similar to Doug Lea's descriptions is effective and versatile even with limited memory
2026-03-25 13:57:23 <veltas      > MrMobius: By the way I wouldn't recommend compaction, I tried it once and it's too damn hard to use it
2026-03-25 13:57:46 <veltas      > Implementing the compactor is trivial compared to the mental overhead it creates whenever you want to do literally anything with dynamic memory
2026-03-25 13:58:08 <MrMobius    > interesting
2026-03-25 13:58:28 <veltas      > That was my experience anyway, and I would guess a lot of old 16-bit Windows programmers would agree
2026-03-25 13:58:57 <veltas      > I think that may have been the opinion of Raymond Chen when he wrote about it too
2026-03-25 13:59:50 <MrMobius    > what I have now is blocks for various purposes that are small. when they fill up, I shift the rest of the memory forward to expand the block by the same small amount then recalculate all pointers since any blocks after that have been displaced
2026-03-25 14:00:19 <MrMobius    > switching to a new program just copies all of it's memory to the top of the list so all free space is above it in memory and ready to use
2026-03-25 14:00:51 <MrMobius    > it works well enough when you have 5-6 different block types but is annoying when you add new blocks because you have to figure out which pointers need to be recalculated
2026-03-25 14:01:30 <veltas      > Interesting
2026-03-25 14:02:29 <MrMobius    > kind of the path of least resistance because any time programs switch, all pointers need to be recalculated anyway so that's already in place
2026-03-25 14:23:42 <iv4nshm4k0v > I have to admit that XSLT is rather low in my list of priorities (I've been mostly using Perl's XML::Twig for my XML processing needs, as few and far apart as they might be), though it looks like Dave Beckett's RDF processing tools - I find them a tad more interesting than XSLT itself - also rely on libxslt / libxml.  And I recall xmlstarlet being a fairly convenient tool.
2026-03-25 14:25:55 <iv4nshm4k0v > (Back in the day, I've found XSLT 1 way too limited, and, IIRC, the later versions only had free software implemention in Java, to which I'm fairly averse.)
2026-03-25 14:28:45 <veltas      > I'm not a huge fan of XML, or libXML, but it's interesting how critical libXML seems to be to so much
2026-03-25 14:29:32 <veltas      > libXML has had some annoying changes that have caused bugs in programs I've used, like a CD burner that I couldn't open project files in ... turned out it's because they had switched empty tag content from "" to NULL at some point
2026-03-25 14:29:42 <veltas      > Which is unbelievable in terms of API stability
2026-03-25 14:30:33 <veltas      > No truly I think XML is extremely over-used, it's almost never the right solution.
2026-03-25 14:30:54 <veltas      > CMSIS is probably a reasonable application though
2026-03-25 14:33:59 <iv4nshm4k0v > As in, C NULL?  I suppose with how popular (?) XML is, it's no surprise that it gets abused left and right.  I, however, /am/ an XML fan.  Though I'd think that I do understand its scope and limitations.
2026-03-25 14:37:36 <veltas      > Yes C NULL
2026-03-25 14:37:51 <veltas      > So you can imagine swapping "" for NULL caused crashes
2026-03-25 14:38:40 <veltas      > I'm interested to know what you think a good use of XML would be?
2026-03-25 14:39:26 <veltas      > I do laugh when people use JSON and have to reinvent the wheel because JSON is too under-specified, but usually they would have found it easier to specify a *binary* format than either JSON or XML
2026-03-25 14:40:28 <veltas      > Like how many JSON specs end up talking about min/max integer values allowed, fractions forbidden, use base64 for binary encodings etc; just use a binary format already lol
2026-03-25 14:43:15 <iv4nshm4k0v > The XML applications I'm personally familiar with are HTML (the specification explicitly permits both 'traditional' and 'XML-based' HTML) and Atom.  I'm less familiar with SVG.  Other than that - XML is good for a. embedding XML (like Atom embeds XHTML), b. using XPath / XQuery.
2026-03-25 14:45:06 <veltas      > Why does Cascadia Mono look so much like Comic Sans
2026-03-25 15:16:46 <MrMobius    > SVG is awesome for people like me who have no artistic talent. I generate everything programmatically
2026-03-25 15:16:54 <MrMobius    > id probably be stuck in a terminal window otherwise
2026-03-25 15:17:29 <iv4nshm4k0v > 
ACTION listens to http://he3.magnatune.com/all/05-Under%20Starry%20Skies-Opera%20Rock.mp3 

2026-03-25 15:18:22 <veltas      > MrMobius I'll be honest I've tried learning SVG and I'm too stupid to understand it
2026-03-25 15:18:39 <MrMobius    > heh
2026-03-25 15:18:49 <MrMobius    > I should have said that I love creating python wrappers around SVG
2026-03-25 15:18:51 <veltas      > Or too disinterested maybe but it's just not pic
2026-03-25 15:18:59 <MrMobius    > not writing SVG by hand
2026-03-25 15:19:12 <veltas      > Okay that's more relatable
2026-03-25 15:19:32 <vms14       > i want to try to reverse rpn
2026-03-25 15:19:38 <vms14       > so just pn
2026-03-25 15:19:55 <veltas      > So lisp basically?
2026-03-25 15:20:01 <vms14       > i remember having tried once and idk what kind of limitation i saw
2026-03-25 15:20:14 <vms14       > veltas: not really, forth reversed in a way, but yeah no stack
2026-03-25 15:20:18 <vms14       > + 1 2
2026-03-25 15:20:21 <iv4nshm4k0v > SVG is a graphics format, it can be used to describe art - but it also can be used to describe data plots.  But, well, http://am-1.org/~ivan/qinp-2024/112.l-system.en.xhtml .
2026-03-25 15:20:23 <vms14       > print + 1 + 2 3
2026-03-25 15:20:28 <MrMobius    > you can embed SVG in html and give each element a name if you like then attach behaviors like mouseover
2026-03-25 15:20:41 <vms14       > or yes, lisp without parentheses
2026-03-25 15:21:05 <vms14       > i tried once by knowing the arity of every word, idk why it failed
2026-03-25 15:21:33 <iv4nshm4k0v > Because "+ 1 + 2 3" tries to apply "+" to "1" and "+"?
2026-03-25 15:21:41 <veltas      > Well RPN makes a lot more sense in evaluation and using a stack
2026-03-25 15:21:41 <MrMobius    > one example: http://calc6502.com/calcTTL/schematic-v2.html
2026-03-25 15:21:45 <veltas      > And yes what iv4nshm4k0v said
2026-03-25 15:21:49 <veltas      > It's just lisp but worse
2026-03-25 15:21:59 <vms14       > actually print forces the reading of one word and executes it, which is +, then + forces the reading of two more values
2026-03-25 15:22:18 <veltas      > MrMobius: nice
2026-03-25 15:22:40 <vms14       > i don't remember why i stopped with that experiment, but i'll try again
2026-03-25 15:22:46 <veltas      > vms14 this is just harder than RPN to implement, and not really any easier to read than RPN
2026-03-25 15:22:56 <veltas      > Unless you add parens in which case it's l***
2026-03-25 15:23:13 <vms14       > yeah, i don't want to make a lisp, i just want a command based lang :/
2026-03-25 15:23:28 <veltas      > I suspect the reason you're oscillating a lot currently is because you aren't thinking too hard about what you're spending your time on :P
2026-03-25 15:24:11 <vms14       > veltas: like "why not just use an existing mainstream lang instead of making my own random stuff?"
2026-03-25 15:24:23 <veltas      > It helps to actually have some goals (even personal subjective ones) and think about design a bit
2026-03-25 15:24:32 <vms14       > but making random interpreters is what i like the most
2026-03-25 15:24:55 <veltas      > I'm not saying don't reinvent the wheel, I'm saying you might enjoy yourself more if you actually think a little harder about what you're doing
2026-03-25 15:25:15 <vms14       > like stop and think instead of keep walking in circles
2026-03-25 15:25:20 <veltas      > Yeah
2026-03-25 15:25:26 <veltas      > Because we've explained pretty much why your idea, of using reverse-reverse-polish, is a bit of a dead end
2026-03-25 15:25:37 <veltas      > And it sounds like you already discovered this yourself but have forgotten
2026-03-25 15:25:43 <vms14       > yes xD
2026-03-25 15:25:48 <vms14       > i don't remember why it failed
2026-03-25 15:25:59 <veltas      > Maybe you should make project diaries
2026-03-25 15:26:04 <vms14       > what i want to try is to make every word kind of immediate
2026-03-25 15:26:12 <vms14       > and they will return a function
2026-03-25 15:26:13 <veltas      > And just finish them with "and I stopped working on this because X was dumb and didn't work"
2026-03-25 15:27:07 <vms14       > for example 1 will be a function returning the number, then + 1 2  will make + read 1 and turn it into a function, same with the two, then return a function that will execute both functions to get the numbers and return the result
2026-03-25 15:27:37 <veltas      > This sounds basically as hard as parsing infix, so the question remains why you would do this
2026-03-25 15:27:38 <vms14       > it sounds quite cursed already
2026-03-25 15:27:57 <vms14       > yeah, i'll try anyways, won't take too much to make a prototype in perl
2026-03-25 15:28:37 <veltas      > Eventually I hope to stop hearing cries of "ow, I burnt myself on the stove" and you should stop touching the stove while it's hot
2026-03-25 15:29:11 <vms14       > veltas: i think is cool to try ideas and learn from them
2026-03-25 15:29:22 <veltas      > I think it's cool to not build houses on sand
2026-03-25 15:29:28 <vms14       > :D
2026-03-25 15:29:40 <veltas      > And when the waves come and crash on them you will not learn anything because you already knew the lesson
2026-03-25 15:30:02 <iv4nshm4k0v > I think if you don't recall why something you did in the past didn't work, you didn't really learn.
2026-03-25 15:30:08 <veltas      > ^
2026-03-25 15:31:09 <vms14       > i don't remember the reason last time, it was using arity, this time every word will gather its own values and delay execution
2026-03-25 15:31:45 <veltas      > Like every word is an immediate parsing word, to use Forth terms
2026-03-25 15:31:48 <vms14       > might be it was just too weird
2026-03-25 15:35:29 <veltas      > iv4nshm4k0v: I don't have permission to access that URL
2026-03-25 15:39:08 <vms14       > https://gitlab.com/vms14/oh/-/blob/master/oh.pm
2026-03-25 15:39:09 <iv4nshm4k0v > That's strange - I've just checked it locally and from sdf.org, and it "just works."  Perhaps https://web.archive.org/web/2025/http://am-1.org/~ivan/qinp-2024/112.l-system.en.xhtml , then?
2026-03-25 15:39:14 <vms14       > that's a test
2026-03-25 15:39:19 <vms14       > it only has + and print
2026-03-25 15:39:30 <vms14       > and strings with :str
2026-03-25 15:39:59 <vms14       > i'll try to provide if and blocks and see where it dies
2026-03-25 15:40:17 <iv4nshm4k0v > Though I see failed attempts to access "qinq" (not "qinp") in the logs.
2026-03-25 15:46:42 <veltas      > My bad lol
2026-03-25 15:48:45 <veltas      > Very nice page
2026-03-25 15:48:53 <iv4nshm4k0v > I suppose it's perhaps a tad unconventional to setup an HTTP server to use a more or less explicit list of resources to grant access to, and "403" anything that doesn't match.
2026-03-25 15:49:06 <veltas      > No it's quite normal I think
2026-03-25 15:49:41 <veltas      > And HTTP says 403 is okay if you don't want to confirm/deny whether it's forbidden or just doesn't exist
2026-03-25 15:49:46 <veltas      > I think(?)
2026-03-25 15:50:24 <veltas      > I might be thinking of 404 that doesn't confirm/deny existence
2026-03-25 15:50:43 <iv4nshm4k0v > I think 404 does confirm non-existence.  Still, my sdf.org mirror uses no such list (well, "less of such list"), so will "404" normally.  http://vathor.andropov.org/ .
2026-03-25 15:51:57 <veltas      > Nobody uses these codes right anyway, the whole web is just abused wholesale by 'APIs' now, can forgive a '403 forbidden' response for a typo
2026-03-25 15:55:49 <iv4nshm4k0v > I believe there's a plenty of websites that do it right.  Wikimedia wikis, for instance; say, https://en.wikipedia.org/wiki/Non-existent_example_article gives 404.  As I do use wget(1) and curl(1), it's kind of important that the codes are right.  (I'm pretty certain Wget does not save 4xy bodies by default, and Curl fails with a non-zero exit code for the same.)