matplotplusplus icon indicating copy to clipboard operation
matplotplusplus copied to clipboard

Not compatible with gnuplot 5.4.1 in Win10 ?

Open ElonH opened this issue 5 years ago • 9 comments

Bug category

  • [ ] bug - compilation error
  • [ ] bug - compilation warning
  • [x] bug - runtime error
  • [ ] bug - runtime warning
  • [ ] bug - logic error

Describe the bug

I installed Gnuplot 5.4.1 and run any sample in this project, the Gnuplot window came up (with the correct result) BUT frozen (no response, I can't control the window).

And I try to down ground Gnuplot to 5.2.8, everything is fine.

Is it not compatible with Gnuplot 5.4.1?

Platform

  • [ ] cross-platform issue - linux
  • [x] cross-platform issue - windows
  • [ ] cross-platform issue - macos

ElonH avatar Feb 14 '21 09:02 ElonH

It should be compatible with gnuplot 5.4.1, but gnuplot is giving us a lot of inconsistencies across platforms and versions. So this kind of thing is expected. We are now working on our own backend to make this behavior more consistent. The gnuplot will then be deprecated.

alandefreitas avatar Feb 24 '21 22:02 alandefreitas

I can reproduce this problem exactly as @ElonH described.

As a veteran Windows programmer, the frozen window looked distinctly like the symptom of an application that was not running a message pump. That made sense to me, since I was trying the basic samples from the documentation (https://alandefreitas.github.io/matplotplusplus/plot-types/line-plots/line-plot/) in a console application, and the console application was terminating as soon as it had displayed the plot. However, even after moving to a proper Win32 application with a full message pump, this did not solve the problem. Uninstalling Gnuplot 5.4.1 and installing Gnuplot 5.2.8 got the demo working again.

After doing some additional research, it turns out that problem with Gnuplot 5.4.1 may be fixed by adding the "pause" command (page 100 in the manual) to the end of the commands/script sent to Gnuplot. This will keep the entire plot window interactive, which should stop it from freezing. However, this likely has other side effects.

I'm evaluating Matplotplusplus for integration with a Windows application under development. The application has extremely simple plotting requirements (it really just needs a line plot with basic axes, a legend, and, preferably, interactive zoom functionality). Seeing these serious issues when just trying to get a simple demo up and a running makes me very concerned about integrating this into an app with reliability requirements, especially one that will be delivered to customers with unpredictable machine configurations (e.g., how do I keep them from upgrading Gnuplot?).

@alandefreitas: What is the status of the development on the new backend? How will the new backend fix these problems? Are you referring to the OpenGL backend? Are there instructions anywhere for how I can test a prototype/development version of this backend?

codygray avatar May 30 '21 06:05 codygray

Hi @codygray,

Thanks for your feedback. You're correct. It seems like gnuplot doesn't care too much about compatibility even in major versions, especially regarding what the plots look like. I'll read about this "pause" command and try to come up with something. Let me know if you have any ideas because I haven't been able to replicate the problem yet.

I agree with you. I wouldn't recommend integrating matplot++ for something you are going to deliver to customers. Even if this gnuplot issue is fixed or you used matplot++ internal functions to ensure the user is using a "good" version of GnuPlot, it's not a good idea to embed matplot++ in a product like that because creating plots with your own GUI library would give much more flexibility.

Matplot++ is much more useful for the plots you need while you are developing your libraries, like benchmarks and experiments where you might need to interpret somewhat complex relationships in the data with little effort. This is especially useful in scientific computing, but the plots made for your GUI library are almost always going to beat that in the final product. It's a trade-off. In a way, I'm kind of flattered that you considered that because I wouldn't consider matplot++ or matplotlib-cpp for this kind of thing.

Regarding the other backend, I started an OpenGL backend as a separate project. It was actually much easier to just feed data points to OpenGL than to endlessly reverse-engineer GnuPlot to get consistent results. The reason this backend is taking longer than expected (besides my day job XD) is that I realized I needed something more general (and complex) to solve the problem permanently. Many platforms don't work well with OpenGL nowadays. So I've been abstracting this backend to make it work on webassembly, qt, vulkan, metal, directx, xeus-cling, ...

alandefreitas avatar May 31 '21 01:05 alandefreitas

I am also stuck with this gnuplot bug https://sourceforge.net/p/gnuplot/bugs/2412/. It is expected that it will be fixed in gnuplot 5.5. To verify it, I downloaded and built the latest gnuplot 5.5 branch and the issue disappeared.

eagle-dai avatar Sep 07 '21 02:09 eagle-dai

Just force using 'gnuplot.exe --persist' when open the pipe.

KnIfER avatar Sep 07 '21 15:09 KnIfER

I was experiencing the same issue of the plot window freezing when trying to run the first example (Line Plot) from the matplot++ documentation. Downloading the latest source (~5.5) for gnuplot, building the application, and updating my PATH variable fixed the issue. The plot window can now be interacted with and windows doesn't complain about it not responding.

The freezing isn't a matplot++ issue, but for new users looking to explore the tool it might be an onboarding issue.

TorrentialFire avatar Sep 09 '21 01:09 TorrentialFire

Maybe we can add a note in Readme

matplot++ is not compatible with gnuplot - 5.4.x, plz down to gnup 5.2.x or up to 5.5.x

ElonH avatar Sep 12 '21 13:09 ElonH

Maybe we can add a note in Readme

Is the problem happening for all gnuplot terminals?

We already avoid the default qt terminal on windows because of some similar problems. We could check the gnuplot version with a function that already exists in the backend and use another terminal when it's windows and the version is in the 5.2-5.4 range.

The problem with not being compatible with the 5.2-5.4 range at all is that 1) this does not seem to be a problem in POSIX systems, 2) some features, like legends, require gnuplot ^5.2, 3) the current stable version of gnuplot is 5.4, and 4) version gnuplot 5.5 is probably going to take a while to be the current stable version. So removing the 5.2-5.4 range would be equivalent to removing support for almost all versions of gnuplot.

alandefreitas avatar Sep 12 '21 15:09 alandefreitas

gnuplot 5.4.3 win64 is fully working for me. I had the same freezing issues as described above for 5.4.2

aliaksei135 avatar Jan 29 '22 13:01 aliaksei135