Re: [PATCH] Test for weak pairs in hash-for-each
David Thompson dthomps...@worcester.edu writes: * libguile/hashtab.c (hash-for-each): Test for deleted weak pairs. Instead of (hash-for-each), it should be (scm_internal_hash_for_each_handle). I went ahead and pushed it, with that change. Thanks! Mark
Re: Memory accounting in libgc
Andy Wingo wi...@pobox.com writes: How does this affect libgc? First of all, it gives an answer to the question of how much memory does an object use -- simply stop the world, mark the heap in two parts (the first time ignoring the object in question, the second time starting from the object), and subtract the live heap size of the former from the latter. Libgc could do this without too much problem, it seems to me, on objects of any kind. It would be a little extra code but it could be useful. Or not? Dunno. This could be generalized to the far more useful question: How much memory does this set of objects use?, although that's a slippery question that might better be formulated as How much memory would be freed if this set of objects were no longer needed?. For example, suppose you have a large data structure that is referenced from two small header objects, A and B. If you ask How much memory does A use?, the answer will be the size of the small header, and ditto for B. Without being able to ask the more general question, there's no way to find out how much would be freed by releasing both. Mark
Re: Memory accounting in libgc
On 03/12/14 08:57, Mark H Weaver wrote: Andy Wingo wi...@pobox.com writes: How does this affect libgc? First of all, it gives an answer to the question of how much memory does an object use -- simply stop the world, mark the heap in two parts (the first time ignoring the object in question, the second time starting from the object), and subtract the live heap size of the former from the latter. Libgc could do this without too much problem, it seems to me, on objects of any kind. It would be a little extra code but it could be useful. Or not? Dunno. This could be generalized to the far more useful question: How much memory does this set of objects use?, although that's a slippery question that might better be formulated as How much memory would be freed if this set of objects were no longer needed?. For example, suppose you have a large data structure that is referenced from two small header objects, A and B. If you ask How much memory does A use?, the answer will be the size of the small header, and ditto for B. Without being able to ask the more general question, there's no way to find out how much would be freed by releasing both. Mark Agreed. In order to build industrial-strength applications in guile, it's important to be able to answer questions such as what is causing my process' memory usage to grow? -- Andrew Gaylard
Re: [Hydra Build Daemon] [Guile-commits] Failed with output: Hydra job gnu:guile-2-0:build.x86_64-darwin
Mark H Weaver m...@netris.org skribis: The Darwin build was broken by 8f7887d61604073528544ccb09849ca0e2f4df78 Provide glthread/lock.h implementation in terms of Guile threads. I guess that we'll need to add some of the AM_CPPFLAGS from libguile/Makefile.am to lib/Makefile.am. We'll need to make sure not only that glthread/lock.h finds libguile/threads.h from the source tree (not from previously-installed Guile headers), Oops, thanks for the heads-up. The problem manifests when $top_srcdir != $top_builddir, as is the case on Hydra. but also that all of the Guile headers included directly or indirectly from libguile/threads.h have access to the Gnulib headers. I believe commit da7e43a fixes it. I confess to being a bit nervous about this circular dependency between Guile and Gnulib. Yeah. Another thing we could do is to AC_DEFINE([SCM_GNULIB_LOCK_PTHREAD]) when building with pthread support, and have glthread/lock.h not include libguile/threads.h at all. WDYT? Ludo’.
Re: [PATCH] Test for weak pairs in hash-for-each
On Wed, Mar 12, 2014 at 2:45 AM, Mark H Weaver m...@netris.org wrote: David Thompson dthomps...@worcester.edu writes: * libguile/hashtab.c (hash-for-each): Test for deleted weak pairs. Instead of (hash-for-each), it should be (scm_internal_hash_for_each_handle). I went ahead and pushed it, with that change. Thanks! Mark Ah, sorry. I always mess up something like that. Thanks for taking care of it. - Dave
Problem with removing config.h from gen-scmconfig when cross-compiling
Hi Ludovic, Commit 8cb0d6d7fa9aaac316c29a64c541336b51b6f93d build: Don't include config.h in native programs when cross-compiling. apparently broke cross-compiling. Madsy on #guile, who successfully cross-compiled e1bb79f for mingw, ran into this problem with 21a7ba9: --8---cut here---start-8--- make[1]: Entering directory `/home/madsy/mingw/home/madsy/test/guile-2.0.9.f239-21a7b-dirty/libguile' GEN gen-scmconfig.o gen-scmconfig.c: In function 'main': gen-scmconfig.c:245:39: error: 'SIZEOF_CHAR' undeclared (first use in this function) gen-scmconfig.c:245:39: note: each undeclared identifier is reported only once for each function it appears in gen-scmconfig.c:246:48: error: 'SIZEOF_UNSIGNED_CHAR' undeclared (first use in this function) gen-scmconfig.c:247:40: error: 'SIZEOF_SHORT' undeclared (first use in this function) gen-scmconfig.c:248:49: error: 'SIZEOF_UNSIGNED_SHORT' undeclared (first use in this function) gen-scmconfig.c:249:39: error: 'SIZEOF_LONG' undeclared (first use in this function) gen-scmconfig.c:250:48: error: 'SIZEOF_UNSIGNED_LONG' undeclared (first use in this function) gen-scmconfig.c:251:38: error: 'SIZEOF_INT' undeclared (first use in this function) gen-scmconfig.c:252:47: error: 'SIZEOF_UNSIGNED_INT' undeclared (first use in this function) gen-scmconfig.c:253:41: error: 'SIZEOF_SIZE_T' undeclared (first use in this function) gen-scmconfig.c:258:44: error: 'SIZEOF_LONG_LONG' undeclared (first use in this function) gen-scmconfig.c:259:53: error: 'SIZEOF_UNSIGNED_LONG_LONG' undeclared (first use in this function) gen-scmconfig.c:275:43: error: 'SIZEOF_INTMAX_T' undeclared (first use in this function) gen-scmconfig.c:279:43: error: 'SIZEOF___INT64' undeclared (first use in this function) gen-scmconfig.c:296:50: error: 'SIZEOF_PTRDIFF_T' undeclared (first use in this function) gen-scmconfig.c:300:43: error: 'SIZEOF_INTPTR_T' undeclared (first use in this function) gen-scmconfig.c:302:44: error: 'SIZEOF_UINTPTR_T' undeclared (first use in this function) make[1]: *** [gen-scmconfig.o] Error 1 make[1]: Leaving directory `/home/madsy/mingw/home/madsy/test/guile-2.0.9.239-21a7b-dirty/libguile' make: *** [libguile/scmconfig.h] Error 2 --8---cut here---end---8--- Mark
