[go-nuts] Re: How to go-imports subdirectory?

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 discussion

Re: [go-nuts] Re: gzip.Reader.Read does not fill the given buffer

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

Re: [go-nuts] Re: gzip.Reader.Read does not fill the given buffer

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

[go-nuts] A simple LogPrint function for file/line chain/log wrapping and error testing

BSD license/public domain, Feel free to criticise/use Means I can easily disable file/line inclusion if stdlib ever gets that part of the error values proposal. Also easy to apply with search/replace. // LogPrint : An error wrapping log.Print replacement that adds location and // fil

Re: [go-nuts] Re: gzip.Reader.Read does not fill the given buffer

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 im

Re: [go-nuts] Re: gzip.Reader.Read does not fill the given buffer

Thank you!! io.ReadFull is just what I needed (and what I actually expected from Reader.Read). Why would I ever use Reader.Read rather than ReadFull? On Tue, Jun 9, 2020 at 6:11 PM Brian Candler wrote: > There is io.ReadFull if you want to > read as much as

[go-nuts] Re: How to go-imports subdirectory?

On Tuesday, June 9, 2020 at 4:33:06 AM UTC, Tamás Gulácsi wrote: > > Can't you move the go.mod one level up, into the root? But that would mean all imports paths would have the `/go` in them, no? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

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 w

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

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)

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

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.

[go-nuts] Re: gzip.Reader.Read does not fill the given buffer

There is io.ReadFull if you want to read as much as it can into the preallocated buffer; you'll get io.ErrUnexpectedEOF if it's less than this. https://play.golang.org/p/gIAX046vNvW There is ioutil.ReadAll if you

[go-nuts] Re: gzip.Reader.Read does not fill the given buffer

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

Re: [go-nuts] compress/bzip2：Why is there only a decompression function, no compression function.

Chapter 13 in 'The Go Programming Language" uses bzip as an example of CGO integration. Book is good, code is here: https://github.com/adonovan/gopl.io/tree/master/ch13/bzip On Mon, Jun 8, 2020 at 7:06 PM 'Dan Kortschak' via golang-nuts < golang-nuts@googlegroups.com> wrote: > bzip2 compression i

[go-nuts] gzip.Reader.Read does not fill the given buffer

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 invisibl

Re: [go-nuts] Using context package for goroutines cancellation is quite verbose

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 Monday