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

2020-01-03 Thread 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

[go-nuts] distributed runtime

2020-01-03 Thread 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

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

2020-01-03 Thread 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

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

2020-01-03 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

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

2020-01-03 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

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

2020-01-03 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

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

2020-01-03 Thread 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

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

2020-01-03 Thread 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

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

2020-01-03 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

Re: [go-nuts] distributed runtime

2020-01-03 Thread 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

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

2020-01-03 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

[go-nuts] distributed runtime

2020-01-03 Thread 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

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

2020-01-03 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."

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

2020-01-03 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 -

[go-nuts] modules exclude version and above

2020-01-03 Thread 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

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

2020-01-03 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:

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

2020-01-03 Thread 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 >

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

2020-01-03 Thread 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

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

2020-01-03 Thread 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:

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

2020-01-03 Thread 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

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

2020-01-03 Thread 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,

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

2020-01-03 Thread 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

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

2020-01-03 Thread 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. > >

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

2020-01-03 Thread 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

[go-nuts] Unlinked temporary files

2020-01-03 Thread 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

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

2020-01-03 Thread 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

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

2020-01-03 Thread 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

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

2020-01-03 Thread 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,

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

2020-01-03 Thread 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

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

2020-01-03 Thread 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

[go-nuts] Re: [ANN] sorty

2020-01-03 Thread 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,

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

2020-01-03 Thread 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

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

2020-01-03 Thread 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