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

Re: gnuplot needs more developers/administrators

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

Yes, here it works in such a way that someone wishing to push his feature 
into gnuplot is becoming a developer... and that one with many patches has a 
right to cvs ... Daniel, just you haven't wished so.

> -few people have CVS commit rights

For pushing a feature, from time to time we "ask" on this mailing list what 
to submit now from the Patches. So someone must be active to push...

> -gnuplot isn't eye-candy, so it doesn't make the crowd crazy. The target 
> audience is quite heavily restricted to scientists, programmers and 
> system administrators. In the scientists part, those who may be 
> interested in gnuplot are those who aren't afraid of the command-line, 
> those who are used to program or to use a shell, and those who are not 
> addicted to Matlab but to LateX. Programmers and sysadmins tend to use 
> gnuplot to plot stats and profiles, gnuplot is probably well suited for 
> those people. All in all, I think gnuplot has a small target audience, 

I've just came from a crystallography workshop ... there I was surprised by 
an acknowledgment to gnuplot by one speaker. When asked, she said her boss 
convinced her to use gnuplot and he was right :-)

> -apart from the regular command-line use case, gnuplot architecture 

gnuplot is just for fast drawing

> -gnuplot license discourages new contributors

some people don't care too much -- if they like the project, they help


> -contact identified contributors/rewrite parts of gnuplot to change the 
> license, to something reasonable (core LGPL, frontend GPL). This is a 
> huge lot of work, but that would definitely worth it. As far as 

I don't see any benefit of rewriting gnuplot.


BTW, what could be done, is to write down a project subject, and submit it 
for a bachelor thesis for an informatics student. (Well, most of them have 
never drawn any graph from data...)

---
PM

Re: gnuplot needs more developers/administrators

[Daniel J F. <dan...@im...>]

Hi,

I would be interested in started developing for gnuplot, but find =20
where to start a bit daunting. Maybe some mentoring of new developers =20=

with simple targets might be a good idea. Is there some sort of =20
'introduction to gnuplot dev' docs?

Dan.


On 19 Jun 2007, at 20:45, Timoth=E9e Lecomte wrote:

> Daniel J Sebald wrote:
>> I'll be tuning out from the list for now...  My thoughts are that =20
>> gnuplot development could use some fresh people to keep it going.  =20=

>> The summers used to be fairly productive, but now not much happens =20=

>> even then.  Should open an invitation for a few more =20
>> administrators or whomever's role it is to sort through patches =20
>> and chart a course for what needs attention.  One or two people =20
>> doing that isn't enough on a voluntary basis.  There are plenty of =20=

>> ideas for new stuff (multiple keys, better 3D/2D layout and use of =20=

>> margins, etc.).  My sense is that people are willing to contribute =20=

>> but become discouraged when patches sit on SourceForge =20
>> indefinitely.  Also, it might be good to review this kind of thing =20=

>> after each release, i.e., Will another release be warranted? What =20
>> new features, if any, should be in a future release? Are there =20
>> enough active contributors and administrators to get there in the =20
>> course of a year or two?
>>
>> Regards,
>>
>> Daniel
>>
>
> Hi Daniel,
>
> For what is worth, I don't think the situation is hopeless, but I
> understand how you feel. The same happens for many open-source =20
> projects,
> apart from the most trendy ones, and it heavily depends on the history
> of the project. For one thing, gnuplot being very old, some parts have
> not been touched for long. gnuplot is highly portable, which is a good
> thing but also a thing to take care of. Anyway, that's not what you
> express here. I would personally love to review your patches if I had
> more time, and it will hopefully happen after my examinations, i.e. =20=

> next
> week. I can for sure review the history ones, but I'm afraid I =20
> won't be
> able to understand much of the hidden3d one unless I devote a lot of
> time to it... until now I've carefully stayed away from the graphic =20=

