2 comments

  • willquack 4 hours ago ago

    > `seapie.breakpoint()` opens a working `>>>` REPL at the current execution state. Any changes to variables or function definitions persist. Debugger state is exposed via built-ins (e.g. `_magic_`), and stepping/frame control/etc is handled via small `!commands`.

    This is largely what `pdb` does already, no? Example:

    ```

    (Pdb) list

      1   something = 100
    
      2   import pdb; pdb.set_trace()
    
      3  -> print(f"value is: {something}")
    
    (Pdb) something = 1234

    (Pdb) c

    value is: 1234

    ```

    I do like that you use `!<cmd>` to avoid the naming collision issue in pdb between commands and python code!!!

  • malux85 4 hours ago ago

    I use debuggers heavily, I code like Carmack does - I basically live in the debugger. The REPL at breakpoints is already integrated into my IDEs (all of the different ones) for the last 20 years, I couldn’t imagine a debugger without this functionality.

    I guess this could be useful if you were cli only and didn’t use an IDE, but it’s not just the REPL that I like, in my IDE when I hit a breakpoint, I can see all local variables, the whole call stack without having to do anything (don’t have to type commands, don’t have to click buttons) - I want to see the entire program state without having to type a bunch of stuff at a REPL, that would slow me down enormously.

    For example in the gif when you hit a breakpoint, print the line straight away! Don’t make me type: print(__line__, __source__) just to see which breakpoint I hit (!)

    Also I preview of the variables would be better, in my ide I see a list if all the local variables and all of their values (str, int, float, are just shown, numpy arrays the shape is shown, arrays the first few values are shown and the length) again, all of this without having to type exhaustive print statements into a REPL

    Maybe it’s not your focus though, I’m just trying to say what I love about debugger driven development