boredjohnny

I run a small consulting shop with a family member. We are a little bit tight on time but I'm willing to help with whatever you guys are facing rn.

That is awesome! Checking it out. And the fact that is 100% compatible with vfp9 makes it a solid choice.

Interesting! Yes, I would love to give it a try.

That is the same experience that I had with manufacturing shops, they just keep using the tool if it works.

> And to the Author of the project. Thank You for making it. My pleasure

Yeah sorry about that. Didn't thought about releasing it as this was a solution for my dad's friend shop that ran an old really old VFP project and didnt wanted/care to migrate. So I put together the site quickly using Claude. I might give it some human love next weekend

Fair concern. MIT licensed, all source code on Github for audit. Only Nodejs + a Rust toolchain is required to compile it. On windows (for the FLL bridge) it needs Visual Studio C++ tools

Hi Neat! you mentioned you guys are already on a rewrite path. That is the proper way forward and I recommend gathering as much information about the product and edge cases as possible. Document every business rule, every product decision. Handwaving aside, audit the Foxscript source code, clone it to a virtual machine or container. Any issue you face, feel free to post an issue on Github as I would love a few edge cases on the wild. As the Foxscript runtime relies on 64 bit offsets for the DBF/Memo, once a DBF (past the 2GB) is opened they can't be migrated back to old VFP9, so I recommend to test this carefully on an airgaped setup with tests DBF.

Hi! thank you for the candid response.

Because the same module runs in three places: inside the Electron IDE, in the shipped app, and in the test suite under jsdom, with no native build per platform. The other reason is the boundary itself: wasm exports can't re-enter, which forced the design where every side effect is yielded to the host and the VM is never on the stack while a dialog is up. That's what makes MESSAGEBOX not freeze the window. Perf isn't where these apps hurt, they're I/O and UI bound, and VFP itself was a p-code interpreter. The crate is plain Rust, the CLI runner is native, so a native build is a cargo flag away if it ever matters

Thanks, this is the most useful comment here. FoxDev reads the DBC the same way VFP does, so today it inherits the hole exactly. The runtime is actually the one place it can be fixed. I would put in a hash of the stored procedure text into the built executable and refuse to run a container whose procs don't match. Adding it to the list. Would you mind if I quoted your comment in the issue?

Funny enough the customer is one of my dads friends that has been running the same shop for 20 years, wanted bigger tables and keep milking that for the foreseable future. I wanted something simple, no jit stuff, no gc complexity. Just a stack based interpreter. Yes it was LLM assisted like most stuff nowadays.

bigger tables (2 GB cap) and no source code changes.