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

Re: DPU-414 terminal

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

On Thursday 22 May 2008 13:30, Jonathan Thornburg wrote:
> On Thu, 22 May 2008, someone whose nested quoting has overflowed
> my mental stack :) wrote:
> > The bitmap terminals are pretty ancient code at this point. 
> > Other than special devices like your DPU gadget, there
> > isn't any incentive to use or modernize them.  The PBM
> > driver was at one point a reasonable output path, but for
> > years now PNG has been better for any purpose I can think
> > of.
> 
> I hope we keep the PBM driver around

I wasn't proposed to dump it.  I was just trying to prioritize where
development effort is spent.  There are plenty of things to work on
that will benefit many terminal types (new plot modes, continued work
on internationalization, updated numerical routines) and other 
terminal types with more potential users (cairopdf). 

> -- I still use it fairly often 
> to generate individual frames for encoding into a movie with ppmtompeg
> (which only groks a limited set of native input formats: PPM, PNM,
> YUV, JPEG, and JMOVIE, but *not* PNG).

That's not much of a reason.
You could use the far more featureful png driver and interpose 
a png->pnm  filter in the output:
    set term png truecolor enhanced font "verdana,11"
    set output '| convert png:- mypic.pnm'

-- 
Ethan A Merritt

Re: DPU-414 terminal

[Jonathan T. <J.T...@so...>]

On Thu, 22 May 2008, someone whose nested quoting has overflowed
my mental stack :) wrote:
> The bitmap terminals are pretty ancient code at this point. 
> Other than special devices like your DPU gadget, there
> isn't any incentive to use or modernize them.  The PBM
> driver was at one point a reasonable output path, but for
> years now PNG has been better for any purpose I can think
> of.

I hope we keep the PBM driver around -- I still use it fairly often
to generate individual frames for encoding into a movie with ppmtompeg
(which only groks a limited set of native input formats: PPM, PNM,
YUV, JPEG, and JMOVIE, but *not* PNG).

ciao,

-- 
-- Jonathan Thornburg (remove -animal to reply) <J.T...@so...>
   School of Mathematics, U of Southampton, England
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam

Re: DPU-414 terminal

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

On Thursday 22 May 2008 11:56, Thomas Sefzick wrote:
>  
> set term pbm size 160,120 large
> set out 'test.pbm'
> load 'all.dem'
> 
> segfault when running 'singulr.dem'
> 
> with 'set term pbm size 320,240 large' everything is ok, segfaults occur
> when y-size is <=170 or x-size <= 110.
> 
> Program received signal SIGSEGV, Segmentation fault.
> in_front (edgenum=1240, vnum1=441, vnum2=442, firstpoly=0xbfffe318)
>     at hidden3d.c:1821
> 1821        polynum = qlist[listhead].p;

That's a bit strange, because apparently it segfaulted in the 
hidden-surface bookkeeping routines rather than anything having to do
with bitmap management. I suppose one of those overflowed coordinates
causes trouble in the depth-sort algorithm.

Let me know when you are ready for me to look at the driver again
before adding it to CVS.

-- 
Ethan A Merritt

Re: DPU-414 terminal

[Thomas S. <t.s...@fz...>]

> If your version of the simple fix to b_vector() passes muster,
> let's leave it at that for now.  Could you test it by running
> all.dem through   'set term pbm size 1.0,0.5 large' 
> or something like that?  If it segfaults, we've still got a problem.

set term pbm size 160,120 large
set out 'test.pbm'
load 'all.dem'

segfault when running 'singulr.dem'

with 'set term pbm size 320,240 large' everything is ok, segfaults occur
when y-size is <=170 or x-size <= 110.

Program received signal SIGSEGV, Segmentation fault.
in_front (edgenum=1240, vnum1=441, vnum2=442, firstpoly=0xbfffe318)
    at hidden3d.c:1821
1821        polynum = qlist[listhead].p;

-- 
View this message in context: http://www.nabble.com/DPU-414-terminal-tp17371497p17411182.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: DPU-414 terminal

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

