IRC channel logs
2026-05-29.log
back to list of logs
<ArneBab>dthompson: it seems that both sdl2 and guile3.0-opengl pull in mesa … <dthompson>ArneBab: you're always going to have a massive bundle with guix pack, unfortunately <ArneBab>I just tried that for smaller dependencies and that was surprisingly small <ArneBab>If I just package bash, that’s 30 MiB -- with all dependencies. <dthompson>the issue is that guix is going to pack in the entire dependency graph <dthompson>and you can't be like "don't include mesa, I want to use the host's" <ArneBab>are your build instructions available somewhere? <dthompson>a project I have never gotten around to is doing this same thing but with guix. <ArneBab>My main question is whether it would be viable to create a specialized build of chickadee and sdl that does not depend on mesa. <dthompson>what you want are shared libraries that don't have hardcoded runpaths <dthompson>I used 'chickadee bundle' to create the aforementioned bundle. I built it on an ubuntu vm with an old glibc so the binary would run on as many systems as possible <ArneBab>I’d like to have a way to specify system libraries: "please use these from the host system" <dthompson>you can't easily do that with guix by the very nature of how it works <dthompson>I have experimented with making specialized package graphs that built libraries without runpaths, but it's been a long time and I never got it fully working. <ArneBab>couldn’t I delete store paths and replace them with symlinks into the host system with LSB paths? <dthompson>I'm sure it's possible to patch everything out <ArneBab>(which would naturally void some of the guarantees of Guix …) <dthompson>basically the idea would be to build things in such a way that you rely on the host machine's glibc and mesa and x11/wayland, etc. <dthompson>and you just ship the stuff you can't reasonably assume will be there: sdl, libpng, guile <ArneBab>yes -- that could be a good fit for the pack appimage command. <dthompson>the problem is that it's not easily generalizable <dthompson>but I see a path towards making something specific to chickadee, for example <dthompson>besides the shared libraries, the other contributor to bundle bloat is guile itself. <ArneBab>As a first step that would already be great -- a way to create games that stay binary compatible as long as possible without embedding everything. <dthompson>you don't need/want to ship all the .scm and .go files it comes with, only the ones your program actually uses. chickadee bundle has a tree shaking pass that takes care of this, at least. <ieure>ArneBab, Distribute it in the form of a S/NES or Genesis ROM. Problem solved. <dthompson>my blocker in the past with this whole thing was getting a guix gcc toolchain that didn't do the runpath stuff <dthompson>ArneBab: you could probably slim guile down a ton if you are shipping all of it <dthompson>your program likely uses a small fraction of it <ArneBab>dthompson: if I can do something (on the order of things manageable in limited time) please drop me a note. <ieure>dthompson, Nice, love to see new games coming out for old platforms. Some good C64 stuff these days, too. <ArneBab>dthompson: I wonder whether it could also be possible to only pre-compile and auto-compile the stuff the program uses. <dthompson>ArneBab: well the task open to anyone is to make a gcc-toolchain variant that builds "traditional" .so files <dthompson>ArneBab: for me that doesn't really matter. I compile the program on my machine and then use module introspection to find the full dependency set and pack only those .go files <dthompson>this trick would be made obsolete if/when guile can generate an excecutable that bundles the vm with the bytecode <ieure>dthompson, Game looks cool, reminds me of Pulstar or Blazing Star on the Neo-Geo. <ieure>I've been playing through some old arcade shmups (coin-op is my first video gaming love), got a good chunk of the way through Strikers 1945, but it ramps up something awful. <ieure>Was just playing in MAME, but I have the PCB, just need to fix up the cabinet I want to put it in. <ieure>Too many projects, not enough time. <ArneBab>I fear a gcc-toolchain variant is outside the level of things I can manage … <ArneBab>bonnie-bee sadly doesn’t start for me: bin/guile: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory -- I guess that’s guix … <dthompson>ArneBab: yeah it was not built for guix but for FHS distros <dthompson>on Guix you can just use the guix.scm file in the repo <dthompson>though I haven't touched that since 2021 so who knows if it builds still <ArneBab>sounds worthwhile to give it a try, will report <JohnCowan>dthompson: Msybe you are thinking of SRFI 272? <ArneBab>it starts with the start screen when using guix environment -l guix.scm -- bash -c './bootstrap && ./configure && make && ./pre-inst-env bonnie-bee' -- but then dies with starling/kernel.scm:376:29: Wrong number of arguments to #<procedure 7faaea6f07a0 at starling/kernel.scm:376:29 (stack key args)> <ArneBab>maybe something in my environment -- I should adapt the environment to be pure and include all tools actually needed. <dthompson>it's still referring to starling, a project I renamed to catbird later <ArneBab>doesn’t seem to be my environment. This one starts pure (but errors out the same): guix environment --pure -l guix.scm bash guile -- bash -c './bootstrap && ./configure && make && ./pre-inst-env scripts/bonnie-bee' <ArneBab>anyway: it’s nice to see that 17MiB are possible! Thank you! <tohoyn>are .go files generated by guile 3.0.11 and 3.0.10 binary compatible? <ArneBab>rlb: do you plan to package guile-freezer into guix? <tohoyn>daviid: it seems that running example program layout-manager-2 requires subdirectory examples/gtk-4/demos built explicitly. is this intentional? <tohoyn>daviid: this is because layout-manager-2 needs file libfpt.so <graywolf>Hello Guile :) So I have a problem. When I compile by files, some top-level symbols are no longer available in a REPL. I suspect some optimization pass is responsible, since it happens only with -O2 and using -O0 fixes it. I have tried -Ono-eliminate-dead-code, but did not help. Does anyone know which pass I need to disable to keep my top-level symbols alive? <rlb>graywolf: not sure which optimization causing that, but someone (old?) mentioned a possible related trick, but I forget exactly what. It was something like an extraneous (define x x) at the top level. <rlb>I'd guess an export would also do it if that's feasible. <rlb>ArneBab: I got the impression that guile-freezer was still pretty experimental. And I also have very little experience with guix as yet. <mwette>the `(define x x)' trick came from civodul, IIRC <mwette>guile-freezer probably works if you don't use the `-b' (include system files) option; but yes, it's a WIP <old>graywolf: do: (set! foo foo) <old>that will prevent inlining <old>I'm thinking of adding some way to specify information do the compiler <old>such information would be preventing of inline <old>you can also change the optimization level of the REPL: ,option optimization-level 1 <old>that should prevent inlining when compiling file in the REPL <old>but you also might want to tweak the optimization level of auto-compilation <rlb>Be nice if there was a good/appropriate type/annotation/etc. related srfi that might interleave (I think you might have been suggesting that?). <rlb>(I haven't looked at the related srfi(s) myself.) <old>yes. I would like something akin to what common lisp has <rlb>(There's I think a pr up wrt a typing-related srfi, but I know nothing about that srfi yet.) <old>eeh really a shame we can't tag people on Codeberg that are not part of the discussion already <old>would be actually a good thing to be able to tag someone so they cna be include in a discussion <identity>old: can you really not tag them or is there just no auto-completion for that? <identity>i think Codeberg does not do auto-completion for tagging not-immediately-relevant accounts/teams <old>well I just tried. will see if the person I want to ping will answer <old>the link does work in the comment, so logically it should have ping them also <rlb>I suspect it will, but you're welcome to test it on me later if that's inconclusive. <old>rlb: you are in the team Guile so I can always tag you <rlb>oh (definitely don't know forgejo very well atm)