Re: [go-nuts] Channel Feature Suggestion

[Serhat Sevki Dincer]

Forgot to start it :P

func main() {
  waiter()
}

22 Şub 2019 Cum 09:56 tarihinde Kurtis Rader  şunu
yazdı:

> I don't see where your `waiter()` function is used in your example. I have
> been lurking till now but I concur with the other people who have told you
> your proposal doesn't make any situation easier to deal with and in fact is
> likely to be the source of bugs.
>
> On Thu, Feb 21, 2019 at 10:43 PM Serhat Şevki Dinçer 
> wrote:
>
>> Another use case is wait groups with Max number of goroutines allowed:
>>
>> ch:= make(chan bool, 10)
>>
>> func waiter() {
>>   ch <-true
>>   go worker()
>>
>>   // when empty, all jobs are finished
>>   waitempty(ch)
>> }
>>
>> func worker() {
>>   // do work
>>
>>   Select {
>>   ch <- true:
>> go worker() // try to handover some jobs
>>   default:
>> // max goroutine limit
>> // do them yourself
>>   }
>>
>>   // do remaining jobs
>>
>>   // make way
>>   <- ch
>>   return
>> }
>>
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Kurtis Rader]

I don't see where your `waiter()` function is used in your example. I have
been lurking till now but I concur with the other people who have told you
your proposal doesn't make any situation easier to deal with and in fact is
likely to be the source of bugs.

On Thu, Feb 21, 2019 at 10:43 PM Serhat Şevki Dinçer 
wrote:

> Another use case is wait groups with Max number of goroutines allowed:
>
> ch:= make(chan bool, 10)
>
> func waiter() {
>   ch <-true
>   go worker()
>
>   // when empty, all jobs are finished
>   waitempty(ch)
> }
>
> func worker() {
>   // do work
>
>   Select {
>   ch <- true:
> go worker() // try to handover some jobs
>   default:
> // max goroutine limit
> // do them yourself
>   }
>
>   // do remaining jobs
>
>   // make way
>   <- ch
>   return
> }
>

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Serhat Şevki Dinçer]

Another use case is wait groups with Max number of goroutines allowed:

ch:= make(chan bool, 10)

func waiter() {
  ch <-true
  go worker()

  // when empty, all jobs are finished
  waitempty(ch)
}

func worker() {
  // do work

  Select {
  ch <- true:
go worker() // try to handover some jobs
  default:
// max goroutine limit
// do them yourself
  } 

  // do remaining jobs

  // make way
  <- ch
  return
}

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is WASM support planned in go 1.12 ?

[schmorrison]

Ill be following your repo closely Max. Really like the looks of it!


On Thursday, February 21, 2019 at 3:40:47 PM UTC-6, max...@segment.com 
wrote:
>
> I'm working on a wasm go library to build front end.
> It is unstable on mobile but work fine on desktop (except Edge).
> Waiting for go 1.12 to solves some issues.
>
> If you are on a desktop, you see the hello world example built with it 
> here: wasm go hello world 
> The repo is available here: https://github.com/maxence-charriere/app
>
> On Wednesday, February 6, 2019 at 12:31:18 PM UTC-8, Tharaneedharan 
> Vilwanathan wrote:
>>
>> Somehow I was dreaming I can use Go for frontend too, instead of JS. Is 
>> my thinking right?
>>
>> Regards
>> dharani
>>
>>
>> On Wed, Feb 6, 2019 at 12:26 PM Robert Engels  
>> wrote:
>>
>>> Just mo wasm is horrible on any platform. Unless you maybe have a 
>>> large game engine that you are attempting to integrate. 
>>>
>>> You have to ask yourself, what are you trying to do? If it is just to 
>>> avoid the garbage that is JS, then use an environment that transpiles to 
>>> JS. You’ll have better integration with the DOM, and not have to learn yet 
>>> another client side technology. 
>>>
>>> Again, just mo. 
>>>
>>> On Feb 6, 2019, at 2:06 PM, Tharaneedharan Vilwanathan <
>>> vdha...@gmail.com> wrote:
>>>
>>>
>>> I have one more question. Has anyone used WASM in Go for something more 
>>> than small examples I managed to see and got them working?
>>>
>>> It was challenging to get it working and then I wasn't sure how it is 
>>> used and how to use it for any bigger projects.
>>>
>>> Please share your thoughts.
>>>
>>> Regards
>>> dharani
>>>
>>>
>>> On Wed, Feb 6, 2019 at 11:57 AM gocss  
>>> wrote:
>>>
 while webassembly was considered experimental in go 1.11 is it
 planned in go 1.12 release later this month? If so will it's inclusion 
 be considered non-experimental ?

 -- 
 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...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>> -- 
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Visual Studio Code oddity with Go

[Brian Mcneely]

On Thu, Feb 21, 2019, 9:42 PM andrey mirtchovski  > I tried the solution posted by Andrey (Thank you!) and it still does the
> popup thing.  Oh well, it's a minor distraction, click update and it goes
> away.
>
> If you go to the OUTPUT tab does it give you an error message? or does
> it say "things successfully installed"?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Visual Studio Code oddity with Go

[Rich]

Yeah. When I install the tool, it always gives me a success.  When I 
selected all of them it also gave me a success.

Thanks!

On Thursday, February 21, 2019 at 10:42:33 PM UTC-5, andrey mirtchovski 
wrote:
>
> > I tried the solution posted by Andrey (Thank you!) and it still does the 
> popup thing.  Oh well, it's a minor distraction, click update and it goes 
> away. 
>
> If you go to the OUTPUT tab does it give you an error message? or does 
> it say "things successfully installed"? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[robert engels]

