gnuplot-beta

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

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...>]

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