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

Re: GPVAL_VERSION

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

On Thursday 29 June 2006 11:19 pm, Petr Mikulik wrote:
> The "GPVAL_ variables" patch has been committed ... now I think that might 
> 
> then:
> GPVAL_VERSION = 4.2
> GPVAL_PATCHLEVEL = 0
> 
> Any opinion why not to add them?

Might as well start right now with 4.2
I've just updated the docs to say 4.2


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

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):

now:
GPVAL_VERSION = 4.1
GPVAL_PATCHLEVEL = 0

then:
GPVAL_VERSION = 4.2
GPVAL_PATCHLEVEL = 0

Any opinion why not to add them?

---
PM

Re: crashes using history

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

Ethan A Merritt wrote:
> On Thursday 29 June 2006 12:37 pm, Daniel J Sebald wrote:
> 
>>The word "below" for the key was deprecated?  
>>("under" still works.)  I assume you want us to remove any 
>>examples of deprecated syntax from gnuplot.doc as well.  
> 
> 
> Apparently so. Maybe it was unintentional.  I don't care
> whether you reinstate "below" or change the docs and the
> demos.  Just so long as they agree with each other.

I seem to recall a discussion where no decision was made to deprecate the key settings.  Therefore, I will leave any reference to "below" and "under" in the documentation gnuplot.doc, but I have removed all use of these in the demos.

For "set title" and "set label" I've made sure no outdated syntax appears in gnuplot.doc and removed all use from the demos.

A patch is on SourceForge.

One bug resulted from the switchover to non-compatible compile--rainbow.dem.

Dan

PS: rectangle.dem  "Oooo!  Ahhh!"  (getting read for the fireworks)

Re: crashes using history

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

On Thursday 29 June 2006 12:37 pm, Daniel J Sebald wrote:
> 
> The word "below" for the key was deprecated?  
> ("under" still works.)  I assume you want us to remove any 
> examples of deprecated syntax from gnuplot.doc as well.  

Apparently so. Maybe it was unintentional.  I don't care
whether you reinstate "below" or change the docs and the
demos.  Just so long as they agree with each other.

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

Re: crashes using history

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

Ethan A Merritt wrote:

> I did find one other thing inadvertantly while testing on VMS, however.
> Some of the demos use deprecated syntax that only works if you build 
> with BACKWARDS_COMPATIBLE defined.  They should be fixed to use the
> current syntax, since they serve as coding examples.
> I logged a feature request to track this.

The word "below" for the key was deprecated?  ("under" still works.)  I assume you want us to remove any examples of deprecated syntax from gnuplot.doc as well.

Dan

Re: crashes using history

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

Ethan A Merritt wrote:
> On Thursday 29 June 2006 10:10 am, you wrote:
> 
>>I do see some more dodgy potential memory leak code in command.c.  That use of do_line() followed by a free of a non-static memory pointer:  (from do_string, ... in most cases the command given to it by the mouse and so on should not fail)
>>
>>    do_line();
>>    strcpy(gp_input_line, orig_input_line);
>>    free(orig_input_line);
> 
> 
> You mean because it might int_error() inside do_line()?

Yes.

> The possibility of a memory leak triggered only by a user error doesn't
> bother me nearly as much as a memory that can happen during correct
> usage.  Presumably if it's a script that errors out, they've got bigger
> problems than the memory leak.

I'm a-r that way, I guess; don't like losing memory--probably because I work on other platforms where there isn't the abundance of memory like on a general computer system.


> I did find one other thing inadvertantly while testing on VMS, however.
> Some of the demos use deprecated syntax that only works if you build 
> with BACKWARDS_COMPATIBLE defined.  They should be fixed to use the
> current syntax, since they serve as coding examples.
> I logged a feature request to track this.

OK.

Dan

Re: crashes using history

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

On Thursday 29 June 2006 10:10 am, you wrote:
> 
> I do see some more dodgy potential memory leak code in command.c.  That use of do_line() followed by a free of a non-static memory pointer:  (from do_string, ... in most cases the command given to it by the mouse and so on should not fail)
> 
>     do_line();
>     strcpy(gp_input_line, orig_input_line);
>     free(orig_input_line);

