[go-nuts] Re: Unit testing slog output
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
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
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
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
> 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
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
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
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
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
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
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
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
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.
