Nabble - Gnuplot - Dev

Re: line color lacking on clipboard (wgnuplot)

2008-10-10T10:42:33Z

On Friday 10 October 2008 03:32:22 Shigeharu TAKENO wrote:

> shige 10/10 2008
> ----------------
>
> Ethan Merritt <merritt@...> wrote:
> | A bit of Googling suggests that the problem may be because we switched from
> | using CreatePenIndirect() to using ExtCreatePen(). Apparently some versions
> | of Windows have trouble with ExtCreatePen and the clipboard.
>
> Thank you for your information.
>
> The following patch forces wgnuplot to use CreatePenIndirect() if
> line_width==1. Certainly, the graph by "plot sin(x)" (made by
> CreatePenIndirect()) can be copied through the clipboard with no
> problem and the copying of the graph by "plot sin(x) lw 5"
> (made by ExtCreatePen()) loses the color, at least on my PC
> (MS-Windows XP).

OK. Applied to CVS for both 4.2 and 4.3

Does this mean that the clipboard still has a problem with
colored lines with linewidth > 1 ?

>
> ----- From here -----
> --- src/win/wgraph.c.ORG Thu Oct 9 08:23:00 2008
> +++ src/win/wgraph.c Fri Oct 10 19:12:10 2008
> @@ -939,13 +939,23 @@
> if (line_width != 1)
> cur_penstruct.lopnWidth.x *= line_width;
>
> - /* use ExtCreatePeninstead of CreatePen/CreatePenIndirect to support
> + /* use ExtCreatePen instead of CreatePen/CreatePenIndirect to support
> * dashed lines if line_width > 1 */
> lb.lbStyle = BS_SOLID;
> lb.lbColor = cur_penstruct.lopnColor;
> +/* shige */
> +#if 0
> lpgw->hapen = ExtCreatePen(
> (line_width==1 ? PS_COSMETIC : PS_GEOMETRIC) | cur_penstruct.lopnStyle | PS_ENDCAP_FLAT | PS_JOIN_BEVEL,
> cur_penstruct.lopnWidth.x, &lb, 0, 0);
> +#else
> + if (line_width==1)
> + lpgw->hapen = CreatePenIndirect((LOGPEN FAR *) &cur_penstruct);
> + else
> + lpgw->hapen = ExtCreatePen(
> + PS_GEOMETRIC | cur_penstruct.lopnStyle | PS_ENDCAP_FLAT | PS_JOIN_BEVEL,
> + cur_penstruct.lopnWidth.x, &lb, 0, 0);
> +#endif
> DeleteObject(SelectObject(hdc, lpgw->hapen));
>
> SelectObject(hdc, lpgw->colorbrush[cur_pen]);
> ----- To here -----
>
> +========================================================+
> Shigeharu TAKENO NIigata Institute of Technology
> kashiwazaki,Niigata 945-1195 JAPAN
> shige@... TEL(&FAX): +81-257-22-8161
> +========================================================+
>

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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: line color lacking on clipboard (wgnuplot)

2008-10-10T03:32:22Z

shige 10/10 2008
----------------

Ethan Merritt <merritt@...> wrote:
| A bit of Googling suggests that the problem may be because we switched from
| using CreatePenIndirect() to using ExtCreatePen(). Apparently some versions
| of Windows have trouble with ExtCreatePen and the clipboard.

Thank you for your information.

The following patch forces wgnuplot to use CreatePenIndirect() if
line_width==1. Certainly, the graph by "plot sin(x)" (made by
CreatePenIndirect()) can be copied through the clipboard with no
problem and the copying of the graph by "plot sin(x) lw 5"
(made by ExtCreatePen()) loses the color, at least on my PC
(MS-Windows XP).

----- From here -----
--- src/win/wgraph.c.ORG Thu Oct 9 08:23:00 2008
+++ src/win/wgraph.c Fri Oct 10 19:12:10 2008
@@ -939,13 +939,23 @@
if (line_width != 1)
cur_penstruct.lopnWidth.x *= line_width;

