gnuplot-beta — Developers and beta testers of new gnuplot code

Re: set multiplot layout ... downwards|upwards

[Hans-Bernhard B. <br...@ph...>]

Petr Mikulik wrote:

> I'm about to add two new keywords as the subject indicates:
> 
>        set multiplot { layout <cols>,<rows>
>                        {rowmajor|columnmajor} {downwards|upwards}
> 			...
> 
> that specify vertical stacking of plot rows. The current, and default, is
> downwards. I think the names are quite reasonable.

A good idea.

> Further, I propose that if "set multiplot layout" is used, then "unset
> multiplot" resets "size" to 1,1 and "origin" to 0,0. Otherwise, the next
> plot is outside of the drawing canvas, and you have to do "set size ...; set
> origin ..." explicitly. These values are not affected for normal "set
> multiplot" for compatibility reasons. Any objections?

Not an objection, but a suggestion: better make sure you reset size and 
origin to what they actually were before 'set multiplot layout', instead 
of forcing them to their defaults.  I.e. 'unset multiplot' should un-do
what 'set multiplot layout' did, in this case.

Re: Cleanup list of patches and bug reports on sf.net

[Hans-Bernhard B. <br...@ph...>]

Petr Mikulik wrote:
>>>>And isn't the bug report #963176, "wish: only create docs for available
>>>>terminals", solved?
>>>
>>>Not that I know of.
>>
>>I think the discussion was somehow good. In all platform-independent
>>formats, all terminals should be described. In the online form (via typing
>>help in gnuplot), either only installed ones should be described (which is
>>the case, I think) or not installed terminals should be described but
>>marked as not installed. But the bug report #963176 requested to not
>>describe uninstalled terminals at all, if I remember correctly. And then,
>>it is not unsolved.
> 
> 
> Currently, "set term" lists all available terminals, while gnuplot docs
> describes docs for all terminals. 

Only for some select values of what "docs" you may be speaking of.  You 
won't see help for the X11, PM, or aquaterm drivers in the Windows version.

The scheme is supposed to be: docs for all terminals *only* in the 
platform-independent versions of the docs (essentially the printable 
ones, and everything derived from gnuplot.texi).  The online help of
any given version will not contain documentation on terminal drivers not
present in that version.

The only other option I can see would be to have an #ifdef inside the
documentation section of the relevant terminal drivers that switches 
between the actual documentation and " Sorry, this terminal is not 
present in your version of gnuplot" line, then build even
the online versions using allterm.h instead of term.h.  This would 
generate online docs with the complete set of nodes, but some of them
would just contain this "Sorry" notice.

set multiplot layout ... downwards|upwards

[Petr M. <mi...@ph...>]

I'm about to add two new keywords as the subject indicates:

       set multiplot { layout <cols>,<rows>
                       {rowmajor|columnmajor} {downwards|upwards}
			...

that specify vertical stacking of plot rows. The current, and default, is
downwards. I think the names are quite reasonable.

Further, I propose that if "set multiplot layout" is used, then "unset
multiplot" resets "size" to 1,1 and "origin" to 0,0. Otherwise, the next
plot is outside of the drawing canvas, and you have to do "set size ...; set
origin ..." explicitly. These values are not affected for normal "set
multiplot" for compatibility reasons. Any objections?

---
PM

Re: [ gnuplot-Bugs-1046521 ] [Mac] installer failure

[Per P. <per...@ma...>]

On Oct 14, 2004, at 09:42, SourceForge.net wrote:

> Bugs item #1046521, was opened at 2004-10-13 21:31
> Message generated for change (Settings changed) made by broeker
> You can respond by visiting:
> https://sourceforge.net/tracker/? 
> func=detail&atid=102055&aid=1046521&group_id=2055
>
> Category: Other
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Lenore Horner (lhorner)
>> Assigned to: Per Persson (persquare)
> Summary: [Mac] installer failure
>
> Initial Comment:
> On X 10.2.8, the new .pkg installer fails.

[snip]

I've been working off-list with the submitter to track this down.
I'm not convinced that the installer is to blame, but I'll increase the  
authorization level of future installers to avoid problems with faulty  
ownership/permissions.

In the process, we discovered that the binary won't run properly on  
pre-10.3 systems due to stpcpy not being available on those systems.  
That is a problem when building on 10.3+ and deploying on previous  
system versions. This is now handled by the installer creating script I  
have by removing HAVE_STPCPY from config.h.

I've only had a single bug report, so the pre-10.3 to 10.3 ratio seems  
to be  1/3500 judging from the number of downloads...

I could create a new installer, and someone with the appropriate powers  
could then put it on the d/l site.

/Per

Re: crash bug in pdf terminal

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:

> I'm running into some quirks with the pdf terminal that I can't recall 
> in the past.  I returned to some octave code and got some crashes 
> where there were none before.  The PostScript and X11 terminals still 
> work fine with the script in question. 


./configure log shows nothing aberant with pdflib.  Perhaps it is a bug 
in pdflib.  The version of pdflib.h I have is:

/* $Id: pdflib.h,v 1.39.2.11 2002/01/23 15:40:42 rjs Exp $

#define PDFLIB_MAJORVERSION    4    /* PDFlib major version number */
#define PDFLIB_MINORVERSION    0    /* PDFlib minor version number */
#define PDFLIB_REVISION        2    /* PDFlib revision number */
#define PDFLIB_VERSIONSTRING    "4.0.2"    /* The whole bunch */

crash bug in pdf terminal

[Daniel J S. <dan...@ie...>]

I'm running into some quirks with the pdf terminal that I can't recall 
in the past.  I returned to some octave code and got some crashes where 
there were none before.  The PostScript and X11 terminals still work 
fine with the script in question.

Here is one that I discovered in playing around with gnuplot.  Generate 
a plot to the PDF terminal without having defined the output file:

gnuplot> set terminal pdf
Terminal type set to 'pdf'
Options are 'noenhanced fname 'Helvetica'  fsize 6 linewidth 1.0 '
gnuplot> plot x
gnuplot> set output
PDFlib runtime error: Must call PDF_get_buffer() after PDF_close()

Obviously, what I've done above is an incorrect procedure.  However, it 
would be nice if gnuplot not crash after issuing an appropriate error 
message.


I get a different PDFlib error in Octave.  Think I've found the problem 
with a few number of gnuplot commands:

gnuplot> set terminal pdf
Terminal type set to 'pdf'
Options are 'noenhanced fname 'Helvetica'  fsize 6 linewidth 1.0 '
gnuplot> set output 'junk.pdf'
gnuplot> set bmargin 0
gnuplot> plot x
PDFlib value error: floating point value too large in pdf_ftoa

(Setting bmargin to zero makes sense in multiplot mode.)  Now, if I try:

set term pdf
set output 'junk.pdf'
set bmargin 0
set xtics offset 0,graph 0.5
plot x
set output

things work fine.  And using "set xtics offset 0,graph -0.5" in the 
above (which should result in the tic text off the PDF plot area) causes 
the same crash with pdf_ftoa.  So the problem may be placing text 
partially or fully off the screen... or perhaps not the screen, but the 
graph area... not sure.

Ethan, it has been several months since I've used the particular Octave 
script that leads to this problem, so I'm sure there've been many 
changes since that time and likely won't recall anything having changed, 
but any thoughts?  Can I help pin this down?

I just tried:

set term pdf
set output 'junk.pdf'
set xtics offset 0,graph -0.5
plot x
set output

and that fails too, so the "bmargin 0" has nothing to do with the problem.

Dan

Re: possible addition to 'gnuplot links' page

[Petr M. <mi...@ph...>]

> > > I am the author of Engauge Digitizer, which seeks to undo what gnuplot
> > > does. This open source tool is at digitizer.sourceforge.net.
>
> > BTW, are there other projects that do the same thing? I could not find
> > references on digitizer's web page. That would be nice for completeness.
>
> I often use g3data for this task:
>
> http://www.acclab.helsinki.fi/~frantz/software/g3data.php

OK, both are listed.

---
PM

Re: Terminal settings saved where they shouldn't

[Petr M. <mi...@ph...>]

> > bind "p" 'set term post color solid; set output "a.ps"; replot; set out; set term pop'
>
> Huh?
> You mean I am supposed to issue a pop without a previous push?
> [tries it - yes, that works]
> So then what is the "push" used for?

According to docs:

 After gnuplot's startup, the default terminal or that from
 `startup` file is pushed automatically.

=> without "push", you can "pop" the default startup terminal.

> No wonder I never got it to work before now.

That has nothing to do with your command.

> Also, does this use require that "set output" comes before "set term pop"?
> I note that the documentation current states:
>
> 	When both `set terminal` and `set output` are used together,
> 	it is safest to give `set terminal` first

The interactive terminals, for which 'push' is mainly used, have empty 'set
out'.

---
PM

Re: macros with parameters

[Ethan M. <merritt@u.washington.edu>]

On Monday 18 October 2004 06:11 am, Petr Mikulik wrote:
> 
> Would it be possible to execute C-like macros:
> 	@(F(1))

Probably it would be @F(1), where F is an existing
string-valued function.  But yes, that should be possible.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Cleanup list of patches and bug reports on sf.net

[Ethan M. <merritt@u.washington.edu>]

On Monday 25 October 2004 06:50 am, Petr Mikulik wrote:
> > > > This patch fixes bug #1000676 =A0(Rotated multiline text misaligned=
).
>=20
> I would also prefer an option. Maybe "rleft, rright, rcenter" for rotated=
=2Dsth?

Maybe an additional keyword "block" as a modifier to left/right/center

Rotate text but use current baseline for alignment:
	set label ... rotate by 45 left

Rotate text as a block
	set label ... rotate by 45 left block

=2D-=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Request for comments: string variable patchset 2

[Ethan M. <merritt@u.washington.edu>]

On Monday 25 October 2004 11:19 am, Juergen Wieferink wrote:
> >
> > With the new syntax, you would do 
> > 	gawkcall = sprintf( '` gawk -f getname %i %s `', ...)
> > 	show var
> > 		gawkcall = ` gawk -f getname ... `
> > 	name = @"gawkcall"
> >
> 
> Which does essentially the same as
> 
>   gawkcall = sprintf('"` gawk -f getname %i %s `"', ...)
>   name = @gawkcall
> 
> right?  I haven't thought of this before seeing your @"var" syntax.

Yes, it seems so.  I didn't think of it either.
So the @"foo" variant is not needed after all.

It is amazing how complicated this stuff becomes, starting with
something rather simple.

> But I like the syntax of command("foo") much more.  It seems cleaner
> to me because there is no detour through the parser.  There are
> no problems if the input or output contains quotes. And it's easier 
> to understand.

Yes. I thought it was a very nice idea. But I had second thoughts while
I was in the middle of implementing it.  I was reminded of the discussion
a month or so back sparked by someone who wanted a "secure" version
or wrapper for gnuplot. The idea was to allow use by untrusted, possibly
malicious users.  One the one hand I don't think we should cripple gnuplot
just because someone could use it to issue arbitrary shell commands.
But on the other hand I do think we should think twice before adding a
feature that could encourage poor scripting via over-use of shell 
intervention. But I could be convinced by a real-world example where shell
intervention for every point plotted was required.

Anyway, this is really a separate issue and can be pursued later.
The command("foo") syntax by itself  does not address the problem of
storing the result in a string.  For that you need these other tricks.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Terminal settings saved where they shouldn't

[Ethan M. <merritt@u.washington.edu>]

On Monday 25 October 2004 02:56 am, Petr Mikulik wrote:
> 
> > bind "p" 'set term push; set term post color solid; set output "| lpr"; replot; set term pop'
> >
> > does not work.  It produces a corrupt output stream.
> > Adding in another 'set output' does not help.
> 
> I think you want this:
> 
> bind "p" 'set term post color solid; set output "a.ps"; replot; set out; set term pop'

Huh?  
You mean I am supposed to issue a pop without a previous push?
[tries it - yes, that works]
No wonder I never got it to work before now.
So then what is the "push" used for?

Also, does this use require that "set output" comes before "set term pop"?
I note that the documentation current states:

	When both `set terminal` and `set output` are used together, 
	it is safest to give `set terminal` first


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Request for comments: string variable patchset 2

[Juergen W. <wie...@fr...>]

On Monday 25 October 2004 00:38, Ethan Merritt wrote:
> I did figure out how to implement a gnuplot function
>    <string-value> = command(<string-expression>)
> but I have serious reservations about it.
> (1) it leaks memory (probably fixable, but so far I haven't
> figured out how)
> (2) it makes me really uneasy that you could trigger evaluation
> of this function from, say, inside a plot statement:
> 	plot <foo> 1:using (command("something expensive"))
> This could, to say the least, consume system resources.

I didn't thought of that, you're right.  There could be a warning in
the docs to command(), and anybody dumb enough to try it
nevertheless gets what he deserves.  But this probably is indeed not
an ideal solution.

> So instead I offer the following alternative proposal.
> I have updated the patchset on SourceForge to include the
> following variant syntax
> 	@"stringvar"  evaluates to "contents of stringvar"
> That is, it evaluates the stringvar and places the value in
> double-quotes.
>
> For string constants this is a complicated no-op.
> E.g.
> 	a = "string constant blah blah"
> 	b = a
> 	c = @"a"
>
> a, b, and c now contain identically the same string.
> But when back-tics are involved it becomes more interesting.
>
> > I need something like
> >
> >   gawkcall = sprintf("gawk -f getname %i %s", this_index,
> > filename) name = execute(gawkcall)
>
> With the new syntax, you would do this as follows:
> 	gawkcall = sprintf( '` gawk -f getname %i %s `', ...)
> 	show var
> 		gawkcall = ` gawk -f getname ... `
> 	name = @"gawkcall"
>

Which does essentially the same as

  gawkcall = sprintf('"` gawk -f getname %i %s `"', ...)
  name = @gawkcall

right?  I haven't thought of this before seeing your @"var" syntax.

> Note that the sprintf call uses single-quote + back-tic to
> delimit the command string.
>
> name becomes a string variable containing the output from
> executing the shell command in gawkcall.
>
> What do you think?  Is this sufficient, or is there still a need
> for an actual function command("foo")?

It suffices /my/ needs.  Obviously, it was OK before, too, I just
didn't see it.  Thus, should be some examples in the docs.

But I like the syntax of command("foo") much more.  It seems cleaner
to me because there is no detour through the parser.  There are
no problems if the input or output contains quotes. And it's easier 
to
understand.  But once more: It's fine as it is.

Juergen

Re: Request for comments: string variable patchset 2

[Ethan M. <merritt@u.washington.edu>]

On Monday 25 October 2004 06:32 am, Petr Mikulik wrote:
> > (2) it makes me really uneasy that you could trigger evaluation
> > of this function from, say, inside a plot statement:
> > 	plot <foo> 1:using (command("something expensive"))
> > This could, to say the least, consume system resources.
> 
> It could whatever syntax is used, couldn't it?

No.  Because the proposed syntax is only relevant at the
time the input line is first lexically parsed.
	var = @"command"
Only executes once.

An executable function could be triggered as part of the
point-by-point evaluation of a "using" spec.   That is arguably
a legitimate use, but my initial reaction is that this is very ugly.
If you need some external program or shell command to 
process each data point, then it would be better to process
the whole input stream at one go prior to plotting rather than
trigger the external program all over again for each point. 
	plot "foo" using (command)
executes once per line of data in "foo"


> > Note that the sprintf call uses single-quote + back-tic to delimit
> > the command string.
> 
> Well, this needs a lot of thinkinkg to understand this syntax, but looks
> feasible if enough examples are given in the docs. (BTW, there should be
> "help string" and "help quotes" added to gnuplot.doc to easily find them.)

I agree.  I have updated all 3 patchsets on SourceForge to contain
documentation entries in gnuplot.doc
see
	"help string"
	"help substitution"
	"help macro"



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: possible addition to 'gnuplot links' page

[Lutz M. <ma...@uc...>]

On Monday 25 October 2004 03:53, Petr Mikulik wrote:
> > I am the author of Engauge Digitizer, which seeks to undo what gnuplot
> > does. This open source tool is at digitizer.sourceforge.net.

> BTW, are there other projects that do the same thing? I could not find
> references on digitizer's web page. That would be nice for completeness.

I often use g3data for this task:

http://www.acclab.helsinki.fi/~frantz/software/g3data.php

  -- Lutz

Re: Cleanup list of patches and bug reports on sf.net

[Petr M. <mi...@ph...>]

> > > And isn't the bug report #963176, "wish: only create docs for availab=
le
> > > terminals", solved?
> >
> > Not that I know of.
>
> I think the discussion was somehow good. In all platform-independent
> formats, all terminals should be described. In the online form (via typin=
g
> help in gnuplot), either only installed ones should be described (which i=
s
> the case, I think) or not installed terminals should be described but
> marked as not installed. But the bug report #963176 requested to not
> describe uninstalled terminals at all, if I remember correctly. And then,
> it is not unsolved.

Currently, "set term" lists all available terminals, while gnuplot docs
describes docs for all terminals. Then we are sure that gnuplot docs is
always complete. The beginning of "help term" should probably say explicitl=
y
that the terminals listed below may be platform-dependent or not available
on some systems.


> > > This patch fixes bug #1000676 =A0(Rotated multiline text misaligned).
> > > The alignment of rotated multiline text was correct for
> > > horizontal and vertical text but incorrect for other
> > > angles (they were handled as not rotated). This patch
> > > corrects this.
>
> In short: I still think it is a bug since even text rotated by 89 degree
> is aligned vertically. If the alignment axis should rotate with the text
> or if it has to stay at a fixed angle up to a threshold angle is a
> question of taste. I think both possibilities should be there.
> Maybe there should be an additional keyword 'alignmentangle' or similar.

I would also prefer an option. Maybe "rleft, rright, rcenter" for
rotated-sth?

---
PM

Re: Request for comments: string variable patchset 2

[Petr M. <mi...@ph...>]

> > > I though that instead of using
> > > 	a=`runme`
> > > there would be an alternative with macro expansion:
> > > 	a=command('runme')
>
> I did figure out how to implement a gnuplot function
>    <string-value> = command(<string-expression>)
> but I have serious reservations about it.
> (1) it leaks memory (probably fixable, but so far I haven't
> figured out how)
> (2) it makes me really uneasy that you could trigger evaluation
> of this function from, say, inside a plot statement:
> 	plot <foo> 1:using (command("something expensive"))
> This could, to say the least, consume system resources.

It could whatever syntax is used, couldn't it?


> So instead I offer the following alternative proposal.
> I have updated the patchset on SourceForge to include the
> following variant syntax
> 	@"stringvar"  evaluates to "contents of stringvar"
> That is, it evaluates the stringvar and places the value in
> double-quotes.
>
> But when back-tics are involved it becomes more interesting.
>
> > I need something like
> >
> >   gawkcall = sprintf("gawk -f getname %i %s", this_index, filename)
> >   name = execute(gawkcall)
>
> With the new syntax, you would do this as follows:
> 	gawkcall = sprintf( '` gawk -f getname %i %s `', ...)
> 	show var
> 		gawkcall = ` gawk -f getname ... `
> 	name = @"gawkcall"
>
> Note that the sprintf call uses single-quote + back-tic to delimit
> the command string.

Well, this needs a lot of thinkinkg to understand this syntax, but looks
feasible if enough examples are given in the docs. (BTW, there should be
"help string" and "help quotes" added to gnuplot.doc to easily find them.)

---
PM

Re: possible addition to 'gnuplot links' page

[Petr M. <mi...@ph...>]

	Hello,

> I am the author of Engauge Digitizer, which seeks to undo what gnuplot
> does. This open source tool is at digitizer.sourceforge.net.
>
> Perhaps Engauge would be a useful addition to your 'gnuplot links' page.

OK. Please send me the text for the web and where do you wish to put it.

BTW, are there other projects that do the same thing? I could not find
references on digitizer's web page. That would be nice for completeness. (I
was using my own command-line routines for this task, and didn't care about
this kind of software from others.)

