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

Re: Idea: env-mapping for dataplot over pipes

[Tino W. <ti...@wi...>]

Petr Mikulik schrieb:
>> what if it would be possible to map xrange, yrange, ..
>> settings into the environment where the external
>> command via popen is run? This way it would be easy
>> to just fetch and deliver only the amount of data
>> which is really in the display boundaries - for example
>> if you magnify parts of a measure log.
> 
> 
> Since very recently, you can
>     print GPVAL_X_MIN, GPVAL_X_MAX, GPVAL_Y_MIN, GPVAL_Y_MAX
> and let your driving application to read it. See also 'help set print' 
> and "bidirectional" examples on gnuplot web page.

But this looks as if my application would have to
run gnuplot in popen() and not vice versa?

Currently I run a number of scripts in plot
where each script delivers data for a part graph.

It would be nice to be able to access these values
from the script which runs inside

plot "<script"

or am I misunderstanding?

Regards
Tino

Re: Bug/Feature: cursor coordinates dont follow date/time style on axis

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

>> Hit hotkey '1' to change the mouse format (hit 'h' for help).
>> Then read 'help mouse' => mouseformat.
>> 
> Ah great! Thats why I saw code to format like this
> in the sources ;) Its hard to find if you dont know
> where to look, but now :-)

If you think it needs a change into docs, into FAQ, ... please contribute.

---
PM

Re: Idea: env-mapping for dataplot over pipes

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

> what if it would be possible to map xrange, yrange, ..
> settings into the environment where the external
> command via popen is run? This way it would be easy
> to just fetch and deliver only the amount of data
> which is really in the display boundaries - for example
> if you magnify parts of a measure log.

Since very recently, you can
 	print GPVAL_X_MIN, GPVAL_X_MAX, GPVAL_Y_MIN, GPVAL_Y_MAX
and let your driving application to read it. See also 'help set print' and 
"bidirectional" examples on gnuplot web page.

---
PM

Idea: env-mapping for dataplot over pipes

[Tino W. <ti...@wi...>]

Hi,

another idea that bugs me, maybe others would
find it usefull too:

what if it would be possible to map xrange, yrange, ..
settings into the environment where the external
command via popen is run? This way it would be easy
to just fetch and deliver only the amount of data
which is really in the display boundaries - for example
if you magnify parts of a measure log.

Bad idea?


Regards
Tino

Re: Bug/Feature: cursor coordinates dont follow date/time style on axis

[Tino W. <ti...@wi...>]

Petr Mikulik schrieb:
>> However if for example the xaxis is set to datetime,
>> the x-value of the crosshair-display is completely
>> nonsense (its always an fp-value around 2.04842e+08,
>> which probably represents epoch )
> 
> 
> Yes, it is epoch.
> 
>> A quick glance into the source does not yet show
>> me where I can easy fix it myself, but I'm still
>> trying ;)
> 
> 
> Hit hotkey '1' to change the mouse format (hit 'h' for help).
> Then read 'help mouse' => mouseformat.
> 
Ah great! Thats why I saw code to format like this
in the sources ;) Its hard to find if you dont know
where to look, but now :-)

Thx!
Tino

Re: Bug/Feature: cursor coordinates dont follow date/time style on axis

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

> However if for example the xaxis is set to datetime,
> the x-value of the crosshair-display is completely
> nonsense (its always an fp-value around 2.04842e+08,
> which probably represents epoch )

Yes, it is epoch.

> A quick glance into the source does not yet show
> me where I can easy fix it myself, but I'm still
> trying ;)

Hit hotkey '1' to change the mouse format (hit 'h' for help).
Then read 'help mouse' => mouseformat.

Hope this helps.

---
PM

Bug/Feature: cursor coordinates dont follow date/time style on axis

[Tino W. <ti...@wi...>]

Hi folks,

The following was meant for the sf bugtracker, but
the registration there didnt work, so I post it to
the list:


X11 driver has a cross-hair cursor to easy take points on the plot and read their value.

3rd mouse button can be used to draw the cross and coordinates permanently.

However if for example the xaxis is set to datetime,
the x-value of the crosshair-display is completely
nonsense (its always an fp-value around 2.04842e+08,
which probably represents epoch )

