IRC channel logs
2013-11-24.log
back to list of logs
<civodul>i hear expandable stacks have landed already? <wingo>reduces base memory usage significantly <wingo>and it lets us recurse in our algorithms to our heart's content <wingo>initial size is 1024 words -- so 4KB or 8 KB <wingo>and the default size at which an error is thrown is 256M words <civodul>we must be doing good at the "guile --version" benchmark ;-) <wingo>civodul: it actually doesn't affect startup time too much <wingo>also each time an error is thrown the stack limit is increased by 256K words <wingo>a stack overflow error i mean <wingo>up to a hard limit that is much larger <civodul>where it would sometimes fail to display the error message <wingo>actually 256M might be the hard limit, i don't recall <wingo>ok hard limit is 512M words, default soft limit is 1M words <wingo>you can set the soft limit with the GUILE_STACK_SIZE env var <wingo>that's the only way, currently <wingo>we should have something better, eventually *wingo just found out about the mremap call a couple days ago; neat <civodul>it'd be nice if we could set per-thread stack limits <civodul>so you could run untrusted code in a thread with a small stack, say <wingo>so we can switch the map implementation to remove the "reverse" call, and just implement map recursively... <wingo>the limit is a per-thread thing, we just need to expose the right knobs <civodul>wingo: you mean we can implement things non-tail-recursively <civodul>and yeah, the effect is the same as having an accumulator <wingo>and it "just works" regarding captured continuation <civodul>but the stacks never shrinks, does it? <wingo>you probably recall all that, capturing continuations in mapped procedures... <wingo>i want to record the max stack height <wingo>and then in gc madvise MADV_DONTNEED the pages between the current sp and the max stack height <wingo>which would be neat, to be able to make algorithms that use space then return it to the os <wingo>you could munmap them and lower the stack size again <civodul>but you may get the same effect with MADV_DONTNEED actually <civodul>i mean, if it's really unneeded, then it's as if it were unmapped <civodul>it doesn't use any physical memory etc. <wingo>yes, except that it is mapped, so there are some associated kernel data structures <wingo>it's mapped but has no backing store at that point <wingo>so no associated physical memory, as you say <wingo>and the next time it is paged in it comes as all zeroes <civodul>in RTL VM, what's the cost of a tail call compared to that of a call? <wingo>civodul: they are pretty much the same <wingo>both have to shuffle the proc and args into place, then execute one opcode to do the call <wingo>with a non-tail call you then have to receive the return values, which you don't with a tail call <mark_weaver>wingo: I don't think we can change 'map' to use recursion until the stack size has no soft or hard limit. <mark_weaver>still, I'm *very* glad to see these changes. now I can deuglify my SCC implementation :) <shanecelis>I'm having trouble getting anything out of source-properties but '(). <stis>(define-syntax f (lambda (x) (pk (source-properties (syntax->datum x))) #f)) <stis>scheme@(guile-user)> (f 12 10) <stis>;;; (((line . 17) (column . 0) (filename . #f))) <civodul>you could even do (syntax-source x) here <stis>(define-syntax f (lambda (x) (pk (syntax-source x)) #f))scheme@(guile-user)> (f 12 10) <stis>;;; (((line . 22) (column . 0) (filename . #f))) <mark_weaver>civodul: SCC == Strongly Connected Components. I have an efficient implementation of Tarjan's algorithm, but I had to make the code rather ugly to avoid using unbounded stack space. <shanecelis>hmm... so source-properties are used on source objects. Hmm... I was hoping that I could just determine the file and location of any given procedure. I assume that's stored somewhere since it's recovered in backtraces. <civodul>shanecelis: for instance, this works: (source-properties (call-with-input-string "(a b)" read)) <civodul>but in general, it only works on objects returned by 'read', when the corresponding read-option is enabled <civodul>macros should instead use 'syntax-source', as discussed before <civodul>and then <program> objects (for compiled code) have associated line source information <c107>Is there a difference between 'object code' and 'binary code'? <c107>Can a binary be made from Scheme code? <ijp>c107: I wouldn't rely on those modules, the architecture had changed quite a bit with the new vm <ijp>objcode is basically what gets written out to a .go <ijp>so in that sense, a .go is a binary file <ijp>but it is not directly executable <ijp>does that answer your question? <c107>ijp: I was afraid that programs written in Scheme could not be directly executable.