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

Re: historysize

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

On Friday 12 August 2005 01:55 am, Petr Mikulik wrote:
> I'm bit surprised what "unset historysize" is doing. It sets historysize
> to unlimited, not suppressing writing the history file.
>
> I propose the following changes:
> 1. The code for history file is always compiled in (thus no need to
>     --enable-history-file nor to modify dozen of files in config/).
> 2. By default, the history file is not read. It can be switched on in
>     .gnuplot by "set historysize"
> 3. Switching off writing/reading history file: "unset historysize"
> 4. "set historysize -1" would set historysize to unlimited.

That all sounds reasonable.

> Ideas?

What does "set historysize 0" do?

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

Re: using bgd.dll on windows

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

Hans-Bernhard Broeker wrote:
> Bastian Maerkisch wrote:
>=20
>> Ethan A Merritt wrote:
>>
>>> On Thursday 11 August 2005 09:06 am, Bastian Maerkisch wrote:
>=20
>=20
>>>> While trying to compile gnuplot on Windows using MSVC 6.0
>>>> and the precompiled gdlib (gdwin32.zip package) I ran into
>>>> problems concerning calling convention. The supplied
>>>> bgd.dll now uses __stdcall whereas gnuplot uses __cdecl.
>=20
>=20
> If so, then there has to be some macro or typedef exported by the GD=20
> headers that tells us what exactly the type of the callback functions=20
> has to be.  If not, that's a bug in GD which we should report, instead =

> of hacking around it.

Yes, there is macro:
#define BGD_DECLARE(rt) __declspec(dllimport) rt __stdcall

But this is not usable in our case because of "__declspec(dllimport)".
I sent a message to Mr. Boutell proposing a #define similar to the
one in my previous patch.

If there will be no changes to libgd and we don't want to be "hacking
around" it, we could use some intermediate functions to call
gdImagePolygon() and gdImageFilledPolygon(). The only change the
calling convention and should be eliminated by any descent optimizer.

I have implemeted this idea in the patch attached. It is still a hack,
but more reliable than the previous one.

>=20
>> it is probably better to just link statically (or at least
>> ship the latest version of bgd.dll with gnuplot).
>=20
>=20
> That would go right against some strict advice Mr. Boutell gave about=20
> using his library on Windows, last time I looked.  He rather strongly=20
> discourages anybody trying to build their own GD from sources on Window=
s.

I have looked through the documentation and the web page but could not fi=
nd
any recomendation like that. In any case using the pre-compiled version
would be much easier.

--=20
Bastian M=C3=A4rkisch
Physikalisches Institut, Universit=C3=A4t Heidelberg

historysize

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

Patch "History file for gnuplot readline" has been just committed. So both 
readlines can use it.

I'm bit surprised what "unset historysize" is doing. It sets historysize to 
unlimited, not suppressing writing the history file.

I propose the following changes:
1. The code for history file is always compiled in (thus no need to
    --enable-history-file nor to modify dozen of files in config/).
2. By default, the history file is not read. It can be switched on in
    .gnuplot by "set historysize"
3. Switching off writing/reading history file: "unset historysize"
4. "set historysize -1" would set historysize to unlimited.

Ideas?

---
PM

Re: minitics patch

[Eddie K. <ko...@cs...>]

That's totally cool!!  Having tried it out, it looks like it could effectively 
do most anything the old patch would have done.  Thanks so much.  Hope it 
makes it in!

Eddie



Ethan A Merritt wrote:
> On Thursday 11 August 2005 04:44 pm, you wrote:
> 
>>>On Thursday 11 August 2005 02:40 pm, Eddie Kohler wrote:
>>>I.e., is the only effect of the patch to *not* turn off minor tics
>>>in the presence of user labels?  If so, then it seems like it could
>>>be done either by using the 'set format' statement, or by a 1-line
>>>change to the existing code.
>>
>>If it could be done by a 1-line change, great.  The 'set format'
>>statement doesn't work, as far as I know, if, for example, the user
>>wants to highlight one important Y-position with a tic; "set ytics
>>(1, 10, "Median" 25, 100, 1000, 10000)"
> 
> 
> First pass at such a patch uploaded to SourceForge.
> More than one line changed, but it only adds about 10 lines in total.
> Give it a while and see if I have understood what you want.
> In this form I might even use the feature myself :-)
> 

bug in new 'set tics ...' save code

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

The recently added "set tics ..." code seems to have a problem
with reading back its own save files.

Example:

gnuplot> load 'electron.dem'
Hit return to continue
^C
gnuplot> save 'bug'
gnuplot> load 'bug'
gnuplot> set tics x in
                  ^
         "bug", line 96: extraneous arguments in set tics



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

Re: minitics patch

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

On Thursday 11 August 2005 04:44 pm, you wrote:
> > On Thursday 11 August 2005 02:40 pm, Eddie Kohler wrote:
> > I.e., is the only effect of the patch to *not* turn off minor tics
> > in the presence of user labels?  If so, then it seems like it could
> > be done either by using the 'set format' statement, or by a 1-line
> > change to the existing code.
>
> If it could be done by a 1-line change, great.  The 'set format'
> statement doesn't work, as far as I know, if, for example, the user
> wants to highlight one important Y-position with a tic; "set ytics
> (1, 10, "Median" 25, 100, 1000, 10000)"

First pass at such a patch uploaded to SourceForge.
More than one line changed, but it only adds about 10 lines in total.
Give it a while and see if I have understood what you want.
In this form I might even use the feature myself :-)

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

Re: minitics patch

[Eddie K. <ko...@CS...>]

> On Thursday 11 August 2005 02:40 pm, Eddie Kohler wrote:
>
>> One portion of the minitics patch isn't obsoleted, as far as I can
>> tell.  This is the code that can place minitics automatically when
>> tics were placed explicitly.  Here's a demo:
>>
>> set logscale y
>> set yrange [1:10000]
>> set xrange [0:100]
>> set mytics 10
>> set ytics ("10^0" 1,"10^1" 10,"10^2" 100,"10^3" 1000,"10^4" 10000)
>> plot x**2
>>
>
> Is this intended to produce a different output than the current
> version does using:
>
>  set logscale y
>  set yrange [1:10000]
>  set xrange [0:100]
>  set mytics 10
> # set ytics ("10^0" 1,"10^1" 10,"10^2" 100,"10^3" 1000,"10^4" 10000)
>  set format y "10^%L"
>  plot x**2
>
> I.e., is the only effect of the patch to *not* turn off minor tics
> in the presence of user labels?  If so, then it seems like it could
> be done either by using the 'set format' statement, or by a 1-line
> change to the existing code.

If it could be done by a 1-line change, great.  The 'set format'  
statement doesn't work, as far as I know, if, for example, the user  
wants to highlight one important Y-position with a tic; "set ytics  
(1, 10, "Median" 25, 100, 1000, 10000)"

>> So what about a patch like this?
>>
>> - Update `set mxtics` documentation to say that explicit minitic
>> placement can be achieved with `set xtics`
>>
>
> Sure.  If the current docs are confusing, let's fix them.
> Also think about whether adding an explicit index entry would help
> (the cvs version of the docs makes an index).

Sure.

>> - Remove explicit `set mxtics (pos1,pos2,...)` syntax
>
> You mean remove it from your earlier patch?
> That syntax is not currently legal in the cvs code.

Yes, I meant remove it from the current patch.

>> - Allow syntax such as `set mxtics FREQ {, MAJFREQ {, OFFSET}}`,
>> which will place FREQ minitics between every "major tic", where
>> "major tics" are defined as occuring at OFFSET + i*MAJFREQ for all i.
>>
>
> You lost me there. I thought that's what the current code already
> does. Please post a sample plot that illustrates what you are aiming
> for. It's OK to dummy it up by hand; I just want to see what the  
> goal is.

The current code does do that, as long as major tics were not  
explicitly set.  If major tics were explicitly set, all automatic  
minitic generation is turned off.  (As far as I know.)  I'd like to  
tell gnuplot to go ahead and generate automatic minitics anyway,  
based on an assumed major tic frequency.

> There's another issue that is lurking. I don't see on the face of  
> it how
> you could mix manual placement of major tics with auto-generation of
> intervening minor tics.  Would each interval have a different
> spacing of tics?  That seems really strange.  And if the intervals
> are the same, then I think the current code can handle this already
> by clever use of the "set format" statement.  Post a sample plot
> and I'll see if I can come up with a way to generate it with the
> current command set.

OK, see the attached plot.  Now, one could do this with a "set ytics  
(...)" statement that placed each minitic explicitly (that's how I  
mocked it up).  But I'd like to avoid that.  A plot from the paper  
that inspired my initial patch is below that; there are varying  
formats on both axes, requiring explicit tics.

