The docs don't mention channels and say that fibres are built on limited continuations (call/cc) which suggests missing some of the clever stuff in CML (e.g. that threads deadlocked on a channel get garbage collected)
While being heavily inspired guile-fibers, it seems to not actually be parallel.
Anyway, I would say it is actually the nicest way to write concurrent programs. It supports you and helps you to not shoot yourself in the foot, while also staying out of the way.
After skimming the docs and the site, I suspect this is x86-only for now. No mention of ARM or other processor architectures and the listed hardware support suggests a PC hardware target. You could probably cross compile on an Apple silicon Mac and run under emulation (e.g., QEMU).
This is super interesting. I kind of want to use this to turn one of my old laptops into a Scheme machine. But from the docs I think on bare metal it's only usable over serial.
To have a working keyboard with en-us keys layout and LAN (Intel's NIC card) you need to build image from the latest development version, it might be an EFI or
a legacy MBR image. The REPL is only interpreted, it does not have
runtime bindings (I mean you can't change the running system state
because REPL creates new library instances) and it does not compile at runtime.
This looks nice and very interesting that this runs on bare metal. Is more documentation / tutorials available anywhere?
EDIT: Found the documentation: https://scheme.fail/manual/loko.html
Nice achievement, building on the foregone dreams of Lisp powered workstations.
We need more efforts like these and less yet another UNIX clone in C.
Agree. How would one use/access graphics and GUIs with overlapping windows from it?
Like this?
https://interlisp.org/
Or are you asking about this instead?
https://archive.org/details/bitsavers_symbolicssGuidetoSymbo...
> Loko’s runtime uses concurrency based on Concurrent ML.
That one could be a big deal.
https://scheme.fail/manual/loko.html#Concurrency
The docs don't mention channels and say that fibres are built on limited continuations (call/cc) which suggests missing some of the clever stuff in CML (e.g. that threads deadlocked on a channel get garbage collected)
While being heavily inspired guile-fibers, it seems to not actually be parallel.
Anyway, I would say it is actually the nicest way to write concurrent programs. It supports you and helps you to not shoot yourself in the foot, while also staying out of the way.
I also like that it runs on bare metal. I wonder is it builds and runs on macOS? (I am on a mobile device and can’t check it myself.)
Off topic, but I love the design of the linked web site.
After skimming the docs and the site, I suspect this is x86-only for now. No mention of ARM or other processor architectures and the listed hardware support suggests a PC hardware target. You could probably cross compile on an Apple silicon Mac and run under emulation (e.g., QEMU).
That's right, currently only the x86-64 architecture is supported.
This is super interesting. I kind of want to use this to turn one of my old laptops into a Scheme machine. But from the docs I think on bare metal it's only usable over serial.
I did successfully run the bare-metal Loko image on the ThinkPad x230 with GUI, mouse and keyboard access.
OOh nice, I am certainly going to try it then!
To have a working keyboard with en-us keys layout and LAN (Intel's NIC card) you need to build image from the latest development version, it might be an EFI or a legacy MBR image. The REPL is only interpreted, it does not have runtime bindings (I mean you can't change the running system state because REPL creates new library instances) and it does not compile at runtime.
I know what I'll be playing with this week :)
It can be made to work over Qemu