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

Re: wxWidgets terminal : locale "C" ?

[<tim...@en...>]

Petr Mikulik wrote:

>> gnuplot> set xr[-6,56788793103:4,12176724138]; set
>> yr[-4,97885835095:3,73150105708]; set x2r[-6,56789: 4,12177]; set
>> y2r[-4,97886: 3,73150]
>>                            ^
>>         ':' or keyword 'to' expected
>
>
> I think this has been already fixed -- it does not happen for my cs_CZ
> locale.

Indeed, it was a problem caused by wxwidgets, in my patched gnuplot only.

>
>> P.S. : by the way, I realised that the "coords to clipboard with 2*<B1=
>"
>> doesn't work with the x11 terminal. Is it normal ?
>
>
> Copying to xterm, nedit, gedit works.
>
> Copying to anything using Qt (thus, any Qt/KDE application) does not
> work.
> How can this be allowed?

You're right, I was pasting to Konsole... but unfortunately I can't help
you to allow this in Qt. (In my wxwidgets terminal, I use the clipboard
object, and it just works)

Greetings,

Timoth=E9e Lecomte

Re: wxWidgets terminal : locale "C" ?

[<tim...@en...>]

Ethan A Merritt wrote:

>The patch changed gnuplot's scanner routine to accept
>commas as part of a number.  That is necessary if the user
>has used "set decimalsign locale", because in this case numbers
>belonging to a gnuplot command line are interpreted according
>to the current LOCALE_NUMERIC.
>
>(...)
>
>Perhaps a better way is to force LC_NUMERIC to C during the
>scanning of a gnuplot input line.  That means all numbers on a
>gnuplot command line must use dot rather than comma as a=20
>decimal sign.  Then to fix the original bug report, any code
>that *constructs* a gnuplot command line, must *also* set
>LC_NUMERIC to C while it operates.
>That would include both the built-in functions like zoom and the
>interpretation of key bindings.
>
>Let's have some input from people using a locale with a comma
>for LC_NUMERIC.  Should gnuplot command line syntax be affected
>by LC_NUMERIC, or not?
>
Thanks for your deep investigation !

I finally found that the original bug was *my* problem. In fact, current
cvs is not broken and in particular x11 terminal works properly on my
"french box". It was a problem of my wxwidgets terminal : the wxwidgets
library uses GTK+, which changes the locale itself, so that the default
locale "C" was changed to "fr_FR". I have added setlocale(LC_NUMERIC,
"C"); to my code, where the locale was changed.

I agree that the command line syntax should not be affected by
LC_NUMERIC, and so should always require a dot as a decimal sign.
However, the way numbers are written in the terminal output might be
tweaked with an option.

Greetings,

Timoth=C3=A9e Lecomte

Re: How about a fresh release ?

[Hans-Bernhard B. <br...@ph...>]

Timoth=E9e Lecomte wrote:
> I was wondering if it wasn't the good moment to do a fresh release of
> gnuplot, I mean "gnuplot 4.1".

I think it's way too early for that.  Worse yet, I'd have to be the one=20
to do it, and I don't see where I could steal the time for that right=20
now.  Last time took about us 6 weeks of preparation, the last two of=20
them nearly full-time on my end of things.  People have got used to a
"release early --- release often" strategy.  Sorry, but with the=20
licensing issues as they are, that's a non-option for gnuplot.

That set aside, I don't think the code currently has the level of=20
maturity people rightfully expect from a release version of gnuplot.=20
There's way too much on-going activity on the 'adding features' front=20
for that.  We have to let the dust settle a bit before a release can be=20
considered in earnest.

The most we could usefully do right now is a general review of open=20
patches and feature requests, with a view towards making a three-way=20
decision for each and every one of them:

1) outdated ---> tag as such, and close.
2) keeper --> tag 'release-critical', integrate in good time, then close
3) later --> tag 'later', keep open

Re: patch MAX_NUM_VAR in version 4.0.0

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

> # define MAX_NUM_VAR    5
>
> in 'syscfg.h' e.g. to:
>
> # define MAX_NUM_VAR   10

