Re: [go-nuts] Tools for developing Go compiler/ Go code from SSA

On Wed, Jul 3, 2019 at 9:04 PM Ian Lance Taylor wrote: > [ +khr ] > > On Wed, Jul 3, 2019 at 4:46 PM Mohit Verma wrote: > > > > Hi All, > > > > I am trying to change the ssa phase of Go compiler to do extra work > during memory stores. > > For example whenever there is a memory store, I want to

Re: [go-nuts] can't change build in type error interface

On Thursday, July 4, 2019 at 3:28:01 AM UTC+2, Ian Lance Taylor wrote: > > On Wed, Jul 3, 2019 at 6:19 PM Gert > > wrote: > > > > On Thursday, July 4, 2019 at 2:52:42 AM UTC+2, Ian Lance Taylor wrote: > >> > >> On Wed, Jul 3, 2019 at 4:39 PM Gert wrote: > >> > > >> > On Thursday, July 4,

Re: [go-nuts] can't change build in type error interface

On Wed, Jul 3, 2019 at 6:19 PM Gert wrote: > > On Thursday, July 4, 2019 at 2:52:42 AM UTC+2, Ian Lance Taylor wrote: >> >> On Wed, Jul 3, 2019 at 4:39 PM Gert wrote: >> > >> > On Thursday, July 4, 2019 at 12:39:34 AM UTC+2, Ian Lance Taylor wrote: >> >> >> >> On Wed, Jul 3, 2019 at 3:30 PM Gert

Re: [go-nuts] can't change build in type error interface

On Thursday, July 4, 2019 at 2:52:42 AM UTC+2, Ian Lance Taylor wrote: > > On Wed, Jul 3, 2019 at 4:39 PM Gert > > wrote: > > > > On Thursday, July 4, 2019 at 12:39:34 AM UTC+2, Ian Lance Taylor wrote: > >> > >> On Wed, Jul 3, 2019 at 3:30 PM Gert wrote: > >> > > >> > I changed

Re: [go-nuts] Tools for developing Go compiler/ Go code from SSA

[ +khr ] On Wed, Jul 3, 2019 at 4:46 PM Mohit Verma wrote: > > Hi All, > > I am trying to change the ssa phase of Go compiler to do extra work during > memory stores. > For example whenever there is a memory store, I want to make a function call > to one of my Go packages instead of the store.

Re: [go-nuts] can't change build in type error interface

On Wed, Jul 3, 2019 at 4:39 PM Gert wrote: > > On Thursday, July 4, 2019 at 12:39:34 AM UTC+2, Ian Lance Taylor wrote: >> >> On Wed, Jul 3, 2019 at 3:30 PM Gert wrote: >> > >> > I changed /usr/local/go/src/builtin/builtin.go >> > >> > type error interface { >> > Error() string >> > Unwrap()

Re: [go-nuts] Does your Windows app rely on os.Rename() or .Remove() ?

On Wed, Jul 3, 2019 at 1:09 PM Liam wrote: > [Sorry to keep re-posting this; I'm keeping it visible for infrequent > readers] > I'm a frequent reader and I've now seen it four times. IMHO, that's enough. Jim > > Microsoft recommends changing syscall.Open() for GOOS=windows to fix this. > Pls

[go-nuts] Tools for developing Go compiler/ Go code from SSA

Hi All, I am trying to change the ssa phase of Go compiler to do extra work during memory stores. For example whenever there is a memory store, I want to make a function call to one of my Go packages instead of the store. So, far I have some working changes and I can see the new SSA nodes when I

Re: [go-nuts] `on err` alternative to `try()` has traction...?

May be indent(1) can be taught about Go syntax rules so that it can "pretty-print" ala Lisp? > On Jul 3, 2019, at 3:25 PM, Michael Jones wrote: > > Any form of restraining gofmt has my vote. One that I despise is ruining: > > switch v { > case ‘a’: doA = true > case ‘b’: doB = true > : > case

Re: [go-nuts] can't change build in type error interface

On Wed, Jul 3, 2019 at 3:30 PM Gert wrote: > > I changed /usr/local/go/src/builtin/builtin.go > > type error interface { > Error() string > Unwrap() wrapper.Wrapper > } > > But after compiling go successfully with ./all.bash it seems type error is > stil > > type error interface { >

[go-nuts] can't change build in type error interface

I changed /usr/local/go/src/builtin/builtin.go type error interface { Error() string Unwrap() wrapper.Wrapper } But after compiling go successfully with ./all.bash it seems type error is stil type error interface { Error() string } -- You received this message because you are

Re: [go-nuts] Re: `on err` alternative to `try()` has traction...?

Any form of restraining gofmt has my vote. One that I despise is ruining: switch v { case ‘a’: doA = true case ‘b’: doB = true : case ‘z’: doZ = true } Just had this two days ago. So sad to see it balloon up On Wed, Jul 3, 2019 at 11:36 AM Aston Motes wrote: > This proposal is not very much

Re: [go-nuts] Is runtime.Keepalive() needed inside the methods for a receiver object?

Thank you very much, Ian. Regards – Bhaskar On Wednesday, July 3, 2019 at 5:44:58 PM UTC-4, Ian Lance Taylor wrote: > > On Wed, Jul 3, 2019 at 1:32 PM K.S. Bhaskar > wrote: > > > > https://github.com/golang/go/issues/13347#issuecomment-158568326 seems > to suggest runtime.KeepAlive() is not

Re: [go-nuts] Is runtime.Keepalive() needed inside the methods for a receiver object?

On Wed, Jul 3, 2019 at 1:32 PM K.S. Bhaskar wrote: > > https://github.com/golang/go/issues/13347#issuecomment-158568326 seems to > suggest runtime.KeepAlive() is not needed but it does not seem definitive. > > If there is a function such as the one below (from >

Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

I have been following the various proposals for changing error handling in Go since the beginning. Recently I've decided I probably would not use them and I would stick with the explicit error checking. While verbose and repetitive, in my opinion it is the easiest to read and understand. I've

[go-nuts] Is runtime.Keepalive() needed inside the methods for a receiver object?

https://github.com/golang/go/issues/13347#issuecomment-158568326 seems to suggest runtime.KeepAlive() is not needed but it does not seem definitive. If there is a function such as the one below (from

Re: [go-nuts] Re: `on err` alternative to `try()` has traction...?

This proposal is not very much different from a one-liner if err != nil { } It's just 10 more characters. Granted, gofmt won't leave the one-liner formatted that way, but it's not much more typing and comes with the benefit of not needing a new keyword. One variation on this proposal that is a

Re: [go-nuts] OOM occurring with a small heap

I actually just managed to trace down the root cause of the bug, and it's quite surprising. It's not a heap overflow, it's a stack overflow, due to a bug in the stdlib! Specifically, adding the same http.ClientTrace twice onto a request context causes a stack overflow.

Re: [go-nuts] Does your Windows app rely on os.Rename() or .Remove() ?

[Sorry to keep re-posting this; I'm keeping it visible for infrequent readers] Microsoft recommends changing syscall.Open() for GOOS=windows to fix this. Pls reply if you know of existing apps that rely on it. This code fails with a "sharing violation" on Windows. That behavior is

Re: [go-nuts] panic during panic

On Wed, Jul 3, 2019 at 12:03 AM Mayank Jha wrote: > > fatal error: freedefer with d._panic != nil > > goroutine 7909027 [running]: > fatal error: unexpected signal during runtime execution > panic during panic > [signal SIGSEGV: segmentation violation code=0x1 addr=0x1c pc=0x459951] > > runtime

Re: [go-nuts] OOM occurring with a small heap

On Mon, Jul 1, 2019 at 12:42 PM 'Yunchi Luo' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Hello, I'd like to solicit some help with a weird GC issue we are seeing. > > I'm trying to debug OOM on a service we are running in k8s. The service is > just a CRUD server hitting a database

Re: [go-nuts] Re: A counter proposal to the try proposal - catch

The two posts I made regarding the errors as values blog clearly demonstrates the significant problems with the current approach. > On Jul 3, 2019, at 8:23 AM, mh cbon wrote: > > but exceptions are shit. even the typed catch/final statements are a > workaround. > >> On Sunday, June 30, 2019

[go-nuts] Re: `on err` alternative to `try()` has traction...?

I like this. A lot. It's clean and explicit. The reader only needs to understand that 'on' is a test for a nil value (vs 'if' which tests for boolean true). On Tuesday, July 2, 2019 at 3:57:24 PM UTC-4, Liam wrote: > > This proposal has attracted modest attention from the Go team... >

Re: [go-nuts] panic during panic

Where is the code? On Wed, Jul 3, 2019 at 3:03 AM Mayank Jha wrote: > fatal error: freedefer with d._panic != nil > > goroutine 7909027 [running]: > fatal error: unexpected signal during runtime execution > panic during panic > [signal SIGSEGV: segmentation violation code=0x1 addr=0x1c

Re: [go-nuts] Re: A counter proposal to the try proposal - catch

but exceptions are shit. even the typed catch/final statements are a workaround. On Sunday, June 30, 2019 at 7:03:49 PM UTC+2, Robert Engels wrote: > > I think both of the proposals are fine, but they suffer from the “lack of > completeness”. In that, they improve things, but don’t go far

[go-nuts] panic during panic

fatal error: freedefer with d._panic != nil goroutine 7909027 [running]: fatal error: unexpected signal during runtime execution panic during panic [signal SIGSEGV: segmentation violation code=0x1 addr=0x1c pc=0x459951] runtime stack: runtime.throw(0x185c7d9, 0x2a)