>
> I'm not sure what you mean when you say that io.EOF is not treated as an
> error. io.EOF is an error: it implements the error interface, and is
> returned as the error value by methods such as Read.
I am mediocre at best at programming and I'm quite a picky person, so I
just have a problem with wrapping my head around texts like this below,
which is a documentation of io.ReadAll. Nothing more.
ReadAll reads from r until an error or EOF and returns the data it read. A
> successful call returns err == nil, not err == EOF. Because ReadAll is
> defined to read from src until EOF, it does not treat an EOF from Read as
> an error to be reported.
>
This mental dissonans is probably caused by the simple fact that I think
about error as information that something doesn't work as it should, but
arriving at the end of the file means that we are where we should be.
But that doesn't mean that it's not an error. The Read failed. Every
> failure is reported via an error. For the case in which Read fails because
> it reaches the end of the file, the error that it returns is io.EOF.
>
Thank you very much. I will try to digest that io.EOF means that Read
fails, so this is an error of Read method/function. I never think about it
that way.
Best
Kamil
czw., 7 paź 2021 o 06:25 peterGo <go.peter...@gmail.com> napisał(a):
> Kamil,
>
> A Go interface implements a particular behavior. For example, io.Reader is
> the interface that wraps the basic Read method.
>
> type Reader interface {
> Read(p []byte) (n int, err error)
> }
>
> The outcome of the Read method ranges from good to catastrophic failure.
> The outcome is reported in the err error type return value. The err return
> value for good is nil. For a finite stream of data, a particular outcome of
> interest is end-of-file.
>
> var EOF = errors.New("EOF")
>
> io.EOF is the error returned by Read when no more input is available.
>
> See package io.
> https://pkg.go.dev/io
>
> Peter
>
> On Wednesday, October 6, 2021 at 5:35:11 PM UTC-4 kziem...@gmail.com
> wrote:
>
>> Hello,
>>
>> I currently read about "io" package and again I read that "io.EOF" is not
>> treated as error, since it is what you expect to end file, which is almost
>> tautology. At the same time it satisfies error interface and is created
>> busing errors.New function.
>>
>> I understand why this is done, doing it other way would probably make
>> serious mess in the code, but pedantic said of me is unsettled by this.
>> Does any experience Gopher can give my advice how to think about situation
>> when some object satisfy interface, but it is exception that proves the
>> rule? I should just get used to it, or is it some better way of thinking?
>>
>> Best
>> Kamil
>>
>> sobota, 4 września 2021 o 23:28:20 UTC+2 Brian Candler napisał(a):
>>
>>> Ah, I missed the bit where it says "Flag syntax is xyz (set)
>>> or -xyz (clear) or xy-z (set xy, clear z)." You're quite right, there's a
>>> much simpler way:
>>> https://play.golang.org/p/upupUQUcsR8
>>>
>>> On Saturday, 4 September 2021 at 20:51:53 UTC+1 kziem...@gmail.com
>>> wrote:
>>>
>>>> Thank you for your answer and opinion Briana Candler.
>>>>
>>>> I ask about unset only because of the cryptic text, at least to me, in
>>>> the description of RE2 (https://github.com/google/re2/wiki/Syntax).
>>>> From practical point of view, your solutions look good.
>>>>
>>>> I try to google about changes in examples in Go's stdlib, maybe this
>>>> can be done?
>>>>
>>>> Best
>>>> Kamil
>>>>
>>>> pt., 3 wrz 2021 o 21:42 Brian Candler <b.ca...@pobox.com> napisał(a):
>>>>
>>>>> I believe (?m) applies to the current group only; if you want to
>>>>> "unset" it then start a separate group.
>>>>> https://play.golang.org/p/wT_ZTrUSABL
>>>>>
>>>>> And I think you're right, there's no need to have capture groups for
>>>>> FindIndex.
>>>>>
>>>>> On Friday, 3 September 2021 at 20:33:14 UTC+1 kziem...@gmail.com
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> My struggles with regexp is going and I have another problem. I read
>>>>>> closely syntax page of RE2 (https://github.com/google/re2/wiki/Syntax)
>>>>>> and I still not sure if I understand one example from regexp package.
>>>>>>
>>>>>> In example in method func (*Regexp) FindIndex (
>>>>>> https://pkg.go.dev/reg...@go1.17#Regexp.FindIndex
>>>>>> <https://pkg.go.dev/regexp@go1.17#Regexp.FindIndex>) we have line
>>>>>>
>>>>>> pattern := regexp.MustCompile(`(?m)(?P<key>\w+):\s+(?P<value>\w+)$`)
>>>>>>
>>>>>> Does (?m) set value of flag m to true and if I want set it to false I
>>>>>> should write (?-m) or not? By default m should be false, but as example
>>>>>> it
>>>>>> is fine.
>>>>>>
>>>>>> As a side note, this regular expression is used in other examples,
>>>>>> when we need <key> and <value>, but looks unnecessary complex for method
>>>>>> FindIndex. I guess
>>>>>> `(?m)\w+:\s+\w+$`
>>>>>> would work fine. Am I wrong?
>>>>>>
>>>>>> Best
>>>>>> Kamil
>>>>>>
>>>>>> środa, 1 września 2021 o 12:29:58 UTC+2 Kamil Ziemian napisał(a):
>>>>>>
>>>>>>> Kurtis Rader, peterGo thank you for the answers. I probably need to
>>>>>>> learn more about RPC protocols, for now I can only expand acronym. But
>>>>>>> this
>>>>>>> point with ignoring leading zeros is clear enough. And probalby more
>>>>>>> "elementary (and stupid)?" questions is comming.
>>>>>>>
>>>>>>> Kamil
>>>>>>> poniedziałek, 30 sierpnia 2021 o 03:02:51 UTC+2 peterGo napisał(a):
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> K,
>>>>>>>>
>>>>>>>> For a finite, unsigned binary number, ignoring leading zeros, how
>>>>>>>> many binary digits (the length in bits) are needed to represent a
>>>>>>>> number?
>>>>>>>>
>>>>>>>> Peter
>>>>>>>> On Sunday, August 29, 2021 at 4:07:41 PM UTC-4 kziem...@gmail.com
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Thank for explanation, but I don't understand "But how many bits
>>>>>>>>> do you need to represent 0? The question is malformed as there are no
>>>>>>>>> set
>>>>>>>>> bits in the used representation of 0.". Why this is malformed
>>>>>>>>> questions?
>>>>>>>>> When I think of coding 1, I think about thaking one bit with 1 inside
>>>>>>>>> and
>>>>>>>>> when it goes to 0, I would take one bit with 0 inside.
>>>>>>>>>
>>>>>>>>> K.
>>>>>>>>> piątek, 27 sierpnia 2021 o 07:14:45 UTC+2 Volker Dobler napisał(a):
>>>>>>>>>
>>>>>>>>>> On Thursday, 26 August 2021 at 22:17:55 UTC+2 kziem...@gmail.com
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Another topic. I needed to check package "math/bits" (learning
>>>>>>>>>>> about Go can lead us in such places quite fast) and I'm confused
>>>>>>>>>>> about
>>>>>>>>>>> function "Len(x uint) int". In its description we have (
>>>>>>>>>>> https://pkg.go.dev/math/bi...@go1.17
>>>>>>>>>>> <https://pkg.go.dev/math/bits@go1.17>)
>>>>>>>>>>> BEGINNING
>>>>>>>>>>> Len returns the minimum number of bits required to represent x;
>>>>>>>>>>> the result is 0 for x == 0.
>>>>>>>>>>> END
>>>>>>>>>>> I have no problem with using function that says 0 can be encoded
>>>>>>>>>>> in 0 bits, but it is still odd. Maybe it is connected to something
>>>>>>>>>>> done
>>>>>>>>>>> under the hood, about which I don't know a thing? Does anyone know
>>>>>>>>>>> why this
>>>>>>>>>>> choose was made?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No, the description doesn't say that 0 can be encoded in 0 bits:
>>>>>>>>>> It says that Len(0) returns 0.
>>>>>>>>>> If you want Len to be a total function you must return a value
>>>>>>>>>> for every input.
>>>>>>>>>> For most inputs the value is strictly determined by what the
>>>>>>>>>> functions does
>>>>>>>>>> (number of bits needed to represent), so Len(9) == 3. But how
>>>>>>>>>> many bits
>>>>>>>>>> do you need to represent 0? The question is malformed as there
>>>>>>>>>> are no
>>>>>>>>>> set bits in the used representation of 0. One could have declared
>>>>>>>>>> "Len(0) returns -42"
>>>>>>>>>> but this makes no sense at all. Having Len(0)==0 results in
>>>>>>>>>> Len(a) <= Len(b) if a < b without having to invent totally
>>>>>>>>>> arbitrary
>>>>>>>>>> values for Len(0).
>>>>>>>>>>
>>>>>>>>>> You probably should not overinterpret Go's documentation.
>>>>>>>>>> This is not lyric. "the result is 0 for x == 0" has no hidden
>>>>>>>>>> meaning.
>>>>>>>>>>
>>>>>>>>>> V.
>>>>>>>>>>
>>>>>>>>> --
>>>>> You received this message because you are subscribed to a topic in the
>>>>> Google Groups "golang-nuts" group.
>>>>> To unsubscribe from this topic, visit
>>>>> https://groups.google.com/d/topic/golang-nuts/RPPfjiuSRHU/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>> golang-nuts...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/golang-nuts/94d8c404-3c25-4897-a582-93b67c6b923an%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/golang-nuts/94d8c404-3c25-4897-a582-93b67c6b923an%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/RPPfjiuSRHU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9209890e-aa3a-4822-a680-bed6b1804b39n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/9209890e-aa3a-4822-a680-bed6b1804b39n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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 on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAB3gO8p-wSE-C5zy2fjM8frTSLPpMhWcibgecKWz5PPfk4QTng%40mail.gmail.com.