Thanks so much!
Eddie

Re: minitics patch

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

On Thursday 11 August 2005 02:40 pm, Eddie Kohler wrote:
> One portion of the minitics patch isn't obsoleted, as far as I can  
> tell.  This is the code that can place minitics automatically when  
> tics were placed explicitly.  Here's a demo:
>  
> set logscale y
> set yrange [1:10000]
> set xrange [0:100]
> set mytics 10
> set ytics ("10^0" 1,"10^1" 10,"10^2" 100,"10^3" 1000,"10^4" 10000)
> plot x**2

Is this intended to produce a different output than the current
version does using:

 set logscale y
 set yrange [1:10000]
 set xrange [0:100]
 set mytics 10
# set ytics ("10^0" 1,"10^1" 10,"10^2" 100,"10^3" 1000,"10^4" 10000)
 set format y "10^%L"
 plot x**2

I.e., is the only effect of the patch to *not* turn off minor tics
in the presence of user labels?  If so, then it seems like it could
be done either by using the 'set format' statement, or by a 1-line
change to the existing code.

> So what about a patch like this?
> 
> - Update `set mxtics` documentation to say that explicit minitic  
> placement can be achieved with `set xtics`

Sure.  If the current docs are confusing, let's fix them.
Also think about whether adding an explicit index entry would help
(the cvs version of the docs makes an index).

> - Remove explicit `set mxtics (pos1,pos2,...)` syntax

You mean remove it from your earlier patch?
That syntax is not currently legal in the cvs code.

> - Allow syntax such as `set mxtics FREQ {, MAJFREQ {, OFFSET}}`,  
> which will place FREQ minitics between every "major tic", where  
> "major tics" are defined as occuring at OFFSET + i*MAJFREQ for all i.

You lost me there. I thought that's what the current code already
does. Please post a sample plot that illustrates what you are aiming
for. It's OK to dummy it up by hand; I just want to see what the goal is.  

There's another issue that is lurking. I don't see on the face of it how
you could mix manual placement of major tics with auto-generation of
intervening minor tics.  Would each interval have a different 
spacing of tics?  That seems really strange.  And if the intervals
are the same, then I think the current code can handle this already
by clever use of the "set format" statement.  Post a sample plot
and I'll see if I can come up with a way to generate it with the
current command set. 






> 
> Eddie
> 
> 
> 
> On Aug 11, 2005, at 1:42 PM, Ethan Merritt wrote:
> 
> > On Thursday 11 August 2005 12:37 pm, Eddie Kohler wrote:
> >
> >>
> >> Over three years ago Harald Harders and I submitted a patch that
> >> supports explicit minitics, as well as minitics when tics are
> >> supplied explicitly.
> >>
> >
> > I guess I am confused about the history of this proposal.
> > I was under the impression that the original idea was to allow
> > user placement of tics at various levels (major/minor/...), and
> > that this feature had in fact been accepted into the cvs version
> > in Dec 2003 and became part of the version 4.0 release.
> >
> > What additional feature is offered by the present patch?
> > I just downloaded and looked at it, but the only description I
> > see is 2 short paragraphs in gnuplot.doc   And frankly, I do
> > not understand from that description what it allows that is not
> > already possible using a command like:
> >
> >  set xtics ("Major" 1.0 1, "Minor" 1.5 2, \
> >             "Major" 2.0 1, "Minor" 2.5 2)
> >
> > Does it allow additional tic levels?
> > Does it actually use the label strings that the current command
> > accepts but then apparently ignores?
> >
> > So it may well be a "cool project", but at least to me it is
> > not obvious what it does.  Could you provide an updated
> > sales pitch?
> >
> >     thanks
> >
> >
> >
> >
> >
> >
> >
> >> It's simple and adds obviously missing
> >> functionality in what seems a pretty sensible way.  It was not
> >> applied because the whole subsystem should be redone, or some such
> >> reason, I don't remember exactly what.  Of course the subsystem has
> >> not been redone and three years have passed.
> >>
> >> It's frustrating to try to contribute to a cool project and get
> >> neither traction nor feedback.  Could someone just go ahead and apply
> >> a version of sourceforge patch #1104018 (the current version of
> >> #594815/#835235), or tell us how improve the patch?
> >>
> >> Thanks very much, and sorry for the frustration.
> >> Eddie Kohler
> >> UCLA
> >>
> >>
> >
> > -- 
> > Ethan A Merritt       merritt@u.washington.edu
> > Biomolecular Structure Center
> > Mailstop 357742
> > University of Washington, Seattle, WA 98195
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> > Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams *  
> > Testing & QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/ 
> > bsce5sf
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >
> 
> 

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

