Re: [go-nuts] Where is my memory in Linux?

[ppcfan]

We started this Go application by supervisor, so this Go app should be the 
subprocess of supervisor. Do you think it is the problem?

On Saturday, February 3, 2018 at 3:18:02 AM UTC+8, Justin Israel wrote:
>
>
>
> On Sat, Feb 3, 2018, 2:21 AM Zhang Rui  
> wrote:
>
>> Hello gophers, 
>>
>> I have a VM on Linode.com. OS is Cent OS 6.8 and kernel 
>> is 4.14.12-x86_64-linode92. It has 1 CPU core and 2G RAM.
>> A Go application is running on this VM.
>> Free memory on this VM is 490M (with buffer and cache), The RSS value of 
>> this Go application is only 12M. After I kill this Go app, free memory will 
>> increase to 950M. I have called Debug.FreeOSMemory() in this Go app every 
>> minute.
>> Sometimes, free memory will be decreased to 0 and this Go app will be 
>> killed by oom-killer. Does anyone know where is my memory?
>>
>
> Does your program make use of cgo to call into C/C++? Does it launch 
> subprocesses? 
>
>>
>> -- 
>> 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: “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[as]

I would rank them mostly unused. There was a point someone made in the past 
how choosing between design patterns is the equivalent of choosing calling 
conventions for functions, I don't remember the source, but I agree with 
the comparison. Most of these are superseded by struct and interface 
composition, along with general interface use. I've recently seen a factory 
in Go, it was rewritten into explicit declaration and this simplified the 
code. The visitor "pattern" is just a function that gets called for a 
traversed composite structure like a list or tree (see filepath.Walk). 

On Friday, February 2, 2018 at 9:03:54 AM UTC-8, matthe...@gmail.com wrote:
>
> I’m looking at patterns summarized on Wikipedia from “Design Patterns: 
> Elements of Reusable Object-Oriented Software” and writing out a few as the 
> equivalent in Go.
>
> Visitor: https://play.golang.org/p/A5tNzxMmetH
>
> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>
> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>
> Facade: https://play.golang.org/p/forPdwy9VCi
>
> Proxy: https://play.golang.org/p/DFWuDPTOzEP
>
> I’m curious how more experienced people rank these and the other patterns.
>
> Matt
>

-- 
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] Where is my memory in Linux?

[Zhang Rui]

Thank you for your reply.

No, this app doesn't use cgo. It's a pure Go application. Another go 
application on this VM used cgo. But it also should not launch the 
subprocesses.


在 2018年2月3日星期六 UTC+8上午3:18:02，Justin Israel写道：
>
>
>
> On Sat, Feb 3, 2018, 2:21 AM Zhang Rui  
> wrote:
>
>> Hello gophers, 
>>
>> I have a VM on Linode.com. OS is Cent OS 6.8 and kernel 
>> is 4.14.12-x86_64-linode92. It has 1 CPU core and 2G RAM.
>> A Go application is running on this VM.
>> Free memory on this VM is 490M (with buffer and cache), The RSS value of 
>> this Go application is only 12M. After I kill this Go app, free memory will 
>> increase to 950M. I have called Debug.FreeOSMemory() in this Go app every 
>> minute.
>> Sometimes, free memory will be decreased to 0 and this Go app will be 
>> killed by oom-killer. Does anyone know where is my memory?
>>
>
> Does your program make use of cgo to call into C/C++? Does it launch 
> subprocesses? 
>
>>
>>
>> -- 
>> 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] Re: Relaxing rules on slice comparison: would it make sense?

['Axel Wagner' via golang-nuts]

On Fri, Feb 2, 2018 at 9:59 PM,  wrote:
>
> Each path represented as a slice of coordinates could be easily encoded to
> a string and compared that way.
>

Ah, I misunderstood "path".


>
> As far as resource expenses go, we'd need benchmarks to say much. I
> understand looking at expensive cases too, but that doesn't mean that there
> aren't smaller regular use cases. Goroutines can be overused too.
>
> Matt
>
> On Wednesday, January 31, 2018 at 10:24:30 AM UTC-6, rog wrote:
>>
>> On 30 January 2018 at 23:19,   wrote:
>> >> - When slices can be compared, they can be used as map keys. What
>> happens
>> >> if the contents of a slice are changed after it has been added to a
>> map?
>> >
>> >
>> > I’m not too familiar with Go map internals, but my thought is the key
>> hash
>> > would depend on the backing array values. Go maps also allow reading
>> the
>> > keys back using iteration so the slice backing array (up to length)
>> would
>> > have to be copied. If the slice contents are changed then that would be
>> a
>> > different key and the original key would be intact.
>>
>> Note that copying the slice contents to make a map key implies
>> that using a slice as a map key might imply copying a whole tree,
>> which seems rather expensive to me (especially as it might end up
>> using more memory than the original if some elements are duplicated,
>> unless an alias-aware copy algorithm is used which would be
>> more expensive still)
>>
>> BTW you can already do something like this:
>> https://play.golang.org/p/q4bz8-AckN3
>>
>> You can even do it without reflect, which I'll leave as an exercise
>> for the reader :)
>>
> --
> 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: Relaxing rules on slice comparison: would it make sense?

[matthewjuran]

>
> Are you sure that's the only edge-case? Because this thread is kinda long 
> and there might even be things we are not thinking about. 


