Stacktrace: can we avoid xpcall?

[hugomg]

Should we replace the default traceback in our patched Lua version?

[singul4ri7y]

@hugomg That is doable. But if we do so, our patched lua-internal would diverge even more from mainstream Lua, requiring more code management. As the patched Lua is mainstream Lua with just the core API exposed, I think we should keep it that way.

My alternative proposal would be, write a separate documentation emphasizing on using the --use-traceback option while building Pallene and using the xpcall. Now, using xpcall would introduce some issues, like manual intervention and adding code to the main Lua file. Now these issues can be addressed accordingly:

1) For adding code to the Lua file, there is a chance that you may commit the "debug" Lua file to the main repository. I would suggest in this case is to use .gitignore and add the following:

...
*/*_pln_debug.lua

Then create a file named <somelua>_pln_debug.lua by copying the contents of the file (or copying the file and changing the name; whichever works) and adding the wrapper function using xpcall on it. Done.

2. As for the manual intervention part. You would use GDB to figure out the stack traceback anyway for C or Pallene for that matter. Comparatively, adding just an xpcall in a different Lua file should be less of a hassle in my opinion.

Let me know which one works for you :).

[hugomg]

I like the idea of using a wrapper script. That would address the original motivation of not wanting to tell users to edit their source files to insert a xpcall.

I didn't understand the part about copying the contents of the file. I suspect we could make a wrapper script that receives the name of the original Lua script in the command-line arguments and then calls it using dofile inside a xpcall.

pallene-debug main.lua arg1 arg2 arg3

[singul4ri7y]

About copying contents of the file: I just meant copying the file :)

The script idea sounds neat 👌.

[singul4ri7y]

This issue has been solved by pt-lua Lua frontend from pallene-tracer.