- /* use ExtCreatePeninstead of CreatePen/CreatePenIndirect to support
+ /* use ExtCreatePen instead of CreatePen/CreatePenIndirect to support
* dashed lines if line_width > 1 */
lb.lbStyle = BS_SOLID;
lb.lbColor = cur_penstruct.lopnColor;
+/* shige */
+#if 0
lpgw->hapen = ExtCreatePen(
(line_width==1 ? PS_COSMETIC : PS_GEOMETRIC) | cur_penstruct.lopnStyle | PS_ENDCAP_FLAT | PS_JOIN_BEVEL,
cur_penstruct.lopnWidth.x, &lb, 0, 0);
+#else
+ if (line_width==1)
+ lpgw->hapen = CreatePenIndirect((LOGPEN FAR *) &cur_penstruct);
+ else
+ lpgw->hapen = ExtCreatePen(
+ PS_GEOMETRIC | cur_penstruct.lopnStyle | PS_ENDCAP_FLAT | PS_JOIN_BEVEL,
+ cur_penstruct.lopnWidth.x, &lb, 0, 0);
+#endif
DeleteObject(SelectObject(hdc, lpgw->hapen));

SelectObject(hdc, lpgw->colorbrush[cur_pen]);
----- To here -----

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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: line color lacking on clipboard (wgnuplot)

2008-10-09T12:52:18Z

On Thursday 09 October 2008 10:58, Bastian Maerkisch wrote:
> Treatment of line colors within the windows terminal is known to be buggy.

If I understand the report correctly, the problem is not with gnuplot's
display of colors. It is instead reporting a problem with the Windows
clipboard operation.

A bit of Googling suggests that the problem may be because we switched from
using CreatePenIndirect() to using ExtCreatePen(). Apparently some versions
of Windows have trouble with ExtCreatePen and the clipboard.
But I did not find a definitive statement or a recommended alternative.

> Currently, nobody is working actively on the windows terminal. I really
> would want to help, but due to my work load, I just cannot find enough time.