Re: minitics patch

[Eddie K. <ko...@CS...>]

First, thanks for responding!!

I wasn't aware of this change!  Abject apologies.  So maybe I'll  
submit a patch that updates the `set mxtics` documentation to mention  
that explicit tic setting is available by `set xtics`.

One portion of the minitics patch isn't obsoleted, as far as I can  
tell.  This is the code that can place minitics automatically when  
tics were placed explicitly.  Here's a demo:


set logscale y
set yrange [1:10000]
set xrange [0:100]
set mytics 10
set ytics ("10^0" 1,"10^1" 10,"10^2" 100,"10^3" 1000,"10^4" 10000)
plot x**2


I find this quite useful (it's nice to not have to place all the  
minitics explicitly).

So what about a patch like this?

- Update `set mxtics` documentation to say that explicit minitic  
placement can be achieved with `set xtics`
- Remove explicit `set mxtics (pos1,pos2,...)` syntax
- Allow syntax such as `set mxtics FREQ {, MAJFREQ {, OFFSET}}`,  
which will place FREQ minitics between every "major tic", where  
"major tics" are defined as occuring at OFFSET + i*MAJFREQ for all i.

Eddie



On Aug 11, 2005, at 1:42 PM, Ethan Merritt wrote:

> On Thursday 11 August 2005 12:37 pm, Eddie Kohler wrote:
>
>>
>> Over three years ago Harald Harders and I submitted a patch that
>> supports explicit minitics, as well as minitics when tics are
>> supplied explicitly.
>>
>
> I guess I am confused about the history of this proposal.
> I was under the impression that the original idea was to allow
> user placement of tics at various levels (major/minor/...), and
> that this feature had in fact been accepted into the cvs version
> in Dec 2003 and became part of the version 4.0 release.
>
> What additional feature is offered by the present patch?
> I just downloaded and looked at it, but the only description I
> see is 2 short paragraphs in gnuplot.doc   And frankly, I do
> not understand from that description what it allows that is not
> already possible using a command like:
>
>  set xtics ("Major" 1.0 1, "Minor" 1.5 2, \
>             "Major" 2.0 1, "Minor" 2.5 2)
>
> Does it allow additional tic levels?
> Does it actually use the label strings that the current command
> accepts but then apparently ignores?
>
> So it may well be a "cool project", but at least to me it is
> not obvious what it does.  Could you provide an updated
> sales pitch?
>
>     thanks
>
>
>
>
>
>
>
>> It's simple and adds obviously missing
>> functionality in what seems a pretty sensible way.  It was not
>> applied because the whole subsystem should be redone, or some such
>> reason, I don't remember exactly what.  Of course the subsystem has
>> not been redone and three years have passed.
>>
>> It's frustrating to try to contribute to a cool project and get
>> neither traction nor feedback.  Could someone just go ahead and apply
>> a version of sourceforge patch #1104018 (the current version of
>> #594815/#835235), or tell us how improve the patch?
>>
>> Thanks very much, and sorry for the frustration.
>> Eddie Kohler
>> UCLA
>>
>>
>
> -- 
> Ethan A Merritt       merritt@u.washington.edu
> Biomolecular Structure Center
> Mailstop 357742
> University of Washington, Seattle, WA 98195
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: minitics patch

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

On Thursday 11 August 2005 12:37 pm, Eddie Kohler wrote:
> 
> Over three years ago Harald Harders and I submitted a patch that  
> supports explicit minitics, as well as minitics when tics are  
> supplied explicitly.

I guess I am confused about the history of this proposal.
I was under the impression that the original idea was to allow
user placement of tics at various levels (major/minor/...), and
that this feature had in fact been accepted into the cvs version
in Dec 2003 and became part of the version 4.0 release.

What additional feature is offered by the present patch?
I just downloaded and looked at it, but the only description I
see is 2 short paragraphs in gnuplot.doc   And frankly, I do
not understand from that description what it allows that is not
already possible using a command like:

 set xtics ("Major" 1.0 1, "Minor" 1.5 2, \
            "Major" 2.0 1, "Minor" 2.5 2)

Does it allow additional tic levels?
Does it actually use the label strings that the current command
accepts but then apparently ignores?

So it may well be a "cool project", but at least to me it is
not obvious what it does.  Could you provide an updated
sales pitch?

	thanks






> It's simple and adds obviously missing   
> functionality in what seems a pretty sensible way.  It was not  
> applied because the whole subsystem should be redone, or some such  
> reason, I don't remember exactly what.  Of course the subsystem has  
> not been redone and three years have passed.
> 
> It's frustrating to try to contribute to a cool project and get  
> neither traction nor feedback.  Could someone just go ahead and apply  
> a version of sourceforge patch #1104018 (the current version of  
> #594815/#835235), or tell us how improve the patch?
> 
> Thanks very much, and sorry for the frustration.
> Eddie Kohler
> UCLA
> 

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

minitics patch

[Eddie K. <ko...@cs...>]

Hi,

Over three years ago Harald Harders and I submitted a patch that  
supports explicit minitics, as well as minitics when tics are  
supplied explicitly.  It's simple and adds obviously missing  
functionality in what seems a pretty sensible way.  It was not  
applied because the whole subsystem should be redone, or some such  
reason, I don't remember exactly what.  Of course the subsystem has  
not been redone and three years have passed.

It's frustrating to try to contribute to a cool project and get  
neither traction nor feedback.  Could someone just go ahead and apply  
a version of sourceforge patch #1104018 (the current version of  
#594815/#835235), or tell us how improve the patch?

Thanks very much, and sorry for the frustration.
Eddie Kohler
UCLA

Re: using bgd.dll on windows

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

Bastian Maerkisch wrote:
> Ethan A Merritt wrote:
>> On Thursday 11 August 2005 09:06 am, Bastian Maerkisch wrote:

>>> While trying to compile gnuplot on Windows using MSVC 6.0
>>> and the precompiled gdlib (gdwin32.zip package) I ran into
>>> problems concerning calling convention. The supplied
>>> bgd.dll now uses __stdcall whereas gnuplot uses __cdecl.

If so, then there has to be some macro or typedef exported by the GD 
headers that tells us what exactly the type of the callback functions 
has to be.  If not, that's a bug in GD which we should report, instead 
of hacking around it.

> it is probably better to just link statically (or at least
> ship the latest version of bgd.dll with gnuplot).

That would go right against some strict advice Mr. Boutell gave about 
using his library on Windows, last time I looked.  He rather strongly 
discourages anybody trying to build their own GD from sources on Windows.

Re: Spurious lines between joined filled rectangles and antialiasing

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

On Thursday 11 August 2005 01:21 am, Petr Mikulik wrote:
> Does somebody knows whether this directive
>
>  	 << ... /Interpolate false ... >>
>
> would help? 

As I understand it, this is an optional dictionary value that is
passed on to the interpreter (printer, or in this case ghostscript).
So any effect it has will vary depending on the output device.
Newer versions of ghostscript claim to process this value, but I have
not found any explicit statement of exactly what they do with it. 

> (And how/where to use it? Inside some gsave/grestore?)

I think you would have to load it into a dictionary during the prolog.
So far as I know, dictionary values are unaffected by gsave/grestore.

It is disappointing that this is all so poorly documented. The closest
I can find is from the notes to ghostscript version 6, which is quite
out of date. And even so it's not very helpful:

  The image operator honors the Interpolate flag in the image dictionary
  only for ImageType 1 and 3 images, only if the combined transformation
  (ImageMatrix + CTM) doesn't involve rotation, skewing, or X-reflection,
  and only for certain scalings and color spaces; imagemask doesn't
  honor Interpolate at all.




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

Re: using bgd.dll on windows

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

Ethan A Merritt wrote:
> On Thursday 11 August 2005 09:06 am, Bastian Maerkisch wrote:
>=20
>>While trying to compile gnuplot on Windows using MSVC 6.0
>>and the precompiled gdlib (gdwin32.zip package) I ran into
>>problems concerning calling convention. The supplied
>>bgd.dll now uses __stdcall whereas gnuplot uses __cdecl.
>=20
>=20
> I can't help with any windows testing, but I do want to point
> out that gdlib itself has changed the dll mechanism between
> versions, perhaps more than once.  More info on the web site=20
> <http://www.boutell.com/gd/>
> So I worry that you risk breaking the use of one version
> of libgd while 'fixing' another.

