💾 Archived View for vierkantor.com › xukut › manual › tricks.gmi captured on 2024-05-10 at 10:39:16. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Here are a couple of places where the implementation of XukutOS/Swail is not quite set up straightforwardly. Usually this is caused by limitations in the tooling, or of the environment. All of the following should be considered low-priority bugs, to be fixed through redesigning the relevant parts of the system in a neater way.
The current compiler/assembler/linker situation is quite limited and unable to (easily) express everything definable from within Swail. A good example is methods: the metamethod protocol is bootstrapped in such a way that you basically need to run Swail code to add a method to a generic function. So whenever we encounter such a situation where we want to use Swail code for definitions, these definitions are done from within the init process, before it starts the other processes.
The hope is that soon Xukut can start compiling itself, and we can turn all the source code into Swail code.
To bootstrap the metamethod protocol, `specialiser:get' is not actually a normal generic function, but has its own special type that informs the interpreter to handle the following specialisers manually:
* `tt'
* `(subclass ty)'
* `(is-same val)'
If `specialiser:get' is not called on one of the above forms of specialisers, it will proceed to follow the normal call-most-specific-method routine.
The main consequence for users is that you cannot redefine the effects `specialiser:get' has for those three forms, while you can for the other forms. Since this redefinition is probably a bad idea anyway, it's not too bad.
This special behaviour is required because the definition of the corresponding `specialiser:get' methods would have to be in terms of the specialisers themselves. Perhaps a cleverer design of the metamethod protocol or its implementation can fix the trickyness.
More details on `specialiser:get' and the metamethod protocol
XukutOS generally follows a microkernel approach, making the kernel do the minimum necessary and letting userspace drivers handle most of the work. However, on a Raspberry Pi, when an interrupt fires for receiving data over an UART, the kernel will acknowledge the incoming bytes and place them in a ringbuffer, then signal the UART driver process to check this ringbuffer. The acknowledging is done in kernel mode since the interrupt will re-fire as soon as interrupts are re-enabled before the data is acknowledged. Communication is done via a ringbuffer rather than the usual message sending, since the kernel cannot allocate during interrupts, so it cannot produce a new message.
One alternative would be to allow certain processes to run with interrupts turned off. The scheduler is definitely not ready for that kind of processes though.
To break circular dependencies, `swail:if' directly calls the `cast-bool' method. This is mostly OK since overriding built-in methods has undefined consequences,
Any questions? Contact me:
By email at vierkantor@vierkantor.com