Re: fine-grained lua_pcall() error processing

[petah <lua@...>]

>Reading between the lines, it sounds like this is a custom debugger
>commissioned to work with a particular C++ project, but, it might also be
>distributed as a standalone open source app?

Actually the Lua debugger is a part of a large, internal, realtime 3D engine that's been powering "high-profile" corporate projects for years (www.inhance.com). Since my company's competitors are miles away technologically and we have trouble hiring qualified Lua coders I convinced them to release the debugger itself, under the same MIT license as Lua, for ethical reasons.

I'm one of the PITAs advocating splitting our platform into separate components; a reusable debugger is just one example.

>In that case, you could consider modding the VM, and posting the diff on
>the power patches page.  That way other projects that embed different
>versions of Lua could potentially patch in the hooks needed by your
>debugger.  And if the debugger is awesome enough, there's an outside chance
>that the Lua author's might take notice, and roll the diffs into 5.3 :)

Nah. The #1 thing that sets Lua apart is Teflon resistance to feature creep; I like it that way.

>But if you're serious about supporting a wide range of Lua VM's, pattern
>matching is probably you're only option.

I think it's too dangerous since the error string is unknown. Last thing you want is your debugger daemon crashing on an iOS app.

>If you go this route, I'd also
>grab a copy of the LuaJIT sources, as that's the other version of the VM
>you're likely to encounter in the wild.

LuaJIT isn't on our radar; over ~5 years we've had only one interpreted Lua bottleneck (gigantic memory requirements) which was solved in a few minutes by a custom type implemented in C++.

I don't know what LuaJIT-compatibility would imply, whoever wants it will be free to do so :)

-- p