IRC channel logs

2014-12-15.log

back to list of logs

<davexunit>hmm, 'or' isn't friendly towards multiple values
<davexunit>(or (values 1 2)) returns 1 and 2
<davexunit>(or (values 1 2) (values 3 4)) returns just 1
<davexunit>as designed or bug?
<daviid>davexunit: don't know the details but i did ask, iirc, i've been told it's not a bug, but better wait for maintainers answer. in the mean time receive or match of course ... as you know already
<davexunit>daviid: thanks
<daviid>actually match may not work either, don't know, in these case i always use receive, just because i'm used to...
<daviid>did ask receive to work with lists, but the idea was not good, i've been told, use match instead they said, now i match my life and receive more haha
<davexunit>match is the best
*mark_weaver loves match
<cky>davexunit: Given multiple values: is (values #f #f) a truthy value? What about (values #f #t)? What about (values #t #f)?
<cky>davexunit: The <test> portion of an `if` is considered a single-value context, so using multiple-values is considered an error.
<cky>davexunit: However, the last expression in `or` is in tail position, so if _that_ is in a multiple-value context, then using MV is okay.
<cky>davexunit: Guile 2.0 does CL-style "primary value" semantics for MVs in single-value context. But Guile 1.8 used a first-class values struct, and Racket throws an error.
<cky>davexunit: I would say that `or` works as designed. :-)
<cky>mark_weaver: Remember that convo about SRFI 45's `eager` being a procedure, so you couldn't use `(eager (values 1 2 3))`, and how that made SRFI 41 streams unlikely to work well with multiple-valued producers? Since we currently use a private copy of SRFI 45 in our SRFI 41 implementation, would it be worth making `stream-eager` a macro and provide actual support for MV producers? (This can be a 2.2-onwards
<cky>change, if you feel it's worth it.)
<cky>Of course, it could just be more trouble than it's worth since nobody really uses streams that way, that I'm aware of.
<davexunit>cky: thanks for the explanation.
<mark_weaver>(values #f #f) is not _a_ value at all. it's two values
<mark_weaver>so it doesn't make sense to ask whether it's a "truthy" value.
<mark_weaver>oh, sorry, I should read the whole backlog before responding.
<cky>:-)
<mark_weaver>cky: I'm not sure it's a good way to use streams, honestly.
<mark_weaver>supporting multiple values has an efficiency cost, and changing procedures to macros means that they can't be passed as arguments to other procedures.
<mark_weaver>(there are hacks to get around that, but it's not so nice)
*mark_weaver goes afk
<cky>Yeah, figured it's not worth the bother. *nods*
***petercommand is now known as Guest43464
***Guest43464 is now known as petercommand
<nalaginrut>morning guilers~
<cky>o/
<nalaginrut>cky: have you tried bigloo?
<cky>nalaginrut: I've heard of it, but not tried it.
<nalaginrut>alright, I've heard that bigloo provide compiling to C&java bytecode&clr
<nalaginrut>I plan to hack it to find something useful for Guile
<nalaginrut>cky: I asked so because I saw you're involved in a SO related topic
<nalaginrut>;-)
<ArneBab>amirouche: ah, yes, __call__ is right. Thanks!
<ArneBab>__run__ was for threads…
<lloda`>it's unfortunate that the Scheme literals for +-inf & nan are +-inf.0, the nearly universal convention seems to be just +-inf & nan :-/
<lloda`>I wish there was at least for a (format ...) option to use +-inf, nan instead of +-inf.0, +nan.0
<nobody111>maybe i am being boring with this, but looking at the info documentation of Guile 2.0.11, i notice that a 'free' function is the one to write when you want to release memory allocated through means other than the _gc_ family. But, how does GC know if I allocated 10M, 100M or 2 GB of memory? Rather, how to tell this to GC of Guile?
<ArneBab>nobody111: where do you read that?
<nobody111>ArneBab, in 5.5.4 Garbage Collecting Smobs, info documentation
<nobody111>ArneBab, However, when data associated with a smob is managed in some other
<nobody111>way—e.g., ‘malloc’’d memory or file descriptors—it is possible to
<nobody111>specify a _free_ function to release those resources when the smob is
<nobody111>reclaimed, and a _mark_ function to mark Scheme objects otherwise
<nobody111>invisible to the garbage collector.
<ArneBab>nobody111: the gc then does not have to know the size of the memory. You have to encode that in the free function.
<ArneBab>(or rather: it knows what to free, because you tell it indirectly in the definition of the free function)
<ArneBab>at least that’s what I read into it.
<nobody111>ArneBab, what if i have a sequence of 20 objects and i go through them iteratively in the following manner: 1) create an object (allocates , say 1GB); 2) perform an operation on it; 3) repeat the previous to steps until no more objects to be processed
<nobody111>GC should step in and release the memory of processed object before allocating the new one in order to prevent the exhaustion of heap.
<nobody111>How would it know that it is necessary to remove allocated and unused objects if it does not know how big they are?
<nobody111>Maybe i don't understand how the GC works, but i thought it does not try to remove things as soon as possible, rather it runs occasionally collecting dead things.
<lloda`>nobody111: AFAIU that is correct. If you need the alloc/free to be done in the way you describe, you need to do it by hand.
<sneek>Welcome back lloda`, you have 2 messages.
<sneek>lloda`, nobody111 says: Thanks for the info. I have only recently checked what's going on here and in the meantime I devised my own fftw3 interface. If yours is incomplete, perhaps we can do some merging.
<sneek>lloda`, nobody111 says: I'll look at your code to see if this is possible. That's in my buffer, as soon as there is less Work to do. :)
<lloda`>nobody111: your call :-)
<dsmith-w`>Monday Greetings, Guilers
***dsmith-w` is now known as dsmith-work
<ArneBab>moin dsmith-work
<cky>nalaginrut: I'm involved in so many topics on SO, I won't remember it unless you send a link to it. :-)
<nalaginrut>cky: never mind, just asking ;-)
<cky>naboo: :-)
<cky>Oops, tab completion fail because nalaginrut has left already.
***alandipert_ is now known as alandipert