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

Re: 16-bit versions of gnuplot doomed?

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

 
> I will leave the CVS version free of these complications for now, until
> the following question is settled: Is support for 16-bit machines (think:
> old lab PCs, "poor pupils", under-developed countries...) important enough
> to warrant changes as deep as these before the release?
> 
> I'll hands-up poll of any users of the 16-bit versions to the newsgroup to
> get some additional feedback.

 That would need to be done.

 I remember receiving email from a user (Nobel laureate in physics ...)
 a few years back, mentioning that he is using both DOS and Linux versions.

16-bit versions of gnuplot doomed?

[Hans-Bernhard B. <br...@ph...>]

Hello, all,

I've got round to trying to build 16-bit binaries of gnuplot for DOS and
Windows and the news, so far, is bad.

Win16 (i.e. good old Windows 3.1 and Windows for Workgroups 3.11) kills
itself directly on startup.  I may be blowing the stack or something ---
investigating that is a nightmare without at least a Win9x machine.

DOS-16bit works, sort of.  But that's after I disabled most of the bit
optional features (filled boxes, PM3D) *and* removed pretty much all
terminal drivers besides dospc (the interactive graphics driver), table
and cgm.  Yes, that does mean I had to throw out post.trm ;-( The reason
post.trm had to go is the PS_header[] string array.  This is simply too
large, and the way it's constructed (array of many short strings) means
that Borland's compiler, which is otherwise quite clever at squeezing a
lot of code into those 640KB, fails to move the bulk of it into a separate
segment.  As is, term.obj with post.trm in it costs 26000 of the total of
64 precious kilobytes of "dgroup".  I won't give up on this quite yet,
though.

The other major challenge is graphics.c, and it affects both 16-bit
platforms: that module is plain and simply too large.  BCC chokes already
on compiling that source file because it contains more than 64KB of code.  
Maybe I'm overlooking some optimization (the 32-bit graphics.o on Linux
has only 52KB...), but for the time being, I decided to tentatively split
graphics.c into two files: I copied all the "steps" plotting style handler
(plot_{f,hi,}steps) and their helper functions to a separate source file
and #ifdef'ed out their implementations in graphics.c.  The new files
steps2d.[ch] currently contain copies of the relevant parts of
graphics.[ch], but those may be replaced by #include'ing graphics.c if I
put even more #ifdef's into the latter.

I will leave the CVS version free of these complications for now, until
the following question is settled: Is support for 16-bit machines (think:
old lab PCs, "poor pupils", under-developed countries...) important enough
to warrant changes as deep as these before the release?

I'll hands-up poll of any users of the 16-bit versions to the newsgroup to
get some additional feedback.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Going over bugs before release...

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

> I was hoping for a more general solution, or rather a solution
> that would help all redrawing of all x11 plot windows.  The bigger
> problem is that the window is redrawn repeatedly during and
> after resizing. Having the individual redraws a bit slow is less of
> a concern than the fact that it may redraw 10 times when only
> 1 or 2 were really necessary.
>

Doesn't this depend on the window manager configuration ?

If the user has set the window manager to continuous redraws during resize,
then that's exactly what they want the behaviour to be. So the redraws
are not unnecessary.

 I seem to be setup to use rubber-banding during resizing, so I wouldn't expect
to get any intermediate redraws. (But maybe I misunderstood the problem.)


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Going over bugs before release...

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

> I was hoping for a more general solution, or rather a solution
> that would help all redrawing of all x11 plot windows.  The bigger
> problem is that the window is redrawn repeatedly during and
> after resizing. Having the individual redraws a bit slow is less of
> a concern than the fact that it may redraw 10 times when only
> 1 or 2 were really necessary.
>

Doesn't this depend on the window manager configuration ?

If the user has set the window manager to continuous redraws during resize,
then that's exactly what they want the behaviour to be. So the redraws
are not unnecessary.

 I seem to be setup to use rubber-banding during resizing, so I wouldn't expect
to get any intermediate redraws. (But maybe I misunderstood the problem.)


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Going over bugs before release...

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

> I was hoping for a more general solution, or rather a solution
> that would help all redrawing of all x11 plot windows.  The bigger
> problem is that the window is redrawn repeatedly during and
> after resizing. Having the individual redraws a bit slow is less of
> a concern than the fact that it may redraw 10 times when only
> 1 or 2 were really necessary.
>

Doesn't this depend on the window manager configuration ?

