[go-nuts] Re: strange failure of golang.org/x/crypto/argon2.IDKey

[andre . kuehne . 77]

Thanks Kurtis and Ren, now I see that the memory usage seems very high 
indeed.

I was just debugging this issue I had with 
https://github.com/avahowell/masterkey.
I will open an issue there to ask why this memory parameter has been set so 
high.

-- 
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/41d896e7-1775-467b-9ef6-418ba18bf7bb%40googlegroups.com.

[go-nuts] distributed runtime

[Justin Israel]

Seems like it would just be easier to explicitly schedule work over something 
like nats.io
At least you would have 100% control over what is distributed over the network. 

-- 
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/6bfa45c1-082f-42ad-84c2-cfa7d000d84d%40googlegroups.com.

[go-nuts] Re: strange failure of golang.org/x/crypto/argon2.IDKey

[Ren Thraysk]

Memory parameter to IDKey is in kilobytes. Your code is specifying 200 
kilobytes.

Ren

On Friday, 3 January 2020 07:14:22 UTC, andre@gmail.com wrote:
>
>
> I attached a minimal test program to reproduce an issue with 
> golang.org/x/crypto/argon2.
>
> It calls IDKey twice with the same parameters. The first call executes, 
> but during the second call the program crashes.
>
> Strange thing: The program does not always crash. If it crashes then I can 
> call it multiple times in a row and it always crashes.
> But then maybe if I try a few hours later it does not crash. And if I try 
> it then again and again it will always work normally.
>
> Another curious thing is that when it crashes it usually (but not always) 
> kills the whole terminal emulator (gnome-terminal) with it.
> I am running this on Fedora 31 64-bit (Intel Core i5-5200U).
> strace shows at the end:
>
> +++ killed by SIGKILL +++
>
> The crash happens somewhere in the argon2.processBlocks function.
>
> Any ideas ? Should I open an issue on https://github.com/golang/go ?
>
>
>

-- 
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/abdd2b5e-d5cc-4b00-b86e-b842224deccd%40googlegroups.com.

Re: [go-nuts] Locking goroutine to "main" thread

[robert engels]

Also, even simpler - just remove the time.Atfter case() and use a default: - 
but the problem is you will spin a single thread at 100% cpu - you really need 
to use a blocking sdl.WaitEvent()

> On Jan 3, 2020, at 6:04 PM, robert engels  wrote:
> 
> You only need a single thread locked to the UI thread.
> 
> Use one Go routine locked to the UI thread. Put events onto a channel.
> 
> Have another Go routine read from the channel, and the app command channel 
> using select.
> 
> 
> 
>> On Jan 3, 2020, at 5:28 PM, bucha...@gmail.com  
>> wrote:
>> 
>> Whether the UI thread is on the main thread or a separate thread, a single 
>> UI thread needs to process events from two sources: the OS window and from 
>> my application. Having one loop process both sources (without support from 
>> the Go runtime scheduler) is the part I'm struggling with.
>> 
>> My latest iteration is something like:
>> 
>> for {
>>   // PollEvent doesn't block/sleep
>> 
>>   for ev := sdl.PollEvent(); ev != nil; ev = sdl.PollEvent {
>> // handle OS window events
>>   }
>>   select {
>>   case cmd := <-app.commands:
>> // process application command
>> 
>> cmd()
>>   case <-time.After(10*time.Millisecond):
>> // only wait 10ms for application commands
>> 
>>   }
>> }
>> 
>> 
>> 
>> This is an improvement, but I'd still prefer help from the Go runtime. If 
>> the runtime supported locking two goroutines to the UI thread, I could split 
>> this loop into two separate loops and remove the time.After, I *think*.
>> 
>> On Friday, January 3, 2020 at 2:59:42 PM UTC-8, robert engels wrote:
>> You can definitely run the event loop for a process on a thread other than 
>> main. The main thread is the thread created by the OS to begin running the 
>> process - the UI thread is the one that initializes the Windowing system. 
>> Some OSs even support multiple UI threads (see 
>> https://docs.microsoft.com/en-us/cpp/parallel/multithreading-creating-user-interface-threads?view=vs-2019
>>  
>> )
>> 
>> Go doesn’t do any Windowing system initialization by default - the main 
>> thread in Go (at least according to the referenced library) is the one that 
>> called the package init() - which may not even be the OS main thread since 
>> according to the Go docs "Package initialization—variable initialization and 
>> the invocation of init functions—happens in a single goroutine, 
>> sequentially, one package at a time.” - which makes no claim that this Go 
>> routine is running on the “main” OS thread.
>> 
>> Whatever thread you use to initialize GLFW is the UI thread (or main for 
>> GLFW).
>> 
>> This is pretty standard across windowing/graphics systems.
>> 
>> 
>> 
>> 
>>> On Jan 3, 2020, at 4:02 PM, buch...@ <>gmail.com  wrote:
>>> 
>>> I'm pretty sure the OS event loop is required to be on the main thread. 
>>> 
>>> From the GLFW docs for glfwPollEvents:
>>> "This function must only be called from the main thread."
>>> 
>>> From the SDL docs for SDL_WaitEvent:
>>> "you can only call this function in the thread that initialized the video 
>>> subsystem."
>>> 
>>> 
>>> On Friday, January 3, 2020 at 1:58:29 PM UTC-8, Robert Engels wrote:
>>> Even if you could I don’t think you would want to do it this way. 
>>> 
>>> Have a go routine sleep on a channel. Post to the channel from the native 
>>> code. 
>>> 
>>> Let your command loop run on any thread and synchronize via a channel the 
>>> calls to/from native. 
>>> 
>>> The os event loop doesn’t need to run on main - it just needs to be locked 
>>> to a thread - use a native thread - and post the os events to a channel.  
>>> 
>>> Probably easiest to export a simple Go postToEventChannel() and have the 
>>> native use this. 
>>> 
 On Jan 3, 2020, at 2:18 PM, buch...@ <>gmail.com  wrote:
 
 
 I've been getting by with a version of this that sends commands (closures) 
 to a loop on the main thread:
 https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L55
  
 
 
 And here is where it pops those commands, and also integrates with the OS 
 event loop:
 https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L163
  
 
 
 But, I'm still not satisfied. The solution ties together the scheduling 
 (and code) of two separate event loops. In particular, I've found that my 
 commands are delayed ~10ms – I think sdl.WaitEvent might be rate limited.
 
 What I really want is for the two event loops (OS event loop vs app 
 command loop) to be in two separate goroutines, both running on the 

Re: [go-nuts] Locking goroutine to "main" thread

[robert engels]

