Re: [go-nuts] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?
On Oct 18, 2016 2:56 AM, "Aram Hăvărneanu" wrote: > > On Mon, Oct 17, 2016 at 8:29 PM, Liam Breck wrote: > > bytes.Replace(s []byte, pos int, len uint, new []byte) > > I have no idea what this bizarre hypothetical function does. It's an > awful interface that aims to solve an unknown problem nobody has > claimed to have. May I refer you to the previous messages in this thread? > Also, bytes.Replace already exists. My mistake, should be bytes.ReplaceAt(s []byte, pos, len int, new []byte) Guess I still miss function overloading :-) -- 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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?
> On Mon, Oct 17, 2016 at 8:29 PM, Liam Breck wrote: >> bytes.Replace(s []byte, pos int, len uint, new []byte) > > I have no idea what this bizarre hypothetical function does. It's an > awful interface that aims to solve an unknown problem nobody has > claimed to have. > > Also, bytes.Replace already exists. > Also, slice lengths are signed integers, not unsigned integers. I suggest you familiarize more with slices before suggest these "improvements". -- Aram Hăvărneanu -- 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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?
On Mon, Oct 17, 2016 at 8:29 PM, Liam Breck wrote: > bytes.Replace(s []byte, pos int, len uint, new []byte) I have no idea what this bizarre hypothetical function does. It's an awful interface that aims to solve an unknown problem nobody has claimed to have. Also, bytes.Replace already exists. -- Aram Hăvărneanu -- 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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?
On Oct 16, 2016 6:03 PM, "Liam Breck" wrote: > > > > On Sun, Oct 16, 2016 at 5:32 PM, Ian Lance Taylor wrote: >> >> On Sun, Oct 16, 2016 at 5:25 PM, Liam wrote: >> > >> > On Sunday, October 16, 2016 at 5:13:36 PM UTC-7, Ian Lance Taylor wrote: >> >> >> >> On Sun, Oct 16, 2016 at 3:34 PM, Liam wrote: >> >> > >> >> > On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor wrote: >> >> > >> >> >> To argue that this should go into the standard library, look at some >> >> >> corpus of Go code and find out how often it occurs. If it occurs >> >> >> fairly often, you've got a good case. >> >> > >> >> > >> >> > Fairly often; i.e. as often as Replace or Trim*? In my experience it >> >> > passes >> >> > that test. >> >> >> >> This is something that can actually be measured. >> > >> > >> > By doing grep 'append.*append' ? And '\[:.*len\(.*\).*\+[0-9]+.*\]' ? >> > Neither of these will be accurate. >> > >> > Part of my point is that Insert operations are semantically obscured. >> >> Understood. But my guess is that insertion operations are fairly >> rare--much less common than Replace or Trim. People obviously append >> to slices all the time, but I suspect that they tend to write their >> slice operations to not require inserting a single element in the >> middle of the slice, because insertion is by definition O(N) rather >> than O(1). I could certainly be wrong, but that guess leads me to >> suspect that adding a function for something that can easily be >> written in a single expression is overkill. Since I am only guessing, >> and since it seems to me that you are also guessing, I think we should >> measure rather than guess. > > > You characterize optimization as a widespread habit. Most code isn't optimized, as it doesn't need to be. Most coders follow the first advice found, which in my case was Insert() on [1]. If you wish the most optimal solution to be widespread, stdlib would be a good vehicle :-) > > I would attempt to provide data confirming my guess, but I can't see how to do that without spending a lot of time hunting for semantically invisible operations. Since there are two authoritative suggestions for this op, it's a reasonable guess that it's widely done. > > BTW, we are having this discussion because fmt does not support thousands grouping, which also seems like a common need. > > [1] https://blog.golang.org/slices As an alternative to bytes.Insert/Delete how about bytes.Replace(s []byte, pos int, len uint, new []byte) A zero len is insert, and empty new is delete. -- 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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?
On Sun, Oct 16, 2016 at 5:32 PM, Ian Lance Taylor wrote: > On Sun, Oct 16, 2016 at 5:25 PM, Liam wrote: > > > > On Sunday, October 16, 2016 at 5:13:36 PM UTC-7, Ian Lance Taylor wrote: > >> > >> On Sun, Oct 16, 2016 at 3:34 PM, Liam wrote: > >> > > >> > On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor > wrote: > >> > > >> >> To argue that this should go into the standard library, look at some > >> >> corpus of Go code and find out how often it occurs. If it occurs > >> >> fairly often, you've got a good case. > >> > > >> > > >> > Fairly often; i.e. as often as Replace or Trim*? In my experience it > >> > passes > >> > that test. > >> > >> This is something that can actually be measured. > > > > > > By doing grep 'append.*append' ? And '\[:.*len\(.*\).*\+[0-9]+.*\]' ? > > Neither of these will be accurate. > > > > Part of my point is that Insert operations are semantically obscured. > > Understood. But my guess is that insertion operations are fairly > rare--much less common than Replace or Trim. People obviously append > to slices all the time, but I suspect that they tend to write their > slice operations to not require inserting a single element in the > middle of the slice, because insertion is by definition O(N) rather > than O(1). I could certainly be wrong, but that guess leads me to > suspect that adding a function for something that can easily be > written in a single expression is overkill. Since I am only guessing, > and since it seems to me that you are also guessing, I think we should > measure rather than guess. > You characterize optimization as a widespread habit. Most code isn't optimized, as it doesn't need to be. Most coders follow the first advice found, which in my case was Insert() on [1]. If you wish the most optimal solution to be widespread, stdlib would be a good vehicle :-) I would attempt to provide data confirming my guess, but I can't see how to do that without spending a lot of time hunting for semantically invisible operations. Since there are two authoritative suggestions for this op, it's a reasonable guess that it's widely done. BTW, we are having this discussion because fmt does not support thousands grouping, which also seems like a common need. [1] https://blog.golang.org/slices -- 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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?
On Sun, Oct 16, 2016 at 5:25 PM, Liam wrote: > > On Sunday, October 16, 2016 at 5:13:36 PM UTC-7, Ian Lance Taylor wrote: >> >> On Sun, Oct 16, 2016 at 3:34 PM, Liam wrote: >> > >> > On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor wrote: >> > >> >> To argue that this should go into the standard library, look at some >> >> corpus of Go code and find out how often it occurs. If it occurs >> >> fairly often, you've got a good case. >> > >> > >> > Fairly often; i.e. as often as Replace or Trim*? In my experience it >> > passes >> > that test. >> >> This is something that can actually be measured. > > > By doing grep 'append.*append' ? And '\[:.*len\(.*\).*\+[0-9]+.*\]' ? > Neither of these will be accurate. > > Part of my point is that Insert operations are semantically obscured. Understood. But my guess is that insertion operations are fairly rare--much less common than Replace or Trim. People obviously append to slices all the time, but I suspect that they tend to write their slice operations to not require inserting a single element in the middle of the slice, because insertion is by definition O(N) rather than O(1). I could certainly be wrong, but that guess leads me to suspect that adding a function for something that can easily be written in a single expression is overkill. Since I am only guessing, and since it seems to me that you are also guessing, I think we should measure rather than guess. 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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?
On Sunday, October 16, 2016 at 5:13:36 PM UTC-7, Ian Lance Taylor wrote: > > On Sun, Oct 16, 2016 at 3:34 PM, Liam > > wrote: > > > > On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor wrote: > > > >> To argue that this should go into the standard library, look at some > >> corpus of Go code and find out how often it occurs. If it occurs > >> fairly often, you've got a good case. > > > > > > Fairly often; i.e. as often as Replace or Trim*? In my experience it > passes > > that test. > > This is something that can actually be measured. > By doing grep 'append.*append' ? And '\[:.*len\(.*\).*\+[0-9]+.*\]' ? Neither of these will be accurate. Part of my point is that Insert operations are semantically obscured. -- 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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?
On Sun, Oct 16, 2016 at 3:34 PM, Liam wrote: > > On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor wrote: > >> To argue that this should go into the standard library, look at some >> corpus of Go code and find out how often it occurs. If it occurs >> fairly often, you've got a good case. > > > Fairly often; i.e. as often as Replace or Trim*? In my experience it passes > that test. This is something that can actually be measured. 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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?
On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor wrote: > > > > A function to insert a byte into a slice is conspicuous by its absence. > > It's a one-liner. > append(s[:p], append([]byte{b}, s[p:]...)...) > This is already gobbledygook :) Does that read "Insert" to you? It doesn't to me. > it's easy enough to write a helper function yourself. > Of course, but two reasons for the stdlib are: foster semantic clarity in client code prevent innumerable variations across packages in the name and signature of a common function To argue that this should go into the standard library, look at some > corpus of Go code and find out how often it occurs. If it occurs > fairly often, you've got a good case. > Fairly often; i.e. as often as Replace or Trim*? In my experience it passes that test. That Insert and Delete are missing implies to me that there is something strange about such operations. -- 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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?
On Sun, Oct 16, 2016 at 1:49 PM, Liam wrote: > > A function to insert a byte into a slice is conspicuous by its absence. It's a one-liner. append(s[:p], append([]byte{b}, s[p:]...)...) (You may want to look at https://github.com/golang/go/wiki/SliceTricks). > // but instead it's gobbledygook: In particular cases where the one-liner is goobledygook, it's easy enough to write a helper function yourself. To argue that this should go into the standard library, look at some corpus of Go code and find out how often it occurs. If it occurs fairly often, you've got a good case. 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.
[go-nuts] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?
A function to insert a byte into a slice is conspicuous by its absence. Consider this code to parse /proc/meminfo into a 2D array and insert commas: MemTotal: 497464 kB MemFree: 386232 kB MemAvailable: 452420 kB Buffers:8612 kB Cached:60160 kB ... . aLine := bytes.SplitN(fileBuf, []byte("\n"), 6) var aPair [5][][]byte for a := 0; a < 5; a++ { aPair[a] = bytes.SplitN(aLine[a], []byte(":"), 2) aPair[a][1] = sRegEx.FindSubmatch(aPair[a][1])[1] // " *([0-9]+)" if len(aPair[a][1]) > 3 { // should be: // aPair[a][1] = bytes.InsertByte(aPair[a][1], len(aPair[a][1])-3, ',') // but instead it's gobbledygook: aPair[a][1] = aPair[a][1][:len(aPair[a][1])+1] copy(aPair[a][1][len(aPair[a][1])-2:], aPair[a][1][len(aPair[a][1])-3:]) aPair[a][1][len(aPair[a][1])-4] = ',' } } Surely this is common enough to merit inclusion in stdlib. -- 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.