***catonano_ is now known as catonano
***wxie1 is now known as wxie
***wxie1 is now known as wxie
<roelj>I have a Guile program that has been running for a week, and upon inspecting the memory allocations with pmap and gdb, I found that most memory regions are simple zeroed chunks. Is this something the garbage collector allocated and doesn't give back to the system? <roelj>No. It's stable. But when I stress-test it, the memory expands (it's supposed to do that, since it then spawns more threads), and it never contracts afterwards. <civodul>is it the resident set size that expands? <civodul>i think the GC can increase its working set and not return things to the OS <civodul>so if you have a peak, resident size will go down afterwards, but virtual memory size may not <roelj>Yes it's the resident size that expands. <roelj>virt and shared seem stable. That makes sense because it doesn't load any new libraries, and it doesn't mmap files. <roelj>Hm, so what could be going on in my case then? <civodul>the way i'd debug it is by looking for a stress-test pattern that makes memory usage grow <civodul>also, while it's in theory okay to leave ports open, it's much better when you explicitly close it <civodul>because they have a lot of memory attached to them, like iconv descriptors <wingo>i think by default, bdw-gc will never give pages back to the system <civodul>yeah so virtual size can only increase <roelj>Can I see a list of open ports? In /etc/<PID>/fd there's not much. <civodul>it could be string ports etc. though <wingo>looking at the defines, i think libgc needs to be built with USE_UNMAP <wingo>there are also some run-time knobs but you need to check that compile-time setting first <roelj>civodul: Grepping for "(open" I found only one code path and there I explicitly close the string port. All other interfaces (like "call-with-..." should automatically close, right? <wingo>see README.macros in bdw-gc for info on USE_UNMAP, and also see GC_UNMAP_THRESHOLD and GC_FORCE_UNMAP_ON_GCOLLECT <wingo>those latter two are environment variables <civodul>would be interesting to build it with USE_UNMAP and see <wingo>yeah i've never tested it that way <civodul>roelj: open ports are just a possibility, but really i'd suggest finding a pattern that triggers the issue <roelj>civodul: Sure. I just don't think there's a leak in the program, because as long as I don't create a peak bigger than the previous stress-test's peak, the memory doesn't grow. <roelj>Would the environment variable GC_FORCE_UNMAP_ON_GCOLLECT have any effect on the Guile compiled with Guix? <civodul>libgc in Guix is not compiled with USE_UNMAP, so you would first need to define a libgc variant that does that <tohoyn>lloda: did you receive my email about the public GPG key of guile-cairo? <ane>when writing extensions in C, what's the best approach for making wrapper interfaces for the C stuff on Scheme side? <ane>what I'm planning on doing is that the C side will define rather crude procedures and I'd like to avoid writing too much C and then "refine" the outputs on Scheme side <ane>to this end, I'm thinking of something like scm_c_define_module("foobar internal") from C code and then in Scheme do something like (define-module (foobar)) ... (load-extension "foobar" "init_foobar_internal") and then re-export those things that don't need to be "wrapped" <ane>but I'm confused of how this would look like <ane>what's the correct order here? 1. define-module foobar 2. load extension 3. re export things from the extension <ane>so are steps 2 and 3 just about like this (load-extension ...) (use-modules (foobar internal)) (export (foobar-nice)) <ane>is the last export even needed? can't I do that in the define-module using #:re-export <leoprikler>ane: you typically shouldn't do define_module from C unless you know what you're doing <ane>hm, reading the manual, it's suggesting I don't scm_c_define_module <ane>and just load the extension on scheme side into the current module <ane>and if I have multiple "modules" on C side <ane>I can just have multiple init functions <leoprikler>If you are able to, you might also evade the C side completely. <leoprikler>The problem with it however is, that it only really works well for functions and some struct types. <leoprikler>If you have something fancier than that, you might still need your extension. <ane>yeah, I had a look at that <ane>but I find it easier to work with it directly from C, since this would be distributed alongside the C library itsef <ane>so the same make install installs both <leoprikler>Okay, in that case [optionally] linking against libguile does make sense. ***hugh_marera_ is now known as hugh_marera
<mwette>ane: I do this: (define-module (foo) #:export (bar)) (load-extension "baz" "init_baz") where "baz" provides define for "bar") <mwette>ane: and my code uses (eval-when (expand load eval) (load-extension )) though I don't remember why I have that <leoprikler>probably because you need (eval-when ... (load-extension)) for byte-compilation <dsmith-work>ane: Yes, it's typical to provide a thin scheme module that just loads the .so and then exports things. <dsmith-work>Pretty sure it's no longer possible to direcly load a .so as a module. <lampilelo>i have a problem compiling gnutls for guile-3.0, it errors out on the bootstrap script saying there's incompatible bytecode kind (while trying to load eval.go from guile 3), does anyone know how to debug it? something clearly is using guile 2.2 and doesn't like my guile 3 files and i don't know what it is <lampilelo>there are some .go files in the boringssl submodule, maybe that's it? <lampilelo>ok, i ran the script with guile 3 specific environment turned off and it worked, i hope it won't affect compilation with guile 3 <lampilelo>these .go files aren't guile files, so that's not it <lloda>I have to check tohoyn. I'll get back to you in a couple hours <dsmith-work>lampilelo: Often strace is helpful when debuggging which files are being opened from where. <dsmith-work>lampilelo: So you have both 2.2 and 3.0 installed? From packages or from source? Do you have *-dev packages installed? <dsmith-work>Ok. Do you have the 2.2 -dev package installed? Remove that. I'm guessing when conpiling/configuring gnutls it's finding the 2.2 dev stuff first. <lampilelo>the problem seems to be autogen that is trying to use guile 2.2 and segfaulting in the process when it tries to load guile 3 files <lampilelo>#if (GUILE_VERSION >= 200000) && (GUILE_VERSION <= 200003) <lampilelo># error AutoGen does not work with this version of Guile <lampilelo>autogen did compile fine and gnutls compilation doesn't seem to segfault anymore <lampilelo>my distro has a wildly out of date version of autogen <lampilelo>the package manager points to an old autogen website and the version from there is the version arch has, even though the development is still happening on savannah <lampilelo>sure, the older version worked fine with their toolchain <lampilelo>maybe next time i won't have to remember to use manually compiled version <lloda>tohoyn: i haven't received any message. That email used to be my main account but i changed isp and now i only get some 'free' tier service on it and it barely works. Could you resend to lloda at member fsf org instead? <tohoyn>lloda: "gpg --import" does not work for the key you sent <lloda>hmm. I used gpg --export-ssh-key key! <tohoyn>lloda: try gpg --export --armor key