Re: [go-nuts] Channels may not be the best solution in Go

> > > Not all programs benefit from concurrency. Writing concurrent code for > essentially sequential programs will not benefit from multiple cores, > like generating prime numbers. Do not forget that concurrency includes > overhead for context switch and memory barriers. Using channels in a > sequ

Re: [go-nuts] Re: An old problem: lack of priority select cases

> Please, drop it. You don't know what you're talking about. I've been amazed at how patient everyone has been. I think it's time to be more blunt in pointing out you don't understand concurrency and independent events. Maybe. But you don't know I'm talking about for sure. -- You received this

Re: [go-nuts] Re: An old problem: lack of priority select cases

Please, drop it. You don't know what you're talking about. I've been amazed at how patient everyone has been. I think it's time to be more blunt in pointing out you don't understand concurrency and independent events. On Fri, Oct 4, 2019 at 3:15 PM T L wrote: > > > On Friday, October 4, 2019 at

Re: [go-nuts] Re: An old problem: lack of priority select cases

On Friday, October 4, 2019 at 5:40:08 PM UTC-4, ohir wrote: > > On Fri, 4 Oct 2019 13:52:19 -0700 (PDT) > T L > wrote: > > > One priority-order select block is not only cleaner than two > random-order > > select blocks, but also more efficient. > > It is neither. > > 1. It is not cleaner, b

Re: [go-nuts] Re: An old problem: lack of priority select cases

On Fri, 4 Oct 2019 13:52:19 -0700 (PDT) T L wrote: > One priority-order select block is not only cleaner than two random-order > select blocks, but also more efficient. It is neither. 1. It is not cleaner, because you would need to somehow denote priorities. If you think now about "in written

[go-nuts] Re: Correct way of sending HEADERS and DATA frames in http2?

Did you solve this problem? If so, could I see the code? I am trying to read the stream's priority field. Em quarta-feira, 23 de maio de 2018 07:41:34 UTC-3, Ankit Gupta escreveu: > > I am using *golang.org/x/net/http2 * and > *golang.org/x/net/http2/ >

Re: [go-nuts] Re: An old problem: lack of priority select cases

But even the two select blocks does not really make a difference. I have shared code that did this previously.For another example, think of two channels A and B. A is the high priority channel where all events should be processed before B channel events - this is especially important considering th

Re: [go-nuts] Re: An old problem: lack of priority select cases

On Friday, October 4, 2019 at 4:38:36 PM UTC-4, Marcin Romaszewicz wrote: > > What he's trying to say is that it is pointless to order select cases in > this example, because it is impossible to guarantee ordering in an > asynchronous system. > > You have two asynchronous data streams, ctx.Done

Re: [go-nuts] Re: An old problem: lack of priority select cases

What he's trying to say is that it is pointless to order select cases in this example, because it is impossible to guarantee ordering in an asynchronous system. You have two asynchronous data streams, ctx.Done() and "v", in that example above. Generally, those select cases will happen one by one,

Re: [go-nuts] Re: An old problem: lack of priority select cases

On Friday, October 4, 2019 at 4:09:09 PM UTC-4, Robert Engels wrote: > > Because ctx.Done() and v being ready for read are independent events. You > can not impose ordering on them unless there is an outer mutex that both > events are subject to. > > As an aside, this is why I think the best 'c

Re: [go-nuts] Re: An old problem: lack of priority select cases

On Friday, October 4, 2019 at 4:09:09 PM UTC-4, Robert Engels wrote: > > Because ctx.Done() and v being ready for read are independent events. You > can not impose ordering on them unless there is an outer mutex that both > events are subject to. > > As an aside, this is why I think the best 'c

Re: [go-nuts] Re: An old problem: lack of priority select cases

Because ctx.Done() and v being ready for read are independent events. You can not impose ordering on them unless there is an outer mutex that both events are subject to.As an aside, this is why I think the best 'concurrent software' developers are those that have been exposed to at least some hardw

[go-nuts] Re: PKCs8 generated using go has errors when doing a openssl check

Sorry, I speed read your email, but you were right Piers. "PRIVATE KEY" as header makes the difference. Rajesh. On Friday, October 4, 2019 at 9:39:52 AM UTC-7, rajesh nataraja wrote: > > Hello Piers, > > I have tried your playground snippet and the snippet I gave here. Both > dont work, what

[go-nuts] xerrors and stack trace

