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

Re: Each x-th element an x-label and boxes with labels

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

On Tuesday 27 January 2009 17:06:20 SteppXXL wrote:
> 
> Hello there
> 
> I got following
> 
> 
> set data style boxes
> 
> set boxwidth 0.9
> set style fill solid 1.0
> 
> set xrange [-1:]
> set yrange [0:]
> 
> set xtics ("5" 0*6, "10" 1*6, "15" 2*6)
> 
> plot 	"data" using ($0):($3) linetype 1, \
> 	"" using ($0):($5>=0 ? $3 : 0) linetype 2
> 
> pause -1 "Hit return to continue"
> 
> 
> with data
> 
> 5	1	32	914	2 classe(s), 1 transition(s)
> 5	2	16	922	2 classe(s), 1 transition(s)
> 5	3	8	1544	137 classe(s), 39 transition(s)
> 5	4	8	888	1 classe(s), 0 transition(s)
> 5	5	16	903	1 classe(s), 0 transition(s)
> 5	6	16	1139	
> 10	1	32	1011	2 classe(s), 1 transition(s)
> 10	2	16	1003	1 classe(s), 0 transition(s)
> 10	3	32	1080	4 classe(s), 4 transition(s)
> 10	4	64	1047	4 classe(s), 3 transition(s)
> 10	5	128	1022	
> 10	6	128	1011	1 classe(s), 0 transition(s)
> 15	1	256	1182	3 classe(s), 3 transition(s)
> 15	2	128	1393	10 classe(s), 19 transition(s)
> 15	3	256	1131	
> 15	4	128	1336	8 classe(s), 16 transition(s)
> 15	5	64	1084	2 classe(s), 1 transition(s)
> 15	6	32	1144	3 classe(s), 2 transition(s)
> 
> 
> Now I urgently need to label the x-axis as written above but dynamical:
> At each 6-th element I need a label at x-axis namely the first column. So
> how to say something like
> 
> 
> plot 	"data" using ($0):($3):xtic(if $2==1 : $1 else "") linetype 1

  plot "data" using 0:3:xtic( column(2)==1 ? stringcolumn(1) : "" )


> Everytime the second column has the value 1 the x-axis shall get the value
> from corresponding value in column $1.
> 
> My little example 'set xtics ("5" 0*6, "10" 1*6, "15" 2*6)' is possible
> because I view just a little range. The real datums will go until 10,000 !
> If it's possible by a for-loop just tell me. I did not find something.
> 
> 
> My 2nd question: How to get the boxes labelled? For example each box shall
> contain the number of 4th column (in or over it).

   See 5th plot in demo
   http://gnuplot.sourceforge.net/demo_4.3/datastrings.html


> 
> Regards
> Stepp
> 
> //edit
> I'm wondering:
> 
> 	"" using ($0):($2==1 ? 10 : 0):xtic($2==1 ? "1" : "")
> 
> This works but I don't need the string "1" but column 1 or $1.
> But
> 	"" using ($0):($2==1 ? 10 : 0):xtic($2==1 ? 1 : "")
> or
> 	"" using ($0):($2==1 ? 10 : 0):xtic($2==1 ? $1 : "")
> => 
> Tic label does not evaluate as string!
> 
> And most strange
> 
> 	"" using ($0):($2==1 ? 10 : 0):xtic(2==1 ? 1 : 2)
> 
> compares whether col 2 equal col 1, if yes so label with col 1 else label
> with col 2.
> Without any '$'s it only deals with columns. 
> -- 
> View this message in context: http://www.nabble.com/Each-x-th-element-an-x-label-and-boxes-with-labels-tp21697428p21697428.html
> Sent from the Gnuplot - Dev mailing list archive at Nabble.com.
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



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

Each x-th element an x-label and boxes with labels

[SteppXXL <mm4...@sp...>]

Hello there

I got following


set data style boxes

set boxwidth 0.9
set style fill solid 1.0

set xrange [-1:]
set yrange [0:]

set xtics ("5" 0*6, "10" 1*6, "15" 2*6)

plot 	"data" using ($0):($3) linetype 1, \
	"" using ($0):($5>=0 ? $3 : 0) linetype 2

pause -1 "Hit return to continue"


with data

5	1	32	914	2 classe(s), 1 transition(s)
5	2	16	922	2 classe(s), 1 transition(s)
5	3	8	1544	137 classe(s), 39 transition(s)
5	4	8	888	1 classe(s), 0 transition(s)
5	5	16	903	1 classe(s), 0 transition(s)
5	6	16	1139	
10	1	32	1011	2 classe(s), 1 transition(s)
10	2	16	1003	1 classe(s), 0 transition(s)
10	3	32	1080	4 classe(s), 4 transition(s)
10	4	64	1047	4 classe(s), 3 transition(s)
10	5	128	1022	
10	6	128	1011	1 classe(s), 0 transition(s)
15	1	256	1182	3 classe(s), 3 transition(s)
15	2	128	1393	10 classe(s), 19 transition(s)
15	3	256	1131	
15	4	128	1336	8 classe(s), 16 transition(s)
15	5	64	1084	2 classe(s), 1 transition(s)
15	6	32	1144	3 classe(s), 2 transition(s)


Now I urgently need to label the x-axis as written above but dynamical:
At each 6-th element I need a label at x-axis namely the first column. So
how to say something like


plot 	"data" using ($0):($3):xtic(if $2==1 : $1 else "") linetype 1

Everytime the second column has the value 1 the x-axis shall get the value
from corresponding value in column $1.

My little example 'set xtics ("5" 0*6, "10" 1*6, "15" 2*6)' is possible
because I view just a little range. The real datums will go until 10,000 !
If it's possible by a for-loop just tell me. I did not find something.


My 2nd question: How to get the boxes labelled? For example each box shall
contain the number of 4th column (in or over it).

Regards
Stepp

//edit
I'm wondering:

	"" using ($0):($2==1 ? 10 : 0):xtic($2==1 ? "1" : "")

This works but I don't need the string "1" but column 1 or $1.
But
	"" using ($0):($2==1 ? 10 : 0):xtic($2==1 ? 1 : "")
or
	"" using ($0):($2==1 ? 10 : 0):xtic($2==1 ? $1 : "")
=> 
Tic label does not evaluate as string!

And most strange

	"" using ($0):($2==1 ? 10 : 0):xtic(2==1 ? 1 : 2)