In reviewing your comments so more, I think you may be having trouble because 
you are initializing the graphics UI in the init() method. I think that is 
going to make things difficult. You are better off adding a StartUI() - which 
spawns a Go routine that handles all UI communicates (you could spawn this from 
the init() but I think that might make things harder.

You can sync the calls so only a single routine/thread will ever be created.

> On Jan 3, 2020, at 6:04 PM, robert engels  wrote:
> 
> You only need a single thread locked to the UI thread.
> 
> Use one Go routine locked to the UI thread. Put events onto a channel.
> 
> Have another Go routine read from the channel, and the app command channel 
> using select.
> 
> 
> 
>> On Jan 3, 2020, at 5:28 PM, bucha...@gmail.com  
>> wrote:
>> 
>> Whether the UI thread is on the main thread or a separate thread, a single 
>> UI thread needs to process events from two sources: the OS window and from 
>> my application. Having one loop process both sources (without support from 
>> the Go runtime scheduler) is the part I'm struggling with.
>> 
>> My latest iteration is something like:
>> 
>> for {
>>   // PollEvent doesn't block/sleep
>> 
>>   for ev := sdl.PollEvent(); ev != nil; ev = sdl.PollEvent {
>> // handle OS window events
>>   }
>>   select {
>>   case cmd := <-app.commands:
>> // process application command
>> 
>> cmd()
>>   case <-time.After(10*time.Millisecond):
>> // only wait 10ms for application commands
>> 
>>   }
>> }
>> 
>> 
>> 
>> This is an improvement, but I'd still prefer help from the Go runtime. If 
>> the runtime supported locking two goroutines to the UI thread, I could split 
>> this loop into two separate loops and remove the time.After, I *think*.
>> 
>> On Friday, January 3, 2020 at 2:59:42 PM UTC-8, robert engels wrote:
>> You can definitely run the event loop for a process on a thread other than 
>> main. The main thread is the thread created by the OS to begin running the 
>> process - the UI thread is the one that initializes the Windowing system. 
>> Some OSs even support multiple UI threads (see 
>> https://docs.microsoft.com/en-us/cpp/parallel/multithreading-creating-user-interface-threads?view=vs-2019
>>  
>> )
>> 
>> Go doesn’t do any Windowing system initialization by default - the main 
>> thread in Go (at least according to the referenced library) is the one that 
>> called the package init() - which may not even be the OS main thread since 
>> according to the Go docs "Package initialization—variable initialization and 
>> the invocation of init functions—happens in a single goroutine, 
>> sequentially, one package at a time.” - which makes no claim that this Go 
>> routine is running on the “main” OS thread.
>> 
>> Whatever thread you use to initialize GLFW is the UI thread (or main for 
>> GLFW).
>> 
>> This is pretty standard across windowing/graphics systems.
>> 
>> 
>> 
>> 
>>> On Jan 3, 2020, at 4:02 PM, buch...@ <>gmail.com  wrote:
>>> 
>>> I'm pretty sure the OS event loop is required to be on the main thread. 
>>> 
>>> From the GLFW docs for glfwPollEvents:
>>> "This function must only be called from the main thread."
>>> 
>>> From the SDL docs for SDL_WaitEvent:
>>> "you can only call this function in the thread that initialized the video 
>>> subsystem."
>>> 
>>> 
>>> On Friday, January 3, 2020 at 1:58:29 PM UTC-8, Robert Engels wrote:
>>> Even if you could I don’t think you would want to do it this way. 
>>> 
>>> Have a go routine sleep on a channel. Post to the channel from the native 
>>> code. 
>>> 
>>> Let your command loop run on any thread and synchronize via a channel the 
>>> calls to/from native. 
>>> 
>>> The os event loop doesn’t need to run on main - it just needs to be locked 
>>> to a thread - use a native thread - and post the os events to a channel.  
>>> 
>>> Probably easiest to export a simple Go postToEventChannel() and have the 
>>> native use this. 
>>> 
 On Jan 3, 2020, at 2:18 PM, buch...@ <>gmail.com  wrote:
 
 
 I've been getting by with a version of this that sends commands (closures) 
 to a loop on the main thread:
 https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L55
  
 
 
 And here is where it pops those commands, and also integrates with the OS 
 event loop:
 https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L163
  
 
 
 But, I'm still not satisfied. The solution ties together the scheduling 
 (and code) of two separate event loops. In 

Re: [go-nuts] Locking goroutine to "main" thread

[robert engels]

You only need a single thread locked to the UI thread.

Use one Go routine locked to the UI thread. Put events onto a channel.

Have another Go routine read from the channel, and the app command channel 
using select.



> On Jan 3, 2020, at 5:28 PM, bucha...@gmail.com wrote:
> 
> Whether the UI thread is on the main thread or a separate thread, a single UI 
> thread needs to process events from two sources: the OS window and from my 
> application. Having one loop process both sources (without support from the 
> Go runtime scheduler) is the part I'm struggling with.
> 
> My latest iteration is something like:
> 
> for {
>   // PollEvent doesn't block/sleep
> 
>   for ev := sdl.PollEvent(); ev != nil; ev = sdl.PollEvent {
> // handle OS window events
>   }
>   select {
>   case cmd := <-app.commands:
> // process application command
> 
> cmd()
>   case <-time.After(10*time.Millisecond):
> // only wait 10ms for application commands
> 
>   }
> }
> 
> 
> 
> This is an improvement, but I'd still prefer help from the Go runtime. If the 
> runtime supported locking two goroutines to the UI thread, I could split this 
> loop into two separate loops and remove the time.After, I *think*.
> 
> On Friday, January 3, 2020 at 2:59:42 PM UTC-8, robert engels wrote:
> You can definitely run the event loop for a process on a thread other than 
> main. The main thread is the thread created by the OS to begin running the 
> process - the UI thread is the one that initializes the Windowing system. 
> Some OSs even support multiple UI threads (see 
> https://docs.microsoft.com/en-us/cpp/parallel/multithreading-creating-user-interface-threads?view=vs-2019
>  
> )
> 
> Go doesn’t do any Windowing system initialization by default - the main 
> thread in Go (at least according to the referenced library) is the one that 
> called the package init() - which may not even be the OS main thread since 
> according to the Go docs "Package initialization—variable initialization and 
> the invocation of init functions—happens in a single goroutine, sequentially, 
> one package at a time.” - which makes no claim that this Go routine is 
> running on the “main” OS thread.
> 
> Whatever thread you use to initialize GLFW is the UI thread (or main for 
> GLFW).
> 
> This is pretty standard across windowing/graphics systems.
> 
> 
> 
> 
>> On Jan 3, 2020, at 4:02 PM, buch...@ <>gmail.com  wrote:
>> 
>> I'm pretty sure the OS event loop is required to be on the main thread. 
>> 
>> From the GLFW docs for glfwPollEvents:
>> "This function must only be called from the main thread."
>> 
>> From the SDL docs for SDL_WaitEvent:
>> "you can only call this function in the thread that initialized the video 
>> subsystem."
>> 
>> 
>> On Friday, January 3, 2020 at 1:58:29 PM UTC-8, Robert Engels wrote:
>> Even if you could I don’t think you would want to do it this way. 
>> 
>> Have a go routine sleep on a channel. Post to the channel from the native 
>> code. 
>> 
>> Let your command loop run on any thread and synchronize via a channel the 
>> calls to/from native. 
>> 
>> The os event loop doesn’t need to run on main - it just needs to be locked 
>> to a thread - use a native thread - and post the os events to a channel.  
>> 
>> Probably easiest to export a simple Go postToEventChannel() and have the 
>> native use this. 
>> 
>>> On Jan 3, 2020, at 2:18 PM, buch...@ <>gmail.com  wrote:
>>> 
>>> 
>>> I've been getting by with a version of this that sends commands (closures) 
>>> to a loop on the main thread:
>>> https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L55
>>>  
>>> 
>>> 
>>> And here is where it pops those commands, and also integrates with the OS 
>>> event loop:
>>> https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L163
>>>  
>>> 
>>> 
>>> But, I'm still not satisfied. The solution ties together the scheduling 
>>> (and code) of two separate event loops. In particular, I've found that my 
>>> commands are delayed ~10ms – I think sdl.WaitEvent might be rate limited.
>>> 
>>> What I really want is for the two event loops (OS event loop vs app command 
>>> loop) to be in two separate goroutines, both running on the main thread. 
>>> That way, the OS event loop can react to infrequent window events (mouse 
>>> clicks, etc) without burning lots of CPU, while my app command loop can 
>>> react to commands instantly. 
>>> 
>>> Does that make sense? Is this possible to implement without requiring a 
>>> change to the Go runtime? Is it possible to change the Go runtime to allow 
>>> multiple goroutines to be 

[go-nuts] Re: Enforcing a type name rather than a variable name

[julio]

By the way, here is the function having this in package `net`: 
https://golang.org/src/net/lookup.go#L81

-- 
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/3365c11e-918e-4bd7-989b-46868148b1ec%40googlegroups.com.

[go-nuts] Enforcing a type name rather than a variable name

[julio]

Hello,

Is there any way to avoid the compilation error "*error is not a type" of 
this example https://play.golang.org/p/gWNStGSCfTm ?
I understand the variable named `error` hides the type named `error` but is 
there some other syntax to specify the error type?

I am facing this issue while writing an instrumentation tool: some 
functions the tool instruments have such signatures, while the tool add Go 
code referencing the type name, not the variable name.

Thanks for your help

-- 
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/8612f73c-bfb4-4bce-a5d3-3567ee2cbd9a%40googlegroups.com.

Re: [go-nuts] Locking goroutine to "main" thread

[buchanae]

Whether the UI thread is on the main thread or a separate thread, a single 
UI thread needs to process events from two sources: the OS window and from 
my application. Having one loop process both sources (without support from 
the Go runtime scheduler) is the part I'm struggling with.

My latest iteration is something like:

for {
  // PollEvent doesn't block/sleep

  for ev := sdl.PollEvent(); ev != nil; ev = sdl.PollEvent {
// handle OS window events
  }
  select {
  case cmd := <-app.commands:
// process application command

cmd()
  case <-time.After(10*time.Millisecond):
// only wait 10ms for application commands

  }
}



This is an improvement, but I'd still prefer help from the Go runtime. If 
the runtime supported locking two goroutines to the UI thread, I could 
split this loop into two separate loops and remove the time.After, I 
*think*.

On Friday, January 3, 2020 at 2:59:42 PM UTC-8, robert engels wrote:
>
> You can definitely run the event loop for a process on a thread other than 
> main. The main thread is the thread created by the OS to begin running the 
> process - the UI thread is the one that initializes the Windowing system. 
> Some OSs even support multiple UI threads (see 
> https://docs.microsoft.com/en-us/cpp/parallel/multithreading-creating-user-interface-threads?view=vs-2019
> )
>
> Go doesn’t do any Windowing system initialization by default - the main 
> thread in Go (at least according to the referenced library) is the one that 
> called the package init() - which may not even be the OS main thread since 
> according to the Go docs "Package initialization—variable initialization 
> and the invocation of init functions—happens in a single goroutine, 
> sequentially, one package at a time.” - which makes no claim that this Go 
> routine is running on the “main” OS thread.
>
> Whatever thread you use to initialize GLFW is the UI thread (or main for 
> GLFW).
>
> This is pretty standard across windowing/graphics systems.
>
>
>
>
> On Jan 3, 2020, at 4:02 PM, buch...@gmail.com  wrote:
>
> I'm pretty sure the OS event loop is required to be on the main thread. 
>
> From the GLFW docs for glfwPollEvents:
> "This function must only be called from the main thread."
>
> From the SDL docs for SDL_WaitEvent:
> "you can only call this function in the thread that initialized the video 
> subsystem."
>
>
> On Friday, January 3, 2020 at 1:58:29 PM UTC-8, Robert Engels wrote:
>>
>> Even if you could I don’t think you would want to do it this way. 
>>
>> Have a go routine sleep on a channel. Post to the channel from the native 
>> code. 
>>
>> Let your command loop run on any thread and synchronize via a channel the 
>> calls to/from native. 
>>
>> The os event loop doesn’t need to run on main - it just needs to be 
>> locked to a thread - use a native thread - and post the os events to a 
>> channel.  
>>
>> Probably easiest to export a simple Go postToEventChannel() and have the 
>> native use this. 
>>
>> On Jan 3, 2020, at 2:18 PM, buch...@gmail.com wrote:
>>
>> 
>> I've been getting by with a version of this that sends commands 
>> (closures) to a loop on the main thread:
>>
>> https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L55
>>
>> And here is where it pops those commands, and also integrates with the OS 
>> event loop:
>>
>> https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L163
>>
>> But, I'm still not satisfied. The solution ties together the scheduling 
>> (and code) of two separate event loops. In particular, I've found that my 
>> commands are delayed ~10ms – I think sdl.WaitEvent might be rate limited.
>>
>> What I really want is for the two event loops (OS event loop vs app 
>> command loop) to be in two separate goroutines, both running on the main 
>> thread. That way, the OS event loop can react to infrequent window events 
>> (mouse clicks, etc) without burning lots of CPU, while my app command loop 
>> can react to commands instantly. 
>>
>> Does that make sense? Is this possible to implement without requiring a 
>> change to the Go runtime? Is it possible to change the Go runtime to allow 
>> multiple goroutines to be scheduled only to the main thread?
>>
>> Thanks.
>>
>> -- 
>> 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 golan...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/e4e3a04d-0f76-4baf-9760-9992ef38d51f%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 

Re: [go-nuts] distributed runtime

[Michael Jones]

Go is a shared memory system. Your challenge would be to understand a
pointer that came to you from a different machine (i.e., remotely, the R in
RPC).

On Fri, Jan 3, 2020 at 2:31 PM  wrote:

> Hi all and Happy New Year,
>
> I was daydreaming the other day and I was wondering if it was possible to
> create some alternate runtime package.
> The point would be to have the scheduler schedule goroutine not only on
> different CPU, but also on different CPU on different machines.
> The system would be a binary that you could run as the scheduler or as a
> worker, and the scheduler would distribute among workers via some RPC. Of
> course, it would take cache optimisation to schedule it on the correct
> machine so they could share the same CPU when needed.
> Is it a stupid idea? A very difficult one? A naive approach that would
> just have networking bandwidth and latency issues?
>
> --
> 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/5a05e457-4d9d-45b2-9822-d1accb48d7af%40googlegroups.com
> 
> .
>


-- 

*Michael T. jonesmichael.jo...@gmail.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/CALoEmQw06TmJO5qET%3DdfjfTFQwNqZwjUhxv57q%3DcjRrch1LDrA%40mail.gmail.com.

Re: [go-nuts] Locking goroutine to "main" thread

[robert engels]

You can definitely run the event loop for a process on a thread other than 
main. The main thread is the thread created by the OS to begin running the 
process - the UI thread is the one that initializes the Windowing system. Some 
OSs even support multiple UI threads (see 
https://docs.microsoft.com/en-us/cpp/parallel/multithreading-creating-user-interface-threads?view=vs-2019
 
)

Go doesn’t do any Windowing system initialization by default - the main thread 
in Go (at least according to the referenced library) is the one that called the 
package init() - which may not even be the OS main thread since according to 
the Go docs "Package initialization—variable initialization and the invocation 
of init functions—happens in a single goroutine, sequentially, one package at a 
time.” - which makes no claim that this Go routine is running on the “main” OS 
thread.

Whatever thread you use to initialize GLFW is the UI thread (or main for GLFW).

This is pretty standard across windowing/graphics systems.




> On Jan 3, 2020, at 4:02 PM, bucha...@gmail.com wrote:
> 
> I'm pretty sure the OS event loop is required to be on the main thread. 
> 
> From the GLFW docs for glfwPollEvents:
> "This function must only be called from the main thread."
> 
> From the SDL docs for SDL_WaitEvent:
> "you can only call this function in the thread that initialized the video 
> subsystem."
> 
> 
> On Friday, January 3, 2020 at 1:58:29 PM UTC-8, Robert Engels wrote:
> Even if you could I don’t think you would want to do it this way. 
> 
> Have a go routine sleep on a channel. Post to the channel from the native 
> code. 
> 
> Let your command loop run on any thread and synchronize via a channel the 
> calls to/from native. 
> 
> The os event loop doesn’t need to run on main - it just needs to be locked to 
> a thread - use a native thread - and post the os events to a channel.  
> 
> Probably easiest to export a simple Go postToEventChannel() and have the 
> native use this. 
> 
>> On Jan 3, 2020, at 2:18 PM, buch...@gmail.com  wrote:
>> 
>> 
>> I've been getting by with a version of this that sends commands (closures) 
>> to a loop on the main thread:
>> https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L55
>>  
>> 
>> 
>> And here is where it pops those commands, and also integrates with the OS 
>> event loop:
>> https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L163
>>  
>> 
>> 
>> But, I'm still not satisfied. The solution ties together the scheduling (and 
>> code) of two separate event loops. In particular, I've found that my 
>> commands are delayed ~10ms – I think sdl.WaitEvent might be rate limited.
>> 
>> What I really want is for the two event loops (OS event loop vs app command 
>> loop) to be in two separate goroutines, both running on the main thread. 
>> That way, the OS event loop can react to infrequent window events (mouse 
>> clicks, etc) without burning lots of CPU, while my app command loop can 
>> react to commands instantly. 
>> 
>> Does that make sense? Is this possible to implement without requiring a 
>> change to the Go runtime? Is it possible to change the Go runtime to allow 
>> multiple goroutines to be scheduled only to the main thread?
>> 
>> Thanks.
>> 
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/e4e3a04d-0f76-4baf-9760-9992ef38d51f%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/cbbca787-1dec-4729-b91f-25a7b5725d80%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 