In the original discussion above I see one opinion toward comparing headers 
and four toward by element values (like strings). I didn't see any 
additional edge cases listed.

The usecase you mentioned above seems - to me - to be served by a 
> map[string]*T just fine. Did I misunderstand it?


Each path represented as a slice of coordinates could be easily encoded to 
a string and compared that way.

As far as resource expenses go, we'd need benchmarks to say much. I 
understand looking at expensive cases too, but that doesn't mean that there 
aren't smaller regular use cases. Goroutines can be overused too.

Matt

On Wednesday, January 31, 2018 at 10:24:30 AM UTC-6, rog wrote:
>
> On 30 January 2018 at 23:19,   wrote: 
> >> - When slices can be compared, they can be used as map keys. What 
> happens 
> >> if the contents of a slice are changed after it has been added to a 
> map? 
> > 
> > 
> > I’m not too familiar with Go map internals, but my thought is the key 
> hash 
> > would depend on the backing array values. Go maps also allow reading the 
> > keys back using iteration so the slice backing array (up to length) 
> would 
> > have to be copied. If the slice contents are changed then that would be 
> a 
> > different key and the original key would be intact. 
>
> Note that copying the slice contents to make a map key implies 
> that using a slice as a map key might imply copying a whole tree, 
> which seems rather expensive to me (especially as it might end up 
> using more memory than the original if some elements are duplicated, 
> unless an alias-aware copy algorithm is used which would be 
> more expensive still) 
>
> BTW you can already do something like this: 
> https://play.golang.org/p/q4bz8-AckN3 
>
> You can even do it without reflect, which I'll leave as an exercise 
> for the reader :) 
>

-- 
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] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[matthewjuran]

Here’s my proxy example with “func (a ProxyCar) Drive()” instead of 
DriveCar (I didn’t think this would work), and an F-150: 
https://play.golang.org/p/drDDkx_e0Mp

This may fix the signature difference but I see that having an interface 
type like you suggested for car would allow other data and methods that 
vary between cars to be held there. The original example from Wikipedia 
would probably need to be more complex to show a use case of the proxy 
pattern.

I think I see what you mean by this being more related to interceptor. My 
thought was the point was to add the additional behavior of checking for 
age on the ProxyCar type.

Thanks Josh.

Matt

On Friday, February 2, 2018 at 1:36:03 PM UTC-6, Joshua Humphries wrote:
>
> I didn't get a chance to look at all of them, but your Proxy pattern 
> example is incorrect.
>
> The idea of a proxy is that the proxy object exposes the same interface as 
> the underlying object, so they are substitutable. 
>
> In your example, Car is concrete (meaning that callers cannot substitute 
> any other type in its place). Also, the signature of the operation on Car 
> differs from the one on the Proxy that is meant to wrap it. Here's a fixed 
> version: https://play.golang.org/p/gq6Koi8f6XC
>
> I'll also pointed out that the example code -- which I see is 
> transliterated from the code snippets in Wikipedia -- likes more like its a 
> related pattern: the decorator (sometimes known as the interceptor pattern).
>
> 
> *Josh Humphries*
> jh...@bluegosling.com 
>
> On Fri, Feb 2, 2018 at 12:03 PM,  
> wrote:
>
>> I’m looking at patterns summarized on Wikipedia from “Design Patterns: 
>> Elements of Reusable Object-Oriented Software” and writing out a few as the 
>> equivalent in Go.
>>
>> Visitor: https://play.golang.org/p/A5tNzxMmetH
>>
>> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>>
>> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>>
>> Facade: https://play.golang.org/p/forPdwy9VCi
>>
>> Proxy: https://play.golang.org/p/DFWuDPTOzEP
>>
>> I’m curious how more experienced people rank these and the other patterns.
>>
>> Matt
>>
>> -- 
>> 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] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[Josh Humphries]

I didn't get a chance to look at all of them, but your Proxy pattern
example is incorrect.

The idea of a proxy is that the proxy object exposes the same interface as
the underlying object, so they are substitutable.

In your example, Car is concrete (meaning that callers cannot substitute
any other type in its place). Also, the signature of the operation on Car
differs from the one on the Proxy that is meant to wrap it. Here's a fixed
version: https://play.golang.org/p/gq6Koi8f6XC

I'll also pointed out that the example code -- which I see is
transliterated from the code snippets in Wikipedia -- likes more like its a
related pattern: the decorator (sometimes known as the interceptor pattern).


*Josh Humphries*
jh...@bluegosling.com

On Fri, Feb 2, 2018 at 12:03 PM,  wrote:

> I’m looking at patterns summarized on Wikipedia from “Design Patterns:
> Elements of Reusable Object-Oriented Software” and writing out a few as the
> equivalent in Go.
>
> Visitor: https://play.golang.org/p/A5tNzxMmetH
>
> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>
> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>
> Facade: https://play.golang.org/p/forPdwy9VCi
>
> Proxy: https://play.golang.org/p/DFWuDPTOzEP
>
> I’m curious how more experienced people rank these and the other patterns.
>
> Matt
>
> --
> 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] Where is my memory in Linux?

[Justin Israel]

On Sat, Feb 3, 2018, 2:21 AM Zhang Rui  wrote:

> Hello gophers,
>
> I have a VM on Linode.com. OS is Cent OS 6.8 and kernel
> is 4.14.12-x86_64-linode92. It has 1 CPU core and 2G RAM.
> A Go application is running on this VM.
> Free memory on this VM is 490M (with buffer and cache), The RSS value of
> this Go application is only 12M. After I kill this Go app, free memory will
> increase to 950M. I have called Debug.FreeOSMemory() in this Go app every
> minute.
> Sometimes, free memory will be decreased to 0 and this Go app will be
> killed by oom-killer. Does anyone know where is my memory?
>

Does your program make use of cgo to call into C/C++? Does it launch
subprocesses?


>
>
> 
>
>
>
> 
>
>
>
>
> 
>
>
>
>
> 
>
>
>
>
>
> 
>
> --
> 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] Rate controlling the Go http server

[mrx]

Thanks again, much appreciated!

Patrik Iselind

Den 2 feb. 2018 16:33 skrev "Henrik Johansson" :

> Happy to help!
>
> The limit can be anything from the link above or something more advanced
> that Jesper suggested. The skeleton could be as outlined above however.
>
> On Fri, Feb 2, 2018, 15:40 mrx  wrote:
>
>> On Fri, Feb 2, 2018 at 1:28 PM, Henrik Johansson 
>> wrote:
>>
>>> You can either use one of the existing other routers that have
>>> meddleware support or you could wrap your handlers in another handler much
>>> like this:
>>>
>>> handle("/foo",wrapHandler(rateLimiter, realHandler))
>>>
>>> func wrapHandler(limit *ARateLimiter, handler func(http.ResponseWriter,
>>> *http.Request)) func(http.ResponseWriter, *http.Request){
>>>   return func(w http.ResponseWriter, r *http.Request) {
>>>limit.Aquire() //Or however you use the limiter
>>>handle(w,r)
>>>  }
>>> }
>>>
>>> Very rudimentary and simplified but could perhaps work. You can wrap any
>>> handler in the same way with either a shared limiter or one per call or any
>>> combination.
>>>
>>
>> Feels like your limit parameter is simply a semaphore to me. I'll try
>> that for now. Thanks a lot for your help, it was most illuminating!
>>
>> // Patrik
>>
>

-- 
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: any discourse-like forum in Go?

[Sebastien Binet]

On Wed, Jan 31, 2018 at 5:28 PM, Sebastien Binet 
wrote:

> hi there,
>
> I am looking for a discourse-like forum, in Go. Does anybody know of such
> a thing?
>
> Interestingly, reading the https://blog.golang.org/hello-china post, I
> stumbled upon:
>
> - https://gocn.io
>
> which could be just what I am looking for, but there are no link to any
> github repo... :}
> (and my chinese is... limited.)
>
> -s
>
> PS: cross-posted on reddit too...
> https://www.reddit.com/r/golang/comments/7ub10v/any_
> discourselike_forum_in_go/
>

FYI, I got an interesting candidate on the reddit forum:

- https://github.com/disintegration/bebop

It doesn't provide everything that I'd like but it's a start (that I can
build upon)

-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] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[matthewjuran]

I’m looking at patterns summarized on Wikipedia from “Design Patterns: 
Elements of Reusable Object-Oriented Software” and writing out a few as the 
equivalent in Go.

Visitor: https://play.golang.org/p/A5tNzxMmetH

Abstract Factory: https://play.golang.org/p/SWwuX49eysd

Factory Method: https://play.golang.org/p/FRgDBx2CLFf

Facade: https://play.golang.org/p/forPdwy9VCi

Proxy: https://play.golang.org/p/DFWuDPTOzEP

I’m curious how more experienced people rank these and the other patterns.

Matt

-- 
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 is the omitted expression in a swtich code block a typed bool "true"?

['Axel Wagner' via golang-nuts]

I did end up asking git, why this was done and it gave this answer
,
which links to this discussion .

Hope that helps

On Fri, Feb 2, 2018 at 5:18 PM,  wrote:

>
>
> On Friday, February 2, 2018 at 10:45:58 AM UTC-5, Axel Wagner wrote:
>>
>> From the spec:
>>
>>
>>> If the switch expression evaluates to an untyped constant, it is first
>>> converted to its default type; if it is an untyped boolean value, it is
>>> first converted to type bool. The predeclared untyped value nil cannot be
>>> used as a switch expression.
>>
>>
>> The current behavior is still as specified. Given that there is an
>> explicit statement about how this is handled makes it less convincing,
>> however, that the spec would be more complicated with a different behavior.
>> So you might still file a language change request, if you want.
>>
>
> but, why design as such? Isn't untyped bool more convenient?
>
>
>>
>> On Fri, Feb 2, 2018 at 4:39 PM,  wrote:
>>
>>>
>>>
>>> On Friday, February 2, 2018 at 10:37:24 AM UTC-5, di...@veryhaha.com
>>> wrote:
>>>


 On Friday, February 2, 2018 at 10:27:04 AM UTC-5, Ian Lance Taylor
 wrote:
>
> On Fri, Feb 2, 2018 at 7:10 AM,   wrote:
> >
> > Why not make it untyped?
> >
> > package main
> >
> > type T bool
> >
> > func f() T {return T(false)}
> >
> > func main() {
> > switch {
> > case f(): // invalid case f() in switch (mismatched types T and
> bool)
> > }
> > }
>
> The current language spec says that omitting the switch expression is
> equivalent to writing `true`.  If you actually write `true`, then,
> following the usual rules for untyped constant expressions, it will
> receive the type `bool`, and you would get the same mismatched type
> error.  You will see a similar case if you write `switch 0` and try to
> compare with a named version of `int`.  So the compiler is following
> the language spec as currently written.
>
> We could change the language spec to say that omitting the switch
> expression is not equivalent to writing `true`, but instead, as you
> suggest, compares each case to an untyped `true` value.  I think the
> main argument against that is that it makes the spec slightly more
> complicated while bringing very little benefit.  You could write it up
> as a language change proposal if you like.
>
> Ian
>

 > If you actually write `true`, then,
 > following the usual rules for untyped constant expressions,
 > it will receive the type `bool`,

 But, in my expression, the result of a constant expression is still
 untyped.
 And "true" is a per-declared untyped boolean value.

 And, here is another example to should the untyped result is converted
 to type "bool":

>>> and sorry again, here "should", I mean "show".
>>>
>>>

 package main

 type T bool

 func f() T {return T(false)}

 func main() {
 switch true == true {
 case f(): // invalid case f() in switch (mismatched types T and
 bool)
 }
 }


 --
>>> 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] Why is the omitted expression in a swtich code block a typed bool "true"?

[digg]

On Friday, February 2, 2018 at 10:45:58 AM UTC-5, Axel Wagner wrote:
>
> From the spec:
>  
>
>> If the switch expression evaluates to an untyped constant, it is first 
>> converted to its default type; if it is an untyped boolean value, it is 
>> first converted to type bool. The predeclared untyped value nil cannot be 
>> used as a switch expression.
>
>
> The current behavior is still as specified. Given that there is an 
> explicit statement about how this is handled makes it less convincing, 
> however, that the spec would be more complicated with a different behavior. 
> So you might still file a language change request, if you want.
>

but, why design as such? Isn't untyped bool more convenient?
 

>
> On Fri, Feb 2, 2018 at 4:39 PM,  wrote:
>
>>
>>
>> On Friday, February 2, 2018 at 10:37:24 AM UTC-5, di...@veryhaha.com 
>> wrote:
>>
>>>
>>>
>>> On Friday, February 2, 2018 at 10:27:04 AM UTC-5, Ian Lance Taylor wrote:

 On Fri, Feb 2, 2018 at 7:10 AM,   wrote: 
 > 
 > Why not make it untyped? 
 > 
 > package main 
 > 
 > type T bool 
 > 
 > func f() T {return T(false)} 
 > 
 > func main() { 
 > switch { 
 > case f(): // invalid case f() in switch (mismatched types T and 
 bool) 
 > } 
 > } 

 The current language spec says that omitting the switch expression is 
 equivalent to writing `true`.  If you actually write `true`, then, 
 following the usual rules for untyped constant expressions, it will 
 receive the type `bool`, and you would get the same mismatched type 
 error.  You will see a similar case if you write `switch 0` and try to 
 compare with a named version of `int`.  So the compiler is following 
 the language spec as currently written. 

 We could change the language spec to say that omitting the switch 
 expression is not equivalent to writing `true`, but instead, as you 
 suggest, compares each case to an untyped `true` value.  I think the 
 main argument against that is that it makes the spec slightly more 
 complicated while bringing very little benefit.  You could write it up 
 as a language change proposal if you like. 

 Ian 

>>>
>>> > If you actually write `true`, then,
>>> > following the usual rules for untyped constant expressions,
>>> > it will receive the type `bool`,
>>>
>>> But, in my expression, the result of a constant expression is still 
>>> untyped.
>>> And "true" is a per-declared untyped boolean value.
>>>
>>> And, here is another example to should the untyped result is converted 
>>> to type "bool":
>>>
>> and sorry again, here "should", I mean "show".
>>  
>>
>>>
>>> package main
>>>
>>> type T bool
>>>
>>> func f() T {return T(false)}
>>>
>>> func main() {
>>> switch true == true {
>>> case f(): // invalid case f() in switch (mismatched types T and bool)
>>> }
>>> }
>>>
>>>
>>> -- 
>> 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] Why is the omitted expression in a swtich code block a typed bool "true"?

[digg]

On Friday, February 2, 2018 at 10:37:24 AM UTC-5, di...@veryhaha.com wrote:
>
>
>
> On Friday, February 2, 2018 at 10:27:04 AM UTC-5, Ian Lance Taylor wrote:
>>
>> On Fri, Feb 2, 2018 at 7:10 AM,   wrote: 
>> > 
>> > Why not make it untyped? 
>> > 
>> > package main 
>> > 
>> > type T bool 
>> > 
>> > func f() T {return T(false)} 
>> > 
>> > func main() { 
>> > switch { 
>> > case f(): // invalid case f() in switch (mismatched types T and 
>> bool) 
>> > } 
>> > } 
>>
>> The current language spec says that omitting the switch expression is 
>> equivalent to writing `true`.  If you actually write `true`, then, 
>> following the usual rules for untyped constant expressions, it will 
>> receive the type `bool`, and you would get the same mismatched type 
>> error.  You will see a similar case if you write `switch 0` and try to 
>> compare with a named version of `int`.  So the compiler is following 
>> the language spec as currently written. 
>>
>> We could change the language spec to say that omitting the switch 
>> expression is not equivalent to writing `true`, but instead, as you 
>> suggest, compares each case to an untyped `true` value.  I think the 
>> main argument against that is that it makes the spec slightly more 
>> complicated while bringing very little benefit.  You could write it up 
>> as a language change proposal if you like. 
>>
>> Ian 
>>
>
> > If you actually write `true`, then,
> > following the usual rules for untyped constant expressions,
> > it will receive the type `bool`,
>
> But, in my expression, the result of a constant expression is still 
> untyped.
> And "true" is a per-declared untyped boolean value.
>
> And, here is another example to should the untyped result is converted to 
> type "bool":
>
and sorry again, here "should", I mean "show".
 

