date:20190828

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/closing-a-go-channel-written-by-several-goroutines-52j2 
also 
in 
https://medium.com/@leolara/closing-a-go-channel-written-by-several-goroutines-eba3a6c9404b
 I 
then created this issue https://github.com/go101/go101/issues/132 and from 
there this topic was created by T L.

Your example does not have several goruitnes writing so I think it is a 
different problem. Perhaps that simple lock would work with several 
goroutines, but I think there would be more contention with this lock.

Anyway, I think I have already an optimisation to my code, I think using a 
RW lock, if I put the "Add(1)" in a read lock and the wait in a Write lock 
it might work better. The race condition that my lock prevents is only 
related when an "Add" and a "Wait" run concurrently, several "Add" can run 
concurrently.

On Thursday, August 29, 2019 at 4:05:06 AM UTC+2, robert engels wrote:
>
> 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 deadlock).
>
> It is probably less efficient, and less orderly than the other example 
> using WaitGroup but you get the idea I hope. It forcibly terminates the 
> writers before they complete by design.
>
> On Aug 28, 2019, at 4:09 PM, Michel Levieux  > wrote:
>
> 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.
>
> From the moment itself when such a resource is shared, there must be some 
> sort of mecanism (that one using resources atomically usable) that ensures 
> the integrity of it.
> Maybe what you're talking about is having it transparent in terms of code, 
> in which case we both agree, but if you're looking for something 
> transparent in essence, as in performance, logical construction and all the 
> rest, I think there is a misunderstanding here: even if it was added in the 
> language, there would be many many things going on under the hood, as it is 
> already (and cannot really be otherwise) for channel use alone.
>
> As for the priority using selects, I think it's more of something to be 
> dealt with on the "user-side". There are many kinds of priority in general, 
> and trying to implement something in the language itself would IMO either 
> be too specific compared to the nessecary time to do so or it would 
> probably have a huge overhead on the "classical' use case of the select 
> construct.
> + the fact that it is apparently already possible using RWMutexes.
>
> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz  > a écrit :
>
>> 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 the channel is drained of data.
>>
>> The producers are managed by something somewhere in your code - and that 
>> is the scope at which it makes sense to create channel ownership. I've used 
>> a waitgroup to ensure that the channel is closed after all producers exit, 
>> but you can use whatever barrier construct you want.
>>
>> Even if you must have a channel per producer, you can safely close the 
>> producer side, without notifying the downstream about this. The example 
>> early in the thread uses multiple channels, with one channel being used to 
>> signal that the producers should exit. Channels aren't really the right 
>> model for this, you want a thread safe flag of some sort. For example:
>>
>> var exitFlag uint64
>> func producer(chan data int, wg *sync.WaitGroup) {
>> defer wg.Done()
>> for {
>> shouldExit := atomic.LoadUint64(&exitFlag)
>> if shouldExit == 1 {
>>  return
>> }
>> chan <- rand.Intn(100)
>> }
>> }
>>
>> Here's 10 producers and 3 consumers sharing a channel and closing it 
>> safely upon receiving an exit flag:
>> https://play.golang.org/p/RiKi1PGVSvF
>>
>> -- Marcin
>>
>> On Wed, Aug 28, 2019 at 11:29 AM Leo Lara > > wrote:
>>
>>> 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 prob

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 to solve: being able to close a 
channel that is written by serveral goroutines, transparent property is 
that the reader or readers of the channel they just do that, without 
knowing about something else.

I think this is established in the article beginnings here: 
https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2

Regarding the priority select, I agree.

On Wednesday, August 28, 2019 at 11:10:18 PM UTC+2, Michel Levieux wrote:
>
> 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.
>
> From the moment itself when such a resource is shared, there must be some 
> sort of mecanism (that one using resources atomically usable) that ensures 
> the integrity of it.
> Maybe what you're talking about is having it transparent in terms of code, 
> in which case we both agree, but if you're looking for something 
> transparent in essence, as in performance, logical construction and all the 
> rest, I think there is a misunderstanding here: even if it was added in the 
> language, there would be many many things going on under the hood, as it is 
> already (and cannot really be otherwise) for channel use alone.
>
> As for the priority using selects, I think it's more of something to be 
> dealt with on the "user-side". There are many kinds of priority in general, 
> and trying to implement something in the language itself would IMO either 
> be too specific compared to the nessecary time to do so or it would 
> probably have a huge overhead on the "classical' use case of the select 
> construct.
> + the fact that it is apparently already possible using RWMutexes.
>
> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz  > a écrit :
>
>> 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 the channel is drained of data.
>>
>> The producers are managed by something somewhere in your code - and that 
>> is the scope at which it makes sense to create channel ownership. I've used 
>> a waitgroup to ensure that the channel is closed after all producers exit, 
>> but you can use whatever barrier construct you want.
>>
>> Even if you must have a channel per producer, you can safely close the 
>> producer side, without notifying the downstream about this. The example 
>> early in the thread uses multiple channels, with one channel being used to 
>> signal that the producers should exit. Channels aren't really the right 
>> model for this, you want a thread safe flag of some sort. For example:
>>
>> var exitFlag uint64
>> func producer(chan data int, wg *sync.WaitGroup) {
>> defer wg.Done()
>> for {
>> shouldExit := atomic.LoadUint64(&exitFlag)
>> if shouldExit == 1 {
>>  return
>> }
>> chan <- rand.Intn(100)
>> }
>> }
>>
>> Here's 10 producers and 3 consumers sharing a channel and closing it 
>> safely upon receiving an exit flag:
>> https://play.golang.org/p/RiKi1PGVSvF
>>
>> -- Marcin
>>
>> On Wed, Aug 28, 2019 at 11:29 AM Leo Lara > > wrote:
>>
>>> 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 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.

 For example, if you want to write a library where the user just reads 
 from a channel, this is an approach I found where the user of the lirbary 
 deos nto have to do anything special. Of course, there might be another 
 solution, but if you need to modify the reader we are talking about a 
 different problem.

 Cheers!!

 On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:
>
> 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 
> wo

[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 [std]:
STALE crypto/tls: not installed but available in build cache
STALE crypto/x509: not installed but available in build cache
STALE net: not installed but available in build cache
STALE net/http: not installed but available in build cache
STALE net/http/cookiejar: not installed but available in build cache
STALE net/http/httptest: not installed but available in build cache
STALE net/http/httptrace: not installed but available in build cache
STALE net/http/httputil: not installed but available in build cache
STALE net/textproto: not installed but available in build cache
STALE os/signal/internal/pty: not installed but available in build cache
STALE os/user: not installed but available in build cache
STALE vendor/golang.org/x/net/http/httpguts: not installed but available in 
build cache
STALE vendor/golang.org/x/net/http/httpproxy: not installed but available 
in build cache
STALE vendor/golang.org/x/net/nettest: not installed but available in build 
cache

// go env
GOARCH="arm64"
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOOS="linux"
GOROOT="/usr/lib/go-1.10"
GOTOOLDIR="/usr/lib/go-1.10/pkg/tool/linux_arm64"
CGO_ENABLED="1"

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8f38c5f3-7ca8-405f-b2d2-1804dd9bdddb%40googlegroups.com.

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 deadlock).

It is probably less efficient, and less orderly than the other example using 
WaitGroup but you get the idea I hope. It forcibly terminates the writers 
before they complete by design.

