Tue 08 Nov 2016 07:16:55 PM UTC, comment #19:
I just submitted a patch for bug #49171. It's not great, but it seems to solve the problem reported there without breaking the examples in comment #9.
|
Tue 08 Nov 2016 06:58:34 PM UTC, comment #18:
Rik, I can confirm the behavior in he sense that when saving a file from the editor, Octave complains about parse errors that had just been fixed in the editor.
However, I think this error has popped up more recently than end of July; maybe only a month ago.
Has it been tried to back out the offending changeset in comment #14 to see if it helps?
|
Tue 08 Nov 2016 05:11:06 PM UTC, comment #17:
Added a dependency to bug #49171. The fix for breakpoints and program counter arrows, is now causing the old file to be parsed rather than the current file in a "save" operation.
|
Tue 26 Jul 2016 12:32:25 AM UTC, comment #16:
Thanks. Closing report.
|
Tue 26 Jul 2016 12:14:46 AM UTC, comment #15:
I tried the original instructions and now it seems to be working correctly.
I tried other thing also and there were no problems
I think it can be closed.
Doug
|
Mon 25 Jul 2016 11:53:47 PM UTC, comment #14:
I updated this changeset and pushed it here:
http://hg.savannah.gnu.org/hgweb/octave/rev/acdd8983d308
Can someone verify that it is still working and if so, we can close this report.
Thanks.
|
Tue 03 May 2016 01:05:36 PM UTC, comment #13:
I can confirm the latest patch (comment #10) works OK in the cases in comments 1, 3 and 9.
|
Thu 03 Mar 2016 09:51:05 AM UTC, comment #12:
I mean "now", not "no" :)
|
Thu 03 Mar 2016 09:50:35 AM UTC, comment #11:
No seems to work in all cases I checked.
|
Thu 03 Mar 2016 09:07:11 AM UTC, comment #10:
Thanks, Ruslan.
The problem was due to a delay in the mechanism for executing commands from within GUI code. I've put in a hack to wait for the "dbquit" command to complete.
I'm not sure if there is a better technique. It isn't possible to call Fdbquit directly, since it throws an interrupt exception rather than returning.
(file #36533)
|
Wed 02 Mar 2016 10:20:44 AM UTC, comment #9:
One case fixed, another not.
Fixed:
1. Make a breakpoint
2. Run
3. Stop
4. Change file, save
5. Run (now the breakpoint is preserved)
Still broken:
1. Make a breakpoint
2. Run
3. Change file, press Ctrl+S
4. Answer "Save" in the newly-appeared dialog
5. See breakpoints are lost
|
Wed 02 Mar 2016 07:02:26 AM UTC, comment #8:
Oops! I should have noticed that. The attached patch should fix the problem.
The problem wasn't actually that my patch removed the breakpoints. They are automatically removed when the file is saved, and restored afterwards. The problem was that I was clearing the file from memory before it had recorded where the breakpoints were. Now it does it after.
(file #36524)
|
Mon 29 Feb 2016 10:55:01 AM UTC, comment #7:
After some testing, I've found a problem with your patch. Namely, after saving the file all breakpoints set in that file are lost. This behavior is quite painful for the user (see bug #47295 for some discussion). The least what should be done is restoration of breakpoints somewhere near the lines they used to be. Even better would be if Octave tracked added/removed lines to update breakpoints position (or delete a breakpoint if the containing line has been deleted).
|
Thu 25 Feb 2016 12:09:27 PM UTC, comment #6:
After applying only the previous patch the yellow arrow behaves correctly.
After applying only the new patch I haven't found any anomalies with breakpoints. Basically the problematic cases now give a message asking whether to quit debugging mode, so no way to exactly reproduce, but anything I tried didn't lead to anomalies, so that's OK.
The new patch doesn't appear address the arrow problem, so both patches have to be applied to completely fix this bug.
|
Tue 23 Feb 2016 10:25:38 PM UTC, comment #5:
Ruslan, the attached patch should fix the error. It works on the example you gave.
Could you please have a try and let me know if any changes are needed?
(file #36446)
|
Sat 06 Feb 2016 01:41:04 AM UTC, comment #4:
Ruslan, the yellow arrow issue is easy to resolve. See the attached patch.
The issue of breakpoints is that Octave is using a cached version of the file, in which the blank line is still there. Notice that when you can't place the breakpoint on test2=2, you can place one on the comment following end.
I'm still thinking of where in the code to force the reload.
(file #36261)
|
Fri 15 Jan 2016 04:54:29 PM UTC, comment #3:
Thanks, that commit is definitely an improvement, but still not complete: yellow arrow still remains there after quitting the debug mode.
Also the following sequence shows another case when breakpoint isn't cleared (should I file separate bug reports for these problems?):
With the same test file, do
1. Break at "test2=2;"
2. Run
3. Insert newline before breakpoint
4. Save
5. Press "Quit Debug Mode"
6. Remove the breakpoint
7. Remove the newline added in step 3
8. Save
9. Try to set breakpoint as in step 1
10. See breakpoint on "end" instead of "test2=2;"
11. Run
12. Try to clear breakpoint at "end"
13. See it still there
If you quit debug mode, you'll see the breakpoint actually vanish.
|
Fri 15 Jan 2016 12:06:09 PM UTC, comment #2:
This should be fixed in changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/0a09c3cae800
Can the bug report be closed now?
|
Tue 08 Dec 2015 02:14:20 PM UTC, comment #1:
Somehow the rest of text got eaten by the site. Here's another try:
Steps to reproduce:
1. Make a breakpoint at "test2=2;" line
2. Run
3. When breakpoint is hit, add a newline after "test=1;"
4. Press "Quit Debug Mode"
If you saved the file between steps 3 and 4, then you have red breakpoint icon and yellow program counter arrow, which you can't remove except by reopening the file.
If you didn't save the file, you can remove the breakpoint, but the yellow program counter arrow will still remain there or on the "end" line.
In any case, you can make a breakpoint on another line ("test=1;") and repeat the experiment, now adding line break before this line. This will give you two unremovable yellow arrows and one unremovable breakpoint icon.
|
Tue 08 Dec 2015 02:11:10 PM UTC, original submission:
You can reproduce this on a simple file with the following code:
|