Tue 06 May 2014 04:41:29 PM UTC, comment #16:
I have already closed the bug report.
|
Tue 06 May 2014 04:33:53 PM UTC, comment #15:
While I have not updated for the change, I consider this closed. How do I handle that?
|
Tue 06 May 2014 04:28:00 PM UTC, comment #14:
I have pushed changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/0f9ed79fb206
which truncates the displayed width of history entries.
|
Mon 05 May 2014 06:24:17 PM UTC, comment #13:
That approach seems reasonable. It needs some kind of exception handler for large arrays pasted in the Command Window.
I don't remember what MatLab or SciLab does. I'm sure I tried to swamp them inadvertently when I used them in the past.
Normally, if the array is even more than a few dozen characters, I would put it into a .m file. I just wanted a quick answer. I was a bit surprised by the result.
|
Mon 05 May 2014 06:15:49 PM UTC, comment #12:
Thank you for the files. I can confirm the issue with the array imMat. After clearing the history the gui is reactive again. I guess that the history viewer should truncate large arrays before displaying them like the workspace viewer does.
|
Mon 05 May 2014 05:33:00 PM UTC, comment #11:
I have tried cutting and pasting the array cropped to 1/2 and 1/4 the original size.
The 1/2 size bogged it down, but the 1/4 did not.
I have attached the .m file containing the array.
I have also attached the original YAML file that I extracted the array from.
(file #31313, file #31314)
|
Mon 05 May 2014 05:02:41 PM UTC, comment #10:
Pasting the array in either format causes it to bog down. It is not a memory issue because instantiating the array from running a .m that declares it does not bog it down.
I haven't taken the time to see if using a matrix half the size or so did the same thing. I will try to get that done this PM.
|
Sat 03 May 2014 10:16:28 PM UTC, comment #9:
My comment just helped to localize the problem, it isn't fixed yet. We still need detailed information on the data to fix the problem with the history viewer.
Does comment #4 mean that the problem does not occur when you paste the data without newlines in it?
|
Fri 02 May 2014 05:18:47 PM UTC, comment #8:
Torsten: Thanks closing the history viewer did it. I cleared history with the menu and the problem is cleared. I never did find the octave_hist file. Although, I probably could have got it with rm ~/.octave_hist, I wanted to see how big it was.
Mike Miller:
Torsten's comments fixed it. Do you still want to play with the data?
Ralph
|
Fri 02 May 2014 04:36:19 AM UTC, comment #7:
The fact that a restart does not help may indicate a problem with the history viewer of the gui. When you reproduce the issue could you please try to
- close the history viewer
- delete the history file (~/.octave_hist)
|
Thu 01 May 2014 11:33:56 PM UTC, comment #6:
It might be useful to diagnose this a bit further. So you experience a severe slowdown in the GUI after pasting a large array into the command window, correct?
Note that when typing or pasting into Octave's interpreter, newlines are interpreted as starting a new row of a matrix. So the dimensions of the resulting array in Octave were probably not what you expected. Could you try what you were originally doing and report back what the size of the variable is? Also what dimensions, type, and memory size does the 'whos' command report? In other words
I wonder whether it's the size of the data, or something about the way the data is being interpreted when pasting into Octave, or the size of the scrollback window in the GUI, or the copy/paste buffer itself that is causing Octave to slow down.
Can you attach a file to this bug report (compressed if necessary) that contains the text that I could copy and paste into Octave to try to reproduce this?
|
Thu 01 May 2014 05:08:22 PM UTC, comment #5:
For what it is worth, the file I extracted it from is 60kb. That could put it close to 64kb for a 16 bit number
|
Thu 01 May 2014 05:04:01 PM UTC, comment #4:
The array was 1x16485. I had cut and pasted it from a file with the text between brackets []. The numbers were separated by commas and newline '\n'. I wasn't aware of the latter and it may have been a factor.
I have the array in a .m file with the \n removed and it works fine in the command line on the terminal.
The Synaptic package manager has an option 'Mark for complete removal.' I marked it and removed the program. Then, I reinstalled it (also with Synaptic).
|
Thu 01 May 2014 04:52:34 PM UTC, comment #3:
What was the size of the array?
"But, that wouldn't explain why the re-install didn't clear it up. Unless the complete reinstall isn't complete."
Do you mean a (complete/incomplete?) reinstall of Octave does not solve the problem?
|
Thu 01 May 2014 04:09:36 PM UTC, comment #2:
It occurs every time.
I tried the usual stuff closing and reopening, etc.
I installed using the Debian in Synaptics for Ubuntu 14.04. I tried a complete removal and reinstalled.
The problem was still there.
The last thing I did before the problem occurred was try pasting a long array into an equation on the command window. So, it is possible that there was a buffer overflow of some kind that may not be being cleared. But, that wouldn't explain why the re-install didn't clear it up. Unless the complete reinstall isn't complete.
|
Thu 01 May 2014 03:53:44 PM UTC, comment #1:
Thanks for the report.
When does this issue occur, every time you are using Octave? Is it reproducable? If yes, what actions have to be performed?
|
Thu 01 May 2014 02:32:01 PM UTC, original submission:
Responses from command window went from instantaneous to taking five to seven seconds. Sometimes the screen dims to indicate saturated resources. Typing the line '4+3' and hitting return takes 24% to 34% of the resources.
If I write an equation in the editor and hit run and then try to open the command window, it takes about 3 seconds to open. Execution of the following took 7 seconds:
H=16;
V=9;
Diag=52;
height=Diag*V/sqrt(H^2+V^2);
In the Linux terminal, it is still instantaneous.
|