IRC channel logs

<rlb>Any ideas why current guile main on freebsd wouldn't produce an exception when asked to output utf-8 (non-ascii) to a port test as ascii with 'error conversion?

<rlb>I should look at the recent history too I suppose.

<rlb>dsmith: happen to recall what version of freebsd you were testing?

<rlb>dsmith: nvm, it's working now --- after a reconfigure and make again.

<rlb>I'm toying with a script to build and/or test guile from scratch on a freebsd system (for now via cloud-init from one of their cloud images), so it shouldn't be too hard to figure out what was missing.

<tohoyn>sneek: botsnack

<sneek>:)

<tohoyn>daviid: Should the $ be omitted in the arguments of getenv in examples/adw-1/demo/xdg-vars.scm?

<dsmith>rlb, Version 14.3-RELEASE

<mwette>old: I saw guix issue #8985 on slowness issues from syntax processing. As a workaround, I wonder if setting initial heap from command line or env var would help. It seems in libguile/gc.c that the initial heap size is hardcoded (see DEFAULT_INITIAL_HEAP_SIZE). WDYT?

<old>mwette: In my reproducer, I am now loading gnu/packages/linux.scm with a dummy read-syntax + macroexpand loop. Doing it 100 time, gc profiling I get: Total time: 146.791819404 seconds (80.642178877 seconds in GC)

<old>with GC_INITIAL_HEAP_SIZE=1G I get: Total time: 72.231254126 seconds (6.720304505 seconds in GC)

<old>So yes it helps. But we can't assume users will be setting GC_INITIAL_HEAP_SIZE

<old>But I think it might be a good idea to add a recomentation to the manual? At least until we have whippet but I assume it will have something similar

<old>Usually, bumping GC_INITIAL_HEAP_SIZE results in faster boot time of Guile for scripts also

<mwette>old: I agree. It does not solve the issue, but for peeps with memory to spare it would be nice option to have. Priority should be on solving the issue, for sure.

<old>tbh I don't understand why we could not bump at least the initial heap size a little by default

<old>it's virtual memory. It's free under Linux

<old>But hm, this is a libgc things so I don't know if we can make a call from Guile to libgc to set the initial heap size ourself

<old>hopefuly libgc is only doing a mmap(2) syscall and not writting the whole heap when allocating it ..

<mwette>line 467 in gc.c

<old>jesus 2Mb

<mwette>IIRC 1/4 MiB is crossover point for using mmap (could be for malloc or for libgc -- my memory fails here).

<old>it's a tunnable but yes

<sneek>tohoyn: Greetings :)

<tohoyn>I have improved the guile VSCode support, see <https://www.iki.fi/tohoyn/guile-vscode/>.

<tohoyn>If you use VSCode package strict-paredit-guile-vscode you should upgrade it to version 1.0.3.

<old>mwette: I checked with strace and yes it's a mmap call

<old>but it's less than 2MB

<old>mwette: Tweaking GC_FREE_SPACE_DIVISOR seems to help also

<mwette>cool. thanks for the reproducer

<civodul>tohoyn: nice! are you aware of https://codeberg.org/tsyesika/vscode-guile-scheme-enhanced ?

<tohoyn>civodul: I'll check it.

<old>Setting: GC_FREE_SPACE_DIVISOR=1

<old>Total time: 99.699013514 seconds (33.46879298 seconds in GC)

<old>that's a huge gain there hm

<identity>old: «[virtual memory is] free under Linux» assuming ¬vm.overcommit_memory=2, which is what some people set it to

<old>it's safe to assume overcommit

<identity>no, it is not

<old>yes it is

<identity>guess you know better than me :/

<rlb>If that minimum was set "a long time ago", seems reasonable to ask whether that's what it should be now...

<old>identity: if you set overcommit to 2, you want a system that can offer strong guarantees and reduce the chance for the OOM to kill your system. Things like database

<old>I don't this apply to a GC managed langauge like Guile, Go or Java. But I might be wrong

<identity>what if you want *both* of those things? why cannot the GC try to free up memory on allocation failure (by e.g. signaling an &implementation-restriction condition, thus unwinding and freeing up memory), instead of getting blasted?

<old>it could if you have emergency memory avaiable I suppose. The thing is most system are not robust to failed memory allocation. Serious applications like databe are, but usually if the allocations fail, just kill the app, which is what would had have if you have deferenced the overcommit memory

<identity>the problem with overcommit is that you cannot actually handle allocation failure when you want to, because you cannot easily know if the non-NULL pointer you got from malloc points to accessible memory. allocating 2GB on startup (like some runtimes do), most of which the program is unlikely to use, is just sloppy

<identity>really, some systems are not robust period. this should not prevent other systems, especially those building on them, from being robust

<dsmith>sneek, botsnack

<sneek>:)

IRC channel logs

2026-06-01.log