I've done some fairly minor graph modifications using the option to add gnuplot commands, with varying degrees of success. I'm definitely a "gnubie" at this, but one of my biggest frustrations is the lack of informativeness of gnuplot's error messages. That said, I like the idea of setting this up as a foreign language interface. Could there be scope for translating gnuplot return codes into English? Of course, if there's already a Rosetta Stone for this, please just give me a pointer.
PS Sent from my iPad > On Sep 28, 2014, at 8:28 AM, Riccardo (Jack) Lucchetti > <r.lucchetti(a)univpm.it> wrote: > > > 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-devel mailing list > Gretl-devel(a)lists.wfu.edu > http://lists.wfu.edu/mailman/listinfo/gretl-devel
