gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Plans for gnuplot version 5

[sfeam <sf...@us...>]

On Saturday, 08 March 2014 09:57:31 AM Bastian Märkisch wrote:
> Am 08.03.2014 09:43, schrieb pl...@pi...:
> 
> > While on the subject of split lines it would be really handy if the
> > history re-united split lines, that may also help with the above.
> >
> >    If I have a plot command in three lines with back-slash continuation,
> > when I want to repeat it I have do the up arrow three times to get the
> > first bit, three times to get the second bit, three times to get the
> > last bit, then hit the return key.
> >
> > Unless there's a down side it would be great to the get the last
> > _command_ with one up arrow, rather then the last text line in the
> > buffer, which is pretty much useless on its own.
> >
> 
> Please have a look at Shigeharu Takeno's patch on SF:
> "#634 save multiline input to a single line in the history"
> https://sourceforge.net/p/gnuplot/patches/634/

While I understand that in some contexts it makes sense to 
concatenate the individual \-terminated lines into a single
history entry, this is not true for the most common case. 

My typical use comes from starting with a command like:

plot \
  "A" using ... with <something complicated>, \
  "B" using ... with <something else>, \
  "C" using ... with <next set of options>, \
  "D" using ... with <yet more stuff, \
;

After looking at the results, I may decide that I want instead
C followed by D followed by A and to not include B at all.
As it is now, I can back up and reorder the component line
fragments from the history list.  If they are concatenated into
one very long line it would be more work to edit the line than
to type (or cut-n-paste) them in again.   

For this reason I do not like the idea of concatenating lines in
the history.

Maybe there is a more creative solution - perhaps a variant on
gnuplot> history !4
gnuplot> history !5
gnuplot> history !6
on the order of "history !6,4-5" or maybe "history !4 to EOC"
or something like that.

	Ethan

Re: Are there any instruction or sample code to write import func(x) in C(++)?

[Tatsuro M. <tma...@ya...>]

--- On Sat, 2014/3/8, Tatsuro MATSUOKA wrote:
> --- On Sat, 2014/3/8, Tatsuro MATSUOKA wrote:
> > --- On Sat, 2014/3/8, Ethan A Merritt wrote:
> > > On Saturday, 08 March, 2014 10:29:44 Tatsuro MATSUOKA wrote:
> > > > Hello
> > > > 
> > > > Prof. Takeno introduced a new feature 'import' on the gnuplot threads in Japan
> > > > 
> > > > On the ChangeLog, 2014-02-27, I have found the description.
> > > > 
> > > > I have read 'help import' and explanation for 'import' for gnuplot.pdf  created from the recent cvs source.
> > > > 
> > > > However I cannot find out how to prepare the C or C++ codes.
> > > > Are there any instruction or sample  code to write import func(x) in C(++)?
> > > 
> > > Yes. 
> > > The directory .../demo/plugin/  contains sample code, a Makefile, and
> > > a demo (plugin.dem) that exercises the sample code.
> > > 
> > >     Ethan
> > 
> > Thanks! I will try later.
> > 
> > Tatsuro
> > 
> I have excute build check Cygwin_x64
> After make check, I have checked demo/plugin/.
> 
> demo_plugin.so.exe is created.  However, demo_plugin.dll is needed for Cygwin.
> So I have created demo_plugin.dll by
> 
> gcc -shared -o demo_plugin.dll demo_plugin_so-demo_plugin.o
> 
> With demo_plugin.dll, plugin.dem test went well.

I have renamed  demo_plugin.so.exe to demo_plugin.dll.
Using this file, plugin.dem test went well.

Regards

Tatsuro

Re: Plans for gnuplot version 5 - typecasting

[<pl...@pi...>]

On 03/07/14 21:23, Ethan A Merritt wrote:
> On Friday, 07 March, 2014 12:05:27 Ethan A Merritt wrote:
>> ere is one way to do it.  This may not cover all the desired cases:
>>
>> gnuplot>  argb(a,r,g,b) = sprintf("0x%.2x%.2x%.2x%.2x",a,r,g,b)
>> gnuplot> print argb(0x78,0,0,0)
>> 0x78000000
>> gnuplot> print argb(0xff, 0, 255, 127.0)
>> 0xff00ff7f
>>
>> Yes that produces a string rather than an integer, but the plotting commands
>> are happy to take the string.
>
>
> Correction.  If you want to pass that directly to a plot command you
> currently need to modify it to
>
> gnuplot>  argb(a,r,g,b) = sprintf("#%.2x%.2x%.2x%.2x",a,r,g,b)
>
> The first form generates a valid hexadecimal constant but the
> color code will only parse it that way if passed as a bare integer,
> not in a string constant.  So this works:
>      plot x lc rgb 0xff00ff7f
> But this doesn't
>      plot x lc rgb "0xff00ff7f"
>
> That's fixable.
>
> 	Ethan
>
>

