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

Re: Some misprints and problems

[Timothée L. <tim...@lp...>]

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

Re: Some misprints and problems

[Shigeharu T. <sh...@ie...>]

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
+========================================================+

Re: Some misprints and problems

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

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

Re: gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

[Tatsuro M. <tma...@ya...>]

Hello

--- Petr Mikulik <mi...@ph...> wrote:

> > The binaries of the gnuplot development series are available at
> >     http://www.gnuplot.info/development/binaries/
> 
> I've just updated the 4.3-cvs binaries of windows, cygwin-x11 as well as the 
> tarball. Available from the gnuplot homepage or directly the URL above.

Thanks.
I will see your package and arrange my binary in your style.

Regards.

Tatsuro



--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

Re: gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

[Petr M. <mi...@ph...>]

> 
> But I see that the bug demonstrated by the attached script is still present.
> I have reverted in CVS the patch that I suspect is responsible.
> 
> Bastian Maerkisch is looking into the problem, but until we have a more solid
> fix I think reversion is best.
> 
> Petr:
> Could you test whether the latest CVS (just changed a few minutes ago) fixes
> the win terminal bug as tested by the attached script?

Now it is even worse -- no colour lines at all! Just black lines for 
win_polyline.bug, and empty plot for winpoly.gp.

--
PM

Re: gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

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

Here is an even more simple-minded test case that shows the
code is still seriously broken. It works fine for all 
rgb-capable terminal except win.

plot '-' using 1:2:3 with lines lc rgb var
0 0 0
 
0 0   51200
1 0.3 51200

0 0.3 51200
1 0.6 51200

0 0.6 51200
1 0.9 51200

e

-- 
Ethan A Merritt

Re: gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

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

On Monday 08 September 2008 11:34:24 Bastian Maerkisch wrote:
> 
> Ethan Merritt schrieb:
> > 
> > But I see that the bug demonstrated by the attached script is still present.
> > I have reverted in CVS the patch that I suspect is responsible.
> 
> > Bastian Maerkisch is looking into the problem, but until we have a more solid
> > fix I think reversion is best.
> > 
> > Petr:
> > Could you test whether the latest CVS (just changed a few minutes ago) fixes
> > the win terminal bug as tested by the attached script?
> > 
> > Bastian:
> > The original patch that I have reverted looks wrong to me, now that I have
> > stared at the code.  Do you have a script that demonstrates the problem it
> > was originally intended to fix?  So far as I can see, there should be no
> > path through the code that produces a "polyline of length 1".  The vertex
> > counter starts at 1, and each polyline vector call increases it.  So 
> > (polyi == 1) really means a polyline of length 0, and we shouldn't draw it.
> > But maybe it should execute a MoveTo()?
> > 
> 
> Ethan, your conclusion is not correct.
> 
> Polylines are drawn with commands like this:
> MOVE, VECTOR, VECTOR, VECTOR, VECTOR, ...
> The code defines the end of a polyline if the next command is not VECTOR.

But after the first MOVE, polyi is *already* equal to 1.
The (polyi == 1) case corresponds to no VECTORs at all.
A length 1 polyline must necessarily have (polyi == 2).

> In the case of RGB color lines there actually are length 1 polylines. 
> That's because they are drawn with commands like like that:
> MOVE, COLOR, VECTOR, COLOR, VECTOR, COLOR, ...., VECTOR
  ^^^^ polyi = 1
               ^^^^^^ polyi = 2

> The fix, which you just reverted, fixes this.

I'm working blind, since I can't actually compile and test this.
But I sure don't see from the code how you can ever have a polyline
with (polyi == 1).

> The new bug is IMHO triggered by some ill-behaviour of the Windows API. 
> In the case you just send me the command sequence is like this:
> MOVE, VECTOR, COLOR, VECTOR, COLOR, VECTOR, COLOR, ...., VECTOR
> The first move and vector command reference the same point. The windows 
> API optimizes this away and does not even update the drawing position.

I don't understand what you are saying.  By "optimize away" do you mean
"ignores both the move and the vector"?  That would be a serious bug indeed.
It seems especially strange the the optimization would only occur if there
is an intervening call to COLOR (remember that the error is not triggered
if the line color is constant).

What exactly does "COLOR" mean in that sequence?
Is it a call to to W_pm3d_setcolor, or is it an actual API call?

