Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Breakpoint: another cool tool to not use

edited June 2 in Code Sharing Posts: 1,163

Presenting... Breakpoint!

Do you ever miss the cool breakpoint features other IDEs have?

Would debugging be SO much easier if you could step line-by-line through your code?

Look no further! You can sort of simulate that behavior mostly kind of with Breakpoint!

Attached is a copy of the builtin “Flappy” project that demonstrates the two breakpoint modes offered; a straight-up normal breakpoint, that stops the code wherever it’s placed and then lets you jump back into the action, and a step-by-step breakpoint where you can examine what’s going on with a fine-toothed comb.

I’ve posted some code that used this method before, but this is the first time I’ve made it general enough to be used by anyone for any purpose. It’s far from perfect, and has some severe limitations, but it’s pretty good, and personally, it helped me find my way through some absolutely maddening bugs I had previously spent days tracking down.

...but don’t use it! Or maybe do! Just be careful!...

Like with TabInator, there’s currently a Codea bug that this can trigger (a different one) . This one doesn’t lose your data, so it’s not as much of a “maybe just don’t use this at all right now” situation. It is super annoying though, because it makes the play button stop working, and you have to close Codea completely and re-open it before the play button works again.

And that said, again I personally have found this extremely helpful even with that bug un-solved. There was just no other way to get at the guts of my code while it was running, and I was willing to live with the drawbacks to untangle the mess I was in.

So yeah. I think this is cool too. Just be aware that, currently, it comes with some drawbacks.

...also it should be noted that, in the end, this is a pretty shoddy stand-in for actual debugging tools. Codea still really needs that, and this stopgap jalopy doesn’t come close to fitting that bill.

Comments

  • dave1707dave1707 Mod
    Posts: 9,233

    Is this supposed to be used with an external keyboard.

  • Posts: 1,163

    @dave1707 no... my iPad keyboard has a ‘tab’ key on it, am I excluding people who don’t? It could be any key combination, I just wanted one that wasn’t super common yet would be easy to activate with one tap.

  • dave1707dave1707 Mod
    Posts: 9,233

    @UberGoober The iPad I use all the time doesn’t have a tab on the keyboard. My other one does, but I don’t use that one. Your breakpoint prints I can inspect flapper.body.x, but nothing I do does anything. So can you say exactly how I’m supposed to inspect anything.

  • Posts: 1,163

    @dave1707 those are good questions, and if it's okay, I'm going to reply over on this thread: https://codea.io/talk/discussion/11620/why-is-one-tab-not-being-imported-as-a-dependency#latest

    ...because I think Ron might be interested in the answers to your questions too.

  • Posts: 1,043

    i dl;d this. it breaks but typing t or q or anything on the screen kbd does nothing.
    this seem like the right thread for this topic, not the dependency thread.

  • edited June 3 Posts: 1,163

    @RonJeffries so just to be clear, again: yes, it does nothing.

    And not only that, but it prevents all other interaction with the program while suspended.

    I’m a little confused by this being brought up so often when I think I’ve been explaining it explicitly from the start. It only stops execution and optionally runs a function every time it stops. Yes that makes it super limited, but it can still be a great help, and has been to me.

  • Posts: 1,163

    @RonJeffries any chance, are you tapping the little area at the lower left that says “type a command” before you’re tapping t and q?

    Don’t do that; it activates a different keyboard, oddly, and for some reason that keyboard’s keypresses are not accessible to the keyboardBuffer() command, which means you’re left with with no way to step through the code or exit the suspended state.

    Any interaction you want to do with the program has to be put in your callback functions...

    ...although I suppose, if you wanted to, you could write your own functions that responded to keypresses other than t and q, and then put that code inside the infinite loop in the breakpoint code—in theory that would let you do almost anything you wanted.

  • Posts: 1,043

    ok

  • edited June 3 Posts: 1,163

    Lol well said

  • Posts: 1,163

    @RonJeffries when I think of it, I could have the breakpoints optionally take a parameter that’s a string-indexed table of functions.

    Then the breakpoint could iterate over that table in every loop, and search the keyboard buffer for any of those keys, and if you’ve typed in one of the keys it runs the associated function.

    Hey presto, you have as much interactivity as you can code.

    Not sure it’s worth the trouble but I can’t see any reason it wouldn’t work.

    Also not sure it’s all that much trouble.

  • Posts: 1,043

    i can't think of any use for the thing.

  • edited June 4 Posts: 1,163

    @RonJeffries proof's in the pudding, I guess.

    It was invaluable for me. I couldn't understand why I was getting certain bugs, and I figured it out with this.

    I used it to examine how the code was flowing from function to function, and to examine the value of certain variables as the code flowed, and that helped me see what was going wrong. It's not a great tool, but it's the only tool that can show me that AFAIK.

    I mean, if you can't think of how to use something that demonstrates, live, what line the project is currently on, and lets you step through the code line-by-line to see how it's jumping around, and lets you see the value of any given variable as it does that jumping around... well then I guess I understand it seeming like it's no use to you.

  • Posts: 1,043

    it doesn't do those things for me, since it seems unable to use the onscreen keyboard. as for debugging, i don't do much, because my tests usually find the problems. when i do need to debug, i might put a print where i want to see some values, or an error or assert if i want to stop. stepping is something i very very rarely have the need for.

    but if it works for you, great!

  • Posts: 1,043

    tried it again. it gets codea so stuck that it won't run any program until i toss codea off the screen to totally exit it and restart it. i don't think i'll try it again.

  • Posts: 1,163

    That’s not my bug, it’s a Codea bug, it’s being discussed in one of the threads.

    Dave has written a five-line project that makes it happen.

    It’s hunky dory with me if you’ve no use for my project, but kindly don’t blame me for the app’s bugs.

  • edited June 6 Posts: 1,163

    This is how it works for me; can you tell me what goes different for you?

    The most confusing thing you’re telling me is that for you the t and q keys don’t work — as you can see they totally work for me.

  • edited June 6 Posts: 1,163

    @RonJeffries Updated video link, should work now.

    I fully get it if you never want to run this project ever again, but if you ever care to, I would love to see a video of what’s happening for you when you say the keyboard keys don’t work.

    Again: The bug that makes the play button not work is not my bug, it’s a known issue in Codea right now.

Sign In or Register to comment.