Activity for Bastian Märkisch
-
Bastian Märkisch modified ticket #2511
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
1 >