You mean because it might int_error() inside do_line()?
The possibility of a memory leak triggered only by a user error doesn't
bother me nearly as much as a memory that can happen during correct
usage.  Presumably if it's a script that errors out, they've got bigger
problems than the memory leak.

I did find one other thing inadvertantly while testing on VMS, however.
Some of the demos use deprecated syntax that only works if you build 
with BACKWARDS_COMPATIBLE defined.  They should be fixed to use the
current syntax, since they serve as coding examples.
I logged a feature request to track this.


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

Re: 4.2pre-whatever builds OK on VMS

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

Ethan A Merritt wrote:
> I've just built and tested the current cvs version on VMS.
> I can't test x11 because it's a remote machine with no X connection
> available, but 'all.dem' run through 'set term post color solid'
> looks almost perfect.  
> 
> Only two glitches:
> 1) There are some spurious <null> characters at the end of each
> page of PostScript output.  Perhaps some buffer flush oddity.
> 2) The column-stacked histogram demo has some missing boxes.
> I vaguely recall encountering that once before, but I can't
> remember what it turned out to be.  Maybe some browsing through
> ChangeLog.

Didn't we recently have something with an extra "gprestore"?  Anyway, maybe you could send an example output with the <null> chars and the missing boxes.  (Just one page each.)  Could think it through to see if there is a bug

> Anyhow, given the huge number of changes since the last time
> I did a full build and test under VMS, I'm amazed how smooth it was.
> Somebody with a local box would have to test the x11 support,
> however.

That is amazing, but not surprising.  I think I've said this before: the attention to detail since the 4.0 series has been very high.

Dan

4.2pre-whatever builds OK on VMS

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

I've just built and tested the current cvs version on VMS.
I can't test x11 because it's a remote machine with no X connection
available, but 'all.dem' run through 'set term post color solid'
looks almost perfect.  

Only two glitches:
1) There are some spurious <null> characters at the end of each
page of PostScript output.  Perhaps some buffer flush oddity.
2) The column-stacked histogram demo has some missing boxes.
I vaguely recall encountering that once before, but I can't
remember what it turned out to be.  Maybe some browsing through
ChangeLog.

Anyhow, given the huge number of changes since the last time
I did a full build and test under VMS, I'm amazed how smooth it was.
Somebody with a local box would have to test the x11 support,
however.


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

Re: crashes using history

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

Daniel J Sebald wrote:

> There is a considerable bug.  How do we go about fixing that?

I may have a solution, if anyone else has started looking at this.  This may not be as difficult as it was made to be.

Dan

Re: crashes using history

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

Daniel J Sebald wrote:

> That or you found another bug.  I didn't touch anything with the malloc() command or the ! form of history.  Only the portion that displays the code, write_history_n().  The command sequence above should not make a call to write_history_n().
> 
> Give me a couple hours to see if there is another bug here.  I have tried your command sequence and can reproduce something similar.

I have a feeling that this bug resides in command.c.  There is quite a problem here.  I get a little more information than what Ethan did:

Terminal type set to 'x11'
gnuplot> history !re
  Executing:
        replot
         ^
         no previous plot

gnuplot> history !re
                  ^
         recurrency forbidden

gnuplot> history !re
Segmentation fault


That "recurrecy forbidden" is the tip off.  Here is the questionable hunk of code in command.c (not help.c):

	    /* execute the command "name" */
	    char *copy_name = gp_strdup(name);
	    save_input_line = gp_input_line;
	    save_c_token = c_token;
	    save_input_line_len = gp_input_line_len;
	    flag = 1;
	    gp_input_line = copy_name;
	    printf("  Executing:\n\t%s\n",name);
bad>	    do_line();
	    free(copy_name);
	    gp_input_line = save_input_line;
	    c_token = save_c_token;
	    gp_input_line_len = save_input_line_len;
	    num_tokens = scanner(&gp_input_line, &gp_input_line_len);
	    flag = 0;

It is of the variety that I've never liked, where some variables are temporarily saved, change, do something, then change them back.