I vote for this change .. maybe even to 12 (i.e., 4 vectors)?

---
PM

Re: wxWidgets terminal : locale "C" ?

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

> gnuplot> set xr[-6,56788793103:4,12176724138]; set
> yr[-4,97885835095:3,73150105708]; set x2r[-6,56789: 4,12177]; set
> y2r[-4,97886: 3,73150]
>                            ^
>         ':' or keyword 'to' expected

I think this has been already fixed -- it does not happen for my cs_CZ 
locale.

> P.S. : by the way, I realised that the "coords to clipboard with 2*<B1>"
> doesn't work with the x11 terminal. Is it normal ?

Copying to xterm, nedit, gedit works.

Copying to anything using Qt (thus, any Qt/KDE application) does not work.
How can this be allowed?

---
PM

Re: wxWidgets terminal : locale "C" ?

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

> This example shows quite nice that the parsing of the *script* file
> should never be locale dependend.  The decimal point is part of the
> script language specification.  It might be a feature to enable the
> possibility for data files with decimal commas.

I agree (locale cs_CZ.UTF-8): optionally allow "," via a set command only 
for data files and for output graphs.

---
PM

Re: wxWidgets terminal : locale "C" ?

[V. <gae...@no...>]

On Sat, Sep 17, 2005 at 09:18:28AM +0200, Juergen Wieferink wrote:
> This example shows quite nice that the parsing of the *script* file
> should never be locale dependend.  The decimal point is part of the
> script language specification.=20

    I totally do agree with this point. Especially a I am from a part of
the world in which the coma is the decimal separator, on paper. On
calculators, for instance, it is the full stop :".".

--
    Ga=EBl

Re: wxWidgets terminal : locale "C" ?

[Juergen W. <wie...@fr...>]

On Saturday 17 September 2005 03:07 Ethan A Merritt wrote:
> On the other hand this makes many gnuplot commands ambiguous
> at best:
>
> 	set label 1 offset 1,2
>
> I would have expected this to set the offset to (xoff=1 yoff=3 zoff=0)
> but now it instead sets (xoff=1,2 yoff=0 zoff=0).
> Is that acceptable?  Is it what a user would expect, if he has gone
> to the trouble of setting a decimalsign == comma locale?

My two pence:
This example shows quite nice that the parsing of the *script* file
should never be locale dependend.  The decimal point is part of the
script language specification.  It might be a feature to enable the
possibility for data files with decimal commas.


> But the current, unpatched, state of the code has problems also.
>   set decimalsign locale
>   show locale
>         LC_CTYPE is fr_FR
>         LC_NUMERIC is fr_FR
>         LC_TIME is C
>   PI = 3.14159
>   print PI
> 	3.0
>   print pi
> 	3,14159265358979
>
> That is both wrong, and puzzling.  I can understand why PI gets
> set to 3 on input - that's the effect of sscanf() or atod() with
> LC_NUMERIC set to fr_FR.  But why does it revert to a dot for the
> decimal sign on output? Notice that the internal constant "pi" is
> printed with a comma, as I would have expected.  Strange.

The ".0" is explicitly added to show it is a float, not an integer.
See show.c (num_to_str):

    if (strchr(s[j], '.') == NULL &&
#ifdef HAVE_LOCALE_H
	strchr(s[j], ',') == NULL &&
#endif
	strchr(s[j], 'e') == NULL &&
	strchr(s[j], 'E') == NULL)
	strcat(s[j], ".0");

> Perhaps a better way is to force LC_NUMERIC to C during the
> scanning of a gnuplot input line.  That means all numbers on a
> gnuplot command line must use dot rather than comma as a
> decimal sign.  Then to fix the original bug report, any code
> that *constructs* a gnuplot command line, must *also* set
> LC_NUMERIC to C while it operates.
> That would include both the built-in functions like zoom and the
> interpretation of key bindings.

ACK.


Juergen

Re: wxWidgets terminal : locale "C" ?

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

On Friday 16 September 2005 04:57 pm, Ethan Merritt wrote:
>
> Please try attached patch.
> Keep an eye open for unexpected side-effects.

