Fri 16 Oct 2015 06:38:26 AM UTC, comment #34:
Many thanks Avinoam for the test.
I am happy to close this one :-).
|
Thu 15 Oct 2015 08:47:45 PM UTC, comment #33:
I have checked it on Windows (MXE-Octave) and it works fine.
Good work!
|
Sun 11 Oct 2015 07:44:56 PM UTC, comment #32:
I finally pushed the patch for bug #44765. Looking forward to see what happens on Windows.
|
Sun 11 Oct 2015 11:19:33 AM UTC, comment #31:
Hi,
Could someone with an MXE toolchain and a machine that triggers this bug try the last patch I attached (comment #31 in bug #44765)? Thanks in advance.
|
Sat 25 Apr 2015 02:59:09 PM UTC, comment #30:
Thanks Rik I made bug #44765 depend on this one. I am unsure what the effect is if I close this report as fixed (when confirmed).
|
Sat 25 Apr 2015 02:37:39 PM UTC, comment #29:
Okay. Back the fix for this bug (#44806) out and re-open bug #44765. Can you also link #44806, #44463, and #44765 in the bug tracker so we don't accidentally solve one and break the other two.
|
Sat 25 Apr 2015 08:08:06 AM UTC, comment #28:
I just noticed, while looking at timing issues in bug #44463, that the patch for bug #44765 broke -dpdflatexstandalone output format: the text-less pdf file is broken (nothing is drawn, see below). As this is a regression even on linux, I'd vote for a complete backout as proposed in comment #25 until we find the time to investigate what's actually going wrong in Octave, gl2ps (and)or ghostscript.
See attached resulting foo-inc.eps and foo-inc.pdf. The eps seems right but the pdf (AFAIU an eps converted to pdf) is rendered empty (the file is not empty).
(file #33783, file #33784)
|
Fri 24 Apr 2015 06:51:00 PM UTC, comment #27:
Is there a correlation with GPU and or drivers? Nvidia, Intel, ATI?
|
Fri 24 Apr 2015 05:53:58 PM UTC, comment #26:
Should we back it out entirely, or should we use #ifdef statements to limit draw_axes() to non-Windows platforms? It seems a shame to lose something that works for Linux. But maybe it is only working on Linux because I have an older version of gl2ps.
|
Fri 24 Apr 2015 04:51:01 PM UTC, comment #25:
I'll push the attached cset and reopen bug #44765 if no one has a better idea.
(file #33775)
|
Wed 22 Apr 2015 11:49:13 AM UTC, comment #24:
The OS in bug #44846 was win 7 professional edition 64bit, so indeed pro/family is not the reason for the failure.
|
Wed 22 Apr 2015 06:51:45 AM UTC, comment #23:
I have checked rc3 on 4 Win7 64 bits machines.
On 3 machines rc3 failes to print, on the 4th it OK.
The only difference I can see is that the first 3 are
with Win7 home edition, and the 4th is with win7 professional edition, but I don't think that's the reason for the difference behavior.
|
Tue 21 Apr 2015 07:45:04 AM UTC, comment #22:
Thanks Avinoam for thorough testing.
I have posted our issue on gl2ps mailing list [1] and would like to wait a few days to see if we get an answer before backing-out the change.
Our main clue, for the moment, would be if you could find a common characteristic to the computers that fail: win7 32 or 64 bits, graphics hardware, ...
[1] http://www.geuz.org/pipermail/gl2ps/2015/000408.html
|
Tue 21 Apr 2015 05:54:51 AM UTC, comment #21:
I have checked the "GL2PS warning: Unknown token in buffer".
It is in routine gl2psParseFeedbackBuffer, when the expecrted
tokens are GL_POINT_TOKEN, GL_LINE_TOKEN, GL_LINE_RESET_TOKEN, etc... They are defined in GL.h, and their values are 0x000700-0x000706. The new token has value of 1, and that's the reason for
the "Unknown token".
|
Sun 19 Apr 2015 03:58:12 AM UTC, comment #20:
I have added checking of return values
+verbatin+
if (drawn_axes)
{
GLint vp[4];
GLint rv;
rv = gl2psEndViewport ();
std::cout << " gl2psEndViewport: " << rv << std::endl;
glGetIntegerv (GL_VIEWPORT, vp);
std::cout << "Viewport: " << vp[0] << ", " << vp[1] << ", "
<< vp[2] << ", " << vp[3] << std::endl;
rv = gl2psBeginViewport (vp);
std::cout << " gl2psBeginViewport: " << rv << std::endl;
}
-verbatim-
but the result is
The return values for gl2psEndViewport and gl2psBeginViewport are both 0.
|
Sat 18 Apr 2015 06:57:19 PM UTC, comment #19:
Thanks for testing Avinoam. Unfortunately the viewport is as expected ... I am stuck. Did you try to print error messages as Rik suggested?
We should probably back-out this change before 4.0. In the mean time, I'll make a post on gl2ps mailing list: maybe the warning message together with a description of the way we use gl2psBegin(End)Viewport will ring a bell there.
|
Sat 18 Apr 2015 01:40:28 PM UTC, comment #18:
Adding glFinish did not help.
Again, Octave stops responding until I kill gs.exe, and then I get
|
Fri 17 Apr 2015 09:05:58 PM UTC, comment #17:
Sorry, should read
"...before "gl2psEndViewport ();" "
|
Fri 17 Apr 2015 08:52:11 PM UTC, comment #16:
There is this comment in gl2ps-renderer.cc, right before gl2psEndPage ():
Maybe adding (in gl2ps-renderer.h) a "glFinish ();" before "gl2psEndViewport (vp);" can sort this out?
|
Fri 17 Apr 2015 08:32:55 PM UTC, comment #15:
@Rik (comment #11):
I did what you asked, using current version with original gl2ps-render.h. I checked the usual example
and it works. As you said, the problem is in draw_axes of gl2ps-render.h
@Pantxo (comment #16):
I have used your patch. For the previous example it works fine.
For your test "plot (1:10, ';foo;')" Octave freezes forever, or until I kill the gs.exe process. When I kill it, Octave returns to prompt as you described in comment #9, and I get the output
Anything else I could check?
|
Thu 16 Apr 2015 11:02:19 PM UTC, comment #14:
@Avinoam: Can you test the attached patch. Note that there must be at least two axes in the figure for the test to be relevant (e.g. "plot (1:10, ';foo;')"). It avoids restarting a new sorting tree while nothing has been drawn in the first one. It also prints the returned values for the GL_VIEWPORT.
(file #33696)
|
Thu 16 Apr 2015 10:12:31 PM UTC, comment #13:
Documentation from gl2ps:
Another possibility is that we should be doing error checking. Maybe one of the three gl* functions is returning an error and we should be aborting rather than continuing.
|
Thu 16 Apr 2015 10:02:33 PM UTC, comment #12:
I will check this.
Just a guess:
maybe this two lines should be swapped: First, get the viewport,
and then close the view port, and repopen it.
|
Thu 16 Apr 2015 09:55:53 PM UTC, comment #11:
@Avinoam: Can you take the current version and copy over only gl-render.cc and check if that works?
I believe it will which then means that it is the small code change to gl2ps-render.h that has the problem
|
Thu 16 Apr 2015 09:44:43 PM UTC, comment #10:
I can't confirm what you have seen: I have seen the ghostscript
process running, but killing it did not release Octave freeze.
The print command worked in RC-2 but not in RC-3 (versions ftom ftp://alpha.gnu.org/gnu/octave).
To find the bug, I did some lion hunting, a find out that version
http://hg.savannah.gnu.org/hgweb/octave/rev/cbba639b956b worked well, but in version http://hg.savannah.gnu.org/hgweb/octave/rev/438485f6a479 the print command stopped working on my machine.
Moreover, I took current version http://hg.savannah.gnu.org/hgweb/octave/rev/8bfadb26afcd and changed only files libinterp/corefcn/gl-render.cc and libinterp/corefcn/gl2ps-renderer.h to the last working version, and it is still working, so the ball is in your hands now.
Thanks.
|
Thu 16 Apr 2015 11:48:24 AM UTC, comment #9:
I had access to the computer used for duplicate bug #44846. I saw that when using fltk, Octave hangs in a call to ghostscript.
When I kill the ghostscript process using the Windows task manager, Octave returns to prompt and obviously the printout is either corrupted or simply missing.
If confirmed, the problem is most probably gl2ps producing an invalid output file and ghostscript hanging while trying to process the file.
@Avinoam: Can you confirm the above behavior? Also, just to be sure, did previous 4.0rc work on the machine on which you see this bug, or is the bug machine dependent whatever the rc binary (not rc dependent)?
|
Mon 13 Apr 2015 11:43:50 AM UTC, comment #8:
Checking on a third Win7 PC, with rc3, I got the same problem.
Any hints, why this happen on one machine, and not on other?
|
Sun 12 Apr 2015 07:27:51 AM UTC, comment #7:
Strangely enough, on another Win7 machine, the print command
works well, both for qt and fltk.
I will check on a third machine, to get a winner...
What could be the reason for such behavior?
|
Sat 11 Apr 2015 03:29:30 PM UTC, comment #6:
The same problem with
print -depsc a.ps
or
print -deps a.ps
|
Sat 11 Apr 2015 03:24:45 PM UTC, comment #5:
Does eps output also hang? If not, this bug could be related to bug #44809 (dead lock when trying to convert to ps?)
|
Sat 11 Apr 2015 03:23:07 PM UTC, comment #4:
The gnuplot toolkit works fine.
for the fltk, I get endless warnings:
GL2PS warning: Unknown token in buffer
before octave stops responding.
The same problem with the plot
|
Sat 11 Apr 2015 02:41:50 PM UTC, comment #3:
Just for the record, can you try with the gnuplot graphics toolktit? I expect it will work, but that will at least definitively say that it is a problem with the OpenGL toolkits and gl2ps.
And just in case the problem is with Qt threading
Also, is this only complex plots or is it all plots?
|
Sat 11 Apr 2015 02:33:40 PM UTC, comment #2:
I have installed rc3 from ftp://alpha.gnu.org/gnu/octave,
and still got the same problem, under Win7
|
Sat 11 Apr 2015 04:39:00 AM UTC, comment #1:
Works for me.
Mercurial id: b34a23c8a9c4
MXE id: d135404e71a4
It is awfully slow to print, but it does complete after 5 seconds.
|
Fri 10 Apr 2015 10:30:37 PM UTC, original submission:
Using
In octave-4.0.0-rc2 from ftp://alpha.gnu.org/gnu/octave
it works fine. Using http://hg.savannah.gnu.org/hgweb/octave/rev/81c31198a193 from Octave and http://hg.octave.org/mxe-octave/rev/2db17a8585e6 from mxe octave, (using my build) the print command freezes on line 168 of
__opengl_print__.m :
+verbatm+
drawnow (gl2ps_device{n}, ['|' pipeline{n}]);
=verbatim-
and octave stops responding. Is the problem with my build?
|