Menu
▾
▴
gnuplot-beta
|
From: Allin C. <cot...@wf...> - 2014-11-15 01:00:40
|
Any ideas what's wrong here? After doing, in a directory containing
the gnuplot CVS sources,
make clean
cvs update -d -P
./prepare
./configure --prefix=opt/gnuplot
make
I'm getting:
make[2]: Entering directory `/home/allin/cfiles/gpcvs/gnuplot/docs'
Building allterm.h
[...]
In file included from doc2x.h:70:0,
from doc2tex.c:63:
allterm.h:2265:33: fatal error: lua/gnuplot-tikz.help: No such file
or directory
Earlier, ./configure gave:
** Configuration summary for gnuplot 5.1:
[...]
cairo-based pdf and png terminals: yes
lua/TikZ terminal: no
wxt terminal: yes
[...]
No lua/TikZ terminal is fine by me.
--
Allin Cottrell
Department of Economics
Wake Forest University
|
|
From: Daniel J S. <dan...@ie...> - 2014-11-15 01:46:44
|
On 11/14/2014 07:00 PM, Allin Cottrell wrote: > Any ideas what's wrong here? After doing, in a directory containing > the gnuplot CVS sources, > > make clean > cvs update -d -P > ./prepare > ./configure --prefix=opt/gnuplot > make > > I'm getting: > > make[2]: Entering directory `/home/allin/cfiles/gpcvs/gnuplot/docs' > Building allterm.h > [...] > In file included from doc2x.h:70:0, > from doc2tex.c:63: > allterm.h:2265:33: fatal error: lua/gnuplot-tikz.help: No such file > or directory > > Earlier, ./configure gave: > > ** Configuration summary for gnuplot 5.1: > > [...] > cairo-based pdf and png terminals: yes > lua/TikZ terminal: no > wxt terminal: yes > [...] > > No lua/TikZ terminal is fine by me. That help text looks to be generated (from term/lua/README): " lua gnuplot-tikz.lua termhelp > gnuplot-tikz.help generates the version to be included in gnuplot help system. " My guess is that somehow the configure script is placing the string #include "lua/gnuplot-tikz.help" inside docs/allterm.h when it shouldn't--or the file gnuplot-tikz.help is not being generated when it should be (but since you don't have lua, there is no way of running "lua gnuplot-tikz.lua termhelp > gnuplot-tikz.help". Here is the script that generates the allterm.h file: allterm.h: $(CORETERM) @echo "Building allterm.h" @for e in `egrep "^[ ]*START_HELP" $(CORETERM) |\ LC_ALL=C sort -f -t':' -k2` ; do \ f=`echo $$e |cut -d\: -f1` ; s=`echo $$e | cut -d\: -f2` ;\ sed -n "/^[ ]*$$s/,/^[ ]*END_HELP/p" $$f ; \ done >$@ it looks to be searching files for a particular string. This is related to what Hans pointed out the other day, when I pointed out that after I build I get a diff hunk because the lua tikz help is regenerated and is different from what was in the repository. Since gnuplot-tikz.help is generated, it technically shouldn't be in the repository. But that leads to the problem you are seeing if the file is not present unless generated. We need some way in the script above to leave out lua/gnuplot-tikz.help from the documentation. Either we could not add "lua.trm" to CORETERM contingent on the presence of "lua" on the system, or place a copy of someone's "lua" help in the repository and not generate it as part of the build process. Dan |
|
From: sfeam <sf...@us...> - 2014-11-15 03:24:10
|
On Friday, 14 November 2014 08:00:26 PM Allin Cottrell wrote: > Any ideas what's wrong here? After doing, in a directory containing > the gnuplot CVS sources, Since term/lua/gnuplot-tikz.help is a constructed file that is created by the build process, it should not be necessary to keep a copy in the repository. Nevertheless there was one there and it was out of date. So I removed it. It is supposed to be recreated if the configure script finds lua. Do you not have lua on your machine? Did ./configure not find it? I am not sure if the best solution is to put a copy of gnuplot-tikz.help back in the repository, or to skip inclusion of the terminal help in the manual if the terminal itself is not built. Right now the manual contains help text for all terminals, not just the ones that have been configured in. Ethan > make clean > cvs update -d -P > ./prepare > ./configure --prefix=opt/gnuplot > make > > I'm getting: > > make[2]: Entering directory `/home/allin/cfiles/gpcvs/gnuplot/docs' > Building allterm.h > [...] > In file included from doc2x.h:70:0, > from doc2tex.c:63: > allterm.h:2265:33: fatal error: lua/gnuplot-tikz.help: No such file > or directory > > Earlier, ./configure gave: > > ** Configuration summary for gnuplot 5.1: > > [...] > cairo-based pdf and png terminals: yes > lua/TikZ terminal: no > wxt terminal: yes > [...] > > No lua/TikZ terminal is fine by me. > > |
|
From: Daniel J S. <dan...@ie...> - 2014-11-15 03:38:28
|
On 11/14/2014 09:20 PM, sfeam wrote: > On Friday, 14 November 2014 08:00:26 PM Allin Cottrell wrote: > >> Any ideas what's wrong here? After doing, in a directory containing > >> the gnuplot CVS sources, > > Since term/lua/gnuplot-tikz.help is a constructed file that is > > created by the build process, it should not be necessary to keep > > a copy in the repository. Nevertheless there was one there and > > it was out of date. So I removed it. > > It is supposed to be recreated if the configure script finds lua. > > Do you not have lua on your machine? Did ./configure not find it? > > I am not sure if the best solution is to put a copy of gnuplot-tikz.help > > back in the repository, or to skip inclusion of the terminal help > > in the manual if the terminal itself is not built. > > Right now the manual contains help text for all terminals, not just > > the ones that have been configured in. I notice CVS has an ignore file. If gnuplot-tikz.help is put back in the repository, then the file name entered in .cvsignore will no diff hunks be created from "cvs diff" if the file is regenerated? Dan |
|
From: Allin C. <cot...@wf...> - 2014-11-15 03:38:55
|
On Fri, 14 Nov 2014, sfeam wrote: > On Friday, 14 November 2014 08:00:26 PM Allin Cottrell wrote: >> Any ideas what's wrong here? After doing, in a directory containing >> the gnuplot CVS sources, > > Since term/lua/gnuplot-tikz.help is a constructed file that is > created by the build process, it should not be necessary to keep > a copy in the repository. Nevertheless there was one there and > it was out of date. So I removed it. > > It is supposed to be recreated if the configure script finds lua. > Do you not have lua on your machine? Did ./configure not find it? I do have a lua binary, /usr/bin/lua, but no lua "dev" files. (This is on Fedora 20.) Apparently the configure script did not look for a lua binary: $ grep lua config.log configure:11433: $PKG_CONFIG --exists --print-errors "lua" Package lua was not found in the pkg-config search path. Perhaps you should add the directory containing `lua.pc' No package 'lua' found configure:11451: $PKG_CONFIG --exists --print-errors "lua" Package lua was not found in the pkg-config search path. Perhaps you should add the directory containing `lua.pc' No package 'lua' found No package 'lua' found configure:11494: $PKG_CONFIG --exists --print-errors "lua5.1" Package lua5.1 was not found in the pkg-config search path. Perhaps you should add the directory containing `lua5.1.pc' No package 'lua5.1' found configure:11512: $PKG_CONFIG --exists --print-errors "lua5.1" Package lua5.1 was not found in the pkg-config search path. Perhaps you should add the directory containing `lua5.1.pc' No package 'lua5.1' found No package 'lua5.1' found configure:11641: WARNING: Could not find support for lua using pkg-config. configure:11650: checking for library containing luaL_openlibs /home/allin/cfiles/gpcvs/gnuplot/conftest.c:130: undefined reference to `luaL_openlibs' | char luaL_openlibs (); | return luaL_openlibs (); configure:11681: gcc -o conftest -g -O2 conftest.c -llua -ldl -lm >&5 /usr/bin/ld: cannot find -llua | char luaL_openlibs (); | return luaL_openlibs (); configure:11681: gcc -o conftest -g -O2 conftest.c -llua5.1 -ldl -lm >&5 /usr/bin/ld: cannot find -llua5.1 | char luaL_openlibs (); | return luaL_openlibs (); configure:16314: result: lua/TikZ terminal: no configure:16523: result: TeX *.sty for lua/tikz terminal: no ac_cv_search_luaL_openlibs=no Allin Cottrell |
|
From: sfeam <sf...@us...> - 2014-11-15 07:16:08
|
On Friday, 14 November 2014 08:00:26 PM Allin Cottrell wrote: > Any ideas what's wrong here? After doing, in a directory containing > the gnuplot CVS sources, > > make clean > cvs update -d -P > ./prepare > ./configure --prefix=opt/gnuplot > make > > I'm getting: > > make[2]: Entering directory `/home/allin/cfiles/gpcvs/gnuplot/docs' > Building allterm.h > [...] > In file included from doc2x.h:70:0, > from doc2tex.c:63: > allterm.h:2265:33: fatal error: lua/gnuplot-tikz.help: No such file > or directory Fixed in CVS (for some value of "fixed"). Now if lua is not present or if you ./configure --without-lua then it will not include the help section for tikz in the docs. This is imperfect, because if you change your mind later and do ./configure --with-lua it won't go back and rebuild the help file. Ethan |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2014-11-15 11:02:45
|
Am 15.11.2014 um 08:12 schrieb sfeam: > Now if lua is not present or if you ./configure --without-lua then it > will not include the help section for tikz in the docs. > This is imperfect, because if you change your mind later and do > ./configure --with-lua it won't go back and rebuild the help file. I've looked at this a bit. I don't think there really is a need to build a dummy version because it is used is only by term.h, and then only #ifdef HAVE_LUA. I think that for this to work correctly, the "build gnuplot-tikz.help" section is in the wrong Makefile. As-is, if the file isn't there, docs/Makefile fails to build it before trying to use it, and therefore fails to build docs/allterm.h. And we cannot safely assume that docs/Makefile will always be run before term/Makefile. So docs/Makefile has to handle the creation of that file itself, and while at it, the file should actually be moved to the docs directory, since its only purpose is to be included in allterm.h: if BUILD_LUA LUA_HELP = gnuplot-tikz.help $(LUA_HELP): $(top_srcdir)/term/lua/gnuplot-tikz.lua lua $< termhelp > $@ else LUA_HELP = endif allterm.h: $(CORETERM) $(LUA_HELP) I'll check this (and the removal of corresponding code in term/Makefile.am.in) in soon, unless there are objections. As an aside, I propose to upgrade the entire auto-tools configuration to current versions (autoconf 2.69, automake 1.14). Some of our automake support scripts are almost a decade out of date... This I will only check in after some discussion. |
|
From: Allin C. <cot...@wf...> - 2014-11-15 17:31:12
|
On Fri, 14 Nov 2014, sfeam wrote: > On Friday, 14 November 2014 08:00:26 PM Allin Cottrell wrote: >> Any ideas what's wrong here? After doing, in a directory containing >> the gnuplot CVS sources, >> >> make clean >> cvs update -d -P >> ./prepare >> ./configure --prefix=opt/gnuplot >> make >> >> I'm getting: >> >> make[2]: Entering directory `/home/allin/cfiles/gpcvs/gnuplot/docs' >> Building allterm.h >> [...] >> In file included from doc2x.h:70:0, >> from doc2tex.c:63: >> allterm.h:2265:33: fatal error: lua/gnuplot-tikz.help: No such file >> or directory > > Fixed in CVS (for some value of "fixed"). > Now if lua is not present or if you ./configure --without-lua > then it will not include the help section for tikz in the docs. > This is imperfect, because if you change your mind later and > do ./configure --with-lua it won't go back and rebuild the > help file. Thanks. The build now goes fine here after configuring --without-lua. Allin Cottrell |
|
From: Daniel J S. <dan...@ie...> - 2014-11-16 17:20:45
|
On 11/15/2014 05:02 AM, Hans-Bernhard Bröker wrote: > As an aside, I propose to upgrade the entire auto-tools configuration to > current versions (autoconf 2.69, automake 1.14). Some of our automake > support scripts are almost a decade out of date... This I will only > check in after some discussion. If it is a minor change. My system is about three years old with a few minor upgrades and has autoconf 2.66, automake 1.11.1. The only reluctance would be if any tools require the builder (common user, not bundle maintainer) to upgrade. Building gnuplot is pretty easy and any minor additional work might be a barrier for some. Philipp asked about moving forward with gnuplot. What I could imagine is maybe next summer attempting an overhaul of the code with a recent autoconf/vcs(git or hg)/compiler(C++) and better internal organization. What currently exists, 5.0 series, could be a stable platform until the upgrade becomes stable, which might even be a couple years away from starting the effort. For those who haven't used git or hg, I'm certain they'll be happy to be done with CVS and maintaining the Changelog file. Changelogs will be part of the "changeset", written by whomever creates the changeset (just follow the defined format). It's much easier to browse through changes in git and hg, create changeset, etc. It depends on how much new features we expect to add. I can think of a few: * True hidden surface code. (I've had in mind for a while to generalize the hidden line segment code to hidden triangle surfaces.) * WXT terminal as outboard driver. * Arrays of plots (data retention) rather than "multiplot". * An interactive terminal? That's been attempted (but not gotten very far) going back twenty years. I've never been real motivated on this one because it doesn't fit my method of working with data. I prefer to do plotting as commands, not sculpture. * New plot types, as always. * Better integration with other programs using emerging trends (say SQL or something). Is that enough to justify an overhaul? Don't know. Dan |
|
From: Philipp K. J. <ja...@ie...> - 2014-11-16 17:54:16
|
[snip] > > Philipp asked about moving forward with gnuplot. What I could > imagine is maybe next summer attempting an overhaul of the code with > a recent autoconf/vcs(git or hg)/compiler(C++) and better internal > organization. What currently exists, 5.0 series, could be a stable > platform until the upgrade becomes stable, which might even be a > couple years away from starting the effort. For those who haven't > used git or hg, I'm certain they'll be happy to be done with CVS and > maintaining the Changelog file. Changelogs will be part of the > "changeset", written by whomever creates the changeset (just follow > the defined format). It's much easier to browse through changes in > git and hg, create changeset, etc. > > It depends on how much new features we expect to add. I can think of > a few: > > * True hidden surface code. (I've had in mind for a while to > generalize the hidden line segment code to hidden triangle surfaces.) > * WXT terminal as outboard driver. > * Arrays of plots (data retention) rather than "multiplot". > * An interactive terminal? That's been attempted (but not gotten > very far) going back twenty years. I've never been real motivated on > this one because it doesn't fit my method of working with data. I > prefer to do plotting as commands, not sculpture. > * New plot types, as always. > * Better integration with other programs using emerging trends (say > SQL or something). One thing to add: clean-up/documentation of some of the internal core data structures? For instance, I'd like to make some minor bug fixes to the kdens smoothing method, but could not figure out what the various elements of "struct curvepoints" do and how they interact (and the preprocessor macros to access them). > > Is that enough to justify an overhaul? Don't know. Agreed. |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2014-11-16 22:00:45
|
Am 16.11.2014 um 18:20 schrieb Daniel J Sebald: > On 11/15/2014 05:02 AM, Hans-Bernhard Bröker wrote: > >> As an aside, I propose to upgrade the entire auto-tools configuration to >> current versions (autoconf 2.69, automake 1.14). Some of our automake >> support scripts are almost a decade out of date... This I will only >> check in after some discussion. > > If it is a minor change. My system is about three years old with a few > minor upgrades and has autoconf 2.66, automake 1.11.1. The only > reluctance would be if any tools require the builder (common user, not > bundle maintainer) to upgrade. It would require people using the CVS source to have the autotools versions mentioned above, or newer. Those are both at least a year old now, so it's not like I would be requiring bleeding-edge versions ;-) > Changelogs will be part of the "changeset", written by whomever > creates the changeset (just follow the defined format). Absolutely not. ChangeLog has to be maintained anyway. > It's much > easier to browse through changes in git and hg, create changeset, etc. For those working off work-in-progress sources, sure. But what about people using an actual release version? > * True hidden surface code. (I've had in mind for a while to generalize > the hidden line segment code to hidden triangle surfaces.) That wouldn't be a generalization. It'd be a complete re-implementation that has essentially no relation to the existing code. > * Better integration with other programs using emerging trends (say SQL > or something). Wow, ROTFL. That must be the first time in well over 20 years that anyone has called SQL, of all things, an "emerging trend". ;-) |
|
From: Daniel J S. <dan...@ie...> - 2014-11-17 03:50:43
|
On 11/16/2014 04:00 PM, Hans-Bernhard Bröker wrote: > Am 16.11.2014 um 18:20 schrieb Daniel J Sebald: >> On 11/15/2014 05:02 AM, Hans-Bernhard Bröker wrote: >> >>> As an aside, I propose to upgrade the entire auto-tools configuration to >>> current versions (autoconf 2.69, automake 1.14). Some of our automake >>> support scripts are almost a decade out of date... This I will only >>> check in after some discussion. >> >> If it is a minor change. My system is about three years old with a few >> minor upgrades and has autoconf 2.66, automake 1.11.1. The only >> reluctance would be if any tools require the builder (common user, not >> bundle maintainer) to upgrade. > > It would require people using the CVS source to have the autotools > versions mentioned above, or newer. Those are both at least a year old > now, so it's not like I would be requiring bleeding-edge versions ;-) > >> Changelogs will be part of the "changeset", written by whomever >> creates the changeset (just follow the defined format). > > Absolutely not. ChangeLog has to be maintained anyway. One could probably generate the ChangeLog by using some kind of git or hg command to list the comments of the repository. Place it in the "prepare" script or something. For example, here's a hypothetical printout of the comments for changesets of a project: +++++ [sebald@ someproject]$ hg log changeset: 5:5faee0bf6335 tag: tip user: Dan Sebald <dan@sebald> date: Fri Nov 14 13:55:34 2014 -0400 files: file1.cpp description: First line is a summary of what was changed (bug #2949) * file1.cc: Change the average code to great code. changeset: 19207:0b12e3693ed4 user: Buster Keaton <buster@keaton> date: Sun Nov 16 20:24:42 2014 -0400 files: file2.cpp file2.h description: Add some hot new feature (patch #1298) * file2.cpp: This is C++ code. * file2.h: Header file for file2.cpp containing class declarations. +++++ That could be done as part of the autoconf stage because with git and hg the whole repository exists in the programmer's project. (That's different from CVS in which the comm link to the remote repository has to be active in order to do "cvs diff", for example.) Also, one stipulation is that the current CVS gnuplot repository would have be translated and somehow write a script or program that would put the existing ChangeLog into the comment of each changeset, i.e., we'd still have the whole history. >> It's much >> easier to browse through changes in git and hg, create changeset, etc. > > For those working off work-in-progress sources, sure. But what about > people using an actual release version? Here's the repository for Octave: http://hg.savannah.gnu.org/hgweb/octave/ The web interface is automatically generated by Mercurial (it's launched using the "hg serve" command), and I'm guessing Git has something similar. It's where I go to when I want to check activity. There is a graph page for following what might be happening on the release branch, etc. I've seen better graph displays, but it's OK. For releases there's no repository, just the generated ChangeLog, I suppose. >> * True hidden surface code. (I've had in mind for a while to generalize >> the hidden line segment code to hidden triangle surfaces.) > > That wouldn't be a generalization. It'd be a complete re-implementation > that has essentially no relation to the existing code. The hidden line segment code isn't too bad. That's the starting point. Instead of line segments, which are cut at intersections and pieces discarded, it becomes little triangular surfaces which are cut into smaller sections with some linear algebra, then discard various pieces. I think we actually have that part of the problem from someone already--but that's not the hard part. If you were thinking about the "painters" algorithm that is currently used to simulate hidden surfaces, no that's not the starting point. >> * Better integration with other programs using emerging trends (say SQL >> or something). > > Wow, ROTFL. That must be the first time in well over 20 years that > anyone has called SQL, of all things, an "emerging trend". ;-) Well, for me. Can't be too careful. :-) Dan |
|
From: Karl R. <ra...@un...> - 2014-11-16 20:02:41
|
On 16.11.2014 18:20, Daniel J Sebald wrote: > * An interactive terminal? That's been attempted (but not gotten very > far) going back twenty years. I've never been real motivated on this > one because it doesn't fit my method of working with data. I prefer to > do plotting as commands, not sculpture. The idea has some attraction, although I positively hate "sculpting" data into plots with programs like Origin or Excel. I´m not sure what exactly you mean by "interactive terminal", so i´ll go speculate a bit. Suppose i have an initial plot in the interactive terminal. Now i´d love to be able to * click a button labeled "add title", and get a dialog window that says "set title" followed by an input line where i can enter whatever would come after the keyword on the console. There is an "OK" button which silently executes the command, possibly a second button that automatically says "replot" afterwards. * said dialog window has a few additional buttons which fill in or remove further "title" options to/from the input line, and i can re-open it any time. * whenever i right-click into the plot, i get a menu that says "set label", "set arrow", plus whatever fits at the location. * e.g. when the cursor is on the legend, i can change the "set key" options, or on an individual key, i get to change the plot colour, linewidth, key text, ... * clicking on the axis labels lets me change the text, etc. * possibility to drag the legend to another position where it doesn´t collide with my data. * upon editing labels, there is a dropdown list of available fonts, and possibly one that inserts symbols as utf-8 characters. * a "set grid" button (oh wait, wxt already has that ;-) ) .... This would help immensely in optically tuning plots, while still all the versatility of old-school gp-scripting is retained. Such an interactive terminal could then (later) also allow adding further plots , changing the "using" statement, plot style, etc., to the point where it becomes an "Origin" clone, only one that is easily script- and programmable. Inline @heredata could be imported, sorted, edited in additional spreadsheet windows, without ever breaking backward compatibility. Looking a few years into the future, Karl P.S. It should optionally be possible to strip the saved script from all settings that were not changed from the default/not used in the present plot, so it can easily be edited and re-used. (That´d be a cool feature also without an interactive terminal.) |
|
From: sfeam <sf...@us...> - 2014-11-16 20:20:09
|
On Sunday, 16 November 2014 09:02:31 PM Karl Ratzsch wrote: > P.S. It should optionally be possible to strip the saved script from > all settings that were not changed from the default/not used in the > present plot, so it can easily be edited and re-used. (That´d be a > cool feature also without an interactive terminal.) That is what the gpsavediff tool is for. It is a contributed script that you can get from the SourceForge site: wget http://gnuplot.sourceforge.net/scripts/files/gpsavediff You can either run it after the fact to clean up a save file, or have the save command pipe through it: save "|gpsavediff > saved_session.gp" I would love to have it integrated into gnuplot as a built-in command, but I haven't come up with a clean way to do that. Ethan |
|
From: Philipp K. J. <ja...@ie...> - 2014-11-16 23:02:25
|
> > * click a button labeled "add title", and get a dialog window that > says "set title" followed by an input line where i can enter > whatever would come after the keyword on the console. There is an > "OK" button which silently executes the command, possibly a second > button that automatically says "replot" afterwards. > > * said dialog window has a few additional buttons which fill in or > remove further "title" options to/from the input line, and i can > re-open it any time. > > * whenever i right-click into the plot, i get a menu that says "set > label", "set arrow", plus whatever fits at the location. YES! And further: click an existing label or arrow, and be able to edit or move it. > > * e.g. when the cursor is on the legend, i can change the "set key" > options, or on an individual key, i get to change the plot colour, > linewidth, key text, ... YES! > > * clicking on the axis labels lets me change the text, etc. > > * possibility to drag the legend to another position where it > doesn´t collide with my data. > > * upon editing labels, there is a dropdown list of available fonts, > and possibly one that inserts symbols as utf-8 characters. YES! > > * a "set grid" button (oh wait, wxt already has that ;-) ) > It does, but something that would guide the casual user through tics and tic labels would be welcome! > .... > > This would help immensely in optically tuning plots, while still all > the versatility of old-school gp-scripting is retained. > > Such an interactive terminal could then (later) also allow adding > further plots , changing the "using" statement, plot style, etc., to > the point where it becomes an "Origin" clone, only one that is > easily script- and programmable. Inline @heredata could be imported, > sorted, edited in additional spreadsheet windows, without ever > breaking backward compatibility. > > Looking a few years into the future, > > Karl > > > P.S. It should optionally be possible to strip the saved script from > all settings that were not changed from the default/not used in the > present plot, so it can easily be edited and re-used. (That´d be a > cool feature also without an interactive terminal.) |
