Re: [go-nuts] Re: Idiomatic way to reference custom error codes

2017. január 26., csütörtök 7:37:49 UTC+1 időpontban JohnGB a következőt írta: > > Since it is an HTTP Api, what about returning a standard HTTP status line, >> maybe with some non standard status code) and additional details about the >> error in the response body, JSON encoded? > > > That is e

[go-nuts] Re: Tracking down logic lock

Thanks, I just had a look and it is very similar to the output of http://127.0.0.1/debug/pprof/goroutine?debug=2 which I can already get to and I can’t see where the lock is left open! On Wed, Jan 25, 2017 at 9:17 PM Tamás Gulácsi wrote: > 2017. január 25., szerda 19:09:36 UTC+1 időpontban l...@

Re: [go-nuts] Re: Idiomatic way to reference custom error codes

Thanks Pierre, that looks like a simple and quite clean implementation. Although it's easier to use an iota for the numbering, does that open up any issues with keeping the documentation up to date? I know it's easier to program and extend, but it's also less obvious when codes change. Is there a

Re: [go-nuts] Re: Idiomatic way to reference custom error codes

> > Since it is an HTTP Api, what about returning a standard HTTP status line, > maybe with some non standard status code) and additional details about the > error in the response body, JSON encoded? That is exactly what we do. We return a HTTP status, but in addition, we return a JSON encoded b

RE: [go-nuts] Is Go too strict for nesting function callings?

I see it that the g(f()) special case is just that,a special case, added to make common use case less tedious. It's not an invitation to extend its rubbery semantics to all classes of function call. -- You received this message because you are subscribed to the Google Groups "golang-nuts" grou

RE: [go-nuts] Is Go too strict for nesting function callings?

Hi Dave. > The blame for this confusion comes from adding the special case, not from a > limitation of the general function call syntax. I see it differently. The limitation I'm referring to is "… arguments must be single-valued expressions assignable to the parameter types of F …". I b

Re: [go-nuts] Is Go too strict for nesting function callings?

I think you misunderstand. The exception is this form func f() (int, boo) func g1(int, bool) g1(f()) Not this form func g2(int, int, bool) g2(1, f()) The exception is the former form which is a special case for convenience. This special case creates confusion when people try the second form.

Re: [go-nuts] Priority cases in select?

Glad someone mentioned reflect.Select. Implemented simple round robin solution with a timeout case (if no data is available at all) using just that . To add to some priority would be just be a matter of setting the channel/cases to nil after several writes, rather than just after one like I do

RE: [go-nuts] Is Go too strict for nesting function callings?

Hi Ian. OK, I understand now. Btw - I wasn't proposing adding an exception, but removing a limitation and the exception due to it. :) John John Souvestre - New Orleans LA -Original Message- From: Ian Lance Taylor [mailto:i...@golang.org] Sent: 2017 January 25, Wed 19:18 To: Joh

Re: [go-nuts] Is Go too strict for nesting function callings?

On Wed, Jan 25, 2017 at 5:05 PM, John Souvestre wrote: > > Thanks! I see both the limitation and the exception. > > Other than implementation complexity, is there a reason for the limitation of > single-valued expressions? Is there some fundamental problem with allowing > multi-valued expressi

RE: [go-nuts] Is Go too strict for nesting function callings?

Hi Caleb. Thanks! I see both the limitation and the exception. Other than implementation complexity, is there a reason for the limitation of single-valued expressions? Is there some fundamental problem with allowing multi-valued expressions that I'm missing? John John Souvestre - New Or

Re: [go-nuts] Is Go too strict for nesting function callings?

https://golang.org/ref/spec#Calls Look for "As a special case, if the return values of a function or method g are equal in number" On Wed, Jan 25, 2017 at 4:42 PM, John Souvestre wrote: > Then I'm still confused. Where is this inconsistency / limitation / > non-orthogonal "syntactic sugar" def

RE: [go-nuts] Is Go too strict for nesting function callings?

