Felix Geisendörfer
Felix Geisendörfer
In reply to @sumerc's comment here: https://github.com/felixge/fgprof/pull/11#discussion_r548553475 > I was too busy lately and could not find time to look/think into this too much. No worries, me too 🙈. >...
> Anyway, I will try working on this whenever I find any time, I don't expect it to be too much complicated AFAIU. However, the tricky part is finding any...
> Yes. It is a good idea. In any case, Goroutineprofile seems to be in need of some kind of refactor for situations like these? The current one: returning all...
@brancz my understanding is that the current profile extension mechanism isn't suitable for fgprof. The problem is that the only way to add a stack trace to a `*Profile` is...
@brancz yeah, something like `func (p *Profile) AddStack(value interface{}, stack runtime.StackRecord)` might do the trick. But I'd have to prototype it a bit more to see if it would work...
Closing this since the upstream proposal was rejected.
Sorry for the late reply. Yeah, this sounds like a nice idea. The problem is that the API I'm currently using doesn't expose labels and the other APIs may have...
Yes, prepared statements are on my todo list. I don't need them myself, so unfortunately they kind of linger at the bottom of the list unless somebody wants to sponsor...
Prepared statements use a range of additional packets that are currently not implemented by my driver: - http://dev.mysql.com/doc/internals/en/prepared-statement-initialization-packet.html - http://dev.mysql.com/doc/internals/en/parameter-packet.html - http://dev.mysql.com/doc/internals/en/long-data-packet.html - http://dev.mysql.com/doc/internals/en/execute-packet.html I have not yet analyzed how...
> How does https://github.com/sidorares/nodejs-mysql-native handle this? It seems to implement the parts of the protocol that are required for prepared statements. > Any reason not to just borrow parts of...