compares whether col 2 equal col 1, if yes so label with col 1 else label
with col 2.
Without any '$'s it only deals with columns. 
-- 
View this message in context: http://www.nabble.com/Each-x-th-element-an-x-label-and-boxes-with-labels-tp21697428p21697428.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: string function: definition of a function

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

On Monday 26 January 2009, James R. Van Zandt wrote:
> 
> I propose the patch below, which adds a function that returns the
> string that defines a specified user defined function.
> 
> I would like to be able to put the definition of a function into a
> label, like this:
> 
>   gnuplot> fun(x)=1-x**2/2
>   gnuplot> set label definition('fun') at graph .05,.95
>   gnuplot> plot [-1:1] fun(x),cos(x)

I agree that the functionality would be nice.
A couple of thoughts:

It is already possible to do essentially the same thing by reversing 
the order of operations and using the recently added evaluate() function:

    gnuplot> def = "f(x) = 1-x**2/2"
    gnuplot> evaluate(def)
    gnuplot> plot [-1:1] cos(x), f(x) title def

Another possibility is to make the function definitions visible as
string variables directly, exactly as the existing variables are.

    gnuplot> g(x,y) = x**2 + y**3
    gnuplot> show variable GPFUN
        Variables beginning with GPFUN:
        GPFUN_g = "g(x,y) = x**2 + y**3"
    gnuplot> set label GPFUN_g at graph .05, .95

The three approaches are each a little different, although I think you
end up with equal functionality in each case.  Maybe it wouldn't hurt
to have all three available?

 
> This becomes useful if the function definition is long, and/or you
> want to plot it for several values of a second variable.  Without this
> function, one can of course use "show functions" and cut and paste the
> text into a separate "set label" command.  However, that has to be
> repeated each time you change the function definition - i.e. a manual
> action to keep the function definition and the label aligned.
> 
> More basically, if you have many functions, this lets you see the
> definition of one without having it scrolled off the screen by a lot
> of others:
> 
>   gnuplot> print definition('fun')
>   fun(x)=1-x**2/2

That seems like a separate question, and could be fixed by allowing you
to request a specific subset of the user-defined functions as we already
do for user-defined variables.
    gnuplot> f(x) = 4
    gnuplot> show fun g
        Variables beginning with GPFUN:
        g(x,y) = x**2 + y**3
        goo(n) = n**n

> The name is the simplest one I came up with.  Maybe "definitionof"
> would be more descriptive.
> 
> I included basic documentation in the patch.  If it's accepted, I
> would add some cross-references.
> 
>        - Jim Van Zandt
> 
> 
> Index: src/internal.h
> ===================================================================
> RCS file: /cvsroot/gnuplot/gnuplot/src/internal.h,v
> retrieving revision 1.19
> diff -u -r1.19 internal.h
> --- src/internal.h	28 Aug 2007 06:13:07 -0000	1.19
> +++ src/internal.h	26 Jan 2009 03:00:33 -0000
> @@ -89,5 +89,6 @@
>  void f_strftime __PROTO((union argument *x));
>  void f_strptime __PROTO((union argument *x));
>  void f_assign __PROTO((union argument *x));
> +void f_definition __PROTO((union argument *x));
>  
>  #endif /* GNUPLOT_INTERNAL_H */
> Index: src/internal.c
> ===================================================================
> RCS file: /cvsroot/gnuplot/gnuplot/src/internal.c,v
> retrieving revision 1.51
> diff -u -r1.51 internal.c
> --- src/internal.c	25 Sep 2008 18:33:50 -0000	1.51
> +++ src/internal.c	26 Jan 2009 03:00:33 -0000
> @@ -1521,3 +1521,33 @@
>      }
>  }
>  
> +/* Return the string defining the specified user function
> + * JRV Jan 2008
> + */
> +void
> +f_definition(union argument *arg)
> +{
> +    struct value a, result;
> +    struct udft_entry *udf = first_udf;
> +
> +    pop(&a);  /* pop the argument */
> +
> +    /* Make sure we got a string */
> +    if (a.type != STRING)
> +	int_error(NO_CARET,"definition requires a string parameter");
> +
> +    while (udf) {
> +      /* find a function with that name */
> +      if (udf->definition && !strcmp(a.v.string_val, udf->udf_name)) {
> +	/* push its definition string onto the stack */
> +	push(Gstring(&result, udf->definition));
> +	goto done;
> +      }
> +      udf = udf->next_udf;
> +    }
> +    int_error(NO_CARET,"undefined user function: %s",a.v.string_val);
> + done:
> +    gpfree_string(&a);
> +}
> +
> +
> Index: src/eval.c
> ===================================================================
> RCS file: /cvsroot/gnuplot/gnuplot/src/eval.c,v
> retrieving revision 1.71
> diff -u -r1.71 eval.c
> --- src/eval.c	2 Sep 2008 21:17:01 -0000	1.71
> +++ src/eval.c	26 Jan 2009 03:00:34 -0000
> @@ -191,6 +191,7 @@
>  
>      {"stringcolumn",  f_stringcolumn},	/* for using specs */
>      {"strcol",  f_stringcolumn},	/* shorthand form */
> +    {"definition", f_definition},	/* for string variables only */
>      {"sprintf",  f_sprintf},	/* for string variables only */
>      {"gprintf",  f_gprintf},	/* for string variables only */
>      {"strlen",  f_strlen},	/* for string variables only */
> Index: docs/gnuplot.doc
> ===================================================================
> RCS file: /cvsroot/gnuplot/gnuplot/docs/gnuplot.doc,v
> retrieving revision 1.553
> diff -u -r1.553 gnuplot.doc
> --- docs/gnuplot.doc	4 Jan 2009 05:47:14 -0000	1.553
> +++ docs/gnuplot.doc	26 Jan 2009 03:00:39 -0000
> @@ -1082,6 +1082,16 @@
>  %c c l .
>  %Function@Arguments@Returns
>  %_
> +4 definition
> +?expressions functions definition
> +?functions definition
> +?definition
> +=definition
> +#definition("name") & string & string defining the user function named "name" \\
> +%definition("name")@string@string defining the user function named "name"
> + `definition("name")` returns the string defining the user function named
> + "name". For example, `foo(x)=x+3; definition("foo")` returns the
> + string "foo(x)=x+3".
>  4 gprintf
>  ?expressions functions gprintf
>  ?functions gprintf
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



-- 
Ethan A Merritt

string function: definition of a function

[James R. V. Z. <jr...@co...>]

I propose the patch below, which adds a function that returns the
string that defines a specified user defined function.