By condition variable I mean sync.Cond

> On Feb 21, 2019, at 3:10 PM, Robert Engels  wrote:
> 
> The proper solution is using a condition variable. You can handle the 
> proposed use case easily. There is no need for it to be specific to channels, 
> but you need another layer. 
> 
>> On Feb 21, 2019, at 2:49 PM, Burak Serdar  wrote:
>> 
>>> On Thu, Feb 21, 2019 at 1:44 PM Serhat Şevki Dinçer  
>>> wrote:
>>> 
 On Thursday, February 21, 2019 at 11:21:11 PM UTC+3, Jan Mercl wrote:
 
 But then calling it or not has the exact same semantics. So what's it even 
 good for?
>>> 
>>> 
>>> Let's take your case Jan:
>>> 
>>> func consumer() {
>>>   select {
>>>   case x := <-ch:
>>>   // received, consume x
>>>   default:
>>>   // empty ch, sleep or poll
>>>   }
>>> }
>>> 
>>> func producer() {
>>>   // produce x
>>>   select {
>>>   case ch <- x:
>>>   // send successful, on to a new x
>>>   default:
>>>   // full ch, sleep or poll, try to resend
>>>   }
>>> }
>>> 
>>> With the directives, you can do the following 'without disturbing the 
>>> processing pipeline' :
>>> 
>>> func consumer() {
>>>   for {
>>>   x := <-ch
>>>   // consume x
>>>   }
>>> }
>>> 
>>> func producer() {
>>>   for {
>>>   // produce x
>>>   ch <- x
>>>   }
>>> }
>>> 
>>> func observer1() {
>>>   for {
>>>   waitempty(ch)
>>>   // not enough producers, say, by some rate or counter, last empty 
>>> buffer time, empty buffer occorance etc.
>>>   // create anotherproducer
>>>  go producer() // could be up to a max number of producers
>>>   }
>>> }
>>> 
>>> func observer2() {
>>>   for {
>>>   waitfull(ch)
>>>   // not enough consumers, say, by some rate or counter etc.
>>>   // create another one
>>>   go consumer() // could be up to a max number of consumers
>>>   }
>>> }
>>> 
>>> I think that will be much more efficient, because you dont 'disturb the 
>>> processing pipeline'.
>> 
>> The problem with these operations is that they operate like flags that
>> tell if a certain threshold was reached. It doesn't tell how many
>> times that threshold was reached, or for how long that state lasted,
>> which is really what you need to do the things you want to do.
>> 
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Visual Studio Code oddity with Go

[robert engels]

I use VS Code with Go on a Mac at times - usually IntelliJ - and don’t have 
that problem. Maybe uninstall, delete the preferences, and re-install. Just a 
thought.

> On Feb 21, 2019, at 8:51 PM, Rich  wrote:
> 
> Just about every video on Go, I see people using VSC, and so was hoping to 
> find another Go user that has this problem, that's why I posted it here 
> rather than the VSC Github site. I'm on a mac, reinstalled, deleted my 
> settings -- all the usual stuff but it keeps popping up a message to install 
> gocode tools.
> 
> I tried the solution posted by Andrey (Thank you!) and it still does the 
> popup thing.  Oh well, it's a minor distraction, click update and it goes 
> away.
> 
> 
> On Thursday, February 21, 2019 at 9:14:12 PM UTC-5, andrey mirtchovski wrote:
> reposting my private comment from a day ago for those searching for answers: 
> 
> try "command-shift-p" or ctrl-shift-p depending on your operating 
> system, to bring the "all commands" pop-up. there you should be able 
> to find "Go: Install/Update tools". click on the checkboxes. hit 
> enter. 
> 
> On Wed, Feb 20, 2019 at 7:14 AM Rich > wrote: 
> > 
> > I tried googling this but I not been able to find a solution, hopefully I 
> > can ask this here and someone else knows how to fix this.  I use Visual 
> > Studio Code -- because it's free. The issue I am having is that every time 
> > I use Visual Studio Code I get the popup that says: 
> > 
> >> The Go extension is better with the latest version of "gocode".  Use "go 
> >> get -u -v github.com/mdempsky/gocode " 
> >> to update 
> > 
> > 
> > Anyone else have this or know how to fix this? It shouldn't ask EVERY time 
> > I use Visual Studio Code? 
> > 
> > -- 
> > 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...@googlegroups.com <>. 
> > For more options, visit https://groups.google.com/d/optout 
> > . 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Visual Studio Code oddity with Go

[Dan Kortschak]

Have you run `go get -u github.com/mdempsky/gocode` in a terminal? Is
the binary put in your $PATH? If you try vim with vim-go or emac with
go-mode does gocode work for you there?

Dan

On Thu, 2019-02-21 at 18:51 -0800, Rich wrote:
> Just about every video on Go, I see people using VSC, and so was
> hoping to 
> find another Go user that has this problem, that's why I posted it
> here 
> rather than the VSC Github site. I'm on a mac, reinstalled, deleted
> my 
> settings -- all the usual stuff but it keeps popping up a message to 
> install gocode tools.
> 
> I tried the solution posted by Andrey (Thank you!) and it still does
> the 
> popup thing.  Oh well, it's a minor distraction, click update and it
> goes 
> away.
> 
> 
> On Thursday, February 21, 2019 at 9:14:12 PM UTC-5, andrey
> mirtchovski 
> wrote:
> > 
> > 
> > reposting my private comment from a day ago for those searching
> > for 
> > answers: 
> > 
> > try "command-shift-p" or ctrl-shift-p depending on your operating 
> > system, to bring the "all commands" pop-up. there you should be
> > able 
> > to find "Go: Install/Update tools". click on the checkboxes. hit 
> > enter. 
> > 
> > On Wed, Feb 20, 2019 at 7:14 AM Rich  > > 
> > wrote: 
> > > 
> > > 
> > > I tried googling this but I not been able to find a solution,
> > > hopefully 
> > I can ask this here and someone else knows how to fix this.  I use
> > Visual 
> > Studio Code -- because it's free. The issue I am having is that
> > every time 
> > I use Visual Studio Code I get the popup that says: 
> > > 
> > > 
> > > > 
> > > > The Go extension is better with the latest version of
> > > > "gocode".  Use 
> > "go get -u -v github.com/mdempsky/gocode" to update 
> > > 
> > > 
> > > 
> > > Anyone else have this or know how to fix this? It shouldn't ask
> > > EVERY 
> > time I use Visual Studio Code? 
> > > 
> > > 
> > > -- 
> > > 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...@googlegroups.com . 
> > > 
> > > For more options, visit https://groups.google.com/d/optout. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Visual Studio Code oddity with Go

[Rich]

Just about every video on Go, I see people using VSC, and so was hoping to 
find another Go user that has this problem, that's why I posted it here 
rather than the VSC Github site. I'm on a mac, reinstalled, deleted my 
settings -- all the usual stuff but it keeps popping up a message to 
install gocode tools.

I tried the solution posted by Andrey (Thank you!) and it still does the 
popup thing.  Oh well, it's a minor distraction, click update and it goes 
away.


On Thursday, February 21, 2019 at 9:14:12 PM UTC-5, andrey mirtchovski 
wrote:
>
> reposting my private comment from a day ago for those searching for 
> answers: 
>
> try "command-shift-p" or ctrl-shift-p depending on your operating 
> system, to bring the "all commands" pop-up. there you should be able 
> to find "Go: Install/Update tools". click on the checkboxes. hit 
> enter. 
>
> On Wed, Feb 20, 2019 at 7:14 AM Rich > 
> wrote: 
> > 
> > I tried googling this but I not been able to find a solution, hopefully 
> I can ask this here and someone else knows how to fix this.  I use Visual 
> Studio Code -- because it's free. The issue I am having is that every time 
> I use Visual Studio Code I get the popup that says: 
> > 
> >> The Go extension is better with the latest version of "gocode".  Use 
> "go get -u -v github.com/mdempsky/gocode" to update 
> > 
> > 
> > Anyone else have this or know how to fix this? It shouldn't ask EVERY 
> time I use Visual Studio Code? 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: sharing types between interface and implementation

[DrGo]

what worked for me in a largish project is using an internal package (named 
"types") to host types used in more than package. 

On Thursday, February 21, 2019 at 3:30:08 PM UTC-6, Manlio Perillo wrote:
>
> Hi.
>
> I'm implementing a generic (and very simple) interface for key-value 
> databases, and I'm using the standard database/sql package as a reference.
> The only difference is that I don't plan to have a Driver interface, but 
> only a Database and Tx interfaces.
>
> For starting a transaction I'm thinking of something like this:
>
> type TxMode int
>
> const (
> ReadOnly TxMode iota
> ReadWrite
> )
>
> func Begin(mode TxMode) (Tx, error)
>
>
> Now, that problem is that this type needs to be used by both the driver 
> and the database packages.
>
> For the standard database/sql package, the TxOptions type is duplicated.
> Is there a reason for this duplication?
> I was thinking of declaring the TxMode in the driver package and using a 
> type alias in the database package, but I'm not sure.
>
>
> Thanks
> Manlio Perillo
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Visual Studio Code oddity with Go

[andrey mirtchovski]

reposting my private comment from a day ago for those searching for answers:

try "command-shift-p" or ctrl-shift-p depending on your operating
system, to bring the "all commands" pop-up. there you should be able
to find "Go: Install/Update tools". click on the checkboxes. hit
enter.

On Wed, Feb 20, 2019 at 7:14 AM Rich  wrote:
>
> I tried googling this but I not been able to find a solution, hopefully I can 
> ask this here and someone else knows how to fix this.  I use Visual Studio 
> Code -- because it's free. The issue I am having is that every time I use 
> Visual Studio Code I get the popup that says:
>
>> The Go extension is better with the latest version of "gocode".  Use "go get 
>> -u -v github.com/mdempsky/gocode" to update
>
>
> Anyone else have this or know how to fix this? It shouldn't ask EVERY time I 
> use Visual Studio Code?
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Visual Studio Code oddity with Go

[Dan Kortschak]

Please remember to try to make golang-nuts a welcoming venue to discuss
Go.

The OP has tried to find out a solution and has been unable to. Asking
here seems like a reasonable place.

On Thu, 2019-02-21 at 17:28 -0800, Space A. wrote:
> Nothing comes for free. For example, now you are wasting your (and
> others) 
> time. 
> 
> 
> среда, 20 февраля 2019 г., 17:14:21 UTC+3 пользователь Rich написал:
> > 
> > 
> > I tried googling this but I not been able to find a solution,
> > hopefully I 
> > can ask this here and someone else knows how to fix this.  I use
> > Visual 
> > Studio Code -- because it's free. The issue I am having is that
> > every time 
> > I use Visual Studio Code I get the popup that says: 
> > 
> > The Go extension is better with the latest version of
> > "gocode".  Use "go 
> > > 
> > > get -u -v github.com/mdempsky/gocode" to update
> > 
> > Anyone else have this or know how to fix this? It shouldn't ask
> > EVERY time 
> > I use Visual Studio Code? 
> > 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Visual Studio Code oddity with Go

