Menu
▾
▴
gnuplot-beta
|
From: Tatsuro M. <tma...@ya...> - 2008-09-08 07:24:23
|
Hi I have opened a new web site which distributes gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x. http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/ Regards Tatsuro -------------------------------------- Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! http://pr.mail.yahoo.co.jp/mlb/ |
|
From: J. A. V. <jai...@gm...> - 2008-09-08 07:58:09
|
Hello, This is really good news. If I've understood well, if I compile this sourcecode with cygwin I will obtain a gnuplot binary with the WXT interface? I've been waiting an easy way to have the WXT interface for windows, and If you can confirm that with this way I will obtain it, I will compile it as soon as possible and let all you know my results. Thank you very much Tatsuro, Jaime |
|
From: Tatsuro M. <tma...@ya...> - 2008-09-08 08:29:48
|
Hello Unfortunately wxt terminal does not work yet because pango and cario on cygwin is too old to use current wxt terminal on cygwin. If you want to achive your request on cygwin, you have to build recent cario and pango and some missing componets. If you want wxt terminal on windows, it is better to use gnuplot bundled with octave 3.5.10. Once you install octave for windows and search bin directry. You can select the gnuplot for windows and related dll files. here. You can find required dll files for wgnuplot, pgnuplot etc. by the cygcheck command. It is the most easy way at to get the wxt terminal for windows. Regards Tatsuro --- Jaime Armend醇@riz Villalba <jai...@gm...> wrote: > Hello, > > This is really good news. If I've understood well, if I compile this > sourcecode with cygwin I will obtain a gnuplot binary with the WXT > interface? > > I've been waiting an easy way to have the WXT interface for windows, and If > you can confirm that with this way I will obtain it, I will compile it as > soon as possible and let all you know my results. > > Thank you very much Tatsuro, > > Jaime > -------------------------------------- Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! http://pr.mail.yahoo.co.jp/mlb/ |
|
From: Petr M. <mi...@ph...> - 2008-09-08 08:34:36
|
> I have opened a new web site which distributes gnuplot 4.3 (cvs) cygwin > binaries prepared by gcc-4.x.x. > http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/ The binaries of the gnuplot development series are available at http://www.gnuplot.info/development/binaries/ I refresh them from time to time. Considering cygwin-x11, currently there is gp43-Mar24_2008-winbinX11.zip I propose that you prepare the gnuplot4.3.cygwin.tar.bz2 using the same file contents (but updated) as the file mentioned above. Then I can put it on the gnuplot web site and the updated package will be easily accessible by anybody from this traditional location, referenced even from the gnuplot main page. --- PM |
|
From: J. A. V. <jai...@gm...> - 2008-09-08 08:36:02
|
Thank you very much Tatsuro, I will probably extract the gnuplot from the octave files. Jaime |
|
From: Tatsuro M. <tma...@ya...> - 2008-09-08 08:49:48
|
Hello --- Petr Mikulik <mi...@ph...> wrote: > > I have opened a new web site which distributes gnuplot 4.3 (cvs) cygwin > > binaries prepared by gcc-4.x.x. > > http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/ > > The binaries of the gnuplot development series are available at > http://www.gnuplot.info/development/binaries/ > > I refresh them from time to time. Considering cygwin-x11, currently there is > gp43-Mar24_2008-winbinX11.zip > > I propose that you prepare the gnuplot4.3.cygwin.tar.bz2 using the same file > contents (but updated) as the file mentioned above. Then I can put it on the > gnuplot web site and the updated package will be easily accessible by > anybody from this traditional location, referenced even from the gnuplot > main page. I agree with your proposal. Please give me some time. I will do the work on it next weekend. Regards Tatsuro -------------------------------------- Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! http://pr.mail.yahoo.co.jp/mlb/ |
|
From: J. A. V. <jai...@gm...> - 2008-09-08 08:54:34
|
This is a great work :) On Mon, Sep 8, 2008 at 10:49 AM, Tatsuro MATSUOKA <tma...@ya...>wrote: > Hello > > --- Petr Mikulik <mi...@ph...> wrote: > > > > I have opened a new web site which distributes gnuplot 4.3 (cvs) cygwin > > > binaries prepared by gcc-4.x.x. > > > http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/ > > > > The binaries of the gnuplot development series are available at > > http://www.gnuplot.info/development/binaries/ > > > > I refresh them from time to time. Considering cygwin-x11, currently there > is > > gp43-Mar24_2008-winbinX11.zip > > > > I propose that you prepare the gnuplot4.3.cygwin.tar.bz2 using the same > file > > contents (but updated) as the file mentioned above. Then I can put it on > the > > gnuplot web site and the updated package will be easily accessible by > > anybody from this traditional location, referenced even from the gnuplot > > main page. > > I agree with your proposal. Please give me some time. I will do the work > on it next weekend. > > 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 > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Petr M. <mi...@ph...> - 2008-09-08 16:54:29
|
> The binaries of the gnuplot development series are available at > http://www.gnuplot.info/development/binaries/ I've just updated the 4.3-cvs binaries of windows, cygwin-x11 as well as the tarball. Available from the gnuplot homepage or directly the URL above. Enjoy, P.M. |
|
From: Tatsuro M. <tma...@ya...> - 2008-09-09 06:04:22
|
Hello --- Petr Mikulik <mi...@ph...> wrote: > > The binaries of the gnuplot development series are available at > > http://www.gnuplot.info/development/binaries/ > > I've just updated the 4.3-cvs binaries of windows, cygwin-x11 as well as the > tarball. Available from the gnuplot homepage or directly the URL above. Thanks. I will see your package and arrange my binary in your style. Regards. Tatsuro -------------------------------------- Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! http://pr.mail.yahoo.co.jp/mlb/ |
|
From: Tatsuro M. <tma...@ya...> - 2008-09-15 09:48:43
|
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/ |
|
From: Ethan M. <merritt@u.washington.edu> - 2008-09-08 17:59:02
Attachments:
win_polyline.bug.gz
|
On Monday 08 September 2008 09:54:33 Petr Mikulik wrote: > > The binaries of the gnuplot development series are available at > > http://www.gnuplot.info/development/binaries/ > > I've just updated the 4.3-cvs binaries of windows, cygwin-x11 as well as the > tarball. Available from the gnuplot homepage or directly the URL above. That's great. But I see that the bug demonstrated by the attached script is still present. I have reverted in CVS the patch that I suspect is responsible. Bastian Maerkisch is looking into the problem, but until we have a more solid fix I think reversion is best. Petr: Could you test whether the latest CVS (just changed a few minutes ago) fixes the win terminal bug as tested by the attached script? Bastian: The original patch that I have reverted looks wrong to me, now that I have stared at the code. Do you have a script that demonstrates the problem it was originally intended to fix? So far as I can see, there should be no path through the code that produces a "polyline of length 1". The vertex counter starts at 1, and each polyline vector call increases it. So (polyi == 1) really means a polyline of length 0, and we shouldn't draw it. But maybe it should execute a MoveTo()? -- Ethan A Merritt |
|
From: Petr M. <mi...@ph...> - 2008-09-08 21:08:39
|
> > But I see that the bug demonstrated by the attached script is still present. > I have reverted in CVS the patch that I suspect is responsible. > > Bastian Maerkisch is looking into the problem, but until we have a more solid > fix I think reversion is best. > > Petr: > Could you test whether the latest CVS (just changed a few minutes ago) fixes > the win terminal bug as tested by the attached script? Now it is even worse -- no colour lines at all! Just black lines for win_polyline.bug, and empty plot for winpoly.gp. -- PM |
|
From: Bastian M. <bma...@we...> - 2008-09-08 18:34:08
|
Ethan Merritt schrieb:
>
> But I see that the bug demonstrated by the attached script is still present.
> I have reverted in CVS the patch that I suspect is responsible.
> Bastian Maerkisch is looking into the problem, but until we have a more solid
> fix I think reversion is best.
>
> Petr:
> Could you test whether the latest CVS (just changed a few minutes ago) fixes
> the win terminal bug as tested by the attached script?
>
> Bastian:
> The original patch that I have reverted looks wrong to me, now that I have
> stared at the code. Do you have a script that demonstrates the problem it
> was originally intended to fix? So far as I can see, there should be no
> path through the code that produces a "polyline of length 1". The vertex
> counter starts at 1, and each polyline vector call increases it. So
> (polyi == 1) really means a polyline of length 0, and we shouldn't draw it.
> But maybe it should execute a MoveTo()?
>
Ethan, your conclusion is not correct.
Polylines are drawn with commands like this:
MOVE, VECTOR, VECTOR, VECTOR, VECTOR, ...
The code defines the end of a polyline if the next command is not VECTOR.
In the case of RGB color lines there actually are length 1 polylines.
That's because they are drawn with commands like like that:
MOVE, COLOR, VECTOR, COLOR, VECTOR, COLOR, ...., VECTOR
The fix, which you just reverted, fixes this.
The new bug is IMHO triggered by some ill-behaviour of the Windows API.
In the case you just send me the command sequence is like this:
MOVE, VECTOR, COLOR, VECTOR, COLOR, VECTOR, COLOR, ...., VECTOR
The first move and vector command reference the same point. The windows
API optimizes this away and does not even update the drawing position.
So with the next VECTOR we get "spurious" lines.
Why don't you try the single line fix I sent to the mailing list? We
hist add an additional MoveTo() after each Polyline, like this:
if ((lastop==W_vect) && (curptr->op!=W_vect)) {
if (polyi >= 2) {
Polyline(hdc, ppt, polyi);
MoveTo(hdc, ppt[polyi-1].x, ppt[polyi-1].y); /* make sure we move the
drawing position in case of empty polygons */
} else if (polyi == 1)
LineTo(hdc, ppt[0].x, ppt[0].y);
polyi = 0;
}
|
|
From: Ethan M. <merritt@u.washington.edu> - 2008-09-08 18:58:34
|
On Monday 08 September 2008 11:34:24 Bastian Maerkisch wrote:
>
> Ethan Merritt schrieb:
> >
> > But I see that the bug demonstrated by the attached script is still present.
> > I have reverted in CVS the patch that I suspect is responsible.
>
> > Bastian Maerkisch is looking into the problem, but until we have a more solid
> > fix I think reversion is best.
> >
> > Petr:
> > Could you test whether the latest CVS (just changed a few minutes ago) fixes
> > the win terminal bug as tested by the attached script?
> >
> > Bastian:
> > The original patch that I have reverted looks wrong to me, now that I have
> > stared at the code. Do you have a script that demonstrates the problem it
> > was originally intended to fix? So far as I can see, there should be no
> > path through the code that produces a "polyline of length 1". The vertex
> > counter starts at 1, and each polyline vector call increases it. So
> > (polyi == 1) really means a polyline of length 0, and we shouldn't draw it.
> > But maybe it should execute a MoveTo()?
> >
>
> Ethan, your conclusion is not correct.
>
> Polylines are drawn with commands like this:
> MOVE, VECTOR, VECTOR, VECTOR, VECTOR, ...
> The code defines the end of a polyline if the next command is not VECTOR.
But after the first MOVE, polyi is *already* equal to 1.
The (polyi == 1) case corresponds to no VECTORs at all.
A length 1 polyline must necessarily have (polyi == 2).
> In the case of RGB color lines there actually are length 1 polylines.
> That's because they are drawn with commands like like that:
> MOVE, COLOR, VECTOR, COLOR, VECTOR, COLOR, ...., VECTOR
^^^^ polyi = 1
^^^^^^ polyi = 2
> The fix, which you just reverted, fixes this.
I'm working blind, since I can't actually compile and test this.
But I sure don't see from the code how you can ever have a polyline
with (polyi == 1).
> The new bug is IMHO triggered by some ill-behaviour of the Windows API.
> In the case you just send me the command sequence is like this:
> MOVE, VECTOR, COLOR, VECTOR, COLOR, VECTOR, COLOR, ...., VECTOR
> The first move and vector command reference the same point. The windows
> API optimizes this away and does not even update the drawing position.
I don't understand what you are saying. By "optimize away" do you mean
"ignores both the move and the vector"? That would be a serious bug indeed.
It seems especially strange the the optimization would only occur if there
is an intervening call to COLOR (remember that the error is not triggered
if the line color is constant).
What exactly does "COLOR" mean in that sequence?
Is it a call to to W_pm3d_setcolor, or is it an actual API call?
> So with the next VECTOR we get "spurious" lines.
>
> Why don't you try the single line fix I sent to the mailing list? We
> hist add an additional MoveTo() after each Polyline, like this:
>
> if ((lastop==W_vect) && (curptr->op!=W_vect)) {
> if (polyi >= 2) {
> Polyline(hdc, ppt, polyi);
> MoveTo(hdc, ppt[polyi-1].x, ppt[polyi-1].y); /* make sure we move the
> drawing position in case of empty polygons */
> } else if (polyi == 1)
> LineTo(hdc, ppt[0].x, ppt[0].y);
> polyi = 0;
> }
You've tested that this fixes the bug show by the test script?
I may be more than usually befuddled, but I just don't understand how it could.
If there is a spurious line, then you will have already drawn it
before you call the MoveTo.
For what it's worth, the test case *should* be generating a sequence like
COLOR MOVE VECTOR COLOR MOVE VECTOR COLOR MOVE VECTOR
Possibly with interspersed calls to W_linetype, although they are supposed to
be optimized away at a higher level.
If it's not doing that, then I think the true bug may lie entirely elsewhere.
You said earlier that the calls to WIN_set_color were generating empty polylines,
but only in the case of variable color. Doesn't that seem strange?
--
Ethan A Merritt
|
|
From: Ethan M. <merritt@u.washington.edu> - 2008-09-08 20:20:06
|
Here is an even more simple-minded test case that shows the code is still seriously broken. It works fine for all rgb-capable terminal except win. plot '-' using 1:2:3 with lines lc rgb var 0 0 0 0 0 51200 1 0.3 51200 0 0.3 51200 1 0.6 51200 0 0.6 51200 1 0.9 51200 e -- Ethan A Merritt |
