61–70 of 76 posts
Earlier quoted context omitted.
We plan to expose all of the inlining information in the DWARF tables so debuggers won't have any problems with this. Internally, the runtime uses a different representation just so we can make it more compact and optimized for the runtime's exact needs. This way, you can also strip the debug info without breaking the runtime's own ability to walk stacks.
Isn't that what `.eh_frame` is for?
Earlier quoted context omitted.
The point is "inlining" already refers to this kind of inlining. The already-present form is more limited than the typical use of the term.
Then what word would you have used in this presentation, given no established word existed?
Earlier quoted context omitted.
The presentation makes a distinction between mid-stack and leaf inlining, and apparently it was only done on leaf calls before because this is less confusing in backtraces.
The point is, as usual, Go is trying to catch up to what everyone else has had for years. The use of non-standard terminology here is suspicious, raising the question that the Go people are trying to hide the fact that they are playing catch-up.
Earlier quoted context omitted.
Then what word would you have used in this presentation, given no established word existed?
"Go inlining improvements..." and then "Conventionally, inlining includes ... but Go has been limited to ... until recently. With ... Go now supports inlining in a broader array of circumstances."
What does it include? You've conveniently managed to skip over the crucial part with ellipses. Calls in the middle of stacks perhaps?
You people have too much time on your hands to go and pick at the wording people use in their presentations.
Earlier quoted context omitted.
I don't think anyone is pretending that Go is a decades-old language. What is the standard term for this kind of inlining which would distinguish it from the inlining already present in the compiler?
> What is the standard term for this kind of inlining which would distinguish it from the inlining already present in the compiler? There isn't a standard term, because virtually all inliners always did what Go is now doing. It's pretty basic functionality.
Earlier quoted context omitted.
Comments like these are so depressing. Someone does a bunch of work to improve the Go compiler and writes a presentation to share their approach (primarily so that other people working on Go can understand and extend it), and gives it all away for free. This is textbook open source citizenry, which should be applauded. But instead, you come along and criticize them for being too specific with their terms (!!) and als…
Nothing about giving your work away for free or wanting to do good necessarily puts one above criticism for misuse (or useless invention) of terminology. It's not a marketing exercise, you are correct -- all the more reason to expect a narrow use of terminology.
Earlier quoted context omitted.
"Go inlining improvements..." and then "Conventionally, inlining includes ... but Go has been limited to ... until recently. With ... Go now supports inlining in a broader array of circumstances."
"Conventionally inclining includes ...?" What does it include? You've conveniently managed to skip over the crucial part with ellipses. Calls in the middle of stacks perhaps? You people have too much time on your hands to go and pick at the wording people use in their presentations.
What kind of argument is that?
Earlier quoted context omitted.
Nothing about giving your work away for free or wanting to do good necessarily puts one above criticism for misuse (or useless invention) of terminology. It's not a marketing exercise, you are correct -- all the more reason to expect a narrow use of terminology.
If you're going to be pedantic, you might at least be strictly correct. There is no existing term that would distinguish it from Go's prior state, so there is no misuse nor "useless invention". Even if there were and you were correct, this would still be pedantry at its finest.
Why would correct use of terminology be "pedantry at its finest"?
What people are concerned about is intellectual dishonesty. The presentation does not go to much effort to show, for example, why the term "mid-stack inlining" needs to be introduced for Go. Do other languages not have this kind of inlining? Does comparing and contrasting other implementations just not matter?