GDSL is written in C++ with use of STL, templates and lambdas, so it's 2600 lines of such C++ source code. There is no self-hosting: neither the LISP compiler nor the C compiler can compile itself. No operating system is implemented, the word kernel in the title means something else.

FYI Here is a 700-line subset-of-C compiler which can compile itself: https://github.com/valdanylchuk/xcc700 . FYI The linker and the libc are not included.

Kernel as used in the title means shared processing core, not necessarily an OS kernel, which probably deserves clarification. As for Lisp and C, those are meant to be subset demonstrations not yet full compilers, thus the phrasing. The compiler you linked is also a subset of C with only what's needed for a minimal compiler.

I’ve been working towards making it self hosting eventually, which is why there’s the start of code for generics in GDSL-C, though that’s a significant project which will take significant time. Add to that, a lot of people would prefer to write handlers in C++ rather than learn a new language. So it may stay as a C++ project for a while.

That being said, I was also hesitant to post this until I had it self hosting, but I decided that being able to implement even the demonstrated subsets was interesting enough to be worth sharing. This is a project in progress, and I hope to expand it massively in the months to come.

It's possible to run WebAssembly programs from the command line (without any GUI) using WASI (see e.g. https://github.com/WebAssembly/WASI). Thus if the user downloads pdfconverter.wasi , and the user already has e.g. wasmtime installed, they can run `wasmtime pdfconverter.wasi input.pdf output.pdf` from the command line (see https://github.com/bytecodealliance/wasmtime/blob/main/docs/... for details).

In addition to the web site, the Electron app and the Chrome extension, you may want to distribute a command-line version of your tools as WASI-style .wasm program files. If you do so, I would exclusively use the them this way, from the command line.

Your commands to process PDF with Ghostscript are lossy (they lose lots of metadata and in minor ways they also change how the PDF renders), and they produce very large PDF files.

Can you expand on why the produced PDF files are supposed to be larger than the originals? I've not observed that yet.

It does exclude unused code. But glibc has too many inter-object-file dependencies, so too much code gets used.

Neither the article nor the README explains how it works.

How does it work? Which WASM euntime does it use? Does it use a Python jnterpreter compiled to WASM?

There's a link to the author's work here:

https://github.com/mavdol/capsule

(From the article)

Appears to be CPython running inside of wasmtime

yep, and to be specific, it leverages the WASM Component Model and uses componentize-py to bundle the user's script

See the linked project at the end: https://github.com/mavdol/capsule

>As a text editor user, I prefer selecting the font and the syntax highlighting independently. This font is not useful for me.

Then it's not for you. This comment does not add anything to the conversation and comments like these are better left unwritten.

I suppose this gets useful in applications where you can change the font, but not add syntax highlighting. Besides being a neat trick, of course.

What is the advantage of this circular implementation?

Is it faster than the simple one? Does it use less memory? Is it easier to write? Is it easier to understand?

I think all of the above is false, but I have a limited understanding of Haskell. Please correct me if I'm wrong.

> The algorithm isn’t single-pass in the sense of Adaptive Huffman Coding: it still uses the normal Huffman algorithm, but the input is transformed in the same traversal that builds the tree to transform it.

Limited understanding here too. Sounds like it's not really single pass anyway so it's not usable to process a stream in real-time either, before having all the data?

There's no (practical) advantage to the circular implementation; it's just a curiosity.

It is useful for understanding laziness and some interesting theoretical tools for traversing data structures, though. For a more in-depth look at the idea of circular programs for traversal, Bird's paper (linked in the post, https://link.springer.com/article/10.1007/BF00264249) is a good start.

It's a weird claim about a single pass too. It's more of a "let's replace some iteration with building a tree of functions to call" and then pretends waking/executing that is not another pass.

Why is ELF so much slower and/or more memory hungry than a.out on Linux?

Relocation information, primarily.

ELF supports loading a shared library to some arbitrary memory address and fixing up references to symbols in that library accordingly, including dynamically after load time with dlopen(3).

a.out did not support this. The executable format doesn't have relocation entries, which means every address in the binary was fixed at link time. Shared libraries were supported by maintaining a table of statically-assigned, non-overlapping address spaces, and at link time resolving external references to those fixed addresses.

Loading is faster and simpler when all you do is copy sections into memory then jump to the start address.

Shameless plug: Some of my hobby projects written in C (e.g. https://github.com/pts/bakefat) can be built reproducibly for Linux >=1.0 (1994), FreeBSD (same ELF executable program file as for Linux) and Win32 working on all versions of Windows (Windows NT 3.1 (1993)--Windows 11). The C compiler (running on Linux i386 and amd64 host) used for the release build is self-contained and included in the project, along with the libc.

Doing such backward compatibility is definitiely possible for command-line tools. Once set up, it's automatic, and it needs extra testing after major changes.

If a text-mode process monitor is larger than about 200 KiB, then it sounds bloated to me. If it's loaded with tons of features, then my upper limit is 1 MiB.