A quick glance into the source does not yet show
me where I can easy fix it myself, but I'm still
trying ;)


Regards
Tino Wildenhain

Re: pslatex.trm: useless \colorgray into tex file

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

On Tuesday 04 July 2006 07:45 pm, Ethan A Merritt wrote:
> > Can a pslatex.trm guru have a look?
> 
> That may be a side effect of this bugfix:
> 
>   2006-06-18  Ethan A Merritt  <merritt@u.washington.edu>
>         * term/emf.trm (EMF_linetype EMF_dashtype): It is necessary to set the

Never mind. I totally mis-read which terminal you were talking about.

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

Re: pslatex.trm: useless \colorgray into tex file

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

On Tuesday 04 July 2006 01:20 pm, Petr Mikulik wrote:
> Currently, "make tutorial" fails due to "TeX capacity exceeded".
> 
> Reason: try
>  	gnuplot eg7.plt
> 
> There seems to be a bug: EPSLATEX_set_color() produces many many 
> \colorgray{} commands into output .tex file, which are completely useless, 
> because color for filled rectangles is set directly in .eps file.
> 
> Can a pslatex.trm guru have a look?

That may be a side effect of this bugfix:

  2006-06-18  Ethan A Merritt  <merritt@u.washington.edu>
        * term/emf.trm (EMF_linetype EMF_dashtype): It is necessary to set the
        line color and dash type every time either is changed.
        Bugfix.

I'll have another look at it.

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

Re: pslatex.trm: useless \colorgray into tex file

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

Daniel J Sebald wrote:
> Petr Mikulik wrote:
> 
>>Currently, "make tutorial" fails due to "TeX capacity exceeded".
>>
>>Reason: try
>> 	gnuplot eg7.plt
>>
>>There seems to be a bug: EPSLATEX_set_color() produces many many 
>>\colorgray{} commands into output .tex file, which are completely useless, 
>>because color for filled rectangles is set directly in .eps file.
> 
> 
> Another question is why does the following line, attributable to EPSLATEX_linetype(int linetype), appear so often in a row:
> 
>       \csname LT0\endcsname

This probably falls in the category of setting line types, palettes, etc more than necessary in the core.  There appears to be no accepted strategy in the README files about this sort of thing.  But there are two approaches to take:

1) In the core, only change settings in the terminal when necessary.  If the terminal needs to reuse or reissue such information like palette (a bug and all its consequences that Ethan and I looked at in the PostScript terminal), then it should save that information and recall it.

2) In the core, ensure the terminal is properly set by resending information before a plot action even if it hasn't changed.  The terminal driver's job is then, at least in the case of PostScript, to weed out all the extraneous calls, e.g., if the _linetype() function is called and the line type is the same as previous, then do not put a PostScript command in the file.

We've seen this issue crop up several times now.  Personally, I'd prefer approach #1 to be the accepted strategy.  The less "traffic" the better.  It's a bit of a danger to mess with this before 4.2 in the core.

In fact, I'm wondering, is there someone taking the lead on the PostScript, combined PS/LatTeX, etc?  This used to be fairly well organized, but looking into the problem that Petr reports, I find a couple things.

One, here is the linetype function in pslatex:

TERM_PUBLIC void
EPSLATEX_linetype(int linetype)
{
    PS_linetype(linetype);

    if (gpoutfile) {
        /* from PS_linetype, should better not be used in twice
         * in source code */
        if (ps_params->oldstyle)
            linetype = (linetype % 4) + 3;
        else
            linetype = (linetype % 9) + 3;
        if (linetype < 0)       /* LT_NODRAW, LT_BACKGROUND, LT_UNDEFINED */
            linetype = 0;
	fprintf(gpoutfile,"      \\csname LT%c\\endcsname\n",
		"wba012345678"[linetype]);
    }
}

which calls PS_linetype(linetype), and that linetype function inside post.trm looks almost identical:

