曹亚文

I think there is some other trick to solve this problem. Such like keep all log function with same stack depth. Now when we invoke Println, the calling path is...

It's right. I'll update it this weekend.

I have complete it. But I find another problem some framework insert their own function object between the real caller and entry.log. Look at below stack info:  This is...

I think I find out the reason. If we use ```Logger``` instance, the call stack is ```Logger.Println -> Entry.Println -> Entry.log```. If we use ```Entry``` instance which is created by...

I write a hook like this. Magic number 5 work well both with Logger and Entry. ```go import ( "path/filepath" "runtime" "strconv" "strings" "github.com/bobcyw/logrus" ) func NewNormalCaller() logrus.Hook { return...

Hi, @sirupsen , I have rebased this commit on the newest master branch. And solved the unstable caller problem. The solution is modifying not only entry's function but also public...

@fs-eire this is not work for me when I use protobuf. ```typescript case 4: if (tag !== 32) { break; } message.int64Field = longToNumber(reader.int64() as Long); continue; ``` ```bash src/tdo/type_test.ts:228:63...