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

Re: no duplicated lines for GNU readline history

[Lars H. <lhe...@us...>]

Petr Mikulik writes:
> Gnuplot's own readline does not keep duplicated lines in the history, so 
> browsing the command line is much faster than with GNU readline. Does 
> someone know whether the latter can be switched to behave the same way?

File: readline.info,  Node: Completion Variables,  Next: A Short Completion Example,  Prev: Completion Functions,  Up: Custom Completers
                                                                                
Completion Variables
--------------------
..
 - Variable: int rl_ignore_completion_duplicates
     If non-zero, then duplicates in the matches are removed.  The
     default is 1.
..

no duplicated lines for GNU readline history

[Petr M. <mi...@ph...>]

Gnuplot's own readline does not keep duplicated lines in the history, so 
browsing the command line is much faster than with GNU readline. Does 
someone know whether the latter can be switched to behave the same way?

---
PM

Re: confirming X behavior

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 24 May 2006 03:12 pm, Daniel J Sebald wrote:
>
> I think I see where the dashed lines are coming from.  When I go back
> now to an older version of gnuplot the lines are coming out as
> dashes.

Are you remembering to set GNUPLOT_DRIVER_DIR to the appropriate
directory when testing new/old versions?  Mixing different versions
of gnuplot and gnuplot_x11 will yield poorly-defined behaviour.

> It has been for the longest time that these were solid lines.
> (I don't know, maybe they were supposed to be dashed all along.)

For a long time the behavior has been that x11.trm didn't know
anything about dashes, while gnuplot_x11 would use dashes if they
were provided as X resources and solid lines otherwise.
I have added an explicit toggle for solid/dashed to x11.trm,
just as other drivers like post.trm and emf.trm have.  The default
state of the toggle is "solid", which is what you always had before
unless you loaded dashed line descriptions into the X resources
database. So...

Before:
    - Default was dashed lines, but only if they are in Xresources
    - No Xresources file unless you created your own
    -> result was default to solid
Now:
    - Default is solid lines
    - Xresources file defines the dash patterns
    -> result is default to solid

> Does the most recent gnuplot installation create or overwrite an
> .Xdefaults file?

No

> And still, there is the issue that the axis line is not solid in the
> latest CVS where the default seemed to be dashed line before.

The axis line is supposed to be an exception (dotted even when the
other line types are solid).  It is possible that there is a bug in
that it gets disabled along with the other dash types. I'll check.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: confirming X behavior

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

Ethan Merritt wrote:
> On Wednesday 24 May 2006 02:42 pm, Daniel J Sebald wrote:
> 
>>Ethan Merritt wrote:
>>
>>>Have you tried out the dashed lines?
>>
>>Funny you should say, because I'm investigating right now.  In some
>>cases I'm seeing dashed lines for the axis, sometimes not.  (See
>>attached.)  Sometimes the plots themselves now have dashed blue and
>>purple lines (but solid red), sometimes not.  I think my running as
>>superuser in one window and not-superuser in another may be what is
>>going on.
> 
> 
> I can't think why being superuser should make a difference per se.
> You may have different initialization files in the respective
> login directories, but the X resources are a property of the server
> rather than the individual user.  So unless your two windows are
> somehow using two different X servers, they should act the same.
> 
> That's a different question from logging out and then logging in
> again as a different user.  In that case you may load a different
> set of X resources into the server during login.

I think I see where the dashed lines are coming from.  When I go back now to an older version of gnuplot the lines are coming out as dashes.  (Newer versions have solid lines.)  It has been for the longest time that these were solid lines.  (I don't know, maybe they were supposed to be dashed all along.)

Does the most recent gnuplot installation create or overwrite an .Xdefaults file?

And still, there is the issue that the axis line is not solid in the latest CVS where the default seemed to be dashed line before.

Dan

Re: confirming X behavior

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 24 May 2006 02:42 pm, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> > Have you tried out the dashed lines?
>
> Funny you should say, because I'm investigating right now.  In some
> cases I'm seeing dashed lines for the axis, sometimes not.  (See
> attached.)  Sometimes the plots themselves now have dashed blue and
> purple lines (but solid red), sometimes not.  I think my running as
> superuser in one window and not-superuser in another may be what is
> going on.

I can't think why being superuser should make a difference per se.
You may have different initialization files in the respective
login directories, but the X resources are a property of the server
rather than the individual user.  So unless your two windows are
somehow using two different X servers, they should act the same.

