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

Re: Interactive terminals : behaviour on window resizing

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

On Friday 24 March 2006 11:08 am, Timoth=E9e Lecomte wrote:
>=20
> I would like to discuss what is the expected behaviour of the interactive
> terminals when the user resizes the windows.

> I am now asking what is the best behaviour in these situations. The
> purpose of gnuplot is to make the layout automatically, and to make it
> good. So, to my mind, rescaling everything except the fontsize is kind of
> strange, as it gives overlapping.

I am afraid that most terminal types do not have enough information
about fonts to re-scale on their own.
And what if the font isn't scalable?

> I can imagine two other possibilites for the plot behavior when the user
> changes the window's size :
>=20
>   1) really scale everything - including the font size

This would be very odd in x11.  I cannot think of a single x11 application
in which the font size changes as you resize the window.  Generally you
pick a readable font size, and that's the size you get no matter how big
or small the window is.

>   2) don't scale anything and just display the plot centered in the window
> if it is smaller than the window, and if it is bigger add scrollbars on
> the edges of the window.

Why would you ever want that? =20

> Thanks for your insight on this topic.

One change that has been suggested for x11 is to honor the
"set ratio" command; scaling up or down as the window size changes, but
always keeping the requested aspect ratio.

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

Interactive terminals : behaviour on window resizing

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

Hi !

I would like to discuss what is the expected behaviour of the interactive
terminals when the user resizes the windows.

The X11 terminal is resizing the plot by scaling everything on it except
the font size and the linewidths. Thus, if the user makes the window
smaller, ticks labels may overlap, the plot box gets closer to the
window's edges and may overlap the labels, etc.
If another plot command is issued, the ratio is kept, so that the positio=
n
of the box doesn't change for example.
If 'set term x11; replot' is issued, the window size seems to be probed,
updating term->xmax and term->ymax, and gnuplot updates the position of
the box, the labels, etc. according to the new size.

The Windows terminal behaves similarly, except that term->xmax and
term->ymax seem to be stored at once on startup only, so that 'set term
win; replot' won't change the layout of the plot at all.

I am now asking what is the best behaviour in these situations. The
purpose of gnuplot is to make the layout automatically, and to make it
good. So, to my mind, rescaling everything except the fontsize is kind of
strange, as it gives overlapping.

I can imagine two other possibilites for the plot behavior when the user
changes the window's size :

  1) really scale everything - including the font size
  2) don't scale anything and just display the plot centered in the windo=
w
if it is smaller than the window, and if it is bigger add scrollbars on
the edges of the window.

The first solution leads to another problem : what to do with the text
aspect ratio (height to width). Two possibilities again :
  a) scale the font size with the width of the window only and maintain
the proportion of the text. This will give overlapping labels again if
the user makes the height of the window smaller
  b) scale the whole text with the window, so the ratio width/height of
the text won't be constant

The second solution (don't scale anything) has the advantage to be faster=
,
as it has basically no complex operation at all to be done when the
window's size changes.
But what would the user have to do to make the plot fit again in the
window ? Just hit 'replot' ? Or 'set term wxt; replot' ? Click a toolbar
button called 'Fit plot to window' and then hit 'replot' ?

--Note that all these 'replot'-based solutions don't work with multiplot-=
-

Thanks for your insight on this topic.

Best regards,

Timoth=E9e Lecomte

Re: To distribute of translated manual

[<br...@ph...>]

Ethan Merritt wrote:
> Should we create a new directory at the top level of the tree?
>     .../japanese/all_Shige's_files

If they come as a "how to change the source code into that of Japanese 
gnuplot": yes.  Deviating from that scheme, those files that just 
replace existing files in that process could be installed next to those, 
e.g.

	docs\japanese.doc
	src\win\japanese.mnu

and so on.  I don't think there's any point in creating a subdirectory 
for a single file.

Re: What's left for a 4.2 release? [drivers]

[<br...@ph...>]

Petr Mikulik wrote:

>> The current code as it is does not run on NT4 and possibly Win95 and 
>> Win32s. This is due to the new directory selection dialog introduced
>> by me. I can think of these options to handle that:
>> 1) provide a separate version for these systems (probably not Win32s ;-)
>> 2) add more code to make it run on all systems
>> 3) make Win98/WIN2000 a requirement (NT4 plus IE update does work, 
>> too), Is there an agreement what to do?
> 
> Could you check on runtime "if (this_dll_available) then ..." ?