[go-nuts] distributed runtime

[dolanor]

Hi all and Happy New Year,

I was daydreaming the other day and I was wondering if it was possible to 
create some alternate runtime package.
The point would be to have the scheduler schedule goroutine not only on 
different CPU, but also on different CPU on different machines.
The system would be a binary that you could run as the scheduler or as a 
worker, and the scheduler would distribute among workers via some RPC. Of 
course, it would take cache optimisation to schedule it on the correct 
machine so they could share the same CPU when needed.
Is it a stupid idea? A very difficult one? A naive approach that would just 
have networking bandwidth and latency issues?

-- 
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/5a05e457-4d9d-45b2-9822-d1accb48d7af%40googlegroups.com.

Re: [go-nuts] Locking goroutine to "main" thread

[buchanae]

I'm pretty sure the OS event loop is required to be on the main thread. 

>From the GLFW docs for glfwPollEvents:
"This function must only be called from the main thread."

>From the SDL docs for SDL_WaitEvent:
"you can only call this function in the thread that initialized the video 
subsystem."


On Friday, January 3, 2020 at 1:58:29 PM UTC-8, Robert Engels wrote:
>
> Even if you could I don’t think you would want to do it this way. 
>
> Have a go routine sleep on a channel. Post to the channel from the native 
> code. 
>
> Let your command loop run on any thread and synchronize via a channel the 
> calls to/from native. 
>
> The os event loop doesn’t need to run on main - it just needs to be locked 
> to a thread - use a native thread - and post the os events to a channel.  
>
> Probably easiest to export a simple Go postToEventChannel() and have the 
> native use this. 
>
> On Jan 3, 2020, at 2:18 PM, buch...@gmail.com  wrote:
>
> 
> I've been getting by with a version of this that sends commands (closures) 
> to a loop on the main thread:
>
> https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L55
>
> And here is where it pops those commands, and also integrates with the OS 
> event loop:
>
> https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L163
>
> But, I'm still not satisfied. The solution ties together the scheduling 
> (and code) of two separate event loops. In particular, I've found that my 
> commands are delayed ~10ms – I think sdl.WaitEvent might be rate limited.
>
> What I really want is for the two event loops (OS event loop vs app 
> command loop) to be in two separate goroutines, both running on the main 
> thread. That way, the OS event loop can react to infrequent window events 
> (mouse clicks, etc) without burning lots of CPU, while my app command loop 
> can react to commands instantly. 
>
> Does that make sense? Is this possible to implement without requiring a 
> change to the Go runtime? Is it possible to change the Go runtime to allow 
> multiple goroutines to be scheduled only to the main thread?
>
> Thanks.
>
> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/e4e3a04d-0f76-4baf-9760-9992ef38d51f%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/cbbca787-1dec-4729-b91f-25a7b5725d80%40googlegroups.com.

