[go-nuts] Re: Unit testing slog output

2023-06-14 Thread shan...@gmail.com
I think that perhaps a bit more explanation might be helpful

I have an established pattern of capturing log messages so that i can check 
them in unit tests. (The code/test first example)

I want to do that with slog (where slog emits a message and I capture that 
message and compare it in the test), as partially demonstrated in the final 
test section..

I've also discovered that i want to drop parts of the message (eg. the 
timestamp).


The goal is to be able to trigger the SUT to emit a log message that can be 
tested as both existing, and matching what is expected.

On Thursday, June 15, 2023 at 2:44:39 AM UTC+10 Tamás Gulácsi wrote:

> github.com/UNO-SOFT/zlog/v2 
> NewT(t).SLog()
> returns an *slog.Logger that uses t.Log for printing.
>
> But maybe I don't understand your real problem.
>
> shan...@gmail.com a következőt írta (2023. június 14., szerda, 2:14:27 
> UTC+2):
>
>> In the past when I wanted to 'capture' the log output so that I could 
>> check it in a unit test I would 'hijack' os.Stdout like so
>> ```
>> var osStdout = os.Stdout
>> func MyCode (){
>>   log.SetOutput(osStdout)
>>   log.Print("My dog has fleas")
>> }
>> ```
>> Which could then be tested thus
>> ```
>> func TestMyCode(t *testing.T){
>>   testcases := map[string]struct{
>>   output string
>>   }{
>> "Dog needs flea shampoo": {
>>   output: "My dog has fleas",
>> },
>>   }
>>   for name, tc := range testcases {
>>   t.Run(name, func(t *testing.T) {
>>  orig := osStdout
>>  flags := log.Flags()
>>  log.SetFlags(0)
>>  reader, writer, err := os.Pipe()
>>  if err != nil {
>> panic(err)
>>  }
>>  osStdout = writer
>>  defer func() {
>>osStdout = orig
>>log.SetFlags(flags)
>>   }()
>>  MyCode()
>>  writer.Close()
>>
>>  var buf strings.Builder
>>  if _, ioerr := io.Copy(, reader); ioerr != nil {
>>log.Fatalf("Copy error, cannot continue %v\n", ioerr)
>>  }
>>
>>   assert.Equal(t, tc.output, buf.String(), "Expected: %s Got: 
>> %s", tc.output, buf.String())
>>  }
>>})
>> }
>> }
>> ```
>>
>> I'm now trying to do the same with the slog package (but not having any 
>> joy) - is there an established pattern that people are using, eg. is the 
>> handler being
>>
>> I've been trying 
>> ```
>> func TestMyCode(t *testing.T){
>>   testcases := map[string]struct{
>>   output string
>>   }{
>> "Dog needs flea shampoo": {
>>   output: "My dog has fleas",
>> },
>>   }
>>   for name, tc := range testcases {
>>   t.Run(name, func(t *testing.T) {
>>  orig := osStdout
>>  reader, writer, err := os.Pipe()
>>  if err != nil {
>> panic(err)
>>  }
>>  osStdout = writer
>>  defer func() {
>>osStdout = orig
>>   }()
>>  slog.SetDefault(slog.New(slog.NewTextHandler(osStdout)
>>  MyCode()
>>  writer.Close()
>>
>>  var buf strings.Builder
>>  if _, ioerr := io.Copy(, reader); ioerr != nil {
>>log.Fatalf("Copy error, cannot continue %v\n", ioerr)
>>  }
>>
>>   assert.Equal(t, tc.output, buf.String(), "Expected: %s Got: 
>> %s", tc.output, buf.String())
>>  }
>>})
>> }
>> }
>> ```
>>
>> Which "works" but I am not happy with it, because it's affecting all of 
>> the slog instances.
>>
>> I saw previously that someone was creating their own implementation of a 
>> slog.Handler? to make testing easier, and would love to see it, and will 
>> that allow me to run multiple slog based tests concurrently?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f6e94c36-3646-48d8-a705-82351bc3f84dn%40googlegroups.com.


[go-nuts] Unit testing slog output

2023-06-13 Thread shan...@gmail.com
In the past when I wanted to 'capture' the log output so that I could check 
it in a unit test I would 'hijack' os.Stdout like so
```
var osStdout = os.Stdout
func MyCode (){
  log.SetOutput(osStdout)
  log.Print("My dog has fleas")
}
```
Which could then be tested thus
```
func TestMyCode(t *testing.T){
  testcases := map[string]struct{
  output string
  }{
"Dog needs flea shampoo": {
  output: "My dog has fleas",
},
  }
  for name, tc := range testcases {
  t.Run(name, func(t *testing.T) {
 orig := osStdout
 flags := log.Flags()
 log.SetFlags(0)
 reader, writer, err := os.Pipe()
 if err != nil {
panic(err)
 }
 osStdout = writer
 defer func() {
   osStdout = orig
   log.SetFlags(flags)
  }()
 MyCode()
 writer.Close()

 var buf strings.Builder
 if _, ioerr := io.Copy(, reader); ioerr != nil {
   log.Fatalf("Copy error, cannot continue %v\n", ioerr)
 }

  assert.Equal(t, tc.output, buf.String(), "Expected: %s Got: %s", 
tc.output, buf.String())
 }
   })
}
}
```

I'm now trying to do the same with the slog package (but not having any 
joy) - is there an established pattern that people are using, eg. is the 
handler being

I've been trying 
```
func TestMyCode(t *testing.T){
  testcases := map[string]struct{
  output string
  }{
"Dog needs flea shampoo": {
  output: "My dog has fleas",
},
  }
  for name, tc := range testcases {
  t.Run(name, func(t *testing.T) {
 orig := osStdout
 reader, writer, err := os.Pipe()
 if err != nil {
panic(err)
 }
 osStdout = writer
 defer func() {
   osStdout = orig
  }()
 slog.SetDefault(slog.New(slog.NewTextHandler(osStdout)
 MyCode()
 writer.Close()

 var buf strings.Builder
 if _, ioerr := io.Copy(, reader); ioerr != nil {
   log.Fatalf("Copy error, cannot continue %v\n", ioerr)
 }

  assert.Equal(t, tc.output, buf.String(), "Expected: %s Got: %s", 
tc.output, buf.String())
 }
   })
}
}
```

Which "works" but I am not happy with it, because it's affecting all of the 
slog instances.

I saw previously that someone was creating their own implementation of a 
slog.Handler? to make testing easier, and would love to see it, and will 
that allow me to run multiple slog based tests concurrently?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8c768749-adbf-4ccc-a328-db3ce7a839d3n%40googlegroups.com.


Re: [go-nuts] Pointer to a pointer

2022-03-10 Thread shan...@gmail.com
Apologies; I had misunderstood your code and was thinking that - because of 
earlier responses - this wasn't going to be a nice day.

> for Shane, Rob did answer it and in way that is really quite deep, and 
thinking about how he answered it will teach you something that is worth 
learning)

Yeah it's definitely above my paygrade and will take some time for me to 
get my head around
On Thursday, March 10, 2022 at 8:31:58 PM UTC+11 Rob 'Commander' Pike wrote:

> On Thu, Mar 10, 2022 at 5:08 PM shan...@gmail.com  
> wrote:
> >
> > Is this really how you want to be known?
>
> Sure, why not? It's a more interesting program than one might think.
>
> For a richer example of the foundational idea here, see the peano.go
> program in the test directory in the repo.
>
> -rob
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fd44a6d2-4764-4d90-9637-2808683fcedfn%40googlegroups.com.


Re: [go-nuts] Pointer to a pointer

2022-03-09 Thread shan...@gmail.com
Is this really how you want to be known?


On Thursday, March 10, 2022 at 4:44:52 PM UTC+11 Rob 'Commander' Pike wrote:

> Here's a program with 1000 *s. You can see the pattern, make it any
> number you like.
>
> https://go.dev/play/p/FZXWcQTutEG
>
> // You can edit this code!
> // Click here and start typing.
> package main
>
> import "fmt"
>
> type self *self
>
> func main() {
> var p self
> p = 
>
> fmt.Println(p)
> }
>
>
> -rob
>
> On Thu, Mar 10, 2022 at 4:29 PM Kurtis Rader  wrote:
> >
> > On Wed, Mar 9, 2022 at 9:12 PM shan...@gmail.com  
> wrote:
> >>
> >> Um
> >>
> >> Really?
> >>
> >> Which of these things are you specifically trying to prevent happening
> >> - Curiousity
> >> - Creativity
> >> - Asking questions
> >> - Some combination of the above
> >>
> >> I mean, I appreciate that you think that people should *know* whatever 
> it is you think you know, but that's a really *really* poor response
> >
> >
> > Yes, your question was silly. The limit is going to be both platform 
> dependent and dependent on the resources (e.g., memory) available on the 
> platform. Your question is silly because regardless of the fundamental 
> limits imposed by the Go language or the platform it runs on absolutely no 
> one will ever write a function that gets within many orders of magnitude of 
> the limit. So your question is interesting in a hypothetical sense but not 
> in a practical sense. For the former I suggest you start a research project 
> and write a paper for review that explains why, or why not, the existing 
> limit is a problem.
> >
> >>
> >> On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:
> >>>
> >>> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
> >>>>
> >>>> A linked list, for example, consists of pointers to pointers to 
> pointers...
> >>>>
> >>>> Why should any limit exist to the length of the list except resources 
> available?
> >>>
> >>>
> >>> Yes, but the O.P. was asking about a silly example. Specifically, when 
> defining a function that receives pointers how many levels of indirection 
> are allowed in the declaration. In practice 99.9% of the time a single 
> level of indirection is specified and 0.09% of the time two levels are 
> specified. Etcetera. For example, if
> >>>
> >>> func wtf(i int) {
> >>> }
> >>>
> >>> is supported, which has eight levels of indirection, why isn't 16? 32? 
> 64? Etcetera levels of indirection supported when defining a function. It's 
> a silly question that shows the O.P. doesn't understand how compilers work. 
> Let alone how people use languages like Go in real life.
> >>>
> >>>>
> >>>> On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  
> wrote:
> >>>>>
> >>>>> This morning someone asked about dereferincing a pointer to a 
> pointer to a pointer
> >>>>>
> >>>>> At first nobody had ever thought about, let alone knew the answer, 
> but some example code was shown, and sure enough ***val is possible
> >>>>> ```
> >>>>> package main
> >>>>>
> >>>>> import "fmt"
> >>>>>
> >>>>> func main() {
> >>>>> a := 0
> >>>>> b := 
> >>>>> c := 
> >>>>> UltimatePointOne()
> >>>>> fmt.Println(a)
> >>>>

Re: [go-nuts] Pointer to a pointer

2022-03-09 Thread shan...@gmail.com
> The limit is going to be both platform dependent and dependent on the 
resources (e.g., memory) available on the platform. 

Then this is the answer you should have started with

> absolutely no one will ever write a function that gets within many orders 
of magnitude of the limit

I mean, nobody will ever go to the stars, so nobody should ask what it 
would take to get their, right

That's really bad. That's attacking "creativity" and "curiousity" both at 
the same time

> So your question is interesting in a hypothetical sense 

This is also "curiousity" - learn to recognise it so you don't stifle it in 
future.



On Thursday, March 10, 2022 at 4:29:54 PM UTC+11 Kurtis Rader wrote:

> On Wed, Mar 9, 2022 at 9:12 PM shan...@gmail.com  
> wrote:
>
>> Um
>>
>> Really?
>>
>> Which of these things are you specifically trying to prevent happening
>>  - Curiousity
>>  - Creativity
>>  - Asking questions
>>  - Some combination of the above
>>
>> I mean, I appreciate that you think that people should *know* whatever it 
>> is you think you know, but that's a really *really* poor response
>>
>
> Yes, your question was silly. The limit is going to be both platform 
> dependent and dependent on the resources (e.g., memory) available on the 
> platform. Your question is silly because regardless of the fundamental 
> limits imposed by the Go language or the platform it runs on absolutely no 
> one will ever write a function that gets within many orders of magnitude of 
> the limit. So your question is interesting in a hypothetical sense but not 
> in a practical sense. For the former I suggest you start a research project 
> and write a paper for review that explains why, or why not, the existing 
> limit is a problem.
>  
>
>> On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:
>>
>>> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
>>>
>>>> A linked list, for example, consists of pointers to pointers to 
>>>> pointers...
>>>>
>>>> Why should any limit exist to the length of the list except resources 
>>>> available?
>>>>
>>>
>>> Yes, but the O.P. was asking about a silly example. Specifically, when 
>>> defining a function that receives pointers how many levels of indirection 
>>> are allowed in the declaration. In practice 99.9% of the time a single 
>>> level of indirection is specified and 0.09% of the time two levels are 
>>> specified. Etcetera.  For example, if
>>>
>>> func wtf(i int) {
>>> }
>>>
>>> is supported, which has eight levels of indirection, why isn't 16? 32? 
>>> 64? Etcetera levels of indirection supported when defining a function. It's 
>>> a silly question that shows the O.P. doesn't understand how compilers work. 
>>> Let alone how people use languages like Go in real life.
>>>  
>>>
>>>> On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  
>>>> wrote:
>>>>
>>>>> This morning someone asked about dereferincing a pointer to a pointer 
>>>>> to a pointer
>>>>>
>>>>> At first nobody had ever thought about, let alone knew the answer, but 
>>>>> some example code was shown, and sure enough ***val is possible
>>>>> ```
>>>>> package main
>>>>>
>>>>> import "fmt"
>>>>>
>>>>> func main() {
>>>>> a := 0
>>>>> b := 
>>>>> c := 
>>>>> UltimatePointOne()
>>>>> fmt.Println(a)
>>>>> }
>>>>>
>>>>> func UltimatePointOne(n ***int) {
>>>>> ***n = 1
>>>>> }
>>>>> ```
>>>>>
>>>>>
>>>>> On a lark a go playground example was tried to find what the maximum * 
>>>>> is in Go
>>>>>
>>>>> https://go.dev/play/p/YhibY3p7TSD
>>>>>
>>>>> There's 28 there, but it's not the limit
>>>>>
>>>>> Does anyone know what the upper bound on this could be?
>>>>>
>>>>> 256 * ?
>>>>>
>>>>> 32k * ?
>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "golang-nuts" group.
>>>>> To unsubscribe from this group and stop receiving emails fr

Re: [go-nuts] Pointer to a pointer

2022-03-09 Thread shan...@gmail.com
Um

Really?

Which of these things are you specifically trying to prevent happening
 - Curiousity
 - Creativity
 - Asking questions
 - Some combination of the above


I mean, I appreciate that you think that people should *know* whatever it 
is you think you know, but that's a really *really* poor response

On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:

> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>> A linked list, for example, consists of pointers to pointers to 
>> pointers...
>>
>> Why should any limit exist to the length of the list except resources 
>> available?
>>
>
> Yes, but the O.P. was asking about a silly example. Specifically, when 
> defining a function that receives pointers how many levels of indirection 
> are allowed in the declaration. In practice 99.9% of the time a single 
> level of indirection is specified and 0.09% of the time two levels are 
> specified. Etcetera.  For example, if
>
> func wtf(i int) {
> }
>
> is supported, which has eight levels of indirection, why isn't 16? 32? 64? 
> Etcetera levels of indirection supported when defining a function. It's a 
> silly question that shows the O.P. doesn't understand how compilers work. 
> Let alone how people use languages like Go in real life.
>  
>
>> On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  wrote:
>>
>>> This morning someone asked about dereferincing a pointer to a pointer to 
>>> a pointer
>>>
>>> At first nobody had ever thought about, let alone knew the answer, but 
>>> some example code was shown, and sure enough ***val is possible
>>> ```
>>> package main
>>>
>>> import "fmt"
>>>
>>> func main() {
>>> a := 0
>>> b := 
>>> c := 
>>> UltimatePointOne()
>>> fmt.Println(a)
>>> }
>>>
>>> func UltimatePointOne(n ***int) {
>>> ***n = 1
>>> }
>>> ```
>>>
>>>
>>> On a lark a go playground example was tried to find what the maximum * 
>>> is in Go
>>>
>>> https://go.dev/play/p/YhibY3p7TSD
>>>
>>> There's 28 there, but it's not the limit
>>>
>>> Does anyone know what the upper bound on this could be?
>>>
>>> 256 * ?
>>>
>>> 32k * ?
>>>
>>> -- 
>>> 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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/974ff13d-59ff-41f5-90a2-9a3ccd08f10dn%40googlegroups.com.


[go-nuts] Pointer to a pointer

2022-03-09 Thread shan...@gmail.com
This morning someone asked about dereferincing a pointer to a pointer to a 
pointer

At first nobody had ever thought about, let alone knew the answer, but some 
example code was shown, and sure enough ***val is possible
```
package main

