Re: [go-nuts] Dynamic composition of interfaces at runtime?

Usually, my experience is that these highly dynamic interfaces is an indication you want to approach the problem from a different angle. You will converge on something that gets closer and closer to having an interface{}, and this means you are converging toward a world of dynamic typing. It often

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

> Other people have said this too, but I want to emphasize that there are not 4 potential states of an interface value. There are 2 potential states: 1) interface does not hold any value, and is == nil; 2) interface holds a value, and is != nil. Indeed, there are 2 states of interface

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

> I gave you a third solution: Having a separate identifier for the zero value of interfaces. It doesn't solve issue at hand. The issue is, conversion from typed nil pointer to interface results in non-nil interface with valid vtable pointer and nil receiver. And only limited set of

[go-nuts] Re: [generics] Bugs + something else

you cannot mix parenthesis and square brackets for type parameters in the same file, you did it on your first example. On Tuesday, 1 September 2020 at 18:12:35 UTC+2 jake...@gmail.com wrote: > > On Monday, August 31, 2020 at 8:49:00 PM UTC-4, p...@pjebs.com.au wrote: >> >> 1. >> For this Go 2

[go-nuts] Re: Internal Compiler error when building go1.15 using go1.14.4

sam.mo...@gmail.com schrieb am Freitag, 28. August 2020 um 09:23:47 UTC+2: > > > On Thursday, August 27, 2020 at 11:38:54 PM UTC-7, Johann Höchtl wrote: >> >> >> Since long I am keeping my go installation up to date by compiling from >> source. Today on my attempt to update from 1.14.4 to 1.15

[go-nuts] Re: custom type wrapping errors; what am i missing?

import "github.com/pkg/errors" should be import "errors" left over from testing, but makes no difference, as expected. -- 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

Re: [go-nuts] Re: custom type wrapping errors; what am i missing?

the example compares the print output of a fmt.errorf wrapped error and a custom-error type wrapped error, the custom one isn't showing the wrapped error., On Wednesday, 2 September 2020 16:58:31 UTC+1, burak serdar wrote: > > On Wed, Sep 2, 2020 at 9:48 AM 'simon place' via golang-nuts > >

Re: [go-nuts] Re: custom type wrapping errors; what am i missing?

On Wed, Sep 2, 2020 at 10:05 AM 'simon place' via golang-nuts wrote: > > the example compares the print output of a fmt.errorf wrapped error and a > custom-error type wrapped error, the custom one isn't showing the wrapped > error., It will if you also print the wrapped error: func (e MyErr)

[go-nuts] regexp group multi Replace Pattern

Hello Can sombody suggest way to realize multipattern replace? 93881231212 -> 13881231212 0013881231212 -> 13881231212 +13881231212 -> 13881231212 somthing like this https://play.golang.org/p/Abeq2-FV7NW import ( "fmt" "regexp" "strings" ) func

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

Some feedback on requiring any/interface{} explicitly. > We feel that the cost of the new predeclared identifier “any” is outweighed by the simplification achieved by making all parameter lists syntactically the same Why is this simplification preferred? If it is intended at simplification

[go-nuts] custom type wrapping errors; what am i missing?

https://play.golang.org/p/REagqrWDb-6 -- 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

Re: [go-nuts] Re: custom type wrapping errors; what am i missing?

On Wed, Sep 2, 2020 at 9:48 AM 'simon place' via golang-nuts wrote: > > import "github.com/pkg/errors" > > should be > > import "errors" > > left over from testing, but makes no difference, as expected. What were you expecting? > > -- > You received this message because you are subscribed to

[go-nuts] Major Updates in Copper: Go Toolkit for building APIs

I'm happy to announce major updates in Copper . It is a set of small Go packages that help you build backend APIs with less boilerplate. These updates include support for more advanced routing, complete auth implementations, messaging utilities, and more.

Re: [go-nuts] Re: custom type wrapping errors; what am i missing?