> On Aug 28, 2019, at 4:09 PM, Michel Levieux  wrote:
> 
> 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.
> 
> From the moment itself when such a resource is shared, there must be some 
> sort of mecanism (that one using resources atomically usable) that ensures 
> the integrity of it.
> Maybe what you're talking about is having it transparent in terms of code, in 
> which case we both agree, but if you're looking for something transparent in 
> essence, as in performance, logical construction and all the rest, I think 
> there is a misunderstanding here: even if it was added in the language, there 
> would be many many things going on under the hood, as it is already (and 
> cannot really be otherwise) for channel use alone.
> 
> As for the priority using selects, I think it's more of something to be dealt 
> with on the "user-side". There are many kinds of priority in general, and 
> trying to implement something in the language itself would IMO either be too 
> specific compared to the nessecary time to do so or it would probably have a 
> huge overhead on the "classical' use case of the select construct.
> + the fact that it is apparently already possible using RWMutexes.
> 
> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz  > a écrit :
> 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 the channel is drained of data.
> 
> The producers are managed by something somewhere in your code - and that is 
> the scope at which it makes sense to create channel ownership. I've used a 
> waitgroup to ensure that the channel is closed after all producers exit, but 
> you can use whatever barrier construct you want.
> 
> Even if you must have a channel per producer, you can safely close the 
> producer side, without notifying the downstream about this. The example early 
> in the thread uses multiple channels, with one channel being used to signal 
> that the producers should exit. Channels aren't really the right model for 
> this, you want a thread safe flag of some sort. For example:
> 
> var exitFlag uint64
> func producer(chan data int, wg *sync.WaitGroup) {
> defer wg.Done()
> for {
> shouldExit := atomic.LoadUint64(&exitFlag)
> if shouldExit == 1 {
>  return
> }
> chan <- rand.Intn(100)
> }
> }
> 
> Here's 10 producers and 3 consumers sharing a channel and closing it safely 
> upon receiving an exit flag:
> https://play.golang.org/p/RiKi1PGVSvF 
> 
> -- Marcin
> 
> On Wed, Aug 28, 2019 at 11:29 AM Leo Lara  > wrote:
> 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 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.
> 
> For example, if you want to write a library where the user just reads from a 
> channel, this is an approach I found where the user of the lirbary deos nto 
> have to do anything special. Of course, there might be another solution, but 
> if you need to modify the reader we are talking about a different problem.
> 
> Cheers!!
> 
> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:
> 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-nuts 
> Subject: [go-nuts] Re: An old problem: lack of priority select cases 
> 
> This i

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.

>From the moment itself when such a resource is shared, there must be some
sort of mecanism (that one using resources atomically usable) that ensures
the integrity of it.
Maybe what you're talking about is having it transparent in terms of code,
in which case we both agree, but if you're looking for something
transparent in essence, as in performance, logical construction and all the
rest, I think there is a misunderstanding here: even if it was added in the
language, there would be many many things going on under the hood, as it is
already (and cannot really be otherwise) for channel use alone.

As for the priority using selects, I think it's more of something to be
dealt with on the "user-side". There are many kinds of priority in general,
and trying to implement something in the language itself would IMO either
be too specific compared to the nessecary time to do so or it would
probably have a huge overhead on the "classical' use case of the select
construct.
+ the fact that it is apparently already possible using RWMutexes.

Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz  a
écrit :