Ethan, this touches on something that I often get hit with when trying 
to generalise to plot some kind of iteration. The problem is how to 
compose a filename, line type specifier, label id or some such element 
composed from the an iteration variable and/or gnuplot constants.

Often it will involve string concatenation or a sprintf() result but as 
we see here, a string result may not be acceptable to the parser.

Now you could tweak the code to accept both integer and string , which 
seems to be what you mean by  "That's fixable." However, wouldn't it be 
a much more far reaching fix to have some kind of typecasting ability?

The fundamental problem here is automatic type magic does not always 
give the desired or required variable type and the parser spits it out. 
Indeed it's often pretty difficult for someone to does not have a 
detailed knowledge of the code to determine what the type of the result 
is going to be.


Type-casting is the classic solution to that kind of problem and 
presumably would not be that difficult of disruptive to introduce.


In that context this may not be v5 issue, but I'll let you judge the 
implications.

/Peter.

Re: Plans for gnuplot version 5

[Bastian M. <bma...@we...>]

Am 08.03.2014 09:43, schrieb pl...@pi...:

> While on the subject of split lines it would be really handy if the
> history re-united split lines, that may also help with the above.
>
>    If I have a plot command in three lines with back-slash continuation,
> when I want to repeat it I have do the up arrow three times to get the
> first bit, three times to get the second bit, three times to get the
> last bit, then hit the return key.
>
> Unless there's a down side it would be great to the get the last
> _command_ with one up arrow, rather then the last text line in the
> buffer, which is pretty much useless on its own.
>

Please have a look at Shigeharu Takeno's patch on SF:
"#634 save multiline input to a single line in the history"
https://sourceforge.net/p/gnuplot/patches/634/

   Bastian

Re: Plans for gnuplot version 5

[<pl...@pi...>]

On 03/07/14 21:37, Jonathan Thornburg wrote:
> On Tue, Mar 04, 2014 at 08:51:32PM -0800, sfeam wrote:
>> This is a reminder that a first release candidate for gnuplot version 5
>> is planned for later this year. In preparation for that I will bump the
>> version information in the current development source tree to 5.0.alpha.
> [[...]]
>>
>> Important note:  If there is some behaviour or syntax in gnuplot
>> that has been annoying you for the last 20 years, please speak up.
>> This is the best chance you will have to get it changed!
>
> Ok, here's my candidate for #1 gnuplot annoyance:
>
> Suppose I have a gnuplot script which sets up a bunch of functions,
> computes some stuff, and eventually does a plot.  For nontrivial plots
> this means that I have many continuation lines ("backslash at the end
> of the line") in the 'plot' command.  The problem is, if I have a
> syntax error anywhere in the plot command, the error will be reported
> with the line number of the *last* continuation line.
>
> For example, what happens if I put an extra comma into this plot command:
>
> plot sigmoid(A,B,C,D, P)                                                \
>          title 'sigmoid fit'                                             \
>          with lines linetype 1 linecolor -1,                             \
>                                                                          \
>       0.327                                                              \
>          title 'Zero OD 0.327 & 0.309'                                   \
>          axis x1y2                                                       \
>          with lines linetype 2 linecolor 3,                              \
>       0.309                                                              \
>          notitle                                                         \
>          axis x1y2                                                       \
>          with lines linetype 2 linecolor 3,                              \
>                                                                          \
>       range20                                                            \
>          title '20% & 80% yrange of sigmoid'                             \
>          axis x1y1                                                       \
>          with lines linetype 1 linecolor 4,                              \
>       range80                                                            \
>          notitle                                                         \
>          axis x1y1                                                       \
>          with lines linetype 1 linecolor 4,                              \
>                                                                          \
>       range10                                                            \
>          title '10% & 90% yrange of sigmoid'                             \
>          axis x1y1                                                       \
>          with lines linetype 1 linecolor 5,                              \
>       range90                                                            \
>          notitle                                                         \
>          axis x1y1                                                       \
>          with lines linetype 1 linecolor 5,                              \
>                                                                          \
>                                                                          \
>       'plate-G25-standards.dat'                                          \
>          title 'standards'                                               \
>          axis x1y2                                                       \
>          with points pointtype 7 pointsize 0.5 linecolor -1,,            \
>                                                                          \
>       'plate-G25-QC-high.dat'                                            \
>          title 'QC high (100)'                                           \
>          axis x1y2                                                       \
>          with points pointtype 1 pointsize 0.750 linecolor rgb "#00A000",\
>                                                                          \
>       'plate-G25-QC-low.dat'                                             \
>          title 'QC low (12.5)'                                           \
>          axis x1y2                                                       \
>          with points pointtype 1 pointsize 0.750 linecolor 1
>
> I get an echoed line (which is several screenfills line-wrapped),
> with an "^" cursor which I can't interpret (because the "line" in
> question is many physical lines wrapped together with line continuation),
> followed by
>
>                                     ^
> "bad.gnuplot", line 159: invalid expression
>
> where line 159 is the last of the continuation lines.
>
> It would be wonderful if error reports could refer to the actual physical
> line of the error instead.  (I realise this might be messy to implement
> if we've already processed the line continuations before the error is
> found.)
>
> ciao,
>