If the user has set the window manager to continuous redraws during resize,
then that's exactly what they want the behaviour to be. So the redraws
are not unnecessary.

 I seem to be setup to use rubber-banding during resizing, so I wouldn't expect
to get any intermediate redraws. (But maybe I misunderstood the problem.)


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Gnuplot and Octave.

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

> The question is whether Gnuplot is doing some housekeeping of curve-data
> (2D & 3D), and this is retrievable in an easy way.

I think gnuplot does some proprocessing on reading the data (especially if
you use "set log", or smoothing (?)), so the data may not be always
reproducible.

> It would be nice to be able to retrieve the curve_data which is
> visualised. That would be perfect.
>
> I know that Octave is able to use a gshow, which will list out properties
> as in show.  I believe I can get labels, ticks, colour and format, but not
> the curve_data, which could be quite useful....

You can get this functionality outside of gnuplot. Just after each plot from
your front-end, do "save 'plot1.gp'" -- and there you have access to all
properties of this plot, including the "plot" command listing the datafiles.
You just have to parse the file -- I think that's how Octave's "gshow"
currently works.

Maybe using mkfifo you don't need to touch the filesystem and keep all these
options as a string list in memory of your front-end.

---
PM

Re: splot can it do

[Andre R. <ar...@gw...>]

On Mon, 23 Feb 2004, kemal asad wrote:

> I am looking for a plotting application or library for 2D and 3D, data
> and function  representation.
> in my selection process i have establish that i want the application or
> library to have the ability  to do the following kind of graphs.
> z(x,y)=  5*cos(2*sqrt(x*x+y*y))*exp(-0.3*sqrt(x*x+y*y)).
> So the question is can gnuplot do this? yes yes how?
> thanks
> Kemal
>
>
yes, yes, yes, gnuplot can do this, ... .
just type:
z(x,y)=  5*cos(2*sqrt(x*x+y*y))*exp(-0.3*sqrt(x*x+y*y))
splot z(x,y)

regards and rtfm

Andre

splot can it do

[kemal a. <as...@cl...>]

I am looking for a plotting application or library for 2D and 3D, data
and function  representation.
in my selection process i have establish that i want the application or
library to have the ability  to do the following kind of graphs. 
z(x,y)=  5*cos(2*sqrt(x*x+y*y))*exp(-0.3*sqrt(x*x+y*y)).  
So the question is can gnuplot do this? yes yes how?
thanks
Kemal

Re: new Gnuplot web site

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

> Sorry, I missed the beginning of this thread.  Would you like this work
> to be integrated with the official http://www.gnuplot.info/ site

I propose the date when gnuplot 4.0 gets released, both webs should be
unified (redirect?).

Or maybe we can even do it now to get more attraction? May not be so bad
idea. Is it only index.html what's there? Then, it should become
index373.html to be saved for future.

> we spoke about it, we agreed that we would be happy if someone would
> take this up.  Alex Woo had done work long ago, but I don't think he has
> worked on the web page in a long time.

I think I took all the relevant info from gnuplot.info, so that site is no
longer needed.

---
Petr Mikulik

Re: Going over bugs before release...

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

On Monday 23 February 2004 05:48 am, Dave Denholm wrote:
> > With the patch applied there is no problem with colors, but any
> > x11 plot containing rotated text is refreshed very much slower.
> > This is in particular noticeable when you resize the plot window.
> > But speeding up window resizing is certainly not release-critical,
> > so we can address it later.
>
> what's the change, and why does it cause a slowdown ?

The previous code assumed that text/background pixel area could
be represented by a 1-bit deep array.  The array was rotated, and
then the entire rotated array was ORer back onto the original image
in one (relatively fast) operation.  The problem is that ORing the
background color is only harmless if it is represented by all zeros.
If it is anything else then the OR operation perturbs the existing
colors.

The new code explicitly tests for pixels in the rotated text box that
are non-background, and substitutes them back into the original
image one by one.  That is relatively slow.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center    (206)543-1421
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Going over bugs before release...

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

> On Monday 23 February 2004 05:48 am, Dave Denholm wrote:
>> > With the patch applied there is no problem with colors, but any
>> > x11 plot containing rotated text is refreshed very much slower.
>> > This is in particular noticeable when you resize the plot window.
>> > But speeding up window resizing is certainly not release-critical,
>> > so we can address it later.
>>
>> what's the change, and why does it cause a slowdown ?
>
> The previous code assumed that text/background pixel area could
> be represented by a 1-bit deep array.  The array was rotated, and
> then the entire rotated array was ORer back onto the original image
> in one (relatively fast) operation.  The problem is that ORing the
> background color is only harmless if it is represented by all zeros.
> If it is anything else then the OR operation perturbs the existing
> colors.
>
> The new code explicitly tests for pixels in the rotated text box that
> are non-background, and substitutes them back into the original
> image one by one.  That is relatively slow.
>