On Thursday 22 May 2008 10:25, Thomas Sefzick wrote:
> > On the other hand, it's possible that by now we have
> > wrapped almost all of the terminal calls originating from
> > the core code in calls to draw_clip_line() and clip_move(),
> > clip_point(), and so on.  It might well be worth the effort
> > to find and fix the few remaining cases.
> 
> there seem to be many remaining cases in gnuplot/src:
> 
> grep clip_move *.[ch] | wc
>      14      50     542
> grep clip_vector *.[ch] | wc
>      14      50     569
> 
> versus
> 
> grep -- "->move" *.[ch] | wc
>     105     590    5121
> grep -- "->vector" *.[ch] | wc
>     151     875    7338
> 
> would it be enough to replace every (*t->vector) with clip_vector,
> and every (*t->move) with clip_move ?
> or would it need extensive testing?

No, it takes more than that.  For one thing, you have to set the
clipping boundaries.  Some operations are clipped against the plot
boundaries; some are clipped against the screen.  Some terminals
(postscript, mostly) still insist on drawing outside the clipping
area for backwards compatibility.  The documentation warns that this
may eventually change to hard clipping, but we don't have a consensus
on that issue I think.

If your version of the simple fix to b_vector() passes muster,
let's leave it at that for now.  Could you test it by running
all.dem through   'set term pbm size 1.0,0.5 large' 
or something like that?  If it segfaults, we've still got a problem.

-- 
Ethan A Merritt 

Re: DPU-414 terminal

[Thomas S. <t.s...@fz...>]

> The bitmap terminals are pretty ancient code at this point. 
> Other than special devices like your DPU gadget, there
> isn't any incentive to use or modernize them.  The PBM
> driver was at one point a reasonable output path, but for
> years now PNG has been better for any purpose I can think
> of.  So there is not much gain to be had from reworking the
> code in bitmap.c. But if you are so inclined - go for it.  As a
> minimal patch, one might just modify b_vector to ignore any
> call for which the coordinates are out of range.  That would
> not be proper clipping, but at least it would prevent memory
> access violations when flipping bits in the bitmap array.

some kind of clipping is done in 'bitmap.c', it's checked if a pixel
is inside the canvas (x < b_xsize) && (y < b_ysize), but this
doesn't help for negative values.

well, i only wanted to get this little printer running, and with
reasonable options ('draft small' or 'normal medium') it's
printing pretty well.

> On the other hand, it's possible that by now we have
> wrapped almost all of the terminal calls originating from
> the core code in calls to draw_clip_line() and clip_move(),
> clip_point(), and so on.  It might well be worth the effort
> to find and fix the few remaining cases.

there seem to be many remaining cases in gnuplot/src:

grep clip_move *.[ch] | wc
     14      50     542
grep clip_vector *.[ch] | wc
     14      50     569

versus

grep -- "->move" *.[ch] | wc
    105     590    5121
grep -- "->vector" *.[ch] | wc
    151     875    7338

would it be enough to replace every (*t->vector) with clip_vector,
and every (*t->move) with clip_move ?
or would it need extensive testing?

thomas
-- 
View this message in context: http://www.nabble.com/DPU-414-terminal-tp17371497p17409329.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: DPU-414 terminal

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

On Thursday 22 May 2008 05:38, Thomas Sefzick wrote:
> 
> > Can you work out where/why the loop happens?
> 
> well...
> the loop is not endless, but stepping
> from  4294967266, 135
> to 350,  135
> stepsize 1
> takes a loooong time...
> 
> this '4294967266' was meant as '-30' in 'term.c' procedure 'test_term'.
> it was produced by
> (*t->move) (xmax_t / 2 - t->h_char * 10, ymax_t / 2 + t->v_char / 2);

As I said in the comment attached to your patch, I'm afraid the
underlying problem is a design flaw in gnuplot.  It tracks terminal
coordinates as unsigned values, which makes proper clipping virtually
impossible.  Unfortunately, changing the coordinates to signed values
would touch essentially every bit of code in the program.

The bitmap terminals are pretty ancient code at this point.  Other than
special devices like your DPU gadget, there isn't any incentive to 
use or modernize them.  The PBM driver was at one point a reasonable
output path, but for years now PNG has been better for any purpose I
can think of.  So there is not much gain to be had from reworking the
code in bitmap.c. But if you are so inclined - go for it.  As a minimal
patch, one might just modify b_vector to ignore any call for which
the coordinates are out of range.  That would not be proper clipping,
but at least it would prevent memory access violations when flipping
bits in the bitmap array.

