Re: [go-nuts] weird "index out of range" in strconv.formatBits

[metronome]

We waited for two weeks, but the panic never resurfaced, will provide 
further updates if it reoccurs or as soon as we have more information.

Thanks Dan and Kurtis for looking into it.

On Friday, August 18, 2023 at 3:18:10 PM UTC+8 Dan Kortschak wrote:

> On Thu, 2023-08-17 at 23:32 -0700, metronome wrote:
> > > > Have you built with CGO_ENABLED=0?
> > Building with CGO_ENABLED=0 succeeded, does that mean the binary's
> > runtime behavior has nothing to do with CGO, deploying
> > a CGO_ENABLED=0 binary online is not an option as well, for now (We
> > are trying, but not sure if we can make it happen).
>
> Do you get the same behaviour with CGO_ENABLED=0?
>
>

-- 
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/55c5fc8d-aa5e-4a7e-8ea6-812c1462fd36n%40googlegroups.com.

Re: [go-nuts] Re: From which programming language did the idea for Golang's interface mechanism design originate?

['Thomas Bushnell BSG' via golang-nuts]

Another precedent for the idea was the use of a "behavior" to specify the
methods which a Smalltalk object can receive. Basically, it was realized
that the question of the class hierarchy for an object was an
implementation concern which the users of an object should not care about.
So early Smalltalk books started using the word "behavior" to refer roughly
to something like a Go "method set". When Smalltalk standardization
happened, the class hierarchy was almost entirely left out of the standard,
instead relying on these behaviors to say what methods an object would
support. Implementations could then make their own decisions about how to
factor those into classes for implementation.