That's a different question from logging out and then logging in
again as a different user.  In that case you may load a different
set of X resources into the server during login.



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: confirming X behavior

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

Ethan Merritt wrote:

> Any others?  Have you tried out the dashed lines?
> They were always there, but up until now there has been no
> convenient way to turn them on.

Funny you should say, because I'm investigating right now.  In some cases I'm seeing dashed lines for the axis, sometimes not.  (See attached.)  Sometimes the plots themselves now have dashed blue and purple lines (but solid red), sometimes not.  I think my running as superuser in one window and not-superuser in another may be what is going on.

Dan

Re: confirming X behavior

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 24 May 2006 02:24 pm, Daniel J Sebald wrote:
> Just confirming a change/bug-fix here.  I'm guessing it is Ethan's
> 2006-05-20 change "New X resources file..." that now causes the
> gnuplot X window to appear white on my system as opposed to gray. 

Hmm. That is possible, but if so then your system is configured
differently than mine.  My system does not load such files 
automatically; only on request.  On the other hand, I have the gnuplot
background set to white anyhow, so that particular change I wouldn't
have noticed.

I view such files more as documentation than anything else.
You can browse the file to see what X resource options are available.
As I said, they aren't actually read in and executed on my systems.

> Also, the gnuplot window no longer comes to the top,
> by default, whenever a plot command is executed.

That would be the line
  gnuplot*raise:        off

The principle of least surprise suggests that maybe I should
either flip this to 'on' or comment out the line.  Thanks for
reporting the issue.

Any others?  Have you tried out the dashed lines?
They were always there, but up until now there has been no
convenient way to turn them on.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

confirming X behavior

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

Just confirming a change/bug-fix here.  I'm guessing it is Ethan's 2006-05-20 change "New X resources file..." that now causes the gnuplot X window to appear white on my system as opposed to gray.  (Fine with me.)  Also, the gnuplot window no longer comes to the top, by default, whenever a plot command is executed.

Dan

Re: unlog min,max for axis

[Petr M. <mi...@ph...>]

>> I've expressed a need for unlogged values in the axis structure. 
>
> At which point during run time?  If it's for GPVAL_ usage, I don't see how 
> later 'set' commands could get in the way of accessing the is_log or log_base 
> fields in struct axis before returning from (s)plot to the command() loop, to 
> update GPVAL_ values.

Just after the plot. Same place where the "writeback" values are set.

---
PM

Re: unlog min,max for axis

[<br...@ph...>]

Petr Mikulik wrote:

> I've expressed a need for unlogged values in the axis structure. 

At which point during run time?  If it's for GPVAL_ usage, I don't see 
how later 'set' commands could get in the way of accessing the is_log or 
log_base fields in struct axis before returning from (s)plot to the 
command() loop, to update GPVAL_ values.

unlog min,max for axis

[Petr M. <mi...@ph...>]

 	Hello Hans-Bernhard,

in the GPVAL_ patch,

http://sourceforge.net/tracker/index.php?func=detail&aid=1488448&group_id=2055&atid=302055

I've expressed a need for unlogged values in the axis structure. That would 
help both mousing and the GPVAL_ patch: currently gnuplot axis keeps min,max 
from the previous graph but it is not known whether it was log or not 
because the log base of the axis structure changes with the "set" command.

I propose to add these field to axis:
 	graph_min, graph_max
 	graph_base

Thanks,
   Petr

Re: gnuplot manual misprint (no.20)

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

Shigeharu TAKENO wrote:
> diff -u term-org/win.trm term/win.trm
> --- term-org/win.trm	Mon May 22 13:38:20 2006
> +++ term/win.trm	Mon May 22 17:31:59 2006
> @@ -893,7 +893,7 @@
>  " Syntax:",
>  "       set terminal windows {color | monochrome}",
>  "                            {enhanced | noenhanced}",
> -"			     {{font} \"fontname{,fontsize}\" {<fontsize>}}",
> +"                            {{font} \"fontname{,fontsize}\" {<fontsize>}}",
>  "",
>  " where `color` and `monochrome` select colored or mono output,", 
>  " `enhanced` enables enhanced text mode features (subscripts,",

This one has already been corrected by Hans-Bernhard Broecker.

Re: gnuplot manual misprint (no.20)

[<tim...@en...>]

> On Monday 22 May 2006 02:04 am, Shigeharu TAKENO wrote:
>>
>> I found a point that seems to be a misprint. I send the unified
>> diff file for them.
>
> Thank you.