[Space A.]

Nothing comes for free. For example, now you are wasting your (and others) 
time. 


среда, 20 февраля 2019 г., 17:14:21 UTC+3 пользователь Rich написал:
>
> I tried googling this but I not been able to find a solution, hopefully I 
> can ask this here and someone else knows how to fix this.  I use Visual 
> Studio Code -- because it's free. The issue I am having is that every time 
> I use Visual Studio Code I get the popup that says: 
>
> The Go extension is better with the latest version of "gocode".  Use "go 
>> get -u -v github.com/mdempsky/gocode" to update
>
>
> Anyone else have this or know how to fix this? It shouldn't ask EVERY time 
> I use Visual Studio Code? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] The Seven Finest Go Books (to popularize and 'socialize' Go).

[Akram Ahmad]

   
   - The amazing language that golang surely is, and how refreshingly (and 
   elegantly) simple a language golang is—take this from someone coming from 
   extensive experience in Java and Scala, two language which well-deservedly 
   have a lot going for them—I think we need to do *more* to popularize 
   (and 'socialize') the promise of golang to the larger community of 
   programmers. 
   - To that end, I put together and recently posted a (fairly) detailed 
   blog post: *Best Go Programming Books (2019) 
   
*
   .
   - Earlier posts (at least on golang) include the following two: *The Go 
   Programming Language 
   
* 
   and *Further Adventures In Go Land 
   
*
   .

Go golang!

Warm Regards to fellow gophers, hibernating or otherwise :)

 ~Akram 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is WASM support planned in go 1.12 ?

[maxence]

I'm working on a wasm go library to build front end.
It is unstable on mobile but work fine on desktop (except Edge).
Waiting for go 1.12 to solves some issues.

If you are on a desktop, you see the hello world example built with it 
here: wasm go hello world 
The repo is available here: https://github.com/maxence-charriere/app

On Wednesday, February 6, 2019 at 12:31:18 PM UTC-8, Tharaneedharan 
Vilwanathan wrote:
>
> Somehow I was dreaming I can use Go for frontend too, instead of JS. Is my 
> thinking right?
>
> Regards
> dharani
>
>
> On Wed, Feb 6, 2019 at 12:26 PM Robert Engels  > wrote:
>
>> Just mo wasm is horrible on any platform. Unless you maybe have a 
>> large game engine that you are attempting to integrate. 
>>
>> You have to ask yourself, what are you trying to do? If it is just to 
>> avoid the garbage that is JS, then use an environment that transpiles to 
>> JS. You’ll have better integration with the DOM, and not have to learn yet 
>> another client side technology. 
>>
>> Again, just mo. 
>>
>> On Feb 6, 2019, at 2:06 PM, Tharaneedharan Vilwanathan > > wrote:
>>
>>
>> I have one more question. Has anyone used WASM in Go for something more 
>> than small examples I managed to see and got them working?
>>
>> It was challenging to get it working and then I wasn't sure how it is 
>> used and how to use it for any bigger projects.
>>
>> Please share your thoughts.
>>
>> Regards
>> dharani
>>
>>
>> On Wed, Feb 6, 2019 at 11:57 AM gocss > > wrote:
>>
>>> while webassembly was considered experimental in go 1.11 is it
>>> planned in go 1.12 release later this month? If so will it's inclusion 
>>> be considered non-experimental ?
>>>
>>> -- 
>>> 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...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] sharing types between interface and implementation

[Manlio Perillo]

Hi.

I'm implementing a generic (and very simple) interface for key-value 
databases, and I'm using the standard database/sql package as a reference.
The only difference is that I don't plan to have a Driver interface, but 
only a Database and Tx interfaces.

For starting a transaction I'm thinking of something like this:

type TxMode int

const (
ReadOnly TxMode iota
ReadWrite
)

func Begin(mode TxMode) (Tx, error)


Now, that problem is that this type needs to be used by both the driver and 
the database packages.

For the standard database/sql package, the TxOptions type is duplicated.
Is there a reason for this duplication?
I was thinking of declaring the TxMode in the driver package and using a 
type alias in the database package, but I'm not sure.


Thanks
Manlio Perillo

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Robert Engels]

The proper solution is using a condition variable. You can handle the proposed 
use case easily. There is no need for it to be specific to channels, but you 
need another layer. 

> On Feb 21, 2019, at 2:49 PM, Burak Serdar  wrote:
> 
>> On Thu, Feb 21, 2019 at 1:44 PM Serhat Şevki Dinçer  
>> wrote:
>> 
>>> On Thursday, February 21, 2019 at 11:21:11 PM UTC+3, Jan Mercl wrote:
>>> 
>>> But then calling it or not has the exact same semantics. So what's it even 
>>> good for?
>> 
>> 
>> Let's take your case Jan:
>> 
>> func consumer() {
>>select {
>>case x := <-ch:
>>// received, consume x
>>default:
>>// empty ch, sleep or poll
>>}
>> }
>> 
>> func producer() {
>>// produce x
>>select {
>>case ch <- x:
>>// send successful, on to a new x
>>default:
>>// full ch, sleep or poll, try to resend
>>}
>> }
>> 
>> With the directives, you can do the following 'without disturbing the 
>> processing pipeline' :
>> 
>> func consumer() {
>>for {
>>x := <-ch
>>// consume x
>>}
>> }
>> 
>> func producer() {
>>for {
>>// produce x
>>ch <- x
>>}
>> }
>> 
>> func observer1() {
>>for {
>>waitempty(ch)
>>// not enough producers, say, by some rate or counter, last empty 
>> buffer time, empty buffer occorance etc.
>>// create anotherproducer
>>   go producer() // could be up to a max number of producers
>>}
>> }
>> 
>> func observer2() {
>>for {
>>waitfull(ch)
>>// not enough consumers, say, by some rate or counter etc.
>>// create another one
>>go consumer() // could be up to a max number of consumers
>>}
>> }
>> 
>> I think that will be much more efficient, because you dont 'disturb the 
>> processing pipeline'.
> 
> The problem with these operations is that they operate like flags that
> tell if a certain threshold was reached. It doesn't tell how many
> times that threshold was reached, or for how long that state lasted,
> which is really what you need to do the things you want to do.
> 
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Burak Serdar]

