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

Re: "gnuplot development" page on the revised SourceForge layout

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

> http://sourceforge.net/projects/gnuplot/
>
> The page title is "gnuplot development".

The "3.8k" message should be removed.

Added should be:
 	You can follow current activity in gnuplot 4.1 development at
 	http://gnuplot.sourceforge.net/development/

>>> The "Operating System" section lists us as
>>>  All 32-bit MS Windows (95/98/NT/2000/XP),
>>>  OS Portable (Source code to work with many OS platforms)

Also see there:
 	Programming Language  : C, C++, Visual Basic

Could someone edit all these information?

---
PM

Re: "gnuplot development" page on the revised SourceForge layout

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

> Any chance that one of you can clean up some of the
> dubious listing on the "gnuplot development" page?

I don't see anything you mention below on
 	http://gnuplot.sourceforge.net/development/index.html

> The existence of a 3.8k snapshot is hardly breaking

in binaries/ ?  I've removed that 38k-gpbin.zip, as it was actually just a 
dummy version.

> The "Operating System" section lists us as
>  All 32-bit MS Windows (95/98/NT/2000/XP),
>  OS Portable (Source code to work with many OS platforms)

???

---
PM

"gnuplot development" page on the revised SourceForge layout

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

Any chance that one of you can clean up some of the
dubious listing on the "gnuplot development" page?

The existence of a 3.8k snapshot is hardly breaking
news, and should not be highlighted at the top left.
I'd love to see it replaced by a pointer to a 4.1 snapshot,
but that's a separate question.

The "Operating System" section lists us as
  All 32-bit MS Windows (95/98/NT/2000/XP),
  OS Portable (Source code to work with many OS platforms)

This seems misleading to me.  There is no
32-bit restriction in the code, and the focus is not
on MS Windows no matter how you look at it. I'd opt to
list only "OS portable".  If we're going to mention
windows in particular, then might as well also tick
off the categories "All POSIX" and "Classic" (includes Atari).

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

Re: wxWidgets terminal : "persist" behaviour

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

On Tuesday 10 January 2006 07:28 am, Hans-Bernhard Broeker wrote:
> Timoth=E9e Lecomte wrote:
>
> > * With multiple plot windows, the expected behaviour is for gnuplot
> > to finish when the user closes the last opened window, isn't it ?

Maybe.  By analogy to the single-window X11 behavior, I would expect
each persistent window to stay open until explicitly closed, regardless
of whether the lead session was still there or not.=20

> The best is to implement it as an option to 'set term wxt', like the
> other drivers are already handling it.  Being able to do this in the
> startup command arguments of the program is a benefit, but not a
> strict necessity.

I agree.  What I would expect would be that if a script said
  set term wxt persist
  plot "one"
  set term wxt
  plot "two"
  set term wxt persist
  plot "three"
  exit

Then at the completion of the script, plot window two would close
immediately but plot windows one and three would stay open=20
until explicitly closed by user action.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: palette allocation during mouse rotation

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

> Here's a patch for that gnuplot "allocating colors..." redraw problem with 
> rotation.  The princple is as follows:

It looks OK. I passed "pm3dcolors.dem" on it (with "set pm3d map" => "set 
pm3d"), rotated by mouse, it's no more reallocating colors and no strange 
thing happened.

BTW, I prefer to surround unused code by #if 0 #endif instead of /**  */; 
it's more readable.

> OK, so that's one problem down and two to go.  I'll see if I can get to 
> another one next weekend.

Please resend the patch when it's final for cvs.

---
PM

Re: wxWidgets terminal : "persist" behaviour

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

Timoth=E9e Lecomte wrote:
> gnuplot ./script.plt
>=20
> where in script.plt stands a line saying "set term wxt"

On a side note: why would that be needed?  Isn't wxt the default=20
terminal in the gnuplot version including that driver?

> As you may have guess, gnuplot draws to the windows, and immediately
> ends after that, closing the plot window with it. As expected, the
> "-persist" option has no effect as it only acts on the specific
> gplot_x11 executable.

-persist is implemented by some other drivers, too.  As of current CVS,
BeOS, OS/2 and Windows native GUI drivers have it, in addition to X11.

> * The expected behaviour is to let the plot window opened until the use=
r
> closes it via the window manager ('X' in the upper right corner
> usually), and then to finish the process, right ?

In the multi-threaded environment you're in, it should rather just close =

that thread, and leave it to the OS, or possibly some watchdog thread,=20
to remove the process after its last thread is gone.

> * With multiple plot windows, the expected behaviour is for gnuplot to
> finish when the user closes the last opened window, isn't it ?

Yes.

> * Is it better to implement it via a command line option, like
> "-persist", or via a new command, which could be called "persist", and
> would mean "Exit when all the plot windows of the currently selected
> terminal are closed" ?

The best is to implement it as an option to 'set term wxt', like the=20
other drivers are already handling it.  Being able to do this in the=20
startup command arguments of the program is a benefit, but not a strict=20
necessity.

wxWidgets terminal : "persist" behaviour

[<tim...@en...>]

Dear gnuplot enthusiasts,

I tested my terminal with a script loaded from the command line,
something like :

gnuplot ./script.plt

where in script.plt stands a line saying "set term wxt"

As you may have guess, gnuplot draws to the windows, and immediately
ends after that, closing the plot window with it. As expected, the
"-persist" option has no effect as it only acts on the specific
gplot_x11 executable.

I am now trying to implement a "-persist" behaviour, and am thinking of
the best way to do it. Please note that unlike the X11 implementation,
my terminal is a thread of the gnuplot process, and not a separate proces=
s.

Some questions that make my mind busy :

* The expected behaviour is to let the plot window opened until the user
closes it via the window manager ('X' in the upper right corner
usually), and then to finish the process, right ?

* With multiple plot windows, the expected behaviour is for gnuplot to
finish when the user closes the last opened window, isn't it ?

* Is it better to implement it via a command line option, like
"-persist", or via a new command, which could be called "persist", and
would mean "Exit when all the plot windows of the currently selected
terminal are closed" ?

Some ideas about it ?

Best regards,

Timoth=E9e Lecomte

Re: ftp://ftp.gnuplot.info/pub/gnuplot/testing

[Clark G. <ga...@di...>]

On Mon, 9 Jan 2006 16:59:25 +0000, "Lars Hecking"
<lhe...@us...> said:
>  I discussed this with Clark when I left my old job. He gave me an
>  account
>  on a machine called preprod.gnuplot.info, and I copied snapshots of the
>  UCC www and ftp sites to that machine.
> 
>  Clark is the only one with shell access to ftp.gnuplot.info IIRC,
>  I think, if he could enlighten us on the status of that box ...

That's correct.  As a production service, I use a level of indirection
for site synchronization.  As mentioned in previous note, I'll happily
give others access to preprod.

Incidentally, Lars, did you have ftp stuff on preprod that you wanted
synchronized with production?  I was thinking we would generally do
manual syncs of preprod-to-prod, in order to keep preprod a testing
environment.  If that is the case only for ftp, well that's ok.  I
control both ends there, so that's easy enough to instrument.  The sf
approach is also nice, though, as it protects from the
Clark-getting-hit-by-bus problem.

--ckg
--
Clark Gaylord
Blacksburg, VA USA
ga...@di...

Re: ftp://ftp.gnuplot.info/pub/gnuplot/testing

[Clark G. <ga...@di...>]

On Mon, 09 Jan 2006 17:48:29 +0100, "Hans-Bernhard Broeker"
<br...@ph...> said:
> Petr Mikulik wrote:
> > I propose to clean $SUBJ.
> 
> Easier said than done.  That site was supposed to be mirroring another 
> one (Lars' one in ireland).  First the mirroring broke (which is why it 
> still has the first 4.0 windows binary package with the 'non-english 
> help' bug), then Lars lost control over the box it's supposedly
> mirroring.
> 
> I think right now we either have to get control over ftp.gnuplot.info, 
> or to declare it a lost cause (--> remove all links to it).

I replied to Petr off-list previously.  We do have ftp.gnuplot.info just
fine, but you are correct that we do not have a staging location to sync
from.  We do have preprod.gnuplot.info, which David and Lars use for
mail and shell access (respectively, I believe).  I don't have any
problem giving accounts to others as necessary there, or we can use
sourceforge like we do for web.  In previous discussions I asked what we
wanted to do with it and no one seemed to be motivated to fix it; I'm
pleased that Petr is willing to take this on.

I think we might have gotten the mirroring working briefly before Lars
lost his access to the source, but maybe not.  At any rate, it's clearly
busted now due to lack of source data.  If you have a place you want me
to sync from, that's cool; if you want to use preprod, that's cool too. 
Just let me know what you want done.

--ckg
--
Clark Gaylord
Blacksburg, VA USA
ga...@di...

Re: ftp://ftp.gnuplot.info/pub/gnuplot/testing

[Lars H. <lhe...@us...>]

Hans-Bernhard Broeker writes:
> Petr Mikulik wrote:
> >I propose to clean $SUBJ.
> 
> Easier said than done.  That site was supposed to be mirroring another 
> one (Lars' one in ireland).  First the mirroring broke (which is why it 
> still has the first 4.0 windows binary package with the 'non-english 
> help' bug), then Lars lost control over the box it's supposedly mirroring.
> 
> I think right now we either have to get control over ftp.gnuplot.info, 
> or to declare it a lost cause (--> remove all links to it).
 
 I discussed this with Clark when I left my old job. He gave me an account
 on a machine called preprod.gnuplot.info, and I copied snapshots of the
 UCC www and ftp sites to that machine.

 Clark is the only one with shell access to ftp.gnuplot.info IIRC,
 I think, if he could enlighten us on the status of that box ...

Re: ftp://ftp.gnuplot.info/pub/gnuplot/testing

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

Petr Mikulik wrote:
> I propose to clean $SUBJ.

Easier said than done.  That site was supposed to be mirroring another 
one (Lars' one in ireland).  First the mirroring broke (which is why it 
still has the first 4.0 windows binary package with the 'non-english 
help' bug), then Lars lost control over the box it's supposedly mirroring.

I think right now we either have to get control over ftp.gnuplot.info, 
or to declare it a lost cause (--> remove all links to it).

Re: observations

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

Daniel J Sebald wrote:
> To get 'all.dem' to run requires that the binary files be built.  That 
> means a "make all" is required in the demo directory.  

It's not.  The usual 'make' in the main directory (that's gnuplot, not 
gnuplot/src!) will already do that for you.

 > Is there a reason
> building the binary files were left out of the general build process?  

They're not, so no reason needed.

> Do they fail on some systems?  Maybe put a note in demo/Makefile why 
> they are left out.

The recommended way for a developer to run 'all.dem' is to 'make check'
(from $top_builddir or $top_builddir/demo).  Making sure all needed 
pieces are present when needed is what 'make' is designed to do, after 
all ;-)

Re: Patch #1393181 Change default colorbox size

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

Ethan A Merritt wrote:
> That way the user can easily tweak the place using, e.g.
> 	set colorbox user orig 1.1 graph, 0.0 graph
> 	set colorbox user size 0.2 graph, 0.8 graph

Err.. please make that syntax match the usual one, i.e.

	set colorbox user orig graph 1.1

Better yet, actually use the low-level input functions for <coordinate> 
values as used by 'set label' and 'set arrow', and support all their 
options, so all you have to put in the docs would be

	set colorbox user orig <coord_x>, <coord_y>

and point to 'help coordinates' for details what <coord_x> can be.

Re: observations

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

On Saturday 07 January 2006 04:04 am, Daniel J Sebald wrote:
> 
> To get 'all.dem' to run requires that the binary files be built.  
> That means a "make all" is required in the demo directory.

So what?

> Is there a reason building the binary files were left out of the
> general build process?

"make all" in the demo directory *is* part of the general build process.
 
> There appears to be a new multiline title, which is nice.  

I think you mean "multiplot title".  The number of lines is not relevant.
It's not getting cleared by "unset multiplot".  I'll fix that.

> Attached is a patch that fixes a strange line in gplt_x11.c that messes
> up highlighting in gvim; it appeared to have incorrect parentheses but
> somehow managed to compile and run.

Thanks. Applied.

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

updated gnuplot.sourceforge.net/development/

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

I've updated $SUBJ page.
Notice also the new directory
 	http://gnuplot.sourceforge.net/development/binaries/

intended for storing precompiled preliminary development binaries.

---
PM

ftp://ftp.gnuplot.info/pub/gnuplot/testing

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

I propose to clean $SUBJ.
Most files are obsolete, other should go to Patches.

---
PM

observations

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

Here's some odds and ends I see when looking through the latest CVS.

To get 'all.dem' to run requires that the binary files be built.  That means a "make all" is required in the demo directory.  Is there a reason building the binary files were left out of the general build process?  Do they fail on some systems?  Maybe put a note in demo/Makefile why they are left out.

There appears to be a new multiline title, which is nice.  However, the multiline title illustrating the example appears to linger and reappear on occassion.  When running all and getting image.dem the line "Same plot with a multi-line title\nshowing adjustment of plot area\n to accommodate it" shows up on top of other titles.  It happens in multiplot mode...  Try doing

load 'layout.dem'
load 'image.dem'

or

load 'layout.dem'
load 'multiplt.dem'

Attached is a patch that fixes a strange line in gplt_x11.c that messes up highlighting in gvim; it appeared to have incorrect parentheses but somehow managed to compile and run.  Don't know how.  The patch makes highlighting correct.

Dan





-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

Re: palette allocation during mouse rotation

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

Here's a patch for that gnuplot "allocating colors..." redraw problem with rotation.  The princple is as follows:

On the _terminal driver side_ of the pipe is the following test:

/* Only send the palette if it is different from the last palette,
 * one hasn't been sent yet, or if the plot number is different from
 * the plot number the last time the palette was set.
 */

If one thinks through the logic for that, you'll find it avoids flaky behavior on part of the palette, even in multiplot mode.

That keeps gplt_x11.c from having to reconstruct the color tables unless necessary.  The refresh speedup is clearly back to what it once was.

I would add that another part of this equation is that the gnuplot core doesn't need to send the palette so often.  If it followed the formula that it only send the palette when the _terminal_ changes or the palette commands are entered, it would reduce more wasted CPU.  (If some devices need a copy of the palette for every plot, the driver should keep a copy internally.)  Don't want to get into that, however.  (Note the rule would change if developers went the path of the core used plots as objects, Hans' desire.)

[Petr, I added a couple helper functions.  Could you have a look at the following functions and see if you agree everything is copied and/or deleted properly?

/* create on the heap, a copy of a palette */
duplicate_palette(t_sm_palette *p)
/* remove a palette from the heap */
destroy_palette(t_sm_palette *p)
udft_del(udft_entry *p_del)
udft_cpy(udft_entry *dest, udft_entry *src)

They are right next to palettes_differ().  The part that confuses me is how the Afunc, Bfunc, Cfunc are used.  They appear to be linked list elements, but the list pointers don't appear to be assigned anywhere, and I don't understand why (if they are linked-list elements) they would be tacked into a structure somewhere.  So they must be ignored.

/* user-defined function table entry */
typedef struct udft_entry {
    struct udft_entry *next_udf; /* pointer to next udf in linked list */
    char *udf_name;		/* name of this function entry */
    struct at_type *at;		/* pointer to action table to execute */
    char *definition;		/* definition of function as typed */
    t_value dummy_values[MAX_NUM_VAR]; /* current value of dummy variables */
} udft_entry;

I attempted to get the at_type and definition copy right, but it sure gets deep.  I stopped at temp_at().

I didn't use gp_alloc(), but instead malloc() because there was only malloc()s in getcolors.c.

If you know of any functions that already exist that are similar to what I created, let me know.

I copied your original bug report that started the palette stuff so that you may verify your example still works.]

...

OK, so that's one problem down and two to go.  I'll see if I can get to another one next weekend.

Dan


Petr Mikulik wrote:
>     Hello,
> 
> I think the palette should not be touched, only the "set view" numbers. 
> I think it was Johannes who programmed this rotation by mouse without 
> rereading the data.
> 
>   Petr
> 
>> Haven't thought about this, but just want to remind you the rule is to 
>> allocate the palette only if it changes.  Could it be that something 
>> about the palette is being changed on the plot you are generating?  If 
>> so, it isn't a bug as programmed, but we may want to come up with a 
>> scheme of tagging the color map somehow because we are going back and 
>> forth two different ones.  (I actually would prefer such an approach 
>> because testing the whole palette each time a redraw is done to check 
>> for a change is inefficient.)
>>
>>>
>>> From: Petr Mikulik <mi...@ph...>
>>> Date: 2005/11/27 Sun PM 12:04:34 EST
>>> To: Daniel J Sebald <dan...@ie...>
>>> Subject: palette allocation during mouse rotation
>>>
>>>      Hello Daniel,
>>>
>>> I have just tried to type
>>>
>>>      splot x with line palette
>>> or
>>>      set pm3d
>>>      splot x
>>>
>>> and then rotated the plot by mouse. Now, the title bar shows that 
>>> gnuplot is
>>> allocating the color palette all the time. I think it was not the case
>>> before your last patch. Could you please have a look to this issue?
>>>
>>> Thanks, Petr
> 
> 

There is a bug in the color palette treatment in the X11 terminal: when
using multiple X11 terminals, window redraw (requested e.g. by a window
manager) will change its palette.

Try this script:


set pm3d map

set term x11 10
set title '10 gray levels'
set palette gray
set palette maxcolors 10
splot x*x

set term x11 2
set title '2 colors'
set palette color
set palette maxcolors 2
splot x


Now, maximize or resize window #10 by mouse => it will change from gray map
with 10 gray levels to color map with 2 colors.

Is it possible to fix it?

---
PM

Patch #1393181 Change default colorbox size

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

Mike:

I just had occasion to use your patch in preparing a plot,
since I ran up against the fact that the current parsing code for 
"set colorbox user orig <pos1>  size <pos2>"
only accepts screen coordinates for <pos>.

Your patch saved me in this case, but I think the restriction
to use screen coordinates should be removed for 2D plots.
Since you've been looking at this code recently, would
you care to modify it to remove this restriction?
That way the user can easily tweak the place using, e.g.
	set colorbox user orig 1.1 graph, 0.0 graph
	set colorbox user size 0.2 graph, 0.8 graph

If not, I'll put in on my list of future code-tweaks.

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

Re: gnuplot license

[<tim...@en...>]

Ethan Merritt wrote:

>On Wednesday 04 January 2006 08:34 am, Petr Mikulik wrote:
> =20
>
>>BTW, could somebody remove
>> 	gnuplot-current  	3.8k.3  	March 28, 2004
>>from [Files]? It's definitely not current.
>>   =20
>>
>
>Better yet, can we replace it with a current 4.1 snapshot?
>
>Just as 3.8k served as a starting point for the long run up to
>a 4.0 release,  let's put out a 4.1jan06 snapshot to give people a
>specific target for criticism leading up to a 4.2 release.
>
> =20
>
I second this completely ! Snapshots are a good idea to show that
development is going on.

Timoth=E9e Lecomte

Re: gnuplot license

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

On Wednesday 04 January 2006 08:34 am, Petr Mikulik wrote:
> 
> BTW, could somebody remove
>  	gnuplot-current  	3.8k.3  	March 28, 2004
> from [Files]? It's definitely not current.

Better yet, can we replace it with a current 4.1 snapshot?

Just as 3.8k served as a starting point for the long run up to
a 4.0 release,  let's put out a 4.1jan06 snapshot to give people a
specific target for criticism leading up to a 4.2 release.

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

Re: a driver for GD.pm

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

> | Subject: a driver for GD.pm
> http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/data/gdpm-1.4.trm

I propose you use the "Patches" section on gnuplot's sourceforge site.
This will allow people to comments on your work.

---
PM

Re: Animations with image size matching output resolution

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

(Ethan, please have a look at this as soon as you can.  As I said, I'm a bit pressed for time.  Also, there are two patches here: your original file updated to account for the changes you already added to CVS repository, and then my update... see the ChangeLog.  It's hard enough keeping track of one patch.)

Here's a resulting patch for the GIF animation modifications.  Actually there are two patches; first animation_eam_1jan2006.patch must be applied.  Then animation_djs_1jan2006.patch must be applied.

I've added a demo.  A new animation that spins the globe around.  So there is an "animate2.dem" combining the concepts of animate.dem and world2.dem.  I've also rewritten "animate.dem" and "gnuplot.rot" slightly, so that I could reuse gnuplot.rot.  I've made it generic as follows:

iteration_count=iteration_count+1
if ((!limit_iterations) || (iteration_count<=limit_iterations)) \
  set view xview(xrot),zview(zrot); \
  replot; \
  zrot=(zrot+zrot_delta)%360; \
  xrot=(xrot+xrot_delta)%360; \
  reread

You can imagine how this works.  Just define all the variables and away we go.  animate2.dem is essentially the same.  (Very first figure might be different.)

Anyway, I think you'll really like this new feature and demos.  (I think they are great.  Try "gthumb" on the GIF files.)  Actually, it really isn't so much a new feature, just realizing how to utilize what we already have.

Dan


PS:  Some comments:

1) The looping file mechanism in gnuplot.rot was actually one greater than the number of iterations specified because even the pass in which the test fails (and doesn't do a reread) does a plot.  I fixed this.

2) [Ethan already replied to this with an alternative.]  It would be nice if looping could be done without requiring two files.  What might enable that is a special test or function saying how deep the "reread" is.  For example, say I wanted to have the above example in a single file, it might be

if (!load_depth()) \
 <all the initial definitions> \
else \
 iteration_count=iteration_count + 1
 if () \
 set view \
 replot \
 zrot= \
 xrot= \
 if () reread

where load_depth() is just some pseudo function or variable that gnuplot makes available.

3) [Ethan replied to this too.  See previous email.]  Modulo (%) doesn't seem to work with negative numbers.  Shouldn't it?

4) We've got to combine the layout and border behavior for 2D and 3D plots.  In the demo I created, I had to make the GIF output resolution very large simply because otherwise all the image is used up by the borders and only a few pixels are left for the plot.  I tried to kludge this by making the view scaling large, but then got:

gnuplot: hidden3d.c:776: store_polygon: Assertion `p->ymax <= surface_scale' failed.

A more graceful failure would be nice in any case.

5) libgd is pretty smart.  Check out this animation file where the internal image is shrunk after the first one because the outer pixels are the same:

[root@local demo]# gifsicle ground_hog_day.gif -I
* ground_hog_day.gif 72 images
  logical screen 200x200
  global color table [128]
  background 0
  loop forever
  + image #0 200x200
    local color table [128]
    disposal asis delay 0.10s
  + image #1 191x165 at 5,11
    local color table [128]
    disposal asis delay 0.10s
...

Re: Animations with image size matching output resolution

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

Ethan A Merritt wrote:

I said wait.  :-)

Read on...


> On Saturday 31 December 2005 06:43 pm, Daniel J Sebald wrote:
> 
> 
>>1) It would be nice if looping could be done without requiring two
>>files.
> 
> 
> It can, although the lack of if/else/endif blocks makes it ugly:
> 
> if (!defined(i))    foo = foo0
> if (!defined(i))    baz = baz0
> if (!defined(i))    i = 0
> i = i + 1
> ... do lots of stuff
> reread


OK, that sort of works.  I didn't think of defined().  But what if i happens to be defined already upon loading such a script and the user doesn't realize it?  It could run without complaints but not produce the desired results.


> 
> 
>>2) Modulo (%) doesn't seem to work with negative numbers.  Shouldn't it?
> 
> 
> Works for me:
> 
> gnuplot> 
> gnuplot> print 9 % 8
> 1
> gnuplot> print -9 % 8
> -1
> gnuplot> 
> 
> Or were you expecting  -9 % 8  to be 7?


Yes, I guess that is what I was expecting--something in the set of integers [0,7], related to modular arithmetic.

Also, Octave generates 7.

The reason this came about is that to get the globe from your world2.dem demo to rotate in the right direction requires a -10 increment in the z rotation.  The modular math as it is means eventually a negative value results and gnuplot complains about that view angle "must be between 0 and 360".  I solved this of course by making the increment 350 degrees.

> 
> 
>>3) We've got to combine the layout and border behavior for 2D and 3D
>>plots.
> 
> 
> Good luck!

I don't think it should be too difficult to do that anymore.  I seem to recall unifying those a bit already.  Definitely post 4.1.

Dan

NO NEED TO READ PREVIOUS EMAIL

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

D'oh, I meant to "save" not "send" previous email.  Wait until it is complete... Dan