I take that's what Bastian meant by option 1) add more code...

>>> #982293         can't print color in win32 gnuplot 4.0
>>> #233405         WGNUPL32.EXE crashes when printing directly (Win 95)

>> Printing via win.trm in general seems to be buggy. This feature
>> should probably be disabled for now. Bernhard recommends not to use
>> it anyway.
> 
> Thus, to be disabled? Hans-Bernhard?

Disabling it might be overkill: sometimes it _does_ work, to some 
extent.   The real problem is that nobody seems to have any consistent 
explanation about when it'll work, and when it won't.  On Win9x, it 
apparently never worked, on NT-based windows, it sometimes does.
E.g. the "Print..." entry in the context menu of the graph window 
(available via the system menu if mousing is on) just got me a nicely 
working printout of the test page.  The PrtSc button (--> command 
"screendump") also worked.

Re: To distribute of translated manual

[<br...@ph...>]

Shigeharu TAKENO wrote:
> O.K. Well, where should I submit them ? "Docs" section, or 
> "Patches" section ? 

The general idea is you become a gnuplot team member and check them into 
CVS yourself, so you can also update them on your own schedule, without 
our help.  Failing that, zip them up and post the package to the 
'Patches' tracker.

> Since it is more complicated to make Japanese wgnuplot.hlp (H), 
> I hope H will be included in the directory.

I really would like to avoid it.  How is making the Japanese version of 
wgnuplot.hlp more complicated than the normal one?

Re: valgrind

[<br...@ph...>]

James R. Van Zandt wrote:
> This leakage turned up every time:

This is a leak-by-design of the C library.  It's not really our job to 
worry about it.

getpwnam() is defined to return a pointer to memory that we don't own. 
We *cannot* free it.  We don't even know it was ever malloc()ed in the 
first place.

> We could use getpwnam_r instead, if it is available.

I seriously doubt that getting gnuplot 100% valgrind-clean is a viable 
goal for the foreseeable future.  Until that changes, I'm against making 
such a change just to quiet valgrind.  We've much bigger cats to skin 
than that one.

Re: An X11 palette issue, approximate_palette

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

Ethan Merritt wrote:
> On Thursday 23 March 2006 12:43 pm, Daniel J Sebald wrote:
> 
>>Here is a small issue with the palette in X11.
>>
>>However, the X11 terminal produces a color box with an artifact at -5
>>and 0.  See the attached PNG "Screenshot-Gnuplot-4-palfunc.png".
> 
> 
> I think this may be a problem with your x11 configuration.
> I see no such artifact on my display (screen capture attached).
> I do, however, see more orange than expected at the boundary 
> between red and green in the plot itself.

I should have emphasized that this is for the demo in the most recent CVS.  My mistake.  An update to the demo pm3dcolors.dem was recently checked in to handle exactly the issue you have found.  That orange strip is the result of defining the functions by flipping the step function in time.  Because it occurs only when the functions are sampled right at 0.25, that orange strip would appear in some terminals but not others.  Sometimes in the color box, sometimes not.

The updated demo implements these functions as

theta(x) = x<0 ? 0 : 1
r(x) = 4*x*(1-theta(x-0.25))
g(x) = 0.5*theta(x-0.25)*(1-theta(x-0.5))
b(x) = x

i.e., flips the step function in amplitude.  The intent is to minimize the effect of now to properly define the value of the function right at the discontinuity.

So, please try the most recent version of the demo.

Thanks,

Dan

Re: An X11 palette issue, approximate_palette

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

On Thursday 23 March 2006 12:43 pm, Daniel J Sebald wrote:
> Here is a small issue with the palette in X11.
>
> However, the X11 terminal produces a color box with an artifact at -5
> and 0.  See the attached PNG "Screenshot-Gnuplot-4-palfunc.png".