On Thu, Feb 21, 2019 at 1:44 PM Serhat Şevki Dinçer  wrote:
>
> On Thursday, February 21, 2019 at 11:21:11 PM UTC+3, Jan Mercl wrote:
>>
>> But then calling it or not has the exact same semantics. So what's it even 
>> good for?
>
>
> Let's take your case Jan:
>
> func consumer() {
> select {
> case x := <-ch:
> // received, consume x
> default:
> // empty ch, sleep or poll
> }
> }
>
> func producer() {
> // produce x
> select {
> case ch <- x:
> // send successful, on to a new x
> default:
> // full ch, sleep or poll, try to resend
> }
> }
>
> With the directives, you can do the following 'without disturbing the 
> processing pipeline' :
>
> func consumer() {
> for {
> x := <-ch
> // consume x
> }
> }
>
> func producer() {
> for {
> // produce x
> ch <- x
> }
> }
>
> func observer1() {
> for {
> waitempty(ch)
> // not enough producers, say, by some rate or counter, last empty 
> buffer time, empty buffer occorance etc.
> // create anotherproducer
>go producer() // could be up to a max number of producers
> }
> }
>
> func observer2() {
> for {
> waitfull(ch)
> // not enough consumers, say, by some rate or counter etc.
> // create another one
> go consumer() // could be up to a max number of consumers
> }
> }
>
> I think that will be much more efficient, because you dont 'disturb the 
> processing pipeline'.

The problem with these operations is that they operate like flags that
tell if a certain threshold was reached. It doesn't tell how many
times that threshold was reached, or for how long that state lasted,
which is really what you need to do the things you want to do.

>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Michael Jones]

Serhat, imagine your feature in the context of a buffered channel that
holds 10 elements, and a writer go routine that wants to send 1000 elements
through that channel.

It is natural to imagine a downstream go routine reading and working on the
first element, and the writer filling the empty slot with #11 then being
blocked waiting to write #12.

But it is possible that the writer writes only #1, the reader reads it, the
channel is empty, and only later is #2 added to the channel, maybe when the
downstream go routine tries to read #2 and blocks, which might force the
runtime to continue the reader routine.

In this second case an outside observer would think "that channel is always
empty." It is unclear what meaning any instantaneous observation can have.

On Thu, Feb 21, 2019 at 12:20 PM Jan Mercl <0xj...@gmail.com> wrote:

> But then calling it or not has the exact same semantics. So what's it even
> good for?
>
> On Thu, Feb 21, 2019, 21:17 Serhat Şevki Dinçer 
> wrote:
>
>> btw waitempty(ch) does not return any value, and it does not (have to)
>> guarantee that ch stays empty when it returns..
>>
>>
>> On Thursday, February 21, 2019 at 11:10:45 PM UTC+3, Serhat Şevki Dinçer
>> wrote:
>>>
>>> Burak, I think you dont get the potential of the suggesred directives.
>>>
>>> You can be interested in waitepty(ch) for example when:
>>> - you have direct control of who is pushing and pulling on it, and you
>>> know what an empty buffer means
>>> buffer could be "things to do or process", and you have a very
>>> easy-to-setup observer to alert some routine that:
>>> - you are out of job, or
>>> - you have too many to process
>>>
>>> Also what you suggest as raciness is irrelevant:
>>>
>>> for {
>>>   x := <- ch {
>>> // here, do you have a guarantee that you can put x back to the
>>> channel ??
>>>   }
>>> }
>>>
>>> On Thursday, February 21, 2019 at 10:57:43 PM UTC+3, Burak Serdar wrote:

 You can implement waitempty(ch) without a race condition. However, any
 scenario in which you use waitempty(ch) would have a race condition,
 because the moment it returns there is no guarantee on the state of
 the channel. So in a piece of code like this:

 waitempty(ch)
 post


 the only guarantee you have is that when 'post' is running, ch was
 empty at least once since waitempty was called.

 This code:

 for {
   if waitempty(ch) {
 ...
   }
 }

 is racy, because when you go into the if block, you have no idea how
 many times ch was empty.

>>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
>
> -j
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Serhat Şevki Dinçer]

On Thursday, February 21, 2019 at 11:21:11 PM UTC+3, Jan Mercl wrote:
>
> But then calling it or not has the exact same semantics. So what's it even 
> good for?
>

Let's take your case Jan:

func consumer() {
select { 
case x := <-ch:
// received, consume x
default:
// empty ch, sleep or poll
}
}   

func producer() {
// produce x
select {
case ch <- x:
// send successful, on to a new x
default:
// full ch, sleep or poll, try to resend
}
}

