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