Fri 26 May 2017 04:57:33 AM UTC, comment #16:
I don't see such a thing. The file that I tried appears to come from Mint/Ubuntu libgl1-mesa-glx-lts-vivid package which is titled
free implementation of the OpenGL API -- GLX runtime
In fact, there are a half dozen packages with similar names (e.g., sans "-lts-vivid". I don't think I want to experiment with installing new packages, though, because the "uninstall" list looks rather long and has a lot of important graphics libraries including
nvidia-340
xorg
xorg-server
I don't want to get that experimental because I'm busy with some other projects. Maybe in a month or so I'll look at this again--after a Mint upgrade, in which case maybe it fixes itself with newer versions of everything.
|
Fri 26 May 2017 04:30:42 AM UTC, comment #15:
libGL.so is wrong.
Do you have just libGLX.so?
Dmitri.
--
|
Fri 26 May 2017 03:51:51 AM UTC, comment #14:
I couldn't find any library file on my system with "mesa" name, so picked this
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0
and that produces
at which point all of the GUI is frozen. swrast is one of the OpenGL drivers if I recall correctly (on its way out).
I configured osmesa out of the build. (Of course, that doesn't mean it isn't built into the program, just that it is apparently not used for drawing.)
|
Fri 26 May 2017 02:59:41 AM UTC, comment #13:
Have you tried
(or whatefver the name of your GL library)
?
Dmitri.
--
|
Thu 25 May 2017 10:49:17 PM UTC, comment #12:
There doesn't seem to be much beyond cosmetic changes to FLTK in the past six months,
http://hg.savannah.gnu.org/hgweb/octave/log/8edbc923a7dc/libinterp/dldfcn/__init_fltk__.cc
except starting here:
http://hg.savannah.gnu.org/hgweb/octave/rev/0842b119dc1b
Out of curiosity I undid the above patch, and it had no effect. Not worth investigating further unless someone else encounters the problem.
|
Thu 25 May 2017 10:30:19 PM UTC, comment #11:
OK, I think I can summarize this better now, given that I have commented
% graphics_toolkit('gnuplot');
out of my .octaverc file.
So, with that, launching and plot uses 'qt' graphics toolkit. If the plot is successful, the command-line window output does not freeze. If the Qt plot is unsuccessful (i.e., a grey window with a white rectange in the upper-left corner) the command-line window output does freeze.
The switch to graphics_toolkit('fltk') consistently freezes the output window event though the plot looks fine. I can still run commands, and in fact I can still run plot commands and get an updated plot, even though characters no longer appear in the command window.
So, the bug here seems to be that FLTK is not return the output resource to the Command Window, similar to what is probably happening when Qt plot freezes.
|
Thu 25 May 2017 10:25:48 PM UTC, comment #10:
Closing, as this seems to be a specific HW/SW interaction on Dan's computer.
|
Thu 25 May 2017 10:06:04 PM UTC, comment #9:
You caught that ahead of me, Dmitri. It is 'qt' that is the default. I didn't think of what the -f option means. So 'qt' works, but sometimes the Qt plot hangs--that's the plot itself that is freezing, not the command line. The 'Qt' plot randomly freezing for me is a known bug.
|
Thu 25 May 2017 09:53:45 PM UTC, comment #8:
I tried to build with those options and I do not see this problem.
It is strange that when you do ./run-octave -f the default graphics toolkit is gnuplot. It should be qt.
Dmitri.
--
|
Thu 25 May 2017 09:52:07 PM UTC, comment #7:
I rebuilt without any options and got the same behavior as described previously.
I assumed 'qt' g.t. would be the same as 'fltk', but interestingly it isn't quite the same.
hangs but notice the extra >>, which doesn't appear with the 'fltk' toolkit when it hangs. But more surprising is that the -f option does in fact work:
If I go into my .octaverc file and comment out all commands unrelated to path and packages, g.t. 'qt' will work. But 'qt' figure once in a while ends up shredded.
Oh! So that wasn't 'gnuplot' toolkit failing. The -f option doesn't load .octaverc, so it is actually 'qt' failing in that instance.
Well, I'd say close this report. I think this is just the usual problems I've had for quite a while with OpenGL and nVidia hardware.
|
Thu 25 May 2017 09:00:29 PM UTC, comment #6:
I've never tried '--no-recursion'. Given that this is something to do with graphics the '--without-osmesa' seems more likely.
Does the default qt toolkit have the same problem or is it only fltk?
|
Thu 25 May 2017 06:13:36 PM UTC, comment #5:
I wasn't quite accurate on that, as I did use some configure options and build outside the source tree. So it was
Maybe the --no-recursion option is the issue. I've been using that option for quite a while now.
|
Thu 25 May 2017 06:06:47 PM UTC, comment #4:
I tried
but there is no change.
hangs the output window (though input is still accepted). The default graphics toolkit (gnuplot) doesn't lead to output window hang.
In addition
freezes the output window (with default graphics toolkit gnuplot) and sometimes messes up the gnuplot plot as well. But with an explicit graphics_toolkit call, i.e.,
the output window does not hang.
|
Wed 24 May 2017 10:33:25 PM UTC, comment #3:
The -f option makes things worse. gnuplot toolkit freezes as well doing a simple plot. I'll do a maintainer clean and rebuild this evening.
|
Wed 24 May 2017 08:58:10 PM UTC, comment #2:
As I reported on bug #48667, this works for me. This might be something with your particular set up. Maybe try running with the '-f' option so you don't load any packages or user settings which might be the issue.
|
Wed 24 May 2017 02:45:18 AM UTC, comment #1:
I meant for one of those to be:
|
Wed 24 May 2017 02:43:48 AM UTC, original submission:
Any type of plotting freezes the command line output in the GUI, even though keystrokes are accepted and processed after the window freezes:
Now type
Relaunch GUI (I'm using "run-octave" after a build):
Same thing. Originally I thought this was a color map issue, but I no longer think that:
https://savannah.gnu.org/bugs/?48667#comment16
|