Red dot breakpoints do not stick in v9

[dunbarx]

Richard.

It doesn't always happen.

I just made a small test stack and tried it. The red dot sticks no matter what I do. I then went to a large script in an existing project with lots of stuff in it. The red dot is always ignored if I add or subtract lines above the dot.

It cannot be that the length of the script matters? Have you really never seen this? You always use the "breakpoint" command?

Craig

[FourthWorld]

It cannot be that the length of the script matters?

It might. Once we have a way to reproduce it we can find out.

Have you really never seen this?

I have neither the time nor any reason to mislead you on that.

You always use the "breakpoint" command?

No, I just write perfect code.

Truth I just don't like LC's debugger. Too cumbersome. I use it when I need it, but I rarely need it. I can usually figure out what I need from a well-placed answer dialog faster than stepping through line by line. Or sometimes I use my Flight Recorder. And once in a great while I use my own debugger, which is leaner but given how rarely I use debuggers at all it's usually not worth the trouble to bring into the session.

[Simon Knight]

This sounds much like it might be related to this bug report https://quality.livecode.com/show_bug.cgi?id=19173 that I submitted the other year. The report was about saved breakpoints not working but the worry was that it seemed that my instance of Livecode was the problem.


Simon

[dunbarx]

Richard.

but I rarely need it. I can usually figure out what I need from a well-placed answer dialog faster

I am astonished. I could not live without the debugger, spending LOTS of time there in every project I work on, large or small, and I also write perfect code.

Did I mention that I am astonished?

Craig

[FourthWorld]

This sounds much like it might be related to this bug report https://quality.livecode.com/show_bug.cgi?id=19173 that I submitted the other year. The report was about saved breakpoints not working but the worry was that it seemed that my instance of Livecode was the problem.

Good work there, Simon. Excellent report, and illuminating discussion.

@DunbarX:. Take a gander at that discussion. The participants there seem to have the same mix of experiences as we in this discussion here.

It appears that somewhere along the road to the current file format, certain not-yet-identified circumstances have led a small number objects to have erroneous breakpoint records.

Most useful there is the discovery that when this occurs, those who have seen it report that clearing all breakpoints and then saving allows new breakpoints to work as expected.

Two takeaways from that discussion:

1. While it may be difficult to pin down which line of engine code in which version triggers this, those experiencing it seem to have an easy remedy.

2. As with most issues that don't get resolved quickly, it's not because the engine team doesn't want to fix it, but simply that sometimes we find issues that are difficult to reproduce. When a consistent recipe is available, an issue (certainly one involving a feature as critical as debugging) can be resolved quickly, and often is. Here, as with window layering on Linux and a few others, the challenge is that a consistent recipe is hard to come by. In those cases, if the team can't see it, any attempt to fix it would be just random guesswork.

However difficult they may sometimes be to find, consistent recipes for reproducing an error are critical to resolution.

[FourthWorld]

Richard.

but I rarely need it. I can usually figure out what I need from a well-placed answer dialog faster

I am astonished. I could not live without the debugger, spending LOTS of time there in every project I work on, large or small, and I also write perfect code.

Did I mention that I am astonished?

People are diverse.

I can't explain why I go weeks at a time without having a problem for which stepping through code seems the best fit. Sometimes it is, other times any number of other methods feel more efficient.

Maybe it's cognitively similar to Strict Variable Enforcement. Some swear by it; others of us find it cumbersome.

It's like bracket placement in C or JavaScript, or the infamous dangling "then"s I sometimes see in xTalk.

If I could explain the psychology behind differences in coder habits I'd have a very different job.

But given how long such differences have been around, I'll bet there's a study (or twelve) on that in the ACM archives.

It might be interesting to see how coding habits correlate with other lifestyle habits. Is there a correlation between coders who rarely step through code and coders who bake their own bread, or prefer a bicycle as their primary means of transportation?

Now you've got me tempted to consider a research project, and I'm supposed to be doing more mundane things like making software.

[FourthWorld]

I discovered a punchline to this story: while researching the issue, I did a search for "LiveCode breakpoints ignored" at Duck Duck Go.