On the other hand, it's possible that by now we have wrapped almost
all of the terminal calls originating from the core code in calls to 
draw_clip_line() and clip_move(), clip_point(), and so on.  It might
well be worth the effort to find and fix the few remaining cases.

	Ethan

 
> xmax is 320  (because of 'dpu414 draft')
> t->h_char is 19  (because of 'dpu414 large')
> and 160-190 is -30, but it's interpreted as 'unsigned int' by 'b_move', so
> it's 4294967266.
> 
> and then b_vector(350, 135) is called which then calls b_line(4294967266,
> 135, 350, 135)
> which takes a long time to step from 4294967266, 135 to 350, 135
> 
> how to repair this?
> check every call to 'b_move' and 'b_vector' (i.e. '*t->move' and
> '*t->vector') that all arguments positive?
> everywhere, where 'b_move' and 'b_vector' are called?
> that's a lot of work...
> but i don't see another solution
> 
> thomas
-- 
Ethan A Merritt

Re: DPU-414 terminal

[Thomas S. <t.s...@fz...>]

> how to repair this?
> check every call to 'b_move' and 'b_vector' (i.e. '*t->move' and
> '*t->vector') that all arguments are positive?
> everywhere, where 'b_move' and 'b_vector' are called?
> that's a lot of work...
> but i don't see another solution

maybe 'b_move' and 'b_vector' could check their arguments for the highest
bit set and then set the too large (= negative) argument to zero.
this would not be too much code:

---------------------------------------------------------------------

--- bitmap.c.orig       2005-04-22 23:40:37.000000000 +0200
+++ bitmap.c    2008-05-22 15:53:01.000000000 +0200
@@ -1168,6 +1168,7 @@
     b_value = value;
 }
 
