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

Re: Death of usenet

[Hans-Bernhard B. <HBB...@t-...>]

Philipp K. Janert wrote:
> I learned recently that one can subscribe to usenet groups 
> via Google Groups, so that one gets usenet postings via 
> email. I have used Google's web interface to post.

So have a lot of others.  Which only contributes to Google's "success" 
as the single biggest source of USENET's problems these days.

Google groups sucks badly as a posting interface.  It's the only system 
that ever managed to create even more broken postings than Outlook.

Gmail accounts have become today's source #1 for USENET spam.

Reaping Google's adword payouts on Google's own blogspot pages has 
become a major motive for USENET spam.

And last but not least, groups.google.com has so completely clouded the 
distinction between actual USENET and their own, Google-only discussion 
groups that many people no longer know the difference.

> That being said, I find it confusing to have a gnuplot
> users mailing list (gnu...@li...)
> AND a users newsgroup (comp.graphics.apps.gnuplot).

They used to be bidirectionally gatewayed to each other.  This died 
years ago, when we lost support by Dartmouth.edu.  Sourceforge.net 
doesn't offer a USENET gateway.

Re: Death of usenet

[Philipp K. J. <ja...@ie...>]

I learned recently that one can subscribe to usenet groups 
via Google Groups, so that one gets usenet postings via 
email. I have used Google's web interface to post.

I find this a convenient way to keep tab on the (very few)
newsgroups I am interested in (including  
comp.graphics.apps.gnuplot group).

That being said, I find it confusing to have a gnuplot
users mailing list (gnu...@li...)
AND a users newsgroup (comp.graphics.apps.gnuplot).
I have also been trapped by confusing the two. It would
make sense to settle on only one of the two forms of
communication (and visibly shutter the other one down).

I would also like to point out that this page:
	http://www.gnuplot.info/help.html
states that the newsgroup is the same as the mailing
list, which is NOT TRUE. Once we have clarity on the
strategy going forward, we should update the website
accordingly.

Best,

		Ph.



On Tuesday 23 September 2008 16:41, Ethan Merritt wrote:
> On Tuesday 23 September 2008 08:53:27 don taber wrote:
> > > So unless I find an alternative quickly, I will disappear from
> > > comp.graphics.apps.gnuplot
> >
> > I have had good luck with the free nntp server at
> > news.motzarella.org.  You need to register (free)
> > and be issued a password.  They have c.g.a.p
>
> Thanks for the pointer!
>
> Yeah, that seems to work OK except that I can't persuade it
> to accept an encrypted connection.  Not a big deal.
>
> 	Ethan
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK & win
> great prizes Grand prize is a trip for two to an Open Source event anywhere
> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Death of usenet

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

On Tuesday 23 September 2008 08:53:27 don taber wrote:
> > So unless I find an alternative quickly, I will disappear from
> > comp.graphics.apps.gnuplot
> 
> I have had good luck with the free nntp server at
> news.motzarella.org.  You need to register (free)
> and be issued a password.  They have c.g.a.p

Thanks for the pointer!

Yeah, that seems to work OK except that I can't persuade it
to accept an encrypted connection.  Not a big deal.

	Ethan

Re: Death of usenet

[don t. <dt...@to...>]

> So unless I find an alternative quickly, I will disappear from
> comp.graphics.apps.gnuplot

I have had good luck with the free nntp server at
news.motzarella.org.  You need to register (free)
and be issued a password.  They have c.g.a.p

Don Taber

Re: Death of usenet

[<gnu...@t4...>]

> I know that the death of usenet has been predicted many times,
> but at least in my corner of the world it seems to be actually
> happening.
> ...
> Any ideas how we might move forward to a new user support mechanism?


All of my usenet feeds have also died within the last year or two, so
I tend to agree. (I also agree all the web usenet interfaces I've seen
are lacking.) Usenet requires large amounts of disk space and bandwidth
(depending on how well-connected one is), and news daemons are terribly
finicky and prone to instability. For the two remaining users (out of
several thousand active) taking advantage of the service, it just wasn't
worth the upkeep.

For asynchronous user support, I like the idea of mailing lists. It is
nice, however, to have a more immediate (synchronous) support mechanism
available, for which I'd recommend IRC. IRC seems to work reasonably
well for a number of other open-source projects. I hung out on #gnuplot
on freenode today, and there are a few people in the channel, but not
so much as a join or part in several hours. To the extent support is
available there, our users apparently don't know it.