The side-effects may outweigh the benefit.
I really don't know what the correct thing to do is here,
partly because I'm from part of the world that doesn't use
a comma for a decimal point.

The patch changed gnuplot's scanner routine to accept
commas as part of a number.  That is necessary if the user
has used "set decimalsign locale", because in this case numbers
belonging to a gnuplot command line are interpreted according
to the current LOCALE_NUMERIC.

On the other hand this makes many gnuplot commands ambiguous
at best:

	set label 1 offset 1,2

I would have expected this to set the offset to (xoff=1 yoff=3 zoff=0)
but now it instead sets (xoff=1,2 yoff=0 zoff=0).
Is that acceptable?  Is it what a user would expect, if he has gone
to the trouble of setting a decimalsign == comma locale?

But the current, unpatched, state of the code has problems also.
  set decimalsign locale
  show locale
        LC_CTYPE is fr_FR
        LC_NUMERIC is fr_FR
        LC_TIME is C
  PI = 3.14159
  print PI
	3.0
  print pi
	3,14159265358979

That is both wrong, and puzzling.  I can understand why PI gets
set to 3 on input - that's the effect of sscanf() or atod() with
LC_NUMERIC set to fr_FR.  But why does it revert to a dot for the
decimal sign on output? Notice that the internal constant "pi" is
printed with a comma, as I would have expected.  Strange.

Anyhow, while I can see some attraction to being able to type
contants into gnuplot using a locale-modified decimal sign, e.g.
  PI = 3,14159
I suspect that it breaks too many other commands.

Perhaps a better way is to force LC_NUMERIC to C during the
scanning of a gnuplot input line.  That means all numbers on a
gnuplot command line must use dot rather than comma as a 
decimal sign.  Then to fix the original bug report, any code
that *constructs* a gnuplot command line, must *also* set
LC_NUMERIC to C while it operates.
That would include both the built-in functions like zoom and the
interpretation of key bindings.

Let's have some input from people using a locale with a comma
for LC_NUMERIC.  Should gnuplot command line syntax be affected
by LC_NUMERIC, or not?

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

Re: wxWidgets terminal : locale "C" ?

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

On Friday 16 September 2005 02:33 pm, Timoth=E9e Lecomte wrote:
> >
> It's my error : I meant "set decimalsign {locale {locale_set}}". This
> command doesn't seem to affect the behaviour of the X11 terminal.
>=20
> My computer's locale os "fr_FR". The locale decimal sign is "," and x11
> terminal seems to use it as it draws coords with it. But it gives an
> error when zooming, as a comma is rejected by the parser...
>=20
> I get :
>=20
> gnuplot> set xr[-6,56788793103:4,12176724138]; set
>                             ^
>          ':' or keyword 'to' expected


Please try attached patch.
Keep an eye open for unexpected side-effects.

	Ethan



=2D-=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Bugs in new key placement code

[<ds...@ch...>]

Ethan,

I'm away on business for a month.  I'll try looking at this over a weekend.

Thanks,

Dan


> 
> From: Ethan Merritt <merritt@u.washington.edu>
> Date: 2005/09/16 Fri PM 04:56:35 EDT
> To: <gnu...@li...>
> CC: Daniel J Sebald <dan...@ie...>
> Subject: Bugs in new key placement code
> 
> Try the following:
> 
>   set key box title "Foo"
>   splot 1,2,3,4,5
> 
> Everything is OK so far.  Now try:
> 
>   set key rmargin
>   replot
> 
> That's not what I expected, but let's proceed.
> 
>   set key tmargin
>   replot
> 
> Huh?  The box is no longer correct.
> 
>   set key lmargin
>   replot
> 
> Seems to be a no-op. Key is still broken.
> 
>   set key title "A much longer title"
>   replot
> 
> And now it's obvious that the title centering is not
> correct, either.
> 
> Now let's start again (2D this time)
> 
>   reset
>   set key box title "A much longer title"
>   plot 1,2,3,4,5
> 
> In 2D the title is centered, but the box is not adjusted
> to fit it.
> 
> -- 
> Ethan A Merritt       merritt@u.washington.edu
> Biomolecular Structure Center
> Mailstop 357742
> University of Washington, Seattle, WA 98195
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