+static unsigned int b_negmask = (1 << (8*sizeof(unsigned int)-1));
 
 /*
  * move to (x,y)
@@ -1175,6 +1176,8 @@
 void
 b_move(unsigned int x, unsigned int y)
 {
+    if (x & b_negmask) x = 0;
+    if (y & b_negmask) y = 0;
     b_currx = x;
     b_curry = y;
 }
@@ -1186,6 +1189,8 @@
 void
 b_vector(unsigned int x, unsigned int y)
 {
+    if (x & b_negmask) x = 0;
+    if (y & b_negmask) y = 0;
     b_line(b_currx, b_curry, x, y);
     b_currx = x;
     b_curry = y;

---------------------------------------------------------------------

any ideas?

thomas
-- 
View this message in context: http://www.nabble.com/DPU-414-terminal-tp17371497p17405047.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: DPU-414 terminal

[Thomas S. <t.s...@fz...>]

> Can you work out where/why the loop happens?

well...
the loop is not endless, but stepping
from  4294967266, 135
to 350,  135
stepsize 1
takes a loooong time...

this '4294967266' was meant as '-30' in 'term.c' procedure 'test_term'.
it was produced by
(*t->move) (xmax_t / 2 - t->h_char * 10, ymax_t / 2 + t->v_char / 2);

xmax is 320  (because of 'dpu414 draft')
t->h_char is 19  (because of 'dpu414 large')
and 160-190 is -30, but it's interpreted as 'unsigned int' by 'b_move', so
it's 4294967266.

and then b_vector(350, 135) is called which then calls b_line(4294967266,
135, 350, 135)
which takes a long time to step from 4294967266, 135 to 350, 135

how to repair this?
check every call to 'b_move' and 'b_vector' (i.e. '*t->move' and
'*t->vector') that all arguments positive?
everywhere, where 'b_move' and 'b_vector' are called?
that's a lot of work...
but i don't see another solution

thomas
-- 
View this message in context: http://www.nabble.com/DPU-414-terminal-tp17371497p17403380.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: DPU-414 terminal

[Thomas S. <t.s...@fz...>]

> Could you please create a new tracker item for the patch and
> upload it there?

yes, ii'l do it.

> I notice a few things on a quick look.
> The various terminal types covered by this driver can share entry points.
> For example, there is no reason to have separate identical routines
> EPSON_reset() STARC_reset() NEC_reset() DPU414_reset().
> All four TERM_TABLEs can simply reference EPSON_reset().

there are some things in 'epson.trm' which should be repaired,
i noticed that for most of the terminals there's a hyphen used in
the name (e.g. nec-cp6) in the help text and in the manual,
but in 'set term' these names are accepted with underscore
only (nec_cp6). obviously because hyphens in terminal names
don't work (i first used 'dpu-414' and had problems with
'set term').

i'll go through 'epson.trm' and try to clean it up a little bit.

>> but the 
>> combination 'draft' + 'large' is forbidden because it drives the 'test'
>> command into an endless(?) loop.
>
> I'd rather fix the bug than forbid an otherwise reasonable combination.
> Anyhow, the bug seems to be more pervasive:
>   set term dpu large normal
>   set output 'test.dpu'
>   load 'histograms.dem'
>also goes into an infinite loop

the same applies for the pbm terminal.

> Can you work out where/why the loop happens?

well, i'll try to find where it happens, up to now i have
no idea where to search.
maybe it's due to clipping of characters which extend
the drawing area?
we'll see...

thomas
-- 
View this message in context: http://www.nabble.com/DPU-414-terminal-tp17371497p17398826.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: Coverity scan of gnuplot code

[<so...@pi...>]

On Tue, 20 May 2008 23:07:01 +0200, Ethan Merritt  
<merritt@u.washington.edu> wrote:

> A quick look at that site doesn't make it obvious what one actually
> gets as part of the analysis

that alone speaks pretty clearly to me. Frankly I would not bother.

/Peter.

Re: DPU-414 terminal

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

On Wednesday 21 May 2008 13:19, Thomas Sefzick wrote:
> 
> i got two Seiko DPU-414 thermal printers
> (http://www.seiko-instruments.de/73-0-dpu414.html) and was asking myself
> whether it would make sense to write a gnuplot driver for this printer. it's
> still in production and sold as printer for various measurement devices, so
> it's not really obsolete and i thought this driver could be useful.
> the driver is an extension of 'epson.trm', mainly a merge of some epson/nec
> code with some code from 'pbm.trm'.
> it supports two resolutions: 'normal' (640x480) and 'draft' (320x240)
> font sizes are 'small', 'medium', and 'large' (like in 'pbm.trm') - 
> 
> http://www.nabble.com/file/p17371497/epson.trm_dpu414.patch
> epson.trm_dpu414.patch 

Fine.

Could you please create a new tracker item for the patch and
upload it there?

I notice a few things on a quick look.
The various terminal types covered by this driver can share entry points.
For example, there is no reason to have separate identical routines
EPSON_reset() STARC_reset() NEC_reset() DPU414_reset().
All four TERM_TABLEs can simply reference EPSON_reset().

> but the 
> combination 'draft' + 'large' is forbidden because it drives the 'test'
> command into an endless(?) loop.

I'd rather fix the bug than forbid an otherwise reasonable combination.
Anyhow, the bug seems to be more pervasive:
   set term dpu large normal
   set output 'test.dpu'
   load 'histograms.dem'
also goes into an infinite loop

Can you work out where/why the loop happens?

	Ethan

-- 
Ethan A Merritt

DPU-414 terminal

[Thomas S. <t.s...@fz...>]

i got two Seiko DPU-414 thermal printers
(http://www.seiko-instruments.de/73-0-dpu414.html) and was asking myself
whether it would make sense to write a gnuplot driver for this printer. it's
still in production and sold as printer for various measurement devices, so
it's not really obsolete and i thought this driver could be useful.
the driver is an extension of 'epson.trm', mainly a merge of some epson/nec
code with some code from 'pbm.trm'.
it supports two resolutions: 'normal' (640x480) and 'draft' (320x240)
font sizes are 'small', 'medium', and 'large' (like in 'pbm.trm') - but the
combination 'draft' + 'large' is forbidden because it drives the 'test'
command into an endless(?) loop.

http://www.nabble.com/file/p17371497/epson.trm_dpu414.patch
epson.trm_dpu414.patch 

-- 
View this message in context: http://www.nabble.com/DPU-414-terminal-tp17371497p17371497.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: gnuplot for PDA

[Gunter S. <sc...@ma...>]

Petr Mikulik wrote:

>> A colleague has sent me the following link for gnuplot for PDA:
>> 
>> http://www.rainer-keuchel.de/wince/gnuplot-ce.html
>> 
>> Could someone compile a newer version of gnuplot?

Hans-Bernhard Bröker wrote:
> Hardly.  It's quite far from being a matter of just compiling the thing.
>   The producer of the above version obviously hacked the source quite a
> lot, and doesn't seem to provide source code on his site.  I'm afraid
> that technically, that's a Copyright violation.

You can get the sourcecode at http://www.wince-devel.org/src/gnuplot-3.7.1-src.tar.gz

Re: Coverity scan of gnuplot code

[Allin C. <cot...@wf...>]

On Tue, 20 May 2008, Ethan Merritt wrote:

> You may or may not recall that Coverity is a commercial outfit 
> that started life as the "Stanford Checker"... [Their] press 
> release says that "Source code analysis from the Scan site is 
> freely available to qualified open source projects at: 
> http://scan.coverity.com"
>
> A quick look at that site doesn't make it obvious what one 
> actually gets as part of the analysis, but I suppose it is worth 
> pursuing...  Anyone interested in contacting them?

In principle this sounds great.  In practice (in my limited 
experience) it's a complete waste of time.  

I have both approached Coverity and have been approached by them 
in connection with the GPL'd econometrics program gretl.  But 
despite several phone calls and emails absoloutely nothing has 
happened.  And their website is totally opaque, IMO.  Of course, 
I'm not offering them thousands of dollars.

Maybe gnuplot will have better luck.  I hope so, but as they say, 
don't hold your breath.

Allin Cottrell

Re: Fwd: Patch 1757226 : probability scaling and axes

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

On Tuesday 20 May 2008 15:40, James R. Van Zandt wrote:
> > Are you still interested in this patch and
> > would be willing to revivify it? ;-)
> 
> Certainly.  I may need CVS access renewed, depending on how my account
> gets straightened out.

That's easy enough.  If you end up with a different SourceForge ID,
just let me know and I'll modify the develop list accordingly.

 
> Ethan A Merritt writes:
> 
> > I would really like to see this implemented in the general form
> > mentioned on the TODO list. That is, I want a mechanism for mapping
> > an arbitrary monotonic function f(x) onto a display axis.
> > Both log(x) and probability(x) could become special cases of this
> > general code rather than being separate parallel code paths.
> 
> Yes, with a couple of caveats.  I expect it will take some tuning
> before people are happy with log scaling in all cases.  In the mean
> time, I expect we should maintain both mechanisms.  My code for
> probability scaling makes use of the analytic expressions for forward
> and inverse scaling, plus the known range of values (open interval
> between zero and one).  Some of the underlying code handles the more
> general case where only one function is supplied, and it's inverted
> numerically.  I haven't tried to figure out the range automatically,
> though.  We'll have to decide how much of that information we expect
> from the user.
> 
> > Furthermore, this would present an excuse^H^H^Hopportunity to
> > re-work how data values are stored internally.  Right now setting
> > log-scaling on an axis causes the corresponding data coordinate to
> > be transformed and stored as the log.  This creates great headaches
> > if you want to toggle the log-scaling and redraw the plot from the
> > data previously read in.  I think it would be much cleaner and more
> > flexible to store the original coordinate value on input, and only
> > apply the log- or other scaling during plot generation.
> 
> Yes!  One reason I didn't take my patch any further was that the "last
> minute scaling" revision ought to be done first.

I had come to the opposite conclusion.
I figured to leave the existing log-scale code in place, as you 
suggested above, while adding a new more general mecanism that worked
on the original stored coordinates.  Once the general mechanism was
in place and working, the old log-scale code could be removed without
ever having to modify it to work  with "last-minute" scaling.
I think that order of doing things has less chance of breaking things
as the new scheme is developed.  But I have not looked seriously at
what it would require to modify the existing log-scale code first.
Maybe it's not so bad.

-- 
Ethan A Merritt 

Fwd: Patch 1757226 : probability scaling and axes

[James R. V. Z. <jr...@co...>]

Philipp -

You wrote:
> I took a look at an older patch 1757226 (probability
> scaling and axes).
> 
> I like the idea a lot, but the patch is large and a bit older. I am
> also not sure how "complete" the patch is in its current form - the
> "todo" list is a bit lengthy.
> 
> Has somebody else taken a look at it? Is James (the original
> submitter) still around to help get it in line with the current
> (4.3) devel version of gnuplot?

I am still around (though not always keeping up with my email :-).
and am still interested in probability and more general scaling and
axes.  

> Since your sourceforge email bounced...

Hmm.  Apparently they don't know about my current email address.  And
they don't recognize the username/password in my Firefox registry and
notebook.

> Are you still interested in this patch and
> would be willing to revivify it? ;-)

Certainly.  I may need CVS access renewed, depending on how my account
gets straightened out.

Ethan A Merritt writes:

> I would really like to see this implemented in the general form
> mentioned on the TODO list. That is, I want a mechanism for mapping
> an arbitrary monotonic function f(x) onto a display axis.
> Both log(x) and probability(x) could become special cases of this
> general code rather than being separate parallel code paths.

Yes, with a couple of caveats.  I expect it will take some tuning
before people are happy with log scaling in all cases.  In the mean
time, I expect we should maintain both mechanisms.  My code for
probability scaling makes use of the analytic expressions for forward
and inverse scaling, plus the known range of values (open interval
between zero and one).  Some of the underlying code handles the more
general case where only one function is supplied, and it's inverted
numerically.  I haven't tried to figure out the range automatically,
though.  We'll have to decide how much of that information we expect
from the user.

> Furthermore, this would present an excuse^H^H^Hopportunity to
> re-work how data values are stored internally.  Right now setting
> log-scaling on an axis causes the corresponding data coordinate to
> be transformed and stored as the log.  This creates great headaches
> if you want to toggle the log-scaling and redraw the plot from the
> data previously read in.  I think it would be much cleaner and more
> flexible to store the original coordinate value on input, and only
> apply the log- or other scaling during plot generation.

Yes!  One reason I didn't take my patch any further was that the "last
minute scaling" revision ought to be done first.

              - Jim Van Zandt

Re: Coverity scan of gnuplot code

[Timothée L. <tim...@lp...>]

Ethan Merritt wrote:
> There's a press release from Coverity today:
> 	http://lwn.net/Articles/283179/
> saying that they are releasing
>   "2 years of analysis of more than 55 million lines of code on a recurring
>   basis from over 250 popular open source projects with Coverity PreventT, the
>   industry-leading static source code analysis solution."
>
> <...>
>
> Anyone interested in contacting them?
>   
I once was, and I am still thinking it would be worth it. Unfortunately, 
I don't have time now to handle that :-(

Best regards,

Timothée Lecomte

Coverity scan of gnuplot code

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

There's a press release from Coverity today:
	http://lwn.net/Articles/283179/
saying that they are releasing
  "2 years of analysis of more than 55 million lines of code on a recurring
  basis from over 250 popular open source projects with Coverity PreventT, the
  industry-leading static source code analysis solution."

You may or may not recall that Coverity is a commercial outfit
that started life as the "Stanford Checker".  As I understand it, it uses
a highly-modified C compiler to examine the code and report flawed code
paths, failures of initialization, and so on.  Anyhow, the point is that
gnuplot is one of the 250 code bases that they analyzed.  The press release
says that 
  "Source code analysis from the Scan site is freely available
   to qualified open source projects at: http://scan.coverity.com"

A quick look at that site doesn't make it obvious what one actually
gets as part of the analysis, but I suppose it is worth pursuing.
That's a lot of high-powered bug-checking already done for us.
But I wonder what version of the code they checked?
The site does say that if you work with them to reduce the number
of bugs, they will re-run the analysis on a current source tree.

Anyone interested in contacting them?

-- 
Ethan A Merritt

Re: a patch for grid linetype of emf.trm

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

On Tuesday 20 May 2008 03:57, Shigeharu TAKENO wrote:
> shige 05/20 2008
> ----------------
> 
> I will send a patch for grid linetype of emf.trm. In emf terminal
> of current gnuplot, grid line (linetype 0) becomes solid lines.

The patch looks correct.
Thank you.


> In the function EMF_dashtype(), LT_AXIS is considered correctly,
> but I think the first line in the function may avoid it.
> 
> ----- From Here -----
> diff -uN term/emf.trm.ORG term/emf.trm
> --- term/emf.trm.ORG	Thu May  1 16:05:10 2008
> +++ term/emf.trm	Tue May 20 19:47:18 2008
> @@ -902,8 +902,11 @@
>  	4, 9, 4, 2, 4, 2, 0, 0,	/* 4 - dash-dot-dot      */
>      };
>  
> +/* shige */
> +#if 0
>      if (dashtype < 0)
>  	dashtype = 0;
> +#endif
>  
>      emf_dashtype = dashtype;
>  
> ----- To Here -----
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry       Regular Mail: Mailstop 357742
Health Sciences Building
University of Washington - Seattle WA 98195-7742