import "fmt"

func main() {
a := 0
b := 
c := 
UltimatePointOne()
fmt.Println(a)
}

func UltimatePointOne(n ***int) {
***n = 1
}
```


On a lark a go playground example was tried to find what the maximum * is 
in Go

https://go.dev/play/p/YhibY3p7TSD

There's 28 there, but it's not the limit

Does anyone know what the upper bound on this could be?

256 * ?

32k * ?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%40googlegroups.com.


[go-nuts] Re: Go 1.16.7 and 1.15.15

2021-08-04 Thread shan...@gmail.com

Ok lazyreader (IRC) has discovered that the release has a  commit, relating 
to a CVE on handler panics that we think is the reason for the release 
(fixed my previously erroneous assertion of a single commit, and tidied up 
the wording a little)

The changeset is
https://go-review.googlesource.com/c/go/+/338551/2/src/net/http/httputil/reverseproxy.go


On Thursday, August 5, 2021 at 8:30:23 AM UTC+10 shan...@gmail.com wrote:

>
> Hi all
>
> My bot picked up that there was a release from github of Go for versions 
> 1.16.7, and 1.15.15
>
> But I cannot find any release notes or supporting documentation, and the 
> release hasn't (yet) made it to downloads
>
> Was this an unintentional release?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b218a633-a34d-4365-807c-982510d24a40n%40googlegroups.com.


[go-nuts] Re: Go 1.16.7 and 1.15.15

2021-08-04 Thread shan...@gmail.com
Ok lazyreader (IRC) has discovered that the release has a single commit, 
relating to a CVE relating to handler panics

The changeset is
https://go-review.googlesource.com/c/go/+/338551/2/src/net/http/httputil/reverseproxy.go

On Thursday, August 5, 2021 at 8:30:23 AM UTC+10 shan...@gmail.com wrote:

>
> Hi all
>
> My bot picked up that there was a release from github of Go for versions 
> 1.16.7, and 1.15.15
>
> But I cannot find any release notes or supporting documentation, and the 
> release hasn't (yet) made it to downloads
>
> Was this an unintentional release?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d29c3783-b974-4c0e-8c71-a4d581e829f7n%40googlegroups.com.


[go-nuts] Go 1.16.7 and 1.15.15

2021-08-04 Thread shan...@gmail.com

Hi all

My bot picked up that there was a release from github of Go for versions 
1.16.7, and 1.15.15

But I cannot find any release notes or supporting documentation, and the 
release hasn't (yet) made it to downloads

Was this an unintentional release?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4d51dbbc-53fc-4e5e-ac57-65ea1766ac43n%40googlegroups.com.


Re: [go-nuts] Slice header

2020-11-10 Thread shan...@gmail.com


On Tuesday, November 10, 2020 at 10:09:44 PM UTC+11 
axel.wa...@googlemail.com wrote:

> On Tue, Nov 10, 2020 at 11:09 AM shan...@gmail.com  
> wrote:
>
>> This seems to me to be the better solution (but it's still in the 
>> pipeline?) https://github.com/golang/go/issues/19367
>> an unsafe, rather than reflect, access to the slice structure, which 
>> allows a user to do.. interesting things to the object. Am I correct in 
>> thinking that this change (when implemented) removes the reflect 
>> implementations, and does away with the comments?
>>
>
> I agree that with unsafe.Slice there shouldn't be any more use cases that 
> necessitate use of reflect.SliceHeader. I don't think it should be removed 
> outright though. There is no need to break existing programs using it, even 
> if we consider it allowed from the compatibility guarantee. Likewise, the 
> comments should persist, so that readers of existing code can look up its 
> documentation.
>
> We can definitely add a note that unsafe.Slice and [0]/len/cap should be 
> used instead, though. 
>

That makes sense. 
 

> But, just to be clear, I also don't think anything substantially changes 
> in terms of compatibility guarantees - unsafe.Slice will give just as 
> little a guarantee as reflect.SliceHeader does today.
>
>
After sleeping on it I realised that that was the case (few guarantees for 
unsafe.Slice), but I feel that the fact that it will be in the unsafe 
package makes this a little more explicit
 

>
>> -- 
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/669b67cd-6336-49ae-be04-4eade048b84an%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/669b67cd-6336-49ae-be04-4eade048b84an%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0c774a9f-4f5e-4f93-958f-213f34d02041n%40googlegroups.com.


Re: [go-nuts] Slice header

2020-11-10 Thread shan...@gmail.com


On Tuesday, November 10, 2020 at 9:41:09 PM UTC+11 Jan Mercl wrote:

Thank you for taking the time to answer, I'm still a little confused and 
have inlined where that confusion is below.

On Tue, Nov 10, 2020 at 11:09 AM shan...@gmail.com  
> wrote: 
>
> > My confusion is this, the comment says (very clearly) 
> > It's not safe, nor portable, and may change (although I have had it 
> pointed out to me that the comparability guarantee may contradict this) 
>
> It does not. When there exists explicit documentation for the 
> contrary, it means the contrary. 
>
>
Sorry, because you quoted the whole string I am confused what you mean (on 
reflection I am thinking you are just saying that the documentation is 
contrary to the compatibility guarantee and as such the sliceheader is not 
subject to that guarantee)
 

> > Further the Data field reference won't stop the Garbage collector 
> removing the data 
>
> It's the same as for any other uintptr anywhere else. It's not a 
> pointer and thus does not guarantee reachability of its "pointee". The 
> documentation just reminds of this. 
>
>
Ah, yes I see what you mean

> So, can someone explain to me what it's purpose in life is (there's 
> suggestion that it was a temporary fix that, like all things temporary, has 
> become permanent, and if so, I wonder if that means the documentation needs 
> updating) 
>
> This does not make reflect.SliceHeader unusable though. The 
> reflect.SliceHeader is either aliased to a real slice or is later 
> unsafely converted to one. Then the uintptr field is no more an 
> uintptr, but a real pointer. The documentation points out that _in 
> between_ one has to guarantee the reachability by other means, the 
> only pseudo-reference of the uintptr value is not sufficient for that. 
>
>  
So, the only two uses I have found for this is
1) A Teaching aid, showing people what a slice is under the hood
2) This piece of code that I have just found that converts/moves a C array 
into a Go slice
```
func getArr(which int) []byte {
var theCArray *C.char = C.getTheArray(C.int(which))
length := int(C.BLOCKSIZE)
var theGoSlice []byte
sliceHeader := (*reflect.SliceHeader)((unsafe.Pointer()))
sliceHeader.Cap = length
sliceHeader.Len = length
sliceHeader.Data = uintptr(unsafe.Pointer(theCArray))
// now theGoSlice is a normal Go slice backed by the C array
return theGoSlice
}
``` 

Are there other uses?

I see nothing in the documentation that needs to be updated. It's 
> possible that it could be improved to become better understood as it 
> seems it's not always working that way. 
>

I think it does need some attention for clarity, I'm still a little 
confused what exactly it's trying to convey (The way it's written, to me at 
least, says, don't use this because it's unsafe, non-portable, and may 
change)

One other bone of contention the term "sliceheader" appears only in the 
reflect package.
But https://blog.golang.org/slices uses the term liberally to refer to an 
example slice struct that appears to be like the one found 
in https://github.com/golang/go/blob/master/src/runtime/slice.go#L13

I *know* this is nit picking, but I feel that the blog should be clear that 
the term is purely informal, a number of times I have been told that that 
use of the term in the blog means that is what the struct is officially 
called

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8cafdfbf-7973-4a29-a160-06e72d0ff7bdn%40googlegroups.com.


[go-nuts] Slice header

2020-11-10 Thread shan...@gmail.com
A bit of attention has been directed at slices recently, with a few high 
profile blogs shining a healthy light on them (they can be traps for young 
players!)

I'm a bit confused about SliceHeader as found in the reflect package 
(https://github.com/golang/go/blob/master/src/reflect/value.go#L1986).

The comment in the code, and in the documentation at 
https://golang.org/pkg/reflect/#SliceHeader says
SliceHeader is the runtime representation of a slice. It cannot be used 
safely or portably and its representation may change in a later release. 
Moreover, the Data field is not sufficient to guarantee the data it 
references will not be garbage collected, so programs must keep a separate, 
correctly typed pointer to the underlying data.

My confusion is this, the comment says (very clearly)
It's not safe, nor portable, and may change (although I have had it pointed 
out to me that the comparability guarantee may contradict this)
Further the Data field reference won't stop the Garbage collector removing 
the data

So, can someone explain to me what it's purpose in life is (there's 
suggestion that it was a temporary fix that, like all things temporary, has 
become permanent, and if so, I wonder if that means the documentation needs 
updating)

This seems to me to be the better solution (but it's still in the 
pipeline?) https://github.com/golang/go/issues/19367
an unsafe, rather than reflect, access to the slice structure, which allows 
a user to do.. interesting things to the object. Am I correct in thinking 
that this change (when implemented) removes the reflect implementations, 
and does away with the comments?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/669b67cd-6336-49ae-be04-4eade048b84an%40googlegroups.com.