2023-05-03 03:46:53 <veltas      > "distant from the lives and concerns of ordinary people; esoteric" is one definition
2023-05-03 03:47:48 <veltas      > What I want to say to vms14 when they're back is that it's way easier to call C code from assembly than they might think
2023-05-03 03:48:38 <veltas      > Calling conventions are designed so you can essentially have a Forth word to call an n-argument function, or just have a bunch of fixed-length function call words
2023-05-03 03:49:03 <veltas      > Complication is supporting floating point arguments, but it doesn't make it that much harder
2023-05-03 03:51:03 <veltas      > You can easily link to anything dynamically at runtime by linking dlopen et al
2023-05-03 03:52:12 <veltas      > I can't remember if it's necessary, but you might need to build as a relocatable elf, and you will want to initialise libc and avoid using memory that libc thinks it owns
2023-05-03 03:58:44 <veltas      > I believe libc 'owns' the area immediately following BSS section, i.e. what sbrk()/brk() control (and where malloc() allocates smaller main thread stuff?)
2023-05-03 04:11:38 <xelxebar    > veltas: Ah, okay. I've never seen that usage before. TIL!
2023-05-03 04:13:04 <xelxebar    > veltas: Wait, what environment is this in? Linux at least shoves solibs way up in high memory far away from BSS.
2023-05-03 04:29:51 <veltas      > What usage?
2023-05-03 04:30:53 <veltas      > I think at some point sbrk() was used that way and it was near BSS, no idea about today to be fair. But the fact it was like that means you don't want to make assumptions today either
2023-05-03 04:31:57 <veltas      > As for relocatable libraries, I wouldn't expect those to be close
2023-05-03 04:34:14 <veltas      > The traditional model which I think you can see in the ELF 32-bit x86 spec was you'd have your .text, .data, .bss, sbrk() area in that order in low addresses. Only need two different 'maps' for that, and sbrk() area can extend into higher addresses. And then the stack and environment info would be somewhere in the high addresses far away so there was plenty of room for sbrk() to grow
2023-05-03 04:35:05 <veltas      > These days we have more sections, and a much larger address space in 64-bit, so if it is all over the place now I wouldn't be shocked
2023-05-03 08:01:32 <KipIngram   > I don't remember the exact details, but last time I was working on that kind of thing I felt like there were restrictions on exactly what I could do with sections that I didn't understand the reason for.  There was something I wanted to do and nasm wouldn't let me.  It'll come to me in a little while, I imagine.
2023-05-03 08:02:23 <vms14       > what can do forth that would be hard or impossible to do in most common languages?
2023-05-03 08:02:35 <vms14       > apart of being efficient :D
2023-05-03 08:02:36 <KipIngram   > Access the return stack.
2023-05-03 08:03:05 <KipIngram   > I mean arbitrarily.  You do "access the call stack" in C whenever you use local variables.
2023-05-03 08:03:14 <vms14       > what kind of benefits does it give that
2023-05-03 08:03:21 <KipIngram   > But what I mean is actually access return addresses on the stack as though they're data.
2023-05-03 08:03:36 <vms14       > to implement jumps
2023-05-03 08:03:39 <KipIngram   > Oh, you can do things you otherwise couldn't.  My simplest example is a double return.
2023-05-03 08:03:50 <KipIngram   > Return to your caller's caller, instead of only to your caller.
2023-05-03 08:03:53 <vms14       > and call with continuations, etc
2023-05-03 08:04:09 <KipIngram   > Most anything - once you can do this you can build any kind of fancy thing.
2023-05-03 08:04:09 <vms14       > oh, that might be handy
2023-05-03 08:04:21 <KipIngram   > It IS - I promise you.  I use it regularly.
2023-05-03 08:04:32 <KipIngram   > Those return-related words changed how I code substantially.
2023-05-03 08:04:51 <KipIngram   > And I'm  pretty convinced it made my code  more compact.
2023-05-03 08:05:04 <unjust      > how many levels of nesting can you skip on return with your implementation?
2023-05-03 08:05:34 <KipIngram   > Well, I generally only have single returns and double returns, in both cases with conditional and unconditional variants.
2023-05-03 08:05:47 <KipIngram   > But since you have general return stack access you can skip as many as you want.
2023-05-03 08:05:54 <vms14       > I do realize chuck and I live in different worlds, mainly having different goals, so we aim at different things
2023-05-03 08:05:55 <KipIngram   > I just have primitives for one level and two levels.
2023-05-03 08:06:01 <vms14       > his world is an embedded device
2023-05-03 08:06:11 <vms14       > I aim to create user applications
2023-05-03 08:06:15 <KipIngram   > Yes, that was the sort of work he did.
2023-05-03 08:06:16 <unjust      > do you have store any metadata about each caller, apart from the return address itself?
2023-05-03 08:06:21 <unjust      > -have
2023-05-03 08:07:01 <KipIngram   > If you wanted to be able to make that work with anything else you did, then yes - you'd have to have a record of what else might be on the return stack aside from return info (you can store data there, temporarily).
2023-05-03 08:07:24 <KipIngram   > But I don't worry about tha t- I assume that if I use a double return word that I haven't put anything else on the return stack.
2023-05-03 08:07:28 <vms14       > it does not make sense to stick to chuck's way of doing things, since I aim for different stuff
2023-05-03 08:07:40 <KipIngram   > Like if you use >r and r> in a word, you better not return in between >r and r>.
2023-05-03 08:07:40 <vms14       > but I still think forth has a lot of concepts I could steal
2023-05-03 08:07:49 <KipIngram   > Because you'll try to return to the data that >r put there.
2023-05-03 08:08:37 <KipIngram   > The general rule in my system is that however far into the stack I try to return to, there better be ONLY return addresses on the stack.
2023-05-03 08:08:41 <vms14       > so I won't aim to make a real forth, but I have to dig deeper to see how many stuff I can steal
2023-05-03 08:08:44 <KipIngram   > If I've put anything else there it will crash.
2023-05-03 08:09:13 <KipIngram   > Of course, you could use that feature - you could transfer control to an arbitrary place by putting the address to that place on the stack with >r and then do a return.
2023-05-03 08:09:38 <KipIngram   > The point I'm trying to make is that you can create any sort of situation like that that you want, since you have full access to that stack.
2023-05-03 08:09:46 <vms14       > the only real reason I would want a call stack is to have tco
2023-05-03 08:09:50 <KipIngram   > You can do "anything that will work."
2023-05-03 08:10:36 <vms14       > returning from random points of the program could be handy, but it's not a feature I can't live without
2023-05-03 08:10:40 <unjust      > KipIngram: found any use for having multiple entry points into words, ie. possibly varying CFA depending on whether some form of initialisation is required or not?
2023-05-03 08:10:41 <KipIngram   > Return stack access is something I regard as "required if you call it Forth."
2023-05-03 08:11:13 <KipIngram   > Yes - I deliberately moved my headers to a separate memory region so that I could have multiple entry points.
2023-05-03 08:11:17 <KipIngram   > For me they work like this:
2023-05-03 08:11:28 <KipIngram   > : foo  ... : bar  ... ;
2023-05-03 08:11:39 <KipIngram   > That does exactly what you'd expect it to.
2023-05-03 08:11:46 <vms14       > KipIngram: I love your temp words btw
2023-05-03 08:11:52 <vms14       > I like that concept a lot
2023-05-03 08:11:59 <KipIngram   > Oh, the .: .wipe thing?
2023-05-03 08:12:03 <KipIngram   > Yeah, I like it too.
2023-05-03 08:12:12 <vms14       > the fact you can define temp words that will end being the definition of another, then disappear
2023-05-03 08:12:17 <KipIngram   > Forth encourages you to factor - which leads to a lot of word names that are mostly used to build other words.
2023-05-03 08:12:21 <unjust      > i'd guess the flow of execution of FOO continues into BAR? though you could just call BAR itself? rather than BAR being confined to a nested vocab/namespace of FOO?
2023-05-03 08:12:27 <KipIngram   > Once you've built the final words, you don't need those names anymore.
2023-05-03 08:12:52 <KipIngram   > Yes.  The compiled code is in one region - the headers are in another region.
2023-05-03 08:13:18 <veltas      > vms14: https://pastebin.com/raw/SRSwyMD5
2023-05-03 08:13:20 <KipIngram   > So bar just points to the code after it.  foo will start where it starts and then just execute right on into bar without even knowing it passed another entry point.
2023-05-03 08:13:28 <unjust      > nice
2023-05-03 08:13:50 <KipIngram   > Usually I'd write it like this, though:
2023-05-03 08:13:56 <KipIngram   > : foo ...
2023-05-03 08:14:00 <KipIngram   > : bar ... ;
2023-05-03 08:14:23 <KipIngram   > No difference from the first example.
2023-05-03 08:14:30 <KipIngram   > Just makes the source code look tidier.
2023-05-03 08:14:39 <vms14       > veltas: pastebin is blocked from my router wtf
2023-05-03 08:15:13 <KipIngram   > As a consequence of those conditional return words, I don't even have IF THEN in my Forth.
2023-05-03 08:15:17 <vms14       > why do they have to block pastebin xd
2023-05-03 08:15:30 <KipIngram   > I don't need it anymore - conditional returns let me build that kind of control structure.
2023-05-03 08:15:48 <KipIngram   > You might pastebin some of their IP.
2023-05-03 08:16:23 <veltas      > vms14: https://pastes.io/raw/i1pble5pqq
2023-05-03 08:16:46 <vms14       > hhaha I was using a bot to repaste the link
2023-05-03 08:16:47 <vms14       > https://perl.bot/p/uskkbu
2023-05-03 08:17:00 <unjust      > KipIngram: do you have an example to share of how your approach eliminates the use of those conditionals?
2023-05-03 08:17:10 <veltas      > vms14: And then after reading that I was going to say that Forth is fine for application software, just go for it
2023-05-03 08:18:07 <KipIngram   > vms14: you also expressed interest in a Forth with "tools."  There are certainly Forths out there you can link to C, which means you can tie them to almost any sort of library.  Just roll a system up that has what you want.
2023-05-03 08:18:38 <vms14       > I also considered to try to steal some forth implementation and add stuff
2023-05-03 08:18:48 <vms14       > for example there's a basicforth.c
2023-05-03 08:18:58 <KipIngram   > There's a lot of stuff.
2023-05-03 08:19:12 <vms14       > yeah forth has implementations in almost every language
2023-05-03 08:19:56 <KipIngram   > Well, I don't really call some of those Forth.  There's a certain kind of ability to access addresses, in an "address" sort of way, that you need to construct a Forth properly.
2023-05-03 08:20:12 <KipIngram   > Like, I know how to do it in assembly (of course) and C.  But I don't know how to do it in Python.
2023-05-03 08:20:23 <KipIngram   > I could write something that "operated like Forth" superficially in Python.
2023-05-03 08:20:23 <vms14       > but I wonder what if instead of sticking to forth I just steal the concepts I like
2023-05-03 08:20:30 <KipIngram   > But I wouldn't really call it Forth.
2023-05-03 08:21:13 <vms14       > the more concepts I want to steal, the closer it needs to get to a real forth
2023-05-03 08:21:32 <KipIngram   > I don't know how to extract the address of a structure in Python, and I don't think it promises you that such addresses will stay the same anyway.
2023-05-03 08:21:53 <vms14       > since my goal is to use existing libraries, assembly does not make much sense
2023-05-03 08:22:04 <KipIngram   > But C gives you pointers, so you can do something with that.
2023-05-03 08:22:12 <veltas      > I think assembly makes as much sense there as anything
2023-05-03 08:22:26 <KipIngram   > And in gcc you can get pointers to labels, which means pointers to code.
2023-05-03 08:22:29 <vms14       > well forth wants to be written in assembly
2023-05-03 08:22:35 <veltas      > Yeah use assembly
2023-05-03 08:22:36 <KipIngram   > And THAT lets you make a "real Forth."
2023-05-03 08:22:36 <vms14       > it's what it expects
2023-05-03 08:22:38 <KipIngram   > It does.
2023-05-03 08:22:51 <KipIngram   > But you can get there in c, particularly gcc.
2023-05-03 08:23:02 <veltas      > But they've already done a high-level forth
2023-05-03 08:23:28 <vms14       > yeah, the most logical option is to try to implement a real forth
2023-05-03 08:23:34 <vms14       > then decide what I want and what not
2023-05-03 08:23:54 <KipIngram   > I think you "should," but that's just me, because I've done it and enjoyed it.  But you're you.  :-)
2023-05-03 08:23:58 <veltas      > I would read Moving Forth and then start writing basic words (like Brad suggests) in x86 or whatever assembly language you're going to use
2023-05-03 08:24:11 <KipIngram   > I think you'd find it to be easy once you got started.
2023-05-03 08:24:28 <vms14       > I also had the idea of making some sort of fake assembly language
2023-05-03 08:24:28 <veltas      > I don't know which assembly language you're most comfortable in
2023-05-03 08:24:31 <vms14       > but meh
2023-05-03 08:24:35 <veltas      > You can do that as well
2023-05-03 08:24:41 <KipIngram   > Well, it's easier if you start with the low level stuff and make sure each bit is working before you move on.
2023-05-03 08:24:43 <vms14       > veltas: I do not know assembly yet xD
2023-05-03 08:24:46 <veltas      > That's how retro works, you're pretty much talking about a VM
2023-05-03 08:24:52 <KipIngram   > Which means the very first thing you write is the "next" code.
2023-05-03 08:24:54 <vms14       > it's something I always wanted to learn
2023-05-03 08:25:03 <KipIngram   > That's the code that moves you along from primitive to primitive.
2023-05-03 08:25:14 <veltas      > vms14: Do you want to start with a desktop forth?
2023-05-03 08:25:14 <vms14       > I have some basic stuff, but never done more than a hello world
2023-05-03 08:25:20 <KipIngram   > Then you write the words that enter and leave new colon definitions.
2023-05-03 08:25:23 <vms14       > veltas: I want a desktop forth
2023-05-03 08:25:27 <vms14       > that runs on my computer
2023-05-03 08:25:32 <veltas      > x86?
2023-05-03 08:25:44 <vms14       > it's all I want, a forth that I can use for any kind of program
2023-05-03 08:25:59 <vms14       > the main goal is to make forth my main language and code only in forth
2023-05-03 08:26:06 <KipIngram   > And also early you write a "terminate" primitive.  You can do a lot of debugging once you have that.
2023-05-03 08:26:11 <veltas      > What OS and arch are you on?
2023-05-03 08:26:13 <vms14       > that's why I end making abominations
2023-05-03 08:26:24 <vms14       > Netbsd amd64
2023-05-03 08:26:39 <veltas      > Does netbsd support 32-bit compatibility?
2023-05-03 08:27:01 <KipIngram   > You initially will be constructing your colon definitions manually, as assembler data structures.
2023-05-03 08:27:07 <vms14       > https://man.netbsd.org/compat_netbsd32.8
2023-05-03 08:27:09 <vms14       > it seems
2023-05-03 08:27:13 <veltas      > I think I would recommend starting with a 32-bit x86 Forth (it will be smaller, easier, and probably faster)
2023-05-03 08:27:14 <KipIngram   > And your assemblers macro facility can help you with that.
2023-05-03 08:27:38 <KipIngram   > If you use 64 bit you get twice as many registers.
2023-05-03 08:27:59 <KipIngram   > and they're useful.
2023-05-03 08:28:09 <veltas      > True
2023-05-03 08:28:21 <veltas      > 32-bit is a valid option anyway
2023-05-03 08:28:28 <vms14       > I had some look at mips, I know a guy who loves mips
2023-05-03 08:28:35 <veltas      > Well you don't have mips
2023-05-03 08:28:40 <vms14       > I wonder why he does
2023-05-03 08:28:42 <KipIngram   > Mine's 64-bit instructions, but I still use 32-bit cells in definitions and stuff.
2023-05-03 08:28:49 <KipIngram   > 64-bit wide stacks, though.
2023-05-03 08:29:11 <KipIngram   > But that does mean that the items in definitions will be offsets from somewhere, rather than full addresses.
2023-05-03 08:29:28 <vms14       > veltas: yeah, but I can get several emulators, althought yeah, it would be cooler if the language runs on my machine natively
2023-05-03 08:29:40 <KipIngram   > So next, docol, and so on have to translate the offsets into addresses.
2023-05-03 08:30:05 <veltas      > And I recommend using nasm because it's got some macro support and is much closer to the manual's syntax than gas
2023-05-03 08:30:14 <veltas      > gas' syntax is far far away
2023-05-03 08:30:14 <KipIngram   > I'm strongly considering using 16-bit xt's in my next one.
2023-05-03 08:30:22 <KipIngram   > To see how compact I can make it.
2023-05-03 08:31:13 <KipIngram   > But that looks to me like it makes it a bit more like a token-threaded system, with 16-bit tokens.
2023-05-03 08:31:34 <KipIngram   > And it would give me a limit of 64k xt's max.
2023-05-03 08:32:01 <vms14       > it's time to become a man
2023-05-03 08:32:45 <KipIngram   > I'd be happy to share my nasm macros with you, though working them up yourself would be educational.
2023-05-03 08:32:45 <veltas      > Start with a hello world and just keep adding stuff until it's a forth environment
2023-05-03 08:33:20 <veltas      > And get godbolt.org to write all your code for you
2023-05-03 08:33:29 <vms14       > KipIngram: yeah don't worry, I prefer to come to ask stuff
2023-05-03 08:33:49 <KipIngram   > Me too - good.
2023-05-03 08:34:13 <KipIngram   > You'll find that you only need a small subset of the x86 instruction set.  A ton of it you'll never use.
2023-05-03 08:34:22 <KipIngram   > Mostly moves, math, and jumps.
2023-05-03 08:34:33 <KipIngram   > math/logic
2023-05-03 08:36:23 <KipIngram   > You'll have a program that first runs some initialization assembly code, then starts an "outermost" colon definition, and stay in that forever.
2023-05-03 08:37:20 <veltas      > I'm being serious when I say get godbolt.org to write your code for you, because it will make some intelligent suggestions for shortening your code and stop you scratching your head trying to figure out the right mnemonics
2023-05-03 08:37:34 <veltas      > And download Intel's x86 manual volume 2
2023-05-03 08:37:44 <KipIngram   > Use registers for a) top item of data stack, b) top address of data stack, c) top address of return stack, and d) instruction pointer.  You'll discover other things for other registers, but that's the starting point.
2023-05-03 08:38:08 <KipIngram   > It's helpful to have a "normal stack" too, since you'll be wanting to call the OS.
2023-05-03 08:38:23 <KipIngram   > I just use the one that's naturally provided - I never actually touch the native stack pointer.
2023-05-03 08:38:51 <veltas      > If you do subroutine threading then return stack is the actual stack rsp, and data stack you'll almost certainly put in rbp
2023-05-03 08:39:25 <KipIngram   > Chuck advocates a pair of "address registers"; rsi and rdi make the most sense for those since they support the processor's auto-increment/decrement stuff.
2023-05-03 08:39:49 <veltas      > If you look at the ABI calling conventions for which registers are saved by functions, then the ones which are saved are better choices for important environment registers because you don't need to save/restore yourself when calling C
2023-05-03 08:40:12 <KipIngram   > I usually winid up deciding that rcx makes the most sense for the cached top of data stack item, but the rest are just choices you make.
2023-05-03 08:40:18 <veltas      > Remember "rsi" and "rdi" stand for "source" and "destination"
2023-05-03 08:40:30 <KipIngram   > Yeah.
2023-05-03 08:40:39 <KipIngram   > And don't forget that direction flag.
2023-05-03 08:41:07 <KipIngram   > It tells the auto-increment instructions which way to go.
2023-05-03 08:42:12 <vms14       > ty for the hints and help :D
2023-05-03 08:42:19 <veltas      > And the first two parameters in SYS-V AMD64 are rdi, rsi, because that's the memcpy order "dst, src" (I don't know if that's the reason, but it makes sense to me, especially since first parameter is very often an address to an object to modify)
2023-05-03 08:42:22 <vms14       > I'll go to steal some asm book and eat something
2023-05-03 08:42:32 <vms14       > see you
2023-05-03 08:42:41 <KipIngram   > :-)
2023-05-03 08:42:48 <KipIngram   > Nice watching them grow up...
2023-05-03 08:44:59 <KipIngram   > Oh, I think I remember that the thing I wanted to be able to do in nasm but couldn't.  It had to do not with sections per se but rather with the "org" directive.
2023-05-03 08:45:18 <KipIngram   > I wanted to just be able to use it arbitrarily, but I think the catch was that nasm won't let me move it backwards.
2023-05-03 08:45:32 <KipIngram   > Once you "org" to somewhere, you can then only org ahead.
2023-05-03 08:46:16 <KipIngram   > Re: sections, what I wanted was to be able to lay out my sections at specific places in a wider address range.
2023-05-03 08:46:27 <KipIngram   > Instead of the assembler just placing them for me.
2023-05-03 08:46:33 <veltas      > Actually to be fair rbp is a bad choice for data stack
2023-05-03 08:46:47 <KipIngram   > It'll just put them one after another, but I wanted to have extra space in between to "grow into."
2023-05-03 08:46:51 <veltas      > Because accessing the top (or second) stack item is a larger instruction
2023-05-03 08:46:59 <veltas      > The offset is always encoded
2023-05-03 08:47:15 <KipIngram   > I use some of r8-r15 for most of those things.
2023-05-03 08:47:33 <KipIngram   > rdi, rsi, and rcx are the only "lettered" ones I use initially.
2023-05-03 08:47:50 <KipIngram   > I think I wound up making rbp my "setjmp/longjmp" pointer.
2023-05-03 08:48:05 <KipIngram   > Which was one of the last things I added.
2023-05-03 08:48:19 <veltas      > r8-r15 often require an extra prefix when they're used, depending on the instruction
2023-05-03 08:48:30 <KipIngram   > It holds a "restore pointer" into the return stack for that word that jumps way out of a deep call stack.
2023-05-03 08:49:00 <KipIngram   > Which means it's used only very rarely, a couple of times in the whole system.
2023-05-03 08:49:26 <KipIngram   > Probably could have done that with a variable instead of a register with practically no performance impact.
2023-05-03 08:49:58 <veltas      > Yeah
2023-05-03 08:50:16 <KipIngram   > Oh, and in my list of registers I forgot to mention the one that I use that points to the base of the system.
2023-05-03 08:50:36 <KipIngram   > Since I have to do that offset->address translation a whole lot, that calls on a register for sure.
2023-05-03 08:51:03 <veltas      > That's what rip's for
2023-05-03 08:51:08 <KipIngram   > I also put next at the very beginning, so that jmp <reg> to that register gets me to next.
2023-05-03 08:51:20 <KipIngram   > Yeah, rip has a real address in it.
2023-05-03 08:51:36 <KipIngram   > But when next picks up the next primitive to go to, it needs to translate.
2023-05-03 08:51:51 <KipIngram   > And when docol picks up the starting item of a new definition, it needs to translate.
2023-05-03 08:52:16 <KipIngram   > But the return addys on the stack are 64 bit, rip is 64 bit.
2023-05-03 09:01:34 <veltas      > Well it's useful for STC forths
2023-05-03 09:02:37 <veltas      > Yeah now I think about it, rbx is the best choice for the data stack
2023-05-03 09:02:47 <veltas      > On sysv amd64 anyway
2023-05-03 09:03:16 <veltas      > I'm going to change that in my ilo amd64 implementation
2023-05-03 09:03:25 <KipIngram   > Another benefit of 64-bit instructions is that they're more orthogonal - in the earlier incarnations there are some things you can't do with some registers.
2023-05-03 09:03:36 <veltas      > Which I am actually still working on in my brief moments of free time :)
2023-05-03 09:03:38 <KipIngram   > But they seemed to "relax" that going to 64-bit.
2023-05-03 09:04:39 <veltas      > And another benefit is you can assume vector instructions, but I would assume that anyway, I'm not trying to target your rusty 80386
2023-05-03 09:06:14 <thrig       > does rust even build on i386?
2023-05-03 09:06:27 <veltas      > :)
2023-05-03 09:06:53 <veltas      > Why would someone want rust on their computer anyway
2023-05-03 09:07:03 <thrig       > cpu fan speed benchmarks
2023-05-03 09:07:16 <KipIngram   > I've never been "called" to rust.
2023-05-03 09:07:30 <KipIngram   > It kind of fell into that "yet another language" category for me.
2023-05-03 09:07:39 <KipIngram   > Which isn't fair for me to say - I've learned nothing about it.
2023-05-03 09:07:58 <veltas      > Rust(R)
2023-05-03 09:11:20 <veltas      > I just hate all the politics, in a vacuum I think Rust is alright, but I don't think it's necessarily good when there are armies of people who think everything will suddenly improve if it's rewritten in rust from scratch
2023-05-03 09:11:54 <veltas      > Rust is a good language choice for new projects, but please stop trying to rewrite everything in Rust
2023-05-03 09:12:02 <KipIngram   > Yeah, that "zealotry."  I don't even know if that's a word, but it probably ought to be.
2023-05-03 09:12:30 <veltas      > It's essentially necessary for people to take Rust seriously
2023-05-03 09:12:47 <veltas      > So I regret the politics rather than the people, I know why they're doing it
2023-05-03 09:13:09 <veltas      > The big drive to rewrite stuff in rust makes it more important/appealing/etc
2023-05-03 09:13:25 <veltas      > It's fun to rewrite stuff, it's harder to maintain it
2023-05-03 09:14:20 <thrig       > probably https://www.jwz.org/doc/cadt.html but it's telling me bots are forbidden
2023-05-03 09:14:28 <veltas      > I'm glad it's got a potential of dethroning C++ which is trying to be like rust is but has so much baggage
2023-05-03 09:15:56 <KipIngram   > I think politics is just a human hobby.  It seems we add it to damn near everything.
2023-05-03 09:15:58 <veltas      > It won't touch C because C's written by people that worship it (UNIX), or refuse to learn anything else (embedded)
2023-05-03 09:18:38 <veltas      > And also it is a different class of language entirely, C is disguised as a small, approachable programming language. Rust is much larger and more intimidating
2023-05-03 09:20:02 <unjust      > though nothing stops you from using C++ without the bloated frameworks and libstdc++ if you just want some approximation of C (yes, i know the core language standard differs from the C standards - but there is a ton of crossover) with classes and templates
2023-05-03 09:20:06 <KipIngram   > Yeah, C fancies itself "low level," because it was when it was born.
2023-05-03 09:20:19 <KipIngram   > It fit PDP11 like a glove.
2023-05-03 09:20:46 <veltas      > What features does C++ have that I'd want?
2023-05-03 09:21:16 <KipIngram   > Honestly I've mostly only used C stuff even if I was running a C++ compiler.
2023-05-03 09:21:28 <thrig       > some have described C++ as three languages standing atop one another in a trenchcoat
2023-05-03 09:21:35 <KipIngram   > Maybe I used the C++ "streams" syntax a time or two.
2023-05-03 09:21:49 <KipIngram   > lmao
2023-05-03 09:25:30 <veltas      > C fits every major arch like a glove, there's instructions in x86 I swear were designed specifically for C, i.e. SETx instructions
2023-05-03 09:25:53 <veltas      > Architectures are designed to fit C, not the other way around
2023-05-03 09:29:13 <veltas      > But also C was designed as a high level language originally, and the standards committee sees it that way as well because they keep failing to define stuff that should be allowed on most reasonable arches that was supported on the original compilers
2023-05-03 09:38:51 <KipIngram   > Yes, the whole business has been a very incestuous "codevelopment."
2023-05-03 09:39:42 <KipIngram   > The argument, though, would be that C is no longer "low level" in the sense that it gets at the *hardware*.  Of course, that's mostly just a complaint about how all of our instruction sets these days are kind of virtual.
2023-05-03 09:40:02 <KipIngram   > I wish Intel would open access the ability to write microcode for their processors.
2023-05-03 09:42:10 <thrig       > but that would surface the make_amd_slow and nsa_entrypoint channels
2023-05-03 09:43:27 <KipIngram   > Yeah.
2023-05-03 09:43:57 <KipIngram   > Just think of the innovation we'd get, though.
2023-05-03 09:44:06 <KipIngram   > It's hard to imagine how extensive it would be.
2023-05-03 09:44:18 <thrig       > an innovative list of exploits and several rounds of updates for security patches
2023-05-03 09:44:37 <KipIngram   > Oh yeah, hackers are nothing if not smart.
2023-05-03 09:44:50 <KipIngram   > I was really impressed with spectre and meltdown.
2023-05-03 09:45:27 <KipIngram   > It's like the mafia - I read a history of the mafia in America called "Five Families," and one thing that stands out is that some of those guys are damn smart and work hard as hell.
2023-05-03 09:45:47 <KipIngram   > I have no doubt they could have prospered "doing things right."  They just chose not to.
2023-05-03 09:46:14 <KipIngram   > There was almost nothing they didn't find a way to get their fingers into.
2023-05-03 10:27:51 <veltas      > C is certainly more machine-friendly than most languages, but Rust and C++ also have this machine-friendliness. The difference is that C is much smaller in terms of features (although there are many caveats in C), so it feels a lot easier to "just write code" sometimes
2023-05-03 10:28:09 <veltas      > And I like that, it's freeing, I can spend less time designing when the language constrains what you can do a bit
2023-05-03 10:30:05 <veltas      > And this is part of why I'm happy with Forth's limited standard library, because I can just work on solving the problem and not worry so much about which features I need, and I can just memorise most of the words I need and rarely consult the spec
2023-05-03 10:46:47 <KipIngram   > Yeah.  It's easy for me to understand my attachment to Forth - I'm an embedded guy, and Forth is just hard to beat for embedded work.
2023-05-03 10:47:17 <KipIngram   > I don't really mean using a Raspberry Pi or something to build some gadget - I'm talking about completely from scratch things.
2023-05-03 10:47:32 <KipIngram   > "Never before existed" hardware configurations.
2023-05-03 12:09:32 <MrMobius    > MIPS is awesome in case vms14 asks again
2023-05-03 12:09:48 <MrMobius    > easy to emulate and runs on a cheap microcontroller
2023-05-03 12:10:19 <MrMobius    > also nasm+gdb has been broken for a while. you can debig MIPS on gdb just fine though
2023-05-03 12:10:35 <Zarutian_iPad> PIC32 ?
2023-05-03 12:12:04 <MrMobius    > ya
2023-05-03 12:12:55 <Zarutian_iPad> pic-list.com is such a treasure trove of info yet ugly as hell
2023-05-03 12:14:08 <KipIngram   > God - meeting slate from hell today.  :-|
2023-05-03 12:14:34 <Zarutian_iPad> ui/ux combined with sales?
2023-05-03 12:15:04 <KipIngram   > Well, different kinds of meetings.  The one I'm in now is a bit executive financial update whoop-te-do
2023-05-03 12:15:10 <KipIngram   > big
2023-05-03 12:15:29 <KipIngram   > The earlier ones have been various sorts of technical focus.
2023-05-03 12:15:49 <Zarutian_iPad> sounds like, in essence, like those bolshevik meetings of yore
2023-05-03 12:15:57 <KipIngram   > Yeah.
2023-05-03 12:16:02 <KipIngram   > "All hands."
2023-05-03 12:16:14 <KipIngram   > But they know whether I call into it or not.
2023-05-03 12:16:29 <Zarutian_iPad> basically a meeting that should have been an email
2023-05-03 12:16:37 <KipIngram   > It told me "registering your attendence" as I signed in.
2023-05-03 12:16:49 <KipIngram   > Yeah, it could have been an email.
2023-05-03 12:16:49 <Zarutian_iPad> oh, remote one
2023-05-03 12:16:55 <veltas      > KipIngram: direction flag must be 0 on entry and exit of a function in sys-v amd64
2023-05-03 12:16:58 <KipIngram   > yeah.
2023-05-03 12:17:22 <KipIngram   > Ok.  I just run CLD in my init and then don't worry about it any more.
2023-05-03 12:17:28 <veltas      > And at process startup
2023-05-03 12:17:36 <veltas      > I found myself double checking because you were finger wagging about DF earlier :P
2023-05-03 12:17:40 <KipIngram   > If I need the other direction for anything that primitive will be responsible for putting it back when it's done.
2023-05-03 12:17:52 <veltas      > Absolutely
2023-05-03 12:17:57 <KipIngram   > Yes, if I start any new "task instances," that will need initializing.
2023-05-03 12:18:20 <KipIngram   > Right now I only have the one execution thread, though.
2023-05-03 12:18:29 <veltas      > Well I mean it's zero when you jump to the entry point, it's up to you re your tasks but zero makes sense there too
2023-05-03 12:18:45 <KipIngram   > I want to make my next one more "green thread" friendly.
2023-05-03 12:19:02 <veltas      > What is a green thread?
2023-05-03 12:19:23 <KipIngram   > Oh, just a low resource thread - I've gotten thie impression it's a phrase used around erlang.
2023-05-03 12:19:32 <KipIngram   > I just mean a very lightweight thread.
2023-05-03 12:19:39 <Zarutian_iPad> Lua coroutine thread is example of such
2023-05-03 12:19:55 <KipIngram   > I'd like to be able to spin those up for order of 1kB apiece.
2023-05-03 12:20:04 <veltas      > I call that a coroutine
2023-05-03 12:20:09 <KipIngram   > For the simple ones that need stacks and very little more.
2023-05-03 12:20:14 <veltas      > Or cooperative thread
2023-05-03 12:20:14 <KipIngram   > Ok, coroutine is good.
2023-05-03 12:20:20 <KipIngram   > Yes.
2023-05-03 12:20:22 <veltas      > Or software thread
2023-05-03 12:20:27 <veltas      > Never heard of green thread
2023-05-03 12:20:45 <KipIngram   > I want to wire the scheduling in down at the next level.
2023-05-03 12:21:04 <KipIngram   > Every so often, next will take an alternate path and switch over to a different thread.
2023-05-03 12:22:20 <KipIngram   > The overhead on the "normal" next path will be the addition of a register decrement and a conditional jump not taken.
2023-05-03 12:23:24 <KipIngram   > It'll only take that branch once every many thousands of times, so the additional work found on that path will be amortized out pretty thin.
2023-05-03 12:24:23 <KipIngram   > And I'm thinking that I want threads to vary in terms of how many of their OPPORTUNITIES to run they take advantage of.  Lower priority threads will pass on a good many opportunities; higher priority ones won't.
2023-05-03 12:24:46 <KipIngram   > And I'd run such a process on each core.
2023-05-03 12:25:47 <drakonis    > https://github.com/inpla/inpla fancy.
2023-05-03 12:26:44 <drakonis    > this link actually isnt all that fit for the channel but remains neat nonetheless
2023-05-03 12:26:54 <KipIngram   > Oh, that looks pretty interesting.
2023-05-03 12:27:01 <drakonis    > this is an implementation of interaction nets
2023-05-03 12:27:34 <KipIngram   > Forth or not, I'm happy to know about it.  Such things are just generally interesting.
2023-05-03 12:27:44 <KipIngram   > I like programming models.
2023-05-03 12:27:50 <drakonis    > the implementation is fairly simple too
2023-05-03 12:28:13 <KipIngram   > God, this is a very "sales" oriented meeting.
2023-05-03 12:28:22 <KipIngram   > Absolutely meaningless to my doing my job.
2023-05-03 12:28:27 <KipIngram   > me
2023-05-03 12:28:46 <KipIngram   > Hey, who knows anything about hugepages in Linux?
2023-05-03 12:29:20 <jgaz        > Me, maybe. It has been a while. What is your question?
2023-05-03 12:29:25 <KipIngram   > I put new latest generation drives in my stand yesterday - the boards were respun to address signal integrity issues.
2023-05-03 12:29:53 <KipIngram   > I can already see that they're much better, but I still have one remaining glitch in my test setup and I'm wondering if it's a resource depletion issue around hugepages.
2023-05-03 12:30:16 <KipIngram   > How do I see how much hugepage resources I have, and configure it for more?
2023-05-03 12:30:38 <KipIngram   > And if I have multiple processes all using hugepages, does it represent a "shared resource"?
2023-05-03 12:31:13 <drakonis    > huge pages has to do with allocation, no?
2023-05-03 12:31:20 <KipIngram   > Do programs generally aquire hugepages throughout execution, like dynamic memory, or is it more typical that they grab the resources they need at startup and then just use those?
2023-05-03 12:31:30 <KipIngram   > I'm not exactly sure, but I think so.
2023-05-03 12:31:38 <KipIngram   > Just memory blocks bigger than 4kB.
2023-05-03 12:31:52 <KipIngram   > Typically either 2MB or 1GB.
2023-05-03 12:31:58 <drakonis    > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhuge
2023-05-03 12:32:05 <jgaz        > cat /proc/meminfo
2023-05-03 12:32:06 <KipIngram   > Pardon me 2 MiB, 1 GiB.
2023-05-03 12:32:51 <drakonis    > its for rhel6 but it will serve nonetheless
2023-05-03 12:33:04 <drakonis    > https://wiki.debian.org/Hugepages
2023-05-03 12:33:15 <KipIngram   > I run a non-standard driver to handle my nvme interface, and it uses hugepages.  I'm noticing that when I have several drives under test at once, things will run great for a while and then all of a sudden several of my driver instances will hit a problem they can't handle and quit.
2023-05-03 12:33:28 <KipIngram   > That causes that drive to revert to the Linux standard driver.
2023-05-03 12:33:56 <drakonis    > aight i think i'll step back for a bit, this is out of my domain
2023-05-03 12:34:00 <KipIngram   > I typically don't see this when I'm running one drive at a time, and I typically don't see it for many hours when I'm running more, then BAM - several drives will drop back to Linux drivers at the same time.
2023-05-03 12:34:56 <veltas      > Oh you *would* say GiB wouldn't you, you dirty drive salesman
2023-05-03 12:34:58 <KipIngram   > My script setup recovers - this driver change causes my traffic generator (fio) to hang - my main script waits some period of time after starting fio, and if it's still running at that point it kills it and repeats that tetst step.  It re-installs the alternate driver when it does that.
2023-05-03 12:35:04 <veltas      > It's a GB to me and all my friends :P
2023-05-03 12:35:17 <KipIngram   > So the multi-drive tests stumble through, with some repeated steps.
2023-05-03 12:35:23 <KipIngram   > Wasted time.
2023-05-03 12:36:13 <KipIngram   > After this round is done I'm going to try to kick my hugepages allocation up substantially - I've got a ton of RAM on this box.
2023-05-03 12:36:50 <KipIngram   > It's the only place I can see these multiple driver instances having any connection to one another.
2023-05-03 12:37:23 <KipIngram   > They shouldn't even know one another is running - they each are looking at different PCI addresses.
2023-05-03 12:39:17 <KipIngram   > I do miss the old days when I worked on actual hardware and the software that runs on it.  I'm listening to this meeting, and it's like the whole world has focused in on "virtual this" and "software defined that" "containerized" yadda yadda yadda.
2023-05-03 12:39:52 <KipIngram   > At least my daily work is focused on actual drives I can hold in my hand.
2023-05-03 12:40:08 <thrig       > but who Kubernetes the Kubernetes?
2023-05-03 12:41:23 <KipIngram   > I know I should learn more about all that, but I've just avoided doing so.
2023-05-03 12:46:57 <veltas      > Is it a fad, will it die out?
2023-05-03 12:47:13 <veltas      > I've got no idea, I've just been using make over here
2023-05-03 12:51:57 <thrig       > rumor has it some googler's removed Stuart Feldman's tab key from the host they built for him
2023-05-03 13:00:08 <KipIngram   > Well, I think that depends on whether anything replaces it.  I'm not really sure I see any reason we'd "go back" at this point.  People seem to attach a lot of value to the flexibility they get from such setups.
2023-05-03 13:00:27 <KipIngram   > I don't claim there are no advantages.
2023-05-03 13:00:52 <KipIngram   > If typical trends hold, we'll add "more layers" of some sort going forward.
2023-05-03 13:01:15 <thrig       > until, eventually, "The Machine Stops"
2023-05-03 13:01:16 <KipIngram   > So this stuff will still "be there" but it'll be hidden underneath other things and those other things will become what everyone is talking about.
2023-05-03 13:02:21 <drakonis    > kubernetes is hell
2023-05-03 13:02:25 <KipIngram   > I figure the machine will run right along, until an asteroid or a pandemic with our name on it comes along, or we nuke ourselves back into the stone age, or we get a runaway greenhouse thing.
2023-05-03 13:02:47 <drakonis    > the last two are more likely to happen
2023-05-03 13:02:52 <drakonis    > actually
2023-05-03 13:02:55 <KipIngram   > I think so too.
2023-05-03 13:02:57 <drakonis    > the last three are more likely
2023-05-03 13:03:11 <drakonis    > but the last two are very close by
2023-05-03 13:03:18 <KipIngram   > The first one will happen SOONER OR LATER, but we may get ready to stop it, and it's likely to be a long long time.
2023-05-03 13:03:21 <thrig       > odds are we won't forget how to ferment things like they didn't know in the stone age
2023-05-03 13:03:28 <KipIngram   > Yep.
2023-05-03 13:03:53 <KipIngram   > And a pandemic or a nuclear holocaust won't kill EVERYBODY.
2023-05-03 13:04:03 <KipIngram   > Some folks will start clambering back up again.
2023-05-03 13:07:46 <KipIngram   > I hope some people somewhere have established a number of "paper document repositories" around the world.
2023-05-03 13:08:00 <KipIngram   > So that if we lose our tech we won't have to start over completely from scratch.
2023-05-03 13:08:07 <thrig       > oh, kindling
2023-05-03 13:08:21 <KipIngram   > And more than a small number, because yeah - some idiots will come along and burn some of them.
2023-05-03 13:08:37 <KipIngram   > I wish I could take an axe handle to the guys that burned the library at Alexandria.
2023-05-03 13:08:44 <thrig       > also paper doesn't last long
2023-05-03 13:08:47 <KipIngram   > God knows what we lost.
2023-05-03 13:09:03 <KipIngram   > Well, I just mean some kind of medium that we can access without technology.
2023-05-03 13:09:03 <Zarutian_iPad> those 5d holographic things made of boro slica class work wonders
2023-05-03 13:09:09 <thrig       > there was also a Chinese emperor who had a bunch of books burned
2023-05-03 13:09:26 <KipIngram   > Yeah, it's happened all over the place.
2023-05-03 13:09:38 <KipIngram   > There was an incident in another part of Africa too.
2023-05-03 13:09:40 <drakonis    > it repeated a lot throughout history
2023-05-03 13:09:42 <Zarutian_iPad> and you can have a few ‘pages’ on hardened clay tablets on how to read those
2023-05-03 13:10:33 <KipIngram   > Songhai dynasty, I think.
2023-05-03 13:10:36 <thrig       > some of the hardened clay tables were due to rioters setting the minoan palaces on fire
2023-05-03 13:13:03 <KipIngram   > In the Songhai case it wasn't religious or anything - they just got an emporer that had a distaste for intellectuals.
2023-05-03 13:13:39 <KipIngram   > Some guy had a series of YouTube videos on historical empires that I worked through.
2023-05-03 13:14:07 <KipIngram   > So, this weekend I want to set up a new Raspberry Pi for my media room.
2023-05-03 13:14:12 <Zarutian_iPad> have you seen those olden Chinese books? Often you need to learn what is in them before you can read them I heard
2023-05-03 13:14:18 <KipIngram   > I've had all the stuff for it around a while - just need to get it done.
2023-05-03 13:14:40 <KipIngram   > That sounds... "so sensible."
2023-05-03 13:15:21 <thrig       > translation is fun when the four characters can be read in at least three different ways
2023-05-03 13:15:26 <KipIngram   > Another problem is that languages evolve, and sometimes so much that you can't read the old stuff anymore.
2023-05-03 13:15:38 <drakonis    > the power of puns is infinite
2023-05-03 13:15:47 <KipIngram   > I saw one guy plug classical Latin as a storage medium for that reason.  Being a dead language, it's no longer changing.
2023-05-03 13:15:49 <Zarutian_iPad> note that Chinese writing is ideogramic and not sensible like alphabets or alphasyllabry based writing
2023-05-03 13:16:06 <drakonis    > a dead language stops being dead once it gets used in large scale again
2023-05-03 13:16:20 <KipIngram   > Sure - if it's used for daily living.
2023-05-03 13:16:34 <thrig       > lords of COBOL, hear our prayer
2023-05-03 13:16:37 <KipIngram   > There's a great book on all that called "The Unfolding of Language."
2023-05-03 13:17:38 <Zarutian_iPad> one example I heard that has changed meaning is “living from paycheque to paycheque”. It now means barely making ends meet but it used to mean such a person was a spendthrift.
2023-05-03 13:18:03 <Zarutian_iPad> lojban might be pentatic enough to not change
2023-05-03 13:18:12 <thrig       > nope, there are folks changing lojban
2023-05-03 13:18:50 <thrig       > so you have "Old High Lojban" from the Red Book, and then what folks on some new discord or something are doing ...
2023-05-03 13:18:55 <Zarutian_iPad> adding words yes but not chaning the meaning of already established ones
2023-05-03 13:19:12 <Zarutian_iPad> changing*
2023-05-03 13:19:19 <KipIngram   > I collect older paper books about controversial things, because I don't trust us not to slip changes into digital libraries.
2023-05-03 13:20:02 <KipIngram   > I kicked that off with a 54-volume copy of Britannica's "Great Books" library published in 1952.  Picked up on eBay for about $400 for all 54 volumes.
2023-05-03 13:20:10 <Zarutian_iPad> I do not consider cloud based stuff like Kindle a “library”
2023-05-03 13:20:28 <KipIngram   > I know, but it's the direction things are headed.
2023-05-03 13:20:45 <KipIngram   > And I use ebooks quite a lot, but it comforts me to collect these "real books" too.
2023-05-03 13:20:50 <thrig       > nope, they be changing lojban words to make it more usable for actually speaking in it
2023-05-03 13:20:55 <jgaz        > Is it possible to make gforth not echo "redefined" when I execute a word that has been overwritten by a new deffinition?
2023-05-03 13:20:58 <Zarutian_iPad> save pdfs or postrscript files of stuff you do not want to have in paper
2023-05-03 13:21:21 <KipIngram   > Yeah, I could do that too - just maintain my own digital library.
2023-05-03 13:21:46 <Zarutian_iPad> thrig: but that is just on discord so it is ephimeral
2023-05-03 13:21:53 <KipIngram   > Maybe I'll look into that while I'm setting up this media room stuff.  It'll need a big fat drive for its content; I could multi-use that.
2023-05-03 13:22:13 <KipIngram   > Back it up periodically.
2023-05-03 13:22:49 <KipIngram   > This new Pi is a 4B, which already isn't that "new" anymore.
2023-05-03 13:23:01 <KipIngram   > I'm leaning toward OSMC/Kodi for the media content.
2023-05-03 13:24:15 <Zarutian_iPad> 
ACTION is reading a ‘thread’ on cash vs credit cards and is wondering why the heck some peeps insist that, specially small, businesses would transport it to a bank

