[go-nuts] Re: GoMobile tools not recognised

2019-08-28 Thread starzar
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*. > >

[go-nuts] Re: GoMobile tools not recognised

2019-08-28 Thread Elias Naur
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*. > >

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

2019-08-28 Thread afriyie . abraham
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] S2: High speed compression with upgrade path from Snappy.

2019-08-28 Thread Klaus Post
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,

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

2019-08-28 Thread Durga Someswararao G
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

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

2019-08-28 Thread ahochauwaaaaa
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

Re: [go-nuts] Re: how to create path/v2 and path/v3 and path/v4 in same repo

2019-08-28 Thread Paul Jolly
The short version is: * semantic version git tags are the means of releasing new versions * you can follow whatever strategy you like when it comes to maintaining multiple major versions of a module (you might not need to); branch, subdirectory... Just so long as the git tag gets you to the right

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

2019-08-28 Thread afriyie . abraham
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

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

2019-08-28 Thread Tamás Gulácsi
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

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

2019-08-28 Thread Nigel Tao
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

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

2019-08-28 Thread Klaus Post
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

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

2019-08-28 Thread w1252675615
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

2019-08-28 Thread w1252675615
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 ...

[go-nuts] The time complexity of gc?

2019-08-28 Thread Jingyu Gao
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

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

2019-08-28 Thread Klaus Post
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.

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

2019-08-28 Thread Martin Schnabel
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

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

2019-08-28 Thread Martin Schnabel
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

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

2019-08-28 Thread Durga Someswararao G
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

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

2019-08-28 Thread Durga Someswararao G
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

[go-nuts] Re: VSCode

2019-08-28 Thread go je
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

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

2019-08-28 Thread Durga Someswararao G
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

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

2019-08-28 Thread Michel Levieux
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

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

2019-08-28 Thread Durga Someswararao G
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.

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

2019-08-28 Thread Michel Levieux
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

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

2019-08-28 Thread T L
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

Re: [go-nuts] About build Go Archive

2019-08-28 Thread Ian Lance Taylor
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 >

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

2019-08-28 Thread Ian Lance Taylor
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

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

2019-08-28 Thread Robert Engels
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]

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

2019-08-28 Thread Leo Lara
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

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

2019-08-28 Thread T L
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] An old problem: lack of priority select cases

2019-08-28 Thread Robert Engels
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-

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

2019-08-28 Thread Robert Engels
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:

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

2019-08-28 Thread T L
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

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

2019-08-28 Thread T L
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

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

2019-08-28 Thread Robert Engels
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:

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

2019-08-28 Thread T L
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

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

2019-08-28 Thread Leo Lara
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

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

2019-08-28 Thread Robert Engels
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

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

2019-08-28 Thread T L
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. > >

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

2019-08-28 Thread Leo Lara
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.

[go-nuts] Re: GoMobile tools not recognised

2019-08-28 Thread starzar
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*. > >

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

2019-08-28 Thread Michel Levieux
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.

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

2019-08-28 Thread Marcin Romaszewicz
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

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

2019-08-28 Thread Robert Engels
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

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

2019-08-28 Thread Leo Lara
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

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

2019-08-28 Thread Leo Lara
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

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

2019-08-28 Thread robert engels
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

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

2019-08-28 Thread Xiangdong JI
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