What I found was a few discussions relating LiveCode, and a lot of discussions about ignored breakpoints in other IDEs across a wide range of languages.

This seems a tricky issue for many, independent of which tools and languages they're using.

Maybe not surprising, given the nature of task. A friend describes such things as "sticking your fingers between rotating fan blades to adjust the motor."

[Simon Knight]

People are diverse.

and how!

I can't explain why I go weeks at a time without having a problem for which stepping through code seems the best fit. Sometimes it is, other times any number of other methods feel more efficient.

While I do occasionally use breakpoints I prefer writing program status out to a field I normally name debug.

Maybe it's cognitively similar to Strict Variable Enforcement. Some swear by it; others of us find it cumbersome.

I'm on the cumbersome side of the fence but I suspect that it is down to how we use variables and the typical length of our routines. For me variables have short lives and are never global. I try to keep the length individual handlers to no more than what may be displayed on a single screen

It's like bracket placement in C or JavaScript, or the infamous dangling "then"s I sometimes see in xTalk.

"{" I find C and JavaScript hard to read which one of the reasons I use Livecode. Not sure what a dangling "then" is but I am happy to believe that they are "bad news".
"}"

and a lot of discussions about ignored breakpoints in other IDEs across a wide range of languages.

I'm not surprised and it shows that we most be careful of not falling into the trap of thinking that other languages and IDE are fault free.

On a more tech note : I am happy to report that so far the line numbers in 9.04 have stayed fixed to the lines of code which was not always the case in 9.03.

[FourthWorld]

Not sure what a dangling "then" is but I am happy to believe that they are "bad news".

History has seen the human capacity for committing atrocity. Dangling "then" is among the more horrifying.

A sane person would write:

Code: Select all

if SomeCondition is true then
   doSomething
end if

But there are dangerous souls in our midst who seek to destroy our sensibilities with:

Code: Select all

if SomeCondition is true
then
    DoSomething
end if

(My hands feel dirty just typing that)

Worse, this crime against humanity is not only supported in the LiveCode engine, but has been offered as some sort of legitimate option in every xTalk I've seen going all the way back to HyperCard 1.0.

I'm told Saddam Hussein used to study the dangling "then" when dreaming up news ways to hurt people.

On a more tech note : I am happy to report that so far the line numbers in 9.04 have stayed fixed to the lines of code which was not always the case in 9.03.

Good to hear. Thanks. I haven't spent much time in 9.0.4 yet, but I have a long couple days ahead of me and will remember to look for that.

[bogs]

Huh, I'm glad you clarified, for a while I thought you were talking about something like

Code: Select all

if statement then do something

on one line (one of my favorites)

[Simon Knight]

No, I don't believe it - they never do, why ?

The world has gone truly mad: Brexit, Trump and now dangling "then"

I'm off for a lie down.

S

[dunbarx]

Going back to red dots.

9.0.4 seems to hold from a trick earlier in this thread by Simon:

1) open up the stack with the breakpoint issue.
2) select clear all breakpoints from Debug menu.
3) Save Stack
4) quit Livecode
5) launch Livecode and re-open offending stack.
6) Add breakpoints.

If I am working for a long time in a stack then it is well worth the small exercise above. Perhaps these dots are getting more stable...

Thanks to Richard for directing me there.

Craig

[FourthWorld]

I wish I could take credit, but it was the contributors to the bug report who found that solution.

Glad it's working for you too.

Now we can focus our kvetching on window layering in Linux.

[Simon Knight]

Ho Hum,

And now they stick.....

Now I am unable to clear breakpoints in 9.04. The red dot clears but the code still stops. Pressing continue causes it to exit. I tried the the global clear, saving and closing, restarting but they still stopped execution.

Fortunately the deleted points were all inside a single button so I copied the code from it to a text editor, deleted the original, hit apply then copied the code back in from the text editor.

best wishes
Simon

[bogs]

I tried the the global clear, saving and closing, restarting but they still stopped execution.

I'm curious, doesn't just cutting/pasting the code back work anymore?