Re: [go-nuts] Memory corruption with GOGC=on

Sorry for taking a while to reply and, thank you very much!!! After testing over and over again this morning, the errors are gone, including the bad errors in Does gc hate me? What I got in the stacktrace is only about gc and

[go-nuts] Re: Best way to do this in golang

What about combining all the urls into one big pattern, and using regex ("SIMILAR TO" or "~") ? I'm sure the number of cases in OR is the culprit of the slowness. Parallelizing may help in wall time, but the query is very inefficient, and running it 1000 times (even if only 32 concurrently)

[go-nuts] Re: Best way to do this in golang

Thanks Tamas, Query itself is slow if i include all url strings. it takes about 10 mins. But when i hit one at a time, i see better response overall. Yes so was planning on running them in parallel. We only have read permissions and hence i am not allowed to add new index, but good idea, will

Re: [go-nuts] Does gc hate me?

On Tue, Feb 26, 2019 at 4:36 AM wrote: Yesterday you showed us an incorrect use of unsafe.Pointers while interacting with C. It might be the same/similar problem. The lines indicated in your post all allocate memory and may trigger GC, yes, but they per se are improbable to crash the process. I

Re: [go-nuts] is it possible to run cgo -buildmode=c-shared dynamic library on main thread?

digging into the source code in runtime/cgo/callbacks.go, suggests that indeed it does spawn a new thread for starting up the library (see code below). Thus, the solution was to just call the initialization for the gui thread *after* the library has been loaded and initialized, which indeed is

Re: [go-nuts] Does gc hate me?

Are you sure the lib 32/64 matches your Go environment. Also, the previous posters told you what was wrong with the original code. Did you change that? > On Feb 25, 2019, at 9:36 PM, yangwu...@gmail.com wrote: > > Hi all, > > The following unexpected fault address errors are occured

[go-nuts] Does gc hate me?

Hi all, The following unexpected fault address errors are occured occasionally. All of them is gcStart relavent, and it works fine when I turn gc off. Feel frustrated and become addicted to runtime.KeepAlive() XD. Please give some clues, thank you! *1. Make slice* code pReceive :=

Re: [go-nuts] is it possible to run cgo -buildmode=c-shared dynamic library on main thread?

On Mon, Feb 25, 2019 at 6:03 PM Randall O'Reilly wrote: > Kurtis — thanks for the suggestion — I had assumed that python always just > runs in the main thread, and when I added this code to my python script, it > shows that it is indeed running in the main thread I probably assumed too much

Re: [go-nuts] efficient random float32 number generator?

My instinct (for "please invent for me the fastest possible low fidelity floating point prng algorithm") is to look at RC4 for inspiration, permuting the order of a large table of float32s and constantly modifying them as well. This could be pared down to three index accesses, a floating

Re: [go-nuts] is it possible to run cgo -buildmode=c-shared dynamic library on main thread?

Kurtis — thanks for the suggestion — I had assumed that python always just runs in the main thread, and when I added this code to my python script, it shows that it is indeed running in the main thread: import threading if threading.current_thread() is threading.main_thread():

[go-nuts] Go 1.12 is Released

Hello gophers, We just released Go 1.12. You can read the announcement blog post here: https://blog.golang.org/go1.12 You can download binary and source distributions from our download page: https://golang.org/dl/ To compile from source using a Git checkout, update to the release with "git

Re: [go-nuts] Generics: the less obvious *constraints*, and the relationship to exception/error handling

On Mon, Feb 25, 2019 at 4:17 PM Louki Sumirniy wrote: > > It didn't occur to me until I was thinking about the issues raised in > constructing a bundle of compound literals to define the parameters for > multi-command CLI applications that such declarations really have to be > sanitised just

Re: [go-nuts] Generics: the less obvious *constraints*, and the relationship to exception/error handling

Well, being I am unlikely to gain the benefit of the as yet not fully settled specification anytime during this or several possible future projects, I was mainly posting these thoughts in part not to address the topic of future changes but more so to highlight the considerations anyone

Re: [go-nuts] efficient random float32 number generator?

My PCG library's 32-bit generator generates a 32-bit pseudo-random integer in 2.23 ns. https://github.com/MichaelTJones/pcg Just wrote this 32-bit float extension and that delivers a float32 in 2.75 ns. (363 million/good values/sec, period of 2**64 = 4 billion). The extra time is for the

Re: [go-nuts] Generics: the less obvious *constraints*, and the relationship to exception/error handling

On Mon, Feb 25, 2019 at 3:06 PM Louki Sumirniy wrote: > > I am in the middle of implementing a generic tree type as part of a CLI > flags/configuration package, and a key goal in my design is to make the > declarations it parses as easy to read as possible, and as far as possible, > avoiding

Re: [go-nuts] efficient random float32 number generator?