Understood. But it would be useful to know if you can replicate
the problem on your Windows machine, and whether switching that
one call back to CreatePenIndirect() fixes it. (I realize that would
re-introduce other problems, but at least we'd confirm what the issue is).

Ethan

>
> Bastian
>
>
> Shigeharu TAKENO schrieb:
> > shige 10/09 2008
> > ----------------
> >
> > On Japanese gnuplot BBS, the following problem was reported:
> >
> > Line colors of wgnuplot's graph (ex. `test` command) may lack on
> > another application which recieve it through the clipboard. This
> > problem arises in wgnuplot-4.2.4 but not 4.2.3.
> >
> > It seems to be arise from src/win/wgraph.c rev.1.58. In fact,
> > wgnuplot with wgraph.c of rev.1.57 has no such problem. But I do
> > not know which code has the problem and how to fix it.
> >
> > +========================================================+
> > Shigeharu TAKENO NIigata Institute of Technology
> > kashiwazaki,Niigata 945-1195 JAPAN
> > shige@... TEL(&FAX): +81-257-22-8161
> > +========================================================+
> >

--
Ethan A Merritt

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: line color lacking on clipboard (wgnuplot)

2008-10-09T10:58:05Z

Treatment of line colors within the windows terminal is known to be buggy.
Currently, nobody is working actively on the windows terminal. I really
would want to help, but due to my work load, I just cannot find enough time.

Bastian

Shigeharu TAKENO schrieb:

> shige 10/09 2008
> ----------------
>
> On Japanese gnuplot BBS, the following problem was reported:
>
> Line colors of wgnuplot's graph (ex. `test` command) may lack on
> another application which recieve it through the clipboard. This
> problem arises in wgnuplot-4.2.4 but not 4.2.3.
>
> It seems to be arise from src/win/wgraph.c rev.1.58. In fact,
> wgnuplot with wgraph.c of rev.1.57 has no such problem. But I do
> not know which code has the problem and how to fix it.
>
> +========================================================+
> Shigeharu TAKENO NIigata Institute of Technology
> kashiwazaki,Niigata 945-1195 JAPAN
> shige@... TEL(&FAX): +81-257-22-8161
> +========================================================+
>
> -------------------------------------------------------------------------
> 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
> gnuplot-beta@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

--
Bastian Märkisch
Physikalisches Institut, Universität Heidelberg
Philosophenweg 12
69120 Heidelberg
Tel.: +49-6221-549239
Fax: +49-6221-549343

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

line color lacking on clipboard (wgnuplot)

2008-10-08T19:35:08Z

shige 10/09 2008
----------------

On Japanese gnuplot BBS, the following problem was reported:

Line colors of wgnuplot's graph (ex. `test` command) may lack on
another application which recieve it through the clipboard. This
problem arises in wgnuplot-4.2.4 but not 4.2.3.

It seems to be arise from src/win/wgraph.c rev.1.58. In fact,
wgnuplot with wgraph.c of rev.1.57 has no such problem. But I do
not know which code has the problem and how to fix it.

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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Death of usenet

2008-09-30T14:37:39Z

Philipp K. Janert wrote:

> And should the gnuplot newsgroup be shuttered down?

It's not up to us to decide about the fate of the newsgroup. We
couldn't shut it down even if we wanted to.

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Death of usenet

2008-09-30T12:35:52Z

On Monday 29 September 2008 18:21:57 Philipp K. Janert wrote:

>
> All of this brings me back to my original question:
>
> Should there be only a single user-discussion
> forum (in addition to the devel list), and should
> this forum be the sourceforge mailiing list
> gnuplot-info@...? And should
> the gnuplot newsgroup be shuttered down?
>
> It strikes me as a good idea. Having two forums is
> confusing and unnecessary. And a mailing list seems
> to be more accepted these days than usenet.

My observation is that the newsgroup continues to be more active
than all of the mailing lists taken together.

>
> On Monday 29 September 2008 12:47, you wrote:
> > 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 (gnuplot-info@...)
> > > 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.
>
> -------------------------------------------------------------------------
> 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
> gnuplot-beta@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: Death of usenet

2008-09-29T18:21:57Z

All of this brings me back to my original question:

Should there be only a single user-discussion
forum (in addition to the devel list), and should
this forum be the sourceforge mailiing list
gnuplot-info@...? And should
the gnuplot newsgroup be shuttered down?

It strikes me as a good idea. Having two forums is
confusing and unnecessary. And a mailing list seems
to be more accepted these days than usenet.

Best,

Ph.

On Monday 29 September 2008 12:47, you wrote:

> 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 (gnuplot-info@...)
> > 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.

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Death of usenet

2008-09-29T12:47:20Z

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 (gnuplot-info@...)
> 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.

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Death of usenet

2008-09-26T17:20:06Z

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 (gnuplot-info@...)
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
> gnuplot-beta@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Anything that would hold up a 4.2.4 release?

2008-09-25T13:16:53Z

Petr Mikulik wrote:

> 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

Might the patch for interpolation of pm3d surface colors be included?

Ben

Re: Death of usenet

2008-09-23T16:41:23Z

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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Death of usenet

2008-09-23T08:53:27Z

> 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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Death of usenet

2008-09-23T01:28:48Z

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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

4.2.4 release tarball now on SourceForge

2008-09-22T21:54:43Z

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
sfeam@...

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Death of usenet

2008-09-22T15:56:10Z

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.

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Death of usenet

2008-09-22T14:17:56Z

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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Anything that would hold up a 4.2.4 release?

2008-09-22T13:29:33Z

> 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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Limit number of axis ticks?

2008-09-22T13:14:13Z

> 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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Anything that would hold up a 4.2.4 release?

2008-09-21T15:49:19Z

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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Limit number of axis ticks?

2008-09-18T11:30:38Z

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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: timelevel setting

2008-09-17T03:02:32Z

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
shige@... TEL(&FAX): +81-257-22-8161
+========================================================+

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: timelevel setting

2008-09-16T05:05:00Z

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
shige@... TEL(&FAX): +81-257-22-8161
+========================================================+

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: timelevel setting

2008-09-15T14:24:34Z

On Mon, 15 Sep 2008 23:13:34 +0200, Ethan Merritt
<merritt@...> 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.

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: timelevel setting

2008-09-15T14:13:34Z

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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: timelevel setting

2008-09-15T09:46:13Z

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 <thse@...>
> | * 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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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

2008-09-15T02:48:46Z

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/

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: timelevel setting

2008-09-14T23:46:02Z

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 <thse@...>
| * 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
shige@... TEL(&FAX): +81-257-22-8161
+========================================================+

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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

2008-09-14T17:47:20Z

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.

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: timelevel setting

2008-09-13T09:49:15Z

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 <thse@...>
* 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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

timelevel setting

2008-09-13T02:30:10Z

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
shige@... TEL(&FAX): +81-257-22-8161
+========================================================+

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Some misprints and problems

2008-09-10T09:37:07Z

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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Some misprints and problems

2008-09-10T09:08:49Z

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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Some misprints and problems

2008-09-10T08:52:46Z

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

-------------------------------------------------------------------------
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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta