You can subscribe to this list here.
2001 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(83) |
Nov
(57) |
Dec
(111) |
2004 |
Jan
(38) |
Feb
(121) |
Mar
(107) |
Apr
(241) |
May
(102) |
Jun
(190) |
Jul
(239) |
Aug
(158) |
Sep
(184) |
Oct
(193) |
Nov
(47) |
Dec
(68) |
2005 |
Jan
(190) |
Feb
(105) |
Mar
(99) |
Apr
(65) |
May
(92) |
Jun
(250) |
Jul
(197) |
Aug
(128) |
Sep
(101) |
Oct
(183) |
Nov
(186) |
Dec
(42) |
2006 |
Jan
(102) |
Feb
(122) |
Mar
(154) |
Apr
(196) |
May
(181) |
Jun
(281) |
Jul
(310) |
Aug
(198) |
Sep
(145) |
Oct
(188) |
Nov
(134) |
Dec
(90) |
2007 |
Jan
(134) |
Feb
(181) |
Mar
(157) |
Apr
(57) |
May
(81) |
Jun
(204) |
Jul
(60) |
Aug
(37) |
Sep
(17) |
Oct
(90) |
Nov
(122) |
Dec
(72) |
2008 |
Jan
(130) |
Feb
(108) |
Mar
(160) |
Apr
(38) |
May
(83) |
Jun
(42) |
Jul
(75) |
Aug
(16) |
Sep
(71) |
Oct
(57) |
Nov
(59) |
Dec
(152) |
2009 |
Jan
(73) |
Feb
(213) |
Mar
(67) |
Apr
(40) |
May
(46) |
Jun
(82) |
Jul
(73) |
Aug
(57) |
Sep
(108) |
Oct
(36) |
Nov
(153) |
Dec
(77) |
2010 |
Jan
(42) |
Feb
(171) |
Mar
(150) |
Apr
(6) |
May
(22) |
Jun
(34) |
Jul
(31) |
Aug
(38) |
Sep
(32) |
Oct
(59) |
Nov
(13) |
Dec
(62) |
2011 |
Jan
(114) |
Feb
(139) |
Mar
(126) |
Apr
(51) |
May
(53) |
Jun
(29) |
Jul
(41) |
Aug
(29) |
Sep
(35) |
Oct
(87) |
Nov
(42) |
Dec
(20) |
2012 |
Jan
(111) |
Feb
(66) |
Mar
(35) |
Apr
(59) |
May
(71) |
Jun
(32) |
Jul
(11) |
Aug
(48) |
Sep
(60) |
Oct
(87) |
Nov
(16) |
Dec
(38) |
2013 |
Jan
(5) |
Feb
(19) |
Mar
(41) |
Apr
(47) |
May
(14) |
Jun
(32) |
Jul
(18) |
Aug
(68) |
Sep
(9) |
Oct
(42) |
Nov
(12) |
Dec
(10) |
2014 |
Jan
(14) |
Feb
(139) |
Mar
(137) |
Apr
(66) |
May
(72) |
Jun
(142) |
Jul
(70) |
Aug
(31) |
Sep
(39) |
Oct
(98) |
Nov
(133) |
Dec
(44) |
2015 |
Jan
(70) |
Feb
(27) |
Mar
(36) |
Apr
(11) |
May
(15) |
Jun
(70) |
Jul
(30) |
Aug
(63) |
Sep
(18) |
Oct
(15) |
Nov
(42) |
Dec
(29) |
2016 |
Jan
(37) |
Feb
(48) |
Mar
(59) |
Apr
(28) |
May
(30) |
Jun
(43) |
Jul
(47) |
Aug
(14) |
Sep
(21) |
Oct
(26) |
Nov
(10) |
Dec
(2) |
2017 |
Jan
(26) |
Feb
(27) |
Mar
(44) |
Apr
(11) |
May
(32) |
Jun
(28) |
Jul
(75) |
Aug
(45) |
Sep
(35) |
Oct
(285) |
Nov
(99) |
Dec
(16) |
2018 |
Jan
(8) |
Feb
(8) |
Mar
(42) |
Apr
(35) |
May
(23) |
Jun
(12) |
Jul
(16) |
Aug
(11) |
Sep
(8) |
Oct
(16) |
Nov
(5) |
Dec
(8) |
2019 |
Jan
(9) |
Feb
(28) |
Mar
(4) |
Apr
(10) |
May
(7) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(23) |
Dec
(3) |
2020 |
Jan
(19) |
Feb
(3) |
Mar
(22) |
Apr
(17) |
May
(10) |
Jun
(69) |
Jul
(18) |
Aug
(23) |
Sep
(25) |
Oct
(11) |
Nov
(20) |
Dec
(9) |
2021 |
Jan
(1) |
Feb
(7) |
Mar
(9) |
Apr
|
May
(1) |
Jun
(8) |
Jul
(6) |
Aug
(8) |
Sep
(7) |
Oct
|
Nov
(2) |
Dec
(23) |
2022 |
Jan
(23) |
Feb
(9) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(1) |
Jul
(6) |
Aug
(8) |
Sep
(30) |
Oct
(5) |
Nov
(4) |
Dec
(6) |
2023 |
Jan
(2) |
Feb
(5) |
Mar
(7) |
Apr
(3) |
May
(8) |
Jun
(45) |
Jul
(8) |
Aug
|
Sep
(2) |
Oct
(14) |
Nov
(7) |
Dec
(2) |
2024 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
(7) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Daniel J S. <dan...@ie...> - 2004-07-27 16:39:03
|
Hans-Bernhard Broeker wrote: >On Mon, 26 Jul 2004, Daniel J Sebald wrote: > > > >>Well, anyway, could you give me a bit of guidance on whether you might >>consider the changes in notation. >> >> > >Feel free to reorganize the existing code without changing the actual >behaviour in any way that makes the code clearer. We can discuss actual >behavioural changes later. Please do use the justification enums from >term_api, if possible. But leave their names as they are, for the time >being. > > OK. I can go back and redo the patch. Give me a few hours to get back to it... But there is a patch on SourceForge which changes everything to typedef enum H_JUSTIFY { H_LEFT, H_CENTRE, H_RIGHT } H_JUSTIFY; typedef enum V_JUSTIFY { V_TOP, V_CENTRE, V_BOT } V_JUSTIFY; if you want to get some cleanup out of the way. |
From: Daniel J S. <dan...@ie...> - 2004-07-27 16:09:38
|
Hans-Bernhard Broeker wrote: >>In any case, if the change is scrapped, you might still want to fix that >>memory leak in the "show_key" function. >> >> > >I'm lost: what exactly was the leak? > Below is the first part of the code from "show_key()". Notice that the memory is allocated every time the function is called. However, it is only conditionally freed in the case of KEY_AUTO_PLACEMENT, but not in the case of KEY_USER_PLACEMENT. So, as a little test, launch gnuplot and also bring up a system monitor for watching memory usage. In gnuplot type show key and the memory usage momentarily goes up but comes back to where it was. But do a set key 30,30 show key and the memory usage goes up but doesn't come back down. In this patch I've put together, I've simply eliminated the need for dynamically allocating memory. (Just send all the little substrings directly to stderr rather than creating the whole string first.) Another fix would be to make the char * "str" static and test if it is zero or not before allocating memory. Do you want to fix this first in the code independent of what I'm doing? (That is, is this something you want to go back to 4.0 branch and fix, but have the same change in 4.1?... I don't know CVS branching too well.) Or do you want me to include it in the key cleanup patch I'm doing so you can move that into CVS quick? In the latter case, I don't think it is too critical of a problem to remain in 4.0. "show key" in user placement mode shouldn't happen enough to chew up too much memory. Dan /* process 'show key' command */ static void show_key() { legend_key *key = &keyT; char *str = gp_alloc(30, "show_key"); SHOW_ALL_NL; if (!(key->visible)) { fputs("\ \tkey is OFF\n", stderr); return; } switch (key->flag) { case KEY_AUTO_PLACEMENT: if (key->vpos == TUNDER) { strcpy(str, "below"); } else if (key->vpos == TTOP) { strcpy(str, "top"); } else { strcpy(str, "bottom"); } if (key->hpos == TOUT) { strcpy(str, "outside (right)"); } else if (key->hpos == TLEFT) { strcat(str, " left"); } else { strcat(str, " right"); } if (key->vpos != TUNDER && key->hpos != TOUT) { strcat(str, " corner"); } fprintf(stderr, "\ \tkey is ON, position: %s\n", str); free(str); break; case KEY_USER_PLACEMENT: fputs("\tkey is at ", stderr); show_position(&key->user_pos); putc('\n', stderr); break; } |
From: Daniel J S. <dan...@ie...> - 2004-07-27 15:52:50
|
Hans-Bernhard Broeker wrote: >>/* this assignment means we can use x-(just*strlen(text)*t->h_char)/2 if >> * term cannot justify >> */ >>typedef enum JUSTIFY { >> LEFT = 0, >> CENTRE = 1, >> RIGHT = 2 >>} JUSTIFY; >> >> > >Not really. That has no effect relative to the existing code. I suggest >we kill that comment instead. As far as I'm aware, no terminal uses the >ugly hack it suggests anyway. > I second that motion. -- Dan |
From: Hans-Bernhard B. <br...@ph...> - 2004-07-27 08:42:13
|
On Mon, 26 Jul 2004, Daniel J Sebald wrote: > Well, anyway, could you give me a bit of guidance on whether you might > consider the changes in notation. Feel free to reorganize the existing code without changing the actual behaviour in any way that makes the code clearer. We can discuss actual behavioural changes later. Please do use the justification enums from term_api, if possible. But leave their names as they are, for the time being. > In any case, if the change is scrapped, you might still want to fix that > memory leak in the "show_key" function. I'm lost: what exactly was the leak? -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
From: Hans-Bernhard B. <br...@ph...> - 2004-07-27 08:05:02
|
On Mon, 26 Jul 2004, Daniel J Sebald wrote: > Ah, geepers... There is nothing wrong with doing that, I think. But > that bit of code should be changed to > /* this assignment means we can use x-(just*strlen(text)*t->h_char)/2 if > * term cannot justify > */ > typedef enum JUSTIFY { > LEFT = 0, > CENTRE = 1, > RIGHT = 2 > } JUSTIFY; Not really. That has no effect relative to the existing code. I suggest we kill that comment instead. As far as I'm aware, no terminal uses the ugly hack it suggests anyway. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
From: Daniel J S. <dan...@ie...> - 2004-07-26 23:33:30
|
Ethan Merritt wrote: >On Monday 26 July 2004 12:48 pm, Daniel J Sebald wrote: > > >>>Linux Weekly News points out that IBM has put up a web site >>>with a gnuplot version 4.0 tutorial. >>> >>> http://www-106.ibm.com/developerworks/library/l-gnuplot/ >>> >>> >>I love that Sastry openned with the paragraph that he did, discussing >>the two different methods or philosophies generating graphs. >> >> > >Well yeah. But it was odd that he only mentions two modes of use, >interactive and batch. He ignores use as a back-end, whether to >a web script or to a higher-level application like octave. > > I noticed that too. Perhaps he's not really used gnuplot that way. Dan |
From: Ethan M. <merritt@u.washington.edu> - 2004-07-26 22:49:20
|
On Monday 26 July 2004 12:48 pm, Daniel J Sebald wrote: > >Linux Weekly News points out that IBM has put up a web site > >with a gnuplot version 4.0 tutorial. > > > > http://www-106.ibm.com/developerworks/library/l-gnuplot/ > > I love that Sastry openned with the paragraph that he did, discussing > the two different methods or philosophies generating graphs. Well yeah. But it was odd that he only mentions two modes of use, interactive and batch. He ignores use as a back-end, whether to a web script or to a higher-level application like octave. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
From: Ethan M. <merritt@u.washington.edu> - 2004-07-26 21:59:54
|
On Saturday 24 July 2004 07:44 pm, Daniel J Sebald wrote: > typedef enum H_JUSTIFY { > H_LEFT, > H_CENTRE, > H_RIGHT > } H_JUSTIFY; > > typedef enum JUSTIFY { > LEFT, > CENTRE, > RIGHT > } JUSTIFY; > Be careful if you consolidate these admittedly redundant definitions. Some of them depend on the ordering of the enums, which of course entirely violates the spirit of using an enum in the first place. For example, see this alarming comment in term_api.h /* this order means we can use x-(just*strlen(text)*t->h_char)/2 if * term cannot justify */ typedef enum JUSTIFY { LEFT, CENTRE, RIGHT } JUSTIFY; -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
From: Daniel J S. <dan...@ie...> - 2004-07-26 20:23:27
|
Ethan Merritt wrote: >On Saturday 24 July 2004 07:44 pm, Daniel J Sebald wrote: > > >>typedef enum H_JUSTIFY { >> H_LEFT, >> H_CENTRE, >> H_RIGHT >>} H_JUSTIFY; >> >>typedef enum JUSTIFY { >> LEFT, >> CENTRE, >> RIGHT >>} JUSTIFY; >> >> >> > >Be careful if you consolidate these admittedly redundant definitions. > >Some of them depend on the ordering of the enums, >which of course entirely violates the spirit of using an enum >in the first place. > >For example, see this alarming comment in term_api.h > >/* this order means we can use x-(just*strlen(text)*t->h_char)/2 if > * term cannot justify > */ >typedef enum JUSTIFY { > LEFT, > CENTRE, > RIGHT >} JUSTIFY; > > Ah, geepers... There is nothing wrong with doing that, I think. But that bit of code should be changed to /* this assignment means we can use x-(just*strlen(text)*t->h_char)/2 if * term cannot justify */ typedef enum JUSTIFY { LEFT = 0, CENTRE = 1, RIGHT = 2 } JUSTIFY; But either way, a blind replacing of LEFT by H_LEFT, etc. wouldn't change the order of anything. Dan |
From: Daniel J S. <dan...@ie...> - 2004-07-26 19:23:28
|
Ethan Merritt wrote: >Linux Weekly News points out that IBM has put up a web site >with a gnuplot version 4.0 tutorial. > > http://www-106.ibm.com/developerworks/library/l-gnuplot/ > > I love that Sastry openned with the paragraph that he did, discussing the two different methods or philosophies generating graphs. I think we've had that discussion here in the past. It's good for new-comers to think about that. Dan |
From: Daniel J S. <dan...@ie...> - 2004-07-26 19:15:59
|
I meant "you" in the rhetorical sense, not literal, of course. Daniel J Sebald wrote: > Oh. Yeah, it is always safe to go through and verify what you want to > change. And that is why it is good to get out of the bad habit of > naming variables such that one is a substring of another like > > JUSTIFY > VERT_JUSTIFY > > then you often don't have to worry about such things. |
From: Daniel J S. <dan...@ie...> - 2004-07-26 19:02:30
|
Hans-Bernhard Broeker wrote: >>>I usually do this kind of replacement either through cscope ("replace this >>>text:") >>> >>> >>Will this work on "whole words" (i.e., similar to grep's -w) so one >>doesn't need to do the " OLDTEXT" ",OLDTEXT" "(OLDTEXT" monkey business? >> >> > >No. It's essentially just a multi-file 'sed', but with the added benefit >of showing you every occurence it'll replace, and letting you toggle if >you want that or not. The actual work is done through 'ed'. > Oh. Yeah, it is always safe to go through and verify what you want to change. And that is why it is good to get out of the bad habit of naming variables such that one is a substring of another like JUSTIFY VERT_JUSTIFY then you often don't have to worry about such things. (You'll notice that is why the space, or comma, or round bracket before the word when searching... that ostensibly changes the substring variable, e.g., "JUSTIFY" to its own unique word " JUSTIFY".) In the case of what is in subdirectory "term", I don't think you have to be too careful about replacing something like CENTRE with H_CENTRE. It is only things like documentation or stuff printed to a screen or file where " VERTICAL" (notice the space preceding the word) might actually should remain " VERTICAL" and not " GPKEY_VERTICAL". >>>, or via Emacs' M-x tags-query-replace. The latter will require >>>a TAGS file built from all relevant files (including the *.trm's). >>> >>> >>> >>grep -l -s -w -r ",$1" * >> >> > >You misunderstand me. The TAGS is really a tag-file (as in: the one used >by vi and emacs to directly jump to a given C function). You create that >with 'etags'. > Ah. Well, anyway, could you give me a bit of guidance on whether you might consider the changes in notation. I'm trying to decide if I should take a momentary diversion here to fix up the key placement or just forget it and let the key land on a portion of the signal trace. In any case, if the change is scrapped, you might still want to fix that memory leak in the "show_key" function. Dan |
From: Ethan M. <merritt@u.washington.edu> - 2004-07-26 17:32:46
|
Linux Weekly News points out that IBM has put up a web site with a gnuplot version 4.0 tutorial. http://www-106.ibm.com/developerworks/library/l-gnuplot/ -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
From: Hans-Bernhard B. <br...@ph...> - 2004-07-25 11:53:28
|
On Sat, 24 Jul 2004, Hans-Bernhard Broeker wrote: > > That isn't the behavior I see. No matter what value of bmargin I use, > > the height of the plot becomes shorter when "set key below" is used. > > Hmmmm... yes, a bug. The vertical order of things apparently is > > graph box > x tics > bmargin > key below > > key below and bmargin should trade places. Correction to self: no. The 'key below' box should be *inside* the 'bmargin' region. I.e. the problem is that ybot is modified by the code that does the 'key below' layout in boundary(), even in the presence of a pre-set bmargin. Patch is on the way in. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
From: Hans-Bernhard B. <br...@ph...> - 2004-07-25 11:22:47
|
On Sat, 24 Jul 2004, Daniel J Sebald wrote: > typedef enum JUSTIFY { > LEFT, > CENTRE, > RIGHT > } JUSTIFY; > > typedef enum VERT_JUSTIFY { > JUST_TOP, > JUST_CENTRE, > JUST_BOT > } VERT_JUSTIFY; > > is one egregious example of lack of consistency. There really aren't > too many occurrences to do a fast group replace on all the files. You may be overlooking the terminal driver files in that count: hbb ~/gp36/gnuplot/src $ cscope -L0 CENTRE | wc -l 93 hbb ~/gp36/gnuplot/src $ cscope -L0 LEFT | wc -l 127 But you're right: if any time is the right one to make changes like this, now is. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
From: Hans-Bernhard B. <br...@ph...> - 2004-07-25 11:17:10
|
On Sat, 24 Jul 2004, Daniel J Sebald wrote: > True. But, to me anyway, the more important detail is that there be a > way of making the plots the same size, and aligned. And for that, the 'set lmargin' family of commands is quite sufficient, as long as you keep the size and origin of the plottable page fixed. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
From: Daniel J S. <dan...@ie...> - 2004-07-25 02:19:36
|
Hans-Bernhard Broeker wrote: >On Sat, 24 Jul 2004, Daniel J Sebald wrote: > > > >>typedef enum en_key_stack_direction { >> VERTICAL, >> HORIZONTAL >>} t_key_stack_direction; >> >> > >[...] > >I would strongly recommend to prefix these enum labels with the word KEY_ >or even GPKEY_, to reduce the risk of namespace pollution. > Okay. GPKEY_ it is. >>/* Horizontal positions of the key box: (left, right, center) */ >> >> > >Why not just use the existing JUSTIFY and VERT_JUSTIFY enums from the >terminal layer for these? > Because the current code has its own versions of those and that is where I started from. Also, I didn't pay close attention to JUSTIFY/VERT_JUSTIFY. If you want to reuse those, which isn't a bad idea, I might suggest changing what is in term_api.h to typedef enum H_JUSTIFY { H_LEFT, H_CENTRE, H_RIGHT } H_JUSTIFY; typedef enum V_JUSTIFY { V_TOP, V_CENTRE, V_BOT } V_JUSTIFY; because typedef enum JUSTIFY { LEFT, CENTRE, RIGHT } JUSTIFY; typedef enum VERT_JUSTIFY { JUST_TOP, JUST_CENTRE, JUST_BOT } VERT_JUSTIFY; is one egregious example of lack of consistency. There really aren't too many occurrences to do a fast group replace on all the files. I'm sure it would mess up some patches, but those should be easy fixes from the compilation errors. Dan |
From: Daniel J S. <dan...@ie...> - 2004-07-25 01:52:31
|
Hans-Bernhard Broeker wrote: >Depends on what it is you're trying to do. That quantity is >terminal-dependant, yes, but not really unkown. And it's fixed for the >time being. So it depends on whether you want the graph box exactly in >some particular physical size, or just want to fix it in place from one >plot to the next. Multiplots are a tricky business of their own, then. > >>From a formal viewpoint, requesting the graph box in any fixed size >positions, independent of how many decorations surround it, is bound to >lead to sub-optimal or broken plots one way or the other for at least some >of the terminals: if the output page size is not controllable by gnuplot >(e.g. for printer terminals), and you fix the graph box on top of that, >you'll either have elements of the plots fall off the page, or leave >undesirably large margins, as the amount of decoration in the margins >varies. > True. But, to me anyway, the more important detail is that there be a way of making the plots the same size, and aligned. If the "decorations" are off a bit here or there, that's tolerable. Also, in many cases there is a location option for many of the decorations if one wants to get meticulous. With scientific plotting, if you want to compare something in one plot with what is in a nearby plot and spatial relation is important, it is nice to have the comfort of knowing that the graphs are the same size. As a case in point, try reaching some conclusion about time signals if the margin of one is longer than the other because of annotation. >[set key below...] > > > >>That isn't the behavior I see. No matter what value of bmargin I use, >>the height of the plot becomes shorter when "set key below" is used. >> >> > >Hmmmm... yes, a bug. The vertical order of things apparently is > > graph box > x tics > bmargin > key below > >key below and bmargin should trade places. Which means someone will >have to go into boundary() and fix this. That's about the scariest >function in all of gnuplot. > Hey, fools rush in. Dan |
From: Ethan A M. <merritt@u.washington.edu> - 2004-07-24 20:44:30
|
On Wednesday 21 July 2004 12:33 am, Volker Dobler wrote: > There are two functions: quote_str and m_quote_capture. > Using quote_str you will have to do memory allocation yourself, > whereas m_quote_capture will do allocation for you if I remember > correctly. My old patch replaced (hopfully) all the invocations > of quote_str with m_quote_capture and did substitution there. You guys may yet convince me. I think it may be even cleaner than you describe, because the expression parsing code can now handle string constants as well as string-valued functions. So many of the instances of isstring() + m_quote_capture() can be replaced by const_express(&a). Better yet, in many places this is what the code was going to try next anyhow. So the test for string constants as a special case just goes away. Example (taken from the "print" command): #ifndef GP_STRING_VARS /* This is the version 4.0 code */ if (isstring(c_token)) { s = NULL; m_quote_capture(&s, c_token, c_token); fputs(s, print_out); need_space = 0; free(s); ++c_token; } else { (void) const_express(&a); if (need_space) putc(' ', print_out); need_space = 1; disp_value(print_out, &a); } #else /* This is the code after adding string variables */ (void) const_express(&a); disp_value(print_out, &a); if (a.type == STRING) free(a.v.string_val); else putc(' ', print_out); #endif Yes, I know that this code fragment does not exactly duplicate the whitespace layout of the old behaviour. I also see that I must work on when, if ever, to print quote marks when showing the value of string variables. The only thing I am stuck on at the moment is trying to automatically free the dynamically-allocated string created by evaluation of const_express(&a). It is annoying to test for it everywhere, though I suppose it's no worse than having to do the same thing after m_quote_capture in the current code. -- Ethan A Merritt Department of Biochemistry & Biomolecular Structure Center University of Washington, Seattle |
From: Hans-Bernhard B. <br...@ph...> - 2004-07-24 10:23:41
|
On Sat, 24 Jul 2004, Daniel J Sebald wrote: > typedef enum en_key_stack_direction { > VERTICAL, > HORIZONTAL > } t_key_stack_direction; [...] I would strongly recommend to prefix these enum labels with the word KEY_ or even GPKEY_, to reduce the risk of namespace pollution. > /* Horizontal positions of the key box: (left, right, center) */ Why not just use the existing JUSTIFY and VERT_JUSTIFY enums from the terminal layer for these? -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
From: Hans-Bernhard B. <br...@ph...> - 2004-07-24 10:13:50
|
On Sat, 24 Jul 2004, Daniel J Sebald wrote: > > Now I see what you are saying. There is code for the key all over > > "graphics.c". That's the general state of affairs. gnuplot's code has never really been organized in terms of individual plot elements. It's pretty much always followed the flow of activity instead. That's why some of those functions are so embarrasingly long. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
From: Hans-Bernhard B. <br...@ph...> - 2004-07-24 10:13:50
|
On Fri, 23 Jul 2004, Daniel J Sebald wrote: > Hans-Bernhard Broeker wrote: > >It doesn't strictly have to be zero. > Oh. I didn't know that. Or I did but didn't make the connection. > There is still a bit of uncertainty, isn't there? If I specify the > margin to 1, for example, I'm not sure what the character height is in > terms of plot units. Hence, subtract that unknown quantity from the > plot size and the size ends up with some uncertainty. Depends on what it is you're trying to do. That quantity is terminal-dependant, yes, but not really unkown. And it's fixed for the time being. So it depends on whether you want the graph box exactly in some particular physical size, or just want to fix it in place from one plot to the next. Multiplots are a tricky business of their own, then. From a formal viewpoint, requesting the graph box in any fixed size positions, independent of how many decorations surround it, is bound to lead to sub-optimal or broken plots one way or the other for at least some of the terminals: if the output page size is not controllable by gnuplot (e.g. for printer terminals), and you fix the graph box on top of that, you'll either have elements of the plots fall off the page, or leave undesirably large margins, as the amount of decoration in the margins varies. [set key below...] > That isn't the behavior I see. No matter what value of bmargin I use, > the height of the plot becomes shorter when "set key below" is used. Hmmmm... yes, a bug. The vertical order of things apparently is graph box x tics bmargin key below key below and bmargin should trade places. Which means someone will have to go into boundary() and fix this. That's about the scariest function in all of gnuplot. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
From: Daniel J S. <dan...@ie...> - 2004-07-24 09:01:16
|
I've put a patch on SourceForge (997001 key cleanup and enhancement) that has the enumerations described previously, fixes the memory leak, makes "outside" and "under" more consistent. Otherwise, it mimics the behavior of the current key placement rules. Please consider moving it into CVS, in which case it can serve as a starting point for further key development. Dan Daniel J Sebald wrote: > I've pretty much got a patch with additional enumerations (below) that > is meant to mimic the current behavior of key placement. So, maybe > wait a couple days so I can test it. The idea would be to move the > fixes and new enumerations in right away, then modifications to the > placement behavior can be done over time as a patch on sourceforge. > > Dan > > > > /* The stacking direction of the key box: (vertical, horizontal) */ > typedef enum en_key_stack_direction { > VERTICAL, > HORIZONTAL > } t_key_stack_direction; > > /* The region, with respect to the border, key is located: (inside, > outside) */ > typedef enum en_key_region { > INTERIOR, > EXTERIOR > } t_key_region; > > /* The vertical positioning of the key box: (top, bottom, center) */ > typedef enum en_key_vertical_position { > VTOP, > VBOTTOM, > VCENTER > } t_key_vertical_position; > > /* Horizontal positions of the key box: (left, right, center) */ > typedef enum en_key_horizontal_position { > HLEFT, > HRIGHT, > HCENTER > } t_key_horizontal_position; > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > > -- Dan Sebald email: daniel DOT sebald AT ieee DOT org URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/ |
From: Daniel J S. <dan...@ie...> - 2004-07-24 07:35:26
|
And here is another inconsistency. Try the following and watch were the key is in each case: set key outside plot sin(x) set key under replot set key outside replot I've pretty much got a patch with additional enumerations (below) that is meant to mimic the current behavior of key placement. So, maybe wait a couple days so I can test it. The idea would be to move the fixes and new enumerations in right away, then modifications to the placement behavior can be done over time as a patch on sourceforge. Dan /* The stacking direction of the key box: (vertical, horizontal) */ typedef enum en_key_stack_direction { VERTICAL, HORIZONTAL } t_key_stack_direction; /* The region, with respect to the border, key is located: (inside, outside) */ typedef enum en_key_region { INTERIOR, EXTERIOR } t_key_region; /* The vertical positioning of the key box: (top, bottom, center) */ typedef enum en_key_vertical_position { VTOP, VBOTTOM, VCENTER } t_key_vertical_position; /* Horizontal positions of the key box: (left, right, center) */ typedef enum en_key_horizontal_position { HLEFT, HRIGHT, HCENTER } t_key_horizontal_position; |
From: Daniel J S. <dan...@ie...> - 2004-07-24 06:49:31
|
Daniel J Sebald wrote: > Ethan Merritt wrote: > >> I quite agree with you that the current setup has lots of problems. >> I thought a bit about trying to introduce explicit code to control the >> number of rows and columns. Then I looked at the code and shuddered. >> > > Now I see what you are saying. There is code for the key all over > "graphics.c". And also graph3d.c has some of the similar code replicated... not good. The "show key" may have a memory leak. There is a magic number for memory allocation: char *str = gp_alloc(30, "show_key"); and, actually, the fact the string gets pumped to stderr means there really isn't any need for "str". Anyway, the above allocation is done *every* time the routine is entered. But the free is only done conditionally on KEY_AUTO_PLACEMENT. I created a script file with "show key" repeated several times. Watching system memory, when KEY_AUTO_PLACEMENT is active, loading that file does nothing to system memory. But after "set key 30,30", calling said script file builds up system memory. Dan |