OK, so the program searches through the history and finds a command that matches.  It comes to the above code, grabs some memory, rearranges some variables, then reaches that line of code I marked as "bad".  But look at the "replot" command above, it calls an internal_error() in all likelihood, in which case the program never returns from "do_line()", copy_name is never freed, *gp_input_line* is pointing to a bogus, less than 1024 character string (could be a problem), and flag never gets set to zero (hence the "recurrency forbidden" message I'm getting.

There is a considerable bug.  How do we go about fixing that?

Dan

Re: crashes using history

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

Ethan A Merritt wrote:
> On Wednesday 28 June 2006 03:07 pm, Petr Mikulik wrote:
> 
>>>The problem actually appears to be something that was sitting in the code for 
>>>quite a while.
>>>SourceForge bugs-report isn't working right now.  I've attached the patch
>>
>>I've committed it to cvs.
> 
> 
> Unfortunately, I think this was a step backwards.
> Before this went in, I was unable to replicate the reported crashes.
> I'm sure they were real, but they must have been hard to trigger.
> With this new patch in cvs, I now get the following:
> 
> gnuplot> history !re
>   Executing:
>         reset
> gnuplot> history !rep
>   Executing:
>         replot
>          ^
>          no previous plot
> gnuplot> 
> *** glibc detected *** malloc(): memory corruption: 0x081e8260 ***
> 
> So I think there is a serious memory error in this code that
> was just added.

That or you found another bug.  I didn't touch anything with the malloc() command or the ! form of history.  Only the portion that displays the code, write_history_n().  The command sequence above should not make a call to write_history_n().

Give me a couple hours to see if there is another bug here.  I have tried your command sequence and can reproduce something similar.

Dan

Re: crashes using history

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

On Wednesday 28 June 2006 03:07 pm, Petr Mikulik wrote:
> > The problem actually appears to be something that was sitting in the code for 
> > quite a while.
> > SourceForge bugs-report isn't working right now.  I've attached the patch
> 
> I've committed it to cvs.

Unfortunately, I think this was a step backwards.
Before this went in, I was unable to replicate the reported crashes.
I'm sure they were real, but they must have been hard to trigger.
With this new patch in cvs, I now get the following:

gnuplot> history !re
  Executing:
        reset
gnuplot> history !rep
  Executing:
        replot
         ^
         no previous plot
gnuplot> 
*** glibc detected *** malloc(): memory corruption: 0x081e8260 ***

So I think there is a serious memory error in this code that
was just added.

Please, can we not add bunches of new and untested code to CVS
at this point?  It's a bad idea when we're trying to tie up all
the loose ends for a release.  The risk of introducing serious
new bugs is greater than the benefit from fixing minor annoyances.

	Ethan



> 
> 
> > OK, now some comments.
> >
> > 1)  By shuffling around the command line entries when placing them in the 
> > history buffer, the history becomes inaccurate in a significant sense.  A 
> > user, especially a new one, will fret "Now what did I type to get that to 
> > work?".  He or she will look back at the history and see something that in no 
> > way reflects what was typed if there are repeat commands.
> 
> It reflects all commands he has entered. By means of them, the last plot can 
> be easily reproduced.
> 
> The current behaviour saves his nerves using "up arrow" key to go always 
> through last 10 replot commands, for example.
> 
> 
> > the list, in order to do this little shuffling thing, one has to search back 
> > through the history time and time again.  If the history buffer gets very 
> > long with one unique command after another, that's a lot of horsepower going 
> > to maintaining the buffer on a consistent basis.
> 
> There is a limit of 1000 commands stored in the history if I remember 
> correctly, so there will be max 1000 times strcmp(). It will take much less 
> time then drawing any graph or writing a character.
> 
> > tricks.  But losing the original sequence of things means we can never get 
> > things back.
> 
> Write your commands into a script file.
> Keep interactive editing easy.
> 
> 
> > Would it make sense to have an option for history:
> >
> > gnuplot> history # {linear | condensed}
> 
> Maybe, if some people like the "linear".
> 
> > o Was the reason for the current behavior to make sure the history buffer 
> > doesn't get so big?
> 
> No, see above.
> 
> > We should also have a "depth" option.
> 
> yes, and
>  	set historyfile depth 0
> would avoid saving (reading also?) of the history file
> 
> > o A way to flush the history would be nice.  "history flush"?
> 
> maybe
> 
> > 2)  Minor thing:  When I type "history", should the word "history" appear as 
> > the most recent entry?  It doesn't matter too much really, but somehow I feel 
> > it shouldn't be displayed.
> 
> sometimes you like to have in history, sometimes not; so I want to let it 
> in the history
> 
> ---
> PM
> 
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

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

