Mon 13 Jul 2015 03:21:37 PM UTC, comment #38:
I think the original issue of this bug report has been fixed well enough so I will close this issue report. It took a while because of the change in the build system which introduced all sorts of new problems.
For polar plots and the lack of a title there is already a bug report outstanding (https://savannah.gnu.org/bugs/?45514).
For hist, there is your bug report here (https://savannah.gnu.org/bugs/?45514).
|
Mon 13 Jul 2015 10:40:44 AM UTC, comment #37:
But,
make -i
make
fixes it.
So, it seems to be out of sequence
problem
|
Mon 13 Jul 2015 10:03:58 AM UTC, comment #36:
Well, I spoke too soon:
Full build from new source (default) ends with
GEN scripts/plot/util/gnuplot_binary.m
GEN scripts/.DOCSTRINGS
GEN doc/interpreter/voronoi.txt
/home/godfrey/d/src/octave/hg/octave/libtool: line 10062: /home/godfrey/d/src/octave/hg/octave/src/octave: No such file or directory
Makefile:26170: recipe for target 'doc/interpreter/voronoi.txt' failed
make[2]: *** [doc/interpreter/voronoi.txt] Error 127
make[2]: Leaving directory '/home/godfrey/d/src/octave/hg/octave'
Makefile:24262: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/godfrey/d/src/octave/hg/octave'
Makefile:9463: recipe for target 'all' failed
make: *** [all] Error 2
[godfrey@pbdsl4 octave]$
|
Mon 13 Jul 2015 08:39:41 AM UTC, comment #35:
Latest patches look good. The following still happens:
GEN doc/interpreter/spchol.eps
GL2PS info: OpenGL feedback buffer overflow
GEN doc/interpreter/spcholperm.eps
GEN doc/interpreter/spchol.pdf
GL2PS info: OpenGL feedback buffer overflow
GEN doc/interpreter/spcholperm.pdf
GEN doc/interpreter/spchol.png
GL2PS info: OpenGL feedback buffer overflow
GEN doc/interpreter/spcholperm.png
Otherwise:
make followed by make no longer builds anything.
plots in Manual look good. (Except for histogram...)
plotimages.m seems to me to be doing the right thing.
So, it may be appropriate to close this report as
the original problems that it reported have been dealt with.
New reports on the histogram and polar plots should
be opened.
histogram: incorrect fill
polar: No title appears in plot.
|
Mon 13 Jul 2015 12:07:35 AM UTC, comment #34:
I noticed that as of a recent change, plotimages.m
does not select the graphics_toolkit any more.
This will not work for gnuplot. One of my csets had
the code to handle gnuplot, but it has not been
included.
Currently, only "extended" needs OpenGL, so use
of gnuplot requires a test to use the old extended
code (which has been removed) in the extended section.
This could be what caused John's problem.
|
Sun 12 Jul 2015 11:52:17 PM UTC, comment #33:
Rik,
You have likely seen this, but is what I
get for current default on Fedora 22:
warning: load_path: ./doc/interpreter: No such file or directory
warning: called from
plotimages at line 101 column 7
GEN doc/interpreter/gplot.pdf
GEN doc/interpreter/grid.pdf
GEN doc/interpreter/spmatrix.pdf
GEN doc/interpreter/spchol.pdf
GL2PS info: OpenGL feedback buffer overflow
There are a few more GL2PS info... messages
|
Sun 12 Jul 2015 11:10:23 PM UTC, comment #32:
Rik,
My message about plotimages.m looks OK in the bug tracker
but not in the email. I did use
Anyhow, what you did was just to insert \displaystyle
but not change the rest of the line.
The line as it should be for both the plotimage.m and plot.txi
files is (as below)
Is there a better way to communicate this?
Mostly, the build looked nearly OK, but I should
do a full build before complaining more.
Michael
|
Sun 12 Jul 2015 10:03:01 AM UTC, comment #31:
Rik:
As of the latest patches the make check problems
are all fixed for me (Fedora 22).
|
Sun 12 Jul 2015 12:38:47 AM UTC, comment #30:
Rik,
I just resolved a problem with the display of math
in -dpdflatexstandalone mode.
In plotimages.m the line:
And, the same change to the corresponding line in plot.txi
Oh, I just realized that the above lines are split in the plotimage.m and plot.txi files
but just add the \displaystyle where it belongs as above.
If this is a nuisance I can submit a dcset after things quite down.
|
Sat 11 Jul 2015 10:51:34 PM UTC, comment #29:
Rik:
I just built a default system with the large
batch of updates for the new makefile. Mostly
went smoothly, and make check runs correctly (almost).
Two things I noticed:
1. The version of plot.txi may have new stuff, but
the correct version of the material about
-dpdflatexstandalone has been lost. I think that
you applied the updates a few days ago so maybe
you can reinstate them. Or, I could remake a cset
if you want.
The easy check of whether the updates are correct is
the text just above Figure 15.7. If the text string
in the description matches what is shown in the plot
it is up-to-date. Right now they do not match.
2. When make check is run, it runs:
GEN doc/interpreter/extended.pdf
This has been true all along, and I am sure
are aware of it. Just a reminder. This may go away
when the directory referencing problem in plotimages.m
is fixed.
|
Sat 11 Jul 2015 05:08:41 PM UTC, comment #28:
Rik:
I assumed that this was the cause. This also affects
make check. Your patch made that better, but not well-
formatted.
When you are working on plotimages.m remember the
cleanup starting at line 93. Only one
if (strcmp (typ, "pdf"))
is needed there instead of two.
This would matter more if anyone wants to
allow use of gnuplot again. I would prefer to drop gnuplot
as a dependence for builds, but others may have other views.
Looks to me like it is getting done, and is MUCH better
than before.
|
Sat 11 Jul 2015 04:35:03 PM UTC, comment #27:
@Michael: Yes, this is due to some changes in the build system that happened just a few days ago. It used to be that the build system was recursive and cd'ed into each directory and then ran commands from there. Now the build system sits at the top-level and issues commands which have a directory component.
If you look at plotimages.m you can see that the first argument to the function is the directory where it should operate. I've got a changeset 3/4 complete that deals with this and the figure (1, 'visible', 'off') issue. Probably later today I'll be able to check it in.
|
Sat 11 Jul 2015 02:56:39 PM UTC, comment #26:
The problem with:
warning: delete: no such file: extended-inc.pdf
warning: called from
delete at line 47 column 9
plotimages at line 109 column 7
warning: delete: no such file: extended.tex
is due to scope. nm is an argument to plotimages(d, nm, typ)
and system (["pdflatex " nm]); results in:
This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) (preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
(./doc/interpreter/extended.tex
and its outputs go into ./doc/interpreter/
but:
delete ([nm ".aux"], [nm "-inc.pdf"], [nm ".log"], [nm ".tex"]);
tries to delete the files in the octave home dir:
system (["pdflatex " nm]);
system ("ls -l extend*");
system("pwd");
the last 2 systen calls show:
-rw-rw-r--. 1 godfrey godfrey 8 Jul 11 15:25 extended.aux
-rw-rw-r--. 1 godfrey godfrey 13059 Jul 10 20:58 extended.eps
-rw-rw-r--. 1 godfrey godfrey 8900 Jul 11 15:25 extended.log
-rw-rw-r--. 1 godfrey godfrey 78936 Jul 11 15:25 extended.pdf
-rw-rw-r--. 1 godfrey godfrey 18329 Jul 10 20:58 extended.png
/home/godfrey/d/src/octave/hg/octave
and
delete ([nm ".aux"], [nm "-inc.pdf"], [nm ".log"], [nm ".tex"]);
tries to delete from /home/godfrey/d/src/octave/hg/octave
even though pdflatex knew to use: ./doc/interpreter/
I think that there is some make rule hat causes this????
|
Sat 11 Jul 2015 12:20:40 PM UTC, comment #25:
Rik and Mike,
plotimages.m is getting a lot better, I think, but there are
a few items left from my initial version:
First, starting at line 93 there is clumsy code which I
cleaned up in my last version: there are 2
if (strcmp (typ, "pdf"))
....
else
...
endif
sequences.
Obviously there should just be one. Specifically:
I am putting this here since you are currently working on the code and a diff
would likely be based on code that is no longer current. You may have fixed this
already anyhow.
also, would it work to replace the system(["pdflatex " nm]);
by: [status, output] = system(["pdflatex " nm]); ?
This would get rid of the direct output and "output" could be scanned
for errors if needed.
You surely know that there is something wrong indicated by the warning messages:
Output written on extended.pdf (1 page, 78935 bytes).
Transcript written on extended.log.
warning: delete: no such file: extended-inc.pdf
warning: called from
delete at line 47 column 9
plotimages at line 106 column 7
warning: delete: no such file: extended.tex
================
Right now I do not understand this. It does appear that there is
something wrong with the make logic that should check when plotimages needs to
be run and with what arguments.
If I have any time, I will try to learn more about this.
Finally, I hope that you do not feel that I have caused unnecessary trouble
by making a start on this. With all your added work this not only enhances
the Manual build, but will make use of the -dpdflatexstandalone mode a lot
clearer.
Once this settles down I could write a description for the Manual that
explains how to edit additional LaTeX into the generated .tex file. What
probably makes sense is to use \input (filename) but allowing the text
to appear anywhere on the plot will need more thought. Something like
text(x,y, "\input xxx"); may be a start.
|
Fri 10 Jul 2015 09:51:25 PM UTC, comment #24:
The inline method of
is preferred and should eliminate the flicker. I almost made that change yesterday when I was cleaning up the files, but decided not to change anything since it didn't seem to be causing problems.
Now it is a problem so go ahead and change all of the m-files to use that syntax.
|
Fri 10 Jul 2015 09:45:21 PM UTC, comment #23:
I'll try this later, but is there a reason we can't use
instead of
? That may be what's causing the flickering I'm seeing (and jwe confirms on irc he can see figure windows appear briefly when under load).
The other *images.m scripts in doc/interpreter are still using gnuplot BTW, is the intention to build all images with the qt toolkit?
|
Fri 10 Jul 2015 07:27:21 PM UTC, comment #22:
Rik,
I am using gnome. I will figure it out. Use your time
to get the patches straight.
Oh, I tried your quick patch for the make check problem.
It caused the tests to be run, but each line
had the full path to the script, so it did not look too
nice. Anyhow, the patch did not apply cleanly so it will
probably work when you apply it. Again, low priority.
|
Fri 10 Jul 2015 07:21:38 PM UTC, comment #21:
Octave is using xdg-open internally to open the file. I think xdg-open gets the filetype and desired program through a mimetype database. Are you using KDE or GNOME? I only know how to do it in KDE.
|
Fri 10 Jul 2015 07:03:28 PM UTC, comment #20:
Rik,
open sort of works for me, but uses evince.
How do I tell it about okular?
Anyhow, good to switch to "open" I think.
|
Fri 10 Jul 2015 06:47:08 PM UTC, comment #19:
Rik,
Here are:
1. the cset (qt_manual.plot.diff) against the current default
There are a few lines at the end which I do not understand.
I did not intend to change anything there and they do not
seem to do anything.
2. the two edited files: plot.txi and plotimages.m
This correctly generated the Manual. In particular Figure 15.7
seems as intended and shows LaTeX capability.
I quickly tried open("extended.pdf") in my system but
it did not seem to work. I am probably missing some
configuration?? I will check later. Your idea is definitely the
right thing to do.
Anything else I can do?
(file #34415, file #34416, file #34417)
|
Fri 10 Jul 2015 06:44:02 PM UTC, comment #18:
@Michael: OpenGL is the preferred plot engine going forward, and of the two, 'qt' is probably going to be preferred since the widgets match the GUI. Right now I use FLTK too as my default in my .octaverc but I'm going to switch over to qt pretty soon.
|
Fri 10 Jul 2015 06:18:06 PM UTC, comment #17:
@Michael: Yes, make the diff with respect to the latest tip from Mercurial.
Also, look at the open() command from within Octave. This opens whatever file you specify by trying to use the appropriate system resource. In my case
results in okular showing the plot.
If you do this then we don't have to hardcode a system command into the documentation.
|
Fri 10 Jul 2015 05:11:01 PM UTC, comment #16:
Rik,
Should I make the diff with respect to your current cset?
|
Fri 10 Jul 2015 05:09:08 PM UTC, comment #15:
Mike,
The version that Rik built from an earlier version
of my code has some problems. I think
you would also see the problem with build if you
started from a clean build. In any case I attached
newer versions (merging Rik's additions with
my latest) of both plot.txi and plotimages.m
below.
And, I agree that there should be a better choice
than acroread. I only put in acroread since I did
not know what most people would prefer. What is the
most widely used free viewer? For my testing I used
okular.
And, the pdflatex output should probably go somewhere
else. Again, I left it in while debugging and because
I do not know what other choice most people would prefer.
It would be nice to see the output if pdflatex fails,
for instance if the user provides bad syntax in the input.
This is particularly important since pdflatex will
typically prompt the user when it fails.
Look for files #34411 and #34412 below if you want to
try my current version.
I do not see any transient flickering.
|
Fri 10 Jul 2015 03:12:24 PM UTC, comment #14:
I see some odd behavior from this change as well, the extended.pdf file keeps getting rebuilt every successive make even though it is already there, the X display flashes (I assume this is due to invisible figures mapping and unmapping very quickly), and the pdflatex command is much too verbose. But I don't have the error Michael is seeing. This is with the version committed to the default branch.
Can we also change the example to use a better (free software) PDF viewer instead of acroread? Or use "xdg-open" as the command to open the file?
|
Fri 10 Jul 2015 03:04:26 PM UTC, comment #13:
@Michael: If you can produce a diff with 'hg diff' that will be easier. Much work to today, but I can review things on the weekend.
|
Fri 10 Jul 2015 12:20:45 PM UTC, comment #12:
Rik,
I am attaching my current copies of plotimages.m and
plot.txi. I had made a few minor changes to plot.txi
also to make it match the plotimages.m result.
Do you prefer a diff?
Sorry that things got out of step.
(file #34411, file #34412)
|
Fri 10 Jul 2015 12:05:04 PM UTC, comment #11:
Rik,
For me your patch to plotimages.m failed:
So, I will fix plotimages.m and post a copy soon.
|
Fri 10 Jul 2015 11:09:31 AM UTC, comment #10:
Rik,
You might consider switching to use code from my most
recent plotimages.m
It does a couple of things better:
1. Falls back to gnuplot if no fltk (change to qt) is
available. This may be helpful for people who do
not have OpenGL. Now plotimages will just crash if
there is no qt.
2. I cleaned up the code so that there is just one
if (strcmp (typ, "pdf")) in the extended... section,
put back the gnuplot code in case it was selected.
This made the possible use of gnuplot simpler.
Latest is: (file #34398)
|
Fri 10 Jul 2015 10:44:38 AM UTC, comment #9:
Seems good to me. Is it agreed that qt is the way
forward? Will there be any need for fltk?
I have been using fltk as my default but will switch to qt
and see what happens.
|
Fri 10 Jul 2015 04:18:03 AM UTC, comment #8:
I was working from an older version of Michael's cset. I adapted it to build and to clean up the auxiliary files created by pdflatex. I also changed the default toolkit to 'qt' in plotimages.m since that is what we would like to use going forward. I checked that change in here (http://hg.savannah.gnu.org/hgweb/octave/rev/b9d4ccf4291c).
Can we add a dependency on OSmesa in this section of doc/module.mk?
Should just be able to copy and paste and change HAVE_COLAMD to HAVE_OSMESA.
|
Wed 08 Jul 2015 11:19:51 PM UTC, comment #7:
Attached is the changeset for the conversion
of the Manual plots to fltk including
updates to the Manual.
(file #34398)
|
Wed 08 Jul 2015 10:03:05 PM UTC, comment #6:
Updates to the plotimages.m file which addresses comments below:
1. If fltk is not available gnuplot is chosen. This at
least permits building the Manual on a system without
OpenGL. But, the text in the manual will still describe
fltk, etc.
2. Code and text cleanup.
While doing this I noticed that title() does not work
with polar plots. Separate bug report for this.
(xlabel, ylabel do not work either, but that seems OK.)
(file #34397)
|
Wed 08 Jul 2015 04:45:57 PM UTC, comment #5:
Since it is pretty simple, I have modified the
plotimages.m code so that it will work correctly
for either gnuplot or fltk.
It tests for fltk then gnuplot and fails if
neither are present.
Is this OK?
|
Wed 08 Jul 2015 01:09:23 PM UTC, comment #4:
Mike:
It may be safer to check specifically for pdflatex, but
I am not aware of any TeX distributution that provides
pdftex but not pdflatex, or, in any case, any TeX
distribution at all that lacks pdflatex.
It is true that this will not work if fltk, due to lack
of OSMesa, is not present. But, this means that the only
graphics_toolkit would be gnuplot. So, if necessary both
could be implemented, i.e. leave the gnuplot version of
figure 15-7 in used conditionally on gnuplot. This may
be reasonable, and quite simple. As you will see, only
the one figure was modified for fltk. All the others work
for both without change.
|
Wed 08 Jul 2015 12:50:47 PM UTC, comment #3:
Yeah, I think the main intent of Michael's patch was to remove the dependence on gnuplot completely. And the main blocker to building the doc image with fltk is the one plot in the manual that uses TeX markup.
I haven't reviewed the entire patch yet, but it seems to me that calling out to pdflatex should use a new make variable just in case there is no pdflatex on the system or it's in a custom location, the usual reasons. And building the documentation would need to depend on both OSMesa and pdflatex being present and functional. We use pdftex elsewhere in the build but not pdflatex, so that's a new build-dependency.
|
Wed 08 Jul 2015 08:51:39 AM UTC, comment #2:
Could you read the description of -dpdflatexstandalone in the Manual?
This describes how to use LaTeX with fltk. This is what
I used for figure 15.7 which is the only figure in the
Manual that was using interpreter tex mode. The result
is actually better.
You can see how it works by lookinf at the patch or trying
it.
The patch would, as you say, improve the documentation,
but the main intent is to remove the dependence on gnuplot.
|
Wed 08 Jul 2015 06:34:42 AM UTC, comment #1:
Hi,
The problem with using fltk to generate the documentation figures is that super/subscript, special characters and multi-line texts won't be rendered properly. Do you think your cset can be useful without switching to fltk, for the purpose of of documenting fltk/qt features ? If so I will review it in the coming days.
|
Tue 07 Jul 2015 10:30:55 PM UTC, original submission:
The Manual does not explain the differences between toolkits
and it depends on gnuplot to produce the example plots. Therefore,
the behavior of fltk and qt plotting cannot be shown.
This changset converts the plots to use fltk and it makes a
start at explaining the current plotting capabilities.
The changeset which is attached is for the current devel branch.
A changeset for the stable branch is available.
|