I would like to be able to put the definition of a function into a
label, like this:

  gnuplot> fun(x)=1-x**2/2
  gnuplot> set label definition('fun') at graph .05,.95
  gnuplot> plot [-1:1] fun(x),cos(x)
  
This becomes useful if the function definition is long, and/or you
want to plot it for several values of a second variable.  Without this
function, one can of course use "show functions" and cut and paste the
text into a separate "set label" command.  However, that has to be
repeated each time you change the function definition - i.e. a manual
action to keep the function definition and the label aligned.

More basically, if you have many functions, this lets you see the
definition of one without having it scrolled off the screen by a lot
of others:

  gnuplot> print definition('fun')
  fun(x)=1-x**2/2
  
The name is the simplest one I came up with.  Maybe "definitionof"
would be more descriptive.

I included basic documentation in the patch.  If it's accepted, I
would add some cross-references.

       - Jim Van Zandt


Index: src/internal.h
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/src/internal.h,v
retrieving revision 1.19
diff -u -r1.19 internal.h
--- src/internal.h	28 Aug 2007 06:13:07 -0000	1.19
+++ src/internal.h	26 Jan 2009 03:00:33 -0000
@@ -89,5 +89,6 @@
 void f_strftime __PROTO((union argument *x));
 void f_strptime __PROTO((union argument *x));
 void f_assign __PROTO((union argument *x));
+void f_definition __PROTO((union argument *x));
 
 #endif /* GNUPLOT_INTERNAL_H */
Index: src/internal.c
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/src/internal.c,v
retrieving revision 1.51
diff -u -r1.51 internal.c
--- src/internal.c	25 Sep 2008 18:33:50 -0000	1.51
+++ src/internal.c	26 Jan 2009 03:00:33 -0000
@@ -1521,3 +1521,33 @@
     }
 }
 
+/* Return the string defining the specified user function
+ * JRV Jan 2008
+ */
+void
+f_definition(union argument *arg)
+{
+    struct value a, result;
+    struct udft_entry *udf = first_udf;
+
+    pop(&a);  /* pop the argument */
+
+    /* Make sure we got a string */
+    if (a.type != STRING)
+	int_error(NO_CARET,"definition requires a string parameter");
+
+    while (udf) {
+      /* find a function with that name */
+      if (udf->definition && !strcmp(a.v.string_val, udf->udf_name)) {
+	/* push its definition string onto the stack */
+	push(Gstring(&result, udf->definition));
+	goto done;
+      }
+      udf = udf->next_udf;
+    }
+    int_error(NO_CARET,"undefined user function: %s",a.v.string_val);
+ done:
+    gpfree_string(&a);
+}
+
+
Index: src/eval.c
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/src/eval.c,v
retrieving revision 1.71
diff -u -r1.71 eval.c
--- src/eval.c	2 Sep 2008 21:17:01 -0000	1.71
+++ src/eval.c	26 Jan 2009 03:00:34 -0000
@@ -191,6 +191,7 @@
 
     {"stringcolumn",  f_stringcolumn},	/* for using specs */
     {"strcol",  f_stringcolumn},	/* shorthand form */
+    {"definition", f_definition},	/* for string variables only */
     {"sprintf",  f_sprintf},	/* for string variables only */
     {"gprintf",  f_gprintf},	/* for string variables only */
     {"strlen",  f_strlen},	/* for string variables only */
Index: docs/gnuplot.doc
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/docs/gnuplot.doc,v
retrieving revision 1.553
diff -u -r1.553 gnuplot.doc
--- docs/gnuplot.doc	4 Jan 2009 05:47:14 -0000	1.553
+++ docs/gnuplot.doc	26 Jan 2009 03:00:39 -0000
@@ -1082,6 +1082,16 @@
 %c c l .
 %Function@Arguments@Returns
 %_
+4 definition
+?expressions functions definition
+?functions definition
+?definition
+=definition
+#definition("name") & string & string defining the user function named "name" \\
+%definition("name")@string@string defining the user function named "name"
+ `definition("name")` returns the string defining the user function named
+ "name". For example, `foo(x)=x+3; definition("foo")` returns the
+ string "foo(x)=x+3".
 4 gprintf
 ?expressions functions gprintf
 ?functions gprintf

Re: strange colormap behaviour with postscript printing

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

I have patch gnuplot 4.2 and cvs so that it keeps the custom colour map 
intact when printing to "postscript monochrome".

Now I propose that Octave is passing the colormap() through a "rgb2gray()" 
function before printing to any monochromatic device (probably only "-dps" 
and "-deps") so that the image will look the same whatever the drawing 
backend is selected.


> >I think that Octave could pass the custom colormap() through a "rgb2gray()"
> >function before printing to any monochromatic device (not just monochromatic
> >postscript). Then the plots
> > print('mono.ps', '-dps')
> > print('color.ps', '-dpsc')
> >will be same as in Matlab.
> 
> Unfortunately, 'mono.ps' and 'color.ps' inverted images (using the example
> below which accompanyied your patch).
> 
> 	a=1./hilb(42);
> 	colormap(flipud(gray));
> 	imagesc(a); colorbar
> 	print('mono.ps', '-dps');
> 	print('color.ps', '-dpsc');

---
PM

Re: pango 1.22

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

> > I cannot compile wxt terminal on OpenSUSE 11.1:
> >
> > $ ./configure
> > ...
> > checking for PANGO_1_10_2... no
> 
> Pango 1.10.2 is a buggy release which caused a bug report some time ago.

Thanks for explanation. 
Now it compiles and works fine. 

---
PM

Re: pango 1.22

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

Petr Mikulik wrote:
> I cannot compile wxt terminal on OpenSUSE 11.1:
>
> $ ./configure
> ...
> checking for PANGO_1_10_2... no
>
> However, I have pango installed:
> $ rpm -qa | grep -i pango
> libpangomm-1_4-1-2.14.0-2.20
> SDL_Pango-0.1.2-164.101
> pangomm-devel-2.14.0-2.20
> pango-devel-1.22.1-2.9
> pango-1.22.1-2.9
> SDL_Pango-devel-0.1.2-164.101
>
> It seems ./configure wants exactly pango 1.10.2 and thus it does 
> not like pango 1.22; the config.log contains:
>
>   
Hi Petr,

Pango 1.10.2 is a buggy release which caused a bug report some time ago. 
That's why ./configure checks for the version of pango and fails if it 
is that particular one. So:

checking for PANGO_1_10_2... no

