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

Re: 'with pixels' (was Re: Engines are started; ...)

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

Ethan Merritt wrote:

>On Friday 09 July 2004 09:52 am, Daniel J Sebald wrote:
>  
>
>>Hans-Bernhard Broeker wrote:
>>    
>>
>>>  I would prefer just adding the new arguments unconditionally.
>>>      
>>>
>>You must be referring to the df_open() function:
>>
>>int
>>#ifdef BINARY_DATA_FILE
>>df_open(int max_using, int plot_mode)
>>#else
>>df_open(int max_using)
>>#endif
>>{
>>    
>>
>
>With regard to the df_* functions in particular, I hit the same problem
>of the plot information not being easily available.  See this comment
>in plot2d.c:
>
>#ifdef EAM_HISTOGRAMS
>    /* EAM FIXME - There are places in df_readline where it would be really */
>    /* nice to know what kind of plot we are making, so I think that        */
>    /* current_plot should be a parameter to df_readline. For now, however, */
>    /* I am using a global variable, and only for HISTOGRAMS.               */
>    df_current_plot = (current_plot->plot_style == HISTOGRAMS) ? current_plot : NULL;
>#endif
>
>
>I do not like the idea of extending any of the df_* functions to add only a
>single value like plot_mode.  I would, however, support the idea of adding
>a pointer to the plot itself.  E.g.
>
>df_readline(double v[], int max, struct curve_points *current_plot)
>df_open(int max_using, struct curve_points *current_plot)
>

Such that the information in question can be had inside df_readline and 
df_open with something like

if (current_plot->plot_type == SPLOT) {
}

?  Or however it is organized.  That's just as well.

Dan

Re: 'with pixels' (was Re: Engines are started; ...)

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

On Friday 09 July 2004 09:52 am, Daniel J Sebald wrote:
> Hans-Bernhard Broeker wrote:
> >   I would prefer just adding the new arguments unconditionally.
>
> You must be referring to the df_open() function:
>
> int
> #ifdef BINARY_DATA_FILE
> df_open(int max_using, int plot_mode)
> #else
> df_open(int max_using)
> #endif
> {

With regard to the df_* functions in particular, I hit the same problem
of the plot information not being easily available.  See this comment
in plot2d.c:

#ifdef EAM_HISTOGRAMS
    /* EAM FIXME - There are places in df_readline where it would be really */
    /* nice to know what kind of plot we are making, so I think that        */
    /* current_plot should be a parameter to df_readline. For now, however, */
    /* I am using a global variable, and only for HISTOGRAMS.               */
    df_current_plot = (current_plot->plot_style == HISTOGRAMS) ? current_plot : NULL;
#endif


I do not like the idea of extending any of the df_* functions to add only a
single value like plot_mode.  I would, however, support the idea of adding
a pointer to the plot itself.  E.g.

df_readline(double v[], int max, struct curve_points *current_plot)
df_open(int max_using, struct curve_points *current_plot)



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: 'with pixels' (was Re: Engines are started; ...)

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

Hans-Bernhard Broeker wrote:

>>2)  There are some messages in the patch that come up the first time a 
>>feature is used that eventually can be weeded out. 
>>    
>>
>
>Please turn all of them into calls of our usual debugging macro
>FPRINTF() soon.  We don't really want or need developer debug print out
>in the regular build that serve no purpose to the ordinary user.
>

OK.

>I'm not terribly happy with some of the changes.  Especially those where
>the signature of old gnuplot functions is extended conditionally. I think
>we've learned from PM3D that this generally doesn't work out well in the
>long run.  I would prefer just adding the new arguments unconditionally.
>

You must be referring to the df_open() function:

==========

int
#ifdef BINARY_DATA_FILE
df_open(int max_using, int plot_mode)
#else
df_open(int max_using)
#endif
{

#ifdef BINARY_DATA_FILE
        specs = df_open(MAXDATACOLS, MODE_PLOT);    /* up to MAXDATACOLS 
cols */
#else
        specs = df_open(MAXDATACOLS);    /* up to MAXDATACOLS cols */
#endif

==========

I tried very hard to not do that.  I resist using global variables 
across data files, and it is conditional because I wanted in no way to 
alter the current software when BINARY_DATA_FILE was not active.

The need for that MODE_PLOT/MODE_SPLOT type is that for binary data 
files there is automatic generation of coordinate information for 
equidistant samplings, e.g., a time waveform or an image.  And the 
manner in which coordinates are constructed depends on whether it is 
intended for a 2D plot or a 3D plot.  My inclination was to leave that 
until the developers felt comfortable to allow alteration of the code 
when the items were disabled.

>BTW: I took the liberty of deleting the dozens of outdated version of your
>patch from the patch tracker, keeping only what appeared to be the latest
>versions of independent files --- that patch tracker entry is a menace to
>society at its current length!
>

Please do.  Thanks.

Dan

regression: 'with pixels' affects 'all.dem'

[Hans-Bernhard B. <br...@ph...>]

As threatened, I've begun regression-testing prospective new
patches against the existing code.

And already found the first one: the current edition of the "with pixels &
friends" patch (after fixing a conflict in misc.c...) causes off-by-one
differences to the current head of CVS.  Affected plots include a
considerable subset of 'surface.dem' (starting at the first that has x**3
in it, then every plot up to the second plot of the sinc function), the
see-through sphere plot in world.dem, and all the pm3d "flush" option's
demos.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

'with pixels' (was Re: Engines are started; ...)

[Hans-Bernhard B. <br...@ph...>]

On Thu, 8 Jul 2004, Daniel J Sebald wrote:

> 1)  With contributions from Ethan and Per, there are a good number of 
> drivers covered so far:  x11, postscript family (postscript, epslatex, 
> pstex), png, pdf, aqua.  The one main one not covered is probably 
> Windows in some form.  However, the software should at least default to 
> using filled polygons for that case if pm3d is available.

I had forgotten: so 'with pixels' needs a terminal API extension, it
seems?  I'll have a look.  But don't expect anything to happen on the
Windows front soon --- we're still short-handed on people willing touch
anything Windoze.

> 2)  There are some messages in the patch that come up the first time a 
> feature is used that eventually can be weeded out. 

Please turn all of them into calls of our usual debugging macro
FPRINTF() soon.  We don't really want or need developer debug print out
in the regular build that serve no purpose to the ordinary user.

I'm not terribly happy with some of the changes.  Especially those where
the signature of old gnuplot functions is extended conditionally. I think
we've learned from PM3D that this generally doesn't work out well in the
long run.  I would prefer just adding the new arguments unconditionally.

BTW: I took the liberty of deleting the dozens of outdated version of your
patch from the patch tracker, keeping only what appeared to be the latest
versions of independent files --- that patch tracker entry is a menace to
society at its current length!

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: String variables

[Hans-Bernhard B. <br...@ph...>]

On Thu, 8 Jul 2004, Ethan Merritt wrote:

> Or did you mean
> 
>     set label 1 sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B)

That one, mostly.  Generally, the "A = $A" syntax may seem simple, but
it's also of rather limited flexibility.   

This function-like syntax also extends more naturally to other operations
on strings (scanning a string, reading a string from an external file,
...).  I think we can take a hint from Java, here: Strings are native
datatypes, but the only operator they support is '+' for concatenation.
Everything else is done by functions.

> But I don't really see how either of these would work on the
> command line. The existing "userstrings" patch allows
> 
>     STYLE1 = "1:4 with lines lw 2"
>     plot 'datafile' using $STYLE1

In this context, the decision about $ vs. sprintf() would affect only the
first of these lines.  In my scheme, it might become:

   STYLE1 = sprintf("1:%d with lines lw %g", i, width)

We should probably foresee an interface to gprintf(), too, to give access 
to %l/%L from 'help format spec'.

