IRC channel logs

2016-01-23.log

back to list of logs

<davexunit> https://twitter.com/H2CO3_iOS/status/690281223734874112
<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>gah
<rntz>figuring out how to work guile-wm would be easier if it didn't routinely crash when something has the wrong type
<frofroggy>davexunit: if they only knew that Guile uses itself to build itself in the regular build process. I really enjoyed wingo's blog post on the build process. http://wingolog.org/archives/2016/01/11/the-half-strap-self-hosting-and-guile
<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>djcb: 'kons' in vector-fold is different
<davexunit>from the docs:
<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.
<davexunit>so you are adding indices to your result
<davexunit>0, 1, 2.
<davexunit>thus you get 9 as a result instead of 6
<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>I think you should adjust your expectation.
<davexunit>'fold' is a very general thing.
<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>*various
<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>it's not a special case, though.
<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>but it wouldn't be general anymore.
<davexunit>folds are a general-purpose tool
<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>+1 djcb
<amz3>at least I don't understand why this is the default behavior, I don't a lot of math anyway
<amz3>or vector stuff
<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>(not (eq? 'length 'magnitude))
<davexunit>two completely different meanings of vector.
<djcb>exactly
<davexunit>this is OK
<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
<davexunit>,d vector-length
<davexunit>done
<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.
<djcb>aha
<mark_weaver>(whereas SRFI-43 vector-map and vector-for-each passes the index to the procedure)
<djcb>oh, that's interesting
<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.
<djcb>ouch!
<mark_weaver>I did a better job with my R7RS implementation, but that's still on the wip-r7rs branch and not yet merged
<mark_weaver>s/wip-r7rs/r7rs-wip/
<djcb>great!
<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
<mark_weaver>I agree :)
<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
<taylan>filing bug reports...
<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>taylan: that would be great, thanks!
<mark_weaver>I apologize for my latency on dealing with some of your pending patches. I'm a bit overloaded at present.
<mark_weaver>but your contributions are very much appreciated.
<sjoerd`>For anyone with a little interest into it, I have been continuing with my implementation of a GUILE-based assembler-executor
<sjoerd`>Progress here: https://github.com/santidhammo/guile-assembler