With the directives, you can do the following 'without disturbing the 
processing pipeline' :

func consumer() {
for {
x := <-ch
// consume x
}
}   

func producer() {
for {
// produce x
ch <- x
}
}

func observer1() {
for {
waitempty(ch)
// not enough producers, say, by some rate or counter, last empty 
buffer time, empty buffer occorance etc.
// create anotherproducer
   go producer() // could be up to a max number of producers
}
}

func observer2() {
for {
waitfull(ch)
// not enough consumers, say, by some rate or counter etc.
// create another one
go consumer() // could be up to a max number of consumers
}
}

I think that will be much more efficient, because you dont 'disturb the 
processing pipeline'.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Jan Mercl]

But then calling it or not has the exact same semantics. So what's it even
good for?

On Thu, Feb 21, 2019, 21:17 Serhat Şevki Dinçer  wrote:

> btw waitempty(ch) does not return any value, and it does not (have to)
> guarantee that ch stays empty when it returns..
>
>
> On Thursday, February 21, 2019 at 11:10:45 PM UTC+3, Serhat Şevki Dinçer
> wrote:
>>
>> Burak, I think you dont get the potential of the suggesred directives.
>>
>> You can be interested in waitepty(ch) for example when:
>> - you have direct control of who is pushing and pulling on it, and you
>> know what an empty buffer means
>> buffer could be "things to do or process", and you have a very
>> easy-to-setup observer to alert some routine that:
>> - you are out of job, or
>> - you have too many to process
>>
>> Also what you suggest as raciness is irrelevant:
>>
>> for {
>>   x := <- ch {
>> // here, do you have a guarantee that you can put x back to the
>> channel ??
>>   }
>> }
>>
>> On Thursday, February 21, 2019 at 10:57:43 PM UTC+3, Burak Serdar wrote:
>>>
>>> You can implement waitempty(ch) without a race condition. However, any
>>> scenario in which you use waitempty(ch) would have a race condition,
>>> because the moment it returns there is no guarantee on the state of
>>> the channel. So in a piece of code like this:
>>>
>>> waitempty(ch)
>>> post
>>>
>>>
>>> the only guarantee you have is that when 'post' is running, ch was
>>> empty at least once since waitempty was called.
>>>
>>> This code:
>>>
>>> for {
>>>   if waitempty(ch) {
>>> ...
>>>   }
>>> }
>>>
>>> is racy, because when you go into the if block, you have no idea how
>>> many times ch was empty.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Burak Serdar]

On Thu, Feb 21, 2019 at 1:10 PM Serhat Şevki Dinçer  wrote:
>
> Burak, I think you dont get the potential of the suggesred directives.
>
> You can be interested in waitepty(ch) for example when:
> - you have direct control of who is pushing and pulling on it, and you know 
> what an empty buffer means
> buffer could be "things to do or process", and you have a very easy-to-setup 
> observer to alert some routine that:
> - you are out of job, or
> - you have too many to process

I see. However, I still don't think channel is a good abstraction for
this. A customized solution, possibly without using channels is much
better suited I think.

>
> Also what you suggest as raciness is irrelevant:
>
> for {
>   x := <- ch {
> // here, do you have a guarantee that you can put x back to the channel ??

No, but you have a guarantee that ch was read, and what you read is
what was written.

>   }
> }
>
> On Thursday, February 21, 2019 at 10:57:43 PM UTC+3, Burak Serdar wrote:
>>
>> You can implement waitempty(ch) without a race condition. However, any
>> scenario in which you use waitempty(ch) would have a race condition,
>> because the moment it returns there is no guarantee on the state of
>> the channel. So in a piece of code like this:
>>
>> waitempty(ch)
>> post
>>
>>
>> the only guarantee you have is that when 'post' is running, ch was
>> empty at least once since waitempty was called.
>>
>> This code:
>>
>> for {
>>   if waitempty(ch) {
>> ...
>>   }
>> }
>>
>> is racy, because when you go into the if block, you have no idea how
>> many times ch was empty.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Serhat Şevki Dinçer]

btw waitempty(ch) does not return any value, and it does not (have to) 
guarantee that ch stays empty when it returns..

On Thursday, February 21, 2019 at 11:10:45 PM UTC+3, Serhat Şevki Dinçer 
wrote:
>
> Burak, I think you dont get the potential of the suggesred directives.
>
> You can be interested in waitepty(ch) for example when:
> - you have direct control of who is pushing and pulling on it, and you 
> know what an empty buffer means
> buffer could be "things to do or process", and you have a very 
> easy-to-setup observer to alert some routine that:
> - you are out of job, or
> - you have too many to process
>
> Also what you suggest as raciness is irrelevant: 
>
> for { 
>   x := <- ch { 
> // here, do you have a guarantee that you can put x back to the 
> channel ?? 
>   } 
> } 
>
> On Thursday, February 21, 2019 at 10:57:43 PM UTC+3, Burak Serdar wrote:
>>
>> You can implement waitempty(ch) without a race condition. However, any 
>> scenario in which you use waitempty(ch) would have a race condition, 
>> because the moment it returns there is no guarantee on the state of 
>> the channel. So in a piece of code like this: 
>>
>> waitempty(ch) 
>> post 
>>
>>
>> the only guarantee you have is that when 'post' is running, ch was 
>> empty at least once since waitempty was called. 
>>
>> This code: 
>>
>> for { 
>>   if waitempty(ch) { 
>> ... 
>>   } 
>> } 
>>
>> is racy, because when you go into the if block, you have no idea how 
>> many times ch was empty.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Serhat Şevki Dinçer]