Hi, I was using xerrors, and now with go1.13 i wanted to remove this dependency since I read on github.com/golang/xerrors This repository holds the transition packages for the new Go 1.13 error values. But unfortunately there are no more stack trace in go1.13 So xerrors is not more a tra

Re: [go-nuts] Re: An old problem: lack of priority select cases

On Friday, October 4, 2019 at 3:32:31 PM UTC-4, Robert Engels wrote: > > You still are not understanding proper concurrent design. Priority select > cases do not matter in the case of asynchronous external events. > It at least avoids code verbosity and improves code quantity.. BTW, I don't

Re: [go-nuts] Re: An old problem: lack of priority select cases

You still are not understanding proper concurrent design. Priority select cases do not matter in the case of asynchronous external events. > On Oct 4, 2019, at 1:46 PM, T L wrote: > >  > I just found an example in the "context" package docs: > > // // Stream generates values with DoSom

[go-nuts] Re: An old problem: lack of priority select cases

On Friday, October 4, 2019 at 2:46:36 PM UTC-4, T L wrote: > > I just found an example in the "context" package docs: > > // // Stream generates values with DoSomething and sends them to out > // // until DoSomething returns an error or ctx.Done is closed. > // func Stream(ctx cont

[go-nuts] Re: An old problem: lack of priority select cases

I just found an example in the "context" package docs: // // Stream generates values with DoSomething and sends them to out // // until DoSomething returns an error or ctx.Done is closed. // func Stream(ctx context.Context, out chan<- Value) error { // for { //

[go-nuts] Re: PKCs8 generated using go has errors when doing a openssl check

Hello Piers, I have tried your playground snippet and the snippet I gave here. Both dont work, what I meant is saving the Marshalled key into a file and then using that to be processed by other applications (java, python, openssl command). This is with go 1.11.5, do you think there is some com

[go-nuts] Re: PKCs8 generated using go has errors when doing a openssl check

For PKCS8 (rather than PKCS1), use PEM type "PRIVATE KEY" (rather than "RSA PRIVATE KEY"). You may be constructing the ASN1 by hand deliberately, but just in case you didn't see it, there's also a standard library function x509.MarshalPKCS8PrivateKey() https://godoc.org/crypto/x509#MarshalPKCS

Re: [go-nuts] Channels may not be the best solution in Go

JuciÊ, I'm not going to endorse or dispute you assertions in the general case. But, I do want to point out that the OP started with "I've been working on a math library". It then provides a link to the library on github. It may be a matter of personal choice and style when writing an applicati

Re: [go-nuts] micro review and hello gio: portable GUI code, all in Go

> FYI, Elias gave a talk about this project at Gophercon: > https://www.youtube.com/watch?v=9D6eWP4peYM . > > Ian > And another at Gophercon UK: https://www.youtube.com/watch?v=PxnL3-Sex3o And there will be another (+workshop) at GoLab later this month :) Thank you for the glowing (micro) r

Re: [go-nuts] micro review and hello gio: portable GUI code, all in Go

On Thu, Oct 3, 2019 at 10:08 PM Jason E. Aten wrote: > > Somehow I missed Gio ( https://gioui.org/ ) on its first announcement earlier > this year. > > Gio -- as a pure Go GUI framework -- really ought to be better known. > > Hence I offer here a short review, and a getting started example projec

Re: [go-nuts] Channels may not be the best solution in Go

Travis, glad to hear that you are exploring Harshad Numbers. It is an area where I have done more than a decade of work and I did not know that anyone else even cared about them. If you ever want to know how many thousand digit (or whatever) base 10 (or whatever) numbers have the Harshad property,

[go-nuts] Re: Clarification on unsafe conversion between string <-> []byte

I wrote a self contained implementation of the solution described by Keith Randall. It seemed at the end of this long thread it would be nice to have something concrete to look at. https://github.com/fmstephe/unsafeutil On Friday, October 4, 2019 at 11:38:22 AM UTC+2, Francis Stephens wrote: >

[go-nuts] Re: Clarification on unsafe conversion between string <-> []byte

Serhat, That implementation looks very tidy. But it still uses uintptr. So it doesn't solve the GC problems discussed above. On Thursday, September 26, 2019 at 10:59:08 PM UTC+2, Serhat Şevki Dinçer wrote: > > Hi, > > I wrote a string utility library with many >