I think you may be confused about fmt and error unwrapping. The fmt.Println() in your example code does *not *unwrap err1. When fmt.Errorf creates the error, the message is hard coded "fmt wrapping: error". The Println is just printing the result of err1.Error() On Wednesday, September 2,

Re: [go-nuts] Re: custom type wrapping errors; what am i missing?

my understanding is the whole wrap mechanism is to move to types, rather than strings, so you can test for a 'class' of error without the hacky use of string comparison. On Wednesday, 2 September 2020 17:18:10 UTC+1, burak serdar wrote: > > On Wed, Sep 2, 2020 at 10:05 AM 'simon place' via

Re: [go-nuts] Re: custom type wrapping errors; what am i missing?

On Wed, Sep 2, 2020 at 10:31 AM 'simon place' via golang-nuts wrote: > > my understanding is the whole wrap mechanism is to move to types, rather than > strings, so you can test for a 'class' of error without the hacky use of > string comparison. You do that using errors.Is and errors.As that

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

On Wed, Sep 2, 2020 at 7:02 PM Nishanth Shanmugham < nishanth.gerr...@gmail.com> wrote: > If it is intended at simplification for parsers, […] If it is intended to > improve readability for readers of generic code > I would argue that this is not a dichotomy. On the contrary: In general, a

[go-nuts] how to omit empty array

I have this code used to construct an ElasticSearch json query: ``` type Term = map[string]interface{} type QueryString = map[string]interface{} type Range = map[string]interface{} type Match = map[string]string type HasTermOrMatch = struct { Term `json:"term,omitempty"` QueryString

[go-nuts] how to stream json to http post req

I have the following code: ``` b := bytes.NewBuffer([]byte("")) go func() { for _, v := range z { jsonStr, err := json.Marshal() if err != nil { continue } b.Write([]byte(string(jsonStr) + "\n")) } }() fullUrl := fmt.Sprintf("%s/%s", baseUrl, "_bulk") req, err := http.NewRequest("POST",

Re: [go-nuts] how to stream json to http post req

thanks that looks correct to me On Wednesday, September 2, 2020 at 2:16:30 PM UTC-7 bbse...@gmail.com wrote: > On Wed, Sep 2, 2020 at 2:49 PM Alexander Mills > wrote: > > > > I have the following code: > > > > ``` > > b := bytes.NewBuffer([]byte("")) > > > > go func() { > > for _, v := range z

Re: [go-nuts] Re: custom type wrapping errors; what am i missing?

> %w is not a formatting verb, so fmt.Prinf("%w") is not valid. yes, i thought i was pasting fmt.Errorf("%w",err) err1:= errors.New("error") > err1= fmt.Errorf("fmt wrapping: %w",err1) > fmt.Println(err1) > > err2:=errors.New("error") > err3= fmt.Errorf("Wrapped: %w",err2) > // Here,

Re: [go-nuts] how to stream json to http post req

On Wed, Sep 2, 2020 at 2:49 PM Alexander Mills wrote: > > I have the following code: > > ``` > b := bytes.NewBuffer([]byte("")) > > go func() { > for _, v := range z { > > jsonStr, err := json.Marshal() > > if err != nil { > continue > } > > b.Write([]byte(string(jsonStr) + "\n")) > } > }() > > >

Re: [go-nuts] Re: custom type wrapping errors; what am i missing?

OK, i think i have it; basically he root of it was i wasn't thinking properly about how errors need/should be implemented as immutable. Unwrap is basically a state getter. (no setter for the wrapped error.) so it seems to me that custom and fmt.Prinf("%w") wrappers have different use cases:

Re: [go-nuts] Re: custom type wrapping errors; what am i missing?

On Wed, Sep 2, 2020 at 12:20 PM 'simon place' via golang-nuts wrote: > > OK, i think i have it; > > basically he root of it was i wasn't thinking properly about how errors > need/should be implemented as immutable. Unwrap is basically a state getter. > (no setter for the wrapped error.) > > so

[go-nuts] Re: regexp group multi Replace Pattern

There are various projects that combine multiple regexps into a single DFA. Have a look at https://github.com/proebsting/re On Wednesday, 2 September 2020 21:23:40 UTC+1, Brian Candler wrote: > > Can you define the problem more clearly? > > It looks like you just want to replace a leading "9",

[go-nuts] Re: regexp group multi Replace Pattern

Can you define the problem more clearly? It looks like you just want to replace a leading "9", "001" or "+1" with "1"? In that case, you just match ^(9|001|[+]1) and replace it with 1 If that's not what you want, then what are the exact rules for how the input needs to be changed? -- You

Re: [go-nuts] Efficient bitmask twiddling

https://godbolt.org/z/6n7G8q I'm actually not sure how good this assembly is, it would be interesting to hear from you, but it looks promising. вт, 1 сент. 2020 г. в 22:54, Oliver Smith : > > In the process of developing a piece of middleware, I need to translate from > a bit-array into a

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

The clarifying question first: What would be the meaning of "none" interface? > A `none` interface would be the zero value of an interface - an interface value with no dynamic type/value. It doesn't solve issue at hand. The issue is, conversion from typed nil > pointer to interface results in

Re: [go-nuts] Dynamic composition of interfaces at runtime?

On Wed, 2 Sep 2020 at 10:56, Jesper Louis Andersen < jesper.louis.ander...@gmail.com> wrote: > Usually, my experience is that these highly dynamic interfaces is an > indication you want to approach the problem from a different angle. You > will converge on something that gets closer and closer to

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

On Wed, Sep 2, 2020 at 3:45 AM targe...@gmail.com wrote: > > > Other people have said this too, but I want to emphasize that there > are not 4 potential states of an interface value. There are 2 > potential states: 1) interface does not hold any value, and is == nil; > 2) interface holds a value,

