IRC channel logs

2018-09-01.log

back to list of logs

<massma>hi guile, I'm trying to use pattern matching more, but I'm a little confused about matching vectors and I'm hoping someone might be able to tell me where I went wrong.
<massma>the manual says:
<massma>#(pat_1 ... pat_n) matches vector of n elements
<massma>but, when i evaluate:
<massma>(match (list->vector (iota 10))
<massma> (#(first second ... last)
<massma> (display first)))
<massma>I get a match error:
<massma>Throw to key `match-error' with args `("match" "no matching pattern" #(0 1 2 3 4 5 6 7 8 9))'.
<massma>am I misinterpretting the manual?
<amz3>massma: maybe ... doesn't work in vectors
<amz3>ellipsis
<amz3>remove the ellipsi and retry
<massma>amz3: thanks, yeah
<massma>(match (list->vector (iota 3))
<massma> (#(first second last)
<massma> (display first)))
<massma>works fine.
<amz3>ok
<amz3>IIRC you can do that wiht a list
<amz3>IDK how match works, so I don't know why it doesn't work on vector and worse failure ever I can not guess..
<amz3>;]
<massma>what's weird is:
<massma>(match (list->vector (iota 10))
<massma> (#(first second last ...)
<massma> (display last)))
<massma>works fine
<massma>it's only when the ... is in middle that it fails, but that syntax works find one lists
<massma>*works fine on lists
<massma>which is too bad, b/c grabbing the last element of a vector or handling it differently seems useful
<massma>looks match is provided by upstream
<massma>at first glance I gotta brush up on macros to follow the code. but, if I can pin down where the problem is I'll report back
<amz3>massma: unlikely your bug report will be sucessful
<amz3>massma: it's adapted to guile, it's not considered upstream
<amz3>amz3: or maybe you are right...
<amz3>sorry
<amz3>massma: maybe you are right and ellipsis should be supported in vector syntax
<mwette>syntax-rules does support the pattern #(P1 .. Pi <elipses> Pj .. Pn) so it seems it should be doable
<mwette>ellipsis
<massma>amz3: mwette: thanks; I got this deadline I'm stuck behind right now but hopefully next week I can dig in and try and figure out what's going on. Nice to know should be/could be fixable
<massma>I'm new to guile and scheme, so it might just take me a bit to figure out how!
***Server sets mode: +nt
***Server sets mode: +nt
*wingo just ran into another lightning register allocation weirdness :/
<wingo>i want a calling convention in which, around calls (which are really jumps), R0 and R1 are set. however lightning sometimes needs temporary registers, and computes liveness info to determine which registers are free. sometimes that means that our R0 or R1 get clobbered :(
<myonmyon>Hi there.
<myonmyon>I`ve been using the string->pointer function for a while only to get a memory leak. In the reference manual, they say that the C string is freed when the returned foreign pointer becomes unreachable.
<myonmyon>How does Guile judge the pointer reachability? I did use the string->pointer function to supply an argument to a foreign function.
<dustyweb>yay davexunit https://toot.cat/@dthompson/100650476852216318
<jlicht>dustyweb: Is there some ongoing game-jam?
<dustyweb>jlicht: there's one at the end of the month I think
<dustyweb> https://events.tymoon.eu/4
<dustyweb>oh
<dustyweb>end of next month :)
<jlicht>cool :-)
<amz3>myonmyon: oh
<amz3>myonmyon: that is a complex question. can you reproduce the leak on a small set of expressions?
<amz3>friendly reminder that we are trying to get a room at fosdem 2019
<amz3> http://community.schemewiki.org/?FOSDEM2019
<dustyweb>hm
<rain1>>How does Guile judge the pointer reachability
<rain1>it uses the boehm gc right?
<rain1>so it scans through the stack for objects that "look like" pointers
<amz3>yes something like that
<dustyweb>civodul: have you tried (use-modules (chop)) in guile within guix
<dustyweb>doesn't seem to work for me
<myonmyon>(import (system foreign))
<myonmyon>(define puts* (pointer->procedure void (dynamic-pointer "puts" (dynamic-link)) '(*)))
<myonmyon>(define (puts s) (puts* (string->pointer s "utf-8")))
<myonmyon>(puts (string-join (map (lambda (_) "a") (iota (* 1024 100))) ""))
<myonmyon>seems like memory consumption goes up while evaluating the last line repeatedly
<amz3>myonmyon: rewrite that and use named loop instead of iota
<amz3>myonmyon: (iota 1024) will create a list of 1024 elements that's somewhat big
<amz3>myonmyon: that might be the source of the 'memory' consumption, IIRC, the GC (garbage collector) doesn't free data as soon as they are not useful anymore, I think there is a small delay before it's free'd
<amz3>so you might need to keep the program running a while, after that last line, before GC kicks in
<amz3>myonmyon: do you work at the REPL? because i think in that case the GC can not reclaim some of the memory because there is reference to it in the REPL
<myonmyon>i work at the repl, there are no (and should be no references to repl $x variables)
<myonmyon>no repl references since everything goes to the void
<myonmyon>(gc) does not lower memory consumption
<myonmyon>and a 1024 * 100 element list is not the primary cause
<mwette>check sec 4.4.3 of manual and (ice-9 history); you can disable $-saves
<myonmyon>Also at the very moment when I did try that string->pointer thing, there were no big lists, just a huge string.
<myonmyon>and of course there was no REPL interfering.
<myonmyon>>running a while
<myonmyon>The first program I did write was a daemon.
<myonmyon>Days passed by and no frees.
<amz3>oh
<amz3>in the REPL again?
<myonmyon>It was not a REPL.
<amz3>can you paste the program somewhere so I can have a look at it
<amz3>also how to you measure meomry consumption?
<myonmyon>I just look at the memory percentage in top
<mwette>(gc-stats)
<mwette>sec 6.19 of manual
<myonmyon>These are enabled on debug builds, as I recall.
<myonmyon>I`ve lost all references to string->pointer in the old program back then. I decided to make
<myonmyon>C subroutines which free all the memory instead of ffi-calling them
***rekado_ is now known as rekado
<amz3>TIL
<rekado>I would like to rewind a port to a previous state when I unexpectedly read <eof>. Will ports play nicely with delimited continuations?
<rekado>or should I just record the port seek position before and then seek back on error?
<amz3>that's what i do
<amz3>that being said, i wrap the "port" in a custom stream
<amz3>I think if performance is not an issue you can use guile stream library
<amz3>instead of read + seek
***Elon_Satoshi is now known as Copenhagen_Bram
<civodul>rekado: you could "unread" things back to the port, would that help?
<rekado>no, because then I’d need to keep track of all things I’ve read.
<rekado>the idea was to read until I find a boundary string.
<rekado>if no boundary string is found something’s obviously wrong and I’d rather reset to the previous state.
<rekado>I ended up avoiding this problem completely, but I was wondering about ports in the context of delimited continuations anyway.
<civodul>the state of port is independent from the control flow of the program, if that's what you mean
<civodul>so if you resume a continuation, the port's state is not rewound
<rekado>I see.
***ngz` is now known as ngz