>
> package main
>
> type T bool
>
> func f() T {return T(false)}
>
> func main() {
> switch true == true {
> case f(): // invalid case f() in switch (mismatched types T and bool)
> }
> }
>
>
>

-- 
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 is the omitted expression in a swtich code block a typed bool "true"?

[digg]

On Friday, February 2, 2018 at 10:37:24 AM UTC-5, di...@veryhaha.com wrote:
>
>
>
> On Friday, February 2, 2018 at 10:27:04 AM UTC-5, Ian Lance Taylor wrote:
>>
>> On Fri, Feb 2, 2018 at 7:10 AM,   wrote: 
>> > 
>> > Why not make it untyped? 
>> > 
>> > package main 
>> > 
>> > type T bool 
>> > 
>> > func f() T {return T(false)} 
>> > 
>> > func main() { 
>> > switch { 
>> > case f(): // invalid case f() in switch (mismatched types T and 
>> bool) 
>> > } 
>> > } 
>>
>> The current language spec says that omitting the switch expression is 
>> equivalent to writing `true`.  If you actually write `true`, then, 
>> following the usual rules for untyped constant expressions, it will 
>> receive the type `bool`, and you would get the same mismatched type 
>> error.  You will see a similar case if you write `switch 0` and try to 
>> compare with a named version of `int`.  So the compiler is following 
>> the language spec as currently written. 
>>
>> We could change the language spec to say that omitting the switch 
>> expression is not equivalent to writing `true`, but instead, as you 
>> suggest, compares each case to an untyped `true` value.  I think the 
>> main argument against that is that it makes the spec slightly more 
>> complicated while bringing very little benefit.  You could write it up 
>> as a language change proposal if you like. 
>>
>> Ian 
>>
>
> > If you actually write `true`, then,
> > following the usual rules for untyped constant expressions,
> > it will receive the type `bool`,
>
> But, in my expression, the result of a constant expression is still 
> untyped.
>
sorry, here should be "the result of an untyped constant expression is 
still untyped."
 

> And "true" is a per-declared untyped boolean value.
>
> And, here is another example to should the untyped result is converted to 
> type "bool":
>
> package main
>
> type T bool
>
> func f() T {return T(false)}
>
> func main() {
> switch true == true {
> case f(): // invalid case f() in switch (mismatched types T and bool)
> }
> }
>
>
>

-- 
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 is the omitted expression in a swtich code block a typed bool "true"?

[digg]

On Friday, February 2, 2018 at 10:27:04 AM UTC-5, Ian Lance Taylor wrote:
>
> On Fri, Feb 2, 2018 at 7:10 AM,   
> wrote: 
> > 
> > Why not make it untyped? 
> > 
> > package main 
> > 
> > type T bool 
> > 
> > func f() T {return T(false)} 
> > 
> > func main() { 
> > switch { 
> > case f(): // invalid case f() in switch (mismatched types T and 
> bool) 
> > } 
> > } 
>
> The current language spec says that omitting the switch expression is 
> equivalent to writing `true`.  If you actually write `true`, then, 
> following the usual rules for untyped constant expressions, it will 
> receive the type `bool`, and you would get the same mismatched type 
> error.  You will see a similar case if you write `switch 0` and try to 
> compare with a named version of `int`.  So the compiler is following 
> the language spec as currently written. 
>
> We could change the language spec to say that omitting the switch 
> expression is not equivalent to writing `true`, but instead, as you 
> suggest, compares each case to an untyped `true` value.  I think the 
> main argument against that is that it makes the spec slightly more 
> complicated while bringing very little benefit.  You could write it up 
> as a language change proposal if you like. 
>
> Ian 
>

> If you actually write `true`, then,
> following the usual rules for untyped constant expressions,
> it will receive the type `bool`,

But, in my expression, the result of a constant expression is still untyped.
And "true" is a per-declared untyped boolean value.

And, here is another example to should the untyped result is converted to 
type "bool":

package main

type T bool

func f() T {return T(false)}

func main() {
switch true == true {
case f(): // invalid case f() in switch (mismatched types T and bool)
}
}


-- 
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] Rate controlling the Go http server

[Henrik Johansson]

Happy to help!

The limit can be anything from the link above or something more advanced
that Jesper suggested. The skeleton could be as outlined above however.

On Fri, Feb 2, 2018, 15:40 mrx  wrote:

> On Fri, Feb 2, 2018 at 1:28 PM, Henrik Johansson 
> wrote:
>
>> You can either use one of the existing other routers that have meddleware
>> support or you could wrap your handlers in another handler much like this:
>>
>> handle("/foo",wrapHandler(rateLimiter, realHandler))
>>
>> func wrapHandler(limit *ARateLimiter, handler func(http.ResponseWriter,
>> *http.Request)) func(http.ResponseWriter, *http.Request){
>>   return func(w http.ResponseWriter, r *http.Request) {
>>limit.Aquire() //Or however you use the limiter
>>handle(w,r)
>>  }
>> }
>>
>> Very rudimentary and simplified but could perhaps work. You can wrap any
>> handler in the same way with either a shared limiter or one per call or any
>> combination.
>>
>
> Feels like your limit parameter is simply a semaphore to me. I'll try that
> for now. Thanks a lot for your help, it was most illuminating!
>
> // Patrik
>