> Admittedly the userstrings patch would probably better be
> described as implementing macro definitions rather string variables,

Exactly.  Just storing a fixed string in a variable is not very helpful.
The real power to be gained would lie in the methods for constructing such
strings from other elements.  Compare it to our user-defined variables.  
They would be of rather limited applicability if you couldn't use
arbitrary expressions to compute their value.

> > $ already being used for at 
> > least two entirely unrelated things in gnuplot
> 
> The primary use is for column numbers.
> The second use I know about is for the command line 
> variables ($1, $2, $3...).  

IIRC there's a feature request that we should $-expand environment
variables.  And TeX strings have to be able to contain literal $
characters.  And your own suggestions just introduced two independent uses
of it: to signal a string variable / macro to be expanded, and to signal a
number to be inserted inside a string.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: String variables

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

> On Thursday 08 July 2004 03:27 am,  
> Hans-Bernhard Broeker <br...@ph...> wrote:
>>
>> > I also have some largish patches corresponding to implementations
>> > of several different flavors of user-accessible string variables.
>> > These have been discussed off and on over the last year or so,
>> > but I never sensed a real consensus as to which approach was
>> > best.
>>
>> I think that means we'll need a summary of their differences to
>> start off that discussion again.  As far as I remember, there
>> were several open issues we never decided upon conclusively:


>> 1) how deep down into the expression evaluator do we put them, i.e. do
>> we only need string-valued variables controlled by a 'set' or 'let'
>> command of their own, or should 'string' become a third native type of
>> expression, in addition to integer and complex, meaning that we could
>> have string operators, string arguments and results in both internal and
>> user-defined functions?


> But I don't really see how either of these would work on the
> command line. The existing "userstrings" patch allows
>
>     STYLE1 = "1:4 with lines lw 2"
>     plot 'datafile' using $STYLE1
>
> or even
>
>     Source1 = " 'data1' using 1:4"
>     Source2 = " 'data2' using 2:3"
>     plot $Source1 with lines, $Source2 with points
>
> How does printf/sprintf fit in here? 
>
> Admittedly the userstrings patch would probably better be
> described as implementing macro definitions rather string variables,
> but it raises the same issues of acceptable syntax.
>


I see this as the crux of the issue. As you say, userstring patch is
really macros rather than full string variables. I spent a bit of time
thinking about "true" string expressions / variables a long time
ago. That would be my preference, though since the chances are I won't
have any time to implement anything, I don't want to push my views too
hard.

If I did have time, then my goal would be able to do something like

 plot 'file' using (timecolumn("format, 1) + timecolumn("fmt", 3)):5

where (I hope it's obvious) timecolumn is a built-in function like
column() but which allows the format to be supplied as a parameter.
This fixes some of the problems with timefmt where only one format can
be specified, for example.

I would go as far as allowing user-defined functions which take and
return strings, etc. I had always assumed that STRING would become the
third type of a value.


String literals in expressions become a complication. (Assuming
expression evaluation is still as it was a few years ago.) My plan had
been to store a string table in an action table where the literals
go. This way, the literals last for as long as the action table lasts,
which may be brief for a temporary at, or for the duration of a plot
for a plot-using expression, or for the lifetime of a user-defined
function.


As is pointed out, this doesn't allow strings to be used as macros. My
suggestion was to provide an eval()-like command which evaluates
a string expression, then puts that back through the parser to
interpret it as a gnuplot command. Ugly, but...
And of course, a user-defined function could invoke eval() and really
make things complicated.



My only objection to the string-macros patch is that it would get
in the way of a "full" string-expression change later.


But anyway, it's a long time since I've been actively involved in
development, so I don't want to push my own opinions on this.



dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

String variables

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

On Thursday 08 July 2004 03:27 am,  
Hans-Bernhard Broeker <br...@ph...> wrote:
>
> > I also have some largish patches corresponding to implementations
> > of several different flavors of user-accessible string variables.
> > These have been discussed off and on over the last year or so,
> > but I never sensed a real consensus as to which approach was
> > best.
>
> I think that means we'll need a summary of their differences to
> start off that discussion again.  As far as I remember, there
> were several open issues we never decided upon conclusively:

I need to clean them up, modify them to apply against the current
cvs source, and generally re-familiarize myself with the code.  Then
I'll update or replace the descriptions on SourceForge and post them
to the list as well.

> 1) how deep down into the expression evaluator do we put them, i.e. do
> we only need string-valued variables controlled by a 'set' or 'let'
> command of their own, or should 'string' become a third native type of
> expression, in addition to integer and complex, meaning that we could
> have string operators, string arguments and results in both internal and
> user-defined functions?

That would be the hard part, yes.

> 3) As a follow-up to 2), how to expand variables into strings? 
> Bash-like $var, or C-like sprintf() style? 

