Suggestion - stack traces

[dmarcuse]

It would be helpful to have stack traces as a feature, either built into the shell or as a standalone program. This can be done without the debug API using xpcall and some magic, like so:

It would be easy to add an existing program to the ROM, or add it as a shell feature that can be toggled with the settings API. What do you guys think? I can whip up a PR, I already have the code written.

[dan200]

In CraftOS 2.0 I exposed debug.stacktrace() (but just that function, not the rest of the library), I wouldn't object to someone doing that. You'd also want to make shell and bios use xpcall when invoking things so they can actually grab those stacktraces!

…

On 8 May 2017 at 17:14, apemanzilla ***@***.***> wrote: Would be helpful to have stack traces as a feature, either built into the shell or as a standalone program. This can be done without the debug API using xpcall and some magic, like so <https://pastebin.com/CYQp63kb>: [image: Screenshot] <https://camo.githubusercontent.com/0539bd48e3ab5631bcb244a8952493398006bf5c/687474703a2f2f692e696d6775722e636f6d2f34703739554e762e706e67> It would be easy to add an existing program to the ROM, or add it as a shell feature that can be toggled with the settings API. What do you guys think? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#216>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB3bbFNXRTIjSeubp6Dj8K4i8GjYVTfbks5r3z9QgaJpZM4NUK0h> .

[SquidDev]

If Cobalt (#163) gets merged, it should be safe to expose the entire debug library without issue. However, if not, it shouldn't be too hard to expose a limited subset of the library (traceback, some of getinfo).

[dan200]

In my other codebase I just did the equivalent to dostring( "debug = { traceback = debug.traceback }" )

…

On 8 May 2017 at 17:56, SquidDev ***@***.***> wrote: If Cobalt (#163 <#163>) gets merged, it should be safe to expose the entire debug library without issue. However, if not, it shouldn't be too hard to expose a limited subset of the library (traceback, some of getinfo). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#216 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB3bbMMmiyzMnn_4gxdkIiBbu3Asjl8Tks5r30lWgaJpZM4NUK0h> .

[ghost]

I'd love to have stack traces in CC. Debugging is so much easier when you can see where the problem actually is.

[REDACTED] exposes debug.traceback() and debug.getinfo(), but hides the rest of debug. I think that could be easily implemented by exposing debug from Java, then in bios.lua, doing:

_G.debug = {traceback = debug.traceback, getinfo = debug.getinfo}

I've done similar things in the various kernels (yes, plural) I've written in various Lua environments.

[dmarcuse]

@alexbuzzbee if I remember correctly there were issues with LuaJ and the debug API, which is why it's not available in CC, but the Cobalt PR would fix that. (#163)