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

Re: make: *** [doc2html-ja.exe] Error 1 on Japanese environments (mingw)

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

Hello Ethan

I have confirmed the fix.

Thanks

Tatsuro

--- On Wed, 2012/9/5, sfeam (Ethan Merritt)  wrote:

> On Tuesday, 04 September 2012, Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > I have tried to build the recent cvs source (2012-09-04) mingw.
> > Build of gnuplot is fine. 
> > 
> > However, in making help an error appeared.
> 
> I think the error arose from applying the patch file term-ja.diff to
> the revised emf.trm file.   Please try the new term-ja.diff in 4.7 CVS
> (uploaded just a few minutes ago).
> 
>     Ethan
> 
> 
> > 
> > gcc -shared-libgcc -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc-v2 -L/c/Programs/gplibs/lib -s -o doc2html-ja.exe -DWINDOWS_NO_GUI -DJAPANESE_DOC -I/c/Programs/gplibs/include -fno-keep-inline-dllexport -O3 -I. -I../../src -D_Windows -DHAVE_CONFIG_H  -DGNUPLOT_SHARE_DIR=\"share\" -DDEVELOPMENT_VERSION -DUSE_MOUSE=1 -DWIN_IPC -I/c/PROGRA~2/HELPWO~1/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_LUA -DHAVE_ICONV -I. -Ija/docs/ -Ija//term ../../docs/windows/doc2htm
> > l.c ../../docs/termdoc.c ../../docs/xref.c version.o
> > In file included from ../../src/term.h:265:0,
> >                  from ja/docs/doc2x.h:72,
> >                  from ../../docs/windows/doc2html.c:65:
> > ja//term/emf.trm:1830:0: error: unterminated #ifdef
> > make: *** [doc2html-ja.exe] Error 1
> > 
> > ja//term/emf.trm:1830:0
> > 
> > #ifdef TERM_HELP
> > START_HELP(emf)
> > #ifndef JAPANESE_DOC
> >  :
> >  :
> > #endif /* TERM_HELP */
> > 
> > ***********
> > #ifndef JAPANESE_DOC seem not terminated
> > 
> > 
> > Regards
> > 
> > Tatsuro
> > 
> > ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and 
> > threat landscape has changed and how IT managers can respond. Discussions 
> > will include endpoint security, mobile security and the latest in malware 
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> 

Re: make: *** [doc2html-ja.exe] Error 1 on Japanese environments (mingw)

[sfeam (E. Merritt) <eam...@gm...>]

On Tuesday, 04 September 2012, Tatsuro MATSUOKA wrote:
> Hello
> 
> I have tried to build the recent cvs source (2012-09-04) mingw.
> Build of gnuplot is fine. 
> 
> However, in making help an error appeared.

I think the error arose from applying the patch file term-ja.diff to
the revised emf.trm file.   Please try the new term-ja.diff in 4.7 CVS
(uploaded just a few minutes ago).

	Ethan


> 
> gcc -shared-libgcc -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc-v2 -L/c/Programs/gplibs/lib -s -o doc2html-ja.exe -DWINDOWS_NO_GUI -DJAPANESE_DOC -I/c/Programs/gplibs/include -fno-keep-inline-dllexport -O3 -I. -I../../src -D_Windows -DHAVE_CONFIG_H  -DGNUPLOT_SHARE_DIR=\"share\" -DDEVELOPMENT_VERSION -DUSE_MOUSE=1 -DWIN_IPC -I/c/PROGRA~2/HELPWO~1/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_LUA -DHAVE_ICONV -I. -Ija/docs/ -Ija//term ../../docs/windows/doc2htm
> l.c ../../docs/termdoc.c ../../docs/xref.c version.o
> In file included from ../../src/term.h:265:0,
>                  from ja/docs/doc2x.h:72,
>                  from ../../docs/windows/doc2html.c:65:
> ja//term/emf.trm:1830:0: error: unterminated #ifdef
> make: *** [doc2html-ja.exe] Error 1
> 
> ja//term/emf.trm:1830:0
> 
> #ifdef TERM_HELP
> START_HELP(emf)
> #ifndef JAPANESE_DOC
>  :
>  :
> #endif /* TERM_HELP */
> 
> ***********
> #ifndef JAPANESE_DOC seem not terminated
> 
> 
> Regards
> 
> Tatsuro
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

make: *** [doc2html-ja.exe] Error 1 on Japanese environments (mingw)

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

Hello

I have tried to build the recent cvs source (2012-09-04) mingw.
Build of gnuplot is fine. 

However, in making help an error appeared.

gcc -shared-libgcc -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc-v2 -L/c/Programs/gplibs/lib -s -o doc2html-ja.exe -DWINDOWS_NO_GUI -DJAPANESE_DOC -I/c/Programs/gplibs/include -fno-keep-inline-dllexport -O3 -I. -I../../src -D_Windows -DHAVE_CONFIG_H  -DGNUPLOT_SHARE_DIR=\"share\" -DDEVELOPMENT_VERSION -DUSE_MOUSE=1 -DWIN_IPC -I/c/PROGRA~2/HELPWO~1/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_LUA -DHAVE_ICONV -I. -Ija/docs/ -Ija//term ../../docs/windows/doc2htm
l.c ../../docs/termdoc.c ../../docs/xref.c version.o
In file included from ../../src/term.h:265:0,
                 from ja/docs/doc2x.h:72,
                 from ../../docs/windows/doc2html.c:65:
ja//term/emf.trm:1830:0: error: unterminated #ifdef
make: *** [doc2html-ja.exe] Error 1

ja//term/emf.trm:1830:0

#ifdef TERM_HELP
START_HELP(emf)
#ifndef JAPANESE_DOC
 :
 :
#endif /* TERM_HELP */

***********
#ifndef JAPANESE_DOC seem not terminated


Regards

Tatsuro

Re: a bunch of warnings

[Mojca M. <moj...@gm...>]