a patch for grid linetype of emf.trm

[Shigeharu T. <sh...@ie...>]

shige 05/20 2008
----------------

I will send a patch for grid linetype of emf.trm. In emf terminal
of current gnuplot, grid line (linetype 0) becomes solid lines.
In the function EMF_dashtype(), LT_AXIS is considered correctly,
but I think the first line in the function may avoid it.

----- From Here -----
diff -uN term/emf.trm.ORG term/emf.trm
--- term/emf.trm.ORG	Thu May  1 16:05:10 2008
+++ term/emf.trm	Tue May 20 19:47:18 2008
@@ -902,8 +902,11 @@
 	4, 9, 4, 2, 4, 2, 0, 0,	/* 4 - dash-dot-dot      */
     };
 
+/* shige */
+#if 0
     if (dashtype < 0)
 	dashtype = 0;
+#endif
 
     emf_dashtype = dashtype;
 
----- To Here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: Zooming issues in interactive terminals

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

On Monday 19 May 2008 18:44, Lutz Maibaum wrote:
> Hi Ethan,
> 
> I just read that on many 32-bit systems the "int" and "long" datatypes are 
> the same, whereas on 64-bit system such as the AMD x86-64 I am 
> using "long" is 8 bytes, whereas "int" is 4 bytes. This would explain why 
> you don't see the effect of the long->int conversion on your system.