---
PM

Re: Changes to stable branch?

[Petr M. <mi...@ph...>]

> As far as mousing is concerned, I had a quick look and hacked up
> aquaterm.trm to support passing events from aquaterm windows some time
> ago.
> I never finished it because I couldn't figure out how aquaterm events
> and keyboard events (at the prompt, not in the plot window) were
> supposed to interact.
>
> I seems to me that the driver will have to duplicate the main event
> loop and take over control while mousing is active.

Currently, there are 3 approaches for mouse communication, see src/README.
E.g., OS/2 uses a thread.

---
PM

Re: any chance of a gui in the future?

[Petr M. <mi...@ph...>]

> Too bad that jerk gave you one star on version
> tracker, just for not having a GUI.
> I don't think that's fair.
>
> I'd still like to ask:
> any chance of a gui in the future?

There are GUIs already in the present:
	http://www.gnuplot.info/links.html

---
PM

Re: Qt Wrapper for gnuplot

[Petr M. <mi...@ph...>]

> I have been working on a KDE interface to Octave, when I found that there
> was no nice KDE wrapper around gnuplot.  So I started one.
>
> I am mostly looking for people who are interested in helping me that are
> familiar with gnuplot.  I only really know how to do pretty simple things
> with it, but I did most of the dirty work already, so anyone with minor
> C++ knowledge, and a good gnuplot background would work.