> 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 the channel is drained of data.
>
> The producers are managed by something somewhere in your code - and that
> is the scope at which it makes sense to create channel ownership. I've used
> a waitgroup to ensure that the channel is closed after all producers exit,
> but you can use whatever barrier construct you want.
>
> Even if you must have a channel per producer, you can safely close the
> producer side, without notifying the downstream about this. The example
> early in the thread uses multiple channels, with one channel being used to
> signal that the producers should exit. Channels aren't really the right
> model for this, you want a thread safe flag of some sort. For example:
>
> var exitFlag uint64
> func producer(chan data int, wg *sync.WaitGroup) {
> defer wg.Done()
> for {
> shouldExit := atomic.LoadUint64(&exitFlag)
> if shouldExit == 1 {
>  return
> }
> chan <- rand.Intn(100)
> }
> }
>
> Here's 10 producers and 3 consumers sharing a channel and closing it
> safely upon receiving an exit flag:
> https://play.golang.org/p/RiKi1PGVSvF
>
> -- Marcin
>
> On Wed, Aug 28, 2019 at 11:29 AM Leo Lara  wrote:
>
>> 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 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.
>>>
>>> For example, if you want to write a library where the user just reads
>>> from a channel, this is an approach I found where the user of the lirbary
>>> deos nto have to do anything special. Of course, there might be another
>>> solution, but if you need to modify the reader we are talking about a
>>> different problem.
>>>
>>> Cheers!!
>>>
>>> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:

 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-nuts
 Subject: [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 become less efficient.

 On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:
>
> 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"
>
>

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 until the channel is drained of data.

The producers are managed by something somewhere in your code - and that is
the scope at which it makes sense to create channel ownership. I've used a
waitgroup to ensure that the channel is closed after all producers exit,
but you can use whatever barrier construct you want.

Even if you must have a channel per producer, you can safely close the
producer side, without notifying the downstream about this. The example
early in the thread uses multiple channels, with one channel being used to
signal that the producers should exit. Channels aren't really the right
model for this, you want a thread safe flag of some sort. For example:

var exitFlag uint64
func producer(chan data int, wg *sync.WaitGroup) {
defer wg.Done()
for {
shouldExit := atomic.LoadUint64(&exitFlag)
if shouldExit == 1 {
 return
}
chan <- rand.Intn(100)
}
}

Here's 10 producers and 3 consumers sharing a channel and closing it safely
upon receiving an exit flag:
https://play.golang.org/p/RiKi1PGVSvF

-- Marcin

On Wed, Aug 28, 2019 at 11:29 AM Leo Lara  wrote:

> 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 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.
>>
>> For example, if you want to write a library where the user just reads
>> from a channel, this is an approach I found where the user of the lirbary
>> deos nto have to do anything special. Of course, there might be another
>> solution, but if you need to modify the reader we are talking about a
>> different problem.
>>
>> Cheers!!
>>
>> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:
>>>
>>> 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-nuts
>>> Subject: [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 become less efficient.
>>>
>>> On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:

 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 struct{}
 }

 func NewProducer() *Producer {
 p := &Producer {
 data:   make(chan int),
 closed: make(chan struct{}),
 }

 go p.run()

 return p
 }

 func (p *Produce) Stream() chan int {
 return p.data
 }

 func (p *Producer) run() {
 for {
 // If non-blocking cases are selected by their appearance order,
 // then the following slect block is a perfect use.
 select {
 case(0) <-p.closed: return
 case p.data <- rand.Int():
 }
 }
 }

 func (p *Produce) Clsoe() {
 close(p.closed)
 close(p.data)
 }

 func main() {
 p := NewProducer()
 for n := p.Stream() {
 // use n ...
 }
 }

 If the first case in the select block in the above example has a higher
 priority than the second one,
 then coding will be much happier for the use cases like the above one.

 In short, the above use case requires:
 * for receivers, data streaming end is notified by the close of a
 channel.
 * for senders, data will never be sent to closed channel.

 But, as Go 1 doesn't support priority select cases, it is much tedious
 to implement the code
 satisfying the above listed requirements. The final implementation is
 often very ugly and

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 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.Could you show a piece of code for easily understanding?-Original Message-
From: T L 
Sent: Aug 28, 2019 12:37 PM
To: golang-nuts 
Subject: 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. Pretty easy to wrap this in a function that takes N channels.This is not the priority I expected. Could you make an example based on my code in the first comment? so that I can understand it easily.In fact, I have verbose version which doesn't need priority select cases.It is an acceptable solution. But there are many other more complex cases, such as multiple senders.I haven't found an acceptable solution for such complex cases.import "math/rand"type Producer struct {    data chan int    closing  chan struct{}    canSafeClose chan struct{}}func NewProducer() *Producer {    p := &Producer {    data: make(chan int),    closing:  make(chan struct{}),    canSafeClose: make(chan struct{}),    }       go p.run()       return p}func (p *Produce) Stream() chan int {    return p.data}func (p *Producer) run() {    for {    select {    case <-p.closing:        close(p.canSafeClose)        return    default:    }        select {    case <-p.closing:        close(p.canSafeClose)        return    case p.data <- rand.Int():    }    }}func (p *Producer) Close() {    close(p.closed)    <-p.canSafeClose    close(p.data)}func main() {    p := NewProducer()    for n := p.Stream() {    // use n ...    }}-Original Message-
From: T L 
Sent: Aug 28, 2019 11:43 AM
To: golang-nuts 
Subject: 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 this. What I mean is it would be great to support priority select cases.-Original Message-
From: T L 
Sent: Aug 28, 2019 11:06 AM
To: golang-nuts 
Subject: [go-nuts] An old problem: lack of priority select cases

The old thread: https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9oGo 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 struct{}}func NewProducer() *Producer {    p := &Producer {        data:   make(chan int),        closed: make(chan struct{}),    }        go p.run()        return p}func (p *Produce) Stream() chan int {    return p.data}func (p *Producer) run() {    for {        // If non-blocking cases are selected by their appearance order,        // then the following slect block is a perfect use.        select {        case(0) <-p.closed: return        case p.data <- rand.Int():        }    }}func (p *Produce) Clsoe() {    close(p.closed)    close(p.data)}func main() {    p := NewProducer()    for n := p.Stream() {        // use n ...    }}If the first case in the select block in the above example has a higher priority than the second one,then coding will be much happier for the use cases like the above one.In short, the above use case requires:* for receivers, data streaming end is notified by the close of a channel.* for senders, data will never be sent to closed channel.But, as Go 1 doesn't support priority select cases, it is much tedious to implement the codesatisfying the above listed requirements. The final implementation is often very ugly and inefficient.Does anyone else also experience the pain?

-- 
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 golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com.

-- 
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 golan...@googlegroups.com.
To vie

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 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.
>
> For example, if you want to write a library where the user just reads from 
> a channel, this is an approach I found where the user of the lirbary deos 
> nto have to do anything special. Of course, there might be another 
> solution, but if you need to modify the reader we are talking about a 
> different problem.
>
> Cheers!!
>
> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:
>>
>> 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-nuts 
>> Subject: [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 become less efficient.
>>
>> On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:
>>>
>>> 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 struct{}
>>> }
>>>
>>> func NewProducer() *Producer {
>>> p := &Producer {
>>> data:   make(chan int),
>>> closed: make(chan struct{}),
>>> }
>>> 
>>> go p.run()
>>> 
>>> return p
>>> }
>>>
>>> func (p *Produce) Stream() chan int {
>>> return p.data
>>> }
>>>
>>> func (p *Producer) run() {
>>> for {
>>> // If non-blocking cases are selected by their appearance order,
>>> // then the following slect block is a perfect use.
>>> select {
>>> case(0) <-p.closed: return
>>> case p.data <- rand.Int():
>>> }
>>> }
>>> }
>>>
>>> func (p *Produce) Clsoe() {
>>> close(p.closed)
>>> close(p.data)
>>> }
>>>
>>> func main() {
>>> p := NewProducer()
>>> for n := p.Stream() {
>>> // use n ...
>>> }
>>> }
>>>
>>>
>>> If the first case in the select block in the above example has a higher 
>>> priority than the second one,
>>> then coding will be much happier for the use cases like the above one.
>>>
>>> In short, the above use case requires:
>>> * for receivers, data streaming end is notified by the close of a 
>>> channel.
>>> * for senders, data will never be sent to closed channel.
>>>
>>> But, as Go 1 doesn't support priority select cases, it is much tedious 
>>> to implement the code
>>> satisfying the above listed requirements. The final implementation is 
>>> often very ugly and inefficient.
>>>
>>> Does anyone else also experience the pain?
>>>
>> -- 
>> 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 golan...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/b284f880-034a-4721-8686-ef48d3e2c14c%40googlegroups.com
>>  
>> 
>> .
>>
>>
>>
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/aeb38a0a-8268-42d7-a8eb-ce5ef01c5380%40googlegroups.com.

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.

For example, if you want to write a library where the user just reads from 
a channel, this is an approach I found where the user of the lirbary deos 
nto have to do anything special. Of course, there might be another 
solution, but if you need to modify the reader we are talking about a 
different problem.

Cheers!!

On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:
>
> 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-nuts 
> Subject: [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 become less efficient.
>
> On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:
>>
>> 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 struct{}
>> }
>>
>> func NewProducer() *Producer {
>> p := &Producer {
>> data:   make(chan int),
>> closed: make(chan struct{}),
>> }
>> 
>> go p.run()
>> 
>> return p
>> }
>>
>> func (p *Produce) Stream() chan int {
>> return p.data
>> }
>>
>> func (p *Producer) run() {
>> for {
>> // If non-blocking cases are selected by their appearance order,
>> // then the following slect block is a perfect use.
>> select {
>> case(0) <-p.closed: return
>> case p.data <- rand.Int():
>> }
>> }
>> }
>>
>> func (p *Produce) Clsoe() {
>> close(p.closed)
>> close(p.data)
>> }
>>
>> func main() {
>> p := NewProducer()
>> for n := p.Stream() {
>> // use n ...
>> }
>> }
>>
>>
>> If the first case in the select block in the above example has a higher 
>> priority than the second one,
>> then coding will be much happier for the use cases like the above one.
>>
>> In short, the above use case requires:
>> * for receivers, data streaming end is notified by the close of a channel.
>> * for senders, data will never be sent to closed channel.
>>
>> But, as Go 1 doesn't support priority select cases, it is much tedious to 
>> implement the code
>> satisfying the above listed requirements. The final implementation is 
>> often very ugly and inefficient.
>>
>> Does anyone else also experience the pain?
>>
> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/b284f880-034a-4721-8686-ef48d3e2c14c%40googlegroups.com
>  
> 
> .
>
>
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/405013db-74c9-474b-857c-09d3f30030c1%40googlegroups.com.

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 during 
> the write.
>

Could you show a piece of code for easily understanding?

>
> -Original Message- 
> From: T L 
> Sent: Aug 28, 2019 12:37 PM 
> To: golang-nuts 
> Subject: 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. Pretty easy to wrap this in a function 
>> that takes N channels.
>>
>
> This is not the priority I expected. Could you make an example based on my 
> code in the first comment? so that I can understand it easily.
> In fact, I have verbose version which doesn't need priority select cases.
> It is an acceptable solution. But there are many other more complex cases, 
> such as multiple senders.
> I haven't found an acceptable solution for such complex cases.
>
> import "math/rand"
>
> type Producer struct {
> data chan int
> closing  chan struct{}
> canSafeClose chan struct{}
> }
>
> func NewProducer() *Producer {
> p := &Producer {
> data: make(chan int),
> closing:  make(chan struct{}),
> canSafeClose: make(chan struct{}),
> }
>
> go p.run()
>
> return p
> }
>
> func (p *Produce) Stream() chan int {
> return p.data
> }
>
> func (p *Producer) run() {
> for {
> select {
> case <-p.closing:
> close(p.canSafeClose)
> return
> default:
> }
> 
> select {
> case <-p.closing:
> close(p.canSafeClose)
> return
> case p.data <- rand.Int():
> }
> }
> }
>
> func (p *Producer) Close() {
> close(p.closed)
> <-p.canSafeClose
> close(p.data)
> }
>
> func main() {
> p := NewProducer()
> for n := p.Stream() {
> // use n ...
> }
> }
>
>
>> -Original Message- 
>> From: T L 
>> Sent: Aug 28, 2019 11:43 AM 
>> To: golang-nuts 
>> Subject: 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 this. What I mean is it would be great to support priority 
>> select cases.
>>
>>>
>>> -Original Message- 
>>> From: T L 
>>> Sent: Aug 28, 2019 11:06 AM 
>>> To: golang-nuts 
>>> Subject: [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 struct{}
>>> }
>>>
>>> func NewProducer() *Producer {
>>> p := &Producer {
>>> data:   make(chan int),
>>> closed: make(chan struct{}),
>>> }
>>> 
>>> go p.run()
>>> 
>>> return p
>>> }
>>>
>>> func (p *Produce) Stream() chan int {
>>> return p.data
>>> }
>>>
>>> func (p *Producer) run() {
>>> for {
>>> // If non-blocking cases are selected by their appearance order,
>>> // then the following slect block is a perfect use.
>>> select {
>>> case(0) <-p.closed: return
>>> case p.data <- rand.Int():
>>> }
>>> }
>>> }
>>>
>>> func (p *Produce) Clsoe() {
>>> close(p.closed)
>>> close(p.data)
>>> }
>>>
>>> func main() {
>>> p := NewProducer()
>>> for n := p.Stream() {
>>> // use n ...
>>> }
>>> }
>>>
>>>
>>> If the first case in the select block in the above example has a higher 
>>> priority than the second one,
>>> then coding will be much happier for the use cases like the above one.
>>>
>>> In short, the above use case requires:
>>> * for receivers, data streaming end is notified by the close of a 
>>> channel.
>>> * for senders, data will never be sent to closed channel.
>>>
>>> But, as Go 1 doesn't support priority select cases, it is much tedious 
>>> to implement the code
>>> satisfying the above listed requirements. The final implementation is 
>>> often very ugly and inefficient.
>>>
>>> Does anyone else also experience the pain?
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>

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: golang-nuts 
Subject: 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. Pretty easy to wrap this in a function that takes N channels.This is not the priority I expected. Could you make an example based on my code in the first comment? so that I can understand it easily.In fact, I have verbose version which doesn't need priority select cases.It is an acceptable solution. But there are many other more complex cases, such as multiple senders.I haven't found an acceptable solution for such complex cases.import "math/rand"type Producer struct {    data chan int    closing  chan struct{}    canSafeClose chan struct{}}func NewProducer() *Producer {    p := &Producer {    data: make(chan int),    closing:  make(chan struct{}),    canSafeClose: make(chan struct{}),    }       go p.run()       return p}func (p *Produce) Stream() chan int {    return p.data}func (p *Producer) run() {    for {    select {    case <-p.closing:        close(p.canSafeClose)        return    default:    }        select {    case <-p.closing:        close(p.canSafeClose)        return    case p.data <- rand.Int():    }    }}func (p *Producer) Close() {    close(p.closed)    <-p.canSafeClose    close(p.data)}func main() {    p := NewProducer()    for n := p.Stream() {    // use n ...    }}-Original Message-
From: T L 
Sent: Aug 28, 2019 11:43 AM
To: golang-nuts 
Subject: 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 this. What I mean is it would be great to support priority select cases.-Original Message-
From: T L 
Sent: Aug 28, 2019 11:06 AM
To: golang-nuts 
Subject: [go-nuts] An old problem: lack of priority select cases

The old thread: https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9oGo 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 struct{}}func NewProducer() *Producer {    p := &Producer {        data:   make(chan int),        closed: make(chan struct{}),    }        go p.run()        return p}func (p *Produce) Stream() chan int {    return p.data}func (p *Producer) run() {    for {        // If non-blocking cases are selected by their appearance order,        // then the following slect block is a perfect use.        select {        case(0) <-p.closed: return        case p.data <- rand.Int():        }    }}func (p *Produce) Clsoe() {    close(p.closed)    close(p.data)}func main() {    p := NewProducer()    for n := p.Stream() {        // use n ...    }}If the first case in the select block in the above example has a higher priority than the second one,then coding will be much happier for the use cases like the above one.In short, the above use case requires:* for receivers, data streaming end is notified by the close of a channel.* for senders, data will never be sent to closed channel.But, as Go 1 doesn't support priority select cases, it is much tedious to implement the codesatisfying the above listed requirements. The final implementation is often very ugly and inefficient.Does anyone else also experience the pain?

-- 
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 golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com.

-- 
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 golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0f753567-eaa8-4d1d-9db1-a3f382f59216%40googlegroups.com.

-- 
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

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. Pretty easy to wrap this in a function 
> that takes N channels.
>

This is not the priority I expected. Could you make an example based on my 
code in the first comment? so that I can understand it easily.
In fact, I have verbose version which doesn't need priority select cases.
It is an acceptable solution. But there are many other more complex cases, 
such as multiple senders.
I haven't found an acceptable solution for such complex cases.

import "math/rand"

type Producer struct {
data chan int
closing  chan struct{}
canSafeClose chan struct{}
}

func NewProducer() *Producer {
p := &Producer {
data: make(chan int),
closing:  make(chan struct{}),
canSafeClose: make(chan struct{}),
}
   
go p.run()
   
return p
}

func (p *Produce) Stream() chan int {
return p.data
}

func (p *Producer) run() {
for {
select {
case <-p.closing:
close(p.canSafeClose)
return
default:
}

select {
case <-p.closing:
close(p.canSafeClose)
return
case p.data <- rand.Int():
}
}
}

func (p *Producer) Close() {
close(p.closed)
<-p.canSafeClose
close(p.data)
}

func main() {
p := NewProducer()
for n := p.Stream() {
// use n ...
}
}


> -Original Message- 
> From: T L 
> Sent: Aug 28, 2019 11:43 AM 
> To: golang-nuts 
> Subject: 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 this. What I mean is it would be great to support priority 
> select cases.
>
>>
>> -Original Message- 
>> From: T L 
>> Sent: Aug 28, 2019 11:06 AM 
>> To: golang-nuts 
>> Subject: [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 struct{}
>> }
>>
>> func NewProducer() *Producer {
>> p := &Producer {
>> data:   make(chan int),
>> closed: make(chan struct{}),
>> }
>> 
>> go p.run()
>> 
>> return p
>> }
>>
>> func (p *Produce) Stream() chan int {
>> return p.data
>> }
>>
>> func (p *Producer) run() {
>> for {
>> // If non-blocking cases are selected by their appearance order,
>> // then the following slect block is a perfect use.
>> select {
>> case(0) <-p.closed: return
>> case p.data <- rand.Int():
>> }
>> }
>> }
>>
>> func (p *Produce) Clsoe() {
>> close(p.closed)
>> close(p.data)
>> }
>>
>> func main() {
>> p := NewProducer()
>> for n := p.Stream() {
>> // use n ...
>> }
>> }
>>
>>
>> If the first case in the select block in the above example has a higher 
>> priority than the second one,
>> then coding will be much happier for the use cases like the above one.
>>
>> In short, the above use case requires:
>> * for receivers, data streaming end is notified by the close of a channel.
>> * for senders, data will never be sent to closed channel.
>>
>> But, as Go 1 doesn't support priority select cases, it is much tedious to 
>> implement the code
>> satisfying the above listed requirements. The final implementation is 
>> often very ugly and inefficient.
>>
>> Does anyone else also experience the pain?
>>
>> -- 
>> 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 golan...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com
>>  
>> 
>> .
>>
>>
>>
>>
>> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/

[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, the code would be simple with priority 
> select, but also perhaps select would become less efficient.
>

Aha, multiple writers, which will be much more complex (if priority select 
cases are not supported).
 

>
> On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:
>>
>> 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 struct{}
>> }
>>
>> func NewProducer() *Producer {
>> p := &Producer {
>> data:   make(chan int),
>> closed: make(chan struct{}),
>> }
>> 
>> go p.run()
>> 
>> return p
>> }
>>
>> func (p *Produce) Stream() chan int {
>> return p.data
>> }
>>
>> func (p *Producer) run() {
>> for {
>> // If non-blocking cases are selected by their appearance order,
>> // then the following slect block is a perfect use.
>> select {
>> case(0) <-p.closed: return
>> case p.data <- rand.Int():
>> }
>> }
>> }
>>
>> func (p *Produce) Clsoe() {
>> close(p.closed)
>> close(p.data)
>> }
>>
>> func main() {
>> p := NewProducer()
>> for n := p.Stream() {
>> // use n ...
>> }
>> }
>>
>>
>> If the first case in the select block in the above example has a higher 
>> priority than the second one,
>> then coding will be much happier for the use cases like the above one.
>>
>> In short, the above use case requires:
>> * for receivers, data streaming end is notified by the close of a channel.
>> * for senders, data will never be sent to closed channel.
>>
>> But, as Go 1 doesn't support priority select cases, it is much tedious to 
>> implement the code
>> satisfying the above listed requirements. The final implementation is 
>> often very ugly and inefficient.
>>
>> Does anyone else also experience the pain?
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/104a1a10-9b16-4a1b-9526-139f103ea518%40googlegroups.com.

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.
 

>
> -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 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 become less efficient.
>
> On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:
>>
>> 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 struct{}
>> }
>>
>> func NewProducer() *Producer {
>> p := &Producer {
>> data:   make(chan int),
>> closed: make(chan struct{}),
>> }
>> 
>> go p.run()
>> 
>> return p
>> }
>>
>> func (p *Produce) Stream() chan int {
>> return p.data
>> }
>>
>> func (p *Producer) run() {
>> for {
>> // If non-blocking cases are selected by their appearance order,
>> // then the following slect block is a perfect use.
>> select {
>> case(0) <-p.closed: return
>> case p.data <- rand.Int():
>> }
>> }
>> }
>>
>> func (p *Produce) Clsoe() {
>> close(p.closed)
>> close(p.data)
>> }
>>
>> func main() {
>> p := NewProducer()
>> for n := p.Stream() {
>> // use n ...
>> }
>> }
>>
>>
>> If the first case in the select block in the above example has a higher 
>> priority than the second one,
>> then coding will be much happier for the use cases like the above one.
>>
>> In short, the above use case requires:
>> * for receivers, data streaming end is notified by the close of a channel.
>> * for senders, data will never be sent to closed channel.
>>
>> But, as Go 1 doesn't support priority select cases, it is much tedious to 
>> implement the code
>> satisfying the above listed requirements. The final implementation is 
>> often very ugly and inefficient.
>>
>> Does anyone else also experience the pain?
>>
> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/b284f880-034a-4721-8686-ef48d3e2c14c%40googlegroups.com
>  
> 
> .
>
>
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f6c8e515-525e-4f3c-b384-70e510b687d5%40googlegroups.com.

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-nuts 
Subject: [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-52j2I 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 become less efficient.On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:The old thread: https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9oGo 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 struct{}}func NewProducer() *Producer {    p := &Producer {        data:   make(chan int),        closed: make(chan struct{}),    }        go p.run()        return p}func (p *Produce) Stream() chan int {    return p.data}func (p *Producer) run() {    for {        // If non-blocking cases are selected by their appearance order,        // then the following slect block is a perfect use.        select {        case(0) <-p.closed: return        case p.data <- rand.Int():        }    }}func (p *Produce) Clsoe() {    close(p.closed)    close(p.data)}func main() {    p := NewProducer()    for n := p.Stream() {        // use n ...    }}If the first case in the select block in the above example has a higher priority than the second one,then coding will be much happier for the use cases like the above one.In short, the above use case requires:* for receivers, data streaming end is notified by the close of a channel.* for senders, data will never be sent to closed channel.But, as Go 1 doesn't support priority select cases, it is much tedious to implement the codesatisfying the above listed requirements. The final implementation is often very ugly and inefficient.Does anyone else also experience the pain?

-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b284f880-034a-4721-8686-ef48d3e2c14c%40googlegroups.com.

-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/76267041.5448.1567012615707%40wamui-bison.atl.sa.earthlink.net.

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 select cases

This is connected with my article: https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2I 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 become less efficient.On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:The old thread: https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9oGo 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 struct{}}func NewProducer() *Producer {    p := &Producer {        data:   make(chan int),        closed: make(chan struct{}),    }        go p.run()        return p}func (p *Produce) Stream() chan int {    return p.data}func (p *Producer) run() {    for {        // If non-blocking cases are selected by their appearance order,        // then the following slect block is a perfect use.        select {        case(0) <-p.closed: return        case p.data <- rand.Int():        }    }}func (p *Produce) Clsoe() {    close(p.closed)    close(p.data)}func main() {    p := NewProducer()    for n := p.Stream() {        // use n ...    }}If the first case in the select block in the above example has a higher priority than the second one,then coding will be much happier for the use cases like the above one.In short, the above use case requires:* for receivers, data streaming end is notified by the close of a channel.* for senders, data will never be sent to closed channel.But, as Go 1 doesn't support priority select cases, it is much tedious to implement the codesatisfying the above listed requirements. The final implementation is often very ugly and inefficient.Does anyone else also experience the pain?

-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b284f880-034a-4721-8686-ef48d3e2c14c%40googlegroups.com.

-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1729188189.5384.1567012429475%40wamui-bison.atl.sa.earthlink.net.

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-
From: T L 
Sent: Aug 28, 2019 11:43 AM
To: golang-nuts 
Subject: 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 this. What I mean is it would be great to support priority select cases.-Original Message-
From: T L 
Sent: Aug 28, 2019 11:06 AM
To: golang-nuts 
Subject: [go-nuts] An old problem: lack of priority select cases

The old thread: https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9oGo 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 struct{}}func NewProducer() *Producer {    p := &Producer {        data:   make(chan int),        closed: make(chan struct{}),    }        go p.run()        return p}func (p *Produce) Stream() chan int {    return p.data}func (p *Producer) run() {    for {        // If non-blocking cases are selected by their appearance order,        // then the following slect block is a perfect use.        select {        case(0) <-p.closed: return        case p.data <- rand.Int():        }    }}func (p *Produce) Clsoe() {    close(p.closed)    close(p.data)}func main() {    p := NewProducer()    for n := p.Stream() {        // use n ...    }}If the first case in the select block in the above example has a higher priority than the second one,then coding will be much happier for the use cases like the above one.In short, the above use case requires:* for receivers, data streaming end is notified by the close of a channel.* for senders, data will never be sent to closed channel.But, as Go 1 doesn't support priority select cases, it is much tedious to implement the codesatisfying the above listed requirements. The final implementation is often very ugly and inefficient.Does anyone else also experience the pain?

-- 
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 golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com.

-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0f753567-eaa8-4d1d-9db1-a3f382f59216%40googlegroups.com.

-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1979231886.5340.1567012298824%40wamui-bison.atl.sa.earthlink.net.

[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 become less efficient.

On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:
>
> 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 struct{}
> }
>
> func NewProducer() *Producer {
> p := &Producer {
> data:   make(chan int),
> closed: make(chan struct{}),
> }
> 
> go p.run()
> 
> return p
> }
>
> func (p *Produce) Stream() chan int {
> return p.data
> }
>
> func (p *Producer) run() {
> for {
> // If non-blocking cases are selected by their appearance order,
> // then the following slect block is a perfect use.
> select {
> case(0) <-p.closed: return
> case p.data <- rand.Int():
> }
> }
> }
>
> func (p *Produce) Clsoe() {
> close(p.closed)
> close(p.data)
> }
>
> func main() {
> p := NewProducer()
> for n := p.Stream() {
> // use n ...
> }
> }
>
>
> If the first case in the select block in the above example has a higher 
> priority than the second one,
> then coding will be much happier for the use cases like the above one.
>
> In short, the above use case requires:
> * for receivers, data streaming end is notified by the close of a channel.
> * for senders, data will never be sent to closed channel.
>
> But, as Go 1 doesn't support priority select cases, it is much tedious to 
> implement the code
> satisfying the above listed requirements. The final implementation is 
> often very ugly and inefficient.
>
> Does anyone else also experience the pain?
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b284f880-034a-4721-8686-ef48d3e2c14c%40googlegroups.com.

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 this. What I mean is it would be great to support priority 
select cases.

>
> -Original Message- 
> From: T L 
> Sent: Aug 28, 2019 11:06 AM 
> To: golang-nuts 
> Subject: [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 struct{}
> }
>
> func NewProducer() *Producer {
> p := &Producer {
> data:   make(chan int),
> closed: make(chan struct{}),
> }
> 
> go p.run()
> 
> return p
> }
>
> func (p *Produce) Stream() chan int {
> return p.data
> }
>
> func (p *Producer) run() {
> for {
> // If non-blocking cases are selected by their appearance order,
> // then the following slect block is a perfect use.
> select {
> case(0) <-p.closed: return
> case p.data <- rand.Int():
> }
> }
> }
>
> func (p *Produce) Clsoe() {
> close(p.closed)
> close(p.data)
> }
>
> func main() {
> p := NewProducer()
> for n := p.Stream() {
> // use n ...
> }
> }
>
>
> If the first case in the select block in the above example has a higher 
> priority than the second one,
> then coding will be much happier for the use cases like the above one.
>
> In short, the above use case requires:
> * for receivers, data streaming end is notified by the close of a channel.
> * for senders, data will never be sent to closed channel.
>
> But, as Go 1 doesn't support priority select cases, it is much tedious to 
> implement the code
> satisfying the above listed requirements. The final implementation is 
> often very ugly and inefficient.
>
> Does anyone else also experience the pain?
>
> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com
>  
> 
> .
>
>
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0f753567-eaa8-4d1d-9db1-a3f382f59216%40googlegroups.com.

[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*. 
>
> GolangVersion :- *go1.11.5 windows/amd64* 
>
> Please let me know how to get Golang mobile tools to work
>
>
> PS C:\Go> go get golang.org/x/mobile/cmd/gomobile
> PS C:\Go> gomobile init
> gomobile : The term 'gomobile' is not recognized as the name of a cmdlet, 
> function, script file, or operable program. Check the spelling of the name
> , or if a path was included, verify that the path is correct and try again
> . At line:1 char:2 + gomobile init +  + CategoryInfo : 
> ObjectNotFound: (gomobile:String) [], CommandNotFoundException + 
> FullyQualifiedErrorId : CommandNotFoundException
> PS C:\Go> gomobile version
> gomobile : The term 'gomobile' is not recognized as the name of a cmdlet, 
> function, script file, or operable program. Check the spelling of the name
> , or if a path was included, verify that the path is correct and try again
> . At line:1 char:1 + gomobile version +  + CategoryInfo : 
> ObjectNotFound: (gomobile:String) [], CommandNotFoundException + 
> FullyQualifiedErrorId : CommandNotFoundException
> PS C:\Go> go version 
> go version go1.11.5 windows/amd64
>
> *ANSWER *- On reinstalling the latest Golang version [1.12.9 
windows/amd64] and reconfiguring the Environment path's ,'GoMobile tools' 
is now recognised,
Gomobile tools was installed in the GOPATH directory and there was no need 
to  add it  to  the PATH environment variables.
 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5a0bf2db-8431-4d36-87b5-c3c9ec5620b9%40googlegroups.com.

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 old problem: lack of priority select cases

The old thread: https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9oGo 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 struct{}}func NewProducer() *Producer {    p := &Producer {        data:   make(chan int),        closed: make(chan struct{}),    }        go p.run()        return p}func (p *Produce) Stream() chan int {    return p.data}func (p *Producer) run() {    for {        // If non-blocking cases are selected by their appearance order,        // then the following slect block is a perfect use.        select {        case(0) <-p.closed: return        case p.data <- rand.Int():        }    }}func (p *Produce) Clsoe() {    close(p.closed)    close(p.data)}func main() {    p := NewProducer()    for n := p.Stream() {        // use n ...    }}If the first case in the select block in the above example has a higher priority than the second one,then coding will be much happier for the use cases like the above one.In short, the above use case requires:* for receivers, data streaming end is notified by the close of a channel.* for senders, data will never be sent to closed channel.But, as Go 1 doesn't support priority select cases, it is much tedious to implement the codesatisfying the above listed requirements. The final implementation is often very ugly and inefficient.Does anyone else also experience the pain?

-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com.

-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1664469656.4611.1567010186688%40wamui-bison.atl.sa.earthlink.net.

[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 struct{}
}

func NewProducer() *Producer {
p := &Producer {
data:   make(chan int),
closed: make(chan struct{}),
}

go p.run()

return p
}

func (p *Produce) Stream() chan int {
return p.data
}

func (p *Producer) run() {
for {
// If non-blocking cases are selected by their appearance order,
// then the following slect block is a perfect use.
select {
case(0) <-p.closed: return
case p.data <- rand.Int():
}
}
}

func (p *Produce) Clsoe() {
close(p.closed)
close(p.data)
}

func main() {
p := NewProducer()
for n := p.Stream() {
// use n ...
}
}


If the first case in the select block in the above example has a higher 
priority than the second one,
then coding will be much happier for the use cases like the above one.

In short, the above use case requires:
* for receivers, data streaming end is notified by the close of a channel.
* for senders, data will never be sent to closed channel.

But, as Go 1 doesn't support priority select cases, it is much tedious to 
implement the code
satisfying the above listed requirements. The final implementation is often 
very ugly and inefficient.

Does anyone else also experience the pain?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com.

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 current implementation of Go's garbage collector runs
concurrently with the program, it's hard to give useful answers to
these questions.

There is some background on the garbage collector at
https://blog.golang.org/ismmkeynote .

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVX9zUpPL-TX2Y9hkbbTtC%2BzT%3D5xYRnb0DO8Vhdg_1yzg%40mail.gmail.com.

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 
> project), it throw error like cannot use packages ... from different roots, i 
> want to ask if i do something wrong, or it can't support well with 1.12?

Using -buildmode=archive or -buildmode=shared isn't a way to step
around the restrictions on binary packages.  Now that support for
binary packages has been removed, the "go build" process inherently
expects to be able to see the source code of a package.

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWMUSGK_WYb9nS_mpBPDAxoduoNKcN%3DeHBmCmsO42-hQg%40mail.gmail.com.

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 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.
>>
>> Thanks.
>>
>>
>> On Wed, Aug 28, 2019 at 4:45 PM Martin Schnabel  wrote:
>>
>>> 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 guess. Here is another one:
>>> Go has raw string literals using back-ticks `like this` those literals
>>> do not use escape sequences (`\n` == "\\n" && `\\` == ""). Could it
>>> be, that you accidentally used those raw string literals in the producer
>>> code with the newline escape sequence that is not supported?
>>>
>>>
>>>
>>> On 28.08.19 12:32, Durga Someswararao G wrote:
>>> > 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 <
>>> m.levi...@capitaldata.fr
>>> > > wrote:
>>> >
>>> > 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
>>> > >> > > a écrit :
>>> >
>>> > 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","'@_@_@'",-1)
>>> >
>>> > On Wed, Aug 28, 2019 at 3:26 PM Tamás Gulácsi
>>> > mailto:tgulacs...@gmail.com>> wrote:
>>> >
>>> > 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 receiving emails
>>> > from it, send an email to
>>> > golang-nuts+unsubscr...@googlegroups.com
>>> > .
>>> > To view this discussion on the web visit
>>> >
>>> https://groups.google.com/d/msgid/golang-nuts/865188f0-405e-45ee-82b9-7f6d24f1d49f%40googlegroups.com
>>> .
>>> >
>>> > --
>>> > 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
>>> > .
>>> > To view this discussion on the web visit
>>> >
>>> https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGr83pA%2Bvrkg-bYkOs-qjsqxkOgEjoGTmigtJsr0hO287w%40mail.gmail.com
>>> > <
>>> https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGr83pA%2Bvrkg-bYkOs-qjsqxkOgEjoGTmigtJsr0hO287w%40mail.gmail.com?utm_medium=email&utm_source=footer
>>> >.
>>> >
>>> > --
>>> > 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
>>> > .
>>> > To view this discussion on the web visit
>>> >
>>> https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGrM47a%3Dj6Zbk1caY46FYUG7fXC2J0z0QvoJtSp69b6NCQ%40mail.gmail.com
>>> > <
>>> https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGrM47a%3Dj6Zbk1caY46FYUG7fXC2J0z0QvoJtSp69b6NCQ%40mail.gmail.com?utm_medium=email&utm_source=footer
>>> >.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubs

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. 


/Klaus

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f17da08c-8a1f-405f-b3ca-ec1a995fd5f3%40googlegroups.com.

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.
>>
>
> That requirement is documented here:
> https://golang.org/cmd/go/#hdr-Build_modes
>
>
>> 在 2016年5月18日星期三 UTC+8上午11:11:57，Justin Israel写道：
>>>
>>> I'm wondering if someone can tell me if this is either a limitation of 
>>> buildmode=c-archive static libs, or if I am really just doing something 
>>> wrong.
>>>
>>> Problematic steps:
>>>
>>>1. export functions to  libgofoo.a using buildmode=c-archive
>>>2. statically link libgofoo.a into another library to produce 
>>>libfoo.a
>>>3. Someone else consumes libfoo.a and libgofoo.a in their library, 
>>>and get linker errors about:
>>>ld: libgofoo.a(go.o): relocation R_X86_64_TPOFF32 against 
>>>`runtime.tlsg` can not be used when making a shared object; recompile 
>>> with 
>>>-fPIC
>>>libgofoo.a: could not read symbols: Bad value
>>>
>>> But library that wants to consume these libs can do so if they 
>>> dynamically link with shared libs from c-shared. Also, if the consumer 
>>> of the libs is a main binary, then the static linking works and does not 
>>> complain. It is only when the target is a library.
>>>
>>> I could swear I went through and ensured -fPIC was being used, but it 
>>> didn't seem to make a difference. Am I infact just messing up my 
>>> compilation settings and failing to add this flag as it suggests, or is 
>>> there a known limitation related to the steps I have outlined?
>>>
>>> Thanks!
>>> Justin
>>>
>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/EhndTzcPJxQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/2032198a-00dd-40a8-a8aa-489e9ae406bf%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/908b8c77-5315-4806-b9a9-dc89cdba8902%40googlegroups.com.

[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 ... from different roots 
, i want to ask if i do 
something wrong, or it can't support well with 1.12? 

thanks a lot.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9ecf1d28-2e91-42f8-b6d4-0a9d0b64e29e%40googlegroups.com.

[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 Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/88fabca9-9307-4fad-ae80-fee144874b21%40googlegroups.com.

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 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.
>
> Thanks.
>
>
> On Wed, Aug 28, 2019 at 4:45 PM Martin Schnabel  wrote:
>
>> 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 guess. Here is another one:
>> Go has raw string literals using back-ticks `like this` those literals
>> do not use escape sequences (`\n` == "\\n" && `\\` == ""). Could it
>> be, that you accidentally used those raw string literals in the producer
>> code with the newline escape sequence that is not supported?
>>
>>
>>
>> On 28.08.19 12:32, Durga Someswararao G wrote:
>> > 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 <
>> m.levi...@capitaldata.fr
>> > > wrote:
>> >
>> > 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
>> > > > > a écrit :
>> >
>> > 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","'@_@_@'",-1)
>> >
>> > On Wed, Aug 28, 2019 at 3:26 PM Tamás Gulácsi
>> > mailto:tgulacs...@gmail.com>> wrote:
>> >
>> > 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 receiving emails
>> > from it, send an email to
>> > golang-nuts+unsubscr...@googlegroups.com
>> > .
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/golang-nuts/865188f0-405e-45ee-82b9-7f6d24f1d49f%40googlegroups.com
>> .
>> >
>> > --
>> > 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
>> > .
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGr83pA%2Bvrkg-bYkOs-qjsqxkOgEjoGTmigtJsr0hO287w%40mail.gmail.com
>> > <
>> https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGr83pA%2Bvrkg-bYkOs-qjsqxkOgEjoGTmigtJsr0hO287w%40mail.gmail.com?utm_medium=email&utm_source=footer
>> >.
>> >
>> > --
>> > 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
>> > .
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGrM47a%3Dj6Zbk1caY46FYUG7fXC2J0z0QvoJtSp69b6NCQ%40mail.gmail.com
>> > <
>> https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGrM47a%3Dj6Zbk1caY46FYUG7fXC2J0z0QvoJtSp69b6NCQ%40mail.gmail.com?utm_medium=email&utm_source=footer
>> >.
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid

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 is that you call a string quote function
like strconv.Quote either directly or indirectly on the producer side.

The following playground link demonstrates some ways you could arrive
at a quoted string. https://play.golang.org/p/-QRz7x00Shn

However, then you would also see double quotes enclosing the quoted text
in your output.

To summarize: we found out that your problem has nothing to do with
strings.Replace, but instead with the way your producer writes its
output. We have two general ideas how this could be the case but
can only help you find the issue if you share reproducible examples.

On 28.08.19 13:15, Martin Schnabel wrote:

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 guess. Here is another one:
Go has raw string literals using back-ticks `like this` those literals
do not use escape sequences (`\n` == "\\n" && `\\` == ""). Could it
be, that you accidentally used those raw string literals in the producer
code with the newline escape sequence that is not supported?

On 28.08.19 12:32, Durga Someswararao G wrote:

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
mailto:m.levi...@capitaldata.fr>> wrote:

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
mailto:durgasomeswararao...@gmail.com>> a écrit :

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","'@_@_@'",-1)

On Wed, Aug 28, 2019 at 3:26 PM Tamás Gulácsi
mailto:tgulacs...@gmail.com>> wrote:

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 receiving emails
from it, send an email to
golang-nuts+unsubscr...@googlegroups.com
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/golang-nuts/865188f0-405e-45ee-82b9-7f6d24f1d49f%40googlegroups.com.

-- 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
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGr83pA%2Bvrkg-bYkOs-qjsqxkOgEjoGTmigtJsr0hO287w%40mail.gmail.com

--
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
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGrM47a%3Dj6Zbk1caY46FYUG7fXC2J0z0QvoJtSp69b6NCQ%40mail.gmail.com
.

--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/e9b

[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 somebody pleas let me know what statements to add, as 
> every thing to date hasn't worked. 
> Thank you
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c978a0c1-5097-4278-9b01-27ee8937db9f%40googlegroups.com.

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.

Thanks.


On Wed, Aug 28, 2019 at 4:45 PM Martin Schnabel  wrote:

> 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 guess. Here is another one:
> Go has raw string literals using back-ticks `like this` those literals
> do not use escape sequences (`\n` == "\\n" && `\\` == ""). Could it
> be, that you accidentally used those raw string literals in the producer
> code with the newline escape sequence that is not supported?
>
>
>
> On 28.08.19 12:32, Durga Someswararao G wrote:
> > 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
> > 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
> >  > > a écrit :
> >
> > 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","'@_@_@'",-1)
> >
> > On Wed, Aug 28, 2019 at 3:26 PM Tamás Gulácsi
> > mailto:tgulacs...@gmail.com>> wrote:
> >
> > 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 receiving emails
> > from it, send an email to
> > golang-nuts+unsubscr...@googlegroups.com
> > .
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/golang-nuts/865188f0-405e-45ee-82b9-7f6d24f1d49f%40googlegroups.com
> .
> >
> > --
> > 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
> > .
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGr83pA%2Bvrkg-bYkOs-qjsqxkOgEjoGTmigtJsr0hO287w%40mail.gmail.com
> > <
> https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGr83pA%2Bvrkg-bYkOs-qjsqxkOgEjoGTmigtJsr0hO287w%40mail.gmail.com?utm_medium=email&utm_source=footer
> >.
> >
> > --
> > 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
> > .
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGrM47a%3Dj6Zbk1caY46FYUG7fXC2J0z0QvoJtSp69b6NCQ%40mail.gmail.com
> > <
> https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGrM47a%3Dj6Zbk1caY46FYUG7fXC2J0z0QvoJtSp69b6NCQ%40mail.gmail.com?utm_medium=email&utm_source=footer
> >.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/2c202a4b-1db1-2247-d374-814f66c81b0c%40mb0.org
> .
>

-- 
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.
To view this discussi

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 compression ratio, worse throughput) or "betterSpeed / 
> faster", otherwise it's not immediately obvious on which axis "better" 
> is better in. (Or if it's better in both axes, why not just always 
> turn it on). 
>
>
> Also, from 
> https://github.com/klauspost/compress/tree/master/s2#format-extensions: 
> > Format Extensions 
> > ... 
> > Framed compressed blocks can be up to 4MB (up from 64KB). 
>
> Do you know how much of the size or speed gains come from bumping 64K 
> to 4M? Put another way, do you still see good size/speed gains if you 
> do everything else other than bump this number? One of the original 
> design goals was to limit the amount of memory needed for 
> decompressing an arbitrary snappy stream. 
>

Then it depends more on the content. Especially machine generated content 
suffers a lot.

Here is the size/speed of the compression, with 64KB block size restriction 
on S2:


| file| out| level | insize  | outsize| 
millis | mb/s|
|-||---|-|||-|
| rawstudio-mint14.tar| snappy | 1 | 8558382592  | 4796307031 | 
17814  | 458.17  |
| rawstudio-mint14.tar| s2 | 1 | 8558382592  | 4741757590 | 
13157  | 620.3   |
| rawstudio-mint14.tar| s2 | 2 | 8558382592  | 4568241215 | 
25962  | 314.37  |
| file| out| level | insize  | outsize| 
millis | mb/s|
| github-june-2days-2019.json | snappy | 1 | 6273951764  | 1525176492 | 
12085  | 495.07  |
| github-june-2days-2019.json | s2 | 1 | 6273951764  | 1416959675 | 
8496   | 704.17  |
| github-june-2days-2019.json | s2 | 2 | 6273951764  | 1344106237 | 
13165  | 454.45  |
| file| out| level | insize  | outsize| 
millis | mb/s|
| github-ranks-backup.bin | snappy | 1 | 1862623243  | 589837541  | 
3785   | 469.21  |
| github-ranks-backup.bin | s2 | 1 | 1862623243  | 637075877  | 
2869   | 619.01  |
| github-ranks-backup.bin | s2 | 2 | 1862623243  | 579284488  | 
4411   | 402.61  |
| file| out| level | insize  | outsize| 
millis | mb/s|
| consensus.db.10gb   | snappy | 1 | 10737418240 | 5412897703 | 
22273  | 459.75  |
| consensus.db.10gb   | s2 | 1 | 10737418240 | 5303306037 | 
15025  | 681.5   |
| consensus.db.10gb   | s2 | 2 | 10737418240 | 5377169131 | 
71860  | 142.5   |
| file| out| level | insize  | outsize| 
millis | mb/s|
| adresser.json   | snappy | 1 | 7983034785  | 809697891  | 
7997   | 951.91  |
| adresser.json   | s2 | 1 | 7983034785  | 568975289  | 
4944   | 1539.86 |
| adresser.json   | s2 | 2 | 7983034785  | 527205659  | 
9675   | 786.88  |
| file| out| level | insize  | outsize| 
millis | mb/s|
| gob-stream  | snappy | 1 | 1911399616  | 457984585  | 
3668   | 496.85  |
| gob-stream  | s2 | 1 | 1911399616  | 440972884  | 
2528   | 720.91  |
| gob-stream  | s2 | 2 | 1911399616  | 426735950  | 
3982   | 457.67  |
| file| out| level | insize  | outsize| 
millis | mb/s|
| 10gb.tar| snappy | 1 | 10065157632 | 6056946612 | 
23905  | 401.54  |
| 10gb.tar| s2 | 1 | 10065157632 | 6170962298 | 
22430  | 427.95  |
| 10gb.tar| s2 | 2 | 10065157632 | 5775224369 | 
31923  | 300.69  |
| file| out| level | insize  | outsize| 
millis | mb/s|
| sharnd.out.2gb  | snappy | 1 | 2147483647  | 2147745801 | 
327| 6261.61 |
| sharnd.out.2gb  | s2 | 1 | 2147483647  | 2147745801 | 
356| 5751.51 |
| sharnd.out.2gb  | s2 | 2 | 2147483647  | 2147745801 | 
485| 4221.73 |
| file| out| level | insize  | outsize| 
millis | mb/s|
| enwik9  | snappy | 1 | 10  | 508028601  | 
4098   | 232.66  |
| enwik9  | s2 | 1 | 10  | 523651446  | 
2736   | 348.49  |
| enwik9  | s2 | 2 | 10  | 461872591  | 
4689   | 203.38  |
| file| out| level | insize  | outsize| 
millis | mb/s|
| silesia.tar | snappy | 1 | 211947520   | 103008711  | 
634| 318.74  |
| silesia.tar | s2 | 1 | 21194

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'

On 28.08.19 12:32, Durga Someswararao G wrote:

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
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
mailto:durgasomeswararao...@gmail.com>> a écrit :

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","'@_@_@'",-1)

On Wed, Aug 28, 2019 at 3:26 PM Tamás Gulácsi
mailto:tgulacs...@gmail.com>> wrote:

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

https://groups.google.com/d/msgid/golang-nuts/865188f0-405e-45ee-82b9-7f6d24f1d49f%40googlegroups.com.

--
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
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGr83pA%2Bvrkg-bYkOs-qjsqxkOgEjoGTmigtJsr0hO287w%40mail.gmail.com

--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/2c202a4b-1db1-2247-d374-814f66c81b0c%40mb0.org.

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 immediately obvious on which axis "better"
is better in. (Or if it's better in both axes, why not just always
turn it on).

Also, from 
https://github.com/klauspost/compress/tree/master/s2#format-extensions:
> Format Extensions
> ...
> Framed compressed blocks can be up to 4MB (up from 64KB).

Do you know how much of the size or speed gains come from bumping 64K
to 4M? Put another way, do you still see good size/speed gains if you
do everything else other than bump this number? One of the original
design goals was to limit the amount of memory needed for
decompressing an arbitrary snappy stream.

https://github.com/google/snappy/blob/master/framing_format.txt says:
"the uncompressed data in a chunk must be no longer than 65536 bytes.
This allows consumers to easily use small fixed-size buffers".

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOeFMNWiz2T-9efjDg%2BQEfGDB8Cnp_6OyV7Z9m0TTYVLChUJPA%40mail.gmail.com.

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 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 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","'@_@_@'",-1)
>>
>> On Wed, Aug 28, 2019 at 3:26 PM Tamás Gulácsi 
>> wrote:
>>
>>> 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 receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/865188f0-405e-45ee-82b9-7f6d24f1d49f%40googlegroups.com
>>> .
>>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGr83pA%2Bvrkg-bYkOs-qjsqxkOgEjoGTmigtJsr0hO287w%40mail.gmail.com
>> 
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGrM47a%3Dj6Zbk1caY46FYUG7fXC2J0z0QvoJtSp69b6NCQ%40mail.gmail.com.

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 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","'@_@_@'",-1)
>
> On Wed, Aug 28, 2019 at 3:26 PM Tamás Gulácsi 
> wrote:
>
>> 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 receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/865188f0-405e-45ee-82b9-7f6d24f1d49f%40googlegroups.com
>> .
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGr83pA%2Bvrkg-bYkOs-qjsqxkOgEjoGTmigtJsr0hO287w%40mail.gmail.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANgi334x6aPL-TQOk-4SfwXd4%2BC3hZMB74c797upE9%3DhYzB%3D8w%40mail.gmail.com.

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","'@_@_@'",-1)

On Wed, Aug 28, 2019 at 3:26 PM Tamás Gulácsi  wrote:

> 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 receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/865188f0-405e-45ee-82b9-7f6d24f1d49f%40googlegroups.com
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGr83pA%2Bvrkg-bYkOs-qjsqxkOgEjoGTmigtJsr0hO287w%40mail.gmail.com.

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 receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/865188f0-405e-45ee-82b9-7f6d24f1d49f%40googlegroups.com.

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, but typically at speeds slightly below "better" mode in 
> this package. 
>
> Do you know how S2 compares with LZ4? https://github.com/lz4/lz4 
> suggests that LZ4 is faster (for both compression and decompression) 
> than Snappy, for a comparable compression ratio. 
>

To be fair to LZ4, here is a single core comparison. Only the fastest mode 
of LZ4 is really 'competitive' - this is level 0 in the chart. S2 level 1 
is default, level 2 is "better".

It is against master of `github.com/pierrec/lz4` to which I also sent in 
some nice speedups.

| file| out | level | insize  | outsize| 
millis | mb/s|
|-|-|---|-|||-|
| rawstudio-mint14.tar| lz4 | 0 | 8558382592  | 4553246910 | 
17942  | 454.90  |
| rawstudio-mint14.tar| s2  | 1 | 8558382592  | 4461314089 | 
12935  | 630.95  |
| rawstudio-mint14.tar| s2  | 2 | 8558382592  | 4285178801 | 
25292  | 322.7   |
| github-june-2days-2019.json | lz4 | 0 | 6273951764  | 1274316041 | 
9441   | 633.75  |
| github-june-2days-2019.json | s2  | 1 | 6273951764  | 1086090092 | 
7425   | 805.76  |
| github-june-2days-2019.json | s2  | 2 | 6273951764  | 1055384443 | 
10936  | 547.1   |
| github-ranks-backup.bin | lz4 | 0 | 1862623243  | 618233345  | 
3655   | 485.89  |
| github-ranks-backup.bin | s2  | 1 | 1862623243  | 624632852  | 
3002   | 591.58  |
| github-ranks-backup.bin | s2  | 2 | 1862623243  | 564891142  | 
4990   | 355.95  |
| consensus.db.10gb   | lz4 | 0 | 10737418240 | 5065051629 | 
23608  | 433.75  |
| consensus.db.10gb   | s2  | 1 | 10737418240 | 4610183941 | 
14913  | 686.63  |
| consensus.db.10gb   | s2  | 2 | 10737418240 | 4612959122 | 
32878  | 311.45  |
| adresser.json   | lz4 | 0 | 7983034785  | 470399106  | 
5572   | 1366.27 |
| adresser.json   | s2  | 1 | 7983034785  | 457342320  | 
4546   | 1674.7  |
| adresser.json   | s2  | 2 | 7983034785  | 438421980  | 
5320   | 1431|
| gob-stream  | lz4 | 0 | 1911399616  | 377393110  | 
2904   | 627.56  |
| gob-stream  | s2  | 1 | 1911399616  | 356137611  | 
2439   | 747.21  |
| gob-stream  | s2  | 2 | 1911399616  | 345184546  | 
3392   | 537.28  |
| 10gb.tar| lz4 | 0 | 10065157632 | 5852284245 | 
22916  | 418.87  |
| 10gb.tar| s2  | 1 | 10065157632 | 5936329234 | 
20340  | 471.91  |
| 10gb.tar| s2  | 2 | 10065157632 | 5725266005 | 
29463  | 325.79  |
| sharnd.out.2gb  | lz4 | 0 | 2147483647  | 2147485710 | 
442| 4632.35 |
| sharnd.out.2gb  | s2  | 1 | 2147483647  | 2147500041 | 
246| 8323.35 |
| sharnd.out.2gb  | s2  | 2 | 2147483647  | 2147500041 | 
272| 7527.72 |
| enwik9  | lz4 | 0 | 10  | 469015635  | 
3681   | 259.02  |
| enwik9  | s2  | 1 | 10  | 489432671  | 
2973   | 320.71  |
| enwik9  | s2  | 2 | 10  | 435069175  | 
4733   | 201.49  |
| silesia.tar | lz4 | 0 | 211947520   | 95265393   | 
600| 336.75  |
| silesia.tar | s2  | 1 | 211947520   | 97205820   | 
484| 417.52  |
| silesia.tar | s2  | 2 | 211947520   | 90759543   | 
794| 254.51  |

On a single core, it seems like LZ4 on the fastest setting is between the 
two modes. Some cases (the 2 JSON cases, the VM image and the gob stream) 
are strictly worse on LZ4.

TLDR; LZ4 is typically between the default and "better" mode of s2.
 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a5cb9e65-c04b-4a43-87fa-dc54d9d4c979%40googlegroups.com.

[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 

.

Thanks for the hint.

Abraham

On Wednesday, August 28, 2019 at 10:28:16 AM UTC+3, Afriyie Abraham Kwabena 
wrote:
>
> 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 the diameter 
> code did i need to modify to 
> achieve this.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9f122b51-7858-4ddf-9d8d-944ea34fccd9%40googlegroups.com.

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 16:28、afriyie.abra...@gmail.comのメール:

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 the diameter code did 
i need to modify to 
achieve this.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7e06b8dc-e8cc-4eb7-b554-f7b7d924fa71%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/96940B47-A8AD-4084-B440-324D55B82393%40gmail.com.

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