Right. I was assuming that v.int_val was a long, but it isn't.
That explains the intention of the previous test  if ((A=B) == B) that 
was puzzling me.  I thought A and B were both longs.

I wonder why int_value is not being kept as a long?
value.v is a union, and one other member of the union is a double,
so it wouldn't add any space to store a long rather than an int.
But changing it to

typedef struct value {
    enum DATA_TYPES type;
    union {
        long int_val;
        struct cmplx cmplx_val;
        char *string_val;
    } v;
} t_value;

might cause similar problems to pop up all over the place when
int_val is dereferenced.   Hmm.  For now I'll leave the change to atol(),
but also restore the earlier ((A=B)==B) test.

	Ethan


> 
>  Lutz
> 
> 
> On Monday 19 May 2008 17:46:08 you wrote:
> > On Monday 19 May 2008 17:28, Lutz Maibaum wrote:
> > > Hi Ethan,
> > >
> > > > I've made this change in scanner.c get_num().
> > > > It fixes the overflows on a system that handles stderr properly
> > > > (linux) and does no worse that the previous code on a system that
> > > > doesn't (sunos 4.1).
> > >
> > > I just tried the current CVS build, and the problems with interactive
> > > zooming remain, except that I don't get an error message anymore ;)
> >
> > I confess that I am mystified.
> > What compiler and glibc versions are you using?
> > What hardware? You probably said before, but I've forgotten.
> >
> > Does the man page for strtol on your system claim that it will
> > set errno on overflow?
> >
> > > As you mentioned before, the problem is that large numbers, such as
> > > those generated by apply_zoom() when using logarithmic axes, are not
> > > recognized as floating point values when they do not contain a decimal
> > > point:
> > >
> > > gnuplot> set yr[313136844993:1.8789321221e+13]
> > > gnuplot> show yr
> > >         set yrange [ -3.95768e+08 : 1.87893e+13 ] noreverse
> > > nowriteback
> >
> > On my machine (32-bit, rather old AMD athlon) I get
> >
> > gnuplot> set yr[313136844993:1.8789321221e+13]
> >                 ^
> >          warning: integer overflow; changing to floating point
> > gnuplot> show yr
> >         set yrange [ 3.13137e+11 : 1.87893e+13 ] noreverse nowriteback
> >
> > I assume that you also get something else for the simpler test case:
> >
> > gnuplot> t = 313136844993
> >              ^
> >          warning: integer overflow; changing to floating point
> > gnuplot> print t
> > 313136844993.0
> >
> > > This obviously doesn't work when the y-axis is logarithmic.
> > > Changing "%.12g" to "%.12E" in apply_zoom() fixed this issue for me.
> > >
> > > Thanks for looking into this,
> >
> > But changing the format in the zoom code won't fix the general case.
> > I would rather figure out how to make it work everywhere!
> >
> > 	Ethan
> 
> 
> 

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

