2024-06-27 01:01:52 <KipIngram   > MrMobius: Yes, I'm hoping for this system to be very very portable.
2024-06-27 01:02:27 <KipIngram   > Basically I want to be able to port the vm layer and then have the system itself (a code-threaded Forth running on that vm) be binary portable.
2024-06-27 01:06:35 <vms14       > KipIngram you will define your own assembly and a vm that interprets this assembly even if in bytecode and then write your forth in that assembly?
2024-06-27 01:08:53 <vms14       > well it was obvious since you told me you wanted to create everything, this also includes the assembler
2024-06-27 01:08:55 <KipIngram   > Yes.  The vim instructions will be the "primitives."  The goal will be to write everything using those instructions.
2024-06-27 01:09:07 <KipIngram   > s/vim/vm/
2024-06-27 01:09:59 <vms14       > but does not feel like an assembly, just part of your forth lang?
2024-06-27 01:10:29 <vms14       > like your forth will have stuff to mess with the registers and alike
2024-06-27 01:10:41 <KipIngram   > Well, the instruction set itself is designed to be very "Forth friendly."  It won't look a lot like conventional assembly language.
2024-06-27 01:10:42 <vms14       > and then write your forth in your forth
2024-06-27 01:10:58 <KipIngram   > And the line between primitives and definitions is blurry in code threading anyway, since you can inline.
2024-06-27 01:11:49 <vms14       > the bootstraping ability is an interesting thing and i would like to learn about some day
2024-06-27 01:12:14 <vms14       > i assume is just to know what primitives you need defined and add stuff on top of that
2024-06-27 01:12:53 <KipIngram   > What I'm planning to do first is a C program for Linux that has a vm layer in it.  And then I want to write in my finished Forth form right from the start.  Initially it will be interpreted comiled by that C program, but I'll gradually transfer control over to the code I've written until the C isn't being used anymore.
2024-06-27 01:13:07 <KipIngram   > That's the idea at least - I haven't done it yet so I'm only assuming it will go ok.
2024-06-27 01:13:57 <KipIngram   > That MAX board can be programmed by just droping a firmware file onto the storage device it presents when you plug it into a USB port.
2024-06-27 01:14:13 <KipIngram   > So I don't need a "programmer" or anything like that, and I intend for gcc to be my only "dev tool."
2024-06-27 10:49:44 <veltas      > MrMobius: Have you seen how old Windows solved this problem?
2024-06-27 10:51:11 <veltas      > https://devblogs.microsoft.com/oldnewthing/20041104-00/?p=37393
2024-06-27 10:51:52 <veltas      > That's how I would do it if I wanted memory compaction (i.e. if you don't have virtual memory)
2024-06-27 11:44:19 <veltas      > KipIngram: To be really 'enterprisey', I think the best way to design this is with some user stories, think through what sort of situations users might encounter with multitasking and running multiple apps
2024-06-27 11:44:33 <veltas      > How will they run these apps, how will that work in Forth's model of loading, etc
2024-06-27 11:45:12 <veltas      > And I think the answer is really you need separate threads with separate dictionaries for multiple big programs running at once if you want windows etc
2024-06-27 11:45:39 <veltas      > I would just load a fixed area for such a program, and reload if it crashes with too little
2024-06-27 11:45:57 <veltas      > On a big machine just give it a lot
2024-06-27 11:46:05 <veltas      > On a small machine might take some tweaking, but it will anywya
2024-06-27 11:46:17 <veltas      > And this avoids compaction which is a lot of extra complexity
2024-06-27 11:46:52 <veltas      > In Forth we don't mind passing some hacky details to the user to worry about, if it saves a ton of extra programming
2024-06-27 14:22:39 <zelgomer    > which one of you keeps posting forth stuff to ycombinator news lately
2024-06-27 14:28:09 <dave0       > lol
2024-06-27 14:40:19 <KipIngram   > lmao
2024-06-27 14:40:56 <KipIngram   > I'm enterprisey at work.  I'd rather take a "craft" approah to this.
2024-06-27 14:41:16 <KipIngram   > But yeah, I do spend some time trying to imagine how I'd want to use it in the end.
2024-06-27 14:41:24 <KipIngram   > So, maybe that counts a little.
2024-06-27 14:41:55 <KipIngram   > You know, some "how is that actually going to go?" pondering.
2024-06-27 20:56:26 <veltas      > So is LoC relevant again? https://sansec.io/research/polyfill-supply-chain-attack
2024-06-27 20:59:54 <veltas      > I'm always enterprisey :P
2024-06-27 21:00:23 <GeDaMo      > If you use NoScript, make sure you haven't whitelisted polyfill.io
2024-06-27 21:02:28 <thrig       > websites are forever telling me to enable javascript in w3m for a "better experience" or some other such nonesense
2024-06-27 21:04:41 <GeDaMo      > "This site requires Javascript"
2024-06-27 21:04:41 <GeDaMo      > /me inspects and deletes nojs banner
2024-06-27 22:23:08 <KipIngram   > Yeah, I know "active content" fuels a lot of stuff, but I've never been able to beat the feeling that it was a misstep security-wise.
2024-06-27 22:26:01 <thrig       > https://www.cve.org/ (a security incident database) is soon mandating a javascript-only website...
2024-06-27 22:58:52 <KipIngram   > I'm definitely not saying it's not useful.  It opened all kinds of doors.  Just not all of them good.
2024-06-27 23:44:02 <KipIngram   > It does seem like there was a tractable middle ground there, though - maybe allow things like JS to control the display and the speaker, and access the keyboard and mouse as inputs, but give it no access at all to storage.  Something that would have raised the chance of keeping security bugs out.
2024-06-27 23:44:16 <KipIngram   > Though I guess there are always the "classics" like buffer overrun and so on.