4.2.4 release tarball now on SourceForge

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

I've tagged 4.2.4 in CVS for release, and uploaded 
source tarball, pdf, and release notes to SourceForge.

They've changed the procedure; it's easier now.

I'll give it a day or so to propagate to the mirrors
before announcing it on the newsgroup.

-- 
Ethan A Merritt
sf...@us...

Re: Death of usenet

[Hans-Bernhard B. <HBB...@t-...>]

Ethan Merritt wrote:

> The "Help forum" on the gnuplot SourceForge site has historically
> been drowing in spam, and seems to be broken completely today.

Works fine here.  And I haven't seen Spam on it in quite a while now.

The real problem is that it's incredibly inefficient.  It's virtually 
impossible to conduct a useful discussion with such unusable quoting and 
without any filtering mechanisms.

> Here's the error I see when trying to access it from the main site:
> 
>   An error occurred while loading http://sourceforge.net/forum/forum.php
>   Connection to host sourceforge.net is broken. 

This happens from time to time. It usually clears by just reloading the 
page.

> Any ideas how we might move forward to a new user support mechanism?

Maybe USENET isn't quite as dead as it looks from your current 
point-of-view.  I see no indication of it being terminated by either 
ISPs or Universities around here.

Death of usenet

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

I know that the death of usenet has been predicted many times,
but at least in my corner of the world it seems to be actually 
happening.

My University dropped its usenet feed at the end of the Summer;
my ISP (Comcast) is dropping it as of this week.

While it may be possible for me to find a pay-for-service newsfeed
elsewhere, expecting our user community to pay for access to
support requests seems unreasonable.   I realize that delayed 
access through Google and Gmane may well continue, but I can't
be the only one who finds that mechanism painfully slow.

So unless I find an alternative quickly, I will disappear from
comp.graphics.apps.gnuplot

The "Help forum" on the gnuplot SourceForge site has historically
been drowing in spam, and seems to be broken completely today.
Here's the error I see when trying to access it from the main site:

  An error occurred while loading http://sourceforge.net/forum/forum.php
  Connection to host sourceforge.net is broken. 

Any ideas how we might move forward to a new user support mechanism?

-- 
Ethan A Merritt

Re: Limit number of axis ticks?

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

> Bug #2117370 in essence complains that if you foolishly set too
> small an axis tick increment, the number of ticks generated will
> overwhelm your system. In the case provided, the program was
> trying to generated > 10^9 labelled tick marks.
> 
> Can anyone see a problem with sanity-checking the values of
> start, end, and increment in the "set {xyz}tic" command, and
> refusing to draw more ticks than the resolution of the axis?

I like this solution - I've been touched by the "gnuplot deadlock" due to 
too many tics several times.

---
PM

Re: Anything that would hold up a 4.2.4 release?

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

> I'm thinking to release 4.2.4 (Patchlevel 4) this week.
> 
> I realize that there are still issues on the windows terminal
> with "rgb variable" or "palette z", but the current state is at
> least better than 4.2.3. 

The "polyline bug" seems to be fixed.

> Does anyone know of other outstanding bugs or problems that 
> would argue for delaying a 4.2.4 release?  

I vote for release.

---
PM

Anything that would hold up a 4.2.4 release?

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

I'm thinking to release 4.2.4 (Patchlevel 4) this week.

I realize that there are still issues on the windows terminal
with "rgb variable" or "palette z", but the current state is at
least better than 4.2.3. 

Does anyone know of other outstanding bugs or problems that 
would argue for delaying a 4.2.4 release?  

Top section of the NEWS file:

New features, changes and fixes in gnuplot version 4.2.4
===========================================================
* NEW add support for enhanced text mode in the emf terminal driver
* NEW built-in functions 'strftime' and 'strptime'
* NEW set absolute plot margins in screen coordinates
* NEW "nocontours" keyword for splot
* NEW "undefine foo" clears previously defined user variable foo
* NEW allow contouring of pm3d surfaces
* NEW allow color by z value ("palette z") in 2D plots
* NEW "pause mouse close" waits until the plot window is closed
* FIX Do not re-quantize time tics interval explicitly set by user
* FIX (gd post) don't segfault on very long font names
* FIX allow variable color from input file for "with boxes", "with vectors"
* FIX don't run off the end of "set format" commands
* FIX Fix discontinuity in piecewise approximation of inverse error function
* FIX discard out of range vectors in the bitmap terminals (pbm, epson, etc)
* FIX 2nd colour in the colour box for negative palette in postscript
* FIX insure palette is initialized before any objects are drawn
* FIX wxt terminal was not obeying "set palette maxcolors"
* FIX Histograms did not correctly honor 'set style user increment'
* FIX Avoid segfault if tic labels are requested from a non-existent data column
* FIX emf terminal - allow fractional linewidth (fixes 0-length dash problem)
* FIX post terminal - fix parsing error for palfuncparam
* FIX post terminal - escape {} chars in enhanced text mode
* FIX clip "splot with labels" against plot boundaries in 2D mode
* CHANGE try harder to autotitle columns in using specs with expressions
* CHANGE gd.trm: use dynamically-allocated TTF font names
* CHANGE x11: more finely sampled color palette for PM3D
* CHANGE cgm: switch to using web_color_rgbs; approximate RGB colors
* CHANGE fig: more point types, 4.2-style font and size syntax for "set term"
* CHANGE emf: separate dashlength option (don't use linewidth for dashlength)
* CHANGE stacked histograms grow upward for values > 0, downward for values < 0
* CHANGE 'pause mouse button1' (or button2) does not disable zooming
* CHANGE built-in readline tries to recognize <home> and <end> keys

-- 
Ethan A Merritt

Limit number of axis ticks?

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

Bug #2117370 in essence complains that if you foolishly set too
small an axis tick increment, the number of ticks generated will
overwhelm your system. In the case provided, the program was
trying to generated > 10^9 labelled tick marks.

Can anyone see a problem with sanity-checking the values of
start, end, and increment in the "set {xyz}tic" command, and
refusing to draw more ticks than the resolution of the axis?

First cut at patch:

diff -ur gnuplot/src/axis.c gnuplot-cvs/src/axis.c
--- gnuplot/src/axis.c  2008-09-03 11:48:50.000000000 -0700
+++ gnuplot-cvs/src/axis.c      2008-09-18 11:13:18.000000000 -0700
@@ -1053,6 +1053,11 @@
            return;             /* just quietly ignore them ! */
        /* }}} */

+       if ( (end-start)/step > term->xmax) {
+           int_warn(NO_CARET,"Too many axis ticks (>%.0g)", (end-start)/step);
+           return;
+       }
+
        /* FIXME HBB 20010121: keeping adding 'step' to 'tic' is
         * begging for rounding errors to strike us. */
        /* HBB 20010410: ... and strike they did :-( */



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

Re: timelevel setting

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

shige 09/17 2008
----------------

I wrote:
| While we can not do it for 30 days interval simply, we can do the
| other days (ex. 10, 15, 20, 25 days) without such trick. I think 
| the simple way is to enable to modify the automatic timelevel 
| setting.

For example, the following patch enable us to control timelevel by
set xdata:

 set xdata time tmlevel day   # timelevel[x-axis] = TIMELEVEL_DAYS 
 set ydata time tmlevel week  # timelevel[y-axis] = TIMELEVEL_WEEKS
 set xdata time tmlevel none  # not use timelevel[x-axis]
 set xdata time tmlevel auto  # timelevel[x-axis] = automatic setting
 set xdata time               # the same as above

But, I do not know whether this is appropriate or not.

----- From here -----
diff -u src/axis.h.ORG src/axis.h
--- src/axis.h.ORG	Wed Sep 10 12:20:05 2008
+++ src/axis.h	Wed Sep 17 18:21:07 2008
@@ -688,4 +688,17 @@
     || 1 == (plot)->lp_properties.use_palette)
 int set_cbminmax __PROTO((void));
 
+/* shige: moved from axis.c */
+#ifdef USE_CTRL_TIMELEVEL
+typedef enum e_timelevel {
+    TIMELEVEL_SECONDS = 1, TIMELEVEL_MINUTES, TIMELEVEL_HOURS,
+    TIMELEVEL_DAYS, TIMELEVEL_WEEKS, TIMELEVEL_MONTHS,
+    TIMELEVEL_YEARS
+    ,
+    /* shige: add two */
+    TIMELEVEL_NONE = -1, /* unuse timelevel */
+    TIMELEVEL_AUTO = 0 /* use auto setting */
+} t_timelevel;
+#endif
+
 #endif /* GNUPLOT_AXIS_H */
