[go-nuts] Re: When will the official encoding/json package support parsing json5？

[jan.f...@gmail.com]

Just googled for "json5 golang" and there seem to be several 3rd party 
implementations available.
Can you not use one of those?

söndag 20 mars 2022 kl. 14:27:05 UTC skrev Brian Candler:

> If you're going down that route, you could also consider jsonnet 
>  (which does have a Go implementation 
> )
>
> It will almost certainly be much more powerful than you need, but it *is* 
> another superset of JSON which includes comments.
>
> On Sunday, 20 March 2022 at 13:16:20 UTC christoph...@gmail.com wrote:
>
>> You might want to try qjson that I wrote a year ago (
>> https://github.com/qjson). 
>> It's basically just one function that converts qjson text into json. 
>> Qjson is inspired by hjson, but extend it in many ways. 
>> It is convenient for config files. 
>>
>> Maybe I extend it a bit too far by supporting unquoted strings or single 
>> quoted strings. Lol
>>
>>
>> Le samedi 19 mars 2022 à 01:03:17 UTC+1, ben...@gmail.com a écrit :
>>
>>> Yeah, Go's encoding/json will almost certainly never support json5. 
>>> However, one very simple approach: if you're using JSON for a config file 
>>> and just need ability to add // line comments, you can just write a simple 
>>> transformer which reads the file line by line and filters out lines that 
>>> start with "//" (optionally preceded by whitespace), and then send the 
>>> result to encoding/json.
>>>
>>> On Friday, March 18, 2022 at 1:59:21 PM UTC+13 r...@rwx.gg wrote:
>>>
 It is my sincere hope that Go will never support anything as poorly 
 designed as JSON5, using reflection is already slow enough. Comments were 
 never intended for JSON and never should be added, ever. But since most 
 discerning development shops are moving to Protobuf for everything that 
 matters, perhaps that would be less of a problem.

 On Monday, March 14, 2022 at 12:07:37 PM UTC-4 fliter wrote:

> I need to add comments to json, but now json version does not support 
> it
>


-- 
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/d9c5fe9e-0109-438a-a932-b9d45c9328b3n%40googlegroups.com.

Re: [go-nuts] Any good idea to stop the goroutine as soon as possible?

[jan.f...@gmail.com]

Just a related observation. I don't think you need to have a select 
statement to check if a context is cancelled. I think it is sufficient to 
just check if ctx.Err() gives a result different from nil.

>From the API documentation for Context (https://pkg.go.dev/context#Context):
// If Done is not yet closed, Err returns nil. 
// If Done is closed, Err returns a non-nil error explaining why: 
// Canceled if the context was canceled 
// or DeadlineExceeded if the context's deadline passed. 
// After Err returns a non-nil error, successive calls to Err return the 
same error.
Err() error 

//Jan

onsdag 12 januari 2022 kl. 09:41:23 UTC+1 skrev lege...@gmail.com:

> Hi Axel, thank you very much, your explanation of this problem is very 
> detailed and solves my question.
>
> What I think it's not so good is that I must add the select at all the 
> places the goroutine is waiting or looping, it makes the execution and 
> scheduling part of the task scheduling system coupling a bit tightly, 
> because I need to implement many different types of tasks, and I have to 
> consider the cancel logic (which I think belongs to scheduling part) 
> explicitly in each type of task executor, instead of leaving it all to the 
> scheduling part. I think it will be better if the task executor can only 
> consider the business logic.
>
> I also tried to abstract this cancel logic into generic processing so that 
> it could be easily applied to different types of tasks, but I didn't find a 
> good way to do this, I had to manually add the code wherever it was needed
>
> On Tue, Jan 11, 2022 at 10:31 PM Axel Wagner  
> wrote:
>
>>
>>
>> On Wed, Jan 12, 2022 at 3:01 AM E Z  wrote:
>>
>>> Thank you very much.
>>>
>>> I understand that we can use context.Context to resolve the network 
>>> blocking problem in long-running function if the network library support 
>>> passing a context parameter. 
>>>
>>> But for the CPU-bound code,  Is the following implementation mentioned 
>>> by axel the only way to make a function exit earlier?
>>>
>>
>> It's not the only way, but it's the way I'd generally recommend. 
>> Universally using `context.Context` to signal cancellation solves exactly 
>> the problem you where having. Specifically,
>>
>> > The above code is executing in a goroutine, if I want to cancel this 
>> goroutine, I can send a signal to task.channel, but the signal only can be 
>> retrieved after the task.task.Run is finished, it may be a long time, such 
>> as 5 mins. 
>>
>> If `task.task.Run` takes a `context.Context`, it can exit sooner than 
>> after 5 minutes. If it takes that long because it does remote requests, it 
>> can propagate the Context itself. If it is CPU-bound, it can check if the 
>> Context was cancelled, say, every 1000 iterations (or whatever. What's a 
>> reasonable number depends heavily on what it's doing).
>>
>> But, yes, for such a CPU-bound task, actively checking if it was 
>> cancelled via a mechanism like a Context is the only way to be aborted.
>>
>> For example, goroutine is executing a task to update a DNS record and 
>>> then wait some time until the DNS record takes effect in some name 
>>> servers.  It may take some seconds even minutes to make the DNS record take 
>>> effect in the name server.
>>>
>>
>> To be clear, this is not a CPU-bound process. Updating the DNS record is 
>> either a network request/IPC. The waiting is then a loop like
>>
>> for {
>> select {
>> case <-ctx.Done():
>> return ctx.Err()
>> case <-time.After(time.Second()): // simplistic, you'd likely want 
>> some jitter and/or exponential backoff here
>> if recordHasChanged(ctx) { // network request to check if the DNS 
>> record has changed - takes a Context, as it's a network request
>> return nil
>> }
>> }
>> }
>>
>> This will spend most of its time sleeping.
>>
>> A CPU-bound task is something like a diff-operation, which is just an 
>> algorithm that can be very slow for large inputs, just because it has a lot 
>> of work to churn through.
>>
>> In this case, seems I can't cancel the running goroutine except that we 
>>> add the above select at every for loop or wait timer, or  I change the 
>>> design to split these time-consuming operations into different goroutine. 
>>> Both seem not so good.
>>>
>>
>> I don't understand why you think this is not good. It seems perfectly 
>> reasonable code. But yes, it's what you have to do. Go has no way to 
>> asynchronously stop code, you need to manually cancel. And context.Context 
>> gives a universal mechanism to do that, which I would recommend using for 
>> that.
>>  
>>
>>>
>>> On Tuesday, January 11, 2022 at 1:04:15 PM UTC-8 Ian Lance Taylor wrote:
>>>
 On Tue, Jan 11, 2022 at 12:15 PM 'Axel Wagner' via golang-nuts 
  wrote: 
 > 
 > The best way to do this is to plumb a context.Context through all 
 long-running functions - in particular, anything talking to the 

Re: [go-nuts] Re: go build prints gc traces

[jan.f...@gmail.com]

tisdag 14 september 2021 kl. 02:48:15 UTC+2 skrev Ian Lance Taylor:

> Sounds related to https://golag.org/issue/27628. The build cache 
> caches the output of the tools. You may have gotten a build cache 
> entry with GODEBUG set, and that kept being used even though GODEBUG 
> was not set later. 
>

That explains it. Thanks.

Regards
//Jan Flyborg

-- 
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/716567a1-c617-4d91-9522-06bbc1fad1bcn%40googlegroups.com.

[go-nuts] Re: go build prints gc traces

[jan.f...@gmail.com]

Hi again,

Removed ~/Library/Caches/go-build and the problem is now gone. Still I 
would like to know what caused this.

Regards
//Jan Flyborg

måndag 13 september 2021 kl. 23:09:14 UTC+2 skrev jan.f...@gmail.com:

> Hi everyone!
>
> Since I upgraded to Go 1.17.1 on macOS, it seems like whenever I run the 
> compiler, it prints out GC traces just like it was invoked with 
> GODEBUG=gctrace=1.
>
> It might look like this:
>
> $ go build main.go
> # github.com/pion/dtls/v2/pkg/crypto/clientcertificate
> gc 1 @0.004s 6%: 0.012+1.8+0.013 ms clock, 0.077+0.11/2.1/1.4+0.079 ms 
> cpu, 4->4->3 MB, 5 MB goal, 6 P
> # github.com/pion/dtls/v2/pkg/crypto/signature
> gc 1 @0.003s 4%: 0.008+1.6+0.087 ms clock, 0.051+0.081/0.91/2.0+0.52 ms 
> cpu, 4->4->3 MB, 5 MB goal, 6 P
> ...
> Many more lines omitted
>
> I cannot for my world understand what is causing this. The GODEBUG 
> environment variable is not set, and I also have no aliases in the shell 
> that could explain this. 
>
> Went back to Go 1.16.8 and the problem is gone. Also built my own tool 
> chain from the 1.17 release branch of https://github.com/golang/go.git, 
> and it gives me the same behavior, by printing out GC traces.
>
> I must be missing something really simple, so does anyone have any ideas?
>
> Regards
> //Jan Flyborg
>
>

-- 
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/aeffe934-b71c-4fc6-915b-f740eeb00eean%40googlegroups.com.

[go-nuts] go build prints gc traces

[jan.f...@gmail.com]

Hi everyone!

Since I upgraded to Go 1.17.1 on macOS, it seems like whenever I run the 
compiler, it prints out GC traces just like it was invoked with 
GODEBUG=gctrace=1.

It might look like this:

$ go build main.go
# github.com/pion/dtls/v2/pkg/crypto/clientcertificate
gc 1 @0.004s 6%: 0.012+1.8+0.013 ms clock, 0.077+0.11/2.1/1.4+0.079 ms cpu, 
4->4->3 MB, 5 MB goal, 6 P
# github.com/pion/dtls/v2/pkg/crypto/signature
gc 1 @0.003s 4%: 0.008+1.6+0.087 ms clock, 0.051+0.081/0.91/2.0+0.52 ms 
cpu, 4->4->3 MB, 5 MB goal, 6 P
...
Many more lines omitted

I cannot for my world understand what is causing this. The GODEBUG 
environment variable is not set, and I also have no aliases in the shell 
that could explain this. 

Went back to Go 1.16.8 and the problem is gone. Also built my own tool 
chain from the 1.17 release branch of https://github.com/golang/go.git, and 
it gives me the same behavior, by printing out GC traces.

I must be missing something really simple, so does anyone have any ideas?

Regards
//Jan Flyborg

-- 
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/7f499256-a40e-4e4f-bd12-bf03b6ad374fn%40googlegroups.com.

[go-nuts] How to get hold of GOARM at runtime?

[jan.f...@gmail.com]

Hi,

Short question: GOARCH and GOOS is available from the runtime package, but 
how do I get hold of the corresponding variable GOARM at runtime? 

Best Regards
//Jan Flyborg

-- 
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/78834d26-b4b0-432b-896e-3caf0bd73b8an%40googlegroups.com.