Re: crashes using history

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

Petr Mikulik wrote:
>> The problem actually appears to be something that was sitting in the 
>> code for quite a while.
>> SourceForge bugs-report isn't working right now.  I've attached the patch
> 
> 
> I've committed it to cvs.
> 
> 
>> OK, now some comments.
>>
>> 1)  By shuffling around the command line entries when placing them in 
>> the history buffer, the history becomes inaccurate in a significant 
>> sense.  A user, especially a new one, will fret "Now what did I type 
>> to get that to work?".  He or she will look back at the history and 
>> see something that in no way reflects what was typed if there are 
>> repeat commands.
> 
> 
> It reflects all commands he has entered. By means of them, the last plot 
> can be easily reproduced.
> 
> The current behaviour saves his nerves using "up arrow" key to go always 
> through last 10 replot commands, for example.

Yeah, I can see how that would be nice.  Tossing out repeated commands helps, but it doesn't totally rid the issue of the command you want being far back in the history buffer.  That is sort of the reason for displaying the history.  There should be a way to quickly get the one command you see on the displayed list.  (Of course, in linux I can simply use the middle button of the mouse to grab that command.)  "hi 34 get" would be nice.


> Write your commands into a script file.
> Keep interactive editing easy.

That is what I do.  I've always found it easy to do that sort of thing.


>> Would it make sense to have an option for history:
>>
>> gnuplot> history # {linear | condensed}
> 
> 
> Maybe, if some people like the "linear".

How about this?  up-arrow key goes backward through *unique* history entries (current behavior), <SHIFT>-up-arrow key goes backward through all history.  That might be nice.  Is there a precedence for such a thing in readline types of scenarios?

Anyway, post 4.2 discussion...

Dan

Re: crashes using history

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

> The problem actually appears to be something that was sitting in the code for 
> quite a while.
> SourceForge bugs-report isn't working right now.  I've attached the patch

I've committed it to cvs.


> OK, now some comments.
>
> 1)  By shuffling around the command line entries when placing them in the 
> history buffer, the history becomes inaccurate in a significant sense.  A 
> user, especially a new one, will fret "Now what did I type to get that to 
> work?".  He or she will look back at the history and see something that in no 
> way reflects what was typed if there are repeat commands.

It reflects all commands he has entered. By means of them, the last plot can 
be easily reproduced.

The current behaviour saves his nerves using "up arrow" key to go always 
through last 10 replot commands, for example.


> the list, in order to do this little shuffling thing, one has to search back 
> through the history time and time again.  If the history buffer gets very 
> long with one unique command after another, that's a lot of horsepower going 
> to maintaining the buffer on a consistent basis.

There is a limit of 1000 commands stored in the history if I remember 
correctly, so there will be max 1000 times strcmp(). It will take much less 
time then drawing any graph or writing a character.

> tricks.  But losing the original sequence of things means we can never get 
> things back.

Write your commands into a script file.
Keep interactive editing easy.


> Would it make sense to have an option for history:
>
> gnuplot> history # {linear | condensed}

Maybe, if some people like the "linear".

> o Was the reason for the current behavior to make sure the history buffer 
> doesn't get so big?

No, see above.

> We should also have a "depth" option.

yes, and
 	set historyfile depth 0
would avoid saving (reading also?) of the history file

> o A way to flush the history would be nice.  "history flush"?

maybe

> 2)  Minor thing:  When I type "history", should the word "history" appear as 
> the most recent entry?  It doesn't matter too much really, but somehow I feel 
> it shouldn't be displayed.

sometimes you like to have in history, sometimes not; so I want to let it 
in the history

---
PM

Re: crashes using history

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

Bastian Maerkisch wrote:

>>Umm, I got one right away:
>>
>>gnuplot> hi
>>    1  (null)
>>Segmentation fault
>>
>>I'll investigate.
>>
> 
> 
> Thanks, I appreciate that. As I was the last to mess with the histroy stuff,
> the error was probably introduced by me.

