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

Re: non-interactive usage and color error messages

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

> > > > It is neither nice or useful when gnuplot is writing error message such as:
> > > > 
> > > > Error: terminal "dumb" does not support continuous colors.
> > > > This terminal does not support palette-based images.
> > > > This terminal does not support rgb images.
> > > > This terminal does not support filled polygons.
> > > > 
> > > > when in non-interactive mode (e.g. driven via Octave). They are actually 
> > > > just warnings, not errors.
> > >
> > > Every message that is generated by 
> > >   fprintf(stderr,ERROR_NOTICE(foo))
> > > should be changed to use int_warn() instead.
> > 
> > Good idea. These ERROR_NOTICEs are actually warnings only, not errors. I've 
> > tried to patch this replacement in color.c and graphics.c, it works fine.
> 
> I am inclined to agree that warning "this terminal does not support..."
> is not very useful.  Maybe we should jusr remove these altogether.

I see you have removed the message from color. I think it is OK and I agree 
all these messages can be removed (graphics.c). You can change to comment 
only, i.e.fprintf(...) => /* This terminal does not support palette-based 
images. */

> > Constructions with ERROR_NOTICE are found also in gplt_x11.c. It seems to me 
> > that they serve for reporting problems with ipc communication, so they 
> > should "never" happen. 
> 
> I have actually seen these trigger, and used them to debug problems with the 
> x11 terminal.  Of course, that's probably only useful for developers.  
> So maybe these should be wrapped in #if (DEBUG) ... #endif ?

Yes, this wrapping would be enough.

---
PM

Re: Windows Help program (WinHlp32.exe) for Windows 7

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

Tatsuro MATSUOKA wrote:

> From windows Vista, WinHlp32.exe is required to display 32-bit Help files that have the ".hlp" file
> name extension. The help file for gnuplot for windows is prepared in the ".hlp" format.  So
> WinHLP32.exe is required for windows Vista.  

> I have confirmed that WinHlp32.exe is prepared also for Windows 7.

In other words, the coming of Windows 7 hasn't changed the situation 
regarding 32-bit Windows help files in any way, except that there's a 
non-negligible chance that many people and organizations who have been 
sticking with XP because of Vista being, well ... Vista, will now update.

But gnuplot is not terribly likely to be the only, or even the first 
program such people encounter this Microsoft nonsense with.  In all the 
years PCs have been shipping with Vista now, I don't recall any 
significant number of questions about people lacking WinHlp32.  Guess 
they all fixed Microsoft's mistake before they ever got round to 
installing gnuplot...

> In the Readme of next version (4.4) for the windows distribution , is it better to add description of
> WinHlp32.wxe ?

A note might not hurt.

Re: non-interactive usage and color error messages

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

On Saturday 24 October 2009, Petr Mikulik wrote:
> > > It is neither nice or useful when gnuplot is writing error message such as:
> > > 
> > > Error: terminal "dumb" does not support continuous colors.
> > > This terminal does not support palette-based images.
> > > This terminal does not support rgb images.
> > > This terminal does not support filled polygons.
> > > 
> > > when in non-interactive mode (e.g. driven via Octave). They are actually 
> > > just warnings, not errors.
> >
> > Every message that is generated by 
> >   fprintf(stderr,ERROR_NOTICE(foo))
> > should be changed to use int_warn() instead.
> 
> Good idea. These ERROR_NOTICEs are actually warnings only, not errors. I've 
> tried to patch this replacement in color.c and graphics.c, it works fine.

I am inclined to agree that warning "this terminal does not support..."
is not very useful.  Maybe we should jusr remove these altogether.

> Constructions with ERROR_NOTICE are found also in gplt_x11.c. It seems to me 
> that they serve for reporting problems with ipc communication, so they 
> should "never" happen. 

I have actually seen these trigger, and used them to debug problems with the 
x11 terminal.  Of course, that's probably only useful for developers.  
So maybe these should be wrapped in #if (DEBUG) ... #endif ?

Re: non-interactive usage and color error messages

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

> > It is neither nice or useful when gnuplot is writing error message such as:
> > 
> > Error: terminal "dumb" does not support continuous colors.
> > This terminal does not support palette-based images.
> > This terminal does not support rgb images.
> > This terminal does not support filled polygons.
> > 
> > when in non-interactive mode (e.g. driven via Octave). They are actually 
> > just warnings, not errors.
>
> Every message that is generated by 
>   fprintf(stderr,ERROR_NOTICE(foo))
> should be changed to use int_warn() instead.

