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