Menu
▾
▴
gnuplot-beta
|
From: Shigeharu T. <sh...@ie...> - 2008-09-08 06:48:19
|
shige 09/08 2008 ---------------- I found some points that seem to be misprints and problems in CVS version. 1) misprints (term/emf.trm and docs/gnuplot.doc) ----- From here ----- diff -uN term/emf.trm.ORG term/emf.trm --- term/emf.trm.ORG Mon Sep 8 10:40:54 2008 +++ term/emf.trm Mon Sep 8 14:57:33 2008 @@ -1320,7 +1320,7 @@ " `solid` draws all curves with solid lines, overriding any dashed patterns;", " `linewidth <factor>` multiplies all line widths by this factor.", " `dashlength <factor>` is useful for thick lines.", -" <font> is the name of a font; and ", +" <fontname> is the name of a font; and ", " `<fontsize>` is the size of the font in points.", "", " The nominal size of the output image defaults to 1024x768 in arbitrary", diff -uN docs/gnuplot.doc.ORG docs/gnuplot.doc --- docs/gnuplot.doc.ORG Mon Sep 8 10:40:35 2008 +++ docs/gnuplot.doc Mon Sep 8 14:56:41 2008 @@ -10243,7 +10243,7 @@ ?set view equal_axes ?view equal_axes The command `set view equal_axes` forces the unit length of the x and y axes - to be on the same same. Otherwise by default both axes are scaled to fill the + to be on the same scale. Otherwise by default both axes are scaled to fill the available area. See also `set ticslevel`. ----- To here ----- 2) problems (src/graph3d.c and term/cairo.trm) Some compile errors occur by gcc-3.4.3 on Solaris 9. In /usr/include/sys/types.h of Solaris there is uint32_t but is not u_int32_t. ----- From here ----- diff -uN src/graph3d.c.ORG src/graph3d.c --- src/graph3d.c.ORG Mon Sep 8 10:40:48 2008 +++ src/graph3d.c Mon Sep 8 13:39:23 2008 @@ -661,7 +661,7 @@ /* Allow 'set view equal_axes' to shrink rendered length of either X or Y axis */ if (aspect_ratio_3D == 1.0) { - xscale3d = MIN(xscale3d,yscale3d); + xscale3d = GPMIN(xscale3d,yscale3d); yscale3d = xscale3d; } diff -uN term/cairo.trm.ORG term/cairo.trm --- term/cairo.trm.ORG Mon Sep 8 10:40:53 2008 +++ term/cairo.trm Mon Sep 8 13:31:18 2008 @@ -505,7 +505,11 @@ int stride = cairo_image_surface_get_stride(surface); int i, j, x1 = 0, y1 = 0, x2 = width, y2 = height; +#ifndef __sun typedef u_int32_t uint32; +#else + typedef uint32_t uint32; +#endif uint32 BG = ~0x0; uint32 *row; ----- From here ----- +========================================================+ Shigeharu TAKENO NIigata Institute of Technology kashiwazaki,Niigata 945-1195 JAPAN sh...@ie... TEL(&FAX): +81-257-22-8161 +========================================================+ |
|
From: Shigeharu T. <sh...@ie...> - 2008-12-24 10:36:51
|
shige 12/24 2008 ---------------- I found some points that seem to be problems and misprints in CVS version. 1) problems for new Lua terminal. [a] The definition of CORETERM in docs/Makefile.in lacks the entry of lua terminal. [b] I think the help document inlcuded in term/lua/gnuplot.lua (at pgf.print_help) should also be included in term/lua.trm. [c] The help document in term/lua.trm uses the C macro "LUA_SCRIPT" defined as "gnuplot.lua" at the top of the file. But, it may not replace when making allterm.h which is used docs/doc2tex. 2) misprints (docs/gnuplot.doc rev.1.551) ----- From here ----- --- gnuplot.doc.org 2008-12-24 19:03:52.000000000 +0900 +++ gnuplot.doc 2008-12-24 19:16:40.000000000 +0900 @@ -256,9 +256,10 @@ 3 New plot elements =circles =ellipse +=polygon The `set object` command can now be used to define fixed circles, ellipses, and polygons as well as rectangles. There is a corresponding new plot style - `plot with circles`. See `circles` `ellipse`. + `plot with circles`. See `circle` `ellipse` `polygon`. 3 New or revised terminal drivers Two new drivers based on the cairo and pango libraries are included, @@ -4661,7 +4662,7 @@ For each point in the file, the index value of the data set it appears in is available via the pseudo-column `column(-2)`. This leads to an alternative way of distinguishing individual data sets within a file as shown below. This is - more awkward that the `index` command if all you are doing is selecting one + more awkward than the `index` command if all you are doing is selecting one data set for plotting, but is very useful if you want to assign different properties to each data set. See `pseudocolumns`, `lc variable`. @@ -5100,7 +5101,7 @@ ^ <a href="http://www.gnuplot.info/demo/using.html"> Feeble using demos. ^ </a> -5 pseuodocolumns +5 pseudocolumns ?pseudocolumns ?commands plot datafile using pseudocolumns ?plot datafile using pseudocolumns @@ -7300,7 +7301,7 @@ #\verb@%A@ & full name of day of the week \\ #\verb@%b@ or \verb@%h@ & abbreviated name of the month \\ #\verb@%B@ & full name of the month \\ -#\verb@%d@ & day of the month, 1--31 \\ +#\verb@%d@ & day of the month, 01--31 \\ #\verb@%D@ & shorthand for \verb@"%m/%d/%y"@ (only output) \\ #\verb@%F@ & shorthand for \verb@"%Y-%m-%d"@ (only output) \\ #\verb@%k@ & hour, 0--23 (one or two digits)\\ @@ -7308,7 +7309,7 @@ #\verb@%l@ & hour, 1--12 (one or two digits)\\ #\verb@%I@ & hour, 01--12 (always two digits)\\ #\verb@%j@ & day of the year, 1--366 \\ -#\verb@%m@ & month, 1--12 \\ +#\verb@%m@ & month, 01--12 \\ #\verb@%M@ & minute, 0--60 \\ #\verb@%p@ & "am" or "pm" \\ #\verb@%r@ & shorthand for \verb@"%I:%M:%S %p"@ (only output)\\ @@ -7327,7 +7328,7 @@ %%A@full name of day of the week %%b or %h@abbreviated name of the month %%B@full name of the month -%%d@day of the month, 1--31 +%%d@day of the month, 01--31 %%D@shorthand for "%m/%d/%y" (only output) %%F@shorthand for "%Y-%m-%d" (only output) %%k@hour, 0--23 (one or two digits) @@ -7335,7 +7336,7 @@ %%l@hour, 1--12 (one or two digits) %%I@hour, 01--12 (always two digits) %%j@day of the year, 1--366 -%%m@month, 1--12 +%%m@month, 01--12 %%M@minute, 0--60 %%p@"am" or "pm" %%r@shorthand for "%I:%M:%S %p" (only output) @@ -8612,7 +8613,7 @@ or from <position> rto <position> ... {rto <position>} - The position of the rectangle may be specified by giving the position of a + The position of the polygon may be specified by giving the position of a sequence of vertices. These may be given in axis, graph, or screen coordinates. If relative coordinates are used (rto) then the coordinate type must match that of the previous vertex. @@ -10379,9 +10380,9 @@ The first sets all the four default values. The second changes only scale, to 0.5. -4 equal_axes -?set view equal_axes -?view equal_axes +4 equal +?set view equal +?view equal The command `set view equal xy` forces the unit length of the x and y axes to be on the same scale, and chooses that scale so that the plot will fit on the page. The command `set view equal xyz` additionally sets the z axis ----- To here ----- +========================================================+ Shigeharu TAKENO NIigata Institute of Technology kashiwazaki,Niigata 945-1195 JAPAN sh...@ie... TEL(&FAX): +81-257-22-8161 +========================================================+ |
|
From: Mojca M. <moj...@gm...> - 2008-12-24 10:44:29
|
On Wed, Dec 24, 2008 at 11:36 AM, Shigeharu TAKENO wrote: > shige 12/24 2008 > ---------------- > > I found some points that seem to be problems and misprints in CVS > version. > > 1) problems for new Lua terminal. > > [b] I think the help document inlcuded in term/lua/gnuplot.lua > (at pgf.print_help) should also be included in term/lua.trm. I'm not entirely sure, but I guess that the terminal code should be able to output the contents of term/lua/gnuplot.lua. When one says "help term lua" it returns some help of little use for someone who wants to use the TikZ terminal. help term tikzlua (or whatever the terminal would be called) should return full help for tikz terminal. I'm almost sure that this is possible with properly implemented functions in lua. Mojca |
|
From: Ethan M. <merritt@u.washington.edu> - 2008-09-08 18:06:46
|
On Sunday 07 September 2008 23:48:20 Shigeharu TAKENO wrote: > shige 09/08 2008 > ---------------- > > I found some points that seem to be misprints and problems in CVS > version. > > > 2) problems (src/graph3d.c and term/cairo.trm) > > Some compile errors occur by gcc-3.4.3 on Solaris 9. In > /usr/include/sys/types.h of Solaris there is uint32_t but is not > u_int32_t. > > ----- From here ----- > diff -uN src/graph3d.c.ORG src/graph3d.c > --- src/graph3d.c.ORG Mon Sep 8 10:40:48 2008 > +++ src/graph3d.c Mon Sep 8 13:39:23 2008 > @@ -661,7 +661,7 @@ > > /* Allow 'set view equal_axes' to shrink rendered length of either X or Y axis */ > if (aspect_ratio_3D == 1.0) { > - xscale3d = MIN(xscale3d,yscale3d); > + xscale3d = GPMIN(xscale3d,yscale3d); > yscale3d = xscale3d; > } Petr has added that to CVS. Thanks. > diff -uN term/cairo.trm.ORG term/cairo.trm > --- term/cairo.trm.ORG Mon Sep 8 10:40:53 2008 > +++ term/cairo.trm Mon Sep 8 13:31:18 2008 > @@ -505,7 +505,11 @@ > int stride = cairo_image_surface_get_stride(surface); > int i, j, x1 = 0, y1 = 0, x2 = width, y2 = height; > > +#ifndef __sun > typedef u_int32_t uint32; > +#else > + typedef uint32_t uint32; > +#endif > uint32 BG = ~0x0; > uint32 *row; Yeah. That's what I was worried about when I commented on the pngcairo cropping patch. I don't think it is sufficient to test specifically for __sun. It will break for other compilers and other platforms as well. That typedef is simply wrong. It needs to take the type from somewhere in the cairo headers. Or, at worst, the configure script needs to check for legal types. Note that initializing BG = ~0x0 is also wrong, since it assumes that the background is always solid white. -- Ethan A Merritt |
|
From: Ethan M. <merritt@u.washington.edu> - 2008-09-09 18:48:17
|
On Monday 08 September 2008 11:06:50 Ethan Merritt wrote: > On Sunday 07 September 2008 23:48:20 Shigeharu TAKENO wrote: > > > > I found some points that seem to be misprints and problems in CVS > > version. > > > > > diff -uN term/cairo.trm.ORG term/cairo.trm > > --- term/cairo.trm.ORG Mon Sep 8 10:40:53 2008 > > +++ term/cairo.trm Mon Sep 8 13:31:18 2008 > > @@ -505,7 +505,11 @@ > > int stride = cairo_image_surface_get_stride(surface); > > int i, j, x1 = 0, y1 = 0, x2 = width, y2 = height; > > > > +#ifndef __sun > > typedef u_int32_t uint32; > > +#else > > + typedef uint32_t uint32; > > +#endif > > uint32 BG = ~0x0; > > uint32 *row; > > Yeah. That's what I was worried about when I commented on the > pngcairo cropping patch. > > I don't think it is sufficient to test specifically for __sun. > It will break for other compilers and other platforms as well. > That typedef is simply wrong. > It needs to take the type from somewhere in the cairo headers. > Or, at worst, the configure script needs to check for legal types. > > Note that initializing BG = ~0x0 is also wrong, since it assumes > that the background is always solid white. I have now fixed these in CVS by adding tests in configure.in Cropping will fail silently for platforms that both - do not use autoconf - have (sizeof(int) != 4) This can be fixed by adding an explicit definition of GP_UINT32_T in the appropriate platform-specific configuration file. -- Ethan A Merritt |
|
From: Shigeharu T. <sh...@ie...> - 2008-09-10 01:15:51
|
shige 09/10 2008 ---------------- | From: Ethan Merritt <merritt@u.washington.edu> | To: gnu...@li... | Subject: Re: Some misprints and problems | Date: Tue, 9 Sep 2008 11:48:15 -0700 | Cc: Shigeharu TAKENO <sh...@ie...>, | Petr Mikulik <mi...@ph...> ===== | I have now fixed these in CVS by adding tests in configure.in | Cropping will fail silently for platforms that both | - do not use autoconf | - have (sizeof(int) != 4) | This can be fixed by adding an explicit definition of GP_UINT32_T | in the appropriate platform-specific configuration file. Thank you for the fix. But I think there is a typo. ----- diff -uN configure.in.ORG gnuplot-current/configure.in --- configure.in.ORG Wed Sep 10 10:01:32 2008 +++ configure.in Wed Sep 10 10:12:13 2008 @@ -145,7 +145,7 @@ # Now we need to find what gp_uint32_t (sizeof == 4) will be. if test "$ac_cv_sizeof_u_int32_t" = "4"; then - uint32_t_def='#define GP_UINT32_T uint32_t' + uint32_t_def='#define GP_UINT32_T u_int32_t' AC_DEFINE(GP_UINT32_T, u_int32_t, [ some 32-bit type ]) elif test "$ac_cv_sizeof_int" = "4"; then uint32_t_def='#define GP_UINT32_T unsigned int' ----- +========================================================+ Shigeharu TAKENO NIigata Institute of Technology kashiwazaki,Niigata 945-1195 JAPAN sh...@ie... TEL(&FAX): +81-257-22-8161 +========================================================+ |
|
From: Timothée L. <tim...@lp...> - 2008-09-10 08:13:16
|
Shigeharu TAKENO a écrit : > shige 09/10 2008 > ---------------- > > | From: Ethan Merritt <merritt@u.washington.edu> > | To: gnu...@li... > | Subject: Re: Some misprints and problems > | Date: Tue, 9 Sep 2008 11:48:15 -0700 > | Cc: Shigeharu TAKENO <sh...@ie...>, > | Petr Mikulik <mi...@ph...> > ===== > | I have now fixed these in CVS by adding tests in configure.in > | Cropping will fail silently for platforms that both > | - do not use autoconf > | - have (sizeof(int) != 4) > | This can be fixed by adding an explicit definition of GP_UINT32_T > | in the appropriate platform-specific configuration file. > > Thank you for the fix. But I think there is a typo. > > ----- > diff -uN configure.in.ORG gnuplot-current/configure.in > --- configure.in.ORG Wed Sep 10 10:01:32 2008 > +++ configure.in Wed Sep 10 10:12:13 2008 > @@ -145,7 +145,7 @@ > > # Now we need to find what gp_uint32_t (sizeof == 4) will be. > if test "$ac_cv_sizeof_u_int32_t" = "4"; then > - uint32_t_def='#define GP_UINT32_T uint32_t' > + uint32_t_def='#define GP_UINT32_T u_int32_t' > AC_DEFINE(GP_UINT32_T, u_int32_t, [ some 32-bit type ]) > elif test "$ac_cv_sizeof_int" = "4"; then > uint32_t_def='#define GP_UINT32_T unsigned int' > ----- > Hi, I know it's a bit late, but I'll let you know that cairo-based terminals depend on pango, which in turns depends on GLib, which defines integer types whose sizes are guaranteed on all platforms : gint8, guint8, gint16, guint16, gint32, guint32, gint64, guint64. You can use them by including glib.h first, and then there's no more autoconf magic needed. Besides, I've been using the same kind of byte-wise and 32-bits manipulation with a simple "unsigned int" in gp_cairo.c:gp_cairo_draw_image(), where "unsigned int" is implicitly 32 bits. If you choose to be bullet-proof with this crop code, I guess it's worth changing the image code too ! On a side note, I am inclined to say that it would have been better to fix the code that makes margins too big instead of cropping the picture later... Best regards, Timothée |
|
From: Ethan A M. <merritt@u.washington.edu> - 2008-09-10 15:54:47
|
On Wednesday 10 September 2008, you wrote: > > | I have now fixed these in CVS by adding tests in configure.in > > | Cropping will fail silently for platforms that both > > | - do not use autoconf > > | - have (sizeof(int) != 4) > > | This can be fixed by adding an explicit definition of GP_UINT32_T > > | in the appropriate platform-specific configuration file. > I know it's a bit late, but I'll let you know that cairo-based terminals > depend on pango, which in turns depends on GLib, which defines integer > types whose sizes are guaranteed on all platforms : gint8, guint8, > gint16, guint16, gint32, guint32, gint64, guint64. You can use them by > including glib.h first, and then there's no more autoconf magic needed. uint32_t is defined in the C99 standard, but not for C++. The u_int32_t type is used by BSD and is defined in various compatibility headers. But neither of these is guaranteed to be on all platforms. We explicitly try not to depend on C99 compliance, and also I do not think we can depend on GLib being present. > Besides, I've been using the same kind of byte-wise and 32-bits > manipulation with a simple "unsigned int" in > gp_cairo.c:gp_cairo_draw_image(), where "unsigned int" is implicitly 32 > bits. I think that is not safe. Has the code been tested on native 64-bit machines? That is, machines where sizeof(int)==8 ? I don't currently have such a machine in the lab, but they are not so very rare. I used to have several. > If you choose to be bullet-proof with this crop code, I guess it's > worth changing the image code too ! Yes. If you look in datafile.c, you'll see that there is a ridiculous amount of code and pre-checking just devoted to sorting out the size of possible data units. I wish this could all go away, or be sorted out by autoconf, but so far that's what we've got. > On a side note, I am inclined to say that it would have been better to > fix the code that makes margins too big instead of cropping the picture > later... Well, I'm already on record as disliking the crop option. But if we're going to have it at all, we should at least try to make it compile+work on all platforms. -- Ethan A Merritt |
|
From: Timothée L. <tim...@lp...> - 2008-09-10 16:08:54
|
Ethan A Merritt a écrit : > > uint32_t is defined in the C99 standard, but not for C++. > The u_int32_t type is used by BSD and is defined in various compatibility > headers. But neither of these is guaranteed to be on all platforms. > We explicitly try not to depend on C99 compliance, and > also I do not think we can depend on GLib being present. > My point was that cairo-based terminals do already depend on GLib, so for them we can directly use this library. >> Besides, I've been using the same kind of byte-wise and 32-bits >> manipulation with a simple "unsigned int" in >> gp_cairo.c:gp_cairo_draw_image(), where "unsigned int" is implicitly 32 >> bits. >> > > I think that is not safe. > Has the code been tested on native 64-bit machines? > That is, machines where sizeof(int)==8 ? > I don't currently have such a machine in the lab, but they are not so > very rare. I used to have several. > > My personal machine is an Intel Core2 running a 64-bits distribution, but that's most likely not a guarantee. Instead, wikipedia says that sizeof(int)==4 on 64 bits machines with compilers from Solaris, AIX, HP, Linux, Mac OS X, FreeBSD, IBM z/OS and Microsoft's VC++. I'm not sure I can find a machine with sizeof(int)==8 !! >> On a side note, I am inclined to say that it would have been better to >> fix the code that makes margins too big instead of cropping the picture >> later... >> > > Well, I'm already on record as disliking the crop option. > But if we're going to have it at all, we should at least try to make > it compile+work on all platforms. > > Agreed, of course. Best regards, Timothée |
|
From: Ethan A M. <merritt@u.washington.edu> - 2008-09-10 16:36:59
|
On Wednesday 10 September 2008, Timothée Lecomte wrote: > Ethan A Merritt a écrit : > > > > uint32_t is defined in the C99 standard, but not for C++. > > The u_int32_t type is used by BSD and is defined in various compatibility > > headers. But neither of these is guaranteed to be on all platforms. > > We explicitly try not to depend on C99 compliance, and > > also I do not think we can depend on GLib being present. > > > My point was that cairo-based terminals do already depend on GLib, so > for them we can directly use this library. OK. I fully agree with that. > >> Besides, I've been using the same kind of byte-wise and 32-bits > >> manipulation with a simple "unsigned int" in > >> gp_cairo.c:gp_cairo_draw_image(), where "unsigned int" is implicitly 32 > >> bits. > >> > > > > I think that is not safe. > > Has the code been tested on native 64-bit machines? > > That is, machines where sizeof(int)==8 ? > > I don't currently have such a machine in the lab, but they are not so > > very rare. I used to have several. > > > > > My personal machine is an Intel Core2 running a 64-bits distribution, > but that's most likely not a guarantee. Instead, wikipedia says that > sizeof(int)==4 on 64 bits machines with compilers from Solaris, AIX, HP, > Linux, Mac OS X, FreeBSD, IBM z/OS and Microsoft's VC++. I'm not sure I > can find a machine with sizeof(int)==8 !! DEC Alpha, for one. (Wikipedia is wrong if it implies that *all* compilers from the listed vendors use the LP64 model for data types). -- Ethan A Merritt |