Hi rog,

As -> and <- are 'not racy', because they are 'core' language features, 
because runtime handles them, because they are guaranteed to 'work', I am 
asking how easy and useful to implement them as 'core' language features.

Thank you..

On Thursday, February 21, 2019 at 9:04:22 PM UTC+3, rog wrote:
>
> As others have said, such operations are inherently racy - when you 
> receive the message that a channel is empty, it may not be empty any more. 
> For that reason, it's not a good idea to add them as primitives to the 
> language.
>
> That said, it's not too hard to implement them yourself. We are talking 
> about buffered channels here, so an extra item being buffered should be OK. 
> So you can insert a goroutine in between sender and receiver that signals 
> when it can't receive on a channel (it's empty) or when it can't send on a 
> channel (it's full).
>
> Here's some code that implements those operations:
>
> https://play.golang.org/p/2xyZnUI0imX
>
> Note that there are many other possible variants. For example, you might 
> want to send on the notification channel only when the channel has been 
> idle for some time.
>
>   cheers,
> rog.
>
>
> On Thu, 21 Feb 2019 at 13:38, Serhat Şevki Dinçer  > wrote:
>
>> Hi,
>>
>> Say you have a buffered channel
>> ch := make(chan int, 10)
>>
>> Would it make sense and be easy to add the following directives to the Go 
>> language core?
>>
>> waitempty(ch)
>> blocks caller until ch buffer is empty
>>
>> waitfull(ch)
>> blocks caller until ch buffer is full
>>
>> This means there are 3 types of goroutines related to a channel:
>> - senders
>> - receivers
>> - observers
>>
>> There are nice possibilities with these, for example wait groups, 
>> resource usage alerts etc.
>>
>> What do you think?
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] drop-in replacement of net with default netgo build tag ?

[Sebastien Binet]

hi there,

I am building a couple of packages that somehow need to import "net" and
"net/http".
I'd like for the users of my packages to get, by default, a statically
linked binary.
I know about the "go build -tags netgo" technique but I'd prefer if one
didn't have to fiddle with those.

so... is there a way to make sure that 'import "net"' will by default
statically link? (using the pure-Go DNS resolver isn't an issue.)

is vendoring an option here?
has somebody already provided a drop-in replacement of "net" but with the
"netgo" build tag enabled by default ?

cheers,
-s

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Visual Studio Code oddity with Go

[Louki Sumirniy]

I believe that very notification has a button that triggers it to be 
automatically installed. Otherwise just exactly do what it says and it'll 
stop coming up and you'll get more juicy information from vscode about your 
go things.

On Wednesday, 20 February 2019 15:14:21 UTC+1, Rich wrote:
>
> I tried googling this but I not been able to find a solution, hopefully I 
> can ask this here and someone else knows how to fix this.  I use Visual 
> Studio Code -- because it's free. The issue I am having is that every time 
> I use Visual Studio Code I get the popup that says: 
>
> The Go extension is better with the latest version of "gocode".  Use "go 
>> get -u -v github.com/mdempsky/gocode" to update
>
>
> Anyone else have this or know how to fix this? It shouldn't ask EVERY time 
> I use Visual Studio Code? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[roger peppe]

As others have said, such operations are inherently racy - when you receive
the message that a channel is empty, it may not be empty any more. For that
reason, it's not a good idea to add them as primitives to the language.

That said, it's not too hard to implement them yourself. We are talking
about buffered channels here, so an extra item being buffered should be OK.
So you can insert a goroutine in between sender and receiver that signals
when it can't receive on a channel (it's empty) or when it can't send on a
channel (it's full).

Here's some code that implements those operations:

https://play.golang.org/p/2xyZnUI0imX

Note that there are many other possible variants. For example, you might
want to send on the notification channel only when the channel has been
idle for some time.

  cheers,
rog.


On Thu, 21 Feb 2019 at 13:38, Serhat Şevki Dinçer 
wrote:

> Hi,
>
> Say you have a buffered channel
> ch := make(chan int, 10)
>
> Would it make sense and be easy to add the following directives to the Go
> language core?
>
> waitempty(ch)
> blocks caller until ch buffer is empty
>
> waitfull(ch)
> blocks caller until ch buffer is full
>
> This means there are 3 types of goroutines related to a channel:
> - senders
> - receivers
> - observers
>
> There are nice possibilities with these, for example wait groups, resource
> usage alerts etc.
>
> What do you think?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Serhat Sevki Dincer]

21 Şub 2019 Per 17:12 tarihinde Burak Serdar  şunu yazdı:

> On Thu, Feb 21, 2019 at 6:51 AM Serhat Sevki Dincer 
> wrote:
> >
> > But observer goroutines are not supposed to push to or pull from the
> channel.
>
> What is a use case for observing a channel like this? If you call
> waitempty(ch), when it returns ch may or may not be empty. Similar for
> other functions. Looks like a good opportunity to create race
> conditions.
>

By definition, waitempty(ch) returns "when" ch buffer is empty.

Just after waitempty returns, ch buffer may or may not get new members.
waitempty has guarantee that it will stay empty.

>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Michel Levieux]

No but you can for example have a second channel from the pusher to the
observer that signals (in case it cannot push anymore) the latter that the
channel to which it tries to push to is full.
The opposite is true from the consumer, that could signal via a second
channel, when it cannot pull from a channel anymore, that it is empty?

Le jeu. 21 févr. 2019 à 14:51, Serhat Sevki Dincer  a
écrit :