Good idea. These ERROR_NOTICEs are actually warnings only, not errors. I've 
tried to patch this replacement in color.c and graphics.c, it works fine.

Constructions with ERROR_NOTICE are found also in gplt_x11.c. It seems to me 
that they serve for reporting problems with ipc communication, so they 
should "never" happen. The int_warn() construct cannot be used in gplt_x11.

The (interactive) mode is off also for the load command, where the messages 
can be useful.


Well, I came to this problem when testing the "dumb" terminal from within 
Octave (ssh without x11). Then every plot was entitled 
    Error: terminal "dumb" does not support continuous colors.
I want to get rid of that annoying message in this terminal - the dumb 
terminal is too dumb for this message :-)

Thus I propose to add
  if (strcmp(term->name,"dumb"))
before these warnings in graphics.c:
  int_warn "terminal ... does not support continuous colors.",term->name;
  int_warn "terminal ... does not support palette-based images.",term->name;
  int_warn "terminal ... does not support rgb images.",term->name;

Further, there is:
  int_error(NO_CARET, "This terminal does not support filled polygons");
I think that this should be changed to
  int_warn "terminal ... does not support filled polygons.",term->name;
with the same if ("dumb").

All other screen/interactive terminals implement all of these functions so 
the message never appears for them.

> Or maybe we could add a command line option
>    gnuplot -nowarnings
> and/or an internal command
>    unset warnings

Yes, this may be interesting. There are indeed languages where you can set 
warnings on and off.

---
PM

Windows Help program (WinHlp32.exe) for Windows 7

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

Hello

>From windows Vista, WinHlp32.exe is required to display 32-bit Help files that have the ".hlp" file
name extension. The help file for gnuplot for windows is prepared in the ".hlp" format.  So
WinHLP32.exe is required for windows Vista.  