Re: Zooming issues in interactive terminals

[Allin C. <cot...@wf...>]

On Mon, 19 May 2008, Lutz Maibaum wrote:

> gcc 4.2.1 on x86-64, glibc 2.6.1 release 18.3 (openSUSE 10.3 
> packages)

> Ethan:
> 
> > I assume that you also get something else for the simpler test case:
> >
> > gnuplot> t = 313136844993
> >              ^
> >          warning: integer overflow; changing to floating point
> > gnuplot> print t
> > 313136844993.0

Lutz won't get that on a 64-bit system; it's well within range of 
a long.  

Allin Cottrell

Re: Zooming issues in interactive terminals

[Lutz M. <lut...@gm...>]

On Monday 19 May 2008 17:46:08 Ethan Merritt wrote:
> What compiler and glibc versions are you using?
> What hardware? You probably said before, but I've forgotten.

gcc 4.2.1 on x86-64, glibc 2.6.1 release 18.3 (openSUSE 10.3 packages)

> Does the man page for strtol on your system claim that it will
> set errno on overflow?

I think so:

     If the string has valid syntax for an integer but the value is not
     representable because of overflow, `strtol' returns either
     `LONG_MAX' or `LONG_MIN' (*note Range of Type::), as appropriate
     for the sign of the value.  It also sets `errno' to `ERANGE' to
     indicate there was overflow.