[go-nuts] Asynchronous preemption

Is it possible to stop the asynchronous preemption like: GODEBUG=asyncpreemptoff=1 go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go I am using gccgo compiler. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe

Re: [go-nuts] Asynchronous preemption

On Wed, Sep 2, 2020 at 7:14 PM Yonatan Gizachew wrote: > Is it possible to stop the asynchronous preemption like: > GODEBUG=asyncpreemptoff=1 go build -o libgotest.so -buildmode=c-shared > -compiler=gccgo test.go > > I am using gccgo compiler. > Yes, although that will only disable async

Re: [go-nuts] Asynchronous preemption

I see. If that is so, what is the job of sysmon thread? On Thursday, September 3, 2020 at 12:35:26 PM UTC+9 Ian Lance Taylor wrote: > On Wed, Sep 2, 2020 at 7:14 PM Yonatan Gizachew wrote: > > > > Is it possible to stop the asynchronous preemption like: > > GODEBUG=asyncpreemptoff=1 go build -o

Re: [go-nuts] Asynchronous preemption

Ok, thanks for the clarification. On Thu, Sep 3, 2020, 11:27 AM Kurtis Rader wrote: > On Wed, Sep 2, 2020 at 7:14 PM Yonatan Gizachew wrote: > >> Is it possible to stop the asynchronous preemption like: >> GODEBUG=asyncpreemptoff=1 go build -o libgotest.so -buildmode=c-shared >>

Re: [go-nuts] Any way to exclude testcase(s) from 'go test'?

On Mon, Aug 31, 2020 at 11:22 PM xiangdong...@gmail.com < xiangdong...@gmail.com> wrote: > The issue happens at building time of 'go test' for misc/cgo/test, I was > expecting 'go test' is powerful enough to skip building a specific case > given a negation pattern and without involving tags, but

Re: [go-nuts] Asynchronous preemption

On Wed, Sep 2, 2020 at 7:14 PM Yonatan Gizachew wrote: > > Is it possible to stop the asynchronous preemption like: > GODEBUG=asyncpreemptoff=1 go build -o libgotest.so -buildmode=c-shared > -compiler=gccgo test.go > > I am using gccgo compiler. Note that executables built by the gccgo compiler