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

Hi Robert, To put you in context, it all started when I read https://go101.org/article/channel-closing.html , that said that it is impossible or at least you shouldn't close a channel that is being written by several goroutines. Then I wrote this article with my solution https://dev.to/leolara

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

Hi Michael, The way I always have seen "transparent" used in software engineering is, that the user of something (lirabry, service, framework, etc) can use it without knowing its internal details, just normally, and the magic is done in the thing used. To in terms of the problem I was trying t

[go-nuts] Building go 1.13 on aarch64 failed in pkg testing

Hello, I got the following error while building the latest source code (synced to d0eaec79f9) on aarch64, both cache and /tmp/go-build* had been cleaned in advance, can anyone shed a light? Thanks a lot. go tool dist: unexpected stale targets reported by go list -gcflags="" -ldflags="" for [st

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

Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf It won’t run correctly in the playground because it terminates when all routines are asleep - which happens during the test (not sure why it does this, as sleeping is different than a de

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

One should also be careful regarding the conceptual demands he or she is making. Having a shared resource (that is complex enough that it cannot be atomically accessed or modified) means essentially that "having multiple writers being transparent to the readers", fundamentally, is not possible. >F

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

Think of a channel as existing for the lifetime of a particular data stream, and not have it be associated with either producer or consumer. Here's an example: https://play.golang.org/p/aEAXXtz2X1g The channel here is closed after all producers have exited, and all consumers continue to run until

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

I will write and post this evening. -Original Message- From: T L Sent: Aug 28, 2019 1:11 PM To: golang-nuts Subject: Re: [go-nuts] An old problem: lack of priority select cases On Wednesday, August 28, 2019 at 1:49:51 PM UTC-4, Robert Engels wrote:As I said in another email, using a RWMu

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

I do not think priority select is *necessary*, it could be a nice addition if the performance does not change. On Wednesday, August 28, 2019 at 8:27:36 PM UTC+2, Leo Lara wrote: > > Hi Robert, > > From the article: """To bound more the problem, in my case, you control > the writers but not the r

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

Hi Robert, >From the article: """To bound more the problem, in my case, you control the writers but not the readers""" So what I was trying to do was to be able to close, with mutiple writers, while being transparent for the readers. The readers only need to read as usual form the channel. Fo

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

On Wednesday, August 28, 2019 at 1:49:51 PM UTC-4, Robert Engels wrote: > > As I said in another email, using a RWMutex makes the multiple senders > problem easily solvable. Grab the Read lock when writing, and the Write > lock when closing. Set a 'closed' flag during Close that is checked duri

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

As I said in another email, using a RWMutex makes the multiple senders problem easily solvable. Grab the Read lock when writing, and the Write lock when closing. Set a 'closed' flag during Close that is checked during the write.-Original Message- From: T L Sent: Aug 28, 2019 12:37 PM To: g

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

On Wednesday, August 28, 2019 at 1:12:10 PM UTC-4, Robert Engels wrote: > > And what I was trying to say is that request is inherently racy. > > You can already do priority selects. see > https://play.golang.org/p/58FfsKIivSr as a way to do it - more realistic > though to use buffered channels.

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

On Wednesday, August 28, 2019 at 1:06:07 PM UTC-4, Leo Lara wrote: > > This is connected with my article: > https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2 > > I think there I show it is possible to workaround that limitation using > standard Go tools. Of course,

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

On Wednesday, August 28, 2019 at 1:14:09 PM UTC-4, Robert Engels wrote: > > Reading the article, why not just wrap the write function in one that uses > panic/recover, since the write is expected to panic if the channel is > closed. > Using panic/recover is a way, but it is ugly. > > -O

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

A better solution is to wrap the writes using a RWLock, grab the read lock for writing, and the Write lock for closing. Pretty simple.Just encapsulate it all in a MultiWriterChannel struct - generics would help here :)-Original Message- From: Leo Lara Sent: Aug 28, 2019 11:24 AM To: golang

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

Reading the article, why not just wrap the write function in one that uses panic/recover, since the write is expected to panic if the channel is closed.-Original Message- From: Leo Lara Sent: Aug 28, 2019 11:24 AM To: golang-nuts Subject: [go-nuts] Re: An old problem: lack of priority sel

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

And what I was trying to say is that request is inherently racy.You can already do priority selects. see https://play.golang.org/p/58FfsKIivSr as a way to do it - more realistic though to use buffered channels. Pretty easy to wrap this in a function that takes N channels.-Original Message-

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

This is connected with my article: https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2 I think there I show it is possible to workaround that limitation using standard Go tools. Of course, the code would be simple with priority select, but also perhaps select would be

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

On Wednesday, August 28, 2019 at 12:36:56 PM UTC-4, Robert Engels wrote: > > That's inherently racy - since between when the runtime determines the > channel is OK for writing, another routine can close the channel before the > write is attempted - so "priorities" won't help. > I understand th

[go-nuts] Re: GoMobile tools not recognised

On Monday, 19 August 2019 01:57:24 UTC+5:30, starzar wrote: > > On installing Golang mobile tools > on my > Windows10-64bit machine,the gomobile tools are not recognised . The > installation path is the *GOROOT PATH C:\Go*. > > GolangVersion

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

That's inherently racy - since between when the runtime determines the channel is OK for writing, another routine can close the channel before the write is attempted - so "priorities" won't help.-Original Message- From: T L Sent: Aug 28, 2019 11:06 AM To: golang-nuts Subject: [go-nuts] An

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

The old thread: https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o Go channels are flexible, but in practice, I often encountered some situations in which channel are hard to use. Given an example: import "math/rand" type Producer struct { data chan int closed chan struc

Re: [go-nuts] The time complexity of gc?

On Wed, Aug 28, 2019 at 5:53 AM Jingyu Gao wrote: > > Is the gc time complexity O(n) ? n is the num of alive object. > Is there a formula to describe the gc time? > How can I know the meaning time per object? > Is there some related paper or blog? > Or the question is no meaning? Since the curre

Re: [go-nuts] About build Go Archive

On Wed, Aug 28, 2019 at 5:53 AM wrote: > > As we know, Go 1.13 will drop support for binary-only packages. it seems we > have to use buildmode=plugin/archive if we want to build go archive to > provide to others. > > when I try go buildmode=archive or buildmode=shared(go 1.12, go module > proje

Re: [go-nuts] Regarding strings replace functions issues

Thanks Michel. On Wed, Aug 28, 2019 at 5:53 PM Michel Levieux wrote: > https://golang.org/ref/spec#String_literals > > Here you go. > > > Le mer. 28 août 2019 à 14:05, Durga Someswararao G < > durgasomeswararao...@gmail.com> a écrit : > >> Hi Martin, >> Thanks for your help. >> >> From first poi

Re: [go-nuts] S2: High speed compression with upgrade path from Snappy.

Also, while there was other opportunities for making it more effective (3 byte offsets, even shorter repeat codes), I choose to keep it as close to Snappy as feasible so the same decoder works for both formats. Re "better (compression)": Yeah, it does require to read the docs. Oh well. /Klau

Re: [go-nuts] Re: buildmode=c-archive and statically linking into another lib

thank you~I got it. 在 2019年8月28日星期三 UTC+8上午11:59:42，Justin Israel写道： > > > > On Wed, Aug 28, 2019, 3:47 PM > wrote: > >> I find the package you build with 'go build >> buildmode=c-archive/c-shared', when you build you code with the lib, the >> outer need to have main func, I don't know why. >> >

[go-nuts] About build Go Archive

As we know, Go 1.13 will drop support for binary-only packages. it seems we have to use buildmode=plugin/archive if we want to build go archive to provide to others. when I try go buildmode=archive or buildmode=shared(go 1.12, go module project), it throw error like cannot use packages ... from

[go-nuts] The time complexity of gc?

Is the gc time complexity *O*(*n*) ? n is the num of alive object. Is there a formula to describe the gc time? How can I know the meaning time per object? Is there some related paper or blog? Or the question is no meaning? -- You received this message because you are subscribed to the Google Gr

Re: [go-nuts] Regarding strings replace functions issues

https://golang.org/ref/spec#String_literals Here you go. Le mer. 28 août 2019 à 14:05, Durga Someswararao G < durgasomeswararao...@gmail.com> a écrit : > Hi Martin, > Thanks for your help. > > From first point as you said is right in my case \\n is as it is > considering \n as string thanks for

Re: [go-nuts] Regarding strings replace functions issues

Go has a fantastic and very readable language specification with all the details: https://golang.org/ref/spec#String_literals (To my surprise the effective go document does not explain raw string literals, but uses them in the web server example in the template string) Another guess by Michel i

[go-nuts] Re: VSCode

I have this because installing and reinstall messes my git bash export GOPATH=/c/Users/Goko/go; export PATH=$PATH:$GOPATH/bin; On Tuesday, August 27, 2019 at 8:40:33 PM UTC+8, Andreqx wrote: > > I am trying to install VSCode to run with Go. I Need to modify the > /.bashrc file. Could somebod

Re: [go-nuts] Regarding strings replace functions issues

Hi Martin, Thanks for your help. >From first point as you said is right in my case \\n is as it is considering \n as string thanks for this. Second point you mentioned about back-ticks where can I get this information? Can you please share any reference links to get more knowledge about this. Th

Re: [go-nuts] S2: High speed compression with upgrade path from Snappy.

On Wednesday, 28 August 2019 12:57:33 UTC+2, Nigel Tao wrote: > > On Wed, Aug 28, 2019 at 7:11 PM Klaus Post > wrote: > > TLDR; LZ4 is typically between the default and "better" mode of s2. > > Nice! > > Just a suggestion: rename "better" to either "betterSize / smaller" > (i.e. better compre

Re: [go-nuts] Regarding strings replace functions issues

Somewhere in your code producing the text you seem to escape the the escape sequence for the newline character. "\n" is a string with the escape sequence for the newline character '\n' "\\n" is a string with escaped slash and a lowercase n '\\' 'n' Again, without seeing the code we can only gues

Re: [go-nuts] S2: High speed compression with upgrade path from Snappy.

On Wed, Aug 28, 2019 at 7:11 PM Klaus Post wrote: > TLDR; LZ4 is typically between the default and "better" mode of s2. Nice! Just a suggestion: rename "better" to either "betterSize / smaller" (i.e. better compression ratio, worse throughput) or "betterSpeed / faster", otherwise it's not immedi

Re: [go-nuts] Regarding strings replace functions issues

Hi, Manually I tried but here my concern is shall I get the reason, Why that was happening like that? I am trying to debug strings.Replace is not working. Thanks. On Wed, Aug 28, 2019 at 3:52 PM Michel Levieux wrote: > Hi, > > Isn't it that from the other side, you escape the string, or call a

Re: [go-nuts] Regarding strings replace functions issues

Hi, Isn't it that from the other side, you escape the string, or call a method that does it before sending it via tcp? That would explain that all the "\n" become "\\n". Le mer. 28 août 2019 à 12:17, Durga Someswararao G < durgasomeswararao...@gmail.com> a écrit : > Hi Tamás, > > But even in oth

Re: [go-nuts] Regarding strings replace functions issues

Hi Tamás, But even in other side also I am using golang to convert string into bytes. Using tcp connection with net package I am getting data from other process. FYI When I try to replace string with \\n it was working fine. Like below: processoutput = strings.Replace("String 1\n String 2","\\n"

Re: [go-nuts] Regarding strings replace functions issues

That means that other process speaks some other encoding, not utf-8, which the strings package waits. Use golang.org/x/text/encoding to convert to utf-8. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop rec

Re: [go-nuts] S2: High speed compression with upgrade path from Snappy.

On Wednesday, 28 August 2019 02:37:25 UTC+2, Nigel Tao wrote: > > On Mon, Aug 26, 2019 at 8:29 PM Klaus Post > wrote: > > This package is aimed at replacing Snappy as a high speed compression > package. If you are mainly looking for better compression zstandard gives > better compression, but

[go-nuts] Re: Diameter EAP Application - go-diameter

Hi, Yes, i mean “github.com/fiorix/go-diameter” package. I have open an issue asking if it possible https://github.com/fiorix/go-diameter

Re: [go-nuts] Diameter EAP Application - go-diameter

Hi, Do you mean “github.com/fiorix/go-diameter” package? I think it’s impossible without modifying large part of the source code in the package itself, but you still have chance to get some hints by asking on GitHub issue. https://github.com/fiorix/go-diameter Yoshiyuki 2019/08/28 16:28、afriy

Re: [go-nuts] Regarding strings replace functions issues

Hi, Here I have added the link for my exact concern. Please consider from byte conversion to string only. Here getting as expected but while reading from another process not working with strings package. https://play.golang.org/p/7YqfuLWQHtT On Wed, Aug 28, 2019 at 12:04 AM Martin Schnabel wrote:

[go-nuts] Diameter EAP Application - go-diameter

Hi All, It it possible to modify the go-diameter package to implement Diameter EAP Application, that is instead of the current capabilities exchange request and answer, CER/CEA exchange, i would like to do a DER/DEA request and answer. If possible how would go about it, which files or part of t

[go-nuts] Re: GoMobile tools not recognised

søndag den 18. august 2019 kl. 21.27.24 UTC+1 skrev starzar: > > On installing Golang mobile tools > on my > Windows10-64bit machine,the gomobile tools are not recognised . The > installation path is the *GOROOT PATH C:\Go*. > > GolangVersi