Re: [go-nuts] What is the point of gzip Reader.Close?

2021-06-23 Thread Steven Penny
On Wed, Jun 23, 2021 at 5:55 AM a2800276 wrote: > As a rule if I feel that the author of libraries I intend to use are totally > inept morons and can't be trusted to not ask me to arbitrarily call random > unnecessary functions I would shy away from using their library altogether. I want to

Re: [go-nuts] What is the point of gzip Reader.Close?

2021-06-22 Thread Steven Penny
On Tue, Jun 22, 2021 at 4:31 PM 'Dan Kortschak' wrote: > Yes, trivial examples also exist. I thought one possible reason was `http#Response.Body` [1], because if a response contains `Content-Encoding: gzip`, then Go will automatically wrap the Body in a `gzip.Reader`. If that was the case, then a

Re: [go-nuts] What is the point of gzip Reader.Close?

2021-06-22 Thread Steven Penny
On Mon, Jun 21, 2021 at 6:52 PM 'Dan Kortschak' wrote: > https://play.golang.org/p/gwDnxVSQEM4 Thanks for the help, but I found a much simpler example: https://play.golang.org/p/EcitH-85X6S -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] What is the point of gzip Reader.Close?

2021-06-21 Thread Steven Penny
Thanks to all the replies, but looks like I got the answer from another forum [1]. Copying here: The Close() method was originally used to tear down the background groutine used by the deflater. The background goroutine was removed in in a June, 2011 change list [2]. The author of the CL wrote

Re: [go-nuts] What is the point of gzip Reader.Close?

2021-06-21 Thread Steven Penny
> You asked a question. People here are genuinely trying to help you by > giving you their acquired knowledge of (collectively) over more than a > couple of decades of Go programming. OK, so all all these decades of experience, why cant anyone produce a small program to demonstrate the problem?

Re: [go-nuts] What is the point of gzip Reader.Close?

2021-06-21 Thread Steven Penny
> No, I gave a clear path that would lead to a case of a non-detected > error when Close is not called. > > This seems like a really odd hill to die on, but it's your choice I > guess. You calling "go look through 3200 lines of Go code" (not including tests) [1] a "clear path" is a dubious

Re: [go-nuts] What is the point of gzip Reader.Close?

2021-06-21 Thread Steven Penny
>> - https://golang.org/pkg/compress/flate >> >> - https://golang.org/pkg/compress/lzw >> - https://golang.org/pkg/compress/zlib > > All of these do. whoops, yeah thats true. However my original point still stands. Three people have replied now: - Axel Wagner - Bruno Albuquerque - Dan Kortschak

Re: [go-nuts] What is the point of gzip Reader.Close?

2021-06-21 Thread Steven Penny
> Not to mention this all is an implementation detail and even if it did > nothing today, relying on this behavior would be a recipe so see cobe > breaking in the future. In this sense, the advice "if there is a Close() > method, call it when you are done with it" is a very good one. No other

Re: [go-nuts] What is the point of gzip Reader.Close?

2021-06-21 Thread Steven Penny
> Again, the idiom is, if you get an `io.Closer`, `Close` should be called once > you're done with it. Thanks for the responses, but I am not convinced. Other than "its just good practice", I havent seen a single concrete example where not closing a gzip reader would cause a problem. Until that

Re: [go-nuts] What is the point of gzip Reader.Close?

2021-06-21 Thread Steven Penny
Thanks for the response. Couple of points: > 1. You don't get notified about checksum mismatches or the like. i.e. the > data you read might be corrupted and you might not realize it. I dont think this is true. I tried with this file [1], and Close returns the same error as, for example io.Copy,

[go-nuts] What is the point of gzip Reader.Close?

2021-06-21 Thread Steven Penny
If I have a program like this, it fails as expected (on Windows): ~~~ package main import ( "fmt" "os" ) func main() { old := "go1.16.5.src.tar.gz" os.Open(old) err := os.Rename(old, "new.tar.gz") // The process cannot access the file because it is being used by another

Re: [go-nuts] unexpected EOF with fmt.Scanner

2021-05-27 Thread Steven Penny
Hm interesting - so if you just panic(io.EOF) instead of return io.EOF, then it works as expected. Must be the code is recovering the panic somewhere. Thanks for the help On Thursday, May 27, 2021 at 5:37:38 PM UTC-5 Ian Lance Taylor wrote: > On Thu, May 27, 2021 at 3:33 PM Steven Penny wr

Re: [go-nuts] unexpected EOF with fmt.Scanner

2021-05-27 Thread Steven Penny
Did you even look at my example? If EOF is not right, then what is? How do I do what Im trying to do? On Thursday, May 27, 2021 at 4:37:38 PM UTC-5 Ian Lance Taylor wrote: > On Thu, May 27, 2021 at 2:25 PM Steven Penny wrote: > > > > Ian, that doesnt make sense. Then how will t

Re: [go-nuts] unexpected EOF with fmt.Scanner

2021-05-27 Thread Steven Penny
6 PM UTC-5 Ian Lance Taylor wrote: > On Thu, May 27, 2021 at 6:41 AM Steven Penny wrote: > > > > If I want to scan through a string, I can do this: > > > > ~~~go > > package main > > > > import ( > > "fmt" > > "strings" >

[go-nuts] unexpected EOF with fmt.Scanner

2021-05-27 Thread Steven Penny
If I want to scan through a string, I can do this: ~~~go package main import ( "fmt" "strings" ) func main() { r := strings.NewReader("west north east") for { var s string _, e := fmt.Fscan(r, ) fmt.Printf("%q %v\n", s, e) if e != nil { break } } } ~~~

[go-nuts] Go update all modules

2021-04-21 Thread Steven Penny
Using this module as an example (using a specific commit so others will see what I see): ~~~ git clone git://github.com/walles/moar Set-Location moar git checkout d24acdbf ~~~ I would like a way to tell Go to "update everything". Assume that the module will work with the newest version of