Re: [go-nuts] Find biggest memory holder
Is that really true though I am thinking the OP has pointers in global variables, and the size of the objects pointed to are changing. The question is not very clear though. > On Feb 7, 2019, at 12:33 PM, Ian Lance Taylor wrote: > > On Thu, Feb 7, 2019 at 2:33 AM Thomas S wrote: >> >> But now, to go forward, I need a monitoring of my globals variables. >> And not of the "run consumption" of ram. >> >> Any ideas on how to do this efficiently ? > > The size of your global variables doesn't change during execution of > your program, of course. If you are using GNU/Linux you can see the > size of each separate global variable by running "readelf -s BINARY" > and looking at the "Size" column. > > Ian > > -- > 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. > For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] I Developed TUI tool for Docker.
Hello Everyone. I Developed TUI tool for Docker. If you interested, Please read this. https://medium.com/@sho19921005/i-developed-tui-tool-for-docker-ebf48da51c6a I am waiting for your impressions. Thank you. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] A Measure of Hash Function Collisions
On Tuesday, February 5, 2019 at 12:29:32 AM UTC+3, Michael Jones wrote: > I recently did just this in an effort (successful!) to make a well-known > simple hash function be its best with minor single CPU cycle changes. > yes I am told 15 is not the best shift amount, how about this? x = x<<27 ^ x>>37 the upper limit of length sum could be 9, because hashes of 9-byte valid utf8 strings are less than 255^9, on average ~247 per uin64 value, so one such uint64 value most likely will be zero which is the hash of empty string. so you get a length sum of 9. can you bring it down? or can we "design" a hash to guarantee 9? -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Request Content Length zero when copy from another Request
I am not following. You stated that the usage of Len was internal and a type
switch on known concrete types, so how is related to how the OP was attempting
to have things work?
There is no “generally accepted use of Len()”, otherwise it would not need to
perform a type switch on known concrete types - it would cast to an interface
declaring Len(), and use the interface, and then it would work with any type.
> On Feb 7, 2019, at 1:07 PM, Dan Kortschak wrote:
>
> Yeah, I'm not agreeing with you.
>
> On Thu, 2019-02-07 at 07:07 -0600, Robert Engels wrote:
>> You are agreeing with me. A type switch on concrete types (that you
>> control) is far different than using an available Len() method and
>> assuming the same semantics.
>>
>>>
>>> On Feb 7, 2019, at 1:05 AM, Dan Kortschak wrote:
>>>
>>> Addressing the first sentence, it was a direct answer to a comment
>>> you
>>> made:
>>>
But is it really? If you read the description for Len() on
bytes.Buffer it is the length of unread portion. But that doesn’t
mean the buffer isn’t just a portion of the entire body - it can
be a
chunk which is continually reloaded.
>>> As far as the claim that there is a need to have a Len method in
>>> io.Reader, have a look at the code in question. It type asserts on
>>> three concrete types that are known to the function, all three have
>>> a
>>> Len method and this is used to obtain the known length. All other
>>> io.Readers are considered to have an unknown length.
>>>
>>> Whether it's wrong to use Len depends on whether there is a
>>> generally
>>> accepted and consistent set of semantics to Len() int. There is.
>>> This
>>> is strengthened if the use of an existing Len method is noted in
>>> the
>>> docs.
>>>
On Wed, 2019-02-06 at 15:50 -0600, robert engels wrote:
I am not sure what that has to do with the discussion. My point
was
that for it to be applicable here, it needs to be defined as part
of
io.Reader, since that is what Body is declared as. It is not, so
using in the manner outlined is not correct IMO.
>
>
> On Feb 6, 2019, at 3:37 PM, Dan Kortschak
> wrote:
>
> The generalised semantics of Len are that it returns the number
> of
> available elements in the collection, being a cognate of the
> len
> built-
> in. This means that as you consume elements from a buffer, the
> Len
> value reduces. This is directly equivalent to
>
> for len(buf) != 0 {
>println(buf[0])
>buf = buf[1:]
> }
>
>>
>> On Wed, 2019-02-06 at 08:56 -0600, Robert Engels wrote:
>>
>> But is it really? If you read the description for Len() on
>> bytes.Buffer it is the length of unread portion. But that
>> doesn’t
>> mean the buffer isn’t just a portion of the entire body - it
>> can
>> be a
>> chunk which is continually reloaded.
>>
>> This is the danger in using private APIs publically based
>> upon
>> the
>> existence of a method - it leads to very brittle code - and
>> there
>> are
>> almost certainly better ways to design it to avoid these
>> issues.
>> If
>> the core api is not expressive enough then it will be more
>> difficult.
>>
>>>
>>>
>>>
>>> On Feb 6, 2019, at 8:30 AM, Burak Serdar
>>> wrote:
>>>
On Wed, Feb 6, 2019 at 5:15 AM Robert Engels >>> netc
om.c
om> wrote:
I see now, but if that can be the case, shouldn’t the
Body be
documented that the Reader may be a ReaderWithLen, and
the
consumer is free to type check/cast? If not, you are
using
internal details that you should not be.
>>> Yes, the documentation should say if the reader has a Len()
>>> method
>>> it
>>> would be used to set the ContentLength. Len is no longer an
>>> internal
>>> detail then.
>>>
This is a problem with Go in general. Because the
returned
object
“implements” some interface because it happens to have
the
required method, doesn’t mean it was designed to be used
that
way, or that it has the required semantics - unless
documented to
have them.
>>> I agree with you there. Len() is straight forward, but in
>>> general
>>> just
>>> because a function is named something doesn't mean it'll do
>>> the
>>> same
>>> thing for all implementations. On the other end of the
>>> spectrum
>>> is
>>> Java-like interfaces where you want explicit inheritance of
>>> a
>>> specific
>>> interface. I don't know if there's anything in between, but
>>> I
>>> like
>>> Go's approach much better.
>>>
Re: [go-nuts] Request Content Length zero when copy from another Request
I didn't mention the word internal, nor did I imply it; with
documentation stating that it would be used, it is clearly *not*
internal.
If you look at the code in question, you can see a probable reason why
a Lener interface is not used; for each of the blessed types, a
concrete copy of the pointed-to-value is made to allow GetBody to
return it. This cannot be done with an interface value without the use
of reflect.
Please show me a Len method in the standard library that does not
return the number of available-to-access elements in a collection.
On Thu, 2019-02-07 at 13:27 -0600, robert engels wrote:
> I am not following. You stated that the usage of Len was internal and
> a type switch on known concrete types, so how is related to how the
> OP was attempting to have things work?
>
> There is no “generally accepted use of Len()”, otherwise it would not
> need to perform a type switch on known concrete types - it would cast
> to an interface declaring Len(), and use the interface, and then it
> would work with any type.
>
> >
> > On Feb 7, 2019, at 1:07 PM, Dan Kortschak wrote:
> >
> > Yeah, I'm not agreeing with you.
> >
> > On Thu, 2019-02-07 at 07:07 -0600, Robert Engels wrote:
> > >
> > > You are agreeing with me. A type switch on concrete types (that
> > > you
> > > control) is far different than using an available Len() method
> > > and
> > > assuming the same semantics.
> > >
> > > >
> > > >
> > > > On Feb 7, 2019, at 1:05 AM, Dan Kortschak
> > > > wrote:
> > > >
> > > > Addressing the first sentence, it was a direct answer to a
> > > > comment
> > > > you
> > > > made:
> > > >
> > > > >
> > > > >
> > > > > But is it really? If you read the description for Len() on
> > > > > bytes.Buffer it is the length of unread portion. But that
> > > > > doesn’t
> > > > > mean the buffer isn’t just a portion of the entire body - it
> > > > > can
> > > > > be a
> > > > > chunk which is continually reloaded.
> > > > As far as the claim that there is a need to have a Len method
> > > > in
> > > > io.Reader, have a look at the code in question. It type asserts
> > > > on
> > > > three concrete types that are known to the function, all three
> > > > have
> > > > a
> > > > Len method and this is used to obtain the known length. All
> > > > other
> > > > io.Readers are considered to have an unknown length.
> > > >
> > > > Whether it's wrong to use Len depends on whether there is a
> > > > generally
> > > > accepted and consistent set of semantics to Len() int. There
> > > > is.
> > > > This
> > > > is strengthened if the use of an existing Len method is noted
> > > > in
> > > > the
> > > > docs.
> > > >
> > > > >
> > > > >
> > > > > On Wed, 2019-02-06 at 15:50 -0600, robert engels wrote:
> > > > > I am not sure what that has to do with the discussion. My
> > > > > point
> > > > > was
> > > > > that for it to be applicable here, it needs to be defined as
> > > > > part
> > > > > of
> > > > > io.Reader, since that is what Body is declared as. It is not,
> > > > > so
> > > > > using in the manner outlined is not correct IMO.
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Feb 6, 2019, at 3:37 PM, Dan Kortschak > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > The generalised semantics of Len are that it returns the
> > > > > > number
> > > > > > of
> > > > > > available elements in the collection, being a cognate of
> > > > > > the
> > > > > > len
> > > > > > built-
> > > > > > in. This means that as you consume elements from a buffer,
> > > > > > the
> > > > > > Len
> > > > > > value reduces. This is directly equivalent to
> > > > > >
> > > > > > for len(buf) != 0 {
> > > > > > println(buf[0])
> > > > > > buf = buf[1:]
> > > > > > }
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, 2019-02-06 at 08:56 -0600, Robert Engels wrote:
> > > > > > >
> > > > > > > But is it really? If you read the description for Len()
> > > > > > > on
> > > > > > > bytes.Buffer it is the length of unread portion. But that
> > > > > > > doesn’t
> > > > > > > mean the buffer isn’t just a portion of the entire body -
> > > > > > > it
> > > > > > > can
> > > > > > > be a
> > > > > > > chunk which is continually reloaded.
> > > > > > >
> > > > > > > This is the danger in using private APIs publically based
> > > > > > > upon
> > > > > > > the
> > > > > > > existence of a method - it leads to very brittle code -
> > > > > > > and
> > > > > > > there
> > > > > > > are
> > > > > > > almost certainly better ways to design it to avoid these
> > > > > > > issues.
> > > > > > > If
> > > > > > > the core api is not expressive enough then it will be
> > > > > > > more
> > > > > > > difficult.
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Feb 6, 2019, at 8:30 AM, Burak Serdar > > > > > > > org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On
Re: [go-nuts] Request Content Length zero when copy from another Request
Yeah, I'm not agreeing with you.
On Thu, 2019-02-07 at 07:07 -0600, Robert Engels wrote:
> You are agreeing with me. A type switch on concrete types (that you
> control) is far different than using an available Len() method and
> assuming the same semantics.
>
> >
> > On Feb 7, 2019, at 1:05 AM, Dan Kortschak wrote:
> >
> > Addressing the first sentence, it was a direct answer to a comment
> > you
> > made:
> >
> > >
> > > But is it really? If you read the description for Len() on
> > > bytes.Buffer it is the length of unread portion. But that doesn’t
> > > mean the buffer isn’t just a portion of the entire body - it can
> > > be a
> > > chunk which is continually reloaded.
> > As far as the claim that there is a need to have a Len method in
> > io.Reader, have a look at the code in question. It type asserts on
> > three concrete types that are known to the function, all three have
> > a
> > Len method and this is used to obtain the known length. All other
> > io.Readers are considered to have an unknown length.
> >
> > Whether it's wrong to use Len depends on whether there is a
> > generally
> > accepted and consistent set of semantics to Len() int. There is.
> > This
> > is strengthened if the use of an existing Len method is noted in
> > the
> > docs.
> >
> > >
> > > On Wed, 2019-02-06 at 15:50 -0600, robert engels wrote:
> > > I am not sure what that has to do with the discussion. My point
> > > was
> > > that for it to be applicable here, it needs to be defined as part
> > > of
> > > io.Reader, since that is what Body is declared as. It is not, so
> > > using in the manner outlined is not correct IMO.
> > >
> > > >
> > > >
> > > > On Feb 6, 2019, at 3:37 PM, Dan Kortschak
> > > > wrote:
> > > >
> > > > The generalised semantics of Len are that it returns the number
> > > > of
> > > > available elements in the collection, being a cognate of the
> > > > len
> > > > built-
> > > > in. This means that as you consume elements from a buffer, the
> > > > Len
> > > > value reduces. This is directly equivalent to
> > > >
> > > > for len(buf) != 0 {
> > > > println(buf[0])
> > > > buf = buf[1:]
> > > > }
> > > >
> > > > >
> > > > > On Wed, 2019-02-06 at 08:56 -0600, Robert Engels wrote:
> > > > >
> > > > > But is it really? If you read the description for Len() on
> > > > > bytes.Buffer it is the length of unread portion. But that
> > > > > doesn’t
> > > > > mean the buffer isn’t just a portion of the entire body - it
> > > > > can
> > > > > be a
> > > > > chunk which is continually reloaded.
> > > > >
> > > > > This is the danger in using private APIs publically based
> > > > > upon
> > > > > the
> > > > > existence of a method - it leads to very brittle code - and
> > > > > there
> > > > > are
> > > > > almost certainly better ways to design it to avoid these
> > > > > issues.
> > > > > If
> > > > > the core api is not expressive enough then it will be more
> > > > > difficult.
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Feb 6, 2019, at 8:30 AM, Burak Serdar
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Feb 6, 2019 at 5:15 AM Robert Engels > > > > > > netc
> > > > > > > om.c
> > > > > > > om> wrote:
> > > > > > >
> > > > > > > I see now, but if that can be the case, shouldn’t the
> > > > > > > Body be
> > > > > > > documented that the Reader may be a ReaderWithLen, and
> > > > > > > the
> > > > > > > consumer is free to type check/cast? If not, you are
> > > > > > > using
> > > > > > > internal details that you should not be.
> > > > > > Yes, the documentation should say if the reader has a Len()
> > > > > > method
> > > > > > it
> > > > > > would be used to set the ContentLength. Len is no longer an
> > > > > > internal
> > > > > > detail then.
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > This is a problem with Go in general. Because the
> > > > > > > returned
> > > > > > > object
> > > > > > > “implements” some interface because it happens to have
> > > > > > > the
> > > > > > > required method, doesn’t mean it was designed to be used
> > > > > > > that
> > > > > > > way, or that it has the required semantics - unless
> > > > > > > documented to
> > > > > > > have them.
> > > > > > I agree with you there. Len() is straight forward, but in
> > > > > > general
> > > > > > just
> > > > > > because a function is named something doesn't mean it'll do
> > > > > > the
> > > > > > same
> > > > > > thing for all implementations. On the other end of the
> > > > > > spectrum
> > > > > > is
> > > > > > Java-like interfaces where you want explicit inheritance of
> > > > > > a
> > > > > > specific
> > > > > > interface. I don't know if there's anything in between, but
> > > > > > I
> > > > > > like
> > > > > > Go's approach much better.
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Feb 6, 2019, at 2:22 AM, Matteo Biagetti
> > > > >
Re: [go-nuts] Find biggest memory holder
On Thu, Feb 7, 2019 at 2:33 AM Thomas S wrote: > > But now, to go forward, I need a monitoring of my globals variables. > And not of the "run consumption" of ram. > > Any ideas on how to do this efficiently ? The size of your global variables doesn't change during execution of your program, of course. If you are using GNU/Linux you can see the size of each separate global variable by running "readelf -s BINARY" and looking at the "Size" column. Ian -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Request Content Length zero when copy from another Request
Their is an assumption in the code that users don't mutate values under the feet of routines that have been called. The copy does not protect against that and is not designed for that purpose; it is there to make the GetBody function return a zeroed copy of the body (for some definition of zeroed - zero is the state that was handed in to the NewRequest call). If the behaviour of the copy here is broken, any Go code that causes a slice, map or pointer to be retained is broken since the user can mutate the backing data after the call has done work on it. This becomes a philosophical point. There is a simple work around (not as simple as having NewRequest Just Do The Right Thing™, but reasonable) that does not require reflect and puts the control in the users' hands. Since the ContentLength and GetBody fields are exported, they can be set after the return of NewRequest in the same way that NewRequest does for the blessed types, but with the users' knowledge of internal behaviours of their types. An example of this is here https://bitbucket.org/ausocean/iot/pull-requ ests/42 On Thu, 2019-02-07 at 14:55 -0600, robert engels wrote: > I see the documented use of the types in NewRequest - you are correct > - I was wrong. > > But, it could of easily also declared that if the provided Reader is > also a Lener, it uses it to determine the content length. Why have > this behavior for Closer and not for Lener? Then you don’t need the > type switch. You say, well the copy... > > The current code with the copy is broken - the caller could continue > to modify the contents of the bytes.Buffer and things would not work > as expected since the backing array of the slice is shared - so how > is the copy helping ? The length will remain the same, but the data > represented could be corrupted. > > The correct solution is to declare that NewRequest takes an interface > Content, that has both Reader and ContentLength methods, where > ContentLength() can return -1 if the content length is indeterminate. > Then declare simple facades for Content from bytes.Buffer, a string, > etc. And also declare that continued use of the Content after > NewRequest is undefined. And if you wanted to retain the simplicity, > just declare it uses ContentLength like it uses Closer. > > I am all for the simplicity of Go, but “solutions" like NewRequest > are not the way modern software should be developed. Casting an > interface to a concrete type is a sign of code that needs design > work. Having to read the doc in addition to the method signature is > also a sign the interface needs work (primarily since changes to the > doc can/will/might change behavior but it avoids compile time type > checking = brittle code with obscure bugs). > > > > > > On Feb 7, 2019, at 1:56 PM, Dan Kortschak wrote: > > > > I didn't mention the word internal, nor did I imply it; with > > documentation stating that it would be used, it is clearly *not* > > internal. > > > > If you look at the code in question, you can see a probable reason > > why > > a Lener interface is not used; for each of the blessed types, a > > concrete copy of the pointed-to-value is made to allow GetBody to > > return it. This cannot be done with an interface value without the > > use > > of reflect. > > > > Please show me a Len method in the standard library that does not > > return the number of available-to-access elements in a collection. > > > > > > On Thu, 2019-02-07 at 13:27 -0600, robert engels wrote: > > > > > > I am not following. You stated that the usage of Len was internal > > > and > > > a type switch on known concrete types, so how is related to how > > > the > > > OP was attempting to have things work? > > > > > > There is no “generally accepted use of Len()”, otherwise it would > > > not > > > need to perform a type switch on known concrete types - it would > > > cast > > > to an interface declaring Len(), and use the interface, and then > > > it > > > would work with any type. > > > > > > > > > > > > > > > On Feb 7, 2019, at 1:07 PM, Dan Kortschak > > > > wrote: > > > > > > > > Yeah, I'm not agreeing with you. > > > > > > > > On Thu, 2019-02-07 at 07:07 -0600, Robert Engels wrote: > > > > > > > > > > > > > > > You are agreeing with me. A type switch on concrete types > > > > > (that > > > > > you > > > > > control) is far different than using an available Len() > > > > > method > > > > > and > > > > > assuming the same semantics. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Feb 7, 2019, at 1:05 AM, Dan Kortschak > > > > > > > > > > > > wrote: > > > > > > > > > > > > Addressing the first sentence, it was a direct answer to a > > > > > > comment > > > > > > you > > > > > > made: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But is it really? If you read the description for Len() > > > > > > > on > > > > > > > bytes.Buffer it is the length of unread portion. But that > > > > > > > doesn’t > > > > > > > mean
[go-nuts] Re: About 64bits alignment
Is the bug zone outdated now. How about the support on other 32-bit archs? Such as mips? On Wednesday, February 1, 2017 at 12:03:59 PM UTC-4, T L wrote: > > the sync/atomic docs, https://golang.org/pkg/sync/atomic/, says in the > end of the docs > > > On x86-32, the 64-bit functions use instructions unavailable before the >> Pentium MMX. >> > On non-Linux ARM, the 64-bit functions use instructions unavailable before >> the ARMv6k core. >> >> On both ARM and x86-32, it is the caller's responsibility to arrange for >> 64-bit alignment of 64-bit words accessed atomically. >> > The first word in a global variable or in an allocated struct or slice can >> be relied upon to be 64-bit aligned. >> > > The last line says the first word in a global variable or in an allocated > struct or slice is 64-bit aligned for sure. > But what does an allocated struct or slice means? A struct or slice > allocated on heap, not stack? > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Request Content Length zero when copy from another Request
And to come full circle, this poorly declared method, with hidden internal implementation details, is exactly the cause of OP’s initial problem. Not expecting that the Body passed in, and retrieved later could be used as a Body of a new request - why wouldn’t he think that ? > On Feb 7, 2019, at 2:55 PM, robert engels wrote: > > I see the documented use of the types in NewRequest - you are correct - I was > wrong. > > But, it could of easily also declared that if the provided Reader is also a > Lener, it uses it to determine the content length. Why have this behavior for > Closer and not for Lener? Then you don’t need the type switch. You say, well > the copy... > > The current code with the copy is broken - the caller could continue to > modify the contents of the bytes.Buffer and things would not work as expected > since the backing array of the slice is shared - so how is the copy helping ? > The length will remain the same, but the data represented could be corrupted. > > The correct solution is to declare that NewRequest takes an interface > Content, that has both Reader and ContentLength methods, where > ContentLength() can return -1 if the content length is indeterminate. Then > declare simple facades for Content from bytes.Buffer, a string, etc. And also > declare that continued use of the Content after NewRequest is undefined. And > if you wanted to retain the simplicity, just declare it uses ContentLength > like it uses Closer. > > I am all for the simplicity of Go, but “solutions" like NewRequest are not > the way modern software should be developed. Casting an interface to a > concrete type is a sign of code that needs design work. Having to read the > doc in addition to the method signature is also a sign the interface needs > work (primarily since changes to the doc can/will/might change behavior but > it avoids compile time type checking = brittle code with obscure bugs). > > >> On Feb 7, 2019, at 1:56 PM, Dan Kortschak wrote: >> >> I didn't mention the word internal, nor did I imply it; with >> documentation stating that it would be used, it is clearly *not* >> internal. >> >> If you look at the code in question, you can see a probable reason why >> a Lener interface is not used; for each of the blessed types, a >> concrete copy of the pointed-to-value is made to allow GetBody to >> return it. This cannot be done with an interface value without the use >> of reflect. >> >> Please show me a Len method in the standard library that does not >> return the number of available-to-access elements in a collection. >> >> >> On Thu, 2019-02-07 at 13:27 -0600, robert engels wrote: >>> I am not following. You stated that the usage of Len was internal and >>> a type switch on known concrete types, so how is related to how the >>> OP was attempting to have things work? >>> >>> There is no “generally accepted use of Len()”, otherwise it would not >>> need to perform a type switch on known concrete types - it would cast >>> to an interface declaring Len(), and use the interface, and then it >>> would work with any type. >>> On Feb 7, 2019, at 1:07 PM, Dan Kortschak wrote: Yeah, I'm not agreeing with you. On Thu, 2019-02-07 at 07:07 -0600, Robert Engels wrote: > > You are agreeing with me. A type switch on concrete types (that > you > control) is far different than using an available Len() method > and > assuming the same semantics. > >> >> >> On Feb 7, 2019, at 1:05 AM, Dan Kortschak >> wrote: >> >> Addressing the first sentence, it was a direct answer to a >> comment >> you >> made: >> >>> >>> >>> But is it really? If you read the description for Len() on >>> bytes.Buffer it is the length of unread portion. But that >>> doesn’t >>> mean the buffer isn’t just a portion of the entire body - it >>> can >>> be a >>> chunk which is continually reloaded. >> As far as the claim that there is a need to have a Len method >> in >> io.Reader, have a look at the code in question. It type asserts >> on >> three concrete types that are known to the function, all three >> have >> a >> Len method and this is used to obtain the known length. All >> other >> io.Readers are considered to have an unknown length. >> >> Whether it's wrong to use Len depends on whether there is a >> generally >> accepted and consistent set of semantics to Len() int. There >> is. >> This >> is strengthened if the use of an existing Len method is noted >> in >> the >> docs. >> >>> >>> >>> On Wed, 2019-02-06 at 15:50 -0600, robert engels wrote: >>> I am not sure what that has to do with the discussion. My >>> point >>> was >>> that for it to be applicable here, it needs to be defined as >>> part >>> of >>> io.Reader, since that is what
Re: [go-nuts] Request Content Length zero when copy from another Request
So GetBody just fails… It returns NoBody in this case.. which means calling code will just break (when the original request is not one of the known types). So, according to the referenced issue, 307/308 redirects won’t work when the underlying request is not a known type. This is a very brittle API IMO. If you need to do stuff like this, the readers should be using mark/reset etc with buffered streams, not relying on special cased functions like GetBody that don’t work in all cases. > On Feb 7, 2019, at 3:42 PM, Dan Kortschak wrote: > > Keeping a zeroed state is important for the GetBody func because the > io.ReadCloser returned by GetBody can be read and closed. If there is > no zero state for the next time GetBody is called, it is not > idempotent. This would break the whole point of it existing. > > See https://go-review.googlesource.com/c/go/+/31733/ > > On Thu, 2019-02-07 at 15:33 -0600, robert engels wrote: >> I agree with you on the correct solution - vs. the OP’s request of >> the GetWrapped method. >> >> I guess I still don’t understand the “zeroed” concern though. If you >> adhere to the “don’t mutate values…” then why do the zero copy at all >> ? The state of the body should still be the state it was passed in as >> (unless the caller was breaking the aforementioned rule anyway…). >> >> Having “blessed types” is not a good design IMO - better to just >> declare the required interfaces and use those - especially when the >> object being provided as a parameter is already an interface… just >> seems lazy… (and long-term error prone). >> >> >> >>> >>> On Feb 7, 2019, at 3:05 PM, Dan Kortschak wrote: >>> >>> Their is an assumption in the code that users don't mutate values >>> under >>> the feet of routines that have been called. The copy does not >>> protect >>> against that and is not designed for that purpose; it is there to >>> make >>> the GetBody function return a zeroed copy of the body (for some >>> definition of zeroed - zero is the state that was handed in to the >>> NewRequest call). If the behaviour of the copy here is broken, any >>> Go >>> code that causes a slice, map or pointer to be retained is broken >>> since >>> the user can mutate the backing data after the call has done work >>> on >>> it. This becomes a philosophical point. >>> >>> There is a simple work around (not as simple as having NewRequest >>> Just >>> Do The Right Thing™, but reasonable) that does not require reflect >>> and >>> puts the control in the users' hands. Since the ContentLength and >>> GetBody fields are exported, they can be set after the return of >>> NewRequest in the same way that NewRequest does for the blessed >>> types, >>> but with the users' knowledge of internal behaviours of their >>> types. >>> >>> An example of this is here https://bitbucket.org/ausocean/iot/pull- >>> requ >>> ests/42 >>> >>> On Thu, 2019-02-07 at 14:55 -0600, robert engels wrote: I see the documented use of the types in NewRequest - you are correct - I was wrong. But, it could of easily also declared that if the provided Reader is also a Lener, it uses it to determine the content length. Why have this behavior for Closer and not for Lener? Then you don’t need the type switch. You say, well the copy... The current code with the copy is broken - the caller could continue to modify the contents of the bytes.Buffer and things would not work as expected since the backing array of the slice is shared - so how is the copy helping ? The length will remain the same, but the data represented could be corrupted. The correct solution is to declare that NewRequest takes an interface Content, that has both Reader and ContentLength methods, where ContentLength() can return -1 if the content length is indeterminate. Then declare simple facades for Content from bytes.Buffer, a string, etc. And also declare that continued use of the Content after NewRequest is undefined. And if you wanted to retain the simplicity, just declare it uses ContentLength like it uses Closer. I am all for the simplicity of Go, but “solutions" like NewRequest are not the way modern software should be developed. Casting an interface to a concrete type is a sign of code that needs design work. Having to read the doc in addition to the method signature is also a sign the interface needs work (primarily since changes to the doc can/will/might change behavior but it avoids compile time type checking = brittle code with obscure bugs). > > > On Feb 7, 2019, at 1:56 PM, Dan Kortschak > wrote: > > I didn't mention the word internal, nor did I imply it; with > documentation stating that it would be used, it is clearly > *not* > internal. > > If you look at the
[go-nuts] Providing more detail after a nil pointer dereference
After reading https://golang.org/issues/27605 (proposal: report indexes for bounds failure), I started to wonder why we don't do something similar with nil pointer dereferences. I've more than once found myself in a situation where I'm inspecting a nil pointer dereference panic and it ends up on a line where any number of variables could have been the nil pointer in question. It would be helpful in these circumstances to get a message like "attempt to dereference variable 'myvar', which is a nil pointer" or something along those lines. Here is a toy example that causes a panic on a line where there are many variables that could have been the problematic nil pointer. https://play.golang.com/p/mmkOOU3M3lU My guess as to why I've never seen this in a language before is because dereferencing doesn't always happen on a named variable. For example, `getSomePointer().field` could result in a nil pointer dereference, but there's no variable name to put in the panic. Maybe then the panic message would be "attempt to dereference anonymous variable, which is a nil pointer", which is still slightly less ambiguous than the current panic message. Do you think a feature like this could be useful, even with its inherent limitations? -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] parse timestamp in Go
How can I parse the following timestamp in Go? date +%y%m%d%H%M%S%N 190207202017034235995 Thanks, Raj -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Request Content Length zero when copy from another Request
Keeping a zeroed state is important for the GetBody func because the io.ReadCloser returned by GetBody can be read and closed. If there is no zero state for the next time GetBody is called, it is not idempotent. This would break the whole point of it existing. See https://go-review.googlesource.com/c/go/+/31733/ On Thu, 2019-02-07 at 15:33 -0600, robert engels wrote: > I agree with you on the correct solution - vs. the OP’s request of > the GetWrapped method. > > I guess I still don’t understand the “zeroed” concern though. If you > adhere to the “don’t mutate values…” then why do the zero copy at all > ? The state of the body should still be the state it was passed in as > (unless the caller was breaking the aforementioned rule anyway…). > > Having “blessed types” is not a good design IMO - better to just > declare the required interfaces and use those - especially when the > object being provided as a parameter is already an interface… just > seems lazy… (and long-term error prone). > > > > > > > On Feb 7, 2019, at 3:05 PM, Dan Kortschak wrote: > > > > Their is an assumption in the code that users don't mutate values > > under > > the feet of routines that have been called. The copy does not > > protect > > against that and is not designed for that purpose; it is there to > > make > > the GetBody function return a zeroed copy of the body (for some > > definition of zeroed - zero is the state that was handed in to the > > NewRequest call). If the behaviour of the copy here is broken, any > > Go > > code that causes a slice, map or pointer to be retained is broken > > since > > the user can mutate the backing data after the call has done work > > on > > it. This becomes a philosophical point. > > > > There is a simple work around (not as simple as having NewRequest > > Just > > Do The Right Thing™, but reasonable) that does not require reflect > > and > > puts the control in the users' hands. Since the ContentLength and > > GetBody fields are exported, they can be set after the return of > > NewRequest in the same way that NewRequest does for the blessed > > types, > > but with the users' knowledge of internal behaviours of their > > types. > > > > An example of this is here https://bitbucket.org/ausocean/iot/pull- > > requ > > ests/42 > > > > On Thu, 2019-02-07 at 14:55 -0600, robert engels wrote: > > > > > > I see the documented use of the types in NewRequest - you are > > > correct > > > - I was wrong. > > > > > > But, it could of easily also declared that if the provided Reader > > > is > > > also a Lener, it uses it to determine the content length. Why > > > have > > > this behavior for Closer and not for Lener? Then you don’t need > > > the > > > type switch. You say, well the copy... > > > > > > The current code with the copy is broken - the caller could > > > continue > > > to modify the contents of the bytes.Buffer and things would not > > > work > > > as expected since the backing array of the slice is shared - so > > > how > > > is the copy helping ? The length will remain the same, but the > > > data > > > represented could be corrupted. > > > > > > The correct solution is to declare that NewRequest takes an > > > interface > > > Content, that has both Reader and ContentLength methods, where > > > ContentLength() can return -1 if the content length is > > > indeterminate. > > > Then declare simple facades for Content from bytes.Buffer, a > > > string, > > > etc. And also declare that continued use of the Content after > > > NewRequest is undefined. And if you wanted to retain the > > > simplicity, > > > just declare it uses ContentLength like it uses Closer. > > > > > > I am all for the simplicity of Go, but “solutions" like > > > NewRequest > > > are not the way modern software should be developed. Casting an > > > interface to a concrete type is a sign of code that needs design > > > work. Having to read the doc in addition to the method signature > > > is > > > also a sign the interface needs work (primarily since changes to > > > the > > > doc can/will/might change behavior but it avoids compile time > > > type > > > checking = brittle code with obscure bugs). > > > > > > > > > > > > > > > > > > On Feb 7, 2019, at 1:56 PM, Dan Kortschak > > > > wrote: > > > > > > > > I didn't mention the word internal, nor did I imply it; with > > > > documentation stating that it would be used, it is clearly > > > > *not* > > > > internal. > > > > > > > > If you look at the code in question, you can see a probable > > > > reason > > > > why > > > > a Lener interface is not used; for each of the blessed types, a > > > > concrete copy of the pointed-to-value is made to allow GetBody > > > > to > > > > return it. This cannot be done with an interface value without > > > > the > > > > use > > > > of reflect. > > > > > > > > Please show me a Len method in the standard library that does > > > > not > > > > return the number of available-to-access elements in a > > > > collection. >
Re: [go-nuts] Request Content Length zero when copy from another Request
I agree that this is a brittle API and it's one that has bitten us twice (partly because - I beleive - the dev_appserver.py development server is broken in how it deals with the cases here. This is why I filed an issue - though not with great hope of a fix other than maybe improving the documentation. On Thu, 2019-02-07 at 16:10 -0600, robert engels wrote: > So GetBody just fails… It returns NoBody in this case.. which means > calling code will just break (when the original request is not one of > the known types). > > So, according to the referenced issue, 307/308 redirects won’t work > when the underlying request is not a known type. > > This is a very brittle API IMO. If you need to do stuff like this, > the readers should be using mark/reset etc with buffered streams, not > relying on special cased functions like GetBody that don’t work in > all cases. > > > > > On Feb 7, 2019, at 3:42 PM, Dan Kortschak wrote: > > > > Keeping a zeroed state is important for the GetBody func because > > the > > io.ReadCloser returned by GetBody can be read and closed. If there > > is > > no zero state for the next time GetBody is called, it is not > > idempotent. This would break the whole point of it existing. > > > > See https://go-review.googlesource.com/c/go/+/31733/ > > > > On Thu, 2019-02-07 at 15:33 -0600, robert engels wrote: > > > > > > I agree with you on the correct solution - vs. the OP’s request > > > of > > > the GetWrapped method. > > > > > > I guess I still don’t understand the “zeroed” concern though. If > > > you > > > adhere to the “don’t mutate values…” then why do the zero copy at > > > all > > > ? The state of the body should still be the state it was passed > > > in as > > > (unless the caller was breaking the aforementioned rule anyway…). > > > > > > Having “blessed types” is not a good design IMO - better to just > > > declare the required interfaces and use those - especially when > > > the > > > object being provided as a parameter is already an interface… > > > just > > > seems lazy… (and long-term error prone). > > > > > > > > > > > > > > > > > > > > > On Feb 7, 2019, at 3:05 PM, Dan Kortschak > > > > wrote: > > > > > > > > Their is an assumption in the code that users don't mutate > > > > values > > > > under > > > > the feet of routines that have been called. The copy does not > > > > protect > > > > against that and is not designed for that purpose; it is there > > > > to > > > > make > > > > the GetBody function return a zeroed copy of the body (for some > > > > definition of zeroed - zero is the state that was handed in to > > > > the > > > > NewRequest call). If the behaviour of the copy here is broken, > > > > any > > > > Go > > > > code that causes a slice, map or pointer to be retained is > > > > broken > > > > since > > > > the user can mutate the backing data after the call has done > > > > work > > > > on > > > > it. This becomes a philosophical point. > > > > > > > > There is a simple work around (not as simple as having > > > > NewRequest > > > > Just > > > > Do The Right Thing™, but reasonable) that does not require > > > > reflect > > > > and > > > > puts the control in the users' hands. Since the ContentLength > > > > and > > > > GetBody fields are exported, they can be set after the return > > > > of > > > > NewRequest in the same way that NewRequest does for the blessed > > > > types, > > > > but with the users' knowledge of internal behaviours of their > > > > types. > > > > > > > > An example of this is here https://bitbucket.org/ausocean/iot/p > > > > ull- > > > > requ > > > > ests/42 > > > > > > > > On Thu, 2019-02-07 at 14:55 -0600, robert engels wrote: > > > > > > > > > > > > > > > I see the documented use of the types in NewRequest - you are > > > > > correct > > > > > - I was wrong. > > > > > > > > > > But, it could of easily also declared that if the provided > > > > > Reader > > > > > is > > > > > also a Lener, it uses it to determine the content length. Why > > > > > have > > > > > this behavior for Closer and not for Lener? Then you don’t > > > > > need > > > > > the > > > > > type switch. You say, well the copy... > > > > > > > > > > The current code with the copy is broken - the caller could > > > > > continue > > > > > to modify the contents of the bytes.Buffer and things would > > > > > not > > > > > work > > > > > as expected since the backing array of the slice is shared - > > > > > so > > > > > how > > > > > is the copy helping ? The length will remain the same, but > > > > > the > > > > > data > > > > > represented could be corrupted. > > > > > > > > > > The correct solution is to declare that NewRequest takes an > > > > > interface > > > > > Content, that has both Reader and ContentLength methods, > > > > > where > > > > > ContentLength() can return -1 if the content length is > > > > > indeterminate. > > > > > Then declare simple facades for Content from bytes.Buffer, a > > > > > string, > > > > > etc. And also declare
Re: [go-nuts] Re: About 64bits alignment
On Thu, Feb 7, 2019 at 3:49 PM T L wrote: > > Is the bug zone outdated now. How about the support on other 32-bit archs? > Such as mips? The bug description is not out of date. Yes, 32-bit MIPS also requires 8 byte alignment for the 64-bit operations. I sent https://golang.org/cl/161697 to update the docs. Ian > On Wednesday, February 1, 2017 at 12:03:59 PM UTC-4, T L wrote: >> >> the sync/atomic docs, https://golang.org/pkg/sync/atomic/, says in the end >> of the docs >> >> >>> On x86-32, the 64-bit functions use instructions unavailable before the >>> Pentium MMX. >>> >>> On non-Linux ARM, the 64-bit functions use instructions unavailable before >>> the ARMv6k core. >>> >>> On both ARM and x86-32, it is the caller's responsibility to arrange for >>> 64-bit alignment of 64-bit words accessed atomically. >>> >>> The first word in a global variable or in an allocated struct or slice can >>> be relied upon to be 64-bit aligned. >> >> >> The last line says the first word in a global variable or in an allocated >> struct or slice is 64-bit aligned for sure. >> But what does an allocated struct or slice means? A struct or slice >> allocated on heap, not stack? > > -- > 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. > For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] parse timestamp in Go
Thanks. This is what I had to do as also pointed out by Martin Schnabel:
https://play.golang.org/p/cC3yJ2AWquk
On Thu, Feb 7, 2019 at 7:10 PM Burak Serdar wrote:
> On Thu, Feb 7, 2019 at 2:28 PM Rajanikanth Jammalamadaka
> wrote:
> >
> > How can I parse the following timestamp in Go?
> >
> > date +%y%m%d%H%M%S%N
> >
> > 190207202017034235995
>
> for the ymdHMS part, you can use:
>
> time.Parse("060102150405",str[:12])
>
> I don't know if time parser has something for the %N, you might need
> to do it manually, line strconv.Atoi(str[12:])
>
> >
> >
> > Thanks,
> >
> > Raj
> >
> > --
> > 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.
> > For more options, visit https://groups.google.com/d/optout.
>
--
Rajanikanth
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Find biggest memory holder
On Thu, Feb 7, 2019 at 1:33 PM Thomas S wrote: > > Yes Indeed, the size are changing, because it's trees mainly, and some > maps/slices To be clear, any changes to the trees, maps, whatever, will appear in the normal memory profile. Ian -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Request Content Length zero when copy from another Request
I see the documented use of the types in NewRequest - you are correct - I was wrong. But, it could of easily also declared that if the provided Reader is also a Lener, it uses it to determine the content length. Why have this behavior for Closer and not for Lener? Then you don’t need the type switch. You say, well the copy... The current code with the copy is broken - the caller could continue to modify the contents of the bytes.Buffer and things would not work as expected since the backing array of the slice is shared - so how is the copy helping ? The length will remain the same, but the data represented could be corrupted. The correct solution is to declare that NewRequest takes an interface Content, that has both Reader and ContentLength methods, where ContentLength() can return -1 if the content length is indeterminate. Then declare simple facades for Content from bytes.Buffer, a string, etc. And also declare that continued use of the Content after NewRequest is undefined. And if you wanted to retain the simplicity, just declare it uses ContentLength like it uses Closer. I am all for the simplicity of Go, but “solutions" like NewRequest are not the way modern software should be developed. Casting an interface to a concrete type is a sign of code that needs design work. Having to read the doc in addition to the method signature is also a sign the interface needs work (primarily since changes to the doc can/will/might change behavior but it avoids compile time type checking = brittle code with obscure bugs). > On Feb 7, 2019, at 1:56 PM, Dan Kortschak wrote: > > I didn't mention the word internal, nor did I imply it; with > documentation stating that it would be used, it is clearly *not* > internal. > > If you look at the code in question, you can see a probable reason why > a Lener interface is not used; for each of the blessed types, a > concrete copy of the pointed-to-value is made to allow GetBody to > return it. This cannot be done with an interface value without the use > of reflect. > > Please show me a Len method in the standard library that does not > return the number of available-to-access elements in a collection. > > > On Thu, 2019-02-07 at 13:27 -0600, robert engels wrote: >> I am not following. You stated that the usage of Len was internal and >> a type switch on known concrete types, so how is related to how the >> OP was attempting to have things work? >> >> There is no “generally accepted use of Len()”, otherwise it would not >> need to perform a type switch on known concrete types - it would cast >> to an interface declaring Len(), and use the interface, and then it >> would work with any type. >> >>> >>> On Feb 7, 2019, at 1:07 PM, Dan Kortschak wrote: >>> >>> Yeah, I'm not agreeing with you. >>> >>> On Thu, 2019-02-07 at 07:07 -0600, Robert Engels wrote: You are agreeing with me. A type switch on concrete types (that you control) is far different than using an available Len() method and assuming the same semantics. > > > On Feb 7, 2019, at 1:05 AM, Dan Kortschak > wrote: > > Addressing the first sentence, it was a direct answer to a > comment > you > made: > >> >> >> But is it really? If you read the description for Len() on >> bytes.Buffer it is the length of unread portion. But that >> doesn’t >> mean the buffer isn’t just a portion of the entire body - it >> can >> be a >> chunk which is continually reloaded. > As far as the claim that there is a need to have a Len method > in > io.Reader, have a look at the code in question. It type asserts > on > three concrete types that are known to the function, all three > have > a > Len method and this is used to obtain the known length. All > other > io.Readers are considered to have an unknown length. > > Whether it's wrong to use Len depends on whether there is a > generally > accepted and consistent set of semantics to Len() int. There > is. > This > is strengthened if the use of an existing Len method is noted > in > the > docs. > >> >> >> On Wed, 2019-02-06 at 15:50 -0600, robert engels wrote: >> I am not sure what that has to do with the discussion. My >> point >> was >> that for it to be applicable here, it needs to be defined as >> part >> of >> io.Reader, since that is what Body is declared as. It is not, >> so >> using in the manner outlined is not correct IMO. >> >>> >>> >>> >>> On Feb 6, 2019, at 3:37 PM, Dan Kortschak >>> >>> wrote: >>> >>> The generalised semantics of Len are that it returns the >>> number >>> of >>> available elements in the collection, being a cognate of >>> the >>> len >>> built- >>> in. This means that as you consume elements from a buffer, >>>
[go-nuts] Re: parse timestamp in Go
Save it as a string, then access the slice parts of the string: d := datestringtoparse YY := d[0:2] MM := d[2:4] and so forth. On Thursday, February 7, 2019 at 2:28:30 PM UTC-7, Rajanikanth Jammalamadaka wrote: > > How can I parse the following timestamp in Go? > > date +%y%m%d%H%M%S%N > > 190207202017034235995 > > > Thanks, > > Raj > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: using docker for compiling
Yes, but we have somewhat different objectives than you might.
We use the Docker golang (alpine) image to build our images, and it works
wonderfully (and really makes it a lot easier to cope with differences in
Jenkins build nodes). However, our apps generally eventually run on
Kubernetes, which means we have a few things to consider for actual use that
other folks might not.
I should also note that for the most part, we use shell scripts to build, as
make doesn't really bring us many advantages; it can't really track
dependencies across the Docker barrier, and since they're not strictly speaking
files, it can't track the predecessor images (we use a multi-stage build
process) as dependencies, so shell scripts it is.
By way of background, our project is a collection of microservices which we
generally build at the same time for a variety of reasons (one of which is to
maximize parallelism and cache reuse). We use `go build` and/or `go install`
to achieve that, but we use `go run` when testing things.
Our build process is as follows:
- We make a "build" image for each supported distribution we build our apps for
(currently Alpine and CentOS, which have to be built separately because
Alpine's musl-libc makes the binaries incompatible with everything else). The
build image is generally the base Go image (which is the official one for
Alpine, and an equivalent cobbled-together one for CentOS) along with a basic
set of packages installed that we know we need for our build (typically git,
gcc, protobuf stuff and not much more). That image is stored locally and used
as a base for the next step.
- We make a "base" image by first copying in the bootstrap scripts (formerly to
install dep, but now just to do a bit of prep work) and the go.{mod,sum} files.
We warm up the build cache by running `go mod download`, then copy in some
secondary scripts to run `go get -u` to pull in the required Go binaries for
things like code generators needed for the build. Then we copy in the rest of
the code (we defer this to maximize use of the Docker build cache so it doesn't
fetch the dependencies every time), run the code generators with `go generate`,
and then run `go install` on all the apps we want to build (rather than `go
build` so they wind up in an easily-known location), running it on all of them
at once to build them at the same time. After that, we copy a few of the
static assets that get bundled with the apps over to other well-known locations
in the image because none of our environment variables carry over to the next
step.
- We then use Docker's newer multi-stage build capability to start from a fresh
runtime image for each app/distro combo, and copy the apps and their required
static assets into the fresh image. That way, our Alpine images tend to be less
than 15MB each (CentOS is a bit more, though in theory the base layers get
reused, though this is not always true for distribution). Because they are
microservices, each app container is built with the entrypoint simply launching
the app itself so the container terminates when the app does (which is
preferable for Kubernetes).
Now, this obviously wouldn't be ideal for rapid deployment, which is where
things start getting interesting. In theory, we could work directly from the
"base" container (the middle piece), since that has all the source and runtime
needed to run the containers, but not everyone on the team relishes using
terminal-based text editors (there's no accounting for taste). We do, in fact,
run the unit tests and benchmarks from that container and it works splendidly.
But for an edit-compile-run cycle, it leaves a little bit to be desired, so we
add a bit more on for local development.
For the iterative cycle, we do two things. First, we bind-mount our source
directory over the copied source directory in the container (yeah, it's a
little wasteful, but the image is already there and set up, so). We then run
an autorunner which watches the source files and re-runs `go run
.// ` (we use `reflex` since it worked best for our
purposes, but there are others out there including `realize` which seems to be
generally more popular). This works wonders for developing microservices in
the container environment with an editor outside the container, though getting
the regexes to hit all the right files can be interesting; you may need to
manually poke things after a `go generate`, for example. This works extremely
well even across the VM barrier of Docker for Mac, and I would assume also
Docker for Windows, since they have taken great pains to ensure that filesystem
notifications work across platforms.
For specific Kubernetes work, because we want to be able to connect to
in-cluster resources that aren't available outside the cluster as well as
connect to the API and get all the environment variables we'd get when deployed
in-cluster, it's a bit more complex. You don't want to be
Re: [go-nuts] Request Content Length zero when copy from another Request
I agree with you on the correct solution - vs. the OP’s request of the GetWrapped method. I guess I still don’t understand the “zeroed” concern though. If you adhere to the “don’t mutate values…” then why do the zero copy at all ? The state of the body should still be the state it was passed in as (unless the caller was breaking the aforementioned rule anyway…). Having “blessed types” is not a good design IMO - better to just declare the required interfaces and use those - especially when the object being provided as a parameter is already an interface… just seems lazy… (and long-term error prone). > On Feb 7, 2019, at 3:05 PM, Dan Kortschak wrote: > > Their is an assumption in the code that users don't mutate values under > the feet of routines that have been called. The copy does not protect > against that and is not designed for that purpose; it is there to make > the GetBody function return a zeroed copy of the body (for some > definition of zeroed - zero is the state that was handed in to the > NewRequest call). If the behaviour of the copy here is broken, any Go > code that causes a slice, map or pointer to be retained is broken since > the user can mutate the backing data after the call has done work on > it. This becomes a philosophical point. > > There is a simple work around (not as simple as having NewRequest Just > Do The Right Thing™, but reasonable) that does not require reflect and > puts the control in the users' hands. Since the ContentLength and > GetBody fields are exported, they can be set after the return of > NewRequest in the same way that NewRequest does for the blessed types, > but with the users' knowledge of internal behaviours of their types. > > An example of this is here https://bitbucket.org/ausocean/iot/pull-requ > ests/42 > > On Thu, 2019-02-07 at 14:55 -0600, robert engels wrote: >> I see the documented use of the types in NewRequest - you are correct >> - I was wrong. >> >> But, it could of easily also declared that if the provided Reader is >> also a Lener, it uses it to determine the content length. Why have >> this behavior for Closer and not for Lener? Then you don’t need the >> type switch. You say, well the copy... >> >> The current code with the copy is broken - the caller could continue >> to modify the contents of the bytes.Buffer and things would not work >> as expected since the backing array of the slice is shared - so how >> is the copy helping ? The length will remain the same, but the data >> represented could be corrupted. >> >> The correct solution is to declare that NewRequest takes an interface >> Content, that has both Reader and ContentLength methods, where >> ContentLength() can return -1 if the content length is indeterminate. >> Then declare simple facades for Content from bytes.Buffer, a string, >> etc. And also declare that continued use of the Content after >> NewRequest is undefined. And if you wanted to retain the simplicity, >> just declare it uses ContentLength like it uses Closer. >> >> I am all for the simplicity of Go, but “solutions" like NewRequest >> are not the way modern software should be developed. Casting an >> interface to a concrete type is a sign of code that needs design >> work. Having to read the doc in addition to the method signature is >> also a sign the interface needs work (primarily since changes to the >> doc can/will/might change behavior but it avoids compile time type >> checking = brittle code with obscure bugs). >> >> >>> >>> On Feb 7, 2019, at 1:56 PM, Dan Kortschak wrote: >>> >>> I didn't mention the word internal, nor did I imply it; with >>> documentation stating that it would be used, it is clearly *not* >>> internal. >>> >>> If you look at the code in question, you can see a probable reason >>> why >>> a Lener interface is not used; for each of the blessed types, a >>> concrete copy of the pointed-to-value is made to allow GetBody to >>> return it. This cannot be done with an interface value without the >>> use >>> of reflect. >>> >>> Please show me a Len method in the standard library that does not >>> return the number of available-to-access elements in a collection. >>> >>> >>> On Thu, 2019-02-07 at 13:27 -0600, robert engels wrote: I am not following. You stated that the usage of Len was internal and a type switch on known concrete types, so how is related to how the OP was attempting to have things work? There is no “generally accepted use of Len()”, otherwise it would not need to perform a type switch on known concrete types - it would cast to an interface declaring Len(), and use the interface, and then it would work with any type. > > > On Feb 7, 2019, at 1:07 PM, Dan Kortschak > wrote: > > Yeah, I'm not agreeing with you. > > On Thu, 2019-02-07 at 07:07 -0600, Robert Engels wrote: >> >> >> You are agreeing with me. A type switch on
Re: [go-nuts] Find biggest memory holder
Thank you Ian & Robert ! Yes Indeed, the size are changing, because it's trees mainly, and some maps/slices Le jeudi 7 février 2019 19:49:13 UTC+1, robert engels a écrit : > > Is that really true though I am thinking the OP has pointers in global > variables, and the size of the objects pointed to are changing. > > The question is not very clear though. > > > On Feb 7, 2019, at 12:33 PM, Ian Lance Taylor > wrote: > > > > On Thu, Feb 7, 2019 at 2:33 AM Thomas S > wrote: > >> > >> But now, to go forward, I need a monitoring of my globals variables. > >> And not of the "run consumption" of ram. > >> > >> Any ideas on how to do this efficiently ? > > > > The size of your global variables doesn't change during execution of > > your program, of course. If you are using GNU/Linux you can see the > > size of each separate global variable by running "readelf -s BINARY" > > and looking at the "Size" column. > > > > Ian > > > > -- > > 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...@googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] parse timestamp in Go
On Thu, Feb 7, 2019 at 2:28 PM Rajanikanth Jammalamadaka
wrote:
>
> How can I parse the following timestamp in Go?
>
> date +%y%m%d%H%M%S%N
>
> 190207202017034235995
for the ymdHMS part, you can use:
time.Parse("060102150405",str[:12])
I don't know if time parser has something for the %N, you might need
to do it manually, line strconv.Atoi(str[12:])
>
>
> Thanks,
>
> Raj
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: using docker for compiling
And FYI the folder is in local system and API is on server and hence the
path thing will not work, we need to send the object to API
On Fri, Feb 8, 2019 at 11:09 AM akshita babel
wrote:
> How can I take a folder as an input in my go api and know the relative
> path or absolute path of each file in each folder
>
> On Fri, Feb 8, 2019 at 7:12 AM David Riley wrote:
>
>> Yes, but we have somewhat different objectives than you might.
>>
>> We use the Docker golang (alpine) image to build our images, and it works
>> wonderfully (and really makes it a lot easier to cope with differences in
>> Jenkins build nodes). However, our apps generally eventually run on
>> Kubernetes, which means we have a few things to consider for actual use
>> that other folks might not.
>>
>> I should also note that for the most part, we use shell scripts to build,
>> as make doesn't really bring us many advantages; it can't really track
>> dependencies across the Docker barrier, and since they're not strictly
>> speaking files, it can't track the predecessor images (we use a multi-stage
>> build process) as dependencies, so shell scripts it is.
>>
>> By way of background, our project is a collection of microservices which
>> we generally build at the same time for a variety of reasons (one of which
>> is to maximize parallelism and cache reuse). We use `go build` and/or `go
>> install` to achieve that, but we use `go run` when testing things.
>>
>> Our build process is as follows:
>>
>> - We make a "build" image for each supported distribution we build our
>> apps for (currently Alpine and CentOS, which have to be built separately
>> because Alpine's musl-libc makes the binaries incompatible with everything
>> else). The build image is generally the base Go image (which is the
>> official one for Alpine, and an equivalent cobbled-together one for CentOS)
>> along with a basic set of packages installed that we know we need for our
>> build (typically git, gcc, protobuf stuff and not much more). That image
>> is stored locally and used as a base for the next step.
>>
>> - We make a "base" image by first copying in the bootstrap scripts
>> (formerly to install dep, but now just to do a bit of prep work) and the
>> go.{mod,sum} files. We warm up the build cache by running `go mod
>> download`, then copy in some secondary scripts to run `go get -u` to pull
>> in the required Go binaries for things like code generators needed for the
>> build. Then we copy in the rest of the code (we defer this to maximize use
>> of the Docker build cache so it doesn't fetch the dependencies every time),
>> run the code generators with `go generate`, and then run `go install` on
>> all the apps we want to build (rather than `go build` so they wind up in an
>> easily-known location), running it on all of them at once to build them at
>> the same time. After that, we copy a few of the static assets that get
>> bundled with the apps over to other well-known locations in the image
>> because none of our environment variables carry over to the next step.
>>
>> - We then use Docker's newer multi-stage build capability to start from a
>> fresh runtime image for each app/distro combo, and copy the apps and their
>> required static assets into the fresh image. That way, our Alpine images
>> tend to be less than 15MB each (CentOS is a bit more, though in theory the
>> base layers get reused, though this is not always true for distribution).
>> Because they are microservices, each app container is built with the
>> entrypoint simply launching the app itself so the container terminates when
>> the app does (which is preferable for Kubernetes).
>>
>>
>> Now, this obviously wouldn't be ideal for rapid deployment, which is
>> where things start getting interesting. In theory, we could work directly
>> from the "base" container (the middle piece), since that has all the source
>> and runtime needed to run the containers, but not everyone on the team
>> relishes using terminal-based text editors (there's no accounting for
>> taste). We do, in fact, run the unit tests and benchmarks from that
>> container and it works splendidly. But for an edit-compile-run cycle, it
>> leaves a little bit to be desired, so we add a bit more on for local
>> development.
>>
>> For the iterative cycle, we do two things. First, we bind-mount our
>> source directory over the copied source directory in the container (yeah,
>> it's a little wasteful, but the image is already there and set up, so). We
>> then run an autorunner which watches the source files and re-runs `go run
>> .// ` (we use `reflex` since it worked best for our
>> purposes, but there are others out there including `realize` which seems to
>> be generally more popular). This works wonders for developing
>> microservices in the container environment with an editor outside the
>> container, though getting the regexes to hit all the right files can be
>> interesting; you may need to manually poke things after a `go
Re: [go-nuts] Re: using docker for compiling
How can I take a folder as an input in my go api and know the relative path
or absolute path of each file in each folder
On Fri, Feb 8, 2019 at 7:12 AM David Riley wrote:
> Yes, but we have somewhat different objectives than you might.
>
> We use the Docker golang (alpine) image to build our images, and it works
> wonderfully (and really makes it a lot easier to cope with differences in
> Jenkins build nodes). However, our apps generally eventually run on
> Kubernetes, which means we have a few things to consider for actual use
> that other folks might not.
>
> I should also note that for the most part, we use shell scripts to build,
> as make doesn't really bring us many advantages; it can't really track
> dependencies across the Docker barrier, and since they're not strictly
> speaking files, it can't track the predecessor images (we use a multi-stage
> build process) as dependencies, so shell scripts it is.
>
> By way of background, our project is a collection of microservices which
> we generally build at the same time for a variety of reasons (one of which
> is to maximize parallelism and cache reuse). We use `go build` and/or `go
> install` to achieve that, but we use `go run` when testing things.
>
> Our build process is as follows:
>
> - We make a "build" image for each supported distribution we build our
> apps for (currently Alpine and CentOS, which have to be built separately
> because Alpine's musl-libc makes the binaries incompatible with everything
> else). The build image is generally the base Go image (which is the
> official one for Alpine, and an equivalent cobbled-together one for CentOS)
> along with a basic set of packages installed that we know we need for our
> build (typically git, gcc, protobuf stuff and not much more). That image
> is stored locally and used as a base for the next step.
>
> - We make a "base" image by first copying in the bootstrap scripts
> (formerly to install dep, but now just to do a bit of prep work) and the
> go.{mod,sum} files. We warm up the build cache by running `go mod
> download`, then copy in some secondary scripts to run `go get -u` to pull
> in the required Go binaries for things like code generators needed for the
> build. Then we copy in the rest of the code (we defer this to maximize use
> of the Docker build cache so it doesn't fetch the dependencies every time),
> run the code generators with `go generate`, and then run `go install` on
> all the apps we want to build (rather than `go build` so they wind up in an
> easily-known location), running it on all of them at once to build them at
> the same time. After that, we copy a few of the static assets that get
> bundled with the apps over to other well-known locations in the image
> because none of our environment variables carry over to the next step.
>
> - We then use Docker's newer multi-stage build capability to start from a
> fresh runtime image for each app/distro combo, and copy the apps and their
> required static assets into the fresh image. That way, our Alpine images
> tend to be less than 15MB each (CentOS is a bit more, though in theory the
> base layers get reused, though this is not always true for distribution).
> Because they are microservices, each app container is built with the
> entrypoint simply launching the app itself so the container terminates when
> the app does (which is preferable for Kubernetes).
>
>
> Now, this obviously wouldn't be ideal for rapid deployment, which is where
> things start getting interesting. In theory, we could work directly from
> the "base" container (the middle piece), since that has all the source and
> runtime needed to run the containers, but not everyone on the team relishes
> using terminal-based text editors (there's no accounting for taste). We
> do, in fact, run the unit tests and benchmarks from that container and it
> works splendidly. But for an edit-compile-run cycle, it leaves a little
> bit to be desired, so we add a bit more on for local development.
>
> For the iterative cycle, we do two things. First, we bind-mount our
> source directory over the copied source directory in the container (yeah,
> it's a little wasteful, but the image is already there and set up, so). We
> then run an autorunner which watches the source files and re-runs `go run
> .// ` (we use `reflex` since it worked best for our
> purposes, but there are others out there including `realize` which seems to
> be generally more popular). This works wonders for developing
> microservices in the container environment with an editor outside the
> container, though getting the regexes to hit all the right files can be
> interesting; you may need to manually poke things after a `go generate`,
> for example. This works extremely well even across the VM barrier of
> Docker for Mac, and I would assume also Docker for Windows, since they have
> taken great pains to ensure that filesystem notifications work across
> platforms.
>
> For specific Kubernetes
[go-nuts] Re: Write to file (rather then stderr) on crash
That's fine if you only have one go-routine but if you have lots then you have to recover the panic (ie catch the exception in normal parlance) in every go-routine. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: About 64bits alignment
Thanks for the clarification. On Thursday, February 7, 2019 at 8:57:00 PM UTC-4, Ian Lance Taylor wrote: > > On Thu, Feb 7, 2019 at 3:49 PM T L > > wrote: > > > > Is the bug zone outdated now. How about the support on other 32-bit > archs? Such as mips? > > The bug description is not out of date. > > Yes, 32-bit MIPS also requires 8 byte alignment for the 64-bit > operations. I sent https://golang.org/cl/161697 to update the docs. > > Ian > > > > On Wednesday, February 1, 2017 at 12:03:59 PM UTC-4, T L wrote: > >> > >> the sync/atomic docs, https://golang.org/pkg/sync/atomic/, says in the > end of the docs > >> > >> > >>> On x86-32, the 64-bit functions use instructions unavailable before > the Pentium MMX. > >>> > >>> On non-Linux ARM, the 64-bit functions use instructions unavailable > before the ARMv6k core. > >>> > >>> On both ARM and x86-32, it is the caller's responsibility to arrange > for 64-bit alignment of 64-bit words accessed atomically. > >>> > >>> The first word in a global variable or in an allocated struct or slice > can be relied upon to be 64-bit aligned. > >> > >> > >> The last line says the first word in a global variable or in an > allocated struct or slice is 64-bit aligned for sure. > >> But what does an allocated struct or slice means? A struct or slice > allocated on heap, not stack? > > > > -- > > 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...@googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Find biggest memory holder
Hello, I work on a service using a big amount of RAM memory (500-100MB). Most of them is used by global variable, it's pre-processed data, allowing the service to answer quickly. However, I'm working on improving the RAM consumption. I generated PDF callgraphs with pprof. Some elementary upgrade thanks to this. [image: cg_ext.png] *But now, to go forward, I need a monitoring of my globals variables.* And not of the "run consumption" of ram. Any ideas on how to do this efficiently ? Thank you ! Thomas -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] When would you use single quotes?
On Thu, Feb 7, 2019 at 11:25 AM Jamie Caldwell wrote: > But why would you use one over the other? Why does Go support being able to assign a codepoint using single quotes? `type rune` vs type `string` not the same, but is bit like `type byte` vs `type []byte`. The serve very different purposes. One cannot do the same things with `byte` that can be done with `[]byte`. > Also, why do they take more than three bytes each? `rune` is an alias of `int32`, hence 4 bytes. `string` is a two word struct, hence 2*size of pointer. 8 or 16 bytes. -- -j -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] When would you use single quotes?
A rune is an int32, so it takes 4 bytes by definition. A string in a struct with position, length and backing array of bytes. The backing array here consumes 3 bytes, but tge position and length occupies space too, so the string of that rune occupies more than 3 bytes after all. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] When would you use single quotes?
Thank you for getting back to me, but I don't think you have answered my question. I understand they are a rune and string respectively. But *why* would you use one over the other? Why does Go support being able to assign a codepoint using single quotes? Also, why do they take more than three bytes each? Thank you. On Wed, 6 Feb 2019 at 23:30, Wagner Riffel wrote: > '⌘' is of type rune (aka int32), "⌘" and `⌘` are of type string, both > takes more than 3 bytes. > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] When would you use single quotes?
Thank you both for your answers. It is much appreciated. The UTF8 encoding of that codepoint is three bytes. So the rune will still occupy 4 bytes, even if the last byte holds no data? I'm sorry for the school boy question! Thank you. On Thu, 7 Feb 2019, 10:52 Tamás Gulácsi A rune is an int32, so it takes 4 bytes by definition. > A string in a struct with position, length and backing array of bytes. The > backing array here consumes 3 bytes, but tge position and length occupies > space too, so the string of that rune occupies more than 3 bytes after all. > > -- > 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/-bvJLkhX_dY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > On Thu, 7 Feb 2019, 10:52 Tamás Gulácsi A rune is an int32, so it takes 4 bytes by definition. > A string in a struct with position, length and backing array of bytes. The > backing array here consumes 3 bytes, but tge position and length occupies > space too, so the string of that rune occupies more than 3 bytes after all. > > -- > 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/-bvJLkhX_dY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: When would you use single quotes?
Jamie, This is a question about Unicode: The Unicode Consortium: http://unicode.org/ The Unicode Standard: http://www.unicode.org/standard/standard.html Unicode Frequently Asked Questions: UTF-8, UTF-16, UTF-32 & BOM: http://www.unicode.org/faq/utf_bom.html Briefly, a Unicode code point is 24 bits. The nearest common hardware equivalent is 32 bits. Go uses type int32. Go uses an alias of type rune to distinguish code points from integers. A Unicode transformation format (UTF) is an algorithmic mapping from every Unicode code point to a unique byte sequence. Go favors UTF-8. In Go, single quotes enclose a rune (32 bit) literal, double quotes enclose a UTF-8 encoded string (one to four byte) literal. Peter On Wednesday, February 6, 2019 at 6:14:41 PM UTC-5, Jamie Caldwell wrote: > > Hello, > > I'd be grateful if someone could please explain why you would use > > r := '⌘' > > Instead of > > s := "⌘" / s:= `⌘` > > All use three bytes ...? > > Thank you, > Jamie. > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Request Content Length zero when copy from another Request
You are agreeing with me. A type switch on concrete types (that you control) is
far different than using an available Len() method and assuming the same
semantics.
> On Feb 7, 2019, at 1:05 AM, Dan Kortschak wrote:
>
> Addressing the first sentence, it was a direct answer to a comment you
> made:
>
>> But is it really? If you read the description for Len() on
>> bytes.Buffer it is the length of unread portion. But that doesn’t
>> mean the buffer isn’t just a portion of the entire body - it can be a
>> chunk which is continually reloaded.
>
> As far as the claim that there is a need to have a Len method in
> io.Reader, have a look at the code in question. It type asserts on
> three concrete types that are known to the function, all three have a
> Len method and this is used to obtain the known length. All other
> io.Readers are considered to have an unknown length.
>
> Whether it's wrong to use Len depends on whether there is a generally
> accepted and consistent set of semantics to Len() int. There is. This
> is strengthened if the use of an existing Len method is noted in the
> docs.
>
>> On Wed, 2019-02-06 at 15:50 -0600, robert engels wrote:
>> I am not sure what that has to do with the discussion. My point was
>> that for it to be applicable here, it needs to be defined as part of
>> io.Reader, since that is what Body is declared as. It is not, so
>> using in the manner outlined is not correct IMO.
>>
>>>
>>> On Feb 6, 2019, at 3:37 PM, Dan Kortschak wrote:
>>>
>>> The generalised semantics of Len are that it returns the number of
>>> available elements in the collection, being a cognate of the len
>>> built-
>>> in. This means that as you consume elements from a buffer, the Len
>>> value reduces. This is directly equivalent to
>>>
>>> for len(buf) != 0 {
>>>println(buf[0])
>>>buf = buf[1:]
>>> }
>>>
On Wed, 2019-02-06 at 08:56 -0600, Robert Engels wrote:
But is it really? If you read the description for Len() on
bytes.Buffer it is the length of unread portion. But that doesn’t
mean the buffer isn’t just a portion of the entire body - it can
be a
chunk which is continually reloaded.
This is the danger in using private APIs publically based upon
the
existence of a method - it leads to very brittle code - and there
are
almost certainly better ways to design it to avoid these issues.
If
the core api is not expressive enough then it will be more
difficult.
>
>
> On Feb 6, 2019, at 8:30 AM, Burak Serdar
> wrote:
>
>>
>>
>> On Wed, Feb 6, 2019 at 5:15 AM Robert Engels > om.c
>> om> wrote:
>>
>> I see now, but if that can be the case, shouldn’t the Body be
>> documented that the Reader may be a ReaderWithLen, and the
>> consumer is free to type check/cast? If not, you are using
>> internal details that you should not be.
> Yes, the documentation should say if the reader has a Len()
> method
> it
> would be used to set the ContentLength. Len is no longer an
> internal
> detail then.
>
>>
>>
>>
>> This is a problem with Go in general. Because the returned
>> object
>> “implements” some interface because it happens to have the
>> required method, doesn’t mean it was designed to be used that
>> way, or that it has the required semantics - unless
>> documented to
>> have them.
> I agree with you there. Len() is straight forward, but in
> general
> just
> because a function is named something doesn't mean it'll do the
> same
> thing for all implementations. On the other end of the spectrum
> is
> Java-like interfaces where you want explicit inheritance of a
> specific
> interface. I don't know if there's anything in between, but I
> like
> Go's approach much better.
>
>>
>>
>>
>> On Feb 6, 2019, at 2:22 AM, Matteo Biagetti > gmai
>> l.com> wrote:
>>
>> Make sense, thanks for explanation
>>
>>
>>
>> Il giorno mercoledì 6 febbraio 2019 07:28:54 UTC+1, Burak
>> Serdar
>> ha scritto:
>>>
>>>
>>>
>>> On Tue, Feb 5, 2019 at 8:13 PM robert engels >> com.
>>> com> wrote:
That’s what I was trying to point out. Your design is not
correct. The Body is a Reader, not a Buffer - the length
of
the request/body may be indeterminate - that is, a
stream.
Attempting to get the length of an underlying buffer is
not
only probably not possible, but not correct in many
situations.
>>> The length of the body *may* be indeterminate, and if
>>> that's
>>> the case,
>>> the underlying Reader will not have a Len method. The
>>> design is
>>> to
>>> handle the case where the underlying Reader is a Buffer
>>> with
Re: [go-nuts] When would you use single quotes?
> > The UTF8 encoding of that codepoint is three bytes. So the rune will > still occupy 4 bytes, even if the last byte holds no data? > A rune has nothing to do with UTF-8. A rune stores the codepoint which is totally independent of any encoding (like UTF-8, UTF-16, UTF-23, EBCDIC, whatnot). A rune is an integer, the number of the codepoint. An integer is stored in a certain number of bytes. Asking "So the rune will still occupy 4 bytes, even if the last byte holds no data?" is like asking "So the number 12 will still occupy 8 bits, even if the last 5 bits hold no data?". Yes. An integer is stored in 8 bytes (64bit architecture) and this is true even for "small" integers which would "fit" into one byte. A rune is an integer. It has nothing to do with UTF. V. -- 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. For more options, visit https://groups.google.com/d/optout.
