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

Re: gnuplot terminates unexpectedly

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

On Sunday, March 20, 2011, Hans-Bernhard Bröker wrote:
> On 18.03.2011 10:39, Bastian Märkisch wrote:
> >
> > Currently the builtin readline causes gnuplot to terminate
> > if ^D (DEL) is entered on an empty line.
> 
> That's been the default behaviour of Unix command line shells since the 
> beginning of time().  Some let you change that, some don't.
> 
>  > Would the following
> > trivial change have any negative side effect?
> 
> I suspect it would surprise some long-time users.

Including me :-)
That's what ^D is supposed to do.  It means "End of File".

	Ethan

Re: gnuplot terminates unexpectedly

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

On 18.03.2011 10:39, Bastian Märkisch wrote:
>
> Currently the builtin readline causes gnuplot to terminate
> if ^D (DEL) is entered on an empty line.

That's been the default behaviour of Unix command line shells since the 
beginning of time().  Some let you change that, some don't.

 > Would the following
> trivial change have any negative side effect?

I suspect it would surprise some long-time users.

Re: Smooth Step

[Douglas M. <dou...@gm...>]

That is a valid response, however, I don't believe it to be outside the
realm of what gnuplot offers.

For instance, people often use these techniques for 2d data, using dgrid3d,
to interpolate ungridded data so that it can be compared to other data and
plotted on a grid. In many ways, my problem is quite similar, only the
available interpolate functions aren't able to do it. I would refrain from
suggesting gratuitous features, but it seems fairly simple and useful. For
instance 'smooth step', it would make plotting "filled steps", a plotting
style that would combine filledcurves and steps, far easier than some
methods that have been proposed.

Douglas

2011/3/18 Hans-Bernhard Bröker <HBB...@t-...>

> On 18.03.2011 17:01, Douglas Mason wrote:
>
>  [This is a question that came up when I was comparing some original data
>> to an approximation which was computed through an external program. You
>> can see the original plot in the attachment. My goal is to quantify the
>> variation between the data and the approximation.]
>>
>
> But why are you trying to use gnuplot for that?  You need a data processing
> tool, not a plotting program.
>
> When you want to compare data sets in a plotting program, you plot them
> into a common diagram and look at it.  For quantifying differences, you run
> a data processor.
>
> As far as filledcurves is concerned, all it takes would be to transform
> your data, adding the "extra" points introduced by "steps" or "fsteps".
>
> x1 y1
> x2 y2
> x3 y3
>
> -->
>
> x1 y1  # "steps"
> x2 y1
> x2 y2
> x3 y2
> x3 y3
>
>

Re: Smooth Step

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

On 18.03.2011 17:01, Douglas Mason wrote:

> [This is a question that came up when I was comparing some original data
> to an approximation which was computed through an external program. You
> can see the original plot in the attachment. My goal is to quantify the
> variation between the data and the approximation.]

But why are you trying to use gnuplot for that?  You need a data 
processing tool, not a plotting program.

When you want to compare data sets in a plotting program, you plot them 
into a common diagram and look at it.  For quantifying differences, you 
run a data processor.

As far as filledcurves is concerned, all it takes would be to transform
your data, adding the "extra" points introduced by "steps" or "fsteps".

x1 y1
x2 y2
x3 y3

-->

x1 y1  # "steps"
x2 y1
x2 y2
x3 y2
x3 y3

gnuplot terminates unexpectedly

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

Currently the builtin readline causes gnuplot to terminate
if ^D (DEL) is entered on an empty line. Would the following
trivial change have any negative side effect?

Bastian


