IRC channel logs

2017-11-23.log

back to list of logs

<amz3>héllo all
<ArneBab>hello amz3 ☺
<fraya>hi all
<ArneBab>this is strange …
<ArneBab>(define a (iota 10000000)) (define a (reverse a)) ;; needs 347 MiB memory
<ArneBab>(define a (iota 10000000)) (define a (reverse! a)) ;; needs 180 MiB memory
<ArneBab>shouldn’t the memory of the first a be freed in both cases, maybe with a memory spike while processing?
<lloda>ArneBab: you expect the memory to be freed at once? I wish sometimes that memory were freed as soon as the handle goes out of scope (I allocate big arrays often), but afaiu that's not how it works.
<str1ngs>hello, The autoconf macro will set GUILE and GUILD variables however this is nothing that handles guile-snarf
<str1ngs>for a parallel installation this kinda breaks for me. I need to figure out what guile-snarf to use when snarfing
<mwette>can you use sed to convert?
<str1ngs> I'm thinking I'll have to create a autoconf test. but this is my first autotools project :(
<str1ngs>for example my host system is fedora 27. and it has guile-snarf which is 2.0 and also guile-snarf2.2
<mwette>but then it should have guile2.2 ? so if GUILE is guile2.2 then test for guile-snarf2.2
<str1ngs>that might work for my system. but when I distribute my software, configure needs to use the right snarf for the possible parallel install. actually the snarf tool my be the same across versions even. but I'd rather future proof it.
<mwette>bug if you configure guile w/ --program-suffix=2.2 then guile guild and guile-snarf get installed as guile2.2, guild2.2 and guile-snarf2.2, respectively
<str1ngs>right in which case I can then use. guile-snarf$(GUILE_EFFECTIVE_VERSION)
<str1ngs>but that breaks if guile is not build with --program-suffix
<str1ngs>I guess I could have a test, if GUILD equals guild then check if guile-snarf exists and use that.
<mwette>here it is in a makefile:
<mwette>GUILE=guile20
<mwette>
<mwette>GUILD=$(shell echo $(GUILE) | sed -e s/guile/guile-snarf/)
<mwette>
<mwette>all:
<mwette> echo GUILE=$(GUILE)
<mwette> echo GUILD=$(GUILD)
<mwette>GUILE=guile20
<mwette>
<mwette>SNARF=$(shell echo $(GUILE) | sed -e s/guile/guile-snarf/)
<mwette>
<mwette>all:
<str1ngs>ya, I'll have to create a GUILE_SNARF AM varible I guess. and use configure.ac for setting and testing.
<str1ngs>for now I think I can just assume if GUILD is guild then snarf is guile-snarf
<str1ngs>autotools gives me grey hair :P
<mwette>IMO, you should assume if GUILD is guild$_guile_suffix then GUILE_SNARF is guile-snarf$_guile_suffix
<str1ngs>I did at first but that breaks with no suffix
<mwette>then two tests: one for guild and one for guild$_guile_suffix
<str1ngs>I agree, I just need to figure out how to do this withing configure.ac now
<str1ngs>within*
<str1ngs>I have another issue where I can't have guile-devel and guild22-devel installed but that could be distro specific.
<str1ngs>it there both installed it will find guile 2.2 headers. then then complain /bin/guile is not version 2.2
<str1ngs>mwette I think I can just use AC_PATH_PROG(GUILE_SNARF,guile-snarf2.2
<str1ngs>and then enforce AC_PROGS([2.2])
<str1ngs>this only allow for guile 2.2 though and installed with suffix though.
<str1ngs>but at least it's stable and works. I'll fine tune it before I release it though. which probably wont be for awhile
<wingo>zow
<wingo>so range inference on logand was busted. but somehow this didn't cause a problem because the rest of the type/range inference wasn't precise enough. i added precision in an unrelated area, triggering the bad logand inference bug
<wingo>ultimately causing negative fixnum constants to miscompile
<wingo>but there are so few of those in the compiler that it would take a compiled and optimized compiler to exhibit the bug
<wingo>f.m.l.
<str1ngs>inc point release fix? :P
<ArneBab>lloda: even triggering ,gc did not free the memory
<ArneBab>lloda: I had expected that I have to run ,gc, but that didn’t suffice
<mwette>ACTION is thrashing nyacc git repo, c99dev branch, to test OS ports
<janneke>mwette: about an hour ago i hit a major milestone with c99dev branch :-)
<janneke>here's a bootstrap dependency diagram in svg: http://paste.debian.net/997274/