> So with the next VECTOR we get "spurious" lines.
> 
> Why don't you try the single line fix I sent to the mailing list? We 
> hist add an additional MoveTo() after each Polyline, like this:
> 
> if ((lastop==W_vect) && (curptr->op!=W_vect)) {
> 	    if (polyi >= 2) {
> 		Polyline(hdc, ppt, polyi);
> 		MoveTo(hdc, ppt[polyi-1].x, ppt[polyi-1].y);  /* make sure we move the 
> drawing position in case of empty polygons */
> 	    } else if (polyi == 1)
> 		LineTo(hdc, ppt[0].x, ppt[0].y);
> 	    polyi = 0;
> 	}

You've tested that this fixes the bug show by the test script?

I may be more than usually befuddled, but I just don't understand how it could.
If there is a spurious line, then you will have already drawn it
before you call the MoveTo.

For what it's worth, the test case *should* be generating a sequence like
COLOR MOVE VECTOR COLOR MOVE VECTOR COLOR MOVE VECTOR
Possibly with interspersed calls to W_linetype, although they are supposed to
be optimized away at a higher level.

If it's not doing that, then I think the true bug may lie entirely elsewhere. 
You said earlier that the calls to WIN_set_color were generating empty polylines,
but only in the case of variable color.  Doesn't that seem strange?

-- 
Ethan A Merritt

Re: gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

[Bastian M. <bma...@we...>]

Ethan Merritt schrieb:
> 
> But I see that the bug demonstrated by the attached script is still present.
> I have reverted in CVS the patch that I suspect is responsible.

> Bastian Maerkisch is looking into the problem, but until we have a more solid
> fix I think reversion is best.
> 
> Petr:
> Could you test whether the latest CVS (just changed a few minutes ago) fixes
> the win terminal bug as tested by the attached script?
> 
> Bastian:
> The original patch that I have reverted looks wrong to me, now that I have
> stared at the code.  Do you have a script that demonstrates the problem it
> was originally intended to fix?  So far as I can see, there should be no
> path through the code that produces a "polyline of length 1".  The vertex
> counter starts at 1, and each polyline vector call increases it.  So 
> (polyi == 1) really means a polyline of length 0, and we shouldn't draw it.
> But maybe it should execute a MoveTo()?
> 

Ethan, your conclusion is not correct.

Polylines are drawn with commands like this:
MOVE, VECTOR, VECTOR, VECTOR, VECTOR, ...
The code defines the end of a polyline if the next command is not VECTOR.

In the case of RGB color lines there actually are length 1 polylines. 
That's because they are drawn with commands like like that:
MOVE, COLOR, VECTOR, COLOR, VECTOR, COLOR, ...., VECTOR

The fix, which you just reverted, fixes this.

The new bug is IMHO triggered by some ill-behaviour of the Windows API. 
In the case you just send me the command sequence is like this:
MOVE, VECTOR, COLOR, VECTOR, COLOR, VECTOR, COLOR, ...., VECTOR
The first move and vector command reference the same point. The windows 
API optimizes this away and does not even update the drawing position.
So with the next VECTOR we get "spurious" lines.

Why don't you try the single line fix I sent to the mailing list? We 
hist add an additional MoveTo() after each Polyline, like this:

if ((lastop==W_vect) && (curptr->op!=W_vect)) {
	    if (polyi >= 2) {
		Polyline(hdc, ppt, polyi);
		MoveTo(hdc, ppt[polyi-1].x, ppt[polyi-1].y);  /* make sure we move the 
drawing position in case of empty polygons */
	    } else if (polyi == 1)
		LineTo(hdc, ppt[0].x, ppt[0].y);
	    polyi = 0;
	}

Re: Some misprints and problems

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

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

Re: gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

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

On Monday 08 September 2008 09:54:33 Petr Mikulik wrote:
> > The binaries of the gnuplot development series are available at
> >     http://www.gnuplot.info/development/binaries/
> 
> I've just updated the 4.3-cvs binaries of windows, cygwin-x11 as well as the 
> tarball. Available from the gnuplot homepage or directly the URL above.

That's great.

But I see that the bug demonstrated by the attached script is still present.
I have reverted in CVS the patch that I suspect is responsible.