> core
> functions in gnuplot.
>
> As far as contributions and administration is concerned, my feeling is
> that Ethan has been doing a great job lately. Of course, this doesn't
> mean that he can be everywhere every time.
>
> To me, the biggest differences between trendy projects that seem to be
> very dynamic and gnuplot today are:
>
> -few people have CVS commit rights, whereas the politic for kde (for
> example) is to give commit access almost immediately after the first
> patch. Other projects work like gnuplot, with a very small group of
> commiters, like compiz, but the latter also has a plugin architecture,
> and those plugins are written and modified by lots of people. Should
> more people get CVS access to gnuplot ? Why not. Apart from you, =20
> Daniel,
> I don't see major and regular contributors that don't have CVS access.
> Anyway, having the right to commit doesn't mean that one should commit
> immediately anything. Staying a while on Sourceforge is a good =20
> thing, at
> least it gives the time to think about the best solution. So the real
> question is : why aren't there more contributors ?
>
> -gnuplot isn't eye-candy, so it doesn't make the crowd crazy. The =20
> target
> audience is quite heavily restricted to scientists, programmers and
> system administrators. In the scientists part, those who may be
> interested in gnuplot are those who aren't afraid of the command-line,
> those who are used to program or to use a shell, and those who are not
> addicted to Matlab but to LateX. Programmers and sysadmins tend to use
> gnuplot to plot stats and profiles, gnuplot is probably well suited =20=

> for
> those people. All in all, I think gnuplot has a small target audience,
> and only a small subset of this audience tend to contribute.
>
> -there are a few alternatives to gnuplot (python, ...) so not all =20
> of the
> target audience ends up using gnuplot. And that's fortunate, diversity
> is good.
>
> -apart from the regular command-line use case, gnuplot architecture
> isn't that flexible. Most works to use gnuplot from another =20
> application
> are either hacks or are not well integrated, so it's not satisfying =20=

> for
> other projects that need a plotting engine.
>
> -gnuplot license discourages new contributors. This license obviously
> doesn't help in protecting gnuplot today. It prevents from sharing
> precious code with others. It results in doubt about the future of
> gnuplot, since because of this license, gnuplot is tied to its =20
> original
> authors, who are now completely out of the development process.
>
> To address these problems and improve the situation, few but radical
> changes are needed:
>
> -make gnuplot core available as a library (including all its
> file/printers terminals, and adapted screen terminals, so that they =20=

> can
> be used as widgets inside other apps).
> It implies to disentangle the command-line parser from the =20
> routines, and
> identify a sensible API. It's a lot of work.
>
> -contact identified contributors/rewrite parts of gnuplot to change =20=

> the
> license, to something reasonable (core LGPL, frontend GPL). This is a
> huge lot of work, but that would definitely worth it. As far as
> rewriting parts, it could a good time to think about external
> libraries/tools. I'm thinking of doxygen for the help formatting,
> flex/bison for the parser. I think we would need to distribute the =20
> jobs
> between several of us, and slowly get them done.
>
> I hope one day those two points will be marked as done. Most of the
> time, this kind of threads end up being unproductive, but I hope your
> mail and this one can help to start the process.
>
> Best regards,
>
> Timoth=E9e
>
>
> ----------------------------------------------------------------------=20=

> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: gnuplot needs more developers/administrators

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

Daniel J Sebald wrote:
> I'll be tuning out from the list for now...  My thoughts are that gnupl=
ot development could use some fresh people to keep it going.  The summers=
 used to be fairly productive, but now not much happens even then.  Shoul=
d open an invitation for a few more administrators or whomever's role it =
is to sort through patches and chart a course for what needs attention.  =
One or two people doing that isn't enough on a voluntary basis.  There ar=
e plenty of ideas for new stuff (multiple keys, better 3D/2D layout and u=
se of margins, etc.).  My sense is that people are willing to contribute =
but become discouraged when patches sit on SourceForge indefinitely.  Als=
o, it might be good to review this kind of thing after each release, i.e.=
, Will another release be warranted? What new features, if any, should be=
 in a future release? Are there enough active contributors and administra=
tors to get there in the course of a year or two?
>
> Regards,
>
> Daniel
>  =20

Hi Daniel,

For what is worth, I don't think the situation is hopeless, but I=20
understand how you feel. The same happens for many open-source projects, =

apart from the most trendy ones, and it heavily depends on the history=20
of the project. For one thing, gnuplot being very old, some parts have=20
not been touched for long. gnuplot is highly portable, which is a good=20
thing but also a thing to take care of. Anyway, that's not what you=20
express here. I would personally love to review your patches if I had=20
more time, and it will hopefully happen after my examinations, i.e. next =

week. I can for sure review the history ones, but I'm afraid I won't be=20
able to understand much of the hidden3d one unless I devote a lot of=20
time to it... until now I've carefully stayed away from the graphic core =

functions in gnuplot.

As far as contributions and administration is concerned, my feeling is=20
that Ethan has been doing a great job lately. Of course, this doesn't=20
mean that he can be everywhere every time.

To me, the biggest differences between trendy projects that seem to be=20
very dynamic and gnuplot today are:

-few people have CVS commit rights, whereas the politic for kde (for=20
example) is to give commit access almost immediately after the first=20
patch. Other projects work like gnuplot, with a very small group of=20
commiters, like compiz, but the latter also has a plugin architecture,=20
and those plugins are written and modified by lots of people. Should=20
more people get CVS access to gnuplot ? Why not. Apart from you, Daniel, =

I don't see major and regular contributors that don't have CVS access.=20
Anyway, having the right to commit doesn't mean that one should commit=20
immediately anything. Staying a while on Sourceforge is a good thing, at =

least it gives the time to think about the best solution. So the real=20
question is : why aren't there more contributors ?

-gnuplot isn't eye-candy, so it doesn't make the crowd crazy. The target =

audience is quite heavily restricted to scientists, programmers and=20
system administrators. In the scientists part, those who may be=20
interested in gnuplot are those who aren't afraid of the command-line,=20
those who are used to program or to use a shell, and those who are not=20
addicted to Matlab but to LateX. Programmers and sysadmins tend to use=20
gnuplot to plot stats and profiles, gnuplot is probably well suited for=20
those people. All in all, I think gnuplot has a small target audience,=20
and only a small subset of this audience tend to contribute.

-there are a few alternatives to gnuplot (python, ...) so not all of the =

target audience ends up using gnuplot. And that's fortunate, diversity=20
is good.

-apart from the regular command-line use case, gnuplot architecture=20
isn't that flexible. Most works to use gnuplot from another application=20
are either hacks or are not well integrated, so it's not satisfying for=20
other projects that need a plotting engine.

-gnuplot license discourages new contributors. This license obviously=20
doesn't help in protecting gnuplot today. It prevents from sharing=20
precious code with others. It results in doubt about the future of=20
gnuplot, since because of this license, gnuplot is tied to its original=20
authors, who are now completely out of the development process.

To address these problems and improve the situation, few but radical=20
changes are needed:

-make gnuplot core available as a library (including all its=20
file/printers terminals, and adapted screen terminals, so that they can=20
be used as widgets inside other apps).
It implies to disentangle the command-line parser from the routines, and =

identify a sensible API. It's a lot of work.

-contact identified contributors/rewrite parts of gnuplot to change the=20
license, to something reasonable (core LGPL, frontend GPL). This is a=20
huge lot of work, but that would definitely worth it. As far as=20
rewriting parts, it could a good time to think about external=20
libraries/tools. I'm thinking of doxygen for the help formatting,=20
flex/bison for the parser. I think we would need to distribute the jobs=20
between several of us, and slowly get them done.

I hope one day those two points will be marked as done. Most of the=20
time, this kind of threads end up being unproductive, but I hope your=20
mail and this one can help to start the process.

Best regards,

Timoth=E9e

gnuplot needs more developers/administrators

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

I'll be tuning out from the list for now...  My thoughts are that gnuplot development could use some fresh people to keep it going.  The summers used to be fairly productive, but now not much happens even then.  Should open an invitation for a few more administrators or whomever's role it is to sort through patches and chart a course for what needs attention.  One or two people doing that isn't enough on a voluntary basis.  There are plenty of ideas for new stuff (multiple keys, better 3D/2D layout and use of margins, etc.).  My sense is that people are willing to contribute but become discouraged when patches sit on SourceForge indefinitely.  Also, it might be good to review this kind of thing after each release, i.e., Will another release be warranted? What new features, if any, should be in a future release? Are there enough active contributors and administrators to get there in the course of a year or two?

Regards,

Daniel

hidden lines (was Re: Winding down patches...)

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

Daniel J Sebald wrote:

> The existing version isn't much different really.  But there is definitely a bug 
> here and it shouldn't be dismissed as something else.  If one would prefer to go 
> through the existing code and find the case that is failing, that's fine.  But 
> someone has to do that work, which I simply didn't find easy to follow...  I can 
> give a hint for anyone who wants to look for the abberant case statement: the 
> existing version seems to leave the bits behind when the hidden line intersects 
> with one of the vertices of the triangle that is supposed to be hiding it.  If I 
> find some time, I will search for this.  (But if the original author who has 
> familiarity with the CVS algorithm wants to find it, I'm fine with that too.)

Here's a patch to get one started on fixing bug [ 1718109 ].  And there is always the alternate method if no one gets around to looking at this.

Dan

RE: Urgent... How to call only output in my Devloped GUI

[Nigel N. <nN...@au...>]

Dear Amit Kumar,

You wrote:

> I am developing real time project, I have need to call
> graphical representation in that project. I want to see
> only output GNU window, after clicking on command button.
> I am using Visual C++ for Developing this project. Plz
> give me clear instructions.


This is precisely how I use gnuplot: as a plotting engine driven
programmatically by a GUI simulation environment.  There is a
chance that during July, I will try to synch with sourceforge.
Sadly, for now nothing, least of all clear instructions  :~)