2023-05-03 13:24:31 <Zarutian_iPad> look into JellyFin too
2023-05-03 13:25:21 <KipIngram   > And I've got a 2TB drive that should be fine to start out with.
2023-05-03 13:25:25 <Zarutian_iPad> 
ACTION adds: It is not that wierd if the business pays out in cash too to employees and suppliers.

2023-05-03 13:26:15 <KipIngram   > I like cash - it has a pleasant anonymity to it.
2023-05-03 13:26:56 <Zarutian_iPad> not only that. It just works even when the Point Of Sale terminal does not
2023-05-03 13:28:00 <Zarutian_iPad> I do carry cash but most places here accept card which many peeps use.
2023-05-03 13:28:47 <KipIngram   > Yeah, that to.
2023-05-03 13:28:58 <KipIngram   > I also try to have a small amount of cash on me all the time.
2023-05-03 13:29:01 <Zarutian_iPad> and it is rather easy to bork a POS terminal at an obnoxiously expensive bar like a friend of mine did
2023-05-03 13:29:34 <KipIngram   > I ought to replenish that; I'm down to a little less than I like to have.
2023-05-03 13:29:47 <KipIngram   > Tank of gas or so.
2023-05-03 13:29:52 <Zarutian_iPad> just trip tamper detection switch in the POS and it wipes certain crypto keys from its memory
2023-05-03 13:30:15 <KipIngram   > Well, that seems reaosnable.
2023-05-03 13:30:27 <KipIngram   > As a precaution, I mean.
2023-05-03 13:31:40 <Zarutian_iPad> yeah but it can mean that on friday or saturday night the place is down a pos and slows service down causing folks to go elsewhere
2023-05-03 13:31:56 <KipIngram   > Sure.
2023-05-03 13:32:23 <KipIngram   > I guess any business that wanted to could bear a little extra cost and have a redundant one.
2023-05-03 13:33:08 <thrig       > been a while since a good Carrington Event
2023-05-03 13:33:19 <KipIngram   > :-)  No kidding.
2023-05-03 13:33:26 <KipIngram   > And no one really takes that seriously.
2023-05-03 13:34:10 <KipIngram   > Any of us who wanted to could store backup electronics in a Faraday cage, but without a world to connect them to, you don't gain a lot.
2023-05-03 13:34:20 <KipIngram   > That would just cause utter chaos.
2023-05-03 13:35:19 <KipIngram   > And could shift the balance of power in the world, because it's the sort of thing that's going to affect one face of the world more than the other.
2023-05-03 13:35:35 <KipIngram   > So it's like Russian roulette - who happens to be pointing at the sun?
2023-05-03 13:35:51 <KipIngram   > At least we have a 50% chance that it's Russia and China.
2023-05-03 13:37:36 <KipIngram   > Also, at least there's a lot of optical fiber infrastructure.  The equipment at each end is still electronic, but those things could be caged.
2023-05-03 13:37:53 <KipIngram   > I wouldn't think such a thing would have any affect on the optical datapath itself.
2023-05-03 13:38:40 <KipIngram   > I know Carrington took out telegraph lines, but think about how those were made - a pair of wires, spaced a foot or several feet apart, the whole way from end to end.
2023-05-03 13:38:44 <KipIngram   > That's a big loop.
2023-05-03 13:38:58 <KipIngram   > Coaxial cable would be a lot less affected.
2023-05-03 13:39:12 <KipIngram   > It's hard to predict  how bad it might be.
2023-05-03 13:39:23 <Zarutian_iPad> coaxial cable is pretty much shielded
2023-05-03 13:39:31 <KipIngram   > Yeah - that's what I mean.
2023-05-03 13:39:33 <thrig       > get Bill Nye on the job... for science!
2023-05-03 13:39:46 <KipIngram   > So we might be a lot better off than they were back then.
2023-05-03 13:40:20 <KipIngram   > I expect the equipment damage came from that big loop producing a voltage pulse - I bet it wasn't the local flux around the equipment itself.
2023-05-03 13:40:28 <KipIngram   > We had a great big loop antenna out there.
2023-05-03 13:50:51 <KipIngram   > Even twisted pair would be a whole lot better than those telegraph lines.
2023-05-03 13:51:14 <KipIngram   > I'd never really given it all that level of thought - I may need to downgrade my concerns over such things some.
2023-05-03 13:55:04 <KipIngram   > Hey, does anyone know what "qpars" would mean in the context of data storage?  There is "queue pairs," but it seems a little odd to me to just drop one letter.
2023-05-03 13:55:37 <KipIngram   > But it may be that anyway; maybe someone found the i offensive.
2023-05-03 13:59:01 <veltas      > < Zarutian_iPad> have you seen those olden Chinese books? Often you need to learn what is in them before you can read them I heard
2023-05-03 13:59:09 <veltas      > That sounds like some documents I've reviewed
2023-05-03 13:59:52 <KipIngram   > Ah, "quality parameters."  In statistical modeling.
2023-05-03 14:02:57 <veltas      > What weird language should I learn?
2023-05-03 14:03:29 <veltas      > I probably won't but I would probably learn Esperanto
2023-05-03 14:03:39 <KipIngram   > Or may not statistcs - it also shows up when discussing lossy compression.
2023-05-03 14:03:58 <KipIngram   > Someone asked me about it; that's probably the context they were facing.
2023-05-03 14:10:54 <vms14       > veltas: what if I start with the z80?
2023-05-03 14:11:16 <vms14       > for some reason I keep coming to it
2023-05-03 14:11:21 <vms14       > https://wwwhomes.uni-bielefeld.de/achim/z80-asm.html
2023-05-03 14:11:38 <vms14       > there's also the fmsx emulator
2023-05-03 14:11:53 <vms14       > https://fms.komkon.org/fMSX/fMSX.html
2023-05-03 14:11:55 <unjust      > what about 6809?
2023-05-03 14:12:20 <vms14       > and I see https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/emulators/aliados/index.html but the offficial link seems to be dead
2023-05-03 14:12:25 <vms14       > it's a spanish guy
2023-05-03 14:12:26 <veltas      > vms14: You can start with Z80 if you want, and I'm assuming lots of people here and elsewhere can help with Z80 (I certainly can)
2023-05-03 14:12:30 <KipIngram   > 6809 is a groovy little processor.  It's a great early processor to focus on if you're interested in that retro stuff.
2023-05-03 14:12:34 <veltas      > But if you want a desktop forth just write a desktop forth
2023-05-03 14:13:12 <vms14       > well I always wanted to learn assembly, but it felt like I was loosing time and I should focus on stuff that gives me results
2023-05-03 14:13:14 <KipIngram   > Yeah - if you're really wanting to use this for "all of your programming" it seems like you'd want a Forth for your native processor.
2023-05-03 14:13:35 <KipIngram   > 6809 is certainly an easy assembly language to learn.
2023-05-03 14:13:35 <vms14       > the reason to make a real forth is mainly for "educative" purposes
2023-05-03 14:13:50 <vms14       > my goal is to make a real forth, and then see how much better is to my abomination
2023-05-03 14:14:03 <vms14       > and decide how much I will stick to a real forth after that
2023-05-03 14:14:11 <vms14       > it's mainly a research
2023-05-03 14:14:24 <vms14       > the x86 assembly does not seem the best option to start
2023-05-03 14:14:36 <KipIngram   > Hey, does anyone know where I'd start looking to investigate having my udev rules select this alternate driver of mine for my SSDs instead of the default native one?
2023-05-03 14:14:36 <vms14       > and there's plenty of emulators for several chips
2023-05-03 14:15:02 <unjust      > why not blacklist the native one altogether?
2023-05-03 14:15:11 <KipIngram   > I'd like for them to default to uio_pci_generic instead of nvme.
2023-05-03 14:15:33 <vms14       > for example the fmxs emulator is a computer and some sort of console
2023-05-03 14:15:42 <KipIngram   > I occasionally want to use it.  I can swtich back and forth between them easily - I'd just like to change the default but still have that switching ability.
2023-05-03 14:16:05 <vms14       > but I suspect the real reason is the game boy console xD
2023-05-03 14:16:17 <vms14       > it uses a modified z80 and most instructions are the same
2023-05-03 14:17:04 <vms14       > I had a little exposure to gb manuals and the gb is mainly a hardware api
2023-05-03 14:17:34 <vms14       > I don't think it matters too much with what I start anyways
2023-05-03 14:18:25 <vms14       > I suspect once you learn the basics of assembly and feel comfortable with it, it's not hard to learn other assembly languages
2023-05-03 14:19:27 <vms14       > so the goal is to find some cpu/platform that has assemblers on my machine, and also emulators, and is simple enough to get started without having to worry about stuff I shouldn't
2023-05-03 14:20:48 <vms14       > unjust why the 6809?
2023-05-03 14:20:58 <unjust      > vms14: 2 stack pointers
2023-05-03 14:21:39 <vms14       > :0
2023-05-03 14:22:23 <vms14       > unjust any book about you recommend?
2023-05-03 14:22:29 <veltas      > You know what else has two stack pointers? x86
2023-05-03 14:23:00 <unjust      > vms14: datasheets and application/technical reference manual for your processor of interest
2023-05-03 14:23:12 <vms14       > I have this https://www.6809.org.uk/asm6809/
2023-05-03 14:23:19 <vms14       > which is an assembler
2023-05-03 14:23:39 <KipIngram   > vms14: That's exactly right; the "concept" of assembly is sort of a universal thing.  When you "get it" it's not hard to familiarize yourself with a new one.
2023-05-03 14:23:39 <vms14       > and this https://www.6809.org.uk/xroar/
2023-05-03 14:23:45 <vms14       > being an emulator
2023-05-03 14:23:46 <unjust      > veltas: counting {,e,r}bp in there too?
2023-05-03 14:24:10 <veltas      > Well honestly any register can be used as a stack but rbp is designed for it
2023-05-03 14:24:20 <KipIngram   > Some processors have two stack pointers so that privileged code can have its own separate stack.
2023-05-03 14:24:33 <KipIngram   > Which one gets used depends on what security level the processor is at.
2023-05-03 14:24:42 <veltas      > Others work better because addressing from rbp requires an offset byte
2023-05-03 14:24:46 <KipIngram   > But that's not something you manipulate; it's just part of system security.
2023-05-03 14:25:05 <KipIngram   > It's not two stack pointers in the Forth sense.
2023-05-03 14:25:27 <KipIngram   > Although dave0 took interesting advantage of it with his "next = ret" design.
2023-05-03 14:25:58 <KipIngram   > He used the non-privileged stack pointer as his Forth instruction pointer, so ret would send him to his next direct threaded primitive.
2023-05-03 14:26:02 <vms14       > Dragon 32 "The Family Computer to fire your imagination"
2023-05-03 14:26:11 <KipIngram   > Meanwhile, os calls use the other, privileged, stack pointer.
2023-05-03 14:26:22 <KipIngram   > I thought that was clever as hell.
2023-05-03 14:27:05 <vms14       > https://colorcomputerarchive.com/repo/Documents/Books/6809%20Assembly%20Language%20Programming%20(Lance%20Leventhal).pdf
2023-05-03 14:28:28 <unjust      > "The 6809 CamelForth model holds top-of-stack in D, and uses the S stack pointer for the Parameter Stack. The U stack pointer is the Return Stack Pointer," -- https://www.bradrodriguez.com/papers/moving8.htm
2023-05-03 14:30:06 <KipIngram   > Interersting.  That's not quite what I was thinking of - I was thinking of later Intel processors with the four privilege rings.
2023-05-03 14:30:31 <KipIngram   > My 6809 exposure it... nearly 40 years ago.
2023-05-03 14:31:37 <vms14       > KipIngram: haha you're getting old :D
2023-05-03 14:32:02 <KipIngram   > Yep - it gets us all in the end.
2023-05-03 14:32:35 <unjust      > anyone encountered any implementations of something forth-like that is transpiled into other languages, rather than being implemented as an interpreter for a virtual forth machine in the usual sense?
2023-05-03 14:32:38 <vms14       > I have some interest in forth metacompilers
2023-05-03 14:32:39 <KipIngram   > I'm  pretty happy with how I'm doing, though - people still typically gues about ten years to low when they guess my age.  It's been like that for decades.
2023-05-03 14:33:11 <vms14       > KipIngram: with me people tended to guess ten years more
2023-05-03 14:33:13 <KipIngram   > And I don't weigh 225-230 like I did at one point in time.
2023-05-03 14:33:31 <KipIngram   > How old are you?
2023-05-03 14:33:45 <KipIngram   > I turned 60 in January.
2023-05-03 14:35:49 <vms14       > 29
2023-05-03 14:35:57 <vms14       > going to 30 on july
2023-05-03 14:36:23 <vms14       > https://www.bradrodriguez.com/papers/6809cpu.htm  the guy made a computer with that chip, it seems
2023-05-03 14:37:00 <vms14       > says he was tempted to choose a z80, but the 6809 was 1 dollar more, and is better
2023-05-03 14:37:34 <KipIngram   > Well, that's a time in life when looking somewhat older might actually work to your advantage.
2023-05-03 14:37:46 <KipIngram   > 40-ish guys typically appeal to women quite a lot.
2023-05-03 14:37:48 <thrig       > Robocop - I'd Buy That For a Dollar
2023-05-03 14:38:51 <vms14       > https://www.bradrodriguez.com/papers/ms/pat4th-e.html a pattern match forth?
2023-05-03 14:38:53 <vms14       > :0
2023-05-03 14:40:41 <unjust      > i wrote something sort of like a forth in shell script once, and realized it was horribly slow in comparison to implementing the same logic in shell script itself. i never had the time/desire to redo it, but i often wonder about writing a 'parasitic forth' that would compile its words as functions in a target high level language
2023-05-03 14:42:20 <thrig       > shell scripts ain't where you look for speed
2023-05-03 14:42:23 <vms14       > unjust: you mean some sort of transpiler?
2023-05-03 14:42:33 <unjust      > vms14: yes
2023-05-03 14:42:38 <unjust      > thrig: you can imagine how slow it was then
2023-05-03 14:43:02 <vms14       > an easy way to make a forth transpiler is to also put the stack on the target language
2023-05-03 14:43:16 <vms14       > but it can be avoided anyways
2023-05-03 14:44:00 <vms14       > i've played with it a bit, I had some basic stuff working, but is a bit trickier than just an interpreter
2023-05-03 14:44:11 <vms14       > also depends on the target language
2023-05-03 14:44:31 <vms14       > unjust: I'd say to not worry about performance
2023-05-03 14:44:40 <vms14       > I wonder when you will really need it
2023-05-03 14:45:05 <unjust      > i've learnt that terrible performance is usually an indication that i've taken the wrong turn somewhere
2023-05-03 14:45:11 <vms14       > I have concat lang on perl and also in js, the js version has "decent" performance
2023-05-03 14:45:19 <vms14       > obviously it can't compete with assembly
2023-05-03 14:45:44 <vms14       > unjust: with shell scripting is not like you can get any performance
2023-05-03 14:46:07 <vms14       > anyways for research purposes is good
2023-05-03 14:46:14 <unjust      > if you stick to shell-builtins and spawn no other processes, it's not bad
2023-05-03 14:46:23 <vms14       > and making your toy lang is super fun
2023-05-03 14:46:27 <vms14       > specially when using it
2023-05-03 14:46:29 <unjust      > this does severely limit your ability to parse non-textual data though
2023-05-03 14:46:59 <thrig       > perl while(readline) is 1000% faster than a sh while IFS= read -r line || [ -n "$line" ];
2023-05-03 14:47:02 <vms14       > I always hated sh/bash I'm lucky I learned perl
2023-05-03 14:47:21 <unjust      > and if you stick to a posix dialect, your scripts will run on almost any unix, even old ones like xenix
2023-05-03 14:47:29 <vms14       > it turns that reading the source code is the least of your problems when you want performance
2023-05-03 14:47:44 <vms14       > it's execution what matters, reading is done only once
2023-05-03 14:51:31 <unjust      > it's good to have readible source code for your own sanity, especially when the inevitable time to debug comes along
2023-05-03 14:52:05 <vms14       > brb
2023-05-03 16:38:04 <jgaz        > unjust Power C was a 6502 C compiler that implemented a partial Forth machine under the hood to help work around the 6502's limitations. Is that in your wheelhouse?
2023-05-03 16:45:08 <jgaz        > At least, I think it was Power C... but now I can't seem to find an article on it.
2023-05-03 16:48:39 <unjust      > jgaz: sounds cool, i'm always interested in learning about unorthodox solutions to problems
2023-05-03 16:49:10 <jgaz        > you and me both. :)
2023-05-03 16:50:40 <jgaz        > unjust if I find the article I'll post it here.
2023-05-03 16:52:17 <veltas      > KipIngram: Wait how did that next=ret thing work again?
2023-05-03 16:52:27 <veltas      > I remember seeing this but can't figure it out in my head
2023-05-03 16:53:17 <veltas      > Oh rsp would be the instruction pointer right, funny how asking questions you answer them
2023-05-03 16:53:40 <veltas      > The problem with that is it might be really slow, I think that would confuse the return branch prediction
2023-05-03 16:54:35 <veltas      > Because return branch prediction is based on a stack of up to the last N CALL's if I remember rightly
2023-05-03 16:57:28 <unjust      > jgaz: i found https://github.com/pzembrod/cc64 while trying to find an article that fits that description, it's a C compiler written in forth that targets the 6502
2023-05-03 16:59:20 <jgaz        > unjust that might be it... I could just be misremembering. This looks interesting.
2023-05-03 17:05:30 <unjust      > was it a proper compiler? or a C interpreter?
2023-05-03 17:08:24 <unjust      > this looks pretty close to what you described: https://mdfs.net/System/C/BBC/Small-C/v073/docs/Read.me
2023-05-03 17:12:07 <unjust      > "Small-C is a subset of the C programming language"  ...  "I quickly realised that the virtues of using a threaded-code interpreted language (TIL) could be exploited just as easily by generating code for an interpreter conventionally, instead of using Forth itself to generate a 'target' vocabulary."
2023-05-03 17:27:48 <thrig       > shouldn't it be written Small-c
2023-05-03 17:31:12 <veltas      > :)
2023-05-03 17:38:08 <KipIngram   > veltas: So, the stack pointer is pointing at the next direct-threaded xt, so it's pointing right at code.
2023-05-03 17:38:20 <veltas      > Yeah I clocked that eventually lol
2023-05-03 17:38:29 <KipIngram   > When you execute "ret," it "pops" that xt and jumps to it, moving sp to the next one.
2023-05-03 17:38:39 <KipIngram   > That's it - it does exactly what you want next to do.
2023-05-03 17:39:01 <KipIngram   > And since the OS uses a different stack, your code doesn't get written all over when you make an OS call.
2023-05-03 17:39:04 <veltas      > Yeah I've seen that before, that's how mark4's forth works
2023-05-03 17:39:09 <KipIngram   > Now, it means you can't "call" anything.
2023-05-03 17:39:42 <veltas      > Well his 64-bit one anyway
2023-05-03 17:39:52 <KipIngram   > But my  Forth doesn't do any calls.
2023-05-03 17:40:12 <KipIngram   > I thought it was quite slick, and almost certainly the fasted method for direct threading you can do on most processors.
2023-05-03 17:40:30 <veltas      > As I said, I would guess it's slow on modern processors
2023-05-03 17:40:41 <veltas      > Because it screws with return branch prediction
2023-05-03 17:41:14 <KipIngram   > Well, that may be true.  See, there I go applying "1990's think."
2023-05-03 17:41:32 <veltas      > Honestly I think processors in the 90's would have had this problem too :P
2023-05-03 17:41:36 <KipIngram   > Back in the good old days when you could just look up cycle counts in a book.
2023-05-03 17:41:41 <veltas      > True that
2023-05-03 17:41:46 <KipIngram   > Ok, I don't know the history that well.
2023-05-03 17:41:57 <KipIngram   > I was busy working on railguns during that period.
2023-05-03 17:42:39 <KipIngram   > I worked for National Instruments in 1986/87, and then went to graduate school in the electromagnetics stuff, and worked for the lab I did my research with until 1996.
2023-05-03 17:42:54 <KipIngram   > So everything from 87 to 96 kind of blew by me.
2023-05-03 17:43:04 <KipIngram   > And that was a hell of a lot of stuff.
2023-05-03 17:46:09 <veltas      > I was born in '93, I just find certain bits of computing history interesting
2023-05-03 17:53:23 <KipIngram   > Oh, it's a fascinating history for sure.  I really enjoy the "early stories."  Have you ever read "Soul of a New Machine" by Tracey Kidder?
2023-05-03 17:53:55 <KipIngram   > It's an "up close" documentary, with lots of personality stuff, around the Data General "Eagle" project.
2023-05-03 17:54:15 <KipIngram   > Kind of an inside look at how the design team did their work, got along with one another, and so on.
2023-05-03 17:54:30 <KipIngram   > That was the Data General response to the DEC VAX.
2023-05-03 17:54:58 <vms14       > https://www.bradrodriguez.com/papers/tcjassem.txt this is interesting
2023-05-03 17:55:03 <veltas      > Actually it's not even that I find the history particularly interesting, it's more that I've found it's often easier to learn about computers incrementally
2023-05-03 17:55:13 <KipIngram   > Yeah.
2023-05-03 17:55:20 <vms14       > he uses the dictionary as output file
2023-05-03 17:55:25 <veltas      > And it's easier for me to understand CPU's looking at how they've improved over time
2023-05-03 17:55:44 <KipIngram   > Damn it - for some reason my text cuts from console aren't working.
2023-05-03 17:56:05 <vms14       > HEX  : NOP,   12 C, ;
2023-05-03 17:56:55 <KipIngram   > Oh, it looks like somehow copy got changed to shift-ctrl-C instead of just ctrl-C.
2023-05-03 17:56:59 <KipIngram   > I didn't do that on purpose.
2023-05-03 17:57:16 <KipIngram   > That does look like fun to browse through.
2023-05-03 17:57:21 <vms14       > (This comma is a Forth convention, indicating that something is appended to the dictionary.)
2023-05-03 17:57:27 <vms14       > did not know that :0
2023-05-03 17:57:36 <KipIngram   > :-)
2023-05-03 17:57:39 <veltas      > Yeah like , and C,
2023-05-03 17:57:40 <KipIngram   > Yeah, that's a standard one.
2023-05-03 17:57:46 <KipIngram   > C, appends one byte.
2023-05-03 17:57:55 <KipIngram   > , appends a cell, whatever size it is.
2023-05-03 17:58:16 <veltas      > I often have STR, or similar to append a string to dictioary
2023-05-03 17:58:22 <vms14       > I always thought forth could be a nice preprocessor
2023-05-03 17:58:37 <veltas      > Yeah that and other things lol
2023-05-03 17:58:38 <vms14       > also an assembller, this guy shows even more than what I imagined
2023-05-03 17:58:59 <KipIngram   > Yeah, I used to chat with a guy who accused  Forth of being a "glorified macro assembler."
2023-05-03 17:59:02 <vms14       > as forth can have the machine code directly
2023-05-03 17:59:05 <veltas      > It's quite standard for 'real forths' to have assemblers provided with them
2023-05-03 17:59:10 <KipIngram   > That's not a correct assessment, but I do see what he was talking about.
2023-05-03 17:59:28 <veltas      > Honestly a glorified macro assembler sounds like fun to me
2023-05-03 17:59:29 <KipIngram   > It can do most anything an assembler can do.  But it can do a whole lot more, and his words didn't convey that.
2023-05-03 17:59:40 <veltas      > You should see what people do with masm and derivatives
2023-05-03 17:59:58 <KipIngram   > I can imagine.  And nasm has a great macro facility.
2023-05-03 18:00:03 <veltas      > Certainly a macro assembler these days isn't interactive
2023-05-03 18:00:18 <KipIngram   > Yes, there's that, for sure.
2023-05-03 18:00:34 <KipIngram   > BTW, my oldest daughter was born in 1993.
2023-05-03 18:00:39 <veltas      > nasm is very basic compared to that, which is fine, it's minimalistic
2023-05-03 18:00:58 <veltas      > You are similar age to my dad, a little older
2023-05-03 18:01:11 <veltas      > I'm the eldest child in my family
2023-05-03 18:01:21 <KipIngram   > Me too.
2023-05-03 18:01:30 <KipIngram   > I just have one sister, five and a half years younger.
2023-05-03 18:02:06 <vms14       > I was going to use my abomination to generate assembly anyways
2023-05-03 18:02:15 <KipIngram   > Once when I was in high school, or maybe I was off to college by this time, our high school principal passed her in the all and said "Hi, Little Ingram."
2023-05-03 18:02:27 <KipIngram   > She HATED IT - she got in a real twist over it.  :-)
2023-05-03 18:02:31 <vms14       > just need to make a package and start defining instructions
2023-05-03 18:03:24 <KipIngram   > "in the *h*all"
2023-05-03 18:03:30 <vms14       > I was also born in 93
2023-05-03 18:03:37 <vms14       > 14/7/93
2023-05-03 18:03:40 <KipIngram   > Wow - popular year.
2023-05-03 18:03:49 <KipIngram   > Oh my gosh, my daughter's birthday is the next day, the 15th.
2023-05-03 18:03:50 <vms14       > yeah, netbsd was also born that time
2023-05-03 18:04:30 <vms14       > KipIngram: of july too?
2023-05-03 18:04:36 <KipIngram   > Yeah.
2023-05-03 18:04:39 <vms14       > that would be too much coincidence
2023-05-03 18:04:42 <vms14       > lol
2023-05-03 18:05:05 <vms14       > well you will remember my birthday then
2023-05-03 18:05:34 <unjust      > +1 for glorified macro assemblers
2023-05-03 18:07:45 <vms14       > btw I guess I'll go for the z80
2023-05-03 18:08:04 <vms14       > I've already seen some stuff and it makes no sense to loose more time deciding anyways
2023-05-03 18:09:22 <vms14       > I'm reading this paper of the guy making a cross assembler
2023-05-03 18:09:44 <vms14       > I think a script could look a datasheet and automatically create the assembler
2023-05-03 18:13:13 <vms14       > the jupiter ace must be fun
2023-05-03 18:13:21 <vms14       > http://www.jupiter-ace.co.uk/listing_pcworld8308_232.html
2023-05-03 18:16:09 <vms14       > https://github.com/petrihakkinen/ace-forth
2023-05-03 18:16:14 <vms14       > it's written in lua :0
2023-05-03 18:16:58 <veltas      > We're getting into birthday paradox now lol
2023-05-03 18:17:12 <veltas      > The birthday paradox: Everyone's birthday is the same day
2023-05-03 18:17:20 <veltas      > Strange but true
2023-05-03 18:17:45 <unjust      > if your point of view is that everyday is today, then that's true
2023-05-03 18:19:32 <vms14       > now I realize I don't need to make a forth, just to use one
2023-05-03 18:19:33 <vms14       > xD
2023-05-03 18:19:46 <veltas      > Start with using one
2023-05-03 18:20:04 <veltas      > Do some advent of code with it, or dpt roll
2023-05-03 18:20:06 <vms14       > but looking at all forth implementations, it's likely I can find some forth implementation I can get fun with
2023-05-03 18:20:21 <vms14       > for example using some emulator and X forth for that platform
2023-05-03 18:20:31 <vms14       > it's likely that I can put stuff on video memory or alike
2023-05-03 18:20:42 <veltas      > https://dpt-roll.github.io/
2023-05-03 18:21:27 <vms14       > it's cool
2023-05-03 18:21:44 <vms14       > I don't tend to do exercises, more than simple tests I make
2023-05-03 18:21:57 <vms14       > I usually learn by reading books and looking on internet
2023-05-03 18:22:05 <vms14       > then I practice myself doing tests
2023-05-03 18:22:06 <MrMobius    > if you don't have real hardware, emulator quality might be a deciding factor
2023-05-03 18:22:31 <vms14       > well what really worries me is the fact that: "If you have seen a forth, you've seen a forth"
2023-05-03 18:22:53 <veltas      > Don't underestimate social power in learning, share some stuff and let people give you advice
2023-05-03 18:22:58 <vms14       > specially in some devices/platforms they're likely to differ
2023-05-03 18:23:26 <vms14       > ah, when I'm stuck I usually come to IRC
2023-05-03 18:23:35 <MrMobius    > np. you can work on a forth thing for one platform then take what you learn and decide if you want to switch platforms
2023-05-03 18:23:49 <veltas      > Because despite all these books aimed at 'programmer #23242', there is a bunch of people in here who can crowdsource good answers and tips
2023-05-03 18:23:53 <vms14       > I need to learn forth properly
2023-05-03 18:24:07 <vms14       > my goal is to have a forth implementation that can do whatever I want to do
2023-05-03 18:24:19 <vms14       > which mainly means some kind of ffi to C
2023-05-03 18:24:31 <veltas      > Well if you use a standard forth then you can start writing most of that 'anything' code already
2023-05-03 18:24:34 <veltas      > Without your own forth
2023-05-03 18:24:38 <veltas      > And then fill that bit in later
2023-05-03 18:24:40 <vms14       > yeah
2023-05-03 18:24:52 <vms14       > and there's a lot I can do by just printing to stdout
2023-05-03 18:25:22 <vms14       > still assembly is a thing I'll always have in my todo list
2023-05-03 18:26:27 <vms14       > http://www.jupiter-ace.co.uk/whatisforth.html
2023-05-03 18:27:38 <vms14       > The great secret to implementing Forth is natively compiling it, so that it compiles itself.
2023-05-03 18:27:41 <vms14       > :0
2023-05-03 18:29:33 <vms14       > the jupiter ace guys really liked forth
2023-05-03 18:30:26 <KipIngram   > Yeah, that's my big goal that I've inched closer to each time.
2023-05-03 18:30:36 <KipIngram   > Self rebuild capability.
2023-05-03 18:30:47 <KipIngram   > Once I have that I can un-tether from nasm.
2023-05-03 18:30:47 <vms14       > http://www.jupiter-ace.co.uk/index_forth_books.html
2023-05-03 18:40:48 <veltas      > crc: Is it konilo or komilo?
2023-05-03 18:41:09 <veltas      > Because your logo looks like it says komilo, but the text seems to say konilo
2023-05-03 18:44:47 <vms14       > https://i.imgur.com/ScZKvq4.png  this is why I love my wm
2023-05-03 18:45:06 <vms14       > the pdf becomes the background
2023-05-03 18:45:16 <vms14       > same with youtube videos or whatever
2023-05-03 18:46:02 <gordonjcp   > vms14: why do you need to involve C at all?
2023-05-03 18:46:33 <vms14       > to use stuff like sockets, sql, Xlib, etc
2023-05-03 18:46:34 <gordonjcp   > vms14: the Jupiter Ace was an excellent machine, except the vacuum-formed plastic case crumbled
2023-05-03 18:47:01 <vms14       > gordonjcp: I imagine it must be fun to have a forth integrated with the system
2023-05-03 18:47:09 <vms14       > being it the interface to the system itself
2023-05-03 18:47:18 <gordonjcp   > that's generally how Forth is supposed to work
2023-05-03 18:47:36 <vms14       > usually forth is the whole system
2023-05-03 18:47:53 <gordonjcp   > there were a lot of interesting design decisions made there, because the Z80 is maybe not ideal for implementing Forth
2023-05-03 18:47:58 <gordonjcp   > well
2023-05-03 18:48:01 <gordonjcp   > not as good as a 6809
2023-05-03 18:48:06 <gordonjcp   > arguably a lot better than a 6502
2023-05-03 18:48:07 <vms14       > why the z80 is not ideal?
2023-05-03 18:48:21 <vms14       > and why they ended choosing it
2023-05-03 18:48:22 <gordonjcp   > vms14: you have to do a lot of index register fuckery to implement two stacks
2023-05-03 18:48:32 <gordonjcp   > in a 6809 you have two hardware stacks already
2023-05-03 18:49:24 <vms14       > so it was because it was cheaper?
2023-05-03 18:49:28 <gordonjcp   > vms14: I've always assumed it was was because they'd both used it extensively in the ZX80, ZX81 and ZX Spectrum
2023-05-03 18:49:39 <gordonjcp   > well the 6809 was always an expensive part
2023-05-03 18:50:40 <vms14       > gordonjcp: did you make something cool with your ace?
2023-05-03 18:50:49 <crc         > veltas: konilo
2023-05-03 18:50:54 <gordonjcp   > it was a pretty bizarre design for the era though, with pairs of 4 bit 1k RAM chips
2023-05-03 18:51:06 <veltas      > Is it just the handwriting or something?
2023-05-03 18:51:09 <gordonjcp   > vms14: a few things. I still have the PCB and keyboard mat
2023-05-03 18:51:18 <crc         > I'm going to have arland update the image to make this clearer
2023-05-03 18:51:30 <crc         > but that probably won't happen until the weekend
2023-05-03 18:51:33 <unjust      > vms14: i think these might help you on your forth quest ... https://tinytapeout.com/siliwiz/ https://app.siliwiz.com/
2023-05-03 18:51:47 <KipIngram   > vms14: The 6809 just had a really nice instruction set.  For the most part you could do "all tihngs with all registers."  I want to think it wasn't 100% that way, but it was a long way there.
2023-05-03 18:51:57 <crc         > veltas: yes, was based on handwriting
2023-05-03 18:52:00 <gordonjcp   > vms14: given that Richard had already designed the Spectrum using 16kbit dynamic RAMs I'm surprised it wasn't what they used with the Ace
2023-05-03 18:52:00 <thrig       > I hear forth quests are open to interpert
2023-05-03 18:52:01 <KipIngram   > It was just a friendly instruction set to learn, withtout a lot of "odd quirks."
2023-05-03 18:52:26 <unjust      > thrig: text based adventures none the less
2023-05-03 18:52:38 <gordonjcp   > vms14: I guess they'd have had to do all sorts of fun bus arbitration, and that would have basically meant using a ULA, which would have meant it was essentially a ZX Spectrum
2023-05-03 18:53:12 <gordonjcp   > KipIngram: compare with the NEC 78C11 which I'm currently doing battle with, which appears to have had its instruction set generated by throwing dice
2023-05-03 18:53:21 <KipIngram   > Ugh.
2023-05-03 18:53:40 <gordonjcp   > bloody japanese synthesizers
2023-05-03 18:55:44 <vms14       > Design and order your own chip with TinyTapeout
2023-05-03 18:55:47 <thrig       > maybe they used I Ching
2023-05-03 18:55:55 <vms14       > it's cool, but I'm not going to design any chip xD
2023-05-03 18:56:28 <unjust      > why not recreate one of these https://vfxforth.com/flag/jfar/vol2/no1/article1.pdf ?
2023-05-03 18:56:33 <vms14       > I always wanted to steal stuff from broken electric devices and make something with them btw
2023-05-03 18:56:47 <vms14       > but I have 0 knowledge of electronics/hardware
2023-05-03 18:57:14 <vms14       > I have to learn assembly first, I always wanted to cross the line between software/hardware
2023-05-03 18:57:24 <vms14       > I'm sticking to the software for now
2023-05-03 18:57:47 <gordonjcp   > vms14: have you read Jonesforth yet?
2023-05-03 18:57:51 <unjust      > you can do both
2023-05-03 18:57:57 <thrig       > broken devices could be used for music generation
2023-05-03 18:58:07 <vms14       > gordonjcp: I think is the first implementation I saw
2023-05-03 18:58:21 <vms14       > it's remarkably popular
2023-05-03 18:58:31 <vms14       > https://github.com/nornagon/jonesforth/blob/master/jonesforth.S
2023-05-03 18:58:58 <vms14       > can't run it as I'm not on linux, but I could end translating it
2023-05-03 18:59:26 <unjust      > doesn't netbsd still have linux binary emulation?
2023-05-03 18:59:41 <vms14       > right, never tried it
2023-05-03 18:59:53 <veltas      > crc: I hadn't even noticed until now
2023-05-03 19:00:28 <vms14       > https://www.netbsd.org/docs/guide/en/chap-linux.html
2023-05-03 19:00:40 <vms14       > supposedly I just need to install some compat libraries
2023-05-03 19:01:09 <thrig       > Shirley netbsd can run a linux under qemu?
2023-05-03 19:01:41 <veltas      > crc: I might recommend looking at the emphasised lines and connection points of roundhand https://design.tutsplus.com/articles/mastering-calligraphy-how-to-write-in-roundhand-script--vector-25652
2023-05-03 19:01:52 <veltas      > But everyone's got their favourite handwriting standards I'm sure lol
2023-05-03 19:02:16 <veltas      > You show me your font face, I'll show you my standardised handwriting
2023-05-03 19:04:20 <vms14       > xterm*faceName:courier
2023-05-03 19:06:43 <thrig       > -xos4-terminus-bold-r-normal--28-280-72-72-c-140-iso10646-1
2023-05-03 19:09:32 <vms14       > oh, I liked terminus
2023-05-03 19:10:12 <thrig       > it fits pretty well on this wacky-sized monitor, for the usual four xterms
2023-05-03 19:10:35 <vms14       > I used fira code also, but meh
2023-05-03 19:10:41 <vms14       > no ligatures on the terminal
2023-05-03 19:12:56 <veltas      > I like Courier Prime for UPPERCASE LANGUAGES and Deja Vu Sans Mono for other languages like C
2023-05-03 19:13:06 <veltas      > I find serifs help with lots of capital letters
2023-05-03 19:13:46 <veltas      > And on high DPI monitors unfortunately I usually need to adjust weight of Deja Vu, or use something else
2023-05-03 19:14:05 <veltas      > I tend to have Courier Prime in bold
2023-05-03 19:14:38 <vms14       > I'm not much into ricing the system, I work mostly with defaults
2023-05-03 19:14:57 <veltas      > Deja Vu was the default everywhere for a long time
2023-05-03 19:14:58 <thrig       > oh yeah high dpi leaves a lot of fonts too thin
2023-05-03 19:15:00 <vms14       > I had some time looking at the fonts that come with the system, courier was fine
2023-05-03 19:15:40 <vms14       > I have very few settings
2023-05-03 19:15:49 <vms14       > https://termbin.com/hcdmr this is my .Xdefaults
2023-05-03 19:16:10 <vms14       > https://termbin.com/m64c my emacs.el
2023-05-03 19:16:45 <vms14       > https://termbin.com/ifww my .cwmrc
2023-05-03 19:16:46 <vms14       > xD
2023-05-03 19:17:10 <veltas      > My .bashrc ends with  alias ed='rlwrap ed'
2023-05-03 19:17:26 <vms14       > and a xorg.conf for rotating the screen
2023-05-03 19:17:36 <vms14       > oh, I use my abomination as a shell
2023-05-03 19:17:47 <veltas      > I love readline
2023-05-03 19:17:54 <vms14       > https://termbin.com/3fx0 this is the init file
2023-05-03 19:18:02 <vms14       > it just sets some words as commands
2023-05-03 19:18:19 <veltas      > alias gforth='gforth -e "-status warnings off"'
2023-05-03 19:19:19 <vms14       > works fine as a shell
2023-05-03 19:19:53 <vms14       > but for some reason rlwrap has a bug this time
2023-05-03 19:20:07 <vms14       > if I have a prompt it prints it twice
2023-05-03 19:20:28 <vms14       > it did not happen the last time I installed rlwrap
2023-05-03 19:20:43 <vms14       > and the same code used on linux with rlwrap does not have that bug
2023-05-03 19:22:19 <vms14       > I think I'm going to try to make a forth in perl
2023-05-03 19:22:33 <vms14       > faking memory allocation by just having an array
2023-05-03 19:22:46 <vms14       > and implementing the return stack, and the dictionary as arrays too
2023-05-03 19:29:41 <vms14       > https://github.com/howerj/libforth
2023-05-03 19:49:23 <vms14       > what happens in forth if I set base to 11?
2023-05-03 19:50:04 <vms14       > chuck says to implement NUMBER you have to multiply the numbers by BASE
2023-05-03 19:50:19 <vms14       > and hex is like a special case
2023-05-03 19:50:27 <vms14       > which is when base is 16
2023-05-03 19:50:57 <vms14       > but I suspect from 11 upwards the other base are ignored? or what
2023-05-03 19:53:25 <vms14       > pforth seems to ignore them
2023-05-03 19:53:31 <crc         > it'll depend on the forth. I've done implementations that supported bases 1-256, and others that only support a single base.
2023-05-03 19:53:45 <vms14       > crc how do you implement those bases?
2023-05-03 19:53:57 <vms14       > if hex is [0-9a-f]
2023-05-03 19:54:02 <vms14       > you keep using letters?
2023-05-03 19:54:10 <unjust      > yes
2023-05-03 19:54:31 <unjust      > things get weird beyond base 36
2023-05-03 19:56:59 <crc         >  yes, I had the entire base + extended ascii character set on my machine used for that
2023-05-03 19:57:25 <crc         > ans says base can be 2 through 36 (6.1.0750)
2023-05-03 19:58:21 <vms14       > hmm
2023-05-03 19:58:52 <vms14       > I think with base [2,8,10,16] is more than enough
2023-05-03 19:59:17 <vms14       > why would you use any other kind of base
2023-05-03 20:00:14 <thrig       > 7 sees use
2023-05-03 20:01:48 <vms14       > I think base is the first thing I'll differ with forth
2023-05-03 20:02:04 <thrig       > it can be something of a footgun
2023-05-03 20:02:04 <vms14       > I don't see a reason to implement it
2023-05-03 20:02:21 <vms14       > just need a way to have octal hex binary and decimals
2023-05-03 20:02:21 <crc         > 60 for some historical stuff
2023-05-03 20:02:43 <thrig       > more common is to accept #foo or 0xfoo for hex
2023-05-03 20:02:45 <unjust      > base 36 probably gives you the most compact representation possible with only printable ascii characters (with sequential ordinal values)
2023-05-03 20:02:52 <vms14       > 0x will be for hex
2023-05-03 20:02:57 <vms14       > I always had this way
2023-05-03 20:03:12 <vms14       > /^0x[-f0-9]+/i
2023-05-03 20:03:25 <vms14       > I never had oct numbers as I never use them
2023-05-03 20:03:36 <thrig       > [[:xdigit:]]
2023-05-03 20:03:38 <vms14       > only hex and decimal
2023-05-03 20:03:41 <vms14       > not even binary
2023-05-03 20:04:04 <vms14       > lol
2023-05-03 20:04:14 <unjust      > some systems won't acknowledge character escape values if they aren't in octal
2023-05-03 20:04:30 <crc         > 40 was used on some old DEC systems
2023-05-03 20:04:35 <vms14       > I only see octal in permission modes
2023-05-03 20:07:42 <thrig       > serial supports 5? or 6? bits to 9 bits
2023-05-03 20:08:00 <thrig       > CS5 five bits!
2023-05-03 20:09:18 <vms14       > KipIngram: to implement your temp words, isn't it enough with just a marker + forget?
2023-05-03 20:11:38 <vms14       > if I try to implement forth in perl I'll end discarding a lot of stuff
2023-05-03 20:12:05 <vms14       > every time I think to implement X I question myself why, if I already have that
2023-05-03 20:13:08 <vms14       > but I like the fact compile time can be changed at any time and words can put stuff on the word is currently being defined
2023-05-03 20:13:56 <vms14       > also create/does
2023-05-03 20:33:21 <crc         > 
ACTION decides to spend a couple of minutes writing a `does` for konilo