> I assume that you also get something else for the simpler test case:
>
> gnuplot> t = 313136844993
>              ^
>          warning: integer overflow; changing to floating point
> gnuplot> print t
> 313136844993.0

This is what I get:

gnuplot> t = 313136844993
gnuplot> print t
-395767615

I think the reason for this behavior is that the call to strtol does not 
generate an error, since the argument is within the range of a long 
integer, but then there is an implicit conversion to the smaller int type:

	token[t_num].l_val.v.int_val = strtol(str, &endptr, 0);

If I remember correctly, leading bits are simply truncated in a long->int 
conversion, and errno is not set.

Hope this helps,

  Lutz

Re: Zooming issues in interactive terminals

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

On Monday 19 May 2008 17:28, Lutz Maibaum wrote:
> Hi Ethan,
> 
> > I've made this change in scanner.c get_num().
> > It fixes the overflows on a system that handles stderr properly (linux)
> > and does no worse that the previous code on a system that doesn't (sunos
> > 4.1).
> 
> I just tried the current CVS build, and the problems with interactive 
> zooming remain, except that I don't get an error message anymore ;)

I confess that I am mystified.
What compiler and glibc versions are you using?
What hardware? You probably said before, but I've forgotten.

Does the man page for strtol on your system claim that it will
set errno on overflow?

> As you mentioned before, the problem is that large numbers, such as those 
> generated by apply_zoom() when using logarithmic axes, are not recognized 
> as floating point values when they do not contain a decimal point:
> 
> gnuplot> set yr[313136844993:1.8789321221e+13]
> gnuplot> show yr
>         set yrange [ -3.95768e+08 : 1.87893e+13 ] noreverse nowriteback

On my machine (32-bit, rather old AMD athlon) I get

gnuplot> set yr[313136844993:1.8789321221e+13]
                ^
         warning: integer overflow; changing to floating point
gnuplot> show yr
        set yrange [ 3.13137e+11 : 1.87893e+13 ] noreverse nowriteback

I assume that you also get something else for the simpler test case:

gnuplot> t = 313136844993
             ^
         warning: integer overflow; changing to floating point
gnuplot> print t
313136844993.0

> This obviously doesn't work when the y-axis is logarithmic. 
> Changing "%.12g" to "%.12E" in apply_zoom() fixed this issue for me.
> 
> Thanks for looking into this,

But changing the format in the zoom code won't fix the general case.
I would rather figure out how to make it work everywhere!

	Ethan
-- 
Ethan A Merritt