Gretl has used gnuplot for all its graphical output since the dawn of time. Some people find gnuplot's output ugly, but that's highly subjective IMO; as far as I'm concerned, I simply love it; I certainly wouln't trade the austere beauty of a line graph like gretl produces with a cheap alternative sporting grossly fatter lines in a tacky light blue frame. We also go to great lengths to make gnuplot's output customisable from our GUI client, and it's a great credit to Allin's committment and ingenuity that most GUI users don't even realise that their graphs are in fact produced by a piece of software other than gretl. Our relationship with gnuplot, when it comes to scripting, is a bit more awkward. We have one command (the 'gnuplot' command) for doing most things, and its syntax has been expanding over time in order to accommodate more and more flexibility. In fact, now that we have the --input option, a hansl script writer has at her disposal the potential for producing masterpieces such as those found at http://gnuplot.sourceforge.net/demo_4.6/ if necessary. However, this implies writing functions in which, basically, we issue strings into a file that is then re-used as input by gnuplot. The funny thing is, we already have a "foreign" environment that does basically the same job for statistical packages. It could perhaps be advisable to extend the "foreign" command to drive gnuplot in a more transparent way than we do now, and at the same time take advantage of a change scheduled for gnuplot 5.0 (which should be in a cinema near you real soon): "Command scripts may place in-line data in a named data block for repeated plotting." This would make it possible to pass data to gnuplot in a clean and efficient way. The big difference with other "foreign" environments would be that it's highly likely that a script writer might want to pass to gnuplot strings as well as data. So, we could imagine a situation in which we pass bundles and have something like <pseudo-hansl> bundle to_gp = null to_gp["foo"] = X to_gp["bar"] = "A string" foreign language=gnuplot --data=to_gp ... end foreign </pseudo-hansl> Being able to do something like this would reduce the need for supporting the rather byzantine syntax we now have for the "gnuplot" command, which could be much simplified with some options deprecated. How do you like the idea? ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------

Gretl has used gnuplot for all its graphical output since the dawn of time. [...] It could perhaps be advisable to extend the "foreign" command to drive gnuplot in a more transparent way than we do now, and at the same time take advantage of a change scheduled for gnuplot 5.0 (which should be in a cinema near you real soon): "Command scripts may place in-line data in a named data block for repeated plotting." This would make it possible to pass data to gnuplot in a clean and efficient way. The big difference with other "foreign" environments would be that it's highly likely that a script writer might want to pass to gnuplot strings as well as data. So, we could imagine a situation in which we pass bundles and have something like <pseudo-hansl> bundle to_gp = null to_gp["foo"] = X to_gp["bar"] = "A string" foreign language=gnuplot --data=to_gp ... end foreign </pseudo-hansl> Being able to do something like this would reduce the need for supporting the rather byzantine syntax we now have for the "gnuplot" command, which could be much simplified with some options deprecated.

On Oct 8, 2014, at 11:02 AM, Riccardo (Jack) Lucchetti <r.lucchetti(a)univpm.it&gt; wrote: > On Thu, 2 Oct 2014, Allin Cottrell wrote: > > Sorry it's taken me a while to reply on this, but here are my thoughts. > I like the idea of using a "block" approach for non-trivial gnuplot commands within gretl, for two main reasons: > > 1) to avoid option-overload and the somewhat fussy syntax we have at present for appending "literal" lines to a plot specification; and > > 2) to streamline the handling of custom plots (i.e. those not supported by gretl's built-in "gnuplot" options) so that package writers or others don't have to mess with low-level file I/O. > > I think that that these two uses probably call for somewhat different handling -- maybe two distinct modes of a "plot", or perhaps "foreign", block. I've given this more thinking time, and I now think that we could combine the two approaches that Allin suggested as follows: we scrap the "gnuplot" command of most options and we leave it as a quick-n-dirty tool for basic data visualisation: simple line graphs, xy plots, and the like. Then, we introduce, for more sophisticated jobs, *two* new constructs: (1) a "plot" environment like the first one Allin envisaged. That is, a block inside which we allow for special syntax which translates internally into gnuplot commands, but basically follows the old "gnuplot" command conventions. In other words, a pidgin language that is neither hansl not gnuplot. Allin's example plot data foo option with-lines literal set title "My title" end plot exemplifies this quite well. What you get between "plot" and "end plot" is simple syntax, with only a few rigid commands. Of course, you wouldn't be able to use the full power of gnuplot, but in return you would have the guarantee that the subset of gnuplot commands we'd use for producing the output is compatible with our GUI editor, so that you could save the result to the icon view and modify it via our gnuplot interaction GUI tool if needed. (2) a "literal" environment, which IMO could well be just another incarnation of "foreign", as in foreign language=gnuplot ... end foreign in which you could issue _any_ gnuplot command you want and unleash our graphic engine to its (enormous) full potential. However, you'd lose the ability to save the result into a gretl graph and, as fare as data passing is concerned, you'd be totally on your own with solutions like temporary files (ok, maybe we could envisage some form of string substitution). Do you guys like this? ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti ------------------------------------------------------- _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

I've given this more thinking time, and I now think that we could combine the two approaches that Allin suggested as follows: we scrap the "gnuplot" command of most options and we leave it as a quick-n-dirty tool for basic data visualisation: simple line graphs, xy plots, and the like. Then, we introduce, for more sophisticated jobs, *two* new constructs:

(1) a "plot" environment like the first one Allin envisaged. That is, a block inside which we allow for special syntax which translates internally into gnuplot commands, but basically follows the old "gnuplot" command conventions. In other words, a pidgin language that is neither hansl not gnuplot. Allin's example

On Thu, 9 Oct 2014, Sven Schreiber wrote:

> What I like about this is that it is in principle backend-independent, > i.e. in the future you could use the same "pidgin" commands to trigger > some other graphics engine in the background, if somebody wrote the > necessary bindings. > OTOH however there is a tradeoff; I think Allin is also right in that he > doesn't want to reinvent the wheel and thus chose to outsource the > plotting stuff to gnuplot. The logical implication then is that to > control plots users need to speak gnuplotish, instead of extending hansl > to that area. > > Of course you could argue that gnuplot's results are just so great, only > the syntax bothers you. But is that really the general opinion? I > somehow doubt that. I like this approach. I fully agree that 4 approaches are too many; however, IMO "textplot" could be scrapped: it's nice to have something that retains the flavour of 80x25 displays, but that's (as far as I'm concerned) just a sentimental thing.

After all, if you really really want to do really really complex things, you'd probably want to export your data and start from scratch with something else. And besides, you can always use the --input switch.

So that would leave the stripped-dow version of the gnuplot command and the new "plot" environment.

And, like you said, this opens up the possibility of using a different backend in the future. Plplot, for example, whose output is very cool and has very nice C bindings. But that's far into the future.

On Fri, 10 Oct 2014, Sven Schreiber wrote: >> After all, if you really really want to do >> really really complex things, you'd probably want to export your data >> and start from scratch with something else. And besides, you can always >> use the --input switch. > > Again, I agree in principle. OTOH I think many people (including me) > like the inline way of controlling everything from a single script file. > So it was good to be able to supply literal gnuplot commands inline > inside curly braces. That's a matter of taste. If I had to produce some very complex output, I'd rather write a function for producing the corresponding gnuplot script, save it into a temporary location, and then invoke gnuplot with the --input option. This can be done from a single script, without having to issue a monster-like, 20-lines literal appenidx to the gnuplot command. >> So that would leave the stripped-dow version of the gnuplot command and >> the new "plot" environment. > > I'm now thinking, why actually stripping down the gnuplot command? This > would mean to scrap stuff which is working nicely, mostly. Of course the > way that the command is described in the docs could be adjusted in order > to encourage other usage. But stripping down the functionality would > seem to have no real benefit. Well, for cleanliness, mostly; code maintainability etc. ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti ------------------------------------------------------- _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

On Fri, 10 Oct 2014, Giuseppe Vittucci wrote: > Instead, I do not like too much the idea of the plot environment cause > it seems half in between the full control given by the foreign block and > the clean and simple control for ready-to-use plots given by the gnuplot > command. Well, I kind of changed my mind on this. We still have a large user base who would like to adjust graphs by using the GUI widget, which I use quite often myself. It's absolutely impossible to have this possibility with graphs generated by arbitrary gnuplot syntax. So, you have to accept a few constraints; but, given this, why not work directly with a sublanguage that is closer to hansl and easier to grasp than gnuplot (and, BTW, could use other backends if needed, like Sven said)?

And besides, like I said in my previous message: if you really want to use gnuplot to its full potential, create a tempfile, have gnuplot read it and produce output. A simple proof-of-concept follows: <hansl> function string cool_gnuplot_pic(scalar angle, scalar resolution) string fname = sprintf(&quot;(a)dotdir/%d.gp&quot;, floor(randgen1(u,1000,9999))) outfile @fname --write printf "set border 4095 front linetype -1 linewidth 1.000\n" printf "set view %d, 10, 1, 1\n", angle printf "set samples %d, %d\n", resolution, resolution printf "set isosamples %d, %d\n", resolution, resolution printf "unset surface\n" printf "set title \"Cool, no?\" \n" printf "set pm3d implicit at s\n" printf "set pm3d scansbackward\n" printf "splot sin(sqrt(x**2+y**2))/sqrt(x**2+y**2)\n" outfile --close return fname end function pic_1 = cool_gnuplot_pic(125, 200) pic_2 = cool_gnuplot_pic(100, 400) gnuplot --input=@pic_1 --output=display gnuplot --input=@pic_2 --output=display </hansl>

Well, yes it's a nice example, but IMHO it really just shows Jack is good at speaking gnuplotish.

I'd like to experience this, but I get an error running Jack's script: sprintf: argument should be string Data types not conformable for operation *** error in function cool_gnuplot_pic, line 1 > string fname = sprintf("C:\Users\psummers\AppData\Roaming\gretl/%d.gp", floor(randgen1(u,1000,9999))) Error executing script: halting > pic_1 = cool_gnuplot_pic(125, 200) I'm guessing I need to use "\%d.gp" since I'm on Windows (7), but that's not all that's going on. This is with Gretl 1.9.92 cvs.

I am writing a function for drawing simple pie charts with gretl trough Gnuplot. It seems everything is ok except that gretl produces this error: "Failed to parse gnuplot file". But if you click over the 'close' button in the error message window, the graph emerges correctly, without problem. (I send the script as attachment). Can I do anything to avoid this error? This is in gretl from current CVS, on Ubuntu Linux 14.04. Executing gretl from the console I obtain these messages: gnuplot: using pngcairo driver bad gnuplot line: 'reset ' (but I think 'reset' is not the problem)