That's a good point . I often have a long , slash separated, line by the 
time I've got all the titles and line styles into the plot command. The 
error messages are of very little help other than just indicating 
something was wrong with the syntax. Digging out where the problem is, 
is usually rather a lengthy debugging process.


Now since the caret symbol is there there must be some character 
position that it is trying to indicate. So one simply improvement would 
be to add that information to the error message

eg
  "bad.gnuplot", line 159 CHARACTER 78: invalid expression

That would at least give a clue as to where in the multiple split lines 
the error was detected.



While on the subject of split lines it would be really handy if the 
history re-united split lines, that may also help with the above.

  If I have a plot command in three lines with back-slash continuation, 
when I want to repeat it I have do the up arrow three times to get the 
first bit, three times to get the second bit, three times to get the 
last bit, then hit the return key.

Unless there's a down side it would be great to the get the last 
_command_ with one up arrow, rather then the last text line in the 
buffer, which is pretty much useless on its own.

/m2c



regards, Peter.

Re: Plans for gnuplot version 5

[Daniel J S. <dan...@ie...>]

On 03/07/2014 04:43 PM, Jon Gjengset wrote:
>> As for areas for refactoring:
>
> Not sure how much has changed in the image mode handling code recently,
> but I keep running into issues with image mode. In particular:
>
>    - Visible pixel grid has a scan line longer than previous scan lines.
>    - Number of pixels cannot be factored into integers matching grid. N = ...  K = ...
>
> Improving the robustness of the image handling code would certainly be a
> welcome change, even if the input syntax for images would have to change
> (not sure that it would need to though, as "failsafe" is usually enough
> fix the problem).

I'm open to the idea.  Ethan and I agreed on a message in the configure 
indicating that image scripts were experimental.  Not sure why it is no 
longer robust...used to be, albeit finicky syntax.

The big challenge was compatibility with the existing gnuplot binary and 
the df_readline() routine.  That really put things in a bind, partly 
because the gnuplot binary was so basic that it became restrictive to 
work around it.

Someone mentioned reviewing code quality.  There are many things that 
could be done better.  Organization of the main plotting routines for 
more clarity would be a good start.  A way to re-read data for 
individual plots.  Remove all global variables (almost had all of them 
at one point, but more keep finding their way in).  The date code, but 
that one's not for mortals.  Many more.  But I think before embarking on 
this, it takes some good planning.

Dan

Re: Are there any instruction or sample code to write import func(x) in C(++)?

[Tatsuro M. <tma...@ya...>]

--- On Sat, 2014/3/8, Tatsuro MATSUOKA wrote:
> --- On Sat, 2014/3/8, Ethan A Merritt wrote:
> > On Saturday, 08 March, 2014 10:29:44 Tatsuro MATSUOKA wrote:
> > > Hello
> > > 
> > > Prof. Takeno introduced a new feature 'import' on the gnuplot threads in Japan
> > > 
> > > On the ChangeLog, 2014-02-27, I have found the description.
> > > 
> > > I have read 'help import' and explanation for 'import' for gnuplot.pdf  created from the recent cvs source.
> > > 
> > > However I cannot find out how to prepare the C or C++ codes.
> > > Are there any instruction or sample  code to write import func(x) in C(++)?
> > 
> > Yes. 
> > The directory .../demo/plugin/  contains sample code, a Makefile, and
> > a demo (plugin.dem) that exercises the sample code.
> > 
> >     Ethan
> 
> Thanks! I will try later.
> 
> Tatsuro
> 
I have excute build check Cygwin_x64
After make check, I have checked demo/plugin/.