How about a fresh release ?

[<tim...@en...>]

Hello !

I was wondering if it wasn't the good moment to do a fresh release of
gnuplot, I mean "gnuplot 4.1".

Very interesting features have been implemented, such as RGB color as a
linetype, which has sometimes be a source of complains in octave mailing
list for example. It's also the case of the new "image" plot style, as
well as the "vector" one. To continue with octave needs, I'm sure that
the new "set termoption <foo>" will be appreciated. The mouse always
enabled by default on x11 is also a important improvement, as many users
might have never discovered such a feature !

On the other hand, it could be a way to put a little more focus on
gnuplot. Users and scientists may be happy to learn that it's not dead
at all : I'm the first to lose my interest for a program when it doesn't
*appear* to be actively maintained. It's time to bring the new
functionnalities to all users who won't ever try to compile from cvs !

Greetings,

Timoth=E9e Lecomte

Re: wxWidgets terminal : locale "C" ?

[<tim...@en...>]

Ethan A Merritt wrote:

>I've been gone, and may have missed a resolution to this question.
>But in case not...
>
>On Thursday 25 August 2005 01:33 pm, Timoth=E9e Lecomte wrote:
> =20
>
>>I've seen this problem on my box too, which has locale fr_FR, with a
>>comma for the LC_numeric locale. However, I see the same problem with
>>the x11 terminal.
>>
>>And the command "set locale {locale {locale_set}}" doesn't seem to do
>>anything about it... What behaviour should I expect ?
>>   =20
>>
>
>The "set locale" command only affects LC_TIME.
>To change the locale of the decimal sign (LC_NUMERIC) you need to
>call "set decimalsign".
>
>Does that answer your question?=20
> =20
>
It's my error : I meant "set decimalsign {locale {locale_set}}". This
command doesn't seem to affect the behaviour of the X11 terminal.

My computer's locale os "fr_FR". The locale decimal sign is "," and x11
terminal seems to use it as it draws coords with it. But it gives an
error when zooming, as a comma is rejected by the parser...

I get :

gnuplot> set xr[-6,56788793103:4,12176724138]; set
yr[-4,97885835095:3,73150105708]; set x2r[-6,56789: 4,12177]; set
y2r[-4,97886: 3,73150]
                            ^
         ':' or keyword 'to' expected


Hope I'm clear enough ;-)

Timoth=E9e


P.S. : by the way, I realised that the "coords to clipboard with 2*<B1>"
doesn't work with the x11 terminal. Is it normal ?

Bugs in new key placement code

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

Try the following:

  set key box title "Foo"
  splot 1,2,3,4,5

Everything is OK so far.  Now try:

  set key rmargin
  replot

That's not what I expected, but let's proceed.

  set key tmargin
  replot

Huh?  The box is no longer correct.

  set key lmargin
  replot

Seems to be a no-op. Key is still broken.

  set key title "A much longer title"
  replot

And now it's obvious that the title centering is not
correct, either.

Now let's start again (2D this time)

  reset
  set key box title "A much longer title"
  plot 1,2,3,4,5

In 2D the title is centered, but the box is not adjusted
to fit it.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: About cygwin compilation

[Hans-Bernhard B. <br...@ph...>]

Salvatore Lionetti wrote:
> I see that if you copy gd{,_io,fx}.h, in
> gnuplot-4.0.0/src, then one can successfully install
> gnuplot under cygwin.

If *that* makes a difference, it means you don't actually have a working 
gd installation for the part of cygwin you're compiling gnuplot with.

A gd package installed for the real cygwin will not (and should not) be 
found by makefile.cyg.   A gd package installed for the -mno-cygwin 
subsystem will not (and should not) be found by ./configure.

About cygwin compilation

[Salvatore L. <sal...@ya...>]