Yes, that's what I feared...

isn't the standard trick here to

first AND with bg = ~0, fg = reqd colour
then   OR with bg =  0, fg = reqd colour


true there may be an intermediate frame with the wrong foreground colour,
but it's usually not noticable.

dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: new Gnuplot web site

[Clark G. <ga...@di...>]

Petr Mikulik wrote:
>>Petr - Do you want to be the point person for changes to the web site,
>>or should it proceed by shared access as with the CVS tree itself?
> 
> Anyone can modify these new gnuplot's web pages, I hapilly claim no
> copyright for it (especially if it means less work for me!).

Sorry, I missed the beginning of this thread.  Would you like this work 
to be integrated with the official http://www.gnuplot.info/ site or are 
you working with Lars in that matter?  I can easily point the mirror 
elsewhere or we can update the master which Lars maintains.  Last time 
we spoke about it, we agreed that we would be happy if someone would 
take this up.  Alex Woo had done work long ago, but I don't think he has 
worked on the web page in a long time.

--ckg

Re: file permissions - Re: release plane for 4.0

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

> >From some strange reasons, I cannot touch files in subdirectories. I don't
> see what's wrong in file permissions... only in "demo/" directory I can
> write a file.
> 
> Can you please fix it?
> 
> If you are there, please move scr-new-petr/index.html into
> screenshots/index.html, and remove this directory.
 
 Done.

 Petr, you too need to take care that all files and directories you
 create are group-writable!

Re: new Gnuplot web site

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

> > At the bottom of the main page there is no link to demos amongst the
> > other links such as Home|Downloads|Screenshots, etc.
>
> Mike:
>
> 	The "Screenshots" link does actually take you via 1-hop to the
> the demo directory.  But yes, there could be a 1-click pointer on the
> main page as well.  Sounds reasonable to me.

