<lilyp>Both are also worst-case O(n) :) <fnstudio>lilyp: thanks, when you say both, do you mean the three of them or rather case/hts? <lilyp>cond/case are basically if chains <lilyp>and there are degenerate hash tables, which are barely better than lists <lilyp>but those are just asymptotics; for real hardware numbers you have to benchmark benchmark benchmark <fnstudio>lilyp: yeah, very interesting, i might be overthinking my current task a little bit but it's fascinating to understand these efficiency problems and corner-cases <lilyp>somewhat related is what you'd be using it for <lilyp>a hash table can be extended, cond/case can not unless you're handing off control in the else statement <randart>Morning guilers! I'm trying to figure out web client (talking to a local programme). It uses POST/GET to send a some json which is then parsed at the other end. I am trying to replicate a python requests call which works fine. Problem seems to be that the Content-type being sent as text/plain instead of application/json. Pastebin of code and link to public webtest next. Any pointers on how to use this <lilyp>randart: content-type is its own field in request <lilyp>you probably want to use lower-case content-type to set it <lilyp>okay, my bad, content-type is not a field, but kebab-case symbols are probably still the way to go <randart>web/request.scm:184:10: In procedure build-request: <randart>Bad request: Bad value for header content-type: "application/json" <randart>'content-type is its own field in request' : sorry, but I don't understand the implication of this. <randart>Trying blindly to duplicate the headers from the python request seems to work for everything execpt content-type. <lilyp>yeah, my bad, it's not a field <lilyp>the reason this works is because your headers aren't being validated <lilyp>so Guile just checks if they're strings and sends them on their way <lilyp>but guile actually checks for the content-type (lowercase) header and if unset uses text/plain <randart>May /may not be relevant, but if I add gzip to the accept-encoding field I get the following fatal error: <randart>Throw to key `decoding-error' with args `("scm_from_utf8_stringn" "input locale conversion error" 0 #vu8(31 139 8 0 0 0 0 0 0 3 3 0 0 0 0 0 0 0 0 0))'. <randart>lilyp: hmm: it won't accept a lowercase header to set... <lilyp>you should just have gotten a request from me <ArneBab>randart: for decoding: do you get utf8 or iso-something? (the latter is still the default on the web if you do not send a content type with encoding) <randart>lilyp: looks correct! How did you do that? :) <lilyp>(content-type application/json) <lilyp>See `info '(guile)HTTP Headers'` <ArneBab>if you need to add options, you might need sonething like this: (content-type . (application/json (charset . "utf-8"))) <randart>Ah, got it! I have to say this is confusing! It looked to me that the correct format was a list of pairs. And, indeed, it seems to be, except when it is not :) <ArneBab>(content-type . (application/json)) is the same as (content-type application/json) <randart>Thanks for the help folks: time to digest the info page on headers now! <fnstudio>hi, i'd like to build an array whose elements are equal to the respective coordinates <fnstudio>e.g. #2((0 0)(0 1)(1 0)(1 1)), i suppose? <fnstudio>i thought of creating a blank array first, with make-array <fnstudio>and then using array-index-map! to iterate over its coords <fnstudio>now... except that doesn't seem to work, i believe because array-index-map! gives separate values, which identity is not happy with <fnstudio>how about (array-index-map! ra (lambda x x)) ? i refuse to believe this can be a solution? <fnstudio>yeah, it does work, it looks (to me) pretty ugly though, as if i'm missing some easier way to do it <ArneBab>lampilelo: how so? doesn’t that wrap every entry in lists? <lampilelo>list takes its arguments and turns them to a list <ArneBab>lampilelo: arg, yes — I missed the missing parens around the first x <ArneBab>randart: as a start, go into the terminal and get the REPL (with guile). Then enter '(foo . (bar)) and compare with '(foo bar) <ArneBab>for background: '(foo . (bar)) is the underlying syntax of '(foo bar). It is literally (cons 'foo '(bar)) <randart>ArneBab: Thanks, yes I see that. I was a bit sloppy in terminology as I say pair for alist when lists are also pairs! What I did not realise is that each header has its own specific data format. Presumably the '(Upper-Case . "string") format is parsed behind the scenes and it looks like content-type is a special case. I am guessing that the parsing is too late in the process, and the user has to provide <randart>the form that you all gave me manually. <lilyp>Upper-Case . "string" is not parsed at all <lilyp>a raw string value is accepted as "header" when no such header is known to Guile <lilyp>presumably to work around various "X-MySpecialHeader" things <randart>In my original attempt (Accept . "*/*") and (Accept-Encoding . "deflate") did seem to work, though. Coincidence? <fnstudio>lampilelo: oh wow... that's unexpected and interesting, thanks <lilyp>randart: again, those headers don't get verified at all and are just passed as is; so yes, it's a lucky coincidence <fnstudio>but yes, of course, i should have thought of it, it's a sort of... multi-value identity, after all <randart>lilyp: *unlucky* coincidence, since it set me off on the wrong path. I've made a list of headers with string values and fed it through parse-header to deal with the different data type requirements. Sledgehammer to crack a nut? Seems to work though, and I can keep it as a snippet. <lilyp>tl;dr-driven programming at its finest <randart>tl:dr is a bit harsh give that the entirety of the explanation of headers in the web client manual page is "Any extra headers in the alist headers will be added to the request." <randart>Anyway, isn't tl:dr otherwise known as 'abstraction'? :) <lilyp>you have a manual page about headers <lilyp>those are already an abstraction from raw string values <lilyp>you're actively undoing that <lilyp>It's as though I wrote an x86 assembler in Rust. <ArneBab>lilyp: I made a similar error at first, after reading the page, so I think we need to work on that part of the documentation. <lampilelo>definitely, when i read it the first time it seemed unclear to me too <lilyp>there already is an example, though <lilyp>I think we should link back to the HTTP headers page and polish that up with one example per header <randart>A link to the HTTP headers page would probably have solved it for me: it can be hard to know where to look in the voluminous documentation. The key thing I didn't predict was that each header had it's specific data format. <lilyp>In other news, data in Scheme is structured :) <ArneBab>we’re lacking a "send patches here" part on the site. We only have that for bugs. <lilyp>Just file it as a bug against the documentation :) <ArneBab>To contribute smaller improvements, please send patches to guile-devel@gnu.org <ArneBab><include list with patch format from bugs> <lampilelo>there is a link to guile-devel under the main Contribute header <ArneBab>yes, but no instructions where to send patches ***spk121_ is now known as spk121
<spk121>ArneBab: did that e-mail actually contain a patch? I don't see one <spk121>OK. I blame this bad phone app, then *ArneBab is pretty annoyed by free phone email apps often not doing the core job of email <randart>ArneBab: That would have been perfect! <bricewge>Oh, no... There isn't support for `lchown` in Guile <bricewge>Interesting, I don't know this module. I was thinking of using ffi to call lchown <mwette>that's ffi calls; I didn't try it but I've written my share of ffi interfaces <bricewge>mwette: Indeed, it show how clueless I'm about FFI...