#go-nuts

/

      • tat_ joined the channel
      • BuGoNee joined the channel
      • jminter has quit
      • tat_ has quit
      • knoq joined the channel
      • LennardW|afk joined the channel
      • BuGoNee has quit
      • plutoniix joined the channel
      • plutoniix joined the channel
      • knoq has quit
      • Argylelabcoat has quit
      • danc__ joined the channel
      • preyalone has quit
      • Fr4n has quit
      • justicefries joined the channel
      • sz0 joined the channel
      • johanhenselmans joined the channel
      • neoncontrails joined the channel
      • zwischenzug joined the channel
      • fluter joined the channel
      • andyhuzhill joined the channel
      • knoq joined the channel
      • yohnnyjoe joined the channel
      • Monoctave has quit
      • knoq has quit
      • keepguessing joined the channel
      • keepguessing
        Any suggestions on how to make this work? https://play.golang.org/p/EN7Xn-heei
      • I was assuming that * wouldbe ahndled by []
      • hef
        but like
      • pixelplayer
        ok i got my byte to struct working
      • byte array
      • does any one know a good website for go code review?
      • mubdlur has quit
      • KuroiKitsu
      • Term1nal
        keepguessing: you'll need to deference the pointer first.
      • such as KuroiKitsu just linked
      • though I don't think it's entirely necessary to pass a map as a pointer in that way, given that as I understand it, map is a reference type anyway.
      • Someone correct me if I'm wrong.
      • Tv`
        it is
      • Teckla has quit
      • pixelplayer
        any chance i can have some one check my code to see if there is a more performant way to apply my byte array to my struct?
      • maroloccio joined the channel
      • Term1nal
        There's a general code review subreddit, but not sure if that's necessarily going to get you a review guaranteed.
      • davr0s joined the channel
      • sh4d0w_dev joined the channel
      • KirkMcDonald
        keepguessing: I'd just get rid of the ampersand.
      • streblo has quit
      • pixelplayer
        ah okay =/
      • sh4d0w_dev
        hello, may I ask very stupid question I can't clear answer for, why do I need drain http.Response.Body before closing it? can someone explain since behind that
      • *can't get
      • KirkMcDonald
        sh4d0w_dev: Can't read from something after closing it.
      • Teckla joined the channel
      • sh4d0w_dev: Or are you asking, why do you need to do that in order to keep the connection alive?
      • keepguessing
        KirkMcDonald: thanks.
      • KuroiKitsu: Term1nal thanks
      • Term1nal
        np
      • sh4d0w_dev
        not exactly, let me explain better im sorry after work i have hard time remembering that other people can't read my thoughts :)
      • Tv`
        sh4d0w_dev: you don't *need to*, it just changes the behavior
      • if you don't, net/http discards the rest of the body, and the only way to do that on http/1 is by closing the tcp connection
      • sh4d0w_dev
        i often see code defer func (){ io.Copy(ioutil.Discard, resp.Body; rest.Body.Close()}
      • Tv`
        people do weird things
      • sh4d0w_dev
        or CopyN first 512 bytes
      • Tv`
        and it even has a comment explaining what it does ;)
      • KirkMcDonald
        There's an assumption there that if the body has more than 512 bytes, it probably doesn't want to keep that connection open anyway.
      • sh4d0w_dev
        so it's not enough to just close body you need make sure to drain a bit in order to let Transport reuse connection?
      • KirkMcDonald
        You need to drain the whole thing in order to reuse the connection. But you also might not want to naively drain everything there is to read, since there might not be a limit on that size.
      • So tossing in an arbitrary limit (like 512 bytes) seems fairly reasonable.
      • deehuck joined the channel
      • Tv`
        better not try to drain robpike.io
      • KirkMcDonald
        I mean, why download a big thing, if you're just going to discard it.
      • Reusing connections is a fine thing, but at a certain point, it's not worth it.
      • For that project, the point was the 513th byte.
      • mubdlur joined the channel
      • knoq joined the channel
      • zair has quit
      • sh4d0w_dev
        interesting
      • lukd has quit
      • lukd joined the channel
      • Tv`
        at a certain point, it'll be http/2 anyway
      • at which point all these "helpful" gimmicks will be just overhead
      • knoq has quit
      • sh4d0w_dev
        thank you guys for your time and answers
      • Tv`
        i guess if you really cared, you could put a if req.ProtoMajor == 1 { } around that
      • the Close is needed either way
      • Term1nal has quit
      • neoncontrails joined the channel
      • sh4d0w_dev
        what about arbitrary 512 bytes. i understand that if response is long than 512 bytes (will be my case) then it will have left overs there, right?
      • Tv`
        yes
      • some limit is good
      • they picked 512
      • cloudCrawler has quit
      • zetashift joined the channel
      • sh4d0w_dev
        welp im in very bad place. im writing automation that uses vendors API it's http 1.x and sends around 54MB of json blob (because they does not know how to implement pagination), problem im trying to solve is that apparently i make too many connections... i slow down API by opening-closing after each request
      • deparker has quit
      • Tv`
        sounds like you ask for a lot of data, then don't read it
      • hummerpaskaa has quit
      • sh4d0w_dev
        yep, if i could not load whole thing on every single request that would be nice, but world is not perfect. for some requests i need parse data to do verification other times i don't, either way api will send me everything
      • BuGoNee joined the channel
      • pixelplayer
        i posted it on their code review forum see how things go
      • sh4d0w_dev
        and of course Content-Length is just random in those responses....
      • devxxx joined the channel
      • knoq joined the channel
      • IndianAr_ joined the channel
      • knoq has quit
      • sh4d0w_dev has quit
      • moloch has quit
      • lukd has quit
      • sh4d0w_dev joined the channel
      • ap4y has quit
      • errl joined the channel
      • lukd joined the channel
      • xkapastel joined the channel
      • errl has quit
      • zair joined the channel
      • IndianAr_ has quit
      • knoq joined the channel
      • one_zero has quit
      • knoq has quit
      • soupladler joined the channel
      • sh4d0w_dev has quit