Bastian Maerkisch is looking into the problem, but until we have a more solid
fix I think reversion is best.

Petr:
Could you test whether the latest CVS (just changed a few minutes ago) fixes
the win terminal bug as tested by the attached script?

Bastian:
The original patch that I have reverted looks wrong to me, now that I have
stared at the code.  Do you have a script that demonstrates the problem it
was originally intended to fix?  So far as I can see, there should be no
path through the code that produces a "polyline of length 1".  The vertex
counter starts at 1, and each polyline vector call increases it.  So 
(polyi == 1) really means a polyline of length 0, and we shouldn't draw it.
But maybe it should execute a MoveTo()?


-- 
Ethan A Merritt

Re: gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

[Petr M. <mi...@ph...>]

> The binaries of the gnuplot development series are available at
>     http://www.gnuplot.info/development/binaries/

I've just updated the 4.3-cvs binaries of windows, cygwin-x11 as well as the 
tarball. Available from the gnuplot homepage or directly the URL above.

Enjoy,
  P.M.

Re: gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

[J. A. V. <jai...@gm...>]

This is a great work :)

On Mon, Sep 8, 2008 at 10:49 AM, Tatsuro MATSUOKA <tma...@ya...>wrote:

> Hello
>
> --- Petr Mikulik <mi...@ph...> wrote:
>
> > > I have opened a new web site which distributes gnuplot 4.3 (cvs) cygwin
> > > binaries prepared by gcc-4.x.x.
> > > http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/
> >
> > The binaries of the gnuplot development series are available at
> >     http://www.gnuplot.info/development/binaries/
> >
> > I refresh them from time to time. Considering cygwin-x11, currently there
> is
> >     gp43-Mar24_2008-winbinX11.zip
> >
> > I propose that you prepare the gnuplot4.3.cygwin.tar.bz2 using the same
> file
> > contents (but updated) as the file mentioned above. Then I can put it on
> the
> > gnuplot web site and the updated package will be easily accessible by
> > anybody from this traditional location, referenced even from the gnuplot
> > main page.
>
> I agree with your proposal.  Please give me some time. I will do the work
> on it next weekend.
>
> Regards
>
> Tatsuro
>
>
> --------------------------------------
> Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
> http://pr.mail.yahoo.co.jp/mlb/
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

[Tatsuro M. <tma...@ya...>]

Hello

--- Petr Mikulik <mi...@ph...> wrote:

> > I have opened a new web site which distributes gnuplot 4.3 (cvs) cygwin 
> > binaries prepared by gcc-4.x.x.
> > http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/
> 
> The binaries of the gnuplot development series are available at
>     http://www.gnuplot.info/development/binaries/
> 
> I refresh them from time to time. Considering cygwin-x11, currently there is
>     gp43-Mar24_2008-winbinX11.zip
> 
> I propose that you prepare the gnuplot4.3.cygwin.tar.bz2 using the same file 
> contents (but updated) as the file mentioned above. Then I can put it on the 
> gnuplot web site and the updated package will be easily accessible by 
> anybody from this traditional location, referenced even from the gnuplot 
> main page.

I agree with your proposal.  Please give me some time. I will do the work on it next weekend.

Regards

Tatsuro


--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

Re: gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

[J. A. V. <jai...@gm...>]

Thank you very much Tatsuro,

I will probably extract the gnuplot from the octave files.

Jaime

Re: gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

[Petr M. <mi...@ph...>]

> I have opened a new web site which distributes gnuplot 4.3 (cvs) cygwin 
> binaries prepared by gcc-4.x.x.
> http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

The binaries of the gnuplot development series are available at
    http://www.gnuplot.info/development/binaries/

I refresh them from time to time. Considering cygwin-x11, currently there is
    gp43-Mar24_2008-winbinX11.zip

I propose that you prepare the gnuplot4.3.cygwin.tar.bz2 using the same file 
contents (but updated) as the file mentioned above. Then I can put it on the 
gnuplot web site and the updated package will be easily accessible by 
anybody from this traditional location, referenced even from the gnuplot 
main page.

---
PM

Re: gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

[Tatsuro M. <tma...@ya...>]

Hello

Unfortunately wxt terminal does not work yet because pango and cario on cygwin is too old to use
current wxt terminal on cygwin.
If you want to achive your request on cygwin, you have to build recent cario and pango and some
missing componets.

If you want wxt terminal on windows, it is better to use gnuplot bundled with octave 3.5.10.
Once you install octave for windows and search bin directry.
You can select the gnuplot for windows and related dll files. here.

You can find required dll files for wgnuplot, pgnuplot etc. by the cygcheck command.
It is the most easy way at to get the wxt terminal for windows.


Regards

Tatsuro




--- Jaime Armend醇@riz Villalba <jai...@gm...> wrote:

> Hello,
> 
> This is really good news. If I've understood well, if I compile this
> sourcecode with cygwin I will obtain a gnuplot binary with the WXT
> interface?
> 
> I've been waiting an easy way to have the WXT interface for windows, and If
> you can confirm that with this way I will obtain it, I will compile it as
> soon as possible and let all you know my results.
> 
> Thank you very much Tatsuro,
> 
> Jaime
> 


--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

Re: gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

[J. A. V. <jai...@gm...>]

Hello,

This is really good news. If I've understood well, if I compile this
sourcecode with cygwin I will obtain a gnuplot binary with the WXT
interface?

I've been waiting an easy way to have the WXT interface for windows, and If
you can confirm that with this way I will obtain it, I will compile it as
soon as possible and let all you know my results.

Thank you very much Tatsuro,

Jaime

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x

[Tatsuro M. <tma...@ya...>]

Hi

I have opened a new web site which distributes gnuplot 4.3 (cvs) cygwin binaries prepared by
gcc-4.x.x.

http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

Regards

Tatsuro
 

--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

Some misprints and problems

[Shigeharu T. <sh...@ie...>]

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
+========================================================+

Re: texi in CVS?

[Philipp K. J. <ja...@ie...>]

Thanks!

On Friday 05 September 2008 12:04, you wrote:
> Philipp K. Janert wrote:
> > Apparently, the file
> > 	gnuplot.texi
> > is under CVS version control. Shouldn't just
> > the master (ie gnuplot.doc) be in CVS, since
> > all other files are built from it?
>
> Should: yes.  The general rule is that files generated from others
> shouldn't go into version control themselves.  I.e. no Makefile.in, no
> Makefile, no configure, no gnuplot.info, and no gnuplot.texi.
>
> But some people strongly objected to the idea that this would require
> everyone building from CVS to have Emacs...
>
> The same objections keep us from installing a normal rule to rebuild
> gnuplot.texi automatically.  A CVS checkout jumbles timestamps, so even
> with gnuplot.texi in CVS, it would be rebuilt on most fresh checkouts.

Re: texi in CVS?

[Hans-Bernhard B. <HBB...@t-...>]

Philipp K. Janert wrote:

> Apparently, the file
> 	gnuplot.texi
> is under CVS version control. Shouldn't just
> the master (ie gnuplot.doc) be in CVS, since
> all other files are built from it?

Should: yes.  The general rule is that files generated from others 
shouldn't go into version control themselves.  I.e. no Makefile.in, no 
Makefile, no configure, no gnuplot.info, and no gnuplot.texi.

But some people strongly objected to the idea that this would require 
everyone building from CVS to have Emacs...

The same objections keep us from installing a normal rule to rebuild 
gnuplot.texi automatically.  A CVS checkout jumbles timestamps, so even 
with gnuplot.texi in CVS, it would be rebuilt on most fresh checkouts.

texi in CVS? (was: Target to make PS/PDF documentation?)

[Philipp K. J. <ja...@ie...>]

Since we are talking about documentation,
here is something that has confused me 
before:

Apparently, the file
	gnuplot.texi
is under CVS version control. Shouldn't just
the master (ie gnuplot.doc) be in CVS, since
all other files are built from it?

Best,

		Ph.