Then I'm still confused. Where is this inconsistency / limitation / non-orthogonal "syntactic sugar" defined? I'm trying to understand why it exists if perhaps it isn't necessary. John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com [mailto:

RE: [go-nuts] Is Go too strict for nesting function callings?

It was just a turn of phrase, it's not a real rule. -- 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, vi

RE: [go-nuts] Is Go too strict for nesting function callings?

Hi Dave. I believe that the example I posed is more fundamental, but along the same lines, than the one posed by TL. Perhaps not... Regardless, what is the rule you referred to? And is there any disadvantage to allowing the "syntactic sugar" to work in all cases? John John Souvestre - N

Re: [go-nuts] Priority cases in select?

On Jan 25, 2017, at 8:00 AM, 'Axel Wagner' via golang-nuts wrote: > It's also a feature rabbit-hole. I'd predict, that next up, someone who > experiences starvation wants to add weighted scheduling ("give this case an > 80% chance of succeeding and this other case 20%, so that eventually eith

RE: [go-nuts] Is Go too strict for nesting function callings?

I think you're talking about a different example to TL. -- 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

Re: [go-nuts] Re: Priority cases in select?

Hi John, they are equivalent. I chose to not indent the second select. Your comment on the call to next being concurrent is the exact point of this program. It reveals the race condition between the first and second select and demonstrates that even if hi and lo are both ready, or hi became ready

RE: [go-nuts] Re: Priority cases in select?

Hi Val. Yes! Not all software races are critical. I would say that this is an example of a non-critical one, depending on your needs (is 1us resolution good enough?). The only software method of synchronizing events absolutely would probably would require locking the CPU's interrupts. :) D

RE: [go-nuts] Re: Priority cases in select?

Hi Paul. I looked at your code a bit more. I believe that there might be another problem. The call to “next” is concurrent with the setting of hi and low. This means that “next” might get through the first select, get paused, hi and low be set, then “next” continues and executes the secon

RE: [go-nuts] Re: Priority cases in select?

I believe that there is a typo in your example. It seems that you have separate selects instead of nested selects. Try: https://play.golang.org/p/YWYhnLJsdS John John Souvestre - New Orleans LA From: Paul Borman [mailto:bor...@google.com] Sent: 2017 January 25, Wed 16:01 To: Jo

RE: [go-nuts] Is Go too strict for nesting function callings?

Hi Dave. I'm trying to understand this. What is the rule? Does this mean that there is no way to call this function? func h(func()(int, bool)) {} Is there any disadvantage to not allowing the "syntactic sugar" to work in all cases? John John Souvestre - New Orleans LA -Original

Re: [go-nuts] Re: Priority cases in select?

Thank you John and Paul, I find this debate really interesting. > hi was clearly written before lo This is not my understanding of the memory model : because the channels are buffered, I can't really infer the "happens-before" relationship between the reading event of the channels. And even if t

Re: [go-nuts] Re: Priority cases in select?

I originally was thinking on the lines of what John said, but I proved it wrong, see https://play.golang.org/p/JwX_cxaR99 for the code. You can't run it in the playground, but on my MacPro I get output like: $ GOMAXPROCS=1 go run r.go Failed after 1137702 Failed after 699376 Failed after 757658 ^

[go-nuts] Is Go too strict for nesting function callings?

The confusion comes, like most cases in go, where a little syntactic sugar has been added to make the common case more appealing, but has the side effect of making the less common case more jarring. g1(f()) Is th exception to the rule. By _not_ requiring the caller to capture each value from

Re: [go-nuts] timer Reset concurrent to receive

I'm not going to debate it since I am not really volunteering to fix the docs right now, anyway :) My sense is that when I want to know how to use something, I run `go doc` on it. The doc as it stands says "don't do it" when the reality has an extra "unless ..." clause. Thanks for the guidance!

[go-nuts] Is Go too strict for nesting function callings?

package main import "fmt" func f() (int, bool) {return 1, false} func g1(int, bool) {} func g2(string, int, bool) {} func main() { fmt.Println(f()) // 1 false fmt.Println("a", f()) // multiple-value f() in single-value context g1(f()) // ok g2("a", f()) // multiple-value f()

[go-nuts] Re: Tracking down logic lock

2017. január 25., szerda 19:09:36 UTC+1 időpontban l...@pinkfroot.com a következőt írta: > > I seem to have an issue with logic in my code as from time to time it will > totally lock up the application and doing a dump of the goroutines shows > that they are all in the semacquire state. > > Is t

Re: [go-nuts] timer Reset concurrent to receive

On Wed, Jan 25, 2017 at 11:32 AM, Tim Hockin wrote: > Better to have a documented race than a potential hang, though, yeah? > If it delivers and then I Stop(), drain, Reset(), I might lose the > race, have the channel read by the concurrent receiver, and and just > block here. Or am I missing som

Re: [go-nuts] timer Reset concurrent to receive

Better to have a documented race than a potential hang, though, yeah? If it delivers and then I Stop(), drain, Reset(), I might lose the race, have the channel read by the concurrent receiver, and and just block here. Or am I missing some other nuance here? On Wed, Jan 25, 2017 at 11:21 AM, Ian L

RE: [go-nuts] Re: Priority cases in select?

I understand what you are saying, but all of these situations are basically race conditions, aren’t they? So there is no deterministic manner of resolving them. Thus it doesn’t matter which is chosen. However, in the more general, non-race, condition I believe that it meets the goals. Joh

Re: [go-nuts] timer Reset concurrent to receive

On Wed, Jan 25, 2017 at 10:30 AM, Tim Hockin wrote: > Thanks! That makes sense. Does it make sense to update the docs to > show the "select-with-default" mode of draining the channel instead? I guess I don't think so, as there is still a potential race with the other receive. I mean, we can ma

Re: [go-nuts] Re: Priority cases in select?

Doesn't work. If no communication can proceed when entering the select, this degenerates to a simple select. For example, say there are no writers to any of those channels. At the same time, that the last select is entered, three different goroutines start blocking to write to one of the channels e

RE: [go-nuts] Re: Priority cases in select?

> I don't believe the actual use case described can be mapped. From what I > understand, the intended behavior was > a) put the goroutine to sleep until some communication can proceed > b) if exactly one communication can proceed, do it > c) if multiple communications can proceed, choose the on

Re: [go-nuts] timer Reset concurrent to receive

Thanks! That makes sense. Does it make sense to update the docs to show the "select-with-default" mode of draining the channel instead? On Wed, Jan 25, 2017 at 10:20 AM, Ian Lance Taylor wrote: > On Wed, Jan 25, 2017 at 9:34 AM, 'Tim Hockin' via golang-nuts > wrote: >> I'm not convinced that t

Re: [go-nuts] timer Reset concurrent to receive

On Wed, Jan 25, 2017 at 9:34 AM, 'Tim Hockin' via golang-nuts wrote: > I'm not convinced that the docs quite cover the case I am looking, so > I am posting here. > > https://golang.org/pkg/time/#Timer.Reset says "This should not be done > concurrent to other receives from the Timer's channel" but

[go-nuts] Re: Idiomatic way to reference custom error codes

Il giorno mercoledì 25 gennaio 2017 18:16:33 UTC+1, JohnGB ha scritto: > > I have an HTTP API written in Go, and to give more fine grained responses > to the client app, we return our own error codes along with the standard > HTTP status codes Along a similar line to what Twitter does with its

[go-nuts] Tracking down logic lock

I seem to have an issue with logic in my code as from time to time it will totally lock up the application and doing a dump of the goroutines shows that they are all in the semacquire state. Is there any way without littering the console with logs to determine what had left the lock open at all

[go-nuts] Re: Idiomatic way to reference custom error codes

Maybe use a map along the lines of: https://play.golang.org/p/YDF4q6cTyX ? Le mercredi 25 janvier 2017 18:16:33 UTC+1, JohnGB a écrit : > > I have an HTTP API written in Go, and to give more fine grained responses > to the client app, we return our own error codes along with the standard > HTTP

[go-nuts] timer Reset concurrent to receive

I'm not convinced that the docs quite cover the case I am looking, so I am posting here. https://golang.org/pkg/time/#Timer.Reset says "This should not be done concurrent to other receives from the Timer's channel" but it's not clear what the repercussions are. In our case, I have a function to b

[go-nuts] Idiomatic way to reference custom error codes

I have an HTTP API written in Go, and to give more fine grained responses to the client app, we return our own error codes along with the standard HTTP status codes Along a similar line to what Twitter does with its error codes . The correct

Re: [go-nuts] Re: Priority cases in select?

Well, while this changes the random distribution, it still violates c. c specifically requires *deterministic* behavior in the case that multiple communications can proceed. I may be reading OP wrong, but from what I understand, the idea is that this test suite (roughly) is supposed to determinist

Re: [go-nuts] Re: Priority cases in select?

On Wed, Jan 25, 2017 at 5:00 PM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > I don't believe the actual use case described can be mapped. From what I understand, the intended behavior was > a) put the goroutine to sleep until some communication can proceed > b) if exactly

Re: [go-nuts] Re: Priority cases in select?

I don't believe the actual use case described can be mapped. From what I understand, the intended behavior was a) put the goroutine to sleep until some communication can proceed b) if exactly one communication can proceed, do it c) if multiple communications can proceed, choose the one with the hig

[go-nuts] Re: Priority cases in select?

On Wednesday, 25 January 2017 15:14:27 UTC+2, T L wrote: > > sometimes, I do want one case on a select block get selected even if there > are multiple unblocked cases. > For example, I don't want the dataCh case is selected if the stopCh and > the timer channel are unblocked: > > select { > case

Re: [go-nuts] GolangRT Docs?

On Wed, Jan 25, 2017 at 12:40 AM, josvazg wrote: > > Here are my takeaways (with a few questions): > > There is not a clearly defined GolangRT subset (at least for now), it is a > moving target requiring very low level knowledge on the compiler inner > workings. > For the runtime, implicit memory

Re: [go-nuts] Priority cases in select?

On Wednesday, January 25, 2017 at 10:14:49 PM UTC+8, Jan Mercl wrote: > > On Wed, Jan 25, 2017 at 2:14 PM T L > > wrote: > > > sometimes, I do want one case on a select block get selected even if > there are multiple unblocked cases. > > For example, I don't want the dataCh case is selected if

Re: [go-nuts] Priority cases in select?

On Wed, Jan 25, 2017 at 2:14 PM T L wrote: > sometimes, I do want one case on a select block get selected even if there are multiple unblocked cases. > For example, I don't want the dataCh case is selected if the stopCh and the timer channel are unblocked: select { case <-priorit

Re: [go-nuts] GolangRT Docs?

IIRC, even interface conversions would potentially allocate memory. (Correct me if I am wrong. It might have been changed.) And I wonder if the 'restrictions' can be checked through an external tool like 'go vet' or another rather than deep corners of the compiler? If so, that would be useful fo

[go-nuts] Priority cases in select?

sometimes, I do want one case on a select block get selected even if there are multiple unblocked cases. For example, I don't want the dataCh case is selected if the stopCh and the timer channel are unblocked: select { case <- stopCh: return case value := <-dataCh: } select { case <- time.A

Re: [go-nuts] Question regarding goroutines

On Wed, Jan 25, 2017, 4:25 PM Matt Harden wrote: > Yes, a hang in one goroutine will spread to the rest of the goroutines, > because the loop in engine() is run while holding the lock on the map. If > it hangs in Write(), any other goroutine trying to run engine() would block > on m.Lock(). > Wh

Re: [go-nuts] GolangRT Docs?

Thanks a lot Ian, that gives me a big picture of it! To clarify my question about the heap, it was wrongly written; I meant to say if all memory was kept in the stack (instead to the heap). You already it answered anyway. Here are my takeaways (with a few questions): 1. There is not a clear