-- 
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 is the omitted expression in a swtich code block a typed bool "true"?

[Ian Lance Taylor]

On Fri, Feb 2, 2018 at 7:10 AM,   wrote:
>
> Why not make it untyped?
>
> package main
>
> type T bool
>
> func f() T {return T(false)}
>
> func main() {
> switch {
> case f(): // invalid case f() in switch (mismatched types T and bool)
> }
> }

The current language spec says that omitting the switch expression is
equivalent to writing `true`.  If you actually write `true`, then,
following the usual rules for untyped constant expressions, it will
receive the type `bool`, and you would get the same mismatched type
error.  You will see a similar case if you write `switch 0` and try to
compare with a named version of `int`.  So the compiler is following
the language spec as currently written.

We could change the language spec to say that omitting the switch
expression is not equivalent to writing `true`, but instead, as you
suggest, compares each case to an untyped `true` value.  I think the
main argument against that is that it makes the spec slightly more
complicated while bringing very little benefit.  You could write it up
as a language change proposal if you like.

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

[go-nuts] Re: Why is the omitted expression in a swtich code block a typed bool "true"?

[digg]

Looks the non-omitted "true" is also a typed value of "bool" type.

package main

type T bool

func f() T {return T(false)}

func main() {
switch true {
case f(): // invalid case f() in switch (mismatched types T and bool)
}
}

On Friday, February 2, 2018 at 10:11:31 AM UTC-5, di...@veryhaha.com wrote:
>
> Why not make it untyped?
>
> package main
>
> type T bool
>
> func f() T {return T(false)}
>
> func main() {
> switch {
> case f(): // invalid case f() in switch (mismatched types T and bool)
> }
> }
>

-- 
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] Why is the omitted expression in a swtich code block a typed bool "true"?

[digg]

Why not make it untyped?

package main

type T bool

func f() T {return T(false)}

func main() {
switch {
case f(): // invalid case f() in switch (mismatched types T and bool)
}
}

-- 
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] Does go programmers should handle syscall.EINTR all by themselves after go1.9 when writing disk files?

[Ian Lance Taylor]

On Fri, Feb 2, 2018 at 6:07 AM, rmfr  wrote:
>
> Does go programmers should handle syscall.EINTR all by themselves after
> go1.9 when writing disk files?
>
> I just noticed this commit
> https://github.com/golang/go/commit/c05b06a12d005f50e4776095a60d6bd9c2c91fac#diff-b7452e0f27c15f140b5e86f88e2d43deL192
>
> If the answer is 'yes', I wonder why deleted this loop-write-if-eintr logic?
> Does it not bring unnecessary inconvenience to the go programmer?

Go programmers should never see syscall.EINTR when calling
function/methods in the os and net packages.  If they do, something
has gone wrong.

The main protection against EINTR is that Go installs its signal
handlers with SA_RESTART set.

If you do get an EINTR return, by all means report a bug.

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

Re: [go-nuts] Rate controlling the Go http server

[mrx]

On Fri, Feb 2, 2018 at 1:28 PM, Henrik Johansson 
wrote:

> You can either use one of the existing other routers that have meddleware
> support or you could wrap your handlers in another handler much like this:
>
> handle("/foo",wrapHandler(rateLimiter, realHandler))
>
> func wrapHandler(limit *ARateLimiter, handler func(http.ResponseWriter,
> *http.Request)) func(http.ResponseWriter, *http.Request){
>   return func(w http.ResponseWriter, r *http.Request) {
>limit.Aquire() //Or however you use the limiter
>handle(w,r)
>  }
> }
>
> Very rudimentary and simplified but could perhaps work. You can wrap any
> handler in the same way with either a shared limiter or one per call or any
> combination.
>

Feels like your limit parameter is simply a semaphore to me. I'll try that
for now. Thanks a lot for your help, it was most illuminating!

// Patrik

-- 
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] Does go programmers should handle syscall.EINTR all by themselves after go1.9 when writing disk files?

[rmfr]

Does go programmers should handle syscall.EINTR all by themselves after 
go1.9 when writing disk files?

I just noticed this commit 
https://github.com/golang/go/commit/c05b06a12d005f50e4776095a60d6bd9c2c91fac#diff-b7452e0f27c15f140b5e86f88e2d43deL192

If the answer is 'yes', I wonder why deleted this loop-write-if-eintr 
logic? Does it not bring unnecessary inconvenience to the go programmer?

-- 
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] Development infrastructure research

[yia]

 

Hi,


I'm working with a startup that wants to bring the first-class development 
infrastructure of companies like Google to engineers at companies of all 
sizes.  This project will be an open source effort.


We are looking for software architects, software engineers, and DevOps 
engineers who work within companies interested in or actively transitioning 
from monoliths to microservices.


We would appreciate a few minutes of your time to answer a brief survey.  We'll 
ask you to share your challenges and successes with software iteration and 
deployment cycles.  In return for your time, we'll be happy to provide you 
with the results of the research.


Click here to start the 
survey: https://www.surveygizmo.com/s3/4141414/1b3e669b5834