The problem actually appears to be something that was sitting in the code for quite a while.  Did someone reactivate something recently to choose a different history?  (I think someone did, because I now have a history buffer I never had and I'm very happy for it.)

SourceForge bugs-report isn't working right now.  I've attached the patch here and will add it to S.F. later.

The problem, as I figure is when the user asked for a history length that was greater than the number entries in the history buffer.  In that case, "start" was never being set.

OK, now some comments.  I see this goes back a few weeks on the list and understand why the behavior is what it currently is.  But I have a concern with behavior and we might be able to resolve something here.

1)  By shuffling around the command line entries when placing them in the history buffer, the history becomes inaccurate in a significant sense.  A user, especially a new one, will fret "Now what did I type to get that to work?".  He or she will look back at the history and see something that in no way reflects what was typed if there are repeat commands.

The other thing I don't like is that when placing a command line entry into the list, in order to do this little shuffling thing, one has to search back through the history time and time again.  If the history buffer gets very long with one unique command after another, that's a lot of horsepower going to maintaining the buffer on a consistent basis.  Sure, it might be small compared to what gnuplot usually does, but my preference always leans toward efficiency.

Here is what I'd like to see to try and combine desires:

o The history buffer keeps a linear history of commands that have been entered.  That way, putting a new entry in the list is straightforward.

o With that, hitting the up arrow will have a nice memory.  I often use the up arrow in quick succession if I know how far back I want to recall commands.  How can I rely on that if the entries are being shuffled about?

o Even if the history buffer is linear, we can always make the display of that buffer behave just like it currently does with a few little programming tricks.  But losing the original sequence of things means we can never get things back.  Would it make sense to have an option for history:

gnuplot> history # {linear | condensed}

o Was the reason for the current behavior to make sure the history buffer doesn't get so big?  We should also have a "depth" option.  Otherwise the history buffer continues to grow, especially when it recalls the previous history from a file on startup.  A double linked-list might be good for that so we can dump things off the beginning of the list.

o We should keep track of the history length so that when "history #" is used for loops can break out right away rather than having to recompute the history length.

o A way to flush the history would be nice.  "history flush"?

o Some way of recalling a particular line into the command line buffer would be nice.  history 20 will display a nice view of recent history.  But if the command I want is 15 back I would have to hit the up arrow 15 times.  What sould be nice is if I could type "history 233 get" and it puts that command on the screen ready for me to hit return or use the arrow keys to edit it.


2)  Minor thing:  When I type "history", should the word "history" appear as the most recent entry?  It doesn't matter too much really, but somehow I feel it shouldn't be displayed.

Dan

Re: Build problem

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

Juergen Wieferink wrote:
> On Tuesday 27 June 2006 21:34 Timoth=E9e Lecomte wrote:
>  =20
>> Nevermind, this patch does not solve anything. I uninstalled pkg-confi=
g,
>> and can reproduce exactly your problem (AC_MSG_WARN undefined and
>> PKG_CHECK_MODULES with wrong syntax).
>>
>> However, I think I have found the right solution. As explained in
>> http://programming.linux.com/programming/05/08/11/1923248.shtml?tid=3D=
22
>> ("Best Practices with autotools"), we should always distribute the
>> macros we are using, because the user may have an old and buggy macro =
or
>> he may not have it at all.
>>
>> So the solution is to put 'pkg.m4' taken from the pkg-config package i=
n
>> <gnuplot source directory>/m4
>>
>> I have commited the file to the CVS.
>> Hardy and Juergen, can you try with the current CVS ?
>>    =20
>
> Yepp.  Works.  Great work, thanks!
>
> FWIW: If I understand correctly, you say that this problem occurs if
> there is no pkgconfig.  But actually, I have pkgconfig installed.
>  =20
Then, the pkg.m4 file that pkgconfig is supposed to install cannot be=20
found by autoconf. It should be in /usr/share/aclocal/pkg.m4 or=20
something like that depending on your distribution.

By the way, you can also look at the following line when executing=20
./configure saying :
    checking for pkg-config... /usr/bin/pkg-config

If it does not find the pkg-config program in your PATH, then your=20
pkg-config install has definitely a problem.