> But observer goroutines are not supposed to push to or pull from the
> channel.
>
> 21 Şub 2019 Per 16:46 tarihinde Jan Mercl <0xj...@gmail.com> şunu yazdı:
>
>> On Thu, Feb 21, 2019 at 2:38 PM Serhat Şevki Dinçer 
>> wrote:
>>
>> > waitempty(ch)
>> > blocks caller until ch buffer is empty
>>
>> Not exactly the same, but a similar mechanism exists:
>>
>> select {
>> case x := <-ch:
>> ...
>> default:
>> ... ch is empty
>> }
>>
>> > waitfull(ch)
>> > blocks caller until ch buffer is full
>>
>> Dtto
>>
>> select {
>> case ch <- x:
>> ...
>> default:
>> ... ch is full
>> }
>>
>>
>> > What do you think?
>>
>> That the above is enough of gears to implement what you're after.
>>
>> --
>>
>> -j
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Serhat Sevki Dincer]

meant has no guarantee

21 Şub 2019 Per 17:18 tarihinde Serhat Sevki Dincer 
şunu yazdı:

> 21 Şub 2019 Per 17:12 tarihinde Burak Serdar  şunu
> yazdı:
>
>> On Thu, Feb 21, 2019 at 6:51 AM Serhat Sevki Dincer 
>> wrote:
>> >
>> > But observer goroutines are not supposed to push to or pull from the
>> channel.
>>
>> What is a use case for observing a channel like this? If you call
>> waitempty(ch), when it returns ch may or may not be empty. Similar for
>> other functions. Looks like a good opportunity to create race
>> conditions.
>>
>
> By definition, waitempty(ch) returns "when" ch buffer is empty.
>
> Just after waitempty returns, ch buffer may or may not get new members.
> waitempty has guarantee that it will stay empty.
>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Serhat Sevki Dincer]

But observer goroutines are not supposed to push to or pull from the
channel.

21 Şub 2019 Per 16:46 tarihinde Jan Mercl <0xj...@gmail.com> şunu yazdı:

> On Thu, Feb 21, 2019 at 2:38 PM Serhat Şevki Dinçer 
> wrote:
>
> > waitempty(ch)
> > blocks caller until ch buffer is empty
>
> Not exactly the same, but a similar mechanism exists:
>
> select {
> case x := <-ch:
> ...
> default:
> ... ch is empty
> }
>
> > waitfull(ch)
> > blocks caller until ch buffer is full
>
> Dtto
>
> select {
> case ch <- x:
> ...
> default:
> ... ch is full
> }
>
>
> > What do you think?
>
> That the above is enough of gears to implement what you're after.
>
> --
>
> -j
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Jan Mercl]

On Thu, Feb 21, 2019 at 2:38 PM Serhat Şevki Dinçer 
wrote:

> waitempty(ch)
> blocks caller until ch buffer is empty

Not exactly the same, but a similar mechanism exists:

select {
case x := <-ch:
...
default:
... ch is empty
}

> waitfull(ch)
> blocks caller until ch buffer is full

Dtto

select {
case ch <- x:
...
default:
... ch is full
}


> What do you think?

That the above is enough of gears to implement what you're after.

-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Channel Feature Suggestion

[Serhat Şevki Dinçer]

Hi,

Say you have a buffered channel
ch := make(chan int, 10)

Would it make sense and be easy to add the following directives to the Go 
language core?

waitempty(ch)
blocks caller until ch buffer is empty

waitfull(ch)
blocks caller until ch buffer is full

This means there are 3 types of goroutines related to a channel:
- senders
- receivers
- observers

There are nice possibilities with these, for example wait groups, resource 
usage alerts etc.

What do you think?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Why does "go mod" ignore tags in this case?

[roger peppe]

I suspect it's because it's version 2. Major version v2 and above needs to
have the version in the import path.
So the correct import path for your package would be:

   github.com/twpayne/go-xdg/v2

It might be nice if the go tool complained about this at some stage of the
process; I suspect that's the role of the (currently non-existent) "go
release" tool.

  cheers,
rog.

On Wed, 20 Feb 2019 at 23:54,  wrote:

> tl;dr "go mod" writes a timestamp/commit hash to go.mod when a perfectly
> good tag exists. I don't understand why go.mod doesn't use the tag.
>
>
> Given this library
>
>   https://github.com/twpayne/go-xdg
>
> with a "v2.0.0" tag:
>
>   https://github.com/twpayne/go-xdg/releases/tag/v2.0.0
>
> if I create a trivial program that uses it, like
>
>   https://gist.github.com/twpayne/09e9135d3f62471ebd7c83359b081e80
>
> when I run the go command (e.g. go build), I end up with a go.mod file
> that contains
>
>   require github.com/twpayne/go-xdg v0.0.0-20190214203150-05c8dc503590
>
> whereas I would expect go.mod to contain
>
>   require github.com/twpayne/go-xdg v2.0.0
>
> Even I run the explicit command:
>
>   $ go get github.com/twpayne/go-xdg@v2.0.0
>
> go.mod still ends up containing the v0.0.0/timestamp/commit hash instead
> of v2.0.0.
>
>
> Why does go.mod contain v0.0.0/timestamp/commitHash instead of "v2.0.0"?
>
>
> Possibly relevant information:
> - I initially made a mistake tagging "v2.0.0", so the tag has moved since
> the go command first saw it. However, I also tried creating a new "v3.0.0"
> tag, but also saw the v0.0.0/timestamp/commit hash instead of the expected
> "v3.0.0".
> - I have GO111MODULE=on.
>
> Thanks for any insight :)
>
> Tom
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.