Wed 21 Sep 2016 06:41:51 PM UTC, comment #11:
Yeah I suppose my thinking was too naive :-) I overlooked that the tests are run by the interpreter, not by a binary fuction.
Well maybe we'll find a way someday.
|
Wed 21 Sep 2016 03:24:13 PM UTC, comment #10:
Is there a way to close an editor tab from the command line? I thought it had to be done by using the mouse on the close icon, or a keyboard shortcut.
|
Wed 21 Sep 2016 09:47:55 AM UTC, comment #9:
Alternatively the files in the editor could be closed using the relevant function call after the tests in debug-cc.tst.
After all, that is what Octave does too upon exit when closing down the GUI.
|
Wed 21 Sep 2016 12:33:57 AM UTC, comment #8:
I think that is the desired behavior for users of the GUI, from what I've seen on bug tracker activity dealing with breakpoints and the GUI editor.
What's surprising is the test suite testing the debugging commands and having those files be opened and remain open in the editor after the test suite finishes. Maybe something could be added to temporarily disable this link during the running of this particular unit test. Not a very high priority, though, I agree.
|
Wed 21 Sep 2016 12:24:40 AM UTC, comment #7:
This was clearly an architectural decision, although I don't know if it was the right one. Whenever a breakpoint is created from the command window, and the GUI is active, the corresponding file is loaded into the editor with the breakpoint set.
Simple test case:
This behavior has been with us a while. It goes back at least to version 3.8.2.
Is it worth changing? Or is it kind of handy that the files you are debugging are automatically available in the GUI editor window?
|
Tue 20 Sep 2016 04:01:08 PM UTC, comment #6:
Opening a fresh Octave, with no files open in the editor, and running
shows 5 files left open in the editor.
|
Tue 20 Sep 2016 03:58:41 PM UTC, comment #5:
Thanks for pointing that out Dmitri. This is likely due to the unit tests in libinterp/corefcn/debug.cc. It tests setting and deleting debug breakpoints in help, ls, @audioplayer/set, @ftp/dir, and quantile.
|
Tue 20 Sep 2016 03:32:26 PM UTC, comment #4:
I see it on Fedora (see atached screenshot). Not only it opens
help.m, ls.m,dir.m,set.m, quantile.m it also sets some breakboints
(that is what red/orange dots are, aren't they?) in some of them.
Some breakponts get cleared off after the test run is finished.
Dmitri.
--
(file #38564)
|
Tue 20 Sep 2016 02:11:35 PM UTC, comment #3:
Rik, I didn't say that is mappers.cc that is at fault, rather that this "bug" happens around the time that the mappers-cc.tst tests run in __run_test_suite__ .
I am quite surprised that it happens during the tests of the binary (builtin) functions (at least, on Windows).
And funny that you can see it on Linux as well; I couldn't (Mageia-4 64bit)
I agree with lowering priority - unless this points to something that can bite later on. But that hasn't happened yet AFAICS.
|
Mon 19 Sep 2016 11:02:53 PM UTC, comment #2:
Also, I can reproduce this on Linux, so this isn't just an MS Windows problem.
|
Mon 19 Sep 2016 10:54:41 PM UTC, comment #1:
Yes, I can confirm this. I've marked it as Minor with a priority of Later since most users will never encounter this.
I suppose there is something that is not being cleaned up during one of the tests.
Are you sure it is mappers.cc-tst that is at fault? I copie that file into a local directory so I wouldn't have to run the whole test suite and then did 'test mappers.cc-tst' and didn't have any new windows pop up.
|
Sat 17 Sep 2016 10:23:13 PM UTC, original submission:
(Couldn't find if this was reported before, but I seem to have a vague reminiscence that it was mentioned somewhere a while ago)
When running __run_test_suite__.m in the GUI on Windows, several .m files get opened in the GUI editor around the time that mappers-cc.tst is tested. I.e., help.m, ls.m, dir.m, set.m and quantile.m, in that order.
I first noted this a few months ago. I suppose this is related to __run_test_suite__.m's operation.
I cannot reproduce this on Linux (that is, with __run_test_suite__.m in an installed Octave).
My mxe-octave setup is up-to-date and "standard".
|