> OTOH the distribution (SuSE 9.3) is rather outdated:
>
> wiefer@localhost:~> rpm -qa |grep -i pkgconfig
> pkgconfig-0.15.0-201
>  =20
I checked in the pkg-config changelog, and this version should have=20
everything we need.
> 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
>  =20
Well, these are outdated (and by the way 2.5.x are development versions)=20
but they may be enough for the wxWidgets terminal.
> wiefer@localhost:~> rpm -qa |grep -i cairo
>  =20
That will be the main issue (once you solved your pkg-config problem) to=20
compile the wxWidgets terminal. If you really want to try it, you will=20
have to compile cairo from source (it has no dependency - at least none=20
of them is required for the wxWidgets terminal), and probably pango too,=20
unless you upgrade to suse 10.
> Thanks,
> Juergen
>  =20
Best regards,

Timoth=E9e

Re: Build problem

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

On Tuesday 27 June 2006 21:34 Timoth=E9e Lecomte wrote:
> Nevermind, this patch does not solve anything. I uninstalled pkg-config,
> and can reproduce exactly your problem (AC_MSG_WARN undefined and
> PKG_CHECK_MODULES with wrong syntax).
>
> However, I think I have found the right solution. As explained in
> http://programming.linux.com/programming/05/08/11/1923248.shtml?tid=3D22
> ("Best Practices with autotools"), we should always distribute the
> macros we are using, because the user may have an old and buggy macro or
> he may not have it at all.
>
> So the solution is to put 'pkg.m4' taken from the pkg-config package in
> <gnuplot source directory>/m4
>
> I have commited the file to the CVS.
> Hardy and Juergen, can you try with the current CVS ?

Yepp.  Works.  Great work, thanks!

=46WIW: If I understand correctly, you say that this problem occurs if
there is no pkgconfig.  But actually, I have pkgconfig installed.
OTOH the distribution (SuSE 9.3) is rather outdated:

wiefer@localhost:~> rpm -qa |grep -i pkgconfig
pkgconfig-0.15.0-201
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
wiefer@localhost:~> rpm -qa |grep -i cairo
wiefer@localhost:~>=20


Thanks,
Juergen

Re: [ 1004754 ] Tics and grid slightly outside border.

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

Ethan Merritt wrote:
> On Wednesday 28 June 2006 08:07 am, Petr Mikulik wrote:
> 
>>>I've placed a patch under bug report [ 1004754 ] on SourceForge
>>>that is a cleanup of the tic generation.  I think it would be worth
>>>considering for 4.2, because it does fix the bug and it is much
>>>friendlier computer math
>>
>>I propose to commit it.
>>
>>Notes: "logorithm" => "logarithm"
> 
> 
> I have not analyzed the code itself, and don't have time to 
> do so right now.  But the cover explanation contains an 
> off-by-one error in the algorithm, so I worry that it is not
> correct.

That is fine in this new layout.  It's explained in the note.  (But if you are uncomfortable with it, leave it out for now.)

I will use [ ] to signify range (i.e., lmin and lmax), and I will use T to be major tic and t to be minor tic.


             [                           ]

t       T       t       t       t       t       T       t

        ^                                       ^
      start                                   outside

i_tic=  0       0       0       0       0       1       1     ...



The scheme is to first "integerize" the major tics where "start" will be the case of i_tic = 0.  (I should say, that we don't round the upper limit upward anymore, but downward because if it is outside of the range, it isn't printed.)  In this case N_start and N_end are the same.  We only need one interval and minor tics.

Imagine the case of moving that upper range "]" so that it equals a major tic.  Well in that case, with the rounding downward (floor) it will be that N_end = N_start + 1, and we'll get two intervals of major tic and minor tics.  (The minor tics will be outside the range and not printed, but that is the idea.)

Dan

Re: crashes using history

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

Daniel J Sebald wrote:
> Petr Mikulik wrote:
>>> I am experiencing spurious crashes here when using
>>> history command recall, e.g. the sequence
>>>
>>> hi !cd
>>> hi !load
>>> hi !load
>>>
>>> makes wgnuplot segfault (sometimes) independent of the script loaded.=

>>> Has anybody else seen behaviour like that?
>>> I'm using the latest CVS snapshot compiled with makefile.nt (MSVC 6)
>>> on Windows XP and gnuplot's built-in readline library.
>>
>> I don't see this on Linux with neither gnuplot's or GNU readline.
>=20
> Umm, I got one right away:
>=20
> gnuplot> hi
>     1  (null)
> Segmentation fault
>=20
> I'll investigate.
>=20

Thanks, I appreciate that. As I was the last to mess with the histroy stu=
ff,
the error was probably introduced by me.

