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

Re: Patches item #1729825 ready to go.

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

> Another reason for keeping the stack always in order as typed is so that
> the up-arrow recall maintains an order.  (Often a lot of my patterns at the
> linux command line are derived from how many times I hit up-arrow to recall
> a command... easier to do than describe.)

Would this even allow an implementation of the C-o sequence in bash
(enter line + go to next history item)?  This command sequence is
really nice because it saves you from counting up-arrows.  This
would be *too* nice!

Juergen

Re: Patches item #1729825 ready to go.

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

> I thought it was just an annoying bug that some of my commands seemed to 
> disappear. I never figured out any rhyme or reason to it.
>
> I strongly request that the default history behaviour is to leave
> all my commands in place.  I would consider this a bug-fix.
>
> I want it to behave like the csh [and tcsh and bash] history commands.
> Go with what the users expect.

I'm strongly against your proposal.

Well, it was my first patch to gnuplot ages ago, to remove the repeated 
commands from the stack. I was so upset in a long night experiment at the 
ESRF having to hit dozen of times up-arrow before the actual plotting 
command appeared, that I started hacking gnuplot...

I never used history to report what exactly I was doing. I need it to 
quickly go through the commands and have them available for editing, or with 
the "history" command to paste them via mouse.

---
PM

Re: Quick refresh [was: q for quit in plot windows]

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

Daniel J Sebald wrote:
>  >   - refresh of "with image" styles produces garbage
>  >     So far I can't figure out why.
>  >     Daniel, maybe you can see what I'm overlooking?
> 
> I'll look when I get the chance.  Will be gone this weekend.

I'm going through the image.dem and image2.dem examples and data seems to be 
reloaded correctly.  The only thing I've seen so far is:

set title "Convex     November 1-7 1989    Circadian"
set key left box
set xrange[-1:24]
plot 'using.bin' binary format='%*int32%int8%*int16%int8%*int16%*int16' using 
1:2 title "Logged in" with impulses,\
      'using.bin' binary format='%*int32%int8%*int16%int8%*int16%*int16' using 
1:2 title "Logged in" with points

will "replot" looking exactly the same, but will "refresh" with the y scale as 
0,10,20,30,40,50 rather than 0,5,10,15,20,25,30,35,40,45,50.

Same is true of the example following it.


There is another example in image2 that acts funny, but I don't think it has 
anything to do with images.  Try the following

plot x
set xrange [10:-10]
replot
refresh

and I see that the range goes back to its original orientation.  (Perhaps this 
is the same issue as the previous noted problem.)


I've also seen a bug or ILOTWIO with multiplot.  Try the following

plot x; pause -1

And the plot appears, then there is a pause.  However, try the following

set multiplot layout 2,1
plot x; pause -1

and the plot doesn't appear until after the user breaks out of the pause.

Dan

Re: gnuplot-beta Digest, Vol 12, Issue 10

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

On Monday 04 June 2007 13:14, Ethan Merritt wrote:
> On Sunday 03 June 2007 19:48, m sutton wrote:
> > I would like a couple of my patches to be considered for inclusion into CVS:
> > 
> >  1659135  	  dashed grid for GD term to accept linewidths
> 
> OK, that's better than the earlier version.

On closer inspection, I'm not entirely happy.
This line:

        static int png_linetype_dotted[MAXLINEWIDTH*MAXLINEWIDTH*5];

ties up 0.2 MByte permanently, on the off-chance that we want
to change the grid width.  Yeah I know, virtual memory is cheap these days.
But it's ugly.  Doesn't 200,000,000 bytes of storage to specify
a 2+3 dot pattern seem a little outrageous?

My reading of the libgd docs is that there is no need for static arrays.
I quote:

    As of version 1.1.1, the style array is copied when you set 
    the style, so you need not be concerned with keeping the 
    array around indefinitely. 