Recently Windows 7 has been sold. (I have still been using windows XP. :-( )  
I have been worried about WinHlp32.exe being available on windows 7 and searched by Google.
 
I have confirmed that WinHlp32.exe is prepared also for Windows 7.

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=258aa5ec-e3d9-4228-8844-008e02b32a2c

At least the Windows 7, '.hlp' can be used as a help file of gnuplot.

In the Readme of next version (4.4) for the windows distribution , is it better to add description of
WinHlp32.wxe ?

Regards

Tatsuro 


--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

Re: non-interactive usage and color error messages

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

On Friday 23 October 2009 10:05:49 Petr Mikulik wrote:
> It is neither nice or useful when gnuplot is writing error message such as:
> 
> Error: terminal "dumb" does not support continuous colors.
> This terminal does not support palette-based images.
> This terminal does not support rgb images.
> This terminal does not support filled polygons.
> 
> when in non-interactive mode (e.g. driven via Octave). They are actually 
> just warnings, not errors.

Comments:

I'm not an Octave user, so maybe I am missing something.
Would that actually work?  Isn't an Octave session also interactive?

Every message that is generated by 
  fprintf(stderr,ERROR_NOTICE(foo))
should be changed to use int_warn() instead.
I think these were added by Dan Sebald at a time when he was not familiar
with the existing mechanisms and conventions.

Having done that, we could put the   "if (interactive) ..."
test in int_warn() and cover all of these messages in one go.

Or maybe we could add a command line option
   gnuplot -nowarnings
and/or an internal command
   unset warnings


> I propose to surround the respective code by
> 
> if (interactive)
>   ...error message...
> 
> What do you think? Are there any other messages that would deserve the same 
> care?


-- 
Ethan A Merritt

non-interactive usage and color error messages

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

It is neither nice or useful when gnuplot is writing error message such as:

Error: terminal "dumb" does not support continuous colors.
This terminal does not support palette-based images.
This terminal does not support rgb images.
This terminal does not support filled polygons.

when in non-interactive mode (e.g. driven via Octave). They are actually 
just warnings, not errors.

I propose to surround the respective code by

if (interactive)
  ...error message...

What do you think? Are there any other messages that would deserve the same 
care?

---
PM

Re: Send bug reports and ...

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

> >   Send bug reports and suggestions to <http://sourceforge.net/projects/gnuplot>
> > 
> > does no longer fit to 80 characters making it strange looking on many 
> > terminals. Thus, it should be changed. The following messages would fit into 
> > 80 characters:
> > 
> > 1. 
> >   The gnuplot FAQ is available from http://www.gnuplot.info/faq/
> >   ...
> >   Report bugs and suggestions to http://sf.net/projects/gnuplot
> > 
> > 2.
> >   The gnuplot FAQ is available from www.gnuplot.info/faq/
> >   ...
> >   Report bugs and suggestions to www.sourceforge.net/projects/gnuplot
> > 
> > 
> > I would vote for 2.
> > Any ideas?
> 
> I have simplified the start message further. Is it OK?
> 
> stonelion [132] ./gnuplot
> 
>         G N U P L O T
>         Version 4.3 patchlevel CVS-06Oct2009
>         last modified Tue Oct  6 20:44:40 PDT 2009
>         System: Linux 2.6.29.6-desktop-1mnb
> 
>         Copyright (C) 1986-1993, 1998, 2004, 2007-2009
>         Thomas Williams, Colin Kelley, and many others
> 
>         immediate help:  type "help"
>         gnuplot FAQ:     http://www.gnuplot.info/faq/
>         report bugs:     http://sf.net/projects/gnuplot/support

That's fine, and I propose to add gnuplot homepage as well, thus:

         immediate help:  type "help"
         gnuplot home:    http://www.gnuplot.info
         gnuplot FAQ:     http://www.gnuplot.info/faq
         report bugs:     http://sf.net/projects/gnuplot/support

---
PM

Re: MSWin issues holding up 4.4.rc1

[Benjamin L. <lin...@gm...>]

Tait wrote:
> Ethan Merritt <merritt_u.washington.edu> said (on 2009/10/07):
>> This is a plea for assistance with serveral windows-specific bugs
>> still marked "open" on the bug tracker.
>> ...
>>    Bug #
>>  2848002   Ctrl+C crashes windows console build
>>  2807154   On Vista x64 plot keeps redrawing
>>  1952364   Windows driver draws points with dashed lines
>>  1952287   Windows driver draws dashed border for rectangles
>>  1609845   quota limits pipe size in pgnuplot
> 
> I'd love to help out with this, since I use gnuplot on Windows a lot, but
> I still haven't been able to get the sources to build (using mingw). If
> someone has tips/tricks on getting gnuplot to build under mingw, please
> share them. If not, I'll clean up, start over, and try to post a log
> where I'm getting errors.
> 
> Tait


If you're interested, you can take a look at the patches and procedures 
I use for building gnuplot and its dependencies as plotting backend for 
octave. You can find the code at

https://octave.svn.sourceforge.net/svnroot/octave/trunk/octave-forge/admin/Windows/mingw32/tools/gnuplot

It's currently for the 4.3.0-2009-07-08 CVS snapshot.

benjamin

Re: MSWin issues holding up 4.4.rc1

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

Hello

Sorry for my delaying to write the tutorial because I'm busy in my university work now.

> Notably, "make install" fails:
> 	$ make install
> 	./doc2rtf ../docs/gnuplot.doc win/gnuplot.rtf
> 	# hcw -c -e win/wgnuplot.hpj
> 	mkdir -p /home/xxxxxxxx/install
> 	cp gnuplot.exe /home/xxxxxxxx/install/gnuplot.exe
> 	cp: cannot stat `gnuplot.exe': No such file or directory
> 	make: *** [install] Error 1
> 
> This appears to be a minor issue, as pgnuplot.exe and wgnuplot.exe both
> exist.

If you would like to make gnuplot.exe, 'TARGET' in the makefile.mgw should be set as gnuplot.exe.  If
you would like to build all binaries; wgnuplot.exe, gnuplot.exe and wguplot_pipes.exe, you should
execute 'make' three times by changing the TARGET.
In my case, all TARGET is commented out in the makefile.mgw and set TARGET variable and make three
binaries as   

****************************
# make gnuplot.exe
cd /home/gnuplotcvs/gnuplot
echo TARGET=gnuplot.exe > target.txt
cat target.txt config/makefile.mgw > config/makefile.mgw.t
make clean -C src -f ../config/makefile.mgw.t; make -C src -f ../config/makefile.mgw.t

# make wgnuplot_pipes.exe
cd /home/gnuplotcvs/gnuplot
echo TARGET=wgnuplot_pipes.exe > target.txt
cat target.txt config/makefile.mgw > config/makefile.mgw.t
make clean -C src -f ../config/makefile.mgw.t; make -C src -f ../config/makefile.mgw.t

# make wgnuplot.exe
cd /home/gnuplotcvs/gnuplot
echo TARGET=wgnuplot.exe > target.txt
cat target.txt config/makefile.mgw> config/makefile.mgw.t
make clean -C src -f ../config/makefile.mgw.t; make -C src -f ../config/makefile.mgw.t
**************************
 However, a quick attempt at a png
> plot led to an application crash at offset 0x000a01ee. The exception
> was 0xc0000005. (SVG and PNG are probably the two most common formats I 
> use.) I'm not sure if this is a libgd issue, or what.
> 
> Debugging (outside of MS tools) is sorta new to me, so guidance and
> suggestions are welcome. This was the latest CVS that I checked out as
> of about 10 minutes before writing this email. 

Building the gd library requires grate care.   

Do you build your gd libraries dynamically ?

I am now using  dynamic libgd (2.0.36RC1) constructed with very trick hucks.

Basically it is safe to use statically build libgd libraries.
At the statically building, you should add 

#define NONDLL 1

at the very top of gd.h.

BTW, how did get libpng, libjpeg, freetype and zlib libraries?
>From GNUWIN32, GTK+ download for windows or build by yourself.

I am using the gd and cario related libraries downloaded from the GTK+ download for windows.
http://www.gtk.org/download-windows.html

These libraries enable us to make pngcairo and pdfcairo terminals.
However, the modification of a  header file of jpeg7 was required to build gd library.

I hope the above is useful for you.

Regards

Tatsuro  




--- Tait wrote:

> > > > I'd love to help out with this, since I use gnuplot on Windows a lot, but
> > > > I still haven't been able to get the sources to build (using mingw). If
> > > > someone has tips/tricks on getting gnuplot to build under mingw, please
> > > > share them. If not, I'll clean up, start over, and try to post a log
> > > > where I'm getting errors.
> > > > 
> > > OK
> > > Please give me some time to write tips and to upload the gd and wxWidget libraries built by
> myself.
> > > (Other dependency libraries are able to downloaded from the web site of GTK for windows.)
> > 
> > Did you manage to get mingw under control?
> > Are you still planning to have a look at the listed bug reports?
> 
> A little prod can do wonders for one's motivation sometimes... thanks
> Ethan!
> 
> I had sort of let this linger a bit long, so I finally got off my duff
> and had another go. After a lengthy process of beating libgd (2.0.35)
> into submission, I think I have managed to successfully compile gnuplot.
> I don't have HCW, so I just commented that command out of the makefile
> for the time being.
> 
> Notably, "make install" fails:
> 	$ make install
> 	./doc2rtf ../docs/gnuplot.doc win/gnuplot.rtf
> 	# hcw -c -e win/wgnuplot.hpj
> 	mkdir -p /home/xxxxxxxx/install
> 	cp gnuplot.exe /home/xxxxxxxx/install/gnuplot.exe
> 	cp: cannot stat `gnuplot.exe': No such file or directory
> 	make: *** [install] Error 1
> 
> This appears to be a minor issue, as pgnuplot.exe and wgnuplot.exe both
> exist. I ran wgnuplot.exe and was able to do a quick plot and splot. A
> quick svg plot seems to have worked. However, a quick attempt at a png
> plot led to an application crash at offset 0x000a01ee. The exception
> was 0xc0000005. (SVG and PNG are probably the two most common formats I 
> use.) I'm not sure if this is a libgd issue, or what.
> 
> Debugging (outside of MS tools) is sorta new to me, so guidance and
> suggestions are welcome. This was the latest CVS that I checked out as
> of about 10 minutes before writing this email.
> 
> Tait
> 
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

Re: MSWin issues holding up 4.4.rc1

[Tait <gnu...@t4...>]

> > > I'd love to help out with this, since I use gnuplot on Windows a lot, but
> > > I still haven't been able to get the sources to build (using mingw). If
> > > someone has tips/tricks on getting gnuplot to build under mingw, please
> > > share them. If not, I'll clean up, start over, and try to post a log
> > > where I'm getting errors.
> > > 
> > OK
> > Please give me some time to write tips and to upload the gd and wxWidget libraries built by myself.
> > (Other dependency libraries are able to downloaded from the web site of GTK for windows.)
> 
> Did you manage to get mingw under control?
> Are you still planning to have a look at the listed bug reports?

A little prod can do wonders for one's motivation sometimes... thanks
Ethan!

I had sort of let this linger a bit long, so I finally got off my duff
and had another go. After a lengthy process of beating libgd (2.0.35)
into submission, I think I have managed to successfully compile gnuplot.
I don't have HCW, so I just commented that command out of the makefile
for the time being.

Notably, "make install" fails:
	$ make install
	./doc2rtf ../docs/gnuplot.doc win/gnuplot.rtf
	# hcw -c -e win/wgnuplot.hpj
	mkdir -p /home/xxxxxxxx/install
	cp gnuplot.exe /home/xxxxxxxx/install/gnuplot.exe
	cp: cannot stat `gnuplot.exe': No such file or directory
	make: *** [install] Error 1

This appears to be a minor issue, as pgnuplot.exe and wgnuplot.exe both
exist. I ran wgnuplot.exe and was able to do a quick plot and splot. A
quick svg plot seems to have worked. However, a quick attempt at a png
plot led to an application crash at offset 0x000a01ee. The exception
was 0xc0000005. (SVG and PNG are probably the two most common formats I 
use.) I'm not sure if this is a libgd issue, or what.

Debugging (outside of MS tools) is sorta new to me, so guidance and
suggestions are welcome. This was the latest CVS that I checked out as
of about 10 minutes before writing this email.

Tait

Re: MSWin issues holding up 4.4.rc1

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

Hello

--- Tait  wrote:
> 
> I'd love to help out with this, since I use gnuplot on Windows a lot, but
> I still haven't been able to get the sources to build (using mingw). If
> someone has tips/tricks on getting gnuplot to build under mingw, please
> share them. If not, I'll clean up, start over, and try to post a log
> where I'm getting errors.
> 
OK
Please give me some time to write tips and to upload the gd and wxWidget libraries built by myself.
(Other dependency libraries are able to downloaded from the web site of GTK for windows.)

I will do it on my weekend job.

Regards

Tatsuro

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

Re: MSWin issues holding up 4.4.rc1

[Tait <gnu...@t4...>]

Ethan Merritt <merritt_u.washington.edu> said (on 2009/10/07):
> This is a plea for assistance with serveral windows-specific bugs
> still marked "open" on the bug tracker.
> ...
>    Bug #
>  2848002   Ctrl+C crashes windows console build
>  2807154   On Vista x64 plot keeps redrawing
>  1952364   Windows driver draws points with dashed lines
>  1952287   Windows driver draws dashed border for rectangles
>  1609845   quota limits pipe size in pgnuplot

I'd love to help out with this, since I use gnuplot on Windows a lot, but
I still haven't been able to get the sources to build (using mingw). If
someone has tips/tricks on getting gnuplot to build under mingw, please
share them. If not, I'll clean up, start over, and try to post a log
where I'm getting errors.

Tait

Re: MSWin issues holding up 4.4.rc1

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

--- Ethan Merritt <merritt@u.washington.edu> wrote:

> This is a plea for assistance with serveral windows-specific bugs
> still marked "open" on the bug tracker.
> 
> I was really hoping that we could resolve the major known glitches
> in the windows terminal before putting out a 4.4 release candidate.
> And in fact a couple of windows bugs were resolved over the summer
> (emf + enhanced text now works, kudos to Ben Lindner).
> 
> Unfortunately several other remain.
> 
>    Bug #
>  2848002   Ctrl+C crashes windows console build
This phenomena also occur on octave / mingw.  To my knowledge this comes limitation of cmd.exe and is
not easy to be avoided.


>  1609845   quota limits pipe size in pgnuplot
> 
> I very much suspect that the "quota limits" thing is out of date;
> pgnuplot has been replaced by a newer console mode variant, right?

I think so. If the implementation of console version gnuplot to the official release, pgnuplot is no
longer needed because it can be used for limited range.

Regards

Tatsuro      

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

Web site issues

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

On Friday 25 September 2009 00:19:47 pl...@pi... wrote:
> Allin Cottrell wrote:

> > <survey>
> > 
> > (1) Google search: "free plotting program"
> > www.gnuplot.info = #2
> > gnuplot sf page not on first 2 google pages

Yeah, but that's because there are so many free-but-crap plotting programs
for Windows :-)
If you search on "free plotting program linux" then the
first several hits are summaries that list gnuplot near the top.

> > (2) Google search: "open source plotting program"
> > www.gnuplot.info = #3
> > gnuplot sf page not on first 2 google pages
[same for several other search queries]

That is a bit misleading. The Google search has folded the
two sites into a single hit.  If you hit "show similar" on 
any of these search hits you will see that both sites are there.
I don't know how it decides which one of the equivalent sites to
use as the representative.

> > (1) I would say, if we're interested in proselytizing [...]
> >     we should also include the term "graphing". 

I can't explain the search results, but I note that "gnuplot" is the
largest category in the Google directory of page ranks under
    http://www.google.com/Top/Science/Math/Software/Graphing/
It's one of only 4 programs that rate their own category.

I have added the term "graphing" to the web page anyhow, but I doubt that it
will make a difference.  To my understanding, the critical thing would be
to get the word "graphing" to appear nearby in text of the _linking_ pages.

> > (2) This is more speculative, but IMO google page rank is quite
> > dynamic, not necessarily strongly bound by history.  That is, I
> > think that _if_ the gnuplot developers (and I don't count myself
> > as one, I'm just an interested spectator) were to choose to make
> > gnuplot.sf.net the canonical site, then the ranking would fairly
> > quickly adjust to favour gnuplot.sf.net.

When I checked yesterday, both www.gnuplot.info and gnuplot.sourceforge.net
had page ranks of 7.  So I think that page rank per se is a non-issue.


Anyhoo..............

I'm much more concerned about the lack of an assigned maintainer for either
the web site or the FAQ.  Both could use a thorough updating, and that will
be even more true shortly, when the release version switches to 4.4 and the
CVS version switches to 4.5   These numbers appear all over the place.

Any volunteers to make a pass over the web pages and/or FAQ?
You don't need to be listed as a developer;  just download the page source
using wget or the like, edit locally, and then upload the revised pages to
the Patches tracker.  Or, if you prefer, there is (I think) a mechanism to
give separate mainainer access to the web pages.


	Ethan (sfeam)

MSWin issues holding up 4.4.rc1

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

This is a plea for assistance with serveral windows-specific bugs
still marked "open" on the bug tracker.

I was really hoping that we could resolve the major known glitches
in the windows terminal before putting out a 4.4 release candidate.
And in fact a couple of windows bugs were resolved over the summer
(emf + enhanced text now works, kudos to Ben Lindner).

Unfortunately several other remain.

   Bug #
 2848002   Ctrl+C crashes windows console build
 2807154   On Vista x64 plot keeps redrawing
 1952364   Windows driver draws points with dashed lines
 1952287   Windows driver draws dashed border for rectangles
 1609845   quota limits pipe size in pgnuplot

I very much suspect that the "quota limits" thing is out of date;
pgnuplot has been replaced by a newer console mode variant, right?

I've seen no other complaints about continual redrawing in Vista.
Can someone confirm whether this is reproducible?

The two dashed line problems may be the same bug, and are probably
trivial to fix if you have a windows build system to use for debugging.


-- 
Ethan A Merritt

Re: Send bug reports and ...

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

On Tuesday 22 September 2009, Petr Mikulik wrote:
> Nowadays, the message on gnuplot's start-up:
> 
>   Send bug reports and suggestions to <http://sourceforge.net/projects/gnuplot>
> 
> does no longer fit to 80 characters making it strange looking on many 
> terminals. Thus, it should be changed. The following messages would fit into 
> 80 characters:
> 
> 1. 
>   The gnuplot FAQ is available from http://www.gnuplot.info/faq/
>   ...
>   Report bugs and suggestions to http://sf.net/projects/gnuplot
> 
> 2.
>   The gnuplot FAQ is available from www.gnuplot.info/faq/
>   ...
>   Report bugs and suggestions to www.sourceforge.net/projects/gnuplot
> 
> 
> I would vote for 2.
> Any ideas?

I have simplified the start message further. Is it OK?

stonelion [132] ./gnuplot

        G N U P L O T
        Version 4.3 patchlevel CVS-06Oct2009
        last modified Tue Oct  6 20:44:40 PDT 2009
        System: Linux 2.6.29.6-desktop-1mnb

        Copyright (C) 1986-1993, 1998, 2004, 2007-2009
        Thomas Williams, Colin Kelley, and many others

        immediate help:  type "help"
        gnuplot FAQ:     http://www.gnuplot.info/faq/
        report bugs:     http://sf.net/projects/gnuplot/support

Terminal type set to 'wxt'
gnuplot>

Re: multiplot title font

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

On Thursday 01 October 2009, Shigeharu TAKENO wrote:
> shige 10/01 2009
> > 
> I found the following short patch may be enable us to use
> 
>   set multiplot title "<string>" font "<fontname>,<size>"

Applied.
Thanks.

Re: console mode gnuplot for windows with wxt doen not work (gnuplot 4.3 / mingw)

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

Hello

--- Ethan Merrt wrote:
> 
> Sorry,  I see that in working through a 2 week backlog of Email I missed
> a set of follow-on patch proposals.  Was there a final patch version that
> I should apply?
> 

I am sending a mail in which the final patch is attached again.

Explanation
Remove "-Wl,--subsystem,windows++" and "-mwindows" option to get correct link options for gnuplot for
windows on MinGW platform

It is also to be applied for makefile.cyg but I have never to used cross-compile circumstance for
windows native application on cygwin.   

If my English for the explanation is not good please correct it.

Regards

Tatsuro

 

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

Re: console mode gnuplot for windows with wxt doen not work (gnuplot 4.3 / mingw)

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

On Monday 05 October 2009, Ethan Merritt wrote:
> On Wednesday 23 September 2009, Benjamin Lindner wrote:
> > 
> > > I have posted a thread about a problem on console mode gnuplot for windows
> > > with wxt.
>  
> > The wxt link flags incorrectly include the setting "-mwindows", which causes gnuplot to be a gui-subsystem application, no longer a console-subsystem application. Thus stdin/stdout will not work.
> > You have to modify the flags returned by wx-config.
> 
> Could you please submit a patch for the INSTALL file or else
> a separate bit of documentation that explains this to people
> trying to build under MSWin?

Sorry,  I see that in working through a 2 week backlog of Email I missed
a set of follow-on patch proposals.  Was there a final patch version that
I should apply?


	Ethan

Re: console mode gnuplot for windows with wxt doen not work (gnuplot 4.3 / mingw)

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

On Wednesday 23 September 2009, Benjamin Lindner wrote:
> 
> > I have posted a thread about a problem on console mode gnuplot for windows
> > with wxt.
 
> The wxt link flags incorrectly include the setting "-mwindows", which causes gnuplot to be a gui-subsystem application, no longer a console-subsystem application. Thus stdin/stdout will not work.
> You have to modify the flags returned by wx-config.

Could you please submit a patch for the INSTALL file or else
a separate bit of documentation that explains this to people
trying to build under MSWin?

	thanks,

		Ethan

Re: multiplot title font

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

shige 10/01 2009
----------------

I wrote:
| Current version of gnuplot supports 
| 
|   set multiplot title "<string>"
| 
| but we can not specify the font of the title string. Though it may
| be done by 

I found the following short patch may be enable us to use

  set multiplot title "<string>" font "<fontname>,<size>"

but I don't know how to make space according to the font size.

----- From Here -----
--- term.c.ORG	Sat Sep  5 14:27:41 2009
+++ term.c	Thu Oct  1 18:25:15 2009
@@ -651,6 +659,16 @@
 	    if ((s = try_to_get_string())) {
 		free(mp_layout.title.text);
 		mp_layout.title.text = s;
+	    }
+	    continue;
+	}
+
+	/* shige */
+	if (equals(c_token, "font")) {
+	    c_token++;
+	    if ((s = try_to_get_string())) {
+		free(mp_layout.title.font);
+		mp_layout.title.font = s;
 	    }
 	    continue;
 	}
----- To Here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: Patch for makefile.mgw for console mode of gnuplot 4.3 for windows

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

Hello Benjamin


--- Benjamin Lindner  wrote:
The flag "-mwindows" has nothing to do with whether an application is 
using GDI libraries or not. It specifies the type of startup code and 
entry point of the application. So I cannot follow the wxwidgets 
developers argumentation. But it's their decision to make.

I agree. But it seem to difficult to make their decision to change.

> However I can get useful information for disabling the the flag '-Wl,--subsystem,windows -mwindows':

> override it by a subsequent -Wl,--subsequent,console.

I am sorry but this is IMO a very bad solution to take.
This depends on the order of arguments on the command line, is not 
portable and depends no binutils' actual interpretation of such a 
double-specfication.
And it is simply wrong. An application is either a GUI-subsystem 
application or a console-subsystem application. If it's not a GUI 
application, one shouldn't say so in the first place and not change 
one's mind halfway through. It's not a clean method, IMO

OK. I under stand your statement.  Surely it should be clean.

> Tatsuro MATSUOKA wrote:
> > Hello 
> > 
> > After discussion with Vadim Zeitlin, who is one of the developer of wxWidget, in the following
> address
> > 
> >
>
http://groups.google.co.jp/group/wx-dev/browse_thread/thread/65a3af28e9a21bca/89264cf1c66e16f3#89264cf1c66e16f3
> > 
> > I consider two different patch. First one, 'makefile.mgw.1.patch' is the same as that I have
> proposed
> > in the previous post.
> > Second one is add overrideng option to when PIPES flag is on: 'makefile.mgw.2.patch'  
> > 
> > First patch:
> > -	WX_LIBS = $(shell wx-config --libs)
> > +	WX_LIBS = $(shell wx-config --libs | sed -e 's/ -Wl,--subsystem,windows -mwindows//')
> > This removes  '-Wl,--subsystem,windows -mwindows' flag
> 
> I'd propose a more robust version like
> sed -e "s+-Wl,--subsystem,windows++g" -e "s+-mwindows++g"


> Removing should not be dependent on spaces and the actual order of the 
> erroneus commands.
> 
> > Second patch:
> >  	WX_LIBS = $(shell wx-config --libs)
> > +	ifdef PIPES
> > +		WX_LIBS += -Wl,--subsystem,console
> > +	endif
> > add overrideing option for gnuplot.exe and wgnuplot_pipes.exe
> > 
> > I cannot figure out which is better.  Please discuss this matter and produce better patch.
> > Of course, more smart ideas are highly welcome.
> 
> The former. The latter looks wrong and is highly unportable as it 
> depends on the order of the flags on the command line and their 
> interpreation by binutils.

I submit a patch considering Benjamin suggestion.

Benjamin. Thank you for your comprehensive and extensive suggestions.

Regards

Tatsuro


--------------------------------------
Yahoo! JAPAN - Internet Security for teenagers and parents.
http://pr.mail.yahoo.co.jp/security/

Re: Patch for makefile.mgw for console mode of gnuplot 4.3 for windows

[Benjamin L. <lin...@gm...>]

Tatsuro MATSUOKA wrote:
> Hello 
> 
> After discussion with Vadim Zeitlin, who is one of the developer of wxWidget, in the following address
> 
> http://groups.google.co.jp/group/wx-dev/browse_thread/thread/65a3af28e9a21bca/89264cf1c66e16f3#89264cf1c66e16f3
> 
> I consider two different patch. First one, 'makefile.mgw.1.patch' is the same as that I have proposed
> in the previous post.
> Second one is add overrideng option to when PIPES flag is on: 'makefile.mgw.2.patch'  
> 
> First patch:
> -	WX_LIBS = $(shell wx-config --libs)
> +	WX_LIBS = $(shell wx-config --libs | sed -e 's/ -Wl,--subsystem,windows -mwindows//')
> This removes  '-Wl,--subsystem,windows -mwindows' flag

I'd propose a more robust version like
sed -e "s+-Wl,--subsystem,windows++g" -e "s+-mwindows++g"

Removing should not be dependent on spaces and the actual order of the 
erroneus commands.

> Second patch:
>  	WX_LIBS = $(shell wx-config --libs)
> +	ifdef PIPES
> +		WX_LIBS += -Wl,--subsystem,console
> +	endif
> add overrideing option for gnuplot.exe and wgnuplot_pipes.exe
> 
> I cannot figure out which is better.  Please discuss this matter and produce better patch.
> Of course, more smart ideas are highly welcome.

The former. The latter looks wrong and is highly unportable as it 
depends on the order of the flags on the command line and their 
interpreation by binutils.

benjamin

Re: Patch for makefile.mgw for console mode of gnuplot 4.3 for windows

[Benjamin L. <lin...@gm...>]

Tatsuro MATSUOKA wrote:
> Hello
> 
> --- Tatsuro MATSUOKA wrote:
>> In my opinion, the flag '-Wl,--subsystem,windows -mwindows' in wx-config for wxMSW is to be
>> removed. 
>> I have posted my opinion to the wx-develop post.  However at the moment, I cannot say that my
>> opinion
>> will be accepted. Therefore I propose the patch attached.
> 
> My proposal was rejected by the wxWidgets developper.
> 
> http://groups.google.co.jp/group/wx-dev/browse_thread/thread/65a3af28e9a21bca# 
> 

The flag "-mwindows" has nothing to do with whether an application is 
using GDI libraries or not. It specifies the type of startup code and 
entry point of the application. So I cannot follow the wxwidgets 
developers argumentation. But it's their decision to make.

> However I can get useful information for disabling the the flag '-Wl,--subsystem,windows -mwindows': 
> override it by a subsequent -Wl,--subsequent,console.

I am sorry but this is IMO a very bad solution to take.
This depends on the order of arguments on the command line, is not 
portable and depends no binutils' actual interpretation of such a 
double-specfication.
And it is simply wrong. An application is either a GUI-subsystem 
application or a console-subsystem application. If it's not a GUI 
application, one shouldn't say so in the first place and not change 
one's mind halfway through. It's not a clean method, IMO

benjamin