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
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,
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
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 /usr/local
[ +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.
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() w
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
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
d
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() wrapper.Wrapper
> > }
> >
> > But after comp
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
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 {
> Error()
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 subscribe
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 di
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 n
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
> https://gitlab.com/YottaDB/Lang/Y
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 b
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
https://gitlab.com/YottaDB/Lang/YDBGo/blob/47f5960d03b2c00ae33222ec1d3bdc60a98226c1/buffer_t.go#
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
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.
https://github.com/mightygua
[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
undocumented
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 st
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 (Dy
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
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...
> https:/
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 pc=0x4599
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 enough
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)
/usr/local/go/src/runtime/panic
27 matches
Mail list logo
