[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Function Source
- From: "Mark Meijer" <meijer78@...>
- Date: Tue, 16 Sep 2008 00:13:29 +0200
One approach might be to somehow tie into the actual parsing process
of Lua, and keep your extra debug info (i.e. function definition in
source code format) as it reads the chunk. I wouldn't know how
exactly, but perhaps Luiz's tokenf is a starting point:
http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/#tokenf (bottom of page)
Although I guess tokens are only part of the story. I don't know, I'm
just throwing random ideas around. MetaLua or LuaSub can probably help
more.
Parsing the code yourself might be a practical option, though. In case
you didn't know about this one yet: http://leg.luaforge.net/ :)
2008/9/15 Brian Weed <brianw@imaginengine.com>:
> I'm looking for a way to get the source string of a function from Lua, but
> I'd rather not have to parse it myself.
>
> Using the debug library, I see that I could get the source filename, and
> line numbers of where the function was defined...But I was hoping there was
> a way for me to ask the debug library to give me exactly the string that was
> used to define the function, and nothing more. This would only be for named
> functions.
>
> Example:
>
> -- bob.lua
> --
> return {
> name = "Bob",
> OnClick = function(self) print("You clicked on "..self.name) end,
> }
> -- EOF
>
> I want to do this:
>
> local bob = dofile("bob.lua")
>
> print(debug.getinfo(bob.OnClick).string)
>
>>> function(self) print("You clicked on "..self.name) end
>
> Since this exact functionality does not seem to exist in the debug library,
> I'm looking at adding it, but I wanted to ask here if someone already has
> something like this, or a parser that can get this information.
>
> This is for an object editor, where the user can load, edit , and save the
> code associated with objects....Edit, and Save are trivial. Loading is what
> I'm asking about. Worst case is I could store the function as a string, but
> I'd rather not.
>
> Brian