I don't quite see how the latter would work in general.  Do you mean

    set label 1 "After fitting, A = "+printf(A)+"  B = "+ printf(B)

I find that incredibly ugly and unreadable compared to

    set label 1 "After fitting, A = $A  B = $B"

Or did you mean

    set label 1 sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B)

That variant does have the virtue of allowing format specifiers.

But I don't really see how either of these would work on the
command line. The existing "userstrings" patch allows

    STYLE1 = "1:4 with lines lw 2"
    plot 'datafile' using $STYLE1

or even

    Source1 = " 'data1' using 1:4"
    Source2 = " 'data2' using 2:3"
    plot $Source1 with lines, $Source2 with points

How does printf/sprintf fit in here? 

Admittedly the userstrings patch would probably better be
described as implementing macro definitions rather string variables,
but it raises the same issues of acceptable syntax.

> $ already being used for at 
> least two entirely unrelated things in gnuplot

The primary use is for column numbers.
The second use I know about is for the command line 
variables ($1, $2, $3...).  

But of those are easily avoided simply by requiring that string
variables start with a letter, which we would want to do
anyhow to avoid parsing problems.

Are there any other uses?

> I would prefer the latter.

I prefer $, although I have no particular objection to
using some other symbol or syntax.  There was an earlier
suggestion to use %(VARIABLE) instead of $VARIABLE.

Even so I agree that *if* we allow string functions, then
some equivalents to printf()  and sprintf() need to be built in. 
I never got as far as a solid implementation of string-valued
functions in my earlier attempts, however.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Engines are started; first car is out the gate

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

On Thursday 08 July 2004 12:11 pm, Daniel J Sebald wrote:
> pstex), png, pdf, aqua.  The one main one not covered is probably
> Windows in some form.  However, the software should at least default to
> using filled polygons for that case if pm3d is available.

I plan to move the filled_polygon() code out of the PM3D #ifdefs, and
make it dependent on USE_ULIG_FILLEDBOXES instead.  I'll make this
change one driver at a time.  In most cases the existing term->fillbox()
will then become a special-case wrapper that simply passes along a
request for a 4-vertex polygon.  Once the drivers are ready, I'll change
the core routines to allow filledcurves and other options based on 
term->filled_polygon even in the absence of PM3D.
But as you all know, I don't do Windows - so I leave that to someone else. 

> 5)  In the reading of raw data, I've intermixed code in the
> "df_readline()" routine so that the changes I've made have a small
> probability of altering the way any file entry current behaved.
>  However, I look at "df_readline()" as being the workhorse of the file
> reading routines.  As such, it could maybe be cleaned up later on when
> all is said and done.  In fact, I'm wondering if just a couple extra
> conditional statements within this routine could achieve reading
> "gnuplot binary" files so that a special routine for gnuplot binary is
> not needed.

It would be nice to further clean up the code in df_readline().
But I think it is OK to start with a working version and use it for
a baseline against which to compare the output of cleaned up
versions.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Engines are started; first car is out the gate

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

Hans-Bernhard Broeker wrote:

>>>The patch I'm proposing is the "wth image", "with rgbimage", and "binary
>>>datafile" stuff, but I should probably say a few things about it on the
>>>list so people know what to expect.
>>>      
>>>
>>My main concern is that you carefully check that your patch does not
>>undo some of the code changes that my recent round of patches added.   
>>
>>In fact, I suggest that is a general requirement for patches added in
>>this current round.  Major changes on top of other major changes
>>are a bit tricky.  Big patches should come with a demo/test-case so
>>that it is easy to verify it still works later on.  For my recent patches
>>these are:
>>	fillbetween.dem
>>	datatstrings.dem
>>	histograms.dem
>>	histograms2.dem	(currently shows a minor bug is present) 
>>

I just confirmed that the patch doesn't alter any of your new additions.

>>We also might want a policy that new features default to 
>>--enable-<feature>  to insure that they are well-tested for compatibility.
>>

OK...  BTW, currently the default for "histograms" is disabled.

...

Well, here are some comments:

1)  With contributions from Ethan and Per, there are a good number of 
drivers covered so far:  x11, postscript family (postscript, epslatex, 
pstex), png, pdf, aqua.  The one main one not covered is probably 
Windows in some form.  However, the software should at least default to 
using filled polygons for that case if pm3d is available.

2)  There are some messages in the patch that come up the first time a 
feature is used that eventually can be weeded out.  For example, the 
first time an image is drawn in X11, information about the graphics 
display is put on the screen.  This is in case someone runs across the 
situation where their color scheme looks incorrect.  They can then pass 
that info along to me for a bug fix.

3)  I think Petr and I have come up with a fairly good syntax for all 
the options to bring in raw data files.  However, feedback is welcome.

4)  I believe the code is clean, compact and efficient.  Some of it may 
look bulky, like all the arrays constructed to extract the variable data 
size info from the compiler.  However, once that is passed through the 
compiler, the result is a compact set of tables.  But on the original 
note, I'm probably a weaker programmer than the group and with perhaps 
different style (although I've learned and adapted a lot), so if anyone 
someday realizes "hey that could be done better like this", feel free to 
alter things.  Or if there is question, just ask.

5)  In the reading of raw data, I've intermixed code in the 
"df_readline()" routine so that the changes I've made have a small 
probability of altering the way any file entry current behaved. 
 However, I look at "df_readline()" as being the workhorse of the file 
reading routines.  As such, it could maybe be cleaned up later on when 
all is said and done.  In fact, I'm wondering if just a couple extra 
conditional statements within this routine could achieve reading 
"gnuplot binary" files so that a special routine for gnuplot binary is 
not needed.

6)  There is one small detail within the software that I've left undone. 
 It is the clipping of pixels for images that are skewed, drawn with 
polygons.  That is, the pixels at the edges of the image which extend 
partial into a non-visible region are currently not clipped into 3 sided 
or 5 sided polygons as they should be.  This happens when zooming.  I 
thought it a bit tedious to go through that, not knowing if the 
arbitrary angle feature were to end up in the final product.  After some 
evaluation if people think "let's keep that", then I can patch the fix. 
 It shouldn't be that difficult.

7)  I'll ask Petr to make the change in the source.  But, I just noticed 
I left some "Enable ..." messages out of the config file.  I'll add that 
quick.

Dan

Re: Engines are started; first car is out the gate

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

On Thursday 08 July 2004 10:21 am, Hans-Bernhard Broeker wrote:
> On Thu, 8 Jul 2004, Ethan Merritt wrote:
> >  Big patches should come with a demo/test-case so
> > that it is easy to verify it still works later on.  For my recent
> > patches these are:
> > 	fillbetween.dem
> > 	datatstrings.dem
> > 	histograms.dem
> > 	histograms2.dem	(currently shows a minor bug is present)
>
> Are they in 'all.dem' yet?  

Not yet, because...

> > We also might want a policy that new features default to
> > --enable-<feature>  to insure that they are well-tested for
> > compatibility.

This policy is needed first.  It doesn't currently work to test
conditionally-compiled options in all.dem because the script
can exit with an error if the option has not been configured.
[I'd like to change that behaviour, but that's a whole other discussion] 

> Agreed.  People building from CVS right now, so soon after a public
> release, should get what they asked for: undiluted work-in-progress
> code.

OK.  So I'll change the default to --enable-histograms and add all 
the demos to all.dem


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Engines are started; first car is out the gate

[Hans-Bernhard B. <br...@ph...>]

On Thu, 8 Jul 2004, Ethan Merritt wrote:

> On Thursday 08 July 2004 08:59 am, Daniel J Sebald wrote:
> >
> > I would be a taker, but I'm not sure Ethan has completed his changes.
> 
> As I said, I have some more tweaks that I will feed in after testing.
> But they are both localized and small, so I don't think that you should
> hold off just because of that.
> 
> > The patch I'm proposing is the "wth image", "with rgbimage", and "binary
> > datafile" stuff, but I should probably say a few things about it on the
> > list so people know what to expect.
> 
> My main concern is that you carefully check that your patch does not
> undo some of the code changes that my recent round of patches added.   
> 
> In fact, I suggest that is a general requirement for patches added in
> this current round.  Major changes on top of other major changes
> are a bit tricky.  Big patches should come with a demo/test-case so
> that it is easy to verify it still works later on.  For my recent patches
> these are:
> 	fillbetween.dem
> 	datatstrings.dem
> 	histograms.dem
> 	histograms2.dem	(currently shows a minor bug is present) 

Are they in 'all.dem' yet?  Because if so, I would like to propose a
regression test to be set up and be maintained from now on: for at least a
select few terminal drivers that write multi-page output files, e.g.
postscript and SVG, I think we should run a script like this in 'make
check':

	set term postscript colour solid
	set output 'current.ps'
	load 'all.dem'
	! diff -u current.ps regress.ps

"regress.ps" would have to be maintained outside CVS, though --- It's way
too large for regular processing by 'cvs update' and colleagues, esp. over
a dial-up link.

> We also might want a policy that new features default to 
> --enable-<feature>  to insure that they are well-tested for compatibility.

Agreed.  People building from CVS right now, so soon after a public
release, should get what they asked for: undiluted work-in-progress code.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Engines are started; first car is out the gate

[Hans-Bernhard B. <br...@ph...>]

On Thu, 8 Jul 2004, Daniel J Sebald wrote:

> The patch I'm proposing is the "wth image", "with rgbimage", and "binary 
> datafile" stuff, but I should probably say a few things about it on the 
> list so people know what to expect.

Fine with me.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Should 4.1 keep supporting pre-4.0 syntax?

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

On Thursday 08 July 2004 03:06 am, Hans-Bernhard Broeker wrote:
>
> I propose to remove this from the splash message, and turn off the old
> syntax (--> turn off BACKWARDS_COMPATIBLE in setshow.h, code would stay
> in for the time being).  Objections?

OK by me.  If nothing else, it will turn up any old syntax still lingering
in the set of demos.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Engines are started; first car is out the gate

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

On Thursday 08 July 2004 08:59 am, Daniel J Sebald wrote:
>
> I would be a taker, but I'm not sure Ethan has completed his changes.

As I said, I have some more tweaks that I will feed in after testing.
But they are both localized and small, so I don't think that you should
hold off just because of that.

> The patch I'm proposing is the "wth image", "with rgbimage", and "binary
> datafile" stuff, but I should probably say a few things about it on the
> list so people know what to expect.

My main concern is that you carefully check that your patch does not
undo some of the code changes that my recent round of patches added.   

In fact, I suggest that is a general requirement for patches added in
this current round.  Major changes on top of other major changes
are a bit tricky.  Big patches should come with a demo/test-case so
that it is easy to verify it still works later on.  For my recent patches
these are:
	fillbetween.dem
	datatstrings.dem
	histograms.dem
	histograms2.dem	(currently shows a minor bug is present) 

We also might want a policy that new features default to 
--enable-<feature>  to insure that they are well-tested for compatibility.
Later on we can decide if some are too specialized or so big that they 
should require deliberate selection at ./configure time.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Engines are started; first car is out the gate

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

Hans-Bernhard Broeker wrote:

>On Sun, 4 Jul 2004, Ethan A Merritt wrote:
>
>  
>
>>	So -- who is next out of the gate?  
>>    
>>
>
>No takers, it seems.  I take that to mean we can proceed to the "go
>through all entries in the SF.net patch tracker" stage.  Also known as
>"fire at will".  Except that Patches already assigned to someone should be
>left to that person.  All discussion in this mailing list, please --- the
>patch tracker itself is too cumbersome for that.
>

I would be a taker, but I'm not sure Ethan has completed his changes.  I 
wanted to wait a bit for that to stabilize and be tested a bit.  I've 
tried the changes he's made and they seem fine.

The patch I'm proposing is the "wth image", "with rgbimage", and "binary 
datafile" stuff, but I should probably say a few things about it on the 
list so people know what to expect.

Dan

Re: Engines are started; first car is out the gate

[Hans-Bernhard B. <br...@ph...>]

On Sun, 4 Jul 2004, Ethan A Merritt wrote:

[3 patches already in]
Ethan: please close those patches in the patch tracker, then
(including #482108).

> I also have some largish patches corresponding to implementations
> of several different flavors of user-accessible string variables.
> These have been discussed off and on over the last year or so,
> but I never sensed a real consensus as to which approach was
> best. 

I think that means we'll need a summary of their differences to
start off that discussion again.  As far as I remember, there
were several open issues we never decided upon conclusively:

1) how deep down into the expression evaluator do we put them, i.e. do we
only need string-valued variables controlled by a 'set' or 'let' command
of their own, or should 'string' become a third native type of expression,
in addition to integer and complex, meaning that we could have string
operators, string arguments and results in both internal and user-defined
functions?

2) How to recognize usage of string variables in existing commands
that currently rely on having "" or '' around strings? 

3) As a follow-up to 2), how to expand variables into strings?  Bash-like
$var, or C-like sprintf() style?  $ already being used for at least two
entirely unrelated things in gnuplot, I would prefer the latter.

> 	So -- who is next out of the gate?  

No takers, it seems.  I take that to mean we can proceed to the "go
through all entries in the SF.net patch tracker" stage.  Also known as
"fire at will".  Except that Patches already assigned to someone should be
left to that person.  All discussion in this mailing list, please --- the
patch tracker itself is too cumbersome for that.


-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Should 4.1 keep supporting pre-4.0 syntax?

[Hans-Bernhard B. <br...@ph...>]

Hello, everyone,

I was pointed to the fact that the current splash screen of 4.1
still contains this:

        This is gnuplot version 4.0.  Please refer to the documentation
        for command syntax changes.  The old syntax will be accepted
        throughout the 4.0 series, but all save files use the new syntax.

Obviously, "this" is no longer 4.1, nor is it the 4.0 series.  I thus
propose to remove this from the splash message, and turn off the old
syntax (--> turn off BACKWARDS_COMPATIBLE in setshow.h, code would stay
in for the time being).  Objections?

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

unsubscribe

[GANNOUNE L. <Las...@ei...>]

Unsubscribe

=20

-----Original Message-----
From: gnu...@li...
[mailto:gnu...@li...] On Behalf Of GANNOUNE
Lassaad
Sent: jeudi, 8. juillet 2004 09:04
To: gnu...@li...
Subject: (no subject)

=20

Please I would like to unsubscribe from this list.=20

=20

Regards,

=20

Lassaad

=20

=20

=20

(no subject)

[GANNOUNE L. <Las...@ei...>]

Please I would like to unsubscribe from this list.=20

=20

Regards,

=20

Lassaad

=20

=20

=20

Re: Keyboard input losses also on MS Windows

[Hans-Bernhard B. <br...@ph...>]

On Wed, 7 Jul 2004, Daniel J Sebald wrote:

> As with some other case statements, the "break" was moved inside the 
> curley bracket thinking that it was like the others.  But in this case 
> the {} is not for defining new variables, it is for an if(){} statement, 
> I believe.  Does that seem like it could be the problem?

Yep, that was the one.  CVS head is fixed already.  The 4.0 branch will
receive the fix right away.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Keyboard input losses also on MS Windows

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

I can't compile those files, but another check you could do is to 
generate the assembly file for both (non-annotated) and do a diff on the 
two generated files. -- Dan


Daniel J Sebald wrote:

> Hans-Bernhard Broeker wrote:
>
>>
>> Any assistance in solving this puzzle would be glady appreciated.
>

Re: Keyboard input losses also on MS Windows

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

Hans-Bernhard Broeker wrote:

>
> Any assistance in solving this puzzle would be glady appreciated.



I think I may have found it... or one problem anyway.

I'm doing a "diff -w" and this one is in question:

<         while((nYinc || nXinc) && !PtInRect(&rect, pt)
<               && (GetAsyncKeyState(VK_LBUTTON) < 0));
<         } /* moved inside viewport */
<         break;
---
 >               while( (nYinc || nXinc) && !PtInRect(&rect, pt) &&
 >                 (GetAsyncKeyState(VK_LBUTTON) < 0) );
1425a1402,1403
 >             }
 >             break;

As with some other case statements, the "break" was moved inside the 
curley bracket thinking that it was like the others.  But in this case 
the {} is not for defining new variables, it is for an if(){} statement, 
I believe.  Does that seem like it could be the problem?

Dan

Re: Keyboard input losses also on MS Windows

[Hans-Bernhard B. <br...@ph...>]

Franco Fritschij wrote:

> If I replace wtext.c .h and all the other source code is from the CVS
> from yesterday, the problem with the first character are gone.
> So in mine opion it is not mouse.c or readline.c but wtext.c with was
> modified to remove a very old bug, but introduced a new bug.

Dietmar and I also reached this conclusion in the meantime.  The new bug 
apparently crept in between version 4.0.1 and 4.0.2, in wtext.c. But 
even after looking at the diffs for quite some time, I still have no 
idea what may be broken.  The changes are numerous, but AFAICS, they're 
all benign: whitespace changes, re-indentation, comments moved around a 
bit, and such things.  The only somewhat suspicious ones I can see are 
the changes to move return and break commands into the blocks enclosing 
code for one case of a switch().

Any assistance in solving this puzzle would be glady appreciated.
-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Keyboard input losses also on MS Windows

[Franco F. <ffr...@Ca...>]

Gnuplot team,

I also found that the first key is missing when starting gnuplot, when
I compiled the CVS source. I first noticed it for version 4.0.2.
But it is not only the first keystroke, also the commands from the pull
done window are missing the first character. 

On top of this it depends on how gnuplot is launched and if the mouse
pointer is moved and or inside the new gnuplot window.
(also noticed by Daniel J Sebald)

I have done some experiments with the latest CVS from yesterday, and 
compiled this with replacing some files with files from the source tar
ball of 4.0.0.

If I replace mouse.c .h and readline.c  I get still the same behavior.
This is not what Hans-Bernard Broeker found, he wrote in this list

On Sunday 04 July 2004 07:46 am, Hans-Bernhard Broeker wrote:
> Warning:  wgnuplot now tends to lose the first keypress after
starting
> the program.  This did not happen with 4.0.0, and is fixed by
back-dating
> mouse.[ch] and readline.c to that state.



If I replace wtext.c .h and all the other source code is from the CVS
from yesterday, the problem with the first character are gone.
So in mine opion it is not mouse.c or readline.c but wtext.c with was
modified to remove a very old bug, but introduced a new bug.

Franco Fritschij