Hi,
my name is Salvatore Lionetti.
I use cygwin (setup.exe has version 2.510.2.2) amd
i've installed 2 src:
1) octave, (./configure,make,make install) OK.
2) gnuplot (./configure, make) FAIL.

I see that if you copy gd{,_io,fx}.h, in
gnuplot-4.0.0/src, then one can successfully install
gnuplot under cygwin.
(instead coping, a more clean solution can be to make
a simbolink link to real include files)

Here the details:
after see INSTALL file, i try:
   cd src/
   cp ../config/makefile.cyg .
   make -f makefile.cyg.
But i have 2 main error:
1) gd.h, gd_io.h, gdfx.h does !exist in -I,.,
   that cause million of compiler error.
   SOL1: put -I/include that have this & other file
         but have many conflict.
   SOL2: copy only this 3 .h in src/
         This go ok but
2) linker error: some symbol !resolved, see vedi.txt.
   SOL1: I see that many symbol are dll related
         , cause have _imp_, and try to give it
         many version of gd library in several
         way, but without success.

So i try to do the simplest thing, alias
   cd gnuplot-4.0.0
   ./configure
   make
   make install
that go OK, because using this way the only obstacle
are the tree include reported above.




  
   


	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

plot perspective

[William E. <mru...@po...>]

Hi Guys,

  How can I make gnuplot produce a 3D plot with true prespective.  By 
that I mean that X, Y and Z
all relate to each other.  The scale of X, Y and Z are the same.  A 
picture is worth more that me
explaining.

  This is what gnuplot produced: 

    http://mt-umunhum-wireless.net/Images/Gnuplot_1.png


  If I expand the image wide, I get what look better:

    http://mt-umunhum-wireless.net/Images/Gnuplot_2.png

  What I want is for gunplot to produce the second image with the right 
perspective.

  Thanks for you time.

-- 
  William Estrada 
<HTTP://www.Mt-Umunhum-Wireless.net/resume/william_estrada.html>    --  
MrUmunhum at popdial dot com <mailto:MrU...@po...>  --   
408-997-0743
  Ymessenger ID: MrUmunhum
  HTTP://Mt-Umunhum-Wireless.net

Re: wxWidgets terminal : locale "C" ?

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

I've been gone, and may have missed a resolution to this question.
But in case not...

On Thursday 25 August 2005 01:33 pm, Timoth=E9e Lecomte wrote:
>
> I've seen this problem on my box too, which has locale fr_FR, with a
> comma for the LC_numeric locale. However, I see the same problem with
> the x11 terminal.
>
> And the command "set locale {locale {locale_set}}" doesn't seem to do
> anything about it... What behaviour should I expect ?

The "set locale" command only affects LC_TIME.
To change the locale of the decimal sign (LC_NUMERIC) you need to
call "set decimalsign".

Does that answer your question?=20

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: SF patch #1040192

[Lars H. <lhe...@us...>]

Harald Harders writes:
> Lars,
> 
> > | 2005-02-09  Harald Harders  <h.h...@tu...>
> > |
> > |         SourceForge patch #1040192 "Merge post, epslatex, pslatex, pstex
> > |         terminals".
> > ...
> > |         * share/: New directory.
> > |
> > |         * share/LaTeX/Makefile share/LaTeX/README share/LaTeX/gnuplot.cfg:
> > |         New directory LaTeX/. New files for supporting the epslatex terminal.

 HBB and I have finally fixed "make distcheck". The downside is that
 share/LaTeX/gnuplot.cfg does not get installed into the LaTeX hierarchy,
 this needs to be done by a privileged user.

 The documentation needs to mention this. Any takers?

Re: SF patch #1040192

[Lars H. <lhe...@us...>]

> I like the idea of a new structure
>   share/LaTeX
>   share/pm3d
>   share/lisp
> instead of top-level directories. And I agree that it was nonsense if the
> other directories are not moved there, too.
 
 I may actually get around to that in a while ...

 In the meantime, please note that additional directories require a good
 bit of automake work to make sure that

 - "make dist" works
 - a distribution built with "make dist" contains all required files
 - building outside the source directory works

 I just spent some time to repair all this.