According to that web site this is a "one-time breakage of
binary compatibility" introduced in version 2.0.24. As there
might still be older versions installed on a user's machine
it is probably better to just link statically (or at least
ship the latest version of bgd.dll with gnuplot).

So please forget about that patch. It will just create
another FAQ....

--=20
Bastian M=C3=A4rkisch
Physikalisches Institut, Universit=C3=A4t Heidelberg

Re: using bgd.dll on windows

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

On Thursday 11 August 2005 09:06 am, Bastian Maerkisch wrote:
> While trying to compile gnuplot on Windows using MSVC 6.0
> and the precompiled gdlib (gdwin32.zip package) I ran into
> problems concerning calling convention. The supplied
> bgd.dll now uses __stdcall whereas gnuplot uses __cdecl.

I can't help with any windows testing, but I do want to point
out that gdlib itself has changed the dll mechanism between
versions, perhaps more than once.  More info on the web site 
<http://www.boutell.com/gd/>
So I worry that you risk breaking the use of one version
of libgd while 'fixing' another.

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

using bgd.dll on windows

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

While trying to compile gnuplot on Windows using MSVC 6.0
and the precompiled gdlib (gdwin32.zip package) I ran into
problems concerning calling convention. The supplied
bgd.dll now uses __stdcall whereas gnuplot uses __cdecl.

The attached patch fixes this issue. Could you please check
if it doesn't break anything?

Re: Spurious lines between joined filled rectangles and antialiasing

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

Does somebody knows whether this directive

 	 << ... /Interpolate false ... >>

would help? (And how/where to use it? Inside some gsave/grestore?)

---
PM

Re: tilde expansion failure

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

Bastian Maerkisch wrote:
> I would propose the following behaviour:
> 
>     1) Try %HOME% directory from environment. That way
>        gnuplot can adjust to user preferences and it won't
>        break unix-like builds on Windows (cygwin)

You're forgetting defined behaviour.  See "help environment", and what 
it says abyout %GNUPLOT%.

>     3) Issue a warning message (no HOME found) and give up. This
>        means gnuplot now requires HOME to be set for certain
>        functionality.

No.  That would be too harsh.  The wording of that warning may have to 
change, but bailing out is IMHO unacceptable, when the only problem is 
that a feature the majority of Windows users don't know about would fail 
to work.  They'll notice as they get there.

Re: tilde expansion failure

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

Hans-Bernhard Broeker wrote:
> Bastian M=E4rkisch wrote:
>=20
>> Currently tilde expansion of paths like "~/gnuplot.history" via=20
>> gp_expand_tilde() on Windows 9x will fail unless the user sets the=20
>> HOME environment variable.
>=20
>=20
> And because that's bad,  wgnuplot prints this message in such case,=20
> right on the startup screen:
>=20
>          warning: no HOME found
>=20
>=20
>> The string containing the path is left unchanged and does therefore=20
>> not contain
>> a valid path.=20
>=20
>=20
> There's not much that could usefully be done about that --- there's no =

> single replacement that would be equally applicable for all Windows=20
> platforms.
>=20
> Now that we have the code to locate a suitable fall-back location (for =

> wgnuplot.ini), arguably all other state save files should go there, too=

> (i.e. gnuplot.ini, the cross-session history file, and whatever else).

Agreed. Possibly it would be even better to have a %APPDATA%\gnuplot
directory in that case.

>=20
>> 2) Use a default directory instead, where 'default' could be the curre=
nt
>> directory or the directory where gnuplot.exe resides.=20
>=20
>=20
> That's pretty much guaranteed to be wrong (not to mention isn't even=20
> accessible to normal users on a properly installed, modern Windows).

That's why I propsed it as as a fall-back for older versions of Windows
(like Win9x) only ...

I would propose the following behaviour:

	1) Try %HOME% directory from environment. That way
	   gnuplot can adjust to user preferences and it won't
	   break unix-like builds on Windows (cygwin)

	2) Try SHGetSpecialFolderPath() or %APPDATA%, if available.
	   Optionally use %APPDATA%\gnuplot directory instead.

	3) Issue a warning message (no HOME found) and give up. This
	   means gnuplot now requires HOME to be set for certain
	   functionality.