I've added "Demo | ".
Will function when files/directories permissions are solved (needs to
rewrite screenshots/index.html.


BTW, I've put some links to German gnuplot sites -- can somebody review it
for the order of appearance?

Also, all French sites listed there are dead -- someone can google them?


> Petr - Do you want to be the point person for changes to the web site,
> or should it proceed by shared access as with the CVS tree itself?

Anyone can modify these new gnuplot's web pages, I hapilly claim no
copyright for it (especially if it means less work for me!).

---
pm

file permissions - Re: release plane for 4.0

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

>  Could you also please go through the permissions of all the files you created
>  (I have moved demo to demo.old, couldn't do much more with it), and make
>  sure that all directories are chmod 755 (maybe 775 is better), all files
>  are 664, and group ownership is always gnuplot. This will insure that all
>  developers in the gnuplot group have full access to all files.

From some strange reasons, I cannot touch files in subdirectories. I don't
see what's wrong in file permissions... only in "demo/" directory I can
write a file.

Can you please fix it?

If you are there, please move scr-new-petr/index.html into
screenshots/index.html, and remove this directory.

---
pm

Re: Going over bugs before release...

[Dave D. <dde...@es...>]

Ethan A Merritt <merritt@u.washington.edu> writes:

> On Sunday 22 February 2004 12:42 pm, Hans-Bernhard Broeker wrote:
>>
>> After going over those I marked one by one, there's currently only one
>> such bug left (X11 rotated text on unusual platforms...), which I've
>> assigned to Ethan, since he claimed at one point in time to have
>> reproduced the misbehaviour and understood the patch, too.
>
> I will apply the fix, but I remind you that there is a trade-off involved.
> The current bug can be described:
> 	"If you use a non-white background in the X11 terminal, then
> 	 rotated text may cause nearby elements to be drawn in the 
> 	 wrong color"
> I am not aware of any platform dependence. The bug is only 
> triggered by having a background color that is not pure white.
>
> With the patch applied there is no problem with colors, but any
> x11 plot containing rotated text is refreshed very much slower.
> This is in particular noticeable when you resize the plot window.
> But speeding up window resizing is certainly not release-critical,
> so we can address it later.
>


Sorry, I'm way out of date with gnuplot...

what's the change, and why does it cause a slowdown ?


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Going over bugs before release...

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

On Sunday 22 February 2004 12:42 pm, Hans-Bernhard Broeker wrote:
>
> After going over those I marked one by one, there's currently only one
> such bug left (X11 rotated text on unusual platforms...), which I've
> assigned to Ethan, since he claimed at one point in time to have
> reproduced the misbehaviour and understood the patch, too.

I will apply the fix, but I remind you that there is a trade-off involved.
The current bug can be described:
	"If you use a non-white background in the X11 terminal, then
	 rotated text may cause nearby elements to be drawn in the 
	 wrong color"
I am not aware of any platform dependence. The bug is only 
triggered by having a background color that is not pure white.

With the patch applied there is no problem with colors, but any
x11 plot containing rotated text is refreshed very much slower.
This is in particular noticeable when you resize the plot window.
But speeding up window resizing is certainly not release-critical,
so we can address it later.

> We won't release unless all bugs have either been resolved+closed, or we
> have agreed that they're not all that critical right at this time.  E.g. I
> personally don't consider lack of any optional feature by any terminal
> driver a critical bug that should delay the release.

Agreed.


-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Going over bugs before release...

[Hans-Bernhard B. <br...@ph...>]

Hello, everyone,

as your should have noticed from the flurry of status change mails that
went by on the gnuplot-developers mailing list (you *are* all subscribed
to that, aren't you?), I went over the currently open bugs and (rather
subjectively) selected those which I would consider release-criticial,
i.e. which really have to be settled one way or the other before we can
confidently claim to have a version worthy of being released to the
general public.

To keep track of which those bugs are, I added a "Group" called
"release_critical" in the bug tracker.  You can narrow down the view of
open bugs by selecting that from the drop-down menu.  If you consider any
of the existing bugs release-critical, you can mark them accordingly.

After going over those I marked one by one, there's currently only one
such bug left (X11 rotated text on unusual platforms...), which I've
assigned to Ethan, since he claimed at one point in time to have
reproduced the misbehaviour and understood the patch, too.

We won't release unless all bugs have either been resolved+closed, or we
have agreed that they're not all that critical right at this time.  E.g. I
personally don't consider lack of any optional feature by any terminal
driver a critical bug that should delay the release.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Gnuplot and Octave.

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

Hans-Bernhard Broeker wrote:

>On Fri, 20 Feb 2004, Daniel J Sebald wrote:
>
>[...]
>  
>
>>One small drawback though is that when the data reaches the point of 
>>gnuplot_x11 it has been translated to a new coordinate system. 
>>    
>>
>
>Not just translated, but projected, too.  I.e. the coordinates known
>to gnuplot_x11 are always 2D.  There's no way at all it could give
>back 3D data.
>

Oh yeah.  That too.

>But now that I look at the sources, it seems the 3D data are actually kept 
>around until the next 'plot', i.e. the only calls to the relevant routine
>sp_free() are in eval3d_plot() and when you change the 'samples' settings
>(for whatever that is supposed to achieve...)
>

My guess would be that sampling pertains to the sampling intervals of a 
internal math function so that if the user changes that it is assumed 
that the data inherently changes.

Dan

Re: Gnuplot and Octave.

[Hans-Bernhard B. <br...@ph...>]

On Fri, 20 Feb 2004, Daniel J Sebald wrote:

[...]
> One small drawback though is that when the data reaches the point of 
> gnuplot_x11 it has been translated to a new coordinate system. 

Not just translated, but projected, too.  I.e. the coordinates known
to gnuplot_x11 are always 2D.  There's no way at all it could give
back 3D data.

But now that I look at the sources, it seems the 3D data are actually kept 
around until the next 'plot', i.e. the only calls to the relevant routine
sp_free() are in eval3d_plot() and when you change the 'samples' settings
(for whatever that is supposed to achieve...)

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Gnuplot and Octave.

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

Ethan Merritt wrote:

>On Friday 20 February 2004 02:54 pm, Hans-Bernhard Broeker wrote:
>  
>
>>Not after the fact.  gnuplot does not generally keep plotted data in
>>memory after the plot has been drawn, so it can't report them back to
>>octave, either.  This kind of data copying would have to be done at the
>>octave end of the connection instead.  There's, again, an exception to
>>this, but it only applies to mouse-enabled versions, and then only to 3D
>>plots, IIRC.
>>    
>>
>
>Only 2D I think you mean?  The x11 mousing code stores the axis
>info so that it can translate mouse clicks into plot coordinates.
>But it only does such translation for 2D plots.
>
>The outboard x11 driver, gplt_x11, stores most of the plot information
>implicitly. It needs this anyway in order to continuously display plots,
>even old plots, on the screen. There is a code stub in
>gplt_x11.c just waiting to pass mousing events from prior windows
>back to external applications. But as of now it is commented out
>because we have no such interface defined.
>
>If some interested parties on both the gnuplot and octave side work
>to define such an interface, I believe it would not be a tremendous
>amount of work to export data on demand from gnuplot_x11 to an
>octave session.
>

One small drawback though is that when the data reaches the point of 
gnuplot_x11 it has been translated to a new coordinate system.  I 
suppose the translation can be reversed, but there will be some 
precision discrepancies.

Dan

Re: Gnuplot and Octave.

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

On Friday 20 February 2004 02:54 pm, Hans-Bernhard Broeker wrote:
>
> Not after the fact.  gnuplot does not generally keep plotted data in
> memory after the plot has been drawn, so it can't report them back to
> octave, either.  This kind of data copying would have to be done at the
> octave end of the connection instead.  There's, again, an exception to
> this, but it only applies to mouse-enabled versions, and then only to 3D
> plots, IIRC.

Only 2D I think you mean?  The x11 mousing code stores the axis
info so that it can translate mouse clicks into plot coordinates.
But it only does such translation for 2D plots.

The outboard x11 driver, gplt_x11, stores most of the plot information
implicitly. It needs this anyway in order to continuously display plots,
even old plots, on the screen. There is a code stub in
gplt_x11.c just waiting to pass mousing events from prior windows
back to external applications. But as of now it is commented out
because we have no such interface defined.

If some interested parties on both the gnuplot and octave side work
to define such an interface, I believe it would not be a tremendous
amount of work to export data on demand from gnuplot_x11 to an
octave session.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center    (206)543-1421
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Gnuplot and Octave.

[Hans-Bernhard B. <br...@ph...>]

On Fri, 20 Feb 2004, Ole Jacob Hagen wrote:

> I know Octave can get some parameters from gnuplot using gshow, which 
> will run show in Gnuplot.

But that's not exactly the easiest possible way.  "show" is meant for
consumption by humans, not computers.  The "save" command's output would 
be a lot better for that, I guess.  This writes out a complete script to 
generate the current plot (with the exception of multiplot stuff).

Note that some parameters actually used in the plot are neither in 'save'
nor in 'show' output.  The major examples are the margin sizes, legend
positioning and, most prominently, the actual axis range.  Unless mousing
is in use or you explicitly requested the "writeback" feature, the axis
range endpoints are not kept anywhere after the plot has been done.

> The question is whether Gnuplot is doing some housekeeping of curve-data 
> (2D & 3D), and this is retrievable in an easy way.

Not after the fact.  gnuplot does not generally keep plotted data in
memory after the plot has been drawn, so it can't report them back to
octave, either.  This kind of data copying would have to be done at the
octave end of the connection instead.  There's, again, an exception to 
this, but it only applies to mouse-enabled versions, and then only to 3D 
plots, IIRC.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Gnuplot and Octave.

[Arun P. <ape...@lb...>]

Hi,

Ole Jacob Hagen wrote:
> The question is whether Gnuplot is doing some housekeeping of curve-data 
> (2D & 3D), and this is retrievable in an easy way.
> 
> It would be nice to be able to retrieve the curve_data which is 
> visualised. That would be perfect.

not sure if gnuplot can do it already or if I misunderstood the question 
;), but it seams to me that all you need is a terminal that will output 
plot and splot data in text format (e.g. x/y/z values)... wouldn't 
"terminal table" work? Octave could parse the output and you would get 
the data back into octave...

HTH

Arun

Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

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

On Friday 20 February 2004 12:43 pm, Lars Hecking wrote:
> > I've updated the gnuplot.sourceforge.net/demo/ directory contents
> > also. They are now html 4.0.1 transitional compliant (well almost),
> > and can should even be viewable in broken browsers like IE5.
>
>  Could you also please go through the permissions of all the files you
> created (I have moved demo to demo.old, couldn't do much more with it),
> and make sure that all directories are chmod 755 (maybe 775 is better),
> all files are 664, and group ownership is always gnuplot. This will
> insure that all developers in the gnuplot group have full access to all
> files.

Done.  I thought that setting g+sw on the directory was sufficient,
but apparently not.  Sorry.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center    (206)543-1421
Mailstop 357742
University of Washington, Seattle, WA 98195