Can't you do something like:

        if (lw != last_lw) {
            int i;
            int psize = lw*lw*2;
            int ssize = lw*lw*5;
            int *png_linetype_dotted = gp_alloc( 5*lw*lw*sizeof(int), "dots");

            /* Fill style with with color then transparent.
             * The style is 2 on / 3 off and scales with linewidth.
             */
            for(i = 0;i < psize; i++)
                png_linetype_dotted[i] = png_state.color;
            for (;i < ssize; i++)
                png_linetype_dotted[i] = gdTransparent;
            gdImageSetStyle(png_state.image, png_linetype_dotted, ssize);
            free(png_linetype_dotted);
            last_lw = lw;
        }

This seems to work, but I haven't tested extensively

-- 
Ethan A Merritt

genopt.com/getcolor.h

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

src/getcolor.h is downloaded from CVS as being executable files.

src/genopt.com is hightlighted on my system as being executable but isn't so 
listed using "ls".  Perhaps the "com" extension is some old standard for 
executable files?

Dan

Re: Patches item #1729825 ready to go.

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

On Monday 04 June 2007 15:30, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> 
> > I strongly request that the default history behaviour is to leave
> > all my commands in place.  I would consider this a bug-fix.
> 
> I'll put a patch together this evening with options (default numbered and 
> non-condensed).  Simple changes.
> 
> So, would you also want that if the current command is exactly the same as the 
> previous (and just the previous, no later) *then* it is not put in the history 
> stack?

I want it to behave like the csh [and tcsh and bash] history commands.
Go with what the users expect.

-- 
Ethan A Merritt

Re: Patches item #1729825 ready to go.

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

Ethan Merritt wrote:
> On Monday 04 June 2007 15:19, Daniel J Sebald wrote:
> 
>>Daniel J Sebald wrote:
>>
>>
>>>Well, it could be programmed that way [but what user keeps typing replot; replot 
>>>without making any changes in between? :-)].  The "do not put redundant commands 
>>>in the history stack" as gnuplot currently behaves has the same problem you're 
>>>pointing out.
>>
>>Keep in mind with an option
>>
>>   set history {full|condensed} {quiet|numbered}
>>
>>it could be
>>
>>   1 foo = 35
>>   2 plot x*foo
>>   3 foo = 25
>>   4 plot x*foo
>>   5 history
>>   6 foo = 20
>>   7 plot x*foo
>>   8 history
>>
>>or
>>
>>   1 foo = 35
>>   3 foo = 25
>>   6 foo = 20
>>   7 plot x*foo
>>   8 history
> 
> 
> The logic here escapes me.
> Why are the "plot x*foo" commands any more redundant than the
> "foo = baz" commands?

No argument here.

Another reason for keeping the stack always in order as typed is so that the 
up-arrow recall maintains an order.  (Often a lot of my patterns at the linux 
command line are derived from how many times I hit up-arrow to recall a 
command... easier to do than describe.)


   Even apart from the fact that one version
> can produce 3 windows on my screen, and the other only 1, what
> happens if "foo" has side-effects?  These two sequences of
> commands are not equivalent.
> 
> OK, I can understand not putting the "history" command on the
> history stack.  But everything else should remain visible.

Could do that easily.  In the above case everything is still on the stack, it's 
just how the stack is displayed.  I know you might not like it, but Petr does 
and so might others.

Dan

Re: Patches item #1729825 ready to go.

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

Ethan Merritt wrote:
> On Monday 04 June 2007 15:14, Daniel J Sebald wrote:
> 
>>>I don't like it at all.
>>>
>>>If I want the history, then I want it to show all the
>>>commands I issued, in the order they were issued.  The condensed
>>>form you show above would not let me determine from the history
>>>command what was the value of 'foo' when I made the most recent
>>>plot.  It's one thing to remove a series of "replot; replot; replot..."
>>>commands, since nothing changes between them.  But your example
>>>is hiding important changes.
>>
>>Well, it could be programmed that way [but what user keeps typing replot; replot 
>>without making any changes in between? :-)].
> 
> 
> Anyone who closes the plot window to do something else for a while?
> To get it back again, he types "replot".  I do this all the time.

