IRC channel logs


back to list of logs

<mark_weaver>there are many things that could be happening here. I told you what I need if you want my help.
<mark_weaver>a huge complex pile of code that doesn't work is not something I'm willing to look at, sorry.
<mark_weaver>if after-gc-hook is not getting called, then maybe that's because the GC doesn't realize how much memory has been allocated. this can happen, for example, if you have a large amount of memory allocated outside of libgc (e.g. malloc) that's being kept alive by a much smaller amount of GC-allocated memory.
<mark_weaver>the scenario here is that you arrange for the large blocks allocated outside of libgc (e.g. malloc) to be freed by a finalizer on the much smaller libgc-allocated block.
<mark_weaver>ideally, such blocks would be allocated using scm_gc_malloc, but if that's not feasible for some reason (e.g. you don't control the code that does the allocation), then see scm_gc_register_allocation..
<mark_weaver>of course, there are many other possibilities, e.g. you are corrupting some memory somewhere, or otherwise violating a contract.
<mark_weaver>please_help: ^^
<mark_weaver>or, if it *is* a bug in guile, then I need either a minimal self-contained example that demonstrates the problem, or else the results of "git bisect".
***dje is now known as dje42
***christop1 is now known as christoph_debian
<amz3>héllo :)
<mthl>Does anyone know if static functions in C can cause problem if registered with 'scm_c_define_gsubr' and then called from scheme?
<amz3>are embedding guile?
<mthl>amz3: sorry i miss your answer
<mthl>if embedding guile means using scm_boot_guile, yeah it's what I'm doing.
<mthl>(info "(guile-2) Linking Guile into Programs") gives me an implicit answer
<mthl>Sorry for the noise
<daviid>rotty: fyi, i see g-wrap 1.9.15 landed in debian testing, but it seems its guile-library dependency hasn't been updated to 0.2.2 [it still refers to 0.1.1]
<rlb>I've been tracking down some problems with Debian 2.0.11-9 on armel with gcc 5, and I may have figured out a workaround, but I though I'd ask if there are any known issues there?
<rlb>(I think the original build problem was being caused by debian/rules bugs that prevented the addition of -O2 - in which case it fails with a compiler offset error. I've fixed that and am working on some test issues.)
<civodul>rlb: i think we always build with -O2; building with -O0 used to cause problems
<rlb>Right, I'm seeing other issues with -O2 now - tracking them down. Need to get this fixed - otherwise guile will be the only thing holding the old compiler(s) in Debian.
<rlb>I suspect the "other issues" might be related to Debian's default (armel) build flags.
<rlb>We'll see. Each test cycle takes quite a while on ARM.
<rlb>(Would still be slow on x86, but not as slow.)
<rlb>civodul: and hi! ;>
<civodul>hey, rlb :-)
<civodul>2.0.11 builds fine for us on armhf (armv7)
<civodul>ah but that's with 4.9
<rlb>right, and the issue is on armel, armhf is fine
<rlb>Though I wonder what's going to happen when I switch all the archs over to the correct build flags...
<civodul>ah sorry
<rlb>np - the bit I'm investigating now might be broken on armhf too for all I know. But the current debs build fine on armhf.
<rlb>Debian adds various flags by default (cf. dpkg-buildflags)
<rlb>but the current debs don't use that (yet)
<rlb>CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
<rlb>for example, on armel
<rlb>OK, so a clean tree build with dpkg-buildflags was fine (passed all tests but the version.test). Must be something else about the Debian changes.
<rlb>(or the build process)
<rlb>wonder if fakeroot might be a problem for any of the tests on armel...
<rlb>ACTION reviews debian/patches/