TERM_PUBLIC void
PS_linetype(int linetype)
{
    if ((ps_params->terminal == PSTERM_EPSLATEX) && ps_params->oldstyle)
	linetype = (linetype % 4) + 3;
    else
	linetype = (linetype % 9) + 3;
    if (linetype < 0)	/* LT_NODRAW, LT_BACKGROUND, LT_UNDEFINED */
	linetype = 0;
    PS_relative_ok = FALSE;

#if 0
    /*  In order to make 'PS_linewidth' work properly, I need to comment
     *  this line out.  Especially in combination with the line width
     *  extension of the `set arrow` command this is necessary.
     *  Can we live with that drawback?  (JFi)
     */
    if (PS_linetype_last == linetype) return;
#endif

    /* HBB 20031219: use PS_FLUSH_PATH! */
    /* PS_relative_ok = FALSE; */
    PS_FLUSH_PATH;

    PS_linetype_last = linetype;
    fprintf(gppsfile, "LT%c\n", "wba012345678"[linetype]);
    ps_path_count = 0;
}

I really wish that the practice of code reuse were implemented here, so there is only need to maintain one "functional" hunk of code.  I.e., create a function that has an output file pointer as an argument and call it twice with different output file pointers.

Two, you can see where the above is leading.  In the post.trm version of the routine is the  line

    if (PS_linetype_last == linetype) return;

which effectively "weeds out" repetitive calls to the routine when parameters don't actually change.  Naturally, there needs to be a similar thing in the pslatex.trm version.

But, even still, this "weed out" conditional is currently commented out in the post.trm version, with an explanation that seems more conjecture than anything else.  This is really the kind of thing that should be tossed to the discussion list and resolved before being moved into the CVS tree.

Although this looks to be a not-too-difficult fix, I think I'll pass on this one.

Dan

Re: pslatex.trm: useless \colorgray into tex file

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

Petr Mikulik wrote:
> Currently, "make tutorial" fails due to "TeX capacity exceeded".
> 
> Reason: try
>  	gnuplot eg7.plt
> 
> There seems to be a bug: EPSLATEX_set_color() produces many many 
> \colorgray{} commands into output .tex file, which are completely useless, 
> because color for filled rectangles is set directly in .eps file.

Another question is why does the following line, attributable to EPSLATEX_linetype(int linetype), appear so often in a row:

      \csname LT0\endcsname

Dan

pslatex.trm: useless \colorgray into tex file

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

Currently, "make tutorial" fails due to "TeX capacity exceeded".

Reason: try
 	gnuplot eg7.plt

There seems to be a bug: EPSLATEX_set_color() produces many many 
\colorgray{} commands into output .tex file, which are completely useless, 
because color for filled rectangles is set directly in .eps file.

Can a pslatex.trm guru have a look?

---
PM

Re: calling all computers, 4.2 odds and ends

[James R. V. Z. <jr...@co...>]

>   3) Please ask Jim Van Zandt if his 'bivariat.dem' patch is ready.
>      There are currently some quite inaccurate plots in the CVS
>      version of that demo.

As far as I'm concerned, the version I just posted can go in.

                - Jim Van Zandt

show derivative of the graph

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

FYI: I've fixed that polar coordinates (distance between ruler and mouse 
cursor) are displayed also for log and semilog plots.

In addition, hitting hotkey '5' three times flips polar coordinates format 
among
    off / (distance,angle) / (distance,tangent)

(until now there were only the first two) => and that's how you can find
easily tangents of your curves:

- e.g. plot x*x
- put cursor on the curve and hit 'r'
- put cursor on the curve close to ruler and hit twice '5'

Hope this helps,
   PM

Re: Mouse support on 4.1 on Windows fails

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

>>>> on gnuplot 4.1 (patchlevel 0 from March 2006) on a windows PC does not
>>>> appear to work. A small window pops up, but there are no OK of Cancel
>>>> buttons.
>>
>>> What really does not work is
>>>         pause mouse key
>>> and
>>>         pause mouse any
>>> while pressing a key.
>>> This is a bug.

Well, the simplest commands to reproduce this bug of Windows gnuplot are:

 	plot x
 	pause mouse; plot 1/x

It works OK on X11.
Someone knows to fix it?

---
PM

Re: Build problem

[Juergen W. <wie...@fr...>]

