Re: [go-nuts] Re: How can I tell if a http.Server has a TLS listener?

[Frank Schröder]

Only for exported types. tls.listener isn't

-- 
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: How can I tell if a http.Server has a TLS listener?

[Aldrin Leal]

Can't you use type assertions?

https://tour.golang.org/methods/15

--
-- Aldrin Leal,  / http://about.me/aldrinleal

On Wed, May 24, 2017 at 4:50 PM, Frank Schröder 
wrote:

> This works but it is somewhat ugly ...
>
> // l is either a tls.listener or a TCPListener
> if strings.Contains("*tls.listener", fmt.Sprintf("%T", l)) {
> srv.proto = "https"
> }
>
> --
> 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: How can I tell if a http.Server has a TLS listener?

[Frank Schröder]

This works but it is somewhat ugly ...

// l is either a tls.listener or a TCPListener
if strings.Contains("*tls.listener", fmt.Sprintf("%T", l)) {
srv.proto = "https"
}

-- 
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] Go 1.8.3 is released

[Nathan Kerr]

Thanks for the hard work.

I updated my Go Release Timeline: 
https://pocketgophers.com/go-release-timeline/#go1.8.3

-- 
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] Go 1.8.3 is released

[Chris Broadfoot]

Hi gophers,

We have just released Go version 1.8.3, a minor point release.

This release includes fixes to the compiler, runtime, documentation, and the
database/sql package.
https://golang.org/doc/devel/release.html#go1.8.minor

It also includes the security fix to the crypto/elliptic package from Go
1.8.2.

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with "git
checkout go1.8.3" and build as usual.

Thanks to everyone who contributed to the release.

Chris

-- 
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] How can I tell if a http.Server has a TLS listener?

[Frank Schröder]

I've tried this but srv.TLSConfig is always non-nil. 

package main

import (
"log"
"net/http"
"time"
)

func main() {
srv := {Addr: ":8080"}
go srv.ListenAndServe()
time.Sleep(25 * time.Millisecond)
if srv.TLSConfig == nil {
log.Println("Started HTTP Server on ", srv.Addr)
} else {
log.Println("Started HTTPS Server on ", srv.Addr)
}
}

$ go run main.go
2017/05/24 22:50:15 Started HTTPS Server on  :8080

Thx
Frank

-- 
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: [golang-dev] Golang Developers @ Dallas,TX

[Brad Fitzpatrick]

[+golang-nuts, moving golang-dev to bcc]


On Wed, May 24, 2017 at 12:59 PM, Amruta Shenolikar Warkad <
amruta.shenoli...@gmail.com> wrote:

> Hi,
>
> Looking for Go Developers for a position @ Dallas,TX. Please email resumes
> to amruta.war...@resolvetech.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+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: File diff based go test check

[Tong Sun]

Just FTA, I've implemented such File diff based go test checking in my 

easygen  universal code/text 
generator
https://github.com/go-easygen/easygen#details

without pulling any extra packages. 

Specifically, the test file is at, 
https://github.com/go-easygen/easygen/blob/master/cmd/easygen/main_test.go

HTH


On Friday, April 14, 2017 at 3:55:13 AM UTC-4, mhh...@gmail.com wrote:
>
> do you mean something like git diff ? Would like t.
>
> On Thursday, April 13, 2017 at 7:35:42 PM UTC+2, Tong Sun wrote:
>>
>> My program works on files, read from input and write to output. 
>>
>> Is there any ready-made and *light *testing packages that allows me 
>> checking whether the new output is the same as before? 
>>
>> Thanks
>>
>>
>>

-- 
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: bash completion for flag package

[mhhcbon]

wahou :) trying it now!

On Tuesday, May 23, 2017 at 9:21:07 PM UTC+2, Eyal Posener wrote:
>
> I recently did the complete package , 
> that enables bash completion for the go command line.
> I came to be really satisfied with the result, but the package downside is 
> that the completion can be inconsistent with the actual flags provided by 
> the program.
> I thought how is it possible to add support to the standard library flag 
> package for automatic bash completion, more or less in the same way. 
> (Including installation, and that the program binary will provide bash 
> completion for itself)
>
> Here is what I came out with: https://github.com/posener/flag.
>
> It is 100% interchangeable with the standard library flag package.
> The implementation is also interesting, I only add to make 
> 'flat.Flag.Value' implement an interface I called 'Completer'. All the 
> standard library flags, which do not implement this interface don't 
> complete anything (which is fine) and additional flag types can complete 
> all sort of stuff.
>
> Please let me know your opinion about it.
>
> Cheers,
> Eyal
>