Yes, thank you.
>
>> I also think that the entry "$(T)wxt.trm" should be added to the
>> variable CORETERM in docs/Makefile.in.
>
> Probably.

I will do that.

>> @@ -326,11 +326,11 @@
>>  " translate character codes to their utf-8 counterparts, and it will
>> use", " your current font instead of Symbol.",
>>  " However, this will not work with other non conform fonts, such
>> as", -" \"windings\". These fonts may not appear at all."
>> +" \"windings\". These fonts may not appear at all.",
>>  "",
>
> Actually, that sentence should just be deleted.  The current terminal
> does in fact work with Wingdings and at least some other non-conforming
> fonts.

I just commited the typo corrections for wxt.trm . I will check soon with
different versions of pango to see how it works with the fonts, and will
update this help message accordingly.

By the way, I will add an $Id$ line to the wxWidgets terminal files,
thanks again Shigeharu for mentioning that.

Best regards,

Timoth=E9e

Re: gnuplot manual misprint (no.20)

[Ethan M. <merritt@u.washington.edu>]

On Monday 22 May 2006 02:04 am, Shigeharu TAKENO wrote:
>
> I found a point that seems to be a misprint. I send the unified
> diff file for them.

Thank you.

> I also think that the entry "$(T)wxt.trm" should be added to the
> variable CORETERM in docs/Makefile.in.

Probably.

> @@ -326,11 +326,11 @@
>  " translate character codes to their utf-8 counterparts, and it will
> use", " your current font instead of Symbol.",
>  " However, this will not work with other non conform fonts, such
> as", -" \"windings\". These fonts may not appear at all."
> +" \"windings\". These fonts may not appear at all.",
>  "",

Actually, that sentence should just be deleted.  The current terminal
does in fact work with Wingdings and at least some other non-conforming
fonts.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Information about SF CVS services

[<br...@ph...>]

Mojca Miklavec wrote:
> Some other projects on sourceforge switched to SVN. Would this be the
> solution to non-working CVS perhaps?

I really don't think so.  SVN has its merits, sure, but I don't see us 
needing any of those badly enough to migrate just like that.

Re: continuation at end of comment?

[<br...@ph...>]

Daniel J Sebald wrote:

> OK, I see that now.  This means that if I temporarily want to comment 
> out a line, I must check for a backslash at the end of it as well.  A 
> bit cumbersome.

Actually, no.  If you want to comment out a line, you'll want to comment 
out a command, right?  The existing code achieves exactly that, even if 
the command spreads over multiple lines.

Re: Information about SF CVS services

[Ethan M. <merritt@u.washington.edu>]

On Monday 22 May 2006 09:44 am, Mojca Miklavec wrote:
> Some other projects on sourceforge switched to SVN. Would this be the
> solution to non-working CVS perhaps?

As I understand it, the SourceForge problems have been hardware
failures.  I don't think it has anything to do with whether the
disk arrays that died happened to contain cvs or svn files.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: continuation at end of comment?

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

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> Does the fact that a continuation character at the end of a comment=20
>> cause the next line to also be treated as a comment agree, disagree,=20
>> or not-conflict with the documentation.
>=20
>=20
> Agree with it --- see 'help introduction'

OK, I see that now.  This means that if I temporarily want to comment out=
 a line, I must check for a backslash at the end of it as well.  A bit cu=
mbersome.

Dan

Re: Information about SF CVS services

[Mojca M. <moj...@gm...>]

Some other projects on sourceforge switched to SVN. Would this be the
solution to non-working CVS perhaps?

Mojca

Re: Information about SF CVS services

[Aapo L. <aap...@gm...>]

On Fri, 2006-05-12 at 16:39 +0200, Hans-Bernhard Bröker wrote:
> We'll also all have to update our working directories to reflect this, 
> again.  SF only mentions  scrapping your working copy and checking out 
> fresh.  You may want to give the cvsutils package a try instead.  It 
> contains a nifty little tool "cvschroot" to do this. Or, if you're more 
> adventurous, just edit the CVS/Root files manually.

The following BASH one-liner (run in my local gnuplot working copy
directory) worked for me; however, YMMV:

for i in `find . -iname Root | grep CVS`; do mv $i $i.old; sed -e 's/cvs\.sourceforge/gnuplot\.cvs.sourceforge/' $i.old >$i; done

Best Regards,
Aapo Lankinen

Re: X Resources file for x11 terminal

[Lars H. <lhe...@us...>]

> >And is there a way to have the autoconfigure
> >tools figure out where such files are kept on the
> >system so that it can be installed?  
> 
> Environment variables XUSERFILESEARCHPATH, APPLRESDIR, XFILESEARCHPATH
> control this (--> 'man X'), otherwise it'll be next to the library and 
> include paths found by autoconf macro AC_PATH_X.
 
 I would give it the same treatment as the LaTeX files - put a copy of it
 into $(prefix)/share/gnuplot/<version>.

Re: z_floor and z_ceiling (was Re: various observations)

[<br...@ph...>]

Daniel J Sebald wrote:
> Hans-Bernhard Bröker wrote:

> I will disallow "unset xyplane" for now in the patch, unless you think 
> "unset xyplane" should be documentated instead.

I think I would slightly prefer it to be documented as a no-op.

Re: continuation at end of comment?

[<br...@ph...>]

Daniel J Sebald wrote:

> Does the fact that a continuation character at the end of a comment 
> cause the next line to also be treated as a comment agree, disagree, or 
> not-conflict with the documentation.

Agree with it --- see 'help introduction'

gnuplot manual misprint (no.20)

[Shigeharu T. <sh...@ie...>]

shige 05/22 2006
----------------

In term/wxt.trm and term/win.trm:

 * $Id: win.trm,v 1.47 2006/05/14 14:09:25 broeker Exp $
 (wxt had no line for $Id$)

I found a point that seems to be a misprint. I send the unified
diff file for them.

I also think that the entry "$(T)wxt.trm" should be added to the 
variable CORETERM in docs/Makefile.in.

----- From here -----
diff -u term-org/wxt.trm term/wxt.trm
--- term-org/wxt.trm	Mon May 22 13:38:15 2006
+++ term/wxt.trm	Mon May 22 17:35:05 2006
@@ -264,7 +264,7 @@
 "?set terminal wxt",
 "?wxt",
 " The `wxt` terminal device generates output in a separate window. The window ",
-" created by the wxWidgets library, where the 'wxt' comes from.",
+" is created by the wxWidgets library, where the 'wxt' comes from.",
 " The actual drawing is done via cairo, a 2D graphics library.",
 " Text is handled by pango, a library for laying out and rendering text.",
 "",
@@ -296,7 +296,7 @@
 "",
 " This terminal supports an enhanced text mode, which allows font",
 " and other formatting commands (subscripts, superscripts, etc.)",
-" to be embedded in labels and other text strings."
+" to be embedded in labels and other text strings.",
 " The enhanced text mode syntax is shared with other gnuplot",
 " terminal types. See `enhanced` for more details.",
 "",
@@ -326,11 +326,11 @@
 " translate character codes to their utf-8 counterparts, and it will use",
 " your current font instead of Symbol.",
 " However, this will not work with other non conform fonts, such as",
-" \"windings\". These fonts may not appear at all."
+" \"windings\". These fonts may not appear at all.",
 "",
 " The rendering of the plot can be done in several ways.",
-" It can be altered with a dialog available from the toolbar."
-" To obtain the best output possible, the rendering involves three"
+" It can be altered with a dialog available from the toolbar.",
+" To obtain the best output possible, the rendering involves three",
 " mechanisms : antialiasing, oversampling and hinting.",
 " Antialiasing allows to display non-horizontal and non-vertical lines",
 " smoother.",
diff -u term-org/win.trm term/win.trm
--- term-org/win.trm	Mon May 22 13:38:20 2006
+++ term/win.trm	Mon May 22 17:31:59 2006
@@ -893,7 +893,7 @@
 " Syntax:",
 "       set terminal windows {color | monochrome}",
 "                            {enhanced | noenhanced}",
-"			     {{font} \"fontname{,fontsize}\" {<fontsize>}}",
+"                            {{font} \"fontname{,fontsize}\" {<fontsize>}}",
 "",
 " where `color` and `monochrome` select colored or mono output,", 
 " `enhanced` enables enhanced text mode features (subscripts,",
----- To here ----- 

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

continuation at end of comment?

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

The documentation for comments says:

 Comments are supported as follows: a `#` may appear in most places in a line
 and `gnuplot` will ignore the rest of the line.  It will not have this effect
 inside quotes, inside numbers (including complex numbers), inside command
 substitutions, etc.  In short, it works anywhere it makes sense to work.

Does the fact that a continuation character at the end of a comment cause the next line to also be treated as a comment agree, disagree, or not-conflict with the documentation.

I.e.,

# comment \
plot x

will not create a plot.

Dan