Look to gnuplot web page. There are some front-ends / wrappers lists. It
would be useful to use an already existing API rather than developing your
own.


BTW, you could not use one of the existings, and add a possibity to draw
into a KDE widget? Or even a "KE Widget" terminal for gnuplot?


> The following C++ code generates the graphic at
> http://www.geiseri.com/kdevelop/gnuplot.png
>
> 	KGNUPlotWidget *wid = new KGNUPlotWidget();

not GNUPlot, see FAQ --> rather KGnuplot


> 	LineStyle line(2);

rather prefixed: kgnuplotLineStyle


> 	wid->setXLabel("Test X Label");
> 	wid->setYLabel("Test Y Label");
> 	wid->setFormats(KGNUPlotWidget::X, "%g");
> 	wid->setFormats(KGNUPlotWidget::Y, "%.2f");

That looks like reimplementation of gnuplot structure into you KDE. What
about just the similar thing as Octave does:
	wid->raw("set mxtics 5");

raw would do printf()+fflush()


---
PM

Re: Terminal settings saved where they shouldn't

[Petr M. <mi...@ph...>]

> > It produces two identical, coloured, eps figures. I would prefer that a
> > terminal starts with its default settings when it is chosen after another
> > terminal type.
>
> I would prefer that the current settings are kept.