Btw. I compiled wgnuplot with GNUPLOT_HISTORY defined and my history wasn=
't empty (obviously).

Bastian

> Dan
>=20




--=20
Bastian M=E4rkisch
Physikalisches Institut, Universit=E4t Heidelberg
Philosophenweg 12
69120 Heidelberg
Tel.: +49-6221-549239
Fax: +49-6221-549343

Re: [ 1004754 ] Tics and grid slightly outside border.

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

Petr Mikulik wrote:
>> I've placed a patch under bug report [ 1004754 ] on SourceForge that 
>> is a cleanup of the tic generation.  I think it would be worth 
>> considering for 4.2, because it does fix the bug and it is much 
>> friendlier computer math
> 
> 
> I propose to commit it.
> 
> Notes: "logorithm" => "logarithm"
> 
> (I wish also the "rounding" plot [-1:1] patch...)

It's up to Ethan and Hans, depending on how things are honing in on 4.2.  It sounds like Ethan wants to only get the most obvious of bugs with a few lines diff at this point.

I would like to see it considered right after 4.2 though.  In general, looking through the bug list, I can see that time data and tics is going to be an issue.  With the way time data currently works (setting the minitic to a certain value rather than a fraction of the major tic) suggests to me that minitics will have to be the basis in that case, not the other way around.

So, before revisiting time data tics, this patch should be considered.

I'll look for the misspelling "logorithm".

Dan

Re: crashes using history

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

Petr Mikulik wrote:
>>I am experiencing spurious crashes here when using
>>history command recall, e.g. the sequence
>>
>>hi !cd
>>hi !load
>>hi !load
>>
>>makes wgnuplot segfault (sometimes) independent of the script loaded.
>>Has anybody else seen behaviour like that?
>>I'm using the latest CVS snapshot compiled with makefile.nt (MSVC 6)
>>on Windows XP and gnuplot's built-in readline library.
> 
> 
> I don't see this on Linux with neither gnuplot's or GNU readline.

Umm, I got one right away:

gnuplot> hi
    1  (null)
Segmentation fault

I'll investigate.

Dan

Re: [ 1004754 ] Tics and grid slightly outside border.

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

On Wednesday 28 June 2006 08:07 am, Petr Mikulik wrote:
> > I've placed a patch under bug report [ 1004754 ] on SourceForge
> > that is a cleanup of the tic generation.  I think it would be worth
> > considering for 4.2, because it does fix the bug and it is much
> > friendlier computer math
>
> I propose to commit it.
>
> Notes: "logorithm" => "logarithm"

I have not analyzed the code itself, and don't have time to 
do so right now.  But the cover explanation contains an 
off-by-one error in the algorithm, so I worry that it is not
correct.

> number of intervals, N_int
>    /* Address rounding issues in the following way */
>    if (i_tic == (N_int - 1))
>	tic = end;
>    else
>	tic = start + i_tic * step;

This is an off-by-one error, an instance of the "fencepost problem".
The obvious case is when there is one interval, so (N_int-1) == 0 ,
and the above code puts both tics at the same end of the axis.












>
> (I wish also the "rounding" plot [-1:1] patch...)
>
> ---
> PM
>
>
> Using Tomcat but need to do more? Need to support web services,
> security? Get stuff done quickly with pre-integrated technology to
> make your job easier Download IBM WebSphere Application Server
> v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121
>642 _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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

Re: [ 1004754 ] Tics and grid slightly outside border.

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

> I've placed a patch under bug report [ 1004754 ] on SourceForge that is a 
> cleanup of the tic generation.  I think it would be worth considering for 
> 4.2, because it does fix the bug and it is much friendlier computer math

I propose to commit it.

Notes: "logorithm" => "logarithm"

(I wish also the "rounding" plot [-1:1] patch...)

---
PM

Re: crashes using history

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

> I am experiencing spurious crashes here when using
> history command recall, e.g. the sequence
>
> hi !cd
> hi !load
> hi !load
>
> makes wgnuplot segfault (sometimes) independent of the script loaded.
> Has anybody else seen behaviour like that?
> I'm using the latest CVS snapshot compiled with makefile.nt (MSVC 6)
> on Windows XP and gnuplot's built-in readline library.

I don't see this on Linux with neither gnuplot's or GNU readline.

---
PM