[go-nuts] Re: [slog] customize defaultHandler
Hi Tamás,
Have you actually tried that and gotten it to work? It does not compile
for me but this does (note method call vs. property reference):
slog.SetDefault(slog.New(myHandler{Handler:slog.Default().Handler()}))
However, when delegating the Handle() method it seems to cause an infinite
loop:
func (m MyHandler) Handle(ctx context.Context, r slog.Record) error {
return m.Handler.Handle(ctx, r)
}
See https://goplay.tools/snippet/qw07m0YflLd
I know about this because just this past weekend I was trying to write a
TeeHandler to output the default to the screen and JSON to a file just this
past weekend and ran into an infinite loop problem with the default handler.
I tried my best to figure out why it needed to be structured the way it was
in that it seems to call itself recursively. I wanted to post a question to
this list to see if there was a workaround, or if not to see if there might
be interest in allowing it to work, but I could not get my head around it so
eventually gave up and just used the TextHandler instead.
Shame though. It would be nice to be able to reuse the default handler but
AFACT it is not possible (though if I am wrong I would love for someone to
show me how to get it to work.)
-Mike
On Monday, August 28, 2023 at 12:50:50 PM UTC-4 Tamás Gulácsi wrote:
slog.SetDefault(slog.New(myHandler{Handler:slog.Default().Handler}))
vl...@mailbox.org a következőt írta (2023. augusztus 28., hétfő, 15:06:37
UTC+2):
Hi,
When reading trough the log/slog documentation, it seems one can create
a logger with a different handler, which is either NewTextHandler or
NewJSONHandler.
Why can't I configure the defaultHandler? Let's say I want my logger to
behave exactly like the defaultHandler, but output to a logfile or
Stdout instead.
The defaultHandler's output is different compared to the NewTextHandler:
slog.Info("ok"), gives me:
INFO ok
The NextTextHandler gives me:
level=INFO msg="ok"
Regards,
--
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/f35b9d1a-86bf-446b-a0c7-54cb197b0116n%40googlegroups.com.
Re: [go-nuts] Is it safe to keep noCopy types in a slice which might copy on re-alloc?
On Sun, Aug 27, 2023 at 2:28 PM Antonio Caceres Cabrera
wrote:
>
> Thanks for your reply, Ian.
> I've decided on using a []*Foo now. Just to clarify, however: In general,
> copying/assigning from a struct literal as in
> a[i] = Foo{}, is that always safe for these sync types? Or generally, is
> copying their "untouched" zero-values always safe?
Yes, in general it's safe to copy the untouched zero value of these types.
Ian
> On Sunday, August 27, 2023 at 7:05:15 PM UTC+2 Ian Lance Taylor wrote:
>>
>> On Sun, Aug 27, 2023 at 7:54 AM Antonio Caceres Cabrera
>> wrote:
>> >
>> > Go vet complains about this minimal example code
>> >
>> > type Foo struct {
>> > val atomic.Uint64
>> > }
>> >
>> > func main() {
>> > var foos = make([]Foo, 0)
>> > var bar Foo
>> > bar.val.Store(5)
>> > foos = append(foos, bar) // call of append copies lock value:
>> > example.com/foo.Foo contains sync/atomic.Uint64 contains sync/atomic.noCopy
>> >
>> > }
>> >
>> > Because the types of the sync package are not supposed to be copied.
>> > This is also true for sync.Map, sync.Mutex, sync.WaitGroup etc.
>> >
>> > However, if I instead copy in a zero-value Foo and then set that, go vet
>> > does not complain, even if later appends are done:
>> >
>> > func main() {
>> > var foos = make([]Foo, 0)
>> > foos = append(foos, Foo{})
>> > foos[0].val.Store(5)
>> > foos = append(foos, Foo{})
>> > foos = append(foos, Foo{})
>> > // append some more
>> > // ...
>> > fmt.Println(foos)
>> > }
>> >
>> > However, is this supposed to be safe, or is go vet just not catching it?
>> > Even if copying a zero-value of such a type is safe, append() might have
>> > to re-allocate the underlying array, which includes copying the existing
>> > values, which might already have been used, as foo[0] has been in this
>> > case. This would violate the noCopy trait of the type. My question is thus:
>> >
>> > Is it safe to keep nocopy types from the sync and sync.atomic packages in
>> > a slice, given that they might internally be copied when the slice is
>> > appended to?
>> >
>> > Of course, copying these types is not by itself atomic or synchronized
>> > with other accesses. So let's assume that I, as the programmer, guarantee
>> > that while an append happens, this slice will only be accessed by the one
>> > appending goroutine, using other synchronization primitives, such as
>> > mutex, channels etc. or by only running these appends in the main before
>> > any other go-routine is started.
>>
>> Doing an append on a slice of types that contain atomic types is in
>> general not safe and go vet is not catching it.
>>
>> If your program can guarantee that while the append is happening there
>> is no concurrent access to the atomic types, then I think that is
>> safe. It's not safe in general for all nocopy types, but it's safe
>> for types like atomic.Uint64. It doesn't seem like a very clear way
>> to write a program though. It may be better to use a slice of
>> pointers: in your example, []*Foo. Or precount the size of the slice
>> to ensure that append won't copy it.
>>
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6ad297ba-19d4-4eaf-a2c2-252ca9db390cn%40googlegroups.com.
--
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/CAOyqgcUY9R%2Bm74Dzf4Z_Gp1BQ8eCRBNzrNW4xW1PEbQPfgK7pg%40mail.gmail.com.
[go-nuts] Re: [slog] customize defaultHandler
slog.SetDefault(slog.New(myHandler{Handler:slog.Default().Handler}))
vl...@mailbox.org a következőt írta (2023. augusztus 28., hétfő, 15:06:37
UTC+2):
> Hi,
>
> When reading trough the log/slog documentation, it seems one can create
> a logger with a different handler, which is either NewTextHandler or
> NewJSONHandler.
>
> Why can't I configure the defaultHandler? Let's say I want my logger to
> behave exactly like the defaultHandler, but output to a logfile or
> Stdout instead.
>
> The defaultHandler's output is different compared to the NewTextHandler:
>
> slog.Info("ok"), gives me:
>
> INFO ok
>
> The NextTextHandler gives me:
>
> level=INFO msg="ok"
>
>
> Regards,
>
>
--
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/09cba7f7-6109-4874-9ab3-1584771499cdn%40googlegroups.com.
[go-nuts] [slog] customize defaultHandler
Hi,
When reading trough the log/slog documentation, it seems one can create
a logger with a different handler, which is either NewTextHandler or
NewJSONHandler.
Why can't I configure the defaultHandler? Let's say I want my logger to
behave exactly like the defaultHandler, but output to a logfile or
Stdout instead.
The defaultHandler's output is different compared to the NewTextHandler:
slog.Info("ok"), gives me:
INFO ok
The NextTextHandler gives me:
level=INFO msg="ok"
Regards,
--
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/be7c2e16-68b5-4d32-ae99-3b6786b32fa0%40mailbox.org.
