Re: [go-nuts] Re: Interesting public commentary on Go...

[Lucio]

Well, the two enries are listed at the given URI, quite far apart and in 
the opposite order.

Could be a mistake or a bureaucratic glitch.

Lucio.

On Friday, 24 May 2019 08:49:18 UTC+2, Rob 'Commander' Pike wrote:
>
> If that's true - and it might well not be - it's a surprise to me. When 
> launching the language we explicitly made sure NOT to trademark it.
>
> -rob
>
>
> On Fri, May 24, 2019 at 10:50 AM Gerald Henriksen  > wrote:
>
>> On Fri, 24 May 2019 07:40:52 +1000, you wrote:
>>
>> >The last sentence of the article is not correct. The name Go is not
>> >trademarked by Google, at least as a programming language trademark. 
>> There
>> >are other things Google makes called Go (an interesting signal on its 
>> own)
>> >and they might be trademarked, but Go the language is not a trademark.
>>
>> The link provided in the blog post would seem to indicate otherwise.
>>
>> If one scrolls down the list the following 2 entries are of interest:
>>
>> Golang™ programming language
>> Go™ programming language
>>
>> https://www.google.com/permissions/trademark/trademark-list/
>>
>>

-- 
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/3871529c-47f9-4704-a7ee-e43c6e1a98a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[roger peppe]

On Thu, 23 May 2019 at 19:28, Bruno Albuquerque  wrote:

> This was my attempt at a channel with priorities:
>
>
> https://git.bug-br.org.br/bga/channels/src/master/priority/channel_adapter.go
>
> Based on the assumption that priorities only make sense if items are
> queued. If they are pulled out from a channel as fast as they are added to
> it, then there is no need for priorization.
>

I'm not entirely sure that's the right assumption. The original request is
about having priority
between different channels. If there's a value available on both channels,
you only ever want to
process the high priority one. With your code, however, if you've got two
goroutines sending and the
output channel is always ready to receive, the priority is decided by
goroutine scheduling, and
the low priority channel can win inappropriately:
https://play.golang.org/p/YBD_w5vVqjt

There are other issues too: the goroutine effectively acts as an infinite
buffer, so any back pressure
from the output channel is lost; if you have a slow receiver, you could use
a large amount of memory.
Also, if the input channel is closed, your code will discard any values in
the buffer: https://play.golang.org/p/5e_E17klnef
You perhaps want something a bit more like this:
https://play.golang.org/p/hPHSRvpsqxa

FWIW the classical way to address the original problem in Go AIUI is to
select on the
high priority channels first (with a default clause), and then block on all
the channels if there's
nothing immediately ready. This idiom is a bit tedious to generalise to
multiple channels (first select on c1, then c1, c2, then c1, c2, c3,
etc until finally select on c1, ... cN), but isn't two bad with two.

 https://play.golang.org/p/pkgZsgENdDb

  cheers,
rog.


>
> On Thu, May 23, 2019 at 1:38 AM roger peppe  wrote:
>
>> Oops, forgot to include the playground link at the end there:
>> https://play.golang.org/p/mYSRsGb4mRA
>>
>> On Thu, 23 May 2019 at 09:38, roger peppe  wrote:
>>
>>> On Thu, 23 May 2019 at 01:34, Anthony Metzidis <
>>> anthony.metzi...@gmail.com> wrote:
>>>
 Fun thought exercise -- here's another approach.


 https://play.golang.org/p/Xu7iWhY4PUQ

>>>
>>> ISTM that that approach doesn't work because you're buffering 10 values
>>> before you send any.
>>> So if you have a situation when you've got very little traffic on all
>>> the channels, a message might
>>> get delayed indefinitely.
>>>
>>> For example, here's your example with only one message being sent - it
>>> hasn't arrived
>>> at the receiver after 5 seconds have elapsed.
>>>
>>>   cheers,
>>> rog.
>>>
>>> --
>> 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/CAJhgaciGHN633%2BCWtYE6Gw4i8pdB9XoQ5HbOiHR1X06oJxMdCQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJhgacgN_OhK505k9gcufiK_GwwJBWx%3D9qv0wdU5oPg4ViQ6-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Interesting public commentary on Go...

[stephen]

I am a consumer of Go. As far as I am concerned, it has been a wonder of modern 
computing. And I have been programming for almost 40 years. 

As a cloud computing and data science polyglot, Go has become my go to language 
for systems control and critical web “glue” projects. It has been a joy to 
learn, with very little about it’s structure and syntax that made me scratch my 
head.

Most impressive is the efficiency, speed and scalability baked into this 
project. So whether the core team is at Google or not, the value of the core 
team originally being at Google in these areas is most apparent and appreciated.

Thank you to the many who created, evolve and maintain Go. Numerous people who 
likely will never comment here appreciate it. Of that I am confident. 

Best regards,
Stephen McDaniel
Principal Data Scientist
YakData, LLC

-- 
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/2a1f94f7-8f33-4b69-9a40-6af7ff6ae5e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Aggressive Golang Garbage Collection Issues When Using cgo?

[Ian Lance Taylor]

On Thu, May 23, 2019 at 9:05 PM  wrote:
>
> Is there something else I can try to isolate this (msan and race have not 
> been fruitful)? Note our C code has some memory sanity options in it too - we 
> have a storage manager in it that on request will over-allocate all requests 
> placing the requested storage in the middle, then back-filling all but the 
> requested storage with 0xdeadbeef values with the entire storage chain having 
> their backfills verified on every storage invocation. That too is running 
> clean. Also, the first thing our C code does when it gets control is take out 
> a lock because our C code is not (yet) multi-threaded so that part is 
> single-threaded.

I haven't looked at your code so I don't know if it will help, but you
can try setting the environment variable GODEBUG=cgocheck=2 when you
run the program.  That will turn on a more intensive set of tests for
whether you are violating the cgo pointer passing rules.

In general, read those rules, at https://golang.org/cmd/cgo, and make
sure that you are following them.

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/CAOyqgcX3HckyaypEgkPm%3DzSgBX-sLtjskA6NeuBbMncsnF%2BH7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Interesting public commentary on Go...

[Gerald Henriksen]

On Fri, 24 May 2019 01:30:02 -0700 (PDT), you wrote:

>Well, the two enries are listed at the given URI, quite far apart and in 
>the opposite order.

The list is alphabetical.

