Yes. It has zero runtime dependencies but development currently assumes GNU tools. The test suite for example is entirely written in bash and uses GNU coreutils. I submitted a patch to coreutils to allow env to set argv[0] of programs specifically so I could use it in my test suite.
Currently lone is a single C source file. It could easily be compiled manually if necessary.
I've started reorganizing the repository though so that's likely to change.
Is there a plan to write a lone compiler so as to eventually have lone bootstrapping/compiling itself so that you no longer have to sully your hands with C?
I would like that. I wanted to create the simplest possible reference C implementation first so the language can always be bootstrapped with a C compiler. After that, I'll probably make a better one. I'm considering a Rust implementation as well.
At least that's what I tell myself. Just this simple interpreter has already generated a lifetime of work. It's making me wish I had infinite time to work on it.
Writing your software to directly use the syscalls of a specific kernel does not make it "zero dependency", it makes it "one dependency" - and non-portable.
TBH I have mixed feelings about this approach. It's true that this is more or less what Go or (Cosmopolitan libc) do, but the motivation in their case is to maximize portability (by making cross-compilation trivial). However when you #include <linux/...>, you not only make your software non-portable, you also make it a PITA to cross-compile as you need the kernel headers on the host machine.
In contrast, with Go or cosmo, I can trivially build a tiny /sbin/init for amd64 Linux, pack it up with cpio, and run it with qemu-system-x86_64 -initrd - all from a Mac/arm64 host.
At that point we really get into semantics... But now that you mention it, I would be interested to see if it could be built with APE to benefit from their bare metal support.
Yes. It has zero runtime dependencies but development currently assumes GNU tools. The test suite for example is entirely written in bash and uses GNU coreutils. I submitted a patch to coreutils to allow env to set argv[0] of programs specifically so I could use it in my test suite.
Currently lone is a single C source file. It could easily be compiled manually if necessary. I've started reorganizing the repository though so that's likely to change.
>Currently lone is a single C source file.
Is there a plan to write a lone compiler so as to eventually have lone bootstrapping/compiling itself so that you no longer have to sully your hands with C?
I would like that. I wanted to create the simplest possible reference C implementation first so the language can always be bootstrapped with a C compiler. After that, I'll probably make a better one. I'm considering a Rust implementation as well.
At least that's what I tell myself. Just this simple interpreter has already generated a lifetime of work. It's making me wish I had infinite time to work on it.
You don't have to; you get to! ;D
1 reply →
All software needs dependencies at build time, saying no dependencies always means runtime.
I'm surprised the Kernel doesn't count here.
It does.
Writing your software to directly use the syscalls of a specific kernel does not make it "zero dependency", it makes it "one dependency" - and non-portable.
The author elaborates on their rationale and the technical details in a blog post: <https://www.matheusmoreira.com/articles/linux-system-calls>
TBH I have mixed feelings about this approach. It's true that this is more or less what Go or (Cosmopolitan libc) do, but the motivation in their case is to maximize portability (by making cross-compilation trivial). However when you #include <linux/...>, you not only make your software non-portable, you also make it a PITA to cross-compile as you need the kernel headers on the host machine.
In contrast, with Go or cosmo, I can trivially build a tiny /sbin/init for amd64 Linux, pack it up with cpio, and run it with qemu-system-x86_64 -initrd - all from a Mac/arm64 host.
5 replies →
At that point we really get into semantics... But now that you mention it, I would be interested to see if it could be built with APE to benefit from their bare metal support.