windows binary

[Johannes Z. <joh...@ze...>]

Hello,

can someone provide a recent windows binary? (new enough to have
the pm3d option "corners2color min|max")
Thanks.

-- 
Johannes

Re: Stuck with compiling 4.1 on windows (again)

[Hans-Bernhard B. <br...@ph...>]

Bastian Maerkisch wrote:
> Hans-Bernhard Broeker wrote:
>  > Marko Brandes wrote:
>  >
>  >> - copy ..\config\config.nt ..\src\config.h
>  >
>  >
>  > That still looks strange.  One of those ..\ should be superfluous.
>  >
>  > It's no longer really needed, either --- makefile.nt now makes the copy
>  > itself, if you didn't.
> 
> Hhm. It looks like it really should, but it doesn't do so on my system.

Comparing makefile.nt (which I can't really debug, because I never had 
MSVC) and makefile.oww (which I derived from the former), I find one 
important difference that might explain both this, and the original 
problem with nmake not building anything even *after* copying config.h, 
even though it doesn't so much as hint at why this issue is coming up 
only *now* --- makefile.nt has changed only very little over time. 
Could NMAKE have been modified behind our backs?  Gentlemen, please 
report your nmake versions.

The issue is that there's no manifest information about dependencies in 
makefile.nt (nor in any files it includes).  I had to put this rule in 
makefile.oww:

$(OBJS): config.h .AUTODEPEND

This achieves two things:

1) it causes OpenWatcom's make program to automatically compute 
dependencies for all the main .obj files that gnuplot consists of, 
thanks to the .AUTODEPEND tag.

2) it declares every single one of them as dependent on config.h, so 
wmake will try to build config.h, and thus execute the copy rule if 
there's no config.h in sight.

Someone who has nmake and its documentation will have to duplicate this 
for makefile.nt.

Re: SF patch #1040192

[Harald H. <h.h...@tu...>]

Lars,

> | 2005-02-09  Harald Harders  <h.h...@tu...>
> |
> |         SourceForge patch #1040192 "Merge post, epslatex, pslatex, pstex
> |         terminals".
> ...
> |         * share/: New directory.
> |
> |         * share/LaTeX/Makefile share/LaTeX/README share/LaTeX/gnuplot.cfg:
> |         New directory LaTeX/. New files for supporting the epslatex terminal.
>
>  I have very strong feelings against the creation of a whole new subdirectory
>  structure for one new file. Can you thing of any other approriate locations
>  outside share/ ? I missed the original cvs submit as my SF forward was broken
>  for a week or so.

There has been a discussion where to put the LaTeX stuff. Our idea was to
move all platform-independent things into the new share directory. This
directory structure was an idea of Petr on 2005-01-27 in patch
#1040192. The new structure would mean that, for example, also the "lisp"
and "pm3d" directories could move into this directory. This would decrease
the number of top-level directories.

I like the idea of a new structure
  share/LaTeX
  share/pm3d
  share/lisp
instead of top-level directories. And I agree that it was nonsense if the
other directories are not moved there, too.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Stuck with compiling 4.1 on windows (again)

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

Hans-Bernhard Broeker wrote:
 > Marko Brandes wrote:
 >
 >> - copy ..\config\config.nt ..\src\config.h
 >
 >
 > That still looks strange.  One of those ..\ should be superfluous.
 >
 > It's no longer really needed, either --- makefile.nt now makes the cop=
y
 > itself, if you didn't.

Hhm. It looks like it really should, but it doesn't do so on my system.
I always have to do =B4nmake -f makefile.nt config.h=B4 first.

--=20
Bastian M=E4rkisch

Re: config.nt (was: Stuck with compiling 4.1 on windows (again))

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

> Indeed. Config.nt and makefile.nt haven't been updated to reflect recent
> features yet. E.g. GP_MACROS, WITH_IMAGE, GP_STRING_VARS, BINARY_DATA_FILE
> etc. are missing as well.

Update config.nt in the same way as config.mgw, .cyg, .os2.

---
PM