Long answer: It should be possible, but I know of only one way.
A horrible way.
You could cause an error inside a protected call. This should, if im not mistaken, give you an option to get the stacktrace. You could then parse this stacktrace.
I doubt that is a good solution though.
So probably I should ask: What would you need that for?
i'd like to record what functions are calling a particular function. it's for a message handling system and it would be nice to know if something is sending a message that has nobody listening for it and if so, who it is that's sending it so i can see if it's a bug/typo.
i was thinking of a different horrible way:
scrubbing _G[] to generate a lookup table for all known functions (recursively descending into tables for methods) and then indexing them by their environment via getfenv and then using getfenv(1) inside my message handling function to look up into that function name table. if no name, then assume an anonymous function, i guess. altho, maybe it's not really that horrible. horrible sounding stuff is often really easy in lua.
scrubbing _G[] to generate a lookup table for all known functions (recursively descending into tables for methods) and then indexing them by their environment via getfenv and then using getfenv(1) inside my message handling function to look up into that function name table. if no name, then assume an anonymous function, i guess. altho, maybe it's not really that horrible. horrible sounding stuff is often really easy in lua.
Afaik you won't get every function that way. Consider the following situation:
function foo()
local bar = function()
-- do evil stuff which calls lilsparky's function
end
return bar
end
I don't see any way to access this closure (but I might be missing something).
But since you got a better solution, that won't be a real problem.
debugstack is of course a much cleaner way than my suggestion.
I would still like to remind you, that this information should only be used for debuggin purposes, i.e, you should not behave differently based on the name of the called function.
I would still like to remind you, that this information should only be used for debuggin purposes, i.e, you should not behave differently based on the name of the called function.
This please. Consider:
local f = function() <...calls your name-deciphering function... > end
foo = f
bar = f
_G[42] = { baz = f }
-- postcondition: _G.foo == _G["bar"] == _G[42].baz
f()
The 64 million bit question of the hour: what is the name of this function? Followup questions: why do you care and what are you going to do with it? :-)
Answer to first question: the string "f" is unavailable at runtime as the local name (at least in WoW's Lua). All functions are technically anonymous functions and there is never an official/primary name for them. The three names in the comment line above are all equally good names (but if I see people around here using naming schemes like that third one, I'll be smacking some knuckles with a wooden ruler).
yeah, i had figured there'd be some cases of anonymous functions. it's only a bit of info to help me debug and is informational only. if i even decide i need it. my first version just used the environment which was actually good enough to let me print an error and record that i had acknowledged the error so it wouldn't keep printing.
probably won't need to go further for now, but i might use this for something else.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Long answer: It should be possible, but I know of only one way.
A horrible way.
You could cause an error inside a protected call. This should, if im not mistaken, give you an option to get the stacktrace. You could then parse this stacktrace.
I doubt that is a good solution though.
So probably I should ask: What would you need that for?
i was thinking of a different horrible way:
scrubbing _G[] to generate a lookup table for all known functions (recursively descending into tables for methods) and then indexing them by their environment via getfenv and then using getfenv(1) inside my message handling function to look up into that function name table. if no name, then assume an anonymous function, i guess. altho, maybe it's not really that horrible. horrible sounding stuff is often really easy in lua.
Afaik you won't get every function that way. Consider the following situation:
function foo() local bar = function() -- do evil stuff which calls lilsparky's function end return bar endI don't see any way to access this closure (but I might be missing something).
But since you got a better solution, that won't be a real problem.
debugstack is of course a much cleaner way than my suggestion.
I would still like to remind you, that this information should only be used for debuggin purposes, i.e, you should not behave differently based on the name of the called function.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis please. Consider:
local f = function() <...calls your name-deciphering function... > end foo = f bar = f _G[42] = { baz = f } -- postcondition: _G.foo == _G["bar"] == _G[42].baz f()The 64 million bit question of the hour: what is the name of this function? Followup questions: why do you care and what are you going to do with it? :-)
Answer to first question: the string "f" is unavailable at runtime as the local name (at least in WoW's Lua). All functions are technically anonymous functions and there is never an official/primary name for them. The three names in the comment line above are all equally good names (but if I see people around here using naming schemes like that third one, I'll be smacking some knuckles with a wooden ruler).
-
View User Profile
-
View Posts
-
Send Message
Project AuthorBut it's so much shorter than:
_G["Answer to the Ultimate Question of Life, the Universe, and Everything"]= { baz = f }-
View User Profile
-
View Posts
-
Send Message
Curse Premiumprobably won't need to go further for now, but i might use this for something else.