Log In  

it'd be great to be able to output to console via a debug command.

P#13848 2015-09-08 10:25 ( Edited 2015-12-10 06:46)

Yeah. I think Pico needs full debug suite, you know, breakpoints, step over, etc.

P#13853 2015-09-08 10:55 ( Edited 2015-09-08 14:55)

A debug log command would be great, I think a big win for not much effort to implement.

Stack trace on error (to debug log and/or screen) would be nice if it's easy.

I doubt anything beyond that is really worth the implementation effort.

P#13882 2015-09-08 19:23 ( Edited 2015-09-08 23:23)

+1 most desired feature, a function to log to console and backtrace on error.

P#13892 2015-09-08 23:27 ( Edited 2015-09-09 03:27)

My current process is inspecting variables on the command line using print() after it crashes.

P#13902 2015-09-09 05:21 ( Edited 2015-09-09 09:21)

@matt: And what if it doesn't crash, but behave in an unintended way? That's why at the very least breakpoints should be implemented.

P#13906 2015-09-09 07:50 ( Edited 2015-09-09 11:50)

Absolutely.

You can make it crash my introducing an out if index error at the point you want to break.

I stated my workaround to show the current state of affairs.

P#13907 2015-09-09 07:54 ( Edited 2015-09-09 11:54)

printh() ("print host") is in for 0.1.2, and it's likely pico-8 will get a stack trace later on. (these are the only debugging tools I ever really appreciate, myself)

P#13987 2015-09-10 18:32 ( Edited 2015-09-10 22:32)

\o/ awesome!
yeah console logging and backtraces are great. an assert would be nice too.

P#13993 2015-09-10 20:49 ( Edited 2015-09-11 00:49)

Throwing the idea out there: [debugger.lua]( https://github.com/slembcke/debugger.lua)

It's a pure Lua command line debugger, and it's meant to be easily embeddable so the IO is trivially remappable. All the basic commands are there (step, next, finish, continue, backtrace, print locals, eval, etc). It has some limited support for output coloring. Best of all, it's pretty simple at ~400 SLoC.

P#14228 2015-09-16 00:17 ( Edited 2015-09-16 04:53)
1

I know I'm probably beating a dead horse here, but what the heck. Mockup time! Doesn't this just say pico-8 to you? It has the same sort of feel to using the "monitor" program on an Apple ][, but with less assembly code. ;)

'L' is list locals. 'P [expr]' is evaluate and print expression. 'N' is step next. 'T' is print trace.

That's all more or less real output from debugger.lua, though I lowered the message verbosity.

All that it would need to be integrated is to:
1) Implement the dbg_read() and dbg_write() functions to work with the pico-8 REPL.
2) Wrap the init/update/draw functions with dbg.call instead of Lua's pcall.
3) Expose dbg() in the pico-8 API. (It's the function you call when you want to enter the debugger.)
Optional) Shorten some of the messages or support colored output.

The rest should "just work" if you are using Lua 5.1 to 5.3 or LuaJIT.

P#14250 2015-09-16 12:58 ( Edited 2015-09-16 16:58)

Debugger.lua is now extremely easy to embed in a project with a single .lua or .c file and a drop in lua_pcall() replacement.
https://github.com/slembcke/debugger.lua

Maybe it's time for a debugger in pico-8? Eh? Eh?

P#17646 2015-12-10 01:46 ( Edited 2015-12-10 06:46)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 15:17:43 | 0.009s | Q:24