Wrong handling of piped input in version 5.4 .3 on Windows
Finally in 5.4 and 5.5 branches. Thanks!
Missing definitions
windows console: buffered pipe input
Data out of scope in CACA_arrow
Missing definitions
Use corresponding inttype.h macro as parameter to scanf
windows console: buffered pipe input
svga: float text angle requires float modulus function
Data out of scope in CACA_arrow
(Windows) Plotting data from stdin does not work properly.
Link to [#2491]
win: reenable boxed text
win: reenable boxed text
ANSI C compatible initialisation of default object styles
Not all data displayed with terminal 'windows' and 'impulses' style
wgnuplot menu code uses standard heap functions
win: use C heap for the blocks which contain the graph ops
win: use C heap for command lists
wgnuplot menu code uses standard heap functions
win: use C heap for the blocks which contain the graph ops
win: use C heap for command lists
Thanks for the feature-request. In version 5.4.5, gnuplot is now associated with .plt files. Concerning the static link: not all the libraries required are currently available in a static version on my system, so it would require a bit of effort. We will be switching to gcc9 and the library ecosystem available via rpm in the next version, though. At that point dynamic linking would be preferred again.
File association OS/2
Thanks for the feature-request. In version 5.4.5, gnuplot is now associated with .plt files. Concerning the static link: not all the libraries required are currently available in a static version on my system, so it would require a bit of effort. We will be switching to gcc9 and the library ecosystem available via rpm in the next version, though. At that point dynamic linking would be preferred again.
Please note that the "windows" terminal internally has three variants "GDI", "GDI+", and "Direct2D". In version 5.4 releases, only the GDI+ and D2D variants are included, with the modern D2D being the default. But the problem is not within the plotting code itself. Also, we do not exceed the GDI handle limit (we only use very few). The culprit seems to be that the memory management of the internal list of drawing commands uses Local* heap family of functions which stem from the Windows 16 bit era...
Menu code uses heap allocations instead of deprecated Local/Global heap
win: use C heap for the blocks which contain the graph ops
win: use C heap for command lists
html help: allow figures that are specific to the HTML doc output
block: Unicode and PUA code ranges for sextants and octants
block: animate option
Thanks for pointing out the issue! I had initially assumed I screwed up the thread sync. Limiting pipe input to one single mechanism seems like a great idea iny any case. To be conservative, I consider (a variant of) your initial patch for 5.4 and this one for 5.5 aka master branch. I very much like your solution, but it should get more testing. We just had too many issues with IO in 5.4 for console mode. What do you think? Btw. have you verified with the qt terminal? qt_waitforinput() is an even...
Thanks, I too had spotted the additional case in MyFGetC().
Need ability to interrupt plot causing a stream of error messages
Spurious crashes when unzooming
Seems to be fixed in patchlevel releases.
font problem on qt terminal on windows
Crash with -c flag and command line arguments
The index for the call arguments gets one too large which is causing the segfault. Fixed in master.
Index overrun for call arguments
This is the corresponding change: [fb1214] 2017-06-01 Ethan A Merritt <merritt@u.washington.edu> * src/gadgets.c src/plot.c src/term.c (load_linetype): A 2017-04-10 patch re-ordered initialization to (1) error handling, (2) session state, (3) default terminal. This had the effect that a command in ~/.gnuplot that queried terminal state could segfault because the terminal had not yet been initialized. Now we reorder again to (1) error handling (2) terminal (3) session state from ~/.gnuplot. For safety...
Thanks. I still do not fully understand what exactly is the cause of the race condition though (pointers greatly appreciated). Another problem is that the fgets_ipc(), which is used here, does not expect '\r' as line terminator. I am not yet completely sure where to best test for it. Currently, I add a test to next_pipe_input(), but that should probably be at a higher level. Your patch completely serializes the two threads. Doing the fread() before waiting for the event was supposed to somewhat speed...
Check for async Ctrl-C flag when printing warning messages
not_a_number() uses C99 NAN
NAN is not guaranteed to be constant
pslatex, pstex: make sure we don't mix style of line endings
win: unbreak redirected output of printf()
windows console: unbreak fgets()
inline data input does not accept keyboard inputs on cosole mode gnuplot windows
Fixed in master. The console variant of fgets() was utterly broken. But since it is only ever called for interactive data input, it wasn't noticed for six years.
no redirected output, gnuplot 5.4.3
Resolved in master. We use the console API to write to screen and standard file IO for pipes.
win: unbreak redirected output of printf()
windows console: unbreak fgets()
No. It does not fix the problem.
Confirmed. Does the patch in bug report [#2491] fix the issue by an chance? It is not unlikely that these are related.
When piping the script, I cannot reproduce the missing point at x=0. But I get an additional error : gnuplot> 0 ^ line 6: invalid command So there definitively is a bug. I'll investigate but it will take a few days. I note that running the script gnuplot test.dem or simply loading it works fine. Please note that input on Windows is a bit convoluted due to the many different possibilities (GUI/console/different internal and external "mousable" terminals). In particular there's additional code in qt.trm...
pstricks: compatibility with plain TeX
pstricks: output compatible with pdftricks2 macro package
pstricks: disable code only required for currently disabled optimization
no redirected output, gnuplot 5.4.3
It's actually worse than just the version output. My commit [e5f274] accidentally broke redirected output using printf(). Before just reverting this, I need to verify that I doesn't break UTF-8 output to screen again which this commit attempted to fix.
Update README-Windows-ja.txt in the development branch
Check for async Ctrl-C flag when printing warning messages
The technical reasons differ for both variants: the GUI version reads Ctrl-C as a normal keystroke. Also console mode gnuplot programs have no native concept of signals. There's a handler for Ctrl-C, but it runs in a different thread and we cannot bail_to_command_line() from there. I have now put a check in int_warn() as suggested. int_error already bails to the command line, so no need there.
dumb: color codes for bright and dim colors were interchanged ...
Adjust threshold to select halftone fill pattern to middle between levels
block: fixes to terminal options and option string
block: remove debug code
block: remove the undocumented horizontal half block mode
block: background/transparent option
block: support block octants
block: disable variable line width
block: always draw point symbols using a 3x3 grid
block: draw point symbols using Unicode super- and subscript numerals
block: minimally sized arrows
block: (partial) transparency for text
block: approximate the actual aspect ratio
block: revised color optimization for full cells
On Windows, these Ctrl-C interrupts can only be handled asynchronously for both console-mode and GUI variant. Internally, this works by setting a flag ctrlc_flag. Actions are only interrupted when this flag is tested a certain ponits. This is currently the case during pause or fit commands or when checking for mouse or key events in check_for_mouse_events() for example. The behaviour could be improved by adding checks elsewhere. The drawing speed of the wgnuplot terminal is indeed rather low, possibly...
emxvga: first steps to enable input on OS/2
emxvga: EAM_BOXED_TEXT is gone
os2: link with libcerf
os2: link with Netlib amos library
utf8 encoding
Do not build broken cairo terminals on OS/2 by default
Reorder include paths to correctly include Japanese terminal help
Single quotes to fix building Japanese help for tikz
Update README-Windows-ja.txt in the development branch
Btw. I think this is a patch, not a bug.
Applied the S-JIS patch. Thanks. I don't see a downside to converting all Japanese texts to UTF-8 on Windows. We recently also converted the menu file wgnuplot-ja.mnu. I assume also on Japanese *nix systems the default is now UTF-8 ? The Windows GUI and console mode versions of gnuplot support utf8 since version 5.2. Also the version 5.4 Windows README suggests adding "set encoding utf8" to gnuplot.ini. In principle, we could make this the default (on Windows), but this would break compatibility...
Regenerate makefile.all/awc
Update git ignore patterns
Makefile target for the new latex demo (MinGW)
Sync Japanese Windows README
Sync Japanese documentation to git snapshot 23-Dec-2021
Add rule for the Japanese translation of the user manual to the MinGW Makefile
Explicitly set encoding to UTF-8
Include Japanese translation of terminal help texts again in Windows help