diff -u src/axis.c.ORG src/axis.c
--- src/axis.c.ORG	Wed Sep 10 12:20:05 2008
+++ src/axis.c	Wed Sep 17 18:45:39 2008
@@ -83,12 +83,17 @@
  * self-explanatory */
 /* The unit the tics of a given time/date axis are to interpreted in */
 /* HBB 20040318: start at one, to avoid undershoot */
+/* shige: move to axis.h */
+#ifndef USE_CTRL_TIMELEVEL
 typedef enum e_timelevel {
     TIMELEVEL_SECONDS = 1, TIMELEVEL_MINUTES, TIMELEVEL_HOURS,
     TIMELEVEL_DAYS, TIMELEVEL_WEEKS, TIMELEVEL_MONTHS,
     TIMELEVEL_YEARS
 } t_timelevel;
 static t_timelevel timelevel[AXIS_ARRAY_SIZE];
+#else
+t_timelevel timelevel[AXIS_ARRAY_SIZE];
+#endif
 
 /* The <increment> given in a 'set {x|y|...}tics', or an automatically
  * generated one, if automatic tic placement is active */
@@ -670,6 +675,10 @@
 {
     int guide12 = guide * 3 / 5; /* --> 12 for default of 20 */
 
+/* shige */
+#ifdef USE_CTRL_TIMELEVEL
+    if(timelevel[axis] != TIMELEVEL_AUTO) return tic;
+#endif
     timelevel[axis] = TIMELEVEL_SECONDS;
     if (tic > 5) {
 	/* turn tic into units of minutes */
@@ -794,7 +803,13 @@
      * leading to strange misbehaviours of minor tics on time axes.
      * We used to call quantize_time_tics, but that also caused strangeness.
      */
+/* shige */
+#ifdef USE_CTRL_TIMELEVEL
+    if (this->is_timedata && ticdef->type == TIC_SERIES 
+	&& timelevel[axis] == TIMELEVEL_AUTO) {
+#else
     if (this->is_timedata && ticdef->type == TIC_SERIES) {
+#endif
 	if      (tic >= 365*24*60*60.) timelevel[axis] = TIMELEVEL_YEARS;
 	else if (tic >=  28*24*60*60.) timelevel[axis] = TIMELEVEL_MONTHS;
 	else if (tic >=   7*24*60*60.) timelevel[axis] = TIMELEVEL_WEEKS;
@@ -1165,7 +1180,12 @@
 {
     struct tm tm;
 
+/* shige */
+#ifdef USE_CTRL_TIMELEVEL
+    if (level == TIMELEVEL_NONE || level <= TIMELEVEL_SECONDS) {
+#else
     if (level <= TIMELEVEL_SECONDS) {
+#endif
 	return (ticplace);
     }
     ggmtime(&tm, ticplace);
diff -u src/set.c.ORG src/set.c
--- src/set.c.ORG	Wed Sep 10 12:20:08 2008
+++ src/set.c	Wed Sep 17 18:45:51 2008
@@ -4372,6 +4372,41 @@
 static void
 set_timedata(AXIS_INDEX axis)
 {
+/* shige */
+#ifdef USE_CTRL_TIMELEVEL
+    extern t_timelevel timelevel[];
+    axis_array[axis].is_timedata = FALSE;
+
+    c_token++;
+    while (!END_OF_COMMAND) {
+	if (almost_equals(c_token,"t$ime")) {
+	    axis_array[axis].is_timedata = TRUE;
+	} else if (equals(c_token,"tmlevel")) {
+	    c_token++;
+	    if (almost_equals(c_token,"a$uto")) 
+	      timelevel[axis] = TIMELEVEL_AUTO;
+	    else if (almost_equals(c_token,"s$econd")) 
+	      timelevel[axis] = TIMELEVEL_SECONDS;
+	    else if (almost_equals(c_token,"mi$nute")) 
+	      timelevel[axis] = TIMELEVEL_MINUTES;
+	    else if (almost_equals(c_token,"h$our")) 
+	      timelevel[axis] = TIMELEVEL_HOURS;
+	    else if (almost_equals(c_token,"d$ay")) 
+	      timelevel[axis] = TIMELEVEL_DAYS;
+	    else if (almost_equals(c_token,"w$eek")) 
+	      timelevel[axis] = TIMELEVEL_WEEKS;
+	    else if (almost_equals(c_token,"mo$nth")) 
+	      timelevel[axis] = TIMELEVEL_MONTHS;
+	    else if (almost_equals(c_token,"year")) 
+	      timelevel[axis] = TIMELEVEL_YEARS;
+	    else if (almost_equals(c_token,"no$ne")) 
+	      timelevel[axis] = TIMELEVEL_NONE;
+	    else 
+	      timelevel[axis] = TIMELEVEL_AUTO;
+	}
+	c_token++;
+    }
+#else
     c_token++;
     if(END_OF_COMMAND) {
 	axis_array[axis].is_timedata = FALSE;
@@ -4379,6 +4414,7 @@
 	if ((axis_array[axis].is_timedata = almost_equals(c_token,"t$ime")))
 	    c_token++;
 }
+#endif
 }
 
 
----- To here -----

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

Re: timelevel setting

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

shige 09/16 2008
----------------

Ethan Merritt  wrote: 
| > Perhaps you can accomplish what you want by using some combination
| > of strptime() strftime() and the new iteration function for xtics
| > inspired by your earlier suggestion?
| 
| This approach seems to work, although it conflicts with the setting
| "set xdata time".  Here is my test case:
| 
| TFORMAT = "%d-%m-%Y"
| START   = strptime(TFORMAT,"01-01-2001")
|   END   = strptime(TFORMAT,"01-01-2003")
| DAYS30  = 30*24*60*60
| 
| unset xdata time
| set xrange [START:END]
| 
| set for [date=START:END:DAYS30] xtics (strftime(TFORMAT,date) date)
| 
| set xtics rotate by -90
| plot x

Yes.

While we can not do it for 30 days interval simply, we can do the
other days (ex. 10, 15, 20, 25 days) without such trick. I think 
the simple way is to enable to modify the automatic timelevel 
setting.

| The remaining problem is that the command "set xdata time" is applied
| to both input and output.  In order to use the above approach to control
| output, you must do "unset xdata time".  But then you must also
| explicitly process the input data, rather than using the built-in
| gnuplot timedata system.  So far as I know that work fine, but it
| is an extra requirement.
| 
| I asked on the newsgroup a few weeks ago if anyone was aware of missing
| features that would get in the way of doing the all time processing
| explicitly using strptime() and strftime().  Hans-Bernhard pointed out
| that it would be difficult to do the quantization of tick increments if you
| did this, which is true.  It is interesting that you are now offering a
| case where quantization of tick increments is exactly what you are trying
| to avoid.  So it seems that the built-in and explicit time format
| handling paths may both be needed.
| 
| Nevertheless we may want to provide some way of *not* applying
| the "xdata time" flag to labeling the ticks.  Suggestions?

I think that to enable to modify the timelevel is easier than to 
consider what you say. In the way to handle the timelevel, we may
continue to use the timedata processing system.

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

Re: timelevel setting

[<pl...@pi...>]

On Mon, 15 Sep 2008 23:13:34 +0200, Ethan Merritt  
<merritt@u.washington.edu> wrote:


>
> Nevertheless we may want to provide some way of *not* applying
> the "xdata time" flag to labeling the ticks.  Suggestions?
>
>


Hi,

it would seem that there is a need to differenciate input data and plotted  
axes.

since the variable xdata in essence applies to the data , ie what is read  
in, it would seem best to provide a new variable (perhaps called xaxis)  
that can be different from xdata. If xaxis is not set then gnuplot would  
fall through to the old behaviour of xdata=xaxis and thus backwards compat  
is assured.

regards, Peter.

Re: timelevel setting

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

On Monday 15 September 2008 09:46:13 Ethan Merritt wrote:
> On Sunday 14 September 2008 23:46:02 Shigeharu TAKENO wrote:

> > To obtain "30 days" interval tics (not "1 month" interval), 
> > I think we must specify the interval as 30*24*60*60 (30 days) 
> > and use the timelevel value TIMELEVEL_DAYS, but the patch forces
> > to use TIMELEVEL_MONTHS for "30 days" interval. So, we can not 
> > obtain "30 days" interval tics even if CVS version.
> 
> You are right.  There is a problem.
> 
> Perhaps you can accomplish what you want by using some combination
> of strptime() strftime() and the new iteration function for xtics
> inspired by your earlier suggestion?

This approach seems to work, although it conflicts with the setting
"set xdata time".  Here is my test case:

TFORMAT = "%d-%m-%Y"
START   = strptime(TFORMAT,"01-01-2001")
  END   = strptime(TFORMAT,"01-01-2003")
DAYS30  = 30*24*60*60

unset xdata time
set xrange [START:END]

set for [date=START:END:DAYS30] xtics (strftime(TFORMAT,date) date)

set xtics rotate by -90
plot x


The remaining problem is that the command "set xdata time" is applied
to both input and output.  In order to use the above approach to control
output, you must do "unset xdata time".  But then you must also
explicitly process the input data, rather than using the built-in
gnuplot timedata system.  So far as I know that work fine, but it
is an extra requirement.

I asked on the newsgroup a few weeks ago if anyone was aware of missing
features that would get in the way of doing the all time processing
explicitly using strptime() and strftime().  Hans-Bernhard pointed out
that it would be difficult to do the quantization of tick increments if you
did this, which is true.  It is interesting that you are now offering a
case where quantization of tick increments is exactly what you are trying
to avoid.  So it seems that the built-in and explicit time format
handling paths may both be needed.

Nevertheless we may want to provide some way of *not* applying
the "xdata time" flag to labeling the ticks.  Suggestions?


-- 
Ethan A Merritt

Re: timelevel setting

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

On Sunday 14 September 2008 23:46:02 Shigeharu TAKENO wrote:
> shige 09/15 2008
> ----------------
> 
> Ethan A Merritt wrote:
> | I think that is no longer true.
> | See this note in the ChangeLogs for both 4.2 and 4.3:
> | 
> | 2008-05-08  Thomas Sefzick  <th...@us...>
> |         * src/axis.c (setup_tics):  If the user specified an explicit
> |         tic interval on a timefmt axis, do not change this by calling
> |         quantize_time_tics().
> |         Bug #1908019
> | 
> | This change has been in the CVS version for 6 months, and will be
> | included in the upcoming 4.2.4 release
> 
> I think this patch seems to decide timelevel value from the 
> interval automatically, so it may not do what I want.
> 
> To obtain "30 days" interval tics (not "1 month" interval), 
> I think we must specify the interval as 30*24*60*60 (30 days) 
> and use the timelevel value TIMELEVEL_DAYS, but the patch forces
> to use TIMELEVEL_MONTHS for "30 days" interval. So, we can not 
> obtain "30 days" interval tics even if CVS version.

You are right.  There is a problem.

Perhaps you can accomplish what you want by using some combination
of strptime() strftime() and the new iteration function for xtics
inspired by your earlier suggestion?


-- 
Ethan A Merritt

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated

[Tatsuro M. <tma...@ya...>]

Hello

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated.

http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

I added a distribution style of which is almost the same as that placed at
  http://gnuplot.info/development/binaries/
  The filename of this distribution is 'gp43-winbinX11.zip'.
For install of this package, please read 00READMEgpTeam and 00README_TM in the zip file.

Regards

Tatsuro




--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

Re: timelevel setting

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

shige 09/15 2008
----------------

Ethan A Merritt wrote:
| I think that is no longer true.
| See this note in the ChangeLogs for both 4.2 and 4.3:
| 
| 2008-05-08  Thomas Sefzick  <th...@us...>
|         * src/axis.c (setup_tics):  If the user specified an explicit
|         tic interval on a timefmt axis, do not change this by calling
|         quantize_time_tics().
|         Bug #1908019
| 
| This change has been in the CVS version for 6 months, and will be
| included in the upcoming 4.2.4 release

I think this patch seems to decide timelevel value from the 
interval automatically, so it may not do what I want.

To obtain "30 days" interval tics (not "1 month" interval), 
I think we must specify the interval as 30*24*60*60 (30 days) 
and use the timelevel value TIMELEVEL_DAYS, but the patch forces
to use TIMELEVEL_MONTHS for "30 days" interval. So, we can not 
obtain "30 days" interval tics even if CVS version.

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

[OT] "Gnuplot in Action" Book - Free Content available

[Philipp K. J. <ja...@ie...>]

If you are interested in Gnuplot, you might be interested 
in my upcoming book:
        "Gnuplot in Action"
(To be published, Jan 2009, Manning Publications.)

The manuscript is now complete, and an excerpt from
the first chapter, introducing Gnuplot and its use for
Graphical Analysis, is available for free as "Green Paper"
from the publisher's site:
        www.manning.com/janert

This is also the LAST opportunity to make comments
or give suggestions and feedback on the manuscript
before it goes into print. You can email me (the author)
directly, or post comments on the publishers "Forum"
page.

The book is available for pre-order from the publisher's
site, and of course at Amazon (as well as other sellers):
	www.amazon.com/dp/1933988398

Feel free to forward this information as appropriate.

Best,

                Ph.

Re: timelevel setting

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

On Saturday 13 September 2008, Shigeharu TAKENO wrote:
> shige 09/13 2008
> ----------------
> 
> I have one proposal for timelevel but don't have a patch now.
> Gnuplot uses 'timelevel' for Time/date data. For example,
> 
>  set xdata time
>  set timefmt "%Y %m %d"
>  set format x "%y/%m/%d"
>  set xtics "2008 01 01", 60*60*24*30  # 30 days interval
> 
> makes tics
> 
>  2008/01/01, 2008/02/01, 2008/03/01, ...
> 
> which have "1 month" intervals, not "30 days". This seems to be 
> done by the timelevel value for the axis. Usually "1 month" 
> intervals may be more useful than "30 days" ones.
> 
> However, since the timelevel is always decided automatically
> (in quantize_time_tics() or setup_tics() ?) from the interval
> value, we can not make tics having "30 days" intervals easily 
> (we can do it only by the manual tics setting ("2008 01 01", 
> "2008 01 31", "2008 03 01", ...)). 

I think that is no longer true.
See this note in the ChangeLogs for both 4.2 and 4.3:

2008-05-08  Thomas Sefzick  <th...@us...>
        * src/axis.c (setup_tics):  If the user specified an explicit
        tic interval on a timefmt axis, do not change this by calling
        quantize_time_tics().
        Bug #1908019

This change has been in the CVS version for 6 months, and will be
included in the upcoming 4.2.4 release

	Ethan


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

timelevel setting

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

shige 09/13 2008
----------------

I have one proposal for timelevel but don't have a patch now.
Gnuplot uses 'timelevel' for Time/date data. For example,

 set xdata time
 set timefmt "%Y %m %d"
 set format x "%y/%m/%d"
 set xtics "2008 01 01", 60*60*24*30  # 30 days interval

makes tics

 2008/01/01, 2008/02/01, 2008/03/01, ...

which have "1 month" intervals, not "30 days". This seems to be 
done by the timelevel value for the axis. Usually "1 month" 
intervals may be more useful than "30 days" ones.

However, since the timelevel is always decided automatically
(in quantize_time_tics() or setup_tics() ?) from the interval
value, we can not make tics having "30 days" intervals easily 
(we can do it only by the manual tics setting ("2008 01 01", 
"2008 01 31", "2008 03 01", ...)). 

If gnuplot allows us to control the timelevel value, for example
by an option of xtics, we may use more flexible tics for 
Time/Date data. 

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

Re: Some misprints and problems

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

On Wednesday 10 September 2008, Timothée Lecomte wrote:
> Ethan A Merritt a écrit :
> >
> > uint32_t is defined in the C99 standard, but not for C++.
> > The u_int32_t type is used by BSD and is defined in various compatibility
> > headers.  But neither of these is guaranteed to be on all platforms.
> > We explicitly try not to depend on C99 compliance, and
> > also I do not think we can depend on GLib being present. 
> >   
> My point was that cairo-based terminals do already depend on GLib, so 
> for them we can directly use this library.

OK. I fully agree with that.

> >> Besides, I've been using the same kind of byte-wise and 32-bits 
> >> manipulation with a simple "unsigned int" in 
> >> gp_cairo.c:gp_cairo_draw_image(), where "unsigned int" is implicitly 32 
> >> bits. 
> >>     
> >
> > I think that is not safe.
> > Has the code been tested on native 64-bit machines?
> > That is, machines where sizeof(int)==8 ?
> > I don't currently have such a machine in the lab, but they are not so 
> > very rare.  I used to have several.
> >
> >   
> My personal machine is an Intel Core2 running a 64-bits distribution, 
> but that's most likely not a guarantee. Instead, wikipedia says that 
> sizeof(int)==4 on 64 bits machines with compilers from Solaris, AIX, HP, 
> Linux, Mac OS X, FreeBSD, IBM z/OS and Microsoft's VC++. I'm not sure I 
> can find a machine with sizeof(int)==8 !!

DEC Alpha, for one.  (Wikipedia is wrong if it implies that *all*
compilers from the listed vendors use the LP64 model for data types).
 
-- 
Ethan A Merritt

Re: Some misprints and problems

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

Ethan A Merritt a écrit :
>
> uint32_t is defined in the C99 standard, but not for C++.
> The u_int32_t type is used by BSD and is defined in various compatibility
> headers.  But neither of these is guaranteed to be on all platforms.
> We explicitly try not to depend on C99 compliance, and
> also I do not think we can depend on GLib being present. 
>   
My point was that cairo-based terminals do already depend on GLib, so 
for them we can directly use this library.



>> Besides, I've been using the same kind of byte-wise and 32-bits 
>> manipulation with a simple "unsigned int" in 
>> gp_cairo.c:gp_cairo_draw_image(), where "unsigned int" is implicitly 32 
>> bits. 
>>     
>
> I think that is not safe.
> Has the code been tested on native 64-bit machines?
> That is, machines where sizeof(int)==8 ?
> I don't currently have such a machine in the lab, but they are not so 
> very rare.  I used to have several.
>
>   
My personal machine is an Intel Core2 running a 64-bits distribution, 
but that's most likely not a guarantee. Instead, wikipedia says that 
sizeof(int)==4 on 64 bits machines with compilers from Solaris, AIX, HP, 
Linux, Mac OS X, FreeBSD, IBM z/OS and Microsoft's VC++. I'm not sure I 
can find a machine with sizeof(int)==8 !!

>> On a side note, I am inclined to say that it would have been better to 
>> fix the code that makes margins too big instead of cropping the picture 
>> later...
>>     
>
> Well, I'm already on record as disliking the crop option.
> But if we're going to have it at all, we should at least try to make
> it compile+work on all platforms.
>
>   
Agreed, of course.

Best regards,

Timothée

Re: Some misprints and problems

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

On Wednesday 10 September 2008, you wrote:
> > | I have now fixed these in CVS by adding tests in configure.in
> > | Cropping will fail silently for platforms that both
> > | - do not use autoconf
> > | - have (sizeof(int) != 4)
> > | This can be fixed by adding an explicit definition of GP_UINT32_T
> > | in the appropriate platform-specific configuration file.

> I know it's a bit late, but I'll let you know that cairo-based terminals 
> depend on pango, which in turns depends on GLib, which defines integer 
> types whose sizes are guaranteed on all platforms : gint8, guint8, 
> gint16, guint16, gint32, guint32, gint64, guint64. You can use them by 
> including glib.h first, and then there's no more autoconf magic needed.

uint32_t is defined in the C99 standard, but not for C++.
The u_int32_t type is used by BSD and is defined in various compatibility
headers.  But neither of these is guaranteed to be on all platforms.
We explicitly try not to depend on C99 compliance, and
also I do not think we can depend on GLib being present. 

> Besides, I've been using the same kind of byte-wise and 32-bits 
> manipulation with a simple "unsigned int" in 
> gp_cairo.c:gp_cairo_draw_image(), where "unsigned int" is implicitly 32 
> bits. 

I think that is not safe.
Has the code been tested on native 64-bit machines?
That is, machines where sizeof(int)==8 ?
I don't currently have such a machine in the lab, but they are not so 
very rare.  I used to have several.

> If you choose to be bullet-proof with this crop code, I guess it's  
> worth changing the image code too !

Yes.  If you look in datafile.c, you'll see that there is a ridiculous
amount of code and pre-checking just devoted to sorting out the size of
possible data units.  I wish this could all go away, or be sorted out
by autoconf, but so far that's what we've got.

> On a side note, I am inclined to say that it would have been better to 
> fix the code that makes margins too big instead of cropping the picture 
> later...

Well, I'm already on record as disliking the crop option.
But if we're going to have it at all, we should at least try to make
it compile+work on all platforms.


-- 
Ethan A Merritt