Nigel

--

Re: bug report gnuplot 4.3 patchlevel 0

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

On Tuesday 12 June 2007 01:20, Thomas Vogel wrote:
> 
> gnuplot> set ytics border in scale 1,0.5 mirror norotate  offset character 0, 
> 0, 0 -0.150000,0.01,0.150000
>                                                                                             
> ^
>          "Eall.vglTN.gnuplot", line 98: invalid expression 

Thanks. That's a bug in the 'save' routine.
Fixed in CVS.
 

-- 
Ethan A Merritt

Re: Urgent....How to call only output in my Devloped GUI

[<HBB...@t-...>]

amit kumar wrote:
>       I am developing real time project ,i have need to call graphical 
> representation in that project.i want to see only output GNU window,
> after clicking on command button.I am using Visual C++ for Developing 
> this project.

Which, although you failed to say so, means that you're doing this on MS 
Windows.

That's bad news.  MS Windows as a platform doesn't lend itself easily to 
tools with optional command-line windows.  They either always have them 
(like wgnuplot), or never (like most tools on Windows).

gnuplot is not a MS-centric program.  This is one of the places it shows.

Re: Winding down patches...

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

On Thursday 14 June 2007 13:36, Petr Mikulik wrote:
> > > I was always puzzled by "currently [-10:10]" when the range was completely 
> > > different. Indeed, "default" is the correct word. However, this information 
> > > is completely useless. I usually want to show the real xrange, not the 
> > > unused default. Nowadays, I can do
> > > 	print GPVAL_Y_MIN, GPVAL_Y_MAX
> > > but that's rather cumbersome and not easy to find for others.
> > > 
> > > I proposed to apply Daniel's patch. Then, via "show yrange", I can easily 
> > > copy the real current range to my script, and edit the range manually.
> > 
> > OK. I warn you that the existing code for zoom/unzoom actually looks at
> > these values, so it is possible this may change the zoom behaviour.
> > But the "refresh" patch I've been working on replaces that code anyhow,
> > so now might not be such a bad time to take the risk.
> 
> No, it does not. The output from Daniel's patch only effects what is printed 
> on the screen as a comment.

Ah, OK then.

I thought he was proposing to update the values themselves in the axis structure.
Sure, printing the current value is much more useful than always printing [10:10].

	Ethan



> Compare: 
> 
> 
> current-gnuplot> set xrange [-2:2]; p x*x-1; show yrange
> 
>         set yrange [ * : * ] noreverse nowriteback  # (currently 
> [-10.0000:10.0000] )
> 
> 
> patched-gnuplot> set xrange [-2:2]; p x*x-1; show yrange
> 
>         set yrange [ * : * ] noreverse nowriteback  # (currently 
> [-1.00000:3.50000] )
> 
> 
> The latter is much more logic, but it's just a comment for the user.
> 
> ---
> PM
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: Winding down patches...

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

Hans-Bernhard Bröker wrote:

>> Hans-Bernhard suggested not doing such a thing.  The fix would be to 
>> simply not draw the tic and verticle dotted line outside the border 
>> for range [0:1.99805].   That would still look like the [0:2] case.
> 
> 
> ... only if the border is actually drawn, and the grid isn't.  With
> 
>     set grid ; unset border
> 
> such a change would be very visible.  Not to mention the tick label 
> itself suddenly disappearing.

Good point, but it is easy enough to test on the condition of the border being drawn or not.  The question remains whether or not a grid line should ever be drawn outside a border.

Dan

Re: Winding down patches...

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

> since you are looking at zoom, I have noticed that current code does not
> unzoom as I expected having read the doc.
> 
> 'u' just jumps back to initial unzoomed plot. I seem to recall the doc saying
> it goes to "previous" zoom state.

u is really unzoom; hit 'h' in the graphics window for this help:

 n       `builtin-zoom-next` go to next zoom in the zoom stack
 p       `builtin-zoom-previous` go to previous zoom in the zoom stack
 u       `builtin-unzoom`

