Activity for gnuplot
-
Bastian Märkisch modified ticket #2821
Keyboard & mouse commands not working with Qt6 on Windows
-
.Turns out that the issue was the zero argument to QtLocalSocket::waitForReadyRead(). Changing this to a small number of milliseconds (>0) fixes the issue. Commit in master branch along with changes to config/mingw/Makefile to enable compilation with Qt6.
-
mingw: optional compilation with Qt6
-
mingw: alternative help compiler
-
mingw: optionally use the MSYS2/CLANG64 environment
-
qt: fix for Qt6 on Windows
-
The failing communication path is gnuplot receiving events from gnuplot_qt. There's never a call to qt_processTermEvent(), whereas on the sending side QtGnuplotEventHandler::postTermEvent is called and writes to the socket. Adding a flush() after write() does not help. Interestingly, receiving fontprops in qt_sendFont() works. But the code in qt_waitforinput() which is supposed to read events from the gnuplot console, or the wgnuplot text window, and the windows or wxt terminals, and the qt socket...
-
The failing communication path gnuplot receiving events from gnuplot_qt. There's never a call to qt_processTermEvent(), whereas QtGnuplotEventHandler::postTermEvent is called and writes to the socket. Adding a flush() after write() does not help. Interestingly, receiving fontprops in qt_sendFont() works. But the code in qt_waitforinput() which is supposed to read events from the gnuplot console, or the wgnuplot text window, and the windows or wxt terminals, and the qt socket fails to receive any...
-
Ethan Merritt posted a comment on ticket #2821
Both gnuplot and gnuplot_qt send and receive to each other, so there are four communication paths. I am trying to understand or help diagnose which of them is failing. If plotting works, I take it that means commands are successfully sent from gnuplot to gnuplot_qt. When you say keyboard commands do not work, what does that mean exactly? Commands after the initial "plot" command are ignored? Keyboard is locked up? New commands work but hot-keys (bind commands) do not? Does the plot window (gnuplot_qt)...
-
Keyboard & mouse commands not working with Qt6 on Windows
-
Turns out that compilation with Qt6 is straight forward with some minor tweaks to the Makefile only. But indeed the communciation channel (using Windows specific code) no longer works. Plotting works fine, but keyboard/mouse commands are not sent/received. That was some really complicated code to get right in the first place. I make no promises as to when I will get around looking at this.
-
I agree that switching official Windows builds to Qt6 is eventually a good thing. It still runs fine with Qt5, though, and there's a bit of Windows-specific trickery to enable the wgnuplot GUI and windows, qt, and wxt terminals to work at the same time. That may or may not work with Qt6 atm. At the minimum, the Makefiles in config/msvc and confing/mingw would need an update. It is easiest to build gnuplot with MSYS2/MINGW64 on Windows as MSVC library dependencies can be a pain. (Also, I would recommend...
-
Enrique posted a comment on discussion Open Discussion
I've noticed that since v5.4.9 Qt6 has been supported, but the recommended usage for Windows users is to get the zip or 7z folder to use the binaries, which still uses Qt5 dll's. I tried the other suggested method for building on Windows (running nmake in the config/msvc directory), but kept running into roadblocks only to discover that it looks like Windows Qt6 support hasn't been included. This is potentially a bad thing for projects that use Windows and Linux, because if Linux user's build with...
-
Ethan A Merritt committed [36235f] on Git Repository
"splot with circles" fillcolor lost if hidden3d is active
-
Hiroki Motoyoshi posted a comment on ticket #2820
Thank you for the explanation. After applying the patch, I was able to set the border color for circles. By combining it with "set style fill", the interior of the circles can also be filled in the specified color. Looking at hidden3d.c, it seems that only the "circles" style is treated specially to allow set style fill to apply a fill style. I'm fully satisfied with this fix.
-
Please try this patch: diff --git a/src/plot3d.c b/src/plot3d.c index d0a023575..880037bc6 100644 --- a/src/plot3d.c +++ b/src/plot3d.c @@ -1169,7 +1169,11 @@ get_3ddata(struct surface_points *this_plot) color = z; else color = v[varcol]; - color_from_column(TRUE); + if (this_plot->lp_properties.pm3d_color.type == TC_RGB + && this_plot->lp_properties.pm3d_color.value >= 0.0) + color_from_column(FALSE); + else + color_from_column(TRUE); } else if (this_plot->plot_style == VECTOR) { /* We already enforced...
-
Ethan A Merritt committed [7d8b6f] on Git Repository
Expand unicode escape sequences in string functions strstrt and strlen
-
I am not sure where fill color fits into this. In the first two examples you gave, my interpretation was the reason the circles are green without hidden3d and not green with hidden3d is not because of the fillcolor. I think the fillcolor is still green. But in hidden3d mode the interior of the circle is not drawn at all, so the fill color is never looked at. At least that's how I interpret the difference. You can tell it's not white fill by setting a background color for the plot; the background...
-
To provide some background, what I wanted to achieve with this feature was to hide the rendering of the far side of a sphere, as in the following script. At the same time, I wanted to indicate the extent of the sphere using a color instead of white. set angles degrees set parametric set mapping spherical set isotropic set xyplane relative 0 set title "3D version using spherical coordinate system" set dummy u, v set urange [ -90.0000 : 90.0000 ] noreverse set vrange [ 0.00000 : 360.000 ] noreverse...
-
Thank you for reply. I wasn't interested in the behavior when adding nohidden3d; the real issue was that the fillcolor setting wasn’t working as expected. So I found the following workaround: set hidden3d offset 0 front set style fill solid 1 splot $data using 1:2:3:4:(rgbcolor("green")) with circles, \ -2 with lines lc "blue" This produced the expected result. I would be satisfied if this behavior could be achieved using the inline option with circles fc "green" fs solid 1. That said, like you,...
-
I am kind of surprised the circles are drawn at all in hidden3d mode. It was only designed for "splot with lines". Here's what the documentation says: hidden3d also affects 3D plotting styles points, labels, vectors, and impulses even if no surface is present in the graph. Unobscured portions of each vector are drawn as line segments (no arrowheads). Individual plots within the graph may be explicitly excluded from this processing by appending the extra option nohidden3d to the with specifier. I...
-
fillcolor setting ignored in "splot with circles" when using "set hidden3d"
-
Ethan A Merritt committed [96ed11] on Git Repository
revisit escape sequences (documentation)
-
Ethan A Merritt committed [8a7764] on Git Repository
revisit escape sequences (UTF-8)
-
Ethan A Merritt committed [616c2c] on Git Repository
revisit escape sequences (octal)
-
Ethan A Merritt committed [58336b] on Git Repository
post: use strftime() rather than the obsolete (POSIX 2008) asctime()
-
unreadable label on y-axis in png output
-
Duplicate report of fallout from a long-standing upstream problem. See in particular https://sourceforge.net/p/gnuplot/bugs/2194/ Long story short: the harfbuzz and pango font-handling libraries underwent major changes, and various other libraries (cairo in particular) did not stay in sync with them. Some versions work with each other and others don't. It also depends on what fonts are requested. Gnuplot (and probably other programs on your machine) are victims of this. You may be able to fix it...
-
Anonymous created ticket #2819
unreadable label on y-axis in png output
-
'set mouse mouseformat' directly passing user defined format to 'snprintf()'
-
OK. It's commit a2ec5006 in the development branch
-
Ethan A Merritt committed [a2ec50] on Git Repository
modify "set mouse mouseformat" to use g_sprintf
-
Ethan A Merritt committed [1fb1bc] on Git Repository
Add code in the sharpen filter to ensure the function is sampled at x=0
-
Ethan A Merritt committed [6567e6] on Git Repository
Add code in the sharpen filter to handle step functions
-
Ethan A Merritt committed [57f4a2] on Git Repository
docs: (lualatex, xelatex) remove requirement for package unicode-math
-
Ethan A Merritt committed [eba202] on Git Repository
prefer lualatex to pdflatex during configuration
-
Ethan A Merritt committed [d4c5ad] on Git Repository
Add pre-defined variable Inf (INFINITY)
-
Ethan A Merritt committed [ae3faf] on Git Repository
docs: reorganize and correct errors in description of format specifiers
-
Ugh. I was completely wrong. gprintf() does not handle time formats. Worse, with that wrong thought in my head I revised the documentation to say (or at least imply) that it does handle time formats. I will go undo the damage I did to the documentation before getting back to this.
-
Anonymous created ticket #2818
gnuplot-6.0.x - qt terminal error "IFFChunk::innerFromDevice: unkwnown chunk"
-
If the implementation with gprintf format support turns out to be too complicated, perhaps it would be better to recommend using 'set mouse mouseformat function ...' in scenarios where gprintf is desired. set mouse mouseformat function sprintf("%s,%s",gprintf("%h",x),gprintf("%h",y))
-
Yes, gprintf() formats only a single value. So it would have to be called twice, once for x and once for y. Several approaches come to mind. It would be possible to look for two places in the format string where gprintf() should be called. Upside: This would preserve backward compatibility. Downside: I'm not sure how messy the code would be. The existing f_sprintf() code does this and you can see that's a lot of code. This case would be simpler, however, since we know there are exactly two values...
-
Thank you for your considerations. On the other hand, I do not buy the argument that deliberately malformed format strings are a "vulnerability" for an application like gnuplot. I'm not entirely sure whether this constitutes a true vulnerability in gnuplot. However, I can point out that it is an incorrect usage of the 'snprintf' function. Because, the behavior is undefined if the number of format specifiers in the format string exceeds the number of arguments provided, and depends on the implementation...
-
I have been trying to either confirm or disprove my concern that calling f_sprintf() from inside mouse handling might corrupt the evaluation stack. So far I have not been able to trigger any visible failure while testing. Furthermore an explicit test for stack depth added to the new mouse code never detects being called while the stack is active. So at least tentatively I conclude that the patch is safe, or at least unlikely to trigger an error in practice. As to the patch itself - If the program...
-
Ethan A Merritt committed [430f47] on Git Repository
docs: revise some "EXPERIMENTAL" warnings
-
Ethan A Merritt committed [3fe73b] on Git Repository
docs: Modify for better use with lualatex
-
Ethan A Merritt committed [4f4f19] on Git Repository
docs: documentation for new gprintf formats %C and %Ci
-
Ethan A Merritt committed [b4c13c] on Git Repository
set/show/save imaginary_i
-
Ethan A Merritt committed [f22da4] on Git Repository
New gprintf format specifiers %C and %Ci
-
Ethan A Merritt committed [bb2c17] on Git Repository
update INSTALL file
-
Ethan A Merritt committed [2e3733] on Git Repository
Expand unicode escape sequnces during substring evaluation
-
Ethan A Merritt committed [3d2a1b] on Git Repository
expand Unicode escape sequences \U+xxxx in "noenhanced" strings
-
Ethan A Merritt committed [ccb9e0] on Git Repository
allow "alternate form" modifier # for gprintf formats %h and %H
-
Here is the definitive word on this message from the fontconfig authors: https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/472 The message is harmless, and is apparently intended to prod other projects that use libfontconfig to pay attention to an API change that will happen in the future. Bad idea IMO, since the message mostly annoys or worries end users rather than developers.
-
[puzzled look] You filed this bug on a gnuplot issue-tracker. and provided a version number for gnuplot, so I assumed you were reporting a gnuplot bug. Since this apparently is not the case I will close the issue here. Just for your future reference "terminal" means something special to gnuplot; it does not mean the window on the screen you are typing into. I doubt very much that your error message depends on that. Nevertheless, my earlier diagnosis still holds. The message is probably triggered...
-
swanmoon posted a comment on ticket #2817
Please clarify. Is the idea to add a gnuplot interface to Typst, or is it to add named colors to gnuplot?z It is to add CSS/SVG named colors to gnuplot. We will follow up as advised.
-
Just to be 100% clear, you are now seeing this error message while inside a gnuplot session? I see the message when running scripts from the command line as well as interactively with the pdfcairo and the pngcairo terminals but not the svg terminal. My apologies. So if you don't see the error when using the wxt terminal that might be useful information. I changed a script to use the wxt terminal and the error message did not show up.
-
I worry about having mouse-tracking involve the evaluation stack. Since mouse tracking is asynchronous with the general program flow, I think there would be a possibility of stack corruption if both the main thread and the mouse-tracking thread were pushing and popping operations on the stack. I realize that if this is really a problem, it already exists in principle when you attach commands to a hot key using the bind command. But responding to a bound hotkey is a rare, single-shot, operation compared...
-
P.S. My son contributed a package to make available CSS-SVG named colors to Typst: and would like to do the same for gnuplot. Where should he start and how? Please clarify. Is the idea to add a gnuplot interface to Typst, or is it to add named colors to gnuplot? I don't know what Typst is, so I can't help much there. Perhaps it would be similar to the gnuplot interface packages for Python or Julia? See this page of links As to providing colors... There is a table of color names in the source file...
-
Just to be 100% clear, you are now seeing this error message while inside a gnuplot session? (1) If you seeing it after gnuplot command "set terminal pdfcairo", that would be consistent with the warning being triggered by the pango/cairo libraries. In that case I would also expect that it might be triggered from gnuplot command "set terminal wxt", since the wxt terminal also uses pango/cairo. However in the case of wxt there is an intervening software layer that could conceivably do something that...
-
Windows terminal: gnuplot aborts at some windows size (machine dependent)
-
Bug still present. Interestingly, wgnuplot does not crash if the graph window is already open.
-
gnuplut v6.0.3 for OS/2 doesn't support OS/2
-
I am getting the same error after a large update on Manjaro yesterday. No such warning prior to the update. Terminals are pdfcairo and svg. I am on gnuplot Version 6.0 patchlevel 3. Should I simply ignore the warning and wait for this bug to be flushed out after another update to whatever package is causing it? Thanks. P.S. My son contributed a package to make available CSS-SVG named colors to Typst: https://typst.app/universe/package/niram-css/ and would like to do the same for gnuplot. Where should...
-
I am getting the same error after a large update on Manjaro yesterday. No such warning prior to the update. I am on gnuplot Version 6.0 patchlevel 3. Should I simply ignore the warning and wait for this bug to be flushed out after another update to whatever package is causing it? Thanks. P.S. My son contributed a package to make available CSS-SVG named colors to Typst: https://typst.app/universe/package/niram-css/ and would like to do the same for gnuplot. Where should he start and how?
-
JP CILLIERS posted a comment on ticket #2817
Sorry about that, I did not see the 'Home/ Browse/ gnuplot/ Bugs', the very small link(s) at the top of the page. I was focused on the actual error message thinking I'd found something that I could work with. My apologies for wasting your time it was unintentional. Best regards, Piers.
-
Fontconfig warning: using without calling FcInit()
-
[puzzled look] You filed this bug on a gnuplot issue-tracker. and proved a version number for gnuplot, so I assumed you were reporting a gnuplot bug. Since this apparently is not the case I will close the issue here. Just for your future reference "terminal" means something special to gnuplot; it does not mean the window on the screen you are typing into. I doubt very much that your error message depends on that. Nevertheless, my earlier diagnosis still holds. The message is probably triggered by...
-
TBH I never knew that I even had 'gnuplot' installed or that it existed. 😂😂 It looks pretty cool nonetheless. When I'm looking for a quick edit for say my ~/.zshrc file and don't feel like using Nvim or nano I use 'sudo leafpad ~/.zshrc' from my Tilix terminal. Invoking 'leafpad' without sudo from the terminal also produces the same error. I've got a suspicion that 'Pango' has something to do with this. But how to implement any sort of action or fix is beyond my pay-grade. PS. This error is produced...
-
TBH I never knew that I even had 'gnuplot' installed or that it existed. 😂😂 It looks pretty cool nonetheless. When I'm looking for a quick edit for say my ~/.zshrc file and don't feel like using Nvim or nano I use 'sudo leafpad ~/.zshrc' from my Tilix terminal. Invoking 'leafpad' without sudo from the terminal also produces the same error. I've got a suspicion that 'Pango' has something to do with this. But how to implement any sort of action or fix is beyond my pay-grade.
-
"when I open leafpad from my terminal" Leafpad rather than gnuplot? That might be a clue that this warning comes from gtk. When you see this warning in gnuplot, what terminal is active?
-
Hi Ethan I've given the FC_NO_MT a try and no joy. I still get this when I open leafpad from my terminal: Fontconfig warning: using without calling FcInit() Any other ideas perhaps? I'm aware that it's not really that big of a deal but it DOES annoy me. :-) Thanks and btw I'm using a fully up-to-date Arch install.
-
Thanks for the report, but I think this message must be coming from a library rather than from gnuplot. Although gnuplot does not use or call into libfontconfig directly, several of the output modes (a.k.a. "terminals") depend on libraries that use libfontconfig. So I suspect that this is indicating one or more of the following libraries might need a matching upgrade. cairo-fc cairo gdk-3.0 gdlib gtk4 pangocairo pangoft2 pango If the message is annoying, you might be able to suppress it by setting...
-
MBoehme created ticket #2817
Fontconfig warning: using without calling FcInit()
-
'set mouse mouseformat' directly passing user defined format to 'snprintf()'
-
Ethan A Merritt committed [3cf2a0] on Git Repository
show/save "set micro" was not saving any user-specified string
-
Ethan A Merritt committed [34fdf3] on Git Repository
clean up configure script search for Amos library functions
-
Ethan A Merritt committed [dda9e5] on Git Repository
Support use of either ZEXINT or CEXINT (Amos library expint routines)
-
Thanks. Let me know if you find any other places.
-
Ethan A Merritt committed [053955] on Git Repository
colorspec (fixup) vplot fillcolor uses rgbcolor
-
Thank you for the series of commits related to the handling of colorspec. The commit 7879f3e32 does not include the fix for the following lines. vplot.c:325: quad[0].c = plot->lp_properties.pm3d_color.lt; vplot.c:362: quad[0].c = plot->lp_properties.pm3d_color.lt; A patch for them should be as follows: diff --git a/src/vplot.c b/src/vplot.c index e15ecc1aa..253c38969 100644 --- a/src/vplot.c +++ b/src/vplot.c @@ -322,7 +322,7 @@ tessellate_one_cube( struct surface_points *plot, int ix, int iy, int...
-
Incorrect font size in the svg terminal with enhanced text mode
-
Ethan A Merritt committed [a291a0] on Git Repository
svg: font size changes within a text fragment could be lost
-
PuQ created ticket #2816
Incorrect font size in the svg terminal with enhanced text mode
-
gnuplot released /gnuplot/6.0.3/gp603-os2-pentium4-libcn-test.zip
-
Thank you for testing the new package and providing feedback, as well as your appreciation of my attempt to provide executables on this dated platform. In an attempt to provide technical clarification, I will not get involved in the discussion if a product not being shipped by IBM may be called "OS/2", though. gnuplot.exe is the main executable. It is compiled using gcc 9.2 by Bitwiseworks. The compiler and the libraries were installed using yum/rpm using packages from the Netlabs and ArcaNoe repositories...
-
A.D. Fundum created ticket #2815
gnuplut v6.0.3 for OS/2 doesn't support OS/2
-
-
Anders Andersson posted a comment on ticket #303
Whoa! A project without control of its domain sounds like a very dangerous situation, I hope it can be remedied but the thread is over a year old so maybe not. I am indeed using IPv6 so that may be part of the problem. If the DNS gives out different answers for IPv4 and IPv6 users, I would expect this behavior.
-
All I know for sure is that access via the same URL works for other people. A similar or possibly the same probable was reported last year. To the extent that I understand the resolution of that report (which honestly I mostly do not) it had something to do with whether the user's access proceeded via IPv4 or IPv6. Here is a link to part of that discussion: https://sourceforge.net/p/gnuplot/mailman/message/58739536/
-
I also noticed the inline pictures are broken for me for the same reason. The URL to the images in the document http://www.gnuplot.info/docs_6.0/loc282.html are hardcoded as (for example) "http://gnuplot.info/demo_6.0/windrose.1.png" which fails to resolve.
-
Fixed now. A possible work-around for existing gnuplot versions is to put the iteration variable in parentheses. set for [i=1:3] dashtype (i) (1,2)
-
Ethan A Merritt committed [14696b] on Git Repository
resolve ambiguous syntax in "set dashtype"
-
-
Windows installer glitch
-
Weird. Here, there are no duplicates, but the menu items are not updated properly having installed 6.0.3 over 6.0.2.
-
Feature Request: Non-admin instalation on Windows
-
Installation for non-admins might not be documented, but should be possible using the "/CURRENTUSER" switch on the command line since 2020, see [2dee2c]. If it is not working for you, please file a bug report.
-
Ethan A Merritt committed [d53bde] on Git Repository
colorspec - documentation
-
Ethan A Merritt committed [d0dd20] on Git Repository
colorspec (7/7) Initialize fields in colorspec by name