I think this may be a problem with your x11 configuration.
I see no such artifact on my display (screen capture attached).
I do, however, see more orange than expected at the boundary 
between red and green in the plot itself.


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

An X11 palette issue, approximate_palette

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

Here is a small issue with the palette in X11.

In the pm3dcolors.dem demo, as in the most recent CVS version is an example of using functions for the palette.  By the definition of the functions for each color component, this demo is supposed to have three regions with two sharp transitions between the regions.

The pm3d plot itself has good sharp transitions in X11 and other terminals I've looked at.  As an example, look at the attached PNG "palfunc.png".

Likewise, one would think that the color box should have a similar sharp transition.  This is the case for PNG (see "palfunc.png") and for PDF.  Notice the sharp boundaries right at -5 and 0.

However, the X11 terminal produces a color box with an artifact at -5 and 0.  See the attached PNG "Screenshot-Gnuplot-4-palfunc.png".

I've done a little investigation and concluded parts of the palette method work as they should.  For example, the software produce component values

a=0.984000 b=0.000000 c=0.246000
a=0.992000 b=0.000000 c=0.248000
a=0.000000 b=0.500000 c=0.250000
a=0.000000 b=0.500000 c=0.254000
a=0.000000 b=0.500000 c=0.258000

and

a=0.000000 b=0.500000 c=0.496000
a=0.000000 b=0.500000 c=0.498000
a=0.000000 b=0.000000 c=0.500000
a=0.000000 b=0.000000 c=0.504000
a=0.000000 b=0.000000 c=0.508000

at the boundaries.

To anyone familiar with the x11 palette method (and that includes *any* code in the color.c, getcolor.c, etc. files) is what I'm seeing simply an artifact of the "approximate_palette()" routine?