The current behaviour was intentionally forced to work before 4.0 release.


> > If I want to restore the old settings I can use
> > 'set term push' and 'set term pop' (BTW: gnuplot does not find these
> > command in the help).

I'll add it to docs.

> Do these actually work?

Sure, I use them often.


> bind "P" 'set term post color solid; set output "| lpr"; replot; set term x11'
>
> Now I have a print key in X11.  But it's really annoying if using that
> print key changes what is next shown on the x11 plot window.

Yes, that was the main reason.


> bind "p" 'set term push; set term post color solid; set output "| lpr"; replot; set term pop'
>
> does not work.  It produces a corrupt output stream.
> Adding in another 'set output' does not help.
>
> Did this ever work?

I think you want this:

bind "p" 'set term post color solid; set output "a.ps"; replot; set out; set
term pop'


Note -- don't use "set term push" for restoring the *default* startup
terminal -- that's done automatically on gnuplot startup.


> I'd say first fix push/pop, including making sure they work recursively.

"set term pop" plays with the command line; everything behind it gets
ignored, e.g.
	set term pop; plot x
=> no plot appears


---
PM

Re: Request for comments: string variable patchset 2

[Ethan M. <merritt@u.washington.edu>]

On Saturday 16 October 2004 03:59 am, Juergen Wieferink wrote:
> Petr Mikulik wrote:
> > I though that instead of using
> > 	a=`runme`
> > there would be an alternative with macro expansion:
> > 	a=command('runme')
>
> Yes, yes, I'd love that.  The variable "a" contains a string
> afterwards, doesn't it?

I did figure out how to implement a gnuplot function
   <string-value> = command(<string-expression>)
but I have serious reservations about it.
(1) it leaks memory (probably fixable, but so far I haven't
figured out how)
(2) it makes me really uneasy that you could trigger evaluation
of this function from, say, inside a plot statement:
	plot <foo> 1:using (command("something expensive"))
This could, to say the least, consume system resources.

So instead I offer the following alternative proposal.
I have updated the patchset on SourceForge to include the
following variant syntax    
	@"stringvar"  evaluates to "contents of stringvar"
That is, it evaluates the stringvar and places the value in
double-quotes.  

For string constants this is a complicated no-op.
E.g.
	a = "string constant blah blah"
	b = a
	c = @"a"

a, b, and c now contain identically the same string.
But when back-tics are involved it becomes more interesting.

> I need something like
>
>   gawkcall = sprintf("gawk -f getname %i %s", this_index, filename)
>   name = execute(gawkcall)

With the new syntax, you would do this as follows:
	gawkcall = sprintf( '` gawk -f getname %i %s `', ...)
	show var
		gawkcall = ` gawk -f getname ... `
	name = @"gawkcall"

Note that the sprintf call uses single-quote + back-tic to delimit
the command string.

name becomes a string variable containing the output from
executing the shell command in gawkcall.