is really what you need at that point. Maybe I could change PANGO_1_10_2 
to BUGGY_PANGO_1_10_2. Does it sound ok ?

If you cannot compile wxt, it's probably because of something else.

Best regards,

Timothée


P.S. : the code in configure.in is the following :
  dnl Check for buggy Pango 1.10.2
  PKG_CHECK_MODULES(PANGO_1_10_2, [pango = 1.10.2],
    [AC_MSG_WARN(dnl
[Pango 1.10.2 has been found. This version has a bug which gives unexpected
results in the wxWidgets terminal. If you want to use this terminal, please
install a different version of Pango.])
    enable_wxwidgets_ok=no],
    [HAVE_PANGO_1_10_2=0])

pango 1.22

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

I cannot compile wxt terminal on OpenSUSE 11.1:

$ ./configure
...
checking for PANGO_1_10_2... no

However, I have pango installed:
$ rpm -qa | grep -i pango
libpangomm-1_4-1-2.14.0-2.20
SDL_Pango-0.1.2-164.101
pangomm-devel-2.14.0-2.20
pango-devel-1.22.1-2.9
pango-1.22.1-2.9
SDL_Pango-devel-0.1.2-164.101

It seems ./configure wants exactly pango 1.10.2 and thus it does 
not like pango 1.22; the config.log contains:

configure:14922: checking for CAIROPANGO
configure:14930: $PKG_CONFIG --exists --print-errors "cairo >= 0.9.0 pango 
>= 1.10 pangocairo >= 1.10"
configure:14933: $? = 0
configure:14948: $PKG_CONFIG --exists --print-errors "cairo >= 0.9.0 pango 
>= 1.10 pangocairo >= 1.10"
configure:14951: $? = 0
configure:15027: result: yes
configure:15039: checking for PANGO_1_10_2
configure:15047: $PKG_CONFIG --exists --print-errors "pango = 1.10.2"
Requested 'pango = 1.10.2' but version of Pango is 1.22.1
configure:15050: $? = 1
configure:15065: $PKG_CONFIG --exists --print-errors "pango = 1.10.2"
Requested 'pango = 1.10.2' but version of Pango is 1.22.1
configure:15068: $? = 1
Requested 'pango = 1.10.2' but version of Pango is 1.22.1
configure:15096: result: no


---
PM

Re: strange colormap behaviour with postscript printing

[Ben A. <bpa...@ma...>]

On Jan 18, 2009, at 5:58 AM, Petr Mikulik wrote:

>> So IMHO this really can be considered a gnuplot bug.
>
> It was designed this way when I have implemented pm3d; there were  
> only gray
> and rgbformulae palettes. The interpolated palette colours were  
> added later.
> So let us tell postscript to respect interpolated colour palette
> preferentially to the colour/gray setting. Then the fix is a one- 
> liner.
>
> In postscript file, change
> 	Color true and
> to
> 	Color InterpolatedColor or
>
> The patch for gnuplot source code is on sourceforge.
>
>> Another possibility that occurs to me is to convert the custom  
>> color map
>> to a monochrome version and have gnuplot respect that?
>
> With the above patch, any custom palette will keep the defined  
> colours and
> gnuplot will respect it.
>
>
> I think that Octave could pass the custom colormap() through a  
> "rgb2gray()"
> function before printing to any monochromatic device (not just  
> monochromatic
> postscript). Then the plots
> 	print('mono.ps', '-dps')
> 	print('color.ps', '-dpsc')
> will be same as in Matlab.
>
> ---
> PM

Petr,

I tried your patch

	http://sourceforge.net/tracker2/?func=detail&aid=2516634&group_id=2055&atid=102055

Unfortunately, 'mono.ps' and 'color.ps' inverted images (using the  
example below which accompanyied your patch).

	a=1./hilb(42);
	colormap(flipud(gray));
	imagesc(a); colorbar
	print('mono.ps', '-dps');
	print('color.ps', '-dpsc');

So it appears to me that the problem persists.

Ben

Re: strange colormap behaviour with postscript printing

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

> So IMHO this really can be considered a gnuplot bug.

It was designed this way when I have implemented pm3d; there were only gray 
and rgbformulae palettes. The interpolated palette colours were added later. 
So let us tell postscript to respect interpolated colour palette 
preferentially to the colour/gray setting. Then the fix is a one-liner.

In postscript file, change
	Color true and
to
	Color InterpolatedColor or

The patch for gnuplot source code is on sourceforge.

> Another possibility that occurs to me is to convert the custom color map 
> to a monochrome version and have gnuplot respect that?

With the above patch, any custom palette will keep the defined colours and 
gnuplot will respect it.


I think that Octave could pass the custom colormap() through a "rgb2gray()"
function before printing to any monochromatic device (not just monochromatic 
postscript). Then the plots
	print('mono.ps', '-dps')
	print('color.ps', '-dpsc')
will be same as in Matlab.

---
PM

Re: cvs : prepare fails on ARM

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

On Saturday 17 January 2009, pl...@pi... wrote:
> Ethan A Merritt wrote:
> > On Saturday 17 January 2009, pl...@pi... wrote:
> >> Hi,
> >>
> >> I had an problem running ./prepare on ARM platform. To be sure I was
> >> clean I did a fresh cvs pull but the result was the same:
> >>
> >> echo PLT_FILES = *.plt | fmt | (tr '\012' @; echo ) \
> >>   |sed 's/@$/%/;s/@/ \\@/g;' | tr @% '\012 ' >> Makefile.amt
> >> sed -n '/^##plt-files-end/,$p' Makefile.am.in >> Makefile.amt
> >> chmod a-w Makefile.amt
> >> mv Makefile.amt Makefile.am
> >> src/Makefile.am:52: pkglibexec_PROGRAMS defined both conditionally and
> >> unconditionally
> >> src/Makefile.am:35: gnuplot_SOURCES defined both conditionally and
> >> unconditionally
> >>
> >> Some part of the preparation process failed.
> >> Please refer to INSTALL for details. 
> >>
> >> Any idea what is causing this?
> > 
> > Only that it is some problem with the autotools.
> > What versions of autoconf and automake do you have?
> > 
> > By the way, you can run ./prepare on another machine and use the
> > resulting configure script anywhere.
> > 
> > 
> 
> Thanks, I think it's 2.19 or something, pretty old Debian 3.1

The prepare script is documented as requiring autoconf 2.52 or newer.
It is supposed to check this, and issue an error message if the test fails.

