gnuplot development

maybe
system "clear"
?


RemyLeBeau wrote:
> 
> Is there any command in Gnuplot which works as 'cls' on DOS?
> I'm not talkig about 'clear'. I just want to erase the writen command
> lines, not the graphs.
> 

-- 
View this message in context: http://www.nabble.com/How-to-clear-screen--tp26103978p26113805.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

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

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

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 ?

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

On Monday 26 October 2009 07:15:24 Petr Mikulik wrote:
> > > > 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 have removed them, and changed the remaining ERROR_NOTICE instances
to call int_warn() instead.  I did the same for the small number of warnings
sent directly to stderr by term.c and axis.c.

I leave it to you if you want to experiment with making int_warn() 
output condition on    if (interactive)  or some other controlling flag.

-- 
Ethan A Merritt

Sorry for stepping into this discussion late. 

I think it would be highly desirable to be able to 
switch warnings on or off (or possibly even set
where they are sent).

I often call gnuplot from scripts, producing many
graphs. In such situations, I would like to suppress
warnings - or maybe put them into a log file.

So, if we could support something like this, that
would be great:

set warnings         # directs to STDERR or terminal
set warnings "file" # directs to file
unset warnings     # suppresses output

Interactive terminals can then be "smart" to default
to direct warnings to STDERR. But people who use
gnuplot in the background have the flexibility to do
what they need.

In a similar spirit: would it be possible to include the
start-up greeting message in the list of messages
that can be redirected in this way?

Best,

		Ph.


On Monday 26 October 2009 11:53:47 am Ethan Merritt wrote:
> On Monday 26 October 2009 07:15:24 Petr Mikulik wrote:
> > > > > 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 have removed them, and changed the remaining ERROR_NOTICE instances
> to call int_warn() instead.  I did the same for the small number of
> warnings sent directly to stderr by term.c and axis.c.
>
> I leave it to you if you want to experiment with making int_warn()
> output condition on    if (interactive)  or some other controlling flag.

Philipp K. Janert wrote:

> I think it would be highly desirable to be able to 
> switch warnings on or off (or possibly even set
> where they are sent).
> 
> I often call gnuplot from scripts, producing many
> graphs. In such situations, I would like to suppress
> warnings - or maybe put them into a log file.

IMHO, that's putting the cart before the horse.

> So, if we could support something like this, that
> would be great:
> 
> set warnings         # directs to STDERR or terminal

For all practical purposes, the terminal _is_ STDERR.

> set warnings "file" # directs to file

What's wrong with plain and simple redirection from the outside?

	gnuplot 2>file

> unset warnings     # suppresses output

	gnuplot 2>/dev/null

> Interactive terminals can then be "smart" to default
> to direct warnings to STDERR.

Except it isn't the terminal

> But people who use gnuplot in the background have the flexibility to
> do what they need.

They have that flexibility already, without us having to anything!

> In a similar spirit: would it be possible to include the
> start-up greeting message in the list of messages
> that can be redirected in this way?

It already is.

You have a point, that works. I even convinced myself
that I can do redirection of this form when I call gnuplot
as a subprocess from Perl:

open GP, "| /usr/bin/gnuplot >& foo.log " or die "Fail: $!";
$cmd = "set t png; set o 'foo.png'; plot 'foo' u 1:2 w lp\n";
print GP $cmd;
close GP;

Personally, I find it hacky, and would prefer a way for
gnuplot to take care of its logging destination itself,
without having to rely on shell redirection.

But I admit that the shell redirection works.

Best,

		Ph.


On Tuesday 27 October 2009 01:37:33 pm you wrote:
> Philipp K. Janert wrote:
> > I think it would be highly desirable to be able to
> > switch warnings on or off (or possibly even set
> > where they are sent).
> >
> > I often call gnuplot from scripts, producing many
> > graphs. In such situations, I would like to suppress
> > warnings - or maybe put them into a log file.
>
> IMHO, that's putting the cart before the horse.
>
> > So, if we could support something like this, that
> > would be great:
> >
> > set warnings         # directs to STDERR or terminal
>
> For all practical purposes, the terminal _is_ STDERR.
>
> > set warnings "file" # directs to file
>
> What's wrong with plain and simple redirection from the outside?
>
> 	gnuplot 2>file
>
> > unset warnings     # suppresses output
>
> 	gnuplot 2>/dev/null
>
> > Interactive terminals can then be "smart" to default
> > to direct warnings to STDERR.
>
> Except it isn't the terminal
>
> > But people who use gnuplot in the background have the flexibility to
> > do what they need.
>
> They have that flexibility already, without us having to anything!
>
> > In a similar spirit: would it be possible to include the
> > start-up greeting message in the list of messages
> > that can be redirected in this way?
>
> It already is.

On Wednesday 28 October 2009, Philipp K. Janert wrote:
> 
> You have a point, that works. I even convinced myself
> that I can do redirection of this form when I call gnuplot
> as a subprocess from Perl:
> 
> open GP, "| /usr/bin/gnuplot >& foo.log " or die "Fail: $!";
> $cmd = "set t png; set o 'foo.png'; plot 'foo' u 1:2 w lp\n";
> print GP $cmd;
> close GP;
> 
> Personally, I find it hacky, and would prefer a way for
> gnuplot to take care of its logging destination itself,
> without having to rely on shell redirection.
> 
> But I admit that the shell redirection works.

It also has the advantage that you can use this mechanism from
a cgi script (web server back end) independent of whether the
gnuplot scripts it calls know anything about the redirection.
I use this to create task-specific log files from the web server
even if the various distinct tasks call the same gnuplot script
somewhere along the way.

But what happened to the impetus for the original complaint?
I understood the problem to be that Octave triggers error messages
that appear on the user's screen, even though the user has no way
to do anything about it.  That does seem worth fixing if there is
a well-defined set of harmless messages that are triggered.
Of course, that fix may lie on the Octave side rather than the
gnuplot side :-)  

I never got an answer to my question of whether gnuplot considered 
itself to be in "interactive" mode while being driven from Octave.
Does it?

   Ethan

> But what happened to the impetus for the original complaint?
> I understood the problem to be that Octave triggers error messages
> that appear on the user's screen, even though the user has no way
> to do anything about it.  That does seem worth fixing if there is
> a well-defined set of harmless messages that are triggered.
> Of course, that fix may lie on the Octave side rather than the
> gnuplot side :-)  
> 
> I never got an answer to my question of whether gnuplot considered 
> itself to be in "interactive" mode while being driven from Octave.
> Does it?

It uses the popen("gnuplot", ...), thus gnuplot runs in non-interactive 
mode.

---
PM

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.

--- Ethan Merritt <merritt@...> 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/

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

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/

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

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
> gnuplot-beta@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


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

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