Thank you so much,

Yia



Yia Hang
Researcher
H2R Product Science 
Newsletter  | Twitter 
 | LinkedIn 
 | Medium 


-- 
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] Understanding how to use the "go/*" APIs

[Paul Brousseau]

I am working on a program to consume Go source code and maintain a running 
state of that program as a user edits that source in an IDE.  I have a 
working implementation that *loads* the program AST representation (inc. 
all imports and standard library) and runs it through a type checker, but 
my implementation is rudimentary (so much so that I'm hesitant to share the 
source at this point; it's not terribly readable right now).  Once the 
program is loaded, I can do simple things such as locating where an Ident 
is declared, but I haven't worked through finding all references to an 
Ident yet.  I have some fundamental questions before moving on to greater 
tasks (such as handling edits to the program files).  I hope that some of 
the folks here can provide some insight.

1) My current implementation maintains a single `token.FileSet` for all 
files in the program, across all packages.  Is this correct, or is it 
better to keep a file set per package?

2) Similar question for `types.Info`.  I currently have a single instance 
that is shared among all packages, but the source code comments say that it 
holds data "for *a* type-checked package" (emphasis mine).  Should I be 
keeping a single instance per package instead?

3) I am keeping a `types.Checker` per package, but even so, I can only 
check one package at a time.  My program is highly concurrent, and as it 
turns out, one checker may consuming a package "A", while package "A"'s 
checker is processing some test files, which results in a concurrent 
read/write panic from a map.  (I am checking files from `build.Package` in 
waves -- first all Go and Cgo files, then test files, and later I will add 
external test files.)  Are there any strategies to improve concurrency 
here?  I am thinking about keeping a `sync.RWMutex` per-package, which I 
would write-lock when a package is getting checked, and claim a read-lock 
when a package is returned from my `types.Importer` / `types.ImporterFrom` 
implementation.  Does this seem like a reasonable strategy?

4) When going through the type checker, what is the relationship between 
* `type.Package` instances that are imported via my custom `types.Importer` 
/ `types.ImporterFrom` implementation provides,
* the non-package-local tokens & identifiers,
* and the information that gets stored in the `types.Info`?
The thing that I'm really trying to understand is, if I have a complete 
program representation, and an exported part of a Go source code file 
changes, what will be the impact on packages that consume it?  I know that 
once I run the new file contents through `parser.ParseFile`, I will get a 
completely new `ast.File`, which I will have to type-check again to get a 
new `types.Package`.  I don't want to walk the entire package dependency 
tree if a low-level package changes; are there ways to avoid that?

Thanks for any insight.  This is a pretty big & abstract subject matter to 
ask a bunch of questions about all at once, and I apologize if I'm breaking 
etiquette here.

-- 
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] Where is my memory in Linux?

[Zhang Rui]

Hello gophers, 

I have a VM on Linode.com. OS is Cent OS 6.8 and kernel 
is 4.14.12-x86_64-linode92. It has 1 CPU core and 2G RAM.
A Go application is running on this VM.
Free memory on this VM is 490M (with buffer and cache), The RSS value of 
this Go application is only 12M. After I kill this Go app, free memory will 
increase to 950M. I have called Debug.FreeOSMemory() in this Go app every 
minute.
Sometimes, free memory will be decreased to 0 and this Go app will be 
killed by oom-killer. Does anyone know where is my memory?




















-- 
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: Parse C/C++ source code?

[roozbeh . farahbod]

Hi Leff. Did you find anything good eventually? 

The cznic/cc code offers a decent compiler but I found it very bad to read 
and reuse. I don't want to rely on guess work and the documentation is 
almost non-existant. 

On Tuesday, May 17, 2016 at 12:37:25 PM UTC+2, Leff Ivanov wrote:
>
> Hello! I want to build custom refactoring tool for C/C++ source code and I 
> want to do it in Go. Is there any good library in Go that would parse C/C++ 
> source code into AST (abstract syntax tree) or some other high level 
> structure that I can read and manipulate? Is there any good and up to date 
> bindings to libclang or some other library for parsing C/C++ code? Is there 
> any generic parsing library that has a C/C++ grammar support in it?
>

-- 
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] Rate controlling the Go http server

[Henrik Johansson]

You can either use one of the existing other routers that have meddleware
support or you could wrap your handlers in another handler much like this:

handle("/foo",wrapHandler(rateLimiter, realHandler))

func wrapHandler(limit *ARateLimiter, handler func(http.ResponseWriter,
*http.Request)) func(http.ResponseWriter, *http.Request){
  return func(w http.ResponseWriter, r *http.Request) {
   limit.Aquire() //Or however you use the limiter
   handle(w,r)
 }
}

Very rudimentary and simplified but could perhaps work. You can wrap any
handler in the same way with either a shared limiter or one per call or any
combination.


fre 2 feb. 2018 kl 13:06 skrev Patrik Iselind :

