<UltimateNickFury>ijp, so I'm trying guile now, have to say it's indeed quicker than racket as far as shell scripts go but it seems to compile them what racket doesn't <UltimateNickFury>Is there also a way to stop guile's #! ... !# block comments? Because it requires a !# at the end of the shebang now which other implementations complain about <ijp>UltimateNickFury: you could try doing ;!# <UltimateNickFury>ijp, also, guile seems to recognise #!r6rs and not turn it into a block comment by the way <ijp>yes, it treats the whole thing as one token <ijp>there are a couple of those, like #!fold-case or #!curly-infix ***zzach is now known as leoe
<davexunit>ijp: so I need to keep my signal outputs as weak references. so I guess I need a weak vector, but the problem with vectors is that they don't dynamically resize. <ijp>usual hash table as a set trick <mark_weaver>or you could just reuse vector elements that have been freed. <dje42>Will Guile ever make incompatible changes to scm_t_port? [I'm guessing not, but am not 100% sure.] ***UltimateNickFury is now known as UltimateEyePatch
<linas>aieee Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS <linas>after about 12 hours of guile'ing <linas>21 GB RSS (on a 76GB machine, not all of it is guile; probably most of it isn't) -- this si guile-2.0.9 <linas>build from source .. maybe I need to build bdwgc too, and increase these ... <linas>./configure --with-large-heap=yes is what stackoverflow says .. I'll try that ... <linas>Hmm .. except the system shouldn't be using that much RAM, anyways, Hmm ... something else is wrong ... <linas>exact same binary, different dataset, is just 7GB <mark_weaver>if you're using the old 7.1 from debian wheezy, I'd recommend upgrading to 7.2d. ***ijp is now known as ijp2
***ijp2 is now known as ijp