Wed 09 Nov 2016 05:15:28 AM UTC, comment #12:
I have this change on the dev branch, and it works fine.
Good job!
|
Tue 08 Nov 2016 08:11:46 PM UTC, comment #11:
There must be a difference in compilers. I changed the code to
and checked it in on the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/4678729e8ae1).
|
Tue 08 Nov 2016 07:26:41 PM UTC, comment #10:
I was just about to submit and almost identical patch. However, mine was slightly different because it doesn't seem my compile allows the comparison of octave_value_list and bool
I will still attach my diff, but the difference was that I used
instead.
(file #38907)
|
Tue 08 Nov 2016 07:13:21 PM UTC, comment #9:
I've submitted a patch which applies against stable which appears to solve this problem, while still maintaining the fix for bug #46632). It's not perfect, I sometimes get multiple warning about not being able to parse the file if there is an error in it and you are in debug mode, but it still seems better than the current behavior.
Can John or Avinoam test immediately? jwe is planning to make the rc4 candidate today and this could go in if it is verified in time.
(file #38906)
|
Tue 08 Nov 2016 06:56:40 PM UTC, comment #8:
As to comment #6:
I find that in debug mode (= when any breakpoints have been set and the function is executing), Octave always asks to quit debugging when I press the Save button. This is with octave-4.3.0+ on Windows.
I do find that removal of breakpoints using the relevant menu bar buttons is not completely robust. But that is another story.
|
Tue 08 Nov 2016 06:06:28 PM UTC, comment #7:
There is at least a quick way to check whether Octave is in debug mode with the isdebugmode() command. From a C++ file, this could be called with
I don't know which part of the code you need to wrap with the if statement to make this work.
|
Tue 08 Nov 2016 05:59:53 PM UTC, comment #6:
I think a quick fix may be as easy as checking whether the file has any breakpoints and whether Octave is currently in debug mode before causing the exit_debug_and_clear to be called. I think that in Matlab that if you are trying to save a file while debugging that it asks if you want to stop debugging and save the file. I think this keeps Matlab from having to reparse any files until the next time they are run.
So, an alternative workaround to Bug #46632 is to ask if the user want to stop debugging (assuming Octave is in debug mode) when a save is requested. Additionally, this would prevent the need to re-parse until the next time the function is run.
|
Tue 08 Nov 2016 05:15:39 PM UTC, comment #5:
I added a dependency on bug #46632 and put a note about this bug on that report. Hopefully someone from that report or this report will have insight into the issue.
|
Tue 08 Nov 2016 04:49:02 PM UTC, comment #4:
I have hunted down what is causing this, but don't enough about the interaction between the gui and the core of Octave to know the right way to fix it.
The error is occurring in class method
at the line
It appears that trying to find the symbol associated with the file causes the file to be re-parsed. Since the parsing fails, then the file save fails.
This is called from
at the lines
It appears this was introduced by http://hg.savannah.gnu.org/hgweb/octave/rev/acdd8983d308 in response to Bug #46632 (see https://savannah.gnu.org/bugs/?func=detailitem&item_id=46632#options)
|
Tue 11 Oct 2016 08:23:03 PM UTC, comment #3:
I removed MXE from the Summary, and changed the OS to Any, since this also occurs on Linux.
|
Sat 24 Sep 2016 09:07:49 PM UTC, comment #2:
Maybe related (?)
When I save file with parse errors from the GUI editor, the parse error messages show up in the terminal (fine), but I have to press <RETURN> to get back a prompt.
When I don't do that, the terminal is dysfunctional. I can enter commands but they can't be executed.
Repeatedly saving the fixed file indeed repeats the parse errors that were already fixed, until <RETURN> is entered - at that moment it seems the file is re-parsed?
|
Sat 24 Sep 2016 12:06:20 AM UTC, comment #1:
Confirmed. It's weird. Just saving a file shouldn't cause a full parse of the function. I tried inserting 'clear -f' after making the change to the file name and saving--hoping that it would clear out the existing function from the symbol table--but it didn't work.
|
Fri 23 Sep 2016 09:06:58 PM UTC, original submission:
Example 1:
1. Creating a file names "foo.m"
2. Using the "save as" command to save this file as "foo1.m"
3. Using the editor to change the function name to "foo1"
4. Saving the file. I get a warning:
Example 2:
Creating a file names "foo1.m" with an error
fixing the error and saving the file I get
This error is marked "regression" because it did not appear in 4.0.3
|