--- /src/readline.c	(revision 231)
+++ /src/readline.c	(working copy)
@@ -715,7 +722,9 @@
  	    case 004:		/* ^D */
  		if (max_pos == 0) {
  		    reset_termio();
-		    return ((char *) NULL);
+		    if (!interactive) /* terminate */
+			return ((char *) NULL);
+		    break;
  		}
  		if (cur_pos < max_pos) {
  		    for (i = cur_pos; i < max_pos; i++)

Re: src/win/wgnuplot.exe.manifest

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

>Hello
>
>>From 2011-03-13, src/win/wgnuplot.exe.manifest has been added to the cvs source tree.
>Is it better add it to the binary distributions?
>
>Regards
>
>Tatsuro

This is not necessary. It gets included in the .exe file automatically. 

In fact, previous builds which include wxWidgets do already include a similar
manifest. Now we provide our own in any case.

Bastian 

src/win/wgnuplot.exe.manifest

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

Hello

>From 2011-03-13, src/win/wgnuplot.exe.manifest has been added to the cvs source tree.
Is it better add it to the binary distributions?

Regards

Tatsuro

Re: autoscale.dem failing, left margin not working

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

On 03/13/2011 11:33 PM, Ethan Merritt wrote:
> On Sunday, March 13, 2011, Daniel J Sebald wrote:
>> On 03/12/2011 01:09 PM, Daniel J Sebald wrote:
>>> On 03/12/2011 12:36 PM, Ethan Merritt wrote:
>>>> On Saturday, March 12, 2011, Daniel J Sebald wrote:
>>
>>>>> A second issue is that the left margin no longer works properly.  Try
>>>>> the 'key.dem' demo and it should be apparent.  There are some other
>>>>> demos where the plot edge for the left margin is not computed correctly.
>>>>
>>>> I haven't found any where the left margin of the plot itself is incorrect.
>>>> The placement of the key box is non-obvious or incorrect in some of the
>>>> examples. Not sure whether this is because it's mis-estimating to left
>>>> margin or the font size or what.
>>>
>>> This issue is still present.  It must have come about before 4.4.
>>>
>>> Check the example with "Key (out vert left top)" as a title of the
>>> upper-left sub-plot.  The key used to be outside the actual sub-plot,
>>> but the sub-plot margin is too small.  It should look like a mirror of
>>> the example "Key (out vert right top)".
>>
>> I think it is this change:
>>
>> http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/graphics.c?r1=1.316&r2=1.317
>>
>> specifically the green line added at the start of the diff list.  I
>> commented out that line and the key demo works as I remember.
>
> I take it you are refering to addition of the line
>
>
>           plot_bounds.xleft = xoffset * t->xmax;
>
>
>
> It looks to me that the program flow is currently
>   - preliminary calculation of xleft, xbot, etc
>   - calculation of key box size
>   - add key box size where needed
>   - calculation of tic label sizes
>   - recalculate xleft, xbot, etc now using the tic label sizes
>   - oops the key box wasn't added in again
>
> It may be that the key box size has to be added in twice,
> once for the preliminary calculation and once for the final
> calculation.  Or it may be that it only has to be included
> in the final calculation, whereas right now it is only included
> in the preliminary calculation.
> I'm not sure which fix is correct.

The way I looked at it, when the key is outside (that's the case where 
this is important), its presence effectively shrinks the region for the 
plot.  I guess that is how the tic labels work as well.  xleft, etc. 
should be adjusted relative to their current values whenever a new item 
is added outside its boundaries, I would think.

 From what I recall, there is a lot of code for setting the plot 
locations, and justifiably so.  But it was difficult to follow and in 
some cases may have duplicate code.  As a result it feels a bit like 
trial and error getting layout right.  What's needed is a outline, as 
you've listed above.  I'm not sure it is worth trying to clean this up 
until the day comes for multiple keys.  Not poorly written; just big.

Dan

Re: autoscale.dem failing, left margin not working

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

On Sunday, March 13, 2011, Daniel J Sebald wrote:
> On 03/12/2011 01:09 PM, Daniel J Sebald wrote:
> > On 03/12/2011 12:36 PM, Ethan Merritt wrote:
> >> On Saturday, March 12, 2011, Daniel J Sebald wrote:
> 
> >>> A second issue is that the left margin no longer works properly.  Try
> >>> the 'key.dem' demo and it should be apparent.  There are some other
> >>> demos where the plot edge for the left margin is not computed correctly.
> >>
> >> I haven't found any where the left margin of the plot itself is incorrect.
> >> The placement of the key box is non-obvious or incorrect in some of the
> >> examples. Not sure whether this is because it's mis-estimating to left
> >> margin or the font size or what.
> >
> > This issue is still present.  It must have come about before 4.4.
> >
> > Check the example with "Key (out vert left top)" as a title of the
> > upper-left sub-plot.  The key used to be outside the actual sub-plot,
> > but the sub-plot margin is too small.  It should look like a mirror of
> > the example "Key (out vert right top)".
> 
> I think it is this change:
> 
> http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/graphics.c?r1=1.316&r2=1.317
> 
> specifically the green line added at the start of the diff list.  I 
> commented out that line and the key demo works as I remember.

I take it you are refering to addition of the line


         plot_bounds.xleft = xoffset * t->xmax;



It looks to me that the program flow is currently
 - preliminary calculation of xleft, xbot, etc
 - calculation of key box size
 - add key box size where needed
 - calculation of tic label sizes
 - recalculate xleft, xbot, etc now using the tic label sizes
 - oops the key box wasn't added in again

It may be that the key box size has to be added in twice,
once for the preliminary calculation and once for the final
calculation.  Or it may be that it only has to be included
in the final calculation, whereas right now it is only included
in the preliminary calculation.  
I'm not sure which fix is correct.


	Ethan



> 
> plot_bounds.xleft is adjusted to leave space for the key before the 
> lines in this diff list.  What was the above modification meant to 
> address?  Maybe there is some other way of doing this.
> 
> Before the adjustment for the key, plot_bounds.xleft is set as follows:
> 
>      /*{{{  preliminary plot_bounds.xleft, needed for "under" */
>      if (lmargin.scalex == screen)
> 	plot_bounds.xleft = lmargin.x * (float)t->xmax;
>      else
> 	plot_bounds.xleft = xoffset * t->xmax
> 			  + t->h_char * (lmargin.x >= 0 ? lmargin.x : 1);
>      /*}}} */
> 
> Perhaps plot_bounds.xleft = xoffset * t->xmax; should be grouped with 
> the above code.  E.g.,
> 
>      if (lmargin.x < 0)
> 	plot_bounds.xleft = xoffset * t->xmax;
>      elseif (lmargin.scalex == screen)
> 	plot_bounds.xleft = lmargin.x * (float)t->xmax;
>      else
> 	plot_bounds.xleft = xoffset * t->xmax
> 			  + t->h_char * (lmargin.x >= 0 ? lmargin.x : 1);
> 
> Dan
> 

Re: autoscale.dem failing, left margin not working

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

On 03/12/2011 01:09 PM, Daniel J Sebald wrote:
> On 03/12/2011 12:36 PM, Ethan Merritt wrote:
>> On Saturday, March 12, 2011, Daniel J Sebald wrote:

>>> A second issue is that the left margin no longer works properly.  Try
>>> the 'key.dem' demo and it should be apparent.  There are some other
>>> demos where the plot edge for the left margin is not computed correctly.
>>
>> I haven't found any where the left margin of the plot itself is incorrect.
>> The placement of the key box is non-obvious or incorrect in some of the
>> examples. Not sure whether this is because it's mis-estimating to left
>> margin or the font size or what.
>
> This issue is still present.  It must have come about before 4.4.
>
> Check the example with "Key (out vert left top)" as a title of the
> upper-left sub-plot.  The key used to be outside the actual sub-plot,
> but the sub-plot margin is too small.  It should look like a mirror of
> the example "Key (out vert right top)".

I think it is this change:

http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/graphics.c?r1=1.316&r2=1.317

specifically the green line added at the start of the diff list.  I 
commented out that line and the key demo works as I remember.

plot_bounds.xleft is adjusted to leave space for the key before the 
lines in this diff list.  What was the above modification meant to 
address?  Maybe there is some other way of doing this.

Before the adjustment for the key, plot_bounds.xleft is set as follows:

     /*{{{  preliminary plot_bounds.xleft, needed for "under" */
     if (lmargin.scalex == screen)
	plot_bounds.xleft = lmargin.x * (float)t->xmax;
     else
	plot_bounds.xleft = xoffset * t->xmax
			  + t->h_char * (lmargin.x >= 0 ? lmargin.x : 1);
     /*}}} */

Perhaps plot_bounds.xleft = xoffset * t->xmax; should be grouped with 
the above code.  E.g.,

     if (lmargin.x < 0)
	plot_bounds.xleft = xoffset * t->xmax;
     elseif (lmargin.scalex == screen)
	plot_bounds.xleft = lmargin.x * (float)t->xmax;
     else
	plot_bounds.xleft = xoffset * t->xmax
			  + t->h_char * (lmargin.x >= 0 ? lmargin.x : 1);

Dan

Change in March 8th by Bastian Maerkisch cvs branch(was FYI: 64 bit windows 7 sp1)

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

Hello

Change in March 8th by Bastian Maerkisch make avoid to fault the temporary files on windows 7
64 bit.
Current 4.4 cvs for gnuplot for windows
2011-03-10  Ethan A Merritt  <merritt@u.washington.edu>

	* src/plot2d.c(get_data) src/graphics.c(plot_boxes):
	variable color for plot style BOXXYERROR

gnuplot> load 'pm3d.dem'
Hit return to continue
Hit return to continue
Hit return to continue
Hit return to continue
Hit return to continue
Hit return to continue
Hit return to continue
Hit return to continue
         "pm3d.dem", line 95: cannot write temporary file

At current 4.5 cvs version, this error does not happen.

If possible, please attach corresponding patch, which is attached to 4.5, to the 4.4 cvs branch for
the next official release.

Regards

Tatsuro

--- Tatsuro MATSUOKA wrote:

> Hello
> 
> You are right.
> The gnuplot-4.4.3 binary suffer from the same fault after windows 7 update.
> 
> Thus your change for tmpfile() is important for many windows users.
> 
> Thanks!
> 
> Regards
> 
> Tasuro
> 
> 
> --- Bastian M将」rkisch  wrote:
> 
> > 
> > 
> > Von: "Tatsuro MATSUOKA" <tma...@ya...>
> > >Hello
> > >
> > >Since I have changed my computer at University to windows Home Premium 64 bit, 
> > >pm3d.dem fails due to temporary file error.
> > >
> > >Today I have update my windows 7 to the sp1.
> > >
> > >Temporary file error disappeared and all.dem can be executed normally.
> > >
> > 
> > Or maybe it has something to do with yesterday's change in CVS?
> > Are you saying that your build from March 8th also works?
> > According to several reports on  the net tmpfile() consistently fails 
> > on Vista, Windows 7 and probably any descently configured Windows XP
> > The reason is that for some unknown reason tmpfile() wants to create a 
> > file in C:\. But normal users don't have the appropriate rights to do that.
> >   
> >   Bastian
> >   
> > >Regards
> > >
> > >Tatsuro
> > >
> > 
> 
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: FYI: 64 bit windows 7 sp1

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

Hello

You are right.
The gnuplot-4.4.3 binary suffer from the same fault after windows 7 update.

Thus your change for tmpfile() is important for many windows users.

Thanks!

Regards

Tasuro


--- Bastian M将」rkisch  wrote:

> 
> 
> Von: "Tatsuro MATSUOKA" <tma...@ya...>
> >Hello
> >
> >Since I have changed my computer at University to windows Home Premium 64 bit, 
> >pm3d.dem fails due to temporary file error.
> >
> >Today I have update my windows 7 to the sp1.
> >
> >Temporary file error disappeared and all.dem can be executed normally.
> >
> 
> Or maybe it has something to do with yesterday's change in CVS?
> Are you saying that your build from March 8th also works?
> According to several reports on  the net tmpfile() consistently fails 
> on Vista, Windows 7 and probably any descently configured Windows XP
> The reason is that for some unknown reason tmpfile() wants to create a 
> file in C:\. But normal users don't have the appropriate rights to do that.
>   
>   Bastian
>   
> >Regards
> >
> >Tatsuro
> >
> 

Your app listing has been updated on MacUpdate.com

[MacUpdate C. T. <no-...@ma...>]

Hi Gnuplot Project,

We have updated your application listing for gnuplot 4.4.3 on MacUpdate.com. Please take a moment to review your application's information to make sure that everything is correct.

You may view your updated listing by visiting:
http://www.macupdate.com/app/mac/16168/gnuplot


Create a Developer Account today to reply to comments and view stats:
https://www.macupdate.com/developers/signup/


You may submit new updates, or changes to your app listing here:
http://www.macupdate.com/developers/update/


Questions? Contact our Content Update Team up...@ma....

Thank you for being part of the MacUpdate Software Community!:

-The MacUpdate Team

Re: building with AquaTerm

[Andrea D'A. <and...@ma...>]

2011/3/10 Mojca Miklavec <moj...@gm...>:

> I was not sure what inside/outside meant. Well - yes, I want to use
> MacPorts' libraries, but the binary will be at some other location.

Location doesn't matter, build a Mach-O binary against MacPorts'
libraries, move to a location of your choice and use 'otool -L' on it.
It'll refer to MacPorts' libraries and therefore it's "inside"
MacPorts.


-- 
Andrea

Re: autoscale.dem failing, left margin not working

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

On 12.03.2011 20:09, Daniel J Sebald wrote:
> On 03/12/2011 12:36 PM, Ethan Merritt wrote:
>> On Saturday, March 12, 2011, Daniel J Sebald wrote:

> It's part of SourceForge, isn't it?  At least I think that is what the
> "Download GNU tarball" feature of SourceForge is supposed to be:
>
> http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/

That's a tarball of the head revisions of everything.  And that's 
actually a feature of ViewVC, not SourceForge.

It definitely has nothing to do with the 4.4 branch in any way.

> If I followed the discussion of a couple months ago correctly,
> SourceForge is no longer supporting CVS.

You didn't follow correctly.  SourceForge.net sees CVS as a liability, 
but they haven't announced anything like a termination of service on it. 
  They would prefer us to move to Subversion or something, but they 
won't force that decision on us (yet).

Re: autoscale.dem failing, left margin not working

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

On 03/12/2011 12:36 PM, Ethan Merritt wrote:
> On Saturday, March 12, 2011, Daniel J Sebald wrote:
>> I grabbed the most recent version of the SourceForge gnuplot tree via
>> tar-ball.
>
>> From where?
> We provide no such tarball.

It's part of SourceForge, isn't it?  At least I think that is what the 
"Download GNU tarball" feature of SourceForge is supposed to be:

http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/

It seems to bundle all the files for the user.

If I followed the discussion of a couple months ago correctly, 
SourceForge is no longer supporting CVS.  (All the commands that I've 
tried aren't working.)


>> It has directory names with "4.5", but upon compiling and
>> running, I see "4.4":
>>
>> 	G N U P L O T
>> 	Version 4.4 patchlevel 0
>> 	last modified March 2010
>> 	System: Linux 2.6.35.11-83.fc14.i686
>>
>> Anyway, the autoscale.dem demo is failing:
>>
>> gnuplot>  load 'autoscale.dem'
>>
>> gnuplot>  set yrange [*<-5:5<*]
>
> That is a new syntax from 4.5, but it seems you are running some
> [perhaps modified] variant of version 4.4

Oh, thanks.  I found the issue.  I didn't fully install the compiled 
code and must have mistyped the path to the executable file.  Fixing 
that, this demo works fine now.


>> A second issue is that the left margin no longer works properly.  Try
>> the 'key.dem' demo and it should be apparent.  There are some other
>> demos where the plot edge for the left margin is not computed correctly.
>
> I haven't found any where the left margin of the plot itself is incorrect.
> The placement of the key box is non-obvious or incorrect in some of the
> examples. Not sure whether this is because it's mis-estimating to left
> margin or the font size or what.

This issue is still present.  It must have come about before 4.4.

Check the example with "Key (out vert left top)" as a title of the 
upper-left sub-plot.  The key used to be outside the actual sub-plot, 
but the sub-plot margin is too small.  It should look like a mirror of 
the example "Key (out vert right top)".

Dan

Re: autoscale.dem failing, left margin not working

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

On Saturday, March 12, 2011, Daniel J Sebald wrote:
> I grabbed the most recent version of the SourceForge gnuplot tree via 
> tar-ball. 

From where?
We provide no such tarball.


> It has directory names with "4.5", but upon compiling and 
> running, I see "4.4":
> 
> 	G N U P L O T
> 	Version 4.4 patchlevel 0
> 	last modified March 2010
> 	System: Linux 2.6.35.11-83.fc14.i686
> 
> Anyway, the autoscale.dem demo is failing:
> 
> gnuplot> load 'autoscale.dem'
> 
> gnuplot> set yrange [*<-5:5<*]

That is a new syntax from 4.5, but it seems you are running some
[perhaps modified] variant of version 4.4

> A second issue is that the left margin no longer works properly.  Try 
> the 'key.dem' demo and it should be apparent.  There are some other 
> demos where the plot edge for the left margin is not computed correctly.

I haven't found any where the left margin of the plot itself is incorrect.
The placement of the key box is non-obvious or incorrect in some of the
examples. Not sure whether this is because it's mis-estimating to left
margin or the font size or what.

	Ethan

Re: 4.4.3 release announcement

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

On Thursday, March 10, 2011, Jacques Le Bourlot wrote:
> 
> Bonjour,
> 
> I installed release 4.4.3 on a Mac (using MacPort). It runs smoothly. I am particularly happy with new 'value("var")' feature. Thank you!
> 
> However, I upgraded by chance. There is no announcement on the gnuplot web page at:
> 
> http://www.gnuplot.info/
> 
> This web page is used by many people. Maybe you could add a line there.

Oops :-) 
I have just added "update the web site" to the checklist of things
to do when preparing a release.

autoscale.dem failing, left margin not working

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

I grabbed the most recent version of the SourceForge gnuplot tree via 
tar-ball.  It has directory names with "4.5", but upon compiling and 
running, I see "4.4":

	G N U P L O T
	Version 4.4 patchlevel 0
	last modified March 2010
	System: Linux 2.6.35.11-83.fc14.i686

Anyway, the autoscale.dem demo is failing:

gnuplot> load 'autoscale.dem'

gnuplot> set yrange [*<-5:5<*]
                       ^
          "autoscale.dem", line 23: ':' or keyword 'to' expected

Is there a new feature that needs to be selectively compiled into 
gnuplot?  If so, didn't we have some way now of conditioning code inside 
the demos?

A second issue is that the left margin no longer works properly.  Try 
the 'key.dem' demo and it should be apparent.  There are some other 
demos where the plot edge for the left margin is not computed correctly.

Dan

Re: removal of Win16 support

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

Am 11.03.2011 21:54, schrieb Ethan A Merritt:
> On Friday, March 11, 2011 12:25:28 pm Bastian Märkisch wrote:
>> Hello,
>>
>> the last official release of gnuplot for Win16 (3.7.3) is now 7 years
>> old. I think it's about time to remove support for this platform altogether.
>>
>> Below you find the output of diffstat for a preliminary patch that does
>> that.
>
> I did not realize there was so much residual code left.
> The code sections marked "DOS16" and "DOS386" are long gone.
> Is this remaining cruft hiding in the #else clause of code protected by WIN32?
>
> 	Ethan
>

Yes, most of the code is in #ifndef WIN32 sections. But there are also 
checks for WINVER and some manual GetVersion() calls. Moreover there is 
still code which once was used to handle segmented memory: farmalloc,
OFFSETOF, SELECTOROF etc. Plus some outdated comments which only concern 
Win16.

Bastian

>>
>>    config/config.nt       |    5 -
>>    src/alloc.c            |   10 --
>>    src/alloc.h            |    2
>>    src/command.c          |   42 +++-------
>>    src/eval.c             |    4
>>    src/fit.c              |    4
>>    src/gpexecute.c        |    3
>>    src/plot.c             |    2
>>    src/syscfg.h           |    2
>>    src/win/wcommon.h      |   17 ----
>>    src/win/wgnuplib.c     |   29 -------
>>    src/win/wgnuplib.h     |   19 ----
>>    src/win/wgnuplot.mnu   |    3
>>    src/win/wgnuplot.rc    |    6 -
>>    src/win/wgraph.c       |  120 +++--------------------------
>>    src/win/winmain.c      |   69 +++--------------
>>    src/win/wmenu.c        |   81 ++++----------------
>>    src/win/wpause.c       |   33 --------
>>    src/win/wprinter.c     |  197 --------------------------------------
>> -----------
>>    src/win/wtext.c        |   85 +++------------------
>>    term/win.trm           |   13 ---
>>    22 files changed, 93 insertions(+), 652 deletions(-)
>>
>>
>> In addition several build files could be removed (src/win/wgnuplot.def,
>> wgnuplib.def, config/makefile.msw). config/makefile.win also contains
>> 16bit portions.
>>
>> Please let me know how we should proceed.
>>
>> Bastian
>>

Re: removal of Win16 support

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

On Friday, March 11, 2011 12:25:28 pm Bastian Märkisch wrote:
> Hello,
> 
> the last official release of gnuplot for Win16 (3.7.3) is now 7 years 
> old. I think it's about time to remove support for this platform altogether.
> 
> Below you find the output of diffstat for a preliminary patch that does 
> that.

I did not realize there was so much residual code left.
The code sections marked "DOS16" and "DOS386" are long gone.
Is this remaining cruft hiding in the #else clause of code protected by WIN32?

	Ethan 


> 
>   config/config.nt       |    5 -
>   src/alloc.c            |   10 --
>   src/alloc.h            |    2
>   src/command.c          |   42 +++-------
>   src/eval.c             |    4
>   src/fit.c              |    4
>   src/gpexecute.c        |    3
>   src/plot.c             |    2
>   src/syscfg.h           |    2
>   src/win/wcommon.h      |   17 ----
>   src/win/wgnuplib.c     |   29 -------
>   src/win/wgnuplib.h     |   19 ----
>   src/win/wgnuplot.mnu   |    3
>   src/win/wgnuplot.rc    |    6 -
>   src/win/wgraph.c       |  120 +++--------------------------
>   src/win/winmain.c      |   69 +++--------------
>   src/win/wmenu.c        |   81 ++++----------------
>   src/win/wpause.c       |   33 --------
>   src/win/wprinter.c     |  197 --------------------------------------
> -----------
>   src/win/wtext.c        |   85 +++------------------
>   term/win.trm           |   13 ---
>   22 files changed, 93 insertions(+), 652 deletions(-)
> 
> 
> In addition several build files could be removed (src/win/wgnuplot.def, 
> wgnuplib.def, config/makefile.msw). config/makefile.win also contains 
> 16bit portions.
> 
> Please let me know how we should proceed.
> 
> Bastian
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

removal of Win16 support

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

Hello,

the last official release of gnuplot for Win16 (3.7.3) is now 7 years 
old. I think it's about time to remove support for this platform altogether.

Below you find the output of diffstat for a preliminary patch that does 
that.

  config/config.nt       |    5 -
  src/alloc.c            |   10 --
  src/alloc.h            |    2
  src/command.c          |   42 +++-------
  src/eval.c             |    4
  src/fit.c              |    4
  src/gpexecute.c        |    3
  src/plot.c             |    2
  src/syscfg.h           |    2
  src/win/wcommon.h      |   17 ----
  src/win/wgnuplib.c     |   29 -------
  src/win/wgnuplib.h     |   19 ----
  src/win/wgnuplot.mnu   |    3
  src/win/wgnuplot.rc    |    6 -
  src/win/wgraph.c       |  120 +++--------------------------
  src/win/winmain.c      |   69 +++--------------
  src/win/wmenu.c        |   81 ++++----------------
  src/win/wpause.c       |   33 --------
  src/win/wprinter.c     |  197 --------------------------------------
-----------
  src/win/wtext.c        |   85 +++------------------
  term/win.trm           |   13 ---
  22 files changed, 93 insertions(+), 652 deletions(-)


In addition several build files could be removed (src/win/wgnuplot.def, 
wgnuplib.def, config/makefile.msw). config/makefile.win also contains 
16bit portions.

Please let me know how we should proceed.

Bastian

Re: building with AquaTerm

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

On Fri, Mar 11, 2011 at 05:26, Ethan Merritt wrote:
> On Thursday, March 10, 2011, Allin Cottrell wrote:
>> On Thu, 10 Mar 2011, Mojca Miklavec wrote:
>>
>> Or rather, with
>>
>>   "-Wl,-framework -Wl,AquaTerm"
>
> How confusing.  The existing command contains "-framework Foundation".
> Are you saying that "-framework Foundation -framework AquaTerm" is wrong?

It is definitely not wrong.
(I admit that I don't know what exactly -WI does, but when I google
for it I see that some projects use it.)

>> You're not going to endear yourself to gnuplot developers by
>> describing this change as a "fix" (= remedy for something broken),
>> when in fact it's a backward-incompatible change to gnuplot
>> configuration dictated by a (prospective) change to the setup of a
>> third-party library.
>
> Indeed. I was under the impression that aquaterm was currently not working,
> and that this was a fix going forward.  Have I got that wrong?

The problem with AquaTerm is that it is currently only available as
32-bit library and thus doesn't work on 64-bit systems (it was
released before OS X 10.6 was available). However MacPorts contains a
64-bit version and there will be a new release of AquaTerm to fix this
situation.


What is not working at the moment is when user has a 64-bit version of
AquaTerm residing inside MacPorts, but gnuplot doesn't find it without
extra LDFLAGS. Using -framework won't help here either, but it will at
least select the systemwide aquaterm by default.

> If it breaks a currently-working configuration procedure, then no,
> we should not adopt this change.

It doesn't break it. The switch -framework AquaTerm already works with
the old version (so for a very long time). Symlink was provided in
past just for the sake of backward compatibility, but the "grace
period" has been long enough.

The only thing it might "break" is the need to provide an extra switch
    LDFLAGS="-F/opt/local/Library/Frameworks"
when compiling on MacPorts (or on Fink). (A "shortcut" for that might
be ./configure --with-aquaterm=/opt/local/Library/Frameworks, but I
don't have any strong opinion about that.)

> Can we just add back the symlinks that Per Persson for some reason
> doesn't like?   The configure script could test for a missing
> symlink and create it if it's not there.

But how would you test for a missing symlink? By first trying to use
"-framework AquaTerm" and if that works, create a symlink in working
directory (possibly pointing to the wrong framework) and then use
-laquaterm instead of the already working "-framework AquaTerm"?

> Or if the license permits, maybe we could rebuild AquaTerm as a shared
> library ourselves and make a copy available for download with gnuplot?

But what exactly is the point (apart from being an alternative for not
changing configuration script)? The new AquaTerm will contain a shared
library inside the framework (just as the old one does), it will only
miss a symlink.

> I could wish that Per, or whatever OSX gurus we have on tap,
> would work on cleaning up the wxt installation on OSX.  The wxt
> terminal has more features than Aquaterm, and has the virtue of being
> cross-platform.  And it seems at least some people have gotten it to
> work, so it's clearly not impossible.

I wish it was working as well, but apparently it needs some extra code
in gnuplot.

Mojca

Re: FYI: 64 bit windows 7 sp1

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

Von: "Tatsuro MATSUOKA" <tma...@ya...>
>Hello
>
>Since I have changed my computer at University to windows Home Premium 64 bit, 
>pm3d.dem fails due to temporary file error.
>
>Today I have update my windows 7 to the sp1.
>
>Temporary file error disappeared and all.dem can be executed normally.
>

Or maybe it has something to do with yesterday's change in CVS?
Are you saying that your build from March 8th also works?
According to several reports on  the net tmpfile() consistently fails 
on Vista, Windows 7 and probably any descently configured Windows XP
The reason is that for some unknown reason tmpfile() wants to create a 
file in C:\. But normal users don't have the appropriate rights to do that.
  
  Bastian
  
>Regards
>
>Tatsuro
>

Re: building with AquaTerm

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

On Thursday, March 10, 2011, Allin Cottrell wrote:
> On Thu, 10 Mar 2011, Mojca Miklavec wrote:
> 
> > Just to clarify: the author (Per Persson) wants to remove the library
> > libaquaterm.dylib, so gnuplot will have to use -framework AquaTerm (as
> > opposed to -laquaterm) from now on. This makes quite some points from
> > discussion obsolete since the location of Framework is determined with
> > switch -F, not -L any more which makes the location of AquaTerm better
> > configurable.
> >
> > New release is planned before end of March, so it would be great if
> > this gets fixed in gnuplot's cvs as soon as possible. (One has to
> > replace all occurences of "-laquaterm" with "-framework AquaTerm".)
> 
> Or rather, with
> 
>   "-Wl,-framework -Wl,AquaTerm"

How confusing.  The existing command contains "-framework Foundation".
Are you saying that "-framework Foundation -framework AquaTerm" is wrong?

> You're not going to endear yourself to gnuplot developers by
> describing this change as a "fix" (= remedy for something broken),
> when in fact it's a backward-incompatible change to gnuplot
> configuration dictated by a (prospective) change to the setup of a
> third-party library.

Indeed. I was under the impression that aquaterm was currently not working,
and that this was a fix going forward.  Have I got that wrong?

If it breaks a currently-working configuration procedure, then no, 
we should not adopt this change.   

Can we just add back the symlinks that Per Persson for some reason
doesn't like?   The configure script could test for a missing 
symlink and create it if it's not there.

Or if the license permits, maybe we could rebuild AquaTerm as a shared
library ourselves and make a copy available for download with gnuplot?

I could wish that Per, or whatever OSX gurus we have on tap,
would work on cleaning up the wxt installation on OSX.  The wxt 
terminal has more features than Aquaterm, and has the virtue of being
cross-platform.  And it seems at least some people have gotten it to
work, so it's clearly not impossible.


	Ethan