> running prepare on the PC fixed that one. I copied all across hacked
> term.h down to dumb and svg, removed doc from SUBDIRS and ran:
> 
> ./configure --without-x --without-tutorial --without-pdf --without-cairo
> 
> That ran cleanly and seems to give the expected terminals and options.
> However, make bombed out straight away.
> 
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `/tmpd/gnuplot/src/wxterminal'
> make[3]: Entering directory `/tmpd/gnuplot/src'
> gcc -DHAVE_CONFIG_H -I. -I..  -I../term -I../term
> -DBINDIR=\"/usr/local/bin\"
> -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.3\"
> -DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.3/PostScript\"
> -DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/4.3/js\"
> -DCONTACT=\"gnu...@li...\"
> -DHELPFILE=\"/usr/local/share/gnuplot/4.3/gnuplot.gih\"
> -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"   -march=armv4t  -O2
> -fomit-frame-pointer -pipe -MT alloc.o -MD -MP -MF .deps/alloc.Tpo -c -o
> alloc.o alloc.c
> In file included from alloc.h:44,
>                  from alloc.c:44:
> stdfn.h:47:19: ctype.h: No such file or directory
> stdfn.h:48:19: stdio.h: No such file or directory
> stdfn.h:55:22: strings.h: No such file or directory

These are bog-standard C library headers.  You'll have to sort that
one out yourself, since it doesn't really have anything to do with
gnuplot.  At a guess, you need a development version of the compiler
package rather than a run-time only version.

I'd start by trying to determine if these header files really do live
somewhere on your machine, perhaps in a non-standard directory.
If so, you may be able to fix things just by adding the appropriate
"-I /some/whacky/directory"  to CPPFLAGS before running "make".

	Ethan


> In file included from
> /usr/lib/gcc-lib/arm-linux/3.3.5/include/syslimits.h:7,
>                  from /usr/lib/gcc-lib/arm-linux/3.3.5/include/limits.h:11,
>                  from stdfn.h:248,
>                  from alloc.h:44,
>                  from alloc.c:44:
> 
> 
> I seem to recall having a run around with limits.h before,can you see
> where I'm going wrong?
> 
> Strange thing is , I've built 4.3 on this board before, don't know why
> I'm having these issues.
> 
> Thanks for any help.
> Peter.
> 



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

Re: cvs : prepare fails on ARM

[<pl...@pi...>]

Ethan A Merritt wrote:
> On Saturday 17 January 2009, pl...@pi... wrote:
>> Hi,
>>
>> I had an problem running ./prepare on ARM platform. To be sure I was
>> clean I did a fresh cvs pull but the result was the same:
>>
>> echo PLT_FILES = *.plt | fmt | (tr '\012' @; echo ) \
>>   |sed 's/@$/%/;s/@/ \\@/g;' | tr @% '\012 ' >> Makefile.amt
>> sed -n '/^##plt-files-end/,$p' Makefile.am.in >> Makefile.amt
>> chmod a-w Makefile.amt
>> mv Makefile.amt Makefile.am
>> src/Makefile.am:52: pkglibexec_PROGRAMS defined both conditionally and
>> unconditionally
>> src/Makefile.am:35: gnuplot_SOURCES defined both conditionally and
>> unconditionally
>>
>> Some part of the preparation process failed.
>> Please refer to INSTALL for details. 
>>
>> Any idea what is causing this?
> 
> Only that it is some problem with the autotools.
> What versions of autoconf and automake do you have?
> 
> By the way, you can run ./prepare on another machine and use the
> resulting configure script anywhere.
> 
> 

Thanks, I think it's 2.19 or something, pretty old Debian 3.1

running prepare on the PC fixed that one. I copied all across hacked
term.h down to dumb and svg, removed doc from SUBDIRS and ran:

./configure --without-x --without-tutorial --without-pdf --without-cairo

That ran cleanly and seems to give the expected terminals and options.
However, make bombed out straight away.