2023-05-03 20:34:16 <vms14       > crc what is konilo?
2023-05-03 20:34:20 <vms14       > your new vm?
2023-05-03 20:34:29 <crc         > konilo is the forth for my new vm
2023-05-03 20:35:03 <vms14       > how do you make fib and fact on your lang?
2023-05-03 20:35:26 <vms14       > https://termbin.com/1oxv
2023-05-03 20:35:36 <vms14       > I have fib and fact there
2023-05-03 20:35:41 <vms14       > fib is super slow
2023-05-03 20:36:26 <vms14       > 24 fib => 46368   took: 9.15 real
2023-05-03 20:36:28 <vms14       > xD
2023-05-03 20:37:39 <vms14       > i wonder what the js version will take
2023-05-03 20:42:23 <vms14       > 0.55 real
2023-05-03 20:42:28 <vms14       > lol
2023-05-03 20:42:57 <thrig       > javascript is pretty fast
2023-05-03 20:43:17 <thrig       > must be Jevon's Paradox for how Electrons get so slow
2023-05-03 20:44:04 <vms14       > yeah, it has much better performance than what I've expected
2023-05-03 20:44:25 <vms14       > it always destroys the perl implementation xD
2023-05-03 20:44:50 <vms14       > and it even gives me much less trouble
2023-05-03 20:47:12 <crc         > vms14: forth.works/temp/fib-fact.txt
2023-05-03 20:48:56 <vms14       > i assume choose is if else
2023-05-03 20:49:07 <vms14       > I didn't know you also used lists for them
2023-05-03 20:49:17 <vms14       > I expected it to be like forth
2023-05-03 20:49:22 <crc         > 0.51s for #24 fib (using the c vm on my openbsd box)
2023-05-03 20:49:26 <vms14       > I suppose you have both forms
2023-05-03 20:50:08 <vms14       > wow
2023-05-03 20:50:22 <crc         > no, all my control and loop structures take pointers to functions
2023-05-03 20:50:37 <vms14       > it's amazing to see how my js implementation takes 0.55 while your c implementation takes 0.51
2023-05-03 20:51:16 <vms14       > the dictionary is a js object, so searching should be faster
2023-05-03 20:51:27 <vms14       > but it has packages and environments
2023-05-03 20:51:51 <vms14       > js is just surprisingly fast
2023-05-03 20:51:57 <vms14       > althought it's node
2023-05-03 20:53:06 <vms14       > crc so that list is a normal list, or it does create a function?
2023-05-03 20:54:10 <vms14       > if KipIngram makes the factorial it's likely to take 0.0x
2023-05-03 20:54:42 <crc         > vms14: that includes startup time and evaluating the block. This requires running 86,859,072 instructions. Not loading the standard startup stuff saves 0.11s and drops the total instructions to 63,783,300.
2023-05-03 20:54:44 <vms14       > the sum of the first 1000000 numbers took like nanoseconds for him
2023-05-03 20:55:28 <vms14       > yeah, mine also includes startup time, but it's not much and it's a new version so it's missing a lot of stuff
2023-05-03 20:55:46 <crc         > my vm designs aren't particularly fast. If I had a bigger instruction set, I could save some time on this
2023-05-03 20:56:03 <vms14       > I'm not reading init files or alike this time
2023-05-03 20:56:31 <vms14       > but it's fine to know I'll have acceptable performance in js
2023-05-03 20:56:51 <vms14       > so I don't have to worry about my lang being slow, not able to do X things
2023-05-03 20:57:11 <vms14       > still I need to add a way to compile
2023-05-03 20:57:22 <vms14       > it does not compile anything
2023-05-03 20:57:50 <vms14       > and it's  not cause I want performance, but about packages and their scope, it makes weird stuff
2023-05-03 20:58:07 <crc         > if I don't load it from the blocks it's a little faster 0.33s
2023-05-03 20:58:12 <vms14       > compiling solves that, and also provides tco in node
2023-05-03 20:58:34 <vms14       > crc you can always cheat and make fact be a builtin
2023-05-03 20:58:35 <vms14       > :D
2023-05-03 20:58:43 <vms14       > fib*
2023-05-03 20:58:47 <crc         > no.
2023-05-03 21:02:03 <crc         > I'd use a non-recursive model if I actually needed these for anything serious
2023-05-03 21:03:40 <vms14       > I don't think fib and fact have too many use cases
2023-05-03 21:03:59 <vms14       > mainly they're to show recursion
2023-05-03 21:04:08 <vms14       > fib was the first time I saw recursion on SICP
2023-05-03 21:04:20 <vms14       > I was like: "hey, where the numbers are going?"
2023-05-03 21:05:29 <thrig       > fib pairs well with memoization
2023-05-03 21:06:33 <vms14       > yeah, but mainly for demonstration purposes
2023-05-03 21:11:50 <vms14       > still the conclusion is I have to get rid of perl
2023-05-03 21:12:12 <vms14       > which means use node for the desktop version or choose another lang
2023-05-03 21:12:49 <vms14       > but every time I compare the perl version with the js version, perl gets destroyed
2023-05-03 21:13:47 <vms14       > crc do you have a java version?
2023-05-03 21:13:49 <crc         > here's my `does`: http://forth.works/temp/37.txt
2023-05-03 21:14:07 <vms14       > I don't see java on your list
2023-05-03 21:14:13 <crc         > vms14: I have a kotlin version which runs on the jvm
2023-05-03 21:14:30 <crc         > I've not done a java implementation yet
2023-05-03 21:14:34 <vms14       > oh
2023-05-03 21:14:43 <vms14       > are you going to put it on android?
2023-05-03 21:15:05 <vms14       > I know you did, but not "natively" I guess
2023-05-03 21:15:18 <vms14       > like it was with termux or whatever
2023-05-03 21:16:28 <vms14       > crc what does curry?
2023-05-03 21:16:37 <crc         > I'd like to, but I don't want to deal with Android Studio
2023-05-03 21:16:43 <vms14       > it returns a closure?
2023-05-03 21:17:26 <vms14       > I've put s7 scheme on android with android studio using their native C
2023-05-03 21:17:39 <crc         > curry (vp-q) Create a new quote pushing the value, then calling p
2023-05-03 21:17:40 <vms14       > it was cool, but the binding wasn't nice, as it's trough jni
2023-05-03 21:18:24 <vms14       > I was going to use the java reflection api, so I only needed to bind the reflection methods, but got bored
2023-05-03 21:20:13 <vms14       > you can put your c vm on android
2023-05-03 21:20:37 <vms14       > if you're not willing to mess with android studio, then meh
2023-05-03 21:21:01 <vms14       > there was a way to make android apps without android studio, but I think android didn't like that
2023-05-03 21:21:57 <crc         > The last time I tried running Android Studio it was brutally slow. Might be due to most of my systems being over a decade old now.
2023-05-03 21:22:12 <vms14       > it is
2023-05-03 21:22:38 <vms14       > and every time you launch it, it substracts years of life on your computer
2023-05-03 21:22:42 <vms14       > :D
2023-05-03 21:23:47 <vms14       > I hate java, but sometimes I wonder what if I had a version in java
2023-05-03 21:23:57 <crc         > on iOS, I can update the iOS version using Swift Playgrounds. (this isn't in the app store yet). This is less annoying than Android Studio or Xcode.
2023-05-03 21:24:30 <vms14       > this is the main reason I have a js version btw
2023-05-03 21:24:50 <vms14       > you make a web app, and it gets to android, iphone, windows, linux...
2023-05-03 21:24:58 <vms14       > and to deploy it, you just share a url
2023-05-03 21:25:26 <vms14       > also with progressive web applications (pwa) they fake a native app, and even give you access to some stuff
2023-05-03 21:25:57 <crc         > I've thought about doing a js version, but I'm not sure how to handle the blocks under that
2023-05-03 21:26:16 <vms14       > crc you have localStorage and IndexedDB
2023-05-03 21:26:29 <vms14       > localstorage isn't for large files, but indexeddb is
2023-05-03 21:26:44 <vms14       > also you have the file api
2023-05-03 21:27:41 <vms14       > and the blocks make even more sense there
2023-05-03 21:27:53 <vms14       > you could use html tags for them even
2023-05-03 21:28:11 <vms14       > like a <script type="block">
2023-05-03 21:28:30 <vms14       > the browser will ignore it, but you can access it through the dom
2023-05-03 21:28:41 <vms14       > the sad part is it won't be persistent, just read only
2023-05-03 21:28:44 <KipIngram   > I've got Android Studio installed, but haven't really done much with it.
2023-05-03 21:28:54 <KipIngram   > I installed that when I was thinking about doing a calculator app.
2023-05-03 21:28:55 <vms14       > you need indexeddb, which isn't nice to play with
2023-05-03 21:29:06 <vms14       > but there are some libraries trying to make it easier
2023-05-03 21:29:35 <vms14       > still for readonly blocks, isn't bad
2023-05-03 21:30:04 <crc         > blocks should be readable and writable though
2023-05-03 21:30:32 <vms14       > you can [...document.scripts].forEach((x)=>{if(x.type=='block'){blocks.push(x.textContent)}})
2023-05-03 21:30:52 <vms14       > you could use localStorage, as long as you don't store GB
2023-05-03 21:31:37 <vms14       > blocks make sense on the browser
2023-05-03 21:32:25 <vms14       > if you start someday, I can try to help you with indexedDB
2023-05-03 21:32:49 <vms14       > I'll end with blocks on my lang :D
2023-05-03 21:33:17 <vms14       > still you can just use localstorage
2023-05-03 21:33:39 <vms14       > A block is defined to be a 1024 byte
2023-05-03 21:33:43 <KipIngram   > Yay blocks!
2023-05-03 21:34:11 <vms14       > hmm, no idea if 1024 is good for localStorage
2023-05-03 21:34:16 <KipIngram   > I eventually got around to making blocks 4kB instead of 1kB.
2023-05-03 21:34:29 <KipIngram   > Just because 4kB is a really typical logical page size on many storage devices.
2023-05-03 21:34:31 <vms14       > 5MB per LocalStorage and SessionStorage
2023-05-03 21:34:42 <vms14       > you can have 5 blocks :D
2023-05-03 21:34:54 <crc         > my blocks are 4096 bytes (though I use a word-addressed system, so by default am still 16x64 characters)
2023-05-03 21:34:55 <KipIngram   > Plus it's 64 64 char lines instead of 16, and that's enough room to do fairly fancy things.
2023-05-03 21:35:12 <vms14       > then you can only have one :/
2023-05-03 21:35:32 <vms14       > indexedDB will let you store GB of data
2023-05-03 21:35:52 <vms14       > I guess it's like 80% of the total space the user has on his system
2023-05-03 21:36:18 <vms14       > Chrome and Chromium-based browsers allow up to 80% disk space. If you have 100GB, Indexed DB can use up to 80GB of space, and 60GB by a single origin.
2023-05-03 21:36:44 <crc         > KipIngram: my son is working on a 64x64 editor; they feel excessively large to me :)
2023-05-03 21:36:44 <vms14       > other browsers will let you 70% or alike
2023-05-03 21:37:02 <iyzsong     > i'd suggest make a port to libretro, it will work like a fantasy console like tic80, purely C api so easier that a native android/ios port.  and it also will work on more platforms like 3ds/psp :)
2023-05-03 21:37:20 <KipIngram   > Yeah, I guess they would if you're accustomed to the smaller size.  We get pretty "comfortable" on things like that.
2023-05-03 21:38:28 <vms14       > I only care about sizes when I write C
2023-05-03 21:38:39 <vms14       > the rest of the time I don't give a fuck
2023-05-03 21:38:48 <vms14       > it's unlimited memory for me :D
2023-05-03 21:39:25 <vms14       > like the stack will only overflow if you have no more memory
2023-05-03 21:39:30 <vms14       > in C would be also like that
2023-05-03 21:40:48 <vms14       > safari had a weird approach with indexeddb limits
2023-05-03 21:41:09 <crc         > I have set constraints: 32 data stack elements, 256 addresses on the return stack. 65,536 words of memory.
2023-05-03 21:41:10 <vms14       > it will keep asking the user every X bytes to store, without limit
2023-05-03 21:41:18 <vms14       > but there was a case when it did not ask
2023-05-03 21:42:05 <vms14       > I'd say I'll never have 32 elements on the stack, but maybe someday I decide to use the stack as a list
2023-05-03 21:42:39 <vms14       > for example, reset the stack, execute code that leaves stuff, then iterate the stack and do something
2023-05-03 21:43:03 <crc         > It's not that hard to get a bunch of stuff on the stack. While no single thing uses many values, during execution it can get fairly deep (I've hit 30 a few times)
2023-05-03 21:45:21 <vms14       > oh, you had a java binary of ilo
2023-05-03 21:46:18 <vms14       > Precompiled binaries for ilo for a variety of hosts: 68k Mac System 5, 6, 7  aarch64 Linux armv7e-m Teensy 4.1 x86 MS-DOS, FreeBSD, Linux, Windows amd64 FreeBSD, Haiku, Linux, NetBSD, OpenBSD, Windows, Java
2023-05-03 21:46:28 <crc         > that's the one written in kotlin
2023-05-03 21:46:53 <crc         > the .jar has the minimal set of kotlin libs needed to run it included
2023-05-03 21:47:34 <vms14       > how's kotlin?
2023-05-03 21:47:46 <vms14       > wasn't one of the langs that gave you trouble?
2023-05-03 21:47:53 <vms14       > along with swift
2023-05-03 21:50:09 <vms14       > https://news.ycombinator.com/item?id=26168640
2023-05-03 21:50:16 <vms14       > haha factor is your rival
2023-05-03 21:50:46 <vms14       > you post about retro-forth and people starts talking about how cool factor is
2023-05-03 21:51:12 <vms14       > ah, not your post
2023-05-03 21:52:08 <vms14       > some people told me my lang resembles to factor
2023-05-03 21:52:29 <vms14       > I didn't like factor when I had a look at it
2023-05-03 21:52:53 <vms14       > https://factorcode.org/
2023-05-03 21:53:09 <crc         > iyzsong: I'll look into libretro
2023-05-03 21:53:22 <vms14       > I dislike the example shown there
2023-05-03 21:53:43 <vms14       > and those >>
2023-05-03 21:53:50 <crc         > vms14: the hangups were in i/o for the blocks, and dealing with jvm being big endian (which is easy enough, I had just forgotten about this when I started)
2023-05-03 21:54:49 <vms14       > crc how much did you get with patreon?
2023-05-03 21:54:53 <crc         > I used factor for a while, when it was much smaller of a language
2023-05-03 21:55:01 <vms14       > did you like it?
2023-05-03 21:55:44 <crc         > vms14: on average, about $20/month
2023-05-03 21:56:07 <vms14       > hmm
2023-05-03 21:56:53 <crc         > I got a lot of ideas from it. Modern factor is much bigger and more complex; I mostly stopped following it when they were working on the gui stuff
2023-05-03 21:59:05 <vms14       > aha, stealing from the competence
2023-05-03 21:59:16 <vms14       > I was told to exactly do that too
2023-05-03 21:59:32 <vms14       > to take a look at factor and steal stuff, but nah
2023-05-03 21:59:47 <vms14       > if I want to steal concepts from something, is forth
2023-05-03 21:59:57 <vms14       > it's already a mix of forth and lisp
2023-05-03 22:00:11 <vms14       > with very few of forth xD
2023-05-03 22:01:44 <vms14       > Originally, Factor was written in Java,
2023-05-03 22:02:37 <vms14       > it's cool that the compiler is written in itself
2023-05-03 22:02:43 <vms14       > I like metacompilers
2023-05-03 22:02:43 <iyzsong     > crc: yeah, i'm sure that will be cool.  i think a cons of libretro is lacking native input, so if on mobile without keyboard, you have to implement a virtual keyboard yourself (eg: https://github.com/icculus/mojozork with virtual term and touch keyboard support)
2023-05-03 22:03:34 <crc         > kotlin was ok. It felt less clumsy than java (though it's been over a decade since I wrote in java). I dislike the need for extra runtime stuff, and the fact that the default compilation doesn't strip out unused classes from the runtime.
2023-05-03 22:04:32 <crc         > I ended up unzipping the .jar, removing a lot, then repacking it to get something that was much smaller
2023-05-03 22:04:45 <crc         > iyzsong: thanks; I'll take a look at this tomorrow
2023-05-03 22:06:54 <crc         > vms14: swift is fine. I prefer Objective C, but it works ok, wasn't difficult to use,  and made creating an iOS version pretty easy.
2023-05-03 22:11:57 <vms14       > hmm
2023-05-03 22:12:37 <vms14       > it proves that a vm helps a lot with porting
2023-05-03 22:12:58 <vms14       > porting is one of my issues, but js kind of solves tha
2023-05-03 22:13:44 <vms14       > and the lang is a toy lang, but it evolved a bit over the time
2023-05-03 22:14:19 <vms14       > for now I only I have one design flaw to solve, which will be solved if I make the language compile by default
2023-05-03 22:14:26 <KipIngram   > Oh, I'm liking that B.Y.O. Assembler article.
2023-05-03 22:14:57 <vms14       > what article?
2023-05-03 22:15:27 <vms14       > I was discovering who is peter forth
2023-05-03 22:15:28 <vms14       > https://donhopkins.com/home/PeterForth/
2023-05-03 22:19:26 <KipIngram   > It was posted earlier:
2023-05-03 22:19:42 <KipIngram   > https://www.bradrodriguez.com/papers/tcjassem.txt
2023-05-03 22:20:29 <KipIngram   > That's likely to be very interesting to you right now, vms14.
2023-05-03 22:22:47 <vms14       > ah I've posted it
2023-05-03 22:22:48 <vms14       > XD
2023-05-03 22:23:19 <vms14       > I was suspecting it was this article, but the b.y.o seemed to say it wasnt
2023-05-03 22:23:41 <vms14       > yeah, it's interesting
2023-05-03 22:23:53 <vms14       > ah, build your own assembler
2023-05-03 22:23:59 <vms14       > lol
2023-05-03 22:24:35 <vms14       > hi dave0
2023-05-03 22:24:47 <dave0       > hey KipIngram, vms14
2023-05-03 22:24:57 <dave0       > KipIngram: i clicked on your link
2023-05-03 22:25:02 <dave0       > and i will read it :-)
2023-05-03 22:25:37 <vms14       > I've just went to https://www.bradrodriguez.com/papers/
2023-05-03 22:25:47 <vms14       > as it has autoindex you can seee them all
2023-05-03 22:26:04 <vms14       > well not autoindex
2023-05-03 22:26:43 <vms14       > it has several interesting articles
2023-05-03 22:26:46 <KipIngram   > Hey dave0!  How ya been?
2023-05-03 22:26:53 <vms14       > https://www.bradrodriguez.com/papers/mtasking.html
2023-05-03 22:28:15 <KipIngram   > So, earlier we mentioned lean threads; got me thinking on it a little.  I think specifying a thread reqires three numbers: a) data stack depth, b) return stack depth, and c) user variable count.  Then a couple additional cells would be added for use by the system, and that would let you know how big a block of RAM was needed for that thread.
2023-05-03 22:28:59 <KipIngram   > A super lean one might have on down around a hundred bytes or so.
2023-05-03 22:29:06 <vms14       > crc do you have hashes and arrays on retro-forth?
2023-05-03 22:29:21 <vms14       > if you do, how's the word to get and push elements?
2023-05-03 22:29:36 <vms14       > I have syntax sugar for that plus words
2023-05-03 22:29:37 <crc         > arrays, yes; no hash tables. Arrays are fixed size.
2023-05-03 22:29:54 <vms14       > how do you access an element from an array
2023-05-03 22:30:23 <vms14       > I have [ 1 2 3 ] .0   which would be like [1,2,3][0] in most langs
2023-05-03 22:30:32 <vms14       > it works also for objects/hash
2023-05-03 22:30:39 <vms14       > { oh 1 meh 24 } .meh
2023-05-03 22:30:46 <vms14       > and ! for setting them
2023-05-03 22:30:54 <vms14       > [ 1 2 3 ] 24 .0!
2023-05-03 22:31:10 <KipIngram   > You multiply the index by the item size and add it to the base address - that gives you the address of the element.
2023-05-03 22:31:13 <vms14       > but also have separate words, mainly for when I'm creating code
2023-05-03 22:31:24 <vms14       > like push and get
2023-05-03 22:31:31 <crc         > forth.works/temp/retro-array.txt has some notes on them
2023-05-03 22:31:37 <vms14       > the thing is I never manage to remember the order of elements with get
2023-05-03 22:32:04 <crc         > { #1 #2 #3 } #0 a:fetch
2023-05-03 22:32:53 <crc         > #6 { #1 #2 #3 } #1 a:store (replace_#2_(index_1)_with_#6)
2023-05-03 22:33:10 <vms14       > a:th does return a memory address them
2023-05-03 22:33:14 <vms14       > then*
2023-05-03 22:33:32 <crc         > yes
2023-05-03 22:34:28 <vms14       > that's cool, It could be useful to implement a macro like (setf (car a) 3) on lisp
2023-05-03 22:35:03 <vms14       > as a:th returns a memory address, setf would use that
2023-05-03 22:36:12 <vms14       > crc does a:store need to swap its arguments usually?
2023-05-03 22:36:38 <vms14       > I can't decide on the correct order
2023-05-03 22:36:45 <vms14       > and never remember it later
2023-05-03 22:37:40 <crc         > No. I pass in "value array-pointer index"; then it's just reduced to using `a:th` to get an actual pointer to a specific entry, and `store`. No shuffling needed.
2023-05-03 22:38:46 <vms14       > hmm
2023-05-03 22:39:33 <vms14       > I had "array index value" and another word with "value index array"
2023-05-03 22:41:30 <vms14       > your order makes more sense
2023-05-03 22:42:59 <KipIngram   > Forth will guide you on such things.  Plan the words to work the way that makes implementing them easiest.  If you feel super strong about some other order, you can diddle the stack a little, but it's something to minimize.
2023-05-03 22:43:39 <KipIngram   > With crc's order, for an array of 64-bit cells, all it would take to do that store is 3 << + !
2023-05-03 22:44:28 <KipIngram   > So there's not much to it - even adding one SWAP would add a fairly substantial percent overhead.
2023-05-03 22:45:19 <crc         > My ordering mostly comes from 20+ years of writing programs in forth. As KipIngram, Forth will guide you
2023-05-03 22:46:23 <KipIngram   > And if you look at that article I just gave you the link for, they do the same sort of thing, letting the assembly code take the form that promotes efficient "assembly."
2023-05-03 22:46:35 <crc         > *KipIngram said; my typing is starting to suffer as midnight approaches :(
2023-05-03 22:47:05 <KipIngram   > Where are you, crc?
2023-05-03 22:47:39 <crc         > KipIngram: just outside Philadelphia, Pennsylvania in the USA.
2023-05-03 22:47:58 <thrig       > hopefully nowhere that involves a dreary midnight that has a raven
2023-05-03 22:48:00 <vms14       > yeah I was trying to not implement that word until I really needed to use it
2023-05-03 22:48:17 <vms14       > then I would set the order like I was going to use it
2023-05-03 22:48:34 <vms14       > I have syntax sugar, which is why I use normally
2023-05-03 22:48:50 <crc         > thrig: no ravens, though I did see some crows earlier today
2023-05-03 22:48:50 <vms14       > but sometimes I do generate code and having a word is just better
2023-05-03 22:48:50 <KipIngram   > Nevermore...
2023-05-03 22:49:28 <vms14       > s/why/what/
2023-05-03 22:51:56 <vms14       > crc why parable died?
2023-05-03 22:52:17 <vms14       > and what it had different to retro?
2023-05-03 22:53:29 <vms14       > oh, it was kind of an ide?
2023-05-03 22:53:45 <crc         > parable was an interesting experiment. It had types (every memory location was tagged with a type indicator), and memory was heavily segmented (memory was divided into slices, which could grow or shrink dynamically) and garbage collected.
2023-05-03 22:54:20 <vms14       > Unlike Forth, Parable does not provide programs with access to the parser.
2023-05-03 22:54:26 <vms14       > why did you decide that?
2023-05-03 22:54:48 <vms14       > doesn't make it easier having words reading from the source code?
2023-05-03 22:55:17 <vms14       > hmm I like the memory idea
2023-05-03 22:55:55 <vms14       > so no matter if there is stuff on consecutive memory, the slice would grow using another part of the memory
2023-05-03 22:56:32 <vms14       > what was toka?
2023-05-03 22:56:42 <vms14       > toka died sooner xD
2023-05-03 22:57:02 <crc         > I've not really missed parsing words. Konilo supports them, but I use this sparingly there. RetroForth doesn't support parsing words in all cases (when loading code from a file for instance, s:get and such read from keyboard, not a file input stream).
2023-05-03 22:57:32 <crc         > In my experiments, I tend to decide on a few constraints that seem interesting, and then see how things develop.
2023-05-03 22:58:10 <crc         > toka was an earlier language experiment, that mostly ended up being used to write the original assembler for retroforth 10
2023-05-03 22:58:31 <crc         > I've not run toka in many, many years
2023-05-03 22:58:56 <vms14       > yeah, I never heard of toka, yet parable does sound familiar to me
2023-05-03 23:00:25 <vms14       > https://github.com/crcx/littlesmalltalk :0
2023-05-03 23:00:48 <vms14       > https://github.com/crcx/littlesmalltalk/blob/master/smallworld/2004/SmallObject.java
2023-05-03 23:01:00 <vms14       > oh it had swing
2023-05-03 23:02:14 <crc         > forthworks.com:8080/parable/dir?ci=tip and forthworks.com:8080/toka/dir?ci=tip for parable & toka
2023-05-03 23:03:29 <vms14       > python
2023-05-03 23:03:29 <crc         > smallworld was interesting; it didn't get any real attention from what I could see back when it was being developed. I'm not sure if it still works on modern JVM. I should probably test it sometime.
2023-05-03 23:03:47 <vms14       > you really know a lot of languages
2023-05-03 23:03:58 <crc         > There was a C version of parable, but it wasn't ever completed
2023-05-03 23:08:07 <crc         > I've worked with a lot of languages over the years. The ones I've used the most were BASIC, Pascal, x86 assembly, C, Python, and Forth.
2023-05-03 23:09:20 <crc         > I try to maintain familiarity with a variety of old & new languages though. It's good to gather ideas, and to know when something might be better suited to a particular problem.
2023-05-03 23:11:36 <thrig       > Feynman used that tactic
2023-05-03 23:12:56 <vms14       > I have a lot of languages in a "tolearn" list
2023-05-03 23:13:10 <vms14       > but I guess it would get reduced to prolog and assembly
2023-05-03 23:13:39 <vms14       > and I think I'm going to focus on javascript xD
2023-05-03 23:14:11 <vms14       > I don't have too much interest, but it gives me several benefits
2023-05-03 23:14:24 <vms14       > including the possibility of getting a programming job
2023-05-03 23:15:14 <vms14       > it's not so bad after all
2023-05-03 23:16:17 <vms14       > haskell is cool, but I dislike the purity vs impurity stuff
2023-05-03 23:16:49 <vms14       > it has a lot of cool concepts and "tools" for algorithms
2023-05-03 23:17:08 <vms14       > but then a string gets defiled
2023-05-03 23:17:43 <vms14       > I dislike when compilers complain
2023-05-03 23:19:37 <vms14       > Joy is the canonical Concatenative language,
2023-05-03 23:19:41 <vms14       > ugh, what a lie
2023-05-03 23:20:02 <crc         > 
ACTION is heading to bed; goodnight everyone 

2023-05-03 23:20:05 <vms14       > https://concatenative.org/wiki/view/Comparison%20of%20Factor%20and%20Joy
2023-05-03 23:20:08 <vms14       > and this, wtf
2023-05-03 23:20:11 <vms14       > gn crc
2023-05-03 23:20:22 <vms14       > The following program demonstrates a feature that is present in Joy and not in Factor:
2023-05-03 23:20:26 <vms14       > what a nice comparison
2023-05-03 23:32:17 <KipIngram   > I'm going to try to remember to post an article link next time crc is on.  Read it a few months ago - it's premise is that there are seven "archtypal" languages, and the article recommended learning at least one of each category.
2023-05-03 23:46:19 <thrig       > prolog, forth, lisp, English, C++, C++, C++
2023-05-03 23:50:36 <KipIngram   > Heh heh.
2023-05-03 23:50:54 <KipIngram   > Here it is:
2023-05-03 23:51:01 <KipIngram   > https://madhadron.com/programming/seven_ur_languages.html