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

Povray terminal update

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

    I have made good progress on the povray terminal. I have updated it
on the web :=20
http://www.eleves.ens.fr/home/varoquau/gnuplot/povray.trm

    You can also find an automatically generated list of demo files and
output at :
http://www.eleves.ens.fr/home/varoquau/gnuplot/index.html

    This was automatically generated using a modified version of the
webify script. My perl skills are really horrible, so some files did not
compile properly. This does not always mean that the povray terminal
fails on them (I checked manually in certain case).

    As you can see the povray terminal is almost a fully featured
gnuplot terminal. I have yet add the support for 'set palette
maxcolors', nor even have I looked into that :->, but I do not think it
is a major difficulty.

    I would appreciate if other people could have a look at the code,
and report any bugs they find, I would like to move on to the 3D code.

    I will be gone on holidays and September means, unfortunately, the
start of the teaching period, so I will be quite short on time, but I
think that I will want to start hacking gnuplot's code to add 3D. Any
suggestions on the way to proceed with this are welcomed.
    I would also like some advise on how to work collectively on
gnuplot's code, as I want to be able to work closely with others (Robert
?) on that.
    This seems to me as a huge project but I think we really must go
ahead and do it.

--
    Ga=EBl

Re: historysize

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

On Tue, Aug 16, 2005 at 12:31:18AM -0500, Daniel J Sebald wrote:
>  The data file "using"=20
> format is like this; 0 means point, -1 means line number, -2 means inde=
x=20
> number.  I find that not user friendly.

    Agreed. I prefer words. And I have often heard users of gnuplot
complain about such numbers that they cannot remember.

--
    Ga=EBl

crash in write_history_n

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

The version of write_history_n() using gnuplot's own version
of readline issues an int_error() when it cannot open the
history file for saving. As it is now called at program exit
(via atexit() or similar) it can no longer
bail_to_command_line(), which int_error() does. This causes
a segfault in that case. (Tested ;-) on a Win98 system without
%GNUPLOT% env. variable set.)
So this should be an int_warn(). The attached patch fixes that.

Greetings, Bastian

Re: Tics, minor tics, labels...

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

Ethan A Merritt wrote:
> Two questions:
> 
> 1) The documentation says you can assign labels to minor tics
>       set xtics ("Major" x1 0, "Minor" x2 1, ...)
>    but the code explicitly ignores minor tic labels.  Was there any
>    reason why?  You can always give an empty string if you don't
>    want a label there. I propose that if the user specifies a label,
>    we should print it.

Might as well.  Why limit flexibility?  And it may be easier to have it than to disallow it.

> 2) I am inclined to apply the patchset currently listed as #1104018,
>    having worked with the original proposer, Eddie Kohler, to pare it
>    down to a very simple modification to the existing code.
>    In a nutshell, it now adds a keyword "include" to the 'set <xyz>tics'
>    command. In the presense of this keyword, the command does
>    not clear the existing list of user-specified tics (if any).
>    So
> 	set xtics auto
> 	set xtics include ("Pi" pi 0)
> 	set xtics include ("2Pi" pi*2 0)
>
>    Please speak up if you have any objections or counter-proposals.
>    Also please suggest a better name for the keyword if you can think
>    of one.  "add" is the another possibility on the table at the
>    moment.

"with" ?  e.g.,

set xtics with ("Pi" pi 0)

Dan

Re: historysize

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

Ethan A Merritt wrote:
> On Friday 12 August 2005 01:55 am, Petr Mikulik wrote:
> 
>>4. "set historysize -1" would set historysize to unlimited.

I've no strong opinions on historysize other than using "-1" as special meaning.  It probably is easy from the parser's standpoint, but I don't like when negative numbers have special meaning.  The data file "using" format is like this; 0 means point, -1 means line number, -2 means index number.  I find that not user friendly.  How do others feel?

I'd suggest "unlimited", "infinity", "infinite" rather than -1.

Dan

Re: Tics, minor tics, labels...

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

On Sunday 14 August 2005 03:38 pm, you wrote:
> On Sat, 13 Aug 2005, Ethan A Merritt wrote:
> > 	set xtics auto
> > 	set xtics include ("Pi" pi 0)
> > 	set xtics include ("2Pi" pi*2 0)
> >    will auto-generate tics and include specific labels at pi and 2pi.
>
> Similar commands are things like "set label", which IIRC behaves in a
> much different way - no extra keyword is needed. Of course, using the
> same sort of syntax as set label would break any existing scripts that
> contain multiple explicit tics statements, which I imagine are
> relatively uncommon.

Yeah. This is where the goal of backwards compatibility runs headlong
into the goal of fixing design bugs.  I think it is a bug that successive
user tic specifications are not cumulative.  But that is not nearly so 
clear for the case of switching between automatic and manual tic placement.
If we were to make the default behaviour cumulative, then we would have to
add a mechanism to explicitly turn *off* the previous tic scheme before
selecting a new one:
	set xtics auto
	plot "foo"
	set xtics noauto
	set xtics ("Manual placement" ...)
	replot

