Re: [go-nuts] cgo error I don't understand

Hello, the entry in the path for mingwin is wrong: it should be either start with C:\ or another drive letter or in case it's an absolute path with double backslash. Br Roland Am Freitag, 5. November 2021 schrieb Robert Solomon : > The full error is: > # github.com/go-gl/glfw/v3.3/glfw > cgo:

Re: [go-nuts] cgo error I don't understand

On Thu, Nov 4, 2021 at 4:41 PM Robert Solomon wrote: > > The results of go env are below. If I'm reading this correctly, CC=gcc. > > set GO111MODULE=auto > set GOARCH=amd64 > set GOBIN= > set GOCACHE=C:\Users\Owner\AppData\Local\go-build > set GOENV=C:\Users\Owner\AppData\Roaming\go\env > set

Re: [go-nuts] cgo error I don't understand

The results of go env are below. If I'm reading this correctly, CC=gcc. set GO111MODULE=auto set GOARCH=amd64 set GOBIN= set GOCACHE=C:\Users\Owner\AppData\Local\go-build set GOENV=C:\Users\Owner\AppData\Roaming\go\env set GOEXE=.exe set GOEXPERIMENT= set GOFLAGS= set GOHOSTARCH=amd64 set

Re: [go-nuts] cgo error I don't understand

On Wed, Nov 3, 2021 at 5:40 PM Robert Solomon wrote: > > I'm setting up a new Windows10 computer. I installed Go 1.17.2 and mingw64 > for cgo. When I tried to compile a project that uses cgo, I got this error: > > cgo: exec gcc: gcc resolves to executable relative to current directory >

Re: [go-nuts] HPC image processing in go?

I'm wondering if it would be worth the effort to improve Go's vectorization optimizations as opposed to creating/improving its bindings to the various GPUs. Jon On Thursday, November 4, 2021 at 7:28:15 AM UTC-7 david@gmail.com wrote: > On Thu, Nov 4, 2021 at 5:43 AM quin...@gmail.com >

Re: [go-nuts] Go build speed dependent on time after source modification

On Thu, Nov 4, 2021 at 10:25 AM Brian Hatfield wrote: > This seems a little like you might have a background compilation process > occurring which is populating the build cache. What editor environment are > you using? Is it possible it is effectively running compilations on your > code, whether

Re: [go-nuts] Go build speed dependent on time after source modification

This seems a little like you might have a background compilation process occurring which is populating the build cache. What editor environment are you using? Is it possible it is effectively running compilations on your code, whether via IDE support, indirectly via linters, or other on-save

[go-nuts] Go build speed dependent on time after source modification

I recently migrated from a 2019 i9 Macbook Pro to a new M1 Max Macbook Pro (64GB on both machines), and to my surprise, my go build times ended up being the same. I started to do some research, and I've found a curious behavior that I'm hoping someone can shed some light on. This is with go

[go-nuts] [security] Go 1.17.3 and Go 1.16.10 are released

Hi gophers, We have just released Go versions 1.17.3 and 1.16.10, minor point releases. These minor releases include two security fixes following the security policy : - archive/zip: don't panic on (*Reader).Open Reader.Open (the API implementing io/fs.FS

Re: [go-nuts] Sleep causes a tenfold difference in time interval

Because when you sleep you deschedule the process/thread by the OS - and so the cached code and data needs to be reloaded so operations aren’t slower until then. > On Nov 4, 2021, at 11:19 AM, 尚义龙 wrote: > >  > I was doing pressure testing in my project and found a large gap in the time >

[go-nuts] Sleep causes a tenfold difference in time interval

I was doing pressure testing in my project and found a large gap in the time interval due to time.Sleep, which I abstracted to the following code: code 1: ```go func TestSleep(t *testing.T) { for i := 0; i < 8; i++ { //time.Sleep(time.Second) t1 := time.Now() fmt.Println( time.Since(t1)) } } ```

[go-nuts] Golang JPEG2000 implementation / Gauging community interest in supporting it?

Hello, We (Segmed.ai) are processing a lot of medical imaging data. It comes to us in the form of PNG/JPG/DICOM files. 90% of it is uncompressed or using a normal JPEG encoding, but around ~7% of it is encoded with lossless JPEG 2000 format. We use Suyash Kumar's library:

Re: [go-nuts] How GC trace stack objects

Thank you Ian for the great answer. 在2021年11月4日星期四 UTC+8 上午7:21:57 写道： > On Wed, Nov 3, 2021 at 8:56 AM Ge wrote: > > > > Hi, recently I was trying to figure out how GC marks stack objects and > found > > some places of the implementation detail over my head. > > > > source: > > ``` > >

Re: [go-nuts] HPC image processing in go?

On Thu, Nov 4, 2021 at 5:43 AM quin...@gmail.com wrote: > Hi, > > Has anyone got any experience of high performance image processing in go? > > By this I mean doing complex image processing in real time at 4K > resolution on commodity hardware. This is really pushing it using carefully > written

[go-nuts] HPC image processing in go?

Hi, Has anyone got any experience of high performance image processing in go? By this I mean doing complex image processing in real time at 4K resolution on commodity hardware. This is really pushing it using carefully written C++ but when we tried writing similar code using go slices we go a

Re: [go-nuts] Anyway to wrap or tweak a test file before running go test?

Agreed. I've always found the "just add an argument with the right name" fixture feature too magical and implicit (read: confusing). I much prefer Go's explicitness here, even if slightly more verbose. IMO even in Python that kind of magic is usually frowned upon. -Ben On Thu, Nov 4, 2021 at

Re: [go-nuts] Anyway to wrap or tweak a test file before running go test?

On Thu, Nov 4, 2021 at 8:41 AM Brian Candler wrote: > Perhaps he's thinking of something like pytest. Simply by adding a named > argument to your test function, a corresponding helper is called to create > the value. There is a 'yield' variation so that the helper can also handle > cleanup

Re: [go-nuts] Anyway to wrap or tweak a test file before running go test?

On Wednesday, 3 November 2021 at 21:51:49 UTC axel.wa...@googlemail.com wrote: > On Wed, Nov 3, 2021 at 10:44 PM Matt Mueller wrote: > >> Hey, thanks. I'm aware of this approach. >> >> I'm hoping for some technique that automatically injects, since it can be >> cumbersome to inject all your