Yes. But then you could use go get to import it.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this
Interesting points. So I guess ReadFull can be suitable for the consuming
end of those bytes.
Thank you!
On Tue, Jun 9, 2020 at 11:40 PM Brian Candler wrote:
> On Tuesday, 9 June 2020 17:53:07 UTC+1, Amit Lavon wrote:
>>
>> Why would I ever use Reader.Read rather than ReadFull?
>>
>>
> Because
On Tuesday, 9 June 2020 17:53:07 UTC+1, Amit Lavon wrote:
>
> Why would I ever use Reader.Read rather than ReadFull?
>
>
Because it's often more efficient to process data in the "natural" chunks
it comes in, rather than packing it out to fit a particular buffer size -
in which case the final
Read lets you build pipelines, it involves fewer expensive allocations
(ie. you might not want to use ReadFull in the hot path of an important
project), you could use read to read into a slice at different points,
or not read the entirety of an expensive document into memory all at
once, you can
On Tue, Jun 9, 2020 at 11:23 AM Axel Wagner
wrote:
> If you actually read OPs second E-Mail, they did and they didn't find it
> very clear. With that in mind, your message isn't very nice.
> (Also, not to be repetitive or anything: ~80% of the messages in this
> thread aren't actually concerned
If you actually read OPs second E-Mail, they did and they didn't find it
very clear. With that in mind, your message isn't very nice.
(Also, not to be repetitive or anything: ~80% of the messages in this
thread aren't actually concerned with what the complexity class *is*, but
whether it matters)
I'm surprised none of you have taken all this time to just go read the
code, where it is clearly linear.
On Mon, Jun 8, 2020 at 9:12 PM Robert Engels wrote:
> The OP specifically asked about compilation - in fact it’s in the title.
> You stated the compilation complexity is a DoS attack vector.
On Tuesday, June 9, 2020 at 4:05:38 PM UTC+2, Amit Lavon wrote:
>
> I am reading raw bytes from a gzip input. I found that it only reads up to
> chunks of 2^15 even though there is more data to be read.
>
> Is that the intended behavior? I expected whatever internal buffering it
> may have to be
Hi gophers,
Demonstration: https://play.golang.org/p/AY-fVWiOrFd
I am reading raw bytes from a gzip input. I found that it only reads up to
chunks of 2^15 even though there is more data to be read.
Is that the intended behavior? I expected whatever internal buffering it
may have to be
Thanks Ian, it's nice to know that we're using Go correctly.
I agree that more code doesn't really matter, and I think I'd be completely
fine with this situation had there been a vet check that ensured that no
selects are forgotten.
Let's see if generics change something in this area.
On
10 matches
Mail list logo