If you don't need precision, just generate ints and scale them. -rob On Tue, Feb 26, 2019 at 9:39 AM DrGo wrote: > Thanks Ian, > The std lib float32 is slow for my purpose. In my benchmarking it is > actually slower than the float64. But I don’t even need float16 precision. > I am working on

Re: [go-nuts] efficient random float32 number generator?

Thanks Ian, The std lib float32 is slow for my purpose. In my benchmarking it is actually slower than the float64. But I don’t even need float16 precision. I am working on implementing othe alias method for sampling from a fixed freq dist with possibly thousands of arbitrary values. So the rng

[go-nuts] Re: Generics: the less obvious *constraints*, and the relationship to exception/error handling

oh, just one last point after a re-read - a great deal of what is required to implement generics, in go, does not need to change the syntax of the language, except where it concerns that CCR - (as replacing the builtin numeric types especially would lead to massive overhead in dereferencing),

[go-nuts] Generics: the less obvious *constraints*, and the relationship to exception/error handling

I am in the middle of implementing a generic tree type as part of a CLI flags/configuration package, and a key goal in my design is to make the declarations it parses as easy to read as possible, and as far as possible, avoiding too much boilerplate. Yes, nothing new there, but in the

Re: [go-nuts] efficient random float32 number generator?

On Mon, Feb 25, 2019 at 2:01 PM DrGo wrote: > > what is the fastest possible algorithm to generate a float32 pseudo-random > number in [0.0,1.0)? > need to generate billions of numbers. Statistical performance and security > (and even space) are not a priority. > any Go implementations you know

[go-nuts] Announcement: DOM, HTML bindings for Go WASM + binding generator

Hi, I like to announce my open source project, https://gowebapi.github.io that is Go Web Assembly bindings for things like DOM, HTML, WebGL 1 & 2, SVG 2, CSS, media streams, payment etc, etc. It currently consists of about 80 different standards, see status page for details. Godocs:

[go-nuts] Best way to do this in golang

How fast is the query? You can make it parallel, but if it is sliw, the you have to target that first. How big is the set of one user's all urls? How fast is to get this? Maybe adding some indexes may help How fast is the query with one pattern only? Maybe combining them into a "similar to

Re: [go-nuts] is it possible to run cgo -buildmode=c-shared dynamic library on main thread?

On Mon, Feb 25, 2019 at 1:56 AM Randall O'Reilly wrote: > I’m building a shared library of Go code that is loaded as a module by > python, and called from there. Somehow, I need to ensure that one > particular function is called on the main thread (Mac OS cocoa gui event > loop code requires

Re: [go-nuts] How to kill all open TCP connections?

I'm just coming back to let y'all know that we've progressed; there are actually two separate problems. the nolocaltimewait sysctl seems like a solution to the one I mentioned, but there's also another issue that I might have traced to nginx's end. Either way, it's clear now that the problem

[go-nuts] Re: Resolving methods on pointer types

I could be wrong but this seems like over-complicating what you need. Just return the pointer to your foo struct. If you have your NewFoo return your pointer it should be accessible but not modifiable and a quick test I just did seems to validate that. Let me know if I misunderstand, in

Re: [go-nuts] Memory corruption with GOGC=on

2019. február 25., hétfő 10:18:42 UTC+1 időpontban yang...@gmail.com a következőt írta: > > I'm sorry for the missed detail of Receive() function. Variable gReceive > (sorry > for the silly variable name) will be manipulated in Go, since some data > coversions in the latter loop. > >

[go-nuts] is it possible to run cgo -buildmode=c-shared dynamic library on main thread?

I’m building a shared library of Go code that is loaded as a module by python, and called from there. Somehow, I need to ensure that one particular function is called on the main thread (Mac OS cocoa gui event loop code requires this). I tried adding an init() function in the library and

Re: [go-nuts] Memory corruption with GOGC=on

I'm sorry for the missed detail of Receive() function. Variable gReceive (sorry for the silly variable name) will be manipulated in Go, since some data coversions in the latter loop. Function Receive(): func Receive( devType int, devIndex int, canIndex int, pReceive []CanObj, waitTime int, )

Re: [go-nuts] Memory corruption with GOGC=on

2019. február 25., hétfő 9:10:19 UTC+1 időpontban yang...@gmail.com a következőt írta: > > Thank you! > > There is a pointer copied between Go and Cgo indeed, i.e., Go creates a > slice (pReceive) to Cgo, which reads data into it. It would be reasonable > when there are some panics occurred

Re: [go-nuts] Memory corruption with GOGC=on

Thank you! There is a pointer copied between Go and Cgo indeed, i.e., Go creates a slice (pReceive) to Cgo, which reads data into it. It would be reasonable when there are some panics occurred there. Actually, what triggers the panic is the make-slice statements, i.e., cReceive :=