On Thursday 29 June 2006 00:29 Timoth=E9e Lecomte wrote:
> > wiefer@localhost:~> rpm -qa |grep -i cairo
>
> That will be the main issue (once you solved your pkg-config problem) to
> compile the wxWidgets terminal. If you really want to try it, you will
> have to compile cairo from source (it has no dependency - at least none
> of them is required for the wxWidgets terminal), and probably pango too,
> unless you upgrade to suse 10.

I have compiled and installed cairo-1.2.0 and pango-1.10.4.  The
newest version of pange needs a more recent version of glib.

> > wiefer@localhost:~> rpm -qa |grep -i wx
> > wxGTK-2.5.3.1-5
> > wxGTK-gl-2.5.3.1-5
> > wxGTK-compat-2.5.3.1-5
> > wxGTK-devel-2.5.3.1-5
>
> Well, these are outdated (and by the way 2.5.x are development versions)
> but they may be enough for the wxWidgets terminal.

I just tried.  The ./configure script went fine.  But during
compile, I got:

wxterminal/wxt_gui.cpp: In member function `void
   wxtPanel::DrawToDC(wxWindowDC&, wxRegion&)':
wxterminal/wxt_gui.cpp:588: error: no matching function for call to `
   wxBufferedDC::Init(wxWindowDC*)'
/usr/include/wx-2.5/wx/dcbuffer.h:60: error: candidates are: void
   wxBufferedDC::Init(wxDC*, const wxBitmap&)
/usr/include/wx-2.5/wx/dcbuffer.h:69: error:                 void
   wxBufferedDC::Init(wxDC*, const wxSize&)

This is just for your information.  I think I can live without the
wxterminal until the next operating system update.  Though it really
sounds to be a cool feature. :-)

Juergen

pause mouse key on Windows

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

There is a bug reported: the following two commands

         pause mouse key
         pause mouse any

while pressing a key on the graph are not working on Windows.
Could someone fix it?

---
PM

Re: missing binary flag for demo.edf

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

Ethan Merritt wrote:
> On Friday 30 June 2006 10:15 am, Daniel J Sebald wrote:
> 
>>Leaving image.dem as ASCII may be safe.
> 
> 
> I've just flagged it as binary.  I guess we'll see if there are
> any complaints.
> 
> 
>>Maybe there is something '| < blutux.rgb' that could be used that
>>would work in both Linux and Windows?  Suggestions?
> 
> 
> It was my understanding that only certain flavors of Windows build
> understood pipes.  So I don't think this is possible in general.
> But I also don't think it is an important part of the demo.
> We explain pipes and piped input in other places, and I don't see
> anything very special about this place in particular.

Mainly to illustrate that it works for binary data as well as ASCII, which is a big use in my mind.  (I.e., that your bigger application can pipe binary data across to gnuplot.)  And, of course, for having an example in the demos for purposes of verification when testing gnuplot...

I suppose this example wouldn't exactly have to be under "image", but that is the way things evolve, I guess.  Speaking of which, probably the text below can be removed from image.dem.  There is nothing uniqe about image.dem as far as knowing how to set an output terminal.  Although, it is nice to have that reminder of set output '| display png:-'".

Dan

Re: missing binary flag for demo.edf

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

On Friday 30 June 2006 10:15 am, Daniel J Sebald wrote:
> Leaving image.dem as ASCII may be safe.

I've just flagged it as binary.  I guess we'll see if there are
any complaints.

> Maybe there is something '| < blutux.rgb' that could be used that
> would work in both Linux and Windows?  Suggestions?

It was my understanding that only certain flavors of Windows build
understood pipes.  So I don't think this is possible in general.
But I also don't think it is an important part of the demo.
We explain pipes and piped input in other places, and I don't see
anything very special about this place in particular.

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

Re: missing binary flag for demo.edf

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

Ethan Merritt wrote:
> On Friday 30 June 2006 12:10 am, Daniel J Sebald wrote:
> 
>>Bastian Maerkisch wrote:
>>
>>>I am having problems with image.dem from CVS on OS/2. It aborts
>>>with:
>>>
>>>Damaged EDF header of demo.edf: not multiple of 512 B.
>>>
>>>Is this another case of a missing binary tag? Or is my
>>>cvs screwing up?
>>
>>Could be.  That clearly sounds like something wrong with the file. 
>>The file size I have here is 17408 bytes.  Is that what you are
>>seeing?
> 
> 
> In fact, the file "image.dem" itself also contains in-line binary
> data and may possibly cause problems.
> 
> Does anyone know of possible harm done by marking a file in cvs
> as "binary"?  
> If not, I think we should flag both demo.edf and image.dem