What do you think?  Is this sufficient, or is there still a need for
an actual function command("foo")?

Re: Cleanup list of patches and bug reports on sf.net

[Harald H. <h.h...@tu...>]

On Sat, 23 Oct 2004, Ethan Merritt wrote:

> On Saturday 23 October 2004 01:55 pm, Harald Harders wrote:
> > I have seen some old patches on sf.net that may have to change the stat=
us.
> >
> > For example, the patch #982765, "Patch for AI (Adobe Illustrator) term"=
,
> > has been discussed here. Since the whole AI terminal is outdated and
> > postscript is understood by Adobe Illustrator, this patch could be
> > rejected and closed.
> > Or patch #743667, "Epslatex term merged w/ pslatex/pstex", is superseed=
ed
> > by #1040192, "Merge post, epslatex, pslatex, pstex terminals", and coul=
d
> > also be closed.
>
> It would be nice to hear from people actually using these various
> drivers.  I suppose we can deprecate ai.trm and the older forms of
> the various latex terminals, but we may have to resurrect them if
> there are user communities who rely on some feature of the older
> terminal drivers that we didn't realize we were changing.

When closed, patches are not deleted immediately, right? Then, this should
not be a too big problem.

> > And isn't the bug report #963176, "wish: only create docs for available
> > terminals", solved?
>
> Not that I know of.