---
PM

Re: Winding down patches...

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

> > I was always puzzled by "currently [-10:10]" when the range was completely 
> > different. Indeed, "default" is the correct word. However, this information 
> > is completely useless. I usually want to show the real xrange, not the 
> > unused default. Nowadays, I can do
> > 	print GPVAL_Y_MIN, GPVAL_Y_MAX
> > but that's rather cumbersome and not easy to find for others.
> > 
> > I proposed to apply Daniel's patch. Then, via "show yrange", I can easily 
> > copy the real current range to my script, and edit the range manually.
> 
> OK. I warn you that the existing code for zoom/unzoom actually looks at
> these values, so it is possible this may change the zoom behaviour.
> But the "refresh" patch I've been working on replaces that code anyhow,
> so now might not be such a bad time to take the risk.

No, it does not. The output from Daniel's patch only effects what is printed 
on the screen as a comment. Compare:


current-gnuplot> set xrange [-2:2]; p x*x-1; show yrange

        set yrange [ * : * ] noreverse nowriteback  # (currently 
[-10.0000:10.0000] )


patched-gnuplot> set xrange [-2:2]; p x*x-1; show yrange

        set yrange [ * : * ] noreverse nowriteback  # (currently 
[-1.00000:3.50000] )


The latter is much more logic, but it's just a comment for the user.

---
PM

Re: Winding down patches...

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

On Thu, 14 Jun 2007 20:26:46 +0200, Ethan Merritt  
<merritt@u.washington.edu> wrote:

> On Thursday 14 June 2007 01:10, Petr Mikulik wrote:
>>
>> I was always puzzled by "currently [-10:10]" when the range was  
>> completely
>> different. Indeed, "default" is the correct word. However, this  
>> information
>> is completely useless. I usually want to show the real xrange, not the
>> unused default. Nowadays, I can do
>> 	print GPVAL_Y_MIN, GPVAL_Y_MAX
>> but that's rather cumbersome and not easy to find for others.
>>
>> I proposed to apply Daniel's patch. Then, via "show yrange", I can  
>> easily
>> copy the real current range to my script, and edit the range manually.
>
> OK. I warn you that the existing code for zoom/unzoom actually looks at
> these values, so it is possible this may change the zoom behaviour.
> But the "refresh" patch I've been working on replaces that code anyhow,
> so now might not be such a bad time to take the risk.
>

since you are looking at zoom, I have noticed that current code does not  
unzoom as I expected having read the doc.

'u' just jumps back to initial unzoomed plot. I seem to recall the doc  
saying it goes to "previous" zoom state.

Thus if I do two successive zooms I'd expected to back out in two steps  
with 'u'.

Maybe I just misunderstood, if so, this may be a good idea. I often want  
to do just this and end up having to repeat the first zoom.

Thx

Re: Winding down patches...

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

On Thursday 14 June 2007 01:10, Petr Mikulik wrote:
> 
> I was always puzzled by "currently [-10:10]" when the range was completely 
> different. Indeed, "default" is the correct word. However, this information 
> is completely useless. I usually want to show the real xrange, not the 
> unused default. Nowadays, I can do
> 	print GPVAL_Y_MIN, GPVAL_Y_MAX
> but that's rather cumbersome and not easy to find for others.
> 
> I proposed to apply Daniel's patch. Then, via "show yrange", I can easily 
> copy the real current range to my script, and edit the range manually.

OK. I warn you that the existing code for zoom/unzoom actually looks at
these values, so it is possible this may change the zoom behaviour.
But the "refresh" patch I've been working on replaces that code anyhow,
so now might not be such a bad time to take the risk.

-- 
Ethan A Merritt

Re: Winding down patches...

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

> >>- [ 1731160 ] min/max printout error for show Xrange
> >>  fine, I propose to move it to cvs
> > 
> > No.  I don't think the issue is well understood.
> > There may be an error, but I am not so sure.
> > Isn't this what the "writeback" option is supposed to handle?
> > Do we have a test case for "writeback"?
> 
> I misunderstood this one when writing this patch.  I took it to mean 
> GPVAL_Y_MIN, GPVAL_Y_MAX, etc.  So, there is no error from the perspective I was 
> saying.
> 
> set yrange [ * : * ] noreverse writeback  # (currently [-10.0000:10.0000] )
> should change to reflect something.
>
> I thought maybe the [-1:1] would show in the "currently [ : ]", but there is no 
> reason for gnuplot to display anything different than it currently does.
> 
> I'm inclined to close this patch.  However, maybe if there is one thing to 
> change it would be the word "currently" to "default", i.e.,