On Thursday 04 September 2008 12:01, Hans-Bernhard Bröker wrote:
> Ethan A Merritt wrote:
> > As Phillip pointed out, however, not all of the subdirectory
> > targets are recognized from the top level directory.
>
> Ultimately the reason is that docs/Makefile.in is not made from a
> docs/Makefile.am, and that gnuplot.info is not our primary documentation
> source file.  If it were, it would only take a single line in
> docs/Makefile.am:
>
>     info_TEXINFOS = gnuplot.info
>
> and automake would automatically set up rules build the documentation in
> various formats.  The only downside, if any, would be that texinfo's
> "makeinfo" program would become a build prerequisite, since automake
> insists on building and installing at least the info version in such a
> case.
>
> Oh, and FWIW, the options for building the other help document formats
> _are_ pointed at: right there in README it says:
>
> <quote>The new gnuplot user should begin by reading the general information
> available by typing `help` after running gnuplot. Then read about the
> `plot` command (type `help plot`).  The manual for gnuplot (which is a
> nicely formatted version of the on-line help information) can be
> printed either with TeX, troff or nroff.  Look at the docs/Makefile
> for the appropriate option.</quote>
>
> And once you do look into docs/Makefile (or Makefile.in, if you haven't
> configured yet), it does mention ps, pdf and friends quite clearly.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK & win
> great prizes Grand prize is a trip for two to an Open Source event anywhere
> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Failed build on MacOS

[Daniel F. <boy...@gm...>]

Hello all,

I was very surprise that gnuplot didn't build, because it is normally  
so stable! I should have taken that as a hit it was my fault...  
Anyway, turns that it was my fault because I was using the wrong  
compiler! See my previous e-mail for the details. Thanks for the  
suggestions.

Cheers,

Dan

Re: Target to make PS/PDF documentation?

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

On Thursday 04 September 2008 12:01:49 Hans-Bernhard Bröker wrote:
> Ethan A Merritt wrote:
> > As Phillip pointed out, however, not all of the subdirectory
> > targets are recognized from the top level directory.  
> 
> Ultimately the reason is that docs/Makefile.in is not made from a 
> docs/Makefile.am, 

I'm just trying to understand the mechanism.
"make pdf" does work from the top level directory,
but "make pdffigures" does not.  Why?
Some piece of the automake/autoconf process adds the necessary
dummy targets for pdf (and pdf-recursive) in all subdirectories.
But what triggers this?  
Is there some keyword I can add somewhere that will do the same for pdffigures?


	Ethan



> and that gnuplot.info is not our primary documentation  
> source file.  If it were, it would only take a single line in 
> docs/Makefile.am:
> 
>     info_TEXINFOS = gnuplot.info
> 
> and automake would automatically set up rules build the documentation in 
> various formats. The only downside, if any, would be that texinfo's  
> "makeinfo" program would become a build prerequisite, since automake 
> insists on building and installing at least the info version in such a case.
> 
> Oh, and FWIW, the options for building the other help document formats 
> _are_ pointed at: right there in README it says:
> 
> <quote>The new gnuplot user should begin by reading the general information
> available by typing `help` after running gnuplot. Then read about the
> `plot` command (type `help plot`).  The manual for gnuplot (which is a
> nicely formatted version of the on-line help information) can be
> printed either with TeX, troff or nroff.  Look at the docs/Makefile
> for the appropriate option.</quote>
> 
> And once you do look into docs/Makefile (or Makefile.in, if you haven't 
> configured yet), it does mention ps, pdf and friends quite clearly.
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Target to make PS/PDF documentation?

[Hans-Bernhard B. <HBB...@t-...>]

Ethan A Merritt wrote:
> As Phillip pointed out, however, not all of the subdirectory
> targets are recognized from the top level directory.  

Ultimately the reason is that docs/Makefile.in is not made from a 
docs/Makefile.am, and that gnuplot.info is not our primary documentation 
source file.  If it were, it would only take a single line in 
docs/Makefile.am:

    info_TEXINFOS = gnuplot.info

and automake would automatically set up rules build the documentation in 
various formats.  The only downside, if any, would be that texinfo's 
"makeinfo" program would become a build prerequisite, since automake 
insists on building and installing at least the info version in such a case.

Oh, and FWIW, the options for building the other help document formats 
_are_ pointed at: right there in README it says:

<quote>The new gnuplot user should begin by reading the general information
available by typing `help` after running gnuplot. Then read about the
`plot` command (type `help plot`).  The manual for gnuplot (which is a
nicely formatted version of the on-line help information) can be
printed either with TeX, troff or nroff.  Look at the docs/Makefile
for the appropriate option.</quote>

And once you do look into docs/Makefile (or Makefile.in, if you haven't 
configured yet), it does mention ps, pdf and friends quite clearly.