demo_plugin.so.exe is created.  However, demo_plugin.dll is needed for Cygwin.
So I have created demo_plugin.dll by

gcc -shared -o demo_plugin.dll demo_plugin_so-demo_plugin.o

With demo_plugin.dll, plugin.dem test went well.

Thanks

Tatsuro

Re: Are there any instruction or sample code to write import func(x) in C(++)?

[Tatsuro M. <tma...@ya...>]

--- On Sat, 2014/3/8, Ethan A Merritt wrote:

> On Saturday, 08 March, 2014 10:29:44 Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > Prof. Takeno introduced a new feature 'import' on the gnuplot threads in Japan
> > 
> > On the ChangeLog, 2014-02-27, I have found the description.
> > 
> > I have read 'help import' and explanation for 'import' for gnuplot.pdf  created from the recent cvs source.
> > 
> > However I cannot find out how to prepare the C or C++ codes.
> > Are there any instruction or sample  code to write import func(x) in C(++)?
> 
> Yes. 
> The directory .../demo/plugin/  contains sample code, a Makefile, and
> a demo (plugin.dem) that exercises the sample code.
> 
>     Ethan

Thanks! I will try later.

Tatsuro

Re: Are there any instruction or sample code to write import func(x) in C(++)?

[Ethan A M. <sf...@us...>]

On Saturday, 08 March, 2014 10:29:44 Tatsuro MATSUOKA wrote:
> Hello
> 
> Prof. Takeno introduced a new feature 'import' on the gnuplot threads in Japan
> 
> On the ChangeLog, 2014-02-27, I have found the description.
> 
> I have read 'help import' and explanation for 'import' for gnuplot.pdf  created from the recent cvs source.
> 
> However I cannot find out how to prepare the C or C++ codes.
> Are there any instruction or sample  code to write import func(x) in C(++)?

Yes. 
The directory .../demo/plugin/  contains sample code, a Makefile, and
a demo (plugin.dem) that exercises the sample code.

	Ethan

Re: How to reply to the Bug ticket

[Ethan A M. <sf...@us...>]