Re: [go-nuts] Locking goroutine to "main" thread

[Robert Engels]

Even if you could I don’t think you would want to do it this way. 

Have a go routine sleep on a channel. Post to the channel from the native code. 

Let your command loop run on any thread and synchronize via a channel the calls 
to/from native. 

The os event loop doesn’t need to run on main - it just needs to be locked to a 
thread - use a native thread - and post the os events to a channel.  

Probably easiest to export a simple Go postToEventChannel() and have the native 
use this. 

> On Jan 3, 2020, at 2:18 PM, bucha...@gmail.com wrote:
> 
> 
> I've been getting by with a version of this that sends commands (closures) to 
> a loop on the main thread:
> https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L55
> 
> And here is where it pops those commands, and also integrates with the OS 
> event loop:
> https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L163
> 
> But, I'm still not satisfied. The solution ties together the scheduling (and 
> code) of two separate event loops. In particular, I've found that my commands 
> are delayed ~10ms – I think sdl.WaitEvent might be rate limited.
> 
> What I really want is for the two event loops (OS event loop vs app command 
> loop) to be in two separate goroutines, both running on the main thread. That 
> way, the OS event loop can react to infrequent window events (mouse clicks, 
> etc) without burning lots of CPU, while my app command loop can react to 
> commands instantly. 
> 
> Does that make sense? Is this possible to implement without requiring a 
> change to the Go runtime? Is it possible to change the Go runtime to allow 
> multiple goroutines to be scheduled only to the main thread?
> 
> Thanks.
> -- 
> 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/e4e3a04d-0f76-4baf-9760-9992ef38d51f%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/FFE5D51B-757C-4045-8C70-A764D32E9CEA%40ix.netcom.com.

[go-nuts] modules exclude version and above

[Jérôme LAFORGE]

Hello,

Does it exist a way to exclude modules' version and above  ?

Currently I have to do this (in order to not use v2) in my go.mod:

exclude (
github.com/nicksnyder/go-i18n v2.0.1+incompatible
github.com/nicksnyder/go-i18n v2.0.2+incompatible
github.com/nicksnyder/go-i18n v2.0.3+incompatible
)

Many thx
Jérôme

-- 
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/fbf7d60a-ddf9-43dd-818e-40d1e054de29%40googlegroups.com.

Re: [go-nuts] Locking goroutine to "main" thread

[buchanae]

I've been getting by with a version of this that sends commands (closures) 
to a loop on the main thread:
https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L55

And here is where it pops those commands, and also integrates with the OS 
event loop:
https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L163

But, I'm still not satisfied. The solution ties together the scheduling 
(and code) of two separate event loops. In particular, I've found that my 
commands are delayed ~10ms – I think sdl.WaitEvent might be rate limited.

What I really want is for the two event loops (OS event loop vs app command 
loop) to be in two separate goroutines, both running on the main thread. 
That way, the OS event loop can react to infrequent window events (mouse 
clicks, etc) without burning lots of CPU, while my app command loop can 
react to commands instantly. 

Does that make sense? Is this possible to implement without requiring a 
change to the Go runtime? Is it possible to change the Go runtime to allow 
multiple goroutines to be scheduled only to the main thread?

Thanks.

-- 
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/e4e3a04d-0f76-4baf-9760-9992ef38d51f%40googlegroups.com.

Re: [go-nuts] difference response from play.golang (bit operations)

[X-Thief]

lol thanks xDD I didnt try int32 coz i though int is linked to that

пятница, 3 января 2020 г., 22:28:59 UTC+4 пользователь andrey mirtchovski 
написал:
>
> sorry, i meant to put this in too; 
>
> https://play.golang.org/p/vn5iMAWbDiv 
>
> On Fri, Jan 3, 2020 at 11:27 AM andrey mirtchovski 
> > wrote: 
> > 
> > https://play.golang.org/p/cpKEQZJKDsh 
> > 
> > On Fri, Jan 3, 2020 at 11:24 AM X-Thief > 
> wrote: 
> > > 
> > > thx but have you tried it? it just gives positive on playground. 
> > > 
> > > пятница, 3 января 2020 г., 22:05:48 UTC+4 пользователь Ian Lance 
> Taylor написал: 
> > >> 
> > >> On Fri, Jan 3, 2020 at 9:50 AM X-Thief  wrote: 
> > >> > 
> > >> > Hey. Im realy newbish at bit operations 
> > >> > 
> > >> > Could you help me get the same result as in 
> https://play.golang.org/p/FWocHVrF0Wt 
> > >> > On my PC and my server i got positive number from the script. But i 
> need negative result if it is so 
> > >> > 
> > >> > Any suggestions?) 
> > >> 
> > >> Your PC and server are probably 64-bit systems but the playground is 
> a 
> > >> 32-bit system.  To get consistent results use explicit conversions to 
> > >> int64. 
> > >> 
> > >> 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 golan...@googlegroups.com . 
> > > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/3361a17f-b8e4-447a-89c1-943154834233%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/ee2aa2c4-efaf-49f7-bacc-d9bb2fe3ca84%40googlegroups.com.

Re: [go-nuts] difference response from play.golang (bit operations)

[andrey mirtchovski]

sorry, i meant to put this in too;

https://play.golang.org/p/vn5iMAWbDiv

On Fri, Jan 3, 2020 at 11:27 AM andrey mirtchovski
 wrote:
>
> https://play.golang.org/p/cpKEQZJKDsh
>
> On Fri, Jan 3, 2020 at 11:24 AM X-Thief  wrote:
> >
> > thx but have you tried it? it just gives positive on playground.
> >
> > пятница, 3 января 2020 г., 22:05:48 UTC+4 пользователь Ian Lance Taylor 
> > написал:
> >>
> >> On Fri, Jan 3, 2020 at 9:50 AM X-Thief  wrote:
> >> >
> >> > Hey. Im realy newbish at bit operations
> >> >
> >> > Could you help me get the same result as in 
> >> > https://play.golang.org/p/FWocHVrF0Wt
> >> > On my PC and my server i got positive number from the script. But i need 
> >> > negative result if it is so
> >> >
> >> > Any suggestions?)
> >>
> >> Your PC and server are probably 64-bit systems but the playground is a
> >> 32-bit system.  To get consistent results use explicit conversions to
> >> int64.
> >>
> >> 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/3361a17f-b8e4-447a-89c1-943154834233%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/CAK4xykUroh2gbzROVYbwjFTXNxmfty8BAQC1h5dPeT-Q6ZQy0Q%40mail.gmail.com.

Re: [go-nuts] difference response from play.golang (bit operations)

[andrey mirtchovski]

https://play.golang.org/p/cpKEQZJKDsh

On Fri, Jan 3, 2020 at 11:24 AM X-Thief  wrote:
>
> thx but have you tried it? it just gives positive on playground.
>
> пятница, 3 января 2020 г., 22:05:48 UTC+4 пользователь Ian Lance Taylor 
> написал:
>>
>> On Fri, Jan 3, 2020 at 9:50 AM X-Thief  wrote:
>> >
>> > Hey. Im realy newbish at bit operations
>> >
>> > Could you help me get the same result as in 
>> > https://play.golang.org/p/FWocHVrF0Wt
>> > On my PC and my server i got positive number from the script. But i need 
>> > negative result if it is so
>> >
>> > Any suggestions?)
>>
>> Your PC and server are probably 64-bit systems but the playground is a
>> 32-bit system.  To get consistent results use explicit conversions to
>> int64.
>>
>> 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/3361a17f-b8e4-447a-89c1-943154834233%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/CAK4xykWKp_Um62ew_G_rP53SxwXuTYV8zTk_39EqiV9bap3ybw%40mail.gmail.com.