That would definitely break backwards compatibility.


> b) Is it actually the "verb" that needs to be changed, as in:
> unset xtics
> set xtics auto
> add xtics ("pi" pi 0)
> add xtics ("2pi" 2*pi 0)
> show xtics

I like that idea, but it's too radical a change to the syntax.
If we were to introduce "add" as a major command, people
would expect to be able to use it for other purposes as well.

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

Re: Tics, minor tics, labels...

[Robert H. <en...@no...>]

On Sat, 13 Aug 2005, Ethan A Merritt wrote:

> 	set xtics auto
> 	set xtics include ("Pi" pi 0)
> 	set xtics include ("2Pi" pi*2 0)
>    will auto-generate tics and include specific labels at pi and 2pi.
>    Omitting the keyword retains the current behaviour; each
>    command supersedes the previous ones.
> 
>    Please speak up if you have any objections or counter-proposals.
>    Also please suggest a better name for the keyword if you can think
>    of one.  "add" is the another possibility on the table at the
>    moment.

I suppose the other way of looking at is:

a) Is this a syntax that could consistenly be applied to other commands
should this kind of "addition" behaviour be applicable to them. 

Similar commands are things like "set label", which IIRC behaves in a much
different way - no extra keyword is needed. Of course, using the same sort
of syntax as set label would break any existing scripts that contain
multiple explicit tics statements, which I imagine are relatively
uncommon.

b) Is it actually the "verb" that needs to be changed, as in:
unset xtics
set xtics auto
add xtics ("pi" pi 0)
add xtics ("2pi" 2*pi 0)
show xtics

This is, I guess, more akin to the plot and replot case in the current
syntax. I'm guessing (although I haven't really looked at the code) that
this would be more trouble to implement.

Rob


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: historysize

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

> I am working on a patch to have gnuplot compiled with libedit from
> NETBSD. So could the #ifdef GNUPLOT_HISTORY statements be left in
> there? This would save us some very long #ifdefs ...

If you manage to make a patch for removing that #ifdef first, then there is 
no need for them.

>>> 2. By default, the history file is not read. It can be switched on in
>>>    .gnuplot by "set historysize"
>
> How would the environment variable 'GNUPLOT_HISTORY_SIZE' fit in
> there? Could this be treated like "set historysize" in .gnuplot?

Should it be set before or after reading .gnuplot?

> Wouldn't is make sense to limit the size of 'in-memory' history
> to historysize as well? But that wouldn't work with your

is this necessary?

> approach. So how about seperate commands for enabling/disabling
> saving of history? E.g. sth. like "set history on/off".

Good idea. That GNUPLOT_HISTORY could contain "no" in this case.

---
PM

Re: historysize

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

Ethan A Merritt wrote:
 > 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/).

I am working on a patch to have gnuplot compiled with libedit from
NETBSD. So could the #ifdef GNUPLOT_HISTORY statements be left in
there? This would save us some very long #ifdefs ...

 >>2. By default, the history file is not read. It can be switched on in
 >>    .gnuplot by "set historysize"

How would the environment variable 'GNUPLOT_HISTORY_SIZE' fit in
there? Could this be treated like "set historysize" in .gnuplot?

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

Wouldn't is make sense to limit the size of 'in-memory' history
to historysize as well? But that wouldn't work with your
approach. So how about seperate commands for enabling/disabling
saving of history? E.g. sth. like "set history on/off".

Btw. the gnuplot readline code already does use historysize to
limit the size of history in memory, whereas (as far is can tell)
the GNU readline version does not. There it's only used for saving.

Bastian

Tics, minor tics, labels...

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

Two questions:

1) The documentation says you can assign labels to minor tics
      set xtics ("Major" x1 0, "Minor" x2 1, ...)
   but the code explicitly ignores minor tic labels.  Was there any
   reason why?  You can always give an empty string if you don't
   want a label there. I propose that if the user specifies a label,
   we should print it.

2) I am inclined to apply the patchset currently listed as #1104018,
   having worked with the original proposer, Eddie Kohler, to pare it
   down to a very simple modification to the existing code.
   In a nutshell, it now adds a keyword "include" to the 'set <xyz>tics'
   command. In the presense of this keyword, the command does
   not clear the existing list of user-specified tics (if any).
   So
	set xtics auto
	set xtics include ("Pi" pi 0)
	set xtics include ("2Pi" pi*2 0)
   will auto-generate tics and include specific labels at pi and 2pi.
   Omitting the keyword retains the current behaviour; each
   command supersedes the previous ones.

   Please speak up if you have any objections or counter-proposals.
   Also please suggest a better name for the keyword if you can think
   of one.  "add" is the another possibility on the table at the
   moment.


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

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. <kohler@CS.UCLA.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.

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. <kohler@CS.UCLA.EDU>]

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