On Saturday, 08 March, 2014 10:18:29 Tatsuro MATSUOKA wrote:
> Hello
> 
> I have created a bug ticket (#1346 qt terminal fails on Cygwin-x86).
> 
> Ethan Merritt has made a reply to the ticket.
> 
> However, I cannot figure out how to reply to his comments.
> 
> I am new to the recent bug ticket system.
> 
> It is grateful for me if someone shows the correct way.

So far as I know, the only permission check for commenting is
that you must first log in to SourceForge.    If that does not work,
we may have to request help from the SourceForge support team.

	Ethan

Are there any instruction or sample code to write import func(x) in C(++)?

[Tatsuro M. <tma...@ya...>]

Hello

Prof. Takeno introduced a new feature 'import' on the gnuplot threads in Japan

On the ChangeLog, 2014-02-27, I have found the description.

I have read 'help import' and explanation for 'import' for gnuplot.pdf  created from the recent cvs source.

However I cannot find out how to prepare the C or C++ codes.
Are there any instruction or sample  code to write import func(x) in C(++)?

Regards

Tatsuro

How to reply to the Bug ticket

[Tatsuro M. <tma...@ya...>]

Hello

I have created a bug ticket (#1346 qt terminal fails on Cygwin-x86).

Ethan Merritt has made a reply to the ticket.

However, I cannot figure out how to reply to his comments.

I am new to the recent bug ticket system.

It is grateful for me if someone shows the correct way.

Regards

Tatsuro

Re: Plans for gnuplot version 5

[Jon G. <jo...@th...>]

> As for areas for refactoring:

Not sure how much has changed in the image mode handling code recently,
but I keep running into issues with image mode. In particular:

  - Visible pixel grid has a scan line longer than previous scan lines.
  - Number of pixels cannot be factored into integers matching grid. N = ...  K = ...

Improving the robustness of the image handling code would certainly be a
welcome change, even if the input syntax for images would have to change
(not sure that it would need to though, as "failsafe" is usually enough
fix the problem).

Re: Plans for gnuplot version 5

[Tait <gnu...@t4...>]

Support for an arbitrary number of axes would be a nice feature, and
one that several people have requested. To get an idea of what they
mean, in 3D look for "spider plot" or sometimes "star plot" or "radar
chart", and in 2D see "parallel coordinates chart". This would be a
new feature, but I think it would imply some fundamental changes to
the syntax for describing axes and axis settings, since it would not
be feasible to hard-code a finite list of x, x2, x3, x4, x... etc.

Re: Plans for gnuplot version 5

[Juhász P. <pet...@gm...>]

On Fri, 2014-03-07 at 11:40 -0800, Ethan A Merritt wrote:
> On Friday, 07 March, 2014 20:28:53 Juhász Péter wrote:
> > There is one more point I'd like to raise:
> > there have been much talk about new features and small, incompatible
> > changes, but perhaps a new major release would be a good time to look at
> > the state of the program from a different perspective: find and fix
> > longstanding bugs, go through the featureset and check for
> > inconsistencies and irregularities, check code quality and refactor
> > where needed.
> 
> That's pretty vague.  Do you have specific things in mind?
> 

The patch for translated messages offers a good case study.

The functionality would be good to have, but the changes associated with
it look like unfeasibly large because the code is not organized right
for it. Strings that are part of user messages are all over the place,
spread over several files, embedded in ad-hoc parsing code. If they were
already concentrated, it would be easier to localize them.

As for areas for refactoring:
there is datafile.c with its convoluted code paths that nobody dares to
touch in fear of breaking it; much of the axis-related code, too
complicated and full of hard-coded special cases like the log-scaling
you've mentioned; then there is some duplicate code in the 2d and 3d
plotting code paths... There are too many terminal types, many of them
ancient, not really used and tested anymore, each supporting different
features, having different defaults.

Against all these there is the time-honored principle of not trying to
fix that ain't broken. That and the fact that all contributors to the
project are volunteers, sacrificing their own free time.

I can accept a decision that attacking any of the problems outlined
above is not feasible given the constraints of time and manpower, I just
wanted to start a discussion on them, to get these issues out in the
open.

Peter

Re: Plans for gnuplot version 5

[Jonathan T. <jt...@as...>]

On Tue, Mar 04, 2014 at 08:51:32PM -0800, sfeam wrote:
> This is a reminder that a first release candidate for gnuplot version 5
> is planned for later this year. In preparation for that I will bump the
> version information in the current development source tree to 5.0.alpha.
[[...]]
> 
> Important note:  If there is some behaviour or syntax in gnuplot
> that has been annoying you for the last 20 years, please speak up.
> This is the best chance you will have to get it changed!

Ok, here's my candidate for #1 gnuplot annoyance:

Suppose I have a gnuplot script which sets up a bunch of functions,
computes some stuff, and eventually does a plot.  For nontrivial plots
this means that I have many continuation lines ("backslash at the end
of the line") in the 'plot' command.  The problem is, if I have a
syntax error anywhere in the plot command, the error will be reported
with the line number of the *last* continuation line.

For example, what happens if I put an extra comma into this plot command:

plot sigmoid(A,B,C,D, P)                                                \
        title 'sigmoid fit'                                             \
        with lines linetype 1 linecolor -1,                             \
                                                                        \
     0.327                                                              \
        title 'Zero OD 0.327 & 0.309'                                   \
        axis x1y2                                                       \
        with lines linetype 2 linecolor 3,                              \
     0.309                                                              \
        notitle                                                         \
        axis x1y2                                                       \
        with lines linetype 2 linecolor 3,                              \
                                                                        \
     range20                                                            \
        title '20% & 80% yrange of sigmoid'                             \
        axis x1y1                                                       \
        with lines linetype 1 linecolor 4,                              \
     range80                                                            \
        notitle                                                         \
        axis x1y1                                                       \
        with lines linetype 1 linecolor 4,                              \
                                                                        \
     range10                                                            \
        title '10% & 90% yrange of sigmoid'                             \
        axis x1y1                                                       \
        with lines linetype 1 linecolor 5,                              \
     range90                                                            \
        notitle                                                         \
        axis x1y1                                                       \
        with lines linetype 1 linecolor 5,                              \
                                                                        \
                                                                        \
     'plate-G25-standards.dat'                                          \
        title 'standards'                                               \
        axis x1y2                                                       \
        with points pointtype 7 pointsize 0.5 linecolor -1,,            \
                                                                        \
     'plate-G25-QC-high.dat'                                            \
        title 'QC high (100)'                                           \
        axis x1y2                                                       \
        with points pointtype 1 pointsize 0.750 linecolor rgb "#00A000",\
                                                                        \
     'plate-G25-QC-low.dat'                                             \
        title 'QC low (12.5)'                                           \
        axis x1y2                                                       \
        with points pointtype 1 pointsize 0.750 linecolor 1

I get an echoed line (which is several screenfills line-wrapped),
with an "^" cursor which I can't interpret (because the "line" in
question is many physical lines wrapped together with line continuation),
followed by

                                   ^
"bad.gnuplot", line 159: invalid expression 

where line 159 is the last of the continuation lines.

It would be wonderful if error reports could refer to the actual physical
line of the error instead.  (I realise this might be messy to implement
if we've already processed the line continuations before the error is
found.)

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
    at any given moment.  How often, or on what system, the Thought Police
    plugged in on any individual wire was guesswork.  It was even conceivable
    that they watched everybody all the time."  -- George Orwell, "1984"

Re: Plans for gnuplot version 5

[Ethan A M. <sf...@us...>]

On Friday, 07 March, 2014 12:05:27 Ethan A Merritt wrote:
> ere is one way to do it.  This may not cover all the desired cases:
> 
> gnuplot>  argb(a,r,g,b) = sprintf("0x%.2x%.2x%.2x%.2x",a,r,g,b)
> gnuplot> print argb(0x78,0,0,0)
> 0x78000000
> gnuplot> print argb(0xff, 0, 255, 127.0)
> 0xff00ff7f
> 
> Yes that produces a string rather than an integer, but the plotting commands
> are happy to take the string.   


Correction.  If you want to pass that directly to a plot command you
currently need to modify it to
 
gnuplot>  argb(a,r,g,b) = sprintf("#%.2x%.2x%.2x%.2x",a,r,g,b)

The first form generates a valid hexadecimal constant but the
color code will only parse it that way if passed as a bare integer,
not in a string constant.  So this works:
    plot x lc rgb 0xff00ff7f
But this doesn't
    plot x lc rgb "0xff00ff7f"

That's fixable.

	Ethan

Re: Plans for gnuplot version 5

[Ethan A M. <sf...@us...>]

On Friday, 07 March, 2014 11:06:10 Tait wrote:

> There does seem to be a problem with any approach involving using the
> alpha channel:
> gnuplot> rgba(a,r,g,b)=(a*2**24) | (r*2**16) | (g*2**8) | b
> # having << and >> operators here would be nice

I have wanted that myself more than once.
Please file a Feature Request.

I'm not sure whether the current SourceForge infrastructure allows it,
but if  possibleI will attach a "Version 5 target" flag to the relevant
Bugs, Feature Requests, and Patches on the tracker.

> gnuplot> print rgba(0,0,0,0)
> 0
> gnuplot> print rgba(0x88,0,0,0)
>          non-integer passed to boolean operator
> gnuplot> print rgba(0x78,0,0,0)
> 2025521152
> 
> The problem, of course, is that gnuplot doesn't have an unsigned
> integer data type. The "non-integer" error can be avoided by using +
> instead of |, but then the number is promoted to float and it cannot
> be used as intended in the plot command like
> gnuplot> plot x lw 5 lc rgbcolor rgba(0x88,0x22,0x55,0x88), -x lw 5 lc rgbcolor rgba(0x88,0xBB,0x77,0x33)
> 
> Even defining the function as
> gnuplot> rgba(a,r,g,b)=int((a*2**24) + (r*2**16) + (g*2**8) + b)
> doesnt seem to work right when it comes to the plot command.

Here is one way to do it.  This may not cover all the desired cases:

gnuplot>  argb(a,r,g,b) = sprintf("0x%.2x%.2x%.2x%.2x",a,r,g,b)
gnuplot> print argb(0x78,0,0,0)
0x78000000
gnuplot> print argb(0xff, 0, 255, 127.0)
0xff00ff7f

Yes that produces a string rather than an integer, but the plotting commands
are happy to take the string.   

Although the string can evaluate to a negative value when converted by int(),
the color handling code knows to treat it as unsigned.
Using it for arithmetic might fail, but any numeric operation that is sensitive to
the signed/unsigned distinction is probably a dubious thing to apply to colors.

	Ethan

Re: Plans for gnuplot version 5

[Ethan A M. <sf...@us...>]

On Friday, 07 March, 2014 20:28:53 Juhász Péter wrote:
> There is one more point I'd like to raise:
> there have been much talk about new features and small, incompatible
> changes, but perhaps a new major release would be a good time to look at
> the state of the program from a different perspective: find and fix
> longstanding bugs, go through the featureset and check for
> inconsistencies and irregularities, check code quality and refactor
> where needed.

That's pretty vague.  Do you have specific things in mind?

I would love to rip out and replace all the log-scaling code,
but that's more work than I have time for in the forseeable
future.   Unless someone wants to tackle it, I don't see a
feasible way to do this for version 5.

	Ethan

Re: Plans for gnuplot version 5

[Juhász P. <pet...@gm...>]

On Thu, 2014-03-06 at 13:52 -0800, Ethan A Merritt wrote:
> On Thursday, 06 March, 2014 21:31:00 Juhász Péter wrote:
> > On Wed, 2014-03-05 at 15:02 -0800, Ethan A Merritt wrote:
> 
> > > > Also, may ask what is your proposed timeline for 5.0?
> > > 
> > > That's what I'm trying to determine.
> > 
> > OK, I rephrase the question: what's your latest preferred date for the
> > final release? End of this year perhaps?
> > I think it would be beneficial if you set a tentative date because then
> > potential contributors would be able to gauge whether their proposed new
> > features are plausible within that timeframe.
> > 
> > Peter
> 
> Remember that new features per se do not have to go in before version 5, 
> only features that would be incompatible with past syntax or data formats.
> 
> If the list of "must change" items is empty, then I propose to put out
> an rc1 snapshot by the end of March.
> 
> If the list is non-empty, the rc1 snapshot would go out as soon as the
> list is clear again.
> 
> I expect there will be an rc2 either very soon after that if some major
> but fixable defect is spotted (this has happened before) otherwise
> after 3 months or so of testing and hopefully feedback.
> 
> My crystal ball is hazy about where that puts the final release.
> I hope well before the end of the year.
> 

[...snip explanation about translation of strings...]

> 
> 	Ethan
> 


Thanks for the detailed and clear answer.

There is one more point I'd like to raise:
there have been much talk about new features and small, incompatible
changes, but perhaps a new major release would be a good time to look at
the state of the program from a different perspective: find and fix
longstanding bugs, go through the featureset and check for
inconsistencies and irregularities, check code quality and refactor
where needed.
Of course I'm aware that you and others have been doing such work, and
it is much appreciated. But perhaps in anticipation of the new release,
it would be better to focus effort on tasks of these nature, even at the
expense of new features. One might argue that gnuplot has enough
features as it is.

Peter

Re: Plans for gnuplot version 5

[<pl...@pi...>]

On 03/07/14 12:06, Tait wrote:
> a new keyword like rgbacolor or argbcolor makes the most sense.)


That seems a very good idea but I suspect there are situations where 
colours are defined outside of an explicit declaration, like that.

/Peter

Re: Plans for gnuplot version 5

[Tait <gnu...@t4...>]

> > Currently (version 4) you can plot with RGB colors by saying, for instance
> >    plot  ... using 1:2:3 linecolor rgb variable
> > where input column 3 contains 24-bit RGB values.
> > Bits 25-32 are ignored, and the lines are all solid color.
> 
> Ah, I see, I was thinking of literal RGB values (#AARRGGBB), not their
> binary representation. Hence also my reference to what seems to be
> "common".
> 
> > Are you suggesting that any command using the keyword "rgb" should
> > ignore the high bits?
> > I.e. that a new keyword rgba or argb should be introduced everywhere?
> > And than what - the program would invert the high byte during input?
> 
> Yes, that seems like a sensible approach to me. Particularly so because
> it will never surprise a user who is expecting RGB, but suddenly gets
> RGBA. In fact, even if you don't invert the high bytes, I think the
> choice to use an alpha channel should be explicit.

There does seem to be a problem with any approach involving using the
alpha channel:
gnuplot> rgba(a,r,g,b)=(a*2**24) | (r*2**16) | (g*2**8) | b
# having << and >> operators here would be nice
gnuplot> print rgba(0,0,0,0)
0
gnuplot> print rgba(0x88,0,0,0)
         non-integer passed to boolean operator
gnuplot> print rgba(0x78,0,0,0)
2025521152

The problem, of course, is that gnuplot doesn't have an unsigned
integer data type. The "non-integer" error can be avoided by using +
instead of |, but then the number is promoted to float and it cannot
be used as intended in the plot command like
gnuplot> plot x lw 5 lc rgbcolor rgba(0x88,0x22,0x55,0x88), -x lw 5 lc rgbcolor rgba(0x88,0xBB,0x77,0x33)

Even defining the function as
gnuplot> rgba(a,r,g,b)=int((a*2**24) + (r*2**16) + (g*2**8) + b)
doesnt seem to work right when it comes to the plot command.

(And if I may toss in my 2p, my intuitive expectation is that 0 means transparent, and 1 or 255 or however it ends up means opaque. I think this means a new keyword like rgbacolor or argbcolor makes the most sense.)

patch: qtterminal: make point plots aware of linewidth

[Dieter R. <die...@ps...>]

Hi everybody,

this is my first contribution here, so if my form or the way to send 
this patch is wrong, please correct me.

-----------------

The qt terminal did not take the linewidth parameter of a plot into 
account, when plotting 'with points'. Especially for point types 1 and 
2, but in general for all non-filled point types, this results in points 
drawn with very thin lines, which tend not to be visible well when 
printed, for example.

Attached patches change this for gnuplot 4.6.5 and latest 4.7-CVS.
Like on other terminals, it's now possible to plot 'with points lw 2' to 
get the points made of thicker lines.

I am not sure, if the way I implemented this is the right way, 
especially for the more complicated QtGnuplotPoints:: way of drawing points.



Thanks in advance for feedback on these patches.

Cheers,
Dieter

Re: Plans for gnuplot version 5

[Tait <gnu...@t4...>]

> > Change the default color sequence
> 
> I put in this work already for 4.6.
> Apparently it is not well enough advertised.

I do load my own colors most of the time, so I thought I'd missed
something, but in my 4.6p5 install "out-of-the-box" it still plots
red, green, blue, etc. I see "colors_default.gp", "colors_mono.gp",
etc. in the share directory now that you've mentioned it, but I doubt
anybody would find that unless they were looking. What I'd like is for
the default "out-of-the-box" color sequence -- i.e. what most users
will end up using -- to be better. (The colors_default.gp palette
seem fine, if it's your favorite.)

> > Default enhanced mode on
> As noted in the announcement, that is indeed the new default.

Oops, I overlooked that; sorry.

Re: Plans for gnuplot version 5

[Ethan A M. <sf...@us...>]

On Thursday, 06 March, 2014 21:31:00 Juhász Péter wrote:
> On Wed, 2014-03-05 at 15:02 -0800, Ethan A Merritt wrote:

> > > Also, may ask what is your proposed timeline for 5.0?
> > 
> > That's what I'm trying to determine.
> 
> OK, I rephrase the question: what's your latest preferred date for the
> final release? End of this year perhaps?
> I think it would be beneficial if you set a tentative date because then
> potential contributors would be able to gauge whether their proposed new
> features are plausible within that timeframe.
> 
> Peter

Remember that new features per se do not have to go in before version 5, 
only features that would be incompatible with past syntax or data formats.

If the list of "must change" items is empty, then I propose to put out
an rc1 snapshot by the end of March.

If the list is non-empty, the rc1 snapshot would go out as soon as the
list is clear again.

I expect there will be an rc2 either very soon after that if some major
but fixable defect is spotted (this has happened before) otherwise
after 3 months or so of testing and hopefully feedback.

My crystal ball is hazy about where that puts the final release.
I hope well before the end of the year.

This timeline may go out the window if there is consensus that
version 5 should include some major change that has not been
worked on yet at all.  For example several years back Shige Takeno
proposed that all printout to the user go through a translation layer.
The original patch (#436) would have been very invasive, but I like the
idea in principle.  There was a little bit of followup to reduce the amount
of change required, but no one stepped up to organize coders and
translators to see it the rest of the way through into CVS.
If we were to decide multi-language support  is a serious design goal
then I think we would have to either push back the version 5 timeline by
at least a year or set this as a target for, I suppose,  version 6.

So far the suggested list of version 5 targets contains only 
2 items that I see as requiring substantial coding time:
	* consistent support for bold/italic text
	* explicit dot/dash line attributes

In both cases I view the target for an rc1 snapshot as being core
support and documentation for appropriate new syntax. 
Implementing the new feature in individual terminal types can follow
later, just as we did when enhanced text was generalized to
non-postscript terminals, when the image plot styles were added,
and when rgb+alpha color support was added. 

	Ethan