Well, the harm, if any, would be to Windows users.  I'm guessing most editors and applications these days handle that.  The question is whether gnuplot can handle the absence of a CR or LF character (I forget which), i.e., the underlying C function.

Leaving image.dem as ASCII may be safe.  It is a short little string of characters that is in binary.  So long as there is no CR-LF values in the string, most likely we'd be fine.  Here are the characters:

00 00 00 00  00 00 00 00  00 00 00 3F  00 00 00 00
00 00 00 3F  00 00 00 00  00 00 00 00  00 00 00 3F
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 3F
00 00 00 02  02 00 02 02

CR is 0D and LF is 0A, so it should be safe.

But, perhaps you can suggest a technique for using actual piping, since you know that so well.  Here is the command

plot '-' binary endian=little array=2x2 dx=2 format="%float" using 1:2:3 with rgbimage,\
     '-' binary endian=little record=4 format="%char" using 1:2 with points pt 7 ps 2 lt -1

Maybe there is something '| < blutux.rgb' that could be used that would work in both Linux and Windows?  Suggestions?

Dan

Re: missing binary flag for demo.edf

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

On Friday 30 June 2006 12:10 am, Daniel J Sebald wrote:
> Bastian Maerkisch wrote:
> > I am having problems with image.dem from CVS on OS/2. It aborts
> > with:
> >
> > Damaged EDF header of demo.edf: not multiple of 512 B.
> >
> > Is this another case of a missing binary tag? Or is my
> > cvs screwing up?
>
> Could be.  That clearly sounds like something wrong with the file. 
> The file size I have here is 17408 bytes.  Is that what you are
> seeing?

In fact, the file "image.dem" itself also contains in-line binary
data and may possibly cause problems.

Does anyone know of possible harm done by marking a file in cvs
as "binary"?  
If not, I think we should flag both demo.edf and image.dem


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

Re: GPVAL_VERSION

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

>> The "GPVAL_ variables" patch has been committed ... now I think that might
>> be useful to add also the following two automatic variables (floats):
>>
>> GPVAL_VERSION = 4.2
>> GPVAL_PATCHLEVEL = 0
>
> If possible, tie this variable together with the number printed at startup:

yes, the committed patch uses atof(gnuplot_version) and 
atoi(gnuplot_patchlevel), respectively

---
PM

Re: missing binary flag for demo.edf

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

Bastian Maerkisch wrote:
> I am having problems with image.dem from CVS on OS/2. It aborts with:
> 
> Damaged EDF header of demo.edf: not multiple of 512 B.
> 
> Is this another case of a missing binary tag? Or is my
> cvs screwing up?

Could be.  That clearly sounds like something wrong with the file.  The file size I have here is 17408 bytes.  Is that what you are seeing?

> 
> Btw. The list of terminals supporting images at the beginning
> of image.dem could be extended a little.

Meaning that there are now more terminals that support images than is listed?

Maybe we should get rid of that note at this point.

Dan

missing binary flag for demo.edf

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

I am having problems with image.dem from CVS on OS/2. It aborts with:

Damaged EDF header of demo.edf: not multiple of 512 B.

Is this another case of a missing binary tag? Or is my
cvs screwing up?

Btw. The list of terminals supporting images at the beginning
of image.dem could be extended a little.

Bastian

Re: GPVAL_VERSION

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

Petr Mikulik wrote:
> The "GPVAL_ variables" patch has been committed ... now I think that might 
> be useful to add also the following two automatic variables (floats):
> 
> now:
> GPVAL_VERSION = 4.1
> GPVAL_PATCHLEVEL = 0
> 
> then:
> GPVAL_VERSION = 4.2
> GPVAL_PATCHLEVEL = 0
> 
> Any opinion why not to add them?

If possible, tie this variable together with the number printed at startup:

        G N U P L O T
        Version 4.1 patchlevel 0

Dan