IRC channel logs

<abcdw>When I try to split my project into modules I get a not very descriptive error message. I try to (compile-file "./scheme/hoot/simple.scm") the following stub module: https://paste.sr.ht/~abcdw/fdb098cb1d672412fd13f377e22250d2ca44d116 what am I doing wrong?

<weary-traveler>abcdw: ooc, what's the error you get?

<abcdw>weary-traveler: right, forgot to paste it :) unbound top-level #("./scheme/hoot/simple.scm" 0 1) define-module

<abcdw>weary-traveler: with stacktrace: https://paste.sr.ht/~abcdw/c76b5d6a2e6a7efa5acc74ffc68b420b56cf3e21

<jfred>I ran across Garnix today (https://garnix.io/) and it got me thinking about how one might do the same safely in Guix. The fact that Guix manifests are written in a full programming language suggests more caution is warranted, but maybe a job for capabilities?

<jfred>(Not that converting Guix manifests to a capability-safe Scheme subset/module system would be anything short of a gargantuan task...)

<civodul>jfred: looks interesting

<civodul>note that we have a similar problem with qa.guix.gnu.org, which takes patches from the mailing list

<civodul>but, sorta related, there’s the idea of having channels (not manifests) readable as pure data (JSON): https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00201.html

<jfred>civodul: ah, yeah, something like that could work too for channels. could be s-expressions too, if you treat them as pure data rather than evaluating anything in them

<jfred>good point re: qa though yeah, I was wondering what protections were there for that (but obviously wasn't going to test it on the live instance!)

<civodul>heh :-)

<civodul>there are discussions about running inferiors in containers in the past

<civodul>for that purpose

IRC channel logs

2024-08-22.log