I think what x11 does is not keep track of functions, but has a palette sent to it that is an approximation of the functions.  (The routine gnuplot_x11 doesn't have the foundation for functions and so on.)

This routine "approximate_palette()" is an interesting one.  (And I've a feeling it might be slow because of what it does.   More later...)  If I understand correctly, it first oversamples the palette and then attempts to find a smaller palette that fits within an allowable tolerance of approximation the original palette.  So it seems to be an embedded loop kind of thing.  (Hence its slow speed.  I wonder if we could devise a mathematical formula that would tell us immediately what the size of the palette should be rather than by trial and error.)

So, is it the case that in the color box we are seeing the effect of approximate_palette() doing linear interpolation on the colors on each side of the discontinuity for the RGB formulae?  This is what I'm guessing.  So that is the issue I'm raising--this idea of first sampling the palette and then using linear interpolation to construct a smaller palette.  In the case of discontinuities (and in image processing and pattern recognition, discontinuities do not seem in any way a far stretch), which are not band limited, this is not a good thing.  Perhaps there are some applications where interpolating is desired.

What is the difference with PNG/PDF?  I'm guessing in that case, the term->make_palette(NULL) indicates there are, say 157, colors.  Then the software decides, OK, I'll sample the palette in 157 locations, no interpolation.

If what I've described is the case and there is no desire to address the issue because people feel it is fine the way it is, there should probably be mention of this in the palette documentation.  Otherwise it might seem peculiar to the end user and cause a lot of question.

Dan

Re: valgrind

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

On Tuesday 21 March 2006 06:32 pm, James R. Van Zandt wrote:
> Thanks for reminding us about valgrind.
> This leakage turned up every time:
> 
>   ==17498== 156 (36 direct, 120 indirect) bytes in 1 blocks are
>   definitely lost in loss record 5 of 9
>   ==17498==    at 0x1B90459D: malloc (vg_replace_malloc.c:130)
>   ==17498==    by 0x1BC6C179: (within /lib/tls/libc-2.3.5.so)
>   ==17498==    by 0x1BC6C7C1: __nss_database_lookup (in /lib/tls/libc-2.3.5.so)
>   ==17498==    by 0x1B90F139: ???
>   ==17498==    by 0x1B9108F4: ???
>   ==17498==    by 0x1BC1A0B9: getpwnam_r (in /lib/tls/libc-2.3.5.so)
>   ==17498==    by 0x1BC19B41: getpwnam (in /lib/tls/libc-2.3.5.so)
>   ==17498==    by 0x80FA84A: getusername (util.c:1143)
>   ==17498==    by 0x80DD313: PS_common_init (post.trm:2278)
>   ==17498==    by 0x80DD841: PS_init (post.trm:2403)
>   ==17498==    by 0x80B62B9: term_init (term.c:531)
>   ==17498==    by 0x806E993: do_plot (graphics.c:1301)

I am not seeing that error here, or at least not for
"setenv GNUTERM post; \
 valgrind --leak-check=full --log-file=valgrind gnuplot all.dem </bin/true >foo"

> show that this allocation in post.trm leaks memory:
> 
> 	    ps_fontfile_char = gp_alloc (totlength+1,"ps_fontfile_char");

I already knew about this leak, but have not found the proper place to 
free the pointers.  They are copied to an array which is used in several
places.  IIRC this is Harald Harders' code. Perhaps he can help.

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

Re: Typo in gplot_x11.c

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

On Wednesday 22 March 2006 11:59 am, Timoth=E9e Lecomte wrote:
>=20
> Here is a typo in gplt_x11.c, line 5963 :

Added to cvs.
Thanks

>   } else if (reply.xselection.target =3D=3D XA_TIMESTAMP) {
>=20
> -	FPRINTF((stderr, "timestamp request from %d : %ld\n", i
> +	FPRINTF((stderr, "timestamp request from %d : %ld\n",
> 		reply.xselection.requestor, export_time));
> 	XChangeProperty(dpy, reply.xselection.requestor,
> 		reply.xselection.property, reply.xselection.target,
> 		32, PropModeReplace, (unsigned char *) &(export_time), 1);
=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Typo in gplot_x11.c

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

Hi !

Here is a typo in gplt_x11.c, line 5963 :

  } else if (reply.xselection.target =3D=3D XA_TIMESTAMP) {

-	FPRINTF((stderr, "timestamp request from %d : %ld\n", i
+	FPRINTF((stderr, "timestamp request from %d : %ld\n",
		reply.xselection.requestor, export_time));
	XChangeProperty(dpy, reply.xselection.requestor,
		reply.xselection.property, reply.xselection.target,
		32, PropModeReplace, (unsigned char *) &(export_time), 1);

It only appears when DEBUG is defined, and comes probably from me as I
have proposed the above lines to cope with clipboard's problem...

Best regards,

Timoth=E9e Lecomte

Re: What's left for a 4.2 release? [drivers]

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

> else you miss for a 4.2 release? Multiple window support is a candidate that 
> most likely could be added rather easily.

Or use wxgnuplot

> On my list of changes for win.trm are a changes to WIN_options()
> to make it accept similar options as other terminals. The menu file
> wgnuplot.mnu definitely could do with some update before 4.2 as well.

Good point, can you patch them?

> The current code as it is does not run on NT4 and possibly Win95 and Win32s. 
> This is due to the new directory selection dialog introduced
> by me. I can think of these options to handle that:
> 1) provide a separate version for these systems (probably not Win32s ;-)
> 2) add more code to make it run on all systems
> 3) make Win98/WIN2000 a requirement (NT4 plus IE update does work, too), Is 
> there an agreement what to do?

Could you check on runtime "if (this_dll_available) then ..." ?

>> windows:
>> #1232950        -persist option does not work in Version 4.0.0 (Windows)
> A bug that needs to be fixed for 4.2. I will look into it.
>
>> #1413021        [Wgnuplot] pause 1;reread; blocks interaction
> Cannot comment.
>
>> #561418         (MS Windows) 100% CPU Usage during pause
> I cannot reproduce this.

Please write your comments into SF. 
Those unreproducible should be closed.

>> #982293         can't print color in win32 gnuplot 4.0
>> #233405         WGNUPL32.EXE crashes when printing directly (Win 95)
> Printing via win.trm in general seems to be buggy. This feature
> should probably be disabled for now. Bernhard recommends not to use
> it anyway.

Thus, to be disabled? Hans-Bernhard?

---
PM

Re: To distribute of translated manual

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

shige 03/22 2006
----------------

Hans-Bernhard_Br wrote:
> Submissions to the web site are of secondary interest only.  The key 
> parts will be submissions to the source CVS tarball.

O.K. Well, where should I submit them ? "Docs" section, or 
"Patches" section ? I will modify translations along with changes
of original documents, so I will submit them sometimes.

> A,B,C,E,G and I should go into the CVS.  The generated files (D,F,H) can 
> then be published where you like.

O.K. I will open the pdf files (D,F) on my Web site if I need.

Ethan Merritt wrote:
> Will your README file explain how to apply the terminal patches,
> and anything else necessary to prepare the cvs source tree for
> building a Japanese version from source?

O.K. I will write them to the README. I will also explain the way
to make pdf files (it is not only "make pdf" because pdflatex 
command does not parse the Japanese LaTeX file). 

Since it is more complicated to make Japanese wgnuplot.hlp (H), 
I hope H will be included in the directory.

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

Re: valgrind

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

Daniel J Sebald <dan...@ie...> writes:

>Well, I've got to hand it to valgrind.  It found an uninitialized
>variable in the image demo...

Thanks for reminding us about valgrind.

To extend coverage to more terminals, I modified demo/webify like this

  open(GNUPLOT, "|valgrind --leak-check=full --log-file=$ARGV[0] ../src/gnuplot") or die "can't find gnuplot";
  my $png="png";
  if ($#ARGV>0) {$png=$ARGV[1];}
  print GNUPLOT "set term $png\n";
  print GNUPLOT "set output \"$ARGV[0].$plot.$png\"\n";

so I could call it like this

  for x in *.dem; do ./webify.pl `echo $x|sed 's/.dem//'` postscript; done


This leakage turned up every time:

  ==17498== 156 (36 direct, 120 indirect) bytes in 1 blocks are
  definitely lost in loss record 5 of 9
  ==17498==    at 0x1B90459D: malloc (vg_replace_malloc.c:130)
  ==17498==    by 0x1BC6C179: (within /lib/tls/libc-2.3.5.so)
  ==17498==    by 0x1BC6C7C1: __nss_database_lookup (in /lib/tls/libc-2.3.5.so)
  ==17498==    by 0x1B90F139: ???
  ==17498==    by 0x1B9108F4: ???
  ==17498==    by 0x1BC1A0B9: getpwnam_r (in /lib/tls/libc-2.3.5.so)
  ==17498==    by 0x1BC19B41: getpwnam (in /lib/tls/libc-2.3.5.so)
  ==17498==    by 0x80FA84A: getusername (util.c:1143)
  ==17498==    by 0x80DD313: PS_common_init (post.trm:2278)
  ==17498==    by 0x80DD841: PS_init (post.trm:2403)
  ==17498==    by 0x80B62B9: term_init (term.c:531)
  ==17498==    by 0x806E993: do_plot (graphics.c:1301)

getpwman returns a pointer to a struct.  Apparently this
implementation allocates space for the struct from the heap.  However,
we can't just free it because the man page says the struct may be in a
static area.  We could use getpwnam_r instead, if it is available.
Possibly another configuration test?


This one:
  ==17774== 98 bytes in 2 blocks are definitely lost in loss record 2 of 8
  ==17774==    at 0x1B90459D: malloc (vg_replace_malloc.c:130)
  ==17774==    by 0x804A9CC: gp_alloc (alloc.c:268)
  ==17774==    by 0x80DC8C3: PS_options (post.trm:1427)
  ==17774==    by 0x80A7B13: set_terminal (set.c:3275)
  ==17774==    by 0x8051E88: command (command.c:539)
  ==17774==    by 0x8051938: do_line (command.c:391)
  ==17774==    by 0x8051863: com_line (command.c:342)
  ==17774==    by 0x808E8D8: main (plot.c:639)
  
show that this allocation in post.trm leaks memory:

	    ps_fontfile_char = gp_alloc (totlength+1,"ps_fontfile_char");


                    - Jim Van Zandt

Re: To distribute of translated manual

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

On Monday 20 March 2006 06:56 am, Hans-Bernhard Br=F6ker wrote:
> Shigeharu TAKENO wrote:
> > Well, I want to submit the following files:
> >
> > A: the Japanese translation of gnuplot.doc ((1) [a])
> > B: a patch for Japanese translations of term/*.trm ((1) [b])
> > C: README for Japanese user ((1) [c])
> > D: .pdf format file made from A ((4))
> > E: the Japanese translation of faq/faq.tex ((5))
> > F: .pdf format file made from E ((6))
> > G: the Japanese translation of wgnuplot.mnu ((7) [f])
> > H: wgnuplot.hlp made from A ((7) [g])
> > I: README for Japanese MS-Windows user ((7) [h])
> >
> > Files D,F,H are not ASCII text files. However,
>
> A,B,C,E,G and I should go into the CVS.  The generated files (D,F,H) can
> then be published where you like.

Should we create a new directory at the top level of the tree?
    .../japanese/all_Shige's_files

Otherwise the individual pieces could go in their respective existing
directories, but that seems confusing to me.
    .../docs/japanese/
    .../term/japanese/xxx.patch
    .../?       (currently the FAQ is in a separate cvs tree)

Shige: =20

Will your README file explain how to apply the terminal patches,
and anything else necessary to prepare the cvs source tree for
building a Japanese version from source?

Re: To distribute of translated manual

[<br...@ph...>]

Shigeharu TAKENO wrote:
> Thanks for kindly advices. I will submit our translations to
> sourceforge site.

Submissions to the web site are of secondary interest only.  The key 
parts will be submissions to the source CVS tarball.

> Well, I want to submit the following files:
> 
> A: the Japanese translation of gnuplot.doc ((1) [a]) 
> B: a patch for Japanese translations of term/*.trm ((1) [b])
> C: README for Japanese user ((1) [c])
> D: .pdf format file made from A ((4))
> E: the Japanese translation of faq/faq.tex ((5))
> F: .pdf format file made from E ((6))
> G: the Japanese translation of wgnuplot.mnu ((7) [f])
> H: wgnuplot.hlp made from A ((7) [g])
> I: README for Japanese MS-Windows user ((7) [h])
> 
> Files D,F,H are not ASCII text files. However,

A,B,C,E,G and I should go into the CVS.  The generated files (D,F,H) can 
then be published where you like.

>  http://sourceforge.net/docman/new.php?group_id=2055

gnuplot hasn't ever used SF.net's "Documentation Manager" so far.  I 
don't think this is the point to start.  If at all, only HTML editions 
of the documentation ("make html" in docs) and FAQ really would make 
sense there.

Re: Timefmt bug, or not?

[<br...@ph...>]

Ethan A Merritt wrote:

> But it isn't, because the input parsing code in datafile.c
> assumes that something in quotes cannot be valid numeric
> (or in this case time format) data.
> 
> What do you think - is this a bug, or is it perfectly
> reasonable to say that input data should not be in quotes
> unless it really is string data?

IMHO it's a bug.

The problem is partly one of history here.  This was wrong in 4.0 
already, before the introduction of string data.  Back then, it was 
apparently meant to allow gnuplot to parse CSD (comma-separated data) 
files, in which non-numeric data are customarily quoted.

Re: To distribute of translated manual

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

shige 03/20 2006
----------------

Thanks for kindly advices. I will submit our translations to
sourceforge site.

Well, I want to submit the following files:

A: the Japanese translation of gnuplot.doc ((1) [a]) 
B: a patch for Japanese translations of term/*.trm ((1) [b])
C: README for Japanese user ((1) [c])
D: .pdf format file made from A ((4))
E: the Japanese translation of faq/faq.tex ((5))
F: .pdf format file made from E ((6))
G: the Japanese translation of wgnuplot.mnu ((7) [f])
H: wgnuplot.hlp made from A ((7) [g])
I: README for Japanese MS-Windows user ((7) [h])

Files D,F,H are not ASCII text files. However,

 http://sourceforge.net/docman/new.php?group_id=2055

says:

  Documents submitted here may consist of either normal ASCII 
  text, or text with HTML mark-up. Documentation in other formats
  will not be processed -- all documentation should be either 
  normal ASCII text or text with HTML mark-up.

Can I submit them there ? If not, where should I submit them ?

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

Timefmt bug, or not?

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

You may have seen on comp.graphics.apps.gnuplot
that someone wanted to plot X-axis time data from a file that
looked like this:

#My data file
"2006-03-06 10:25:35" 0.000006914139 0.000051975250
"2006-03-06 10:25:38" 0.000007867813 0.000027894974
...

Note the quotes around the time.
One might think that this could be handled by
    set timefmt '"%Y-%m-%d %H:%M:%S"'
But it isn't, because the input parsing code in datafile.c
assumes that something in quotes cannot be valid numeric
(or in this case time format) data.

What do you think - is this a bug, or is it perfectly
reasonable to say that input data should not be in quotes
unless it really is string data?

The specific case reported can be handled by the following
patch. But it this a desirable thing to do?

diff -ur gnuplot/src/datafile.c gnuplot-cvs/src/datafile.c
--- gnuplot/src/datafile.c      2006-03-17 22:41:30.000000000 -0800
+++ gnuplot-cvs/src/datafile.c  2006-03-19 17:17:27.000000000 -0800
@@ -721,6 +721,9 @@
         if (*s == '"') {
             in_string = !in_string;
             df_column[df_no_cols].good = DF_MISSING;
+           /* DEBUG - ALLOW TIMEFMT DATA TO BEGIN WITH A QUOTE */
+           if (axis_array[df_axis[df_no_cols]].timefmt)
+               df_column[df_no_cols].good = DF_UNDEFINED;
         } else if (check_missing(s))
             df_column[df_no_cols].good = DF_MISSING;
         else {

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

Re: To distribute of translated manual

[<br...@ph...>]

You're right in stating that the Copyright file (and thus the license of 
all gnuplot source files covered by it) doesn't specifically mention 
translations.  Probably for no other reason than that nobody thought 
anyone would ever actually sit down and do one.  It's already hard to 
make developers write any documentation at all, let alone translate it 
to other languages.

Well, as far as I can see, all should be well provided you don't 
restrict distribution of these translations (most obvious way of doing 
that would be to just put them in the gnuplot CVS at SourceForge, so 
they can become part of the next release tarball).  We would point this 
out as a point needing special attention to the primary copyright 
holder(s), when we next go round asking for the blessing for a release.

Re: wgnuplot's enhanced text mode fails

[<br...@ph...>]

Shigeharu TAKENO wrote:
>  wgnuplot (gnuplot-4.1) may fail by
> 
>   set term win enh
>   plot sin(x)

Actually, the same will fail on *any* terminal that has enhanced mode 
turned on.  It'll also fail on more than just wgnuplot, I suspect.

I'll check in a modified version of the fix immediately.  Thanks for 
spotting this (and for generally acting as our only liaison to the 
Japanese gnuplot community).

Re: To distribute of translated manual

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

On Thursday 16 March 2006 03:32 am, Shigeharu TAKENO wrote:
> 
> The gnuplot "Copyright" file does not seem to say about the 
> translations of documents to foreign languages, or to another 
> formats. I want to know whether it is permitted, and what 
> conditions I must satisfy to distribute them.

I do not have a definitive legal answer, and I doubt anyone
here can give you one.  

For what little it is worth, you have my permission.
But I am only one of many copyright holders who have contributed
code and documentation to gnuplot.

You may have seen the recent discussion on the mailing list,
which summarized the unfortunate fact that there is not 
currently a GPL- or BSD- like license in place for gnuplot.

My suggestion is that you contribute your translation of the
documentation back to the gnuplot project. When the next
version of gnuplot is released your translation would then be 
covered by the same authorization that covers release of the
new version itself.

There is in fact a section of the SourceForge project site
for contributed documentation, but currently it is empty.

    http://sourceforge.net/docman/?group_id=2055

I will look into putting a copy of the current PDF docs there,
and your translations could be made available there also.

I realize that this does not answer your questions about 
distributing material from your own web site.
My personal opinion and advice is that anything you distribute
should also be available from the main gnuplot project site.

	I hope that helps,

		Ethan

> 
> For example: 
> 
> on our WWW site, 
> 
> 1) to distribute tar ball manuals including:
>  [a] the Japanese translation of gnuplot.doc
>  [b] a patch for Japanese translations of term/*.trm
>  [c] README for Japanese user
> 
> (cf. http://takeno.iee.niit.ac.jp/~foo/gp-jman/data/
>   20050620/gp400-20050620.tar.gz)
> 
> 2) to distribute 1) [a] only
> 
> (cf. http://takeno.iee.niit.ac.jp/~foo/gp-jman/data/
>   current/gp410-20060312.doc.gz)
> 
> 3) to distribute 1) [b] only
> 
> (cf. http://takeno.iee.niit.ac.jp/~foo/gp-jman/data/
>   current/term410-20060312.diff.gz)
> 
> 4) to distribute another format file made from 1) [a] by 
>  doc/doc2* tools
> 
> (cf. http://takeno.iee.niit.ac.jp/~foo/gp-jman/data/
>   20050620/gp400-20050620.{html,gih,ps,pdf,...})
> 
> 5) to distribute 
>  [e] the Japanese translation of faq/faq.tex 
>    (http://cvs.sourceforge.net/viewcvs.py/gnuplot/faq/faq.tex)
> 
> (cf. http://takeno.iee.niit.ac.jp/~shige/unix/
>   gnuplot/faq-j-20050318.tex) 
> 
> 6) to distribute another format file made from 5) [e] 
> 
> (cf. http://takeno.iee.niit.ac.jp/~shige/unix/
>   gnuplot/faq-j-20050318.{html,pdf,ps,...})
> 
> 7) to distribute an archive including Japanized files for 
>  wgnuplot:
>  [f] the Japanese translation of wgnuplot.mnu
>  [g] wgnuplot.hlp made from 1) [a]
>  [h] README for Japanese user
>  [i] gnuplot's original Copyright file
> 
> (cf. http://takeno.iee.niit.ac.jp/~foo/gp-jman/data/
>   wgp-jp/wgp400-20050625.zip)
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 


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

wgnuplot's enhanced text mode fails

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

shige 03/18 2006
----------------

On gnuplot QandA BBS (Japanese), the following problem was
reported:

 wgnuplot (gnuplot-4.1) may fail by

  set term win enh
  plot sin(x)

To fix the problem, Akira Kakuto (ka...@fu...) 
submited the following patch:

----- From here -----
--- src/graphics.c.orig	Sun Mar 12 16:57:38 2006
+++ src/graphics.c	Sat Mar 18 16:07:05 2006
@@ -345,7 +345,7 @@
     /* This should go *inside* label_width(), but it messes up the key title */
     /* Imperfect check for subscripts */
     if (term->flags & TERM_ENHANCED_TEXT)
-	if (strchr(axis_array[FIRST_X_AXIS].label.text,'_'))
+	if (axis_array[FIRST_X_AXIS].label.text && strchr(axis_array[FIRST_X_AXIS].label.text,'_'))
 	    xlablin++;
 #endif
     if (axis_array[SECOND_X_AXIS].label.text)
----- To here ----- 

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

Re: valgrind

[<br...@ph...>]

Daniel J Sebald wrote:
> ==9857== Conditional jump or move depends on uninitialised value(s)
> ==9857==    at 0x8060111: update (fit.c:989)
> 
>    tmp = s + strlen(s) - 1;
>    while (*tmp != '\\' && *tmp != '/' && *tmp != ':' && tmp - s >= 0)
> [989]    tmp--;

That's the same line 989 that I was looking at when I said there's no 
conditional anywhere in it.  One possible problem is that tmp could be 
moved to before 's'.  A change of test sequence might be in order. 
Checked into CVS.