On Tue, Aug 28, 2012 at 8:26 PM, Ethan A Merritt wrote:
> On Tuesday, August 28, 2012 10:20:35 am Mojca Miklavec wrote:
>> What about the other two trivial patches?
>>
>> --- a/src/set.c
>> +++ b/src/set.c
>> @@ -1420,10 +1420,10 @@ static void
>>  set_degreesign(char *locale)
>>  {
>>  #if defined(HAVE_ICONV) && !(defined WIN32)
>> -    char degree_utf8[3] = {'\302', '\260', '\0'};
>> +    const char degree_utf8[3] = {'\302', '\260', '\0'};
>>      size_t lengthin = 3;
>>      size_t lengthout = 8;
>> -    char *in = degree_utf8;
>> +    const char *in = degree_utf8;
>>      char *out = degree_sign;
>>      iconv_t cd;
>
> That generates the following warning instead:
> set.c:1444:17: warning: passing 'const char **' to parameter of type 'char **'
>       discards qualifiers in  nested pointer types [-Wincompatible-pointer-types]
>                 if (iconv(cd, &in, &lengthin, &out, &lengthout) == (size_t)(-1))
>
> IMHO "const char" is impossible to get right, and warnings can safely
> be ignored.

OK, fair enough.

>> --- a/term/lua.trm
>> +++ b/term/lua.trm
>> @@ -168,7 +168,7 @@ static char last_error_msg[MAX_LINE_LEN+1] = "";
>>   *  the plot's bounding box
>>   */
>>  static int
>> -LUA_GP_get_boundingbox() {
>> +LUA_GP_get_boundingbox(lua_State *L) {
>>    lua_newtable (L);
>>    lua_pushstring (L, "xleft");
>>    lua_pushinteger(L, plot_bounds.xleft);
>
> Wouldn't that require a corresponding change in the call site[s]?

All other functions use lua_State *L, just this one lacks it. But I
don't know details about how it works.

> For that matter, where _are_ the call sites - in the lua code?

For example
    local t = gp.get_boundingbox()
    local t = gp.get_all_variables()
in gnuplot-tikz.lua

and in terminal the following mappings are registered (slightly
simplified; without #ifdefs):

static const luaL_Reg gp_methods[] = {
  {"write", LUA_GP_write},
  {"int_error", LUA_GP_int_error},
  {"int_warn", LUA_GP_int_warn},
  {"term_out", LUA_GP_term_out},
  {"get_boundingbox", LUA_GP_get_boundingbox},
  {"is_multiplot", LUA_GP_is_multiplot},
  {"get_all_variables", LUA_GP_get_all_variables},
  {"term_options", LUA_GP_term_options},
  {"parse_color_name", LUA_GP_parse_color_name},
  {NULL, NULL}
};

static void LUA_register_gp_fnc ()
{
  LUA_register(L, "gp", gp_methods);
}

Mojca

Re: a bunch of warnings

[Ethan A M. <sf...@us...>]

On Tuesday, August 28, 2012 10:20:35 am Mojca Miklavec wrote:
> What about the other two trivial patches?
> 
> --- a/src/set.c
> +++ b/src/set.c
> @@ -1420,10 +1420,10 @@ static void
>  set_degreesign(char *locale)
>  {
>  #if defined(HAVE_ICONV) && !(defined WIN32)
> -    char degree_utf8[3] = {'\302', '\260', '\0'};
> +    const char degree_utf8[3] = {'\302', '\260', '\0'};
>      size_t lengthin = 3;
>      size_t lengthout = 8;
> -    char *in = degree_utf8;
> +    const char *in = degree_utf8;
>      char *out = degree_sign;
>      iconv_t cd;

That generates the following warning instead:
set.c:1444:17: warning: passing 'const char **' to parameter of type 'char **' 
      discards qualifiers in  nested pointer types [-Wincompatible-pointer-types]
                if (iconv(cd, &in, &lengthin, &out, &lengthout) == (size_t)(-1))

IMHO "const char" is impossible to get right, and warnings can safely
be ignored.


> --- a/term/lua.trm
> +++ b/term/lua.trm
> @@ -168,7 +168,7 @@ static char last_error_msg[MAX_LINE_LEN+1] = "";
>   *  the plot's bounding box
>   */
>  static int
> -LUA_GP_get_boundingbox() {
> +LUA_GP_get_boundingbox(lua_State *L) {
>    lua_newtable (L);
>    lua_pushstring (L, "xleft");
>    lua_pushinteger(L, plot_bounds.xleft);

Wouldn't that require a corresponding change in the call site[s]?
For that matter, where _are_ the call sites - in the lua code?

	Ethan

Re: a bunch of warnings

[Mojca M. <moj...@gm...>]

First of all, thank you for applying all the patches.

On Tue, Aug 28, 2012 at 7:10 PM, Daniel J Sebald <dan...@ie...> wrote:
> On 08/28/2012 10:46 AM, sfeam (Ethan Merritt) wrote:
>>
>> On Monday, 27 August 2012, Daniel J Sebald wrote:
>>>>
>>>>
>> The assignment of octal values to a (char) is not an error no matter
>> what the signedness of (char), so that set of warnings is spurious and
>> I won't change the code in gplt_x11.c or elsewhere.
>
>
> Not sure.  I tried searching the Internet for a reference, but there is so
> much static from people wondering how to print/read hexadecimal values in C
> that I can't find anything.
>
> The problem is that statement implies that hexadecimal values (i.e.,
> representations) are inherently unsigned, which I'm not sure.  For example,
> 0xFE is a valid representation in C compilers.  Is -0xFE?  If so, then 0xFE
> means 254 and -0xFE means -254.  In the execution of the code, the
> assignment of a hexadecimal is just a byte transfer, but how the compiler
> interprets the abstract representation might be something different.

Fortran would sometime give compiler errors, not just warnings, for
trying to store FF into signed 1-byte integer.
The expression
    char a = 0xff;
is (from what I believe) equivalent to
    char a = 255;
and doesn't necessarily mean bitmap representation that should be
stored into a. Here's a counterexample:
    float f = 0xffff;
This is definitely different from doing memcpy from 0x0000ffff from to f.

But on the other hand I agree that one doesn't need to worry about
that code so much.

>>> # ifndef TT2$M_DECCRT3          /* VT300 not defined as of VAXC v2.4 */
>>> or is it the $ is not a valid character
>>
>> The $ is valid (and very common) in VAX/VMS identifiers.
>> This whole section of code is inside #ifdef VMS so non-VAX compilers
>> should not even be looking at it.
>
> Yes, from what I remember, this should be ignored.  The compiler might have
> some internal test order wrong.

I agree with both. I just wanted to reply that it was $ that was
problematic after testing. (I later discovered that I probably sent
the wrong patch. I didn't want to ask for patching this.)

What about the other two trivial patches?

--- a/src/set.c
+++ b/src/set.c
@@ -1420,10 +1420,10 @@ static void
 set_degreesign(char *locale)
 {
 #if defined(HAVE_ICONV) && !(defined WIN32)
-    char degree_utf8[3] = {'\302', '\260', '\0'};
+    const char degree_utf8[3] = {'\302', '\260', '\0'};
     size_t lengthin = 3;
     size_t lengthout = 8;
-    char *in = degree_utf8;
+    const char *in = degree_utf8;
     char *out = degree_sign;
     iconv_t cd;
--- a/term/lua.trm
+++ b/term/lua.trm
@@ -168,7 +168,7 @@ static char last_error_msg[MAX_LINE_LEN+1] = "";
  *  the plot's bounding box
  */
 static int
-LUA_GP_get_boundingbox() {
+LUA_GP_get_boundingbox(lua_State *L) {
   lua_newtable (L);
   lua_pushstring (L, "xleft");
   lua_pushinteger(L, plot_bounds.xleft);

Mojca

Re: a bunch of warnings

[Daniel J S. <dan...@ie...>]

On 08/28/2012 10:46 AM, sfeam (Ethan Merritt) wrote:
> On Monday, 27 August 2012, Daniel J Sebald wrote:
>>> "../term/emf.trm", line 344: warning: initializer does not fit or is
>>> out of range: -5
>>>
>>> EAM: This one is a true hit, however.
>>>        It looks to me that a dozen or so of the declarations at the
>>>        top of emf.trm are marked "unsigned" for no good reason.
>>>        But why only complain about this one and not 10 others?
>>
>> The others look to be set to valid unsigned numbers, e.g., 0, 1, FALSE,
>> TRUE, 0x2222, EMF_COLORS (which is 15), etc.  LT_UNDEFINED (which is -5)
>> is the only signed value.
>
> The others are valid at initialization time, but still may be
> assigned one of the flag values (e.g. LT_UNDEFINED) when the
> code is run.  If you run "grep LT_ emf.trm" you'll see many such cases.
> Since LT_UNDEFINED is known at compile time, I'm surprised that
> the compiler doesn't also complain about these other assignments.

True, but what is in term_api.h is a set of definitions, not an 
enumeration.  Only in the latter does the compiler know what the valid 
assignment could be.  An enumeration would be good, but that is too much 
shaking the tree this near to a release.


> The assignment of octal values to a (char) is not an error no matter
> what the signedness of (char), so that set of warnings is spurious and
> I won't change the code in gplt_x11.c or elsewhere.

Not sure.  I tried searching the Internet for a reference, but there is 
so much static from people wondering how to print/read hexadecimal 
values in C that I can't find anything.

The problem is that statement implies that hexadecimal values (i.e., 
representations) are inherently unsigned, which I'm not sure.  For 
example, 0xFE is a valid representation in C compilers.  Is -0xFE?  If 
so, then 0xFE means 254 and -0xFE means -254.  In the execution of the 
code, the assignment of a hexadecimal is just a byte transfer, but how 
the compiler interprets the abstract representation might be something 
different.


>> # ifndef TT2$M_DECCRT3          /* VT300 not defined as of VAXC v2.4 */
>> or is it the $ is not a valid character
> The $ is valid (and very common) in VAX/VMS identifiers.
> This whole section of code is inside #ifdef VMS so non-VAX compilers
> should not even be looking at it.

Yes, from what I remember, this should be ignored.  The compiler might 
have some internal test order wrong.

Dan

Re: _Bool on non-C99-conformant compilers

[Mojca M. <moj...@gm...>]

On Tue, Aug 28, 2012 at 5:50 PM, Daniel J Sebald wrote:
> On 08/28/2012 05:58 AM, Mojca Miklavec wrote:
>>
>> I slightly changed the suggestion that I sent you earlier, to:
>>
>> #if HAVE_STDBOOL_H
>> # include<stdbool.h>
>> #else
>> # ifndef __cplusplus
>> #  if ! HAVE__BOOL
>>      typedef unsigned char _Bool;
>> #  endif
>> #  define bool _Bool
>> #  define false 0
>> #  define true 1
>> # endif
>> // the line below is probably not needed
>> # define __bool_true_false_are_defined 1
>> #endif
>
>
> To check where it is used, I grepped and found the only instances in the
> "configure" file of all places.  It's a quite convoluted definition.

I have just found this:
    http://www.velocityreviews.com/forums/t316556-stdbool-h-and-backward-compatibility.html

"The
Autoconf manual seems to suggest that the following code be used in
one's program instead of #include <stdbool.h>:"

(and then the same code as in gnuplot)

I believe that the variable just mimics part of C99 and gnuplot
shouldn't need it at all. And it looks like a bad advice to me.

>> You need to keep in mind that code like this one:
>>
>> /* suprisingly Cocoa version of wxWidgets does not define _Bool ! */
>> #ifdef __WXOSX_COCOA__
>> #define _Bool bool
>> #endif
>>
>> probably resulted from a bug in autotools. Autotools figured out
>> (wrongly) that _Bool was not defined in C and then ended up defining
>>      #  define bool _Bool
>> in C++, so "bool" stopped working in C++ altogether. By using newer
>> autotools and by using the patch above, the code chunk above should
>> not be needed. It was just a bad workaround (which worked, but didn't
>> do the proper thing, and didn't help for Qt either).
>>
>> Similar symptoms might be true for this:
>>
>> /* May or may not fix a problem reported for Sun Studio compilers */
>> #if defined(__SUNPRO_CC)&&  !defined __cplusplus&&  !defined(bool)
>>
>> #define bool unsigned char
>> #endif
>
>
> If a change ends up being made, check whether this definition actually ends
> up being the case when !defined __cplusplus&&  !defined(bool).  If so, this
> is extraneous.

I'm 99% sure that the first patch for Mac is not needed any more (and
I have exact explanation why it was needed before). I don't have
reliable explanation for this second Sun patch, but I'm unable to
think of a case where it would be needed. The compilation on Solaris 9
Sparc with Sun Studio 12 worked with the patch that I sent (without
that extra "may or may not fix" patch).

Mojca

Re: _Bool on non-C99-conformant compilers

[Daniel J S. <dan...@ie...>]

On 08/28/2012 05:58 AM, Mojca Miklavec wrote:
> Hello,
>
> I exchanged a few emails off-list, but the following discussion should
> better move to the mailing list:
>
> On Tue, Aug 28, 2012 at 9:30 AM, Daniel J Sebald wrote:
>> On 08/27/2012 06:40 PM, Mojca Miklavec wrote:
>>> On Tue, Aug 28, 2012 at 12:27 AM, Daniel J Sebald wrote:
>>>> On 08/27/2012 04:30 PM, Mojca Miklavec wrote:
>>>>
>>>>> Do you have any idea about how to overcome _Bool being defined
>>>>> in C, but not in C++?
>>>>
>>>> C++ uses "bool", doesn't it?  If the code in question is a .cpp file,
>>>> "bool" is probably what should be used.
>>>
>>> Do you mean replacing this (which is what's currently in syscfg.h)
>>
>> Not really.  I was thinking more along the lines of just using "bool" if
>> writing C++ code.  Why is _Bool needed?
>
> The C++ code already uses bool. From my understanding, _Bool is never
> used in C++. But "syscfg.h" is apparently used for both C and C++ (I'm
> not sure about the exact include chain, but it somehow effects wxt's
> C++ compilation) and boolean values are needed in C.

OK.  There are a lot of dependencies in qt_term.cpp.


> On any given modern system with C99-conforming stdbool.h the code
> works perfectly now. It just includes that file and we're done. On all
> the other systems the current approach in "#else" part is wrong in my
> opinion:
>
> #if HAVE_STDBOOL_H
> # include<stdbool.h>
> #else
> # if ! HAVE__BOOL
> #  ifdef __cplusplus
> // this means: if _Bool doesn't exist in C, define _Bool in C++; why?
> typedef bool _Bool;
> #  else
> typedef unsigned char _Bool;
> #  endif
> # endif
> // why would one want to redefine bool, true and false in C++ when it
> is all already present?

I'm wondering that as well.

> // this currently breaks Solaris, Mac OS X 10.6 with Xcode 4.2, etc.
> # define bool _Bool
> # define false 0
> # define true 1
> # define __bool_true_false_are_defined 1
> #endif


>> Well, I'd say try to leave<syscfg.h>  out of the C++ file if nothing there
>> is needed.
>>
>> I'm not exactly understanding what needs to be done.  Please explain.
>
> That is also an option, but I don't know how syscfg.h ends up included
> in C++ code at all, and it might be that the file is needed for other
> purposes. That's a question for other developers. If the function is
> written properly, I don't find any problem with syscfg.h being
> included in C++ as well. It should be harmless (if problems are
> fixed).

Yes.  Plus there are ten C headers included in qt_term.cpp, which is too 
many to sort through.


> I slightly changed the suggestion that I sent you earlier, to:
>
> #if HAVE_STDBOOL_H
> # include<stdbool.h>
> #else
> # ifndef __cplusplus
> #  if ! HAVE__BOOL
>      typedef unsigned char _Bool;
> #  endif
> #  define bool _Bool
> #  define false 0
> #  define true 1
> # endif
> // the line below is probably not needed
> # define __bool_true_false_are_defined 1
> #endif

To check where it is used, I grepped and found the only instances in the 
"configure" file of all places.  It's a quite convoluted definition.


> You need to keep in mind that code like this one:
>
> /* suprisingly Cocoa version of wxWidgets does not define _Bool ! */
> #ifdef __WXOSX_COCOA__
> #define _Bool bool
> #endif
>
> probably resulted from a bug in autotools. Autotools figured out
> (wrongly) that _Bool was not defined in C and then ended up defining
>      #  define bool _Bool
> in C++, so "bool" stopped working in C++ altogether. By using newer
> autotools and by using the patch above, the code chunk above should
> not be needed. It was just a bad workaround (which worked, but didn't
> do the proper thing, and didn't help for Qt either).
>
> Similar symptoms might be true for this:
>
> /* May or may not fix a problem reported for Sun Studio compilers */
> #if defined(__SUNPRO_CC)&&  !defined __cplusplus&&  !defined(bool)
> #define bool unsigned char
> #endif

If a change ends up being made, check whether this definition actually 
ends up being the case when !defined __cplusplus&&  !defined(bool).  If 
so, this is extraneous.

Dan

Re: a bunch of warnings

[sfeam (E. Merritt) <eam...@gm...>]

On Monday, 27 August 2012, Daniel J Sebald wrote:
> > "../term/emf.trm", line 344: warning: initializer does not fit or is
> > out of range: -5
> >
> > EAM: This one is a true hit, however.
> >       It looks to me that a dozen or so of the declarations at the
> >       top of emf.trm are marked "unsigned" for no good reason.
> >       But why only complain about this one and not 10 others?
> 
> The others look to be set to valid unsigned numbers, e.g., 0, 1, FALSE, 
> TRUE, 0x2222, EMF_COLORS (which is 15), etc.  LT_UNDEFINED (which is -5) 
> is the only signed value.

The others are valid at initialization time, but still may be
assigned one of the flag values (e.g. LT_UNDEFINED) when the
code is run.  If you run "grep LT_ emf.trm" you'll see many such cases.
Since LT_UNDEFINED is known at compile time, I'm surprised that
the compiler doesn't also complain about these other assignments.

Anyhow, I've applied the trivial fixes to datafile.c emf.trm hpgl.trm

The assignment of octal values to a (char) is not an error no matter
what the signedness of (char), so that set of warnings is spurious and
I won't change the code in gplt_x11.c or elsewhere.

> # ifndef TT2$M_DECCRT3          /* VT300 not defined as of VAXC v2.4 */
> or is it the $ is not a valid character 
The $ is valid (and very common) in VAX/VMS identifiers.
This whole section of code is inside #ifdef VMS so non-VAX compilers
should not even be looking at it.

Re: a bunch of warnings

[Mojca M. <moj...@gm...>]

On Tue, Aug 28, 2012 at 8:52 AM, Daniel J Sebald wrote:
> On 08/27/2012 11:21 PM, Ethan Merritt wrote:
>>
>> On Monday, 27 August 2012, Mojca Miklavec wrote:
>>>
>>> Hello,
>>>
>>> I'm sending a bunch of compiler warnings for gnuplot from two
>>> different compilers. The first batch comes from Sparc Solaris, the
>>> second one from clang on Mac OS X 10.7 (most warnings are recent, in
>>> particular those about plot2d; the last three are older).
>>
>>
>> Thanks.
>>
>> I'm using clang also, but it hasn't given me these particular warnings.
>> Almost all look like either false positives or utter trivia.
>> The emf.trm declarations should be fixed, however.
>> The lua.trm and wxt_gui.cpp ones I do not understand.
>>
>> "datafile.c", line 448: warning: syntax error:  empty declaration
>> EAM: True, but so what?
>
>
> Usually semincolons aren't placed after function definitions.  Is that what
> it's complaining about?
>
> static void auto_filetype_function(void){};     /* Just a placeholder for
> auto    */

Yes. Removing the semicolon got rid of the warning.

>> "datafile.c", line 642: warning: statement not reached
>> EAM: True, and it's even commented as such in the source
>
>
> I wonder why the "return NULL;" was left in?  The typical error would be
> "missing return", but I can't recall any C compiler complaining about the
> construct whereby this function ends with the infinite loop rather than
> "return".  The fact it was left in with that comment makes me suspect
> someone came across a compiler where "missing return" was a problem.  Odd.
> If there are any other similar constructs in gnuplot code...  in fact, I do
> see several routines which end with an infinite loop.  Since those
> apparently aren't causing problems, I'd say remove this:
>
>     /* NOTREACHED */
>     return NULL;
>
> so that the routine is consistent with the rest.

That also solved it.

>> "set.c", line 1444: warning: argument #2 is incompatible with prototype:
>>          prototype: pointer to pointer to const char :
>> "/opt/csw/include/iconv.h", line 83
>>          argument : pointer to pointer to char
>>
>> EAM: Feh. Ignore all warnings about "const char"
>>       That's not even our code - that's a system header.
>
>
> Well, just changing
>
>     char degree_utf8[3] = {'\302', '\260', '\0'};
>     char *in = degree_utf8;
>
> to
>
>     const char degree_utf8[3] = {'\302', '\260', '\0'};
>     const char *in = degree_utf8;
>
> will get rid of the warning.  Small change.  The header is simply indicating
> that whatever the input is, it won't be altered by the library routine.
> (They probably use the same headers to compile the library itself so the
> "const" enforces that rule.)

Thanks. That change helped.

>> "../term/emf.trm", line 344: warning: initializer does not fit or is
>> out of range: -5
>>
>> EAM: This one is a true hit, however.
>>       It looks to me that a dozen or so of the declarations at the
>>       top of emf.trm are marked "unsigned" for no good reason.
>>       But why only complain about this one and not 10 others?
>
>
> The others look to be set to valid unsigned numbers, e.g., 0, 1, FALSE,
> TRUE, 0x2222, EMF_COLORS (which is 15), etc.  LT_UNDEFINED (which is -5) is
> the only signed value.

Thanks. (But I leave it up to others to figure out which ones need a change.)

>> "../term/hpgl.trm", line 2580: warning: statement not reached
>> EAM: OK
>
>         break;
>         return;
>
> Probably lose points for that one on an exam.

Why is return needed here at all? (Removing it got rid of warning.)

>> "../term/lua.trm", line 469: warning: initialization type mismatch
>> EAM: I have absoluately no idea what this one is about.
>
>
> The definition of LUA_GP_get_boundingbox is incomplete, i.e., missing
> argument definition:
>
> static int
> LUA_GP_get_boundingbox() {
>
> should be
>
> static int
> LUA_GP_get_boundingbox(lua_State *L) {

This helped. Thank you.

>> "term.c", line 2159: warning: tokens ignored at end of directive line
>> EAM: ignore it
>
> What's wrong with this line?  Is it that the comment appears within the
> preprocessor definitions?
>
> # ifndef TT2$M_DECCRT3          /* VT300 not defined as of VAXC v2.4 */
>
> or is it the $ is not a valid character so that this is really

It seems so. Removing comments didn't have any influence, while
replacing $ by _ got rid of the warning. But then, this was only
diagnosis, not a valid solution.

>> "gplt_x11.c", line 634: warning: initializer does not fit or is out of
>> range: 129
>> "gplt_x11.c", line 635: warning: initializer does not fit or is out of
>> range: 136
>> "gplt_x11.c", line 636: warning: initializer does not fit or is out of
>> range: 255
>> "gplt_x11.c", line 637: warning: initializer does not fit or is out of
>> range: 128
>> "gplt_x11.c", line 638: warning: initializer does not fit or is out of
>> range: 128
>> "gplt_x11.c", line 639: warning: initializer does not fit or is out of
>> range: 136
>> "gplt_x11.c", line 640: warning: initializer does not fit or is out of
>> range: 136
>> EAM: These make no sense to me.
>
>
> You might have to declare stipple_pattern_bits as unsigned:
>
> static const unsigned char stipple_pattern_bits[stipple_pattern_num][8] = {
>
> vs.
>
> static const char stipple_pattern_bits[stipple_pattern_num][8] = {
>
> because some of those bit fields as hexadecimal definitons are greater than
> the maximum signed char value.  (Man, this compiler is going after
> everything!)

Exactly. I tried that (the only one I tried to debug myself
yesterday). But then the following complained:

    XCreateBitmapFromData(dpy, plot->pixmap, stipple_pattern_bits[i],
        stipple_pattern_width, stipple_pattern_height);

because XCreateBitmapFromData wants to use signed char as the 3rd
argument. In this particular case I don't really understand why
signed. (It would probably need some casting, but I'm not sure how.)

Thank you for all the diagnosis.

Oh, and of course I forgot another one:
    "fit.c", line 574: warning: statement not reached
(Was it other dumber compiler that complained if return was missing?)

I'm attaching the summary of changes which only left those gplt_x11.c
warnings (I'm not sure how to properly cast) in and the complaint
about $. emf might need a closer look of course. (The bool changes
were needed since I'm unable to compile gnuplot otherwise.)

Mojca

_Bool on non-C99-conformant compilers

[Mojca M. <moj...@gm...>]

Hello,

I exchanged a few emails off-list, but the following discussion should
better move to the mailing list:

On Tue, Aug 28, 2012 at 9:30 AM, Daniel J Sebald wrote:
> On 08/27/2012 06:40 PM, Mojca Miklavec wrote:
>> On Tue, Aug 28, 2012 at 12:27 AM, Daniel J Sebald wrote:
>>> On 08/27/2012 04:30 PM, Mojca Miklavec wrote:
>>>
>>>> Do you have any idea about how to overcome _Bool being defined
>>>> in C, but not in C++?
>>>
>>> C++ uses "bool", doesn't it?  If the code in question is a .cpp file,
>>> "bool" is probably what should be used.
>>
>> Do you mean replacing this (which is what's currently in syscfg.h)
>
> Not really.  I was thinking more along the lines of just using "bool" if
> writing C++ code.  Why is _Bool needed?

The C++ code already uses bool. From my understanding, _Bool is never
used in C++. But "syscfg.h" is apparently used for both C and C++ (I'm
not sure about the exact include chain, but it somehow effects wxt's
C++ compilation) and boolean values are needed in C.

On any given modern system with C99-conforming stdbool.h the code
works perfectly now. It just includes that file and we're done. On all
the other systems the current approach in "#else" part is wrong in my
opinion:

#if HAVE_STDBOOL_H
# include<stdbool.h>
#else
# if ! HAVE__BOOL
#  ifdef __cplusplus
// this means: if _Bool doesn't exist in C, define _Bool in C++; why?
typedef bool _Bool;
#  else
typedef unsigned char _Bool;
#  endif
# endif
// why would one want to redefine bool, true and false in C++ when it
is all already present?
// this currently breaks Solaris, Mac OS X 10.6 with Xcode 4.2, etc.
# define bool _Bool
# define false 0
# define true 1
# define __bool_true_false_are_defined 1
#endif

> This is some strange code.  "typedef bool _Bool" followed by "define bool
> _Bool".  Strange.

That part I understand. A lot of systems have _Bool already defined by
compiler. On those systems gnuplot only uses
    #define bool _Bool
where _Bool comes from compiler. On other even more exotic systems
that don't know anything about _Bool it uses
    #typedef unsigned char _Bool
    #define bool _Bool
but that looks OK to me. OK, one could use just
    #typedef unsigned char bool
if that would change anything ...

> Well, I'd say try to leave <syscfg.h> out of the C++ file if nothing there
> is needed.
>
> I'm not exactly understanding what needs to be done.  Please explain.

That is also an option, but I don't know how syscfg.h ends up included
in C++ code at all, and it might be that the file is needed for other
purposes. That's a question for other developers. If the function is
written properly, I don't find any problem with syscfg.h being
included in C++ as well. It should be harmless (if problems are
fixed).

I slightly changed the suggestion that I sent you earlier, to:

#if HAVE_STDBOOL_H
# include <stdbool.h>
#else
# ifndef __cplusplus
#  if ! HAVE__BOOL
    typedef unsigned char _Bool;
#  endif
#  define bool _Bool
#  define false 0
#  define true 1
# endif
// the line below is probably not needed
# define __bool_true_false_are_defined 1
#endif

This completely avoids _Bool in C++, it is only used in C to define
"bool". This approach solved the problem on Solars for me, and the
user who reported a problem on Mac OS X 10.6 said it solved the
problem for him as well.

The complete patch as suggested by me is here:
    http://sourceforge.net/tracker/?func=detail&aid=3562307&group_id=2055&atid=302055
(with all the links)

You need to keep in mind that code like this one:

/* suprisingly Cocoa version of wxWidgets does not define _Bool ! */
#ifdef __WXOSX_COCOA__
#define _Bool bool
#endif

probably resulted from a bug in autotools. Autotools figured out
(wrongly) that _Bool was not defined in C and then ended up defining
    #  define bool _Bool
in C++, so "bool" stopped working in C++ altogether. By using newer
autotools and by using the patch above, the code chunk above should
not be needed. It was just a bad workaround (which worked, but didn't
do the proper thing, and didn't help for Qt either).

Similar symptoms might be true for this:

/* May or may not fix a problem reported for Sun Studio compilers */
#if defined(__SUNPRO_CC) && !defined __cplusplus && !defined(bool)
#define bool unsigned char
#endif


I would like to request if someone could take a closer look at the
patch. I don't have enough knowledge about different compilers to
claim that it would really solve all problems, but it already looks
much better. At least on two systems where current functionality is
broken (solaris, Mac OS X 10.6) the problem has been fixed.

Mojca

Re: a bunch of warnings

[Daniel J S. <dan...@ie...>]

On 08/27/2012 11:21 PM, Ethan Merritt wrote:
> On Monday, 27 August 2012, Mojca Miklavec wrote:
>> Hello,
>>
>> I'm sending a bunch of compiler warnings for gnuplot from two
>> different compilers. The first batch comes from Sparc Solaris, the
>> second one from clang on Mac OS X 10.7 (most warnings are recent, in
>> particular those about plot2d; the last three are older).
>
> Thanks.
>
> I'm using clang also, but it hasn't given me these particular warnings.
> Almost all look like either false positives or utter trivia.
> The emf.trm declarations should be fixed, however.
> The lua.trm and wxt_gui.cpp ones I do not understand.
>
> "datafile.c", line 448: warning: syntax error:  empty declaration
> EAM: True, but so what?

Usually semincolons aren't placed after function definitions.  Is that 
what it's complaining about?

static void auto_filetype_function(void){};	/* Just a placeholder for 
auto    */


> "datafile.c", line 642: warning: statement not reached
> EAM: True, and it's even commented as such in the source

I wonder why the "return NULL;" was left in?  The typical error would be 
"missing return", but I can't recall any C compiler complaining about 
the construct whereby this function ends with the infinite loop rather 
than "return".  The fact it was left in with that comment makes me 
suspect someone came across a compiler where "missing return" was a 
problem.  Odd.  If there are any other similar constructs in gnuplot 
code...  in fact, I do see several routines which end with an infinite 
loop.  Since those apparently aren't causing problems, I'd say remove this:

     /* NOTREACHED */
     return NULL;

so that the routine is consistent with the rest.


> "set.c", line 1444: warning: argument #2 is incompatible with prototype:
>          prototype: pointer to pointer to const char :
> "/opt/csw/include/iconv.h", line 83
>          argument : pointer to pointer to char
>
> EAM: Feh. Ignore all warnings about "const char"
>       That's not even our code - that's a system header.

Well, just changing

     char degree_utf8[3] = {'\302', '\260', '\0'};
     char *in = degree_utf8;

to

     const char degree_utf8[3] = {'\302', '\260', '\0'};
     const char *in = degree_utf8;

will get rid of the warning.  Small change.  The header is simply 
indicating that whatever the input is, it won't be altered by the 
library routine.  (They probably use the same headers to compile the 
library itself so the "const" enforces that rule.)


> "../term/emf.trm", line 344: warning: initializer does not fit or is
> out of range: -5
>
> EAM: This one is a true hit, however.
>       It looks to me that a dozen or so of the declarations at the
>       top of emf.trm are marked "unsigned" for no good reason.
>       But why only complain about this one and not 10 others?

The others look to be set to valid unsigned numbers, e.g., 0, 1, FALSE, 
TRUE, 0x2222, EMF_COLORS (which is 15), etc.  LT_UNDEFINED (which is -5) 
is the only signed value.


> "../term/hpgl.trm", line 2580: warning: statement not reached
> EAM: OK

	break;
	return;

Probably lose points for that one on an exam.


> "../term/lua.trm", line 469: warning: initialization type mismatch
> EAM: I have absoluately no idea what this one is about.

The definition of LUA_GP_get_boundingbox is incomplete, i.e., missing 
argument definition:

static int
LUA_GP_get_boundingbox() {

should be

static int
LUA_GP_get_boundingbox(lua_State *L) {


>
> "term.c", line 2159: warning: tokens ignored at end of directive line
> EAM: ignore it

What's wrong with this line?  Is it that the comment appears within the 
preprocessor definitions?

# ifndef TT2$M_DECCRT3          /* VT300 not defined as of VAXC v2.4 */

or is it the $ is not a valid character so that this is really

# ifndef TT2
#  define TT2
# endif

if what is after the $ is ignored?


> "wxterminal/wxt_gui.cpp", line 1669: Warning (Anachronism): Formal
> argument 1 of type extern "C" void(*)() in call to std::atexit(extern
> "C" void(*)()) is being passed void(*)().
> "wxterminal/wxt_gui.cpp", line 3831: Warning (Anachronism): Formal
> argument 2 of type extern "C" void(*)(int) in call to std::signal(int,
> extern "C" void(*)(int)) is being passed void(*)(int).
> "wxterminal/wxt_gui.cpp", line 3866: Warning (Anachronism): Formal
> argument 2 of type extern "C" void(*)(int) in call to std::signal(int,
> extern "C" void(*)(int)) is being passed void(*)(int).
> "wxterminal/wxt_gui.cpp", line 3866: Warning (Anachronism): Assigning
> extern "C" void(*)(int) to void(*)(int).
> "wxterminal/wxt_gui.cpp", line 3875: Warning (Anachronism): Formal
> argument 2 of type extern "C" void(*)(int) in call to std::signal(int,
> extern "C" void(*)(int)) is being passed void(*)(int).
> 5 Warning(s) detected.
> EAM: Is it saying that you can't pass a C routine as a C++ parameter?
>       Really?

Probably.  You may have to cast what is inside the argument because 
these two might be different internally:

"C" void(*)()
void(*)()

the latter being a C++ function.  (?)  If such function resided in a 
library somewhere and were called with the wrong format it would likely 
cause problems.  Anyway, maybe something like:

		/* register call for "persist" effect and cleanup */
		GP_ATEXIT(("C" void(*)())wxt_atexit);

Actually, there might be a better exit mechanism under C++ and perhaps 
GP_ATEXIT() should be redefined.


> "gplt_x11.c", line 634: warning: initializer does not fit or is out of
> range: 129
> "gplt_x11.c", line 635: warning: initializer does not fit or is out of
> range: 136
> "gplt_x11.c", line 636: warning: initializer does not fit or is out of
> range: 255
> "gplt_x11.c", line 637: warning: initializer does not fit or is out of
> range: 128
> "gplt_x11.c", line 638: warning: initializer does not fit or is out of
> range: 128
> "gplt_x11.c", line 639: warning: initializer does not fit or is out of
> range: 136
> "gplt_x11.c", line 640: warning: initializer does not fit or is out of
> range: 136
> EAM: These make no sense to me.

You might have to declare stipple_pattern_bits as unsigned:

static const unsigned char stipple_pattern_bits[stipple_pattern_num][8] = {

vs.

static const char stipple_pattern_bits[stipple_pattern_num][8] = {

because some of those bit fields as hexadecimal definitons are greater 
than the maximum signed char value.  (Man, this compiler is going after 
everything!)


> ../../original/src/plot2d.c:821:7: warning: array index of '-1'
> indexes before the beginning of the array [-Warray-bounds]
>
> COLOR_STORE_WITH_LOG_AND_UPDATE_RANGE(cp->CRD_COLOR, v[2], cp->type,
> [snip lots of fallout]
>
> EAM: These warnings are known false positives as noted in the ChangeLog.
> 	The compiler is simply not smart enough to notice that the
>       negative array index can never happen in practice.

Is it possible to write things to fake out the compiler?  These lines 
are difficult to follow for me without thinking too much, so here's a 
hypothetical example:

		    cp = &(current_plot->points[i]);

replaced by:

		    cp = &(current_plot->points[i+1]) - 1;

Kludge, I know.  But rewriting some of these lengthy conditionals would 
be tough.  (BTW, one or two letter variables in a long conditional are 
challenge to debug.)


>       The following patch suppresses the warnings, but I don't like it
>       because it introduces unneeded code into one of the few true
>       hot paths in the program.  Also I'm not 100% that all C compilers
>       will accept and optimize the #VARNAME syntax.

How does this fix out of range errors in a different file (plot2d.c)? 
Very confusing.


> --- gnuplot/src/axis.h  2012-08-05 21:12:03.000000000 -0700
> +++ gnuplot-cvs/src/axis.h      2012-08-07 13:17:43.000000000 -0700
> @@ -539,7 +539,8 @@
>          break;  /* this plot is not being used for autoscaling */         \
>       if (TYPE != INRANGE)                                                 \
>          break;  /* don't set y range if x is outrange, for example */     \
> -    if (axis->linked_to_primary) {                                       \
> +    /* NB: we hope for compile-time evaluation of the strcmp */          \
> +    if (strcmp(#AXIS,"COLOR_AXIS")&&  axis->linked_to_primary) {         \
>          axis =&axis_array[AXIS - SECOND_AXES];                           \
>          if (axis->link_udf->at)                                           \
>              curval = eval_link_function(AXIS - SECOND_AXES, curval);      \


Hope that helps some.

Dan

a bunch of warnings

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

On Monday, 27 August 2012, Mojca Miklavec wrote:
> Hello,
> 
> I'm sending a bunch of compiler warnings for gnuplot from two
> different compilers. The first batch comes from Sparc Solaris, the
> second one from clang on Mac OS X 10.7 (most warnings are recent, in
> particular those about plot2d; the last three are older).

Thanks.  

I'm using clang also, but it hasn't given me these particular warnings. 
Almost all look like either false positives or utter trivia.
The emf.trm declarations should be fixed, however.
The lua.trm and wxt_gui.cpp ones I do not understand.
 
"datafile.c", line 448: warning: syntax error:  empty declaration
EAM: True, but so what?

"datafile.c", line 642: warning: statement not reached
EAM: True, and it's even commented as such in the source

"set.c", line 1444: warning: argument #2 is incompatible with prototype:
        prototype: pointer to pointer to const char :
"/opt/csw/include/iconv.h", line 83
        argument : pointer to pointer to char

EAM: Feh. Ignore all warnings about "const char"
     That's not even our code - that's a system header.

"../term/emf.trm", line 344: warning: initializer does not fit or is
out of range: -5

EAM: This one is a true hit, however.
     It looks to me that a dozen or so of the declarations at the
     top of emf.trm are marked "unsigned" for no good reason.
     But why only complain about this one and not 10 others?

"../term/hpgl.trm", line 2580: warning: statement not reached
EAM: OK
"../term/lua.trm", line 469: warning: initialization type mismatch
EAM: I have absoluately no idea what this one is about.

"term.c", line 2159: warning: tokens ignored at end of directive line
EAM: ignore it

"wxterminal/wxt_gui.cpp", line 1669: Warning (Anachronism): Formal
argument 1 of type extern "C" void(*)() in call to std::atexit(extern
"C" void(*)()) is being passed void(*)().
"wxterminal/wxt_gui.cpp", line 3831: Warning (Anachronism): Formal
argument 2 of type extern "C" void(*)(int) in call to std::signal(int,
extern "C" void(*)(int)) is being passed void(*)(int).
"wxterminal/wxt_gui.cpp", line 3866: Warning (Anachronism): Formal
argument 2 of type extern "C" void(*)(int) in call to std::signal(int,
extern "C" void(*)(int)) is being passed void(*)(int).
"wxterminal/wxt_gui.cpp", line 3866: Warning (Anachronism): Assigning
extern "C" void(*)(int) to void(*)(int).
"wxterminal/wxt_gui.cpp", line 3875: Warning (Anachronism): Formal
argument 2 of type extern "C" void(*)(int) in call to std::signal(int,
extern "C" void(*)(int)) is being passed void(*)(int).
5 Warning(s) detected.
EAM: Is it saying that you can't pass a C routine as a C++ parameter?
     Really?


"gplt_x11.c", line 634: warning: initializer does not fit or is out of
range: 129
"gplt_x11.c", line 635: warning: initializer does not fit or is out of
range: 136
"gplt_x11.c", line 636: warning: initializer does not fit or is out of
range: 255
"gplt_x11.c", line 637: warning: initializer does not fit or is out of
range: 128
"gplt_x11.c", line 638: warning: initializer does not fit or is out of
range: 128
"gplt_x11.c", line 639: warning: initializer does not fit or is out of
range: 136
"gplt_x11.c", line 640: warning: initializer does not fit or is out of
range: 136
EAM: These make no sense to me.


../../original/src/plot2d.c:821:7: warning: array index of '-1'
indexes before the beginning of the array [-Warray-bounds]

COLOR_STORE_WITH_LOG_AND_UPDATE_RANGE(cp->CRD_COLOR, v[2], cp->type,
[snip lots of fallout]

EAM: These warnings are known false positives as noted in the ChangeLog.
	The compiler is simply not smart enough to notice that the
     negative array index can never happen in practice.
     The following patch suppresses the warnings, but I don't like it
     because it introduces unneeded code into one of the few true
     hot paths in the program.  Also I'm not 100% that all C compilers
     will accept and optimize the #VARNAME syntax.

--- gnuplot/src/axis.h  2012-08-05 21:12:03.000000000 -0700
+++ gnuplot-cvs/src/axis.h      2012-08-07 13:17:43.000000000 -0700
@@ -539,7 +539,8 @@
        break;  /* this plot is not being used for autoscaling */         \
     if (TYPE != INRANGE)                                                 \
        break;  /* don't set y range if x is outrange, for example */     \
-    if (axis->linked_to_primary) {                                       \
+    /* NB: we hope for compile-time evaluation of the strcmp */          \
+    if (strcmp(#AXIS,"COLOR_AXIS") && axis->linked_to_primary) {         \
        axis = &axis_array[AXIS - SECOND_AXES];                           \
        if (axis->link_udf->at)                                           \
            curval = eval_link_function(AXIS - SECOND_AXES, curval);      \

a bunch of warnings

[Mojca M. <moj...@gm...>]

Hello,

I'm sending a bunch of compiler warnings for gnuplot from two
different compilers. The first batch comes from Sparc Solaris, the
second one from clang on Mac OS X 10.7 (most warnings are recent, in
particular those about plot2d; the last three are older).

"datafile.c", line 448: warning: syntax error:  empty declaration
"datafile.c", line 642: warning: statement not reached

"set.c", line 1444: warning: argument #2 is incompatible with prototype:
        prototype: pointer to pointer to const char :
"/opt/csw/include/iconv.h", line 83
        argument : pointer to pointer to char

"../term/emf.trm", line 344: warning: initializer does not fit or is
out of range: -5
"../term/hpgl.trm", line 2580: warning: statement not reached
"../term/lua.trm", line 469: warning: initialization type mismatch
"term.c", line 2159: warning: tokens ignored at end of directive line

"wxterminal/wxt_gui.cpp", line 1669: Warning (Anachronism): Formal
argument 1 of type extern "C" void(*)() in call to std::atexit(extern
"C" void(*)()) is being passed void(*)().
"wxterminal/wxt_gui.cpp", line 3831: Warning (Anachronism): Formal
argument 2 of type extern "C" void(*)(int) in call to std::signal(int,
extern "C" void(*)(int)) is being passed void(*)(int).
"wxterminal/wxt_gui.cpp", line 3866: Warning (Anachronism): Formal
argument 2 of type extern "C" void(*)(int) in call to std::signal(int,
extern "C" void(*)(int)) is being passed void(*)(int).
"wxterminal/wxt_gui.cpp", line 3866: Warning (Anachronism): Assigning
extern "C" void(*)(int) to void(*)(int).
"wxterminal/wxt_gui.cpp", line 3875: Warning (Anachronism): Formal
argument 2 of type extern "C" void(*)(int) in call to std::signal(int,
extern "C" void(*)(int)) is being passed void(*)(int).
5 Warning(s) detected.

"gplt_x11.c", line 634: warning: initializer does not fit or is out of
range: 129
"gplt_x11.c", line 635: warning: initializer does not fit or is out of
range: 136
"gplt_x11.c", line 636: warning: initializer does not fit or is out of
range: 255
"gplt_x11.c", line 637: warning: initializer does not fit or is out of
range: 128
"gplt_x11.c", line 638: warning: initializer does not fit or is out of
range: 128
"gplt_x11.c", line 639: warning: initializer does not fit or is out of
range: 136
"gplt_x11.c", line 640: warning: initializer does not fit or is out of
range: 136
"gplt_x11.c", line 1778: warning: statement not reached


../../original/src/plot2d.c:821:7: warning: array index of '-1'
indexes before the beginning of the array [-Warray-bounds]

COLOR_STORE_WITH_LOG_AND_UPDATE_RANGE(cp->CRD_COLOR, v[2], cp->type,

^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../original/src/axis.h:603:5: note: expanded from macro
'COLOR_STORE_WITH_LOG_AND_UPDATE_RANGE'
    STORE_WITH_LOG_AND_UPDATE_RANGE(STORE, VALUE, c_type_tmp, AXIS,       \
    ^
../../original/src/axis.h:543:10: note: expanded from macro
'STORE_WITH_LOG_AND_UPDATE_RANGE'
        axis = &axis_array[AXIS - SECOND_AXES];                           \
                ^
../../original/src/axis.h:303:1: note: array 'axis_array' declared here
extern AXIS axis_array[AXIS_ARRAY_SIZE];
^
../../original/src/plot2d.c:1304:2: warning: array index of '-1'
indexes before the beginning of the array [-Warray-bounds]
        STORE_WITH_LOG_AND_UPDATE_RANGE(current_plot->varcolor[i],
current_plot->varcolor[i],
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../original/src/axis.h:543:10: note: expanded from macro
'STORE_WITH_LOG_AND_UPDATE_RANGE'
        axis = &axis_array[AXIS - SECOND_AXES];                           \
                ^
../../original/src/axis.h:303:1: note: array 'axis_array' declared here
extern AXIS axis_array[AXIS_ARRAY_SIZE];
^
2 warnings generated.

../../original/src/plot3d.c:665:3: warning: array index of '-1'
indexes before the beginning of the array [-Warray-bounds]
                COLOR_STORE_WITH_LOG_AND_UPDATE_RANGE(points->CRD_COLOR, z,
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../original/src/axis.h:603:5: note: expanded from macro
'COLOR_STORE_WITH_LOG_AND_UPDATE_RANGE'
    STORE_WITH_LOG_AND_UPDATE_RANGE(STORE, VALUE, c_type_tmp, AXIS,       \
    ^
../../original/src/axis.h:543:10: note: expanded from macro
'STORE_WITH_LOG_AND_UPDATE_RANGE'
        axis = &axis_array[AXIS - SECOND_AXES];                           \
                ^
../../original/src/axis.h:303:1: note: array 'axis_array' declared here
extern AXIS axis_array[AXIS_ARRAY_SIZE];
^
../../original/src/plot3d.c:1042:4: warning: array index of '-1'
indexes before the beginning of the array [-Warray-bounds]

COLOR_STORE_WITH_LOG_AND_UPDATE_RANGE(cp->CRD_COLOR, color, cp->type,
COLOR_AXIS, this_plot->noautoscale, NOOP, goto
come_here_if_undefined);

^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../original/src/axis.h:603:5: note: expanded from macro
'COLOR_STORE_WITH_LOG_AND_UPDATE_RANGE'
    STORE_WITH_LOG_AND_UPDATE_RANGE(STORE, VALUE, c_type_tmp, AXIS,       \
    ^
../../original/src/axis.h:543:10: note: expanded from macro
'STORE_WITH_LOG_AND_UPDATE_RANGE'
        axis = &axis_array[AXIS - SECOND_AXES];                           \
                ^
../../original/src/axis.h:303:1: note: array 'axis_array' declared here
extern AXIS axis_array[AXIS_ARRAY_SIZE];
^
../../original/src/plot3d.c:1044:4: warning: array index of '-1'
indexes before the beginning of the array [-Warray-bounds]

COLOR_STORE_WITH_LOG_AND_UPDATE_RANGE(cp->CRD_COLOR, z, cp->type,
COLOR_AXIS, this_plot->noautoscale, NOOP, goto
come_here_if_undefined);

^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../original/src/axis.h:603:5: note: expanded from macro
'COLOR_STORE_WITH_LOG_AND_UPDATE_RANGE'
    STORE_WITH_LOG_AND_UPDATE_RANGE(STORE, VALUE, c_type_tmp, AXIS,       \
    ^
../../original/src/axis.h:543:10: note: expanded from macro
'STORE_WITH_LOG_AND_UPDATE_RANGE'
        axis = &axis_array[AXIS - SECOND_AXES];                           \
                ^
../../original/src/axis.h:303:1: note: array 'axis_array' declared here
extern AXIS axis_array[AXIS_ARRAY_SIZE];
^
../../original/src/plot3d.c:1207:3: warning: array index of '-1'
indexes before the beginning of the array [-Warray-bounds]

COLOR_STORE_WITH_LOG_AND_UPDATE_RANGE(points[i].CRD_COLOR, temp,
points[i].type,

^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../original/src/axis.h:603:5: note: expanded from macro
'COLOR_STORE_WITH_LOG_AND_UPDATE_RANGE'
    STORE_WITH_LOG_AND_UPDATE_RANGE(STORE, VALUE, c_type_tmp, AXIS,       \
    ^
../../original/src/axis.h:543:10: note: expanded from macro
'STORE_WITH_LOG_AND_UPDATE_RANGE'
        axis = &axis_array[AXIS - SECOND_AXES];                           \
                ^
../../original/src/axis.h:303:1: note: array 'axis_array' declared here
extern AXIS axis_array[AXIS_ARRAY_SIZE];
^
4 warnings generated.

../../original/src/util.c:518:10: warning: 'sprintf' macro redefined
# define sprintf(str,fmt,arg) \
         ^
/usr/include/secure/_stdio.h:49:9: note: previous definition is here
#define sprintf(str, ...) \
        ^
1 warning generated.

../../original/src/wxterminal/wxt_gui.cpp:2750:11: warning:
enumeration value 'command_enhanced_put_text' not handled in switch
[-Wswitch-enum]
        switch ( command.command ) {
                 ^
1 warning generated.

../../original/src/gplt_x11.c:4565:11: warning: 'XKeycodeToKeysym' is
deprecated [-Wdeprecated-declarations]
        keysym = XKeycodeToKeysym(dpy, event->xkey.keycode, 0);
                 ^
1 warning generated.


Mojca

Re: missing labels in wxt under Mac

[Daniel J S. <dan...@ie...>]

On 08/27/2012 04:38 PM, Mojca Miklavec wrote:
> On Mon, Aug 27, 2012 at 11:13 PM, Daniel J Sebald wrote:
>> On 08/27/2012 04:02 PM, Mojca Miklavec wrote:
>>>
>>>> That should find the proper header files, but you may want to
>>>> check that is in fact the case.
>>>
>>>
>>> What exactly should I look for?
>>
>>
>> When the actual compile commands appear on the screen during "make", check
>> where the -I directories point to and that the header files in that
>> directory(ies) agree with the library(ies) eventually being linked to.  If
>> there is some slight mismatch between those two, the routines will be found
>> and run but behave erratically.
>
> It looks correct to me (duplicates removed):
>
> -L/opt/local/lib -lz -lpangocairo-1.0 -lcairo -lpangoft2-1.0
> -lpango-1.0 -lm -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0
> -lintl -framework Cocoa
>
> -I/opt/local/include -I/opt/local/include/glib-2.0
> -I/opt/local/lib/glib-2.0/include -I/opt/local/include/pixman-1
> -I/opt/local/include/freetype2 -I/opt/local/include/libpng14
> -I/opt/local/include/pango-1.0 -I/opt/local/include/cairo
> -I/opt/local/include/QtCore -I/opt/local/include/QtGui
> -I/opt/local/include/QtNetwork -I/opt/local/include/QtSvg
>
> Is there any function to check?

Not sure.  You are seeing both glib errors and pango errors.  glib-2.0 
looks consistent.  As for pango, is there a difference between 
"pangocairo-1.0" and "pango-1.0", or is there some header file withing 
"pango-1.0" that addresses that?  If you can create a Qt terminal plot 
using a command that doesn't have labels or text, then I would assume Qt 
headers/library match.

I do see one small discrepancy.  The header file indicates "freetype2", 
while the library linked in is "freetype" without the 2.  Now, if there 
is a different library "-lfreetype2" that can be linked to, that might 
be where the problem resides, i.e., slightly different font definitions 
with a different number of descriptive variables.  (I know little about 
Windows freetype.)  I don't see how that would account for the glib 
errors though.  Anyway, look into that: freetype2 vs. freetype library.

Dan

Re: missing labels in wxt under Mac

[Mojca M. <moj...@gm...>]

On Mon, Aug 27, 2012 at 11:13 PM, Daniel J Sebald wrote:
> On 08/27/2012 04:02 PM, Mojca Miklavec wrote:
>>
>>> That should find the proper header files, but you may want to
>>> check that is in fact the case.
>>
>>
>> What exactly should I look for?
>
>
> When the actual compile commands appear on the screen during "make", check
> where the -I directories point to and that the header files in that
> directory(ies) agree with the library(ies) eventually being linked to.  If
> there is some slight mismatch between those two, the routines will be found
> and run but behave erratically.

It looks correct to me (duplicates removed):

-L/opt/local/lib -lz -lpangocairo-1.0 -lcairo -lpangoft2-1.0
-lpango-1.0 -lm -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0
-lintl -framework Cocoa

-I/opt/local/include -I/opt/local/include/glib-2.0
-I/opt/local/lib/glib-2.0/include -I/opt/local/include/pixman-1
-I/opt/local/include/freetype2 -I/opt/local/include/libpng14
-I/opt/local/include/pango-1.0 -I/opt/local/include/cairo
-I/opt/local/include/QtCore -I/opt/local/include/QtGui
-I/opt/local/include/QtNetwork -I/opt/local/include/QtSvg

Is there any function to check?

Mojca

Re: missing labels in wxt under Mac

[Daniel J S. <dan...@ie...>]

On 08/27/2012 04:02 PM, Mojca Miklavec wrote:
> On Mon, Aug 27, 2012 at 9:44 PM, Daniel J Sebald wrote:
>> On 08/26/2012 09:20 AM, Mojca Miklavec wrote:
>>>
>>> Hello,
>>>
>>> I just realized that I don't get any labels with wxt terminal under
>>> Mac OS X (neither with 2.8 nor with 2.9.4). Is there any other mac
>>> user out there who ever tried to use wxt?
>>>
>>> It is possible that some recent library changes under MacPorts broke
>>> the functionality.
>>
>> That would be my guess judging from what you've reported.  I've little
>> knowledge of MacPorts, but it appears that wxt is attempting to call all
>> these global functions which then get lost somewhere or in some way.
>>
>> You recompiled with a proper configuration from scratch, i.e., ./prepare,
>> ./configure?
>
> I tried two scenarios:
> - slightly patched 4.6 (with more-or-less original ./configure file;
> I'm saying "more-or-less" because of a bug in autotools that had to be
> fixed, and the patches that were needed to compile Qt)
> - latest CVS version with ./prepare, ./configure, ...
>
> I also tried with wxWidgets:
> - 2.8
> - 2.9.4
> - 2.9.5
> and they all resulted in the same behaviour. I didn't try to change
> the version of pango/cairo/anyotherlib.
>
>> That should find the proper header files, but you may want to
>> check that is in fact the case.
>
> What exactly should I look for?

When the actual compile commands appear on the screen during "make", 
check where the -I directories point to and that the header files in 
that directory(ies) agree with the library(ies) eventually being linked 
to.  If there is some slight mismatch between those two, the routines 
will be found and run but behave erratically.

Dan

Re: missing labels in wxt under Mac

[Mojca M. <moj...@gm...>]

On Mon, Aug 27, 2012 at 9:44 PM, Daniel J Sebald wrote:
> On 08/26/2012 09:20 AM, Mojca Miklavec wrote:
>>
>> Hello,
>>
>> I just realized that I don't get any labels with wxt terminal under
>> Mac OS X (neither with 2.8 nor with 2.9.4). Is there any other mac
>> user out there who ever tried to use wxt?
>>
>> It is possible that some recent library changes under MacPorts broke
>> the functionality.
>
> That would be my guess judging from what you've reported.  I've little
> knowledge of MacPorts, but it appears that wxt is attempting to call all
> these global functions which then get lost somewhere or in some way.
>
> You recompiled with a proper configuration from scratch, i.e., ./prepare,
> ./configure?

I tried two scenarios:
- slightly patched 4.6 (with more-or-less original ./configure file;
I'm saying "more-or-less" because of a bug in autotools that had to be
fixed, and the patches that were needed to compile Qt)
- latest CVS version with ./prepare, ./configure, ...

I also tried with wxWidgets:
- 2.8
- 2.9.4
- 2.9.5
and they all resulted in the same behaviour. I didn't try to change
the version of pango/cairo/anyotherlib.

> That should find the proper header files, but you may want to
> check that is in fact the case.

What exactly should I look for?

Mojca

Re: missing labels in wxt under Mac

[Daniel J S. <dan...@ie...>]

On 08/26/2012 09:20 AM, Mojca Miklavec wrote:
> Hello,
>
> I just realized that I don't get any labels with wxt terminal under
> Mac OS X (neither with 2.8 nor with 2.9.4). Is there any other mac
> user out there who ever tried to use wxt?
>
> It is possible that some recent library changes under MacPorts broke
> the functionality.

That would be my guess judging from what you've reported.  I've little 
knowledge of MacPorts, but it appears that wxt is attempting to call all 
these global functions which then get lost somewhere or in some way.

You recompiled with a proper configuration from scratch, i.e., 
./prepare, ./configure?  That should find the proper header files, but 
you may want to check that is in fact the case.

Dan


>  I have no idea what exactly is going on. If I try
> to change the font, it crashes with
>
> (process:3664): GLib-GObject-CRITICAL **: g_object_ref: assertion
> `G_IS_OBJECT (object)' failed
>
> (process:3664): GLib-GObject-CRITICAL **: g_object_get_qdata:
> assertion `G_IS_OBJECT (object)' failed
>
> (process:3664): GLib-GObject-CRITICAL **: g_object_set_qdata_full:
> assertion `G_IS_OBJECT (object)' failed
>
> (process:3664): Pango-CRITICAL **: void
> pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
> gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed
>
> (process:3664): Pango-CRITICAL **: void
> pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
> gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed
>
> (process:3664): Pango-CRITICAL **: void
> pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
> gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed
>
> (process:3664): Pango-CRITICAL **: void
> pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
> gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed
>
> (process:3664): Pango-CRITICAL **: void
> pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
> gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed
>
> (process:3664): Pango-CRITICAL **: void
> pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
> gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed
>
> (process:3664): Pango-CRITICAL **: void
> pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
> gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed
>
> (process:3664): Pango-CRITICAL **: void
> pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
> gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed
>
> (process:3664): Pango-CRITICAL **: void
> pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
> gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed
>
> (process:3664): Pango-CRITICAL **: void
> pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
> gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed
>
> (process:3664): Pango-CRITICAL **: void
> pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
> gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed
>
> (process:3664): Pango-WARNING **: failed to choose a font, expect ugly
> output. engine-type='PangoRenderCoreText', script='common'
>
> (process:3664): GLib-GObject-CRITICAL **: g_object_ref: assertion
> `G_IS_OBJECT (object)' failed
>
> (process:3664): Pango-WARNING **: couldn't load font "Lucida
> Not-Rotated 320", modified variant/weight/stretch as fallback, expect
> ugly output.
>
> (process:3664): GLib-GObject-CRITICAL **: g_object_ref: assertion
> `G_IS_OBJECT (object)' failed
>
> (process:3664): Pango-ERROR **: Could not load fallback font, bailing out.
> Trace/BPT trap: 5
>
> Does anyone have any idea what could be going on?
>
> Mojca
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: Out of Date bug for Qt terminal

[Daniel J S. <dan...@ie...>]

Thanks Mojca.  I relayed the thread link early this past weekend but 
haven't heard anything.  However, it looks like the information that 
someone was requesting.

Dan


On 08/25/2012 06:27 AM, Mojca Miklavec wrote:
> On Sat, Aug 25, 2012 at 6:31 AM, Daniel J Sebald wrote:
>> Mojca,
>>
>> Some others are experiencing bugs similar to what you report here:
>>
>> http://sourceforge.net/tracker/index.php?func=detail&aid=3469233&group_id=2055&atid=102055
>>
>> Why was this bug listed as "out of date"?
>
> I'm not sure why it was listed as "out of date" exactly, that's a
> question for Ethan, but that was on 11th January, 6 days before a
> major patch has been applied by Jérôme:
>
> 2012-01-17  Jérôme Lodewyck
>
>    * configure.in src/Makefile.am src/qtterminal/Makefile.am
>    src/qtterminal/QtGnuplotApplication.cpp
>    src/qtterminal/QtGnuplotApplication.h src/qtterminal/QtGnuplotEvent.cpp
>    src/qtterminal/QtGnuplotEvent.h src/qtterminal/gnuplot_qt.cpp
>    src/qtterminal/qt_term.cpp term/qt.trm: The Qt terminal application is
>    executed in a separate executable called gnuplot_qt, started by exec.
>    This makes the Qt terminal compatible with OS X.
>
> https://github.com/gnuplot/gnuplot/commit/a98002601bf690d0c37c47a7948c53a2096c20de
>
> It left some issues (like: Mac now sees two executables instead of one
> and draws both on dock, but one gets hidden afterwards; printing
> crashes). Some further trivial compilation issues which finally
> enabled compilation on Mac have been fixed after 4.6 release with
> commit on "2012-06-23 Jérôme lodewyck".
>
> https://github.com/gnuplot/gnuplot/commit/1da6c54924c275189a5954eeed8bb38e305b780f
>
> That second patch has not yet been imported into branch-4-6-stable (I
> really hope that they will end up in 4.6.1).
>
>> Did it resolve on its own, or is
>> this simply a case of having a fork in the process and the
>> debugger/compile-with-debug-code is unable to handle a fork.
>
> No, it was actually crashing and useless, it wasn't just about
> debugger. It didn't resolve on its own, it was the two patches listed
> above that made Qt usable on Mac. All in all, after end of june that
> bug report has actually been resolved, so there's no need to worry
> about it any more. It's just the ticket that has been closed "in
> advance" ;)
>
> Mojca
>
> (PS: I still believe that there must be a way to completely avoid fork
> on Mac, but I'm not experienced enough to figure it out how.)
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

missing labels in wxt under Mac

[Mojca M. <moj...@gm...>]

Hello,

I just realized that I don't get any labels with wxt terminal under
Mac OS X (neither with 2.8 nor with 2.9.4). Is there any other mac
user out there who ever tried to use wxt?

It is possible that some recent library changes under MacPorts broke
the functionality. I have no idea what exactly is going on. If I try
to change the font, it crashes with

(process:3664): GLib-GObject-CRITICAL **: g_object_ref: assertion
`G_IS_OBJECT (object)' failed

(process:3664): GLib-GObject-CRITICAL **: g_object_get_qdata:
assertion `G_IS_OBJECT (object)' failed

(process:3664): GLib-GObject-CRITICAL **: g_object_set_qdata_full:
assertion `G_IS_OBJECT (object)' failed

(process:3664): Pango-CRITICAL **: void
pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed

(process:3664): Pango-CRITICAL **: void
pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed

(process:3664): Pango-CRITICAL **: void
pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed

(process:3664): Pango-CRITICAL **: void
pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed

(process:3664): Pango-CRITICAL **: void
pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed

(process:3664): Pango-CRITICAL **: void
pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed

(process:3664): Pango-CRITICAL **: void
pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed

(process:3664): Pango-CRITICAL **: void
pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed

(process:3664): Pango-CRITICAL **: void
pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed

(process:3664): Pango-CRITICAL **: void
pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed

(process:3664): Pango-CRITICAL **: void
pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed

(process:3664): Pango-WARNING **: failed to choose a font, expect ugly
output. engine-type='PangoRenderCoreText', script='common'

(process:3664): GLib-GObject-CRITICAL **: g_object_ref: assertion
`G_IS_OBJECT (object)' failed

(process:3664): Pango-WARNING **: couldn't load font "Lucida
Not-Rotated 320", modified variant/weight/stretch as fallback, expect
ugly output.

(process:3664): GLib-GObject-CRITICAL **: g_object_ref: assertion
`G_IS_OBJECT (object)' failed

(process:3664): Pango-ERROR **: Could not load fallback font, bailing out.
Trace/BPT trap: 5

Does anyone have any idea what could be going on?

Mojca

Re: Out of Date bug for Qt terminal

[Mojca M. <moj...@gm...>]

On Sat, Aug 25, 2012 at 6:31 AM, Daniel J Sebald wrote:
> Mojca,
>
> Some others are experiencing bugs similar to what you report here:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=3469233&group_id=2055&atid=102055
>
> Why was this bug listed as "out of date"?

I'm not sure why it was listed as "out of date" exactly, that's a
question for Ethan, but that was on 11th January, 6 days before a
major patch has been applied by Jérôme:

2012-01-17  Jérôme Lodewyck

  * configure.in src/Makefile.am src/qtterminal/Makefile.am
  src/qtterminal/QtGnuplotApplication.cpp
  src/qtterminal/QtGnuplotApplication.h src/qtterminal/QtGnuplotEvent.cpp
  src/qtterminal/QtGnuplotEvent.h src/qtterminal/gnuplot_qt.cpp
  src/qtterminal/qt_term.cpp term/qt.trm: The Qt terminal application is
  executed in a separate executable called gnuplot_qt, started by exec.
  This makes the Qt terminal compatible with OS X.

https://github.com/gnuplot/gnuplot/commit/a98002601bf690d0c37c47a7948c53a2096c20de

It left some issues (like: Mac now sees two executables instead of one
and draws both on dock, but one gets hidden afterwards; printing
crashes). Some further trivial compilation issues which finally
enabled compilation on Mac have been fixed after 4.6 release with
commit on "2012-06-23 Jérôme lodewyck".

https://github.com/gnuplot/gnuplot/commit/1da6c54924c275189a5954eeed8bb38e305b780f

That second patch has not yet been imported into branch-4-6-stable (I
really hope that they will end up in 4.6.1).

> Did it resolve on its own, or is
> this simply a case of having a fork in the process and the
> debugger/compile-with-debug-code is unable to handle a fork.

No, it was actually crashing and useless, it wasn't just about
debugger. It didn't resolve on its own, it was the two patches listed
above that made Qt usable on Mac. All in all, after end of june that
bug report has actually been resolved, so there's no need to worry
about it any more. It's just the ticket that has been closed "in
advance" ;)

Mojca

(PS: I still believe that there must be a way to completely avoid fork
on Mac, but I'm not experienced enough to figure it out how.)

Out of Date bug for Qt terminal

[Daniel J S. <dan...@ie...>]

Mojca,

Some others are experiencing bugs similar to what you report here:

http://sourceforge.net/tracker/index.php?func=detail&aid=3469233&group_id=2055&atid=102055

Why was this bug listed as "out of date"?  Did it resolve on its own, or 
is this simply a case of having a fork in the process and the 
debugger/compile-with-debug-code is unable to handle a fork.  (I can see 
why it would find that tricky.  Notice the error messages says use 
ecec() which I'm sure is an easier thing for a debugger to do because it 
is like starting an additional session from scratch.)

Thank you,

Dan

Re: Qt terminal status / linux distro packages

[Daniel J S. <dan...@ie...>]

On 08/22/2012 01:38 PM, Ethan A Merritt wrote:
> On Wednesday, August 22, 2012 11:28:09 am Daniel J Sebald wrote:
>> On 08/22/2012 12:56 PM, Daniel J Sebald wrote:
>>
>>> I don't know if leaving out the X11 terminal is a good idea.  At least
>>> one of the apps I know of will choose "x11" if the user doesn't set an
>>> environment variable specifying an alternative gnuplot terminal.  So, if
>>> the distro creators leave out x11 that will cause problems in at least
>>> this case.
>>
>> I should say that, as well, an app may want to have both x11 and qt, for
>> example.  A reasonable scenario is: run from the command line, x11, and
>> run from a UI, qt.
>>
>> I've done some compilations here to check sizes:
>>
>> gnuplot with x11 and qt: 3462231
>> gnuplot with x11, no qt: 3067584
>>
>> So, qt adds 13%.  That is a fairly big addition if qt isn't used.  For
>> the qt user though it isn't a concern because of the added support.
>

>> gnuplot with qt, no x11: (I don't see a way to disable x11 terminal)
>
>   ./configure --without-x

OK...

gnuplot with x11 and qt: 3462231
gnuplot with x11, no qt: 3067584
gnuplot with qt, no x11: 3415747

So x11 adds 1.4% approximately.  Not much.  (If I recall, the term just 
packages the commands slightly and sends them on their way to gnuplot_x11.)

> If you care about total size you should include the respective outboard drivers:
>
>     text    data     bss     dec     hex filename
> 1385735   72836   57408 1515979  1721cb gnuplot     # includes x11 + wxt + qt
>    91517    4788   12704  109009   1a9d1 gnuplot_x11
>   141992    2120     744  144856   235d8 gnuplot_qt

I'm discounting that because if I build with qt and run gnuplot, 
gnuplot_x11 outboard driver doesn't appear.  Actually, qt is a little 
nicer along those lines because gnuplot_qt doesn't appear in the process 
list until an actual plot is done even though the qt terminal is set. 
On the other hand, gnuplot_x11 appears without having yet done a plot. 
It would be nice to change that, but even as is I think including X11 in 
any case isn't a concern.

Dan