I think the discussion was somehow good. In all platform-independent
formats, all terminals should be described. In the online form (via typing
help in gnuplot), either only installed ones should be described (which is
the case, I think) or not installed terminals should be described but
marked as not installed. But the bug report #963176 requested to not
describe uninstalled terminals at all, if I remember correctly. And then,
it is not unsolved.

> > This patch fixes bug #1000676 =A0(Rotated multiline text misaligned).
> > The alignment of rotated multiline text was correct for
> > horizontal and vertical text but incorrect for other
> > angles (they were handled as not rotated). This patch
> > corrects this.
>
> I don't agree that this was a bug.  It depends on what you want to
> do with the text.  For me, the chief use is to squeeze more (or longer)
> labels along an axis than would otherwise fit.  And in this case the
> baseline should remain the axis itself, i.e. not rotated. IMHO it looks
> really odd to have multi-line axis tic labels swing out and away from
> the axis.

That is of course a usage I have not thought of, yet. But it surely is a
bug to have the old alignment when using a rotation angle of more than 45
degree. Then, the lines overlap in most cases. But it should be possible
to rotate the whole text block, too.

> If you think it is useful to have the entire text block rotate as a
> unit, I think we would need some new syntax or justification
> option to specify it.  Can you give an example of when you
> would want this?