>
> Den fredag 2 februari 2018 kl. 11:50:43 UTC+1 skrev Jesper Louis Andersen:
>>
>> A simple solution is to have a channel of type struct{} of some bound,
>> say 10. A process only gives service as long as it can pull a message from
>> the channel.
>>
>
> How would i hook in such a channel in the http server? Wouldn't a channel
> of type interface{} be better?
>
>
>> More advanced solutions include handling the channel as a token bucket
>> and regulating it to have a drip-rate.
>>
>
> I would prefer simple over complex in this instance.
>
>
>>
>> Even more advanced solutions sample your system and slows the drip feed
>> when it is overloaded with resources.
>>
>> You might also consider pushback and queuing. If you are overloaded, you
>> have to tell the caller to stop sending requests for a while.
>>
>> Consider using a model such as CoDel (Controlled Delay) on your queues.
>>
>
> pushback, queuing and CoDel might be good ideas further down the line for
> my project. I'll keep those in mind, thanks!
>
>
> // Patrik
>
> --
> 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] Rate controlling the Go http server

[Patrik Iselind]

Den fredag 2 februari 2018 kl. 11:50:43 UTC+1 skrev Jesper Louis Andersen:
>
> A simple solution is to have a channel of type struct{} of some bound, say 
> 10. A process only gives service as long as it can pull a message from the 
> channel.
>

How would i hook in such a channel in the http server? Wouldn't a channel 
of type interface{} be better?
 

> More advanced solutions include handling the channel as a token bucket and 
> regulating it to have a drip-rate.
>

I would prefer simple over complex in this instance.
 

>
> Even more advanced solutions sample your system and slows the drip feed 
> when it is overloaded with resources.
>
> You might also consider pushback and queuing. If you are overloaded, you 
> have to tell the caller to stop sending requests for a while.
>
> Consider using a model such as CoDel (Controlled Delay) on your queues.
>

pushback, queuing and CoDel might be good ideas further down the line for 
my project. I'll keep those in mind, thanks!

// Patrik

-- 
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] Rate controlling the Go http server

[Patrik Iselind]

Den fredag 2 februari 2018 kl. 11:50:22 UTC+1 skrev Henrik Johansson:
>
> I guess a middleware wrapping any of the available rate limiters 
> https://godoc.org/?q=rate+limit should do the trick?
>

Thanks a lot for your suggestion.

How do i add middleware to the HTTP server in the first place? I cannot 
remember ever having the need to use middleware before. Any pointers would 
be very helpful.

// Patrik

-- 
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] Rate controlling the Go http server

[Patrik Iselind]

Hi,

If i define a webserver as such (taken from the docs)

http.Handle("/foo", fooHandler)

http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello, %q", html.EscapeString(r.URL.Path))
})

log.Fatal(http.ListenAndServe(":8080", nil))


How do i control how many simultaneous requests my server may handle?

As i understand it, the handlers get spawned off as separate go routines. 
I'm looking for a way to limit the number of such go routines.

I would like to limit the effects of getting a massive storm of requests in 
a short amount of time which might chew up all RAM/CPU.

// Patrik


-- 
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] Rate controlling the Go http server

[Henrik Johansson]

I guess a middleware wrapping any of the available rate limiters
https://godoc.org/?q=rate+limit should do the trick?

fre 2 feb. 2018 kl 11:30 skrev Patrik Iselind :

> Hi,
>
> If i define a webserver as such (taken from the docs)
>
> http.Handle("/foo", fooHandler)
>
> http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {
>   fmt.Fprintf(w, "Hello, %q", html.EscapeString(r.URL.Path))
> })
>
> log.Fatal(http.ListenAndServe(":8080", nil))
>
>
> How do i control how many simultaneous requests my server may handle?
>
> As i understand it, the handlers get spawned off as separate go routines.
> I'm looking for a way to limit the number of such go routines.
>
> I would like to limit the effects of getting a massive storm of requests
> in a short amount of time which might chew up all RAM/CPU.
>
> // Patrik
>
>
> --
> 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: any discourse-like forum in Go?

[Sebastien Binet]

Hi,

I believe the golangbridge forum is discourse with a (nice) Go theme.
I'd be happy to be proven wrong though :)

-s

sent from my droid

On Feb 2, 2018 9:30 AM,  wrote:

> Golang Bridge has a forum: https://forum.golangbridge.org/top
>
> On Wednesday, January 31, 2018 at 8:29:25 AM UTC-8, Sebastien Binet wrote:
>>
>> hi there,
>>
>> I am looking for a discourse-like forum, in Go. Does anybody know of such
>> a thing?
>>
>> Interestingly, reading the https://blog.golang.org/hello-china post, I
>> stumbled upon:
>>
>> - https://gocn.io
>>
>> which could be just what I am looking for, but there are no link to any
>> github repo... :}
>> (and my chinese is... limited.)
>>
>> -s
>>
>> PS: cross-posted on reddit too...
>> https://www.reddit.com/r/golang/comments/7ub10v/any_discours
>> elike_forum_in_go/
>>
> --
> 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.

[go-nuts] Re: any discourse-like forum in Go?

[kanepyork]

Golang Bridge has a forum: https://forum.golangbridge.org/top

On Wednesday, January 31, 2018 at 8:29:25 AM UTC-8, Sebastien Binet wrote:
>
> hi there,
>
> I am looking for a discourse-like forum, in Go. Does anybody know of such 
> a thing?
>
> Interestingly, reading the https://blog.golang.org/hello-china post, I 
> stumbled upon:
>
> - https://gocn.io
>
> which could be just what I am looking for, but there are no link to any 
> github repo... :}
> (and my chinese is... limited.)
>
> -s
>
> PS: cross-posted on reddit too...
>
> https://www.reddit.com/r/golang/comments/7ub10v/any_discourselike_forum_in_go/
>

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