Re: [go-nuts] difference response from play.golang (bit operations)

[X-Thief]

thx but have you tried it? it just gives positive on playground. 

пятница, 3 января 2020 г., 22:05:48 UTC+4 пользователь Ian Lance Taylor 
написал:
>
> On Fri, Jan 3, 2020 at 9:50 AM X-Thief > 
> wrote: 
> > 
> > Hey. Im realy newbish at bit operations 
> > 
> > Could you help me get the same result as in 
> https://play.golang.org/p/FWocHVrF0Wt 
> > On my PC and my server i got positive number from the script. But i need 
> negative result if it is so 
> > 
> > Any suggestions?) 
>
> Your PC and server are probably 64-bit systems but the playground is a 
> 32-bit system.  To get consistent results use explicit conversions to 
> int64. 
>
> 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/3361a17f-b8e4-447a-89c1-943154834233%40googlegroups.com.

Re: [go-nuts] strange failure of golang.org/x/crypto/argon2.IDKey

[Kurtis Rader]

The SIGKILL coupled with your terminal emulator also being killed suggests
an OOM, out of memory, situation that causes the kernel to kill processes
to keep the entire system from dying. You're probably not correctly
initializing the state of the crypto code on subsequent calls.

On Thu, Jan 2, 2020 at 11:14 PM  wrote:

>
> I attached a minimal test program to reproduce an issue with
> golang.org/x/crypto/argon2.
>
> It calls IDKey twice with the same parameters. The first call executes,
> but during the second call the program crashes.
>
> Strange thing: The program does not always crash. If it crashes then I can
> call it multiple times in a row and it always crashes.
> But then maybe if I try a few hours later it does not crash. And if I try
> it then again and again it will always work normally.
>
> Another curious thing is that when it crashes it usually (but not always)
> kills the whole terminal emulator (gnome-terminal) with it.
> I am running this on Fedora 31 64-bit (Intel Core i5-5200U).
> strace shows at the end:
>
> +++ killed by SIGKILL +++
>
> The crash happens somewhere in the argon2.processBlocks function.
>
> Any ideas ? Should I open an issue on https://github.com/golang/go ?
>
>
> --
> 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/e39ef554-b764-4a90-b5a1-f5b1054dfed3%40googlegroups.com
> 
> .
>


-- 
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/CABx2%3DD__mdYWaZWU6PuWE9KB4HJXwN%2BZZipqLk4QFoXuwGXOnw%40mail.gmail.com.

Re: [go-nuts] difference response from play.golang (bit operations)

[Ian Lance Taylor]

On Fri, Jan 3, 2020 at 9:50 AM X-Thief  wrote:
>
> Hey. Im realy newbish at bit operations
>
> Could you help me get the same result as in 
> https://play.golang.org/p/FWocHVrF0Wt
> On my PC and my server i got positive number from the script. But i need 
> negative result if it is so
>
> Any suggestions?)

Your PC and server are probably 64-bit systems but the playground is a
32-bit system.  To get consistent results use explicit conversions to
int64.

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/CAOyqgcV1gVcRvGA-iz%3Du9A-pkcin6rOCrCfNSKgRxryg7kS7OA%40mail.gmail.com.

Re: [go-nuts] os.RemoveAll of directory that contains long paths hangs

[Ian Lance Taylor]

On Fri, Jan 3, 2020 at 9:50 AM Brian Samek  wrote:
>
> I wanted to check here before I opened an issue.
>
> Given a Windows Server 2008 R2 path longer than 260 characters, like 
> C:\foo\bar\<150 characters>\<150 characters>, os.RemoveAll("bar") from the 
> foo directory hangs indefinitely.
>
> Does anyone know if this is a known issue, or if there is more information 
> that would be useful to include in a bug report?

Sounds like it might be a version of golang.org/issue/27209 on Windows
systems.  Please do open a new issue with a test case, ideally a
standalone program that we can run to recreate the problem.  Thanks.

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/CAOyqgcU01k0Yanfqe6za%2BniWxEFEpfCkvgxo%2BUwfqSOxdZ%3DNng%40mail.gmail.com.

[go-nuts] Re: Go and Mongodb partial update

[Gabriele Bassi]

Il giorno mercoledì 4 dicembre 2019 14:48:57 UTC+1, Gabriele Bassi ha 
scritto:
>
> Hi to allI have some trouble with golang and mongoDB i'm using the 
> official mongodb driver for go.What i have to do is manage partial mongo 
> db update casting a map[string]interface{} to a bison.M to perform an 
> update.I have following collection
> https://jsoneditoronline.org/?id=5d1cb75ba2de4626ab2a4628e29b955eThe 
> request body of update post can contains one or more properties of the 
> collection.How i can cast body request to a valid bison.M to per form the 
> update?For example if update dto is
> https://jsoneditoronline.org/?id=81f6bbd30bab4349964d692fc3b374ee
> *jsoneditoronline.org *
> *JSON Editor Online - view, edit and format JSON online*
> JSON Editor Online is a web-based tool to view, edit, and format JSON. It 
> shows your data side by side in a clear, editable treeview and in a code 
> editor.*jsoneditoronline.org *
> *JSON Editor Online - view, edit and format JSON online*
> JSON Editor Online is a web-based tool to view, edit, and format JSON. It 
> shows your data side by side in a clear, editable treeview and in a code 
> editor.
> [image: jsoneditoronline.org]jsoneditoronline.org
> JSON Editor Online - view, edit and format JSON online 
> 
> JSON Editor Online is a web-based tool to view, edit, and format JSON. It 
> shows your data side by side in a clear, editable treeview and in a code 
> editor.
> [image: jsoneditoronline.org]jsoneditoronline.org
> JSON Editor Online - view, edit and format JSON online 
> 
> JSON Editor Online is a web-based tool to view, edit, and format JSON. It 
> shows your data side by side in a clear, editable treeview and in a code 
> editor.
>
>
Golang play sample:

https://play.golang.org/p/CigD_a_XC2Y 

-- 
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/037a7bbf-0054-40c3-9c2c-e49e3bb917a3%40googlegroups.com.

[go-nuts] Unlinked temporary files

[drakkan1000]

Hi,

I'm going to use this library https://github.com/eikenb/pipeat/ 

it reads/writes from/to an unlinked temporary file, as you can see here:

https://github.com/eikenb/pipeat/blob/master/pipeat.go#L51

the temporary file is removed and then used for I/O operations. 

I ran the test cases on Windows and they work there too.