I was always puzzled by "currently [-10:10]" when the range was completely 
different. Indeed, "default" is the correct word. However, this information 
is completely useless. I usually want to show the real xrange, not the 
unused default. Nowadays, I can do
	print GPVAL_Y_MIN, GPVAL_Y_MAX
but that's rather cumbersome and not easy to find for others.

I proposed to apply Daniel's patch. Then, via "show yrange", I can easily 
copy the real current range to my script, and edit the range manually.


> >>- hidden patches
> > 
> I think these are rock solid.
> 
> The patch on degenerate polygons is a clear cut case.  There is simply no way of 
> choosing a plane direction from 2 points.  Such a thin "triangle" shouldn't have 
> any visual effect anyway.  Just discard those and all is fine.

>From a user point of view, the patch brings hiding of lines and polygons, 
which look much better (and correctly) than what we have now. So, it's an 
improvement, therefore I propose to apply the patch.

---
PM

Re: Winding down patches...

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

> >>This problem is the result of a bit of sloppiness in programming and trying to 
> >>accomplish the whole tic layout in a simple hunk of code when it can't be done. 
> >>  Basically, the fact is we *know* the beginning and end of the ranges as 
> >>entered.  Why toss that information away by doing x_tic = x_min + x_delta + 
> >>x_delta + x_delta + ...?
> > 
> > 
> > Because it is bad to have vanishingly small changes in the specified range
> > cause large changes in the plot layout?
> 
> Is the argument that a range [0:1.99805] should result in a plot having the same 
> appearance as with range [0:2] (which they currently aren't)?  I.e., we're off 
> by 0.0019500 for a range of 1.99805, or 0.0975 percent so no big difference? 
> Hans-Bernhard suggested not doing such a thing.  The fix would be to simply not 
> draw the tic and verticle dotted line outside the border for range [0:1.99805]. 

We may not do this in real graph coordinates, but in terminal coordinates. 
If center of the left/right grid line is smaller/larger than center of the 
border line, then don't draw that grid line.

---
PM

Re: Winding down patches...

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

Ethan Merritt wrote:
> On Wednesday 13 June 2007 10:35, Daniel J Sebald wrote:
> 
>>This problem is the result of a bit of sloppiness in programming and trying to 
>>accomplish the whole tic layout in a simple hunk of code when it can't be done. 
>>  Basically, the fact is we *know* the beginning and end of the ranges as 
>>entered.  Why toss that information away by doing x_tic = x_min + x_delta + 
>>x_delta + x_delta + ...?
> 
> 
> Because it is bad to have vanishingly small changes in the specified range
> cause large changes in the plot layout?

Is the argument that a range [0:1.99805] should result in a plot having the same 
appearance as with range [0:2] (which they currently aren't)?  I.e., we're off 
by 0.0019500 for a range of 1.99805, or 0.0975 percent so no big difference? 
Hans-Bernhard suggested not doing such a thing.  The fix would be to simply not 
draw the tic and verticle dotted line outside the border for range [0:1.99805]. 
  That would still look like the [0:2] case.

Dan

Re: Winding down patches...

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

On Wednesday 13 June 2007 10:35, Daniel J Sebald wrote:
> This problem is the result of a bit of sloppiness in programming and trying to 
> accomplish the whole tic layout in a simple hunk of code when it can't be done. 
>   Basically, the fact is we *know* the beginning and end of the ranges as 
> entered.  Why toss that information away by doing x_tic = x_min + x_delta + 
> x_delta + x_delta + ...?

Because it is bad to have vanishingly small changes in the specified range
cause large changes in the plot layout?


-- 
Ethan A Merritt

Re: Winding down patches...

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

Ethan Merritt wrote:

>>- [ 1731160 ] min/max printout error for show Xrange
>>  fine, I propose to move it to cvs
> 
> 
> No.  I don't think the issue is well understood.
> There may be an error, but I am not so sure.
> Isn't this what the "writeback" option is supposed to handle?
> Do we have a test case for "writeback"?

I misunderstood this one when writing this patch.  I took it to mean 
GPVAL_Y_MIN, GPVAL_Y_MAX, etc.  So, there is no error from the perspective I was 
saying.

However, it does seem that the -10:10 of

set yrange [ * : * ] noreverse writeback  # (currently [-10.0000:10.0000] )

should change to reflect something.  But even the "help writeback" example 
sequence sort of makes sense:

gnuplot> set xrange [-10:10]
gnuplot> set yrange [] writeback
gnuplot> plot sin(x)
gnuplot> show yrange

         set yrange [ * : * ] noreverse writeback  # (currently [-10.0000:10.0000] )

gnuplot> set yrange restore
gnuplot> show yrange

         set yrange [ -1.00000 : 1.00000 ] noreverse writeback

gnuplot> replot x/2

I thought maybe the [-1:1] would show in the "currently [ : ]", but there is no 
reason for gnuplot to display anything different than it currently does.

I'm inclined to close this patch.  However, maybe if there is one thing to 
change it would be the word "currently" to "default", i.e.,

   set yrange [ * : * ] noreverse writeback  # (default [-10.0000:10.0000] )

(and fix the spacing in the parentheses).  The problem I have with the word 
"currently" is that if one does an autorange plot and then show yrange, the 
yrange obviously isn't [-10:10].


>>- [1004754] Tics and grid slightly outside border.
>>  is this still needed?
> 
> 
> No. Please drop this one.  There are always going to be
> corner cases where if you ask for something odd you will
> get an unexpected result.  In this case the requested
> axis range is not reasonable, and the fix belongs in the
> program that generated the unreasonable axis range.

I still think this one is fine.  It boils down to the message left by 
Hans-Bernhard in the code, about computing tics by adding delta_tic each time.

This problem is the result of a bit of sloppiness in programming and trying to 
accomplish the whole tic layout in a simple hunk of code when it can't be done. 
  Basically, the fact is we *know* the beginning and end of the ranges as 
entered.  Why toss that information away by doing x_tic = x_min + x_delta + 
x_delta + x_delta + ...?

> 
> 
>>- hidden patches
> 
> 
> My impression is that this is another case like the one
> above. There are corner cases that cause minor glitches.
> This is annoying, yes.  But the proposed wholesale
> re-working of the hidden3d code is almost certain to have
> an equal number of glitches and corner cases.  You just
> haven't found them yet.  I am inclined to say we should
> drop this whole issue.

I think these are rock solid.

The patch on degenerate polygons is a clear cut case.  There is simply no way of 
choosing a plane direction from 2 points.  Such a thin "triangle" shouldn't have 
any visual effect anyway.  Just discard those and all is fine.

The glitches (spics and specs) is not a case of tolerance (slop factor).  Take a 
look at first/second order 3D surfaces in 'image2.dem'.  In that case there are 
some very big lines that aren't hidden when they should be.  Try this patch out. 
  Step through 'all.dem' before and after and look for the hidden lines demos. 
The difference is clear.  No kludges here either, just a straight forward 
implementation of something similar to this algorithm:

http://local.wasp.uwa.edu.au/~pbourke/geometry/

The existing version isn't much different really.  But there is definitely a bug 
here and it shouldn't be dismissed as something else.  If one would prefer to go 
through the existing code and find the case that is failing, that's fine.  But 
someone has to do that work, which I simply didn't find easy to follow...  I can 
give a hint for anyone who wants to look for the abberant case statement: the 
existing version seems to leave the bits behind when the hidden line intersects 
with one of the vertices of the triangle that is supposed to be hiding it.  If I 
find some time, I will search for this.  (But if the original author who has 
familiarity with the CVS algorithm wants to find it, I'm fine with that too.)

As for the assertion failure.  That one doesn't really concern me, it's just 
that it is easy enough to limit the search range rather than issue an assertion 
failure and exit from the program.

...  Dynamically setting the quadtree range is the thing to look at doing.  A 
noticable speed up can come from that.  But that's not a pressing issue.

Dan

Re: Winding down patches...

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

On Wednesday 13 June 2007 02:27, Petr Mikulik wrote:
> > Due to an probable change of venue in the coming weeks, I will likely not have 
> > time for gnuplot code as I occassionally have had in the past.  If there are any 
> > code bugs or features, or any sourceforge patches that people want me to look 
> > at, now is time.
> 
> My comments:
> 
> - history patch
>   fine, I propose to move it to cvs

OK. I hope you guys have tested it thoroughly.
 
> - [1488168] z_floor and z_ceiling based on xyplane.absolute
>   fine, I propose to move it to cvs

OK.
 
> - [ 1731160 ] min/max printout error for show Xrange
>   fine, I propose to move it to cvs

No.  I don't think the issue is well understood.
There may be an error, but I am not so sure.
Isn't this what the "writeback" option is supposed to handle?
Do we have a test case for "writeback"?
 
> - [1004754] Tics and grid slightly outside border.
>   is this still needed?

No. Please drop this one.  There are always going to be
corner cases where if you ask for something odd you will
get an unexpected result.  In this case the requested
axis range is not reasonable, and the fix belongs in the
program that generated the unreasonable axis range.

> - hidden patches

My impression is that this is another case like the one
above. There are corner cases that cause minor glitches.
This is annoying, yes.  But the proposed wholesale
re-working of the hidden3d code is almost certain to have
an equal number of glitches and corner cases.  You just
haven't found them yet.  I am inclined to say we should
drop this whole issue.

-- 
Ethan A Merritt

Re: Touchup of history.c

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

On Wednesday 13 June 2007 00:19, Petr Mikulik wrote:
> > > > I think you can use simply
> > > >   if (isanumber(c_token)) {
> > > > 	act on integer
> > > >   }
> > 
> > Unfortunately not.
> > "isanumber" is mis-named. It really acts as "isapositivenumber".
> > The reason is that the tokensiser places the - sign into its
> > own separate token.  So isanumber(c_token) sees only the '-' sign,
> > no number.
> > 
> > This has annoyed me many times, but never sufficiently to
> > replace isanumber() with something better.
> 
> Does this mean that it is not possible to add a function "isaninteger()" 
> that woul work for negative numbers as well?

Better to fix "isanumber()" to do what it claims.
But then you would have to check and clean up all the call sites.
Not hard, just tedious.

-- 
Ethan A Merritt

Re: Winding down patches...

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

> > - [1004754] Tics and grid slightly outside border.
> >   is this still needed?
> 
> The following still places a grid line outside the border (try it a couple times 
> if the first time the problem doesn't appear):
> 
> set xrange [0:1.99805]
> set grid
> plot sin(x)
> 
> (Another application computes the range, hence the strange choice.)

Yes, this looks strange.

It seems that the grid line should be canceled if its center in screen 
coordinates is larger than the center of the border line.

---
PM

Re: Winding down patches...

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

Petr Mikulik wrote:

> - [1004754] Tics and grid slightly outside border.
>   is this still needed?

The following still places a grid line outside the border (try it a couple times 
if the first time the problem doesn't appear):

set xrange [0:1.99805]
set grid
plot sin(x)

(Another application computes the range, hence the strange choice.)

Dan

Re: Winding down patches...

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

> Due to an probable change of venue in the coming weeks, I will likely not have 
> time for gnuplot code as I occassionally have had in the past.  If there are any 
> code bugs or features, or any sourceforge patches that people want me to look 
> at, now is time.

My comments:

- history patch
  fine, I propose to move it to cvs

- [1488168] z_floor and z_ceiling based on xyplane.absolute
  fine, I propose to move it to cvs

- [ 1731160 ] min/max printout error for show Xrange
  fine, I propose to move it to cvs

- [1004754] Tics and grid slightly outside border.
  is this still needed?

- hidden patches
  current status?

---
PM

Re: Patches item #1729825 ready to go.

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

On Sun, 10 Jun 2007 16:56:39 +0200, Petr Mikulik <mi...@ph...>  
wrote:

>> Two unresolved things.
>>
>> 1) What should be the default for {full|ignoredups|condensed}?  And why?
>
> condensed -- it is the current behaviour, and it speeds us browsing and
> mouse-copying previous commands

I would have said full should be the natural default and users wanting  
condenced should set ~/gnuplot.conf or whatever it is. HOWEVER, to save  
yet another change to the way things work I'd have to agree with Petr.  
Keep current as default. It's important to maintain backwards compat.

>
>> 2) Can we deprecate "historysize".  (I've currently programmed "set  
>> history
>> <n>" and "set historysize <n>" to be the same.)
>
> change it to 'set history size'

One of my big bugbears with Linux is that every time I need something it  
seems someone has done some insignificant little tweek and broken the way  
it works. I then have to find out what/why/where and fix it. This is a  
futile , mind-blowing waste of time.

This is a good example. If historysize is established in current release  
please leave it. The dupe will cost virtually nothing and will save users  
with established scipts being faced with extra work and breakage which  
serves no real purpose.

There are those of us who like to fiddle with code and others who rely on  
it to do a job. We should not reduce the usefulness of the software by  
unnecessary changes to the commands.

The history clean up and new features is great but please dont break what  
works.

;)