-- 
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] netutil.LimitListener(lis, n) limits to n-2 requests

[Pablo Rozas Larraondo]

Hi Kevin,

That's been a very good guess. Disabling the keep alive on the server has
made it to serve exactly the number of concurrent requests specified on the
LimitListener. Thank you very much for your help. Now I have to do some
work to better understand how all these concepts play together.

Cheers,
Pablo

On Wed, May 24, 2017 at 12:59 PM, Kevin Conway 
wrote:

> I'm speculating a bit here until I can dig back into the listener stack,
> but at least one variable you can tweak is the connection keep alive. On
> the surface, limit listener appears to gate on the socket accept call. I
> feel it is an important distinction because it limits the listener and not
> the request handler so we're ready taking about concurrent connections
> rather than requests.
>
> The default client will reuse established connections as available. It's
> possible you've found a poor interaction beetween connection pooling and
> connection limiting. You might try running your experiment again with keep
> alive disabled on your HTTP client.
>
> On Tue, May 23, 2017, 05:57 Pablo Rozas Larraondo <
> p.rozas.larrao...@gmail.com> wrote:
>
>> Hi gophers,
>>
>> I'm using netutil.LimitListener to limit the number of concurrent
>> requests that can be handled in a server to limit the memory usage of the
>> service. I've noticed that when I send a bunch of requests it serves the
>> number passed to the LimitListerner but after that it serves n-2 requests.
>> I wonder what the problem might be, not a big deal but maybe there is some
>> kind of problem in the library.
>>
>> Here is the code that I've created to test this problem:
>>
>> Server (waits 5 seconds before replying with concurrency limited to 10):
>> package main
>>
>> import (
>> "golang.org/x/net/netutil"
>> "log"
>> "net"
>> "net/http"
>> "time"
>> )
>>
>> type fooHandler struct {
>> }
>>
>> func (fh *fooHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
>> time.Sleep(5 * time.Second)
>> w.Write([]byte("Done"))
>> }
>>
>> func main() {
>> lis, err := net.Listen("tcp", ":8080")
>> if err != nil {
>> log.Fatalf("failed to listen: %v", err)
>> }
>> lis = netutil.LimitListener(lis, 10)
>> fH := {}
>>
>> s := {
>> Handler:fH,
>> ReadTimeout:60 * time.Second,
>> WriteTimeout:   60 * time.Second,
>> MaxHeaderBytes: 1 << 20,
>> }
>>
>> if err := s.Serve(lis); err != nil {
>> log.Fatalf("failed to serve: %v", err)
>> }
>> }
>>
>>
>> Client (Sends 40 concurrent requests to the server):
>> package main
>>
>> import (
>> "fmt"
>> "io/ioutil"
>> "net/http"
>> "sync"
>> )
>>
>> func Ask(wg *sync.WaitGroup, n int) {
>> resp, err := http.Get("http://localhost:8080;)
>> if err != nil {
>> return
>> }
>> defer resp.Body.Close()
>> body, err := ioutil.ReadAll(resp.Body)
>> fmt.Println(err, string(body), n)
>> wg.Done()
>> }
>> func main() {
>> wg := {}
>> for i := 0; i < 40; i++ {
>> wg.Add(1)
>> go Ask(wg, i)
>> }
>> wg.Wait()
>> }
>>
>> In this example I see 10 responses after the first 5 seconds and then 8
>> responses every five seconds.
>>
>> go version go1.8 darwin/amd64
>>
>> Thanks,
>> Pablo
>>
>> --
>> 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] idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

see the title, only for what s needed 
Slice/Splice/Each/Map/First/Last/Reverse/Sort ect ect not len, for reason. 
so interface system serves the userland by its definition of struct, and 
the basic slice type provided by the language is fully operational, without 
breaking, btw. i don t go further in evaluation, i leave that to the 
reader, just trying to work decently.

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