Activity for najevi
-
najevi posted a comment on merge request #29
I have just completed the last of series of edits that made uniform the description of each example above the example rather than sporadically below (or within script comments). I do not plan to take on any more gnuplot.doc edits before 4 Feb 2024. However, I am available between now and 4 Dec 2024 to respond to clarifying questions about the edits I have made so far. I am sitting on entirely rewritten versions of filledcurves and hidden3d sections because I feel that I need to experiment with the...
-
Merge branch 'master' of https://git.code.sf.net/u/najevi/gnuplot
-
Continuation of moving descriptive text for examples to appear before the
-
My proposed allowed deviations from Jens Emerich's rules for
-
Continuation of moving descriptive text for examples to appear before the
-
Continuation of moving descriptive text for examples to appear before the
-
Continuation of moving descriptive text for examples to appear before the
-
Touch every example that placed description after the example.
-
Made consistent the use of ellipsis. Mostly affected Syntax: definitions but
-
Potentially controversial language
-
Removed (my inserted) references to "string macro expansion" and
-
3 Substitution of string variables as macros
-
2 splot -- Syntax: remove '+' and '++' from data-source group
-
I am nowhere near ready to "look under the hood" at code for gnuplot but, ... never say never ... maybe someday! It would be foolhardy for anybody to pick up the lexical scanner task you mentioned without first having a comprehensive gnuplot syntax chart to work from. An "Appendix" of BNF-style syntax definitions is something I would like to contribute (really for my own understanding but also for the above) however I won't make in-roads on that until after Valentine's Day. For now the best I can...
-
Touch every example that had placed description after (or within) the
-
I understand the importance of backward compatibility in the context of a ubiquitous phenomenon like x86 assembly code. I am not as clear about the virtue of maintaining backward compatibility for a tool such as gnuplot. However, I do understand that "it is what it is" so ... I'll just move on! I reckon we might already have a suitable end_of_axis_rangestoken! You wrote that a <definition> (especially one without a following comma) is a legitimate lexical element between the <axis-range-list> and...
-
2 scope of variables
-
Added "3 Syntax definition" subsection and used bullet list to spell out
-
Follow up clarification edits affecting:
-
Oh yes! That is exactly what I've been struggling to articulate these past couple of days. end_of_axis_ranges is equivalent to my Strawman 2. Read my reply below and I think you'll see that Strawman 1 is even better than Strawman 2.
-
Oh yes! That is exactly what I've been struggling to articulate these past couple of days. end_of_axis_ranges is equivalent to my Strawman 2. Read my reply below and I think you'll see that Strawman 1 as even better than Strawman 2.
-
To be honest I lost the plot (sic!) while writing this up! Preparing my reply to your responses helped bring clarity. Please consider the difference between what a keyword descriptively MEANS and the effect that a keyword CAUSES. In the case of this keyword sample I think it is fair to say that it is a misnomer. This particular keyword causes the gnuplot parser to stop waiting for [ = : ] lexical constructs/elements that are to be interpreted as axis-range specifiers. This sample keyword is not the...
-
Please consider the difference between what a keyword descriptively MEANS and the effect that a keyword CAUSES. In the case of this keyword sample I think it is fair to say that it is a misnomer. This particular keyword causes the gnuplot parser to stop waiting for [ = : ] lexical constructs/elements that are to be interpreted as axis-range specifiers. This sample keyword is not the only lexical element that causes the parser to stop waiting for axis-range specifiers. The script attached to this...
-
'sample' keyword is not tolerated after a `plot for[]` iterator
-
'sample' keyword is not tolerated after a `plot for[]` iterator
-
Clarify the apparent standard for main paragraph text cf. verbatim text.
-
Repaired paragraphs added by me that mistakenly used 73 char width
-
Clarification of instructions for seeing `make gih` target flow through
-
Interconnected series of clarification edits affecting:
-
Removed instances of double-parenthetical where an alternate style
-
Consistently use alphabetical order for
-
Consistently use alphabetical order for
-
Another two inline examples containing space characters that are
-
C#TeX \newpage - temporarily comment out all (10) newpage typesetting.
-
Two tilde ~ based (inline) examples of enhanced text mode specifically
-
Replaced ambiguous (albeit technically correct) use of "integral" (as adj.) with integer except when the calculus (noun. sum over interval) meaning was intended.
-
My first merge request - primarily to test my understanding of procedures
-
First commit.
-
Oh, brilliant thought!! Prompted by this I tweaked Notepad++ settings to allow me to create Unix-style (LF) end-of-line sequences. This tweak does not change files that already have Windows-CRLF EOLs but any new files created do adopt Unix-LF EOLs. So attached you will find four files. The two files using Windows style (CRLF) both throw the error. The two files using Unix style (LF) do not throw the error! Actual output from running each script at the PS (Windows PowerShell) command line is shown...
-
With reference to Also, I can confirm that at the gnuplot command line the following session throws no error: above, I have previously confirmed that the problem does not appear when one of these backslashes are typed into the command line of a gnuplot console session. I can confirm that the end of line style is the CRLF typical of windows ASCII files. Ought that be a contributing factor?
-
I am new to gnuplot so I don't have the benefit of historical hindsight. Yes, that script was necessarily dumbed down to only demonstrate a handful of error types that I wanted to report. Where you read if (demo) { I was originally testing an integer variable (not even a string!) for a non-zero value; and then, inside the if { }-clause, was using that non-zero value as a font-size to construct a "font, size" string to use after the font keyword. If the (integer) value was 0 then I would call a version...
-
I agree that a 5% hit to runtime is not a reasonable price to pay for something that is so trivial for a motivated script writer to implement with a simple string assignment. Not every script writer expects to access ARG0 for a function block they themselves have named! The suggestion of a new function is not something I would use ... or remember exists. Honestly, when the gnuplot manual section for Function Blocks makes it explicitly clear that ARG0 .. ARG9 are not available within a function block...
-
Unfortunately the only linux command line that I can readily access is an ubuntu installation under WSL. (Windows Subsystem for Linux) It has gnuplot v5.4.2 and of course, 5.x.x does not support function blocks. Upon extracting the tarball (gnuplot-6.0.rc1.tar.gz) and then running ./configure ... there were just too many no's and then the kicker: "no acceptable C compiler found in $PATH" So I am afraid I cannot contrast the behavior of "v6 rc1" under linux against what I see running under Windows...
-
Ah, yes! ... you see I start with the assumption that the function block may receive a variable number of arguments. See my example above wherein 4 arguments are expected but 6 arguments are accommodated. Those optional arguments are for special cases. In this situation it is for when the dataset is VERY large and so individual data point labels are not meaningful or the dataset size is so large that output to a GUI terminal (e.g. qt) causes an "insufficient resources" error. Other applications of...
-
Correct, testNoLB_NoPARENplot resembles what you intended to send me and that caused no errors and the plot output was as expected. Only after inserting the \ to continue the plot command over two lines did an error get generated. (see testNoPARENplot above) I may have missed it, but it is unclear to me whether you get this same error when a backslash is used outside a function block. Does it work directly from the command line or in a script to split the plot command? Easy enough to miss when my...
-
Am I missing a use case where having the name stored in a fixed-name variable would be advantageous? Yes, of the 10 string variables, ARG0 is definitely the most valuable and the common use case is Error handling. viz. function $conePlot << EOF local ARG0 = "$conePlot" # hack for want of CALL-like usage of ARG0..ARG9 # expected arguments: (N, varColor, useLabels, inFile [,outTerm [,outFile]] ) if (ARGC < 4) { printerr sprintf("function %s\: insufficient arguments passed",ARG0) exit } I do agree that...
-
Could this be an error specific to a particular native Windows platform? Yes, you may be on to something there. The small test case you sent throws an error for me. Just not the line continuation error I had seen previously. Do you see anything in my compile options (below) that might hint at a difference between the gnuplot.exe I am running and what is standard? gnuplot> show version long G N U P L O T Version 6.0 patchlevel rc1 last modified 2023-07-08 Copyright (C) 1986-1993, 1998, 2004, 2007-2023...
-
Function block use of the special string variables ARGC, ARG0, ARG1..ARG9 not consistent with CALL usage
-
The inline data example given is a poor one. The following is a more realistic one that I think emphasizes why a user would want/expect to freely use inline data within a function block. local strN = sprintf("%d",ARGV[1]) : : plot @inFile \ using ($f($1)[3]) : ($f($1)[4]) : ($f($1)[5]) : ($f($1)[6]) : ($f($1)[7]) \ with sectors linecolor @varColor \ , '-' using 1:2:3:4:5 with sectors linecolor variable # NOTE: the use of inline data, '-', throws no error but hangs script execution 0 0 2 @strN 0 EOD...
-
The above demo used only a short plot command so perhaps the impact of forcing a user to put the plot command on one, unbroken, line is lost. Please compare the following two sections of a block function definition. The interpreter friendly version first: plot @inFile using ($f($1)[3]) : ($f($1)[4]) : ($f($1)[5]) : ($f($1)[6]) : ($f($1)[7]) with sectors linecolor @varColor , @inFile using ($f($1)[3]+$f($1)[5]/2) : ($f($1)[4]-0.4) : 1 : (-fixT*( ($f($1)[3]+$f($1)[5]/3) + pi/2 ) ) : ($f($1)[7]) with...
-
A multi-line clause (aka compound statement) associated with an IF/ELSE command is interpreted as one line of commands - this affects string dereferencing using the @ token
-
inline data (as distinct from data block) is not allowed within a function block ... but generates no error message
-
Function block use of the special string variables ARGC, ARG0, ARG1..ARG9 not consistent with CALL usage
-
Defining a datablock within an IF or an ELSE statement throws an error
-
plot command line continuation using "\" within function block is not supported
-
The (approximate) multiplier necessary for achieving the intended angle of rotation (i.e. as specified by the variable ... whether that be in degrees or radians) is different depending on "set angles". This may be a clue as to where the error can be found. about 29 for "set angles degrees" and about 63 for "set angles radians" No, I am not referring to the obvious 180/pi multiplier for converting radians to degrees. Also the compile options are detailed below: gnuplot> show version long G N U P L...
-
in polar plots, "with labels rotate variable" is ineffective without points/nopoints
-
From a response posted just yesterday to wxWidgets issue 19223 I have learned that WxWidgets still has several unresolved issues having the label: Darkmode.
-
Note that on 2023-05-27 the following article was published simultaneously at github and at learn.microsoft.com : Support Dark and Light themes in Win32 apps It provides guidance for achieving a dark theme for win32 apps. It does not explicitly mention winapi or wxWidgets so I do not know if it is new information and therefore relevant to the "wont fix" status of this feature request. Perhaps someone with intimate knowledge of the CB UI might review the above article and determine if this feature...
1
