Menu
▾
▴
gnuplot-beta
|
From: Ethan M. <merritt@u.washington.edu> - 2004-09-12 16:24:14
|
Daniel:
I just discovered a problem with the new binary input code.
Basically it causes the to code break if any of the plot styles
defined in gp_types.h are revised.
In datafile.c there is an array
df_bin_default_columns default_style_cols[LAST_PLOT_STYLE + 1] = {
{1, 1}, /* LINES */
{1, 1}, /* POINTSTYLE */
[... and so on]
But this definition assumes that it knows the exact order and
value of the various plot styles. As I discovered when revising
and testing Volker Dobler's "sizepoints" patch, adding new plot
styles or revising the old ones causes a mismatch of the values
in this array.
I see from your comment that you already knew this might
be a problem. Well, as I just discovered, it *is* a problem.
Could you please modify this array and the code that uses it
so that rather than assuming, for instance, POINTSTYLE==1,
the array includes the actual current values to test against?
I imagine it would look something like
df_bin_default_columns default_style_cols[] = {
{LINES, 1, 1},
{POINTSTYLE, 1, 1},
[... and so on]
|
|
From: Hans-Bernhard B. <br...@ph...> - 2004-09-12 16:32:59
|
Ethan Merritt wrote:
> Could you please modify this array and the code that uses it
> so that rather than assuming, for instance, POINTSTYLE==1,
> the array includes the actual current values to test against?
> I imagine it would look something like
>
> df_bin_default_columns default_style_cols[] = {
> {LINES, 1, 1},
> {POINTSTYLE, 1, 1},
> [... and so on]
Better yet, Someone[^TM] take this as motivation to finally create the
long overdue "properties of a plotting style" data structure. Besides
the above, there are already quite a list of per-style pieces of
information scattered all across the code (including inside the plot
style numbers themselves!). Those really need to be collected and
organized in an orderly fashion.
|
|
From: Daniel J S. <dan...@ie...> - 2004-09-12 16:48:47
|
Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
>
>> Could you please modify this array and the code that uses it
>> so that rather than assuming, for instance, POINTSTYLE==1,
>> the array includes the actual current values to test against?
>> I imagine it would look something like
>>
>> df_bin_default_columns default_style_cols[] = {
>> {LINES, 1, 1},
>> {POINTSTYLE, 1, 1},
>> [... and so on]
>
>
> Better yet, Someone[^TM] take this as motivation to finally create the
> long overdue "properties of a plotting style" data structure. Besides
> the above, there are already quite a list of per-style pieces of
> information scattered all across the code (including inside the plot
> style numbers themselves!). Those really need to be collected and
> organized in an orderly fashion.
Well, what I did there was admittedly a bit of a hack. The reason was
because I realized things could be organized better, but I'm not aware
of what the groups ideas for "properties of a plotting style" are. I
thought originally that this table is something that _should_ go in the
tables.h file or similar. But it didn't seem well organized enough, so
instead I just made it generate an error message. This should fit into
the grand scheme of things including the discussion of default using
strings from the other day, and so on.
Dan
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-09-12 17:07:06
|
On Sunday 12 September 2004 10:15 am, Daniel J Sebald wrote:
> Hans-Bernhard Broeker wrote:
> >
> > Better yet, Someone[^TM] take this as motivation to finally create the
> > long overdue "properties of a plotting style" data structure.
> I'm not aware
> of what the groups ideas for "properties of a plotting style" are.
typedef enum int {
LINES, POINTSTYLE, LINESPOINTS, IMPULSES, .....
} plot_style;
typedef struct {
int plot_style; /* The identifying number */
TBOOLEAN has_points; /* replaces the PLOT_STYLE_HAS_POINT bitflag */
TBOOLEAN has_fill; /* replaces the PLOT_STYLE_HAS_FILL bitflag */
[.. more bitflags ..]
int min_columns;
int max_columns;
int default_columns;
[.. and so on ..]
} t_plotstyle;
extern struct t_plotstyle plotstyle[] =
{ ... initialization array ... };
Everywhere that explicitly tests against the definitions currently
in gp_types.h gets modified to test against this structure instead.
Old: If (<foo> & PLOT_STYLE_HAS_FILL) ...
New: If (plotstyle[<foo>].has_fill) ...
Current code will have to change in lots of places. But you don't have
to worry about missing any of them, because if you remove the current
definitions in gp_types.h the compiler will let you know where they
all are :-)
|
|
From: Daniel J S. <dan...@ie...> - 2004-09-12 17:19:07
|
Ethan Merritt wrote:
>>I'm not aware
>>of what the groups ideas for "properties of a plotting style" are.
>>
>>
>
>typedef enum int {
>LINES, POINTSTYLE, LINESPOINTS, IMPULSES, .....
>} plot_style;
>
>typedef struct {
>int plot_style; /* The identifying number */
>TBOOLEAN has_points; /* replaces the PLOT_STYLE_HAS_POINT bitflag */
>TBOOLEAN has_fill; /* replaces the PLOT_STYLE_HAS_FILL bitflag */
>[.. more bitflags ..]
>int min_columns;
>int max_columns;
>int default_columns;
>[.. and so on ..]
>} t_plotstyle;
>
>extern struct t_plotstyle plotstyle[] =
>{ ... initialization array ... };
>
>
>Everywhere that explicitly tests against the definitions currently
>in gp_types.h gets modified to test against this structure instead.
>
>Old: If (<foo> & PLOT_STYLE_HAS_FILL) ...
>New: If (plotstyle[<foo>].has_fill) ...
>
Yes, makes sense. So that would get rid of the encoding of the
properties within the style enumeration itself. My opinion is that
would be good. That encoding of the properties within the style is kind
of creative but it harks back to the days of squeezing memory
consumption out of every bit you have available. In fact, yes, when I
created this table you raised question about, I specifically looked at
how I could encode that in the plot style number as well. I thought
that to be too much rocking the boat, and furthermore I believe the
enumeration would run out of bits.
Dan
|
|
From: Hans-Bernhard B. <br...@ph...> - 2004-09-12 17:29:28
|
Ethan Merritt wrote:
> On Sunday 12 September 2004 10:15 am, Daniel J Sebald wrote:
>
>>Hans-Bernhard Broeker wrote:
>>
>>>Better yet, Someone[^TM] take this as motivation to finally create the
>>>long overdue "properties of a plotting style" data structure.
>
>
>
>>I'm not aware
>>of what the groups ideas for "properties of a plotting style" are.
>
>
> typedef enum int {
There's no such thing as "enum int" ;-)
> LINES, POINTSTYLE, LINESPOINTS, IMPULSES, .....
> } plot_style;
May be better to name it t_plot_style or plot_style_number or something
like that...
> typedef struct {
> int plot_style; /* The identifying number */
No "int" here, please. This element is inherently of the type of
the above enum, so that's what its type should be.
> TBOOLEAN has_points; /* replaces the PLOT_STYLE_HAS_POINT bitflag */
> TBOOLEAN has_fill; /* replaces the PLOT_STYLE_HAS_FILL bitflag */
> [.. more bitflags ..]
> int min_columns;
> int max_columns;
> int default_columns;
> [.. and so on ..]
> } t_plotstyle;
>
> extern struct t_plotstyle plotstyle[] =
> { ... initialization array ... };
Exactly. I.e., what I'm envisioning here is a modification roughly
similar to my "axis struct" project a couple of years ago.
|
|
From: Daniel J S. <dan...@ie...> - 2004-09-12 17:29:42
|
The patch for supplying an external X11 window has fallen out of discussion. Should I just put that patch on SourceForge? I think it is fairly near a complete usable product, but I expect few conflicts with CVS modifications. I'll see if I can enhance the demo that Donald sent to allow selecting, via widget, which demo to run and add that to the patch. (It would be a "demos.trm" file that could be added to the /demo subdirectory... of course, it wouldn't run under Windows so it may require some error message if someone attempts to do so.) Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-09-12 17:46:40
|
On Sunday 12 September 2004 10:56 am, Daniel J Sebald wrote: > The patch for supplying an external X11 window has fallen out of > discussion. Should I just put that patch on SourceForge? Sure. I have no time to look at it, and consider it of rather low priority until a specific application comes along begging for it. At which point I expect the application's author can use a SourceForge patchset as a starting point to get something that really does the needed job. Until that point we would just be guessing at the details needed. |
|
From: Daniel J S. <dan...@ie...> - 2004-09-12 19:59:47
|
I've spruced up the Tcl/Tk demo a bit. A list box selects the demo to run. There is the "Next" button that Donald included. I want to include a "Stop" button for breaking out of the demo. In other words, I want the "Stop" button to behave as a cntrl-C to gnuplot. Any idea of how to do that from a non-command-line environment? I'm guessing that may be system dependent. Is there an escape character I can send to gnuplot when in pause mode that will stop it executing any script files? I've tried sending ESC (0x1b) or CAN (0x18), but I think gnuplot would have to be programmed to break upon seeing those characters. Worth patching somehow? Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-09-12 16:33:25
|
On Sunday 12 September 2004 09:24 am, Ethan Merritt wrote:
>
> In datafile.c there is an array
>
> df_bin_default_columns default_style_cols[LAST_PLOT_STYLE + 1] = {
> {1, 1}, /* LINES */
> {1, 1}, /* POINTSTYLE */
> [... and so on]
And another question occurs to me.
How does this work at all for plot styles which apply both to
2D and 3D plot styles? I may have missed it, but I couldn't
find a line of code that adjusts the expected number of
columns to be 1 greater in 3D mode.
|
|
From: Daniel J S. <dan...@ie...> - 2004-09-12 17:12:16
|
Ethan Merritt wrote:
>On Sunday 12 September 2004 09:24 am, Ethan Merritt wrote:
>
>
>>In datafile.c there is an array
>>
>> df_bin_default_columns default_style_cols[LAST_PLOT_STYLE + 1] = {
>> {1, 1}, /* LINES */
>> {1, 1}, /* POINTSTYLE */
>> [... and so on]
>>
>>
>
>And another question occurs to me.
>How does this work at all for plot styles which apply both to
>2D and 3D plot styles? I may have missed it, but I couldn't
>find a line of code that adjusts the expected number of
>columns to be 1 greater in 3D mode.
>
It's in there somewhere...
/* If there aren't generated coordinates, then add the
* amount of columns that would be generated.
*/
no_cols += default_style_cols[plot_style_index].dimen_in_2d;
if (df_plot_mode == MODE_SPLOT)
no_cols++;
The above may be it. In any case, I'm sure I addressed this. I guess
my approach to things is that all styles should be allowed to be
extended to 3D plots, as far as generating the data, that is. Whether
further down the line the plotting code can make sense of extending the
plot style to 3D is another matter... I also wonder if the "properties
of plotting styles", default using specs and behavior, extending data to
3D, better integration of plot2d.c/plot3d.c are all part of the grand
scheme... That is sort of why I wrote the image routine to allow
passing in MODE_SPLOT or MODE_PLOT. It can then be used in both plot2D
and plot3D.c, for what that is worth. One could take the same approach
with other styles (e.g., bar graphs in 3D... although 3D bar graphs may
be a faux pas of graphing, i.e., simply a wow factor and/or means to
distort results).
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2004-09-12 16:42:11
|
Ethan Merritt wrote:
>Daniel:
>
>I just discovered a problem with the new binary input code.
>Basically it causes the to code break if any of the plot styles
>defined in gp_types.h are revised.
>
>In datafile.c there is an array
>
> df_bin_default_columns default_style_cols[LAST_PLOT_STYLE + 1] = {
> {1, 1}, /* LINES */
> {1, 1}, /* POINTSTYLE */
> [... and so on]
>
>But this definition assumes that it knows the exact order and
>value of the various plot styles. As I discovered when revising
>and testing Volker Dobler's "sizepoints" patch, adding new plot
>styles or revising the old ones causes a mismatch of the values
>in this array.
>
>I see from your comment that you already knew this might
>be a problem. Well, as I just discovered, it *is* a problem.
>
>Could you please modify this array and the code that uses it
>so that rather than assuming, for instance, POINTSTYLE==1,
>the array includes the actual current values to test against?
>I imagine it would look something like
>
>df_bin_default_columns default_style_cols[] = {
> {LINES, 1, 1},
> {POINTSTYLE, 1, 1},
> [... and so on]
>
Yes, that is a better method. What version of CVS would you like the
patch against? The CVS before the changes you're making or after?
Dan
>
>
|
