IRC channel logs
2016-01-23.log
back to list of logs
<davexunit>"a native Guile 2.0.11 is required to cross-build Guile" <davexunit>this person is angry with the guile build system <davexunit>a build system that I've found to be one of the better ones for a language implementation. <rntz>is there anyone in this channel I ought to ping for guile-wm questions? <rntz>figuring out how to work guile-wm would be easier if it didn't routinely crash when something has the wrong type <b0f>I've a problem using http-post from the web client package - <b0f>the server succeeds when the verb is of the form "POST uri" but not for "POST uri HTTP/1.0" (or 1.1 for that matter) <b0f>So I tried setting #:version to #f but the API chokes on that <b0f>Any way to persuade the high-level API not to specify the HTTP version? <b0f>(FYI server is Oracle App Server 11g) <djcb>(fold + 0 '(1 2 3)) => 6 <djcb>(vector-fold + 0 '#(1 2 3)) => 9 <djcb>that's a bit surprising! <davexunit>KONS is applied as (kons i state (vector-ref vec1 i) (vector-ref vec2 i) ...) <davexunit>the first argument is the index of the element in the vector. <djcb>davexunit: indeed - but it's still a bit surprising <djcb>`vector-index-fold` for this variant would have been clearer imho <davexunit>it's only surprising because you have the expectation that *all* folds should behave the same. <davexunit>see 'file-system-fold' in the guile manual for a very different type of fold. <djcb>sure - my expectations are easier to change than varions srfis <djcb>but things are easier to understand when my expectations need fewer special cases <djcb>and imho, in this particular case, following the list behavior would have been nicer <davexunit>all folds do a similar thing, but every data structure requires a different technique. <djcb>imho my expectation of (vector-fold + 0 '#(1 2 3)) is perfectly reasonable <djcb>vector doesn't "require" a different fold <davexunit>usually when I do vector operations, I care about the index. <djcb>in a different universe, vector-index-fold could be used for that, while vector-fold would follow what list does <davexunit>but you can easily implement what you want in terms of vector-fold <djcb>of course, that's what i did <djcb>but only after being surprised by what vector-fold actually does <amz3>at least I don't understand why this is the default behavior, I don't a lot of math anyway <djcb>amz3: well, guile vectors are not necessarily (usually?) used for math <djcb>just as a convenient data structure <djcb>for mathematicians, scheme's 'vector-length' would be a bit surprising as well! <davexunit>two completely different meanings of vector. <djcb>personally that one does not surprise me, but googling for "vector-length" suggests it might be surprising too <davexunit>surprise is a poor excuse when the explanation to anything is there at the REPL <djcb>true - but looking up every symbol to check for possible surprises might be a stumbling block for some <mark_weaver>djcb: I agree with you that it's confusing, but we can't very well call it SRFI-43 and change the API. <mark_weaver>but I guess the rationale was that for vectors, the index is often needed. <djcb>mark_weaver: thanks, yes i understand. these things are hard! <djcb>i'm writing guile/scheme intermittently, so it's easy to forget things <mark_weaver>djcb: fwiw, R6RS and R7RS opted for consistency with the list procedures in their vector-map and vector-for-each, but they don't include vector-fold at all. <mark_weaver>(whereas SRFI-43 vector-map and vector-for-each passes the index to the procedure) <mark_weaver>unfortunately, our R6RS implementations of vector-{map,for-each} are not very efficient. they work by converting the vector to a list, calling map (or for-each) and then converting the result back to a vector. <mark_weaver>I did a better job with my R7RS implementation, but that's still on the wip-r7rs branch and not yet merged <djcb>for my little experiments i don't care _too_ much about performance, but <djcb>it's nice it is being worked on <djcb>guile/scheme is such an elegant island in the programming language ocean <taylan>mark_weaver: (hashtable-hash-function (make-eq-hashtable)) doesn't return #f in our (rnrs hashtables), and the same with make-eqv-hashtable. is this intentional? <taylan>mark_weaver: also (hashtable-set! table key value) doesn't raise an error when table is immutable <taylan>I couldn't find explicit wording in R6RS on that it should error, though silently ignoring the operation seems weird <mark_weaver>taylan: sorry for the slow response. I'm not familiar with those APIs off-hand, but I guess you're probably right that these are bugs. <taylan>np :) maybe wingo knows. filing reports anyway, won't hurt to have it documented somewhere. <mark_weaver>taylan: I just looked, and indeed r6rs is quite clear that hashtable-hash-function should return #f for eq and eqv tables. <mark_weaver>as for 'hashtable-set!', if it could be modified to raise an error without too much loss of efficiency, I agree that we should do it. <mark_weaver>for some of our fundamental data structures, e.g. cons cells, it's not practical for us to detect whether it's immutable (e.g. a literal). <mark_weaver>the best answer for literal cons cells is probably to arrange for them to be in pages that are mapped read-only on systems that support it. <taylan>mark_weaver: I can write patches if you're not already onto it. <mark_weaver>I apologize for my latency on dealing with some of your pending patches. I'm a bit overloaded at present. <sjoerd`>For anyone with a little interest into it, I have been continuing with my implementation of a GUILE-based assembler-executor