Re: [go-nuts] Slog and error tracing

['Jim Idle' via golang-nuts]

You are logging the same error many times and then trying to solve that in
the logs.

Try this:

Only log the error where it is handled, otherwise wrap it and return it
without logging. At some point, you will log it as either an error if there
is nothing you can do about it, or a warning if somehow you can recover
from it (not panic recover). However your log record will contain the trace
from the point where the error occurred, so you have all the information
you need.

In short: log the error once, at the point you handle it.

On Thu, Aug 10, 2023 at 8:38 PM jal...@gmail.com  wrote:

> Hi all,
>
> I've adopted slog and I am really loving the library.  As I have used this
> on my team, I've noticed a repetitive problem with error wrapping and I am
> curious how other folks have handled this problem.
>
> Lets say you are calling a sequence of functions where one function
> depends on the result of the next function in the sequence. Each function
> returns an error. For traceability, you want to log the error where it was
> encountered, then wrap the error in the current function and return it. You
> then repeat this all the way up the stack. See here for a simplified
> example:
>
> https://go.dev/play/p/uDWU1JucG5W
>
> This has the benefit of clearly communicating what caused the failure in
> each function. It has the drawback that you are repeatedly logging the same
> error information multiple times. Depending on the error text, this could
> turn into a wall of text that makes interpreting logs quite hard for an
> engineer. I learned this the hard way when i use github.com/pkg/errors
> and would print out the stacktrace.
>
> So then I wondered about using context to inject a traceId that would link
> log messages together. I banged out quickly a small library as a PoC.
> Here's what that looks like:
>
> https://go.dev/play/p/BhARBtthdzJ
>
> This allows me to trace back the cause across the logs by sorting by time
> and filtering for the trace id. Means I only need to log the error once.
> The negative here is you have to pass context around for any function that
> logswhich is probably most of them when most of those functions don't
> need to do cancellation. I suppose you could just do context.Background.
>
> So that's what I've come up with. I am curious what others have done.
>
> Thanks,
> Joe
>
> P.S Note yes i know the problem is distributed tracing, that logging is a
> poor way to do this, and one should use an observability platform like
> honeycomb.io  to send errors too. But I don't
> have a platform. I have slog and i am curious how to make error tracing
> work nicely with that.
>
> --
> 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/3a786e33-cb56-4bf5-8e84-d8bfbda7737en%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/CAGPPfg_NwFtTm_%2BZRVbgKCFR7iG85neh%3DUDeCXq1aWVQJgQGZA%40mail.gmail.com.

Re: [go-nuts] binary.ByteOrder

[TheDiveO]

https://github.com/google/nftables/blob/main/binaryutil/binaryutil.go ... 
could give you some bad ideas; we need it for Linux nftables that encodes 
stuff in host endianess.

On Thursday, August 10, 2023 at 3:27:49 PM UTC+2 Stephen Illingworth wrote:

> Thanks. Although I'm not worried about the native byte order of my machine
>
> I'm writing an ARM emulator. The endianness of the ARM I'm taking to be 
> whatever the endianess is in the ELF file from which I'm loading the 
> program. I'm using the debug/elf package in the standard library which in 
> turn uses the binary package
>
> Generally, the specifics of the byte order is irrelevant - I can just use 
> Uint32(), PutUint32() etc. but in some specific instructions it's easier to 
> handle the byte order manually and for that I need to know what the 
> endianness is.
>
> I can work around it but I just thought I might be missing something.
>
>
> Regards
> Stephen
> On Thursday, 10 August 2023 at 14:16:53 UTC+1 Rob Pike wrote:
>
>> First read 
>> https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html
>>
>> then see
>>
>> https://go.dev/play/p/4ESm6nOwgtY
>>
>> -rob
>>
>>
>>
>>
>>
>>
>> On Thu, Aug 10, 2023 at 8:46 PM Stephen Illingworth <
>> stephen.i...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I want to detect the implementation of binary.ByteOrder. ie. whether it 
>>> is Little Endian or Big Endian.
>>>
>>> Normally, you would do this with a type assertion or a type switch but 
>>> in the case of the binary package the little/big endian implementations are 
>>> not exported.
>>>
>>> The only way that I can see to distinguish between the implementations 
>>> is to test the value returned by String(). Am I missing something here or 
>>> should I continue to use String()?
>>>
>>> Regards
>>> Stephen
>>>
>>> -- 
>>> 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/67469c8a-b1aa-4976-8f4a-2b4458d28214n%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/7218dc7e-e136-47aa-b59b-a4f98f2dedd2n%40googlegroups.com.

Re: [go-nuts] binary.ByteOrder

[Stephen Illingworth]

Thanks. Although I'm not worried about the native byte order of my machine

I'm writing an ARM emulator. The endianness of the ARM I'm taking to be 
whatever the endianess is in the ELF file from which I'm loading the 
program. I'm using the debug/elf package in the standard library which in 
turn uses the binary package

Generally, the specifics of the byte order is irrelevant - I can just use 
Uint32(), PutUint32() etc. but in some specific instructions it's easier to 
handle the byte order manually and for that I need to know what the 
endianness is.

