<madsy>Hm.. according to valgrind, guile 2.0.10 is leaking memory <mark_weaver>how does it decide that there's a leak? how can it know? ***brendyyn is now known as brendyn
*wingo writing out-of-memory tests and fixing various bugs <madsy>wingo: Any chance 2.0.10 leaks memory? valgrind thinks so. <davexunit>is it just me or does guile 2.0.11 still print 2.0.10 when the REPL is started? <mark_weaver>madsy: you never answered my question before. how does valgrind decide that we leak memory? <mark_weaver>I suspect that somehow the shared library from 2.0.10 is being used. <madsy>mark_weaver: I don't know the internals. But it does more than just tracking malloc/free for sure <mark_weaver>one issue is that our pointers do not always point to the beginning of the allocated memory block. <mark_weaver>anyway, I think that guile does have at least one leak, but apparently it's quite slow. <madsy>mark_weaver: Well, it differentiates between different kinds of leaked memory with differing accuracy. <madsy>mark_weaver: I only take "definitely lost" into account, which does not look at the kind of pointers you just described. <madsy>Pointers pointing in the middle of a block would show up in the "possibly lost" statistics, and should be taken with a grain of salt. <madsy>And that statistic shows 0 bytes lost anyway <mark_weaver>which statistic(s) are non-zero, and what are their values? <mark_weaver>is the amount of leaked memory bounded, or does it increase with the amount of work you did with guile? <madsy>Only "definitely lost" is worth inspecting. The rest is likely to be false alarms <madsy>It seems to be bounded, but let me double check <mark_weaver>is there a way to view the contents of the 'definitely lost' blocks? <madsy>I don't think you can inspect the contents, but I could run valgrind with more verbose input to see what it complains about. It does use debugging info <madsy>Like, which function or source file <mark_weaver>oh, if it can show us the code that allocated those 'definitely lost' blocks, that would be swell. <madsy>Yeah it seems to be bounded and always less than 10 KiB <madsy>So if there is a leak, it's harmless <mark_weaver>well, I think that's a very low priority item then :) <madsy>But since it changes between invocations I have to disable guile when checking my own code for leaks <mark_weaver>also, I wonder what happens with GC-allocated blocks that are no longer reachable, but just haven't been GC'd yet, when the program exits. <mark_weaver>If I had to make a guess, I'd that guess valgrind probably sees only the big blocks that libgc allocates. *wingo just made guile throw out-of-memory on allocation failures <madsy>mark_weaver: My bad. The offending library is libglew :) <madsy>And it seeems to be deep in driver land <madsy>I use it to create an OpenGL window and context <madsy>When libguile runs alone, only 704 bytes shows up in "possibly" lost, which is just a false alarm. Evertyhing else is 0 <madsy>So the GC seems to do a better job than I do manually <wingo>lloda: around? care to give master's test-suite another test? <didi>OK, I'm terrible with regexps. But shouldn't (string-match "a.+?" "abbb") match "ab"? <mark_weaver>didi: currently, guile's core regexps are just POSIX regexps, where the non-greedy syntax is not supported. <mark_weaver>didi: we plan to add SRFI-115 when it's finalized, which will be much nicer. <ijp>I haven't kept up with the new srfis, is 115 just irregex? <mark_weaver>in the meantime, if you want nicer regexps, I would recommend irregex, which is close to SRFI-115. <ijp>I suppose that answers it <ijp>psychic conversation on #guile <didi>mark_weaver: oic. Well, according to the manual: "By default, Guile supports POSIX extended regular expressions. That means that the characters ‘(’, ‘)’, ‘+’ and ‘?’ are special, and must be escaped if you wish to match the literal characters." <didi>Not that anybody should care, but I already doubt myself any time I write regexps. This doesn't help. <mark_weaver>didi: that's right. but the '+?' is not being interpreted as a single operator (non-greedy +), but rather as two separate operators. + is greedy, and then ? means that the '.+' is optional. <mark_weaver>well, there are a lot of different variants of regexps, which doesn't help. <mark_weaver>speaking of SRFI-115, I wonder what's up with that. its draft period was supposed to end on Dec 12, and the last post to the mailing list was on Dec 13. Nothing since then. <mark_weaver>it's as though Alex just got distracted with other things. <madsy>If I define a module in a .scm file, do I still have to load it with (load ..) ? <madsy>Or is it enough to make sure that the scm file is reachable in the load path? <didi>mark_weaver: Oh, OK. The manual should more explicit then. It points to the Emacs manual, where +? is a non-greedy variant. <ijp>so, I went on qdb.us to find a good quote about psychics and irc....I have now spent 20 minutes on the site just reading <taylanub>didi: You might have luck with "man regex" on your system for explanations of POSIX BRE and ERE <taylanub>They are also what sed, grep, and AWK support per POSIX. (sed BRE, grep configurable, AWK ERE) <ijp>good thing we have all these different regex varieties <didi>And point to different sources. <ijp>it would be terrible to write a regex and have it actually work first time <taylanub>I sometimes think POSIX ERE ought to be enough for everyone but that could be because I never learned Perl RE. <taylanub>Uh, could it be that SRFI-115 is thinking that PCRE stands for POSIX Compatible RE and not Perl Compatible RE ? "How to integrate with the PCRE regular expression library? The intention is to make this the primitive notation, and for POSIX require a separate wrapper such as (pcre->sre <str>)." <taylanub>I'm probably misinterpreting or misunderstanding it; the References list "PCRE - Perl Compatible Regular Expressions". <mark_weaver>didi: I agree that the link to the emacs manual is misleading, and something should be done there. <mark_weaver>but more generally, I really dislike our current regexp API, so I'll be glad when we replace it with something much better. <didi>mark_weaver: I would gladly help you with that. In the mean time, a manual edit is necessary IMO. <madsy>When I've defined a module with define-module in a file, how do I get (use-module) to find it? Do I have to load it *and* use (use-module) ? <mark_weaver>madsy: no, if it's a module, then just 'use-module'. <madsy>I thought I had to add the path to #library-path or %load-path, but it didn't make a difference <mark_weaver>when you (use-module (foo bar baz)) it looks in <DIR>/foo/bar/baz.scm, where <DIR> is a component of the load path. <mark_weaver>the load path being in %load-path, which is initialized based on built-in stuff plus GUILE_LOAD_PATH <madsy>I didn't know the name had path semantics. Thanks <mark_weaver>also see %load-compiled-path and GUILE_LOAD_COMPILED_PATH <madsy>Ok, so I added /some/long/path/modules to %load-path and %load-compiled-path, and my module is at /some/long/path/modules/lambda-demo/opengl.scm <madsy>(use-modules (lambda-demo opengl)) still doesn't find it <madsy>Should my (define-module) call in opengl.scm be (define-module (lambda-demo opengl)) or just (define-module (opengl)) ? <mark_weaver>if you tried to load it once, and it failed, it might have cached the failure somehow, dunno. <madsy>Maybe it ignores the module include because I have defined an internal module in C with the same name? <mark_weaver>it only tries to autoload it in the module doesn't yet exist. <mark_weaver>the way this is normally handled is that the scheme module calls a C procedure that adds the C-level bindings to the modue. <madsy>Great, I just changed the name. Now it works <madsy>So Guile's module system isn't very unlike Clojure's and Java's *mark_weaver goes afk for a while <ijp>madsy: by and large there are only really three kinds of module system: none, normal, and ML <madsy>When I try to compile some code which uses a macro in my module, I get an error from guile, saying that the module contains no code. How do I resolve that? <artyom-poptsov>madsy: How do you compile the code? I mean, how do you call the compiler? <madsy>artyom-poptsov: With geiser. compile-buffer. C-c- C-k <madsy>artyom-poptsov: And my module has a single macro, no functions <zacts>I need to learn geiser. currently I only use a scheme buffer, a scratch scheme buffer, and a repl. <artyom-poptsov>madsy: I guess you should somehow tell the compiler path to directory with your module. <madsy>artyom-poptsov: Geiser has the load path. That's not the problem <tupi>madsy: try ... (eval-when (compile load eval) your macro defs here) ... <madsy>No difference. boot-9 still throws <tupi>i am not sure i understand what you do. could you paste a short example? <madsy>That module lives under %load-path / lambda-demo/opengl/enums.scm <madsy>And I'm loading it with (use-modules (lambda-demo opengl enums)) <madsy>That gives me: ice-9/boot-9.scm:106:20: In procedure #<procedure 3c70400 at ice-9/boot-9.scm:97:6 (thrown-k . args)>: <madsy>ice-9/boot-9.scm:106:20: no code for module (lambda-demo opengl enums) <madsy>But I did set %load-path properly in Geiser. I even modified load-path and load-compiled-path in the code before calling (use-modules) <tupi>that cn only be true if the parent directory of lambda-demo/opengl is _not_ in %load-path <madsy>Geiser has "add to load path.." Which is C-c C-e C-l. I've added the directory twice <tupi>also you name [in the paste] this module "gistfile1.scm" but it must be named enums.scm <tupi>is the case on your machine? <madsy>Yes, the file name is just added by github <artyom-poptsov>madsy: Basically `(lambda-demo opengl enums)' means that the module lives here: %load-path/lambda-demo/opengl/enums.scm <madsy>artyom-poptsov: Indeed. And it does. <madsy>That is, the full path is /home/madsy/Projects2/SchemingDemo/scheme-src/modules/lambda-demo/opengl/enums.scm <madsy>And /home/madsy/Projects2/SchemingDemo/scheme-src/modules/ is in %load-path, and added to Geiser's path <madsy>Maybe "(define-module (lambda-demo opengl enums) ....) is wrong? <madsy>Probably not, since loading it works in the REPL. <ijp>C-c C-e C-l adds the buffers directory <tupi>is this path with the last #/ in %load-path [as you pasted here>] <ijp>sorry, my bad, I misinterpreted the help <ijp>anyway, I'm seeing the same thing <ijp>which is weird, because I modify %load-path in my .guile with no problems <artyom-poptsov>madsy: I think you should try to compile the code by using guild compiler directly, and then compare the results. Try to specify path to your module by passing it with `-L' option to the compiler. <ijp>I stand correct, my problem was pebcak <ijp>madsy: what version of guile are you using? <ijp>I have a vague recollection of a related problem in an earlier version that was fixed <ijp>the problem was if you looked up a module and it failed, and then you fixed it, it was still cached and so always failed <ijp>does that sound similar, or does it happen in a fresh guile too? <madsy>ijp: The last snapshot before 2.0.10 <ijp>that was fixed in 2.0.9 I think <ijp>madsy: does it still fail if you run a fresh guile (with -q), and do (set! %load-path (cons "dir" %load-path)) (use-modules your-module) <tupi>madsy: earlier you said you defined : (define-module (lambda-demo opengl enums) <tupi>but do (use-modules (lambda-demo graphics enums)) <mark_weaver>madsy: I suppose at this point I'd be tempted to attach 'strace' to the guile process and see where it looks when you try to load the module. <madsy>tupi: I change it, because it could conflict with a hardcoded module path <madsy>That is, (lambda-demo opengl) is a module defined in the C interface. So I assume anything with (lambda-demo ..) could be messed up <madsy>I'll try to set the load-path on startup <zacts>what is the proper way to configure guile to build with clang instead of gcc on gnu/linux? <mark_weaver>madsy: it is indeed plausible to me that (lambda-demo opengl) defined from C might be causing this problem. <mark_weaver>there are some wierdnesses in the guile module system that I have yet to learn about. <ijp>I'm not convinced as convinced <ijp>we're not checking that prefixes are guile modules are we? <ijp>madsy: when you changed the path, did you also change the define-module form? <mark_weaver>but I seem to recall that guile modules are hierarchical in the sense that (lambda-demo opengl enums) is looked up by looking up 'lambda-demo' in a root module, and then looking up 'opengl' in the (lambda-demo) module, and then 'enums' in the (lambda-demo opengl) module, or something like that. <ijp>(may as well rule that out) <madsy>mark_weaver: I tried a completely new path now. %load-path/madsy-test/enum.scm. Still complains about no code <mark_weaver>you changed the module name in the 'define-module' form to match? <zacts>mark_weaver: yep, this doesn't seem to be a FreeBSD bug, it's failing with clang on i386 gnu/linux <ijp>madsy: and you tried loading it in a fresh guile instance? <ijp>with -q for good measure <madsy>ijp: I did start my application and passed -L<path> to scm_shell <zacts>mark_weaver: now let me backtrace it on gnu/linux <madsy>Okay.. loading the module works with guile, but not my libguile application <zacts>mark_weaver: nice, I get a much more thorough backtrace on a gnu userland <ijp>";; It used to be, however, that module names were also present in the ;; value namespace. When we enable deprecated code, we preserve this ;; legacy behavior." <ijp>mark_weaver: is that the behaviour you are referring to mark? <mark_weaver>zacts: can you try: make -C libguile clean && make CFLAGS="-O0 -g" <mark_weaver>ijp: not quite. whether the submodules are in the normal value namespace is a separate question. but somehow, the submodules are looked up in their parent modules. *mark_weaver goes afk for a while <mark_weaver>zacts: okay, that's also useful information, plus we get a much more useful backtrace :) <zacts>mark_weaver: what do you think the problem is? <mark_weaver>zacts: I'm reading the relevant code, trying to figure it out. <zacts>ok, thanks. well /me will bbl. I have some schoolwork to do. :-) <mark_weaver>zacts: okay, thanks for the info, this is very helpfull. <mark_weaver>zacts: if you're around, there are some things you could do in gdb that would help me narrow it down. <zacts>what would you like me to try in gdb? <mark_weaver>it should hit the breakpoint. then "p scm_subr_objcode_trampolines[0]" and "p scm_subr_objcode_trampolines[1]" and "p/x *(scm_t_bits *)scm_subr_objcode_trampolines[1]" <zacts>I get: Function "create_gsubr" not defined. <mark_weaver>and then it should ask "Make breakpoint pending on future shared library load? (y or [n])" no? <mark_weaver>also, what number does "p sizeof(scm_t_cell)" print? <zacts>mark_weaver: $5 = (const struct {...} *) 0xb7fb6bb4 <mark_weaver>grump. it's not aligned properly, even though we put a scm_t_uint64 in there for alignment. <mark_weaver>well, okay, I know the problem now, anyway. thanks very much! <zacts>cool! is it a guile problem, or clang? <mark_weaver>I guess that putting in a 64-bit integer in there doesn't guarantee 64-bit alignment on a 32-bit machine, which I guess is plausible. I'll have to look into it. <mark_weaver>I guess that gcc is aligning it on a 64-bit boundary, but clang isn't. *mark_weaver looks at C99 <zacts>keep me updated, I gtg again.. <mark_weaver>both GNU C and C11 allow the alignment of a variable to be specified explicitly. <zacts>hm.. will this be a guile patch? <mark_weaver>okay, we already have a SCM_ALIGNED macro for exactly this, but it wasn't used where it needed to be used. <zacts>mark_weaver: if you can share the patch with me, so that I can include it within the port. <zacts>(unless you are willing to do a shiny new version of guile for this, but I'm assuming not) :-) <mark_weaver>32-bit clang users can suck it up and apply the patch manually. <zacts>oh mark_weaver let me give you my email again in a private /msg <zacts>thanks, you may send me the patch there whenevers. <zacts>yeah, I'll try it out for you <zacts>should I build normally, or with that special make line with -O0? <zacts>ok, I'll let you know if/when the build finishes.