I have had some plots with legends that had up to 2 lines each and were
rotated by 60 degree. I wanted them to be centred. And it looked very odd
that they were centred to a vertical(!) line. To me, it were best to
centre to a line rotated by 60 degree from the vertical direction.

In short: I still think it is a bug since even text rotated by 89 degree
is aligned vertically. If the alignment axis should rotate with the text
or if it has to stay at a fixed angle up to a threshold angle is a
question of taste. I think both possibilities should be there.
Maybe there should be an additional keyword 'alignmentangle' or similar.

Greetings
Harald

--=20
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Cleanup list of patches and bug reports on sf.net

[Ethan M. <merritt@u.washington.edu>]

On Saturday 23 October 2004 01:55 pm, Harald Harders wrote:
> I have seen some old patches on sf.net that may have to change the status.
>
> For example, the patch #982765, "Patch for AI (Adobe Illustrator) term",
> has been discussed here. Since the whole AI terminal is outdated and
> postscript is understood by Adobe Illustrator, this patch could be
> rejected and closed.
> Or patch #743667, "Epslatex term merged w/ pslatex/pstex", is superseeded
> by #1040192, "Merge post, epslatex, pslatex, pstex terminals", and could
> also be closed.

It would be nice to hear from people actually using these various
drivers.  I suppose we can deprecate ai.trm and the older forms of
the various latex terminals, but we may have to resurrect them if
there are user communities who rely on some feature of the older
terminal drivers that we didn't realize we were changing.

> And isn't the bug report #963176, "wish: only create docs for available
> terminals", solved?

Not that I know of.  In fact, I don't think there was a consensus that
this is desirable. The counter-argument was that the documentation
should be complete even if that means describing some terminal
types that are not universally configured.  After all, how would you
know your local installation is missing a terminal type if the=20
documentation doesn't even mention it?

> This patch fixes bug #1000676 =A0(Rotated multiline text misaligned).
> The alignment of rotated multiline text was correct for
> horizontal and vertical text but incorrect for other
> angles (they were handled as not rotated). This patch
> corrects this.

I don't agree that this was a bug.  It depends on what you want to
do with the text.  For me, the chief use is to squeeze more (or longer)
labels along an axis than would otherwise fit.  And in this case the=20
baseline should remain the axis itself, i.e. not rotated. IMHO it looks
really odd to have multi-line axis tic labels swing out and away from
the axis.

If you think it is useful to have the entire text block rotate as a
unit, I think we would need some new syntax or justification
option to specify it.  Can you give an example of when you
would want this?