True.


>>The "do not put redundant commands  
>>in the history stack" as 
> 
> 
> But your example has no redundant commands!  You are erasing
> commands that had a real effect on the contents of my screen.

Just going with current behavior (and as I pointed out, it made a tough time of 
keeping track of what was tossed out).


>>gnuplot currently behaves has the same problem you're  
>>pointing out.
> 
> 
> Ah, so maybe that's the reason I always found history to be
> unreliable.  I thought it was just an annoying bug that some of my
> commands seemed to disappear. I never figured out any rhyme or
> reason to it.

Yes, that's it.


> I strongly request that the default history behaviour is to leave
> all my commands in place.  I would consider this a bug-fix.

I'll put a patch together this evening with options (default numbered and 
non-condensed).  Simple changes.

So, would you also want that if the current command is exactly the same as the 
previous (and just the previous, no later) *then* it is not put in the history 
stack?

Dan

Re: Patches item #1729825 ready to go.

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

On Monday 04 June 2007 15:19, Daniel J Sebald wrote:
> Daniel J Sebald wrote:
> 
> > Well, it could be programmed that way [but what user keeps typing replot; replot 
> > without making any changes in between? :-)].  The "do not put redundant commands 
> > in the history stack" as gnuplot currently behaves has the same problem you're 
> > pointing out.
> 
> Keep in mind with an option
> 
>    set history {full|condensed} {quiet|numbered}
> 
> it could be
> 
>    1 foo = 35
>    2 plot x*foo
>    3 foo = 25
>    4 plot x*foo
>    5 history
>    6 foo = 20
>    7 plot x*foo
>    8 history
> 
> or
> 
>    1 foo = 35
>    3 foo = 25
>    6 foo = 20
>    7 plot x*foo
>    8 history

The logic here escapes me.
Why are the "plot x*foo" commands any more redundant than the
"foo = baz" commands?  Even apart from the fact that one version
can produce 3 windows on my screen, and the other only 1, what
happens if "foo" has side-effects?  These two sequences of
commands are not equivalent.

OK, I can understand not putting the "history" command on the
history stack.  But everything else should remain visible.


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

Re: Patches item #1729825 ready to go.

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

On Monday 04 June 2007 15:14, Daniel J Sebald wrote:
> > I don't like it at all.
> > 
> > If I want the history, then I want it to show all the
> > commands I issued, in the order they were issued.  The condensed
> > form you show above would not let me determine from the history
> > command what was the value of 'foo' when I made the most recent
> > plot.  It's one thing to remove a series of "replot; replot; replot..."
> > commands, since nothing changes between them.  But your example
> > is hiding important changes.
> 
> Well, it could be programmed that way [but what user keeps typing replot; replot 
> without making any changes in between? :-)].

Anyone who closes the plot window to do something else for a while?
To get it back again, he types "replot".  I do this all the time.

> The "do not put redundant commands  
> in the history stack" as 

But your example has no redundant commands!  You are erasing
commands that had a real effect on the contents of my screen.

> gnuplot currently behaves has the same problem you're  
> pointing out.

Ah, so maybe that's the reason I always found history to be
unreliable.  I thought it was just an annoying bug that some of my
commands seemed to disappear. I never figured out any rhyme or
reason to it.

I strongly request that the default history behaviour is to leave
all my commands in place.  I would consider this a bug-fix.

-- 
Ethan A Merritt

Re: Patches item #1729825 ready to go.

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

Daniel J Sebald wrote:

> Well, it could be programmed that way [but what user keeps typing replot; replot 
> without making any changes in between? :-)].  The "do not put redundant commands 
> in the history stack" as gnuplot currently behaves has the same problem you're 
> pointing out.

Keep in mind with an option

   set history {full|condensed} {quiet|numbered}

it could be

   1 foo = 35
   2 plot x*foo
   3 foo = 25
   4 plot x*foo
   5 history
   6 foo = 20
   7 plot x*foo
   8 history

