What is LAYER?
is priority an int16 or an uint16?
--
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.
For more options, visi
I am trying to call a DLL from go and I get an error "The parameter is
incorrect" error when I try to call this function
HANDLE Myopen(const char *filter, LAYER layer, INT16 priority, UINT64
flags)
is my signature in the C file
I call from golang using this
Open(lazyP*syscall.LazyProc, fi
Hello gophers,
We have just released go1.11beta3, a beta version of Go 1.11.
It is cut from the master branch at the revision tagged go1.11beta3.
Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.
Report any prob
Ok. Unfortunately emulation/simulation is not an option for me (trying to
write something against a GPU that I don't have locally.) Thanks for the
info though.
Kenny
On Friday, August 3, 2018 at 1:43:56 PM UTC-4, Ian Lance Taylor wrote:
>
> On Fri, Aug 3, 2018 at 8:06 AM, > wrote:
> >
> >
On Fri, Aug 3, 2018 at 8:06 AM, wrote:
>
> Are there any recommendations on developing on one architecture while
> deploying on another? For example, the target application is to be run on
> arm or on machines with more exotic hardware configurations while my
> development environment is an x86
Is your handler panicking? If so there are also other issues to address, but
you can test/quickfix this by deferring your decrement so it runs regardless:
atomic.AddInt64(&concur, 1)
defer atomic.AddInt64(&concur, -1)
h.ServeHTTP(w, r)
--
You received this message because you are subscribed to
Hi,
Are there any recommendations on developing on one architecture while
deploying on another? For example, the target application is to be run on
arm or on machines with more exotic hardware configurations while my
development environment is an x86 laptop. Are there better ways to do
itera
On Thu, Aug 2, 2018 at 11:58 PM, Michael Gross wrote:
> Thanks for this.
>
>
> What it boils down to for me is having a better reasoning for this
> suggestion from CodeReviewComments:
>
>
> “The implementing package should return concrete (usually pointer or struct)
> types”
>
>
> And that’s the r
Hi all,
It's been a bit tricky to track how vgo/Go 1.11 modules have evolved since
the first vgo blog series and since the official proposal was published.
To help with that, I tried to put together a list of some of the larger
user-facing changes in approach that happened after the first vgo b
That should work and probably is working. I expect h.ServeHTTP not
returning as quickly as you expect it to.
What you could try to do to test if there is an issue with decreasing the
atomic value is to split up concur into two counters, one for entry and one
for exit. The difference between the
Yes, a Close would, but that adds an API knob that shouln't be needed.
The closure approach is the first option that I posted.
On Fri, 2018-08-03 at 09:39 +0200, Sebastien Binet wrote:
> wouldn't this prevent the goroutine leak, w/o the need to drain the
> channel?
>
> func iterator(m map[KT]VT
Sounds like a job for ffmpeg, there are even Go bindings
https://godoc.org/github.com/giorgisio/goav/avcodec
I have never used it, so no idea if it really fits your bill.
Deployment: It links to a C library, so you may have to deploy those as
well.
Am Donnerstag, 2. August 2018 18:20:24 UTC+2 sc
wouldn't this prevent the goroutine leak, w/o the need to drain the channel?
func iterator(m map[KT]VT) iter {
itr := iter{C: make(chan VT), quit: make(chan struct{})}
go func() {
for _, v := range m {
select {
case <-
OH oh, Thanks so much!
On Wed, Aug 1, 2018 at 11:53 PM, wrote:
> The helper function could return the sorted keys. Then you access your map
> using the keys in a sorted way.
>
> https://play.golang.org/p/Fmezsi5pJKG
>
>
> --
> You received this message because you are subscribed to a topic in th
14 matches
Mail list logo
