IRC channel logs


back to list of logs

<Formbi>why isn't the default map tail-recursive?
<civodul>Formbi: mostly because it's unnecessary with expansible stacks
<civodul>they achieve the same thing as having an explicit accumulator
<civodul>the downside is that backtraces with 'map1' are a bit ugly
<Formbi>doesn't it use more memory?
<chrislck>more memory in the stack, less memory in accumulator
<chrislck>accumulator also uses memory
<Formbi>hmm, I think the memory consumptions should be compared
<chrislck>plus, the accumulator will need to be reversed when completed. not so when using the stack.
***apteryx_ is now known as apteryx
***overclucker_ is now known as overclucker
<wingo>good morning
<chrislck> /o\
*wingo has a design for cross-module inlining, whee
<davexunit>wingo: exciting!
<sneek>Welcome back davexunit, you have 1 message!
<sneek>davexunit, manumanumanu says: I have been working on a wrapper around srfi-64 that implements a large chunk of (chibi test)...
<dsmith-work>Hey Hi Howdy, Guilers
<leoprikler>Am I the only one, who finds it funny, that the reference implementation of SRFI 223 contains exactly the kind of bug they were supposed to defend against?
<davexunit>oopsy daisy
<manumanumanu>leoprikler: which one?
<leoprikler>(low + high) / 2
<rlb>I'm wondering why something like string-append has to scm_remember_upto_here_1 the individual strings, i.e. how could we lose track of them if they're in the argument rest list?
<rlb>(Asking because preserving that wrt utf8 strings might be a little more work.)
<manumanumanu>leoprikler: It has been a long time since I implemented a binary tree (I have two implementations I wrote about 11 years ago; one functional and one imperative). Should it floor? Shold it add 1? I don't remember.
<leoprikler>manumanumanu: (low + high) can overflow. This is typically not an issue in Scheme, because it just gets promoted to bignum, but the key is, that it shouldn't need to be promoted
<leoprikler>rlb: the rest list itself – or at least parts of it – could be discarded as you iterate
<manumanumanu>oh, but for a reference implementation clarity is king.
<rlb>I thought anything that was a C side argument was preserved throughout the call.
<rlb>i.e. if we have foo (SCM x) { ... } anything referred to by x will persist until foo returns?
<rlb>And since it's a rest list, no one should be able to destructively modify it to drop refs?
<leoprikler>uhm, no?
<leoprikler>you can drop x if it's no longer on the stack at any point
<leoprikler>the C optimizer can do that
<rlb>At least in our docs: "Guile's garbage collector will automatically discover references to 'SCM' objects that originate in global variables, static data sections, function arguments or local variables on the C and Scheme stacks, and values in machine registers."
<leoprikler>*on the C stack* is important here
<rlb>SCM is "function argument" in this case.
<leoprikler>if you pass arguments through registers and the compiler decides that the argument is no longer used → boom
<leoprikler>arguments on the stack is a full sentence :)
<leoprikler>why else would the example have scm_remember_upto_here_1 (file); // file is an argument
<leoprikler>the manual explicitly tells you, that this can happen
<RhodiumToad>personally I'm not convinced that the gc can actually operate correctly in all cases, given the amount of freedom the compiler has
<RhodiumToad>in particular the compiler can (and modern optimizers actually do) represent a pointer value by means of some offset
<rlb>Yeah, I wasn't looking at that page -- and clearly I've misremembered part of the requirements. Though I still wonder about a rest list to a SCM_DEFINE, i.e. I'd have assumed that pointer is held on to throughout the call by the caller.
<rlb>i.e. the code that constructed the rest list, but that might also just have been a vague incorrect guess.
<rlb>Is it at least a safe assumption that a rest list can't be modified (from outside) during a call?
<rlb>(I *think* that's probably true?)
<RhodiumToad>why are you bothering about this?
<RhodiumToad>you should probably assume that the compiler and optimizer will actively break things, and be as defensive as possible about it
<rlb>because with utf8 strings, it'd be more efficient if we can compute the strinbuf offsets (start and end) for each string as we make the first pass in string-append and then use those to build the final result, than if we have to do that twice (if we can't assume things won't change)
<rlb>(we have to compute the offsets in the first pass to get the total byte count -- similar to the approach for current strings)
<leoprikler>how can you be sure that the strings themselves won't change between computing the offset and concatenating the strings?
<leoprikler>[in an MT environment]
<rlb>Yeah, that's what I'm working on -- one option I was thinking of was to capture the stringbufs and offsets up front, and then traverse that. Since the stringbufs are immutable.
<rlb>Of course if I do that, then some aspects of my other questions don't matter.
<pkill9>dustyweb: how can I add a list metadata? with a quote? e.g. '("listitem1" "listitem2") ?
<pkill9>hmm actually the nicest would be yaml