The same piece of demo script is submitted for 4 separately reported bugs.
It is evident that a datablock may not be defined within a compound statement (i.e. delimited by { .. } tokens) associated with an if or else statement.
It is not a documented ban and although the ability to define a datablock within an if and/or else statement is desirable I'd understand if this is categorized as a feature request rather than a bug.
## Some bugs related to function blocks and/or data blocks
## (gnuplot v6 rc1 on Windows 11)
##
## Given that function blocks are still experiemental I hesitate to call these "bugs" however,
## they are definitely not intuitive/expeceted behaviour.
## To experience each bug uncomment that/those script line(s) that has/have just a single hash '#'.
##
##(1) using the backslash "\" to break a (very long) plot command across multiple lines (within a function block) throws an error: "invalid character \"
##(2) datablock definition within an if or else compound statement throws error: "attempt to define data block from invalid context"
##(3) "function block" usage of the special string variables, ARGC, ARG0, ARG1..ARG9 is not consistent with "call" usage
##(3a) cannot access ARGV[1] as the string, ARG1;
##(3b) cannot access function block name as ARG0; (script filename is returned instead)
##(3c) ... but _can_ access argument count for function block as ARGC
##(4) inline data "plot '-'" may not be used within a function block (somewhat akin to the ban on defining a data block within a function block)
##
function $myPlot(strSource,strFont) << _EOFD
set title strSource." - variable color and orientation in plotstyle 'with labels'" offset 0,-2
## within a function block, a backslash throws the error: "invalid character \" .. but not within main script block
#plot @strSource \
# using 1:1:2:3:0 \
# with labels rotate variable tc variable font @strFont
plot @strSource using 1:1:2:3:0 with labels rotate variable tc variable font @strFont
## ARG0 returns script filename (not function block name) .. but ARGC correctly returns a count of arguments passed to function
##return sprintf("function, %s, completed; with %d arguments", "$myPlot", ARGC)
return sprintf("function, %s, completed; with %d arguments", ARG0, ARGC)
_EOFD
function $myInlinePlot << _EOFD
set title "function block INLINE - variable color and orientation in plotstyle 'with labels'" offset 0,-2
## within a function block, attempting to use inline data as the data source causes script execution to hang without any error message
## ... Ctrl+C will not terminate script execution from this point
## ... the only remedy I have found is to locate the hung gnuplot.exe process and terminate it
plot '-' using 1:1:2:3:0 with labels rotate variable tc variable font ",8"
1 one -30
2 two -60
3 three -90
4 four -120
5 five -150
6 six -180
7 seven -210
8 eight -240
9 nine -270
10 ten -300
11 eleven -330
12 twelve -360
EOD
## it seems that inline data may not be used within a function block
## (somewhat akin to the ban on defining a data block within a function block)
## however, the script hangs without any error message
return sprintf("function, %s, completed; with %d arguments", "$myInlinePlot", ARGC)
_EOFD
##
## Additional data columns can be used to hold text rotation or color
## for plot style "with labels"
##
debug = 1
#if (debug) { ## defining a datablock inside an if/else throws: "attempt to define data block from invalid context"
$Data1 <<EOD
1 one -30
2 two -60
3 three -90
4 four -120
5 five -150
6 six -180
7 seven -210
8 eight -240
9 nine -270
10 ten -300
11 eleven -330
12 twelve -360
EOD
## leading whitespace before the above EOD _does_ throw an error: "no datablock named $Data2"
## ... fair enough since $Data1 definition never correctly ends if EOD not found at start of line.
# }
#else {
$Data2 <<EOD
1 one -30
2 two -60
3 three -90
4 four -120
5 five -150
6 six -180
7 seven -210
8 eight -240
9 nine -270
10 ten -300
11 eleven -330
12 twelve -360
EOD
# }
$Data3 <<EOD
1 one -30
2 two -60
3 three -90
4 four -120
5 five -150
6 six -180
7 seven -210
8 eight -240
9 nine -270
10 ten -300
11 eleven -330
12 twelve -360
EOD
set angle degrees
unset key
set title "variable color and orientation in plotstyle 'with labels'" offset 0,-2
set xrange [0:13]
set yrange [0:13]
set xtics 1,1,12 nomirror
set ytics 1,1,12 nomirror
set border 3
stringFont = "\"Times,10\"" ## exercising care to escape double quotes is necessary (and appropriate)
##plot $Data3 using 1:1:2:3:0 with labels rotate variable tc variable font ",20"
## no error from using backslash to break the above plot command over multiple lines
plot $Data3 \
using 1:1:2:3:0 \
with labels rotate variable tc variable font @stringFont
pause mouse close
printerr $myPlot("$Data1","\"Times,12\"")
pause mouse close
printerr $myPlot("$Data2","\"Times,16\"")
pause mouse close
printerr $myPlot("$Data3","\"Times,20\"")
pause mouse close
set title "INLINE - variable color and orientation in plotstyle 'with labels'" offset 0,-2
plot '-' using 1:1:2:3:0 with labels rotate variable tc variable font ",24"
1 one -30
2 two -60
3 three -90
4 four -120
5 five -150
6 six -180
7 seven -210
8 eight -240
9 nine -270
10 ten -300
11 eleven -330
12 twelve -360
EOD
# EOD
## leading whitespace before EOD, above, does not _seem_ to matter however,
## for the inline data example within a function block this leading whitspace was avoided just to remove any possible doubt
pause mouse close
## to demonstrate bug (4) (and this script hanging without any error message) uncomment the following function call
#printerr $myInlinePlot()
#pause mouse close
I think this is a reasonable feature request.
There may turn out to be a reason why this is not easy to achieve, but my first reaction is that it should be possible.
Ticket moved from /p/gnuplot/bugs/2654/
Can't be converted:
I am just getting back to this now, since version 6 is out and apparently doing well except for the wxt terminal.
The strange thing is, this script works for me now. The three data blocks are all defined successfully even though two of them are inside the if {} else {} bracketed clauses.
It works in the 6.0.0 release version, current git tip, and also in the version 6 -rc1 which was from before the date on this request. So was this ever failing? Or maybe some other problem was contributing?