The main difference between these behaviors and Go's interfaces is that a
behavior in Smalltalk is only a way to talk *about *the language; there is
no such thing as a behavior datatype in Smalltalk, no syntax for specifying
them, etc. It's a way to document what things do, but not something checked
by the compiler. However, as soon as you have typed variables, and you
would be deciding whether the types should be classes or behaviors, you
would certainly pick behaviors (and thus something like Go's interfaces) as
superior to classes (like Java or Python typically use).

Thomas

On Fri, Aug 25, 2023 at 12:27 AM Rob Pike  wrote:

> It was dreamed up independently at the whiteboard on the first day of
> design discussions. We did not know Emerald at the time; the similarity was
> discovered later.
>
> This is not to claim the idea is original, just that we discovered it
> independently.
>
> -rob
>
>
> On Fri, Aug 25, 2023 at 1:57 PM Andrew Harris 
> wrote:
>
>> The comments on Go Data Structures: Interfaces
>>  mention Emerald
>> , maybe this is what you were
>> thinking of?
>>
>> On Thursday, August 24, 2023 at 8:42:43 PM UTC-7 xie cui wrote:
>>
>>> I remembe someone in a video in youtube explain the design of interface.
>>> But I cann't find it now.
>>
>> --
>> 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/e873392b-47fe-4fa9-b465-efadcde0bfd8n%40googlegroups.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/CAOXNBZQ8D5f2uLb1%3D8ttmnwzo7WY3vYqKu7W3Sz%3DqyQ3OmjfTA%40mail.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/CA%2BYjuxtGcGxW_yWqot%2BeF%2BSVZyY%3DrSTXRKFp8FVh%3DezQ48WH9A%40mail.gmail.com.

[go-nuts] How to register a new HTTP handler to an HTTP proxy

[Van Fury]

Hi,

I have a working proxy and would like to add register additional handler 
that will receive HTTP request from an HTTP client and return response. How 
can register this new handler(FooHandler) to the proxy?

func main() {

logger.Log.Infof("Server Name: [%s]", description)  

done := make(chan bool, 1)
quit := make(chan os.Signal, 1)

go func() {
signal.Notify(
quit,
syscall.SIGTERM,
syscall.SIGINT,
)
}()

server := NewServer("127.0.0.10:8085")

go gracefullShutdown(server, quit, done)

// proxy handler 
http.HandleFunc("/", ProxyProcess)

// Get tls files
certFile, keyFile := util.Config.GetCertKeyFiles()

go func() {
err := server.ListenAndServeTLS(certFile, keyFile)
if err != nil && err != http.ErrServerClosed {
logger.Log.Error(err)
os.Exit(1)
}
}()
<-done

logger.Log.Info("Shutting down server ...")
logger.Log.Info("Server shutdown!")
os.Exit(0)
}

// NewServer - Create a new server
func NewServer(listening_addr string) *http.Server {

return &http.Server{
Addr:  listening_addr,
TLSConfig: TLSConfig(), // tls confid ommitted
//Handler:   Router,
ReadTimeout:   readTimeout * time.Second,
WriteTimeout:  writeTimeout * time.Second,
IdleTimeout:   idleTimeout * time.Second,
ReadHeaderTimeout: readHeaderTimeout * time.Second,
}
}

Proxy handler function:

func ProxyProcess(res http.ResponseWriter, req *http.Request) {

remoteUri := "http://127.0.0.5:20015"; 
url, err := url.Parse(remoteUri)
if err != nil {
logger.Log.Error("Error parsing url:", err)
return
}

//create new proxy
proxy := CustomNewSingleHostReverseProxy(url)

// other code omitted

proxy.ServeHTTPS(res, req)
}

func (p *ReverseProxy) ServeHTTPS(rw http.ResponseWriter, req 
*http.Request) {

// code ommitted
.

}

I tried to create a router and updated the Newserver function. With this 
changes as below request to FooHandler works but proxy request does not 
work. How can I modify the server to handle both handler requests?

func FooHandler(w http.ResponseWriter, r *http.Request) {

if r.Method == http.MethodPost {
return
}

// do some stuff and respond back to http client

w.Write([]byte("foo"))
}

// route defined for new handler
var routes = Routes{
Route{
"FooHandler",
strings.ToUpper("Post"),
 "/api/v1/foo",
FooHandler,
},
}


type Route struct {
Namestring
Method  string
Pattern string
HandlerFunc http.HandlerFunc
}

var Router = NewRouter()

type Routes []Route

func NewRouter() *mux.Router {

router := mux.NewRouter().StrictSlash(true)

for _, route := range routes {

var handler http.Handler

handler = route.HandlerFunc
handler = common.RecoverHandler(handler)

router.
Methods(route.Method).
Path(route.Pattern).
Name(route.Name).
Handler(handler)
}
return router
}

// NewServer updated with router
func NewServer(listening_addr string) *http.Server {

return &http.Server{
Addr:  listening_addr,
TLSConfig: TLSConfig(), // tls confid ommitted
Handler:   Router,
ReadTimeout:   readTimeout * time.Second,
WriteTimeout:  writeTimeout * time.Second,
IdleTimeout:   idleTimeout * time.Second,
ReadHeaderTimeout: readHeaderTimeout * time.Second,
}
}


-- 
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/01610fc0-2808-4244-8c26-18f6d9d0e160n%40googlegroups.com.

[go-nuts] Re: go build of a *_unix.go file still used under windows ?

[Peter Galbavy]

After your initial reply and carefully re-reading I also agree that's what 
it means. It is however, IMHO, not clear on first reading and there is an 
implication by omission that "unix" could be considered a valid "GOOS" 
value. Now I know, I know. The next first-time reader, perhaps not so much.

Peter

On Thursday, 31 August 2023 at 11:11:06 UTC+1 Brian Candler wrote:

> During a particular build, the following build tags are satisfied:
>
>- ...
>- "unix", if GOOS is a Unix or Unix-like system.
>- ...
>
>
> It then says:
>
> If a file's name, after stripping the extension and a possible _test 
> suffix, matches any of the following patterns:
> *_GOOS *_GOARCH *_GOOS_GOARCH 
>
> (example: source_windows_amd64.go) where GOOS and GOARCH represent any 
> known operating system and architecture values respectively, then the file 
> is considered to have an implicit build constraint requiring those terms 
> (in addition to any explicit constraints in the file).
>
> This says that only GOOS and GOARCH are considered; it doesn't say that 
> all possible build tags are interpreted when in the filename, and indeed 
> there are many that are not.  For example, "foo_gccgo.go" and 
> "foo_go1.12.go" are not treated specially. So I think it's fairly clear 
> here, as long as you accept that "unix" is neither a GOOS nor a GOARCH.
>
> Aside: finding a comprehensive list of GOOS and GOARCH values is a bit 
> tricker. You can run "go tool dist list", or there are third-party 
> summaries like
> https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63
>
> On Thursday, 31 August 2023 at 10:44:14 UTC+1 Peter Galbavy wrote:
>
>> Ah! Got it. Thanks.
>>
>> Would it perhaps be good to mention this in the docs, here: 
>> https://pkg.go.dev/cmd/go#hdr-Build_constraints ?
>>
>> The bullet points refer to "unix" (which is true) and then a naïve 
>> reader, like me, would think the later paragraphs about GOOS also apply.
>>
>> Peter 
>>
>> On Thursday, 31 August 2023 at 10:13:12 UTC+1 Brian Candler wrote:
>>
>>> https://github.com/golang/go/issues/51572
>>>
>>> On Thursday, 31 August 2023 at 08:57:15 UTC+1 Peter Galbavy wrote:
>>>
 I have used comment level build constraints for a while but I moved to 
 using _linux.go and _windows.go over time as it makes it clearer for 
 external viewing.

 A user reported they tried to build on MacOS and of course this didn't 
 work. I renamed the _linux.go files to _unix.go suffixes but then when I 
 do 
 "GOOS=windows go build" those files were pulled in too. While I would say 
 Windows is a POSIX-ish system I would contend it's not UNIX :-)

 I have gone and added "//go:build !windows" to all the renamed files 
 for now, but is this intended behaviour?

 Peter

>>>

-- 
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/a4c1bbc4-a777-4ce7-b389-949afd7a6a71n%40googlegroups.com.