Is it really safe to assume that an unliked file will work on all supported 
OS? I was really surprised that this work on Windows,

Thanks!

-- 
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/6d670c1e-0bfb-4398-901a-6cae1db7f228%40googlegroups.com.

[go-nuts] difference response from play.golang (bit operations)

[X-Thief]

Hey. Im realy newbish at bit operations

Could you help me get the same result as 
in https://play.golang.org/p/FWocHVrF0Wt
On my PC and my server i got positive number from the script. But i need 
negative result if it is so

Any suggestions?)

-- 
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/12d43bf4-539d-46d8-a01f-a2f9dfdde776%40googlegroups.com.

[go-nuts] os.RemoveAll of directory that contains long paths hangs

[Brian Samek]

I wanted to check here before I opened an issue. 

Given a Windows Server 2008 R2 path longer than 260 characters, like 
C:\foo\bar\<150 characters>\<150 characters>, os.RemoveAll("bar") from the 
foo directory hangs indefinitely.

Does anyone know if this is a known issue, or if there is more information 
that would be useful to include in a bug report?

Thanks,

Brian

-- 
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/da36c808-dc07-4bb1-b5ee-91601f70da75%40googlegroups.com.

Re: [go-nuts] How to fill a map with requests from client

[Prabhu Chawandi]

all["client request"] =  clientJob.name// append the client requests on map

Maps are Key: Value pair, in your case as the same key ie.  "client
request"  is being used, the latest value is overwriting the previous
value. Add a unique key for each request to store them in same map.

On Fri, Jan 3, 2020 at 12:44 PM snk  wrote:

> I am a beginner in Golang, This is a TCP server that receives requests and
> sends back a hello message to the client attached with the client's
> message(name)
>  *how can I fill those requests into a map without erasing the previous
> request?*
>  this is the code, the request is appended to the map but when the next
> comes, it replaces the current on.
>
>
>  // Goroutine and Socket programming TCP server
> //**
> // TCP
> //--
>
> package main
>
> import (
> "bufio"
> "fmt"
> "net"
> "time"
> )
> // check if there is any error and send a message. but it's better to remove 
> panic later (it's not recommended to use it)
> //***
> func check(err error, message string) {
> if err != nil {
> panic(err)
> }
> fmt.Printf("%s\n", message)
> }
> // Create the client structure that contains the client's name and the 
> connection
> //
>
> type ClientJob struct {
> name string
> conn net.Conn
>
> }
>
> // Create the function,the channel with type struct
> //*
>
> func generateResponses(clientJobs chan ClientJob) {
> for {
> // Wait for the next job to come off the queue.
> clientJob := <-clientJobs
>
> // Do something thats keeps the CPU buys for a whole second.
> for start := time.Now(); time.Now().Sub(start) < time.Second; {
> }
>
> // Send back the response.
>
> clientJob.conn.Write([]byte("Hello, " + clientJob.name))
>
> //clientJob:=make(chan ClientJob)
> //name:=make(chan string)
> //name:=<-clientJobs
>
> all := make(map[string]string) // create the map
> all["client request"] =  clientJob.name// append the client requests 
> on map
> fmt.Println("All requests in the slice", all) // show all the 
> requests in the map
>
>
>
> }
>
> }
>
> // The main function
> //***
>
> func main() {
> clientJobs := make(chan ClientJob) // declare the channel used in the 
> function above
> go generateResponses(clientJobs)  // put the function in a goroutine
>
> ln, err := net.Listen("tcp", ":8080") // connect to the port 8080, it can 
> be changed to any port if needed
> check(err, "Server is ready.") // show the message that the server is 
> ready to receive
> //fmt.Println(<-clientJobs)
> // start checking the connection et receiving from the client and pass it 
> into a goroutine and send it via a channel ClientJobs<-ClientJob{name, conn}
> for {
> conn, err := ln.Accept()
> check(err, "Accepted connection.")
>
> go func() {
> buf := bufio.NewReader(conn)
>
> for {
> name, err := buf.ReadString('\n')
>
> if err != nil {
> fmt.Printf("Client disconnected.\n")
> break
> }
>
> clientJobs <- ClientJob{name, conn} // pass the name and conn 
> to the clientJobs channel
>
> }
>
>
> }()
> }
> }
>
>
>
> --
> 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/2457abfa-04c9-476c-a2e4-b86e8e49e012%40googlegroups.com
> 
> .
>


-- 
Cheers
p.

-- 
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/CAN9r%3DsxMH0e2_Y6zhg-hCHgOvXem2SLKGkpn2ToPTi7LEeDWFg%40mail.gmail.com.

[go-nuts] Re: How to fill a map with requests from client

[nks]

that's right 

On Friday, January 3, 2020 at 5:51:22 PM UTC+9, Amnon Baron Cohen wrote:
>
> all := make(map[string]string) // create the map 
> all["client request"] =  clientJob.name// append the client requests 
> on map
>
>
> gets called each time a request arrives.
> So a new empty map gets created each time a request arrives.
>
> The comment on the second line is wrong. The code does not "append" to the 
> map. It overwrites the "client request" element.
>
>
> On Friday, 3 January 2020 07:14:22 UTC, nks wrote:
>>
>> I am a beginner in Golang, This is a TCP server that receives requests 
>> and sends back a hello message to the client attached with the client's 
>> message(name)
>>  *how can I fill those requests into a map without erasing the previous 
>> request?*
>>  this is the code, the request is appended to the map but when the next 
>> comes, it replaces the current on.
>>
>>
>>  // Goroutine and Socket programming TCP server
>> //**
>> // TCP 
>> //--
>>
>> package main
>>
>> import (
>> "bufio"
>> "fmt"
>> "net"
>> "time"
>> )
>> // check if there is any error and send a message. but it's better to remove 
>> panic later (it's not recommended to use it)
>> //***
>> func check(err error, message string) { 
>> if err != nil {
>> panic(err)
>> }
>> fmt.Printf("%s\n", message)
>> }
>> // Create the client structure that contains the client's name and the 
>> connection
>> //
>>
>> type ClientJob struct { 
>> name string
>> conn net.Conn
>>
>> }
>>
>> // Create the function,the channel with type struct
>> //*
>>
>> func generateResponses(clientJobs chan ClientJob) {
>> for {
>> // Wait for the next job to come off the queue.
>> clientJob := <-clientJobs
>>
>> // Do something thats keeps the CPU buys for a whole second.
>> for start := time.Now(); time.Now().Sub(start) < time.Second; {
>> }
>>
>> // Send back the response.
>>
>> clientJob.conn.Write([]byte("Hello, " + clientJob.name))
>>
>> //clientJob:=make(chan ClientJob)
>> //name:=make(chan string)
>> //name:=<-clientJobs
>>
>> all := make(map[string]string) // create the map 
>> all["client request"] =  clientJob.name// append the client requests 
>> on map
>> fmt.Println("All requests in the slice", all) // show all the 
>> requests in the map
>>
>>
>>
>> }
>>
>> }
>>
>> // The main function
>> //***
>>
>> func main() {
>> clientJobs := make(chan ClientJob) // declare the channel used in the 
>> function above
>> go generateResponses(clientJobs)  // put the function in a goroutine
>>
>> ln, err := net.Listen("tcp", ":8080") // connect to the port 8080, it 
>> can be changed to any port if needed
>> check(err, "Server is ready.") // show the message that the server is 
>> ready to receive
>> //fmt.Println(<-clientJobs)
>> // start checking the connection et receiving from the client and pass 
>> it into a goroutine and send it via a channel ClientJobs<-ClientJob{name, 
>> conn}
>> for {
>> conn, err := ln.Accept()
>> check(err, "Accepted connection.")
>>
>> go func() {
>> buf := bufio.NewReader(conn)
>>
>> for {
>> name, err := buf.ReadString('\n')
>>
>> if err != nil {
>> fmt.Printf("Client disconnected.\n")
>> break
>> }
>>
>> clientJobs <- ClientJob{name, conn} // pass the name and 
>> conn to the clientJobs channel
>>
>> }
>>
>>
>> }()
>> }
>> }
>>
>>
>>
>>

-- 
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/45c3ff6a-2401-4826-b112-be23c2dbc4bf%40googlegroups.com.

[go-nuts] Re: How to fill a map with requests from client

[Amnon Baron Cohen]

I have copied the problematic lines of your code into a tiny programme on 
the Go playground.
https://play.golang.org/p/9vMrdtC-2zX

If you run it you will see the problem.

I would play around with the code to get a feel for what is happening.

If you want to append job names, then you probably want to use a slice 
rather than a map.

And to get the lifetime of this slice right, it should be created outside 
the loop which processes each new request.

Like I said, play around with the small example, until you understand what 
is happening and you can get the code to do the right thing.
Then you can update your original program.

Good luck!

On Friday, 3 January 2020 09:02:26 UTC, MUNGAI wrote:
>
> Hi, as indicated above, all is a local variable to you function. Maybe you 
> meant to have all variable on a global scope and as a map of maps.
>
> 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/a9faf0f9-26c8-414c-a4f3-012da8b3a742%40googlegroups.com.

[go-nuts] Re: [ANN] sorty

[Serhat Şevki Dinçer]

Hi,

sorty v0.4.0 is released with:

// Sort3 concurrently sorts underlying collection of length n via
// lesswap() which must be equivalent to:
//  if less(i, k) {
//  if r != s {
//  swap(r, s)
//  }
//  return true
//  }
//  return false
func Sort3(n int, lesswap func(i, k, r, s int) bool)

This function based method is faster than sorty.Collection2, which in turn 
is faster than sort.Interface (just as a way to access generic collections).

Let me know what you think, cheers..

On Wednesday, September 25, 2019 at 10:17:40 PM UTC+3, Serhat Şevki Dinçer 
wrote:
>
> Hi everyone,
>
> I've been improving type-specific concurrent sorting library sorty 
>  for a while and the results seem really 
> competitive on different data types for such a small library (effective 
> code is less than 200 lines). It also implements sort.Interface, though no 
> stable sorting or worst case guarantees yet.
>
> Let me know what you think. I am especially interested on sorting timings 
> on non-x86 platforms.
>
> Thanks..
>

-- 
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/8e938595-3d45-437b-a386-e44abe03c095%40googlegroups.com.

[go-nuts] How to fill a map with requests from client

[MUNGAI]

Hi, as indicated above, all is a local variable to you function. Maybe you 
meant to have all variable on a global scope and as a map of maps.

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/3b2ce648-01a1-4f78-ab99-549d6a311f74%40googlegroups.com.

[go-nuts] Re: How to fill a map with requests from client

[Amnon Baron Cohen]

all := make(map[string]string) // create the map 
all["client request"] =  clientJob.name// append the client requests on 
map


gets called each time a request arrives.
So a new empty map gets created each time a request arrives.

The comment on the second line is wrong. The code does not "append" to the 
map. It overwrites the "client request" element.


On Friday, 3 January 2020 07:14:22 UTC, nks wrote:
>
> I am a beginner in Golang, This is a TCP server that receives requests and 
> sends back a hello message to the client attached with the client's 
> message(name)
>  *how can I fill those requests into a map without erasing the previous 
> request?*
>  this is the code, the request is appended to the map but when the next 
> comes, it replaces the current on.
>
>
>  // Goroutine and Socket programming TCP server
> //**
> // TCP 
> //--
>
> package main
>
> import (
> "bufio"
> "fmt"
> "net"
> "time"
> )
> // check if there is any error and send a message. but it's better to remove 
> panic later (it's not recommended to use it)
> //***
> func check(err error, message string) { 
> if err != nil {
> panic(err)
> }
> fmt.Printf("%s\n", message)
> }
> // Create the client structure that contains the client's name and the 
> connection
> //
>
> type ClientJob struct { 
> name string
> conn net.Conn
>
> }
>
> // Create the function,the channel with type struct
> //*
>
> func generateResponses(clientJobs chan ClientJob) {
> for {
> // Wait for the next job to come off the queue.
> clientJob := <-clientJobs
>
> // Do something thats keeps the CPU buys for a whole second.
> for start := time.Now(); time.Now().Sub(start) < time.Second; {
> }
>
> // Send back the response.
>
> clientJob.conn.Write([]byte("Hello, " + clientJob.name))
>
> //clientJob:=make(chan ClientJob)
> //name:=make(chan string)
> //name:=<-clientJobs
>
> all := make(map[string]string) // create the map 
> all["client request"] =  clientJob.name// append the client requests 
> on map
> fmt.Println("All requests in the slice", all) // show all the 
> requests in the map
>
>
>
> }
>
> }
>
> // The main function
> //***
>
> func main() {
> clientJobs := make(chan ClientJob) // declare the channel used in the 
> function above
> go generateResponses(clientJobs)  // put the function in a goroutine
>
> ln, err := net.Listen("tcp", ":8080") // connect to the port 8080, it can 
> be changed to any port if needed
> check(err, "Server is ready.") // show the message that the server is 
> ready to receive
> //fmt.Println(<-clientJobs)
> // start checking the connection et receiving from the client and pass it 
> into a goroutine and send it via a channel ClientJobs<-ClientJob{name, conn}
> for {
> conn, err := ln.Accept()
> check(err, "Accepted connection.")
>
> go func() {
> buf := bufio.NewReader(conn)
>
> for {
> name, err := buf.ReadString('\n')
>
> if err != nil {
> fmt.Printf("Client disconnected.\n")
> break
> }
>
> clientJobs <- ClientJob{name, conn} // pass the name and conn 
> to the clientJobs channel
>
> }
>
>
> }()
> }
> }
>
>
>
>

-- 
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/4b3b875f-9204-41e4-b427-6981de4f4d66%40googlegroups.com.