-- 
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/mvrfee96lechu0k90h7beds34s86sqt88s%404ax.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Interesting public commentary on Go...

[andrey mirtchovski]

On Fri, May 24, 2019 at 12:49 AM Rob Pike  wrote:
>
> If that's true - and it might well not be - it's a surprise to me. When 
> launching the language we explicitly made sure NOT to trademark it.
>

Go appears to be trademarked, as well as the new design of the Go
logo. Golang doesn't seem to be. Hopefully these links work:

http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4801:7mlvuo.5.15
http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4801:7mlvuo.5.14

Filing dates for both are August 2018, owner of the trademarks is Google.

-- 
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/CAK4xykV8YF21fncR-wLD-RL115o0eauDUJ19MhxMCrSOrAc7Qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[roger peppe]

On Fri, 24 May 2019 at 16:25, Bruno Albuquerque  wrote:

> On Fri, May 24, 2019 at 1:50 AM roger peppe  wrote:
>
>> On Thu, 23 May 2019 at 19:28, Bruno Albuquerque  wrote:
>>
>>> This was my attempt at a channel with priorities:
>>>
>>>
>>> https://git.bug-br.org.br/bga/channels/src/master/priority/channel_adapter.go
>>>
>>> Based on the assumption that priorities only make sense if items are
>>> queued. If they are pulled out from a channel as fast as they are added to
>>> it, then there is no need for priorization.
>>>
>>
>> I'm not entirely sure that's the right assumption. The original request
>> is about having priority
>> between different channels. If there's a value available on both
>> channels, you only ever want to
>> process the high priority one. With your code, however, if you've got two
>> goroutines sending and the
>> output channel is always ready to receive, the priority is decided by
>> goroutine scheduling, and
>> the low priority channel can win inappropriately:
>> https://play.golang.org/p/YBD_w5vVqjt
>>
>
> My code actually uses a single channel and deals with relative priorities
> between items added to the channel. The original problem can be morphed to
> this by using only 2 priorities. I honestly do not think that worrying
> about 2 values being sent by 2 different go routines at nearly the same
> time is something one needs to worry about. This is similar to having 2
> entries sent to individual channels at nearly the same time but with enough
> skew that the low priority one arrives before the higher priority one does
> (so it will be processed first unless there is a forced delay added (as
> seem on the other approach).
>

One example scenario when you might want to have priority receiving on two
different channels (which was after all the question that started this
thread), is when you're receiving messages from a high-volume buffered
channel, and a low volume synchronous channel (for example, a channel
returned from context.Done). If you get a value from the Done channel, you
want to quit as soon as possible. If you just use a regular select, you can
end up processing an unbounded number of messages before you decide to quit.

There is one big advantage with my solution: You can actually model any
> reasonable number of priorities you might need without any code changes
> whatsoever. It can handle 2 priorities as well as it can handle 100.
>

If I may say so, there's one significant disadvantage of your solution: it
doesn't solve the original problem :)

  cheers,
rog.

-- 
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/CAJhgacgcLCXykA%3D5y4izqVGeC%3D75Yw2qMZX6rcno19QkG5GcuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Aggressive Golang Garbage Collection Issues When Using cgo?

[zodness]

Thankyou for your reply - my responses are embedded below..


On Friday, May 24, 2019 at 1:12:43 AM UTC-4, Jan Mercl wrote:
>
> On Fri, May 24, 2019 at 3:05 AM > wrote: 
> > 
> > Unfortunately, after fitting the code with KeepAlive() calls (some 
> probably superfluous), the issues and their frequency have not notably 
> changed. It did allow me to remove the hack I had put in LockST() described 
> in my original note though. I've even gone as far as commenting out the 
> finalizers, which because of the flavor of the interface being used, 
> probably won't leave much if any C memory stranded but is not the way we 
> would want it in production. However it is fine for a test. Even with the 
> finalizers out of the way, the issues remain. 
> > 
> > Is there something else I can try to isolate this (msan and race have 
> not been fruitful)? Note our C code has some memory sanity options in it 
> too - we have a storage manager in it that on request will over-allocate 
> all requests placing the requested storage in the middle, then back-filling 
> all but the requested storage with 0xdeadbeef values with the entire 
> storage chain having their backfills verified on every storage invocation. 
> That too is running clean. Also, the first thing our C code does when it 
> gets control is take out a lock because our C code is not (yet) 
> multi-threaded so that part is single-threaded. 
>
> I took a look at the code. Some things that stand out immediately: 
>
> - Dozen of comments in Go code using "Golang" as the name of the language. 
>

[SEstes] I had been told by a Go consultant to refer to it as Golang to 
reduce confusion (much like how this forum is named). If that's in error I 
apologize and will change the references. But for the record, there are 13 
references to "golang" in the main directory, not dozens..

>
> - Yoda with happy is 
>
> func (buft *BufferT) Free() { 
> if nil == buft { 
> return 
> } 
> if true == buft.ownsBuff { 
> buft.cbuft.Free() 
> } 
> buft.cbuft = nil 
> } 
>
> (
> https://gitlab.com/YottaDB/Lang/YDBGo/blob/4a8c7ab467677c664e1a52ac2b87a9a537cbb605/buffer_t.go#L138)
>  
>
>
> - It seems that in more than one place the code violates the rules 
> about Go pointers crossing the CGo barrier, for example at 
>
> https://gitlab.com/YottaDB/Lang/YDBGo/blob/4a8c7ab467677c664e1a52ac2b87a9a537cbb605/buffer_t.go#L39


[SEstes] Since line 39 is a comment line in the header of a section, I'm 
not sure what code you are referring to. But the *only* place that we 
knowingly pass a pointer to golang storage into C is in the the key_t.go 
routines NodeNextST() and NodePrevST() where we pass a pointer to a Go 
uint32 into C (but do so as a C.int because that is what C expects). All 
other places where we pass structures or buffers into C we are passing the 
address of C.malloc()'d memory which is *anchored* in Go structures. This 
is permissible. What is not permissible is passing the address of a 
structure (Go or C) that contains pointers to Go storage (at least last I 
read - not sure if that has recently changed). We have tried to do what we 
needed to do without violating any cgo rules - which has been ..  at times 
difficult but I think we succeeded.

>
>
> - Exported API that has unsafe.Pointer typed parameters: 
>
> https://gitlab.com/YottaDB/Lang/YDBGo/blob/4a8c7ab467677c664e1a52ac2b87a9a537cbb605/buffer_t.go#L39
>  
> while not even mentioning what's safe to pass as the unsafe pointer 
> argument. Must it be only pointer to C allocated memory or can it be a 
> pointer to anything managed by the Go runtime? 
>

[SEstes] Admittedly this BufferTFromPtr routine could be documented better. 
While the existing comments and the name do mostly hint at its usage, I 
will update this to be more descriptive. The routine takes an unsafe 
pointer because it is driven by transaction callback routine so the overall 
topology is Go -> C -> Go but the C side of this interface has a generic 
parameter so it is passed as a void * in C which of course becomes an 
unsafe pointer in Go. From discussing with the group, the fact that this 
routine is exported is an artifact of an earlier version so it won't be 
exported in the next update.

>
> I looked at the code only for a few minutes, but the impression I got 
> is that this is not at all about "Aggressive Golang Garbage Collection 
> Issues When Using cgo". I think it instead about not 
> following/ignoring the documented rules for Go/CGo interaction as well 
> as not following/ignoring the documented rules about safe/supported 
> uses of unsafe.Pointers. 
>

[SEstes] The original problem which was described as being in LockST() was 
indeed due to aggressive GC and was cured by Ian's suggestion to use 
KeepAlive(). I thought the problems had a single origin but was evidently 
wrong. Something else is going on whic

Re: [go-nuts] Re: Interesting public commentary on Go...

[Michael Jones]

It is very good to have registered the marks to prevent abuse. Once owned,
the owner then has the ability to share as freely as desired, but in a
structured way (a la open source licenses) while holding questionable uses
at bay.

In my work this kind of control has demonstrated its importance. In the
creation of OpenGL ist SGI t was essential to have it mean something
specific API and conformance wise; in inventing Google Earth and growing it
and Google Maps to a billion unique monthly users it was important to
control the brands, including Keyhole's KML which I gave to the OGC; now as
a senior exec at Niantic, it seems more important than ever that Pokémon Go
is a carefully controlled name and mark--every knock-off product seems to
want to use our kind of "Go" as a marketing leverage (including "AR GO"
from Google, a Niantic investor, sigh).

May be a surprise to the Go team, but not to Kent Walker...
[image: Mark Image]
*Word Mark* *GO*
*Goods and Services* IC 009. US 021 023 026 036 038. G & S: Computer
programs and downloadable computer programs that implement a computer
programming language for use in developing, building and managing other
software. FIRST USE: 20091110. FIRST USE IN COMMERCE: 20091110
*Standard Characters Claimed*
*Mark Drawing Code* (4) STANDARD CHARACTER MARK
*Serial Number* 88100955
*Filing Date* August 31, 2018
*Current Basis* 1A
*Original Filing Basis* 1A
*Owner* (APPLICANT) Google LLC LIMITED LIABILITY COMPANY DELAWARE 1600
Amphitheatre Parkway Mountain View CALIFORNIA 94043
*Type of Mark* TRADEMARK
*Register* PRINCIPAL
*Live/Dead Indicator* LIVE


[image: Mark Image]
*Word Mark* *GO*
*Goods and Services* IC 009. US 021 023 026 036 038. G & S: Computer
programs and downloadable computer programs that implement a computer
programming language for use in developing, building and managing other
software
*Mark Drawing Code* (3) DESIGN PLUS WORDS, LETTERS, AND/OR NUMBERS
*Design Search Code* 26.17.01 - Bands, straight ; Bars, straight ; Lines,
straight ; Straight line(s), band(s) or bar(s)
26.17.06 - Bands, diagonal ; Bars, diagonal ; Diagonal line(s), band(s) or
bar(s) ; Lines, diagonal
*Serial Number* 88100957
*Filing Date* August 31, 2018
*Current Basis* 1B
*Original Filing Basis* 1B
*Owner* (APPLICANT) Google LLC LIMITED LIABILITY COMPANY DELAWARE 1600
Amphitheatre Parkway Mountain View CALIFORNIA 94043
*Description of Mark* Color is not claimed as a feature of the mark. The
mark consists of the stylized word GO with three small lines to the left of
the word.
*Type of Mark* TRADEMARK
*Register* PRINCIPAL

*Live/Dead Indicator*

-- 

*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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQzynsAnt5Lf4T4DHzeC_TU5NKSkLv0bDR%3DWogSZbLGUBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Aggressive Golang Garbage Collection Issues When Using cgo?

[Steven Estes]

Thankyou Ian,

I did try a few runs with GODEBUG set to "cgocheck=2" and just the "normal" 
errors (bad Go heap ptr, and sweep increased allocation) occurred. I'm 
assuming I would have seen a different kind of panic if it had detected 
something.

Like I mentioned in the last post, we are very careful not to pass Go 
memory to with one exception where we pass a pointer to a Go uint32 that we 
expect to be filled in by the call. My understanding is this is permitted 
(cgo does not complain though it is very quick to complain if I try to pass 
the address of a string or byte array or structure).

-- 
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/3e71a176-ef6f-4fad-b282-0318d47fda4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Aggressive Golang Garbage Collection Issues When Using cgo?

[Michael Jones]

and when you change that "pass a pointer" to "have a shim c-side function
return a uint32 that you just assign on the Go side," what happens?

On Fri, May 24, 2019 at 8:52 AM Steven Estes  wrote:

> Thankyou Ian,
>
> I did try a few runs with GODEBUG set to "cgocheck=2" and just the
> "normal" errors (bad Go heap ptr, and sweep increased allocation) occurred.
> I'm assuming I would have seen a different kind of panic if it had detected
> something.
>
> Like I mentioned in the last post, we are very careful not to pass Go
> memory to with one exception where we pass a pointer to a Go uint32 that we
> expect to be filled in by the call. My understanding is this is permitted
> (cgo does not complain though it is very quick to complain if I try to pass
> the address of a string or byte array or structure).
>
> --
> 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/3e71a176-ef6f-4fad-b282-0318d47fda4f%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQyW9o%2BqECobt356qt_AYnRAGdsE9KrDpzHUa73FoX%3DVSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Aggressive Golang Garbage Collection Issues When Using cgo?

[Steven Estes]

Since those C functions are already returning a return code through the 
return value and C only has one return, that's not really possible. I could 
allocate 4 bytes of C memory, pass the address to that, make the call, 
return the value and free the memory - and I will do that if we get to the 
point where those two functions are the last two not working but we aren't 
there yet. As I noted, just running DeleteE() is enough to get failures and 
there is NO passing of Go storage addresses to C in that path.

SteveE

On Friday, May 24, 2019 at 11:58:04 AM UTC-4, Michael Jones wrote:
>
> and when you change that "pass a pointer" to "have a shim c-side function 
> return a uint32 that you just assign on the Go side," what happens?
>
> -- 
>
> *Michael T. jonesmichae...@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/e20f4878-8b6c-4840-bc78-ec3c8e80efa2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[Bruno Albuquerque]

On Fri, May 24, 2019 at 8:40 AM roger peppe  wrote:

> On Fri, 24 May 2019 at 16:25, Bruno Albuquerque  wrote:
>
>> On Fri, May 24, 2019 at 1:50 AM roger peppe  wrote:
>>
>>> On Thu, 23 May 2019 at 19:28, Bruno Albuquerque  wrote:
>>>
 This was my attempt at a channel with priorities:


 https://git.bug-br.org.br/bga/channels/src/master/priority/channel_adapter.go

 Based on the assumption that priorities only make sense if items are
 queued. If they are pulled out from a channel as fast as they are added to
 it, then there is no need for priorization.

>>>
>>> I'm not entirely sure that's the right assumption. The original request
>>> is about having priority
>>> between different channels. If there's a value available on both
>>> channels, you only ever want to
>>> process the high priority one. With your code, however, if you've got
>>> two goroutines sending and the
>>> output channel is always ready to receive, the priority is decided by
>>> goroutine scheduling, and
>>> the low priority channel can win inappropriately:
>>> https://play.golang.org/p/YBD_w5vVqjt
>>>
>>
>> My code actually uses a single channel and deals with relative priorities
>> between items added to the channel. The original problem can be morphed to
>> this by using only 2 priorities. I honestly do not think that worrying
>> about 2 values being sent by 2 different go routines at nearly the same
>> time is something one needs to worry about. This is similar to having 2
>> entries sent to individual channels at nearly the same time but with enough
>> skew that the low priority one arrives before the higher priority one does
>> (so it will be processed first unless there is a forced delay added (as
>> seem on the other approach).
>>
>
> One example scenario when you might want to have priority receiving on two
> different channels (which was after all the question that started this
> thread), is when you're receiving messages from a high-volume buffered
> channel, and a low volume synchronous channel (for example, a channel
> returned from context.Done). If you get a value from the Done channel, you
> want to quit as soon as possible. If you just use a regular select, you can
> end up processing an unbounded number of messages before you decide to quit.
>

And you could easily do that with a select on the channel I return and the
done channel. Also this is a very specific scenario you propose. For
specific scenarios one can almost always find specific non-generic
solutions that are better than a generic one. My solution tries to address
the general case of dealing with prioritizing items in a channel.


> There is one big advantage with my solution: You can actually model any
>> reasonable number of priorities you might need without any code changes
>> whatsoever. It can handle 2 priorities as well as it can handle 100.
>>
>
> If I may say so, there's one significant disadvantage of your solution: it
> doesn't solve the original problem :)
>

You you take the original question literally, you are obvious right. But it
the original question can be relaxed to "I want to handle items with
different priorities" which, as I mentioned, the original problem can be
reduced to, then no, you are not.

Anyway, I am fine with agreeing to disagree.

-- 
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/CAEd86Tym8dvnBHQj6Oudyc_K31-HgG-s4cQjB%3DbNzSpX11HKtw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[Bruno Albuquerque]

On Fri, May 24, 2019 at 1:50 AM roger peppe  wrote:

> On Thu, 23 May 2019 at 19:28, Bruno Albuquerque  wrote:
>
>> This was my attempt at a channel with priorities:
>>
>>
>> https://git.bug-br.org.br/bga/channels/src/master/priority/channel_adapter.go
>>
>> Based on the assumption that priorities only make sense if items are
>> queued. If they are pulled out from a channel as fast as they are added to
>> it, then there is no need for priorization.
>>
>
> I'm not entirely sure that's the right assumption. The original request is
> about having priority
> between different channels. If there's a value available on both channels,
> you only ever want to
> process the high priority one. With your code, however, if you've got two
> goroutines sending and the
> output channel is always ready to receive, the priority is decided by
> goroutine scheduling, and
> the low priority channel can win inappropriately:
> https://play.golang.org/p/YBD_w5vVqjt
>

My code actually uses a single channel and deals with relative priorities
between items added to the channel. The original problem can be morphed to
this by using only 2 priorities. I honestly do not think that worrying
about 2 values being sent by 2 different go routines at nearly the same
time is something one needs to worry about. This is similar to having 2
entries sent to individual channels at nearly the same time but with enough
skew that the low priority one arrives before the higher priority one does
(so it will be processed first unless there is a forced delay added (as
seem on the other approach).


> There are other issues too: the goroutine effectively acts as an infinite
> buffer, so any back pressure
> from the output channel is lost; if you have a slow receiver, you could
> use a large amount of memory.
> Also, if the input channel is closed, your code will discard any values in
> the buffer: https://play.golang.org/p/5e_E17klnef
> You perhaps want something a bit more like this:
> https://play.golang.org/p/hPHSRvpsqxa
>

This was more a proof of concept than anything else. It would be trivial to
limit the number of inflight items at the cost off blocking on the input
channel. It is also trivial to empty the buffer before closing the output
channel (thanks for the suggestion).


> FWIW the classical way to address the original problem in Go AIUI is to
> select on the
> high priority channels first (with a default clause), and then block on
> all the channels if there's
> nothing immediately ready. This idiom is a bit tedious to generalise to
> multiple channels (first select on c1, then c1, c2, then c1, c2, c3,
> etc until finally select on c1, ... cN), but isn't two bad with two.
>
>  https://play.golang.org/p/pkgZsgENdDb
>

There is one big advantage with my solution: You can actually model any
reasonable number of priorities you might need without any code changes
whatsoever. It can handle 2 priorities as well as it can handle 100. In
fact if somehow if you end up with a lot of queued items at priority 100
but you really need something else to be processed immediately, you can
send it at priority 101 and that will work as expected.


>   cheers,
> rog.
>
>
>>
>> On Thu, May 23, 2019 at 1:38 AM roger peppe  wrote:
>>
>>> Oops, forgot to include the playground link at the end there:
>>> https://play.golang.org/p/mYSRsGb4mRA
>>>
>>> On Thu, 23 May 2019 at 09:38, roger peppe  wrote:
>>>
 On Thu, 23 May 2019 at 01:34, Anthony Metzidis <
 anthony.metzi...@gmail.com> wrote:

> Fun thought exercise -- here's another approach.
>
>
> https://play.golang.org/p/Xu7iWhY4PUQ
>

 ISTM that that approach doesn't work because you're buffering 10 values
 before you send any.
 So if you have a situation when you've got very little traffic on all
 the channels, a message might
 get delayed indefinitely.

 For example, here's your example with only one message being sent - it
 hasn't arrived
 at the receiver after 5 seconds have elapsed.

   cheers,
 rog.

 --
>>> 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/CAJhgaciGHN633%2BCWtYE6Gw4i8pdB9XoQ5HbOiHR1X06oJxMdCQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.g

[go-nuts] Is this a bug?

[Henry]

Hi, 

I stumbled across this weird behavior and I wonder whether this is a bug. 
Here is the simplified version of the problem (Playground link 
https://play.golang.org/p/mch6NQdTpr5):

package main

import (
"fmt"
)

func main() {
str := MyString("World")
var formatter Format
Print(formatter, str) //ERROR: have Format(StringerA) string, want 
Format(StringerB) string
}

//StringerA and StringerB are identical. Some may wonder why declare 
identical interfaces in the same package.
//In a real world example, they live in different packages. StringerA 
resides in Package A and StringerB is in Package B. 

type StringerA interface {
String() string
}

type StringerB interface {
String() string
}


//MyString is the concrete implementation of Stringer. It applies to both 
StringerA and StringerB.

type MyString string

func (m MyString) String() string {
return string(m)
}


//Then, we have the Formatter. FormatterA and FormatterB are supposed to be 
identical. They both accept a Stringer. 
//FormatterA accepts StringerA, because they are in the same package. 
FormatterB accepts StringerB. Package A and Package B
//are probably authored by different people and they define their own 
Stringer. However, since we are dealing with interfaces, 
//so behaviour-wise, they are supposed to be identical. They format a 
Stringer.

type FormatterA interface {
Format(StringerA) string
}

type FormatterB interface {
Format(StringerB) string
}


//Format is the concrete implementation of Formatter. In this case, Format 
is implemented by the author of Package A. Let's call him Author A.
//Hence, we see StringerA there because StringerA is Author A definition of 
Stringer. However, it is intended to work on any Stringer.

type Format struct{}

func (f Format) Format(s StringerA) string {
return fmt.Sprintf("Hello %s!", s)
}


//Print is written by Author B. She uses FormatterB and StringerB. Those 
interfaces are the 'contracts' she requires for her function to work. 
//Her intention is for Print to work with any Formatter and any Stringer. 
However, Go apparently treat FormatterA and FormatterB as being different.
//Is this a bug?

func Print(f FormatterB, s StringerB) {
fmt.Println(f.Format(s))
}


Thanks


Henry

-- 
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/e5eb2946-e865-40cd-b1f7-3d445d423e00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[Michael Jones]

I see an easy* way to implement channel priorities in Go2 if that is
desired.

two steps:

step 2: At lines 124 and 153-157 of src/runtime/select.go, an *order of
channel testing* index table is created, then permuted.
It is later visited in order. All that needs doing is to make the index
table larger by repeating channel indices based on relative priority.
example:

channels a,b,c of equal priority:
pollorder = permute[a,b,c]

channels a,b,c of priority a=5,b=2,c=1:

pollorder = permute[a,a,a,a,a b,b, c]


step 1:Somehow convey priorities from developer's Go source to select.go.
Open issue, many choices, matter of taste. One idea is explicit parameter
in select, another is to allow cases to repeat and count them, or
equivalently, allow the "comma list of channels" with repeats.

 select {
case msg1 := <-c1:
fmt.Println("received", msg1)
case msg1 := <-c1:
fmt.Println("received", msg1)
case msg2 := <-c2:
fmt.Println("received", msg2)
 }


 select {
case msg1 := <-c1, <-c1:
fmt.Println("received", msg1)
case msg2 := <-c2:
fmt.Println("received", msg2)
 }


Each of these means c1 is 2x and c2 is 1x out of a total of 3, for c1 is 2x
the priority of c2 and is selected 2/3 of the time on average when both
channels have data. Since a deranged developer might copy/paste the "<-c1"
a hundred times, and "<-c2" fifty, the compiler should preferably optimize:

g = gcd(list of priorities)

[list of priorities]/=g // defend against needless scales in priorities,
ivy-like syntax

Michael

*easy to conjecture.

On Fri, May 24, 2019 at 9:18 AM Bruno Albuquerque  wrote:

>
>
> On Fri, May 24, 2019 at 8:40 AM roger peppe  wrote:
>
>> On Fri, 24 May 2019 at 16:25, Bruno Albuquerque  wrote:
>>
>>> On Fri, May 24, 2019 at 1:50 AM roger peppe  wrote:
>>>
 On Thu, 23 May 2019 at 19:28, Bruno Albuquerque  wrote:

> This was my attempt at a channel with priorities:
>
>
> https://git.bug-br.org.br/bga/channels/src/master/priority/channel_adapter.go
>
> Based on the assumption that priorities only make sense if items are
> queued. If they are pulled out from a channel as fast as they are added to
> it, then there is no need for priorization.
>

 I'm not entirely sure that's the right assumption. The original request
 is about having priority
 between different channels. If there's a value available on both
 channels, you only ever want to
 process the high priority one. With your code, however, if you've got
 two goroutines sending and the
 output channel is always ready to receive, the priority is decided by
 goroutine scheduling, and
 the low priority channel can win inappropriately:
 https://play.golang.org/p/YBD_w5vVqjt

>>>
>>> My code actually uses a single channel and deals with relative
>>> priorities between items added to the channel. The original problem can be
>>> morphed to this by using only 2 priorities. I honestly do not think that
>>> worrying about 2 values being sent by 2 different go routines at nearly the
>>> same time is something one needs to worry about. This is similar to having
>>> 2 entries sent to individual channels at nearly the same time but with
>>> enough skew that the low priority one arrives before the higher priority
>>> one does (so it will be processed first unless there is a forced delay
>>> added (as seem on the other approach).
>>>
>>
>> One example scenario when you might want to have priority receiving on
>> two different channels (which was after all the question that started this
>> thread), is when you're receiving messages from a high-volume buffered
>> channel, and a low volume synchronous channel (for example, a channel
>> returned from context.Done). If you get a value from the Done channel, you
>> want to quit as soon as possible. If you just use a regular select, you can
>> end up processing an unbounded number of messages before you decide to quit.
>>
>
> And you could easily do that with a select on the channel I return and the
> done channel. Also this is a very specific scenario you propose. For
> specific scenarios one can almost always find specific non-generic
> solutions that are better than a generic one. My solution tries to address
> the general case of dealing with prioritizing items in a channel.
>
>
>> There is one big advantage with my solution: You can actually model any
>>> reasonable number of priorities you might need without any code changes
>>> whatsoever. It can handle 2 priorities as well as it can handle 100.
>>>
>>
>> If I may say so, there's one significant disadvantage of your solution:
>> it doesn't solve the original problem :)
>>
>
> You you take the original question literally, you are obvious right. But
> it the original question can be relaxed to "I want to handle items with
> different priorities" which, as I mentioned, the original problem can be
> reduced t

Re: [go-nuts] Is this a bug?

[Wagner Riffel]

It's not a bug, FormatterA and FormatterB method has different
signatures, they are not identical, one wants Format(StringerA) other
Format(StringerB), thus your Format type only implements FormatterA
but Print wants a FormatterB.

-- 
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/CAFEfeLx%3DLWw5oioneg%3DSFDABJTuM0z4F7fHygh5WFsxHkWgf5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Burak Serdar]

On Fri, May 24, 2019 at 10:55 AM Henry  wrote:
>
> Hi,
>
> I stumbled across this weird behavior and I wonder whether this is a bug. 
> Here is the simplified version of the problem (Playground link 
> https://play.golang.org/p/mch6NQdTpr5):

I believe this is working as intended because a type implements an
interface if it has the same method signatures as that interface, and
Format(StringerA) is different from Format(StringerB). However, I
wonder if there is any real reason why this is so because it appears
that the type comparison can be "isCompatible" instead of
"isIdentical" for the argument and return types, and things would
still work.

>
> package main
>
> import (
> "fmt"
> )
>
> func main() {
> str := MyString("World")
> var formatter Format
> Print(formatter, str) //ERROR: have Format(StringerA) string, want 
> Format(StringerB) string
> }
>
> //StringerA and StringerB are identical. Some may wonder why declare 
> identical interfaces in the same package.
> //In a real world example, they live in different packages. StringerA resides 
> in Package A and StringerB is in Package B.
>
> type StringerA interface {
> String() string
> }
>
> type StringerB interface {
> String() string
> }
>
>
> //MyString is the concrete implementation of Stringer. It applies to both 
> StringerA and StringerB.
>
> type MyString string
>
> func (m MyString) String() string {
> return string(m)
> }
>
>
> //Then, we have the Formatter. FormatterA and FormatterB are supposed to be 
> identical. They both accept a Stringer.
> //FormatterA accepts StringerA, because they are in the same package. 
> FormatterB accepts StringerB. Package A and Package B
> //are probably authored by different people and they define their own 
> Stringer. However, since we are dealing with interfaces,
> //so behaviour-wise, they are supposed to be identical. They format a 
> Stringer.
>
> type FormatterA interface {
> Format(StringerA) string
> }
>
> type FormatterB interface {
> Format(StringerB) string
> }
>
>
> //Format is the concrete implementation of Formatter. In this case, Format is 
> implemented by the author of Package A. Let's call him Author A.
> //Hence, we see StringerA there because StringerA is Author A definition of 
> Stringer. However, it is intended to work on any Stringer.
>
> type Format struct{}
>
> func (f Format) Format(s StringerA) string {
> return fmt.Sprintf("Hello %s!", s)
> }
>
>
> //Print is written by Author B. She uses FormatterB and StringerB. Those 
> interfaces are the 'contracts' she requires for her function to work.
> //Her intention is for Print to work with any Formatter and any Stringer. 
> However, Go apparently treat FormatterA and FormatterB as being different.
> //Is this a bug?
>
> func Print(f FormatterB, s StringerB) {
> fmt.Println(f.Format(s))
> }
>
>
> Thanks
>
>
> Henry
>
> --
> 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/e5eb2946-e865-40cd-b1f7-3d445d423e00%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqoW5xBT1vKDdNGWLMitXaMkFUypoNGhcVu0EyLVC4Q6_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[Daniela Petruzalek]

If I had to process messages from both high and low priority channels I
would serialise then with a min heap and create a consumer process for the
min heap. The min heap seems to be the canonical way of solving the
priority queues anyway, so I think it makes sense here.

Basically: goroutine 1 reads both channels and insert them into the
min-heap. goroutine 2 reads from min heap and do the processing.


Daniela Petruzalek
Software Engineer
github.com/danicat
twitter.com/danicat83


Em qui, 14 de fev de 2019 às 15:34,  escreveu:

> select {
> case highVal := <- high:
> case lowVal := <- low:
> if len(high) > 0 {
> for len(high) > 0 {
> highVal := <- high
> }
> }
> // process lowVal
> }
>
>
>
> On Tuesday, July 24, 2012 at 5:16:16 AM UTC+8, Erwin Driessens wrote:
>>
>> Hello,
>>
>> i wonder how to implement channel priorities nicely. Say there are two
>> channels, one with a higher priority than the other, and a goroutine
>> waiting for incoming data on these channels. I have read that select picks
>> a random case when multiple channels are ready. I thought of nesting
>> selects: putting the lower priority select in the default case of the
>> higher priority select, and have the default case of the inner (low
>> priority) select do nothing. This leads to a kind of busy wait loop. I
>> could call a short sleep, but that still isn't very clean. Is there a
>> better way?
>>
>> Why aren't the select cases evaluated in order?
>>
> --
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2B%3Diygt2bxH1E8fkD5JpPV1vKrz2ns%2BD5KpbhZ_SSm2vK%3Dds3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[Michael Jones]

Daniela, that seems an excellent solution.

On Fri, May 24, 2019 at 12:12 PM Daniela Petruzalek <
daniela.petruza...@gmail.com> wrote:

> If I had to process messages from both high and low priority channels I
> would serialise then with a min heap and create a consumer process for the
> min heap. The min heap seems to be the canonical way of solving the
> priority queues anyway, so I think it makes sense here.
>
> Basically: goroutine 1 reads both channels and insert them into the
> min-heap. goroutine 2 reads from min heap and do the processing.
>
>
> Daniela Petruzalek
> Software Engineer
> github.com/danicat
> twitter.com/danicat83
>
>
> Em qui, 14 de fev de 2019 às 15:34,  escreveu:
>
>> select {
>> case highVal := <- high:
>> case lowVal := <- low:
>> if len(high) > 0 {
>> for len(high) > 0 {
>> highVal := <- high
>> }
>> }
>> // process lowVal
>> }
>>
>>
>>
>> On Tuesday, July 24, 2012 at 5:16:16 AM UTC+8, Erwin Driessens wrote:
>>>
>>> Hello,
>>>
>>> i wonder how to implement channel priorities nicely. Say there are two
>>> channels, one with a higher priority than the other, and a goroutine
>>> waiting for incoming data on these channels. I have read that select picks
>>> a random case when multiple channels are ready. I thought of nesting
>>> selects: putting the lower priority select in the default case of the
>>> higher priority select, and have the default case of the inner (low
>>> priority) select do nothing. This leads to a kind of busy wait loop. I
>>> could call a short sleep, but that still isn't very clean. Is there a
>>> better way?
>>>
>>> Why aren't the select cases evaluated in order?
>>>
>> --
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CA%2B%3Diygt2bxH1E8fkD5JpPV1vKrz2ns%2BD5KpbhZ_SSm2vK%3Dds3w%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQwZ0mL-UptRZya17ak%2B4nPYz47tBNsOWNcZDtCWPAsTeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[Bruno Albuquerque]

This is what my solution does, except that it uses items associated with
priorities instead of 2 channels. if 2 channels are really needed for some
reason, it is easy to adapt the solution to this.


On Fri, May 24, 2019 at 12:12 PM Daniela Petruzalek <
daniela.petruza...@gmail.com> wrote:

> If I had to process messages from both high and low priority channels I
> would serialise then with a min heap and create a consumer process for the
> min heap. The min heap seems to be the canonical way of solving the
> priority queues anyway, so I think it makes sense here.
>
> Basically: goroutine 1 reads both channels and insert them into the
> min-heap. goroutine 2 reads from min heap and do the processing.
>
>
> Daniela Petruzalek
> Software Engineer
> github.com/danicat
> twitter.com/danicat83
>
>
> Em qui, 14 de fev de 2019 às 15:34,  escreveu:
>
>> select {
>> case highVal := <- high:
>> case lowVal := <- low:
>> if len(high) > 0 {
>> for len(high) > 0 {
>> highVal := <- high
>> }
>> }
>> // process lowVal
>> }
>>
>>
>>
>> On Tuesday, July 24, 2012 at 5:16:16 AM UTC+8, Erwin Driessens wrote:
>>>
>>> Hello,
>>>
>>> i wonder how to implement channel priorities nicely. Say there are two
>>> channels, one with a higher priority than the other, and a goroutine
>>> waiting for incoming data on these channels. I have read that select picks
>>> a random case when multiple channels are ready. I thought of nesting
>>> selects: putting the lower priority select in the default case of the
>>> higher priority select, and have the default case of the inner (low
>>> priority) select do nothing. This leads to a kind of busy wait loop. I
>>> could call a short sleep, but that still isn't very clean. Is there a
>>> better way?
>>>
>>> Why aren't the select cases evaluated in order?
>>>
>> --
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CA%2B%3Diygt2bxH1E8fkD5JpPV1vKrz2ns%2BD5KpbhZ_SSm2vK%3Dds3w%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEd86TzfnfJMWT8%3D%3Dz5yRMrk0gDZgOLpPLRUO6bdhqs_%2BLB_HQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Interesting public commentary on Go...

[Space A.]

Hi Pat,

I also have some (quite a lot) years of Java, and absolutely agree with 
everything you said.

And +1 to Ian's opinion on how free software projects must be driven.


On Friday, May 24, 2019 at 5:24:41 AM UTC+3, Pat Farrell wrote:
>
> On Thursday, May 23, 2019 at 9:18:25 AM UTC-4, lgo...@gmail.com wrote:
>>
>> https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage
>>
>
> Before I became a GO nut, I did 20 years of commercial Java. I became a 
> big fan of Google's Guava library.
> Guava was open source, but was driven by Google's needs. Outside 
> contributions were rare. I got used to it.
>
> I wonder if being "community driven" is really a good thing. GO was 
> invented by a tiny team with strict ideas. This is in strong contrast to 
> Java or C++, which are bloated and overly complex languages.
>
> There are times I'd rather not have something, say generics, rather than 
> pollute the simplicity of the tool to add features that the community 
> wants. IMHO, YMMV, etc. 
>

-- 
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/78f14964-930e-4160-95de-f3e56dffee6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Henry]

Thanks for the reply. 

Is there any specific use case that this intended behavior is supposed to 
solve? It appears to me that it is just a case of simplistic implementation 
where Go does not look deep enough to see if any dependent interfaces are 
identical. In this case, Go does not bother to look beyond Formatter 
interface in order to conclude whether FormatterA and FormatterB are 
identical. In here, I define 'identical' as being interchangeable, rather 
than semantic equality. So when I refer to TypeA and TypeB as identical, it 
means you can use TypeA in place of TypeB, and vice versa. 

Back to the actual situation, Package A and Package B are developed in 
tandem by different teams. They have some communication on how their 
components will interact with each other and fit the bigger picture. They 
use interface to define contracts that are required in order for their 
components to work. Since Go interface is implicit, this is supposed to 
work fine. As an example, if I were to reduce the prior example as follows, 
it works fine. (Link to the playground: 
https://play.golang.org/p/zrpjSYTIyxZ)

import (
"fmt"
)

func main() {
str := MyString("Hello world!")
Print(str)

strA:=StringerA(str)
Print(strA)
}

type StringerA interface {
String() string
}

type StringerB interface {
String() string
}

type MyString string

func (s MyString) String() string {
return string(s)
}

func Print(s StringerB) {
fmt.Println(s.String())
}

However, when I add a more complex interface, as in the first example 
involving Formatter, it breaks. Go fails to recognize that FormatterA and 
FormatterB are interchangeable despite the facts that their dependencies 
(StringerA and StringerB) are interchangeable. Visually, the components 
should look like this:

[image: go.png]
Let me know what you think.

Thanks.

Henry

On Saturday, May 25, 2019 at 1:54:11 AM UTC+7, Wagner Riffel wrote:
>
> It's not a bug, FormatterA and FormatterB method has different 
> signatures, they are not identical, one wants Format(StringerA) other 
> Format(StringerB), thus your Format type only implements FormatterA 
> but Print wants a FormatterB. 
>

-- 
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/3280cda6-ba3e-4847-a23e-5b1c6d5128be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Henry]

The posted diagram isn't correct. Updated the diagram with the new one.

[image: go1.png]


On Saturday, May 25, 2019 at 10:38:42 AM UTC+7, Henry wrote:
>
> Thanks for the reply. 
>
> Is there any specific use case that this intended behavior is supposed to 
> solve? It appears to me that it is just a case of simplistic implementation 
> where Go does not look deep enough to see if any dependent interfaces are 
> identical. In this case, Go does not bother to look beyond Formatter 
> interface in order to conclude whether FormatterA and FormatterB are 
> identical. In here, I define 'identical' as being interchangeable, rather 
> than semantic equality. So when I refer to TypeA and TypeB as identical, it 
> means you can use TypeA in place of TypeB, and vice versa. 
>
> Back to the actual situation, Package A and Package B are developed in 
> tandem by different teams. They have some communication on how their 
> components will interact with each other and fit the bigger picture. They 
> use interface to define contracts that are required in order for their 
> components to work. Since Go interface is implicit, this is supposed to 
> work fine. As an example, if I were to reduce the prior example as follows, 
> it works fine. (Link to the playground: 
> https://play.golang.org/p/zrpjSYTIyxZ)
>
> import (
> "fmt"
> )
>
> func main() {
> str := MyString("Hello world!")
> Print(str)
> 
> strA:=StringerA(str)
> Print(strA)
> }
>
> type StringerA interface {
> String() string
> }
>
> type StringerB interface {
> String() string
> }
>
> type MyString string
>
> func (s MyString) String() string {
> return string(s)
> }
>
> func Print(s StringerB) {
> fmt.Println(s.String())
> }
>
> However, when I add a more complex interface, as in the first example 
> involving Formatter, it breaks. Go fails to recognize that FormatterA and 
> FormatterB are interchangeable despite the facts that their dependencies 
> (StringerA and StringerB) are interchangeable. Visually, the components 
> should look like this:
>
> [image: go.png]
> Let me know what you think.
>
> Thanks.
>
> Henry
>
> On Saturday, May 25, 2019 at 1:54:11 AM UTC+7, Wagner Riffel wrote:
>>
>> It's not a bug, FormatterA and FormatterB method has different 
>> signatures, they are not identical, one wants Format(StringerA) other 
>> Format(StringerB), thus your Format type only implements FormatterA 
>> but Print wants a FormatterB. 
>>
>

-- 
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/86e27716-0dbc-42bd-9c81-45243988c3b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Dan Kortschak]

The interfaces that define the contracts should come from a third
package/source. The issue that I suspect you are hitting is that type
identity for interface types is based on the name, not the method set.
This means that, for example with your code below a function
PrintB(StringerB) and another function PrintA(StringerA) are not
assignable to the same variable unless it is type interface{}.

https://play.golang.org/p/a8aWwA6CAB_K // remove comment to see failure

On Fri, 2019-05-24 at 20:38 -0700, Henry wrote:
> Thanks for the reply. 
> 
> Is there any specific use case that this intended behavior is
> supposed to 
> solve? It appears to me that it is just a case of simplistic
> implementation 
> where Go does not look deep enough to see if any dependent interfaces
> are 
> identical. In this case, Go does not bother to look beyond Formatter 
> interface in order to conclude whether FormatterA and FormatterB are 
> identical. In here, I define 'identical' as being interchangeable,
> rather 
> than semantic equality. So when I refer to TypeA and TypeB as
> identical, it 
> means you can use TypeA in place of TypeB, and vice versa. 
> 
> Back to the actual situation, Package A and Package B are developed
> in 
> tandem by different teams. They have some communication on how their 
> components will interact with each other and fit the bigger picture.
> They 
> use interface to define contracts that are required in order for
> their 
> components to work. Since Go interface is implicit, this is supposed
> to 
> work fine. As an example, if I were to reduce the prior example as
> follows, 
> it works fine. (Link to the playground: 
> https://play.golang.org/p/zrpjSYTIyxZ)
> 
> import (
> "fmt"
> )
> 
> func main() {
> str := MyString("Hello world!")
> Print(str)
> 
> strA:=StringerA(str)
> Print(strA)
> }
> 
> type StringerA interface {
> String() string
> }
> 
> type StringerB interface {
> String() string
> }
> 
> type MyString string
> 
> func (s MyString) String() string {
> return string(s)
> }
> 
> func Print(s StringerB) {
> fmt.Println(s.String())
> }
> 
> However, when I add a more complex interface, as in the first
> example 
> involving Formatter, it breaks. Go fails to recognize that FormatterA
> and 
> FormatterB are interchangeable despite the facts that their
> dependencies 
> (StringerA and StringerB) are interchangeable. Visually, the
> components 
> should look like this:
> 
> [image: go.png]
> Let me know what you think.
> 
> Thanks.
> 
> Henry
> 
> On Saturday, May 25, 2019 at 1:54:11 AM UTC+7, Wagner Riffel wrote:
> > 
> > It's not a bug, FormatterA and FormatterB method has different 
> > signatures, they are not identical, one wants Format(StringerA)
> > other 
> > Format(StringerB), thus your Format type only implements
> > FormatterA 
> > but Print wants a FormatterB. 
> > 
> 
> 

-- 
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/71965bccd27ed0288b09f9b5b1b3dfc75b3a4ef2.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Some questions about the go.sum file content.

[T L]

Do the hashes recorded in go.sum file come from calculating local cached 
modules or from sumdb?

When I clone a main module with complete go.sum files from internet and run 
"go build",
when internet connects the "go build" will make?

-- 
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/6741eaa8-c039-4e3a-a5be-07877fce0d5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.