make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/tmpd/gnuplot/src/wxterminal'
make[3]: Entering directory `/tmpd/gnuplot/src'
gcc -DHAVE_CONFIG_H -I. -I..  -I../term -I../term
-DBINDIR=\"/usr/local/bin\"
-DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.3\"
-DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.3/PostScript\"
-DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/4.3/js\"
-DCONTACT=\"gnu...@li...\"
-DHELPFILE=\"/usr/local/share/gnuplot/4.3/gnuplot.gih\"
-DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"   -march=armv4t  -O2
-fomit-frame-pointer -pipe -MT alloc.o -MD -MP -MF .deps/alloc.Tpo -c -o
alloc.o alloc.c
In file included from alloc.h:44,
                 from alloc.c:44:
stdfn.h:47:19: ctype.h: No such file or directory
stdfn.h:48:19: stdio.h: No such file or directory
stdfn.h:55:22: strings.h: No such file or directory
In file included from
/usr/lib/gcc-lib/arm-linux/3.3.5/include/syslimits.h:7,
                 from /usr/lib/gcc-lib/arm-linux/3.3.5/include/limits.h:11,
                 from stdfn.h:248,
                 from alloc.h:44,
                 from alloc.c:44:


I seem to recall having a run around with limits.h before,can you see
where I'm going wrong?

Strange thing is , I've built 4.3 on this board before, don't know why
I'm having these issues.

Thanks for any help.
Peter.

Re: strange colormap behaviour with postscript printing

[Ben A. <bpa...@ma...>]

On Jan 17, 2009, at 6:51 PM, Ethan A Merritt wrote:

> On Saturday 17 January 2009, Ben Abbott wrote:
>>>
>>>
>>> The reason is that you are using a custom color map (COLOR map)
>>> which you
>>> try to print to a monochrome postscript printer. Therefore gnuplot
>>> ignores
>>> your specific color map and uses the default gray mapping instead
>>> ('set palette gray positive|negative gamma _gamma_').
>
> I think that gnuplot/postscript should honor a custom colormap
> even if it is in monochrome mode, for the same reason that it
> honors RGB colors even though it is in monochrome mode.
> "set term post mono"  should set a default behaviour, but not
> limit what the user can do via explicit commands.
>
> So IMHO this really can be considered a gnuplot bug.

For the case of a monochrome custom colormap, I share Ethan's opinion.

For the case of a RGB colormap, it might be a missing feature, but as  
converted from RGB to gray is a simple procedure I see no reason not  
support all custom colormaps when using the monochrome postscript  
terminal.

In any event, I have submitted a bug report.

	https://sourceforge.net/tracker2/?func=detail&aid=2516634&group_id=2055&atid=102055

Ben

Re: strange colormap behaviour with postscript printing

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

On Saturday 17 January 2009, Ben Abbott wrote:
> >
> >
> > The reason is that you are using a custom color map (COLOR map)  
> > which you
> > try to print to a monochrome postscript printer. Therefore gnuplot  
> > ignores
> > your specific color map and uses the default gray mapping instead
> > ('set palette gray positive|negative gamma _gamma_').


I think that gnuplot/postscript should honor a custom colormap
even if it is in monochrome mode, for the same reason that it 
honors RGB colors even though it is in monochrome mode.
"set term post mono"  should set a default behaviour, but not
limit what the user can do via explicit commands.

So IMHO this really can be considered a gnuplot bug.

-- 
Ethan A Merritt

Re: strange colormap behaviour with postscript printing

[Ben A. <bpa...@ma...>]

On Jan 17, 2009, at 3:04 PM, Petr Mikulik wrote:

>> | octave> imagesc(peaks());colormap(gray())
>> | octave> print("gray.png")          # png image is good
>> | octave> colormap(flipud(gray))
>> | octave> print("udgray.png")        # png image is good
>> | octave> colormap(gray)
>> | octave> print("gray.ps")           # ps image is good
>> | octave> print("udgray.ps"))        # ps image is same as above!
>> |
>> | Apparently, when printing to postscript, flipping the colormap  
>> has no effect!
>>
>> Is this a bug in gnuplot, or are we somehow using it incorrectly?
>
> Try
> 	colormap(rainbow)
> instead of
> 	colormap(flipud(gray))
> and you will see exactly the same result.
> Try
> 	print('xxxx.ps', '-dpsc')
> and you will see image with your desired color mapping.
>
>
> The reason is that you are using a custom color map (COLOR map)  
> which you
> try to print to a monochrome postscript printer. Therefore gnuplot  
> ignores
> your specific color map and uses the default gray mapping instead
> ('set palette gray positive|negative gamma _gamma_').
>
> You should print to color postscript to use a custom (Octave's)  
> colormap.
>
> In gnuplot, there is indeed an inconsistency of plots
> 	test
> 	splot x*y with pm3d
> run under these situations:
> 	gnuplot		# X11 color display
> 	gnuplot -gray	# X11 gray display
> 	gnuplot -mono	# X11 monochromatic display
> and the same with postscript output
> 	set term postscript color
> 	set term postscript mono
> Note that
> 	set term png
> gives always a color output so that you cannot see any difference.
>
> If gnuplot sends a custom color map to a monochrome postscript  
> device, then
> this would be considered as bug as well.
>
> Any idea how to solve this ambiguity on gnuplot side?
> I don't think this is very needed.
>
>
> Octave could write an error message under this situation:
>
> if any(any(colormap()-gray(rows(colormap())))) && is_mono_output
>    fprintf('WARNING: using default gray mapping for printing on  
> monochrome printer\n');
> end

As there is no routinesfor for the gnuplot backend that is  
simultaneously aware of the terminal type and whether or  not any of  
the figure's graphics objects are using a custom color map, I don't  
see any easy way to do that.

It may be necessary to make some compromise. We might (1) issue a  
warning even when the custom color map is not being used by any  
graphics objections, (2) force the use of -dpsc when a custom color  
map is set, or (3) leave the backend as it is.

Of those (1) looks more attractive to me.

Another possibility that occurs to me is to convert the custom color  
map to a monochrome version and have gnuplot respect that?

Petr, is that a possibility?

Ben

Re: cvs : prepare fails on ARM

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

On Saturday 17 January 2009, pl...@pi... wrote:
> Hi,
> 
> I had an problem running ./prepare on ARM platform. To be sure I was
> clean I did a fresh cvs pull but the result was the same:
> 
> echo PLT_FILES = *.plt | fmt | (tr '\012' @; echo ) \
>   |sed 's/@$/%/;s/@/ \\@/g;' | tr @% '\012 ' >> Makefile.amt
> sed -n '/^##plt-files-end/,$p' Makefile.am.in >> Makefile.amt
> chmod a-w Makefile.amt
> mv Makefile.amt Makefile.am
> src/Makefile.am:52: pkglibexec_PROGRAMS defined both conditionally and
> unconditionally
> src/Makefile.am:35: gnuplot_SOURCES defined both conditionally and
> unconditionally
> 
> Some part of the preparation process failed.
> Please refer to INSTALL for details. 
> 
> Any idea what is causing this?

Only that it is some problem with the autotools.
What versions of autoconf and automake do you have?

By the way, you can run ./prepare on another machine and use the
resulting configure script anywhere.


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

cvs : prepare fails on ARM

[<pl...@pi...>]

Hi,

I had an problem running ./prepare on ARM platform. To be sure I was
clean I did a fresh cvs pull but the result was the same:

echo PLT_FILES = *.plt | fmt | (tr '\012' @; echo ) \
  |sed 's/@$/%/;s/@/ \\@/g;' | tr @% '\012 ' >> Makefile.amt
sed -n '/^##plt-files-end/,$p' Makefile.am.in >> Makefile.amt
chmod a-w Makefile.amt
mv Makefile.amt Makefile.am
src/Makefile.am:52: pkglibexec_PROGRAMS defined both conditionally and
unconditionally
src/Makefile.am:35: gnuplot_SOURCES defined both conditionally and
unconditionally

Some part of the preparation process failed.
Please refer to INSTALL for details.




Any idea what is causing this?

TIA, Peter.

Re: strange colormap behaviour with postscript printing

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

> | octave> imagesc(peaks());colormap(gray())
> | octave> print("gray.png")          # png image is good
> | octave> colormap(flipud(gray))
> | octave> print("udgray.png")        # png image is good
> | octave> colormap(gray)
> | octave> print("gray.ps")           # ps image is good
> | octave> print("udgray.ps"))        # ps image is same as above!
> |
> | Apparently, when printing to postscript, flipping the colormap has no effect!
>
> Is this a bug in gnuplot, or are we somehow using it incorrectly?

Try
	colormap(rainbow)
instead of
	colormap(flipud(gray))
and you will see exactly the same result.
Try
	print('xxxx.ps', '-dpsc')
and you will see image with your desired color mapping.


The reason is that you are using a custom color map (COLOR map) which you 
try to print to a monochrome postscript printer. Therefore gnuplot ignores 
your specific color map and uses the default gray mapping instead 
('set palette gray positive|negative gamma _gamma_').

You should print to color postscript to use a custom (Octave's) colormap.

In gnuplot, there is indeed an inconsistency of plots
	test
	splot x*y with pm3d
run under these situations:
	gnuplot		# X11 color display
	gnuplot -gray	# X11 gray display
	gnuplot -mono	# X11 monochromatic display
and the same with postscript output
	set term postscript color
	set term postscript mono
Note that
	set term png
gives always a color output so that you cannot see any difference.

If gnuplot sends a custom color map to a monochrome postscript device, then 
this would be considered as bug as well.

Any idea how to solve this ambiguity on gnuplot side?
I don't think this is very needed.


Octave could write an error message under this situation:

if any(any(colormap()-gray(rows(colormap())))) && is_mono_output
    fprintf('WARNING: using default gray mapping for printing on monochrome printer\n');
end


---
PM

wxt on MacOS X - updated patch

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

I have posted an updated patch on SF to modify wxt for MacOSX. I would 
be very pleased and more motivated if somebody running MacOSX could try 
it on top of the current CVS and report back if it works or not.

For those interested, the patch page is :
https://sourceforge.net/tracker2/index.php?func=detail&aid=1950392&group_id=2055&atid=302055

and once you have built the patched source and installed the binaries, 
you will be able to test the terminal which is temporarly called "wxtp" 
(so use "set term wxtp" as your first command).

Thanks to the testers.

Best regards,

Timothée

-- 
Doctorant
Laboratoire Pierre Aigrain,
École Normale Supérieure
24, rue Lhomond
75005 Paris
01 44 32 25 56

Re: failure in building wx term on migw with the latest cvs source

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

Tatsuro MATSUOKA a écrit :
> Hello Timothee Lecomte
>
> Sorry I forgot to say thanks to you in the previous mail!!
>
> Regards
>
> Tatsuro
> --- Tatsuro MATSUOKA <tma...@ya...> wrote:
>
>   
>> Hello
>>
>> Please add following
>>
>> ****************
>> gp_cairo_helpers.$(O): wxterminal/gp_cairo_helpers.c wxterminal/gp_cairo_helpers.h
>> 	$(CC) -c $(CFLAGS) $(CXXFLAGS) $(CAIRO_CFLAGS) $(PANGO_CFLAGS) wxterminal/gp_cairo_helpers.c
>> ********
>>
>> after
>>
>> ***********
>> gp_cairo.$(O): wxterminal/gp_cairo.c wxterminal/gp_cairo.h
>> 	$(CC) -c $(CFLAGS) $(CXXFLAGS) $(CAIRO_CFLAGS) $(PANGO_CFLAGS) wxterminal/gp_cairo.c
>> *************
>>
>> in makefile.mgw
>>
>> With the above modification wgnuplot.exe and wgnuplot_pipes.exe worked.
>>
>> BTW:
>> For gnuplot.exe,  the problem seems to be remained. 
>> Please see,
>>
>>
>>     
> http://www.nabble.com/Buildng-of-gnuplot.exe-for-win32-with-wxt-fails.-(mingw)-to20745152.html#a20745152
>   
>>

I have added the lines in CVS (I just removed "$(CXXFLAGS) 
$(CAIRO_CFLAGS) $(PANGO_CFLAGS)" which should not be needed for 
gp_cairo_helpers.c which is just a C file without dependency on cairo 
and pango). Too bad I am not familiar enough with makefiles, because the 
real problem is simpler: it's just that this file is in a subfolder 
instead of being in src/ directly.

As for the problem with wxt and gnuplot.exe, I am afraid I have no idea 
where the problem comes from. At first glance, I cannot see anything 
wrong in the gdb file that you provided. There is no segfault, and I 
cannot see a problem in the code either. Maybe you could try to execute 
"GNUTERM=win gnuplot.exe" to see if gnuplot starts properly with the 
default win terminal. Additionally, you could try to verify that 
wxt_waitforinput() (in wxt_gui.cpp, line 3117) calls ConsoleGetch().

Best regards,

Timothée

Re: failure in building wx term on migw with the latest cvs source

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

Hello Timothee Lecomte

Sorry I forgot to say thanks to you in the previous mail!!

Regards

Tatsuro
--- Tatsuro MATSUOKA <tma...@ya...> wrote:

> Hello
> 
> Please add following
> 
> ****************
> gp_cairo_helpers.$(O): wxterminal/gp_cairo_helpers.c wxterminal/gp_cairo_helpers.h
> 	$(CC) -c $(CFLAGS) $(CXXFLAGS) $(CAIRO_CFLAGS) $(PANGO_CFLAGS) wxterminal/gp_cairo_helpers.c
> ********
> 
> after
> 
> ***********
> gp_cairo.$(O): wxterminal/gp_cairo.c wxterminal/gp_cairo.h
> 	$(CC) -c $(CFLAGS) $(CXXFLAGS) $(CAIRO_CFLAGS) $(PANGO_CFLAGS) wxterminal/gp_cairo.c
> *************
> 
> in makefile.mgw
> 
> With the above modification wgnuplot.exe and wgnuplot_pipes.exe worked.
> 
> BTW:
> For gnuplot.exe,  the problem seems to be remained. 
> Please see,
> 
>
http://www.nabble.com/Buildng-of-gnuplot.exe-for-win32-with-wxt-fails.-(mingw)-to20745152.html#a20745152
> 
> Regards
> 
> Tatsuro
>  
> 
> --- Timoth将アe Lecomte <tim...@lp...> wrote:
> 
> > Tatsuro MATSUOKA a セュ竺crit :
> > > Hello
> > >
> > > I failed to build wxt term on mingw with the latest cvs sources (2009-01-14)
> > > I used the makefile.mgw.
> > >
> > > wxt_gui.o:wxt_gui.cpp:(.text+0x2841): undefined reference to
> > `_gp_cairo_helper_coordval_to_chars'
> > > collect2: ld returned 1 exit status
> > > make: [gnuplot.exe] Error 1 (ignored)
> > > The gd libraries used is gd-2.0.36RC1 static build (buily myself.)
> > >
> > > If ./confgiure and make process were modified, is it necesarry to modify  makefile.mgw?
> > >
> > >
> > > Regards
> > >
> > > Tatsuro
> > >
> > >   
> > Hello,
> > 
> > Thanks for the report. You are right, I had forgotten to fix 
> > makefile.mgw. I just did it in CVS. Please tell me if it's ok now.
> > 
> > Best regards,
> > 
> > Timothセュ竺e
> > 
> > 
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: failure in building wx term on migw with the latest cvs source

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

Hello

Please add following

****************
gp_cairo_helpers.$(O): wxterminal/gp_cairo_helpers.c wxterminal/gp_cairo_helpers.h
	$(CC) -c $(CFLAGS) $(CXXFLAGS) $(CAIRO_CFLAGS) $(PANGO_CFLAGS) wxterminal/gp_cairo_helpers.c
********

after

***********
gp_cairo.$(O): wxterminal/gp_cairo.c wxterminal/gp_cairo.h
	$(CC) -c $(CFLAGS) $(CXXFLAGS) $(CAIRO_CFLAGS) $(PANGO_CFLAGS) wxterminal/gp_cairo.c
*************

in makefile.mgw

With the above modification wgnuplot.exe and wgnuplot_pipes.exe worked.

BTW:
For gnuplot.exe,  the problem seems to be remained. 
Please see,

http://www.nabble.com/Buildng-of-gnuplot.exe-for-win32-with-wxt-fails.-(mingw)-to20745152.html#a20745152

Regards

Tatsuro
 

--- Timoth将アe Lecomte <tim...@lp...> wrote:

> Tatsuro MATSUOKA a セュ竺crit :
> > Hello
> >
> > I failed to build wxt term on mingw with the latest cvs sources (2009-01-14)
> > I used the makefile.mgw.
> >
> > wxt_gui.o:wxt_gui.cpp:(.text+0x2841): undefined reference to
> `_gp_cairo_helper_coordval_to_chars'
> > collect2: ld returned 1 exit status
> > make: [gnuplot.exe] Error 1 (ignored)
> > The gd libraries used is gd-2.0.36RC1 static build (buily myself.)
> >
> > If ./confgiure and make process were modified, is it necesarry to modify  makefile.mgw?
> >
> >
> > Regards
> >
> > Tatsuro
> >
> >   
> Hello,
> 
> Thanks for the report. You are right, I had forgotten to fix 
> makefile.mgw. I just did it in CVS. Please tell me if it's ok now.
> 
> Best regards,
> 
> Timothセュ竺e
> 
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: failure in building wx term on migw with the latest cvs source

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

Tatsuro MATSUOKA a écrit :
> Hello
>
> I failed to build wxt term on mingw with the latest cvs sources (2009-01-14)
> I used the makefile.mgw.
>
> wxt_gui.o:wxt_gui.cpp:(.text+0x2841): undefined reference to `_gp_cairo_helper_coordval_to_chars'
> collect2: ld returned 1 exit status
> make: [gnuplot.exe] Error 1 (ignored)
> The gd libraries used is gd-2.0.36RC1 static build (buily myself.)
>
> If ./confgiure and make process were modified, is it necesarry to modify  makefile.mgw?
>
>
> Regards
>
> Tatsuro
>
>   
Hello,

Thanks for the report. You are right, I had forgotten to fix 
makefile.mgw. I just did it in CVS. Please tell me if it's ok now.

Best regards,

Timothée

failure in building wx term on migw with the latest cvs source

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

Hello

I failed to build wxt term on mingw with the latest cvs sources (2009-01-14)
I used the makefile.mgw.

wxt_gui.o:wxt_gui.cpp:(.text+0x2841): undefined reference to `_gp_cairo_helper_coordval_to_chars'
collect2: ld returned 1 exit status
make: [gnuplot.exe] Error 1 (ignored)
The gd libraries used is gd-2.0.36RC1 static build (buily myself.)

If ./confgiure and make process were modified, is it necesarry to modify  makefile.mgw?


Regards

Tatsuro


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Success report: readline support using OSX libraries as shipped by Apple

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

On Wednesday 14 January 2009 10:40:39 Ethan Merritt wrote:
> On Wednesday 14 January 2009 09:17:45 Mojca Miklavec wrote:

> > > I have been told that the OSX "libreadline" library is actually a disguised
> > > version of the BSD libedit.  Since as of recently gnuplot can use libedit
> > > instead of libreadline, the best solution would be (if it works) would be
> > > to force the --with-readline=bsd on OSX configurations.  Unfortunately,
> > > I do not know if OSX also provides an un-wrapped libedit that doesn't
> > > pretend to be libreadline.  Could you please try
> > >  ./configure --with-readline=bsd
> > > and see how it works?
> > 
> > It doesn't.
> > 
> > Making all in wxterminal
> > make[3]: Nothing to be done for `all'.
> > if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
> > -DBINDIR=\"/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/bin\"
> > -DX11_DRIVER_DIR=\"/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/libexec/gnuplot/4.3\"
> > -DGNUPLOT_PS_DIR=\"/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/share/gnuplot/4.3/PostScript\"
> > -DCONTACT=\"gnu...@li...\"
> > -DHELPFILE=\"/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/share/gnuplot/4.3/gnuplot.gih\"
> > -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"
> > -I/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/include
> > -I/Users/mojca/moje/dev/gnuplot/git/gnuplot-static/support_libs/include
> >  -g -O2 -ObjC -MT command.o -MD -MP -MF ".deps/command.Tpo" -c -o
> > command.o command.c; \
> > then mv -f ".deps/command.Tpo" ".deps/command.Po"; else rm -f
> > ".deps/command.Tpo"; exit 1; fi
> > In file included from command.c:76:
> > gp_hist.h:73:32: error: editline/readline.h: No such file or directory
> 
> Actually, that looks like maybe it *did* work.
> It apparently found the library correctly, but then failed to find the 
> corresponding header files.  Is there an OSX developer's kit or something
> that contains the header files for system libraries?

I have now tried it myself, on an OSX 10.4 machine

I got this warning message from running ./configure --with-readline=bsd

  checking for editline/readline.h... no
  configure: WARNING: found BSD editline library but not readline.h 
             please add path to readline.h to CPPFLAGS in Makefile

If I copy that header file over from a linux machine, then the 
configure + make is successful under OSX 10.4 (Leopard), except that I
had to manually add  -lhistory  to the compile command.  That is easily
fixable in the configure script. 

The resulting executable works fine for tab-completion, line editing,
and within-session history commands.  It does not seem to remember
the commands from previous sessions (not sure whether that is fixable
or not, but I can live without it).

So I'd say this is 99% of the way towards a successful automated
configure+build on a stock OSX 10.4 (Leopard) machine, with full support for
readline via the BSD editline that ships with OSX.  The only trick is 
figuring out where OSX users are supposed to get the editline/readline.h
header file.  Is there some standard development kit we can tell them
is required?

	Ethan