or

   1 foo = 35
   3 foo = 25
   6 foo = 20
   7 plot x*foo
   8 history

Dan

Re: Segfaults on exit - something has messed up recent CVS

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

> For the last week or so I've been getting a double-free warning
> message from glibc every time I exit gnuplot with the current driver
> set to wxt.  This was non-fatal, although it did mean
> that the history file was not updated.
>
> As of today this has gotten much worse. It no longer happens every
> time I exit, but if it does happen then it causes a core dump:
>
> (<unknown>:1881): GLib-GObject-WARNING **: instance of invalid
> non-instantiatable type `-g-type-private--GTypeFlags'
>
> (<unknown>:1881): GLib-GObject-CRITICAL **:
> g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE
> (instance)' failed
(...)
>
>
> The only recent patch I see is:
> 2007-06-03  Petr Mikulik  <mi...@ph...>
> * src/history.c (write_history_n): Cannot use int_error() when exiting
> gnuplot.
>
> I don't understand how this would make things worse than before,
> but I don't see any other candidate patches.
>
> Is anyone else seeing this?   Any ideas why?

I see it, and I must be the one to blame, not Petr.

2007-05-23  Timothee Lecomte  <tim...@en...>

        * src/wxterminal/wxt_gui.cpp:
        * src/wxterminal/wxt_gui.h:
        Add/rewrite a few debugging messages.
        (wxt_atexit, wxt_cleanup): Simplify "persist" and exit code.


I'll look at it tomorrow. Thanks for reporting.

Best regards,

Timothée

>
> --
> Ethan A Merritt
>

Re: Patches item #1729825 ready to go.

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

Ethan Merritt wrote:
> On Monday 04 June 2007 14:54, Daniel J Sebald wrote:
> 
>>Let me toss this idea to Petr... What would you think of instead of removing 
>>items from the stack, say the user types
>>
>>foo = 35
>>plot x*foo
>>foo = 25
>>plot x*foo
>>history
>>foo = 20
>>plot x*foo
>>history
>>
>>and the result of the final history might be
>>
>>  1 foo = 35
>>  2 plot x*foo
>>  3 foo = 25
>>  6 foo = 20
>>  8 history
>>
>>For a more condensed appearance?
> 
> 
> I don't like it at all.
> 
> If I want the history, then I want it to show all the
> commands I issued, in the order they were issued.  The condensed
> form you show above would not let me determine from the history
> command what was the value of 'foo' when I made the most recent
> plot.  It's one thing to remove a series of "replot; replot; replot..."
> commands, since nothing changes between them.  But your example
> is hiding important changes.

Well, it could be programmed that way [but what user keeps typing replot; replot 
without making any changes in between? :-)].  The "do not put redundant commands 
in the history stack" as gnuplot currently behaves has the same problem you're 
pointing out.

Dan

Re: Segfaults on exit - something has messed up recent CVS

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

> For the last week or so I've been getting a double-free warning
> message from glibc every time I exit gnuplot with the current driver
> set to wxt.  This was non-fatal, although it did mean
> that the history file was not updated.
>
> As of today this has gotten much worse. It no longer happens every
> time I exit, but if it does happen then it causes a core dump:
>
> (<unknown>:1881): GLib-GObject-WARNING **: instance of invalid
> non-instantiatable type `-g-type-private--GTypeFlags'
>
> (<unknown>:1881): GLib-GObject-CRITICAL **:
> g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE
> (instance)' failed

(...)
>
>
> The only recent patch I see is:
> 2007-06-03  Petr Mikulik  <mi...@ph...>
> * src/history.c (write_history_n): Cannot use int_error() when exiting
> gnuplot.
>
> I don't understand how this would make things worse than before,
> but I don't see any other candidate patches.

Don't blame Petr for his commit, it is correct, and I think I must be the
one to blame here with:

2007-05-23  Timothee Lecomte  <tim...@en...>

        * src/wxterminal/wxt_gui.cpp:
        * src/wxterminal/wxt_gui.h:
        Add/rewrite a few debugging messages.
        (wxt_atexit, wxt_cleanup): Simplify "persist" and exit code.


>
> Is anyone else seeing this?   Any ideas why?
>

I do see it. I'll look at it tomorrow evening. Thanks for reporting !

Best regards,

Timothée

> --
> Ethan A Merritt
>

Re: Touchup of history.c

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

Timothée Lecomte wrote:
>>>The other day Petr made a change to rid the int_error() function.
>>>Rather than
>>>putting "Warning:" in the printf, could the int_warn() function be used
>>>as in
>>>the attached patch instead?
>>
>>>gnuplot-history/src/history.c
>>>- fprintf(stderr, "Warning: cannot open file %s for saving the
>>>history.", filename);
>>>+ int_warn(NO_CARET, "cannot open file %s for saving the history.",
>>>filename);
>>
>>Yes, it seems to work.
>>Is it needed to change it?
>>
> 
> 
> Those two are equivalent.int_warn() with NO_CARET is like fprint(stderr,...)
> I personally would keep the fprintf as we immediately see what it's doing.
> int_warn is more for cases when user input (i.e. a command line) is involved.

I'll go with that logic.

Dan

Re: Patches item #1729825 ready to go.

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

Petr Mikulik wrote:
>>Let me toss this idea to Petr... What would you think of instead of removing 
>>items from the stack, say the user types
>>
>>foo = 35
>>plot x*foo
>>foo = 25
>>plot x*foo
>>history
>>foo = 20
>>plot x*foo
>>history
>>
>>and the result of the final history might be
>>
>>  1 foo = 35
>>  2 plot x*foo
>>  3 foo = 25
>>  6 foo = 20
>>  8 history
> 
> 
> no, plot x*foo will be the last.

You're right, that's what I indended.  Actually, the "history" would still be 
last as we are placing stuff in history, then processing, so it'd be

   1 foo = 35
   3 foo = 25
   6 foo = 20
   7 plot x*foo
   8 history

We place stuff in history first before processing so that the user can recall a 
command even if it failed (because of a one letter typo or something).

I can make that change in the patch.  I like that approach.

Dan

Re: Patches item #1729825 ready to go.

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

On Monday 04 June 2007 14:54, Daniel J Sebald wrote:
> Let me toss this idea to Petr... What would you think of instead of removing 
> items from the stack, say the user types
> 
> foo = 35
> plot x*foo
> foo = 25
> plot x*foo
> history
> foo = 20
> plot x*foo
> history
> 
> and the result of the final history might be
> 
>   1 foo = 35
>   2 plot x*foo
>   3 foo = 25
>   6 foo = 20
>   8 history
> 
> For a more condensed appearance?

I don't like it at all.

If I want the history, then I want it to show all the
commands I issued, in the order they were issued.  The condensed
form you show above would not let me determine from the history
command what was the value of 'foo' when I made the most recent
plot.  It's one thing to remove a series of "replot; replot; replot..."
commands, since nothing changes between them.  But your example
is hiding important changes.

-- 
Ethan A Merritt

Re: Touchup of history.c

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

>> The other day Petr made a change to rid the int_error() function.
>> Rather than
>> putting "Warning:" in the printf, could the int_warn() function be used
>> as in
>> the attached patch instead?
>
>> gnuplot-history/src/history.c
>> - fprintf(stderr, "Warning: cannot open file %s for saving the
>> history.", filename);
>> + int_warn(NO_CARET, "cannot open file %s for saving the history.",
>> filename);
>
> Yes, it seems to work.
> Is it needed to change it?
>

Those two are equivalent.int_warn() with NO_CARET is like fprint(stderr,...)
I personally would keep the fprintf as we immediately see what it's doing.
int_warn is more for cases when user input (i.e. a command line) is involved.

Best regards,

Timothée

> ---
> PM

Re: Patches item #1729825 ready to go.

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

> Let me toss this idea to Petr... What would you think of instead of removing 
> items from the stack, say the user types
> 
> foo = 35
> plot x*foo
> foo = 25
> plot x*foo
> history
> foo = 20
> plot x*foo
> history
> 
> and the result of the final history might be
> 
>   1 foo = 35
>   2 plot x*foo
>   3 foo = 25
>   6 foo = 20
>   8 history

no, plot x*foo will be the last.

---
PM

Re: Touchup of history.c

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

> The other day Petr made a change to rid the int_error() function.  Rather than
> putting "Warning:" in the printf, could the int_warn() function be used as in
> the attached patch instead?

> gnuplot-history/src/history.c
> - fprintf(stderr, "Warning: cannot open file %s for saving the history.", filename);
> + int_warn(NO_CARET, "cannot open file %s for saving the history.", filename);

Yes, it seems to work.
Is it needed to change it?

---
PM

Re: Quick refresh [was: q for quit in plot windows]

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

Ethan Merritt wrote:
> On Monday 04 June 2007 14:45, you wrote:
> 
>>>You've got to be able to tell it that somehow, and that's kind of
>>>hard to do without mention the name of the command you want it to use.
>>
>>"set datafile reread/noreread" would accomplish the same thing.  (I'm 
>>considering '-' a datafile (in-line).)
> 
> 
> But that makes it seem like it's a property of the data file [*].
> It isn't.  It's a question of mouse interactions and hot keys.
> That's why I suggested "set mouse ..."
> 
> Actually, I'd much rather have a mechanism that *was* tied to
> specific data files.  That way you could mark a particular
> data file as volatile, or not re-readable.

I too thought of individual file behavior, but I then thought that would only 
complicate matters but that may be an incorrect assumption.

Dan

Re: Patches item #1729825 ready to go.

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

Let me toss this idea to Petr... What would you think of instead of removing 
items from the stack, say the user types

foo = 35
plot x*foo
foo = 25
plot x*foo
history
foo = 20
plot x*foo
history

and the result of the final history might be

  1 foo = 35
  2 plot x*foo
  3 foo = 25
  6 foo = 20
  8 history

For a more condensed appearance?  Everything could function just as it normally 
does as this might simply be a display option

set history condensed

(btw, "quiet" should also be an option... who wants to keep type "history quiet 
10"?)

Dan

Re: Quick refresh [was: q for quit in plot windows]

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

On Monday 04 June 2007 14:45, you wrote:
> > You've got to be able to tell it that somehow, and that's kind of
> > hard to do without mention the name of the command you want it to use.
> 
> "set datafile reread/noreread" would accomplish the same thing.  (I'm 
> considering '-' a datafile (in-line).)

But that makes it seem like it's a property of the data file [*].
It isn't.  It's a question of mouse interactions and hot keys.
That's why I suggested "set mouse ..."

Actually, I'd much rather have a mechanism that *was* tied to
specific data files.  That way you could mark a particular
data file as volatile, or not re-readable.  That would free me
from having to make this quick refresh mode work for all 
possible mixtures of plots simultaneously, which is a headache.
But so far I have not figured out a way to do that.

The decision is made at a higher level:  either we re-parse
and re-execute the plot command line, re-reading files as we go,
or we skip that whole operation and go with what's already in
the plot data structures.  It's all or none.

[*] In fact it works the same way for functions, although that's
an unintended side-effect.

-- 
Ethan A Merritt

Re: Quick refresh [was: q for quit in plot windows]

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

Ethan Merritt wrote:

>>To have a "refresh" command and then have "refresh" an option somewhere is 
>>getting along the lines of the "hidden3d" and "pm3d hidden3d" option confusion.
> 
> 
> Huh?  What option?
> 
> There would be two commands.  I am not wedded to calling the new one "refresh",
> but let's go with that for the moment.
> replot	= re-read the data and plot all over again
> refresh	= don't reread the data, but update the plot with new limits+labels+etc

Fine for now.  I'm not strongly pitching "set datafile reread".  I'm simply 
wondering how users might like this oft-used command.  Would some be happier to 
set an option and have "replot" to mean reread the data and all.  E.g., Octave 
users have asked for gnuplot to simply reread data.  No mention of an alternate 
command.  I guess it is a question of both "replot" and "refresh" commonly used 
to go back and forth, or simply be in one mode and stay that way.

> If you're typing from the command line, no problem.
> You just pick whichever of the two commands you want.
> The issue is what happens under the hood when a mouse operation,
> in particular zooming, needs to redraw the plot.  
> Does it use "refresh" or does it use "replot"?
> You've got to be able to tell it that somehow, and that's kind of
> hard to do without mention the name of the command you want it to use.

"set datafile reread/noreread" would accomplish the same thing.  (I'm 
considering '-' a datafile (in-line).)

No strong feelings either way, just kind of tossing the alternatives around...

Dan

Re: Patches item #1729825 ready to go.

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

Ethan Merritt wrote:
> On Monday 04 June 2007 13:31, Daniel J Sebald wrote:
> 
>>1) Help now resolves keywords individually as opposed to a whole line of text 
>>(i.e., things like "help se ter post" are understood).  The algorithm goes with 
>>most matching characters as the "winning" help line, and if there is a tie then 
>>it is the most number of whole matches.
> 
> 
> Sounds good. Let's see if it survives stress-testing.
>  
> 
>>2) History is much more robust to recursion detection.  I went with an algorithm 
>>that will complain if every a command off the history stack is run more than 
>>once in a series of history recalls.  For example
>>
>>plot x; hist !plot
>>plot x; hist !plot
> 
> 
> I cannot imagine anyone having a legitimate reason for issuing such a command.
> Can't we just forbid commands of the form "hist !command" unless they are the
> first and only thing on the line?
> 
> In fact, I can't think of a reason to ever allow a "hist" command except
> at the beginning of a line.  Why would you want to do this? 

Well, you're changing the target then.  Before it was suggested to ignore 
"history !hist" if it is in the middle, so that the rest of the line could be 
executed.  Limiting history in that way, i.e., just first command, seems like 
unnecessary conditional code.  That is, there's little difference between

myparam=50; hist !plot

and

myparam=50
hist !plot

Why should the user be restricted from using the first syntax and not the second?

Even still, once we put conditional restrictions in this way, all of a sudden 
the coding becomes worse than this general, more robust idea.  The general 
approach just simply identifies an recursive behavior and lets the user figure 
out what it was.


> 
> 
>>3) History now has recall by number, e.g., "hist !123".  A bit tricky to 
>>implement given the shuffling behavior we have, but I think I've got it.  (No 
>>sense in numbering the stack if we can't recall by number.)
> 
> 
> Does that number stay constant?

Yes (but no), it tries to maintain the same numbered sequence, and it would if 
not for the shuffling.

   I.e., if I go to the trouble of figuring
> out that some complicated upstream command was "!123",  will that still be
> true 10 minutes later after various intervening commands?   If not, then
> this option is a non-starter.


> >>Note, as far as shuffling it would be easy to make an option for that.  I point 
>>this out because if someone is using recall by number, shuffling of the stack 
>>can cause a problem.
> 
> 
> Er, why are we shuffling the stack?

I'm not a fan of it, but the idea was to condense the stack by removing 
redundancy.  ("shuffling" is my expression for taking out redundant history.) 
The stack stays more condensed that way so one can see more non-redundant commands.

Actually, another way of doing this, rather than shuffling around the stack, 
would be to rewright the "write_history_n" routine so that it keeps all 
numbering the same, but doesn't display those numbers in the stack that are the 
same as some command higher than it.  (Wish I would have thought of that 
sooner.)  To keep it from being an order N^2 sort of thing, we'd simply search 
the stack in history_add() for similar commands and keep a pointer along as part 
of the data for the history entry.

Would that work better?  (I like it.)

Dan