There was some discussion about how to handle generated methods in stack
traces in #11432, in particular I brought it up in this
comment: https://github.com/golang/go/issues/11432#issuecomment-146269822.
The discussion eventually led to the addition of the new
runtime.CallersFrames API, but pro
On Mon, Aug 15, 2016 at 10:51 AM, Tim Hockin wrote:
> OK, is there ANY heuristic I can rely on find the "real" call frame?
I don't know. Sorry. As I said earlier, I don't have a good answer here.
You should open an issue for this. For some reason it has not been a
problem, perhaps because mos
OK, is there ANY heuristic I can rely on find the "real" call frame?
On Mon, Aug 15, 2016 at 10:17 AM, Ian Lance Taylor wrote:
> On Sun, Aug 14, 2016 at 10:07 PM, Tim Hockin wrote:
>> Can I rely on "" not changing?
>
> I'm sorry, that's a hard question to answer, because other compilers
> do not
On Sun, Aug 14, 2016 at 10:07 PM, Tim Hockin wrote:
> Can I rely on "" not changing?
I'm sorry, that's a hard question to answer, because other compilers
do not use that string.
There are no plans to change that string for the gc toolchain.
Ian
> On Sun, Aug 14, 2016 at 9:55 PM, Ian Lance Tayl
The autogenerated miranda method only happens if you are calling through an
interface method that is provided by an embedded type. If you're doing
something like
func log(...) {
pc := runtime.Callers(1) // get the caller of log
}
It shouldn't be a problem.
On Monday, 15 August 2016 14:42:1
Can I rely on "" not changing?
On Sun, Aug 14, 2016 at 9:55 PM, Ian Lance Taylor wrote:
> On Sun, Aug 14, 2016 at 9:41 PM, Tim Hockin wrote:
>> On Sun, Aug 14, 2016 at 8:31 PM, Ian Lance Taylor wrote:
>>> On Sun, Aug 14, 2016 at 3:33 PM, Tim Hockin wrote:
Edit: It looks like this has mor
On Sun, Aug 14, 2016 at 9:41 PM, Tim Hockin wrote:
> On Sun, Aug 14, 2016 at 8:31 PM, Ian Lance Taylor wrote:
>> On Sun, Aug 14, 2016 at 3:33 PM, Tim Hockin wrote:
>>> Edit: It looks like this has more to do with being an interface
>>> method than an embedded type.
>>>
>>> https://play.golang.o
On Sun, Aug 14, 2016 at 8:31 PM, Ian Lance Taylor wrote:
> On Sun, Aug 14, 2016 at 3:33 PM, Tim Hockin wrote:
>> Edit: It looks like this has more to do with being an interface
>> method than an embedded type.
>>
>> https://play.golang.org/p/I5XPdWR_O0
>
> Hmmm, you're right. It only happens fo
On Sun, Aug 14, 2016 at 3:33 PM, Tim Hockin wrote:
> Edit: It looks like this has more to do with being an interface
> method than an embedded type.
>
> https://play.golang.org/p/I5XPdWR_O0
Hmmm, you're right. It only happens for a value method.
> Is there a generic way to get the caller safel
Edit: It looks like this has more to do with being an interface
method than an embedded type.
https://play.golang.org/p/I5XPdWR_O0
Is there a generic way to get the caller safely, or should I just
check for and increment?
On Sun, Aug 14, 2016 at 3:02 PM, Tim Hockin wrote:
> It is, in fact, a
It is, in fact, a method on an embedded type. That means I can document it
and it ceases to be a magic number! Thanks.
On Aug 14, 2016 12:27 PM, "Ian Lance Taylor" wrote:
> On Sun, Aug 14, 2016 at 11:10 AM, 'Tim Hockin' via golang-nuts
> wrote:
> > I was playing with a method that wants to pr
On Sun, Aug 14, 2016 at 11:10 AM, 'Tim Hockin' via golang-nuts
wrote:
> I was playing with a method that wants to print the file:line of the
> caller. `runtime.Caller(1)` seems like it should do the trick, but I
> get ':2'. If I call `runtime.Caller(2)` instead it
> seems to work, but I don't kn
I was playing with a method that wants to print the file:line of the
caller. `runtime.Caller(1)` seems like it should do the trick, but I
get ':2'. If I call `runtime.Caller(2)` instead it
seems to work, but I don't know why, so I am reluctant to depend on
that.
Can anyone enlighten me? How can
13 matches
Mail list logo
