This is a much needed thing for Raku's growth.
HN user
apogee
Raku grammars are cracked. Here's Jinja2: https://github.com/m-doughty/Template-Jinja2/blob/master/lib...
I've set up GitHub actions to prebuild all the deps so on any modern Mac/Windows/Linux it should just be 'zef install selkie' now.
Thanks, I will get this into the next version of the Readme, I think the minimum would be roughly:
sudo zypper in \
ncurses-devel libunistring-devel libdeflate-devel \
ffmpeg-7-libavcodec-devel ffmpeg-7-libavformat-devel \
ffmpeg-7-libavutil-devel ffmpeg-7-libavdevice-devel \
ffmpeg-7-libswscale-devel \
cmake pkg-config gccI've got a few LLM modules too, mostly for handling context management:
- https://raku.land/zef:apogee/LLM::Character implements CCv3 which is a standard for managing characters (system prompts) and lorebooks (injected snippets)
- https://raku.land/zef:apogee/LLM::Chat handles context shifting for long contexts, sampler settings, templating for text completion & inferencing with or without streaming using supply/tap
- https://raku.land/zef:apogee/LLM::Data::Inference adds retries, JSON parsing & multi-model route handling to LLM::Chat
- https://raku.land/zef:apogee/LLM::Data::Pipeline allows you to declaratively build multi-step pipelines (simple agentic LLM use)
- https://raku.land/zef:apogee/HuggingFace::API is a partial wrapper around HF API for grabbing tokenizers.json & tokenizer_config.json
- https://raku.land/zef:apogee/Template::Jinja2 is a near-complete impl of Jinja2 for parsing LLM text completion templates (can be used for anything you'd use Jinja2 for)
- https://raku.land/zef:apogee/Tokenizers is a thin wrapper around HF tokenizers, for token counting mostly
np, what kind of TUIs do you write?
Yeah I have thought about doing this with Roaring::Tags (https://raku.land/zef:apogee/Roaring::Tags) so you type a Roaring::Tags query on one side and it shows the built Raku on the other.
Wouldn't be too difficult:
- FileBrowser widget to get the serialised bitmap.
- MultiLineInput for the query text input.
- ListView to show tags and fields.
- RichText for the AST pretty printer.
The tl;dr is: because you want native performance and don't want to focus on blitting pixels or terminal internals.
Selkie has an event/effect model similar to Elm & re-frame, you just declare your widgets and renders/updates are handled by the lib.
As for why Raku:
- grammars allow for easy parsing of complex DSLs
- supply/tap are a natural fit for the event/effect model, asynchronous thread-safe programming
- roles make composing widgets simple
- it's fun to write :D