Is that reasonable now?


--=20
Bastian M=E4rkisch
Physikalisches Institut, Universit=E4t Heidelberg
Philosophenweg 12
69120 Heidelberg
Tel.: +49-6221-549239
Fax: +49-6221-549343

Re: tilde expansion failure

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

Bastian M=E4rkisch wrote:
> Currently tilde expansion of paths like "~/gnuplot.history" via gp_expa=
nd_tilde()=20
> on Windows 9x will fail unless the user sets the HOME environment varia=
ble.

And because that's bad,  wgnuplot prints this message in such case,=20
right on the startup screen:

          warning: no HOME found


> The string containing the path is left unchanged and does therefore not=
 contain
> a valid path.=20

There's not much that could usefully be done about that --- there's no=20
single replacement that would be equally applicable for all Windows=20
platforms.

Now that we have the code to locate a suitable fall-back location (for=20
wgnuplot.ini), arguably all other state save files should go there, too
(i.e. gnuplot.ini, the cross-session history file, and whatever else).

> 2) Use a default directory instead, where 'default' could be the curren=
t
> directory or the directory where gnuplot.exe resides.=20

That's pretty much guaranteed to be wrong (not to mention isn't even=20
accessible to normal users on a properly installed, modern Windows).

Re: Error compiling with MinGW

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

Hans-Bernhard Broeker <br...@ph...> schrieb am 09.08.05 2=
0:12:32:
>=20
> Bastian M=E4rkisch wrote:
> > Dietmar Warning reported compilation errors due to the new code
> > for locating wgnuplot.ini on Windows. The appended small patch=20
> > should fix that.=20
>=20
> Hmm... but that fix appears to be exactly the wrong way round?  Or=20
> doesn't MinGW  #define __MINGW__ any more, these days?
>=20
> Anyway, I'll check in a different fix to the same problem right away
> (I also ran into compilation problems, on OpenWatcom).
>=20

Putting the #ifdef __MINGW__ there in the first place wasn't a good
idea. _WIN32_IE should be defined unconditionally. That's the standard
way of doing things (according to MSDN). Why it worked with MSVC
is not clear ;)

Greetings, Bastian

Re: Error compiling with MinGW

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

>> Dietmar Warning reported compilation errors due to the new code
>> for locating wgnuplot.ini on Windows. The appended small patch should fix 
>> that. 
>
> Hmm... but that fix appears to be exactly the wrong way round?  Or doesn't 
> MinGW  #define __MINGW__ any more, these days?

It's a typo there! It should have been  __MINGW32__

SF is not responding now, so I cannot fix it; to be done later.

---
PM

tilde expansion failure

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

Currently tilde expansion of paths like "~/gnuplot.history" via gp_expand_tilde() 
on Windows 9x will fail unless the user sets the HOME environment variable.
The string containing the path is left unchanged and does therefore not contain
a valid path. 

This problem came up while I was working on the GNUPLOT_HISTORY patch (see SF).
It applies to locating wgnuplot.ini as well as tilde expansion in "load/save" commands.
I could think of different solutions:

1) Issue a warning that a certain functionality (e.g. saving of history) of gnuplot 
requires HOME to be set and do nothing if it is not. (I.e. don't load/save history.)

2) Use a default directory instead, where 'default' could be the current
directory or the directory where gnuplot.exe resides. The first being more
reasonable for "load/save" commands and the later for locating the history
file and wgnuplot.ini.

3) Use a completely different approach to locate files on Windows and disable
tilde expansion there as most users of that platform don't know that 
concept anyway. (No, this would not introduce a lot of #ifdefs. Only
gp_expand_tilde would have to be modfied.

What would be a good solution?


Bastian

Re: Error compiling with MinGW

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

Bastian M=E4rkisch wrote:
> Dietmar Warning reported compilation errors due to the new code
> for locating wgnuplot.ini on Windows. The appended small patch=20
> should fix that.=20

Hmm... but that fix appears to be exactly the wrong way round?  Or=20
doesn't MinGW  #define __MINGW__ any more, these days?

Anyway, I'll check in a different fix to the same problem right away
(I also ran into compilation problems, on OpenWatcom).

Error compiling with MinGW

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

Dietmar Warning reported compilation errors due to the new code
for locating wgnuplot.ini on Windows. The appended small patch 
should fix that. 

Bastian