I can work around it but I just thought I might be missing something.


Regards
Stephen
On Thursday, 10 August 2023 at 14:16:53 UTC+1 Rob Pike wrote:

> First read 
> https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html
>
> then see
>
> https://go.dev/play/p/4ESm6nOwgtY
>
> -rob
>
>
>
>
>
>
> On Thu, Aug 10, 2023 at 8:46 PM Stephen Illingworth <
> stephen.i...@gmail.com> wrote:
>
>> Hello,
>>
>> I want to detect the implementation of binary.ByteOrder. ie. whether it 
>> is Little Endian or Big Endian.
>>
>> Normally, you would do this with a type assertion or a type switch but in 
>> the case of the binary package the little/big endian implementations are 
>> not exported.
>>
>> The only way that I can see to distinguish between the implementations is 
>> to test the value returned by String(). Am I missing something here or 
>> should I continue to use String()?
>>
>> Regards
>> Stephen
>>
>> -- 
>> 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/67469c8a-b1aa-4976-8f4a-2b4458d28214n%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/618e2a97-670f-4df7-98f3-a9b576ad8971n%40googlegroups.com.

Re: [go-nuts] binary.ByteOrder

[Rob Pike]

First read
https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html

then see

https://go.dev/play/p/4ESm6nOwgtY

-rob






On Thu, Aug 10, 2023 at 8:46 PM Stephen Illingworth <
stephen.illingwo...@gmail.com> wrote:

> Hello,
>
> I want to detect the implementation of binary.ByteOrder. ie. whether it is
> Little Endian or Big Endian.
>
> Normally, you would do this with a type assertion or a type switch but in
> the case of the binary package the little/big endian implementations are
> not exported.
>
> The only way that I can see to distinguish between the implementations is
> to test the value returned by String(). Am I missing something here or
> should I continue to use String()?
>
> Regards
> Stephen
>
> --
> 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/67469c8a-b1aa-4976-8f4a-2b4458d28214n%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/CAOXNBZTm3q-XFAcVrY1oDjMviSAY%2B_B9x9qySAc0AKn5yTX_rQ%40mail.gmail.com.

[go-nuts] Slog and error tracing

[jal...@gmail.com]

Hi all,

I've adopted slog and I am really loving the library.  As I have used this 
on my team, I've noticed a repetitive problem with error wrapping and I am 
curious how other folks have handled this problem. 

Lets say you are calling a sequence of functions where one function depends 
on the result of the next function in the sequence. Each function returns 
an error. For traceability, you want to log the error where it was 
encountered, then wrap the error in the current function and return it. You 
then repeat this all the way up the stack. See here for a simplified 
example:

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

This has the benefit of clearly communicating what caused the failure in 
each function. It has the drawback that you are repeatedly logging the same 
error information multiple times. Depending on the error text, this could 
turn into a wall of text that makes interpreting logs quite hard for an 
engineer. I learned this the hard way when i use github.com/pkg/errors and 
would print out the stacktrace.

So then I wondered about using context to inject a traceId that would link 
log messages together. I banged out quickly a small library as a PoC. 
Here's what that looks like:

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

This allows me to trace back the cause across the logs by sorting by time 
and filtering for the trace id. Means I only need to log the error once. 
The negative here is you have to pass context around for any function that 
logswhich is probably most of them when most of those functions don't 
need to do cancellation. I suppose you could just do context.Background. 

So that's what I've come up with. I am curious what others have done.

Thanks,
Joe

P.S Note yes i know the problem is distributed tracing, that logging is a 
poor way to do this, and one should use an observability platform like 
honeycomb.io  to send errors too. But I don't 
have a platform. I have slog and i am curious how to make error tracing 
work nicely with that.

-- 
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/3a786e33-cb56-4bf5-8e84-d8bfbda7737en%40googlegroups.com.

[go-nuts] binary.ByteOrder

[Stephen Illingworth]

Hello,

I want to detect the implementation of binary.ByteOrder. ie. whether it is 
Little Endian or Big Endian.

Normally, you would do this with a type assertion or a type switch but in 
the case of the binary package the little/big endian implementations are 
not exported.

The only way that I can see to distinguish between the implementations is 
to test the value returned by String(). Am I missing something here or 
should I continue to use String()?

Regards
Stephen

-- 
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/67469c8a-b1aa-4976-8f4a-2b4458d28214n%40googlegroups.com.

[go-nuts] Is there a good way to make binary files compiled on a high-version machine run on a low-version machine?

[fliter]

I have a project that uses CGO. After compiling on an ubuntu 20.04 
compilation machine, it is distributed to other machines for execution, but 
many of these machines have very low ubuntu versions, which may be ubuntu 
16.04 or ubuntu 18.04.

In this way, when executing the binary file, an error similar to version 
`GLIBC_2.29' not found will be reported.

I try to use -a -ldflags '-extldflags "-static"' when go build. But it 
seems that because of the use of cgo, it cannot be compiled successfully.

Is there any good way, such as adding appropriate tags when go build, to 
solve this problem?

-- 
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/04a8f645-56c7-45b7-938e-3bdaa4b4fa97n%40googlegroups.com.