IRC channel logs
2024-03-11.log
back to list of logs
<old>sneek: later tell dthompson in the same vein, how would an allocation can be avoid in vec2-dot ? <old>sneek: later tell dthompson ehh I guess that's because floated are always heap allocated .. <cow_2001>how do i quasiquote in match? (match '("a" "b" "c") (`("a" ,rest ...) (display rest))) <flatwhatson>cow_2001: seems like a quirk of ... in quasipatterns. this works: <flatwhatson>(match '("a" "b" "c") (`("a" . ,rest) (display rest))) <flatwhatson>fwiw quasipattern is basically useless in this case: (match '("a" "b" "c") (("a" . rest) (display rest))) <flatwhatson>also this works: (match '("a" "b" "c") (("a" rest ...) (display rest))) <flatwhatson>the difference is likely that the dotted pair accepts improper lists <cow_2001>and ellipsis checks for proper listness. i now remember someone saying something about that. maybe lud...o (don't want to highlight needlessly) <cow_2001>okay, all is well. thank you, flatwhatson! <flatwhatson>proper lists are mentioned in match the docs, you might recall it from there <flatwhatson>cow_2001: this works if you want to embed a proper list match in a quasipattern: <flatwhatson>(match '("a" "b" "c") (`("a" . ,(rest ...)) (display rest))) <flatwhatson>(match '("a" "b" "c") (`("a" ,@(rest ...)) (display rest))) <cow_2001>don't ask me. i can't even delineate between legal and illegal match patterns <cow_2001>but i am getting the hang of it, maybe ~_~ <cow_2001>for a while i've been using just conds because match is a bit of extra syntax <cow_2001>learned recently that you have a guilefmt in the form of guix style -f blah.scm <cow_2001>(spawn "sh" (list "sh" "-c" "echo moo 1>&2") #:error (open-file "moo-error-file" "w")) works but (spawn "sh" (list "sh" "-c" "echo moo 1>&2") #:error (%make-void-port "wb")) does not and results with a segmentation fault <cow_2001>how do i redirect spawn's error into the great big void? <jpoiret>cow_2001: a segfault shouldn't happen <jpoiret>for now you can redirect into /dev/null <jpoiret>basically spawn can't use guile ports that aren't backed by an actual file descriptor, because it's just an interface to the underlying libc's spawn <jpoiret>spawn was buggy when it was introduced unfortunately <old>cow_2001: #:error (open-output-file "/dev/null" #:binary #t) <graywolf>Hello, what is difference between (string-copy) and (substring)? I read the docs, but do not understand what the difference is. <ieure>graywolf, The docs seem pretty clear to me, what part aren't you getting? <graywolf>I mean, it seems to be that they both return a string, initially sharing the storage, copied as soon as one is modified. <graywolf>While both are documented in different words, they seem to be doing the same thing. <graywolf>So I am missing something, but not sure what. <ieure>There's a paragraph at the beginning of the substring documentation which explains what it's doing differently. <graywolf>I see that paragraph. The (optional) start, end for string-copy are not documented, but I assumed they behave the same way <graywolf>In other words, I do not understand how (string-copy "foo" 0 2) differs from (substring "foo" 0 2) <ieure>Okay, I see what you mean. That is weird. <graywolf>In REPL they both produce "fo", hence my confusion <lloda>these functions do the same thing. I imagine substring was written first and then string-copy came from srfi-13 <lloda>doc could be clearer that they're the same <lloda>oh it looks like substring is r5rs <old>scm_srfi13_substring_copy (srfi-13) calls scm_i_substring_copy (substring) <dthompson>old: sneek sent me your messages from... whenever you sent them... to me in a different channel. <old>dthompson: ahh classic sneek <old>I sent them yesterday on this channel <dthompson>to answer "how would an allocation can be avoid in vec2-dot?", allocation *is* already being avoided in vec2-dot. all the arithmetic is unboxed <dthompson>*and* vec2-dot is inlined wherever it's called so the unboxing can continue if the vec2-dot call is part of a larger computation <old>If I disassembled vec2-dot, I can see allocate-pointerless-words/immediate at the end of the procedure <dthompson>as a standalone procedure, yes, that would be expected <old>okay yes I understand, the callee does not know where to put the storage for the caller, so it boxed it on the heap <dthompson>yeah the callee needs to receive a scheme value <old>there are intermediate value that does not seem to be unboxed I do now know why <dthompson>the way to fix this to not allocate at all is to avoid using vec3s at all internally and do the vector normalization and cross product directly in the procedure <dthompson>some code duplication in exchange for no allocation <old>eeeh. would there not be a way for the compiler to do more agressive optimization instead? <old>ahh it is a record wrapepr <old>without the srfi-9 around, do you think the compiler would be able to avoid any allocation then? <old>say vec3 was a bytevector <old>that allocation could be done on the stack if the VM could support it no ? <old>since these allocations are only intermediate value <dthompson>stack allocation is reserved for objects that can fit within a word, though <dthompson>I guess we could imagine an optimization that was capable of noticing well-known bytevector allocations of just a few words or less that did something special with them. doesn't feel like it meets the threshold for being worth additional complexity. <old>If the compiler can determine the maximum size of the bytevector, then it is totally worth it <old>allocating words on the stack vs GC allocation is order of magnitude faster <dthompson>but now we're changing the execution model in a pretty fundamental way :) <old>for the better perhaps! <cow_2001>old: i feel like that's cheating :| it's using a file that may or may not be there